[time-nuts] an interesting problem

[Magnus Danielson]

On 06/02/11 07:14, Hal Murray wrote:
>
>> I've got a system at work with an internal clock oscillator that I want  to
>> get some statistics on, but there's no direct visibility for the
>> oscillator, nor do I have a convenient test point that I can probe.
> ...
>
>
> Fun problem.  Thanks for tossing it out.
>
> I see two approaches.  Are there others?
>
> One is to generate something like a PPS pulse and capture timestamps.  Then
> crunch the data and hope you see N buckets so you can ignore anything that
> isn't in bucket 0.  (or correct them by shifting by N ticks)

If he is going to do anything like ADEV you can't afford to drop 
samples. That would screw up the statistics. Fortunately the delays are 
integer steps of the original clock so the only arbitrary aspect is how 
many steps of clock there is. This allows for a several simple 
approaches to be used to find the base-line and then can all samples be 
time-adjusted to the base-line and then you have a continuous 
time-series with no dead-time... which is what you need for ADEV and 
friends.

> The other approach would be to measure the time between pairs of pulses.  You
> can probably do that much faster than once per second.  This should give you
> 2*N buckets.
>
> I can't quite figure out how far apart the pulses should be for best results.
>   (It will probably be simple after I see it.)  I expect it will depend on the
> ADEV of the measuring system and the ADEV of the clock you are trying to
> measure.

All you really need is that the pulses never may want to occur at the 
same time, so N*[0-14] needs a distance beyond N*14 which may be a 
single cycle. However, selecting a suitable division factor for the 66 
MHz clock will make the trigger signal frequency easy to relate to a 
reference. 100 kHz may be a suitable frequency.

> I assume you can get a rough ADEV of the clock you want to measure by
> measuring a similar part on a typical lab setup.

The systematic noise will drown the noise of the oscillator.

> It's probably worth sanity checking the divide step to make sure it's
> dividing by M rather than M-1 or M+1.  (Digital geeks are often off by one,
> especially if nobody has checked carefully.)  I'm not sure how to do that.
> Probably something like divide by 2*M and see if it matches.  Or divide by a
> small M and measure the frequency.

I've seen and repaired one of those bugs myself. Fascinating when a 
divide by 64 needs and extra bit and actually divides by 65. It looked 
generic but could only divide by 2^n+1 when told to divide by 2^n. A few 
quick fixes and it divided by N and needed no extra bit. The reason is 
simple... it's so simple design, so how could it fail? Well, designers 
attitude is why.

> Plan B would be to use an inconvenient test point. (or make one)
>
> Years ago, my boss gave a neat talk about how to prototype hardware.  Step 0
> was hire a good technician.  :)

Yeah, I've made sure we can do just that at work. Finding that unrouted 
ball in the middle of a BGA grid while not breaking the rest of the 
board is just one of the tricks he does... and it helped a lot (and 
prooved that I had done my part of the design worked).

Cheers,
Magnus