[time-nuts] an interesting problem

[Magnus Danielson]

On 05/02/11 16:25, jimlux wrote:
> Here's an interesting problem..
>
> 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.
>
> I can divide it down by an arbitrary number to generate pulses which I
> then send out via SpaceWire timecodes. SpaceWire is a fast point to
> point digital data link and it has a special capability that essentially
> has a "tick in" signal at one end and a "tick out" signal at the other
> end. The latency between tick in and tick out is random, but bounded and
> discrete. the link runs at a clock rate derived from the same
> oscillator, and you have to wait until the current character being sent
> has been clocked out before you can send the special "timecode" token.
>
> THat is, I can detect the "tick out" pulse and it has a random N*[0-14]
> clock delay (distributed more towards 0 than 14) from when the "tick in"
> (which is synchronous with the clock I want to measure). N is the ratio
> between my clock and the data rate on the wire ( 7, in this case, so the
> time step is about 100ns)
>
> So, by making measurements of the time when the "tick out" appears (or
> time between tick_out pulses) can I somehow "take out" the random
> variability of the link.
>
> It seems, since the clock isn't *terrible* that I could, for instance,
> accumulate statistics, and throw out the ones that have more than 0
> clock latency (which is probably a few 10s of percent of the ticks.. I
> haven't looked yet). Or, given that the interval between ticks is one of
> 28 or 29 discrete values (plus the underlying clock variance), if the
> clock variance on a given pulse is <<clock rate, the
> histogram/probability distribution of times would look like a bunch of
> little humps, each with variance =clock variance.

What you can do is you generate your tick clock at any division greater 
than 7*14 (if I understood the timing correctly). Say you divide your 
clock with 200 (about 3 us period if I got it right). Then you would get 
about half the period between your ticks would have random delay and the 
rest is silent.

You then make TI measurements against some suitable clock. From that you 
should then be able to rebuild your baseline time difference, detect the 
random delay of 7x[0-14] and once you done that re-stamp those with the 
suitable time and you now have a new time-series which all seems to be 
experiencing the random delay of 0. From then on just do the ADEV or 
whatever you want to do according to standard processing.

> or, is a real oscillator going to have an instantaneous variance that is
> comparable to or greater than 1 clock pulse?

No, probably not unless you got a seriously bad design, which you would 
probably know by now anyway. For short time-spans, deterministic noise 
(such as your random buffer delay) and white noise will dominate.

Cheers,
Magnus