Recently, I started again thinking about massive-parallel processor, which I last time designed in early 90's. You can get more information from my web pages: http://reaaliaika.net/showarea.php/procmem Short description: It's a general purpose, programmable, fine-grained massive-parallel processors, it's basically, but not purely a DFM. Why to announce here? If you get interested about the idea, you could help me in many ways. First of all, I'm more a programmer than a CPU designer, so if you have any idea for my "Simple-Cell" or "Macro-Cell" design, I'd be pleased. Second, you could point my browser to projects somewhat similar to mine. And third, I'm of course very interested to get some feedback of my project.

Aloha! markus at reaaliaika.net wrote: One project you should check out is the Raw project. The Raw architecture is very much what you have been thinking about: Lots of small processing elements connected on-die. They have produced real chips and have done quite a lot of work on the non-trivial aspect of programming the beast. There are several other projects. There is at least one project at IMEC in Leuwen that have produced a chip with a programmable (read: configurable) processing array. MITs old Transit project should provide some interesting pointers too. Patterssons iRAM-ideas too perhaps. I took a look at your page, and unless I'm fooled by the PovRay-images, you are thinking in terms if a 3D-array, no? If you are I think you should try to keep that 3D-thingy shallow. Eveb though state of the art technologies provides 10+ metal layers it still don't provide very much in terms of a third connectivity dimension. And, besides the functionality is still implemented at the bottom of the chip. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Hi Markus I was looking at implementing a 8 CPU processor array in a 300K gate Spartan 2e. I've implemented a very simple 16 bit microprocessor and I figure I can fit 8 of them in the XC2S300e. http://members.optushome.com.au/jekent/Micro16Array/index.html The idea was to use the onchip block RAM with the memory segmented in 8 x 1Kbyte blocks. The RAM is driven through a non blocking address and data bus switch in such a way that each processor can write into other CPU's memory but still have its own shared local base page memory. Bus arbitration is prioritized so that the highest memory has the highest priority access by the local CPU. This means that any CPU writing a message to a given CPU's base page memory will have priority. CPU access arbitration is also prioritised based on the position of the messaging CPU's base page memory in the othe CPU's memory map. The blocks are mapped differently in each CPU such that they all have their own base page memory. The CPU's have one interrupt which is used for message passing and is triggered when one processor writes into another processors base page memory. I was going to use my VHDL 6809 clone core to control the processor array from a separate board but had a few problems working out the clock sharing between the boards. (I wanted to make them synchronous) I've got so far with it having designed the CPU core, RAM switch and most of the priority bus access logic.... but sort of lost interest as I could see no real use for it, and was getting a bit sick of CPU design. I'm not sure what scale you are interested in designing on, what size chips and how many. My budget only supports simple 300K gate devices and free web pack software. You might also consider what you can do with 2D and 3D cellular automata designs. John. markus at reaaliaika.net wrote: -- http://members.optushome.com.au/jekent

Aloha! The Raw project is here: http://www.cag.lcs.mit.edu/raw/ -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Alright, I'll take a look on that. Unfortunately I wasn't able to open the
link you gave in your following posting, but I'll use google to find the
project. Thanks for the other links, too.



No, you're not fooled - the fundamental approach is to use a 3D array,
a "cube" of cells.



I know this and I write something about it in the chapter "Cell Array
Organization". I have no formal proof, but my intuition says that
two "layers" (while using 3D model) is the absolute minimum to get the
thing working - and fortunately it's quite easy to design those two
layers with one transistor layer (i.e. using current IC processes). Of
course, it's possible to use just one layer, but you have to have
crossovers in it (shown in the last example there) - or
special "crossover" instruction in the cell.

This intuition comes from the fact, that the electronic designs can still
be drawn to one sheet of paper and that 2-layer PCB can be used for
implement almost anything, if just the ICs are provided in DIP
packages...

---
But besides of this, I'm not sure, if the 2D layout could ever give
reasonable results for the cell array for two reasons - first, it can be so
that one transistor layer is just not enough to carry enough cells to get
real benefits of parallel processing, and second, it's possible that the
software compiled to 2D array has too long data transmission paths to
operate fast enough (without any hardware acceleration solutions).

So, basically I'm designing for 3D world, but I keep continuously in mind,
how to implement things with current technology.

I took a look of your design (I'll study it more closely later). We have
one difference in fundamentals: in my model, processors can change
only their own state (i.e. memory), they have read-only access to the
states (memory) of the neighbor. I selected this approach as the base
of the design to overcome the difficultiness in concurrent writes (i.e.
multiport RAM cells).



Here's another difference in fundamentals: I'm trying to achieve a stand-
alone architecture, with no need for controlling devices (others than a
normal CPU have).



You said it ;-) One possible future of my project.



