USB Specification

USB 3.0 Specifications – Protocol Layer

USB 3.0 Specifications – Protocol Layer

The protocol layer manages the end to end flow of data between a device and its host. This layer is built on the assumption that the link layer guarantees delivery of certain types of packets and this layer adds on end to end reliability for the rest of the packets depending on the transfer type.

Here we will discuss the following concepts in detail:

  • Types of packets
  • Format of the packets
  • Expected responses to packets sent by the host and a device
  • The four SuperSpeed transaction types
  • Support for Streams for the bulk transfer type
  • Timing parameters for the various responses and packets the host or a device may receive or
  • Transmit

IMAGE 1

SuperSpeed Transactions

SuperSpeed transactions are initiated by the host when it either requests or sends data to an endpoint on a device and are completed when the endpoint sends the data or acknowledges receipt of the data. A transfer on the SuperSpeed bus is a request for data made by a device application to the host which then breaks it up into one or more burst transactions. A SuperSpeed host may initiate one or more OUT bus transactions to one or more endpoints while it waits for the completion of the current bus transaction. However a SuperSpeed host shall not initiate another IN bus transaction to any endpoint until the host either:

  • Receives a DP or NRDY or STALL TP or the transaction times out for the current ACK TP sent to a non-isochronous endpoint.
  • Receives all the DPs that were requested or it receives a short packet or it receives a DP with last packet flag field set or the transaction times out for the current ACK TP sent to an isochronous endpoint.

For non-isochronous transfers, an endpoint may respond to valid transactions by:

  • Returning an NRDY Transaction Packet
  • Accepting it by returning an ACK Transaction Packet in the case of an OUT transaction
  • Returning one or more data packets in the case of an IN transaction
  • Returning a STALL Transaction Packet if there is an internal endpoint error

An NRDY Transaction Packet (TP) response indicates that an endpoint is not ready to sink or source data. Consequently, there shall be no further activity between the host and the endpoint on the device until the endpoint notifies the host that it is ready. This allows the links between the device and the host to be placed in a reduced power state until an endpoint is ready to receive or send data. When ready, the endpoint asynchronously sends a notification (ERDY TP) to the host to tell it that it is now ready to move data and the host responds by rescheduling the request. Isochronous transfers do not use ERDY or NRDY TPs as they are serviced by the host at periodic intervals. Additionally, data packets sent to or received from an isochronous endpoint are not acknowledged, i.e., no ACK TPs are sent to acknowledge the receipt of data packets.

Endpoints only respond to requests made by the host. The host is responsible for scheduling transactions on the bus and maintaining the priority and fairness of the data movement on the bus; it does this by the timing and ordering of IN and OUT requests. Transactions are not broadcast; packets traverse a direct path between the host and device. Any unused links may be placed into reduced power states making the bus amenable to aggressive power management.

Packet Types

SuperSpeed USB uses four basic packet types each with one or more subtypes. The four packet types are:

  • Link Management Packets (LMP) only travel between a pair of links (e.g., a pair of directly connected ports) and is primarily used to manage that link.
  • Transaction Packets (TP) traverse all the links directly connecting the host to a device. They are used to control the flow of data packets, configure devices, and hubs, etc. Transaction Packets have no data payload.
  • Data Packets (DP) traverse all the links directly connecting the host to a device. Data Packets have two parts: a Data Packet Header (DPH) and a Data Packet Payload (DPP).
  • Isochronous Timestamp Packets (ITP) are multicast on all the active links from the host to one or more devices.

All packets consist of a 14-byte header, followed by a 2-byte Link Control Word at the end of the packet (16 bytes total). All headers have two common fields (Revision and Type) that are used by the receiving entity (e.g., host, hub, or device) to determine how to process the packet. All headers include a 2-byte CRC (CRC-16). Packet headers have an uncorrectable or undetectable error rate less than one error in 1020 bits.

All devices (including hubs) and the host consume the LMPs they receive. Hubs have the additional responsibility to forward DPs, ITPs, and TPs to the downstream port nearer a device or to the upstream port nearer the host. ITPs are only sent by the host and received by devices. All packets except LMPs are forwarded by hubs unless the packet is routed to the hub itself. The Link Control Word in a TP, ITP, or DPH may be changed by a hub before it is forwarded.

If the value of the Type field is Transaction Packet or Data Packet Header, the Route String and Device Address fields follow the Type field. The Route String field is used by hubs to route packets which appear on their upstream port to the appropriate downstream port. Packets flowing from a device to the host are always routed from a downstream port on a hub to its upstream port. The Device Address field is provided to the host so that it can identify the source of a packet. All other fields are discussed further in this chapter.

IMAGE 2

Data Packets include additional information in the header that describes the data block. The Data Block is always followed by a 4-byte CRC-32 used to determine the correctness of the data. The Data Block and the CRC-32 together are referred to as the Data Packet Payload.

Packet Formats

Here we will define the SuperSpeed packets. It defines the fields that make up the various packet type and subtypes.

Packet byte and bit definitions are described in an un-encoded data format. The effects of symbols added to the serial stream (i.e., to frame packets or control or modify the link), bit encoding, bit scrambling, and link level framing have been removed for the sake of clarity. Refer to Chapters 6 and 7 for detailed information. In cases where bus performance, efficiency, or timing are discussed, the effects of these lower level operations will be discussed to provide additional context.

Fields Common to all Headers

All SuperSpeed headers start with the Type field that is used to determine how to interpret the packet. At a high level this tells the recipient of the packet what to do with it: either to use it to manage the link or to move and control the flow of data between a device and the host.

Reserved Values and Reserved Field Handling

Reserved fields and Reserved values shall not be used in a vendor-specific manner.

A transmitter shall set all Reserved fields to zero and a receiver shall ignore any Reserved field.

A transmitter shall not set a defined field to a reserved value and a receiver shall ignore any packet that has any of its defined fields set to a reserved value. Keep in mind that the receiver shall acknowledge the packet and return credit for the same.

Type Field

The Type field is a 5-bit field that identifies the format of the packet. The type is used to determine how the packet is to be used or forwarded by intervening links.

IMAGE 3

CRC-16

All header packets have a 16-bit CRC field. This field is the CRC calculated over the preceding 12 bytes in the header packet.

Link Control Word

IMAGE 4

Link Control Word Format

IMAGE 5

Link Management Packet (LMP)

Packets that have the Type field set to Link Management Packet are referred to as LMPs. These packets are used to manage a single link. They carry no addressing information and as such are not routable. They may be generated as the result of hub port commands. For example, a hub port command is used to set the U2 inactivity timeout. In addition, they are used to exchange port capability information and testing purposes.

IMAGE 6

Subtype Field

The value in the LMP Subtype field further identifies the content of the LMP.

IMAGE 7

Set Link Function

The Set Link Function LMP shall be used to configure functionality that can be changed without leaving the active (U0) state.

Upon receipt of a LMP with the Force_LinkPM_Accept bit asserted, the port shall accept all LGO_U1 and LGO_U2 Link Commands until the port receives a LMP with the Force_LinkPM_Accept bit de-asserted.

Improper use of the Force_LinkPM_Accept functionality can impact the performance of the link significantly. This capability shall only be used for compliance and testing purposes. Software must ensure that there are no pending packets at the link level before issuing a SetPortFeature command that generates an LGO_U1 or LGO_U2 link command.

This LMP is sent by a hub to a device connected on a specific port when it receives a SetPortFeature (FORCE_LINKPM_ACCEPT) command.

IMAGE 8

Set Link Function

IMAGE 9

U2 Inactivity Timeout

The U2 Inactivity Timeout LMP shall be used to define the timeout from U1 to U2 or the timeout from U0 to U2 if the U1 Inactivity Timeout is disabled.

IMAGE 10

U2 Inactivity Timer Functionality

IMAGE 11

Vendor Device Test

Use of this LMP is intended for vendor-specific device testing and shall not be used during normal operation for the link.

IMAGE 12

Vendor Specific Device Text Function

IMAGE 13

Port Capabilities

The Port Capability LMP describes each port’s link capabilities and is sent by both link partners after the successful completion of training and link initialization. All ports shall send this LMP within tPortConfiguration time after completion of link initialization.

If a link partner does not receive this LMP within tPortConfiguration time then:

  • If the link partner has downstream capability, it shall signal an error.
  • If the link partner only supports upstream capability, then the upstream port shall transition to SS.Disabled and it shall try to connect at the other speeds this device supports.

IMAGE 14

Port Capability LMP Format

IMAGE 15

After exchanging Port Capability LMPs, the link partners shall determine which of the link partners shall be configured as the downstream facing port.

Port Type Selection Matrix

IMAGE 16

Port Configuration

Here we will only discuss the fields that are different from the Port Capability LMP.

All SuperSpeed ports that support downstream port capability shall be capable of sending this LMP.

