Reprogram FPGA

Hi,

I am looking at the possibility of reprogramming the existing firmware
inside FPGA.

I am using the Quartus software to compile the code. However, I am new
to
USRP and GNU Radio.

It would help me if anyone of you could reply to my questions:

  1. Do I need a 3rd party tool to transfer my code to the FPGA on USRP ?
    I
    remember using a JTAG cable and Active-HDL for this task when i worked
    with
    Aldec procesors.

  2. I believe that the firmware is loaded everytime I run GNU radio. Is
    it
    that I replace the existing fpga Verilog firmware code ( .v file ) from
    its
    existing location .i.e. gnuradio folder
    with my modified Verilog firmware code ?

Thank you for your help.

S. Mande.

S Mande wrote:

  1. Do I need a 3rd party tool to transfer my code to the FPGA on USRP ?
    I remember using a JTAG cable and Active-HDL for this task when i worked
    with Aldec procesors.

I’m sure there are multiple ways to do this, but I just use the existing
usrp framework to load the RBF file onto the fpga. That is, when I
generate a new RBF file, I throw it into
/usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf and load it up with my own
C application that links to libusrp.so. It’s the quick and dirty way,
but hey, it works.

  1. I believe that the firmware is loaded everytime I run GNU radio. Is
    it that I replace the existing fpga Verilog firmware code ( .v file
    ) from its existing location .i.e. gnuradio folder
    with my modified Verilog firmware code ?

The RBF file that is loaded is picked up from a predetermined location.
In my case, with a rev 4 usrp, it’s
/usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf. In your quartus project,
the file you want is in usrp/fpga/toplevel/usrp_std/usrp_std.rbf

If you replace the file in /usr/local… with a new rbf file, the
gnuradio code will load it next time you power cycle/run the USRP.

-Roshan

On Tue, Jul 24, 2007 at 04:19:58PM -0700, Roshan B. wrote:

but hey, it works.

If you replace the file in /usr/local… with a new rbf file, the
gnuradio code will load it next time you power cycle/run the USRP.

-Roshan

You can also specify the rbf file name in the usrp constructor:

u = usrp.sourc_c(…, fpga_filename=“myfile.rbf”)

Eric

NOTE: please start new threads with a fresh email, not by replying to
another thread.

Sabu wrote:

Observed that the 3 commands towards the end of the /UbuntuInstall /- viz
1 …/benchmark_usb.py
2 ./test_usrp_standard_tx
3 ./test_usrp_standard_rx

require a power-cycling (OFF-ON) after executing any one command.
Otherwise the second command returns an error
[/failed to find usrp(0/)] as shown in the relevant log-file below:

Querry A : How do I get ri**d of power-cycling, in order to accept
second command to USRP
?

You have encountered the GNU Radio 3.0.3 bug with Linux kernel 2.6.20.
There is already a fix available, but it hasn’t made into a new GNU
Radio release.

Please obtain the Subversion client software (install with Synaptic in
Ubuntu), then follow the directions for checking out and installing GNU
Radio at:

http://gnuradio.org/trac/wiki/BuildGuide

Be sure to use the latest release 3.0 branch code at:

http://gnuradio.org/svn/gnuradio/branches/releases/3.0

*Querry B :*How do I get usrp_fpga.rbf and usrp_firmware.ihx, if they
are needed?

That tutorial is outdated; the correct files are in place and are
getting loaded automatically.

It also says subsequently that, to listen to FM stations, we can connect
a speaker to the sound card and insert a piece of
wire to the RX-A connector and then run the example command:
*“sudo ./wfm_rcv_gui.py 101.5.” *
*Querry C: Where do I get *wfm_rcv_gui.py ? If it is no more valid,
what is the equivalent substitute
?

The file is in:

gnuradio-examples/python/usrp/

And you should invoke it with:

./usrp_wfm_rcv_gui.py -f 101.5M

(Use whatever local broadcast band FM station is in your area)


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Hello friends,

I(sabu) made debute to USRP & GNUradio build-trials 2 days back.
I have three querries… viz. A, B, & C, as mentioned after the
environment observations given below

My environment is :
O.S :: Ubuntu 7.04 Feisty fawn (Free CD distribution
alongwith “Linux For You” magazine in India)
CPU :: Core2 DUO Intel
gcc :: 4.2.0
SWIG :: 1.3.31
Build references used are ::
http://gnuradio.org/trac/wiki/UbuntuInstall
http://www.nd.edu/~jnl/sdr/docs/tutorials/

