Why Two Independent Clocks Can Still Communicate

Module 1 established what a UART is and where its timing does not come from. This module answers the question that leaves behind, and it is worth stating in its most uncomfortable form.

Two devices each have their own crystal. Neither was trimmed against the other. Neither measures the other, now or ever. There is no feedback path, no correction loop, no acknowledgement — Chapter 1.3 established that nothing is acknowledged at all. The two oscillators are, in the strictest sense, unrelated physical objects drifting independently with temperature and age.

And the link works, reliably, for decades, in products shipped by the million.

That should feel like it needs explaining. A reader who accepts "both sides agree on the baud rate" as the explanation has not noticed the problem: agreeing a number in advance does not make two oscillators produce identical intervals, and it says nothing at all about when a bit begins. This chapter takes the arrangement apart into the four things it actually relies on, and identifies which one is doing the heavy lifting.

1. What "Independent Clocks" Actually Means

The word independent hides two different statements, and separating them halves the problem.

Frequency. Each endpoint's timebase runs at some actual rate. Both were asked for the same nominal figure, and neither achieves it exactly — a crystal has a tolerance, and that tolerance moves with temperature, supply and age. So the two actual rates are close but not equal, and neither device knows the other's value.

Phase. Even if the two rates were somehow identical, nothing says where one device's intervals sit relative to the other's. Two devices powered on at unrelated moments have no phase relationship whatsoever. A transmitter can begin a frame at any instant relative to the receiver's internal timing.

transmitter's intervals   |-----|-----|-----|-----|
receiver's intervals         |-----|-----|-----|-----|
                          ^^^
                          unrelated offset — no mechanism
                          anywhere in the link sets this

The distinction matters because the two are not equally hard.

Phase disagreement is total but observable. The receiver has no prior knowledge of it at all — but the transmitter's own signalling contains an event the receiver can detect, and that event carries the phase information.

Frequency disagreement is small but invisible. It is bounded by two component tolerances, which is a genuine constraint. But nothing in the link ever reveals it, so it can never be corrected — only tolerated.

2. The Bargain, in Four Terms

The arrangement rests on four things. Three are unremarkable. The fourth is where the whole thing actually works.

One — the rate is agreed in advance. Both endpoints are configured to the same nominal bit rate before any traffic. This is a prior agreement rather than a measurement, and it bounds the frequency disagreement to the sum of two component tolerances rather than leaving it arbitrary.

Two — each frame carries an alignment event. The transmitter's signalling includes a detectable transition at the start of every transmission. That event is what converts the agreed rate into a position, because a rate says how long an interval lasts and not when the first one begins.

Three — the receiver reconstructs the grid locally. Having observed the event, the receiver predicts where the remaining intervals of this frame should fall, by counting its own clock against the agreed rate. Nothing is transmitted to help it; the prediction is entirely local.

Four — the frame ends. The prediction is only used for a small, bounded number of intervals. Then the transmission finishes, and the next one brings a fresh alignment event.

Notice how little crosses the link. One event per frame is the entire timing content of an asynchronous serial transmission. Everything else is a local computation against a number both sides were told in advance.

3. Why the Fourth Term Is the One That Matters

The first three terms describe a scheme that would fail on its own. Work out why, and the fourth term stops looking like a detail.

Suppose the receiver aligns once and then predicts intervals indefinitely. The two rates are close but unequal, so every predicted interval is slightly the wrong length. Each individual error is tiny and harmless. But the errors are all in the same direction — one clock is consistently the faster one — so they do not cancel. They add.

After enough intervals the receiver's predicted positions have walked far enough from the transmitter's actual ones that the receiver is looking at the wrong interval entirely. Not degraded: wrong. And nothing anywhere in the link notices, because there is no feedback.

So a single alignment cannot support an unbounded stream. The scheme is only sound if the prediction is discarded before the accumulated error grows dangerous — which is precisely what "the frame ends" provides.

The figure is deliberately abstract about what the active region contains — that is Module 3's subject. What it shows is the only structural fact this chapter needs: error accumulates within a frame and starts again at the next one.

4. What This Costs, and What It Buys

Two consequences follow immediately, and both are worth stating because they explain the shape of everything later in the curriculum.

The link has no way to know it is failing. Since nothing measures the far end, a receiver whose predictions have walked off the transmitted grid produces wrong data with complete confidence. There is no degradation signal, no error count that rises gradually, no margin indicator. This is why Chapter 1.2's warning about silent corruption is a property of the timing model rather than an implementation weakness, and it is why the failure modes in Module 9 are about detecting malformed frames rather than about monitoring link health.

Component choice becomes a protocol-level concern. In a link that recovers timing continuously, oscillator accuracy affects a control loop's working point. Here it enters the correctness budget directly: a part with a looser tolerance consumes margin that a frame would otherwise have. That is an unusual and important property — the crystal is part of the protocol implementation, and Chapter 2.4 quantifies exactly how much of the budget it takes.

What the arrangement buys is everything Module 1 catalogued: no clock conductor, no recovery hardware, no training sequence, no link that must come up, and therefore an interface that works when very little else does (Chapter 1.5). The four-term bargain is the mechanism behind that entire property list.

5. Where This Lands in Hardware

The receiver's side of the bargain has a shape in RTL even before any of it is built, and one boundary is worth fixing now because every later chapter reasons across it.

