A few concepts from the USB 3.x specifications are briefly summarized on this page. This an not an exhaustive description of any of the protocol's components, but rather an attempt to clarify issues in a way that will hopefully assist while reading the spec.
Another page, which shows an example of a USB 3.0 link training, may help as well.
Out-of-band signaling (LFPS)
Like several other Gigabit transceiver based protocols (e.g. PCIe and SATA), USB 3.x has a mechanism for transmitting very small pieces of information across the wires while the Gigabit transceivers are turned off. It serves mainly for synchronizing and negotiating the setup of the Gigabit links (when to transmit, at what speed and on how many lanes) and for waking up the link partner from a low-power state, but there are other uses as well.
The LFPS (Low Frequency Periodic Signaling) is based upon toggling the wires between a differential '1' and '0' at a frequency between 10 - 100 MHz (12.5 - 100 MHz for SuperSpeedPlus ports) to create an LFPS burst. Between these bursts, the transmitter issues an Electrical Idle state by holding both transmission wires at the same voltage (i.e. keeping the differential voltage below 10 mV).
The LFPS bursts are detected by the receiver as the absence of Electrical Idle. The actual purpose of toggling the wires is to keep their differential voltage away from zero in the presence of coupling capacitors (of typically 100 nF on each wire). The higher the toggling frequency, the smaller the voltage transient response when the burst transmission stops, and hence a quicker and more time-accurate detection of the burst's end at the receiver (i.e. the return to Electrical Idle). This is probably the reason why the minimal toggling frequency of LFPS is significantly higher than the PCIe beacon's (30 kHz): The PCIe protocol only relates to the presence of the beacon, while USB 3.x gives a lot of significance to the length and timing of the LFPS bursts.
The USB 3.x specifications define certain timing patterns of bursts and Electrical Idle periods for different purposes. For example, a host or hub resets its downstream link partner by generating an LFPS burst of 80-120 ms.
The LFPS patterns can be divided into three categories:
- Baseline patterns, valid for all USB 3.x ports: Polling.LFPS, Ping.LFPS, reset, and three patterns for waking up from the three low-power states.
- SCD1/SCD2 patterns, which are used by SuperSpeedPlus ports to advertise their SuperSpeedPlus capability during the link bringup negotiation. To a USB 3.0 port, these are legal Polling.LFPS patterns, with a slight timing variation pattern within the allowed range. However a SuperSpeedPlus is able to tell the difference between Polling.LFPS and SCD1/SCD2, and hence if it's facing a SuperSpeed or SuperSpeedPlus port. This mechanism was designed in the spirit of the USB 1.1 to USB 2.0 upgrade mechanism (by virtue of chirp signaling).
- LBPM patterns, which are SuperSpeedPlus only patterns. These are used during the link negotiation phase, only after both sides have verified that their link partner is a SuperSpeedPlus port by detecting SCD1/SCD2 patterns. LBPM is a simple pulse-width modulation for transmitting one 8-bit word across the link, mainly containing the lane width and speed capability of the transmitting port. This allows the negotiation of the link's attributes, and is hopefully forward compatible with future revisions of USB 3.x (there are unused bits in the word as of USB 3.2).
Power management
The USB 3.0 defines four power states:
- U0: The Gigabit link is up, and data packets are allowed for transmission.
- U1: The Gigabit link is down, and only LFPS signaling is available for staying in this state or waking up to U0. Intended for invocation after a period of link inactivity.
- U2: Like U1, but with more power saving opportunities allowed at the expense of a longer recovery time. Intended for a deeper sleep after a longer period of inactivity.
- U3: Device suspend.
In principle, the invocation of U1 and U2 should take place as a result of inactivity in the Gigabit link. U3, on the other hand, is invoked per request by the host's software, possibly by the operating system's decision. U3 is similar to USB 2.0's suspend state.
Any of the ports may initiate the return to U0 (through the "Recovery" state) from any power state by virtue of an LFPS handshake.
A quick overview of these states follows. For a deeper look, refer to this page on invoking low-power states, and this one on exiting from them.
The transition into U1 and U3 is always from U0. U2 is normally entered as a result of a timeout condition from U1, but can be entered directly from U0 as well, but it's not the common scenario.
From an physical layer point of view, U1 and U2 differ in that upstream ports send Ping.LFPS signals only when in U1 (LFPS bursts of 40-200 ns every 160-240 ms). Note that this goes only in one direction, so in a plain device-host link only the device sends Ping.LFPS during U1. Also, the transmitter of a port in U1 is required to maintain the common voltage of its differential lines, but not when in U2 (which may slow down the LFPS detection on the other side if and when it's transmitted for a wakeup).
While in U0, either one of the link's two ports can request a transition to any of U1 and U2 states, typically as an inactivity timer expires (the spec defines two parameters, PORT_U1_TIMEOUT and PORT_U2_TIMEOUT, for this purpose). Only the host (or a hub on its behalf) may issue a request for U3.
Several Link Commands are defined for use on the Gigabit link for negotiating the power state: LGO_U1, LGO_U2, LGO_U3, LAU, LXU, and LPMA are the link commands used for link power management. The first three are requests to enter the respective power levels. LAU acknowledges an LGO_Ux request, and LXU rejects it. LPMA acknowledges LAU (it's a three-way handshake, but the power level transition works even if the LPMA is lost, only slightly slower).
LGO_U1 and LGO_U2 can be rejected, even repeatedly in a permanent manner: A port is not required to be U1/U2 capable, and may refuse to requests as well as never initiating these states. An exception is when a Set Link Function packet is sent across a link with the Force_LinkPM_Accept bit set, which disallows such rejection by the packet's recipient until a cancellation by virtue of a similar packet with Force_LinkPM_Accept bit cleared.
LGO_U3 must be acknowledged however. The power mode is entered anyhow on timeout if an LAU isn’t received.
Hubs, power management, and Deferred Packets
A hub employs power management with its downstream ports with the same rules as a root port: The same timeouts and initiated mechanisms apply, with the difference that a request for a low power mode from the host is mediated by the hub.
A hub's upstream port is not allowed to leave the U0 state in favor of a lower power state if any of its downstream ports is in the U0 state: The hub itself never adds wakeup delays if the end device is awake.
However if the device is in U1 or U2, and a packet arrives for this device, it must be waken up, and that takes time, during which the transaction can't be completed. To allow the host to continue other transactions rather than waiting, the hub echoes the header packet back to its upstream port with the Deferred bit (DF) set, turning the packet into a Deferred Header Packet. This tells the host that the packet couldn't be delivered, which makes the host react as if a NRDY response was received for this header packet. In other words, as if the device said it couldn't handle it at the moment. Accordingly, the host expects an ERDY packet to arrive before re-sending the Header Packet.
To make this happen, the hub sends the same Deferred Header Packet that went to the host to the device as well, once it's up in the U0 state, which basically means "I've sent an equivalent to an NDRY on your behalf to this request". The device responds by sending an ERDY on the relevant request when it's ready for it, and remains in U0 until the packet arrives.
This issue is explained in Appendix section C.1.2.2 of the USB spec 3.1 (but was deleted afterwards).
And since we're at it: The Delayed Bit (DL) is set by any entity that handles a header packet if it's delayed for any reason (as listed in the spec's section 7.2.4.1.2: Being re-sent, the link was in Recovery, lack of credits for transmission, or non-empty transmission buffers). This bit has no significance unless it's an ITP packet, whose time of traversal is measured.
LTSSM Link bringup states
This is a crude outline LTSSM (Link Training and Status State Machine), focusing on the essence of each state rather on its details. The LTSSM's behavior, as defined in the USB 3.x specification is lengthy and complicated, and a lot of fine details and possible state transitions are omitted below.
If you're reading this while trying to debug a USB 3.x link, there's a good chance that the problem is among the issues not appearing here.
- SS.Disabled: This state is reached when the USB 3.x subsystem in the absence of a USB 3.x counterpart, either because nothing is connected or there's no USB 3.x support on the other side.
- SS.Inactive: This state is reached when the USB 3.x subsystem is off because a USB 3.x partner has been detected, but something went horribly wrong. It's left when a disconnection is sensed or a reset form the host.
- Rx.Detect: The port periodically performs a simple electrical check to sense if there's something connected to it (similar to PCIe). This check consists of applying a small voltage ramp on both wires of the transmitter, and measure the resulting current pulse (through the coupling capacitors and possibly the port on the other side). Note that a purely differential termination (as in e.g. SFP+ fiber optic transceivers) will not pass this test, but most Gigabit transceivers will. This is the powerup state for any port, and is also invoked after a disconnection, a Warm Reset, and some other types of resets. If and when a receiver is detected on the other side, the Polling state is invoked.
One somewhat peculiar thing is that when a downstream port invokes this state on powerup, it issues a Warm Reset LFPS signal (a burst of 80-120 ms) before attempting any detection, and never again afterwards. This Warm Reset is not applied by the LTSSM when a device is hotplugged after the powerup and is therefore not comparable with USB 2.0's Host Reset (even though the host's software may request a Warm Reset on the port at which a device has been just detected). - Polling: Bring up the Gigabit link. This is the most complicated state, having a lot of substates and a different flow for SuperSpeed and SuperSpeedPlus. Polling.LFPS, SCD1/SCD2 and LBPM patterns are exchanged between the ports as applicable to negotiate the link's attributes. At the next stage, the Gigabit transceivers are enabled, transmitting a pattern for training the other port's equalizer (TSEQ ordered set) for a certain period of time. Following this, TS1 and TS2 ordered sets are transmitted as a handshake to finalize the link training, and possibly request a diversion from the regular setup (e.g. start loopback mode or turn of the scrambler). When all this is done, the next state is U0.
- U0, U1, U2, U3: See section on Power Management above.
- Recovery: This state is invoked from the low-power states U1, U2 and U3 for bringing the Gigabit link up again, and in other situations where the link needs to be re-established (e.g. after an error in U0 mode, or when a TS1 ordered set it received, which may indicate that the link partner has switched to Recovery due to an error). Like in the Polling state, a TS1 and TS2 ordered sets handshake is performed, after which U0 is invoked. The final stage of the Recovery state is resynchronizing the flow control and retransmission counters, as well as the retransmission of any Header Packets that were lost in the course of enterting Recovery or a low-power state. The Recovery state can theoretically last as long as ~19 ms, but typically takes no more than 1-2 us.
- Hot Reset: This state is invoked when the host (or a hub on its behalf) sends a TS2 ordered set with the Hot Reset bit set. After a quick handshake mechanism with the Hot Reset bits, both sides return to U0. The effect of a Hot Reset is clearing the link error count, U1/U2 timers etc. as well as resetting the device's address back to zero and clearing some configuration parameters.
These two states are normally not reached:
- Compliance: The Compliance state is intended for compliance lab tests, and is invoked from Polling when it has failed to detect Polling.LFPS signaling for 360 ms. All upstream facing ports are required to invoke this state on this condition, and downstream ports may do so if instructed so by software. The rationale is to make lab testing easier: When a device is attached to a lab equipment, the latter doesn't need to support any LFPS signal, but only receive the predefined data pattern (actually, it can switch between several patterns). This state is never reached on normal operation, in particular not by USB ports belonging to a host (computer), since this state shouldn't be enabled by the operating system. But if this happens on a regular host-device connection, it means that the other side is completely irresponsive.
- Loopback: Set the transceiver to loop the data arriving at the receiver to the transmitter. Intended for testing. This state is invoked from the Polling or Recovery states if so required in the relevant bit of the received TS2 ordered set.
Reasons for switching to Recovery
There are several reasons for entering the Recovery state, some of which are summarized in Table 7-11 of the USB 3.0 spec. This is a list of them, along with references to the USB 3.0 spec.
- Detecting a TS1 ordered set from link partner, i.e. the link partner engages Recovery (7.5.6.2)
- "When directed" (7.5.6.2), in particular for Hot Reset (7.5.10)
- Wakeup from low-power state (7.2.4.2.7, 7.4.2, 7.5.7.2, 7.5.8.2, and 7.5.9.2)
- LGOOD_n mismatch with expected (Table 7-5, 7.2.4.1.2, 7.2.4.1.7, 7.3.4 and 7.3.5)
- LCRD_x mismatch with expected (Table 7-5, 7.2.4.1.2, 7.2.4.1.8 and 7.3.4)
- Out of order Header Sequence Number (7.2.4.1.4 and 7.3.3.3)
- No Rx Header Buffer available to store arriving Header Packet (7.2.4.1.4)
- Failing to receive a Header Packet three consecutive times (7.2.4.1.4 and 7.3.3.2)
- PENDING_HP_TIMER = 3μs times out (header packet sent to ack arrived) (7.2.4.1.1 and 7.3.6)
- No LAU or LXU response is received within PM_LC_TIMER = 3μs timeout from LGO_Ux request (7.2.4.2.3, Table 7-8 and 7.3.4)
- Timeout of any link commands (LUP / LDN in particular) for 1 ms (tU0RecoveryTimeout) (7.3.4 and 7.5.6.2)
- Header Packet received before sending Header Sequence Number Advertisement (7.3.6)
- LCRD_x or LGO_Ux received before receiving Header Sequence Number Advertisement (7.3.6)
- No LCRD_x causing CREDIT_HP_TIMER timeout (7.3.7)
- A header packet received before sending LCRD_x (7.3.7)
- LGO_Ux received before receiving LCRD_x (7.3.7)
