1. Embedding USB technology Limitations, challenges and compliance
USB software specifications
November Christian Légaré

2. Outline Software specifications Packets Transfer types Transactions
Frames
Endpoints
Pipes

3. Packets The fundamental element of communications is the packet
A packet is made of three parts: START, INFORMATION, and END-OF-PACKET (EOP)
At the START of a packet will be a sequence of transitions which is called SYNC
The SYNC pattern is a chirp of either 8 bits (full-/low-speed) or 32 bits (high-speed) where each bit is a J or K state:
KJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKK
The INFORMATION varies from 1 byte up to 1024 bytes
Packet Identifier (PID) – 4bits + complement
Payload and CRC – Not present in handshake packets
The EOP is indicated by having both D+ and D- low for 3 bits (full-/low-speed) or 8 bits (high-speed). 3

4. USB Packet Fields Packet information Field Description
SYNC
All packets must start with a SYNC field. The SYNC field is 8 bits long at low and full speed or 32 bits long for high speed and is used to synchronize the clock of the receiver with that of the transmitter. The last two bits indicate where the PID fields starts.
Packet information
PID
PID stands for Packet ID. This field is used to identify the type of packet that is being sent.
ADDR
The address field specifies which device the packet is designated for. Being 7 bits in length allows for 127 devices to be supported. Address 0 is not valid, as any device which is not yet assigned an address must respond to packets sent to address zero.
ENDP
The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed devices, however can only have 2 additional endpoints on top of the default pipe. (4 endpoints max)
CRC
A CRC validates the correct reception of the data.
USB uses two different CRCs
a 5 bits long (CRC5) for token and handshake packets
and
a 16 bits long (CRC16) for data packets
EOP
End of Packet is signaled by a Single Ended Zero (SE0) for approximately 2 bit times followed by a J for 1 bit time. 4

5. USB Packet Fields : PID
The first byte in every packet is the Packet Identifier (PID) byte. This byte needs to be recognized quickly by the USB controller. This is why it is not included in any CRC checks. It has its own validity check. There are 4 bits to the PID. The check method uses the PID 4 bits by repeating and complementing them, making an 8 bit PID field in total.
PID0
PID1
PID2
PID3
nPID0
nPID1
nPID2
nPID3
PID shown in transmission order, LSB first. 5

