Why USB Was Created

Chapter 1.1 argued in the abstract that peripheral connectivity had become a system-level architecture problem. Chapters 1.3, 1.4 and 1.5 then went down three real attachment stacks in detail, and produced something the opening chapter could not: evidence about why each interface was shaped the way it was.

This chapter converts that evidence into architecture. Not into a list of complaints — 1.1 already catalogued the costs — but into decisions, each with the reasoning that forces it and the price it carries. That last part matters. A curriculum that presents USB's structure as a series of obvious improvements teaches you to recite features. A curriculum that shows each decision as a trade with a bill attached teaches you to evaluate architectures, including ones nobody has designed yet.

1. What the Three Interfaces Had in Common

Set the findings of 1.3, 1.4 and 1.5 side by side and a single pattern emerges that none of them shows alone.

RS-232 achieved its generality by fixing the agreement about meaning outside the link. The interface carries bytes and declines to interpret them, so the knowledge binding a device to its software lives in an operator and in device-specific code.

The parallel port achieved its efficiency by fixing one device class into its signal vocabulary. Status lines describing paper conditions, a wide path pointing outward, a handshake tuned to feeding a mechanism — all excellent for printing, all meaningless to a camera.

PS/2 achieved its cheapness by fixing the device identity into the port itself, and handing timing to the device. Nothing needs discovering when the answer is known at manufacture, and two wires suffice when only one known device will ever use them.

Three different fixings. And here is the observation that took three chapters to earn:

Each interface bought its simplicity by fixing, inside the interface, something a general architecture must leave open.

That is a much sharper statement than "the landscape was fragmented." Fragmentation is the symptom. The mechanism is that every one of these designs was locally optimal precisely because of an assumption a universal architecture cannot make. You cannot fix the device class and serve unknown device classes. You cannot fix identity into the port and expect the port to report identity. You cannot hand timing to the device and expect the host to schedule a shared bus.

This also explains why the landscape could never have converged on its own. No amount of improving any one of these interfaces produces a universal one, because the property that would have to change is the property each design was built around.

2. From Cost to Decision

Chapter 1.1 asked what must be solved and produced requirements. This chapter asks the harder question that the evidence now supports: what must be decided, and what does each decision cost?

The difference is not pedantry. "Devices should identify themselves" is a requirement; it constrains nothing about how. "Every device carries a mandatory, machine-readable self-description that the host reads before any device-specific software exists" is a decision — it commits to a data format, a protocol phase in which it is read, a class of failure when it is malformed, and an obligation on every device vendor forever.

Six decisions follow from the evidence. Each is stated with what forces it, what it commits the architecture to, and what it costs.

3. Decision One — The Host Owns the Bus

What forces it. Chapter 1.5's inversion. When the device generates the clock, the host receives on timing it does not control; that is tolerable for one known device on a dedicated port and impossible as a general rule. If many devices share a path, something must decide who transmits and when, or the devices collide. The parallel port's handshake shows the same need from the other side: its flow control works because exactly one host drives exactly one peripheral.

The decision. A single host initiates every transaction. Devices respond; they do not speak spontaneously. One agent owns bus scheduling, so contention is resolved by design rather than by arbitration between peers.

What it costs. A great deal, and it is worth being explicit. The host becomes substantially more complex — it must poll, schedule, and manage every attached device, which is why a host controller is a serious piece of silicon and a device controller is often modest. It rules out peripherals talking directly to one another over the bus. And it means a device with something urgent to say must wait to be asked, which shapes the latency behaviour of every device class and drives much of the design of the service models in Module 10.

This is the decision that most shapes the rest of the architecture, and Chapter 2.6 examines it properly.

4. Decision Two — The Device Describes Itself

What forces it. All three chapters, converging. RS-232 left identity outside the link entirely; the parallel port's negotiation established a transfer mode but never who was talking; PS/2 answered identity by fixing it into the port, which works only while there is one possible answer. In every case the knowledge that binds hardware to software originated with a human.

The decision. Every device carries a mandatory, machine-readable self-description that a host can read before it holds any software specific to that device — stating what the device is, what it can do, what it needs, and which standard class of device it belongs to, so that a generic driver can often serve it.

What it costs. Every device vendor must author that data correctly and maintain it. A malformed self-description becomes a new failure mode that did not previously exist — and one with an unhelpful symptom, because a device whose description cannot be parsed presents as a device that does not work at all. It also fixes a format that must remain readable for decades, which constrains how the architecture can evolve.

The mechanism is descriptors, read during enumeration. Module 6 owns enumeration and Module 7 owns descriptors; nothing more about either belongs here.

5. Decision Three — Attachment Is a Defined Event

What forces it. Chapter 1.2's finding that no legacy interface treated a device arriving at runtime as a specified event with guaranteed electrical and software behaviour. Users could not rely on a rule because none had been written.

