Skip to content
VLSI Mentor

USB · Module 4

USB 2.0 Architecture

A new rate on the same two conductors — and the compatibility bill that arrives with it. Why sharing a medium between fast and slow devices forces real silicon into every hub, what a transaction translator is doing, and compatibility as something built rather than inherited.

Chapter 4.1 established the shape of the problem. The pressure was entirely on the transport; the device model, identity framework and topology were untouched by it and worth keeping. So a second generation had a clear brief: raise the transport's capability and leave everything above it alone.

What makes USB 2.0 worth a chapter is not that it succeeded at that. It is the constraint it chose to accept while doing so — the new capability arrives on the same two conductors — and the bill that decision generated, which lands in a place most summaries never mention.

1. The Same Pair, a Third Rate

USB 2.0 adds a third signalling rate, nominally 480 Mbit/s, to the D+/D- pair Module 3 described. The two earlier rates remain. A device negotiates the fastest mode both ends support, using the chirp handshake Chapter 3.7 built, and a device that cannot do the new rate simply operates at an older one.

Note what is not here. No new conductors. No new connector requirement. No change to the device model, the identity framework, addressing, enumeration, the topology rules, or what software sees. The change is confined to one layer, which is exactly the outcome Chapter 4.1 §2 predicted from where the pressure was.

The layers of USB 2.0 compared with USB 1.x, showing which changed. The software-visible device model, the identity and configuration framework, and the host-owned transaction model are all unchanged from generation one. The transport gains a third signalling rate while remaining a single host-scheduled shared bus. The physical layer keeps the same two conductors but adds a new electrical arrangement with terminations for the higher rate. Only the lower two layers changed.Software-visible device modelunchanged from generation oneunchanged from generation oneIdentity and configurationunchanged from generation oneunchanged from generation oneHost-owned transaction modelunchanged — still one shared, host-scheduled busunchanged — still one shared, host-scheduled busTransport: a third signalling rate addedolder rates retained, not replacedolder rates retained, not replacedPhysical: same pair, new electrical arrangementterminations for the higher rate · Chapter 3.8terminations for the higher rate · Chapter 3.8
Figure 1 — generation two changes one layer. The conductors are the same ones; what changed is what may be driven on them, and the electrical arrangement required to do it.

2. Two Electrical Worlds on Two Wires

Chapter 3.8 §3 established the physical half of this and it is worth restating in generational terms, because it is the first example of a pattern that recurs.

The higher rate does not merely clock the existing arrangement faster. It uses a different electrical arrangement on the same conductors: terminations to match the cable's impedance, a much smaller differential swing, and — as Chapter 3.7 showed — the removal of the pull-up that the older arrangement depends on for its announcement mechanism.

So a single pair of conductors must support two mutually incompatible electrical configurations, and a device must be able to move between them. That is why the chirp negotiation exists at all: it is the mechanism for establishing which of two electrical worlds this particular connection will live in.

For silicon this is the first real cost of the generation. A controller supporting both is not one design with a faster clock. It is a PHY capable of two arrangements, logic that decides which applies, and a transition between them that must leave everything in a consistent state.

3. Where the Bill Actually Landed

Now the part that most treatments skip, and which makes this generation genuinely instructive.

Consider a hub operating at the new rate, with an older, slower device attached below it. Chapter 2.3 §3 established that a USB 2.0 hub forwards downstream traffic to its enabled ports. If it simply forwarded a slow device's transaction at that device's pace, the fast upstream bus would be occupied for the whole duration of a slow conversation — and slow, here, means dramatically slower. The bus's new capability would be squandered by its own compatibility.

The resolution is the transaction translator: logic inside the hub that conducts the slow-speed transaction on the downstream side, at that device's pace, while the upstream bus proceeds with other work. The hub buffers, manages both sides, and reconciles them.

Three observations make this the chapter's centre.

This is real silicon whose only purpose is compatibility. It implements no new capability. Every gate of it exists so that devices from the previous generation keep working, and it is present in every hub that must serve both.

The cost landed on a third party. The pressure came from storage and imaging devices; the new capability serves them; and the compatibility bill is paid by hub designers, who gain nothing from it. That asymmetry is characteristic — the party that pays for compatibility is frequently not the party that benefits from the new capability.

And it was a deliberate purchase. The alternative — requiring new conductors, or abandoning the old rates — would have cost more, in ecosystem terms, than the translator costs in gates. Compatibility is not inherited. It is bought, and somebody is invoiced.

4. What Multi-Mode Costs a Controller

Generalise from the hub to any implementation supporting both arrangements. Against Chapter 4.1 §5's baseline, what grows?

PHY capability. Two electrical arrangements rather than one, plus the mechanism to switch between them.

Mode state. Something must hold which arrangement is active — and, critically, that state is now an input to logic that previously had none. Chapter 3.4 already showed one consequence: line-state naming depends on the operating speed, so a decoder needs to be told.

