Digital noise input

Hi,

I’m trying to use my logic analyzer to measure the received noise.
Here is how I proceed to do that. First in the verilog code, I connect
the
12 bit rx_a_a ADC input to the io_rx_a DEBUG output by adding this line
of
code:
assign io_rx_a = {4’b0000, rx_a_a }

I also make sure that the outputs of the io_pins.v module are not
connected
to anything. (especially the io_rx_a output) That way, only rx_a_a
should be
connected to the io_rx_a output.

I then load the .rbf file to the FPGA, connect the io_rx_a outputs of
the
LFRX daughter board to the logic analyzer and observe what I get. I make
sure that no antenna is connected to the RX-A port.
To my surprise, some of the upper bits toggle. For example, bit 11, 10,
9,
8, 5 ,4 , 3 ,2 ,1 0, toggle. Since I should only be getting noise, I was
expecting to get a very low signal where only the least significant bit
would be switiching between low and high values.

Does anyone know what could be the origin of such results? Any insight
would
be greatly appreciated.

Thank you,

Oussama.

On Fri, Nov 10, 2006 at 06:01:02PM -0800, Oussama S. wrote:

Hi,

I’m trying to use my logic analyzer to measure the received noise.
Here is how I proceed to do that. First in the verilog code, I connect the
12 bit rx_a_a ADC input to the io_rx_a DEBUG output by adding this line of
code:
assign io_rx_a = {4’b0000, rx_a_a }

A much less invasive way to handle this would have been to take
advantage of the support for sending whatever debug values you want to
the i/o pins by using the debug_0,…, debug_3 parameters of the
master_control block. See also the FR_DEBUG_EN register documented
in fpga_regs_common.{h,v}

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

I then load the .rbf file to the FPGA, connect the io_rx_a outputs of the
LFRX daughter board to the logic analyzer and observe what I get. I make
sure that no antenna is connected to the RX-A port.
To my surprise, some of the upper bits toggle. For example, bit 11, 10, 9,
8, 5 ,4 , 3 ,2 ,1 0, toggle. Since I should only be getting noise, I was
expecting to get a very low signal where only the least significant bit
would be switiching between low and high values.

Are they being driven or are they just floating?

My guess is that they are floating.

My suggestion (once again) is to use some of debug_0,… debug_3,
write to FR_DEBUG_EN and then enable the outputs of the particular
pins using u._write_oe(which, value, mask)

Does anyone know what could be the origin of such results? Any insight would
be greatly appreciated.

Thank you,

Oussama.

Eric

On 11/10/06, Eric B. [email protected] wrote:

assign io_rx_a = {4’b0000, rx_a_a }

#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

Yes, I could enable the output pins from the host and just connect the
rx_a_a to one of the debug inputs in the master_control module. I
thaught it
wouldn’t make a difference if I just connect it directly to the DEBUG
pins.
Or does it?

I then load the .rbf file to the FPGA, connect the io_rx_a outputs of the

LFRX daughter board to the logic analyzer and observe what I get. I make
sure that no antenna is connected to the RX-A port.
To my surprise, some of the upper bits toggle. For example, bit 11, 10,
9,
8, 5 ,4 , 3 ,2 ,1 0, toggle. Since I should only be getting noise, I was
expecting to get a very low signal where only the least significant bit
would be switiching between low and high values.

Are they being driven or are they just floating?

No antenna is connected to the RX-A and RX-B ports , so those are
floating.
But the debug pins are connected to the logic analyzer. (I am not sure
if I
answered you’re question, when you say “they” are you referring to the
DEBUG
pins or the input ports? )

My guess is that they are floating.

My suggestion (once again) is to use some of debug_0,… debug_3,
write to FR_DEBUG_EN and then enable the outputs of the particular
pins using u._write_oe(which, value, mask)

Ok. Thanks for the suggestion. I will try that and see what I get.

Oussama.

On Fri, Nov 10, 2006 at 07:23:07PM -0800, Oussama S. wrote:

On 11/10/06, Eric B. [email protected] wrote:

Yes, I could enable the output pins from the host and just connect the
rx_a_a to one of the debug inputs in the master_control module. I thaught it
wouldn’t make a difference if I just connect it directly to the DEBUG pins.
Or does it?

It depends on whether or not you need to be able to control the
attached daughterboard too.

No antenna is connected to the RX-A and RX-B ports , so those are floating.