// Synthesizable SystemVerilog — boundary only. Deliberately empty inside.
// The timing reconstruction this chapter describes is Modules 2.3 and 6;
// the rate generation is Modules 4 and 8. This is the port list those
// chapters will fill, and it already states the central difficulty.
module uart_rx_frontend (
    input  logic clk,      // the RECEIVER's own clock — the only timebase
                           // this module has, and unrelated to the far end
    input  logic rst_n,
    input  logic rx_i      // driven by the far end, transitioning at
                           // instants with no relationship to clk
);

Two ports, and the whole problem is in the relationship between them.

clk is the only timebase available. Every timing decision this module ever makes is expressed as a count of clk cycles. The receiver cannot measure time in any other unit, which is why the agreed rate has to be converted into a cycle count — and why Chapter 2.2 makes that conversion the first quantitative step in the module.

rx_i transitions independently of clk. The alignment event arrives whenever the far end decides to send, not on a clock edge. That has a consequence this chapter can state and should not develop: the input must be made safe for synchronous logic before any state decision is taken from it. That is an ordinary digital-design obligation with a standard answer, and Module 12 owns the implementation. For every timing derivation in this module, "the observed transition" means the transition after that boundary — which matters because the boundary itself adds a small, bounded delay that Chapter 2.5 counts as a real term in the margin budget.

There is no third port for timing. Worth saying explicitly, because the instinct carried from clocked interfaces is to look for one. Nothing arrives to tell this module when to sample. Everything it does with rx_i is inferred from clk, the configured rate, and one observed event per frame.

6. What This Changes for Verification

The four-term bargain defines the shape of the test space, and it is larger than engineers new to the interface expect. Each term is an independent axis a testbench can vary:

• the rate agreement — both endpoints at nominal, or each offset in either direction;
• the alignment event — arriving at any phase relative to the receiver's clock, including landing very close to a clock edge;
• the local prediction — exercised over frames of different lengths;
• the frame ending — with back-to-back frames, with long idle gaps, and with the next alignment event arriving immediately.

Two habits follow directly.

Exact nominal rate is the least interesting case. A testbench in which both ends run at precisely the configured rate is testing the one condition that never occurs in hardware. It will pass on a design with no tolerance whatsoever. Deliberate, asymmetric frequency error is the normal operating condition, not an error case — a point Chapter 2.4 makes quantitative.

Long-run traffic does not test what it appears to. Because the prediction is discarded every frame, sending a million frames exercises the same one-frame span a million times. It does not accumulate anything, and it will not find a marginal timing budget. What finds that is varying the parameters of a single frame — its length, the relative error across it, the phase at which it started — which is why UART timing verification is a configuration-space problem rather than a soak-test problem. Modules 14 and 15 build that space; the reason it has these axes is this chapter.

7. What This Changes on an FPGA

An FPGA engineer meets all four terms as concrete facts.

The fabric clock is the measuring stick, and it is unrelated to the rate. A design running at 100 MHz and a link configured for 115200 baud have no arithmetic relationship — Chapter 2.2 shows exactly how unhelpful the ratio is — so the agreed rate must be constructed by counting, and that construction has its own error which joins the budget.

The far endpoint's timebase is genuinely someone else's. Whether the other end is a USB-to-serial bridge, an MCU or a second FPGA, its crystal is a separate component with a separate tolerance. Nothing in the design can observe it, so it must be assumed and budgeted for rather than measured.

The receive pin is asynchronous to the fabric. As §5 noted, this is a standard obligation handled at the input boundary, and the small delay it adds is a real term in the timing budget rather than a rounding error.

Short frames are a feature here. Because the prediction only has to survive one frame, an FPGA UART can tolerate a fabric clock and a far-end crystal that disagree by more than a continuously-recovered link would permit. That tolerance is finite and computable, and Chapter 2.4 computes it.

8. Understanding Check

9. Summary

Two oscillators that are never measured against each other, with no feedback path anywhere in the link, nonetheless support reliable communication — and "both sides agree the baud rate" does not explain it.

The word independent covers two separate unknowns. Phase is completely unknown at the start but observable, because the transmitter's signalling contains a detectable event at the beginning of every frame. Frequency disagreement is small and bounded by two component tolerances, but invisible — nothing in the link ever reveals it, so it can only be tolerated.

The arrangement rests on four terms: the rate is agreed in advance, each frame carries an alignment event, the receiver reconstructs the remaining positions locally, and the frame ends. Only the third is a computation, and only one piece of timing information — the alignment event — ever crosses the link.

The fourth term is the load-bearing one. The two rates are unequal and the resulting positional errors share a sign, so they accumulate rather than cancel; a single alignment could not support an unbounded stream. Ending the frame discards the prediction before the accumulated error becomes dangerous. This locks three quantities together — rate disagreement, frame length, and tolerable positional error — so that a worse rate match demands shorter frames, and longer frames demand a better rate match.

At the next alignment event the receiver's phase reference is re-established. The oscillators are not. Neither frequency error is corrected or even observed; the arrangement limits exposure to the disagreement rather than removing it.

Two consequences shape everything later: the link cannot know it is failing, so corruption is silent; and oscillator accuracy enters the correctness budget directly, which makes the crystal part of the protocol implementation.

10. What Comes Next

The structure is now in place, and every term in it is a quantity waiting to be measured. Chapter 2.2 takes the first step by converting a baud number into the time quantities engineers actually reason with — the bit period, the grid of intervals a frame occupies, how long a frame lasts, and how badly that interval divides into a real system clock. Everything after it — the timing origin in Chapter 2.3, the accumulation arithmetic in Chapter 2.4, and the margin budget in Chapter 2.5 — is expressed in those quantities.

Browse the full path on the UART tutorials index. For the same "where does the receiver's timing reference come from" question answered for a clocked interface that does forward a reference, see Read Capture.