Tiered-Star Architecture

Chapter 2.7 described the shape. This chapter gives it bounds — and the bounds are the point at which Module 2's architecture stops being a diagram and starts being a specification you could build to.

There are two limits worth knowing and one habit worth forming. The habit is this: a limit you have memorised is a number that will be wrong the next time the architecture grows; a limit you have derived is a piece of reasoning that tells you what would have to change for it to move. Both of USB's headline topology limits come from somewhere specific, and the derivations are short.

1. Tiers, Counted

A tier is a level of the tree measured in hops from the host. The host with its root hub is tier 1. Anything plugged directly into a root-hub port is tier 2. Anything plugged into a hub that is itself at tier 2 is tier 3, and so on.

USB 2.0 permits a maximum of seven tiers. Since tier 1 is the root hub and the deepest tier must be occupied by a function rather than by a further hub, that allows at most five external hubs in any single path from the host to a device.

2. Where the Depth Limit Comes From

The number seven is not aesthetic. It falls out of time.

Recall Chapter 2.1: the host initiates, and a device answers. The host cannot wait indefinitely for that answer — it must be able to conclude, within some bounded interval, that no answer is coming, so that it can move on and serve everyone else. That bound is a turnaround budget, and it is fixed, because a host that waited longer for deep devices would have to know the topology before it could interpret silence.

Now count what spends that budget on a maximum-depth path.

Cable propagation, once in each direction, for every hop. Signals travel at finite speed and a cable of any useful length takes measurable time.

Hub handling delay, once in each direction, at every hub. A hub is not a wire: it receives, and re-drives. That takes time, and it takes time again on the way back.

The device's own response time, which the specification also bounds.

The round trip to a tier-7 device therefore spends six hops of cable propagation and five hubs of handling delay, twice over, plus the device's own turnaround — and all of it has to fit inside a budget fixed for the whole architecture.

That is the derivation. The tier limit is what remains after you decide a turnaround budget, a maximum cable length and a maximum per-hub delay. Change any of those three and the tier count moves; keep them and it does not.

Notice what this explains that memorising the number does not:

Why the limit is depth and not device count. Delay accumulates along a path. A hundred devices spread across a shallow tree cost nothing in turnaround; one device six hubs deep costs everything.

Why cable length is also specified. It is not an independent rule — it is the other term in the same budget. Longer cables and more tiers trade against each other, which is why an architecture cannot leave both free.

Why hub latency is bounded. A hub that took as long as it liked would make the budget unenforceable no matter how few tiers were allowed.

And why the limit is structural rather than conservative. It is not a safety margin someone could relax with better components. Exceeding it means the host may time out on a device that is answering correctly — a failure that looks like an unreliable device and is actually a topology violation.

3. Where the Device-Count Limit Comes From

The second limit has an even shorter derivation.

Every device on the bus is distinguished by an address, assigned by the host. That address travels in a field of fixed width, and in USB 2.0 the field is seven bits. Seven bits give 128 values. One of them — zero — is reserved as the default address a newly attached device uses before it has been given one of its own, which Module 6 covers.

So 127 addressable devices, and the derivation is simply the width of a field minus one reserved value.

Two consequences are worth drawing out.

Hubs consume addresses. A hub is a device (Chapter 2.3), so it is addressed like one. A tree built from many hubs spends part of its budget on the infrastructure rather than on peripherals.

The limit is per bus, not per machine. A system with several host controllers has several independent buses, each with its own address space. Counting connectors on a computer does not count devices against one limit.

4. Compound Devices

One case sits awkwardly between the two limits and is worth naming because it is common in practice.

Some products are, internally, a hub plus one or more permanently attached functions in a single package — a keyboard with ports on it, a monitor with a built-in hub, a docking station. The specification calls these compound devices.

The architecture treats them exactly as the pieces they are made of. The hub inside is a hub: it occupies a tier and consumes an address. The functions attached to it are devices: they sit one tier below and consume addresses of their own. One physical object can therefore be several addressed devices and can advance the tier count by one, which surprises people counting objects rather than participants.

This is also the cleanest illustration of why the architecture defines a hub as a device rather than as special infrastructure. Nothing about a compound device needed a new rule: it is a hub and some devices, described by mechanisms that already existed.

5. What the Limits Mean in Practice

They are reached more often than engineers expect, because hubs hide inside things. A monitor with a built-in hub, a dock, a keyboard with ports, and a hub on the desk are four tiers before the user has consciously used a hub at all. A device that misbehaves at depth will meet real users quickly.

Depth costs even below the limit. Nothing improves as a tree deepens. Latency accumulates, bandwidth is shared through each upstream link, and Chapter 2.7's physical properties all degrade. The limit is where the architecture stops working; the degradation starts immediately.

Bus-powered hubs compound the problem. A hub drawing its own power from upstream has less to give downstream, so deep trees of bus-powered hubs hit power limits before topology limits. Module 19 owns power.

And the limits are architecture, not implementation. A vendor cannot relax them by building better silicon, because the budget they derive from is what every other participant assumed when deciding how long to wait.

6. What This Means for Verification

Topology limits define the corners of a stimulus space, and they are cheap to state and easy to omit.

