Question on accessing ADC I/Q outputs on RFX2400 debug heade

GNU Radio
1

Hello,

I would like access to the I and Q output data (12 bits each) from ADC
U601
using the debug headers from two RFX2400 daughterboards and was
wondering if
someone could assist my understanding and tell me if what I am doing is
right or wrong prior to my actually implementing this on the USRP.
Specific
questions are labelled with a “Q” in what follows.

Based on a couple of mailing list discussions I was able to figure out
the
following. Output enable all the general purpose i/o pins referred to
below:

  • 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);

u = usrp.sink_c(0, 64)
side0 = 0 # side A
u._write_oe(side0, 0xffff, 0xffff) # set all i/o pins as outputs
side1=1 # side B
u._write_oe(side1, 0xffff, 0xffff) # set all i/o pins as outputs
Next output enable the debug pins and enable them as debug outputs.
u._write_fpga_reg(FR_DEBUG_EN, ??) <-- Q. I am not sure how to safely
output enable the debug outputs. Would 0xf do the job?

Q. I am also not sure how to assign the 12 I bits and the 12 Q bits
from U601 across
the daughterboard headers. Would the following in usrp_std.v
(master_control) do the trick?
.debug_0(rx_a_a[11:4]),.debug_1(rx_a_a[3:0]),
.debug_2(rx_b_a[11:4]),.debug_3(rx_b_a[3:0]),
);

Q. I was a little confused about the “RX Nets” beside J24 and “TX
Nets” beside J101 in the
2400 receiver and transmitter schematics, respectively. Can someone
please explain?

Thanks very much in advance!

-Nikhil

2

On Mon, Apr 23, 2007 at 11:17:59PM -0400, Nikhil wrote:

u = usrp.sink_c(0, 64)
side0 = 0 # side A
u._write_oe(side0, 0xffff, 0xffff) # set all i/o pins as outputs
side1=1 # side B
u._write_oe(side1, 0xffff, 0xffff) # set all i/o pins as outputs

Oops! You’ve now smoked two RFX-2400 boards and/or the FPGA :wink:

The daughterboard and the FPGA are both driving at least pin 2.

Though the pins are called “general purpose i/o”, that doesn’t mean
the user should mess with all of them. Some of them are used by the
daugtherboard code to control or read status from parts on the
daughterboards. Which pins are safe for the user to mess with depends
on the design of the given daughterboard. Hence our scary warning on
_write_oe.

Step one: Look at the schematics for the RFX-2400 board and figure
out which of the 16 i/o pins are actually used by the Tx and Rx halves
of the transceiver daughterboard, and which ones are available for
your use. See which of the i/o pins actually makes it to the header
on the board.

Step two: Look again and check your work.

Step three: Look at the daughterboard code (db_flexrf.py). See what
it’s doing to the various output enables and i/o pins. Does this
match your understanding of which pins are available for your use?

Step four: Confirm again which pins are safe for you to be messing with.

(I believe that the high 7-bits are available for your use. It might
be 8, but I haven’t looked at the schematics in a long time. I’m not
kidding when I say you should check the schematics.)

Now figure out new values for the calls to u._write_oe(…), that only
change the OE values of the pins that make it to the header and aren’t
used for some other purpose by the code that’s controlling the
daughterboard.

Next output enable the debug pins and enable them as debug outputs.
u._write_fpga_reg(FR_DEBUG_EN, ??) <-- Q. I am not sure how to safely
output enable the debug outputs. Would 0xf do the job?

All the output enables are controlled using _write_oe.

FR_DEBUG_EN determines whether the debug pins are routed to the i/o
pins or whether the normal write_io and auto T/R values
make it to the header. See the bottom of master_control.v for the
details.

Given what you’ll find out after you look at the schematics, no value
of FR_DEBUG_EN except for 0 is safe when you’re using two RFX-2400
boards.

2400 receiver and transmitter schematics, respectively. Can someone
please explain?

Thanks very much in advance!

-Nikhil

If you can get by with a single RFX-2400, my suggestion is that you
put it on the A-side, and then put a Basic Tx and a Basic Rx on the
B-side. Then you’ve got a total of 32 uncommitted i/o pins on the
B-side.

The FR_DEBUG_EN register wasn’t designed to solve every possible
problem. It solved the one we had, which was getting debug info out
to a Basic Rx and/or Basic Tx :wink:

Eric

3

Oops! You’ve now smoked two RFX-2400 boards and/or the FPGA :wink:

Bzzzt! Ok thanks. Your explanation helped clear up my confusion
about
the RX and TX nets in the schematic and prevented frying my boards as
well.
:wink:

(I believe that the high 7-bits are available for your use. It mightbe
8, but I haven’t looked at the >schematics in a long time. I’m
notkidding
when I say you should check the schematics.)
Yes it is only the 7 msbs.

If you can get by with a single RFX-2400, my suggestion is that you
put it on the A-side, and then put a Basic Tx and a Basic Rx on the
B-side. Then you’ve got a total of 32 uncommitted i/o pins on the
B-side.

This is a good idea. So if I insert one of each Basic Tx and Rx on side
B,
with the RFX2400 on side A, then the following should work (?)

u = usrp.source_c(0, 64)
u._write_oe(1, 0xffff, 0xffff)
u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_B |
bmFR_DEBUG_EN_TX_B)

and then in usrp_std.v
master_control master_control
(…
//.debug_0(rx_a_a),.debug_1(ddc0_in_i),
.debug_0(rx_debugbus),.debug_1(ddc0_in_i),
.debug_2(rx_a_a),.debug_3(rx_b_a), … );

Thanks again!
Nikhil

4

On Tue, Apr 24, 2007 at 10:02:47AM -0400, Nikhil wrote:

Yes it is only the 7 msbs.
with the RFX2400 on side A, then the following should work (?)
.debug_2(rx_a_a),.debug_3(rx_b_a), … );
Yes. You may want to consider running a clock up there too,
since otherwise it’s going to hard to figure out when you’ve got good
data. You’ve got enough pins, since the data’s only 12-bits wide.

Eric