[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Debug IO pins
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Debug IO pins |
Date: |
Mon, 21 Aug 2006 12:05:20 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, Aug 21, 2006 at 12:32:11AM -0700, Oussama Sekkat wrote:
> Thank you very much Eric.
>
> I tried it both ways and it works.
Glad to hear it ;)
> For the second way, I enabled the debug outputs as you showed me. When I
> connect the pins to my logic analyzer, it seems that the 16 bit output is
> always the same : the only bits asserted were bit 1,2,,4,8. I suppose this
> is some kind of default value.
> Now that the debug output pins are enabled, what I would like to do for
> example is to generate a signal using say usrp_siggen.py and look at the
> digital signal using those pins. I assume that in order to do that I need to
> change the verilog code and make sure that my FPGA output is sent to the
> right 'debug' register. I need therefore to recompile the code and reprogram
> the board. All my gnu radio packages are installed on a computer running
> ubuntu but I am running Altera Quartus II on a windows machine. I tried to
> program the usrp through the usb cable but my PC does not recognize the
> usrp.
> Is it possible for me to reprogram the USRP using windows and then run
> python applications on it from a Linux machine? If it is, any suggestions on
> how I could program the board from windows?
Just copy the resulting .rbf to your ubuntu machine.
The USRP has virtually no non-volatile storage. It's "programmed"
everytime you run an application. By default it loads the FPGA
bitstream from /usr/local/share/usrp/rev{2,4}/*.rbf. You can specify
the bitstream to load as an additional keyword constructor argument
when opening the usrp.
u = usrp.sink_c(0, 64, fpga_filename="/path/to/my/foo.rbf":)
I suggest you spend a bit of time browsing gr-usrp/src/usrp.py...
> Also, I would appreciate any suggestions on how to connect outputs from the
> FPGA to the debug pins (such as the io_tx_a output)
Look at usrp/fpga/toplevel/usrp_std/usrp_std.v:
wire [15:0] reg_0,reg_1,reg_2,reg_3;
master_control master_control
( .master_clk(clk64),.usbclk(usbclk),
.serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
.tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
.tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
.enable_tx(enable_tx),.enable_rx(enable_rx),
.interp_rate(interp_rate),.decim_rate(decim_rate),
.tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
.rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
.tx_empty(tx_empty),
//.debug_0(rx_a_a),.debug_1(ddc0_in_i),
.debug_0(rx_debugbus),.debug_1(ddc0_in_i),
.debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),.debug_3({rx_dsp_reset,tx_dsp_reset,rx_bus_reset,tx_bus_reset,enable_rx,tx_underrun,rx_overrun,decim_rate}),
.reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3) );
The arguments .debug_0(...) through .debug_3(...) are the signals
that get connected to the debug pins.
debug_0 -> TX_A
debug_1 -> RX_A
debug_2 -> TX_B
debug_3 -> RX_B
> Out of curiosity, was the Quartus II used to compile the Verilog code
> running under Linux or Windows?
The windows one.
> If I am not mistaken, the Linux version is not free.
Correct.
> Thank you once again for all the help and guidance.
You're welcome. Good luck!
Eric