USB Specification

USB 3.0 Specifications – SuperSpeed Data Flow Model

USB 3.0 Specifications – SuperSpeed Data Flow Model

The SuperSpeed Data Flow Model represents how data and information move across the SuperSpeed. Here you will find the bus device framework overview information. All implementers should read through this informational tutorial to understand key concepts of SuperSpeed USB 3.0.

Implementer Viewpoints

SuperSpeed is a lot like High Speed USB 2.0 in that it gives communication services between a USB host and attached USB devices. The communication model view preserves the High Speed USB 2.0 layered architecture and basic components of the communication flow like point-to-point and same transfer types.

The SuperSpeed Data Flow Model describes the differences (from High Speed USB 2.0) of how data and control information is transferred between a SuperSpeed Host and its attached SuperSpeed devices. In order to understand the SuperSpeed Data Flow Model in detail, you must understand the following concepts:

  • Communication Flow Models: How communication flows between the host and devices through the SuperSpeed bus.
  • SuperSpeed Protocol Overview: High level overview of the SuperSpeed protocol and its comparison to the USB 2.0 protocol.
  • Generalized Transfer Description: How data transfers work in SuperSpeed and subsequent sections explain the operating constraints for each transfer type.
  • Device Notifications: Feature which allows a device to asynchronously notify its host of events or status on the device.
  • Reliability and Efficiency: A summarization the information and mechanisms available in SuperSpeed to ensure reliability and increase efficiency.

SuperSpeed Communication Flow

SuperSpeed retains similar concepts, mechanisms, and support for endpoints, pipes, and transfer types. Just like in High Speed USB 2.0, the ultimate consumer and producer of data in an endpoint. The endpoint’s characteristics are reported in the endpoint descriptor and the SuperSpeed Endpoint Companion Descriptor. As in USB 2.0, the endpoint is identified using an addressing triple {Device Address, Endpoint Number, Direction}.

All SuperSpeed devices must implement at least the Default Control Pipe (endpoint zero). The Default Control Pipe is a control pipe as explained in the High Speed USB 2.0 Specification.

Pipes

A SuperSpeed pipe is an association between an endpoint on a device and software on the host. Pipes signify the ability to move data between software on the host through a memory buffer. An endpoint on a device has the same behavior as explained in the High Speed USB 2.0 Specification. The main difference is that when a non-isochronous endpoint in SuperSpeed is busy it returns a Not Ready (NRDY) response and must send an Endpoint Ready (ERDY) notification when it wants to be serviced again. The host will then reschedule the transaction at the next available opportunity within the constraints of the transfer type.

SuperSpeed Protocol Overview

The USB 3.0 SuperSpeed protocol is made to take advantage of the dual-simplex physical layer. All the USB 2.0 transfer types are supported by the SuperSpeed protocol. The differences between the USB 2.0 protocol and the SuperSpeed protocol are first discussed followed by a brief description of the packets used in SuperSpeed.

Differences from USB 2.0

SuperSpeed USB 3.0 is completely backwards compatible with USB 2.0 at the framework level. However, there are some fundamental improvements made between the SuperSpeed protocol and USB revision 2.0:

USB 2.0 uses a three-part transaction (Token, Data, and Handshake) while SuperSpeed uses the same three parts differently. For OUTs, the token is integrated in the data packet; while for INs, the Token is replaced by a handshake.

USB 2.0 does not support bursting while SuperSpeed has the ability for continuous bursting.

USB 2.0 is a half-duplex broadcast bus while SuperSpeed is a dual-simplex unicast bus which enables concurrent IN and OUT transactions.

USB 2.0 utilizes a polling model while SuperSpeed uses asynchronous notifications instead.

USB 2.0 does not have a Streaming capability while SuperSpeed supports Streaming for bulk endpoints.

USB 2.0 has no mechanism for isochronous capable devices to enter the low power USB bus state between service intervals. SuperSpeed enables isochronous capable devices to autonomously enter low-power link states between service intervals. A SuperSpeed host may transmit a PING packet to the targeted isochronous device before service interval to allow time for the path to transition back to the active power state before initiating the isochronous transfer.

USB 2.0 does not have a mechanism for a device to inform the host how much latency the device can tolerate if the system enters lower system power state. As a result, a host may not enter lower system power states since it could impact a device’s performance because it does not have an understanding of a device’s power policy. SuperSpeed USB 3.0 has a mechanism to enable SuperSpeed devices to communicate to the host of their latency tolerance using Latency Tolerance Messaging. The host may use this data to create a system power policy that accounts for the devices’ latency tolerance.

