[time-nuts] Rubidium oscillator controlled clock
hmurray at megapathdsl.net
Tue Jul 13 22:49:07 UTC 2010
> 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
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.
More information about the time-nuts