OpenCores
Home » All forums » Cores » Parallel Array Processor Project
First Prev 4/5 Next Last
Parallel Array Processor Project
by nico on Aug 23, 2004 		nico
Posts: 21
Joined: Jun 21, 2008
Last seen: May 11, 2009
Gunnar Dahlgren:

Isn't it so that your architecture actually IS the architecture
of an FPGA? Or very much like it anyway [...]


I added the comment with my reply to my web pages (feedback
section), because it just brought a whole new world in to my mind...

I also thought the issue a little further and made this addition:

"What really is the difference between the PM and the FPGA? I must
think more about this, because it could reveal some extraordinary
possibilities for the PM.

One thing is sure; the FPGA has been designed to process electronical
signals. The PM has been designed to process abstract signals - data.
PM is like a FPGA, not operating in the physical world, but in the
abstract, virtual data world. Does it make any sense?"


No :)

FPGA only manipulate one and zero. When you aggregate them, bit means
data, or abstracte data.

Do you remember of the coding paradigm : "intelligence must be in the
data". Software code is the data of the HW.

It's possible to put intelligence in hardware but it's more costly than
put it in "DATA", the software.

The PM is something in between. Instead of manipulating bit by bit as an
FPGA, it could manipulate a 8 bits high speed serial link. Instead of
using register, it use memory. Instead of using gate, it use an alu.

Because each pm is a cpu, you could handle very complexe controle
structure. In the FPGA world, controle became mega udge FSM... so udge
that some time a embedded cpu + a ROM is smaller and faster.

I don't know if it's better than your array look like a cpu (but very hard
to programm) or an FPGA (not supposed to reprogram it-self). This is
something in between at least for the kind of application. I imagine that
complexe and heavy data manipulation task could use it (as MPEG 4 codeur).

Maybe you should look at the code of ghdl.free.fr (it's vhdl simulator) to
look how synthetiser extract the hardware description langage to map it to
an FPGA. This synthetiseurs try to find known bloc : FSM, counter, ...

An cpu array compiler will look at "task block" or map the content of a
vhdl process in it, directly.

Nicolas Boulay


Parallel Array Processor Project
by markus on Aug 23, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
[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...


Parallel Array Processor Project
by Unknown on Aug 23, 2004 		Not available!
At 15:00 2004-08-23 +0200, markus at reaaliaika.net wrote:

[...] 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?


An FPGA cell basically consists of a look-up-table (LUT) with four
binary inputs and one binary output. At the output there is a one-bit
register (flip-flop). The LUT can be programmed by a 16-bit word
(= "the program"), whose bits are the value of the output for the
2^4 possible combinations of the inputs.

In reality, the basic cell of the FPGA is a little bigger, containing
a few LUTs and flip-flops, and some multiplexers to allow the LUTs to
be combined in different ways.

The "program" of each LUT is normally loaded during boot-up configuration
and then stays the same. But also see below.

I guess the PM cells are at least a few bits wider, but what other
differences are there?

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


You can. If not in other ways, you can implement a traditional CPU in
the FPGA to do it... :-)
I believe (without knowing) that this would also be the most efficient
way of implementing a compiler in an FPGA. But I guess it should be
theoretically possible to actually implement a compiler as general
hardware (FSMs, datapaths...), which reads source code from a connected
memory, and produces machine code in another part of the memory.

I wouldn't like to design that hardware though. Hardware design (at
RTL level) can be said to be at an abstraction level below assembly
programming, and I guess most programmers would be very unhappy even
to have to write a compiler in assembly language.

This shall, however, not be confused with the general abstraction
level of VHDL (or Verilog). Only subsets of the languages are
synthesizable (ie possible to use to describe RTL hardware). You can
use those languages to write code at a somewhat higher abstraction
level as well, but then it can only be executed in a simulator (ie on
an ordinary CPU). It can not be executed in an FPGA fabric, due to
that we don't have tools for synthesis/compilation of the complete
languages. Such tools have long been attempted, Celoxica's tool is
one attempt (although it uses a C-ish language instead of VHDL/Verilog).

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