High Speed USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals. A device driver is allowed to change the interval with small finite adjustments depending on the implementation of host and system software. SuperSpeed USB 3.0 attached a mechanism for devices to send a Bus Interval Adjustment Message that is utilized by the host to change its 125 μs bus interval up to +/-13.333 μs. The host may also send an Isochronous Timestamp Packet (ITP) within a relaxed timing window from a bus interval boundary.

USB 2.0 power management, including Link Power Management, is always directly initiated by the host. SuperSpeed hold up link-level power management that may be started from either end of the link. Thus, each link can independently enter low-power states whenever idle and exit whenever communication is needed.

High Speed USB 2.0 handles transaction error detection and recovery and flow control only at the end-to-end level for each transaction. SuperSpeed splits these functions between the end-to-end and link levels.

Comparing USB 2.0 and SuperSpeed Transactions

The SuperSpeed dual-simplex physical layer enables information to travel simultaneously in both directions. The SuperSpeed protocol enables the transmitter to send out multiple data packets before getting a handshake. For OUT transfers, the information contained in the USB 2.0 Token is included in the data packet header so a separate Token is not necessary. For IN transfers, a handshake is sent to the device to request data. The device may reply by either returning data, returning a STALL handshake, or by returning a Not Ready (NRDY) handshake to put off the transfer until the device is ready.

USB 2.0 sends packets to all enabled downstream ports. Every device is required to decode the address triple {device address, endpoint, and direction} of each packet to figure out if it has to acknowledge. SuperSpeed then sends the packets to a single network destination identified by a unique address. Downstream packets are delivered over a directed path between the host and the targeted device while upstream packets are sent over the direct path between the device and the host. SuperSpeed packets have routing information that the hubs use to figure out which downstream port the packet needs to traverse to reach the device. The Isochronous Timestamp Packet (ITP) is multicast to all active ports.

USB 2.0 style polling was replaced with asynchronous notifications. The SuperSpeed transaction is launched by the host making a request followed by a response from the device. If the device can fulfill the request, it either accepts or sends data. If the endpoint is stopped, the device will reply with a STALL handshake. If it cannot fulfill the request due to lack of buffer space or data, it will reply with a Not Ready (NRDY) to tell the host that it is unable to process the request at that given time. When the device can fulfill the request, it will send an Endpoint Ready (ERDY) to the host which will then reschedule the transaction.

The move to unicasting and the limited multicasting of packets together with asynchronous notifications allows links that are not actively passing packets to be put into reduced power states. Upstream and downstream ports cooperate to place their link into a reduced power state that hubs will propagate upstream. Allowing link partners to control their independent link power state and a hub’s propagating the highest link power state seen on any of its downstream ports to its upstream port, puts the bus into the lowest allowable power state rapidly.

Introduction to SuperSpeed Packets

