clockprecision
I have worked on a project using high precision clocks for some time now. I have yet to find a clear description on how manufacturers and scientist confirm and verify the precision of clocks like OCXOs.
My approach have been to use time and test two clocks relatively to each other. As time goes, the error between each clock will sum and create a bigger uncertainty.
But how is this done with cutting edge Atomic clocks within NIST standards ?
A better crystal is one way to solve it, but it's going to cost. And even then you get maybe 10ppm, good (or bad) for 5 minutes after 1 year.
Temperature compensated crystals are good to get a predictable stability, but they don't solve the tolerance problem; if you have a 20ppm deviation from nominal frequency, you're sure you'll always have this deviation. BTW, this is also more expensive, and I haven't seen it for 32kHz crystals.
Software compensation is a cheap solution, and I've used it a few times. For production runs you'll have to measure the frequency and program the compensation value on a test jig.
You can also use a trimmer capacitor for the oscillator's load capacitor.
What I find the nicest solution, however, is to add an atomic clock receiver module (WWVB for North-America, DCF77 for Europe), and resync once a day or so. The picture shows an miniature DCF77 module from Conrad.
Define divide by 1 clocks on the and_* nets and declare them to be physically exclusive. Cadence RTL compiler handles the situation correctly by generating 3 timing paths for registers clocked by cpu_clk (one path each for one clock). Registers directly driven by clk0, clk4 and clk_ext have their own timing arcs.
create_generated_clock -source [get_ports clk0] \
-divide_by 1 -name and_clk0 [get_pins and_cpu_1/Y]
create_generated_clock -source [get_ports clk4] \
-divide_by 1 -name and_clk4 [get_pins and_cpu_2/Y]
create_generated_clock -source [get_ports clk_ext] \
-divide_by 1 -name and_clk_ext [get_pins and_cpu_ext1/Y]
set_clock_groups \
-physically_exclusive \
-group [get_clocks and_clk0] \
-group [get_clocks and_clk4] \
-group [get_clocks and_clk_ext]
Best Answer
As with anything that is adjustable, when comparing it and calibrating it against something else that is adjustable, how do you know what is "right"? What is considered "more accurate" if everything is just compared against something else that is compared against something else? There has to be something at the end of the chain where you say "This is exact". Some base value that all others are, ultimately, compared to.
And that is the Caesium atom.
I found a good description of how they work online:
A good caesium clock has a precision of in the order of \$\frac{1}{3\times10^{15}}\$ which is far better than any crystal, OCXO, TCXO, or otherwise.
So having that as a baseline you can now calibrate other systems against it. And the further systems against those. The higher the accuracy of your nominal frequency you want the "closer" to that source you want to get.
But as has already been mentioned in the comments, that's only half the story. The whole purpose of OCXO or TCXO is not to make a crystal oscillate more closely to that precise "source" reference frequency, but to keep the it oscillating at a fixed frequency. A crystal's resonant frequency drifts and changes depending on temperature. By either controlling the temperature (OCXO) or compensating for the changes in temperature (TCXO) you can either reduce or negate that drift.
Very often it doesn't matter one jot if you are a few Hz out when dealing with MHz or GHz frequencies. What matters is that you stay that same few Hz out and don't drift. It doesn't matter (for instance) that everyone would have to tune their TV to 512.000038MHz (that's what "fine tune" is for), but people would get annoyed if they had to keep re-tuning between 511.999381MHz and 512.000482MHz all the time depending on the weather.