6. USB Packet Fields : PID
Group
PID Value
Packet Identifier
Token
0001
OUT
1001 IN
0101
SOF (Start of frame)
1101
SETUP
Data
0011
DATA0
1011
DATA1
0111
DATA2
1111
MDATA
Handshake
0010
ACK
1010
NAK
1110
STALL
0110
NYET (No Response Yet)
Special
1100
PRE (Host-issued preamble. Enables downstream bus traffic to low-speed devices)
ERR (Split Transaction Error Handshake (reuses PRE value))
1000
SPLIT (High-speed Split Transaction Token)
0100
PING (High-speed flow control probe for a bulk/control Endpoint)
0000
EXT - Reserved
The packet types which have been added for high speed are:
DATA2
MDATA
NYET
ERR
SPLIT
PING
This data packet token has been added as part of a system for controlling multiple isochronous IN packets during one microframe at high speed.
For each isochronous IN packet requested, the suffix of the DATAx PID represents the remaining number of packets to be transferred during the current micro-frame.
This data packet token has been added as part of a system for controlling multiple isochronous OUT packets during one microframe at high speed.
All but the last packet sent during a microframe use the MDATA PID. The last packet sent uses DATA0, DATA1 or DATA2 depending on whether one, two or three packets were sent.
NYET handshake packets are used in 2 different high speed situations.
One use is when a hub wishes to respond to a 'complete split' transaction to say that it is has not yet been completed.
The other use is during the high speed control or bulk OUT PING protocol. It means that the endpoint has accepted the data but is not yet ready for further data. A PING will need to be used to verify when it is ready for more data.
Used during the high speed split protocol by a hub, to indicate that there was an error on the full or low speed bus.
This packet introduces a Start Split transaction or a Complete Split transaction.
Split transactions are used at high speed to communicate to a hub, the details of a low or full speed transaction which it is expected to handle, and to get back the results.
A PING packet is used on high speed Control and Bulk OUT endpoints. They may be sent by the host to establish whether the endpoint is ready to accept a DATA0 or DATA1 packet, and will result in an ACK or a NAK packet from the device.
In the case of high speed, when the endpoint receives a packet it can not process, it replies with a NAK. The host will now send a PING instead of the complete data packet to verify when the endpoint is ready to accept the data. This is an efficiency improvement, as at full or low speed, the data packet has to be sent in full to get the endpoint response (ACK or NAK).
High Speed Transactions
The New Packets
The table on the right gives brief details of the purposes of the six new packet types.
Packet Identifier
Usage
The other use is during the high speed control or bulk OUT PING protocol. It means that the endpoint has accepted the data but is not yet ready for further data.
Used during the high speed split protocol by a hub, to indicate that there was an error on the full or low speed bus. SPLIT
This is an efficiency improvement, as at full or low speed, the data packet has to be sent in full, and only then can the endpoint respond with a NAK.
For the sake of completeness we will now look at the packet formats for all the available packets type, including the ones already covered for low and full speed.
There are five different packet formats based on which PID the packet starts with.
Token Packet
Sync
PID
ADDR
ENDP
CRC5
EOP
8 bits
7 bits
4 bits
5 bits
Used for SETUP, OUT, IN and PING packets. They are always the first packet in a transaction, identifying the targeted endpoint, and the purpose of the transaction.
(The SOF packet is also defined as a Token packet, but has a slightly different format and purpose, which is described below.)
The token packet contains two addressing elements:
Address (7 bits)
This device address can address up to 127 devices. Address 0 is reserved for a device which has not yet had its address set.
Endpoint number (4 bits)
There can be up to 16 possible endpoints in a device in each direction. The direction is implicit in the PID. OUT, SETUP and PING PIDs will refer to the OUT endpoint, and an IN PID will refer to the IN endpoint.
Data Packet
DATA
CRC16
(0-1024) x 8 bits
16 bits
Used for DATA0, DATA1, DATA2 and MDATA packets. If a transaction has a data stage this is the packet format used.
DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system. When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been re-sent because the host missed seeing the ACK the first time it sent the data packet.
DATA2 (along with DATA1 and DATA0) is used in High Speed links as part of a system for controlling multiple isochronous IN packets during one microframe at high speed.
MDATA (along with DATA2, DATA1 and DATA0) is used in High Speed links as part of a system for controlling multiple isochronous OUT packets during one microframe at high speed.
Handshake Packet
Used for ACK, NAK, STALL and NYET packets. This is the packet format used in the status stage of a transaction, when required.
ACK
Receiver acknowledges receiving error free packet.
NAK
Receiving device cannot accept data or transmitting device cannot send data.
STALL
Endpoint is halted, or control pipe request is not supported.
No response yet from receiver (high speed only).
SOF Packet
Frame No.
11 bits
The Start of Frame packet is sent every 1 ms on full speed links. The frame is used as a time frame in which to schedule the data transfers which are required. For example, an isochronous endpoint will be assigned one transfer per frame.
Frames and Microframes
On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet.
At high speed the 1 ms frame is divided into 8 microframes of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms frame.
Split Packet
Hub Addr SC
Port S E ET
1 bit
7 bits 1 bit 1 bit 2 bits 5 bits
The SPLIT packet is the first packet in either a Start Split transaction or a Complete Split transaction, sent to a high speed hub when it is handling a low or full speed device.
Control, Interrupt or Bulk Endpoints
SC Start / Complete 0 = Start, 1 = Complete
S Speed 0 = Full, 1 = Low
E not used 0
ET Endpoint Type
00 = Control 01 = Isochronous 10 = Bulk 11 = Interrupt
Isochronous Endpoints
S and E Start and End
00 = HS data is middle of FS data payload
01 = HS data is end of FS data payload
10 = HS data is start of FS data payload
11 = HS data is all of FS data payload
High Speed Bulk Transactions
These work much like full speed bulk transactions. The differences are:
The maximum packet size can only be specified as 512 bytes.
A more efficient method of doing OUT transfers has been introduced, involving the use of PING transactions, and the new NYET handshake packet.
Ping Protocol
Before sending an OUT transaction to a bulk endpoint, the host controller may send a PING packet. The response to the PING will be ACK or NAK. ACK means that the endpoint is ready to accept an OUT transaction of maximum packet size for the endpoint. NAK means it is not. The host may continue to send PINGs after a NAK, or it may choose to wait for a number of microframes before re-trying.
On high speed Bulk OUT endpoints, the endpoint descriptor value bInterval is required to specify the NAK rate of the endpoint. The specification is misleading when it defines this value. The value represents the number of microframes which the host would have to wait, after receiving a NAK in response to a PING, before a further PING is guaranteed to elicit an ACK response. 0 means the endpoint never NAKs.
A further new feature is that, after a successful OUT transaction, the endpoint may respond with ACK to indicate that it is already prepared to accept a further packet, or NYET to indicate that it received the data correctly, but is not yet ready to accept further data.
The first 2 bits of a Token which are transmitted determine which of the 4 groups it falls into. SOF is officially considered to be a Token PID. Bits are transmitted LSB first. 6

7. USB Packet Types USB has four different packet types.
Start of Frame Packets
Token Packets
Data Packets
Handshake Packets & Split Transaction Special Token Packets 7

8. Start of Frame Packets
Start of frame packets indicate the start of a new frame. The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± µs on a high speed bus.
The first transaction in each (micro)frame. An SOF allows endpoints to identify the start of the (micro)frame and synchronize internal endpoint clocks to the host. 8

9. Token Packets
Token packets indicate the type of transaction to follow. They are always the first packet in a transaction, identifying the targeted endpoint, and the purpose of the transaction.
There are three types of token packets: In
Informs the USB device that the host wishes to read information.
Out
Informs the USB device that the host wishes to send information.
Setup
Used to begin control transfers. 9

10. Data Packets - Low and Full speed
Data packets contain the payload.
There are two types of data packets each capable of transmitting up to 1024 bytes of data.
Data0
Data1
DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system.
When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not the expected packet, it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been retransmitted because the host missed seeing the ACK after the previous data packet. 10

