discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] [USRP-users] Modification on vita_tx_chain.v


From: Ian Buckley
Subject: Re: [Discuss-gnuradio] [USRP-users] Modification on vita_tx_chain.v
Date: Mon, 19 Dec 2011 12:16:29 -0800

Ok, I glanced at your code quickly, here are my thoughts (some of which you may already do in files I haven't seen):

1) You are using tx_io[15] as a potentially highspeed I/O. This signal travels via the radio daughter cards and could easily lead to EMI noise issues. You could consider multiplexing I &Q to get more usable pins on the debug header.
2) Your "fifo_not_full" signal may be acted on too late on your external FPGA board, and an I/Q data pair may be lost due to FIFO overrun as the FIFO becomes full. I suggest using a FIFO "nearly full" signal, and adequate pipelining to ensure that AC timing goals are met in passing the signal from the USRP2 to the external FPGA board.
3) Not all bits of the I/Q data bus may be received in the correct clock cycle.
You are using (presumably) a rising clock edge to clock data off chip and a falling edge to clock data onto chip. If I presume that your clock is 25MHz ( the fastest possible on the USRP2) then that leaves 20nS setup and hold margin in an ideal world...it is likely far less. The following points will help improve timing.
* Register all signals passing on and off FPGA's with registers placed in the I/O rather than then core.
* For more deterministic timing, drive clocks off FPGA's using a DDR registers rather than passing the clock signal directly to the pin. See "RAM_CLK_i1" in u2_rev3.v for an example of how this can be done on Spartan3.
* Use IBUFG cells (or equivalent) when bringing a clock into an FPGA. If possible use a DLL in "system synchronous"  or "source synchronous" mode (as appropriate) to give tighter timing control. (You may find that the USRP2 has already used many of the available ones.)
* Use timing constraints in the UCF file for all the signals you are passing off chip to achieve AC timing goals. Check the timing results after the FPGA image is compiled to ensure timing goals were met.
4) Try to bring both boards as close to together as possible using a minimum length of cabling, ideally using a board to board molex connection. Do not use excessive drive strengths are slew rates beyond that needed to achieve timing to minimize EMI.

On Dec 19, 2011, at 1:43 AM, Phone Naing MYINT wrote:

Hi all,
 
I have done some modification on vita_tx_chain.v. I’m trying to get the data (I&Q) from another FPGA board using debug pins. When I receive the data, I write them into FIFO. The data are retrieved from FIFO when there is an strobe_tx signal.
 
And same sequence of data send using gnuradio and modified version(from another FPGA board). And look at the spectrum at RX. With modified version, the noise floor is increased about 20dB. I have attached the modified verilog file and two spectrum pictures. You can see the modification on vita_tx_chain.v file. Can anyone suggest me what is wrong with my modification?
 
PN  
<attached files.zip>_______________________________________________
USRP-users mailing list
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


reply via email to

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