Set-up and hold times and metastability

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

it.

enable or reset may be available as ports on flips(designed at silicon level)

or they may be applied through logic on the D port. In this second case enable

or reset are directly involved in D value.

In the case enable or reset are ports then it is matter of silicon design 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 reset 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

Yes, I certainly don't recommend NOT using the classic dual-rank FF to synchronize across clock boundaries. I'd want to be conservative.

Well, especially in TCP traffic, as long as the failure doesn't lock up the router, it would be a pretty benign failure.

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.

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

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

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 input

timing). But it (or at least TimeQuest) default checks clock domain transfers

unless the path is set false.

Whether metastability occurs or not, it remains a fact that timing violations

certainly cause immediate failures (may be corrected by freezing) and these

may be due to logic errors at sampling.

Kaz

--------------------------------------- Posted through

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