Observed that the 3 commands towards the end of the UbuntuInstall - viz
1 ./benchmark_usb.py
2 ./test_usrp_standard_tx
3 ./test_usrp_standard_rx

require a power-cycling (OFF-ON) after executing any one command.
Otherwise the second command returns an error
[failed to find usrp(0)] as shown in the relevant log-file below:
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/gnuradio-examples/python/usrp#
./benchmark_usb.py

Testing 2MB/sec… usb_throughput = 2M

OK
Testing 4MB/sec… usb_throughput = 4M

OK
Testing 8MB/sec… usb_throughput = 8M

OK
Testing 16MB/sec… usb_throughput = 16M

OK
Testing 32MB/sec… usb_throughput = 32M

OK
Max USB/USRP throughput = 32MB/sec

root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/gnuradio-examples/python/usrp#
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/usrp/host/apps#
…/test_usrp_standard_tx
usrp: failed to find usrp[0]
die: lt-test_usrp_standard_tx: usrp_standard_tx::make
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/usrp/host/apps#
…/test_usrp_standard_rx
usrp: failed to find usrp[0]
die: lt-test_usrp_standard_rx: usrp_standard_rx::make
####### Power off & power ON usrp ###############
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/usrp/host/apps#
…/test_usrp_standard_tx
xfered 1.34e+08 bytes in 4.02 seconds. 3.336e+07 bytes/sec. cpu time =
0.232
0 underruns
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/usrp/host/apps#
…/test_usrp_standard_rx
usrp: failed to find usrp[0]
die: lt-test_usrp_standard_rx: usrp_standard_rx::make
####### Power off & power ON usrp ###############
root@BCGA68:/home/sabu/GNUradio/gnuradio-3.0.3/usrp/host/apps#
…/test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.02 seconds. 3.336e+07 bytes/sec. cpu time =
0.184
noverruns = 0

I am able to view “USRP Rev 4” on ‘usbview’ tool-window, and the second
green LED is blinking every Second…!!
The other LED (2Hz ON-OFF at power on) remains off. Did anyone came
across a similar problem.?

Querry A : How do I get rid of power-cycling, in order to accept second
command to USRP?

Also observed in clause 2.4 of “Tutorial 4” at
http://www.nd.edu/~jnl/sdr/docs/tutorials/4.html that
“…When a USRP application starts, the USRP will load two
files from the directory
/usr/local/share/usrp/rev2: usrp_firmware.ihx and usrp_fpga.rbf. The
blinking LED
should slow down to 1Hz (once a second) after the usrp_firmware.ihx file
was loaded successfully…”

However, these files were not present at the said node. Instead 4 other
files were present in …/rev2 & …/rev4 nodes.
Querry B :How do I get usrp_fpga.rbf and usrp_firmware.ihx, if they are
needed?

It also says subsequently that, to listen to FM stations, we can connect
a speaker to the sound card and insert a piece of
wire to the RX-A connector and then run the example command: “sudo
…/wfm_rcv_gui.py 101.5.”
Querry C: Where do I get wfm_rcv_gui.py ? If it is no more valid, what
is the equivalent substitute?

Please extend your helping hand…(I am in a ditch.!)

best regards
K N Sabu
C-DAC Trivandrum - India.

----- Original Message -----
From: S Mande
To: [email protected]
Sent: Wednesday, July 25, 2007 4:34 AM
Subject: [Discuss-gnuradio] Reprogram FPGA

Hi,

I am looking at the possibility of reprogramming the existing firmware
inside FPGA.

Sabu,
On Querry A, I had the same problem. The bug has been fixed. See
Johnathan’s reply to me.
– Justin

Sabu wrote:

Querry A : How do I get ri**d of power-cycling, in order to accept
second command to USRP
?

Justin S. wrote:

It looks like you have found and fixed this problem. How can I get the

update?

Johnathan C. wrote:
The fix is already in the developer trunk which you can check out and
compile using subversion and the directions on the Wiki.

A patched version of 3.0.3 is also available from subversion at:

http://gnuradio.org/svn/gnuradio/tags/releases/3.0.3-usb-fix

When 3.0.4 is released, it will contain this fix in the source tarball