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
_______________________________________________
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.
