[time-nuts] Metastability (was Brooks Shera)

Javier Serrano javier.serrano.pareja at gmail.com
Tue Mar 26 07:33:55 EDT 2013

On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak <tvb at leapsecond.com> wrote:
>> Both edges of the 24MHz clock gating pulse are asynchronous with respect
>> to the signal being gated.
>> Metastability can result with clock pulse widths that lie within a
>> critical range.
>> Bruce
> I don't disagree with your statement above, but my question was -- does it matter in a GPSDO; does it matter in this GPSDO?
> Occasionally missing a 24 MHz tick is a not a worry (all gated frequency counters share this "feature"). A one-count ambiguity is normal and expected, even welcome. Note also that the PIC will see only 0 or 1; there is no metastability in software. So where exactly is the problem?

Properly designed gated frequency counters get the input pulses into
their system clock domain by using a synchronizer. Then they use this
synchronized pulse to freeze the value of their internal counters. In
the process of synchronizing the input you do introduce a 1 clock tick
uncertainty, and this is unavoidable unless you go to more evolved
designs based on interpolation. I don't think this is what we discuss
about when we talk about metastability. If my understanding is
correct, what we are discussing is what happens if you try to freeze
the value of a counter with a signal which is asynchronous to the
clock of that counter. Imagine that you have a 32-bit counter and your
async pulse comes when the counter is transitioning from 0xFFFFFFFF to
0x00000000. *All* bits are changing state. Even without metastability
involved, i.e. assuming you don't hit the metastability window in any
of the 32 FFs you use for freezing the counter value, you have a
problem which is not a 1 tick problem. This is because the delays of
each bit going from the counter FFs to the freezing register FFs are
never exactly the same, so at the moment of freezing you might sample
e.g. 0xABCDABCD, i.e. something completely unrelated to the value you
would expect. Metastability would only make things worse by making
some of those bits "undefined" for some length of time.

So this is a well understood problem with a standard solution. Designs
which don't use this solution can still function well if the
occurrence I described is not very frequent.  It was said in the other
thread that Brooks Shera got rid of outliers (defined by him as more
than 30 ticks offset) in software. That still leaves a 30 tick
uncertainty for the time tag. So again, there is a proper way of
dealing with metastability, but that does not automatically imply that
designs not using it will malfunction. It depends on how often it
happens and what the specifications are for the given design. Still,
coping with metastability properly is so simple and cheap that there
is really no reason not to do it.



More information about the time-nuts mailing list