The Universal-Connectivity Vision

Chapter 1.6 put six architectural decisions on the table and priced each one. What it did not do is make them look like a single idea. Read as a list, they are six separate commitments a specification happens to make. There is a way of seeing them as one, and that way of seeing is the actual invention this chapter is about.

Start by discarding the description you have almost certainly heard. The goal was never one connector for everything. Chapter 1.2's §8 already disposed of that: unify the plug while the layers beneath stay unlike and you have produced packaging, not architecture — and you have thrown away the physical type-check that previously stopped people connecting incompatible things.

The real goal is harder to state and much more interesting:

One extensible architecture capable of representing device classes that do not exist yet, without redesigning the host's attachment mechanism for each one.

Take that sentence seriously and it contains a demand that sounds impossible. The architecture must accommodate devices whose requirements nobody can know, using mechanisms fixed in advance. This chapter is about how that is done.

1. The Trick — Layers That Vary Independently

A design can only accommodate the unknown by refusing to let the unknown reach most of itself.

The mechanism is layering, but not layering in the weak sense of "things drawn stacked in a diagram." Layering in the strong sense: each layer owns a defined question, communicates with its neighbours through a defined interface, and is structurally prevented from depending on the answers other layers give. When that holds, a change confined to one layer cannot propagate — and the architecture accommodates something new by changing one layer while the rest stands still.

This is why Chapter 1.6's six decisions are one idea. Every one of them is a decision about which layer owns what, and the reason they interlock is that they are cuts through the same structure.

2. What Each Layer Owns — and What It Must Not Know

The discipline is in the second half of each of these.

Physical attachment owns the connector, the cable and the electrical signalling — how a bit becomes a voltage and back. It must not know what kind of device is attached. A keyboard and a storage device present identically here, and that is the point.

Transport owns moving data: addressable paths into and out of a device, the service model each path requires, and the host's scheduling of the shared bus. It must not know what the data means. It knows this path wants steady delivery and that one wants throughput; it does not know one carries audio and the other a filesystem.

Device model and identity owns what the device is: its address on the bus, its machine-readable self-description, and the configuration selected from what that description offers. It must not know what the device is for in any application sense, and it must not depend on how fast the transport beneath it runs.

Function owns what the device does, expressed as membership of a standard class with defined behaviour. It must not know how its data physically travels. Notice this layer is where device diversity is permitted to live — the architecture concentrates variety here deliberately, so it stays out of everything below.

Software-visible behaviour owns how the operating system presents the device and which driver binds to it — generically where the declared class allows, specifically where it does not. It must not know the electrical or transport details beneath.

3. Why Independence Is the Whole Point

Abstract layering claims are cheap. Test this one against the three kinds of change an architecture actually has to survive.

A device class nobody anticipated. Someone invents a peripheral category that did not exist when the specification was written. What has to change? A function definition — a description of what this class of device does and how its data is organised — and software that understands it. The physical layer does not change. The transport does not change. The identity mechanism does not change, because it was designed to carry a class declaration without caring which class. The host's attachment machinery is untouched, and an existing host can enumerate, configure and power the device even if it has no idea what it is.

That is the demand from the opening of this chapter, met. The architecture accommodates the unknown because the unknown is confined to the layer built to hold it.

A faster transport. Demand grows and a new signalling rate is needed. What changes? The physical and transport layers. The device model does not — a device still describes itself the same way, still receives an address, still declares its classes. So a new-generation device and an old-generation host can still meet, and the enormous body of existing device-model knowledge, software and tooling survives. Chapter 1.8 is entirely about this case.

A new connector. A smaller or reversible plug is wanted. What changes? The physical layer, and only it. Everything above is untouched — which is exactly why a connector change is not a new architecture, and why treating the connector as the architecture gets the relationship backwards.

Three quite different pressures, three changes confined to different layers. That confinement is the vision. Not a universal plug: a structure in which the inevitable changes do not propagate.

4. The Cast, Placed in the Model

You have met these names in passing. Here they are as positions in the structure — which is all this chapter claims about them.

The host sits above the transport layer as the owner of scheduling, because Chapter 1.6's first decision put it there. A device presents an identity and one or more functions. A hub is a device whose own function is to provide more attachment points, which is why it fits the model rather than sitting outside it — a genuinely elegant consequence of the layering, since the expansion mechanism is itself just another participant.

Enumeration is the procedure that runs at the identity layer when attachment is detected: it gives the device an address and reads its self-description. Descriptors are that self-description — the data format identity is expressed in. Endpoints are the addressable data paths at the transport layer, and transfer types are the service models those paths declare. Device classes live at the function layer and are what lets a driver be generic.

Each of those has a module. Chapter 2 builds the host, devices and hubs; Module 6 owns enumeration; Module 7 owns descriptors; Module 9 owns endpoints; Module 10 owns transfer types. Nothing here should be read as teaching them — the only claim being made is where each one lives, because knowing the layer tells you what a mechanism is allowed to depend on, which is the single most useful thing to hold before studying it.

5. Where the Separation Leaks

A chapter that presented the layering as perfect would be teaching a diagram rather than an architecture. Real layer separations leak, and knowing where is part of knowing the model.

The transport layer is not fully invisible to function. A device class whose data is genuinely time-sensitive needs a service model that guarantees delivery rate, so the function layer must at least know which service models exist. The separation is that it declares a requirement rather than a mechanism — but it is not complete ignorance.

