DCM jitter (again)

Target = XC3S400 Spartan 3 Tool = ISE 8.2i

If I understand correctly, the DCM does not use a PLL to multiply-up the input frequency; it's a DLL and it generates all required frequencies/phases by selecting outputs from a tapped delay line. I heard these taps are only tens of picoseconds apart. Is this so? Why then is the peak-to-peak jitter, as calculated by the DCM wizard, so large e.g. hundreds of ps?

For Spartan 3 designs, the tools do not automatically take DCM jitter into account. To get it included, I've manually added INPUT_JITTER 0.82 to the end of my external clock constraint:


Half of this figure then appears as "clock uncertainty" on the timing analysis report, and PAR works that much harder to get closure. I don't like including DCM jitter this way. The input clock is clean. Is there a neater way to specify it on the DCM outputs where it belongs?

TIA Andrew.

Reply to
Andrew Holme
Loading thread data ...

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.

Reply to

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.

Reply to


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).


Reply to
Austin Lesea

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.

Reply to

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?


Reply to


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.


Reply to
Austin Lesea

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.