Exact Timing Constraints vs. Over-Constraining

[PO Laprise]

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

 

[Phil Hays]

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

 

[Robert Sefton]

"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

 

[glen herrmannsfeldt]

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 Doolittle]

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

 

[Peter Alfke]

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

 

[Peter Alfke]

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

 

[Peter Alfke]

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]

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

 

[glen herrmannsfeldt]

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

 

[Richard Iachetta]

In article <slrnbspm40.akj.ldoolitt@recycle.lbl.gov>, ldoolitt@recycle.lbl.gov
says...

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.

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.

--
Rich Iachetta

 

[Allan Herriman]

On Tue, 2 Dec 2003 16:07:51 -0600, Richard Iachetta <no@virus.com>
wrote:

In article <slrnbspm40.akj.ldoolitt@recycle.lbl.gov>, ldoolitt@recycle.lbl.gov
says...
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.

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.

 

[Hal Murray]

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!

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

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Hal Murray]

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

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.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Phil Hays]

Larry Doolittle wrote:

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.

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!


--
Phil Hays

 

[Larry Doolittle]

In article <29bqsvcjgj4lrivf4jfet6rdlalpjknbqd@4ax.com>, Allan Herriman wrote:

On Tue, 2 Dec 2003 16:07:51 -0600, Richard Iachetta <no@virus.com
wrote:

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.

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

Moral: avoid cookbook solutions.

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

- Larry

 

[Martin Euredjian]

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

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.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Mike Treseler]

Related Thread:

http://groups.google.com/groups?q=trust+synchronizer+violate+downstream

-- Mike Treseler