Re: [Discuss-gnuradio] Debug IO pins

[Eric Blossom]

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