DCM Jitter

Tool = ISE 8.2i Target = Spartan 3 xc3s400-4tq144

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

700ps?
Reply to
Andrew Holme
Loading thread data ...

Andrew,

You can not (meet timing).

formatting link
and
formatting link

Aust> Tool = ISE 8.2i

Reply to
Austin Lesea

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?

Reply to
John_H

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?

Reply to
Andrew Holme

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

Reply to
John_H

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?

Reply to
Andrew Holme

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.

Reply to
Andrew Holme

Andrew,

What version of software are you using?

If you read the link:

formatting 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:

formatting link

Austin

Reply to
Austin Lesea

formatting link

formatting link

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.

Reply to
Andrew Holme

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.