discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Playstation 3


From: Eric Blossom
Subject: [Discuss-gnuradio] Playstation 3
Date: Sat, 9 Dec 2006 10:53:35 -0800
User-agent: Mutt/1.5.9i

Cross-posting from hell...

> From: Frank Brickle <address@hidden>
> To: Bob McGwier <address@hidden>
> Cc: Jim Lux <address@hidden>, address@hidden
> 
> The 256KB per SPE, 256MB per PS3 limit is perhaps going to be more
> of a problem in the short term.
> I haven't looked much yet at the documentation  on the Cell SDK
> iso. Has somebody done a slick gather/scatter? ;-)
> 
> 73
> Frank
> AB2KT

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


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

> Date: Fri, 08 Dec 2006 14:12:30 -0800
> From: Jim Lux <address@hidden>
> Subject: Re: [Flexradio] PlayStation 3
> 
> At 07:42 AM 12/8/2006, Philip Covington wrote:
> >On 12/8/06, Jim Lux <address@hidden> wrote:
> >>At 05:25 PM 12/7/2006, Charles Greene wrote
> >>
> >> >There's a write up on PS3 and writing game software for it in the
> >> >latest edition of IEEE Spectrum.  I was just thinking about what a
> >> >super SDR you could have using it.  Talk about some real fast DSP.
> >>
> >>I have the impression that, most of the CPU in the current
> >>incarnation of PowerSDR is burned up in the GUI, not the DSP,
> >>right?  All those pretty displays, band scopes, Windows GDI
> >>stuff.  The actual signal processing hasn't changed much since the
> >>days when a 1GHz processor was considered adequate.
> >>
> >>Now, if you wanted to run hundreds of receivers covering 1.8-30 MHz
> >>simultaneously while synthesizing a phased array with 30 elements or
> >>something like that, you might need some more "cruch", but in that
> >>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 application.

> 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 Lux <address@hidden>
> Subject: Re: [Flexradio] PlayStation 3
> To: address@hidden, Philip Covington <address@hidden>

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]