[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Daughter board pins
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Daughter board pins |
Date: |
Wed, 27 Sep 2006 09:48:53 -0700 |
User-agent: |
Mutt/1.5.9i |
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
- [Discuss-gnuradio] Daughter board pins, Andrew Borg, 2006/09/20
- Re: [Discuss-gnuradio] Daughter board pins, Matt Ettus, 2006/09/24
- Message not available
- Message not available
- Message not available
- Re: [Discuss-gnuradio] Daughter board pins, Andrew Borg, 2006/09/26
- Re: [Discuss-gnuradio] Daughter board pins, Eric Blossom, 2006/09/26
- Re: [Discuss-gnuradio] Daughter board pins, Andrew Borg, 2006/09/27
- Re: [Discuss-gnuradio] Daughter board pins, Brian Padalino, 2006/09/27
- Re: [Discuss-gnuradio] Daughter board pins,
Eric Blossom <=
- Re: [Discuss-gnuradio] Daughter board pins, aborg, 2006/09/28