Debug IO pins

GNU Radio
1

Hi,
I generated a signal using the usrp_siggen.py function and tried to use
the
IO_pins on the basic TX board to monitor the digital output on a logic
analyzer but it seems that no signal goes to those pins.
Is there somehting I need to change in the verilog code to be able to
use
the debug IO pins?
Any suggestions on how to observe the output on a logic analyzer?

Thank you,

Oussama.

2

On Sat, Aug 19, 2006 at 11:14:33PM -0700, Oussama S. wrote:

Hi,
I generated a signal using the usrp_siggen.py function and tried to use the
IO_pins on the basic TX board to monitor the digital output on a logic
analyzer but it seems that no signal goes to those pins.
Is there somehting I need to change in the verilog code to be able to use
the debug IO pins?
Any suggestions on how to observe the output on a logic analyzer?

Thank you,
Oussama.

Hi Oussama,

There are two ways to control the i/o pins. Either from the host, or
from within the FPGA.

To control them from the host no changes are required in the verilog.

From python you need to tell it to “output enable” the pins you are
interested, and then write whatever values you like to them:

From gr-usrp/src/usrp1.i:

/*!

  • \brief Write direction register (output enables) for pins that go
    to daughterboard.
  • \param which_dboard [0,1] which d’board
  • \param value value to write into register
  • \param mask which bits of value to write into reg
  • Each d’board has 16-bits of general purpose i/o.
  • Setting the bit makes it an output from the FPGA to the d’board.
  • This register is initialized based on a value stored in the
  • d’board EEPROM. In general, you shouldn’t be using this routine
  • without a very good reason. Using this method incorrectly will
  • kill your USRP motherboard and/or daughterboard.
    */
    bool _write_oe (int which_dboard, int value, int mask);

/*!

  • \brief Write daughterboard i/o pin value
  • \param which_dboard [0,1] which d’board
  • \param value value to write into register
  • \param mask which bits of value to write into reg
    */
    bool write_io (int which_dboard, int value, int mask);

/*!

  • \brief Read daughterboard i/o pin value
  • \param which_dboard [0,1] which d’board
  • \returns register value if successful, else READ_FAILED
    */
    int read_io (int which_dboard);

E.g.,

Assumes Basic_Tx in slot A.

Do not do this blindly! Output enabing all the i/o pins

on other daughterboards will cause problems (burn up daughterboard

and/or FPGA)

u = usrp.sink_c(0, 64)

side = 0 # side A
u._write_oe(side, 0xffff, 0xffff) # set all i/o pins as outputs
counter = 0
while 1:
u.write_io(side, counter, 0xffff)
counter = (counter + 1) & 0xffff

If however, you’re trying to control the debug pins from the FPGA
you’ll need to output enable them from the host, and enable them as
debug outputs. You do the last step by writing to the FR_DEBUG_ENABLE
FPGA register:

From usrp/firmware/include/fpga_regs_common.h:

// If the corresponding bit is set, internal FPGA debug circuitry
// controls the i/o pins for the associated bank of daughterboard
// i/o pins. Typically used for debugging FPGA designs.

#define FR_DEBUG_EN 14

define bmFR_DEBUG_EN_TX_A (1 << 0) // debug controls

TX_A i/o

define bmFR_DEBUG_EN_RX_A (1 << 1) // debug controls

RX_A i/o

define bmFR_DEBUG_EN_TX_B (1 << 2) // debug controls

TX_B i/o

define bmFR_DEBUG_EN_RX_B (1 << 3) // debug controls

RX_B i/o

These defines are available in python like this:

from usrp_fpga_regs import *

u = usrp.sink_c(0, 64)
u._write_oe(0, 0xffff, 0xffff)
u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_TX_A)

Eric

3

Thank you very much Eric.

I tried it both ways and it works.
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?
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)
Out of curiosity, was the Quartus II used to compile the Verilog code
running under Linux or Windows?
If I am not mistaken, the Linux version is not free.

Thank you once again for all the help and guidance.

Oussama.

4

Eric,

thank you so much. It works nicely now.
I did what as you suggested: compiled the verilog code on my windows
machine
and transferred it over to my Ubuntu machine. I then made sure to change
the
fpga filename as you showed me.
I can now use the debug pins to monitor the signals I want.

Thank you once again for your help.

Cheers,

Oussama.

5

On Mon, Aug 21, 2006 at 12:32:11AM -0700, Oussama S. wrote:

Thank you very much Eric.

I tried it both ways and it works.

Glad to hear it :wink:

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.

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":slight_smile:

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

6

On Mon, Aug 21, 2006 at 07:53:06PM -0700, Oussama S. wrote:

Eric,

thank you so much. It works nicely now.
I did what as you suggested: compiled the verilog code on my windows machine
and transferred it over to my Ubuntu machine. I then made sure to change the
fpga filename as you showed me.
I can now use the debug pins to monitor the signals I want.

Thank you once again for your help.

You’re welcome. Glad to hear that it worked for you.

Eric