[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] GNU Radio on different platforms.
Re: [Discuss-gnuradio] GNU Radio on different platforms.
Fri, 15 Jun 2007 02:12:09 -0400
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
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.
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
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.
PS - Sorry for such a long and lengthy post!