Re: [time-nuts] Brooks Shera
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 counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a >30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important. But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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 Mon, Mar 25, 2013 at 3:41 PM, Chris Albertson
albertson.chris@gmail.com wrote:
In normal operation, the counter is clocking back and forth across the 1024 / 24,000,000 boundary. It has to do this for the control loop to "see" anything. Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all.
Yes. the counter value never should go more than 30 counts away from
1024. He defines a difference of over 30 as a "glitch" and as I
wrote, if this happens three times he does a reset and toggle a LED.
I was surprized at how low the threshold is. 30 seems low but
appearenty it almost never goes that far from 1024
Chris Albertson
Redondo Beach, California
There is an AMD patent where they actually drive the input pin to make it decide rather than hang. I have no first hand knowledge with the design (well other than knowing the designer) since I couldn't use the scheme in my own designs.
-----Original Message-----
From: Bob Camp lists@rtty.us
Sender: time-nuts-bounces@febo.com
Date: Mon, 25 Mar 2013 18:02:33
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Metastability (was Brooks Shera)
Hi
In normal operation, the counter is clocking back and forth across the 1024 / 24,000,000 boundary. It has to do this for the control loop to "see" anything. Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all.
It's the "race" between things like enable and clock or data and clock that generates metastable conditions. If the data is changing as the clock fires, the flip flop oscillates rather than goes to a single state. In this case oscillation is not a good thing…..
Bob
On Mar 25, 2013, at 5:43 PM, Chris Albertson albertson.chris@gmail.com wrote:
First off we have the answer. This thing works very reliably well.
The question is "why?"
In the normal steady state case the phase of the VCXO is held to be
1024/24,000,000 seconds. This means the plus from pin 15 of the 4046
would be about 4,000 nanoseconds long and would never be anything so
much as a factor of ten away from 4 uSec.
One thing I notice is that I think the QST artcle has the pins on the
4520 mislabeled. Pins 9 and 10 are the two inputs to an AND gate.
The 24MHz counter is being "anded" with the phase detector and the
result of the AND is then fed to the counter. My data sheet shows
pins 2 and 10 as being called "enable". So what we have as a pulse
that is about 4uSec wide gating a 24MHz square wave.
There might be a "race" to see if the enable pin or the clock pin gets
a pulse first and it would be a coin flip now and then but it's only
an off by one problem.
In the no-steady state case, when power is first applied before the
loop is closed. I don't think we care about glitches and and if the
VXCO is stable but as soon as it does locj the pulse going to pin the
4520's pin-10 will be 1024 times longer than the the period of the
signal at pin-9 Again, pins 10 and 9 are the two inputs to an AND
gate (after pin-10 is inverted)
On Mon, Mar 25, 2013 at 2:04 PM, Bob Camp lists@rtty.us wrote:
Hi
With the 24 MHz clock in the circuit, and the logic families shown, the most
likely metastability issues are edge rather than clock pulse width related.
When you hit the "magic window" (think picoseconds) there is a probability
of going metastable. It's not a 100% thing. Even with multiple synchronizer
stages not being metastable is also not a 100% guarantee.
The real question is - does a once every X seconds / hours / centuries event
bother me in the application? Once you get to a multi stage synchronizer,
the dimensions on the time are large enough that the answer is generally no.
The event is so rare that you will never see it with these data rates. Being
sure it's fixed is easy.
It's the flip side - error rate without the synchronizer that is a bit
harder to quantify. Things could run for weeks outside the threat window. Is
it a several times a minute (every few days) or once an hour (every few
weeks) problem? In the first case, you probably do care. Multiple hits per
minute will mess up the loop. In the second case, you will never notice the
issue.
Of course, boost the clock, change the logic family, mix logic families,
fiddle this or that and you probably should look at things again...
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bruce Griffiths
Sent: Monday, March 25, 2013 4:38 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Metastability (was Brooks Shera)
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
Chris Albertson wrote:
On Mon, Mar 25, 2013 at 12:45 PM, David McGawn1hac@alum.dartmouth.org
wrote:
S/LS logic was introduced in the mid 70's, F/AS/ALS around 1980, HC was
early 80's. By the third 7400 generation (F/AS/ALS) the problem was well
known with parameters available and the logic fairly hard to it
I think this is all moot because as I just wrote in another email the
PPS signal never gets out of the 74hct4046 chip. What gets out is
the output of "Phase Detector #3". You've have to know in some
detail how the 4046 chips' PD3 works.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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.
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.
--
Chris Albertson
Redondo Beach, California
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.
Tom Van Baak 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?
Agilent go to a lot of trouble to add synchronisers (and sometimes clock
jitter eg HP5345A) to their gated frequency counters to ensure that the
average measured frequency is unbiased.
For more detail see:
http://www.hpmemory.org/an/pdf/an_200.pdf pp
27-28
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdfhttp://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf
pp 12-15
The average value of the counter output when sampled is important in a
GPSDO.
Metastability can result in an output that oscillates or dwells at a
level that is neither 1 nor 0.
How the PIC reacts to such inputs is unpredictable although on an
interrupt input, at least, its likely to use a synchroniser.
For educational purposes if nothing else, I'm looking for a precise description of the scenario (at the picosecond level if necessary) that reveals the flaw in his board. I'm not saying there isn't; I'm just saying I'd like to see it explained. Either his design was accidentally or intentionally clever, or there is in fact a minor fault. However, if there is a flaw, we also need to explain why in 15 years no one has reported glitches in their Shera boards.
Probably because those that built them either didn't have the necessary
equipment or were unaware of the potential problem.
I sort of understand metastability, but just adding more hardware to reduce it doesn't seem to be the only way to deal with the issue in a GPSDO.
Said -- how do you handle this in your Fury design?
/tvb
Bruce
Hi
The gotcha with using the XO as a "spreading source" is the hanging bridge issue. As long as temperature (or what ever) is constantly changing the XO all the averaging stuff works out. A GPS with a sawtooth output (and no correction) is doing the same thing. The problem comes in when the XO settles down and runs at one frequency. That may sound impossible, but it's not. Injection locking is one way to make it happen. There are a couple of others. When the averaging stops, you get a dead spot. You don't get a glitch, you just loose resolution. The practical effect is a step in the input rather than a smooth transition. Not easy to spot….
Bob
On Mar 25, 2013, at 6:41 PM, Richard H McCorkle mccorkle@ptialaska.net 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 counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a >30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important. But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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.
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.
The counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a>30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important. But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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.
Hi
Using the GPS sawtooth as a source of randomness is dangerous. It can stop moving for minutes at a time if the conditions happen to be just right (or in this case wrong). Of course lack of randomization isn't your only problem when this happens. The (likely substantial) offset in the data is also a significant issue.
Bob
On Mar 25, 2013, at 8:35 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz 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.
The counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a>30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important. But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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.
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.
Bob,
You are preaching to the choir and although Brooks felt that
using an XO and asynchronous gating to improve the resolution
was sufficient and GPS sawtooth correction was not needed with
the long averaging times in his controller that doesn't mean
that I agreed. The early work I did just reduced the glitches
and improved the resolution so there was sufficient gain for
proper damping to discipline an atomic source. As I learned
more the benefits of greater phase accuracy became apparent
and led to the development of the IDC.
The IDC uses the disciplined source as a stable timebase with
PICTIC interpolation to increase the resolution. The typical
interpolation gain is 400 for 62.5ps/sample resolution but
this is reduced to 1ns to match the GPS resolution. The combined
instabilities in the interpolator are below +/- 4 ADC counts so
after the 16x reduction the 1ns phase data returned is accurate.
The 1PPS stability has no effect on the 1ns TIC resolution so
the accumulated phase data is accurate whether the 1PPS timing
is varying or stationary. The data has the GPS sawtooth correction
applied before filtering, so even if a 1PPS offset is present for
an extended period during a hanging bridge the sawtooth corrected
phase data entering the filter will be accurate. The only place in
the IDC where the sawtooth is used to advantage is over a 2 hour
calibration period there are typically enough min/max variations
due to the GPS sawtooth to accurately determine the interpolator
offset and span.
Richard
Hi
Using the GPS sawtooth as a source of randomness is dangerous. It can stop moving
for minutes at a time if the conditions happen to be just right (or in this case
wrong). Of course lack of randomization isn't your only problem when this happens.
The (likely substantial) offset in the data is also a significant issue.
Bob
On Mar 25, 2013, at 8:35 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz 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.
The counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a>30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important.
But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem
for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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.
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.
Hi
One very important thing to consider when looking at this design - it was done in the era of selective availability. That provided a lot dither all by it's self.
Bob
On Mar 25, 2013, at 10:05 PM, "Richard H McCorkle" mccorkle@ptialaska.net wrote:
Bob,
You are preaching to the choir and although Brooks felt that
using an XO and asynchronous gating to improve the resolution
was sufficient and GPS sawtooth correction was not needed with
the long averaging times in his controller that doesn't mean
that I agreed. The early work I did just reduced the glitches
and improved the resolution so there was sufficient gain for
proper damping to discipline an atomic source. As I learned
more the benefits of greater phase accuracy became apparent
and led to the development of the IDC.
The IDC uses the disciplined source as a stable timebase with
PICTIC interpolation to increase the resolution. The typical
interpolation gain is 400 for 62.5ps/sample resolution but
this is reduced to 1ns to match the GPS resolution. The combined
instabilities in the interpolator are below +/- 4 ADC counts so
after the 16x reduction the 1ns phase data returned is accurate.
The 1PPS stability has no effect on the 1ns TIC resolution so
the accumulated phase data is accurate whether the 1PPS timing
is varying or stationary. The data has the GPS sawtooth correction
applied before filtering, so even if a 1PPS offset is present for
an extended period during a hanging bridge the sawtooth corrected
phase data entering the filter will be accurate. The only place in
the IDC where the sawtooth is used to advantage is over a 2 hour
calibration period there are typically enough min/max variations
due to the GPS sawtooth to accurately determine the interpolator
offset and span.
Richard
Hi
Using the GPS sawtooth as a source of randomness is dangerous. It can stop moving
for minutes at a time if the conditions happen to be just right (or in this case
wrong). Of course lack of randomization isn't your only problem when this happens.
The (likely substantial) offset in the data is also a significant issue.
Bob
On Mar 25, 2013, at 8:35 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz 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.
The counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a>30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.
Richard
The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
I realize there are many cases where clock domain considerations are important.
But
why does it matter in a device that is simply doing long-term 1PPS statistical
sampling?
Could one of you clock domain specialists actually spell out the GPSDO problem
for
the rest of us, nanosecond-by-nanosecond?
Thanks,
/tvb
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.
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.
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 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