If the port that was to be configured in the upstream facing mode does not receive this LMP within tPortConfiguration time after link initialization, then the upstream port shall transition to SS.Disabled and it shall try and connect at the other speeds this device supports.

IMAGE 17

Port Configuration LMP Format (Differences with Port Capability LMP)

IMAGE 18

A port configured in the downstream mode shall send the Port Configuration LMP to the upstream port. The port sending this LMP shall select only one bit for the Link Speed field.

If a downstream capable port cannot work with its link partner, then the downstream capable port shall signal an error.

Port Configuration Response

This LMP is sent by the upstream port in response to a Port Configuration. It is used to indicate acceptance or rejection of the Port Configuration LMP. Here we will only discuss the fields that are different from the Port Capability LMP.

All SuperSpeed ports that support upstream port capability shall be capable of sending this LMP. If the downstream port does not receive this LMP within tPortConfiguration time, it shall signal an error.

IMAGE 19

Port Configuration LMP Format (Differences with Port Capability LMP)

IMAGE 20

If the Response Code indicates that the Link Speed was rejected by the upstream port, the downstream port shall signal an error.

Transaction Packet (TP)

Transaction Packets (TPs) traverse the direct path between the host and a device. TPs are used to control data flow and manage the end-to-end connection. The value in the Type field shall be set to Transaction Packet. The Route String field is used by hubs to route a packet that appears on its upstream port to the correct downstream port. The route string is set to zero for a TP sent by a device. When the host sends a TP, the Device Address field contains the address of the intended recipient. When a device sends a TP to the host then it sets the Device Address field to its own address. This field is used by the host to identify the source of the TP. The SubType field in a TP is used by the recipient to determine the format and usage of the TP.

Transaction Packet Subtype Field

IMAGE 21

Acknowledgement (ACK) Transaction Packet

This TP is used for two purposes:

  • For IN endpoints, this TP is sent by the host to request data from a device as well as to acknowledge the previously received data packet.
  • For OUT endpoints, this TP is sent by a device to acknowledge receipt of the previous data packet sent by the host, as well as to inform the host of the number of data packet buffers it has available after receipt of this packet.

IMAGE 22

ACK TP Format

IMAGE 23

Not Ready (NRDY) Transaction Packet

This TP can only be sent by a device for a non-isochronous endpoint. An OUT endpoint sends this TP to the host if it has no packet buffer space available to accept the DP sent by the host. An IN endpoint sends this TP to the host if it cannot return a DP in response to an ACK TP sent by the host.

Here we only discuss the fields that are different from an ACK TP.

IMAGE 24

NRDY TP Format (Differences with ACK TP)

IMAGE 25

Endpoint Ready (ERDY) Transaction Packet

This TP can only be sent by a device for a non-isochronous endpoint. It is used to inform the host that an endpoint is ready to send or receive data packets.

IMAGE 26

ERDY TP Format (Differences with ACK TP)

IMAGE 27

STATUS Transaction Packet

This TP can only be sent by the host. It is used to inform a control endpoint that the host has initiated the Status stage of a control transfer. This TP shall only be sent to a control endpoint.

STATUS TP Format (Differences with ACK TP)

IMAGE 28

STALL Transaction Packet

This TP can only be sent by an endpoint on the device. It is used to inform the host that the endpoint is halted or that a control transfer is invalid.

IMAGE 29

STALL TP Format (Differences with ACK TP)

IMAGE 30

Device Notification (DEV_NOTIFICATION) Transaction Packet

This TP can only be sent by a device. It is used by devices to inform the host of an asynchronous change in a device or interface state, e.g., to identify the function within a device that caused the device to perform a remote wake operation. This TP is not sent from a particular endpoint but from the device in general.

IMAGE 31

Device Notification TP Format (Differences with ACK TP)

IMAGE 32

Function Wake Device Notification

IMAGE 33

IMAGE 34

Latency Tolerance Message (LTM) Device Notification

Latency Tolerance Message Device Notification is an optional normative feature enabling more power efficient platform operation.

IMAGE 35

IMAGE 36

Bus Interval Adjustment Message Device Notification

IMAGE 37

IMAGE 38

Function Wake Notification

A function may signal that it wants to exit from device suspend (after transitioning the link to U0) or function suspend by sending a Function Wake Device Notification to the host if it is enabled for remote wakeup.

Latency Tolerance Messaging

Latency Tolerance Messaging is an optional normative USB power management feature that utilizes reported BELT (Best Effort Latency Tolerance) values to enable more power efficient platform operation.

The BELT value is the maximum time (factoring in the service needs of all configured endpoints) for leaving a device without service from the host. Specifically, the BELT value is the time between the host’s receipt of an ERDY from a device, and the host’s transmission of the response to the ERDY.

Devices indicate whether they are capable of sending LTM TPs using the LTM Capable field in the SUPERSPEED_USB Device Capability descriptor in the BOS descriptor. The LTM Enable feature selector enables or disables an LTM capable device to send LTM TPs.

Optional Normative LTM and BELT Requirements

General Device Requirements

  • LTM TPs shall be originated only by peripheral devices.
  • LTM TPs apply to all endpoint types except for isochronous endpoints.
  • Once a BELT value has been sent to the host by a device, all configured endpoints for that device shall expect to be serviced within the specified BELT time.
  • A device shall send an LTM TP with a value of tBELTdefault in the BELT field in response to any change in state of LTM Enable within tMinLTMStateChange.
  • A device shall ensure that its BELT value is determined frequently enough that it is able to provide reasonable estimate of the device’s service latency tolerance prior to its need to change
  • BELT value. In addition, the following conditions shall be met:

o   The maximum number of LTM TPs is bounded by tBeltRepeat.

o   Each LTM TP shall have a different BELT value.

  • The system shall default to a BELT of 1 ms for all devices.
  • The minimum value for a BELT is 125 μs.

Device Requirements Governing Establishment of BELT Value

  • The LTM mechanism shall utilize U1SEL and U2SEL to provide devices with system latency information. In this context, the system latency is the time between when a device transmits an ERDY and when it will receive a transaction packet (type is direction-specific) from the host when the deepest allowed link state is U1 or U2. These values are used by the device to properly adjust their BELT value, factoring in their location within the USB link topology.

o   Devices that allow their link to enter U1, but not U2, shall subtract the U1 System Exit Latency (U1SEL) from its total latency tolerance and send the resultant value as the BELT field value in an LTM TP.

o   Devices that allow their link to enter U1 and U2 shall subtract U2SEL from its total latency tolerance and send the resulting value as the BELT field value in an LTM TP.

Bus Interval Adjustment Message

This device notification may be sent by a device to request an increase or decrease in the length of the bus interval. This would typically be used by a device trying to synchronize the host’s bus interval clock with an external clock. Bus interval adjustment requests are relative to the current bus interval. For example, if a device requests an increase of one BusIntervalAdjustmentGranularity unit and then later requests an increase of two BusIntervalAdjustmentGranularity units the overall increase by the host would be three BusIntervalAdjustmentGranularity units.

The host shall support adjustments through an absolute range of -37268 to 37267 BusIntervalAdjustmentGranularity units. A device shall not request adjustments more than once every eight bus intervals. A device shall not send another bus interval adjustment request until it has waited long enough to accurately observe the effect of the previous bus interval adjustment request on the timestamp value in subsequent ITPs. A device shall not make a single BusIntervalAdjustment request for more than ±4096 units. A device may make multiple BusIntervalAdjustment requests over time for a combined total of more than 4096 units. A device shall not request a bus interval adjustment unless the device received an ITP within the past 125 μs, the ITP contained a Bus Interval Adjustment Control field with a value equal to zero or the device’s address and the device is in the Address or Configured state.

Only one device can control the bus interval length at a time. The host controller implements a first come first serve policy for handling bus interval adjustment requests. When the host controller begins operation it shall transmit ITPs with the Bus Interval Adjustment Control field set to zero. When the host controller first receives a bus interval adjustment control request, it shall set the Bus Interval Adjustment Control field in subsequent ITPs to the address of the device that sent the request. The host shall ignore bus interval adjustment requests from all other devices once the Bus Interval Adjustment Control field is set to a non-zero address. If the controlling device is disconnected, the host controller shall reset the Bus Interval Adjustment Control field to zero. The host controller may provide a way for software to override default bus interval adjustment control field behavior and select a controlling device. The host controller shall begin applying bus interval adjustments within two bus intervals from when the bus interval adjustment request is received.

The smallest bus interval adjustment (one BusIntervalAdjustmentGranularity) requires the host to make an average adjustment of eight high speed bit times every 4096 bus intervals. The host is allowed to make this adjustment in a single bus interval such that the clock used to generate ITP times and bus interval boundaries does not need a period smaller than eight high speed bit times. The host shall make bus interval adjustments at regular intervals. When the host is required to make an average of one or more eight high speed bit time adjustments every 4096 bus intervals the adjustments shall be evenly distributed as defined by the following constraints:

