[time-nuts] Brooks Shera

[Richard H McCorkle]

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