discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USB Issues


From: Michael Dickens
Subject: Re: [Discuss-gnuradio] USB Issues
Date: Tue, 17 Jan 2006 14:01:37 -0500

Eric - We do have a logic analyzer, but with the basic connectors. Thus we'd think about changing the FPGA code to route the usbctl[] signals to a daughtercard for viewing. I can tell that at least 2 of the files you're referring to are:

"usrp/fpga/toplevel/usrp_std/usrp_std.v"
"usrp/fpga/sdr_lib/master_control.v"

Unfortunately I'm not an FPGA programmer, and what you wrote (below) doesn't help me very much, even looking at those files and rereading a few times over. Is there maybe another way you could explain it which would be more enlightening? I'd rather believe that I'm at least 90% correct in my changes before messing around and possibly breaking something ("be careful!"). Thanks! - MLD

[snip] I strongly suggest
measuring the actual worst case inter-USB packet delay across the USB
while doing reads and writes. [snip]

This measurement is pretty easy to make on the USRP with a logic
analyzer.  The signals of interest are the GPIF control signals RD and
WR between the FX2 and FPGA.  These are asserted when a packet is
burst between the FX2 and the FPGA.

/*
 * FPGA input lines that are tied to the FX2 CTLx outputs.
 *
 * These are controlled by the GPIF microprogram...
 */
// WR                                   bmBIT0  // usbctl[0]
// RD                                   bmBIT1  // usbctl[1]
// OE                                   bmBIT2  // usbctl[2]

That is:

  WR is FX2 CTL0 (netname: GPIF_CTL0)
  RD is FX2 CTL1 (netname: GPFI_CTL1)

If you've got fancy probes on your analyzer, you may be able to pick
these off the FX2 directly.  If not, then the easiest thing to do is
to use a basic tx or rx daughterboard, and hack the verilog such that
the signals you are interested in are connected to a daughterboard i/o
pin (see below).  Then connect the LA to the daughterboard i/o pin
headers.  You'll also need to enable the outputs using
u._write_oe(...)  Be careful ;)

See usrp_std.v, look at the instantiation of the master_control module.
Find the signals named debug_{0,4} and change them as needed.  Note
that the rx_buffer.v and tx_buffer.v modules define debug busses that
contain the RD and WR signals. [The standard fpga build wires the
rx_debugbus to the TX_A i/o pins.  RD will be output on i/o pin 0.
You'll just need to set bit 0 in the FR_DEBUG_EN register (see below).]

The values of the debug_{0,4} signals are sent to the daughterboard
pins instead of the "normal values" if the appropriate bit is set in the
FR_DEBUG_EN FPGA register.

// 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]