USB4 Architecture

Three generations have answered the same question three ways. Generation two negotiated on a shared medium. Generation three added a medium and kept both. Through all of it, one assumption held without ever being stated: the thing being carried was USB.

This chapter is where that assumption goes.

USB4's change is not another increment of the same kind. The link stops being a USB-only link and becomes a transport that carries other protocols as well as USB — which is a change in what the architecture is for, not merely in what it can do.

1. A Change in Kind

Set the three transitions side by side and the difference is visible.

Generation two asked: can this medium carry more? It answered by adding an arrangement to the same conductors.

Generation three asked: can we add a medium? It answered with additional pairs carrying a new architecture, coexisting with the old.

USB4 asks a different question entirely: what if the link carried things that are not USB?

The motivation is a real and recognisable system pressure. A single cable to a display, a dock or an external enclosure was being asked to carry several kinds of traffic at once — display data, storage, peripheral traffic, sometimes a device that wants to appear on the machine's internal expansion bus. Solving that by defining a USB device class for each would have been the wrong shape of answer: display traffic and expansion-bus traffic already have their own mature protocols, and re-expressing them as USB would discard those ecosystems.

So the answer was to make the link a carrier. USB4 is built on a high-speed link specification contributed to USB-IF by Intel from Thunderbolt 3, and over that link it tunnels other protocols — USB 3.x traffic among them, alongside display traffic and optionally the machine's expansion-bus protocol — with available bandwidth allocated among them dynamically rather than by a fixed split.

2. Why the Connector Became a Requirement

USB4 is the first generation to require a specific connector: USB-C. Every earlier generation was connector-agnostic in the sense that mattered — Chapter 4.2 added a rate to existing conductors, and Chapter 4.3 added conductors that were provided through several connector types.

The reason is not branding, and understanding it is a good test of whether §1 landed.

A carrier link multiplexing several protocols needs more than a set of wires. It needs enough conductors for the lanes; it needs a configuration mechanism by which the two ends establish what is attached, which direction things face and what the cable can support; and because a cable may be reversible and may itself be an active component, the arrangement has to be discoverable rather than assumed. USB-C provides those. Earlier connectors do not, and could not be retrofitted to.

Note carefully what this does and does not imply. USB4 requires USB-C. USB-C does not imply USB4 — or USB 3.x, or any particular capability at all. A USB-C port may be a USB 2.0 port and nothing more. The implication runs in one direction only, and reading it backwards is the single most expensive USB misconception in practice, because it leads people to infer capability from the shape of a socket.

And the same caution applies to power. USB-C is associated with higher power delivery, but power capability is not a protocol generation property. A port's data capability and its power capability are separate facts that happen to be carried by the same connector. Module 19 owns power; this chapter's only claim is that inferring one from the other is unsound.

3. The Oldest Transport Survives Again

One detail in Figure 1 deserves its own attention, because it completes a pattern this module has been tracking.

The USB 2.0 pair still runs on its own wires, outside the tunnelling arrangement entirely. It is not tunnelled. It is not emulated. It is physically present and carries the same architecture it always did.

Count the transitions: generation two added a rate and kept the older ones; generation three added conductors and kept the older pair; USB4 added a tunnelling architecture and kept the older pair again. Nothing has ever been removed. Chapter 4.5 makes this the centre of its argument, and Chapter 4.7 works out what it costs.

For now the observation is simply that the oldest transport in the architecture has survived every generation by continuing to exist alongside whatever was added — and that a modern high-speed link still has a pair of wires carrying a decades-old arrangement is not an oversight but the mechanism by which the installed base stays valid.

4. What Tunnelling Costs an Implementation

Measured against Chapter 4.3's already-doubled controller, this generation adds categories rather than quantities.

An allocator. Something must decide how bandwidth is shared among the tunnelled protocols, and it must do so dynamically. That is a scheduling problem of a kind earlier USB did not have — earlier scheduling allocated bus time among devices on one protocol; this allocates link capacity among protocols.

Protocol adaptation on both ends. Each tunnelled protocol must be carried and delivered such that the endpoints see something they recognise. The USB stack above must still behave like USB even though it is not on a USB link.

A much larger interoperability surface. The implementation now interacts with display and expansion-bus ecosystems as well as USB's. Problems can originate in a protocol the USB engineer does not own, and — as §6 develops — can present as USB problems.

Composite failure modes. Bandwidth is shared, so one tunnelled protocol's demand can affect another's service. A symptom in one may have its cause in another, which is a class of failure earlier generations could not produce.

And the ecosystem cost compounds. Cables become active participants, ports become more capable and more varied, and the number of combinations a product can be plugged into grows substantially.

5. What It Costs Verification

The configuration space gains a dimension that is qualitatively new.

Chapter 4.2 added a mode dimension. Chapter 4.3 added a path dimension. USB4 adds a concurrent-tenant dimension: what else is using the link while the case under test runs.

That is different from the previous two because it is not a property of the connection being tested. A USB transfer's behaviour can now depend on what a display is doing on the same link, which means a test that is deterministic in isolation may not be in context.

The cases worth constructing:

