DCM Jitter

Andrew,

You can not (meet timing).

Aust> Tool = ISE 8.2i

Austin didn't directly address the DCM-generated jitter.

There has been information on the Xilinx tools that suggest that jitter from the DCMs - assuming the input jitter is clean (within datasheet spec) to those devices - is included in the timing analysis. The caveat I saw was something like "for thoroughly characterized Xilinx devices such as the Virtex-4 family" or similar qualification targeting the DCM jitter.

I do not know if the tools do, indeed, add the jitter into the timing uncertainty. I haven't looked hard for it but perhaps I should look harder. The caveat left me with a poor feeling about the tools' ability to deal with my Spartan3(E) designs because I don't know if those families were "thoroughly characterized" or not.

I'd suggest looking at the full timing report for a 200 MHz path and for a 50 MHz path. Do both have identical Tco and Tsu times? Is there a "clock uncertainty" value used in the slack calculation?

The assumption here is that you have a low jitter clock presented to your system for the DCMs to work from. If your input jitter isn't clean, that value needs to be added to your UCF. If it is clean, it was my understanding that the tools were supposed to automatically propagate the DCM jitter values to the registers in that clock domain.

Are we there? With all recent families? With some?

I generated a verbose timing report, as you suggested, and every single path included the line:

Clock Uncertainty: 0.000ns

So I don't think the DCM jitter is automatically propogated.

If the tools stop trying as soon as they get 1ps of slack, how is it supposed to work? Am I supposed to manually create a jitter constraint for the DCM?

You can specify JITTER and/or INPUT_JITTER in the constraints file; check your constraints guide for details.

If the "Clock Uncertainty" is where the jitter shows up, then yes - you would need to add the jitter values manually. I had thought, however, that the adjustments for DCM generated jitter showed up in a different form for those families where DCM jitter *is* included such as for the Tco or Tsu times. If those values match picosecond for picosecond, then you have no DCM jitter included through those values

In the verbose timing report, Tcko is the same for both DCM-generated clocks (0.72ns for setup paths and 0.576ns for hold paths). So I am still confused. Doesn't that mean the place and route stops trying too early?

path

I've taken the pk-pk DCM jitter (0.8ns) and specified it as INPUT_JITTER on my input clock. This now appears as clock_uncertainty = 0.400ns in the timing reports. and my design now fails to meet its constraints.

Andrew,

What version of software are you using?

If you read the link:

you would see that 1/2 the total system jitter is what should be your slack (at least), or shortening your clock constraint by 1/2 your p-p system jitter.

This answer record details how uncertainty is dealt with by the tool:

Austin

Hi Austin,

I'm using ISE 8.2i targetting a Spartan 3 device.

I was not surprised to see the 800ps jitter treated as 400ps uncertainty, because I read about the factor 1/2 in your article.

I was glad to fail timing closure, because now, when I get it to pass, I know jitter has been factored-in.

Thanks, Andrew.