On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak <t...@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
