[time-nuts] Rubidium oscillator controlled clock

[Hal Murray]

> I understand that you received some negative feedback on your ripple counter
> divider circuit but a single resync flipflop on its outputs in front of the
> AC04 drivers will do the job.

I think it's (much?) more complicated than that.

The basic problem is that the 74LS90 is very very slow.  Worst case prop 
times are 50 ns per chip.

I don't see a nice clean simple way to fix this.  It's not even clear what 
the goals should be.

One possible goal would be to make all the output clocks rise at the same 
time.  A simple FF on each clock before the drivers won't fix that since the 
prop time through the chain is several clock cycles.

Another possible goal would be to reduce jitter and wander.  (I'm using 
"wander" to cover low frequency phase shifts, for example the prop time 
changing with temperature.)  An extra FF clocked by a low-jitter clock will 
reduce the Gaussian jitter, probably by the square root of the number of 
clocks in the chain.  On the other hand, if the temperature changes by enough 
so that the delay wanders across a clock edge, you might get "jitter" of a 
whole cycle as the delay through the chain changes from N cycles to N-1 or 
N+1.

You might be able to avoid the cycle jumps.  Suppose you are lucky so that 
the end of the long ripple to make the 1 HZ clock comes out in the middle of 
of the clock window.  Now all you have to do is keep the temperature and 
supply voltage stable.  If you aren't lucky enough, you can add a delay, 
either R-C or a buffer chip.  This is clearly a kludge, but it might work 
well enough for a one-shot lab setup.

There is another worm in this area.  If you are doubly unlucky and your setup 
wanders near the clock edge, your retiming FF might go metastable.  The usual 
clean solution is 2 FF, but you have to check the goodness of your logic 
family and compare that to the excess prop time at your clock rate.

For my uses, I would probably leave out the extra FF and live with the extra 
jitter and wander until I needed something better.  Then I would at least 
know what "better" meant for me.  YMMV.


You can also fix the multi-cycle delay problem by putting a FF (clocked off 
the 10 MHz clock) between each LS90.  That would change the timing from a 
long ripple to several 1-cycle steps.  If you want all the clock edges to 
rise at the same time, you have to put extra FFs in the faster clocks to 
delay them the same number of cycles as the slow path.  (This is standard 
pipeline logic.  It's easy after you see it, but may not be obvious until you 
do get it.  I'll say more if anybody wants.)


Another approach would be to put the whole thing into a CPLD/FPGA/micro.  
These need tools and the skill to drive them.  That's no fun if you don't 
like that stuff, but can be great if you do.

The micro isn't any good for high speeds, but it should work for anything 
slower than 100 KHz.

Sometimes you can use serial ports to make clock/data patterns.  Adjust the 
baud rate to get the speed you want and send a continuous stream of 10101010. 
 That works better when you have a DMA engine that you can feed a big buffer 
to amortize the buffer-reload logic over lots of bits.  (as compared to 
taking an interrupt on each byte)

With multiple clocks in the same chip, the clock-to-out time depends 
(slightly) on the number of signals that are switching.  So for super low 
jitter, you still want an external FF to clean things up.





-- 
These are my opinions, not necessarily my employer's.  I hate spam.