Metastability in a 100 MHz TIC
In my Brooks Shera style LPRO rubidium controller I am using
the same HC4046 input conditioner and divide down counter on
the oscillator and HC4046 phase detector interrupting the PIC
as used in the original design. The phase detector output
feeds the count enable input of a pair of Fairchild 74F163A
synchronous binary counters clocked with a 100 MHz XO to
increase the TIC sample resolution to 10ns. The counters are
read and cleared every second and accumulated in software to
minimize glitches from multiple gating into the counter. A
23-bit DAC and LM199 reference are used to improve the EFC
resolution, applying 0-5v directly to the LPRO EFC input to
minimize noise pickup and maximize loop gain. A 16F688 PIC
monitors the GPS messages and accumulates sawtooth corrections
until read at the update time over a high-speed 200kbps
3-wire handshaking serial interface by the 16F873A main
controller. The handshaking interface allows the 16F688 to
transmit the accumulated sawtooth correction for the current
sample to the controller and reset its accumulator between UART
reads to prevent data loss and before the TRAIM message for
the next sample arrives to insure the predictions match the
samples.
A 4x larger setpoint and 1/4 the filter gain of the original
design are used to adjust for the larger counts returned with
a 100 MHz TIC. This keeps the controller gain and limiting
threshold approximately the same as the original design to
prevent excessive limiting of the input data into the filter
at high phase offsets and maintains good initial lock
performance. Since the 1-second stability of a rubidium
oscillator is relatively poor, and the 100-second stability
is much better, the loop update time was increased in the
rubidium controller from 30 to 120 seconds. The longer update
time results in 1/4 the number of updates to the EFC for
improved stability, and 4x more samples accumulated per update
to provide a better indication of true rubidium oscillator
stability. Without increasing the controller gain and using
a TIC with 4x the resolution of the original design over a
sample period 4x longer than the original design the loop gain
is 16x greater than the original design for proper loop
damping with the rubidium oscillator.
I originally assumed the 4x longer filter times that result
with the longer update time would be an advantage with a
rubidium oscillator. Testing revealed that proper correction
for daily temperature variations prevented using filter modes
with settle times longer than about half a day, or what the
Mode 7 (Tau = 8K sec) IIR filter in the original design
provides. The longer update time made the top two filter
modes settle in about 1 and 2 days and were not fast enough
in correcting for temperature variations to maintain optimum
long-term stability. Adjusting the mode scaling to 1/4 the
original value to compensate for the longer update time
restored the original range of IIR filter times.
With the discussions here on metastable states in TIC
counters, I am asking the experts on the list for their
opinion if the performance of this design would improve
by adding a shift register synchronizer between the phase
detector output and the count enable input of the 74F163A
TIC to reduce metastable states. The 74F series has the
best reliability figures from metastable effects of all
the TTL logic families according to the data I have read.
Each D F/F counter cell in the 74F163A has the clock applied
directly to the F/F, so no clock gating occurs. Instead the
input data is gated by count enable signals for each cell and
either the cell output is sent to the D input if the count
enable is low, or the previous cell output is gated into the
D input on carry if the count enable is high with D latched
into all F/Fs on each clock rising edge. While I see the need
for a synchronizing shift register in a gated clock design
like the original Shera controller, is it necessary for best
performance in a GPSDRO application with a 74F163A 100 MHz TIC?
Richard H McCorkle wrote:
With the discussions here on metastable states in TIC
counters, I am asking the experts on the list for their
opinion if the performance of this design would improve
by adding a shift register synchronizer between the phase
detector output and the count enable input of the 74F163A
TIC to reduce metastable states. The 74F series has the
best reliability figures from metastable effects of all
the TTL logic families according to the data I have read.
Each D F/F counter cell in the 74F163A has the clock applied
directly to the F/F, so no clock gating occurs. Instead the
input data is gated by count enable signals for each cell and
either the cell output is sent to the D input if the count
enable is low, or the previous cell output is gated into the
D input on carry if the count enable is high with D latched
into all F/Fs on each clock rising edge. While I see the need
for a synchronizing shift register in a gated clock design
like the original Shera controller, is it necessary for best
performance in a GPSDRO application with a 74F163A 100 MHz TIC?
It is always advisable to use a synchroniser to substantially reduce any
bias in the averaged phase due to metastability.
However unless there is very high isolation between the 100MHz XO and
the LPRO output as well as the 100MHz XO the divided down output of the
LPRO injection locking of the 100MHz oscillator may be a more
significant source of bias in the averaged phase. If the PPS signal from
the GPS timing receiver has sufficient random noise (~10ns) then this
should not be an issue.
When designing a synchroniser it is useful to have a quntitative model
of the metastability characteristics of the devices used so that a
reasonably accurate estimate of its output metastability rate can be
calculated.
Bruce
Richard,
metastability is an effect that happens when the setup times of an
d-flipflop are not met. This can happen (with a certain statistical
likelyhood) when the sources of the data input and the clock input of an
d-flipflop are not synchronized. The important thing to know about
metastability is that the likelyhood of its appearance might be directly
computed from the setup time and the frequency of the d- and
clock-signal as described in
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSeco
ndaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_metasta
bility
Peter Alfke is THE expert in metastability at XILINX! I guess if you
apply the data presented here to your case you will find that the
probabilty of metastability in your case may be neclected. Roumors are
that 99% of all assumed cases of metastability are due to other design
flaws.
However I would like to draw your attention to an second point. From
your posting it gets clear that you are not the pure user of the Shera
design but have otherwise put a lot of brains into the question of how
to improve it.
First, forget about the Shera design for a moment and consider the case
that you have two 1pps sources and want to compare them by means of an
REAL tic as the HP5370 or the SR620. Question: Since you are comparing
TWO oscillators by means of an THIRD oscillator (the tic's time base),
does the tic's time base stability influence your measurement results or
not?
Clearly so, if you think about it for a while. With this arrangement it
is not possible to decide whether 1pps a or 1pps b or the tic's time
base are responsible if you notice statistical fluctuations in the
measurement results. The measured results will be an statistical average
(not an simple arithmetic one but an more complicated one, but basically
you can imagine it as an average) of ALL source's fluctuations. The
situation changes if you have more sources and/or more tics available
because there are statistical methods available to allocate which source
and which tic is responsible for what but in the simple case of only
three sources these rules cannot be applied.
Now that you aware of the fact that the tic's timebase has an impact on
measurements made with the tic what would you do about it? In the real
world you would synchronize the tic's time base to the best reference
available, for example to the cesium in the backyard or the H2 maser in
the kitchen. But what if you lack equipment like that and have only this
one rubidium oscillator and this gps receiver? Clearly the second best
choice is to use the rubidium also as the timebase for the tic EVEN if
it IS the source that you want to discipline, just because you reduce
the complexity of the problem back to TWO sources of fluctuations.
Now let us come back to the Shera circuit. The question that must be put
forward at this point is: If we have just recognized that the tic's
timebase has pretty much the same influence on our mesurements as the
duts itself, how can the Shera design work with an timebase consisting
of a garden variety canned oscillator of the lowest class of stability?
If the above explained claims are true and the measurement results are
the statistical average over ALL sources then in your case this cheesy
little timebase is by some orders of magnitude worse in terms of
stability compared to the rubidium and the gps and what we measure
should in theory be dominated by the bad time base and not by the duts.
So, how can the circuit work at all ???
At this point we come to one of the big but not commonly well understood
tricks of the Shera design. The cheap canned timebase IS indeed the
biggest source of fluctuations in the design. However the design
includes precautions so that these fluctuation are hindered to show up.
Howzat?
Consider two 1pps signals. They can be as close as 0 s or they can be
apart as much as 500 ms. Consider they are 500 ms apart and you have an
timebase of 24.576 MHz to measure how far they are apart. With 500 ms
your tic will reach something like 12288000 counts in that time. Among
other environmental depencencies the coefficent of temperature will be
the most prominent one with simple xtal oscillators being in the order
of 1E-6/Kelvin. With 10 Kelvin temperature variation this will give you
an change of app. 123 counts in the count result for the SAME 500 ms
just due to temperature. This is an noticeable effect! Even the 10th
part of it, 12 counts would be an noticeable effect. But now comes the
clue: Both effects are noticeable because and ONLY because we made an
HIGH RESOLUTION MEASUREMENT. With 12288000 counts 1 count equals less
then 1E-7 of the result, so we made an measurement with better than 1E-7
resolution. Now consider the case when we limit the measurement range of
the phase comparator. Instead of allowing the pps signals to be 500 ms
apart we now DEMAND that they are not more apart than say 500 µs for
example because we claim that we cannot measure longer times. Within 500
µs the counter may reach an result of maximum 12288 (and not more
12288000) and 1 count equals app. 1E-4 of the maximal result. Which
effectively means that THIS measurement has only 1/1000 the resolution
of the original 500 ms measurement. Can this be true? Think abaout it
for a while and you will see its true. The 10 Kelvin temperature effect
that made an count difference of 123 counts in 500 ms will make an count
difference of 0.123 (!) counts in 500 µs. Which is less than 1 count and
will be VERY difficult to be noticed if possible at all. So one or two
clues of the Shera design is/are to make the measurement range of the
phase comparator THAT small that all environmental depencies of the
tic's time base are SMALLER than the RESOLUTION of the time base. Choose
an resolution sufficiently low and all environmental effects of the time
base will be masked by it.
And that is exactly where your consideration is going to get wrong: The
limited resolution of the Shera design (as well as the limted phase
measurement range) is NOT an FLAW of the design that could be improved
by your 100 MHz tic! It is an FEATURE of the design that may not be
touched in order to give the proposed results! And the fact that you are
NOT observing a real improvement although you increased the resolution
by 4 is the proof for it all: Not only did you increase the resolution
by 4, you also increased the count result's tendency to be influenced by
environmental changes by the same factor. You should notice a big
improvement if you throw away your 100 MHz oscillator to where it
belongs and feed your counters with an 100 MHz signal that has been
generated by an X10 frequency multiplication of your rubidium or by
phase locking an 100 MHz VCXO to the rubidium.
Best regards
Ulrich Bangert
P.S.
The reaction of rubidium oscillators to environmental changes like the
day-to-day temperature changes to happen in a typical flat have not yet
been discussed in the group in depth. However my own experience seconds
your own results concerning the loop's time constant. While the overall
temperature coefficient of of my rubidiums is an order of magnitude
better than that of my best OCXO it is not possible to use a higer time
constant with them compared to the OCXO when the day-to-day changes are
expected to be removed by the loop. Over the last years a natural loop
time constant of app. 1200 s has evolved to be the best compromise for
both the OCXO and the rubidiums. Since my OCXO has MUCH less phase noise
at small observation times I have come to the conclusion that an OCXO
based GPSDO serves me better than an rubidium based one.
-----Ursprüngliche Nachricht-----
Von: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] Im Auftrag von Richard H McCorkle
Gesendet: Donnerstag, 19. Juli 2007 09:09
An: time-nuts@febo.com
Betreff: [time-nuts] Metastability in a 100 MHz TIC
); SAEximRunCond expanded to false
Errors-To:
time-nuts-bounces+df6jb=ulrich-bangert.de+df6jb=ulrich-bangert
.de@febo.com
In my Brooks Shera style LPRO rubidium controller I am using
the same HC4046 input conditioner and divide down counter on
the oscillator and HC4046 phase detector interrupting the PIC
as used in the original design. The phase detector output
feeds the count enable input of a pair of Fairchild 74F163A
synchronous binary counters clocked with a 100 MHz XO to
increase the TIC sample resolution to 10ns. The counters are
read and cleared every second and accumulated in software to
minimize glitches from multiple gating into the counter. A
23-bit DAC and LM199 reference are used to improve the EFC
resolution, applying 0-5v directly to the LPRO EFC input to
minimize noise pickup and maximize loop gain. A 16F688 PIC
monitors the GPS messages and accumulates sawtooth
corrections until read at the update time over a high-speed
200kbps 3-wire handshaking serial interface by the 16F873A
main controller. The handshaking interface allows the 16F688
to transmit the accumulated sawtooth correction for the
current sample to the controller and reset its accumulator
between UART reads to prevent data loss and before the TRAIM
message for the next sample arrives to insure the predictions
match the samples.
A 4x larger setpoint and 1/4 the filter gain of the
original design are used to adjust for the larger counts
returned with a 100 MHz TIC. This keeps the controller gain
and limiting threshold approximately the same as the original
design to prevent excessive limiting of the input data into
the filter at high phase offsets and maintains good initial
lock performance. Since the 1-second stability of a rubidium
oscillator is relatively poor, and the 100-second stability
is much better, the loop update time was increased in the
rubidium controller from 30 to 120 seconds. The longer update
time results in 1/4 the number of updates to the EFC for
improved stability, and 4x more samples accumulated per
update to provide a better indication of true rubidium
oscillator stability. Without increasing the controller gain
and using a TIC with 4x the resolution of the original design
over a sample period 4x longer than the original design the
loop gain is 16x greater than the original design for proper
loop damping with the rubidium oscillator.
I originally assumed the 4x longer filter times that
result with the longer update time would be an advantage with
a rubidium oscillator. Testing revealed that proper
correction for daily temperature variations prevented using
filter modes with settle times longer than about half a day,
or what the Mode 7 (Tau = 8K sec) IIR filter in the original
design provides. The longer update time made the top two
filter modes settle in about 1 and 2 days and were not fast
enough in correcting for temperature variations to maintain
optimum long-term stability. Adjusting the mode scaling to
1/4 the original value to compensate for the longer update
time restored the original range of IIR filter times.
With the discussions here on metastable states in TIC
counters, I am asking the experts on the list for their
opinion if the performance of this design would improve by
adding a shift register synchronizer between the phase
detector output and the count enable input of the 74F163A TIC
to reduce metastable states. The 74F series has the best
reliability figures from metastable effects of all the TTL
logic families according to the data I have read. Each D F/F
counter cell in the 74F163A has the clock applied directly to
the F/F, so no clock gating occurs. Instead the input data is
gated by count enable signals for each cell and either the
cell output is sent to the D input if the count enable is
low, or the previous cell output is gated into the D input on
carry if the count enable is high with D latched into all
F/Fs on each clock rising edge. While I see the need for a
synchronizing shift register in a gated clock design like the
original Shera controller, is it necessary for best
performance in a GPSDRO application with a 74F163A 100 MHz TIC?
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.
Ulrich Bangert wrote:
Richard,
metastability is an effect that happens when the setup times of an
d-flipflop are not met. This can happen (with a certain statistical
likelyhood) when the sources of the data input and the clock input of an
d-flipflop are not synchronized. The important thing to know about
metastability is that the likelyhood of its appearance might be directly
computed from the setup time and the frequency of the d- and
clock-signal as described in
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSeco
ndaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_metasta
bility
Peter Alfke is THE expert in metastability at XILINX! I guess if you
apply the data presented here to your case you will find that the
probabilty of metastability in your case may be neclected. Roumors are
that 99% of all assumed cases of metastability are due to other design
flaws.
However I would like to draw your attention to an second point. From
your posting it gets clear that you are not the pure user of the Shera
design but have otherwise put a lot of brains into the question of how
to improve it.
First, forget about the Shera design for a moment and consider the case
that you have two 1pps sources and want to compare them by means of an
REAL tic as the HP5370 or the SR620. Question: Since you are comparing
TWO oscillators by means of an THIRD oscillator (the tic's time base),
does the tic's time base stability influence your measurement results or
not?
Clearly so, if you think about it for a while. With this arrangement it
is not possible to decide whether 1pps a or 1pps b or the tic's time
base are responsible if you notice statistical fluctuations in the
measurement results. The measured results will be an statistical average
(not an simple arithmetic one but an more complicated one, but basically
you can imagine it as an average) of ALL source's fluctuations. The
situation changes if you have more sources and/or more tics available
because there are statistical methods available to allocate which source
and which tic is responsible for what but in the simple case of only
three sources these rules cannot be applied.
Now that you aware of the fact that the tic's timebase has an impact on
measurements made with the tic what would you do about it? In the real
world you would synchronize the tic's time base to the best reference
available, for example to the cesium in the backyard or the H2 maser in
the kitchen. But what if you lack equipment like that and have only this
one rubidium oscillator and this gps receiver? Clearly the second best
choice is to use the rubidium also as the timebase for the tic EVEN if
it IS the source that you want to discipline, just because you reduce
the complexity of the problem back to TWO sources of fluctuations.
Now let us come back to the Shera circuit. The question that must be put
forward at this point is: If we have just recognized that the tic's
timebase has pretty much the same influence on our mesurements as the
duts itself, how can the Shera design work with an timebase consisting
of a garden variety canned oscillator of the lowest class of stability?
If the above explained claims are true and the measurement results are
the statistical average over ALL sources then in your case this cheesy
little timebase is by some orders of magnitude worse in terms of
stability compared to the rubidium and the gps and what we measure
should in theory be dominated by the bad time base and not by the duts.
So, how can the circuit work at all ???
At this point we come to one of the big but not commonly well understood
tricks of the Shera design. The cheap canned timebase IS indeed the
biggest source of fluctuations in the design. However the design
includes precautions so that these fluctuation are hindered to show up.
Howzat?
Consider two 1pps signals. They can be as close as 0 s or they can be
apart as much as 500 ms. Consider they are 500 ms apart and you have an
timebase of 24.576 MHz to measure how far they are apart. With 500 ms
your tic will reach something like 12288000 counts in that time. Among
other environmental depencencies the coefficent of temperature will be
the most prominent one with simple xtal oscillators being in the order
of 1E-6/Kelvin. With 10 Kelvin temperature variation this will give you
an change of app. 123 counts in the count result for the SAME 500 ms
just due to temperature. This is an noticeable effect! Even the 10th
part of it, 12 counts would be an noticeable effect. But now comes the
clue: Both effects are noticeable because and ONLY because we made an
HIGH RESOLUTION MEASUREMENT. With 12288000 counts 1 count equals less
then 1E-7 of the result, so we made an measurement with better than 1E-7
resolution. Now consider the case when we limit the measurement range of
the phase comparator. Instead of allowing the pps signals to be 500 ms
apart we now DEMAND that they are not more apart than say 500 µs for
example because we claim that we cannot measure longer times. Within 500
µs the counter may reach an result of maximum 12288 (and not more
12288000) and 1 count equals app. 1E-4 of the maximal result. Which
effectively means that THIS measurement has only 1/1000 the resolution
of the original 500 ms measurement. Can this be true? Think abaout it
for a while and you will see its true. The 10 Kelvin temperature effect
that made an count difference of 123 counts in 500 ms will make an count
difference of 0.123 (!) counts in 500 µs. Which is less than 1 count and
will be VERY difficult to be noticed if possible at all. So one or two
clues of the Shera design is/are to make the measurement range of the
phase comparator THAT small that all environmental depencies of the
tic's time base are SMALLER than the RESOLUTION of the time base. Choose
an resolution sufficiently low and all environmental effects of the time
base will be masked by it.
And that is exactly where your consideration is going to get wrong: The
limited resolution of the Shera design (as well as the limted phase
measurement range) is NOT an FLAW of the design that could be improved
by your 100 MHz tic! It is an FEATURE of the design that may not be
touched in order to give the proposed results! And the fact that you are
NOT observing a real improvement although you increased the resolution
by 4 is the proof for it all: Not only did you increase the resolution
by 4, you also increased the count result's tendency to be influenced by
environmental changes by the same factor. You should notice a big
improvement if you throw away your 100 MHz oscillator to where it
belongs and feed your counters with an 100 MHz signal that has been
generated by an X10 frequency multiplication of your rubidium or by
phase locking an 100 MHz VCXO to the rubidium.
Best regards
Ulrich Bangert
P.S.
The reaction of rubidium oscillators to environmental changes like the
day-to-day temperature changes to happen in a typical flat have not yet
been discussed in the group in depth. However my own experience seconds
your own results concerning the loop's time constant. While the overall
temperature coefficient of of my rubidiums is an order of magnitude
better than that of my best OCXO it is not possible to use a higer time
constant with them compared to the OCXO when the day-to-day changes are
expected to be removed by the loop. Over the last years a natural loop
time constant of app. 1200 s has evolved to be the best compromise for
both the OCXO and the rubidiums. Since my OCXO has MUCH less phase noise
at small observation times I have come to the conclusion that an OCXO
based GPSDO serves me better than an rubidium based one.
If the 100MHz clock is derived from the OCXO or other standard being
disciplined then the PPS source needs sufficent random jitter to ensure
accurate averaging of the phase error.
If the 100MHz source isnt as stable as desired then this instability can
be alleviated somewhat by using the 100MHz clock to measure the period
of the OCXO (or a multiple of this period), and using this result to
correct the phase measurement. If one measures 1E7 periods of a 10MHz
OCXO then the calibration error in the 100MHz clock will be around 1E-8
or so, allowing the calibration error (due to the 100MHz clock frequency
calibration error) in a 100us phase measurement to be held to within 1
picosecond or so. Almost any well designed XO mounted within an
enclosure with adequate thermal time constant will drift slowly enough
in frequency for this correction technique to be effective.
Re calibrating the 100MHz clock once a second should allow the effect of
its frequency drift to be minimised provided the critical parts of the
100MHz clock have a thermal time constant of a few tens of seconds or more.
However this method requires dividing the OCXO down to around 1Hz or so
to allow accurate calibration of the 100MHz oscillator against the OCXO
frequency.
The circuit complexity is greater than that required when using hardware
correction of the PPS sawtooth error followed by a simple D flipflop
(plus following synchroniser) where the corrected PPS clocks the
flipflop whose D input is connected to the OCXO output frequency or
submultiple thereof as suggested a few weeks (months??) back.
The D flipflop will typically have a resolution of a few picoseconds or
so depending on the logic family chosen. This is far higher than can
reasonably be expected when using an inexpensive variation of the Shera
circuit.
Bruce
Question: Since you are comparing
TWO oscillators by means of an THIRD oscillator (the tic's time base),
does the tic's time base stability influence your measurement results or
not?
Partly yes, for tau < 1 second.
Mostly no, for tau > 1 second.
Clearly so, if you think about it for a while. With this arrangement it
is not possible to decide whether 1pps a or 1pps b or the tic's time
base are responsible if you notice statistical fluctuations in the
measurement results. The measured results will be an statistical average
Perhaps I misunderstand your setup, but it seems to the
third timebase is only used for a time interval measurement,
not the time measurement. Thus the requirements on its
stability are much less than the two 1pps sources. Think of
it not as a "timebase", but a "time interval base".
For example, suppose you want to measure 1pps sources
which are within 10 microseconds in phase, to a resolution
of 100 ps. To make an ADEV plot for tau 1 second to 1 day,
you need to collect days of data, but you only need a
TIC timebase that is accurate and stable to one part in ten to
the 5th, at tau of 10 us. Any cheap XO will do that, no?
You don't need cesium timebases for a 1pps TIC.
/tvb