Speed Improvements

Chapter 4.5 deliberately avoided the figures. Four generations were described by what they changed architecturally, and the rates appeared only in passing.

This chapter addresses them — and the interesting content is not the sequence of numbers. It is what had to change about the encoding for each number to be reachable, because a line code is not free, its cost changed between generations, and the gap between a signalling rate and the payload it can actually carry is exactly where a marketing number and an engineering number part company.

1. Why a Line Code Exists at All

Before the numbers, the mechanism that governs them.

A receiver at these rates has no separate clock line. It must recover its timing from the data itself, which means the data must contain enough transitions to keep it aligned — and arbitrary payload does not. A long run of identical bits offers nothing to align to, and a receiver free-running through it drifts.

A second problem appears as rates rise: a stream with a persistent imbalance between ones and zeros carries a DC component, which AC-coupled receivers and real channels handle badly.

A line code solves both by transforming payload bits into a slightly different set of line bits chosen to guarantee transition density and, in some schemes, balance. The guarantee is the point — and the price is that some of the line rate is now carrying the code rather than the payload.

That price is the whole of this chapter. How it was paid, and how it changed, explains the shape of USB's rate history better than the rates themselves do.

2. Four Rates, Three Codes

Read the third column as the story.

The early generations use NRZI with bit stuffing. Transitions are guaranteed by inserting an extra bit when the data would otherwise run too long without one. Its cost is small and — importantly — variable, because it depends on the payload's content. Data that transitions often costs nothing; data that does not costs a little.

The first SuperSpeed tier uses 8b/10b, a block code carrying 8 payload bits in 10 line bits. Its guarantees are strong and constant, and so is its price: two line bits in every ten are not payload, which is 20% of the line rate spent on coding.

The later tiers use 128b/132b, carrying 128 payload bits in 132. Same purpose, far cheaper: about 3%.

And the highest USB4 tier changes the variable entirely, moving to multi-level signalling rather than a cheaper binary code — §5.

3. The Arithmetic That Matters

Here is why the coding change is more interesting than the rate change.

At 5 Gbit/s with 8b/10b, eight of every ten line bits are payload:

5 Gbit/s  ×  8/10  =  4 Gbit/s of payload  =  500 MB/s

At 10 Gbit/s with 128b/132b, 128 of every 132 line bits are payload:

10 Gbit/s  ×  128/132  ≈  9.7 Gbit/s of payload  ≈  1212 MB/s

The signalling rate doubled. The payload rate did better than double — roughly 2.4 times — because the generation spent the coding overhead as well as raising the clock.

That is the engineering point this chapter exists for. An engineer reading only the headline figures sees 5 and 10 and concludes twice as fast. An engineer who knows the codes sees that a substantial part of the improvement came from no longer wasting a fifth of the line on the code, which is a completely different kind of gain and one that could be had exactly once.

And it explains why the code changed when it did. 8b/10b's 20% was affordable at 5 Gbit/s and became indefensible as rates rose — at higher rates, a fifth of the line is an enormous quantity to spend on transition guarantees, and a cheaper code with comparable guarantees is worth its added complexity.

4. Three Different Numbers

Every one of these gets called speed, and conflating them is the most common quantitative error in USB discussion.

The first two are arithmetic. The third is not, and the gap between the second and third is where most real disappointment lives.

Payload rate is an upper bound, not a prediction. What a program observes is additionally shaped by protocol overhead above the line code, by how the host schedules the bus among devices, by the device's own ability to source or sink data continuously, by the controller's buffering and its path to memory, and by the workload's access pattern.

None of those is a defect. They are the system doing its job. But they mean that quoting a signalling rate as though it were throughput is wrong by construction, and an engineer who does it will mispredict every time.

Module 5 examines what the speed modes do for transfers, and the transfer-type modules examine scheduling. What belongs here is only the discipline: say which number you mean.

5. Lanes, and a Different Lever Entirely

Raising the rate and cheapening the code are two levers. USB has used two more.

Lanes. Operating more than one differential path in parallel multiplies capability without requiring any one path to run faster. A later USB 3.x tier reaches 20 Gbit/s this way — two lanes at 10 — and USB4 builds on lane operation as well. The attraction is that it reuses a proven per-lane design; the cost is conductors, connector resources, and the requirement that the cable and both ports actually provide them, which is one more way for Chapter 4.7's effective capability to fall short of a label.

Multi-level signalling. The highest USB4 tier moves away from binary signalling to PAM-3, where each symbol carries more than one bit's worth of information by taking one of three levels rather than two. This raises the bits carried per symbol without raising the symbol rate proportionally — which matters because Chapter 3.8 §1's constraints bite on edge rate, and a scheme that extracts more from each symbol relieves pressure on the channel rather than adding to it.

The trade is margin. Three levels in the same voltage range means the gaps between them are smaller, so the receiver has less room — which is exactly Chapter 3.8's observation that a small swing is affordable only when the channel is good. Multi-level signalling is a deal: more bits per symbol in exchange for a channel that must be better.

