DCM jitter (again)

Andrew Holme schrieb:

If its any help you can look at the source code for the unisim or simprim simulation model for the dcm in those respective library sources,I remember looking at them some time ago so it may help to get a better understanding.

snipped-for-privacy@hotmail.co.uk schrieb:

Sorry to have to add to my last post but yes the clock manager is based on a delay locked loop rather than a phase locked loop as the phase noise is lower with a DLL than a PLL.

Andrew,

Yes, the taps are only 10 ps apart, but the control required to generate any M/D of the input clock is unable to be perfect for the DCM DFS output.

I refer to the algorithm as a "tap dance."

One creates a tapped ring oscillator out of the tapped delay line. If the output frequency is greater than the M/D times the input frequency, the period is made longer by changing taps. In the same way if the frequency is lower than the optimal value, the tap is moved to a shorter point.

In order to know that the frequency is high or low, one requires a frequency detector, which means you have to integrate time (count, and wait). Once you have your answer, it is too late to do anything that will correct right away, and you can only nudge towards the proper rate.

The DCM DFS uses a fairly sophisticated prediction method to drop/add tap changes as appropriate (reference the patents if interested), but yet is still not able to get the tap precision as the dominant jitter contributor. Rather, the DCM output jitter on the synthesized frequency output is mostly from not knowing when to zig, or zag, combined with jitter from the clock in, and not being perfectly accurate in knowing if the frequency is larger, or smaller (you sometimes make a mistake, unavoidably, because you can't wait too long! but you must wait to know anything at all).

The DCM DLL outputs do have a much more well behaved and bounded jitter output, which is precisely 5 steps (at most) in jitter plus your input clock jitter, as you are either one high, or one low, or you are two high (because your phase detector guessed wrong), or two low (again because a phase detector in the presence of jitter is also an imperfect arbiter).

Austin

No answer?

If you have access to the hotline, you may actually get a decent response. Constraints are something those guys may be well trained on (versus the complex design de jour from a random customer). There are even some decent documents on constraints that might otherwise be hard to find.

Clocking constraints - including the override of internally implied constraints - should be covered. Somewhere.

Also, if you have a relationship with your FAE, you might get good help there as well.

I had issues trying to trace constraints through a BUFGMUX and got some decent help pretty quickly. Constraints are tricky, particularly when you want to change the implied values.

Nice explanation, Austin, but did not answer the OP's question about how to get the tools to include the appropriate jitter in the static timing analysis. It's an important question. Do you know of any Xilinx guidelines that cover this topic in detail?

Rob

Rob,

No, I am not a tools expert (and really can't comment on constraints for timing). And I think the other posting to just email in a webcase is the best advice.

Austin