OBUF Jitter

[mj61954]

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

[eteam00]

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

[gszakacs]

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

[eteam00]

I agree with everything Gabor wrote.

-- Bob Elkind

[austin]

,,,

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]

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

[mj61954]

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

[mikemar]

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