SuperSpeed+ and Beyond

Chapter 5.4 established SuperSpeed as a mode with its own conductors, and with it the idea that mode is a per-path property. What it did not address is what happens above it.

The tiers above SuperSpeed are not new architectures. They are the same architectural family scaled — and scaling within a family turns out to be a different kind of problem from adding a family, with its own costs and its own characteristic confusions.

This is also the module's closing chapter, so it is where the verification thread reaches its conclusion.

1. Two Axes, Not One

The first thing to fix is that a tier in this family is not a single number. It is determined by two independent choices.

Rate per lane. The signalling rate one differential path carries. The family's entry tier is 5 Gbit/s per lane; the next step is 10 Gbit/s per lane, which Chapter 4.6 §3 showed was reachable partly by raising the rate and partly by replacing a line code costing 20% of the line with one costing about 3%.

Lane count. How many such paths operate together. One lane, or two operating in parallel — which multiplies capability without requiring any individual lane to run faster.

The combination gives the tier. Two lanes at 10 Gbit/s each is a 20 Gbit/s tier; USB4 builds on the same idea and reaches 40 Gbit/s, with a later revision going higher still by the multi-level signalling Chapter 4.6 §5 described.

2. Why Two Axes Rather Than One

The obvious question: why not simply keep raising the per-lane rate?

Because the two axes hit different walls. Chapter 3.8 §1 established that rate pressure lands on edge rate — radiation, reflection, crosstalk, and shrinking margin, all demanding a better channel. Doubling a lane's rate makes every physical requirement harder, and beyond some point the channel becomes impractical or uneconomic.

Lanes buy capability without that pressure. A second lane runs at a rate already proven, over a channel already specified. The per-lane engineering is unchanged.

But lanes are not free either. They need conductors through connectors, cables and boards, which is a physical-ecosystem cost. And they need the lanes to be aligned with one another, because data split across paths must be recombined in the right order — a problem a single lane does not have at all.

So the axes are complementary rather than alternative, and a family scales by pulling whichever is cheaper at the time. That is a general pattern in high-rate interfaces and not a USB peculiarity.

3. The Naming

Chapter 4.3 §4 covered why this family's naming is confusing; the operational consequence belongs here, where the tiers are the subject.

The situation, structurally: capability tiers were added over successive specification revisions, earlier tiers were renamed retroactively, and consumer-facing branding has changed direction more than once — most recently toward naming things by rate. The result is that one capability has carried several names, and some names have meant different things at different times.

The practical rule for an engineer:

Ask for the rate per lane and the lane count. Those two numbers are unambiguous and they determine the tier. A name may or may not.

That reduces a naming problem to a measurement problem, which is the right move whenever labels are unreliable — and it is exactly the discipline Chapter 4.7 applied to capability generally.

And the module's standing caution applies. A tier a participant supports is not a tier a connection runs. Every figure in §1 is a capability; what a given link does is the intersection of host, device and interconnect, observed rather than assumed.

4. What Scaling Costs an Implementation

Measured against Chapter 5.4's single-tier SuperSpeed, each added tier contributes cost in a specific shape.

A PHY capable of more than one rate, with the mechanism to operate at whichever was established — which is Chapter 5.3's multi-arrangement problem appearing again one family up.

Lane management, if lanes are supported. Distributing data across lanes, recombining it in order, and handling the case where fewer lanes are usable than the design supports. That last case is not exotic: a cable or port providing one lane where two were hoped for is ordinary.

More capability state. Chapter 5.4 §3's per-path mode becomes per-path and per-tier, and where lanes vary, the lane count is part of the operating state too.

And a line code that is not the same at every tier. Chapter 4.6 established that the entry tier and the tier above it use different codes, so an implementation spanning both contains two unrelated coding paths — not one parameterised path, because the codes are different mechanisms.

The shape is familiar. As in Chapter 4.5 §3, the growth is in kinds rather than sizes, and none of it retires.

5. The State Space, and Where the Module Lands

This is the conclusion of the module's verification thread.

Count the dimensions this curriculum has accumulated, each contributed by a chapter and none of them retiring:

• operating mode — Low, Full, High, and the SuperSpeed family (5.1–5.4)
• path — classic and SuperSpeed, independently active (5.4 §3)
• tier and lane count within the SuperSpeed family (§1)
• requested versus established, for each path (5.3 §2)
• topology — a hub is a participant in the intersection (4.7 §3)
• reset, attach order and churn (4.5 §7)

