How are system clock and oscillator frequency related?

Question

My question is given a, for example, a quartz oscillator on a MCU board, how is the system clock generated? I'll break down this question into several parts below:

1. I always have the impression that oscillator generates a sinusoidal wave. But digital circuits use square wave as clock signal. So is there always some circuit that converts the sinusoidal wave into a square wave with the same frequency?

2. If the oscillator is eventually used for the MCU to count system time (e.g. the MCU is able to give current timestamp or measure a time duration in terms of its "device time unit"), without using any frequency multiplication or division, does one "device time unit" correspond to the duration of one period of the oscillator?

3. If there's some constant offset between the actual oscillator frequency and its nominal frequency, how does this error translate into the error in the duration represented by one "device time unit"?

Thank you!

Answer 1

PC clocking uses a reference oscillator of about 25MHz (a popular choice for Ethernet and PCIe). This starts as a crystal sine wave that is ‘squared up’ by a buffer to make a digital signal. That square wave then is used to generate the various frequencies (CPU, DRAM, PCIe, etc.) using PLL multipliers and dividers. The resulting clocks will usually will have some ratio relation to each other.

The system clock tick also comes from the same reference, and is used to drive timers and a system clock counter. It will also have a numerical relation to the reference oscillator, but won’t necessarily be an integer relationship to the CPU clock. This clock tick in turn generates an estimate of ‘wall clock’ time. The operating system uses this as the reference time. This is the time that's returned by the operating system, e.g., via the get_time() system call.

However, there's a problem. The difference between local estimated ‘wall clock’ time and actual standards-traceable time is expressed as a clock drift, and is indeed influenced by the accuracy and stability of the system oscillator. PC crystals aren’t expected to be more accurate than about 30ppm or so, nor are they stabilized, so if that matters the local time needs to be corrected from a traceable source.

Where does this matter? Servers for example, need accurate time stamps on transaction events.

These systems that need a calibrated reference will initially adjust their estimated ‘wall clock’ based on an independent local, nonvolatile reference. This can (and often is) in the form of a local battery-backed real-time clock (sometimes called the CMOS clock) that establishes an estimate of wall clock time at start-up.

Once the system is running, the machine can access a standards-traceable time reference over a network using a protocol like NTP. Wireless systems may use a cellular radio or even a GPS receiver that has standards-traceable time (this is true for all cell phones these days.)

Whatever the method - CMOS clock, NTP, GPS or cell radio - this calibration ensures an accurate wall clock time.

One case where the system crystal itself is adjusted in real-time is digital television receivers. These use embedded timing references in MPEG-2 Transport to adjust a VCO or 'pullable' crystal to cancel the clock drift. This ensures video playback doesn't have long term over- or under-run issues. (Nowadays, they use a fractional-n clock synthesizer to make that adjustment.) This standard then generates the video and audio playback clocks. Systems that don't use this correction will instead skip/repeat frames and / or glitch the audio. (experience: media processor IC design.)

Now, as far as a low-end MCU, there isn’t necessarily a system time tick unless it’s generated from a timer. This will have some divisor relationship to the system crystal, whose accuracy determines clock drift. A decent, properly loaded crystal should still deliver +/-50ppm or so; RC oscillators, not so much. Again, if accuracy is critical, best to re-sync with a known reference to establish known wall-clock time.

Answer 2

1. yes. A square/rectangle wave is required.

2. not necessarily. For example a base model 8051 microcontroller divides the oscillator frequency by 12. Thus the counter/timer clock is oscillator/12. Compare this with an AVR mega328 - The default internal oscillator is 8MHz and assuming the div8 fuse is not enabled, then the timers can count at 8MHz.

3. There's always a degree of error - the oscillator might be specified at 8MHz +/- 10% or something more precise might be 8MHz +/- 10ppm (parts per million). The error would affect your timing measurements, so this needs to be factored in.

One example would be for uart communications you generally want better than than 2% timing error. If using the AVR Mega328, the internal oscillator at +/-10% would be unacceptable. Whilst you can trim this value, it is also based on temperature and voltage, so it drifts. An external crystal might be spec'ed at better than 100ppm, so that would be a much better choice with no need for trimming - it would work 'out of the box'.

Answer 3

1. How the oscillator oscillates is one thing, and what kind of output the oscillator produces is another thing. In a MCU the oscillator circuitry would most likely just amplify the sinusoidal waveform into square wave for further use.

2. It really depends on the MCU. There are MCUs that can use the crystal clock directly as the system clock. There are also processors that use two, four, or 12 crystal clocks as the system clock. In some cases the MCU could even use both edges of the crystal clock to run so it varies.

3. No, definitely not an offset, but a ratio. If the clock runs 1% too slow from a target frequency, the whole MCU and everything in it would run 1% too slow, regardless of by how much the crystal frequency is divided or multiplied to get the MCU system clock.