Exact Timing Constraints vs. Over-Constraining

I have seen much conflicting advice w.r.t timing constraints on this
newsgroup, and I was hoping that the proponents of both camps might
make explicit their reasons so that others (meaning I ;) can benefit
from their experience.

I have seen many posts recommending over-constraining the timing
requirements in an effort to ensure correct functioning in the
presence of uncertainty and unknowns, but I have also seen many posts
stating that the tools are now good enough that this is no longer
necessary, and that giving the true timing constraints is sufficient,
and will allow more latitude for the tools to put their effort where
it is truly needed.  I doubt if it's so cut-and-dry, but which is the
"right" one?  Or have I completely misunderstood the problem?

Thanks for your time,
Pierre-Olivier

--To reply directly, remove the obvious in
pl_N0SP4M_apri@cim.mcgill.1NV4LID.ca--

PO Laprise wrote:
 
> I have seen much conflicting advice w.r.t timing constraints on this
> newsgroup, and I was hoping that the proponents of both camps might
> make explicit their reasons so that others (meaning I ;) can benefit
> from their experience.
> 
> I have seen many posts recommending over-constraining the timing
> requirements in an effort to ensure correct functioning in the
> presence of uncertainty and unknowns, but I have also seen many posts
> stating that the tools are now good enough that this is no longer
> necessary, and that giving the true timing constraints is sufficient,
> and will allow more latitude for the tools to put their effort where
> it is truly needed.  I doubt if it's so cut-and-dry, but which is the
> "right" one?  Or have I completely misunderstood the problem?

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.


-- 
Phil Hays

In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote:
> 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.

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

"Larry Doolittle" <ldoolitt@recycle.lbl.gov> wrote in message
news:slrnbsoacg.9j2.ldoolitt@recycle.lbl.gov...
> In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote:
> > 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.
>
> 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

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

Phil Hays wrote:

> PO Laprise wrote:

>>I have seen much conflicting advice w.r.t timing constraints on this
>>newsgroup, and I was hoping that the proponents of both camps might
>>make explicit their reasons so that others (meaning I ;) can benefit
>>from their experience.

>>I have seen many posts recommending over-constraining the timing
>>requirements in an effort to ensure correct functioning in the
>>presence of uncertainty and unknowns, but I have also seen many posts
>>stating that the tools are now good enough that this is no longer
>>necessary, and that giving the true timing constraints is sufficient,
>>and will allow more latitude for the tools to put their effort where
>>it is truly needed.  I doubt if it's so cut-and-dry, but which is the
>>"right" one?  Or have I completely misunderstood the problem?

> 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.

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

Larry, I disagree. Metastability delay is statistically unbounded
(although less than 3 ns in all but perverse cases). But you should not
throw this in willy-nilly. Whenever you have a truly asynchronous
interface, you should be aware of it. If many or most of your timings
are prone to metastability, there is something wrong with the design approach...

Peter Alfke
====================
Larry Doolittle wrote:
> 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

Temperature, Vcc, and process variations are already (and have always
been) covered by the worst-case assumptions behind the Xilinx timing
analyzer numbers.

Peter Alfke
======================
glen herrmannsfeldt wrote:
> 
> 
> 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

In article <bqhbgp$22qvbe$1@ID-212988.news.uni-berlin.de>, Robert Sefton wrote:
> "Larry Doolittle" <ldoolitt@recycle.lbl.gov> 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

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 constraint requests literally. Once
they are met, the software does nothing to make it any better ( why
should it? ), the way a good engineer might naturally be inclined to do it...
It's just a computer!

Peter Alfke
======================
Larry Doolittle wrote: 
> 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

Larry Doolittle wrote:

(snip)

> 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.


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.

> 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").  

(snip)

> 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.

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