USB · Module 4
USB 1.x Architecture
The first generation did not merely define a slow bus — it fixed the invariants every later generation had to preserve. What USB 1.x committed the architecture to, which commitments became load-bearing, and which became the constraints that forced the next generation to exist.
Module 3 finished the physical layer: four line states, a differential pair, biasing that announces presence and speed, and the electrical quantities underneath. Modules 1 and 2 supplied the reasons and the cast. You now have one complete USB — and it is the first one.
Module 4 asks why there had to be more than one, and what actually changed each time. The answer is never it got faster. Speed is the visible consequence; the interesting content is what each generation had to add, what it had to keep, and what that combination cost the people building silicon.
This chapter is about the generation that had no predecessor to be compatible with — and which, precisely because of that freedom, fixed the invariants every later generation would be obliged to preserve.
1. What a First Generation Really Does
A first generation has a privilege no later one has: nothing to be compatible with. Every decision is free, and every decision is therefore permanent in a way later decisions are not — because from generation two onward, changing any of them means abandoning the installed base.
So the useful question about USB 1.x is not what could it do? It is: which commitments did it make that every successor had to keep?
Chapter 1.6 derived six architectural decisions and Chapter 1.7 organised them into layers. USB 1.x is where those became a specification. It established:
A host that owns the bus. One scheduler, one decision-maker, devices that answer — Chapter 2.1's model.
A device model with identity. A device describes itself, is given an address, and is configured from what it declares. This is the invariant that mattered most, as §3 shows.
A tiered-star topology with hubs as devices. Chapter 2.3's arrangement, bounded as Chapter 2.8 described.
A signalling pair with biasing that announces presence and speed. All of Module 3.
Two signalling rates — a low one for input devices and a faster one for everything else, nominally 1.5 Mbit/s and 12 Mbit/s. Module 5 owns what those modes are; here they matter only as the size of the original envelope.
2. The Original Envelope
Read the colours as the chapter's thesis. The three upper layers are still, recognisably, what a device presents to software today. The two lower layers have been rebuilt more than once. That is not a coincidence; it is Chapter 1.7's layering doing exactly what it was designed to do — confine change to where it was expected.
3. The Commitment That Mattered Most
Of everything generation one fixed, one commitment carried more consequence than the rest: a device describes itself in a structured, machine-readable form, is assigned an address, and is configured from what it declared.
Why this rather than the topology or the signalling? Because it is the layer everything else depends on and nothing else can route around.
It is what software binds to. Drivers, class definitions and operating-system device models all sit on top of it. Change it and every piece of software in the ecosystem changes with it.
It is speed-independent by construction. Nothing in describing yourself requires a particular signalling rate. A description is data, and data can be carried by any transport willing to carry it.
And it is what makes an old device work on a new host. Chapter 4.7 develops compatibility properly, but the mechanism is already visible: a host built decades later still knows how to ask a device what it is, because the question has not changed.
The practical measure of how good a decision this was: every subsequent generation rebuilt the transport and the physical layer, some of them twice, and none of them touched this.
4. Where the Envelope Bound First
Generation one was not defeated by a single limit. Three pressures accumulated, and knowing which one bound first is the argument for Chapter 4.2.
Throughput, for a specific class of device. The faster of the two rates was ample for input devices, printing and modest peripherals. It was not ample for storage, imaging and audio capture — categories that were becoming ordinary rather than exotic. The pressure was not general; it came from particular device classes whose data volumes had grown.
The bus is shared, so the ceiling is shared. Chapter 2.3 §3 established that everything below a hub shares the path to the host. A single device wanting more capacity is one problem; several such devices on one bus is a harder one, because they contend for a fixed total.
Devices that could not use USB at all. The most consequential pressure is the one that produces no complaints, because affected devices simply used a different interface. External storage and video capture largely stayed on other connections — which meant the universal architecture of Chapter 1.7 was not yet universal in practice. That is a failure of the architecture's central promise, and it is a much stronger argument for a new generation than any user's stopwatch.
Notice what is absent from that list. No pressure to change the device model, the identity mechanism, the topology, or the host-centric arrangement. The pressure was entirely on the transport — which is precisely why the response could be confined there.
5. What This Means for Silicon and Verification
Generation one's architecture implies a controller of a particular shape, and the shape is worth naming because later chapters measure growth against it.
One physical mode to implement, with two signalling rates that differ in timing rather than in kind — the same pair, the same line states, the same biasing mechanism of Chapter 3.5.
One protocol engine. Everything on the bus is the same kind of traffic at the wire level, so there is one path from the PHY to the protocol logic and one set of state to maintain.
One set of software-visible state. No mode selection, no capability advertisement, nothing to reconcile.
For verification, the configuration space is small. The dimensions are the two rates, the device classes, and topology — and crucially there is no mode dimension and therefore no fallback dimension. A test either runs or does not; there is no question of which architecture is currently active, because there is only one.
That is the baseline against which every later generation's cost should be read. When Chapter 4.5 argues that adding a generation costs more than a clock increase, this is the thing it costs more than.
6. Common Misconceptions
7. Reason It Through
An architect proposes a new peripheral interface and asks which of its early decisions will be hardest to change later.
What does USB's history suggest? That the answer is not the fastest-moving layer but the one the most other things depend on. USB rebuilt its physical and transport layers repeatedly and never touched its identity framework — not because the framework was perfect, but because every driver, class definition and operating-system device model was built on it.
Why is the transport comparatively easy to replace? Because the things above it were forbidden to depend on its details. A device describing itself does not care how the description travels, so a new transport can carry the same description. That is Chapter 1.7's independence claim paying out.
What follows for the architect's actual decision? Spend the most care on the layer that will be depended upon rather than the layer that will be stressed. The stressed layer will be rebuilt and everyone will expect it; the depended-upon layer cannot be rebuilt at any price once an ecosystem exists on top of it.
And what is the diagnostic question? If I changed this, who would have to change with me? A decision whose answer is nobody above me is cheap to revisit. A decision whose answer is every piece of software written against this interface is permanent from the moment the second implementation ships.
8. Understanding Check
9. Summary
USB 1.x matters not for what it could do but for what it fixed. A first generation has nothing to be compatible with, which makes every decision free — and therefore permanent from the moment a second implementation exists.
It established a host that owns the bus, a device model in which a device describes itself and is configured from what it declared, a tiered-star topology with hubs as devices, a signalling pair with biasing that announces presence and speed, and two signalling rates of nominally 1.5 and 12 Mbit/s.
Those commitments split cleanly. The upper layers proved permanent — identity, configuration and the host-owned transaction model are still what a device presents to software. The transport and physical layers proved replaceable and were rebuilt more than once. That split is Chapter 1.7's layering working as designed.
The identity framework was the most consequential commitment, because software binds to it, it is speed-independent by construction, and it is what lets an old device work on a new host. Every later generation rebuilt the transport and none touched it.
And the pressure that ended its sufficiency was not that existing devices were slow but that whole device categories could not use USB at all — a silent failure of the universality promise, and the strongest possible argument for a new generation. Crucially, none of that pressure was on the device model, which is why the response could be confined to the transport.
10. What Comes Next
The pressure was on the transport, and the architecture's upper layers were both untouched by it and worth preserving. That framing determines what a second generation had to be: a transport change that leaves everything above it alone.
Chapter 4.2 is how that was done — and the interesting part is not the higher rate but the constraint the higher rate had to satisfy. The new capability arrives on the same pair of conductors, which means old and new devices share a physical medium and a hub must serve both at once. That turns out to cost real silicon inside every hub, and it is the first appearance of a pattern this module will see repeatedly: compatibility is not inherited, it is built.
Browse the full path on the USB tutorials index.
Continue learning
Related tutorials
- Related topic
Why USB Was Created
The synthesis chapter: what three examined legacy interfaces had structurally in common, the six architectural decisions that follow from that evidence, the cost each decision carries, and why standardising peripheral attachment changes the economics of controller silicon, verification IP and compliance rather than removing the engineering.
- Related topic
The USB Host
The host is a system role assembled from software, controller hardware and a root hub — not a chip. What it owns, what sole initiator means precisely and how that claim is scoped across generations, and why confusing the host with the host controller misplaces responsibility in both RTL and verification.
- Related topic
USB Hubs
How USB adds attachment points without granting any device authority: the hub as a device that is itself enumerated, the repeater role that keeps the host in charge, why a USB 2.0 hub forwards downstream to every enabled port while USB 3.x routes, and why a branching tree is not a peer network.
- Related topic
The Host-Centric Model
Single-master as a deliberate trade rather than an obvious good: what concentrating authority in one participant buys, what it costs in host complexity and device latency, what the alternatives would have cost instead, and why the choice fits peripherals specifically.
Standards & specifications
- Governing standard
- USB-IF (Universal Serial Bus Specification)(opens USB Implementers Forum (USB-IF) in a new tab)
Defines the USB bus — its electrical signalling, connectors, packet and transaction model, device framework and the descriptors a device must expose — together with the device-class specifications layered on it. It does not define host-controller register interfaces (xHCI and EHCI are separate documents) nor any operating system's driver architecture.
This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.
Where this fits
Part of the USB curriculum.
