[time-nuts] Metastability (was Brooks Shera)

[Bob Camp]

Hi

The worst case (this time) are errors in the bottom 5 bits. The software will treat them as valid data. That assumes things stay simple. You are looking a counter that wraps around a lot of times….

Bob

On Mar 26, 2013, at 7:33 AM, Javier Serrano <javier.serrano.pareja at gmail.com> wrote:

> 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.
> 
> Cheers,
> 
> Javier
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.