Intervals that contain one more eight high speed bit time adjustment than other intervals are referred to as maximum adjustment bus intervals.

  • The number of eight high speed bit time adjustments made in any bus interval shall not be more than one greater than the number of high speed bit time adjustments made in any other bus interval.
  • The distance in bus intervals between consecutive maximum adjustment bus intervals shall not vary by more than one bus interval.

The even distribution and average adjustment requirements for bus interval adjustments shall apply from one bus interval after a bus interval adjustment request is received by the host until the bus interval where a subsequent valid bus interval adjustment request is received by the host.

The following is an example of valid host behavior for a specific bus interval adjustment request. After power on, the host receives a bus interval adjustment request for a bus interval decrease of 10 BusIntervalAdjustmentGranularity units in bus interval X-1. The host controller uses a clock with a period of eight high speed bit times to drive a counter that produces timestamps and bus interval boundaries. The host controller adds an extra eight high speed bit time clock tick to its counter in each of the following bus intervals: X+409, X+819, X+1228, X+1638, X+2048, X+2457, X+2867, X+3276, X+3686, X+4096, X+4505

PING Transaction Packet

This TP can only be sent by the host. It is used by the host to transition all links in the path to a device back to U0 prior to initiating an isochronous transfer. Refer to Appendix C for details on the usage of this TP.

A device shall respond to the PING TP by sending a PING_RESPONSE TP to the host within the tPingResponse time.

A device shall keep its link in U0 until it receives a subsequent packet from the host, or until the tPingTimeout time elapses.

IMAGE 39

PING TP Format (differences with ACK TP)

IMAGE 40

PING_RESPONSE Transaction Packet

This TP can only be sent by a device in response to a PING TP sent by the host. A PING_RESPONSE TP shall be sent for each PING TP received. Refer to Appendix C for details on the usage of this TP.

IMAGE 41

PING_RESPONSE TP Format (differences with ACK TP)

IMAGE 42

Data Packet (DP)

This packet can be sent by either the host or a device. The host uses this packet to send data to a device. Devices use this packet to return data to the host in response to an ACK TP. All data packets are comprised of a Data Packet Header and a Data Packet Payload.

Data packets traverse the direct path between the host and a device. It is permissible to send a data packet with a zero length data block; however, it shall have a CRC-32.

IMAGE 43

Data Packet Format (difference with ACK TP)

IMAGE 44

Isochronous Timestamp Packet (ITP)

The value in the Type field is Isochronous Timestamp Packet for an ITP. ITPs are used to deliver timestamps from the host to all active devices. ITPs carry no addressing or routing information and are multicast by hubs to all of their downstream ports with links in the U0 state. A device shall not respond to an ITP. ITPs are used to provide host timing information to devices for synchronization. Any device or hub may receive an ITP. The host shall transmit an ITP on a root port link if and only if the link is already in U0. Only the host shall initiate an ITP transmission. The host shall not bring a root port link to U0 for the purpose of transmitting an ITP. The host shall transmit an ITP in every bus interval within tTimestampWindow from a bus interval boundary if the root port link is in U0. The host shall begin transmitting ITPs within tIsochronousTimestampStart from when the host root port’s link enters U0 from the polling state. An ITP may be transmitted in between packets in a burst. If a device receives an ITP with the delayed flag (DL) set in the link control word, the timestamp value may be significantly inaccurate and may be ignored by the device.

IMAGE 45

Isochronous Timestamp Packet Format

IMAGE 46

The ITS value in the ITP shall have an accuracy of ±1 tIsochTimestampGranularity units of the value of the host clock (for ITP generation) measured when the first framing symbol of the ITP is transmitted by the host.

Addressing Triple

Data Packets and most Transaction Packets provide access to specific data flow using a composite of three fields. They are the Device Address, the Endpoint Number, and the Direction fields.

Upon reset and power-up, a device’s address defaults to a value of zero and shall be programmed by the host during the enumeration process with a value in the range from 1 to 127. Device address zero is reserved as the default address and may not be assigned to any other use.

Devices may support up to a maximum of 15 IN and 15 OUT endpoints (as indicated by the Direction field) apart from the required default control endpoint that has an endpoint number set to zero.

Route String Field

The Route String is a 20-bit field in downstream directed packet that the hub uses to route the packet to the designated downstream port. It is composed of a concatenation of the downstream port numbers (4 bits per hub) for each hub traversed to reach a device. The hub uses a Hub Depth value multiplied by four as an offset into the Route String to locate the bits it uses to determine the downstream port number. The Hub Depth value is determined and assigned to every hub during the enumeration process.

This field is only valid in packets sent by the host and when sent by a device, this field is reserved.

IMAGE 47

Route String Port Field

This 4-bit wide field in the Route String represents the port in the hub being addressed.

Route String Port Field Width

The Route String Port field width is fixed at 4 bits, limiting the maximum number of ports a hub may support to 15.

Port Number

The specific port on a hub to which the packet is directed is identified by the value in the Route String Port field. When addressing the hub controller then the Port Number field at the hub’s tier level shall be set to zero in the Route String. The hub’s downstream ports are addressed beginning with one and count up sequentially.

Transaction Packet Usages

TPs are used to report the status of data transactions and can return values indicating successful reception of data packets, command acceptance or rejection, flow control, and halt conditions.

Flow Control Conditions

Here we discuss the interaction between the host and a device when an endpoint returns a flow control response. The flow control is at an end-to-end level between the host and the endpoint on the device. Only bulk, control and interrupt endpoints may send flow control responses. Isochronous endpoints cannot send flow control responses.

An IN endpoint shall be considered to be in a flow control condition if it returns one of the following responses to an ACK TP:

Responding with an NRDY TP

  • Sending a DP with the EOB field set to 1 in the DPH

An OUT endpoint shall be considered to be in a flow control condition if it returns one of the following responses to a DP:

  • Responding with an NRDY TP
  • Sending an ACK TP with the NumP field set to 0

The Packets Pending field is only valid when set by the host and does not affect whether or not an endpoint enters the flow control state.

When an endpoint is in a flow control condition, it shall send an ERDY TP to be moved back into the active state. Further, if the endpoint is an IN endpoint, then it shall wait until it receives an ACK TP for the last DP it transmitted before it can send an ERDY TP. When an endpoint is not in a flow control condition, it shall not send an ERDY TP unless the endpoint is a Bulk endpoint that supports streams. The host may resume transactions to any endpoint – even if the endpoint had not returned an ERDY TP after returning a flow control response.

Burst Transactions

The SuperSpeed USB protocol allows the host to continually send data to a device or receive data from a device as long as the device can receive the data or transmit the data. The number of packets an endpoint on a device can send or receive at a time without an intermediate acknowledgement packet is reported by the device in the endpoint companion descriptor for that endpoint. An endpoint that reports more than one packet in its maximum burst size is considered to be able to support “Burst” Transactions.

While bursting the following rules apply:

  • The maximum number of packets that can be sent in a burst prior to receiving an acknowledgement is limited to the minimum of the maximum burst size of the endpoint and the value of the NumP field in the last ACK TP received by the endpoint or the host, minus the number of packets that the endpoint or the host has already sent after the packet acknowledged by the last ACK TP.
  • Each individual packet in the burst shall have a data payload of maximum packet size. Only the last packet in a burst may be of a size smaller than the reported maximum packet size. If the last one is smaller, then the same rules for short packets apply to a short packet at the end of a burst.
  • The burst transaction continues as long as the NumP field in the ACK TP is not set to zero and each packet has a data payload of maximum packet size.
  • The NumP field can be incremented at any time by the host or a device sending the ACK TP as long as the device or host wants to continue receiving data. The only requirement is that the NumP field shall not have a value greater than the maximum burst supported by the device.
  • If a device or host sending ACK TP decrements the NumP field, then it shall do so by no more than one. For example, if the previous ACK TP had a value of five in the NumP field, then the next ACK TP to acknowledge the next packet received shall have a value of no less than four in the NumP field. The only exceptions to this rule are:

o   If the device can receive the data but cannot accept any more data, then it shall send ACK TP with the NumP field set to zero.

o   The host shall send an ACK TP with the NumP field set to zero in response to a device sending a DP with the EOB field set or that is a short packet. However, if the host receives a short packet and the host has another transfer to initiate with the same endpoint, then the host may instead send an ACK TP with the NumP field set to a non-zero value.

Short Packets

SuperSpeed retains the semantics of short packet behavior that USB 2.0 supports. When the host or a device receives a DP with the Data Length field shorter than the maximum packet size for that endpoint it shall deem that that transfer is complete.

In the case of an IN transfer, a device shall stop sending DPs after sending a short DP. The host shall respond to the short DP with an ACK TP with the NumP field set to zero. The host shall schedule transactions to an endpoint on the device when another transfer is initiated for that endpoint.

