A team protects an on-chip bus with parity and a chip-to-chip link with nothing, reasoning that the bus is long and the link is short. In the lab, the bus never shows an error and the link corrupts a word every few minutes. The link was short, but it crossed a connector, ran at 16 Gb/s, and shared a board with a switching power supply. The team protected against the errors they imagined, not the ones the channel produced.
What kinds of errors does a link actually see, and how do you describe them well enough to choose a protection?
The obvious picture of an error is a single flipped bit, now and then, independent of everything else. Some channels behave like that. Many do not: noise arrives in bursts that flip several neighbouring bits; a broken wire flips the same bit every time; a buffer overflow loses a whole message; a retry duplicates one; a multi-path fabric reorders them. A protection designed for single random flips can miss all of these.
Error | What happens | Typical cause | Needs |
|---|---|---|---|
Random bit flip | One bit inverted, independently of others | Thermal noise, jitter at the sampling point | Parity, CRC, ECC |
Burst | Several nearby bits wrong together | Crosstalk, a supply glitch, a lost lock in the receiver | CRC (detects bursts up to its width), interleaved or symbol-based FEC |
Stuck bit | One bit always 0 or always 1 | A broken wire or pin, a manufacturing defect | Codes that detect it plus a recovery such as dropping the lane |
Lost message | A whole packet never arrives | Overflow, a dropped packet after a failed check | Sequence numbers and timeouts |
Duplicated message | The same packet arrives twice | A retry after an acknowledgement was lost | Sequence numbers, idempotency (lesson 10.13) |
Reordered messages | Packets arrive out of order | Multiple paths, adaptive routing | Sequence numbers, reorder buffers |
Soft error in storage | A bit in a memory or register flips while stored | Particle strikes | ECC on memories |
An error model says which of these a channel can produce and how often. Each protection in this part targets a part of the model, and the protocol is only as strong as its weakest uncovered case.
The bit error rate (BER) is the fraction of bits received wrong, measured over a long time. It turns "rarely" into a number that can be budgeted:
Link at 32 Gb/s with BER 1e-12:
bit errors per second = 32e9 x 1e-12 = 0.032 (one every ~31 s)
Same link with BER 1e-15: = 3.2e-5 (one every ~8.7 hours)
A 1 GB/s on-chip bus with BER 1e-20: = 8e-11 (one every ~400 years)Fast serial links have BERs in the range where errors happen every few seconds to hours, so they need error detection and recovery as a matter of routine. Short on-chip wires are usually far better, which is why many on-chip buses have no protection at all, while their memories still need ECC against soft errors.
Link | Errors it plans for |
|---|---|
PCI Express | Random and burst bit errors on each link, handled by a CRC per packet and replay (lesson 10.11); from Gen6, also forward error correction (lesson 10.6). |
Ethernet | Bit errors detected by a CRC-32 per frame; bad frames are dropped and higher layers recover (lesson 10.14); fast links add Reed-Solomon FEC. |
DRAM | Soft errors in stored bits, handled by ECC on the memory interface. |
The opening link (illustrative) had a BER around 1e-13 in the lab: about one error every five minutes at its speed. With no CRC, those errors reached the application as silent data corruption. Adding a CRC and replay, as every high-speed link protocol does, turned each error into an invisible retry costing a few hundred nanoseconds.
10e9 × 1e-12 = 0.01 per second: about once every 100 seconds.
Lost, duplicated and reordered messages: a CRC checks the contents of a packet that arrives, not whether packets are missing or repeated.
Errors include random flips, bursts, stuck bits, soft errors in storage, and lost, duplicated or reordered messages.
The bit error rate turns "rarely" into a rate you can budget: fast links see errors every few seconds to hours.
Write the error model first, then map each error type to a mechanism that handles it and one that reports it.