Re: Exact Timing Constraints vs. Over-Constraining

In article <[EMAIL PROTECTED]>, Robert Sefton wrote:
> "Larry Doolittle" <[EMAIL PROTECTED]> wrote in message
>>
>> 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.
> 
> What is metastability slack and how do you apply it? Do you mean you
> over-constrain your clock periods slightly to expand setup margins?

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