11. Data Packets - High Speed
High Speed mode defines two additional data PIDs, DATA2 and MDATA.
DATA2
This data packet token has been added as part of a system for controlling multiple isochronous IN packets during one microframe at high speed. For each isochronous IN packet requested, the suffix of the DATAx PID represents the remaining number of packets to be transferred during the current micro-frame.
MDATA
This data packet token has been added as part of a system for controlling multiple isochronous OUT packets during one microframe at high speed. All but the last packet sent during a microframe use the MDATA PID. The last packet sent uses DATA0, DATA1 or DATA2 depending on whether one, two or three packets were sent. 11

12. Handshake Packets
Handshake packets are used for acknowledging data or reporting errors. There are four type of handshake packets which consist simply of the PID.
ACK
Acknowledgment that the packet has been successfully received.
NAK
Reports that the device temporary cannot send or receive data. Also used during interrupt transactions to inform the host there is no data to send.
STALL
The device finds itself in a state that requires intervention from the host (Endpoint is halted, or control pipe request is not supported)
NYET
The device is not ready to answer (High Speed only). 12

13. Split Transaction Special Token Packets
The split transaction token is used to support split transactions between the host controller communicating with a hub operating at high speed with full-/low-speed devices to some of its downstream facing ports.
Control, Interrupt or Bulk Endpoints
Isochronous Endpoints SC
Start / Complete
0 = Start, 1 = Complete S
Speed
0 = Full, 1 = Low E
not used ET
Endpoint Type
00 = Control 01 = Isochronous 10 = Bulk 11 = Interrupt SC
Start / Complete
0 = Start, 1 = Complete
S and E
Start and End
00 = HS data is middle of FS data payload
01 = HS data is end of FS data payload
10 = HS data is start of FS data payload
11 = HS data is all of FS data payload ET
Endpoint Type
00 = Control 01 = Isochronous 10 = Bulk 11 = Interrupt
The SPLIT packet is the first packet in either a Start Split transaction or a Complete Split transaction, sent to a high speed hub when it is handling a low or full speed device. 13

14. Transfer (Control, Interrupt, Isochronous, Bulk)
Hierarchy of data
Transfer (Control, Interrupt, Isochronous, Bulk)
Transaction 1
Transaction 2
Transaction 3
Transaction n
….. … … …
Packet 1
Packet 2
Packet 3
Packet 1
Packet 2
Packet 1
Packet 2
Packet
Token: OUT, IN, SOF, SETUP
Data: DATA0, DATA1, DATA2, MDATA
Handshake: ACK, NAK, STALL, NYET
Special: PRE, ERR, SPLIT, PING 14

15. Transactions A successful transaction is
a sequence of three packets which performs a simple but secure transfer of data.
For IN and OUT transactions used for isochronous transfers,
there are only 2 packets;
the handshake packet on the end is omitted. This is because error-checking is not required.
There are three types of transaction.
In each of the following illustrations, the packets from the host are indicated with the blue line, and the packets from the device with the red line.
USB is made up of several layers of protocols. We really only have to worry about the higher level layers. Most USB controller ICs will take care of the lower layer, thus making it almost invisible to the end designer.
As we have already discussed, USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow and whether the data transaction will be a read or write and what the device’s address and designated endpoint is. The next packet is generally a data packet carrying the payload and is followed by an handshaking packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not available to accept data.
A transaction is the delivery of service to an endpoint. it consists of a token packet, optional data packet, and optional handshake packet.
Specific packets are allowed/required based on the transaction type.
Some bus transactions between host controllers and hubs involve the transmission of four packets. These types of transactions are used to manage the data transfers between the host and full-/low- speed devices.
A transaction of a particular transfer type typically requires multiple packets. 15

16. SETUP Transaction
A successful SETUP transaction comprises three sequential packets. This is similar to an OUT transaction, but the data payload is exactly 8 bytes long, and the SETUP PID in the token packet informs the device that this is the first transaction in a Control Transfer (see standard requests). SETUP transaction always uses a DATA0 to start the data packet.
Token
Packet
Data
Packet
Handshake
Packet
ENDP
CRC5
DATA0
CRC16
8 bytes
SETUP DATA
SETUP
ADDR
ACK
From Host
From Device
1 SETUP transaction

17. OUT Transaction
A successful OUT transaction comprises two or three sequential packets. Isochronous Transfer does not use the handshake packet from the device as data checking is counter productive for real-time data.
On a low or full speed link, the PID shown as DATAx will be either a DATA0 or a DATA1. An alternating DATA0/DATA1 is used as a part of the error control protocol to (or from) a particular endpoint.
Token
Packet
Data
Packet
Handshake
Packet
ENDP
CRC5
DATAx
CRC16
OUT
ADDR
PAYLOAD DATA
ACK
Each USB transaction consists of a
Token Packet (Header defining what it expects to follow), an
Optional Data Packet, (Containing the payload) and a
Status Packet (Used to acknowledge transactions and to provide a means of error correction)
A successful transaction is a sequence of three packets which performs a simple but secure transfer of data.
For IN and OUT transactions used for isochronous transfers, there are only 2 packets; the handshake packet on the end is omitted. This is because error-checking is not required.
There are three types of transaction. In each of the following illustrations, the packets from the host are indicated with the blue line, and the packets from the device with the red line.
From Host
From Device
1 OUT transaction