In the case of an OUT transaction, the host may stop sending DPs after sending a short DP. The host shall schedule transactions to an endpoint on the device when another transfer is initiated for that endpoint. This shall be the start of a new burst to the endpoint.

TP or DP Responses

Transmitting and receiving devices shall return DPs or TPs. Not all TPs are allowed, depending on the transfer type and depending on the direction of flow of the TP.

Device Responses to TP Requesting Data (Bulk, Control, and Interrupt Endpoints)

Here we see the possible ways a device shall respond to a TP requesting data for bulk, control, and interrupt endpoints. A TP is considered to be invalid if it has an incorrect Device Address or the endpoint number and direction does not refer to an endpoint that is part of the current configuration or it does not have the expected sequence number.

Host Response to Data Received from a Device

The host responses to data received from a device for bulk, controls, and interrupt endpoints. The host is able to return only an ACK TP. A DPH is considered to be invalid if it has an incorrect Device Address or the endpoint number and direction does not refer to an endpoint that is part of the current configuration or it does not have the expected sequence number. DPP Error may be due to one or more of the following:

  • CRC incorrect
  • DPP aborted
  • DPP missing
  • Data length in the DPH does not match the actual data payload length

Host Responses to Data Received from a Device (Bulk, Control, and Interrupt Endpoints)

IMAGE 48

Device Response to Data Received from the Host

Here we see the TP responses by a device to data received from the host for bulk, control, and interrupt endpoints. A DPH is considered to be invalid if it has an incorrect Device Address or the endpoint number and direction does not refer to an endpoint that is part of the current configuration or it does not have the expected sequence number. DPP Error may be due to one or more of the following:

  • CRC incorrect
  • DPP aborted
  • DPP missing
  • Data length in the DPH does not match the actual data payload length

Receipt of an ACK TP indicates to the host the DP with the previous sequence number was successfully received by a device as well as the number of data packet buffers the device has available to receive any pending DPs the host has. A device shall send an ACK TP for each DP received.

Device Responses to OUT Transactions (Bulk, Control, and Interrupt Endpoints)

IMAGE 49

Device Response to a SETUP DP

A SETUP DP is a Special DP that is identified by the Setup field set to one and addressed to any control endpoint. SETUP is a special type of host-to-device data transaction that permits the host to initiate a command that the device shall perform. Upon receiving a SETUP DP, a device shall respond as shown below.

A SETUP DPH shall be considered invalid if it has any one of the following:

  • Incorrect Device Address
  • Endpoint number and direction does not refer to an endpoint that is part of the current configuration
  • Endpoint number does not refer to a control endpoint
  • Non-zero sequence number
  • Data length is not set to eight

DPP Error may be due to one or more of the following:

  • CRC incorrect
  • DPP aborted
  • DPP missing
  • Data length in the Setup DPH does not match the actual data payload length.

Devices Responses to SETUP Transactions (Only for Control Endpoints)

IMAGE 50

TP Sequences

The packets that comprise a transaction vary depending on the endpoint type. There are four endpoint types: bulk, control, interrupt, and isochronous.

Bulk Transactions

Bulk transaction types are characterized by the ability to guarantee error-free delivery of data between the host and a device by means of error detection and retry. Bulk transactions use a twophase transaction consisting of TPs and DPs. Under certain flow control and halt conditions, the data phase may be replaced with a TP.

State Machine Notation Information

Here we discuss detailed host and device state machines required to advance the Protocol on an IN or OUT pipe. The diagrams should not be taken as a required implementation, but to specify the required behavior.

Below you’ll see the legend for the state machine diagrams. A circle with a three line border indicates a reference to another (hierarchical) state machine. A circle with a two line border indicates an initial state. A circle with a single line border is a simple state.

A diamond (joint) is used to join several transitions to a common point. A joint allows a single input transition with multiple output transitions or multiple input transitions and a single output transition. All conditions on the transitions of a path involving a joint must be true for the path to be taken. A path is simply a sequence of transitions involving one or more joints.

A transition is labeled with a block with a line in the middle separating the (upper) condition and the (lower) actions. A transition without a line is a condition only. The condition is required to be true to take the transition. The actions are performed if the transition is taken. The syntax for actions and conditions is VHDL. A circle includes a name in bold and optionally one or more actions that are performed upon entry to the state.

Transitions using a solid arrow are generated by the host. Transitions using a dashed arrow are generated by a device. Transitions using a dot-dot-dash arrow are generated by the either a device or the host.

Legend for State Machines

IMAGE 51

Bulk IN Transactions

When the host is ready to receive bulk data, it sends an ACK TP to a device indicating the sequence number and number of packets it expects from the device.

The host shall send an ACK TP for each valid DP it receives from a device. A device does not need to wait for the ACK TP to send the next DP to the host if the previous ACK TP indicated that the host expected the device to send more than one DP (depending on the value of the Number of Packets field in the TP). The ACK TP implicitly acknowledges the last DP with the previous sequence number as being successfully received by the host and also indicates to the device the next DP with the sequence number and number of packets the host expects from the device. If the host detects an error while receiving any of the DPs, it shall send an ACK TP with the sequence number value set to the first DP that was received with an error with the Retry bit set, even if subsequent packets in the burst asked for by the host were received without error. A device is required to resend all DPs starting from the sequence number set in the ACK TP in which the Retry bit set.

The host expects the first DP to have a sequence number set to zero when it starts the first transfer from an endpoint after the endpoint has been initialized (via a Set Configuration, Set Interface, or a ClearFeature (STALL) command – refer to Chapter 9 for details on these commands). The second DP sent by the device from that endpoint shall have a sequence number set to one; the third DP has a sequence number set to two; and so on until sequence number 31. The next DP after sequence number 31 uses a sequence number of zero. An endpoint on the device keeps incrementing the sequence number of the packets it transmits unless it receives an ACK TP with the Retry bit set to one that indicates that it has to retransmit an earlier DP.

If the host asks for multiple DPs from a device and the device does not have that number of DPs available to send at the time, the device shall send the last DP with the End of Burst flag in the DPH set to one. It is not necessary to set the End of Burst flag if the DP sent to the host has a payload that is less than the MaxPacketSize for that endpoint.

A transfer is complete when a device sends all the data that is expected by the host or it sends a DP with a payload that is less than the MaxPacketSize. When the host wants to start a new transfer, it shall send another ACK TP with the next sequence number and number of DPs expected from a device. For example, if the DP with the payload less than MaxPacketSize was two, the host shall initiate the next transfer by sending an ACK TP with the expected sequence number set to three.

Bulk OUT Transactions

When the host is ready to transmit bulk data, it sends one or more DPs to a device. If a DPH with valid values (valid device address, endpoint number, and direction as well as the expected sequence number) is received by a device, it shall respond as previously defined in the USB 3.0 specification.

The host always initializes the first DP sequence number to zero in the first transfer it performs to an endpoint after the endpoint is initialized (via a Set Configuration, Set Interface, or ClearFeature (STALL) command – refer to Chapter 9 for details on these commands). The second DP has a sequence number set to one; the third DP has a sequence number set to two; and so on until 31. The next DP after sequence number 31 uses a sequence number of zero. The host keeps incrementing the sequence number of the DPs it transmits unless it receives an ACK TP with the Retry bit set to one that indicates that it has to retransmit an earlier packet.

A transfer is complete when the host sends all the data it has to a device; however the last DP of the transfer may or may not have a payload which is equal to the MaxPacketSize of the endpoint. When the host wants to start a new transfer it shall send another DP, with the next sequence number, targeted at an endpoint in the device.

Sample BULK IN Sequence

IMAGE 52

Sample BULK OUT Sequence

IMAGE 53

Bulk Streaming Protocol

The Stream Protocol adheres to the semantics of the standard SuperSpeed Bulk protocol, so the packet exchanges on a SuperSpeed bulk pipe that supports Streams are indistinguishable from a SuperSpeed bulk pipe that does not. The Stream Protocol is managed strictly through manipulation of the Stream ID field in the packet header.

The Stream Protocol applies to the state of the “pipe” and is described as single entity. In reality, the Stream Protocol is being tracked independently by the host at one end of the pipe and the device at the other. So at any instant in time the two ends may momentarily be out of phase due to packet propagation delays between the host and the device.

General Stream Protocol State Machine (SPSM)

IMAGE 54

Here we see the basic state transitions of the Stream Protocol State Machine (SPSM). This describes the general transitions of the SPSM as they apply to both IN and OUT endpoints.

Disabled – This is the initial state of the pipe after it is configured, as well as the state that is transitioned to if an error is detected in any of the other states. The first time an Endpoint Buffer is assigned to the pipe, the host shall transition the SPSM to the Prime Pipe state. If the Disabled state was entered due to an error, then the error condition must be removed by software intervention before the state may be exited. An error (Stall, timeout, etc.) shall transition any SPSM state to the Disabled state.

