|
Message
From: markus at reaaliaika.net<markus@r...>
Date: Mon Aug 23 16:01:20 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...
[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.
> > 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?
> 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 ;-)
> > 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)?
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.
> 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...
|
 |