[time-nuts] Frequency Stability of Trimble Mini-T

[Hal Murray]

> Well, no, proper domain synchronization doesn't just give you an
> incremental advantage.  The use of flip-flops between clock domains is
> done to trade latency for guaranteed stability.  The idea is to
> isolate the effects of metastability to a single clock edge that won't
> be used to clock anything else.  Unless a metastable event somehow
> lasts more than one clock period (or half-period) it won't constitute
> a failure... and that never happens in practice, in the absence of a
> hard failure.  Correct?  Or am I missing something?  (e.g., are we
> talking cosmic-ray hits, which are much more likely to affect RAM
> elements than clock synchronizers?) 

It can happen.  There is no guarantee.  In a good design, it won't happen 
often enough to be interesting.  Not all designs are good.

The key parameter is settling time.  That's the time between the actual cycle 
time and the cycle time that the design rules (setup/hold, clock-to-out, prop 
delays, clock skew...) would let you run at if you weren't concerned about 
metastability.

Cutting corners like using the other edge of the clock without checking the 
numbers is a good way to get a not-good design.  It doesn't help that the 
manufacturers don't normally provide the data.

For example, if the design rules say your FF to FF path will run at 5ns (200 
MHz) but you are running at 10 ns (100 MHz) you have 5ns of settling time.  
If you use the other edge (and the clock is a clean 50% duty cycle), the 
design rule checkers won't complain, but now you have 0 settling time.

In the old TTL/DIP days, blindly using 2 FFs was a good rule of thumb.  The 
typical state machine had a ROM or ALU or cloud of gates in the timing path.  
The overall cycle time included enough time for their prop delays.  The 
settling time on the FF-FF path (which didn't have any slow parts) was the 
prop delay of the slowest ROM/ALU/whatever.  In practice, that was good 
enough.  (Note that things scale with technology, but might get exciting if 
you mix technologies.)



-- 
These are my opinions, not necessarily my employer's.  I hate spam.