18. IN Transaction
A successful IN transaction comprises two or three sequential packets. Isochronous Transfer does not use the handshake packet from the device as data checking is counter productive for real-time data. Here again, the DATAx is either a DATA0 or a DATA1.
Handshake
Packet
Token
Packet
Data
Packet
ENDP
CRC5
DATAx
CRC16 IN
ADDR
PAYLOAD DATA
ACK
1 IN transaction
From Host
From Device

19. Split Transactions Transaction Translator
The Transaction Translator in a high speed hub handles the full or low speed transactions to particular ports.
Transaction Translator
Each high speed hub is required to have a 'Transaction Translator' which handles the full or low speed transactions to particular ports. This includes the root hub.
The transaction translator prevents full or low speed traffic from degrading the high speed bus performance.

20. Periodic Split Transactions
Interrupt and Isochronous
Bandwidth guarantee on low/full speed bus need to be transferred to high speed bus.
Periodic transactions on full or low speed bus are transferred in packets of data of at most 188 bytes.
The longest low/full speed periodic transfer of 1023 bytes is transferred in multiple split transactions.
A split packet covering multiple microframes will use the MDATA PID to indicate that it is not completed.
An Interrupt IN at 64 bytes maximum can take up to 2 microframes.
An Isochronous IN at 1023 bytes maximum will span up to 6 microframes.
Split Interrupt and Isochronous transactions need special treatment because of the bandwidth guarantee which they offer. Every full / low speed device using these endpoint types, which is added to the bus, is given a guaranteed allocation on the full / low speed bus, which also has to be conveyed on the high speed bus. The mechanism is complex and described in full in chapter 11 of the USB specification.
The result of this mechanism is that periodic transactions on the full or low speed bus are transferred in packets of data of at most 188 bytes.
So a longer transaction, which can be up to 1023 bytes long for an isochronous endpoint, will be transferred in multiple Start Split transactions for OUT transfers, or multiple Complete Split transactions for IN transfers.
Furthermore, on periodic IN transactions, data received by the hub from the device within a given microframe is sent in response to a Complete Split, even though it represents only part of the full or low speed data packet. A full speed interrupt IN packet of, say, 64 bytes, which spans two microframes, will be conveyed in up to two Complete Splits. The data packet in the first part will use an MDATA PID to indicate that it is not complete.
Isochronous IN transactions are similar, but can span up to 6 microframes.

21. Transfers types A transfer is made of one of more transactions
Description
Control
Is non-periodic. It is used mostly for commands and status operations. Mandatory using Endpoint 0 OUT and Endpoint 0 IN.
Isochronous
Has a fixed number of bytes per frame. The bandwidth is guaranteed. No error-checking
Interrupt
Is periodic and the latency between transactions is guaranteed. Error-free and low throughput
Bulk
Is not periodic and it is used mostly to transfer large amounts of data. Error-free high volume throughput when bandwidth available
Another more notable feature of USB, is its transfer modes. USB supports Control, Interrupt, Bulk and Isochronous transfers.
Isochronous allows a device to reserve a defined about of bandwidth with guaranteed latency. This is ideal in Audio or Video applications where congestion may cause loss of data or frames to drop. Each transfer mode provides the designer trade-offs in areas such as error detection and recovery, guaranteed latency and bandwidth. 21

22. Control transfer - Example : Control Read
SETUP Stage
SETUP Stage
ENDP
CRC5
DATA0
CRC16
8 bytes
SETUP DATA
SETUP
ADDR
ACK
DATA Stage (optional)
ENDP
CRC5
DATA1
CRC16 IN
ADDR
PAYLOAD DATA
ACK
ENDP
CRC5
DATA0
CRC16 IN
ADDR
PAYLOAD DATA
ACK
Control Transfer
This is a bi-directional transfer which uses both an IN and an OUT endpoint. Each control transfer is made up of from 2 to several transactions.
It is divided into three stages.
The SETUP stage carries 8 bytes called the Setup packet. This defines the request, and specifies whether and how much data should be transferred in the DATA stage.
The DATA stage is optional. If present, it always starts with a transaction containing a DATA1. The type of transaction then alternates between DATA0 and DATA1 until all the required data has been transferred.
The STATUS stage is a transaction containing a zero-length DATA1 packet. If the DATA stage was IN then the STATUS stage is OUT, and vice versa.
Control transfers are used for initial configuration of the device by the host, using Endpoint 0 OUT and Endpoint 0 IN, which are reserved for this purpose. They may be used (on the same endpoints) after configuration as part of the device-specific control protocol, if required.
The max packet size for the data stage is 8 bytes at low speed, 8, 16, 32 or 64 at full Speed and 64 for high speed.
Error Control - IN
If the IN token packet is not recognized, the device will not respond at all. Otherwise, if it has data to send it will send it in a DATA0 or DATA1 packet, If it is not ready to send data it will send a NAK packet. If the endpoint is currently 'halted' then it will respond with a STALL packet.
In the case of DATA0/1 being sent, the host will acknowledge with an ACK, unless the data is not validly received, in which case it does not send an ACK. (Note: the host never sends NAK!)
Error Control - OUT
If the OUT token packet is not recognized, the device will not respond at all. It will then ignore the DATAx packet because it does not know that it has been addressed.
If the OUT token is recognized but the DATAx packet is not recognized, then the device will not respond.
If the data is received but the device can't accept it at this time, it will send a NAK, and if the endpoint is currently halted, it will send a STALL.
STATUS Stage
ENDP
CRC5
DATA1
CRC16
OUT
ADDR
ACK
From Host
From Device