No I'm not sure if the feature is used a lot, but it is possible in
e.g. Xilinx Virtex FPGAs. I also think Celoxica developed a demonstrator
a few years ago that used this feature. (some kind of PDA-like thing
with the possibility to run a few different "applications", the selected
one were then loaded from memory into (parts of) the FPGA. The
demonstrator didn't have a normal stand-alone CPU chip, but surely had
one or several soft CPUs in the FPGA.
(no, I'm not a Celoxica sales rep, I have no connection whatsoever with
them... ;-)


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


Not normally used, but not at all impossible I would say.

Regards
Gunnar



Parallel Array Processor Project
by nico on Aug 23, 2004 		nico
Posts: 21
Joined: Jun 21, 2008
Last seen: May 11, 2009
[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


Parallel Array Processor Project
by markus on Aug 23, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
Below, there's replies to other postings, too.

---
Gunnar:
An FPGA cell basically consists of a look-up-table (LUT) with four
binary inputs and one binary output. At the output there is a
one-bit register (flip-flop). The LUT can be programmed by a
16-bit word (= "the program"), whose bits are the value of
the output for the 2^4 possible combinations of the inputs.
In reality, the basic cell of the FPGA is a little bigger,
containing a few LUTs and flip-flops, and some multiplexers
to allow the LUTs to be combined in different ways.
The "program" of each LUT is normally loaded during
boot-up configuration and then stays the same. But also see below.

I guess the PM cells are at least a few bits wider, but what other
differences are there?


If I describe the PM cell in the same way, I would write: "A PM cell
basically consists of an ALU with two 8-bit inputs and one 8-bit output.
The ALU can be programmed by a X-bit word. The result of the inputs is
calculated to result register, when the inputs are ready.
For real world implementations, the one ALU is shared amongst multiple
cells (in other words, ALU may have more than two inputs and one
output), with some additional hardware for accelerating."

One thing is, that in (current) PM model, you implement aggregate data
types using streams of bytes. I selected that approach, because it
won't need synchronizing multiple cells and it require wider ALUs for
processing large data elements.

[Program for writing programs]
You can. If not in other ways, you can implement a traditional CPU
in the FPGA to do it... :-)


Ah, yes, of course :-)

I believe (without knowing) that this would also be the most
efficient way of implementing a compiler in an FPGA.


I have been thinking the same kind of analog for the PM, too - using
interpreters for processing data. So, analoguously:

FPGA has CPU cores PM has interpreters

This shall, however, not be confused with the general abstraction
level of VHDL (or Verilog). Only subsets of the languages are
synthesizable (ie possible to use to describe RTL hardware). You


This was new for me, but really, I should have guessed that.

(some kind of PDA-like thing with the possibility to run a few
different "applications", the selected one were then loaded
from memory into (parts of) the FPGA.


Sounds very interesting!

---
Nico:
> One thing is sure; the FPGA has been designed to process
> electronical signals. The PM has been designed to process
> abstract signals - data. PM is like a FPGA, not operating
> in the physical world, but in the abstract, virtual data world.
> Does it make any sense?"


No :)


:-(

..Allright, I'll try to invent something else :-)

The PM is something in between. Instead of manipulating bit by bit
as an FPGA, it could manipulate a 8 bits high speed serial link.
Instead of using register, it use memory. Instead of using gate,
it use an alu.


Yes, right.

Because each pm is a cpu, you could handle very complexe controle
structure. In the FPGA world, controle became mega udge FSM... so
udge that some time a embedded cpu + a ROM is smaller and faster.


It's extremely hard, if not impossible, to beat the CPU+memory
architecture in the compactness. I wouldn't even try to do that.

I don't know if it's better than your array look like a cpu (but
very hard to programm) or an FPGA (not supposed to
reprogram it-self).


You're certainly right here!

This makes my project even harder. To be successful:

* It should be easy to program :-)
* It should beat FPGA in the data processing areas, that is, the cell
processor should be tighter than implementing the same logic with FPGA
* It should beat conventional processors in the performance of
computing

I'll try to encourage myself to try it...

Maybe you should look at the code of ghdl.free.fr (it's vhdl
simulator) to look how synthetiser extract the hardware
description langage to map it to an FPGA.


I will certainly do that!

An cpu array compiler will look at "task block" or map
the content of a vhdl process in it, directly.


I have thought, that the compiler will output microcode programs for
cells, thus mapping certain sequential processes directly for the
sequential cell processor.

[reading the state of the FPGA]
Yep, throught the boundary scan controlled by the JTAG interface.
It's mainly use for Fab testing.


Oops, I totally forget this!

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

Sorry, I'm not very familiar with the terminology.



Parallel Array Processor Project
by markus on Aug 24, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
Question was: "Isn't the PM an FPGA? What are the differences between
those?"