The configurations that matter are the extremes and the boundaries: a device at tier 2, and the same device at the maximum depth; a tree using few addresses, and one using nearly all of them; a compound device, which exercises hub-and-function-in-one-package handling; and mixed trees where slow devices sit behind fast hubs.

Representative coverage dimensions — not a verification plan:

• attachment depth: directly attached, mid-tree, and at maximum permitted depth
• address-space occupancy: sparse, and near exhaustion
• attachment at a tier that would exceed the limit — a case whose correct behaviour is refusal
• compound devices versus discrete hub plus device
• bus-powered versus self-powered hubs in the path

The most interesting case is the one where correct behaviour is refusal. A host presented with a device one tier too deep must decline to configure it and report the situation, not attempt it and fail obscurely. That is a genuine requirement with a genuine implementation, and it is exactly the kind of case a test plan built around working configurations never contains — because it only occurs when something is wrong.

For debug, the limits give the topology-varying method of Chapter 2.7 §5 a boundary to push against. A symptom that appears only near maximum depth and disappears one tier up is strong evidence of a timing budget rather than a logic fault, and that is a conclusion reachable in minutes by moving a cable.

7. Common Misconceptions

8. Reason It Through

A user reports that a device works on their desk but fails at their workstation. Investigation finds the workstation path is: computer → monitor with a built-in hub → docking station → desk hub → device.

How deep is the device? Count participants rather than objects. Tier 1 is the host and root hub; the monitor's internal hub is tier 2; the dock is tier 3; the desk hub is tier 4; the device is tier 5. Within the limit — so depth alone does not explain the failure, and an engineer who stopped at “too many hubs” would be wrong.

What else changed? Everything physical from Chapter 2.7. The device now shares upstream bandwidth with whatever else uses the dock and the monitor. Its round-trip latency has grown by four hops. Its power may now come from a bus-powered hub with a budget already partly spent. And under USB 2.0 forwarding it sees traffic addressed to siblings it never met on the desk.

Which would you test first, and how? Power, because it is cheapest to eliminate: substitute a self-powered hub and see whether the symptom moves. Then sibling traffic, by quiescing the other devices. Then bandwidth and latency, by shortening the chain one hub at a time. Each experiment isolates one physical variable, which is §6's method applied.

What if it works at tier 4 and fails at tier 5, with nothing else attached? That pattern — a clean boundary in depth with the other variables removed — points at an accumulating budget rather than a logic fault, and suggests a device whose response time leaves too little margin for the delays ahead of it. That device is within specification only at shallow depths, which is a real defect and one that direct-attachment testing cannot find.

The general lesson. Count participants, not objects, because hubs hide inside things; and when a symptom tracks depth, suspect a budget rather than a bug.

9. Understanding Check

10. Summary

USB's topology has two limits, and each is derived rather than decreed.

Depth: seven tiers in USB 2.0, with tier 1 the host and root hub, allowing at most five external hubs in any path. The number comes from time: the host must decide within a fixed turnaround budget that no answer is coming, and a maximum-depth round trip spends that budget on cable propagation at every hop, hub handling delay at every hub, and the device's own bounded response — all doubled for the return. Fix a turnaround budget, a cable-length bound and a per-hub delay bound, and the tier count is what remains. That is also why cable length is specified alongside depth rather than independently: they are terms in the same budget.

Count: 127 devices per bus in USB 2.0, from a seven-bit address field less the reserved default address. Hubs consume addresses because hubs are devices, and the limit is per bus rather than per machine.

A compound device — a hub plus permanently attached functions in one package — is several addressed devices in one object and advances the tier count by one. That it needed no new rule is the clearest evidence that defining a hub as a device was the right call.

In practice the limits are reached sooner than expected because hubs hide inside things, depth degrades latency and bandwidth long before the limit is reached, and exceeding the depth limit is a correctness failure rather than a performance one — the host may time out on a device that answered correctly, presenting as an unreliable device rather than the topology violation it is.

And the habit worth keeping: derive limits, do not memorise them. A derivation tells you which limits are structural, which move with a generation, and what would have to change for them to move. A number tells you nothing and eventually becomes wrong.

11. What Comes Next

Module 2 is complete. You now have the cast and the shape: a host that owns every decision, assembled from software, a controller and a root hub; devices that answer and never initiate, separable into a protocol engine and the function it serves; hubs that extend reach while gaining no authority, and are themselves devices; a root hub where the tree begins and bus events first become software-visible; a host controller translating between software's world and the bus's; a host-centric model chosen as a deliberate trade with an itemised bill; and a tiered star that is physically a tree of point-to-point links and logically a star, bounded by limits that derive from a timing budget and a field width.

What Module 2 has consistently deferred is everything below the protocol boundary. Every chapter has said the PHY handles signalling and moved on.

Module 3 opens that box. It takes the physical layer: how a bit becomes a voltage on a pair of wires, what the line states mean, how a device's presence and speed are detected electrically before any of Module 2's machinery can begin, and why the electrical design makes the architecture above it possible. It is where the device was attached stops being an event in a register and becomes a change on a wire.

Browse the full path on the USB tutorials index.