The decision. Connection and disconnection are first-class runtime events. The electrical behaviour of a device appearing is defined, the host detects it, and a defined sequence follows that leaves the device addressed and configured — with removal equally defined, including removal partway through an operation.

What it costs. Machinery at every level: electrical detection, a protocol phase to run on detection, and software able to construct and tear down device state at arbitrary moments. It also makes every driver's life harder, because a device can now vanish mid-operation and correct behaviour must be defined for that.

Why it is not optional. Without it, capacity is effectively a boot-time decision and every configuration change interrupts everything running — which is exactly the constraint Chapter 1.2 recorded.

6. Decision Four — Expansion Without New Host Interfaces

What forces it. The port-count ceiling. Every examined interface fixed capacity at manufacture: one device per input port, commonly one parallel port, a small fixed number of serial ports. Adding devices meant adding host hardware or switching between them, and even SCSI — the one interface that genuinely addressed several devices — required an installer who understood addressing and termination.

The decision. Attachment points are extended by devices whose job is to provide more of them, so capacity grows after manufacture without adding host interfaces. The host's single interface serves a whole tree.

What it costs. Topology rules — depth limits, enumeration of nested devices, and the fact that everything shares the bandwidth of the one host interface upstream of it. A tree also adds latency at each level, and makes the failure behaviour richer: a device in the middle of the tree failing affects everything below it.

Those devices are hubs; Chapter 2.3 and Module 5 own them.

7. Decision Five — One Bus, Differentiated Service

What forces it. Chapter 1.2's table, read across its columns. A keyboard sends a few bytes when a human moves and cares about responsiveness. A storage device wants sustained throughput and tolerates delay. An audio device wants delivery at a steady rate rather than as fast as possible. These are not variations in speed; they are different definitions of correct service.

The decision. One transport carries all of them, offering several distinct service models over the same wires, and each device declares which model each of its data paths requires.

What it costs. Scheduling becomes a genuine problem. The host must allocate bus time among devices with incompatible demands, which means admission decisions, reserved capacity for traffic that needs it, and the possibility that a new device cannot be configured because the bus cannot promise what it asks for. That complexity is real and lands on the host.

Those data paths are endpoints and the service models are transfer types. Module 9 owns endpoints, Module 10 owns transfer types, and Module 14 owns scheduling.

8. Decision Six — Power Inside the Model

What forces it. Chapter 1.2's finding that power was a property of whichever stack a device happened to attach through: some ports supplied their device, others defined nothing, so a second cable to the wall was a lottery.

The decision. The interface carries a defined power budget that a device may draw against, with the amount it needs stated in its self-description and granted as part of configuration.

What it costs. Budgeting and enforcement. The host must track what it has promised, refuse configurations it cannot supply, and behave correctly when a device draws more than agreed — and hubs must account for what passes through them. It also caps what can be powered this way, so devices above the budget still need their own supply.

9. What Standardisation Does Not Do

Before the benefits, the honest accounting — because a chapter that presents only the upside produces engineers who are surprised by real projects.

The complexity does not vanish; it relocates and grows. A host controller that schedules a tree of devices with differentiated service is far more complex than a serial port's controller. Enumeration is a protocol phase that did not previously exist. Power budgeting is bookkeeping nobody previously did. The total engineering in the system went up.

New failure modes are created. A malformed self-description, a device that cannot be enumerated, a configuration refused because the bus cannot promise the service or the power it asks for — none of these could happen to a serial port, and all of them are now ordinary bring-up experiences.

Generic does not mean free. A device belonging to a standard class can often be served by a generic driver, but device-specific behaviour did not disappear; it became the exception rather than the rule. Vendors still ship software.

Nothing is instantly obsoleted. The legacy interfaces continued in the roles that suited them, and several are still in service today. An architecture wins by becoming the default for new work, not by deleting what exists.

The accurate claim, then, is the one Chapter 1.1 made and this chapter can now justify in detail: standardisation does not remove the engineering — it makes the engineering reusable and interoperable. Which turns out to change the economics enormously, and that is the next section.

10. What This Changes for Silicon and Verification

This is where the architecture stops being an abstraction and starts affecting what semiconductor engineers do all day.

Controller hardware becomes a product rather than a project. When every peripheral class attaches the same way, a device controller is worth designing once, hardening, and reusing across many products — and worth buying as IP rather than building. The same is true at the host end. Under the fragmented model, each interface's controller was a bespoke block serving one device class, so there was no volume over which to amortise quality.

The PHY boundary becomes a reusable boundary. A defined electrical layer with a defined interface to the protocol logic above it means analogue and digital effort can be separated, specialised, and independently reused — the same separation Chapter 1.3's Figure 1 identified as a layer, now with a standard on both sides of it.