I thought this somewhat hard at yesterday evening, but I haven't yet
found any good answers. The fact is: The PM can be implemented using
FPGA, and if I ever reach that point, it's implemented using FPGA.

So, for FPGA point of view, PM is just one CPU core amongst the others.
But I'll keep thinking a little bit about the common features and
differences between these two.

In the meantime, I'll continue the development :-)

---

If I describe the PM cell in the same way, I would write: "A
PM cell basically consists of an ALU with two 8-bit inputs
and one 8-bit output."


This was a little bit wrong - the cell has N inputs (N >= 3), and the
internal processing unit has two inputs (selected from the neighbor
results).

For real world implementations, the one ALU is shared amongst
multiple
cells (in other words, ALU may have more than two inputs and one
output), with some additional hardware for accelerating."
And here, the ALU doesn't have more than two inputs, but the so called macrocell can have. --- I wrote a short initial PDF of the abstract hardware model of the PM: http://reaaliaika.net/pdfs/pm.abstract.hw.000.sxw.pdf ..And, of course, I wrote a short initial thoughts about the real world hardware implementations: http://reaaliaika.net/pdfs/pm.realworld.hw.000.sxw.pdf
Parallel Array Processor Project
by Unknown on Aug 25, 2004 		Not available!
Markus, Your project is so called medium-grained programmable array. I would say the compiler flow is more similar to FPGA / synthesis. There is a (startup) company trying to push FPOA (field programmable object array) for math applications from FPGA side. On the other hand there is also company called PACT, which have solutions in this area for some time, and have also done a lot of work in parallel-C and stuff for their CPU arrays. You can see that latest observations are not new and are one of three ways to go in the future (fine, medium and large grained arrays). The architecture really depends on the problem you are trying to solve. So far multiprocessor arrays with fast CPUs have proven best for more sequential problems and FPGAs have proven best for massive parallel applications. best regards, Marko On Tuesday 24 August 2004 13:25, markus at reaaliaika.net wrote:
Question was: "Isn't the PM an FPGA? What are the differences between
those?"

I thought this somewhat hard at yesterday evening, but I haven't yet
found any good answers. The fact is: The PM can be implemented using
FPGA, and if I ever reach that point, it's implemented using FPGA.

So, for FPGA point of view, PM is just one CPU core amongst the others.
But I'll keep thinking a little bit about the common features and
differences between these two.

In the meantime, I'll continue the development :-)

---

> If I describe the PM cell in the same way, I would write: "A
> PM cell basically consists of an ALU with two 8-bit inputs
> and one 8-bit output."


This was a little bit wrong - the cell has N inputs (N >= 3), and the
internal processing unit has two inputs (selected from the neighbor
results).

> For real world implementations, the one ALU is shared amongst
> multiple
> cells (in other words, ALU may have more than two inputs and one
> output), with some additional hardware for accelerating."
And here, the ALU doesn't have more than two inputs, but the so called macrocell can have. --- I wrote a short initial PDF of the abstract hardware model of the PM: http://reaaliaika.net/pdfs/pm.abstract.hw.000.sxw.pdf ..And, of course, I wrote a short initial thoughts about the real world hardware implementations: http://reaaliaika.net/pdfs/pm.realworld.hw.000.sxw.pdf _______________________________________________ http://www.opencores.org/mailman/listinfo/cores





Parallel Array Processor Project
by markus on Aug 27, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
Your project is so called medium-grained programmable array.


Thanks! With this keyword in google, I found very similar things that I
have in my web pages!

I'll keep going through the search results to find out, what the other
people have learnt from processing arrays.

(Damn, I hate Internet! I try to find out the problems in the
architecture, but most of the material is either advertisements praising
the excellence of the company's solution, or then they are abstracts to
scientific publications, which are not available on-line... Maybe I should
go to the University's library [the one, which exists in the real world])

would say the compiler flow is more similar to FPGA / synthesis.


Yes, I noticed that :-)

You can see that latest observations are not new and are one of
three ways to go in the future (fine, medium and large
grained arrays).


Yes, I figured this out when scetching the processor cores.

The architecture really depends on the problem you are trying
to solve.


Yes, true. I concentrate on the problem area of general-purpositiness.
The architecture doesn't need to be as fast as a specialized solution,
but it should give moderate speed for all kinds of computable problems.


Parallel Array Processor Project
by Unknown on Aug 30, 2004 		Not available!
On Friday 27 August 2004 07:46, markus at reaaliaika.net wrote:
> Your project is so called medium-grained programmable array.