23. Bulk transfer - Example
ENDP
CRC5
DATA0
CRC16
OUT
ADDR
PAYLOAD DATA
ACK
Bulk transfers can be used for large bursty data. Such examples could include a print-job sent to a printer or an image generated from a scanner.
Bulk transfers provide error correction in the form of a CRC16 field on the data payload and error detection/re-transmission mechanisms ensuring data is transmitted and received without error.
Bulk transfers will use spare un-allocated bandwidth on the bus after all other transactions have been allocated. If the bus is busy with isochronous and/or interrupt then bulk data may slowly trickle over the bus.
It is recommended to use Bulk transfers when a lot of data need to be transmitted as fast as possible, but where it would not be a large problem if there is a delay caused by insufficient bandwidth.
As a result Bulk transfers should only be used for time insensitive communication as there is no guarantee of latency.
The max packet size is 8, 16, 32 or 64 at full Speed and 512 for high speed. Bulk transfers are not allowed at low speed.
If the data payload falls short of the maximum packet size, it doesn't need to be padded with zeros. A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size or transferred a zero-length packet.
Bulk Transfers
Used to transfer large bursty data.
Error detection via CRC, with guarantee of delivery.
No guarantee of bandwidth or minimum latency.
Stream Pipe - Unidirectional
Full & high speed modes only. IN
If the IN token packet is not recognized, the device will not respond at all. Otherwise, if it has data to send it will send it in a DATA0 or DATA1 packet, If it is not ready to send data it will send a NAK packet. If the endpoint is currently 'halted' then it will respond with a STALL packet.
In the case of DATA0/1 being sent, the host will acknowledge with an ACK, unless the data is not validly received, in which case it does not send an ACK. (Note: the host never sends NAK!)
OUT
If the OUT token packet is not recognized, the device will not respond at all. It will then ignore the DATAx packet because it does not know that it has been addressed.
If the OUT token is recognized but the DATAx packet is not recognized, then the device will not respond.
If the data is received but the device can't accept it at this time, it will send a NAK, and if the endpoint is currently halted, it will send a STALL.
From Host
From Device

24. Interrupt transfer - Example
ENDP
CRC5
DATA1
CRC16 IN
ADDR
PAYLOAD DATA
ACK
Any one who has had experience of interrupt requests on microcontrollers will know that interrupts are device generated. However under USB if a device requires the attention of the host, it must wait until the host polls it before it can report that it needs urgent attention!
Interrupt Transfers
Guaranteed Latency
Stream Pipe - Unidirectional
Error detection and next period retry.
Interrupt transfers are typically non-periodic, small device "initiated" communication requiring bounded latency. An Interrupt request is queued by the device until the host polls the USB device asking for data.
Interrupt transfers are regularly scheduled IN or OUT transactions, although the IN direction is the more common usage.
Typically the host will only fetch one packet, at an interval specified in the endpoint descriptor (see descriptors later). The host guarantees to perform the IN transaction at least that often, but it may actually do it more frequently.
The maximum data payload size for low-speed devices is 8 bytes.
Maximum data payload size for full-speed devices is 64 bytes.
Maximum data payload size for high-speed devices is 1024 bytes.
Use an interrupt transfer when you need to be regularly kept up to date of any changes of status in a device. Examples of interrupt transfer based devices are for a mouse or a keyboard.
Some JTAG probe manufacturer have cleverly used this transfer mode to guarantee their device throughput.
From Host
From Device

25. Isochronous transfer - Example
ENDP
CRC5
DATA1
CRC16 IN
ADDR
PAYLOAD DATA
Isochronous transfers have a guaranteed bandwidth. Isochronous transfer does not provide guaranteed error-free delivery.
Applications such as audio or video stream data transfer uses isochronous transfers. These transfers contain time sensitive information. It is important to maintain the data flow, but not so important if some data gets missed or corrupted. If there were a delay or retry of data in an audio or video stream, the time sensitiveness of the information would be lost. The user would experience some erratic content glitches. With time sensitive information . The periodicity of the information must as much as possible always be in sync. It is preferable to drop a packet or frame every now and then, then retransmitting or delay it.
An isochronous transfer uses either an IN transaction or an OUT transaction depending on the type of endpoint. The special feature of these transactions is that there is no handshake packet at the end.
An isochronous packet may contain up to 1023 bytes at full speed, or up to 1024 at high speed. Isochronous transfers are not allowed at low speed.
Isochronous Transfers provide
Guaranteed access to USB bandwidth.
Bounded latency.
Stream Pipe - Unidirectional
Error detection via CRC, but no retry or guarantee of delivery.
Full & high speed modes only.
No data toggling.
The maximum size data payload is specified in the endpoint descriptor of an Isochronous Endpoint. This can be up to a maximum of 1023 bytes for a full speed device and 1024 bytes for a high speed device. As the maximum data payload size is going to effect the bandwidth requirements of the bus, it is wise to specify a conservative payload size. If you are using a large payload, it may also be to your advantage to specify a series of alternative interfaces with varying isochronous payload sizes. If during enumeration, the host cannot enable your preferred isochronous endpoint due to bandwidth restrictions, it has something to fall back on rather than just failing completely. Data being sent on an isochronous endpoint can be less than the pre-negotiated size and may vary in length from transaction to transaction.
From Host
From Device

