Re: [Discuss-gnuradio] Daughter board pins

[Eric Blossom]

On Wed, Sep 27, 2006 at 04:28:08PM +0100, Andrew Borg wrote:
> Hi Eric. Thanks for your help. It all works exactly how you said. I was 
> enabling the correct pins using "usrp.source_c(0, 64)"   - the code I 
> pasted "usrp.sink_c(0, 64)" was a blind copy-paste from Oussama's email. 
> Sorry about the confusion.
> 
> All I was missing was the " u._write_oe(1, 0xffff, 0xffff) ". I put that it 
> and it all worked nicely.
> 
> I have another question. I'm outputting two pieces of information on my 2 
> BasicRX daughter boards - (1) 3 clocks and (2) the USB data. The Verilog 
> code looks as follows:
> 
>   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(usbdata_out),
>      .debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),
>      .debug_3(usbclk,clk64,clk128),
> // 
> .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) );
> 
> 
> Now I'm getting some signals on my oscilloscope that I'm not happy with.
> 
> 1) First of all, the clk64 signal looks like a sine - wave. The frequency 
> is 64MhZ according to my oscilloscope. I was expecting a square wave. Is 
> this correct?

You'll need good probing techniques to see a 64MHz clock and have it
not look like a sine wave.  You won't be able to do this with a scope
probe with a 2 inch ground lead.  For this kind of stuff I usually use
a small wire ground lead wrapped around the ground ring on the tip.
The traditional scope vendors make a special little spring loaded gadget
for this.  Ideally you want the tip of the probe and the ground probe
to be within a 1/4" of each other.

> 2) I get nothing from clk128 - it may just not be connected. Is this 
> correct?

I don't think this is being used.

> 3) The usbclk is also outputting a signal that looks like a sine-wave at 
> around 50MHz. Is this correct?

More probing problems.  The signal is 48MHz.

> 4) The USB data signals look very very unsteady. They look nothing like a 
> square wave or a sine wave - almost somewhere in between with slow rising 
> edges and then fast drops to 0.

Beats me, I've never tried probing them.  They're running at
480Mb/sec.  My scope won't run that fast.  

> I'll explain briefly what I am trying to do. Essentially I've got another 
> FPGA board that I want to get the output from the USRP board to be 
> trasferred onto. Essenitally, I want the I,Q pairs that go to the USB on 
> the USRP board to go to the daughterboard pins so that I can sample them on 
> this second FPGA board.

OK

> I've written some python code to output 1, and 0s onto the daughter board 
> pins (that's why I needed the previous help - thanks again Eric).  The 
> python code is basically a loop that outputs 0x0 and 0xffff alternately to 
> the daughter board pins. My oscilloscope shows a nice clean square wave 
> which comes out at about 3KHz when I remove all delays (delays made with 
> python's sleep). I guess this speed is the fastest at which the python code 
> can be interpreted, and the signal sent up the usb to the FPGA and then to 
> the daughter board pins.

FWIW, most of the delay is the round trip on the USB each time you set the pins.

> This has led to me to believe that, perhaps I'm 
> having a problem of speed - perhaps the USB data coming out of the FPGA is 
> changing too fast for a clear wave to show up on the daughter-board pins. 
> Would this be a correct analysis?

With good probing techniques you should be able to see
the pins moving.  To figure out what's going on a logic analyzer is a
better choice.  Also, how fast is your o'scope?

If you've got any EE friends, they can probably help you with the
probing techniques.

> Any help would be greatly appreciated as I'm hitting a bit of a wall now.
> 
> Thanks a lot for the already received help.
> 
> Andrew

Eric