Thanks! With this keyword in google, I found very similar things that
I have in my web pages!


You might also want to look for "field programmable arithmetic array"
and "fpaa" (ignoring the answers where the first "a" means "analog").

-- Jecel


Parallel Array Processor Project
by nico on Aug 30, 2004 		nico
Posts: 21
Joined: Jun 21, 2008
Last seen: May 11, 2009
On Friday 27 August 2004 07:46, markus at reaaliaika.net wrote:
> Your project is so called medium-grained programmable array.


Thanks! With this keyword in google, I found very similar things that
I have in my web pages!


You might also want to look for "field programmable arithmetic array"
and "fpaa" (ignoring the answers where the first "a" means "analog").
I fund this : http://www.di.ens.fr/~jv/HomePage/pdf/fpga99.pdf nicO
-- Jecel _______________________________________________ http://www.opencores.org/mailman/listinfo/cores




Parallel Array Processor Project
by Unknown on Aug 30, 2004 		Not available!
Hi.

I've actually done a bit of work on what I called "Parallel Data Path
Arrays", or PDPAs for short. The comunication was all with 8-bit
busses, not serial, so it's not a direct comparison.

The thought was that it would make a good candidate for an SBIR (small
business inovation research grant). However, I hate wasting taxpayer
money, and after the initial research turned out poorly, I killed the
project.

What I remember about PDPAs vs. FPGAs:

- Routing dominates both. The actual computation elements are a small
percentage of either (switches.
- Control logic still has to be implemented, and so an FPGA-like fabric
needs to be included in the PDPA.
- The ratio of area devoted to the FPGA like fabric vs the PDPA fabric
was around 1:1.

Basically, unless an application used a lot of datapaths, and not much
random logic, it was a poor fit for a PDPA. However, that's OK. But it
got worse when I started doing more comparisons.

The basic problem was that each bit of each bus still needed to go
through a complex routing fabric to get to a destination. The routing
fabric for the PDPA was smaller than that used in an FPGA, but by less
than about 2x in area. Even using 8-bit buses didn't help much, since
we still needed individual networks of switches for each bit, and the
control logic for Xilinx's switches takes up a small fraction of the
total area devoted to routing.

I was unable to get the PDPA fabric down to 1/2 the area of an FPGA for
any realistic class of applications. Even if I had, a factor of 2 isn't
enough to both spending money trying to compete against Xilinx. I
basically concluded that there isn't any real market for these kinds of
parts.

Bill



Parallel Array Processor Project
by markus on Aug 31, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
Nico wrote:
I fund this : http://www.di.ens.fr/~jv/HomePage/pdf/fpga99.pdf


This was interesting! Thanks for all others, too, for the links and other
things.

The model in FPGA99-document has a lots of design issues I'm
interested in - the most interesting for me is the use of "narrow" (4-bit)
ALU and chained arithmetics, which is one of the corner stones in my
design (I decided to initially start from 8-bit ALUs, just to make the
things easier at first).

Yes and I agree with the writers and many other people, that using
programmable data flow engines probably come first as a coprocessors
between regular CPU and DMA/memory (the CPU configures the DFE and
puts data flow through it), altought I'm not personally interested about
designing such thing :-)


Parallel Array Processor Project
by nico on Aug 31, 2004 		nico
Posts: 21
Joined: Jun 21, 2008
Last seen: May 11, 2009
Nico wrote:
I fund this : http://www.di.ens.fr/~jv/HomePage/pdf/fpga99.pdf


This was interesting! Thanks for all others, too, for the links and other
things.

The model in FPGA99-document has a lots of design issues I'm
interested in - the most interesting for me is the use of "narrow" (4-bit)
ALU and chained arithmetics, which is one of the corner stones in my
design (I decided to initially start from 8-bit ALUs, just to make the
things easier at first).


You you want power, the "good width" is better. With an 8 bits alu, you
will need 4 times it for 16 bits op. Almost twice the ressource of a true
16 bits alu.

So if target DSP market, datapath of 16 or 18 bits will deliver "more
usefull" power.


Yes and I agree with the writers and many other people, that using
programmable data flow engines probably come first as a coprocessors
between regular CPU and DMA/memory (the CPU configures the DFE and
puts data flow through it), altought I'm not personally interested about
designing such thing :-)


Such pure arythmetic array quite bad for control. But mix of cpu +
datapath could do what you want at the beginning : create some VM for java
or perl.




