USB Physical Layer, Topology and Speed Guide

USB becomes confusing when one logo is asked to describe five different things. A Type-C port can carry USB 2.0 only; a fast cable may connect to a slow device; a USB4-capable host may negotiate a lower mode through a hub. The engineering answer is to identify each layer and then follow the negotiated path end to end.

Quick speed reference

• Low-Speed: 1.5 Mbit/s, introduced with early USB and used by simple devices.

• Full-Speed: 12 Mbit/s, defined by USB 1.x and retained in later compatibility.

• High-Speed: 480 Mbit/s, added by USB 2.0.

• USB 5Gbps: the 5 Gbit/s signaling introduced as USB 3.0 and later incorporated into USB 3.2.

• USB 10Gbps: a 10 Gbit/s USB 3.2 signaling mode.

• USB 20Gbps: USB 3.2 two-lane operation at an aggregate 20 Gbit/s.

• USB 40Gbps / USB 80Gbps: USB4 performance levels over capable USB Type-C hosts, devices, and cables. USB4 v2 adds higher-rate and optional asymmetric operation defined by its specification.

Version, speed, connector, cable and power are separate

• Specification/version: defines protocol capabilities and compliance requirements (USB 2.0, USB 3.2, USB4).

• Performance level: the signaling rate actually supported/advertised (for example USB 10Gbps).

• Connector: Type-A, Type-B variants, Micro-B, or USB Type-C physical mating form.

• Cable: passive/active construction, supported lanes/rate, current rating, length, and optional identity/e-marker information.

• Alternate/tunneled protocols: DisplayPort/PCIe and other capabilities require support at both ends and in the path; Type-C shape alone promises none.

• Power: legacy USB power/current rules, USB Type-C current advertisement, and USB Power Delivery negotiation are related but distinct from data speed.

A useful layer model

Application / class protocol (storage, HID, audio, video, vendor)
                    ↓
USB transfers and endpoints (control, bulk, interrupt, isochronous)
                    ↓
Host controller + OS USB core + device/class driver
                    ↓
USB protocol/link (USB 2.0, USB 3.2, USB4 routing/tunneling)
                    ↓
PHY signaling lanes, cable, connectors, hubs/retimers
                    ↓
Power, ground, signal integrity and negotiated capabilities

What this model prevents

• A filesystem benchmark cannot by itself prove a PHY problem; storage media and software layers sit above the link.

• A detected Type-C attachment does not prove SuperSpeed lanes, USB4, video, or a particular power contract.

• A kernel driver error can occur after flawless electrical link training and enumeration.

• Start with observable negotiation/topology, then test one layer at a time rather than replacing random cables and drivers simultaneously.

USB 2.0 and SuperSpeed use different physical resources

USB 2.0 path
  VBUS ───────── power
  D+ / D- ══════ bidirectional differential data pair
  GND  ───────── return/reference
 
SuperSpeed path (in addition to compatibility conductors where provided)
  TX+ / TX- ════ transmit differential pair
  RX+ / RX- ════ receive differential pair
  extra lane(s) may be used for higher aggregate modes
 
USB Type-C also provides CC/orientation and other pins; exact routing depends
on cable, orientation, negotiated mode and product design.

Electrical takeaways

• USB 2.0 uses a shared bidirectional D+/D− path and host-scheduled transactions.

• SuperSpeed adds separate transmit/receive differential paths, enabling simultaneous link directions and higher-rate physical techniques.

• USB 3.2 two-lane performance requires both lanes throughout the host, cable, intermediary, and device path.

• Type-C orientation handling and lane mapping are hardware/PHY responsibilities; this diagram must not be used as a PCB pinout.

• Impedance, insertion loss, return loss, skew, crosstalk, connectors, vias, ESD components, and reference planes all matter at high rates. Follow the exact specification and compliance guidance.

USB is a host-controlled tiered star

Host CPU / operating system
└── Host controller (xHCI on many modern systems)
    └── Root hub
        ├── Device / function
        └── External hub
            ├── Device / function
            └── External hub
                └── Composite device
                    ├── Interface: audio
                    └── Interface: controls

Topology rules and terminology