They cross rather than add, and the product is large enough that exhaustive coverage is not the goal. What is achievable — and what this module has been building toward — is a small set of disciplines that make the space navigable:

Observe, do not assume. Every mode, tier and lane count used for checking must be the established value, read from the design's own reporting. Chapter 5.4 §9's passing test that never exercised SuperSpeed is what assuming costs.

Cross the dimensions that interact, not all of them. Requested × established is productive because the off-diagonal cells are where conflation bugs live. Mode × line-state interpretation is productive because Chapter 3.4's defect lives outside a single-mode space. Mode × topology is productive because a hub bounds the intersection.

Test the refusals. Every envelope has restrictions — Chapter 5.1's forbidden transfer types, Chapter 5.3's unsupported modes, a tier a participant does not support — and refusal paths are the least-exercised logic in any implementation because they run only when something is wrong.

And exercise churn. Attach, detach, re-attach at a different capability, reset mid-operation, force a fallback. That is where the mode-state and stale-state failures live, and an environment naturally tends to reach a working configuration and stay there.

6. Common Misconceptions

7. Reason It Through

A device and host both claim a two-lane tier. Measured capability is about half the expected aggregate. No errors are reported, and the connection is stable.

What does “about half” suggest? That one axis delivered and the other did not. Half the aggregate of a two-lane tier is consistent with one lane operating at the expected per-lane rate — which is a working connection at a lower tier, not a degraded one.

What is the alternative explanation, and how would you separate them? Two lanes running at half the per-lane rate would give the same aggregate. The two are distinguished by asking for the established rate-per-lane and lane count separately — which is §3's rule doing diagnostic work, and why an aggregate figure is a poor thing to reason from.

Why are no errors reported? Because nothing is wrong. Both endpoints claiming a tier is a claim about capability; what runs is the intersection, and if the interconnect provides one lane the system correctly operates one lane. Chapter 4.3 §8's graceful-and-silent degradation once more.

Which participant is the likely constraint? The interconnect, because it is the participant neither endpoint's claim covers and the one most likely to vary — a cable that carries one lane, or a port that routes one.

What would settle it in one experiment? Substitute a known-good cable, exactly as in Chapter 4.3 §8. If capability doubles, the interconnect was the bound and both endpoints are vindicated.

The general lesson. An aggregate figure hides which axis fell short. When capability is a product of independent factors, diagnose by asking for the factors, never the product — a discipline that applies far beyond USB.

8. Understanding Check

9. Summary

A tier in this family is a pair of numbers: rate per lane and lane count. The entry tier is 5 Gbit/s on one lane; the next step is 10 Gbit/s on one lane, reachable partly by rate and partly by replacing an expensive line code; two lanes at 10 Gbit/s give a 20 Gbit/s tier, and USB4 reaches 40 Gbit/s with a later revision going beyond.

The axes are complementary because they hit different walls — rate pressure lands on edge rate and demands a better channel, while lanes demand conductors and lane-to-lane alignment. An aggregate figure is a product, and it hides which axis a participant actually satisfies.

The naming has been revised retroactively and rebranded more than once, so the operational rule is to ask for rate per lane and lane count rather than for a name — reducing a naming problem to a measurement problem.

Scaling costs an implementation a multi-rate PHY, lane management including the ordinary case of fewer usable lanes than supported, more capability state now per-path and per-tier, and two unrelated coding paths because the tiers do not share a line code. As throughout, the growth is in kinds and none of it retires.

And the module's verification conclusion: the accumulated dimensions cross and never retire, so the goal is discipline rather than exhaustiveness — observe rather than assume, cross only the dimensions that interact, test the refusals, and exercise churn.

10. What Comes Next

Module 5 is complete. You can now say what it means to operate in a given mode: an envelope bundling rate, electrical requirements, permitted transfer types and limits; supported, requested and active as three distinct things with only the last fit to qualify behaviour; mode as a per-path property once a mode owns its own conductors; and tiers as two independent axes whose product should never be reasoned from directly.

The link is now up. It has a known mode on each path, at a known tier, established and observed.

And the host still does not know what is attached to it.

Module 6 takes enumeration — the procedure by which a host, having established a working link to something, discovers what that something is, gives it an address, reads its self-description, and configures it for use. Chapter 4.1 identified that framework as the commitment USB never rebuilt across four generations; Module 6 is where you finally see it work.

Everything in Modules 3 to 5 was about making a wire carry bits reliably. Everything from Module 6 onward is about what those bits are for.

Browse the full path on the USB tutorials index.