|
Message
From: markus at reaaliaika.net<markus@r...>
Date: Mon Aug 23 15:00:50 CEST 2004
Subject: [oc] Parallel Array Processor Project
> I am however a hardware developer, and as such, one thing strikes
> me when I read about your ideas; Isn't it so that your architecture
> actually IS the architecture of an FPGA? Or very much like it
> anyway [...]
You're absolutely right here! Unconsciously I have thought that the PM
and FPGA have many things in common (for example, I have studied
using the VHDL as a programming language and I have borrowed many
ideas found from FPGAs to the possible physical implementations), but I
haven't thought this consciously.
Now I'm doing this first time, when writing this, so you probably
understand some "fuzziness" in the thougts... :-)
> [...] might be that the FPGA architectures have even
> simpler processing cells than the ones you have in mind?
That's true. What are the differences of the FPGA cell and the PM cell?
In ground level, the program written for PM could be compiled to the
FPGA, as well as for conventional processor. That's nothing new, I think,
every program can be implemented either with hardware or with
software or with a some kind of combination of both.
---
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?
BTW, one test for analyzing the completeness of the programming
languages is, that is it possible to write a program to output that
program with it? I don't know, if the VHDL passes that test?
* Furthermore, PM design should allow a program to "load" another
program inside the array. If I recall correctly, there has been some
attempts for creating "self-reconfigurable" FPGAs, too? But because of
the application area of the FPGA, I think that those oddities are not
very popular...?
* The PM chip should be able to execute larger programs that can fit
inside of the chip, by using a virtual memory. Normally, you don't have
this kind of possibilities in the FPGA, am I right?
I think that the ground reason for this is, that the PM cell is
synchronous. You can stop it for processing, read the state of it, store
it and later, restore the state from the memory and continue processing.
---
But PM and FPGA share many things, like inherent parallelism and cellular
structure. Some people could say, that PM is one implementation of so
called reconfigurable computing - I'd say, that it's just a massively
parallel processor.
> But they do have an instruction register
> (the LUT programming), a result register (output flip-flops), and
> read connections to their neighbours (the routing, even though
> this is more complicated in the FPGA case).
I borrowed the idea of the "transmission gateway" (accessing distant
parts of the array) from the FPGA world :-)
> but from what I've read in this thread I got the impression that
> you're thinking in the way of a programming language with lots of
> parallellism.
Yes, you're right here. My approach comes from the programming world
and I have just basic knowledge (which is not too much) of the
hardware desing world.
> Sounds quite a lot like hardware design, on RTL or somewhat higher
> level, to me... The RTL code can be seen as a "program" for an
> FPGA, the compiler then being the synthesis and place-and-route
> tools.
Yes, and I think, that the hardware designers would easier understand
the programming paradigms of the PM than regular software designers.
And, I have borrowed the idea of "cell mapper" from the FPGA world -
that is, the PM needs a program for mapping the virtual assembler code
to physical cells just like VHDL does.
> Interesting also that you call it a "processing memory",
> this name also fits quite good for an (SRAM-based) FPGA...
> Which is basically a memory with some processing facilities
> added (the people developing the FPGAs
> might not agree completely with this description... ;-)
:-) But yes, PM and SRAM-based FPGAs are close to each other. And
yes, PIM (Processing In Memory) architectures are close to these, too.
The name comes to very obvious thing: I was designing a memory,
which processes the data by itself.
> Do you think that this interpretation of your ideas makes any
> sense?
Perfectly!
> Maybe the fact that the processing cells you're thinking of are
> much more advanced than the current FPGA macrocells really
> adds a new dimension with regards to how the processor is
> programmed and so on?
Surely, the cells are more complex than the cells in the FPGA. About the
new dimension of processor programming, I'm not sure - my primary goal
is to get the PM to be programmable, without any extra pain (which it is
at the moment).
> Anyway, if my comparison stands, you probably can take some
> inspiration from hardware design and the associated tools.
I'll do that.
> (Take a look at e.g. "handel-C" from Celoxica, which is C
> with extensions for parallellism. They have a compiler for it
> that takes it all the way to hardware. They claim it is a
> very efficient way to design hardware. I don't know about
> that though... :)
I'll do that, altought at the moment I started the design of the HLL once
again from the grounds and decided to leave the world of the existing
languages behind... :-)
|
 |
Browse