A negotiation path. Logic that conducts the chirp handshake, which runs at attachment and after reset and therefore interacts with reset handling.

Clocking. Rates differing by this much are generally not served from one clock arrangement, so a multi-mode implementation tends to acquire additional clock domains and the crossings that come with them.

Software-visible capability. Software must be able to learn what mode a port ended up in, which means status that did not previously need to exist.

The point is the shape of the growth. None of these is a faster version of something that was already there. Each is new structure — a second arrangement, a selector, a negotiation, a reconciliation. That is what Chapter 4.5 means when it argues a generation costs more than a frequency increase.

5. What Multi-Mode Costs Verification

The configuration space acquires a dimension it did not have, and the growth is not additive.

Chapter 4.1 §5 noted that generation one had no mode dimension — one architecture, always active. Generation two introduces one, and with it three classes of case that could not previously exist.

Mode combinations. Host capability crossed with device capability, which includes a new device on an old host and an old device on a new host. These are different paths, not symmetric ones.

The negotiation itself. It runs at every attachment and can fail, and its failure mode is falling back, which must be verified to produce a working connection rather than a broken one.

Mode transitions. What happens to state when the arrangement changes. This is where the interesting bugs live, and Chapter 4.5 builds a teaching model of it.

And the compatibility silicon of §3 is its own verification problem: a translator must be exercised with a slow device below a fast hub, which means the environment needs mixed-speed topologies — precisely the configuration a single-speed test bench never constructs.

Representative cross-coverage dimensions for a multi-mode controller, stated here as a method rather than a plan:

  • host capability × device capability × resulting operating mode
  • attachment directly to a root port × attachment behind a hub of each capability
  • negotiation succeeding × negotiation failing and falling back
  • reset asserted in each mode, and mode changed after reset

Note that the first line alone is a product rather than a sum, which is the observation Chapter 4.5 generalises.

6. Common Misconceptions

7. Reason It Through

A team is costing the addition of a new, faster mode to an existing controller. The proposal estimates the work as "a faster PHY plus wider internal datapaths."

What has the estimate captured? The parts that scale — the PHY's new capability and the datapath width needed to keep up with it. These are real and they are the visible portion.

What has it missed? Everything that is new structure rather than a bigger version of existing structure: mode state that becomes an input to logic which previously had none; a negotiation path that runs at attachment and after reset; the reconciliation of state when the mode changes; additional clock domains and their crossings; and software-visible status that did not need to exist.

What has it missed outside the controller? If the design includes a hub, the compatibility logic of §3 — which serves no new capability and is therefore easy to omit from an estimate framed around the new capability.

And in verification? A dimension, not a case. The estimate's framing invites a plan that tests the new mode and the old mode, whereas what is needed is their cross product with topology, negotiation outcome and reset.

What is the general lesson? Estimate a generation by what becomes newly conditional, not by what becomes faster. Every place where logic must now ask which mode are we in is new structure with new state, new reset behaviour and new verification. The frequency increase is the part everybody sees and usually the part that costs least.

8. Understanding Check

9. Summary

USB 2.0's brief was set by where the pressure was: raise the transport's capability and leave everything above it alone. It added a third signalling rate of nominally 480 Mbit/s on the same two conductors, retained the earlier rates, and changed nothing in the device model, identity framework, addressing, enumeration, topology or software view.

The same conductors carry two mutually incompatible electrical arrangements — the higher rate needs terminations, a smaller swing, and removal of the pull-up the older arrangement depends on — which is why a negotiation exists at all: to decide which world a connection lives in.

The generation's real story is where the compatibility bill landed. A fast hub serving a slow device would otherwise occupy its upstream bus for the whole of a slow conversation, so hubs acquired the transaction translator: real silicon implementing no new capability, existing solely so older devices keep working — and paid for by hub designers, who gain nothing from the capability that created the need. Compatibility is not inherited; it is bought, and somebody is invoiced.

For silicon, the growth is new structure rather than faster structure: two PHY arrangements, mode state feeding logic that had none, a negotiation path entangled with reset, more clock domains, and new software-visible status. For verification it is a new dimension, crossing with topology, negotiation outcome and reset, and creating mixed-speed configurations a single-mode environment never builds.

10. What Comes Next

Generation two worked within a constraint: same conductors, same connector, one shared bus. Everything it cost — the two electrical arrangements, the negotiation, the translator — is the price of honouring that constraint.

Chapter 4.3 is what happens when the constraint stops being affordable. The next demand could not be met by driving the existing pair harder, so USB 3.x added conductors and ran a new architecture on them, alongside the old one rather than instead of it. That is a genuinely different kind of generational change — not a new mode on a shared medium but a second bus — and it changes the compatibility question from which arrangement is active to which of two coexisting paths is carrying this conversation.

It is also where the naming becomes difficult, because this generation was renamed more than once and the labels in circulation do not map cleanly onto the capabilities they describe.

Browse the full path on the USB tutorials index.

Continue learning

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.