• The host initiates/schedules USB communication. Devices do not arbitrate a peer-to-peer bus like independent network hosts.

• The host controller implements host-side transfer machinery; its integrated root hub presents attachment ports.

• A hub adds downstream ports and participates in connection/speed/power management; bandwidth remains constrained by upstream links and scheduling.

• A device can expose one or more configurations, each containing interfaces and alternate settings. A composite device exposes multiple logical functions/interfaces through one address.

• The USB 2.0 topology limit is seven tiers including the root tier, allowing at most five non-root hubs between host and function because the function occupies the final tier. Do not blindly apply that sentence to every USB4 routing design.

• USB uses a 7-bit device address space with address zero reserved during default/enumeration; practical limits are also bounded by hubs, bandwidth, power, host resources, and software.

Enumeration: from attachment to a bound driver

1. A port detects attachment and determines initial electrical/speed conditions.

1. The hub/host resets and enables the port; the device initially responds at the default address.

1. The host reads enough of the device descriptor/control endpoint information to continue.

1. The host assigns a unique address for that bus.

1. The host reads device, configuration, interface, endpoint, string, BOS/class-specific and other relevant descriptors.

1. Policy/software chooses a configuration and drivers bind to matching interfaces.

1. The application communicates through the class/vendor driver or authorized user-space API.

Descriptors describe; they do not prove

• Vendor ID/product ID identify the vendor/product namespace but are not cryptographic identity.

• bcdUSB reports the USB specification level declared by a device descriptor; it is not a benchmark result.

• Configuration bMaxPower and Type-C/PD state are related evidence at different protocol layers; one field does not describe every power possibility.

• Malformed, inconsistent, or overly large descriptors are untrusted device input. Host stacks and diagnostic tools must parse defensively.

• A driver often binds to an interface, not necessarily the entire physical device.

Endpoints, pipes and transfer types

• Endpoint 0/control: every USB device provides the default control endpoint for enumeration and standard/class/vendor requests.

• Bulk: reliable, bandwidth-leftover transfers such as mass storage; latency/throughput are not reserved.

• Interrupt: bounded-service polling for small latency-sensitive data such as HID events; it is host-scheduled, not a device interrupt wire.

• Isochronous: time-sensitive streaming with reserved scheduling characteristics and no retry guarantee like bulk; used by audio/video workloads.

• Endpoint direction is named from the host’s perspective: IN moves device→host, OUT moves host→device. Endpoint address combines number and direction.

• A host-side pipe represents the communication relationship with an endpoint and carries scheduling/type/control context.

How speed is negotiated through a real path

The usable mode is bounded by the host port/controller, every hub/dock/retimer, both connectors, the cable/e-marker/lanes, and the device. A USB 80Gbps-labeled cable cannot make a USB 5Gbps device faster, and a charge-only or USB 2.0 Type-C cable can make a fast-looking port behave like a slow data link.

• Check that the device connected to the expected physical port and host controller.

• Check every intermediary: dock, monitor hub, KVM, adapter, extension, front-panel header, and captive cable.

• Confirm cable data capability, rate, lane support, length, current rating, certification markings, and active-cable direction/requirements.

• Observe the negotiated speed/topology in the operating system, not only product packaging.

• Benchmark with a workload capable of saturating the link and separate read/write, queue depth, file cache, device media, and protocol overhead.

Power delivery does not imply data capability

• VBUS powers devices/charging paths, but available current/power depends on the applicable USB/Type-C/PD rules and negotiation.

• USB Type-C Configuration Channel (CC) handles attachment/orientation and current-role/capability signaling; USB PD exchanges structured power/role/alternate-mode messages.

• A cable can support high charging power with limited data, or high-rate data with a power rating below another cable. Read both markings/specifications.

• Bus-powered hubs share upstream power among hub electronics and downstream ports unless separately powered; brownouts/re-enumeration can look like data errors.

• Never probe or inject VBUS/CC/data lines without appropriate equipment and understanding. Incorrect power experiments can damage devices or create a safety hazard.

Inspect USB topology on Linux

$ lsusb
lsusb -t
lspci -nnk | grep -A3 -i usb

What these three views reveal