Prime Pipe – This state is always initiated by host, and informs a device that an Endpoint Buffer set has been added or modified by software.

Idle – This state indicates that there is no Current Stream selected. In this state, the SPSM is waiting for Prime Pipe or Host Initiated transition to Move Data, or a Device Initiated transition to Start Stream. The object of the Host and Device Initiated transitions is to start a Stream (setting the Current Stream, by the Host or a Device, respectively) and begin moving data.

Start Stream – This state is always initiated by a Device when it wants to select a Stream and start a data transfer. If the device selected Stream is accepted by the host, the Current Stream is set and the pipe enters the Move Data state. If the device selected Stream is rejected by the host, the pipe returns to Idle state.

Move Data – In this state, Stream data is transferred. If this state is entered by a Host Initiated Stream selection, the Current Stream shall be set by the host. If this state is entered from the Start Stream state, the Current Stream selection will have already been set by a device. The SPSM transitions back to the Idle state when the Stream transfer is complete, or if the host or a device decides to terminate the Stream transfer. The transition to Idle invalidates the Current Stream for the pipe.

Stream IDs

A 16-bit field Stream ID field is reserved in DP headers and in ACK, NRDY, and ERDY TPs for passing SIDs between the host and a device. Specific SID values that are reserved by the Stream Protocol and other SID notations are:

  • NoStream – This SID indicates that no Stream ID is associated with the respective bus packet and the Stream ID field should not be interpreted as referencing a valid Stream. The NoStream SID value is FFFFh.
  • Prime – This SID is used to define transitions into and out of the Prime Pipe state. As with NoStream, no Stream ID is associated with the respective bus packet and the Stream ID field should not be interpreted as referencing a valid Stream. The Prime SID value is FFFEh.
  • Stream n – Where n is a value between 1 and 65533 (FFFFh). This notation is used to reference a valid Stream ID. The Stream ID field in the packet header is valid if it uses this notation. Valid Stream n SID values are between 1 and 65533 (FFFFh), where the numeric value is identical to n.
  • Stream 0 – This value is reserved and not used by a pipe that supports Streams. The Stream 0 SID value is 0000h. Its use is required by a standard bulk pipe.
  • CStream – represents the value of the “Current” Stream ID assigned to the pipe. A CStream value is maintained by both the host and a device. The Stream Protocol ensures that the CStream values are consistent in the host and the device. Valid values are NoStream or Stream n.
  • LCStream – represents the value of the CStream SID assigned to the pipe before the last state transition. An LCStream value is maintained by the host. Valid values are Prime, NoStream, or Stream n. For example, while the pipe in the Move Data state CStream = Stream n, when the pipe transitions from Move Data to Idle state, LCStream is set to Stream n, and CStream is set to NoStream, thus LCStream records the “Last CStream” value.

Stream n SID values are assigned by the host and passed to a device (typically through an out-of-band, Device Class defined method). The value of a Stream n SID shall be treated as a “logical value” by a device, i.e., the device should not infer any meaning from the value or modify it.

The Bulk IN and OUT Stream Protocols below describe simplified state machines that do not explicitly detail the burst feature of SuperSpeed endpoints which allows DPs to be sent without receiving an ACK. An implementation shall extend these state machines to manage bursting.

Bulk IN Stream Protocol

Here we define the SuperSpeed packet exchanges that transition the Stream Protocol from one state to another on an IN bulk endpoint.

For an IN pipe, Endpoint Buffers in the host receive Function Data from a device.

Bulk IN Stream Protocol State Machine (ISPSM)

IMAGE 55

After an endpoint is configured, the pipe is in the Disabled state. The host shall transition the pipe to the Prime Pipe state by issuing an ACK TP with the Stream ID field set to Prime. This transition occurs after Endpoint Buffers are assigned to the pipe by system software.

A device shall cause the pipe to exit the Prime Pipe state and transition to the Idle state by asserting an NRDY TP with its Stream ID field set to Prime.

If an intermediate hub deferred the ACK TP, the host and a device shall act as if the device sent an NRDY TP. That is, the host shall transition to the Idle state when it receives the Deferred Response. A device shall transition to the Prime Pipe state when it receives the Deferred ACK TP and then it shall immediately transition to the Idle state as if it has sent the NRDY TP with its Stream ID field set to Prime.

In the Idle state, the pipe is waiting for a Stream selection (e.g., a transition to Start Stream or Move Data) or a notification from the host that an Endpoint Buffer as been added or modified for the pipe (transition to Prime Pipe). In the Idle state, Stream selection initiated by the host is identified by an ACK TP with its Stream ID set to Stream n and a NumP value > 0. This packet shall transition the ISPSM from the Idle state to the Move Data state. If the last ISPSM transition was from Start Stream or Move Data, the host shall initiate an Idle to Move Data transition due to two possible conditions: 1) if an Endpoint Buffer posted to the pipe was for LCStream and the last ISPSM transition was not due to an NRDY(Stream n) Move Data exit, or 2) if an endpoint buffer is posted for a new stream (i.e., newly posted SID not equal LCStream). In the Idle state, Stream selection initiated by a device is identified by an ERDY TP with its Stream ID set to Stream n and a NumP value > 0. This packet shall transition the ISPSM from the Idle state to the Start Stream state. A device shall initiate this transition when it wishes to start a Stream transfer regardless of whether it is in a flow control condition or not.

In the Start Stream state, the pipe is waiting for the host to accept or reject the Stream selection proposed by a device. The host shall indicate the acceptance of a device initiated Stream selection by asserting an ACK TP with the following field settings, Stream ID = Stream n and NumP > 0.

This packet shall transition the ISPSM from the Start Stream state to the Move Data state. The host shall indicate the rejection of a device initiated Stream selection by asserting an ACK TP with the following field settings, Stream ID = NoStream, NumP = 0, and Packet Pending (PP) = 0. This packet shall transition the ISPSM from the Start Stream state to the Idle state. The host shall reject a stream selection if there are no Endpoint Buffers available for a device selected SID.

The ISPSM executes independently on the host and device. A race condition occurs if a device issues an ERDY to the host and enters the Start Stream state, at the same time that the host issues a ACK(Prime,PP=0) to the device and enters the Prime Pipe state. To recover from this condition, if a device receives a ACK(Prime,PP=0) while in the Start Stream state, it shall transition to the Prime Pipe Ack state and issue an NRDY(Prime) to the host, to complete the Prime Pipe to Idle transition for the host, and the Prime Pipe Ack to Idle transition for the device.

In the Move Data state, CStream is set at both ends of the pipe and the pipe is actively moving data to the host. The details of the bus transactions executed in the Move Data state and its exit conditions are defined in the IN Move Data State Machine defined below.

IN Move Data State Machine (IMDSM)

IMAGE 56

The IN Move Data State Machine (IMDSM) is entered from the Start Stream or Idle states as described above. The entry into the IMDSM immediately transitions to the INMvData Device state. The Stream ID field of all packets generated by the IMDSM shall be Stream n.

Each time the INMvData Device state is entered, a device performs the following actions to advance the IMDSM:

  • if (Device Function Data bytes > Max Packet Size)

The device shall generate a DP with EOB field = 0, which shall cause the pipe to transition to the INMvData Host state.

  • else if (Device Function Data bytes = Max Packet Size)

The device shall generate a DP with EOB field = 1, which shall cause the pipe to transition to the INMvData Device Terminate state.

  • else (Device Function Data bytes < Max Packet Size)

The device shall generate a short DP, which shall cause the pipe to transition to the INMvData Device Terminate state.

Optionally, a device may generate an NRDY TP with the Stream ID set to Stream n, which terminates the stream, and shall cause the pipe to exit the IMDSM and transition to Idle state. A device may use this transition to reject a Host Initiated Move Data.

If an intermediate hub deferred the ACK TP, the host and a device shall act as if the device sent an NRDY TP. That is, the host shall transition to the Idle state when it receives the Deferred Response. A device shall exit the IMDSM and transition to the Idle state when it receives the Deferred ACK TP as if it has sent an NRDY TP with its Stream ID field set to Stream n. If a device accepts the host initiated Stream ID, it shall send an ERDY with its Stream ID field set to Stream n. If a device rejects the host initiated Stream ID, it shall stay in the Idle state and wait for next Stream selection either by the host or a device.

The INMvData Host state is entered because a device has more Function Data to send, so the host performs the following actions to advance the IMDSM:

  • if ( Another DP can be scheduled in this burst )
  • if ( The host has more Endpoint Buffer space available )

Generate an ACK TP with NumP > 0, which shall cause the pipe to transition to the INMvData Device state.

  • else the host is out of Endpoint Buffer space.

Generate a Terminating ACK TP with NumP = 0 and PP = 0, which shall cause the pipe to exit the IMDSM and transition to the Idle state.

  • else ( the last DP of the burst has just been received )

