USB Hubs

Two participants and one link is not a system. Chapter 2.1 gave the host every decision and Chapter 2.2 gave the device the obligation to answer, but a host controller has a small, fixed number of ports — and Module 1 established that capacity fixed at manufacture is one of the defects the architecture exists to remove.

So USB needs a way to add attachment points. The constraint is severe: it must add them without granting anything new any authority, because every mechanism in the previous two chapters depends on there being exactly one decision-maker. An expansion mechanism that created a second locus of control would dismantle the architecture it was extending.

The answer is the hub, and the elegant part of it is not that it multiplies ports.

1. A Hub Is a Device

Start with the structural fact, because it resolves most confusion about hubs before it starts.

A hub is itself a USB device. It attaches to an upstream port exactly as any peripheral does. It is detected on attachment, given an address by the host, describes itself, and is configured — the same sequence any keyboard goes through. It has a device controller and protocol-visible state of its own, in exactly the sense Chapter 2.2 established.

What distinguishes it is its function, in that chapter's precise sense: where a keyboard's function is a key matrix and a drive's function is storage, a hub's function is providing attachment points. It is a peripheral whose product is ports.

That is a genuinely elegant consequence of the layering Chapter 1.7 described. The expansion mechanism did not need to be carved out as a special case in the architecture, because the architecture already had a slot for “a thing that attaches and does something useful.” A hub simply fills it.

2. Two Jobs at Once

A hub occupies an unusual position: it is a device on its upstream side and the thing devices attach to on its downstream side. Both roles run simultaneously.

The hub controller is the hub-as-device. The host addresses it like any peripheral to ask what is attached below, to power a port, to enable or disable one, or to reset one. Notice what this means: the host manages the tree by talking to the hubs in it. A device three tiers down was made reachable by the host issuing requests to the hubs above it — requests those hubs answered as ordinary responders.

The repeater path is the traffic-forwarding function: moving host-originated activity toward the devices below, and their answers back up.

The separation matters because the two are governed differently. The repeater path carries other devices' conversations, in which the hub is not a participant. The hub controller is where the hub is itself the addressed device. An engineer who does not separate them will struggle to reason about a hub that forwards traffic correctly but fails to report a port change, or the reverse.

3. What a Hub Does to Traffic — and How That Changed

This section carries the one claim in Module 2 most often stated without its generation scope, so it is stated carefully.

In USB 2.0, a hub is fundamentally a repeater. Traffic arriving from the host is forwarded downstream to the enabled ports in the relevant speed domain — not selectively routed to the one device it is meant for. Devices below the hub therefore see activity addressed to their siblings and ignore what is not addressed to them, because every device decodes the address and answers only to its own. Traffic from a device is forwarded upstream toward the host.

Two consequences follow, and both matter to an engineer.

The first is that bus time downstream of a hub is shared. Forwarding to all enabled ports means the bus below a hub is busy whenever any device below it is being served. Adding a hub multiplies ports; it does not multiply bandwidth.

The second is the failure mode Chapter 2.2 §8 described: a device transmitting without being asked corrupts an exchange belonging to a different device, because they share the forwarded medium. That is not a hypothetical — it is a direct consequence of repeater semantics.

USB 3.x changes this. SuperSpeed hubs route traffic toward the specific port on the path to the addressed device rather than broadcasting it to all of them, which means devices no longer see their siblings' traffic and idle branches are not disturbed. Chapter 1.8 noted this as one of the transport-layer changes of that generation. Module 18 owns hub behaviour in protocol depth and Module 20 owns USB 3.x architecture.

A hub also does real work beyond forwarding: it manages per-port power, reports attachment and removal to the host, enables and disables ports, and — where a fast bus must serve slower devices — contains the compatibility logic Chapter 1.8 §2 identified as the price of backward compatibility. Module 18 builds all of it.

4. The Tree Is Not a Network

Now correct the most damaging misreading available in Module 2.

Draw a hub with four devices below it and the picture resembles a network switch. It is not one, and the difference is total.

Devices below a hub cannot communicate with each other. There is no mechanism by which one could address another; a device can neither originate a transfer nor name a destination, because Chapter 2.2 gave it neither capability. Two devices on the same hub are related only in that they share a path to the host and compete for the same bus time.

Every conversation is host-to-device. A transfer between two peripherals — copying from a camera to a drive, say — is not one transfer. It is data moving from the camera to the host, and then from the host to the drive, with the host as the endpoint of both. The tree describes how signals reach the host, not who may talk to whom.