26. High Speed Transfers
High speed control transfers are the same as full and low speed transfers but with the exception that the maximum packet size is 64 bytes.
For the Data Stage, it is the same as for high speed bulk transfer including the PING protocol rules for a High Speed Bulk OUT transaction.
For the Status Stage, it is the same as for a bulk transfer.

27. High Speed Isochronous Transfers
Isochronous IN Protocol
When requesting IN transactions, the device packages them in DATA2, DATA1 or DATA0 packets, depending on how many packets per microframe are specified.
One transaction per microframe
DATA0
Two transactions per microframe
DATA1
High speed isochronous transfers have an extended control system to allow up to 3 isochronous transactions per microframe, allowing a data rate of up to 192 Mb/s. (The specification refers to an isochronous endpoint with more than 1 packet per microframe as a 'High Bandwidth' endpoint.)
Isochronous IN
When requesting IN transactions, the device packages them in DATA2, DATA1 or DATA0 packets, depending on how many packets per microframe are specified, and which one it is.
As isochronous transactions do not include a acknowledgement (handshake) packet, this sequence of packets allows the recipient to be aware, if a data packet is lost, which one it was.
DATA0
Three transactions per microframe
DATA2
DATA1
DATA0

28. High Speed Isochronous Transfers
Isochronous OUT Protocol
When sending OUT transactions, the host packages them either in MDATA or DATA0 or DATA1 or DATA2 packets.
One transaction per microframe
DATA0
Two transactions per microframe
MDATA
Isochronous OUT
When sending OUT transactions, the host packages the transactions either in MDATA or DATA0 DATA1 or DATA2 packets.
The sequence of packets used in Isochronous IN that allows the recipient to be aware, if a data packet is lost, which one it was can not apply to Isochronous OUT transfers with three transactions per microframe because the first two packets use MDATA as a PID.
DATA1
Three transactions per microframe
MDATA
MDATA
DATA2

29. Maximum DATA packet size
Transfer Type
Attributes
High Speed
Full Speed
Low Speed
Examples
Control
Quality + time 64
8,16,32 or 64 8
System control
Bulk
Quality
<512 NA
Printer, scanner
Interrupt
<1024
<64
Mouse, keyboard
Isochronous
Time
<3072
<1023
Audio, video
Enpoints have several attributes in addition to their type. One of them being the maximum quantity of data that the endpoint can provide or consume in a single transaction.
A single transfer can involve less than the maximum quantity of data an endpoint can handle.
Packets per (Micro)frame
At high speed it is possible to specify up to 3 isochronous or interrupt transfers per microframe, rather than the 1 transfer per frame of full speed; giving a maximum possible isochronous or interrupt transfer rate of 192 Mb/s.

30. Frames All USB communication links are broken into frames
The first packet of each frame is the Start-Of-Frame packet (SOF)
A frame is transmitted every 1 ms in low and full speed
At high speed the 1 ms frame is divided into 8 microframes of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms.
A high-speed microframe is 125µs to minimize the buffer requirement
On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet.
USB establishes a 1 millisecond time base called a frame on a full-/low-speed bus and a 125 μs time base called a microframe on a high-speed bus. A (micro)frame can contain several transactions. Each transfer type defines what transactions are allowed within a (micro)frame for an endpoint. Isochronous and interrupt endpoints are given opportunities to the bus every N (micro)frames
USB has a start of frame packet or keep alive sent periodically on the bus. This prevents an idle bus from entering suspend mode in the absence of data.
A high speed bus will have micro-frames sent every µs ±62.5 ns.
A full speed bus will have a frame sent down each ms ±500 ns.
A low speed bus will have a keep alive which is a EOP (End of Packet) every 1ms only in the absence of any low speed data. 30

31. Frames and Microframes
Full Speed Frames (1 ms)
SOF
SOF n
n+1
8 High Speed Microframes (125 us)
SOF
SOF
SOF
SOF
SOF
SOF
SOF
SOF
SOF n n n n n n n n
n+1

32. Bandwidth Management
The host is responsible in managing the bandwidth of the bus. No more than 90% of any frame to be allocated for periodic transfers (Interrupt and Isochronous) on a full speed bus. (80% in high speed) In a highly saturated bus with periodic transfers, the remaining 10% is left for control transfers and once those have been allocated, bulk transfers will get its slice of what is left…and bulk is what is used for Mass Storage Class. Bandwidth allocation for SuperSpeed is similar to USB 2.0. 32

33. Bandwidth Management
All USB transactions are performed in 1mSec frames (LS and FS) or 125 µSec frames (HS) initiated by the Host. Time Division Multiplexing is used to separate packets or transactions from different sources within each frame. 33

