OPENCORES.ORG

I am however a hardware developer, and as such, one thing strikes

>> 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?
>

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

> 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?

That will be hard but i don't see why this could impossible.

>
> * 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...?

Most FPGA are SRAM based. So you "just" need the access to the SRAM buses.
A compagny have sell a fpga with high-bandwith configuration bus, much
faster than the usual serial link. It could also be reprogrammed partialy.

This is not common because nobody find an application for it.

>
> * 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?

virtual memory are juste a means to "remap" real memory. It don't think
it's the easiest way to spread a lot of tiny memory bloc.

You could always programm the use of an external memory chip.

>
> 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.
>

>From the point of view of the system, an FPGA cell could be much more
synchronous than a unpredictive cpu.

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.

> ---
>
> 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 :-)
>

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.
Buses could not, because of the semantic of the "read".

>> 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.

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.

>
>> 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... :-)
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores
>