Re: [time-nuts] Brooks Shera
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@gmail.com wrote:
On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak tvb@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.
On 03/26/2013 01:35 AM, Bruce Griffiths wrote:
Richard H McCorkle wrote:
Hi Tom,
In the Shera design the instability of the XO timebase is
a key factor in improving the 30-second update resolution.
With the XO drift varying the sample point across the 1PPS
and 312.5 KHz edges the samples are constantly varying and
the average of the samples has a resolution much closer to
(1/CLK)/30 or 1.4ns. If both signals were synchronized
with the clock the start and stop edges of every sample
would fall exactly on a clock. In lock the odds of the
sources having a sample-to-sample variation greater than
1 clock period (+/- 41.7ns) over the 30 second sample
period is low. So the probability is high that you would
get 30 identical samples with an average resolution much
closer to 41.7ns (+/- 1 clock).
The above assertion is not correct if the inputs to the synchroniser(s)
are asynchronous to the synchroniser clock.
The gate period will have a bounded (neglecting the effect of
metastability at the output of the synchronisers) variation of +- 1 count.
Provided that the synchroniser (and counter) clock and the divided down
disciplined oscillator clock meet the conditions outlined by David Chu in:
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf
In practice these conditions may be difficult to meet without adequate
random phase modulation of PPS (and the divided down disciplined
oscillator signal).
Alternatively phase modulating the synchroniser/counter clock is perhaps
simpler.
The sawtooth phase modulation of the PPS signal output produced by many
timing GPS receivers isnt sufficiently random to be particularly useful.
A variant of the modulation was used in the HP5328A with 040 option when
doing T.I. averaging. As the 10 MHz time-base was PLLed to 100 MHz for
increased singel-shot resolution, a noise source was added to the loop
for averaging to make sure that the phase modulation smoothed the
various phase-relationships between the clocks to produce meaningful
averaging.
As for PPS sawtooth, the trouble with that approach is that the clock
generating the PPS isn't tuned to a suitable frequency for this form of
beat-note averaging to always achieve the needed resolution, and the
hanging bridge is when that beating has a "blind spot" and does not
produce useful delta-information at sufficient rate. You can also have
beating conditions causing many transitions, but few of these
transitions carry any useful information, because it sweeps a too low
set of phase-states to do any meaningfull averaging.
I have considered writing something up on this topic, but have not come
around to do it.
Thanks for the reference Bruce! I've seen it, so it was a good reminder.
Cheers,
Magnus