34. Endpoints
All packets are sent to and received by the USB device via endpoints.
Endpoints are buffers where a device either puts or gets data
Each endpoint has a direction, IN or OUT and an address
Up to 32 endpoints can reside within a device
Endpoint 0 is always the control endpoint and is bidirectional (IN/OUT)
A device can have up to 15 additional OUT and 15 additional IN endpoints with each its buffer
The endpoint direction is implicit in the PID.
OUT and SETUP PIDs refer to the OUT endpoint
IN PID refers to the IN endpoint.
Never share endpoints between interfaces
Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints occur at the end of the communications channel at the USB function. At the software layer, the device driver may send a packet to the devices EP1 for example. As the data is flowing out from the host, it will end up in the EP1 OUT buffer. The firmware will then at its leisure read this data. If it wants to return data, the function cannot simply write to the bus as the bus is controlled by the host. Therefore it writes data to EP1 IN which sits in the buffer until such time when the host sends a IN packet to that endpoint requesting the data. Endpoints can also be seen as the interface between the hardware of the function device and the firmware running on the function device.
All devices must support endpoint zero. This is the endpoint which receives all of the devices control and status requests during enumeration and throughout the duration while the device is operational on the bus.
The performance of a device controller is represented by the endpoint specification of the device.
-Number of endpoint
-Support transfer type
-FIFO size of endpoint
The EP configuration essentially determines if a device is suited for an application or not 34

35. Endpoints and Pipes
Once an endpoint is identified and defined, a pipe is established There is no hardware relation to a pipe. For example, there are no registers in the USB controller identifying the pipe. It is a pure logical connection between a source or destination on the host USB Class and on the interface on a device
The pipe is only removed once the device is removed from the USB bus
The USB specification defines an endpoint as a “uniquely addressable portion of an USB device that is either a source or sink of info in a communication flow ”.. True, except in the case of the control endpoint which is bidirectional.
Functions and hubs have associated pipes (logical channels). Pipes are connections from the host controller to a logical entity on the device named an endpoint. Each endpoint can transfer data in one direction only, either into or out of the device/function, so each pipe is unidirectional. The pipe logically connects the device endpoint with its matching class driver and its corresponding instance on the host.
Note that there is not hardware definition for a pipe. There are no registers associated to pipes. On the device side, the endpoint is the device side end of each pipe.
On the host side, the pipe can be use to differentiate when multiple instances of a driver is used to control multiple devices.
In USB, there are a numbers of logical communication pipes between HOST and DEVICE . Pipes are associated to a specific endpoint.

36. USB's actual throughput
Function of:
target device's ability to source or sink data,
the bandwidth consumption of other devices on the bus, and
the efficiency of the host's USB software stack.
Assuming Host and Device CPU can follow line speed, it is a function of:
Transfer type and
Signaling rate
(In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints.)
Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints. 36

37. Transfer impacts on communication flow
Each transfer type determines various characteristics of the communication flow including the following:
Data format imposed by the USB
Direction of communication flow
Packet size constraints
Bus access constraints
Latency constraints
Required data sequences
Error handling
The designers of a USB device choose the capabilities for the device’s endpoints. 37

38. Table Calculation for the transfer impacts
Each table shows:
The protocol overhead required for the specific transfer type (and speed)
For some sample data payload sizes:
The maximum sustained bandwidth possible for this case
The percentage of a (micro)frame that each transaction requires
The maximum number of transactions in a (micro)frame for the specific case
The remaining bytes in a (micro)frame that would not be required for the specific case
The total number of data bytes transported in a single (micro)frame for the specific case
A transaction of a particular transfer type typically requires multiple packets.
The protocol overhead for each packet includes:
a 8-bits (FS/LS) or 32-bits (HS) SYNC field
a PID byte
A 3-bits (FS/LS) or 8-bits (HS) EOP
In a token packet: endpoint number + device address + CRC5 = 16 bits
In a data packet: 16-bits CRC16 + any data field (8 bits per byte)
For transaction with multiple packets, the inter packet gap or bus turnaround time required.
For these calculations, there is assumed to be no bit-stuffing required.
A transaction of a particular transfer type typically requires multiple packets. The protocol overhead for each transaction includes:
• A SYNC field for each packet: either 8 bits (full-/low-speed) or 32 bits (high-speed)
• A PID byte for each packet: includes PID and PID invert (check) bits
• An EOP for each packet: 3 bits (full-/low-speed) or 8 bits (high-speed)
• In a token packet, the endpoint number, device address, and CRC5 fields (16 bits total)
• In a data packet, CRC16 fields (16 bits total)
• In a data packet, any data field (8 bits per byte)
• For transaction with multiple packets, the inter packet gap or bus turnaround time required.
For these calculations, there is assumed to be no bit-stuffing required. 38

39. Low-speed Control Transfer Limits

40. Full-speed Control Transfer Limits

41. High-speed Control Transfer Limits

42. Full-speed Isochronous Transaction Limits

43. High-speed Isochronous Transaction Limits

44. Low-speed Interrupt Transaction Limits

45. Full-speed Interrupt Transaction Limits

46. High-speed Interrupt Transaction Limits

47. Full-speed Bulk Transaction Limits

48. High-speed Bulk Transaction Limits