Terminate the burst.

  • if ( The host has more Endpoint Buffer space available)

Inform the device that the burst is complete (NumP = 0) and another burst shall be scheduled by the host (PP = 1) for CStream. Generate an ACK TP with NumP = 0 and PP = 1, which shall cause the pipe to transition to the INMvData Burst End state.

  • else the host is out of Endpoint Buffer space.

Generate a Terminating ACK TP with NumP = 0 and PP = 0, which shall cause the pipe to exit the IMDSM and transition to the Idle state.

In the INMvData Burst End state, the host shall generate an ACK with NumP > 0 and PP = 1 to initiate the next burst and cause the pipe to transition to the INMvData Device state.

The pseudo code describing the IMDSM assumes that the received DP is valid. If it is invalid, an ACK TP shall be generated, which shall transition the pipe to the INMvData Device state. The Sequence Number in the ACK TP shall not advance. However, the retry may decrement the transmitted NumP value. If NumP = 0 and there are still Endpoint Buffers available in the host, PP shall be set to 1; otherwise, PP is set to 0.

The INMvData Device Terminate state is entered because a device has no more Function Data to be sent, so the host shall generate a Terminating ACK TP with NumP = 0 and PP = 0, which shall cause the pipe to exit the IMDSM and transition to the Idle state. If the host detects an error on the last DP sent by a device, it shall respond with a Retry ACK TP (Steam n, NumP>0, Rty) and the IMDSM shall transition to the INMvDataDevice state.

If a DP error is detected in the INMvDataHost state, the host shall generate an ACK TP with NumP > 0 and Rty = 1, which shall cause the pipe to transition to the INMvDataDevice state and resend the packet.

Bulk OUT Stream Protocol

Here we define the SuperSpeed packet exchanges that transition the Stream Protocol from one state to another on an OUT bulk endpoint.

For an OUT pipe, Endpoint Data in host is transmitted to Function Buffers in a device. Unless otherwise stated, a DP will contain Endpoint Data.

OUT Stream Protocol State Machine (OSPSM)

IMAGE 57

After an endpoint is configured, the pipe is in the Disabled state. The host shall transition the pipe to the Prime Pipe state by issuing a DP with the Stream ID field set to Prime. This transition occurs after Endpoint Buffers are assigned to the pipe by system software.

A device shall cause the pipe to exit the Prime Pipe state and transition to the Idle state by asserting an NRDY TP with its Stream ID field set to Prime.

If an intermediate hub deferred the DP, the host and a device shall act as if the device sent an NRDY TP. That is, the host shall transition to the Idle state when it receives the Deferred Response. A device shall transition to the Prime Pipe state when it receives the Deferred DPH.

Then it shall immediately transition to the Idle state as if it has sent an NRDY TP with its Stream ID field set to Prime.

In the Idle state, the pipe is waiting for a Stream selection (e.g., a transition to Start Stream or Move Data) or a notification from the host that Endpoint Data has been added or modified for the pipe (transition to Prime Pipe). In the Idle state, Stream selection initiated by the host is identified by a DP with its Stream ID set to Stream n. The value of PP will depend on whether the host has one (PP = 0) or more (PP = 1) packets to transfer. This packet shall transition the OSPSM from the Idle state to the Move Data state. If the last OSPSM transition was from Start Stream or Move Data the host shall initiate an Idle to Move Data transition due to two possible conditions: 1) if an Endpoint Buffer posted to the pipe was for LCStream and the last OSPSM transition was not due to an NRDY(Stream n) Move Data exit, or 2) if an endpoint buffer is posted for a new stream. In the Idle state, Stream selection initiated by a device is identified by an ERDY TP with its Stream ID set to Stream n and a NumP value > 0. This packet shall transition the OSPSM from the Idle state to the Start Stream state. A device shall initiate this transition when it wishes to start a Stream transfer regardless of whether it is in a flow control condition or not.

In the Start Stream state, the pipe is waiting for the host to accept or reject the Stream selection proposed by a device. The host shall indicate the acceptance of a device initiated Stream selection by sending a DP with the following field settings; Stream ID = Stream n. The value of PP will depend on whether the host has one (PP = 0) or more (PP = 1) packets to transfer. This packet shall transition the OSPSM from the Start Stream state to the Move Data state. The host shall indicate the rejection of a device initiated Stream selection by asserting a DP with the following field settings; Length = 0, Stream ID = NoStream and PP = 0. This packet shall transition the OSPSM from the Start Stream state to the Start Stream End state. The host shall reject a stream selection if there is no Endpoint Data Buffer available for a device selected SID.

The OSPSM executes independently on the host and device. A race condition occurs if the device issues an ERDY to the host and enters the Start Stream state, at the same time that the host issues a DP(Prime,PP=0) to the device and enters the Prime Pipe state. To recover from this condition, if the device receives a DP(Prime,PP=0) while in the Start Stream state it shall transition to the Prime Pipe ACK state and issue an NRDY(Prime) to the host, to complete the Prime Pipe to Idle transition for the host, and the Prime Pipe ACK to Idle transition for the device.

The Start Stream End state is an intermediate state for exiting the Start Stream state when a selection is rejected. The device shall always force a transition to the Idle state by issuing an NRDY TP, with Stream ID = NoStream. This transition fulfills the requirement that a device must respond to a DP from the host.

In the Move Data state CStream is set at both ends of the pipe and the pipe is actively moving data to a device. The details of the bus transactions executed in the Move Data state and its exit conditions are defined in the OUT Move Data State Machine defined below.

OUT Move Data State Machine (OMDSM)

IMAGE 58

The OUT Move Data State Machine (OMDSM) is entered from the Start Stream or Idle states as described above. The Stream ID field of all packets generated by the OMDSM shall be Stream n.

Upon entering the OMDSM, the value of the PP field in the received DP is evaluated. PP = 1 transitions the OMDSM to the OUTMvData Device state. PP = 0 transitions the OMDSM to the OUTMvData Host Terminate state.

Each time the OUTMvData Device state is entered, a device performs the following actions to advance the OMDSM:

  • if (Device Function Buffer space >= Host Endpoint Data size1)

The device shall generate an ACK TP with the NumP field > 0, which shall cause the pipe to transition to the OUTMvData Host state.

  • else (Device Function Buffer space < Host Endpoint Data size)

The device shall generate a Terminating ACK TP with the NumP field = 0, which shall cause the pipe to exit the OMDSM, and transition to the Idle state.

Optionally, the device may generate an NRDY TP with the Stream ID set to Stream n, which terminates the stream, and shall cause the pipe to exit the OMDSM and transition to the Idle state. A device may use this transition to reject a Host Initiated Move Data.

If an intermediate hub deferred the DP, the host and a device shall act as if the device sent an NRDY TP. That is, the host shall transition to the Idle state when it receives the Deferred Response. A device shall exit the OMDSM and transition to the Idle state when it receives the Deferred DP as if it has sent an NRDY TP with its Stream ID field set to Stream n. If a device accepts the host initiated Stream ID, it shall send an ERDY TP with its Stream ID field set to Stream n. If a device rejects the host initiated Stream ID, it shall stay in the Idle state and wait for next Stream selection either by the host or a device.

The OUTMvData Host state is entered because a device has more Function Buffer space available for receiving data, so the host performs the following actions to advance the OMDSM.

  • if (Host Endpoint Data size > Max Packet Size)

Generate a DP with PP = 1, which shall cause the pipe to transition to the OUTMvData Device state.

  • else the Host Endpoint Data size <= Max Packet Size

Generate a DP with PP = 0, which shall cause the pipe to transition to the OUTMvData Host Terminate state.

The pseudo code describing the OMDSM is independent of whether the received ACK TP indicates a retry or not. An ACK TP with Retry shall affect the transmitted DP Sequence Number and cause Endpoint Data to be retransmitted.

The OUTMvData Host Terminate state is entered because the host has no more Endpoint Data to be sent (PP = 0), so a device shall generate a Terminating ACK TP with NumP = 0, which shall cause the pipe to exit the OMDSM and transition to the Idle state. If a device detects an error on the last DP sent by the host, it shall respond with a Retry ACK TP (Steam n, NumP>0, Rty=1) and the OMDSM shall transition to the OUTMvData Host state.

If a DP error is detected in the OUTMvData Device state, a device shall generate an ACK TP with NumP > 0 and Rty=1, which shall cause the pipe to transition to the OUTMvData Host state and resend the packet.

Control Transfers

Control transfers have a minimum of two transaction stages: Setup and Status. A control transfer may optionally contain a Data stage between the Setup and Status stages. The direction of the Data stage is indicated by the bmRequestType field which is present in the first byte of the data payload of the Setup packet. During the Setup stage, a SETUP transaction is used to transmit information to a control endpoint of the device. SETUP transactions are similar in format to a Bulk OUT transaction but have the Setup field set to one in the DPH along with the Data Length field set to eight. In addition, the Setup packet always uses a Data sequence number of zero. A device receiving a Setup packet shall respond as defined previously in the USB 3.0 specification. The Direction field shall be set to zero in TPs or DPs exchanged between the host and any control endpoint on the device.