USB 3.0 SuperSpeed packets begin with a 16-byte header. Some packets only have a header. All headers start with the Packet Type information utilized to figure out what to do with the request. The header is then protected by a 16-bit CRC (CRC-16_ and ends with a 2-byte link control word.

Depending on the Type, most packets have routing information (Route String) and a device address triple {device address, endpoint number, and direction}. The Route String is directs packets sent by the host on a directed path through the topology. Packets sent by the device are implicitly routed as the hub always forwards a packet seen on any downstream port to its upstream port. There are four basic types of packets: Link Management Packets, Transaction Packets, Data Packets, and Isochronous Timestamp Packets:

  • A Link Management Packet (LMP) only traverses a pair of directly connected ports and is primarily used to manage that link.
  • A Transaction Packet (TP) traverses all the links in the path directly connecting the host and a device. It is used to control the flow of data packets, configure devices and hubs, etc. Note that a Transaction Packet does not have a data payload.
  • A Data Packet (DP) traverses all the links in the path directly connecting the host and a device. Data Packets consist of two parts: a Data Packet Header (DPH) which is similar to a TP and a Data Packet Payload (DPP) which consists of the data block plus a 32-bit CRC (CRC-32) used to ensure the data’s integrity.
  • An Isochronous Timestamp Packet (ITP) is a multicast packet sent by the host to all active links.

Generalized Transfer Description

Each non-isochronous data packet sent to a receiver is acknowledged by a handshake. This is called an ACK transaction packet. But since SuperSpeed has independent transmit and receive paths, the transmitter does not actually have to wait for a specific handshake for each data packet transferred before sending the next packet.

SuperSpeed keeps all the basic data flow and transfer concepts from the High Speed USB 2.0 specification, which includes the transfer types, pipes, and basic data flow model. USB 2.0 utilizes a serial transaction model. This basically means that a host starts and completes on bus transaction {Token, Data, Handshake} before starting the next transaction. Split transactions also follow this same model since they are made of complete high-speed transactions {Token, Data, Handshake} that are completed under the same model as all other transactions.

SuperSpeed improves on the USB 2.0 transaction protocol by using the independent transmit and receive paths. The result is that the SuperSpeed USB transaction protocol is essentially a split transaction protocol that enables more than one OUT “bus transaction” as well as at most one IN “bus transaction” to be active on the bus at the same time. The order in which a device replies to transactions is fixed on a per endpoint basis. The order a device replies to ACKs or DPs that are sent to different endpoints on the device is device implementation dependent and software cannot expect them to occur/complete in any particular order. The split-transaction protocol scales well with signaling bit-rates as it is not subject to propagation delays.

The USB 2.0 protocol completes an entire IN or OUT transaction {Token, Data, Handshake} before continuing to the next bus transaction for the next scheduled function endpoint. All transmissions from the host are essentially broadcast on the USB 2.0 bus. In contrast, the SuperSpeed protocol does not broadcast any packets and packets traverse only the links needed to reach the intended recipient. The host starts all transactions by sending handshakes or data and devices reply with either data or handshakes. If the device does not have data available or cannot accept the data, it replies with a packet that states that it is not able to do so.

Subsequently, when the device is ready to either receive or transmit data it sends a notification to the host that indicates that it is ready to resume transactions. In addition, SuperSpeed provides the ability to transition links into and out of specific low power states. Lower power link states are entered either under software control or under autonomous hardware control after being enabled by software. Mechanisms are provided to automatically transition all links in the path between the host and a device from a non-active power state to the active power state.

Devices report the maximum packet size for each endpoint in its endpoint descriptor. The size indicates data payload length only and does not include any of the overhead for link and protocol level. Bandwidth allocation for SuperSpeed is similar to USB 2.0.

Data Bursting

Data Bursting enhances efficiency by eliminating the wait time for acknowledgements on a per data packet basis. Each endpoint on a SuperSpeed device indicates the number of packets that it can send/receive (called the maximum data burst size) before it has to wait for an explicit handshake. Maximum data burst size is an individual endpoint capability; a host determines an endpoint’s maximum data burst size from the SuperSpeed Endpoint Companion descriptor associated with this endpoint.

The host may dynamically change the burst size on a per-transaction basis up to the configured maximum burst size. Examples of when a host may use different burst sizes include, but are not limited to, a fairness policy on the host and retries for an interrupt stream. When the endpoint is an OUT, the host can easily control the burst size (the receiver must always be able to manage a transaction burst size). When the endpoint is an IN, the host can limit the burst size for the endpoint on a per-transaction basis through a field in the acknowledgement packet sent to the device.

IN Transfers

The host and device must follow the constraints of the transfer type and endpoint characteristics. A host begins a transfer by sending an acknowledgement packet (IN) to the device. This acknowledgement packet contains the addressing information required to route the packet to the intended endpoint. The host tells the device the number of data packets it can send and the sequence number of the first data packet expected from the device. In response the endpoint will transmit data packet(s) with the appropriate sequence numbers back to the host. The acknowledgement packet also implicitly acknowledges the previous data packet that was received successfully.

Note that even though the host is required to send an acknowledgement packet for every data packet received, the device can send up to the number of data packets requested without waiting for any acknowledgement packet.

An IN transfer on the SuperSpeed bus consists of one or more IN transactions consisting of one or more packets and completes when any one of the following conditions occurs:

  • All the data for the transfer is successfully received.
  • The endpoint acknowledges with a packet that is less than the endpoint’s maximum packet size.
  • The endpoint acknowledges with an error.

SuperSpeed IN Transaction Protocol

— IMAGE —

OUT Transfers

The host and device must follow the constraints of the transfer type and endpoint characteristics. A host begins a transfer by sending a burst of data packets to the device. Each data packet contains the addressing information required to route the packet to the intended endpoint. It also includes the sequence number of the data packet. For a non-isochronous transaction, the device returns an acknowledgement packet including the sequence number for the next data packet and implicitly acknowledging the current data packet.

Note that even though the device is required to send an acknowledgement packet for every data packet received, the host can send up to the maximum burst size number of data packets to the device without waiting for an acknowledgement.

OUT transfer on the SuperSpeed bus consists of one or more OUT transactions consisting of one or more packets and completes when any one of the following conditions occurs:

  • All the data for the transfer is successfully transmitted.
  • The host sends a packet that is less than the endpoints maximum packet size.
  • The endpoint acknowledges with an error.

SuperSpeed OUT Transaction Protocol

— IMAGE —

Power Management and Performance

Using inactivity timers and device-driven link power management give SuperSpeed the ability for very aggressive power management. When the host sends a packet to a device behind a hub with a port whose link is in a non-active state, the packet will not be able to traverse the link until it returns to the active state. In the case of an IN transaction, the host will not be able to start another IN transaction until the current one completes. The affect of this behavior could have a significant impact on overall performance.

To balance power management with good performance, the concept of a deferral is used on both IN and OUT transfers. When a host begins a transaction that encounters a link in a non-active state, a deferred response is sent by the hub to tell the host that this particular path is in a reduced power managed state and that the host should go on to schedule other transactions. In addition, the hub sends a deferred request to the device to notify it that a transaction was attempted. This mechanism informs the host of added latency due to power management and allows the host to mitigate performance impacts that result from the link power management.

Control Transfers

Each device is required to implement the default control pipe as a message pipe. This pipe is intended for device initialization and management. This pipe is used to access device descriptors and to make requests of the device to manipulate its behavior (at a device-level). Control transfers must follow the same request definitions described in the High Speed USB 2.0 specification.

The SuperSpeed system will make a “best effort” to support delivery of control transfers between the host and devices. As with USB 2.0, a function and its client software cannot request specific bandwidth for control transfers.

Control Transfer Packet

Control endpoints have a fixed maximum control transfer data payload size of 512 bytes and have a maximum burst size of one. These maximums apply to all data transactions during the data stage of the control transfer.

A SuperSpeed device must report a value of 09H in the bMaxPacketSize field of its Device Descriptor. The Default Control Pipe must support a maximum sequence value of 32. For this metric, sequence values in the range 0-31 are used. The requirements for data delivery and completion of device-to-host and host-to-device Data stages are generally not changed between USB 2.0 and SuperSpeed.

Control Transfer Bandwidth Requirements

USB devices have no way to show the desired bandwidth for a control pip. A host balances the bus access requirements of all control pipes and pending transactions on those pipes to provide the best delivery between client software and functions on the device.

SuperSpeed requires that bus bandwidth be reserved to be available for use by control transfers as follows:

  • The transactions of a control transfer may be scheduled coincident with transactions for other function endpoints of any explained transfer type.
  • Retries of control transfers are not given priority over other best effort transactions.
  • If there are control and bulk transfers pending for multiple endpoints, control transfers for different endpoints are selected for service according to a fair access policy that is host controller implementation-dependent.
  • When a control endpoint delivers a flow control event (as explained in Section 8.10.1), the host will remove the endpoint from the actively scheduled endpoints. The host will resume the transfer to the endpoint upon receipt of a ready notification from the device.

 

These requirements allow control transfers between a host and devices to regularly move data across the SuperSpeed bus with “best effort.”

Control Transfer Data Sequences

SuperSpeed preserves the message format and general stage sequencing of control transfers just as in USB 2.0. The SuperSpeed USB 3.0 protocol explains some changes to the Setup and Status stages of a control transfer. However, all of the sequencing requirements for normal and error recovery scenarios explained in High Speed USB 2.0 specification directly map to the SuperSpeed Protocol.

Bulk Transfers

The Bulk transfer type is intended to support devices that want to communicate relatively large amounts of data at highly variable times where the transfer can use any available SuperSpeed bandwidth. A SuperSpeed Bulk function endpoint provides the following:

  • Access to the SuperSpeed bus on a bandwidth available basis
  • Guaranteed delivery of data, but no guarantee of bandwidth or latency

SuperSpeed retains the following characteristics of bulk pipes:

  • No data content structure is imposed on the communication flow for bulk pipes.
  • A bulk pipe is a stream pipe and, therefore, always has communication flow either into or out of the host for any pipe instance. If an application requires a bi-directional bulk communication flow, two bulk pipes must be used (one IN and one OUT).

Standard USB bulk pipes provide the ability to move a stream of data. SuperSpeed adds the concept of Streams that provide protocol-level support for a multi-stream model.

Bulk Transfer Data Packet Size

An endpoint for bulk transfers shall set the maximum data packet payload size in its endpoint descriptor to 1024 bytes. It also specifies the burst size that the endpoint can accept from or transmit on the SuperSpeed bus. The allowable burst size for a bulk endpoint shall be in the range of 1 to 16. All SuperSpeed bulk endpoints shall support sequence values in the range.

A host is required to support any SuperSpeed bulk endpoint. A host shall support all bulk burst sizes. The host ensures that no data payload of any data packet in a burst transaction will be sent to the endpoint that is larger than the maximum packet size. Additionally, it will not send more data packets than the reported maximum burst size. A bulk function endpoint must always transmit data payloads with data fields less than or equal to 1024 bytes. If the bulk transfer has more data than that, all data payloads in the burst transaction are required to be 1024 bytes in length except for the last data payload in the burst, which may contain the remaining data. A bulk transfer may span multiple bus transactions. A bulk transfer is complete when the endpoint does one of the following:

  • Has transferred exactly the amount of data expected.
  • Transfers a data packet with a payload less than 1024 bytes.
  • Acknowledges with a STALL handshake.

Bulk Transfer Bandwidth Requirements

A bulk function endpoint has no way to show the desired bandwidth for a bulk pipe. Bulk transactions occur on the SuperSpeed bus only on a bandwidth available basis. SuperSpeed gives a “good effort” delivery of bulk data between client software and device functions. Moving control transfers over the SuperSpeed bus has priority over moving bulk transactions. When there are bulk transfers pending for multiple endpoints, the host will provide transaction opportunities to individual endpoints according to a fair access policy, which is host implementation dependent.

All bulk transfers pending in a system contend for the same available bus time. An endpoint and its client software cannot assume a specific rate of service for bulk transfers. Bus time made available to a software client and its endpoint can be changed as other devices are inserted into and removed from the system or as bulk transfers are requested for other function endpoints. Client software cannot assume ordering between bulk and control transfers.

The host can use any burst size between 1 and the reported maximum in transactions with a bulk endpoint to more effectively utilize the available bandwidth. For example, there may be more bulk transfers than bandwidth available, so a host can employ a policy of using smaller data bursts per transactions to provide fair service to all pending bulk data streams. When a bulk endpoint delivers a flow control event, the host will remove it from the actively scheduled endpoints. The host will resume the transfer to the endpoint upon receipt of a ready notification from the device.

Bulk Transfer Data Sequences

Bulk endpoints are launched to the initial transmit or receive sequence number and burst size by an appropriate control transfer (SetConfiguration, SetInterface, ClearEndpointFeature). Likewise, a host assumes the initial transmit or receive sequence number and burst size for bulk pipes after it has successfully completed the appropriate control transfer as mentioned above.

Halt conditions for a SuperSpeed bulk pipe have the identical side effects as explained for a USB 2.0 bulk endpoint. Recovery from halt conditions are also identical to USB 2.0. A bulk pipe halt condition includes a STALL handshake response to a transaction or exhaustion of the host’s transaction retry policy due to transmission errors.

Bulk Streams

A standard USB Bulk Pipe represents the ability to move single stream of (FIFO) data between the host and a device through a host memory buffer and a device endpoint. SuperSpeed streams provide protocol-level support for a multi-stream model and utilize the “stream” pipe communications mode. Streams are managed between the host and a device using the Stream Protocol. Each Stream is assigned a Stream ID (SID).

The Stream Protocol explains a handshake, which allows the device or host to establish the Current Stream (CStream) ID associated with an endpoint. The host uses the CStream ID to select the command or operation-specific Endpoint Buffer(s) that will be used for subsequent data transfers on the pipe. The device uses the CStream ID to select the Function Data buffer(s) that will be used.

USB SuperSpeed IN Stream

— IMAGE —

This shows you an example of an IN Bulk pipe, where a large number of Streams have been established. Associated with each Stream in host memory is one or more Endpoint Buffers to receive the Stream data. In the device, there is a corresponding command or operation-specific Function Data to be transmitted to the host.

When the device has data available for a specific Stream, it gives out an ERDY tagged with the CStream ID, and the host will begin issuing IN ACK TP’s to the device that is tagged with the CStream ID. The device will acknowledge by returning DPs that contain the Function Data associated with the CStream ID that is also tagged with the CStream ID. When the host receives the data, it uses the CStream ID to select the set of Endpoint Buffers that will receive the data.

When the Function Data is exhausted, the device terminates the Stream. The host is also allowed to terminate the Stream if it runs out of Endpoint Buffer space. Streams may be used, for example, to support out-of-order data transfers required for mass storage device command queuing.

A standard bulk endpoint has a single set of Endpoint Buffers associated with it. Streams extend the number of host buffers accessible by an endpoint from 1 to up to 65533. There is a 1:1 mapping between a host buffer and a Stream ID.

Device Class explained methods are used for coordinating the Stream IDs that are used by the host to select Endpoint Buffers and the device to select Function Data associated with a particular Stream. Typically this is done through an out-of-band mechanism that is used to pass the list of valid Stream IDs between the host and the device.

The selection of the Current Stream may be initiated by the host or the device and, in either case; the Stream Protocol provides a method for a selection to be rejected. For example, the host may reject a Stream selection initiated by the device if it has no Endpoint Buffers available for it. Or the device may reject a Stream selection initiated by the host if it has no Function Data available for it. The Device Class explains when a stream may be selected by the host or the device, and the actions that will be taken when a Stream is rejected.

A combination of vendor and Device Class explained algorithms determine how Streams are scheduled by a device. The Stream protocol provides methods for starting, stopping, and switching Streams.

Mechanisms explained by the Stream protocol allow the device or the host to flow control a Stream. These mechanisms overlap with the standard bulk flow control mechanism. The host also may start or stop a Stream. For instance, the host will stop a Stream if it runs out of buffer space for the Stream. When the host controller informs the device of this condition, the device may switch to another Stream or wait and continue the same Stream when the host receives more buffers.

The Stream Protocol also provides a mechanism which allows the host to asynchronously inform the device when Endpoint Buffers have been added to the pipe. This is useful in cases in which the host must terminate a stream because it ran out of Endpoint Buffers; however the device still has more Function Data to transfer. Without this mechanism, the device would have to periodically retry starting the Stream (impacting power management), or a long latency out-of-band method would be required.

Since Streams are run over a standard bulk pipe, an error will halt the pipe, stopping all stream activity. Removal of the halt condition is achieved through software intervention through a separate control pipe as it is for a standard bulk pipe. Finally, Streams significantly increase the functionality of a bulk endpoint, while having a minimal impact on the additional hardware required to support the feature in hosts and devices.

Interrupt Transfers

The purpose and characteristics of interrupt transfers are similar to those explained in USB 2.0. The SuperSpeed interrupt transfer types are intended to support devices that require a high reliability method to communicate a small amount of data with a bounded service interval. The Protocol Layer chapter of this specification describes the details of the packets, bus transactions and transaction sequences used to accomplish Interrupt transfers. The SuperSpeed Interrupt transfer type nominally provides the following:

  • Guaranteed maximum service interval
  • Guaranteed retry of transfer attempts in the next service interval

Interrupt transfers are attempted each service interval for an interrupt endpoint. Bandwidth is reserved to guarantee a transfer attempt each service interval. Once a transfer is successful, another transfer attempt is not made until the next service interval. If the endpoint replies with a not ready notification or an acknowledgement indicating that it cannot accept any more packets, the host will not attempt another transfer to that endpoint until it receives a ready notification. The host must then service the endpoint within twice the service interval after receipt of the notification. The requested service interval for the endpoint is described in its endpoint descriptor.

SuperSpeed retains the following characteristics of interrupt pipes:

  • No data content structure is imposed on communication flow for interrupt pipes.
  • An interrupt pipe is a stream pipe and, therefore, is always unidirectional.

Interrupt Transfer Packet Size

An endpoint for interrupt transfers specifies the maximum data packet payload size that it can accept from or transmit on the SuperSpeed bus. The only allowable maximum data payload size for interrupt endpoints is 1024 bytes for interrupt endpoints that support a burst size greater than one and can be any size from 1 to 1024 for an interrupt endpoint with a burst size equal to one. The maximum allowable burst size for interrupt endpoints is three. All SuperSpeed interrupt endpoints shall support sequence values in the range 0-31.

SuperSpeed interrupt endpoints are only intended for moving small amounts of data with a bounded service interval. The SuperSpeed protocol does not require the interrupt transactions to be maximum size.

A host is required to support SuperSpeed interrupt endpoints. A host shall support all allowed combinations of interrupt packet sizes and burst sizes. The host ensures that no data payload of any data packet in a burst transaction shall be sent to the endpoint that is larger than the endpoint’s maximum packet size. Also, the host shall not send more data packets in a burst transaction than the endpoint’s maximum burst size.

An interrupt endpoint shall always transmit data payloads with data fields less than or equal to the endpoint’s maximum packet size. If the interrupt transfer has more information than will fit into the maximum packet size for the endpoint, all data payloads in the burst transaction are required to be maximum packet size except for the last data payload in the burst transaction, which may contain the remaining data. An interrupt transfer may span multiple burst transactions. An interrupt transfer is complete when the endpoint does one of the following:

  • Has transferred exactly the amount of data expected.
  • Transfers a data packet with a payload less than the maximum packet size.
  • Replies with a STALL handshake.

Interrupt Transfer Bandwidth Requirements

Periodic endpoints may be allocated up to 80% of the total available bandwidth on SuperSpeed. An endpoint for an interrupt pipe specifies its desired service interval bound through its endpoint descriptor. An interrupt endpoint can specify a desired period 2(bInterval-1) x 125 μs, where bInterval is in the range 1 up to (and including) 16. The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period explained by the SuperSpeed (125 μs which is also referred to as a bus interval). Keep in mind that errors on the bus can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed the desired period.

A SuperSpeed interrupt endpoint can move up to three maximum sized packets (3 x 1024 bytes) per service interval. Interrupt transfers are moved over the USB by accessing an interrupt endpoint every service interval. For interrupt endpoints, the host has no way to determine whether the endpoint will source/sync data without accessing the endpoint and requesting an interrupt transfer. If an interrupt IN endpoint has no interrupt data to transmit or an interrupt OUT endpoint has insufficient buffer to accept data when accessed by the host, it replies with a flow control response.

An endpoint should only provide interrupt data when it has interrupt data pending to avoid having a software client erroneously notified of a transfer completion. A zero-length data payload is a valid transfer and may be useful for some implementations. The host may access an endpoint at any point during the service interval. The interrupt endpoint should not assume a fixed spacing between transaction attempts. The interrupt endpoint can assume only that it will receive a transaction attempt within the service interval bound. Errors can prevent the successful exchange of data within the service interval bound and a host is not required to retry the transaction in the same service interval and is only required to retry the transaction in the next service interval.

Interrupt Transfer Data Sequences

Interrupt transactions use the standard burst sequence for reliable data delivery protocol. Interrupt endpoints are initialized to the initial transmit or receive sequence number and burst size by an appropriate control transfer (SetConfiguration, SetInterface, and ClearEndpointFeature). A host sets the initial transmit or receive sequence number and burst size for interrupt pipes after it has successfully completed the appropriate control transfer.

Halt conditions for a SuperSpeed interrupt pipe have the identical side effects as explained for a USB 2.0 interrupt endpoint. Recovery from halt conditions are also identical to the USB 2.0. An interrupt pipe halt condition includes a STALL handshake response to a transaction or exhaustion of the host’s transaction retry policy due to transmission errors.

Isochronous Transfers

The purpose of SuperSpeed isochronous transfers is similar to those explained in USB 2.0. As in USB 2.0, the SuperSpeed isochronous transfer type is intended to support streams that want to perform error tolerant, periodic transfers within a bounded service interval. SuperSpeed does not transmit start of frames as on USB 2.0, but timing information is transmitted to devices through Isochronous Timestamp Packets (ITPs). The Protocol Layer chapter of this specification describes the details of the packets, bus transactions, and transaction sequences used to accomplish isochronous transfers. It also describes how the timing information is conveyed to devices. The SuperSpeed isochronous transfer type provides the following:

  • Guaranteed bandwidth for transaction attempts on the SuperSpeed bus with bounded latency.
  • Guaranteed data rate through the pipe as long as data is provided to the pipe.

Isochronous transactions are attempted each service interval for an isochronous endpoint. Isochronous endpoints that are admitted on the SuperSpeed bus are guaranteed the bandwidth they require on the bus. The host can request data from the device or send data to the device at any time during the service interval for a particular endpoint on that device. The requested service interval for the endpoint is described in its endpoint descriptor. The SuperSpeed isochronous transfer type is designed to support a source and sink that produce and consume data at the same average rate. A SuperSpeed isochronous pipe is a stream pipe and is always unidirectional. The endpoint description identifies whether a given isochronous pipe’s communication flow is into or out of the host. If a device requires bi-directional isochronous communication flows, two isochronous pipes must be used with one in each direction.

SuperSpeed power management may interfere with isochronous transfers whenever an isochronous transfer needs to traverse a non-active link. The resultant delay could result in the data not arriving within the service interval. To overcome this, SuperSpeed explains a PING and PING_RESPONSE mechanism. Before initiating an isochronous transfer the host may send a PING packet to the device. The device acknowledges with a PING_RESPONSE packet that tells the host that all the links in the path to the device are in the active state.

Isochronous Transfer Packet Size

An endpoint for isochronous transfers specifies the maximum data packet payload size that the endpoint can accept from or transmit on SuperSpeed. The only allowable maximum data payload size for isochronous endpoints is 1024 bytes for isochronous endpoints that support a burst size greater than one and can be any size from 0 to 1024 for an isochronous endpoint with a burst size equal to one. The maximum allowable burst size for isochronous endpoints is 16.

However an isochronous endpoint can request up to three burst transactions in the same service interval. The SuperSpeed protocol does not require the isochronous data packets to be maximum size. If an amount of data less than the maximum packet size is being transferred, the data packet shall not be padded.

A host shall support SuperSpeed isochronous endpoints for all allowed combinations of isochronous packet sizes and burst sizes. The host shall ensure that no data payload of any data packet in a burst transaction be sent to the endpoint that is larger than the reported maximum packet size. Also, the host shall not send more data packets in a burst transaction than the endpoint’s maximum burst size.

An isochronous endpoint shall always transmit data payloads with data fields less than or equal to the endpoint’s maximum packet size. If the isochronous transfer has more information than will fit into the maximum packet size for the endpoint, all data payloads in the burst transaction are required to be maximum packet size except for the last data payload in the burst transaction, which may contain the remaining data. An isochronous transfer may span multiple burst transactions.

Isochronous Transfer Bandwidth Requirements

Periodic endpoints can be allocated up to 80% of the total available bandwidth on SuperSpeed. An endpoint for an isochronous pipe specifies its desired service interval bound through its endpoint descriptor. An isochronous endpoint can specify a desired period 2(bInterval-1) x 125 μs, where bInterval is in the range 1 to 16. The system software will use this information during configuration to determine whether the endpoint can be added to the host schedule. Note that errors on the bus can prevent an isochronous transaction from being successfully delivered over the bus.

A SuperSpeed isochronous endpoint can move up to three burst transactions of up to 16 maximum sized packets (3 x 16 x 1024 bytes) per service interval. Isochronous transfers are moved over the USB by accessing an isochronous endpoint every service interval. The host will send data or request data to or from the endpoint every service interval. Note, if an endpoint has no isochronous data to transmit when accessed by the host, it shall send a zero length packet in response to the request for data.

The host may access an endpoint at any point during the appropriate service interval. The isochronous endpoint should not assume a fixed spacing between transaction attempts. The isochronous endpoint can assume only that it will receive a transaction attempt within the service interval bound. Errors may prevent the successful exchange of data within the service interval bound, however since the packets in an isochronous transaction are not acknowledged, a host has no way of knowing which packets were not received successfully and hence will not retry packets.

Isochronous Transfer Data Sequences

Isochronous endpoints always transmit data packets starting with sequence number zero in each service interval. Each successive data packet transmitted in the same service interval is sent with the next higher sequence number. The sequence number shall roll over from thirty one to zero when transmitting the thirty second packet. Isochronous endpoints do not support retries and cannot replieswith flow control responses.

Device Notifications

Device notifications are a standard method for a device to communicate asynchronous device- and bus-level event information to the host. This feature does not map to the pipe model explained for the standard transfer types. Device notifications are always initiated by a device and the flow of data information is always device to host. Device notifications do not have any data payload. Devices can send a device notification at any time.

Reliability

To ensure reliable operation, several layers of protection are used. This provides reliability for both flow control and data end to end.

Physical Layer

The SuperSpeed physical layer provides bit error rates less than 1 bit in 1012 bits.

Link Layer

The SuperSpeed link layer has mechanisms that ensure a bit error rate less than 1 bit in 1020 bits for header packets. The link layer uses a number of techniques including packet framing ordered sets, link level flow control and retries to ensure reliable end-to-end delivery for header packets.

Protocol Layer

The SuperSpeed protocol layer depends on a 32-bit CRC appended to the Data Payload and a timeout coupled with retries to ensure that reliable data is provided to the application.

Efficiency

SuperSpeed efficiency is dependent on a number of factors including 8b/10b symbol encoding, packet structure and framing, link level flow control, and protocol overhead. At a 5 Gbps signaling rate with 8b/10b encoding, the raw throughput is 500 MBps. When link flow control, packet framing, and protocol overhead are considered, it is realistic for 400 MBps or more to be delivered to an application.

Leave a Reply

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