[time-nuts] Metastability in a 100 MHz TIC

Fri Jul 20 06:01:16 EDT 2007

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 at febo.com 
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Richard H McCorkle
> Gesendet: Donnerstag, 19. Juli 2007 09:09
> An: time-nuts at 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 at 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 at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> and 
> follow the instructions there.
> 