Re: never enough

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Dear MISC readers:

Marco Al wrote:
> Excuse me... wasn't he suggesting taking an available graphics chip and
> connecting that to a MISC chip using the video memory as system memory?
> Would have some problems though, latency would be horrible and I think most
> grahpics chips flush their pipeline before granting direct memory access.

Yes.  I think you are right.  I was thinking he was talking about
putting 32MB on the chip rather connecting to a 3D video chip that
contained 32MB on-chip.  Yes, connecting to a 3D chip that way is
an interesting idea. But as you say there might be some performance
gotchas.  Still it might do some very impressive stuff without much
hardware and might be a fun toy to play with.

> <snip>
> 
> > The idea of the F21 design is to get a few hundred mips per megaword
> > of memory or per 32K words or memory depending on the configuration
> > of nodes.
> 
> What would the die size ratio (more meaningfull than transistor/gate #'s)
> between memory and logic be in those cases? (assuming embedded DRAM)

4/1 or 16/1 would seem very useful for embedded apps. Given that we are
working at about 70% whitespace at the moment 3/1 would be almost free.
But those would still be very small amounts of memory.  The F21 die
contains only about 1000 bits of memory.  If we used memory that 
was 4 times as dense as the memory in the stack cells etc. the active
area on the die would be equivalent to about 4000 bits or 200 words.
If all the white space were filled it would be around about 500 words.
If we made the chip 4x larger that would be a couple of K words.
Of course going to .2u would make the chip 16x smaller than it is
now.  So that would equate to 8K or 32K words or memory if die
sizes were equal. But of course there are many variations in 
types of memory that could be implemented some smaller some 
larger some slower some faster etc.

In large volume the cost of the F21 active die area is a few cents and
I/O pins at about one cent each dominate the total cost.   If you have
memory on chip like Chuck's P8 you can eliminate many pins to the
outside world and make chips or nodes very small and cheap.

> It has been clear for a while now that this kind of architecture is going to
> play a big part, the popularity of the FPGA is a sign on the wall...
> reconfigurability is a must, but FPGA's are too fine grained for a lot of
> applications. Pixelfusion already has a chip capable of multiple tera-ops
> for instance using the logic in memory approach (they use upwards of 1500
> basic processing elements). They are more aimed at numerical processing
> though, it was original meant to be a 3D processor... but they are now
> trying to retarget it to networking applications. A MISC processor would be
> better suited to the bit juggling required for that I think.

MISC processors make an interesting match to reconfigurable processors
since they provide a great deal of flexibility in the options due to the
small amount of required resources.  Instead of shoehorning them in
to an app by stripping them down you may be able to enhance one and
add custom features to help with a particular task.
 
> > One of the teams interested in the MISC multiprocessors are interested in
> > compression/decompression and have the best software out there at the
> moment.
> 
> Should I take "out there" and "best" with a pinch of salt? :) 

Always. I have not done an extensive survey and have not seen
everything.

> (the first
> because you seem to enjoy being flamboyant about knowing secrets, and the
> second because the story of supposedly revolutionary compression method's of
> which the details or even results cant be divulged is so common a pitch) Or
> are there any public references you could share?

I don't know what is public yet about our project.  As for the video
compression source the last time I visited their web site the
"live video feed usable with even a slow modem" was not working.
I don't know what sort of problem it had.  It boasts the highest
compression out there and I have little reason to think it is
a scam as they have other well known products.
http://www.livecam.com

But my point was that if you post an .rm file or file in MPEG1
format on the web it will not be as compressed as someone who
posted a file in MPEG2 format.  If you post in MPEG2 someone
else may post a file compressed with wavelets etc.  You can't
expect to hold the edge in the field because other people
working on fractals or wavelets or something new will produce
a newer and higher performance standard in the future.

I am not presently working on doing video compression with my
chips or trying to make the most efficient system.  I simply
posted something about offering videos in mpg and rm format
at lower cost or for free than in their present VHS tape
analog format and was responding to the comments about why
don't I use a higher level of compression or a more expensive
media.

> Strange, you would assume video codec's would be more suited to processors
> wich are better at numerical processing (for transformations and warping
> motion compensation and the like) although I know theres at least one group
> which uses adaptions of more conventional compression algorithms for state
> of the art video compression using for instance Lempel-Ziv which I think is
> more suited to MISC... so there might be more
> (http://pier.ecn.purdue.edu/~dxm/Video/Overview/).

Parallel processing for video compression was one of the topics that
we heard about at the Parallel Processing Connection.  There have been
some very innovative hardware and software approaches and I am sure
there will be more in the future.  There are interesting gains available
both from hardware and improved algorithms. 

Perhaps it is needless to say that I find some unusual techniques that
may be far superior to what people are using today to be the ones that
interest me the most.  They are also ones that might be attacked at
the hardware level more efficiently, but they often first appear as
software implementation of improved algorithms on standard hardware.

Jeff Fox