|
Message
From: nico at seul.org<nico@s...>
Date: Mon Aug 23 16:41:54 CEST 2004
Subject: [oc] Parallel Array Processor Project
> [PM equals FPGA]
>
> [...]
>> > I could quickly think these differences:
>> >
>> > * The PM design should allow you to write programs for writing
>> > programs (e.g. compilers, text editors and so on). I'm not sure,
>> > if you could write a VHDL/FPGA compiler to FPGA?
>>
>> It's theorically possible. But the design will be udge. But it's
>> much easier, to put a LEON or an openrisc in the FPGA and
>> then used C ;D
>
> ;-) Would you believe me, if I say, that I tought that the PM would be
> mainly (?) used to run interpreters - a Java bytecode interpreter, a x86
> machine language interpreter and so on. That is, implementing
> sequential platforms using the parallel engine?
>
> I thought, that the applicable software base would be extended in many
> magnitudes, if I could implement a software to execute Java binaries
> and Python intermediate compilations...
>
:) why not !
> [self-reconfigurable FPGAs]
>> This is not common because nobody find an application for it.
>
> I can understand this, because of the area, where one uses FPGAs.
>
> [Virtual memory, PM and FPGA]
>> virtual memory are juste a means to "remap" real memory.
>
> Ummh, sorry, I meant that in conventional processor architecture this
> equals to disk swapping. The processor can execute the code directly
> from external RAM, which is something that the PM cannot do. The
> external RAM is swapping space for PM.
>
that's possible but not really effiscent at all. The internal buffer will
act as cache to the external chip. But the memory bandwith will is a hudge
bottleneck, you should keep it "exposed" to the codeur.
I didn't understand with FPGA vendor did not implement "common" IO as
internal IP. This block are usualy small but very time critical. They
could implement CAN, RS232, ethernet, pci, 1394, usb protocol, DDR-SDRAM,
hypertransport, PCI-E(?). That's cover a udge part of the interface used.
A cpu array must have few hypertransport link, few ethernet and usb link
and few DDR-SDRAM controller.
>> > I think that the ground reason for this is, that the PM cell
>> > is synchronous.
>>
>> From the point of view of the system, an FPGA cell could be
>> much more synchronous than a unpredictive cpu.
>
> Hmmh, I didn't quite follow this... Could it be possible to read the state
> of the FPGA cell, throw it to memory and replace it with some another
> state, thus continuing the suspended processing?
>
Yep, throught the boundary scan controlled by the JTAG interface. It's
mainly use for Fab testing.
>> Beside that, i don't think it possible for the humain brain to
>> track the state of each individual cpu in a 128 cpus array.
>
> With PM, you should be able track it ;-)
what a headheack...
>
>> > I borrowed the idea of the "transmission gateway"
>> > (accessing distant parts of the array) from the FPGA
>> > world :-)
>>
>> You could also look at the concept of "LAN on chip". This
>> use message passing instead of buses. Message passing
>> could be pipeline very easly.
>
> Would you believe, that I already have thought of having these kind
> of "buses" inside the array (something like a built-in serial interface or
> network)?
>
not bus ! message passing, lan, but not bus that require an answer.
> The idea is/was, that using that kind of transmission, the distant parts
> of the array doesn't need to be executed synchronously, thus allowing
> use of higher clock frequencies.
yep.
>
>> I imagine that a compiled programme is a tiny code that is loaded
>> in the program memory of each cpu. To look like a "usual"
>> cpu, it must be easly change. But it will be a hard task from the
>> HW point of view.
>
> Yes, the software is compiled to a bunch of instructions, and these
> instructions are loaded to individual processors. I haven't thought a
> much, how the program could be changed quickly...
The tiny code memory will have 2 ports, one for read, the other for
writing. So the write port could be used to update the code. The "input"
of this buses could be seen as an internal peripherals.
Nicolas boulay
|
 |
Browse