Verification IP becomes economically possible. This is the biggest change, and it is easy to underrate. Verifying a bespoke interface means writing its checkers yourself, for one project, with no one to compare against. Verifying a standardised protocol means a verification IP — a model, a protocol checker, a coverage model — can be developed once and sold or reused across the industry, with quality far beyond what any single project could justify. The economics invert: under fragmentation, thoroughness was unaffordable; under standardisation, it is shared.

Assertions describe the protocol, not the implementation. Chapters 1.4 and 1.5 each wrote assertions that protected their own example's control behaviour — necessarily, because there was no protocol above them to appeal to. A standardised protocol has invariants that belong to the specification, so a checker written against it applies to every implementation, including ones written by other companies. That is what makes an independent protocol checker meaningful.

Compliance becomes a defined activity. There is a specification to test against, so a device can be tested for conformance rather than merely for working against the one host the vendor happened to own. Interoperability stops being a matter of hope.

Debug becomes instrumented. A standardised bus can be decoded by an analyser, so a trace becomes a protocol-level view rather than a pile of edges — an enormous practical difference during bring-up, and one that simply cannot exist for an interface that only one company implements.

The costs on this side, too. The verification matrix grows with every generation and speed mode the architecture supports, backward compatibility must itself be verified, and the specification is large enough that reading it correctly is a skill. Chapter 1.8 returns to this when it examines what multiple generations do to an engineering organisation.

11. Common Misconceptions

12. Reason It Through

A team proposes a peripheral architecture with one connector, one electrical standard, one framing convention, and a rule that every device must be identified by the operating system before use — implemented by the user selecting the device type from a list during installation.

Which decisions does this satisfy? Arguably the electrical and framing ones. There is a single physical and signalling agreement, which is genuinely more than the legacy landscape had.

Which does it fail? Decision Two, and fatally. Identity is still supplied by a human, so the knowledge binding hardware to software still originates outside the system. Everything that depends on identity then fails with it: configuration cannot be automatic, because there is nothing to configure from; a device moved to another machine needs the ritual repeated; and a device class nobody anticipated needs the list updated.

Why is a human-supplied identity architecturally different from a device-supplied one? Because it cannot participate in a protocol. A self-description is data the host can read at a defined moment and act on mechanically, which makes discovery, driver binding, power granting and service admission all derivable from one mechanism. A list entry chosen by a person is available only at installation, to one machine, and to nothing automated.

What does this reveal about the whole set? That the decisions interlock. Attachment as a defined event is worth little without identity to read at that moment; power budgeting needs a stated requirement to budget against; class-generic drivers need a declared class. A proposal satisfying some decisions and not others does not get partial credit, because the mechanisms are each other's inputs.

13. Understanding Check

14. Summary

Three examined interfaces revealed one mechanism: each bought its simplicity by fixing, inside the interface, something a general architecture must leave open. That is why the landscape could not converge on its own — the property that would have to change was the property each design was built around.

Six decisions follow from that evidence, and each carries a bill. The host owns the bus, which resolves contention by design and costs substantial host complexity, no device-to-device traffic, and devices that must wait to be asked. The device describes itself, which moves identity inside the architecture and obliges every vendor to author that data correctly. Attachment becomes a defined runtime event, which requires electrical, protocol and software machinery and makes every driver handle a device vanishing mid-operation. Expansion happens without new host interfaces, which brings topology rules and shared upstream bandwidth. One bus offers several service models, which makes scheduling a real problem with admission decisions and reservations. Power lives inside the model, which requires budgeting, enforcement and a cap.

The decisions interlock — attachment needs identity to be useful, power budgeting needs a stated requirement, class drivers need a declared class — so they compose only as a set.

And the honest accounting: the total engineering went up. New failure modes appeared, generic drivers did not abolish device-specific software, and nothing was instantly obsoleted. What standardisation changed is the economics. Controller silicon becomes reusable IP, the PHY boundary becomes a reusable boundary, verification IP becomes economically possible, assertions describe a specification rather than one implementation, compliance becomes a defined activity, and an analyser can decode the bus during bring-up. Rigour that no single project could fund became something the industry shares.

15. What Comes Next

The decisions are on the table. What they do not yet form is a model — a way of thinking about peripherals that makes those six commitments look like one idea rather than six.

Chapter 1.7 supplies it. The goal was never one connector for everything, and describing USB that way misses the abstraction entirely. The goal was one extensible architecture capable of representing device classes that do not exist yet, without redesigning the host's attachment mechanism for each one — which requires separating physical attachment, transport, device identity, logical function and software-visible behaviour into layers that can vary independently. That separation is the actual invention, and it is what the next chapter builds.

Browse the full path on the USB tutorials index.