Exact Timing Constraints vs. Over-Constraining

I try to enter the constraints that exactly match the timing that the design will need to function, including board delay, loading delay, clock jitter and clock skew.

Xilinx tools will now allow for a clock jitter number, and will add jitter when going through DCMs. So the tools are (maybe) somewhat better. But the rest still needs at least minimal work, and maybe a lot of work if the timing is tight.

Don't forget metastability slack. In theory it does not apply to the purely synchronous nets; in practice I don't want to go through the work of separating them out, and it's a good excuse to add one more conservative assumption.

- Larry

the

Larry -

What is metastability slack and how do you apply it? Do you mean you over-constrain your clock periods slightly to expand setup margins?

Thanks,

Robert

How about temperature or Vcc variation?

Or process variations in the chips? A newer chip batch, done on a different process, may be faster than an older one.

If the timing constraints already include such margins, you don't need to add additional margins.

-- glen

Yes and no. Yes, I over-constrain my clock slightly (Peter Alfke's nominal number for modern chips and "typical" applications is 3 ns). The interpretation is to allow time after the clock edge for each flip-flop (that has an asynchronous input) to "choose" which state to land in.

In a private e-mail to me, Peter Alfke both complained that this approach is flawed (because the metastability delay is statistically unbounded, and of course he's right) and gave me the 3 ns number above (conservative for "all but perverse cases"). He's right, most nets don't need this. But if _some_ do (and I have two clock domains in my designs, that I cross carefully and minimally, but I can't get away with 'never'), then it's simply easier for me to set a global conservatism than to (in some error-prone way) root out the clock domain crossing flip-flops and change the timing spec on their output nets. Hey, my designs "make timing" and work in the field, so it can't be all bad.

An alternative approach (I have seen other people do this) is to put two stages of flip-flops on all clock-domain crossings, and _assume_ there is a ton of slack between them.

- Larry

When you implement double synchronizers, make sure that the two flip-flops are closely spaced ( e.g. in the same slice ) with minimal routing delay between them. Overconstrain this delay between them ( enforce a few ns ) so that you do not squander the time available for metastable resolution.

Remember: The software takes your c> An alternative approach (I have seen other people do this) is to put

(snip)

The original question didn't ask about metastability at all. It seemed to me that he was trying to exactly predict the timing margins required to make the design work.

(snip)

Well, you have a whole clock cycle of slack between them. Because of the exponential, that is usually good enough. If you are close to where it isn't, synchronous parts of the design will have metastability problems, too!

If your design will not fail in 1e100 years, is that good enough?

OK, today is tuesday, what day of the week will it be in 1e100 days? Only ordinary calculators need to be used in figuring this out.

-- glen

Larry, your clocks must be pretty slow if you can afford to add 3 ns to every path in the design instead of just the few async boundary paths. I would call that majorly, not slightly, over-constraining the design.

Yes. I have some 1.6ns clocks in my current design. It would be a bit hard to make the constraint 3ns tighter.

Moral: avoid cookbook solutions.

Regards, Allan.

Perhaps the software should have a "metastability" tag for signals between FFs that should be placed right next to each other. Then the timing analysis could tell you the slack which is what you really want to know. There are probably other good things smart software could do with that info.

Or maybe that's a wild goose chase. Maybe you don't want them right next to eachother and the clock is slow enough so it doesn't matter...

But they don't know anything about the input clock jitter.

In the old days, we mostly ignored clock jitter. Or rather build clock distribution systems with low enough jitter that it was reasonable to ignore it.

I think part of the round-down that people are doing today is to cover the clock jitter that they haven't thought about much. It's interesting/important at todays higher speeds.

Quick. How much jitter on the clock going into your PCI card? (Is that even covered in the specs?)

Don't forget Ray's stories of SSO adding to the jitter.

"Everything is relative". My current design needs to make 25 ns in a XC2Sxxx-5. I can afford to pad that by a few ns.

It's worth knowing about cookbook solutions, using them properly when they apply, _and_ understanding how to go beyond them when necessary.

- Larry

Yes. When crossing clock domains, make a time group of the synchronizing flipflops and make a FROM TO style constraint for just those flipflops.

While my current designs are slow by my standards (125 MHz fastest clock in a Virtex 2), I can't afford to reduce the periods by 3 ns, as that is a large fraction of an 8 ns period!

Sometimes you use over constraining to force the tools to produce a certain layout or routing. For example, a 100MHz design where you take a data path and call for something like a 600ps MAXDELAY. There are only a few ways to accomplish this. You are effectively saying that you want the tools to use short routing lines as well as close packing of data path elements.

Another case might be --a bit of conjecture here-- a design where you have not taken the time to fully constrain all paths. This meaning that there might be multi-cycle paths as well as flat out TIG's. These paths and those that truly must make timing will compete for routing/placement. By over constraining you might be able to ensure that design iterations (as the project evolves) don't necesarily break the important paths. Like I said, this might be stretching things a bit, but I've definetly seen designs that don't work when constrained according to exact period values suddenly work very well when over-constrained just a tad.

Related Thread:

-- Mike Treseler