Help needed with FPGA

GNU Radio
1

Hi,

I am trying to add some functionalities to the existing FPGA in USRP.

I went through the mailing list and figured out that the current
Verilog/VHDL code implementation occupies 90% of FPGA’s resources.
However,
there were some mails that pointed that reducing some reveiver
functionalities could free some FPGA resources.

Any help as to how I can proceed with this i.e. reducing receiver
functionality and freeing up FPGA resources? Also if I should try
implementing some easy additonal functionalities in the FPGA,(so as to
not
damage the USRP board) then which one should I go ahead with?

Are there any C++ blocks that I can try implementing in VHDL/Verilog
code in
FPGA and improve performance?

I would be grateful if some of you could help me / point in the right
directions with the above questions.

Thanking you,

S Mande.

2

Hi,

Thank you Lee for your response.

I am not sure about the current status of OFDM implementation. I figured
out
from the mailing list that it is still in testing phase.

Would it be a good idea to port some of the OFDM implementation onto the
FPGA.?

I am just starting off with USRP and would greatly appreciate your help.
Please do excuse me if my question sounds too trivial.

S Mande.

3

There’s a header file:
GNU_Radio\usrp\fpga\toplevel\usrp_std\config.vh

That header controls the build configuration and is now functional.
Modify it to use the file:
GNU_Radio\usrp\fpga\toplevel\include\common_config_1rxhb_1tx.vh

This is how:
// Uncomment this for 1 rx channel (w/ halfband) & 1 transmit channel
`include “…/include/common_config_1rxhb_1tx.vh”

This will free up alot of space on the fpga for experimentation!

Lee Studley
Embedded SW/HW Eng.
Kutta Consulting, Inc.

At 03:02 PM 9/5/2007, S Mande wrote:

functionality and freeing up FPGA resources? Also if I should try

S Mande.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Lee Studley
Embedded SW/HW Eng.
Kutta Consulting, Inc.

[email protected]
Office: (602) 896-1976 x236
Cell: (602) 743-4515

4

Thank you Brian and Mande.

mapper might also be interesting.

An interesting consequence of doing this is that your TX bandwidth
goes significantly down since you don’t have to pump 16-bit I/Q values
over the bus, just your raw data rate. This allows for a USRP setup
to both TX and RX to have more USB bandwidth dedicated to the real
processing (RX) and not just some LUTS (TX).

Brian

I have been tracking this topic for sometime now. I am working on a
similar
problem.

Would it be a better idea to use a Reed Solomon encoder (
http://www.opencores.org/projects.cgi/web/rsencoder/overview) and
Reed Solomon decoder (
http://www.opencores.org/projects.cgi/web/rs_decoder_31_19_6/overview )
from
OpenCores.com
to start with? It might be interesting to make it work with the USRP.

Both the encoder and the decoder are written in Verilog and are in
Production/Stable stage.

I have just started to work with USRP and any help on the above topic
would
be helpful to me.

Thanks.

Dhaval.

5

Something you may want to try to do is focus on the TX side of things.

RX is generally the harder part of radio communications, and probably
wouldn’t work out too well inside of an FPGA that is already pretty
full. TX on the other hand is all just simple permutations, look up
tables, and maybe some filtering to stay within band.

You can probably write a decent M-QAM mapper, convolutional encoder,
interleaver, etc and not have it take up too much room other than some
registers and block rams. If you wanted to get more complex, a GMSK
mapper might also be interesting.

An interesting consequence of doing this is that your TX bandwidth
goes significantly down since you don’t have to pump 16-bit I/Q values
over the bus, just your raw data rate. This allows for a USRP setup
to both TX and RX to have more USB bandwidth dedicated to the real
processing (RX) and not just some LUTS (TX).

Brian