Currently, I'm just scetching the fundamental needs for cells, which
could be used to construct that processor "cube". I must say, that I'm
a little bit sceptic, if the 2-layer "cube" would give anything new you
haven't seen already. I place my hopes to future IC manufacturing
technologies... :-)

But there's a small hope, that some of the hardware implementation
alternatives could really be a platform to implement a real, functional
and useful processor (altought that probably requires a huge amount of
gates; something like 20 million). In my dreams this kind of useful
processor would be a "parallel co-processor" in a PCI board. To go
further, if it's possible to get a Pentium-compatible pin layout and
replace the old PC's processor with a parallel one, that would be much
more interesting... But the way to go there is long.



I'm not yet looking a physical implementation, software simulations are
more than enough. But I could really benefit for a VHDL-models of cell
implementations.



Yes, this was the "magic word" I'd forgot! Thanks, I'll go to the web to
search more information.

Hi Markus, markus at reaaliaika.net wrote:
With a cellular automata design you can get away with two port memory
because you only have
the processor and it's neighbour accessing shared memory.


You need some mass storage, and usually this is localise to one of the
CPUs. To keep the design
symetrical I was going to use the 6809 to load and save code by using
the dual port facility of
the Xilinx Block RAM. There is no reason why the 6809 can't be on the
same chip
It was only a size constraint of the FPGA. Back in the early 90's when I
was doing my masters
my supervisor had a 16 Transputer array organised in a hyper cube (I
think). They were running
Helios on it as I recall with a PC host for file serving. They used a
CSP style message passing
system on th transputer.




I attended an FPGA conference in the UK back in 1997. There was a paper
on 3D semiconductor
design ... The problem as I understand it was to be able to pollish the
surface of the chip such that
it was level enough to grow another silicom layer on it. I had the
opportunity earlier this year
to speak with the Xilinx Fellow Bill Carter who said that they hard
largely overcome the pollishing
problem but presumably there are other reasons why you can't go vertical
...

I was interested in using Cellular Automata for image processing at one stage, but the FPGA chips were too small at the time to do any thing serious ... I was half wondering if there was any way to block move data in and out of an array quickly so that the cellular automata could work on "patches". Moving the data around meant that the processing array was sitting idle most of the time, but I guess there are ways to pipeline the data flow. Also it seemed a waste in region growing routines that only the processors on the edge of the "wave front" did anything, and was pondering if there was some other way to "farm" cells, so that as the wave front increased in size you could use more CPUs. John. -- http://members.optushome.com.au/jekent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040715/08c55d4e/attachment.htm

OK, I read the available information of RAW, Transit, iRAM and those.

RAW is "regular" transputer -like architecture. The similarities between
these architectures and mine is the connection network (just ot
neighbors) and for the same reasons - this kind of network is highly
scalable compared to any central-controlled networks.

The difference between my project and these "transputer" -like
architectures are the cell design. Both transputer and MIT RAW use
quite regular CPUs as processing nodes. I'm trying to construct an
independent cell, which have:

- 1 instruction word memory (maybe 12 bits?)
- 1 x 8-bit write-only memory element
- N x 8-bit read-only memory (N = number of neighbors, possible values
might be 4, 6 or 8)

You might think, that my "macrocell" units bring the project closer to
transputers, but it's not entirely true. "Macrocells" are there just to
reduce transistor count by "simulating" the operation of multiple cells -
thus many logic circuits can be shared, altought the speed drops
because of sequential execution.

Because cells are basically (but not purely) DFMs (Data Flow Machines),
the "macrocells" are DFMs, too. I have already found DFM designs, but
they mostly concentrate for implementing a - could we say - large scale
DFM, with a pool of processors and common memory. Altought for these
differences between my "macrocells" and those DFMs, I was able to
refine my design using the information available on those.

For programmers point of view, there's no semantical difference, if the
processor hardware is constructed from single cells or macro-cells or
with a hybrid model (using both macrocells and single cells in various
combinations). It's possible to use even a heterogenous model, i.e. not
all cells are able to perform all instructions - or the instruction
completition time may vary. For example, single-cycle multiplication,
which takes a lots of space, could only be performed in one cell, while
others implement it with chained adding-and-shifting (taking several
cycles).

I also searched information about cellular automatas. I found something,
but most of these systems are not aimed to produce a computational
platform or to be used in physical world (only in computer simulations).
I'll keep my eyes open for these.

[multiport memories]


Yes, true. I just try even simpler. Altought last night when I was waiting
for sleep I realized, that there could be some use for cell operations,
which could change the state of the neighbor. But I must refine my
instruction set to see it...

