Hi,
1) I removed tx_io[15] from my design 2) Change fifo_not_full signal to fifo_almost_full 3) I tried to follow most of your suggestions to achieve better timing 4) I use minimum cable length. Now I'm observing strange behavior. I grounded Virtex board and USRP2 board together. Initially I use ground pin at J503 (Test CLK) on USRP2 mother board and observe the spectrum at RX. I see the noise floor of spectrum goes up and down about 20dB. And unknowingly, I change ground pin to J101 at RFX2400 daughter board. Then the observed spectrum at RX is correct. No more noise floor goes up and down. Can someone please explain what is happening here? Thank you. PN From: Ian Buckley [mailto:i...@ionconcepts.com] Sent: Tuesday, December 20, 2011 4:16 AM To: Phone Naing MYINT Cc: usrp-us...@lists.ettus.com; discuss-gnuradio@gnu.org Subject: Re: [USRP-users] Modification on vita_tx_chain.v 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 usrp-us...@lists.ettus.com<mailto:usrp-us...@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