49. USB 2.0 VS USB 3.0 USB 2.0 USB 3.0 Bus protocol Host directed
Polling traffic flow
Packet traffic is broadcast to all devices
Asynchronous traffic flow
Packets traffic is explicitly routed
Power management
Multi-level link power management supporting idle, sleep and suspend states. Link, Device and Function level power management
Port-level suspend
Device level power management
Data transfer types
Control
Bulk
Interrupt
Isochronous
Bulk (bursting, streaming)
Differences between USB 2.0 and USB 3.0
SuperSpeed is backward compatible with USB 2.0 at the framework level. However, there are some fundamental differences between the USB 2.0 and SuperSpeed protocol:
• 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 incorporated in the data packet; while for INs, the Token is replaced by a handshake.
• USB 2.0 does not support bursting while SuperSpeed supports continuous bursting.
• USB 2.0 is a half-duplex broadcast bus while SuperSpeed is a dual-simplex unicast bus which allows concurrent IN and OUT transactions.
• USB 2.0 uses a polling model while SuperSpeed uses asynchronous notifications.
• USB 2.0 does not have a Streaming capability while SuperSpeed supports Streaming for bulk endpoints.
• USB 2.0 offers no mechanism for isochronous capable devices to enter the low power USB bus state between service intervals. SuperSpeed allows isochronous capable devices to autonomously enter low-power link states between service intervals. A SuperSpeed host shall 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 offers no mechanism for device to inform the host how much latency the device can tolerate if the system enters lower system power state. Thus a host may not enter lower system power states as it might impact a device's performance because it lacks an understanding of a device's power policy. USB 3.0 provides a mechanism to allow SuperSpeed devices to inform host of their latency tolerance using Latency Tolerance Messaging. The host may use this information to establish a system power policy that accounts for the devices’ latency tolerance.
• USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals. A device driver may change the interval with small finite adjustments depending on the implementation of host and system software. USB 3.0 adds mechanism for devices to send a Bus Interval Adjustment Message that is used by the host to adjust its 125 μs bus interval up to +/ μs. In addition, the host may 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 supports link-level power management that may be initiated from either end of the link. Thus, each link can independently enter low-power states whenever idle and exit whenever communication is needed.
• 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.

50. USB 3.0 Link Power Management
The key points of link power management include:
Devices send asynchronous ready notifications to the host.
Packets are routed, allowing links that are not involved in data communications to transition to and/or remain in a low power state.
Packets that encounter ports in low power states cause those ports to transition out of the low power state with indications of the transition event.
Multiple host or device driven link states with progressively lower power at increased exit latencies.
Lower power link states are entered either under software control or under autonomous hardware control after being enabled by software.

51. USB 3.0 packets
USB 3.0 has four packet type, each with one or more subtypes:
Link Management Packet (LMP)
Transaction Packet (TP)
Data Packet (DP)
Isochronous Timestamp Packet (ITP)
All packets
14 byte header including CRC-16 and 2 byte Link Control Word = 16 bytes.
The first field is the Type field.
In a TP or a DP header, Routing String and Device Address follow the Type field.
Routing String tells the hubs where to forward the packets to their downstream ports. Packets received from hubs on their downstream ports are automatically forward to their upstream port in their way to the host.
In an packet to the host, the Device Address is provided so that the host can identify the source of the packet.

52. USB 3.0 LMP
Link Management Packets are used to manage the link between two link partners. The LMP commands to manage a link are:
Set Link Function
U2 Inactivity Timeout
Vendor Device Test
Port Capability
Port Configuration
Port Configuration Response
USB 3.0 Specifications, page 8-5

53. USB 3.0 TP
Transaction Packets are used to control the flow of packets between the host and device. TPs do not contain application data and have a number of different subtypes:
Acknowledgement (ACK)
Not Ready (NRDY)
Endpoint Ready (ERDY)
STATUS
STALL
Device Notification (DEV_NOTIFICATION)
PING
PING_RESPONSE
USB 3.0 Specifications, page 8-12

54. USB 3.0 DP
Data Packets are used to transmit application data between the host and device. A Data Packet is composed of a Data Packet Header (DPH) and the Data Packet Payload (DPP). Since data is being sent between the host and device, DP packets have a route string to direct it to intended device
USB 3.0 Specifications, page 8-23

55. USB 3.0 ITP
Isochronous Timestamp Packets (ITP) are used to send timestamps to all devices for synchronization. ITPs are the only packets that are broadcast by the host to all active devices. Since this packet is broadcast, it does not require a route string.
Only hosts are allowed to send ITPs, and only when the host port is already in the U0 state. Devices are not required to respond to the ITP.
USB 3.0 Specifications, page 8-25

56. USB 3.0
Hubs are part of the enumeration process to create the Routing string from Host to Device
Hubs ports are configurable (ON/OFF)
Polling is reduced because of the full duplex nature of the USB 3.0 protocol (i.e. NAK and ERDY)
Because transmitters are aware of the data to be transmitted, power savings are possible when in idle state.

57. Summary
We just started to describe the first level of software. If it is not clear now that USB is complex, we will raise the stakes with the Host and Device stacks and with the USB Classes. Also, with the complexity of packets, transactions and transfers, a USB Protocol Analyzer is a great asset when working with USB technology.