But the debug pins are connected to the logic analyzer. (I am not sure if I
answered you’re question, when you say “they” are you referring to the DEBUG
pins or the input ports? )

No, not the antenna, the i/o pins. My guess is that you haven’t
output enabled them.

Eric

Hi,

I am still trying to measure the digital output noise (from the LFRX_A
daughterboard).
In the verilog code I made sure to connect the rx_a_a input to the
debug1
input of the master control module
master_control master_control
( .master_clk(clk64),.usbclk(usbclk) …
… .debug_1(rx_a_a),.debug_0(ddc0_in_i)…);

then my python code looks like the following:

u = usrp.sink_c(0, 64, fpga_filename=“usrp_test.rbf”)
side = 0 # side A
u._write_oe(side, 0xffff, 0xffff) # set all i/o pins as outputs
u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_A)

I then connect the io_rx debug outputs of side A to the logic analyzer.
(no
antenna is inserted)
I was expecting to get some noise , but I get a 0 signal ( 16 bit zeroes
:frowning:
)

Any ideas on why this is happening? Any suggestions?

Thank you ahead of time.

Oussama

On 11/17/06, Eric B. [email protected] wrote:

( .master_clk(clk64),.usbclk(usbclk) .......

(no

You have opened the Tx side (the sink), and output enabled the pins on
the side A Tx daughterboard. Then you’ve connected your logic
analyzer to the side A Rx daughterboard. Those pins are not output
enabled.

Ok.
I fixed it now by making it a source instead. Thanks.
My output reading from the logic analyzer is now the following constant
16
bit value: 0000 1111 1100 0011
This seems to me a too high of a value since I shouldn’t be receiving
any
signal. On top of that, none of the bits are toggling, which doesn’t
make
sense if it was just noise.
Any ideas on what’s going on here?

Thanks again,

Oussama.

Eric

On Fri, Nov 17, 2006 at 07:13:05PM -0800, Oussama S. wrote:

then my python code looks like the following:

Any ideas on why this is happening? Any suggestions?

Thank you ahead of time.

Oussama

You have opened the Tx side (the sink), and output enabled the pins on
the side A Tx daughterboard. Then you’ve connected your logic
analyzer to the side A Rx daughterboard. Those pins are not output
enabled.

Eric

On 11/17/06, Oussama S. [email protected] wrote:

Ok.
I fixed it now by making it a source instead. Thanks.
My output reading from the logic analyzer is now the following constant 16
bit value: 0000 1111 1100 0011
This seems to me a too high of a value since I shouldn’t be receiving any
signal. On top of that, none of the bits are toggling, which doesn’t make
sense if it was just noise.
Any ideas on what’s going on here?

Would it be worth while to try to see if you can use Altera’s Signal
Tap software (internal FPGA logic analyzer) to help out? I don’t know
the M4k usage in the part with the design, but there should be enough
to help a little debug - right? Does the FPGA have a convenient JTAG
connection to it?

Thanks again,

Oussama.

Brian

On 11/17/06, Brian P. [email protected] wrote:

signal. On top of that, none of the bits are toggling, which doesn’t
make
sense if it was just noise.
Any ideas on what’s going on here?

Would it be worth while to try to see if you can use Altera’s Signal
Tap software (internal FPGA logic analyzer) to help out? I don’t know
the M4k usage in the part with the design, but there should be enough
to help a little debug - right? Does the FPGA have a convenient JTAG
connection to it?

I don’t think the FPGA has a JTAG connection to it.
I did the same tests agains, but I used a Basic RX daugterboard instead
of
the previous LFRX. Now I get the following output: all bits are 0
except
bit 5 and bit 1 toggles.
This output seems to make a little more sense to me.
Does it look like a reasonable output ?

Thank you for your time.

On Fri, Nov 17, 2006 at 07:13:05PM -0800, Oussama S. wrote:

I am still trying to measure the digital output noise (from the LFRX_A
daughterboard).
[and later:]
I fixed it now by making it a source instead. Thanks.
My output reading from the logic analyzer is now the following constant 16
bit value:
0000 1111 1100 0011
This seems to me a too high of a value since I shouldn’t be receiving any
signal. On top of > that, none of the bits are toggling, which doesn’t
make sense if it was just noise.
Any ideas on what’s going on here?

How is the input to your LFRX connected? The response goes down to DC
and
will only be (near) zero with a 50-ohm (at DC) source resistance. Does
your
output reading depend on the PGA setting?

– Don W.

I actually get a very strange behavior now.
Every time I rerun my program , the output of the logic analyzer
changes.
But the output that comes up the most often is the one I described
before
where bit 1 toggles, and bit 5 is asserted (sometimes) .

What I am trying to do is to get some delay measurements in the
following
way: if 12 bit input (say rx_a) is larger than a certain threshold, than
I
assert a signal in a register. So for this reason I am trying to see
what’s
the digital “value” of the noise input in order to have an idea on how
to
set the threshold.
Has anyone done any such thresholding measurements? Is there a good or
‘basic’ threshold that I could use for my measurements?

Any suggestion would be greatly appreciated.

Thank you,

Oussama.

On Fri, Nov 17, 2006 at 10:23:01PM -0800, Oussama S. wrote:

Has anyone done any such thresholding measurements? Is there a good or
‘basic’ threshold that I could use for my measurements?

Any suggestion would be greatly appreciated.

Thank you,
Oussama.

OK folks,

It’s hard to do remote diagnosis, but here are some observations:

Matt and I have successfully used this strategy to debug code running
in the FPGA. It work as expected.

Using the standard fpga build, this stuff is wired to the pins if
debug is enabled:

.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})

