The USB Host

Module 1 ended with an architecture described from the outside: five layers that vary independently, tested by decades of generational pressure. You know why the architecture exists and what shape it has. What you do not yet have is the cast.

Module 2 supplies it, and it starts here because everything else in USB is defined relative to this one participant. Get the host wrong and every later mechanism — enumeration, endpoints, scheduling — will be reasoned about incorrectly, because all of them are things the host does to devices that are waiting.

Begin with a question that sounds trivial and is not.

When an engineer says “the USB host”, what exactly are they pointing at?

Ask five engineers and you will get three answers: the computer, the chip, or the driver. All three are partly right, which is precisely the problem — and the confusion has consequences that show up in RTL partitioning and in testbench architecture, not merely in conversation.

1. The Host Is a Role, Not a Component

The USB host is a system role: the single entity that owns the bus and decides what happens on it. That role is not implemented by one thing. It is discharged by a stack of cooperating pieces, and the pieces sit on different sides of the hardware/software boundary.

Everything inside Figure 1 is the host. Point at the middle box alone and you have named the host controller, which is a component of the host and not the whole of it. That distinction gets its own section below because it is the single most common source of misattributed responsibility in USB work.

2. What the Host Owns

The responsibilities below are the host's by architecture. Later modules build the mechanisms; this chapter establishes the ownership.

Bus activity. Nothing happens on the bus unless the host causes it. This is developed precisely in §3 and is the foundation of everything else.

Addressing. Every device on the bus is distinguished by an address, and the host assigns it. A device does not choose or announce an address; it is given one. Module 6 owns the procedure.

Discovery and configuration. When a device appears, the host reads its self-description and selects an operating configuration from what the device offers. Modules 6 and 7 own the mechanism; what matters here is that the decision is the host's.

Bus time. Because one bus serves devices with incompatible service needs, someone must decide who gets served and when. The host does. Module 17 owns scheduling.

Power budget. A device states what it needs; the host grants or refuses it. Module 19 owns power management.

Error policy. When something goes wrong, the decision to retry, to reset a port, or to give up is the host's.

Read that list again and notice its character: every item is a decision, not a data movement. That is what the host role fundamentally is — the place where the architecture concentrated its decisions, for reasons Chapter 2.6 examines as a trade rather than as an obvious good.

3. “Sole Initiator” — Stated Precisely

This phrase appears in every USB summary ever written, usually without the qualification that makes it true. Here is the careful version, because the careless version will mislead you the moment you meet USB 3.x.

In the classic USB 2.0 model, the host initiates every transaction. A device transmits on the bus only when it has been addressed by the host — it has no mechanism to begin a conversation. A keyboard with a keystroke waiting does not send it; it holds it until the host next asks, and the host asks because it scheduled itself to. This is genuine, strict, and the clearest expression of the architecture.

USB 3.x relaxes the mechanism without changing the ownership. A device may send an asynchronous notification indicating that an endpoint has become ready, rather than being repeatedly polled while it has nothing to say — which is a real efficiency gain and a real change in what appears on the wire. But the host still schedules and still issues the request that moves the data. The device has gained a way to say ask me now; it has not gained the ability to transfer on its own authority.

So the durable formulation is not “the device never transmits first.” It is:

The host owns initiation. A device may signal readiness, in generations that provide for it, but it does not schedule or transfer on its own authority.

4. The Host Is Not the Host Controller

Now protect the distinction, because engineers lose real time to it.

The USB host is the system role of §1 — software stack, controller hardware and root hub together.

The host controller is the hardware engine that implements the bus-facing part of that role: generating bus activity, handling the protocol-level exchanges, moving data between memory and the bus, and reporting what happened. Chapter 2.5 is about it.

The host software stack is the policy layer: which device gets configured how, which driver binds, which transfers are submitted, what happens on error.

The reason this matters is that responsibilities are not interchangeable between them, and assigning one to the wrong layer produces a specific class of mistake. A hardware team asked to implement policy that belongs in the driver builds silicon that cannot be changed when the policy does. A software team assuming the controller will handle something it does not discovers the gap at bring-up. And a verification engineer who models “the host” as a single monolithic agent builds an environment that cannot reproduce the failure where software programmed the controller correctly but the controller did not act.

The third row repays attention. The host controller's software-facing interface is standardised separately from USB itself — which is why one driver can serve many vendors' controllers, and why controller interface specifications exist as documents distinct from the USB specification. Module 22 owns that subject.

5. What the Host Role Implies for Hardware

Module 2 is architecture rather than RTL, but architecture is what tells an RTL engineer which categories of state will eventually exist. From the responsibilities in §2, a host controller must eventually hold:

A view of what is attached. Port state for each root-hub port, and enough per-device context that the controller knows where to direct activity.

Scheduling state. A representation of what work is pending and when it should be attempted, because §2 gave the host the job of allocating bus time.

Data movement machinery. Buffers and a path to system memory, because transfers move data the software stack owns.

A software-visible surface. Registers and memory-resident structures through which the driver expresses intent and reads results, plus a way to raise an event when something needs attention.

Error and recovery state. Because the host owns error policy, the controller must at minimum detect, record and report.

