[time-nuts] Brooks Shera

Tue Mar 26 00:35:55 UTC 2013

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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>