An endpoint may return an ACK TP with the NumP field set to zero in response to a SETUP packet if it wants to flow control the control transfer. A device must send an ERDY to start the Data or Status stage.

The Data stage, if present, of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers with a burst set to one. The Data stage always starts with the sequence number set to zero. All the transactions in the Data stage shall be in the same direction (i.e., all INs or all OUTs). The maximum amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the data packet size, the data is sent in multiple data packets that carry the maximum packet size. Any remaining data is sent as a residual in the last data packet.

All control endpoints only support a burst of one and hence the host can only send or receive one packet at a time to or from a control endpoint.

The Data stage, if present, of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers with a burst set to one. The Data stage always starts with the sequence number set to zero. All the transactions in the Data stage shall be in the same direction (i.e., all INs or all OUTs). The maximum amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the data packet size, the data is sent in multiple data packets that carry the maximum packet size. Any remaining data is sent as a residual in the last data packet.

All control endpoints only support a burst of one and hence the host can only send or receive one packet at a time to or from a control endpoint.

The Status stage of a control transfer is the last transaction in the sequence. The status stage transaction is identified by a TP with the SubType set to STATUS. In response to a STATUS TP with zero in the Deferred bit, a device shall send an NRDY, STALL, or ACK TP. If a device sends an NRDY TP, the host shall wait for it to send an ERDY TP for that control endpoint before sending another STATUS TP to the device. If the Deferred bit is set in the STATUS TP, then the device shall send an ERDY TP to indicate to the host that is ready to complete the status stage of the control transfer.

Control Read Sequence

IMAGE 59

Control Write Sequence

IMAGE 60.1

When a STALL TP is sent by a control endpoint in either the Data or Status stages of a control transfer, a STALL TP shall be returned on all succeeding accesses to that endpoint until a SETUP DP is received. An endpoint shall return an ACK TP when it receives a subsequent SETUP DP. For control endpoints, if an ACK TP is returned for the SETUP transaction, the host expects that the endpoint has automatically recovered from the condition that caused the STALL and the endpoint shall operate normally.

Reporting Status Results

During the Status stage, a device reports to the host the outcome of the previous Setup and Data stages of the transfer. Three possible results may be returned:

  • The command sequence completed successfully.
  • The command sequence failed to complete.
  • The device is still busy completing the command.

Status reporting is always in the device-to-host direction. Below you’ll see a summary of the type of responses required for each. All Control transfers return status in the TP that is returned to the host in response to a STATUS TP transaction.

The host shall send a STATUS TP to the control pipe to initiate the Status stage. The pipe’s handshake response to this TP indicates the current status. An NRDY TP indicates that a device is still processing the command and that the device shall send an ERDY TP when it completes the command. An ACK TP indicates that a device has completed the command and is ready to accept a new command. A STALL TP indicates that a device has an error that prevents it from completing the command.

The NumP field of the ACK TP sent by a control endpoint on the device shall be set to zero. However this is not considered a flow control condition for a control endpoint.

If during a Data stage a control pipe is sent more data or is requested to return more data than was indicated in the Setup stage, it shall return a STALL TP. If a control pipe returns a STALL TP during the Data stage, there shall not be a Status stage for that control transfer.

Variable-length Data Stage

A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, a device indicates that the Data stage is ended by returning a DP that has a payload less than the maximum packet size for that endpoint.

If the amount of data in the data structure that is returned to the host is less than the amount requested by the host and is an exact multiple of maximum packet size then a control endpoint shall send a zero length DP to terminate the data stage.

STALL TPs Returned By Control Pipes

Control pipes have the unique ability to return a STALL TP due to problems in control transfers. If a device is unable to complete a command, it returns a STALL TP in the Data and/or Status stages of the control transfer. Unlike the case of a functional stall, protocol stall does not indicate an error with the device. The protocol STALL condition lasts until the receipt of the next SETUP DP, and the device shall return a STALL TP in response to any IN or OUT transaction on the pipe until the SETUP DP is received. In general, protocol stall indicates that the request or its parameters are not understood by a device and thus provides a mechanism for extending USB requests.

Devices do not support functional stall on a control pipe.

Bus Interval and Service Interval

For all periodic (interrupt and isochronous) endpoints, the interval at which an endpoint must be serviced is called a “Service Interval”. In this specification the term “Bus Interval” is used to refer to a 125 μs period.

Interrupt Transactions

The interrupt transfer type is used for infrequent data transfers with a bounded service period. It supports a reliable data transport with guaranteed bounded latency. It offers guaranteed constant data rate as long as data is available. If an error is detected in the data delivered, the host is not required to retry the transaction in the same service interval. However, if a device is momentarily unable to transmit or receive the data (i.e., responds with an NRDY TP), the host shall resume transactions to an endpoint only after it receives an ERDY TP from that device for that endpoint.

Interrupt transactions are very similar to bulk transactions – but are limited to a burst of three DPs in each service interval. The host shall continue to perform transactions to an interrupt endpoint at the agreed upon service interval as long as a device accepts data (in the case of OUT endpoints) or returns data (in the case of IN endpoints). The host is required to send an ACK TP for every DP successfully received in the service interval even if it is the last DP in that service interval. The final ACK TP shall acknowledge the last DP received and shall have the Number of Packets field set to zero. If an error occurs while performing transactions to an interrupt endpoint in the current service interval, then the host is not required to retry the transaction in the current service interval but the host shall retry the transaction in the next service interval at the latest.

Interrupt IN Transactions

When the host wants to start an Interrupt IN transaction to an endpoint, it sends an ACK TP to the endpoint with the expected sequence number and the number of packets it expects to receive from the endpoint. If an interrupt endpoint is able to send data in response to the ACK TP from the host, it may send up to the number of packets requested by the host within the same service interval. The host shall respond to each of the DPs with an ACK TP indicating successful reception of the data or an ACK TP requesting the DP to be retried in case the DPP was corrupted.

The host expects the first DP to have its sequence number set to zero when it starts the first transfer from a specific endpoint, after the endpoint has been initialized (via a Set Configuration or Set Interface or ClearFeature (STALL) command – refer to Chapter 9 for details on these commands).

An interrupt endpoint shall respond to TPs received from the host. As long as a device returns data in response to the host sending ACK TPs and the transfer is not complete, the host shall continue to send ACK TPs to the device during every service interval for that endpoint.

The host shall stop performing transactions to an endpoint on the device when any of the following happen:

  • The endpoint responds with an NRDY or STALL TP.
  • All the data for the transfer is successfully received.
  • The endpoint sets the EOB flag in the last DP sent to the host.

When an endpoint receives an ACK TP from the host and cannot respond by sending data, it shall send an NRDY (or STALL in case of an internal endpoint or device error) TP to the host. The host shall not perform any more transactions to the endpoint in subsequent service intervals.

The host shall resume interrupt transactions to an endpoint that responded with a flow control response in a previous service interval only after it receives an ERDY TP from the endpoint. This notifies the host about the endpoint’s readiness to transmit data again. Once the host receives the ERDY TP, it shall send an IN request (via an ACK TP) to the endpoint no later than twice the service interval as determined by the value of the bInterval field in the interrupt endpoint descriptor. An interrupt endpoint responds by returning either the DP (the sequence number of the packet being one more than the sequence number of the last successful data sent) or, should it be unable to return data, an NRDY or a STALL TP.

If a device receives a deferred interrupt IN TP, and the device needs to send interrupt IN data, the device shall respond with an ERDY TP and keep its link in U0 until it receives the subsequent interrupt transaction from the host, or until tPingTimeout time elapses.

As in the case of Bulk transactions, the sequence number is continually incremented with each packet sent by an interrupt endpoint. When the sequence number reaches 31 it wraps around to zero.

Host Sends Interrupt IN Transactions in Each Service Interval

IMAGE 60

Host Stops Servicing Interrupt IN Transaction once NRDY is received

IMAGE 61

Host Resumes IN Transaction after Device Sent ERDY

IMAGE 62

Endpoint Sends Stall TP

IMAGE 63

Host Detects Error in Data and Device Resends Data

IMAGE 64

Here the host retries the data packet received with an error in the same service interval. It is not required to do so and may retry the transaction in the next service interval.

Interrupt OUT Transactions

When the host wants to start an Interrupt OUT transaction to an endpoint, it sends the first DP with the expected sequence number. The host may send more packets to the endpoint in the same service interval if the endpoint supports a burst size greater than one. If an endpoint was able to receive that data from the host, it sends an ACK TP to acknowledge the successful receipt of data.

