Playstation 3

Cross-posting from hell…


I’m working on it. The basic architecture supports scatter-gather
with DMA chains. It’s pretty easy to set up and each SPE has it’s own
DMA engine (called Memory Flow Controller (MFC)). You can DMA from
main memory to/from SPE and SPE <-> SPE. The bandwidth of the EIB
(SPE/PPE/IO interconnect) is about 180 GB/sec. The bandwidth to
RAM is > 20 GB/sec. Not bad :wink:

I believe the difficulty in doing this with the Cell will be to schedule
the 8 SPE’s efficiently. Bayesian learning in EM will certainly fly at
the (say) 50 GFlops we can expect to get upon optimization of the CDR
code if we keep the SPE’s flaming. I have no doubt in my mind that we
can do blind learning about entire amateur bands and process them on the
fly in the Cell on the PS3 with USB2 delivery of the data! The
potential is just amazing now that it is here and upon us.

I’ve got some ideas on scheduling this beast. You know you’re in “full
immersion mode” when you’re dreaming about computer architecture.

super SDR you could have using it. Talk about some real fast DSP.
situation, I suspect that there are other aspects of the problem that
will drive your design (like A/Ds, signal distribution, and such).

Real time decoding of HDTV comes to mind…

Porting the GNU Radio HDTV code to the Cell will serve as our test

So, you’re already in a high data rate, high bandwidth
platform, and perhaps a software implementation isn’t the best system
solution (i.e. why not put it into an FPGA?)

FPGAs are great. I love them.
On the other hand you get to work in floating point on the cell
instead of fixed point.

From: Jim L. [email protected]
Subject: Re: [Flexradio] PlayStation 3
To: [email protected], Philip Covington [email protected]

The big thing going for a PS3 based solution is that because it’s a
consumer device, it’s cheap in a $/MFLOP sense. The question would
be whether, for a given application, you wind up spending more $ (or
time, which is the same, really) fitting your application into the
PS3 framework (to take advantage of the low hardware cost) than you’d
spend on a more expensive platform.

I believe that I can port GNU Radio to the cell in such a way that
most code “just runs faster.” I think that 10 to 20x opteron
performance is quite doable on the cell even with suboptimal
scheduling. GNU Radio’s data flow abstraction and the message passing
stuff are inherently parallel.

Busting it up into 256KB pieces shouldn’t be too hard. I’m thinking
about runtime linking of individual images for each SPE based on
walking the GNU Radio flow graph.


Eric B. wrote:


Slobber, drool. 8Mhz two-element interferometry, slobber, grunt.