• lsusb lists currently enumerated devices by bus/address and descriptor IDs. Bus/device numbers can change after reconnect.

• lsusb -t renders the tree, negotiated speeds, interfaces, and bound drivers—usually the best first check for an unexpected 480M/5000M link.

• lspci -nnk exposes PCI USB host controllers and kernel drivers on typical PC-class Linux systems; embedded SoCs may expose controllers differently.

• A displayed Mbit/s value is negotiated bus speed, not current utilization or application throughput.

• Capture output before and after changing one cable/port so the topology difference is attributable.

Read descriptors for one authorized device

$ lsusb -d 1234:5678
sudo lsusb -v -d 1234:5678

Replace the example identifier

• 1234:5678 is a placeholder vendor:product ID. Copy the exact ID from the unprivileged lsusb output.

• -v requests verbose descriptors; some control reads need privileges or can be limited by a bound driver/device behavior.

• Descriptor strings and serial numbers can identify people/devices. Redact before sharing and avoid collecting unrelated hardware inventory.

• Do not infer authenticity or safety from vendor/product strings; USB devices control much of the descriptor data they return.

Watch connection and driver events

$ sudo journalctl -kf
# In another terminal, optionally watch udev events:
udevadm monitor --kernel --property --subsystem-match=usb

Correlate one physical action

• journalctl -kf follows kernel messages; start immediately before one authorized unplug/replug and stop promptly.

• Look for disconnect/reset loops, descriptor-read errors, negotiated speed, address assignment, interface drivers, over-current, and controller messages.

• udevadm monitor shows kernel uevents/properties, not raw USB packets. It helps distinguish enumeration from user-space device-node policy.

• Logs may include serial numbers and other identifiers. Store and share them according to incident/privacy policy.

Common symptoms and likely layers

• Type-C device charges but no data: cable may be power-only/limited, port data disabled, role/CC negotiation failed, or device/driver did not enumerate.

• Expected 10/20/40/80Gbps but tree shows 480M: path fell back to USB 2.0; inspect cable, orientation/connector damage, hub/dock, port lanes, and host/device capability.

• Tree shows high speed but copy is slow: investigate protocol, storage media, filesystem/cache, queue depth, encryption, CPU, errors, and workload.

• Repeated disconnect/reset: suspect power droop, marginal cable/connectors/signal integrity, hub/retimer/firmware, controller/driver, or device fault. Change one element at a time.

• Device enumerates but application gets permission denied: this is OS access policy/udev/interface ownership, not physical link training.

• Device busy: a kernel or user-space driver owns the interface. Identify it before detaching or replacing drivers.

• Too many devices/resource errors: inspect hub depth, address/resources, bandwidth scheduling, power budgets, controller limits, and OS logs.

Design and debugging checklist

• State the required connector, USB data rate, protocol/class, power roles/range, cable assumptions, and alternate modes separately.

• Select certified components and follow USB-IF electrical/layout/compliance specifications; this conceptual guide is not a compliance design rulebook.

• Test all supported cable orientations, ports, hubs/docks, suspend/resume, hotplug, brownout, role swaps, and backward-compatible speeds.

• Instrument VBUS and high-speed signals only with suitable bandwidth/probes/fixtures so measurement does not become the failure.

• Capture protocol traffic at the right layer: usbmon/host controller traces show transfers; a PHY analyzer is needed for link/electrical failures.

• Verify graceful behavior for malformed descriptors, stalls/timeouts, disconnect mid-transfer, short packets, and device reset.

Related USB guides

• Use usbutils and lsusb on Ubuntu for descriptor/topology inspection.

• Develop user-space device tools with building and using libusb.

• Capture host-level transfers with Linux usbmon and Wireshark.

Primary references

• USB-IF’s USB data-performance language guide defines consumer names for USB 5/10/20/40/80Gbps.

• USB-IF explains USB 3.2 5/10/20 Gbit/s modes and two-lane operation.

• USB-IF’s USB4 overview covers Type-C, two-lane architecture, and up-to-80-Gbit/s capability.

• The Linux kernel’s USB host-side documentation describes topology, descriptors, interfaces, endpoints, and speed reporting.