I'm using an external 50 MHz oscillator and a single DCM to generate clocks of 50, 100 and 200 MHz. The static timing reports says the minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare.
I saw this comment in the Verilog file auto-generated by the DCM wizard:
// Period Jitter (unit interval) for block DCM_INST = 0.14 UI // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns
What does this mean? How can I meet timing by 1ps when the jitter is
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?
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.
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:
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.