[stand-alones]


Of course. Normally, when I'm scetching a virtual processor core, I left
the code download issues (just like MMU's and such) out of the design
at the first phase. But the concept I'm scetching now is different
enough from my other designs, that I think it's important for me to keep
in mind (and scetch), how to implement programs with the array to
program the array.

If I am ever going to make a prototype out of the design, I probably
leave the programming issues last ones to try out. Before that, the
array is programmed by an external controller (e.g. PC).


I attended an FPGA conference in the UK back in 1997. There was a
paper on 3D semiconductor design ...

Aloha! markus at reaaliaika.net wrote:


OK, I read the available information of RAW, Transit, iRAM and those.

RAW is "regular" transputer -like architecture. The similarities between
these architectures and mine is the connection network (just ot
neighbors) and for the same reasons - this kind of network is highly
scalable compared to any central-controlled networks.

The difference between my project and these "transputer" -like
architectures are the cell design. Both transputer and MIT RAW use
quite regular CPUs as processing nodes. I'm trying to construct an
independent cell, which have:

Offtopic: I meant, that I already have readed the basics of those
projects. I'll of course continuosly search more information of those.

---


Yep, sure, I readed all the material I quickly found and I'm looking
forward to get more information. But unfortunately at the moment the
RAW material hasn't had anything I haven't already know and to be
honest, the fundamental approach difference between RAW and my
project could mean, that I can't find anything very useful from the
materials. But I'll keep reading that material.

If you think a RAW-based computer or a transputer, where you don't
compile programs to nodes but use fixed software modules inside of
those and design the software using only that fixed set of cell code,
you're designing more or less the same thing as I do.


[...]


I already did that.



Thanks.

I also earlier found a DFM design from here (OpenCores), in fact that led
me to announce my project here :-)

Le Jeudi 15 Juillet 2004 11:33, Joachim Strömbergson a écrit :


This can't be a new architecture target for HDL ?

I imagine that it could possible to exchange macrocell with tiny cpu (8 or 16
bits ?). If some connection could be change (like chaining alu of different
cpu), maybe a lot of power could be used for code with a lot of complexity in
the control part.

Nicolas Boulay

----- Original Message ----- From: Nicolas Boulaynico at s...> To: Date: Sat Aug 14 00:05:53 CEST 2004 Subject: [oc] Parallel Array Processor Project

I'm not sure, if you're heading this question to me or to Joachim, but I'll
answer anyway.

For MIT RAW, yes there are. They have already made it on silicon. For my project, from the HW point of view, there are no HW specifications, just thoughts. I'm not a HW specialist and not very familiar with VHDL and such things. I have a software simulator (VM, Virtual Machine, written with Python) of the model and I'm writing a HLL compiler for it. (Almost) all the existing material can be found from my website (http://reaaliaika.net/showarea.php/procmem). Nicolas Boulay:

Sure. I have already thought of having tiny 8-bit microcode programmed
cells in the array, but of course there's lots more possibilities for
constructing the chip.

Many people have suggested, that the cell should preferaly be 16-bit or
wider, but I still think, that it's better to design the software for 8-bit
cells and thus increase the number of execution units.



That's possible too. I already thought, that there could be
synchronization "bypass" in the one-arg cells, so that you can directly
join several cells together. The compiler could decide the bypassing,
there's no need for complex HW for that (at least currently I think so).

For two or more arg cells, I think that the by-passing won't work. The
args can enter the cell in different times, so only in rare cases you can
be sure, that all the args are ready for processing. But in some cases,
yes, it should be possible.

All: There Is a complete body of knowledge relative to SIMD processing. http://www.cse.ogi.edu/~strom/papers/cnaps.pdf Is a web site that describes a commercial architecture ( I managed Hardware Engineering there for a short period.) Motorola also made an experimental chip called VeComp related to the work of this company (Adaptive Solutions). You certainly should understand the MMX extensions to the Pentium as a preliminary to building the kind of core you are talking about. There may be ways to leverage some of the software developed for MMX -- there may also be ways to leverage the CNAPS software. A word of caution. The application space for these machines is high performance digital filtering ( neural networks have not proved commercially viable). In this space throughput is critical. You must consider back-end issues ( at the leading edge ) if you plan for anything that could be actually competitive -- MACS/sec is the figure of merit -- beating the DSP's ( and the Pentium MMX for that matter) is not easy. bj Porcella http://pages.sbcglobal.net/bporcella/ ----- Original Message ----- From: patrick.pelgrims at pandora.be> To: cores at opencores.org> Sent: Sunday, August 15, 2004 11:15 AM Subject: Re: [oc] Parallel Array Processor Project