Four levers, then, and only the first is what people mean by faster: raise the signalling rate; make the code cheaper; use more lanes; carry more per symbol. A generation typically pulls several at once, which is another reason a single headline number explains so little.

6. What This Means for Silicon and Verification

For silicon, each lever lands differently. A higher signalling rate stresses the PHY and forces wider internal datapaths to keep up at a manageable clock. A different line code is an encoder and decoder — genuinely new logic, not a faster version of the old, since 8b/10b and 128b/132b are unrelated mechanisms. Lanes multiply per-lane logic and add the problem of keeping lanes aligned with one another. Multi-level signalling is almost entirely an analogue burden, with a receiver that must resolve more levels in the same range.

A multi-generation controller therefore contains multiple, unrelated coding paths, which is another instance of Chapter 4.5 §3's observation that implementations grow in kinds. An 8b/10b path does not become a 128b/132b path by parameterisation; they are different designs that coexist.

For verification, coding creates a specific and valuable target because it is a pure transformation. A reference model is straightforward — encode a payload stream, compare against the observed line stream, or decode an observed stream and compare against expected payload — and when a reference model is that simple and the design still disagrees, the fault is nearly always in the plumbing rather than the algorithm.

The cases worth constructing are the ones that stress the code's guarantees rather than its typical behaviour: payloads chosen to be worst-case for transition density, payloads that would be unbalanced without the code's intervention, the boundaries where a block code's framing must align, and — for the earlier generations — data patterns that force the maximum amount of bit stuffing, since that path is the variable-cost one and therefore the one whose timing assumptions are easiest to get wrong.

7. Common Misconceptions

8. Reason It Through

A team is choosing between two ways of increasing a link's payload capability: raise the signalling rate by 25%, or replace a code costing 20% of the line with one costing 3%.

What does each deliver? Raising the rate by 25% delivers 25% more payload, since the code's efficiency is unchanged. Replacing the code delivers about 21% more payload at the same signalling rate — from 0.80 of the line to about 0.97, a ratio of roughly 1.21.

So they are nearly equivalent in payload. Are they equivalent in cost? Not remotely. Raising the signalling rate stresses the channel — faster edges, less margin, tighter requirements on cables and connectors, and per Chapter 3.8 more radiation, reflection and crosstalk. Replacing the code costs logic: a new encoder and decoder, verified once, running at the existing rate on the existing channel.

Which is the better engineering choice? Usually the code, where the option exists — it converts a channel problem into a logic problem, and logic is cheaper, more predictable and improves with process while channels do not.

Why can this lever only be pulled once? Because efficiency is bounded above by 1. Going from 0.80 to 0.97 recovers most of what was available; there is no third step of comparable size. After that, further gains must come from rate, lanes or symbol density — the harder levers.

What is the general lesson? Ask what fraction of a resource is being spent on overhead before asking for more of the resource. A 20% overhead is a 20% headroom opportunity that costs no channel quality at all, and it is routinely invisible because overhead is usually presented as a fixed property rather than a design choice.

9. Understanding Check

10. Summary

The rates are the least interesting part of the rate story. What made each reachable was a change in what the line was being asked to carry.

A line code exists because the receiver recovers timing from the data and needs guaranteed transitions, and because high rates tolerate a DC component badly. Its price is that part of the line rate carries the code. USB has used NRZI with bit stuffing (small, variable cost), 8b/10b (20% of the line), and 128b/132b (about 3%).

That makes the arithmetic the point. 5 Gbit/s × 8/10 = 4 Gbit/s ≈ 500 MB/s; 10 Gbit/s × 128/132 ≈ 9.7 Gbit/s ≈ 1212 MB/s. The signalling rate doubled and the payload rate rose about 2.4 times, because the generation also stopped wasting a fifth of the line — a gain available exactly once, since efficiency is bounded above by 1.

Three numbers get called speed. Signalling rate is a specification fact; payload rate is derivable; application throughput is nobody's fact, being shaped by protocol overhead, scheduling, device capability, buffering and workload. Quoting the first as the third is wrong by construction.

Four levers, not one: raise the rate, cheapen the code, add lanes, carry more per symbol. Only the first is what people mean by faster, and PAM-3 is a trade rather than an improvement — more bits per symbol in exchange for less receiver margin, affordable only on a good channel.

For silicon this means multiple unrelated coding paths coexisting; for verification, a pure transformation with an easy reference model whose valuable stimulus stresses the code's guarantees rather than typical data.

11. What Comes Next

This module has now described four generations, the pattern connecting them, and the rate and coding story underneath. One question has been deferred at every step and referenced repeatedly: when a host, a device, a cable and a port each have their own capability, what actually happens?

Chapter 4.7 answers it, and it is the chapter that makes the rest of the module usable. It takes apart the phrase this module has been careful never to use loosely — backward compatible — and shows that it means different things at the electrical, protocol and software layers, that Chapter 4.2's fallback and Chapter 4.3's coexistence are genuinely different mechanisms, and that effective capability is an intersection rather than a property of any single participant. It also builds the model in hardware, with the assertion that catches a component claiming a capability it cannot deliver.

Browse the full path on the USB tutorials index.