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.par...@gmail.com> wrote: > 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. _______________________________________________ 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.