The host always initializes the first DP sequence number to zero in the first transfer it performs to an endpoint after the endpoint is initialized (via a Set Configuration or Set Interface or ClearFeature (STALL) command – refer to Chapter 9 for details on these commands).

As long as a device returns ACK TPs in response to the host sending data packets and the transfer is not complete, the host shall continue to send data to the device during every service interval for that endpoint. A device shall acknowledge the successful reception of the DP or ask the host to retry the transaction if the data packet was corrupted. In response to the OUT data sent by the host an interrupt endpoint shall respond appropriately.

When an endpoint receives data from the host, and it cannot receive data momentarily, it shall send an NRDY (or STALL in case of an internal endpoint or device error) TP to the host. The host shall not perform any more transactions to the endpoint in subsequent service intervals.

A host shall only resume interrupt transactions to an endpoint that responded with a flow control response after it receives an ERDY TP from that endpoint. This notifies the host about the endpoint’s readiness to receive data again. Once the host receives an ERDY TP, the host shall transmit the data packet to the endpoint no later than twice the service interval as determined by the value of the bInterval field in the interrupt endpoint descriptor for that endpoint.

If a device receives a deferred interrupt OUT DPH, and the device needs to receive interrupt OUT data, the device shall respond with an ERDY TP and keep its link in U0 until it receives the subsequent interrupt transaction from the host, or until tPingTimeout elapses.

As in the case of Bulk transactions, the sequence number is continually incremented with each packet sent by host. When the sequence number reaches 31 it wraps around to zero.

Host Sends Interrupt OUT Transaction in Each Service Interval

IMAGE 65

Host stops servicing Interrupt OUT Transaction once NRDY is received

IMAGE 66

Host resumes sending Interrupt OUT Transaction after Device sent ERDY

IMAGE 67

Device Detects Error in Data and Host Resends Data

IMAGE 68

Here the host retries the data packet received with an error in the same service interval. It is not required to do so and may retry the transaction in the next service interval.

Endpoint Sends STAL TP

IMAGE 69

Host Timing Information

USB 3.0 host controllers do not broadcast regular start of frame (SOF) packets to all devices on a SuperSpeed USB link. Host timing information is only sent by the host via isochronous timestamp packets (ITP) when the root port link is in U0 around a bus interval boundary. Hubs forward isochronous timestamp packets to any downstream port with a link in U0. The host shall provide isochronous timestamps based on a non-spread clock. Devices are responsible for keeping the link in U0 around bus interval boundaries when isochronous timestamps are required for device operation. A device should never keep the link in U0 for the sole purpose of receiving timestamps unless the timestamps are required for device operation.

A device will receive an isochronous timestamp if its link is in U0 around a bus interval boundary. This means that devices without any isochronous endpoints or need for synchronization may discard isochronous timestamp packets without negative side effects. If a device implements an inactivity timer for deciding when to drive the link into a lower power state, the device may choose to not reset the inactivity timer upon receiving an isochronous timestamps.

The timing information is sent in an isochronous timestamp packet around each bus interval boundary and communicates the current bus interval and the time from the start of the timestamp packet to the previous bus interval. Isochronous endpoints request a service interval of 125 * 2n μs, where n is an integer value from 0 to 15 inclusive.

ITPs communicate timing information such that all isochronous endpoints receive the same bus interval boundaries. The host shall keep service interval boundaries aligned for all endpoints at all times unless the host link enters U3. ITPs issued after the host root port link exits U3 may be aligned with boundaries from before the host root port link entered U3. The host shall begin transmitting ITPs within tIsochronousTimestampStart from when the host root port’s link enters U0 after the link was in U3. Below you’ll see an example with an active isochronous IN endpoint and isochronous OUT endpoint connected below the same USB 3.0 host controller. The service interval for the isochronous IN endpoint is X and the service interval for the isochronous OUT endpoint is 2X. The host is free to schedule an isochronous IN (via an ACK TP) or isochronous OUT data anywhere within the appropriate service interval. A device shall not assume that transactions occur at the same location within each service interval. The host shall schedule isochronous transactions such that they do not cross service interval boundaries.

Multiple Active Isochronous Endpoints with Aligned Service Interval Boundaries

IMAGE 70

Isochronous Transactions

IN isochronous transactions and OUT isochronous transactions are shown below. For INs, the host issues an ACK TP followed by a data phase in which the endpoint transmits data for INs. For OUTs, the host simply transmits data when there is data to be sent in the current service interval. Isochronous transactions do not support retry capability.

Isochronous IN Transaction Format

IMAGE 71

Isochronous OUT Transaction Format

IMAGE 71.2

SuperSpeed isochronous transactions with a single data packet per service interval always use sequence number zero. For isochronous transactions that include multiple data packets in a service interval the sequence number is increased by one for each subsequent data packet. The first data packet sent in any service interval always uses sequence number zero. The host shall be able to accept and send up to 48 data packets (DP) per service interval. The first DP in each service interval shall start with the sequence number set to 0. The second DP shall have a sequence number set to one; the third DP has a sequence number set to two; and so on until sequence number 31. The next DP after sequence number 31 uses a sequence number of zero. A SuperSpeed device with an isochronous endpoint shall be able to send or receive the number of packets (with sequence numbers 0 – N) as indicated in its endpoint and endpoint companion descriptors.

If the data is less than endpoint maximum packet size, then it will be sent as the last packet within the service interval with the lpf field set to 1. If there is no data to send to an isochronous OUT endpoint during a service interval, the host does not send anything during the interval. If a device with an isochronous IN endpoint does not have data to send when an isochronous IN ACK TP is received from the host, it shall send a zero length data packet.

Below you’ll see sample isochronous IN and OUT transactions for endpoints that have requested 2000 bytes of bandwidth per service interval (i.e., no more than two packets can be sent or received each service interval).

If the host is not able to send isochronous OUT data during the specified interval due to an error condition, the host discards the data and notifies host software of the error. If the host is not able to send an isochronous ACK TP during the specified service interval due to an error condition, the host notifies host software of the error.

Samples Isochronous IN Transaction

IMAGE 72

Sample Isochronous OUT Transaction

IMAGE 73

Isochronous IN Transaction Example

IMAGE 74

Isochronous OUT Transaction Example

IMAGE 75

Host Flexibility in Performing Isochronous Transactions

The host is allowed some flexibility in performing isochronous service during a service interval. The host may transfer all the DPs to or from an endpoint as a single isochronous burst transaction or it may split the transfer into smaller bursts of two, four, or eight DPs followed by a final isochronous burst with the remaining DPs for that service interval. The host shall not perform isochronous transactions in any other way. For isochronous endpoints that have a multiplier value greater than one, these rules apply to the burst transactions associated with each multiplier value separately. A device shall support all possible host burst transactions allowed by these rules. For example, if an isochronous OUT endpoint requests a maximum number of packets in a burst of 11 and the host has 11 packets to send to the endpoint during a service interval there are four possible ways the host could perform the transaction:

  • A single burst of 11 packets
  • A burst of eight followed by a burst of three
  • Two bursts of four followed by a burst of three
  • Five bursts of two followed by a burst of one

The host shall not reset the sequence number within the service interval. The host shall set the LPF flag only on the last packet in the last burst within the service interval.

Device Response to Isochronous IN Transactions

Here we see a list of the possible responses a device may make in response to an ACK TP. An ACK TP is considered to be invalid if it has an incorrect Device Address or the endpoint number and direction does not refer to an endpoint that is part of the current configuration or it does not have the expected sequence number.

Device Response to Isochronous IN Transactions

IMAGE 76

Host Processing of Isochronous IN Transactions

Here we see a list of the host processing of data from an IN transaction. The host never returns a response to isochronous IN data received. DP Error may be due to one or more of the following:

  • CRC-32 incorrect
  • DPP aborted
  • DPP missing
  • Data length in the DPH does not match the actual data payload length.

If the host receives a corrupted data packet, it discards the remaining data in the current service interval and informs host software of the error.

Host Response to IN Transactions

IMAGE 77

Device Response to an Isochronous OUT Data Packet

Here we see a list of the device processing of data from an OUT data packet. A device never returns a TP in response. DP Error may be due to one or more of the following:

  • CRC-32 incorrect.
  • DPP aborted.
  • DPP missing.
  • Data length in the DPH does not match the actual data payload length.

Device Responses to OUT Data Packets

IMAGE 78

Timing Parameters

Here we see a list of the minimum and/or maximum times a device shall adhere to when responding to various types of packets it receives. It also lists the default and minimum times a device may set in Latency Tolerance messages as well as the minimum time after receipt of certain TPs and when it can initiate a U1 or U2 entry. In addition, it lists the maximum time between DPs a device must adhere to while bursting.

All txxxResponse (e.g., tNRDYResponse) times are all timings that a device shall meet when the device has nothing else to send on its upstream link.

Leave a Reply

Your email address will not be published. Required fields are marked *