Re: [Discuss-gnuradio] GNU Radio on different platforms.

[Brian Padalino]

On 6/15/07, John Kent <address@hidden> wrote:
> I am an amateur radio enthusiast, and am interested in implementing
> Digital TV. I believe, reading the GNU Radio web site, that that was one
> of the motivations of some of the members here. I have seen some screen
> shots of HDTV receiver pictures on the web site, but browsing through
> the archives I could not see much in the way of IP for the FPGA or MPEG
> encoders and so on for the transmitter. The web site looked as though
> the USRP is just used as a decimating front end and that all the signal
> processing is done in the PC with Python scripts. I would imagine an
> MPEG encoder would not lend itself particularly well to a scripting
> language and would have to be implemented as hardware in the FPGA.

In the general application of how it is generally used, I believe you
are correct.  Basically the USRP will get the signal down to 1 sample
per symbol, and the rest of the processing is done on the host side.

It should be noted that the Python scripting language is NOT where all
the work takes place.  The Python is strictly used to stitch the
pieces together - all the heavy lifting is done in C++ underneath it
all.

> I have a bit of an idea about how an MPEG encoder might work, but I am a
> bit foggy on how the data stream is encapsulated and transmitted. I
> recently attended an Avnet/Xilinx XFest seminar where they gave a talk
> about implementing video over ethernet, but their solution was to simply
> go out and buy an MPEG encoder core, which I thought was a bit rich. At
> least outside the price range of the average hobbyist.

A simpler way might just be to buy an MPEG PCI card to put into a PC,
and just have that run.  Moreover, if there is a hardware encoder,
there is usually a hardware decoder within the same card.

> I understand most of the work here is on the USRP Ettus Research Altera
> board. Is the Altera device on the USRP large enough for an MPEG encoder ?

By itself, it might be large enough - it has a good amount of block
RAM and flops in there, but within the entire system I highly doubt
it.  It's a little over 90% filled right now using the standard setup.
You can slim it down if you take out a few RX chains, but I am not
sure you could slim it down enough.

> I would like to use my existing Xilinx boards if possible.  I have a
> Virtex4 FX12 board with high speed dual ADC and DAC P160 module and a
> XC3S1000 board which I thought might be large enough for the video
> encoder. I thought I could connect the boards together over ethernet and
> use one as the encoder and one as the transmitter. It's pretty much pie
> in the sky stuff at this stage, and the labor involved in designing the
> MPEG encoder may well dwarf the cost of the boards anyway.

I believe Matt is working on a USRP2 which will host a Xilinx Spartan3
chip with embedded multipliers and all that snazzy jazz.  He has some
files within the svn repository if you feel like taking a peek, but
they are obviously under much construction.

 http://gnuradio.org/trac/browser/gnuradio/branches/developers/matt/u2f

> If the IP is designed well it maybe possible to port it from Xilinx to
> Altera and vice versa. I think the only real difference is in the
> implementation of on chip memory although of course the hardware
> implementation would be different. I'm not sure if the USRP uses a
> processor, but that may be another consideration.

The main differences between Altera and Xilinx targeting really is the
use of the SRL16 blocks within streaming applications.  Memories seem
to port over pretty easily, though Xilinx likes to use 16kbit sizes
whereas Altera likes 4kbit sizes.

Generally just retargeting for the new chip will be good enough
between the two different architectures.

> The USRP uses USB as the interface. Has any though been given to
> connecting the boards over ethernet so multiple boards can communicate
> between themselves ?

I believe the new USRP2 is supposed to have Gigabit ethernet instead
of USB as a main interface.  This could allow for better chaining of
systems together and possibly a pseudo-distributed model for how data
gets transmitted back and forth.  The possibilities are endless!

Now, as a side note, it seems as if your main concern was transmission
of HDTV signals over the air.  If you started with an MPEG source that
you were working from, did the required interleaving and FEC encoding
on the PC and just sent down the raw packet bits to the USRP over USB.
If you wrote an 8-VSB modulator in Verilog for the FPGA (much easier
than writing an MPEG encoder), then you would probably be in business
for at least transmission of HDTV.

On the RX side, much of the processing is done in any equalization of
the waveform and getting samples to end up as bits through the FEC
most likely (and can be proven by profiling the code).  If this is the
case, you can probably write the equalizer to work within the FPGA and
possibly even an FEC decoder.  This way, you are just transmitting
back interleaved (and already decoded) packets back.  The host PC
would then just have to deinterleave and send to the appropriate MPEG
decoder.

I had thought about writing a modulator for the FPGA which would do
simple constellation mappings given a number of bits per symbol and a
look up table then sending it through a raised cosine filter then the
interpolating CIC filter.  This could decrease the amount of traffic
over USB and shift the processing over to the FPGA.

I hope I have answered your questions.  It seems as if today was a big
FPGA question day.  I'd be glad to try to answer any others if you had
them, though my FPGA experience is relatively limited as well.

Brian

PS - Sorry for such a long and lengthy post!