• USB traffic alone on the link, and USB traffic alongside another tunnelled protocol under load
• bandwidth contention, including a tenant whose demand changes during a USB transfer
• a USB4-capable device attached to a port that provides only an earlier capability, which must produce a working connection at that capability
• the USB 2.0 path exercised while the tunnelled path is active — the coexistence of §3
• cables and ports of differing capability, since the interconnect is now a more capable and more variable participant

And a verification-strategy observation worth taking seriously. When a link carries protocols your team does not own, a USB-only environment cannot reproduce a whole class of real behaviour. That is not a gap to be closed by more USB tests; it is a reason for system-level and interoperability testing to carry weight that unit-level verification cannot.

6. Debugging When USB Is a Tenant

§4's composite failure modes deserve a concrete method, because they defeat the reflexes earlier chapters built.

A USB symptom may have a non-USB cause. If a USB transfer underperforms while a display is driving heavy traffic on the same link, nothing in the USB stack is broken. The allocator is doing its job and USB's share is what it is. Investigating the USB controller here will find nothing, correctly.

So the first question changes. Earlier modules asked which layer failed? Here the prior question is: was this connection alone on the link? If not, the behaviour may be a sharing outcome rather than a fault, and that must be established before layer-by-layer investigation is worth starting.

The layer discipline still applies below that. Once the connection is known to be alone, or the sharing accounted for, Chapter 3.8 §4's instrument reasoning and the module's earlier debugging chains work unchanged.

And observability is genuinely harder. A protocol analyser watching USB sees USB. It does not see what a display was doing on the same link, so the evidence that would explain the symptom may be outside the instrument's view entirely — which is a stronger version of Chapter 3.8's point that no instrument sees another's abstraction.

7. Common Misconceptions

8. Reason It Through

A USB storage device performs well when it is the only thing attached. Through a dock that is also driving a high-resolution display, its throughput drops substantially. No errors are reported anywhere and the device is never disconnected.

Is this a fault? Probably not. It is the shape of a sharing outcome: performance degrades, correctness does not, and nothing errors because nothing is wrong. §4's allocator is apportioning a shared capacity among tenants, and the storage device is receiving its share.

What distinguishes this from a genuine fault? A fault degrades correctness or produces errors; sharing degrades throughput while everything remains correct. And a sharing outcome will track the other tenant's demand — reduce the display's requirements and the storage throughput should recover, which is a cheap and decisive experiment.

Why would investigating the USB controller be wasted effort? Because it is behaving correctly. Its transfers complete, its error counters are clean, and its share of the link is being delivered. Every USB-level observation will say healthy, which is accurate and unhelpful.

What if reducing the display's demand does not recover the throughput? Then the sharing hypothesis is falsified and the ordinary layered investigation applies — and it now has a much narrower target, because the most likely explanation has been eliminated for the cost of one experiment.

What is the general lesson? When a resource is shared, "slow" is not automatically "broken", and the diagnostic question shifts from which layer failed to was this measurement taken in isolation. That question costs one experiment and eliminates an entire class of investigation, which makes it the right first move rather than a fallback.

9. Understanding Check

10. Summary

USB4 is a change in kind. Earlier generations asked how much USB could carry; USB4 asks what the link can carry, of which USB is one thing. Built on a high-speed link contributed to USB-IF from Thunderbolt 3, it tunnels several protocols at once — USB 3.x traffic, display traffic, optionally the machine's expansion bus — with bandwidth allocated dynamically among them. USB becomes a tenant on a link it no longer owns, and every consequence follows from that inversion.

It is the first generation to require a specific connector, because a carrier link needs conductors for its lanes and a configuration mechanism to discover what is attached and what the cable supports. USB4 requires USB-C; USB-C implies nothing — a USB-C port may be USB 2.0 and nothing more, and power capability is a separate fact again.

The USB 2.0 pair survives once more, on its own wires, outside the tunnelling arrangement. Three consecutive generations have added without removing.

Implementation gains categories rather than quantities: an allocator, protocol adaptation at both ends, a much larger interoperability surface, and composite failure modes where one tenant's demand affects another's service. Verification gains a concurrent-tenant dimension that is not a property of the connection under test — so a USB-only environment structurally cannot reproduce a class of real behaviour, which is a reason for system-level testing to carry weight rather than a gap to close with more USB tests.

And the debugging consequence: when a resource is shared, slow is not automatically broken. The first question becomes whether the measurement was taken in isolation, and it costs one experiment to eliminate an entire class of investigation.

11. What Comes Next

Four generations are now on the table, and they answered the same question four different ways — a new arrangement on shared wires, additional wires carrying a coexisting architecture, and a carrier link on which USB is one passenger.

Chapter 4.5 stops describing them individually and asks what the sequence shows. There is a pattern, and it is sharp enough to be predictive: every generation added at the bottom and removed nothing, while the layers software depends on were never touched. That is worth stating precisely, because it explains both why the architecture survived and what each survival cost — and it leads directly to the question of what a controller supporting several generations must keep separate, which is where this module finally gets to write some hardware.

Browse the full path on the USB tutorials index.