Synchronous vs Asynchronous Serial Links

Chapter 1.1 established what a UART converts between, and left one sentence deliberately unexamined: the receiver is given one signal and must work out the bit boundaries itself. That sentence is the entire subject of this chapter.

The question is not what the word asynchronous means. It is narrower and more useful:

When timing is no longer carried across the interface alongside the data, what happens to the hardware problem — what does the receiver lose, what does it get instead, and which side now owns the work?

Answer that precisely and the rest of the curriculum stops looking like a list of UART features. Baud generation, sampling strategy, error detection and the entire shape of a receiver become consequences of one architectural decision made at the interface.

1. Three Clocks, and Why One Word Covers All of Them

Almost every confusion about asynchronous serial links comes from using one word for three different things. Separate them before going further.

The transmitter's local system clock. The clock that runs the digital logic inside the sending device. It comes from that device's own oscillator, and it exists whether or not the device is transmitting anything.

The receiver's local system clock. The same, in the other device. Different oscillator, different frequency in general, and no defined relationship to the first.

A forwarded interface clock. A signal driven across the interface for the purpose of telling the far end when the data is valid. This is the one an asynchronous serial link does not have.

The name is also not a claim about the logic. Asynchronous here describes the interface — the two endpoints do not share a timing reference. It does not describe the implementation: a UART is built from ordinary synchronous RTL, clocked by the local system clock, the same as everything around it.

2. What a Forwarded Clock Actually Supplies

To see what is lost, be exact about what a forwarded clock provides.

A forwarded clock is a sampling reference generated by the same source as the data. That single fact is what makes it valuable. Because the transmitter produces both, it controls their relationship directly: it can place its clock edges where its data is stable, and that relationship travels across the interface intact, to first order. The receiver does not have to work out when the data is good. It is told.

What the forwarded clock supplies, then, is not "a clock" in the abstract. It is the answer to the question when — computed at the transmitter, where the answer is known, and shipped so the receiver does not have to compute it.

The figure's asymmetry is the whole point. In the upper model the reference crosses the interface. In the lower model there is nothing in the middle that answers when, so an extra block appears at the receiver whose only job is to produce that answer.

3. What the Receiver Uses Instead

Remove the forwarded clock and the receiver still has to arrive at a sampling instant. It builds one from three ingredients, and it is worth being clear that they arrive at three different times.

A nominal rate, known in advance. Both ends are configured — at design time, or by firmware before traffic starts — to the same nominal bit rate. This is a prior agreement, not a measurement, and it is the only information about the transmitter's timing the receiver gets for free.

An observable event in the signal, once per transmission. Since the agreed rate says how long a bit lasts but not when the first one begins, the transmitter's signalling has to contain something the receiver can detect and align to. That event is what converts a rate into a position. Chapter 2.3 covers how the alignment is established and re-established; here it matters only that such an event must exist, and that it is the transmitter's data signal itself — not a separate wire — that carries it.

Its own local clock, as the measuring stick. Everything the receiver does with the first two happens in cycles of its own clock. This is why the receiver's clock accuracy is part of the link's correctness, and why the phrase "the receiver knows the rate" is loose: it knows a number, which it can only act on as a count of its own cycles.

Two steps in the forwarded model; five inputs assembled locally in the asynchronous one. That difference in length is not incidental complexity — it is the work that used to cross the interface, now done at the receiver.

4. Agreeing a Rate Is Not Being Aligned

This is the distinction most often collapsed, and collapsing it produces a specific and recognisable class of bug. Three separate properties hide behind "both ends are set to the same rate":

Nominal rate agreement. Both configurations name the same number. This is a statement about intent, settled before any traffic, and it is the only one of the three that is actually guaranteed by configuring both ends identically.

Phase relationship. Whether the receiver knows where in time a bit begins. Configuration says nothing about this. Two devices powered up independently have no phase relationship at all, which is exactly why an alignment event has to exist in the signalling.

Actual frequency. What each endpoint's timebase really achieves, as opposed to what it was asked for. Each is derived from a physical oscillator with its own accuracy, and from a local clock that may not divide evenly toward the requested rate in the first place. Neither endpoint measures the other.

So two correctly configured endpoints are running at approximately the same rate, with no phase relationship, and with no mechanism anywhere in the link for either to discover the other's error. Communication works because the alignment event restarts the reckoning often enough that the accumulated difference stays small over the span that matters — and "often enough" and "small enough" are quantities, derived in Module 4, not assumed here.

5. Where the Responsibility Moved