rx_debugbus is connected like this:

// Debugging Aids
assign debugbus[0] = RD;
assign debugbus[1] = rx_overrun;
assign debugbus[2] = read_count[8];
assign debugbus[3] = rx_full;
assign debugbus[4] = rxstrobe;
assign debugbus[5] = usbclk;
assign debugbus[6] = have_pkt_rdy;
assign debugbus[10:7] = store_next;
//assign debugbus[15:11] = rxfifolevel[4:0];
assign debugbus[15:11] = bitwidth;

debug_0 comes out on TX_A
debug_1 comes out on RX_A
debug_2 comes out on TX_B
debug_3 comes out on RX_B

Note that the USB clock is on bit 5 of debug_0 (== TX_A)
It will be running at 48 MHz. If you output enable and FR_DEBUG_EN
you will see this! See more below

You have to:

  • output enable the pins
  • write a suitable value to FR_DEBUG_EN register
    u._write_fpga_reg(FR_DEBUG_EN, 0xf) will enable all debug outputs
    This is only safe if you are using basic or LF tx/rx d’boards.

Are you sure that you know how to drive your logic analyzer?
Have you tried probing the pins with an oscilloscope?
Do you have a proper ground hooked up to your LA and/or oscope?

I have just confirmed this info as follows:

USRP with only a BASIC_TX on side A

From the command line I typed this:

[[email protected] ~]$ python
Python 2.4.2 (#1, Oct 13 2006, 17:10:51)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.

from gnuradio import usrp
from usrp_fpga_regs import *
u=usrp.sink_c(0,64)
u._write_oe(0,0xffff, 0xffff)
True

u._write_fpga_reg(FR_DEBUG_EN, 0x1)
True

Then I fired up my trust o’scope and probed the pin labeled io_tx(5) on
J50 on the Basic Tx. To get this I used a very short ground
connection (about 1/4 inch) from my scope probe to one of the pins
labeled DGND on J50

The o’scope screen shot is attached, and here’s a link to the probing
technique http://comsec.com/images/probe-technique.jpg

Eric

On Fri, Nov 17, 2006 at 07:13:05PM -0800, Oussama S. wrote:

Hi,

I am still trying to measure the digital output noise (from the LFRX_A
daughterboard).

Another random thought:

Since you are using the LFRX and it’s DC coupled you must turn off
the ADC DC offset removal control loop in the FPGA.

/*!

  • \brief Enable/disable automatic DC offset removal control loop in
    FPGA
  • \param bits which control loops to enable
  • \param mask which \p bits to pay attention to
  • If the corresponding bit is set, enable the automatic DC
  • offset correction control loop.
  • 
    
  • The 4 low bits are significant:
  • ADC0 = (1 << 0)
  • ADC1 = (1 << 1)
  • ADC2 = (1 << 2)
  • ADC3 = (1 << 3)
  • By default the control loop is enabled on all ADC’s.
    */
    bool set_dc_offset_cl_enable(int bits, int mask);

In python:

u.set_dc_offset_cl_enable(0x0, 0x3)

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs