A new serial link passes every test with random data. Then a customer streams a large file that happens to contain long stretches of zero bytes, and the link starts reporting errors in exactly those stretches. Nothing is wrong with the zeros themselves. The receiver had lost track of where the bits were.

How does a receiver find bit timing with no clock wire at gigabit rates, and why can a long run of identical bits defeat it?

The obvious answer, and why it breaks

Two earlier answers both fail at these rates. A forwarded strobe (lesson 1.3) needs the strobe and data wires matched to a small fraction of a bit, which becomes impossible across connectors and cables when a bit lasts tens of picoseconds. Asynchronous framing (lesson 1.2) resynchronises only once per frame and relies on the clocks matching to a few percent over ten bits. At gigabit rates you want long frames, thousands of bits, between timing references. Neither scheme can do that.

The idea: the clock is hidden in the transitions

Every time the data changes from 0 to 1 or 1 to 0, the edge marks a bit boundary. A clock and data recovery (CDR) circuit watches those edges and continually adjusts the phase of its own sampling clock so its samples land in the middle of each bit. Between edges it coasts on its own clock, which differs from the transmitter's by a small frequency offset measured in parts per million (ppm). So the sampling point drifts by that offset, a fraction of a bit per bit, until the next edge pulls it back.

The figure shows the loop. The phase detector compares data edges with the recovered clock and says "early" or "late"; the loop filter smooths those votes; the oscillator or phase interpolator moves the sampling clock; the sampler uses it.

How far can the receiver coast?

Measure timing in unit intervals (UI), one bit time each. With a frequency offset of p ppm, the sampling point moves p × 10⁻⁶ UI per bit. A sample is wrong once it has moved half a bit from the centre. So the longest run of bits with no transition the receiver can survive is about:

This is the best case. It assumes the loop snaps back to the centre at every edge and that nothing else moves the sampling point. Real loops correct gradually, and jitter and noise take their share of the half bit, so real limits are much tighter.

Build it: drift between transitions

The model drifts an ideal receiver's sampling point by the frequency offset on every bit of a run with no transitions, and finds the longest run that stays within half a bit, for three offsets.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

"""Why a serial link needs transitions.

The receiver recovers the clock from data transitions. Between transitions its
sampling point drifts by the frequency offset between the two clocks, a few parts
per million (ppm) of a bit per bit. Here an ideal recovery circuit snaps back to
the bit centre at every transition. A sample is wrong once the drift exceeds half
a bit (0.5 UI), so the longest safe run of identical bits is about 0.5 / offset.
"""


def survives(run_length, ppm):
    drift_per_bit = ppm * 1e-6           # in UI (fractions of a bit)
    phase = 0.0                          # offset from the bit centre, in UI
    for _ in range(run_length):          # a run of identical bits: no transitions
        phase += drift_per_bit
        if phase > 0.5:
            return False
    return True


print("offset   longest safe run of identical bits")
for ppm in (100, 300, 600):
    limit = int(0.5 / (ppm * 1e-6))
    assert survives(limit, ppm) and not survives(limit + 1, ppm)
    print(f"{ppm:4d} ppm  {limit:6d} bits")
print("an 8b/10b stream never has more than 5 identical bits in a row")
print("PASS: the safe run length is 0.5 UI divided by the offset per bit")

It prints:

offset   longest safe run of identical bits
 100 ppm    5000 bits
 300 ppm    1666 bits
 600 ppm     833 bits
an 8b/10b stream never has more than 5 identical bits in a row
PASS: the safe run length is 0.5 UI divided by the offset per bit

Even in this generous model, a run of a few thousand identical bits is enough to lose a 100 ppm receiver, and a file full of zero bytes contains runs far longer than that. Real receivers need transitions far more often than the model's limit, which is why serial protocols do not leave transition density to chance. 8b/10b encoding, for example, never allows more than five identical bits in a row, hundreds of times inside the limit.

The protocol's job: guarantee transitions

A CDR turns "when is the data valid?" into a promise the protocol must keep: there will be transitions often enough. Protocols keep it in three ways, each covered in Part 2:

The design space

How real protocols chose

What breaks

The opening failure (illustrative): the link scrambled its data, but a configuration bug disabled the scrambler in one direction. Random test data has plenty of transitions, so every test passed. Real files with long zero runs then produced runs of thousands of identical bits, the CDR drifted off the bit centres, and errors appeared exactly in those stretches.

• Symptom: errors that depend on the content of the data, not its rate.

• Evidence: the error positions line up with long runs of identical bits on the wire.

• Root cause: the mechanism that guarantees transitions was off; the CDR had nothing to lock to.

• Fix: enable scrambling, and add a test with worst-case data patterns (all zeros, all ones, long runs) to the regression. Random data is the kindest data a link will ever see.

Key takeaways

• Embedded-clock links recover timing from data transitions with a CDR loop and coast between them.

• Coasting drifts by the frequency offset; the ideal limit is about 0.5 UI divided by the offset per bit, and real limits are far tighter.

• So every serial protocol must guarantee transitions, with bit stuffing, block codes or scrambling plus a header.

Related topics

• Part 1 overview: Timing and Clocking

• Part 2: Encoding and Framing