USB · Module 31
“USB Is Point-to-Point Only”
One cable, two ends — so the belief is drawn from the thing in your hand. Its prediction is that two devices on one port must contend. A tiered star with a flat address space, and a hub that is a device rather than a multiplexer.
Thirty modules have built USB from a differential pair to a design-review procedure. This one does something different: it attacks six beliefs that survive all of that — beliefs an engineer can hold after learning the terminology, because each one is supported by something they can see.
1. The Belief
"USB is point-to-point. One host, one device, one cable. That is why you need a hub if you want more than one thing plugged in — the hub is a workaround."
2. Why An Intelligent Engineer Believes It
Because the visible evidence supports it completely.
WHAT YOU CAN SEE WHAT IT SUGGESTS
----------------------------------- -------------------------
every USB cable has exactly two a link joins exactly two
connectors, and they are different participants, and they have
shapes different roles
a device has one upstream connector a device has one place to
attach, and only one
the specification and every textbook the word means what it says
describe USB links as point-to-point
plugging two devices into one port one port, one device
is physically impossibleEvery one of those observations is correct. The belief is not built on ignorance; it is built on true statements about the physical layer, extended one step too far.
3. The Prediction It Makes
This is the technique the whole module uses, and it is stronger than contradiction: take the belief seriously, and work out what would have to be true.
IF USB WERE POINT-TO-POINT AS A TOPOLOGY, THEN:
1 the number of devices a host can address would equal the number
of physical connectors on the host
2 a hub would have to be a MULTIPLEXER -- something that switches
one of its downstream ports onto the upstream link at a time,
because only one device can be at the far end of a link
3 two devices on one hub could not transfer in the same frame,
because they would be taking turns on the one link the host has
4 a device behind a hub would need a different kind of address
from a device plugged in directly, because the host would have
to say WHICH hub port as well as which device
5 hubs could not be nested, because a hub is a device and a device
is an endpoint of the linkAll five are testable. None of them is true.
4. The Counterexample
The smallest one that settles it: a laptop with one USB port, a four-port hub, and four devices.
OBSERVED
o all four devices enumerate, and the host addresses four devices
through one connector -- prediction 1 fails
o each device gets its OWN address, in the same address space as a
directly-connected device. The host does not say "port 3 of the
hub"; it says the device's address -- prediction 4 fails
o a mouse and a webcam behind the same hub both get service in the
same frame -- prediction 3 fails
o plugging a second hub into the first works, and devices behind
BOTH enumerate -- prediction 5 failsAnd the most instructive observation, which disposes of prediction 2:
5. The Corrected Model
EACH LINK SEGMENT point-to-point, exactly two participants,
one upstream and one downstream. TRUE.
THE TOPOLOGY a TIERED STAR: a root at the host, hubs as
interior nodes, functions as leaves.
BOTH AT ONCE and there is no contradiction, because they
describe different objects. A tree is made
of edges; each edge has two ends; the tree
has many nodes.What the belief predicts
What USB actually does
6. Why No New RTL Here
This chapter has no new hardware, and the reason is worth stating rather than leaving as an absence.
The misconception is not about a mechanism. It is about the relationship between two words, and the correction is a distinction rather than a circuit. A block that counted hub tiers, or routed a token down a tree, would compile and simulate and teach nothing that the second diagram above does not teach faster — which is precisely the "decorative RTL" that 30.1 §10 would file as a finding.
What is worth building for this subject already exists: 18.x builds hub port management, and 2.x builds the host-centric model that makes one address space across all tiers possible. This chapter's job is to stop a learner extrapolating from a true statement about links to a false one about topologies.
7. What The Wrong Model Does To Debugging
A wrong mental model does not merely produce wrong answers. It produces wrong questions, and the wasted time is in the questions.
SYMPTOM a device works plugged in directly and fails behind a hub
WRONG MODEL "the hub is multiplexing and my device is losing its
turn"
WRONG QUESTION how do I get more of the hub's attention?
WASTED ON hub settings, port order, unplugging other devices
CORRECT MODEL the device is a full participant either way; something
about the PATH differs
RIGHT QUESTIONS
o is it a bus-powered hub, and is the device drawing more than
the hub can supply? (power, not bandwidth)
o is the device low- or full-speed behind a high-speed hub, so
split transactions are involved?
o does the hub report an overcurrent or a failed port enable?
o does the device enumerate at all behind the hub -- which
separates "not detected" from "detected and failing"?Three of those four are answered by reading the hub's port status, which is one request. The wrong model does not suggest asking.
8. Interview Reasoning
The adversarial version of this question is common, and the trap is that the premise is half true.
"USB is point-to-point, correct?"
The answer that gets it right without being combative:
Each link segment is, yes — every cable joins exactly one upstream and one downstream participant, and that is what the specification means by the term. The topology is a tiered star: hubs are interior nodes and can be nested, and every device, at any tier, gets its own address in one flat address space. So "point-to-point" is a true statement about the edges and a false one about the graph.
Then the follow-up that shows you know why it matters:
The consequence for a device controller is that it has no idea where it is. A token carries a seven-bit address and nothing about the path, so the same silicon works plugged in directly or three tiers down. The only place position shows up is speed translation — a low-speed device behind a high-speed hub needs split transactions, and that is the hub's problem rather than the device's.
9. Exercises
1 PREDICTION
Write three more predictions that follow from the belief, beyond
the five in section 3. For each, name the observation that would
falsify it.
2 THE SMALLEST COUNTEREXAMPLE
What is the smallest physical arrangement of hardware that
disproves the belief? Justify why nothing smaller works.
3 THE OTHER DIRECTION
Name a protocol where "point-to-point" IS true of the topology,
and say what that costs it relative to USB.
4 ADDRESSING
If a device's address did encode its position in the tree, what
would have to change in the token format, in the device
controller, and in what happens when a device is moved to a
different port?
5 HUB AS A DEVICE
A hub is itself a USB device with its own address, descriptors
and endpoints. What does it use its interrupt endpoint for, and
why is that the right transfer type for it?
6 DEBUG
A device enumerates behind hub A and not behind hub B. List four
differences between the hubs that could explain it, and the
cheapest observation that discriminates.
7 INTERVIEW
Write the sixty-second answer to "USB is point-to-point,
correct?" and then the two-minute version for a senior role.10. What Carries Forward
THE CORRECTION
o point-to-point describes a LINK SEGMENT; the topology is a
tiered star, and both statements are true of different objects
o a hub is a repeater with per-port state, NOT a multiplexer --
devices behind it do not take turns
o every device at every tier has its own address in ONE flat
address space, and the address does not encode position
THE TECHNIQUE, which the rest of this module reuses
o take the belief seriously and derive what must follow from it
o find the observation that falsifies one of those predictions
o identify the WORD that was doing two jobs
THE DEBUG CONSEQUENCE
o a wrong model produces wrong QUESTIONS, and the cost is in the
questions: "how do I get more of the hub's attention" has no
answer, and three of the four right questions are one request
THE INTERVIEW SKILL
o correct a half-true premise by naming which object the word
describes -- neither accepting it nor contradicting itThe next belief is the one that most changes what an engineer expects to see on a bus, and it survives because a mouse appears to send.
Continue learning
Related tutorials
- Related topic
“USB 3.x Is Just Faster USB 2.0”
The connector fits, the device works, the software is unchanged — so this belief has the best evidence of any in the module. There are two buses in the cable, and the differences that matter are architectural rather than numeric.
- Related topic
Cascading Hubs
The seven-tier rule is a timing constraint wearing a topology costume — and the limit applies to hubs, not to devices, which is one comparison operator almost everyone gets wrong.
- Related topic
I²C Misconceptions Engineers Still Get Wrong
Twelve wrong mental models that survive because they are right almost everywhere — each with the region that confirms it, the failure signature it uniquely produces, and the correct model. Includes a symptom-to-model table for reading a failure backwards, and why the most dangerous signatures are absences.
- 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.
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.