Re: Exact Timing Constraints vs. Over-Constraining

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