None of that is implemented here — Modules 21 to 23 own controller design. The point is that the list is derivable from the role, which is the sense in which architecture precedes microarchitecture.

6. What the Host Role Implies for Verification

The same derivation works for a testbench, and it produces one immediately useful rule.

Stimulus originates on the host side. In a device-under-test environment, the verification component that drives the bus is playing the host, because the architecture says initiation lives there. A device model does not spontaneously produce traffic; it responds. An environment built the other way round is not modelling USB.

The device is the responder, so its correctness is conditional. Checking a device means checking what it does given a host-originated stimulus, which makes the stimulus part of the specification of the check rather than mere setup.

The host is layered, so host-side stimulus can be injected at more than one level. A test can express intent at the software-stack level, at the controller-programming level, or as raw bus activity — and those are different tests finding different bugs. Knowing which layer your environment drives is knowing which class of defect it can catch.

Chapter 2.5 develops the controller side of this and Module 24 owns verification methodology. What Module 2 gives you is the reason the environment has the shape it has.

7. A Failure That Comes From This Confusion

A USB device works electrically. Signals are present and clean on the analyser. But the device never becomes usable by software: no application can open it, and the operating system lists nothing new.

Where do you look? The layering of §1 turns a vague symptom into an ordered search.

Did the root-hub port see an attachment? If not, the problem is below the controller — the electrical detection or the port itself — and nothing above will ever run.

Did the controller report the attachment to software? A port can register an attach while the event never reaches the driver: a masked interrupt, an unserviced status bit, a controller not yet placed in the right operational state. Clean bus signals tell you nothing about this layer.

Did the software stack act on the report? The host controller does not, by itself, decide to configure anything. That is policy, and policy lives in the stack. A report that arrives and is not acted on looks exactly like a report that never arrived.

Did configuration complete, and did a driver bind? A device can be fully configured and still be unusable if nothing in software claims it.

Notice what the “electrically fine” observation actually establishes: only that the lowest layer worked. Every layer above it is untested by that evidence, and an engineer who believes the host is one thing has no way to decompose the question. This ordered search is the beginning of the debugging framework the rest of Module 2 develops.

8. Common Misconceptions

9. Reason It Through

A verification engineer builds a USB device-under-test environment. The testbench contains a device model, a monitor, and a component that generates traffic whenever the DUT has data available to send. Tests pass. Silicon fails immediately on a real host.

What is architecturally wrong? Traffic is being generated because the device has data. That inverts ownership: on a real bus, data being available at the device causes nothing by itself. The host asks, on its own schedule, and the device answers.

Why did the tests pass? Because the environment and the DUT share the same wrong assumption. The testbench asked exactly when the device was ready, so every response was produced under conditions the device found convenient — and no test ever created the situation that dominates real operation.

What does real silicon do differently? It asks when it decided to, which means asking when the device has nothing to say, asking again before the device is ready, and not asking for a long interval while the device holds data. None of those were ever stimulated.

What would have caught it? Making the host-side component schedule independently of the DUT's internal state, then randomising that schedule. The check to add is the ownership invariant itself: the device must produce nothing on the bus that was not preceded by a host-originated request. Chapter 2.2 writes that assertion against a concrete teaching abstraction.

What is the general principle? A testbench encodes an architecture whether or not its author intended to. If the environment's structure contradicts the protocol's ownership model, it will generate only the traffic patterns that model permits — and will be silent about precisely the cases the real system spends its life in.

10. Understanding Check

11. Summary

The USB host is a system role, not a component. It is discharged by the operating system's USB software stack, the host-controller driver, and the host controller hardware with its integrated root hub — and naming any single layer “the host” misplaces the responsibilities of the other two.

What the role owns is a list of decisions: all bus activity, device addressing, discovery and configuration, allocation of bus time, power budget, and error policy. That the items are decisions rather than data movements is the character of the role and the reason the architecture concentrated them in one place.

The initiation rule, stated so it survives Module 20: the host owns initiation. In the classic USB 2.0 model a device transmits only when addressed; USB 3.x adds asynchronous readiness notification, which changes the mechanism and not the ownership.

For hardware, the role predicts the categories of state a controller must eventually hold — attachment and port state, scheduling state, data-movement machinery, a software-visible surface, and error state. For verification, it dictates that stimulus originates on the host side, that a device's correctness is conditional on host-originated activity, and that host-side layering offers a choice of injection point which determines what class of bug an environment can find.

And the distinction to carry into every later chapter: host, host controller and host software stack are three different things with non-interchangeable responsibilities. Collapsing them puts policy in silicon, protocol in drivers, and blind spots in testbenches.

12. What Comes Next

The host owns the decisions. That immediately raises the question this chapter deliberately left open: if the device decides nothing, what exactly is it?

Chapter 2.2 answers it, and the answer is less trivial than subordination suggests. A responder must still maintain protocol-visible state, behave correctly according to that state, distinguish its USB-facing machinery from the function it actually provides, and do all of it under a reset it does not control. That chapter also draws the distinction that matters most to an RTL engineer in this module — device controller against device function — and puts the ownership rule of §3 into a small piece of teaching hardware with an assertion that protects it.

Browse the full path on the USB tutorials index.