Are clock and divided clock synchronous?

Google dug up the following quote from Ray back on 2003-04-21.

/quote

I got nailed on an early Virtex design where the 1x and 2x clocks were sourced by the same DLL. Several factors contributed:

- the 1x clock was very lightly loaded while the 2x clock was heavily loaded,

- There was fair amount of jitter on the clock input (>300ps IIRC),

- There was heavy output switching on pins adjacent to the clock input pin (adds to jitter at DLL clock input)

- the failing nets were on direct flip-flop to flip-flop connections (no LUT) on FF's that were floorplanned to be adjacent.

- static timing indicated no setup or hold violations.

The combination of the jitter (which with input jitter barely in spec plus jitter introduced by output current modulation of input thresholds was likely out of spec), highly skewed loading (not convinced this is a real factor), and the absolute minimum flip-flop to flip-flop delay conspired to bite us where it counted. Since then, we have as a policy treated the 1x and 2x clock domains with utmost care to make sure the receiver is not sensitive around the transmitter's active edge. I suspect that if you have no direct connects between adjacent slices at the clock domain boundary, you won't have a problem.

/unquote

Peter & Austin, I really want to believe you. Do you think Ray's being overly careful? Could it be a problem in the "extreme" topology Ray describes?

Jeff

Reply to
Jeff Cunningham
Loading thread data ...

As I recall this discussion and various previous analyses, the final concensus was that hugely different loads on the two clocks is suspect #1.

If so, is this still (!) the view at Xilinx, and if it is the view has the clock buffering changed enough on recent products to alter matters?

Reply to
Tim

Jeff,

Read my techXclusive on the web "Does Your Design Have Enough Slack" which describes how jitter takes directly away from the slack in your timing budget.

ISE6.1 has new ways that keep track of jitter in the new products, so that this effect can be carefully kept track of (between clocks from different DCMs, 1X vs 2X, etc.).

I would say that if you ignore jitter totally, and expect to operate without any problems, and are pushing any limit (frequency, time, part utilization, SSO limits) you will be disappointed.

This is not unique to FPGAs or even to any one vendor: it is a fact of life that with clock periods approaching 2.5 ns in some designs, 500 ps P-P of jitter becomes 20% of the entire timing budget!

If the system clock was 10 MHz, and the design was not too exciting, then no one would care about 500 ps of jitter.

Aust> Google dug up the following quote from Ray back on 2003-04-21.

Reply to
Austin Lesea

Tim,

Since Virtex everything is fully buffered, Loads can change the timing, but only very slightly (10s of ps MAX), and not much at all on global clock buffers.

What gets folks in trouble is what I answered in my other post on this thread: they fail to see what their total system jitter is, and add that to the amount of slack they need.

Aust> Jeff Cunn> > Google dug up the following quote from Ray back on 2003-04-21.

Reply to
Austin Lesea

Jim, if your design is sensitive to 50 ps jitter, it needs an external clean-up PLL. Inside a digital chip there will always be some jitter, and on-chip PLL are not so good either. Jitter is noise in the time domain, and digital circuits are inherently noisy...

Peter Alfke

Reply to
Peter Alfke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.