Generations are visible above the physical layer. A device capable of a newer signalling mode must behave correctly when attached to a host that supports only an older one, which means the identity layer carries generation-dependent information. Chapter 1.8 shows how this was managed, and it is the clearest example of a leak the architecture had to accept.

Power crosses several layers at once. It is physically supplied at the attachment layer, requested in the self-description at the identity layer, granted during configuration, and enforced by hubs. It is genuinely a cross-cutting concern rather than a layer's private business.

Some classes need vendor software anyway. The function layer permits a device to declare a standard class, and permits it not to.

None of this invalidates the model. It means the model is a design intent that is mostly honoured, and the places it is not are where the specification's complexity concentrates — which is a good predictor of where bugs and interoperability problems live.

6. What This Gives Silicon and Verification

The layering is not only an explanatory device. It shapes how USB hardware is built and verified, and the correspondence is unusually direct.

Hardware partitions along the layers. A PHY implements the physical layer; protocol logic implements transport; endpoint buffering sits at the transport boundary; and identity and function behaviour frequently live in firmware on a small processor rather than in gates. That partition is a design decision every USB device team makes, and the layering is what makes it a decision with clean cut points rather than an arbitrary split.

The hardware/firmware boundary follows from layer rates of change. Transport behaviour is fixed by the specification and performance-critical, so it belongs in hardware. Identity and function behaviour is device-specific and changes with the product, so firmware is the natural home — a descriptor set is data a team edits, not a block they re-synthesise. Getting this boundary wrong in either direction is a recognisable design mistake: transport logic in firmware misses timing, and descriptors in gates make every product change a silicon change.

Verification decomposes the same way. A protocol checker verifies transport-layer invariants without knowing the device class. A class-level testbench verifies function behaviour without re-verifying transport. Endpoint-level abstractions let a stimulus generator talk in terms of data paths rather than signalling. This is why USB verification environments are layered in a way that Chapter 1.4's and 1.5's bespoke interfaces could never be — those had nothing above them to appeal to, so every check was implementation-specific.

Reuse tracks the layers too. A device controller is reusable across products precisely because it implements the layers that do not vary per product. The parts that vary — descriptors, class behaviour — were deliberately placed where varying is cheap.

7. Common Misconceptions

8. Reason It Through

A new category of peripheral is invented — one whose requirements nobody anticipated when the specification was written. It must work with hosts that already exist.

What must change? A definition of what this class of device does and how its data is organised, plus software that understands it. That is the function layer and the software above it.

What must not change, and why can it not? The physical layer, because the connector and signalling were never told what kind of device they carry. The transport layer, because it moves declared service models without knowing what the data means. The identity layer, because it was built to carry a class declaration without interpreting it.

What can an existing host do with this device, knowing nothing about it? Rather a lot: detect its attachment, give it an address, read its self-description, allocate its power, and configure it. It cannot use it — that needs the function-layer knowledge it lacks — but every mechanism below function works unchanged, and the device can report precisely what it would need.

What does that tell you about where an architecture should place variety? That the layer holding the unknown must be as high and as narrow as possible, and every layer beneath must be structurally forbidden from depending on it. Each legacy interface in Chapters 1.3–1.5 did the reverse — it let device-specific assumptions reach all the way to the wire — which is exactly why none of them could accommodate anything new.

9. Understanding Check

10. Summary

The vision behind USB is not one connector for everything. It is one extensible architecture able to represent device classes that do not exist yet, without redesigning the host's attachment mechanism for each one — and the way that impossible-sounding demand is met is by layering in the strong sense.

Five layers, each owning a question and structurally forbidden from depending on the answers the others give. Physical attachment knows nothing of device kind. Transport moves declared service models and knows nothing of meaning. Device model and identity carries an address and a self-description and knows nothing of purpose. Function holds what the device does, as a standard class — and is where the architecture deliberately concentrates variety. Software-visible behaviour presents the device and binds a driver, generically where the class allows.

The payoff is confinement. A new device class changes function and software only; a faster transport changes physical and transport while the device model survives intact; a new connector changes one layer. Each is a change the architecture absorbs rather than a new architecture.

The model is a design intent that is mostly honoured. Function must know which service models exist, generation capability is visible above the physical layer, and power cuts across everything — and those leaks predict where specification complexity and interoperability problems concentrate.

For engineers the layering is directly useful: hardware partitions along it, the hardware/firmware boundary follows from each layer's rate of change, verification decomposes into protocol-level and class-level concerns that are independently reusable, and controller IP is reusable exactly because it implements the layers that do not vary per product.

11. What Comes Next

The strongest claim in this chapter is §3's second case: that a faster transport can be introduced while the device model stands still, so new and old equipment still meet and the accumulated software and tooling survive.

That claim deserves evidence, and Chapter 1.8 supplies it. USB has been through several generations, each driven by a different pressure — more bandwidth, more power, more kinds of device, and eventually a demand to carry traffic that is not USB at all. The interesting question is not what each generation added, but what each one was allowed to leave alone, because that is the layering being tested by decades of real requirements rather than by argument. It is also where the model's leaks show most clearly, and where the cost of compatibility lands on the engineers who build and verify it.

Browse the full path on the USB tutorials index.