Branching does not create independence. A branch is not a separate bus with its own arbitration. In USB 2.0 it is a forwarded segment of the same host-owned bus; in USB 3.x it is a routed path on the same host-owned fabric. Either way, one decision-maker.

The distinction to hold is between physical topology and logical architecture. Physically, USB is a tree of point-to-point links. Logically, it is a star: every device has exactly one conversational partner, and it is always the host. Chapter 2.7 develops this properly; it is previewed here because the hub is where the wrong intuition is born.

5. What This Means for Hardware and Verification

For hardware. A hub design is two designs sharing a package: a perfectly ordinary device controller for the hub-as-device role, and a forwarding path with per-port control and status. The per-port state — powered, enabled, what is attached, what has changed since the host last asked — is the part that connects to Chapter 2.4, where the same problem appears inside the host controller itself.

For verification, hubs change the shape of the problem in three ways worth knowing now.

Topology becomes a stimulus dimension. A device that works when attached directly to a host may fail behind a hub, or behind two. If an environment only ever tests direct attachment it has not tested the configurations most users will create.

Sibling traffic becomes a stimulus dimension. Under USB 2.0 repeater semantics a device sees traffic addressed to others and must ignore it. A device tested alone on a quiet bus has never had that requirement exercised — and a device that responds to a sibling's address is a bug no single-device test can find.

Failures become misattributed. Because a hub sits between the host and the device, a fault in forwarding, in port enabling, or in the hub's own reporting presents as a device problem. Any debugging method must be able to ask did the hub forward it as a separate question from did the device answer, which is the layered reasoning Chapter 2.5 formalises.

6. Common Misconceptions

7. Reason It Through

A verification engineer builds an environment in which each downstream port of a hub model is driven by an independent traffic generator, so that several devices can be exercised in parallel and the testbench runs faster.

What is architecturally wrong? Independent generators per port model several sources of initiation. On a real bus there is exactly one, above the hub. The environment has invented parallel authority that the architecture does not contain.

What will it fail to test? Everything that arises from sharing. Under USB 2.0 semantics a device must ignore traffic addressed to a sibling — never exercised here, because each port sees only its own generator. Contention for bus time never occurs, so no device is ever kept waiting by another's transfer. And the hub's forwarding path is never asked to carry one conversation while another waits.

What will it wrongly pass? A device that responds to addresses other than its own. In this environment nothing else's address ever reaches it, so the defect is invisible — and it is precisely the defect that corrupts a neighbour's transfer in the field.

What is the correct shape? One host-side source of initiation above the hub, with the hub model forwarding according to the generation being modelled, and devices below required to filter by address. Parallelism in a USB environment is the host interleaving work among devices, not several hosts.

The general lesson, which is Chapter 2.1 §9's in a new form: an environment whose structure contradicts the architecture's ownership model will be silent about exactly the failures that ownership model creates.

8. Understanding Check

9. Summary

A hub is a device whose function is providing attachment points. It is detected, addressed, described and configured exactly as any peripheral is, which means the expansion mechanism needed no special case in the architecture — a direct dividend of the layering established in Module 1.

It runs two roles at once. The hub controller is the hub-as-device, which the host addresses to power, enable, reset and query ports — so the host manages the whole tree by talking to the hubs in it. The repeater path forwards other devices' conversations, in which the hub is not a participant. The two fail independently and must be reasoned about separately.

Forwarding behaviour is generation-specific: USB 2.0 repeats downstream to enabled ports, so siblings see each other's traffic and discard what is not theirs; USB 3.x routes toward the addressed device. Generation-independent is that the forwarded activity was host-originated, and that a hub holds no authority.

The misreading to refuse is that a branching tree is a network. Devices below a hub cannot address one another, peripheral-to-peripheral movement is two host-mediated transfers, and branching creates no independent bus. Physically USB is a tree of point-to-point links; logically it is a star with the host at the centre.

For engineers: a hub is two designs in one package; topology and sibling traffic are stimulus dimensions an environment must cover; and because the hub sits in the path, its faults present as device faults unless the debugging method can separate did the hub forward it from did the device answer.

10. What Comes Next

A hub extends the host's reach. But the tree has to start somewhere — there must be a first set of ports that a hub can be plugged into, and those ports belong to the host itself.

Chapter 2.4 examines the root hub, and it is more interesting than “the hub built into the computer.” It occupies a genuinely unusual position: architecturally a hub, physically part of the host controller, and managed by software through the controller's own register interface rather than by addressing a device on the bus. That makes it the place where bus events first become something software can see — and the place where Module 2's hardware/software boundary stops being an abstraction and becomes a register with a status bit in it.

Browse the full path on the USB tutorials index.