Now the architectural consequence, which is the reason this distinction is worth a chapter.

In a forwarded-clock interface, the burden of answering when sits with the transmitter and with the physical path between the two devices. Getting it right is largely a matter of driving, routing and constraining the two signals so their relationship survives the journey. The receiving logic can be modest: if the reference is trustworthy when it arrives, capturing data against it does not require the receiver to decide anything.

Remove the forwarded clock and that burden does not disappear. It moves, and it changes form — from a physical-path problem at the transmitter into a logic problem at the receiver. The receiver must now detect an event, decide that it was the real thing, establish a position from it, maintain that position across the transmission using its own clock, and judge whether what arrived was well formed.

That is why an asynchronous serial receiver is built from a state machine and counters while a forwarded-clock receiver may need little more than a capture register. The state machine is not incidental to UART. It is the forwarded clock's replacement.

6. What This Changes for RTL, Verification and FPGA Work

For RTL design. The two halves of a UART have genuinely different natures, and this chapter is why. Transmit timing originates in local synchronous logic: the transmitter decides when bits start, so its timing is something it produces. Receive timing is observed: the receiver is reacting to a signal whose timing was fixed elsewhere. Both halves end up converting the local system clock into serial-rate decisions using counters and enables, but they do so for opposite reasons — one to impose a cadence, the other to interpret one. Modules 6 to 8 build all three pieces; what belongs here is knowing that the transmitter's job is well determined and the receiver's job requires judgement.

For verification. A testbench that compares transmitted and received byte values is not verifying this interface. Because the sampling reference is constructed rather than delivered, correctness includes how long each bit was held, what relative error between the two timebases the receiver survives, and whether it aligned to the right event. All three can be wrong while the byte values happen to come out right — and a test that only checks values will pass. Conversely, deliberately imperfect timing is legitimate stimulus here in a way it would not be for an interface that ships its own reference. Modules 14 to 16 build the environment; the point now is that the specification being verified is temporal.

For FPGA work. The scale gap makes this concrete. Fabric typically runs at something like 100 MHz or 125 MHz, while a debug or console link is configured for a serial rate three to four orders of magnitude lower — and the device at the far end, an MCU or a USB-to-serial bridge on the same board, is clocked from a completely separate source. Nothing ties the two together. So the local clock is not the serial rate and has to be turned into one, the incoming signal genuinely originates outside the design and must be treated as an asynchronous input before any decision is taken on it, and bring-up routinely means observing the line directly because the wire is the only place where both endpoints' behaviour is visible at once.

7. Understanding Check

8. Summary

Three different things get called a clock, and the distinction is the chapter. Both endpoints of an asynchronous serial link have local system clocks and are ordinary synchronous designs. What the link lacks is the third one — a forwarded interface clock driven across the interface so the far end is told when the data is valid. “A UART does not forward a clock with the data” is accurate; “UART is clockless” is not, and it points an RTL engineer the wrong way.

A forwarded clock is valuable because it is generated by the same source as the data, so the transmitter fixes their relationship and ships it. That does not make such interfaces easy — setup and hold, skew, jitter and timing closure are all still there — but it does mean the receiver is told when rather than having to work it out.

Without it, the receiver assembles a reference from three ingredients arriving at three different times: a nominal rate agreed in advance, a detectable event in the data signal that turns the rate into a position, and its own clock as the measuring stick. Which is why agreeing a rate is not the same as being aligned: identical configuration guarantees intent, not phase and not actual frequency, and no mechanism in the link lets either end discover the other's error.

The consequence worth carrying forward is that the work of answering when did not disappear when the wire did — it moved to the receiver and became logic. That is why a UART receiver is a state machine and counters rather than a capture register, and it is the single decision from which baud generation, sampling strategy, error detection and receiver architecture all follow.

9. What Comes Next

Chapter 1.3 takes the link apart as two independent directions — what each side drives, the level the line rests at between transmissions, and what full duplex does and does not guarantee. Chapter 1.4 separates the framing this curriculum teaches from the electrical layer that carries it. Then Module 2 answers the question this chapter has been careful to leave open: given two independent timebases and one alignment event per transmission, how much error accumulates, over what span, and why does the arrangement work at all.

Browse the full path on the UART tutorials index. For the receiving end of this problem already built and verified, Case Study — A UART Agent shows a monitor that has to recover bit timing from the signal rather than from a clock — the practical form of everything in §3 and §5. For the same "where does the timing reference come from" question asked about a clocked, source-synchronous interface instead, Read Capture shows what a receiver does when the reference is delivered and still has to be positioned.