FPGA in USRP

GNU Radio
1

Hi All,

I have worked with VHDL for 3 years and would want to make use my
knowledge
to do some research in Software defined Radio.

I have a very different problem from most of the other postings. I am
actually looking for a ‘problem’.

For the past one month I have been Googling to see the research
problems/constraints of USRP’s. There were many different implementation
ideas (of software defined radio’s)on the web. But, most of these ideas
are
in general (.i.e. different ways to implement software defined radio)
and
not related to implementation on USRP. I was looking for research topics
related to USRP. --> But, I didn’t find a specific answer as to how
FPGA’s
power could be harnessed to make USRP a more powerful tool. <–

I request you members to give your inputs as to what you would want to
do
with the existing Altera’s Cyclone FPGA on USRP, to make USRP a more
powerful tool!

I am extremely sorry if you think that this email is in an inappropriate
place. I believe that I can get much solid & better idea’s from what
people
would want out of their USRP’s by posting to this forum.

Thank you !

S.S. Mande

2

On 6/14/07, S Mande [email protected] wrote:

For the past one month I have been Googling to see the research
problems/constraints of USRP’s. There were many different implementation
ideas (of software defined radio’s)on the web. But, most of these ideas are
in general (.i.e. different ways to implement software defined radio) and
not related to implementation on USRP. I was looking for research topics
related to USRP. → But, I didn’t find a specific answer as to how FPGA’s
power could be harnessed to make USRP a more powerful tool. ←

I request you members to give your inputs as to what you would want to do
with the existing Altera’s Cyclone FPGA on USRP, to make USRP a more
powerful tool!

For all open tickets for the USRP you can check this page:
http://www.gnuradio.org/trac/query?status=new&status=assigned&status=reopened&component=usrp&order=priority

The inband signaling is already being worked on by Thibaud within the
FPGA. You can check the inband_lib directory under the usrp/fpga
directory for what he already has working.

There have been a lot of people who want easier access to the digital
IO pins on the daughtercards.

I think Automatic Gain Control within the hardware would probably be a
very good way to figure things out, but I am not sure how daughtercard
dependent that might be. Matt would have a better idea of the
specifics of how that might want to get done in a generic way.

There have also been a number of people who would like to perform FFTs
within the FPGA instead of bringing the sample stream. Being able to
mux functionality might be fun, but there probably isn’t enough
resources for all of that within the original USRP board.

Moreover, you could always grep for TODO within the Verilog source to
see what features might have to be revisited for optimization. I
believe the CIC filters are not optimized and can possibly release
maybe 10% of resources if they are optimized.

Obviously other people should chime in as well! Those are just the
things I can think of off the top of my head.

Brian

3

Hi,

I’ve been subscribing to the GNU Radio mailing list for a couple of
months now, but I have been having trouble keeping up with all the
discussions.

I have been using FPGAs since the mid 1990’s when I worked at the CSIRO
here in Australia working on Machine Vision. Over the past 5 years, I
suppose, I have been working on FPGA designs more as a hobby than
anything else, starting off with the BurchED B3 and B5-X300 Spartan 2
boards. I’ve been largely locked into Xilinx rather than Altera, due to
history more than anything else. That’s what we used at CSIRO and the
development boards for Xilinx were more readily available here for hobby
use.

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.

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.

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

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.

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 USRP uses USB as the interface. Has any though been given to
connecting the boards over ethernet so multiple boards can communicate
between themselves ?

John.

–
http://www.johnkent.com.au
http://members.optushome.com.au/jekent

4

On 6/15/07, John K. [email protected] 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 R. 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!

5

Hi Brian,

Thanks for your reply.

Brian P. wrote:

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.

OK … I did see some C++ files in the repository.
It sounds a bit like the wish interface on Tcl/Tk.

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.

Yes … I guess that would make more sense.

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.

Are they using a NIOS processor for the USB interface by any chance ?

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

Ok … Thanks … I’ll take a look at that …
You could certainly do some more DSP stuff with a few multipliers if the
Altera
device does not have them.

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.

The Spartan 3 uses 16Kbit RAMs. It sounds like the Altera device more
closely
resembles the Spartan 2.
I have not played with the SRL16 blocks, but it sounds like I should
read up on them.

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

You’d have to be a little careful about not using SRL16, multipliers and
so on
to make the design compatible.

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!

Sounds very Groovy !

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.

I’m not too sure if the interleaving and FEC need to be done on the PC
or in the FPGA. I’ve got no real preference on that, although I would
have
thought it would off load some of the work by putting it into the FPGA.

All the FPGA code I have written so far has been in VHDL rather than
Verilog.
I’m not sure there is really a big difference.

I have an ATV kit for the 1296 MHz band. It uses FM modulation rather
than AM.
The 1296 MHz PA I bought was a linear Mitsubishi module.
I guess I would be looking to use a commercial Digital TV receiver to
decode the
video, so it would have to be compatible with that.

We had a talk at the North East Radio Group a couple of years ago on
digital TV
and the guy there talked about encoding the video stream on 1024
separate
carriers. It might have been for a repeater system transmitting on the
same
frequency though. I’m a bit hazy on the details.

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.

To be honest … I have to read up on interleaving. As I said … I was
not
really up on the framing of the video signal for Broadcast transmission.
I’d also have to read up on equalizer design. I remember studying
equalizers for digital transmission back in my under graduate course
25 years ago, but I must admit I’m a bit rusty on how to adapt the
delay co-efficients.

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 remember doing a 4 x 4 QAM encoder for a design project in my
undergraduate engineering course too. It was not particularly hard.
Actually as I recall it handled a variety of constellations. Some of the
data bits were used for differential phase shift and some for amplitude

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.

Yes … the information was very useful. It gave me a few things to
follow up on.

Brian

PS - Sorry for such a long and lengthy post!

Yes … I was thinking my original post was a bit long :slight_smile:
Oh well … that is what these list are for !

Thanks for your reply … It’s much appreciated.
Maybe I’ll get back to you after I have read up a few Xilinx app notes
on the topic.

John.

–
http://www.johnkent.com.au
http://members.optushome.com.au/jekent

6

On 6/16/07, John K. [email protected] wrote:

Are they using a NIOS processor for the USB interface by any chance ?

No, a Cypress FX2 is used for the USB MAC/PHY. I believe the next
design is going to have an opencores processor within it.

It sounds like the Altera device more closely resembles the Spartan 2.
I have not played with the SRL16 blocks, but it sounds like I should
read up on them.

SRL16 information can be seen here:
http://toolbox.xilinx.com/docsan/xilinx5/data/docs/lib/lib0393_377.html

For a signal processing prospective, Xilinx has an app note about
writing a CDMA matched filter here:
http://www.xilinx.com/bvdocs/appnotes/xapp212.pdf

All the FPGA code I have written so far has been in VHDL rather than
Verilog. I’m not sure there is really a big difference.

VHDL is based on ADA and is strongly typed. VHDL also has more
support for configurations, generate loops, etc.

Verilog is a bit more loose and not as high level. I, too, do most of
my work in VHDL but have some experience within Verilog.

We had a talk at the North East Radio Group a couple of years ago on
digital TV and the guy there talked about encoding the video stream on
1024 separate carriers. It might have been for a repeater system transmitting
on the same frequency though. I’m a bit hazy on the details.

The digital video standard in the United States uses 8-VSB for the
modulation scheme, whereas the rest of the world seems to have settled
on using an OFDM solution.

What you are describing there sounds very much like an OFDM
implementation. There is currently an effort underway for getting
OFDM working on the USRP.

Brian