Set-up and hold times and metastability

[James823]

James823 <3681@embeddedrelated> wrote:

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-u
and
hold times, however the enable can be completely asynchronous withou
ever
causing a problem?

The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
seems to have some pretty good data (actual numbers) on
metastability.

-- glen

Ahh you read my mind - I was just about to ask!
Thanks, I'll give it a read.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[kaz]

James823 <3681@embeddedrelated> wrote:

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up
and
hold times, however the enable can be completely asynchronous without
ever
causing a problem?

When it comes to enable (or reset), devices differ in the way the
implement
it.

enable or reset may be available as ports on flips(designed at silico
level)
or they may be applied through logic on the D port. In this second cas
enable
or reset are directly involved in D value.

In the case enable or reset are ports then it is matter of silicon desig
but
I know altera defines timing violation in terms of D or enable or reset
release.

I usually visualise the flip as if it is in "sleep mode" when under rese
or
not enabled. Once it wakes up it should do so away from timing
window even if D is stable (but has changed value compared to current Q)
It is all eventually an issue of sampling a stable input or sampling by a
stable device.

Kaz


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jon Elson]

rickman wrote:

I don't have the stats memorized, but I don't think this is an accurate
description. If you design is truly async then the rate is such that
with a number of units in the field you will likely see failures long
before the warranty period is up... lol But by providing even as little
as two nanoseconds of settling time the probability is hugely reduced so
that it would then be years if not centuries between failures for
thousands of units.

Yes, I certainly don't recommend NOT using the classic dual-rank

FF to synchronize across clock boundaries. I'd want to be
conservative.

But this is also related to the significance of a failure. If it is a
router handling Internet traffic in a user's home, I think a failure
once a month per unit will never be noticed. If it is a more critical
application a failure once a decade across the product line might be a
problem.
Well, especially in TCP traffic, as long as the failure doesn't

lock up the router, it would be a pretty benign failure.

The real logic hazard is for a signal that changes near the clock
edge to propagate through the chip in such a way that the transition
arrives before the clock at some FFs, and after the clock at some
others, either due to routing or combinatorial delays. A simple
state machine can be sent to never-never land when this occurs.
By properly synchronizing when crossing clock boundaries, you
allow the tools to be sure that no signal can change state too
close to the setup time and cause such a hazard.

Static timing analysis is typically used to eliminate such timing
problems. That is FPGA 101 type stuff. Timing tools can't help you
with clock crossings, but they are easy to do if you pay attention and
don't miss any... that is the domain of project management.

Static timing finds real violations in propagation delay, but
totally misses non-synchronized signals coming from off-chip.
A static analysis says everything is fine, meaning that all signals
generated WITHIN that clock domain meet the setup/hold requirements.
And, I challenge you to find ANY logic designer who hasn't, at
one time, missed putting a proper synchronizer on a signals that
crossed a clock boundary. I sure know I have done it, and have
been on projects where others have done it.

Many people claim such problems were metastability, when they were
more prosaic logic hazards.

Yes, the two are sometimes confused.

And, that was really the big point I was trying to make, that what
the OP was asking about was most likely NOT a real metastability
problem, but a need to synchronize all inputs that cross a clock
boundary.

Jon

 

[kaz]

Static timing finds real violations in propagation delay, but
totally misses non-synchronized signals coming from off-chip.
A static analysis says everything is fine, meaning that all signals
generated WITHIN that clock domain meet the setup/hold requirements.
And, I challenge you to find ANY logic designer who hasn't, at
one time, missed putting a proper synchronizer on a signals that
crossed a clock boundary. I sure know I have done it, and have
been on projects where others have done it.

True, static timing analysis can only check paths between two registers an

will ignore the first set of fpga input registers (unless it has info on
external device output timing), any asynchronous input coming offchip and
external device input registers(unless it has info on external device inpu

timing). But it (or at least TimeQuest) default checks clock domai
transfers
unless the path is set false.

Whether metastability occurs or not, it remains a fact that timin
violations
certainly cause immediate failures (may be corrected by freezing) and thes

may be due to logic errors at sampling.

Kaz

---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jon Elson]

glen herrmannsfeldt wrote:

The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
seems to have some pretty good data (actual numbers) on
metastability.
Wow, this is an INTERESTING paper! It definitely contradicts current

wisdom and extrapolation. As FPGAs move to higher frequencies, this
trend is not good at all!

Jon