cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mj61954
Visitor
Visitor
6,512 Views
Registered: ‎04-14-2012

OBUF Jitter

What jitter, if any, is introduced by a Virtex5 xq5vfx130t-2ef1738 part?
Let's assume a 125MHz jitter-free input clock going thru an IBUFG to an ODDR, the Q pin assigned to an arbitrary o/p pin.

Please give me the answer in picoseconds.

 

Thanks,

mark

0 Kudos
Reply
7 Replies
eteam00
Instructor
Instructor
6,510 Views
Registered: ‎07-21-2009

First off, IBUFG is not a clock buffer and it cannot drive ODDR clock pins directly.  IBUFG is nothing more than an IBUF which is located at a GCLK pin.  Do not confuse IBUFG with BUFG, they are completely different.

 

I don't believe Xilinx specifies this sort of performance.  I would think that the circuit you describe introduces very little "jitter", if any at all, presuming that the input pin rise/fall time is theoretically zero and the on-chip interconnect is also zero.  Slowing rise/fall time and increasing on-chip interconnect delays -- combined with circuit board and internal power supply/GND noise -- will introduce jitter.

 

In a practical circuit, using differential input (and IBUFDS) and differential output (and OBUFDS) will help minimise jitter.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
gszakacs
Professor
Professor
6,506 Views
Registered: ‎08-14-2007

Unless your clock design includes a PLL or DCM, the jitter is almost entirely

due to noise induced on the power and ground rails.

 

As Bob pointed out, you can minimise the effect of this on I/O using differential

standards.  However there will still be some jitter on the internal global clock

nets due to noise on Vccint.  And if your design has a lot of high-speed outputs,

there will be additional noise on Vcco and more importantly Ground causing

more jitter.  If your jitter budget is a handful of picoseconds, then I would not

suggest running the clock through the FPGA, regardless of how you do it.  The

fact that you are using a large part indicates that you will most likely have a large

dynamic component on your Vccint current draw.  This is not good for jitter.

If the part were empty other than the forwarded clock, you would have very little

jitter (and no reason to use a large FPGA).  Otherwise, you're much better off

using an external clock buffer to drive the clock to multiple chips in the system.

 

-- Gabor

-- Gabor
eteam00
Instructor
Instructor
6,503 Views
Registered: ‎07-21-2009

I agree with everything Gabor wrote.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
austin
Scholar
Scholar
6,485 Views
Registered: ‎02-27-2008

,,,

 

and so do I (agree).

 

Controlling peak to peak jitter is very very hard in a large part, with one clock, and with strong single ended IO standards.

 

Best is having asynchronous clocks for different functions (or use phase offests for the same clock so not everything swicthes at the same time), using differential signals, having the best possible bypasing or decoupling, and using the best signal integrity possible (no reflections, best impedance match, no overshoot, nor undershoot).

 

Another trick id that often, there is much less jitter at a higher frequency clock (much better decoupling performance), so often using a 2X clock for large sections of logic is more than 2X less jitter! (one wouldn't think this could be true, as when the period gets smaller, then the p-p period jitter is larger for the same absolute value of p-p,,,,)

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
austin
Scholar
Scholar
6,477 Views
Registered: ‎02-27-2008

40psec RMS is not very tight at all.

 

That would be ~ 14X larger for peak to peak.

 

Careful:  the units are very important here!.

 

If really p-p, the previous post says to send that clock to the A/D or D/A directly (only way) and also using a good clock buffer chip, send a copy to the FPGA so you are able the capture the data.

 

Radio systems do this, as the jitter reduces the resolution of the converters.

 

Clock ---> buffers --> ADC, DAC

                                ----> FPGA

 

The data path doesn't care (the signal is digital now, and as long as timing is met, everything is OK).

 

Often the ADC, DAC, clock is on its own pcb, or completely separated from the FPGA part of the PCB (separate ground and power planes).

 

40 ps p-p is VERY TOUGH, and should be done by an expert familiar with the problems and issues, and everything checked by a compentent signal integrity engineer.

 

40 ps p-p = TOUGH, 40 ps RMS, EASY

Austin Lesea
Principal Engineer
Xilinx San Jose
mj61954
Visitor
Visitor
6,463 Views
Registered: ‎04-14-2012

More details about the implementation...

 

The TLK2711 is a parallel to serial converter - we are using it as a TX only . It has a 16bit data, 2 K chars (MSB/LSB) and a clock inputs. We are sending it the data and K chars,and I would also like to send the clock to it to eliminate concerns over turn-around delay analysis should the TLK2711 receive the same clock as the FPGA.

 

The TLK2711 converts the data/k-cars into an 8b10b serial stream, and uses the 80MHz clock to create that 1.6 GB serial stream. Thus, the tight constraint in that the 80MHz clock can only have p-p 40psec jitter. So my question is quite simple - thru a ODDR w/that clock and its 2 D i/ps tied at 1/0 to follow the clock, will there be more than 40psec p-p jitter? You may have already answered this, but I'm not certain, and if so, my apologies.

 

thanks again,

mark

0 Kudos
Reply
mikemar
Newbie
Newbie
6,007 Views
Registered: ‎01-24-2013

Hi Mark,  (Hey Austin its mike m. hello from LA !)

 

The TLK2711 PLL has a loop filter that is most sensitive to jitter in the area between 1 and 3 MHz centered around the the fundamental period of the GTX_CLK you input into the device.  The gain is around +3-4db and rolls off at 20db/decade after that.  In the datasheet TI specifies for both the commercial and space qualified device an input clock with 40ps of PEAK-PEAK jitter maximum.  Now assuming you are running at 1.6Gbps which is 20x a 80MHz input clock to achieve an acceptable BER 10^-12 you would use an N-Factor = 14.069 as Austin pointed out.  This implies that you have a clock with approximately 2.8ps of RMS Jitter.  This is achievable with a very good oscillator.  Now what may save you is if the clock coming from the FPGA does not have significant frequency content in the 1 to 3 MHz range around the fundamental.   However I would like to point out that this assumption is dangerous since clock jitter from FPGA has both Rj & Dj components in it that can vary with the voltage supply rail, PWR & GND Bounce from SSOs, and the internal logic of the device, not to mention board layout and driver selection.  

 

Another gotcha on this device is to be careful about setting the pre-emphasis level to the correct level for the transmission medium you are using.  You can see significant degradation if you do not set this properly.  On the receive side TI did not implement an adaptive receiver for this device but you can buy one off the shelf.  

 

-Mike

0 Kudos
Reply