Parallel Array Processor Project
by markus on Aug 31, 2004 		markus
Posts: 32
Joined: Dec 9, 2002
Last seen: Apr 30, 2013
[narrow ALUs]
You you want power, the "good width" is better. With an 8
bits alu, you will need 4 times it for 16 bits op. Almost twice
the ressource of a true 16 bits alu.


But 16-bit ALU would require 16-bit buses between the cells, thus
doubling the routing area... And in my plans, I think it's better to
have 2 x 8-bit independent buses than have 1 x 16-bit bus - or to have
4 x 8-bit separate data flows than single 32-bit flow.

I have tought hard for possible 5-bit implementation of the cell - 4-bits
for "raw" data (one hex nibble) and 16 different flow control instructions
(flow breaks, field breaks, "parenthesis" and so on).

So if target DSP market, datapath of 16 or 18 bits will deliver
"more usefull" power.


True, but general-purpose processors, like MCUs, need to deal with
almost arbitrary sized data elements, so ALU width doesn't really matter
(because it can't be the size of the largest element). Much of the MCU
programs are just plain data transfers from memory location A to
memory location B, and consecutive conditional branches ("if", "switch").

This area is definitely not the first one in anybody's mind to apply
arithmetic arrays, I know ;-D But like I stated before, the _true_
(hardware) goals are in the future, when we start to wonder, what to
do with the billions of transistors in a chip.

Of course, I wouldn't mind, if the array executing control code could be
implemented today and find to be useful. Maybe the real-world
implementation is a mix of different sized (& equipped) cells and buses?
5-bit cell arrays controlling/configuring pure 64-bit floating point
arithmetic arrays (i.e. just scalar floating point reconfigurable routes)?

[Arithmetic arrays as coprocessors]
Such pure arythmetic array quite bad for control. But mix of cpu +
datapath could do what you want at the beginning : create some VM
for java or perl.


I already have VM written with Python (PMVM). In that VM, I have
passed all the hard things (like arrays and such) and concentrated only
to form instruction set.

Currently, I moved the HLL design to the future (because of having hard
times to invent good control structures) and started instead to
implement a "toy" HLL and during that I implement a VM of even higher
level to test the concept.

ToyHLL isn't meant to be complete or something like that, it's aimed to
be a test platform for control structures and easy to use for
constructing "PM-like" software.


Parallel Array Processor Project
by Unknown on Sep 4, 2004 		Not available!
Le Lundi 30 Août 2004 18:33, Bill Cox a écrit :
Hi.

I've actually done a bit of work on what I called "Parallel Data Path
Arrays", or PDPAs for short. The comunication was all with 8-bit
busses, not serial, so it's not a direct comparison.

The thought was that it would make a good candidate for an SBIR (small
business inovation research grant). However, I hate wasting taxpayer
money, and after the initial research turned out poorly, I killed the
project.

What I remember about PDPAs vs. FPGAs:

- Routing dominates both. The actual computation elements are a small
percentage of either ( switches.
- Control logic still has to be implemented, and so an FPGA-like fabric
needs to be included in the PDPA.
- The ratio of area devoted to the FPGA like fabric vs the PDPA fabric
was around 1:1.

Basically, unless an application used a lot of datapaths, and not much
random logic, it was a poor fit for a PDPA. However, that's OK. But it
got worse when I started doing more comparisons.

The basic problem was that each bit of each bus still needed to go
through a complex routing fabric to get to a destination. The routing
fabric for the PDPA was smaller than that used in an FPGA, but by less
than about 2x in area. Even using 8-bit buses didn't help much, since
we still needed individual networks of switches for each bit, and the
control logic for Xilinx's switches takes up a small fraction of the
total area devoted to routing.

I was unable to get the PDPA fabric down to 1/2 the area of an FPGA for
any realistic class of applications. Even if I had, a factor of 2 isn't
enough to both spending money trying to compete against Xilinx. I
basically concluded that there isn't any real market for these kinds of
parts.

Bill


In that case, you just connect ALU. There is not any control ? But if you add
the control part that you find in cpu, things change, no ? Control part stay
in some cpu, alu are use for the data path.

From your experience, what is the need of routing ? What is the average

"fanout" ? What is the influence on direct neibourghood fast connection in
the design ? (Is that used often in real world application ?) What do you
think of some "software based" routing ? If you could reduice FPGA type
routing, you could almost use 4 times more cells ?

nicO



First Prev 4/5 Next Last
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.