Universal Serial Bus Specification Revision 2.0
`
`G (LSb)
`I
`D0 I D1
`
`Byte N-1
`
`D2 I D3 I D4
`
`Byte N
`
`Byte N+1
`
`(MSb)
`
`(LSb)
`
`Ds I D5 I D1 IG
`
`Data packet size varies with the transfer type, as described in Chapter 5.
`
`Figure 8-4. Data Field Format
`
`8.3.5 Cyclic Redundancy Checks
`Cyclic redundancy checks (CRCs) are used to protect all non-PID fields in token and data packets. In this
`context, these fields are considered to be protected fields. The PID is not included in the CRC check of a
`packet containing a CRC. All CRCs are generated over their respective fields in the transmitter before bit
`stuffing is performed. Similarly, CRCs are decoded in the receiver after stuffed bits have been removed.
`Token and data packet CRCs provide 100% coverage for all single- and double-bit errors. A failed CRC is
`considered to indicate that one or more of the protected fields is corrupted and causes the receiver to ignore
`those fields and, in most cases, the entire packet.
`
`For CRC generation and checking, the shift registers in the generator and checker are seeded with an all(cid:173)
`ones pattern. For each data bit sent or received, the high order bit of the current remainder is XORed with
`the data bit and then the remainder is shifted left one bit and the low-order bit set to zero. If the result of
`that XOR is one, then the remainder is XORed with the generator polynomial.
`
`When the last bit of the checked field is sent, the CRC in the generator is inverted and sent to the checker
`MSb first. When the last bit of the CRC is received by the checker and no errors have occurred, the
`remainder will be equal to the polynomial residual.
`
`A CRC error exists if the computed checksum remainder al the end of a packet reception does nol match the
`residual.
`
`Bit stuffing requirements must be met for the CRC, and this includes the need to insert a zero at the end of a
`CRC if the preceding six bits were all ones.
`
`8.3.5.1 Token CRCs
`A five-bit CRC field is provided for tokens and covers the ADDR and ENDP fields of IN, SETUP, and
`OUT tokens or the time stamp field of an SOF token. The PING and SPLIT special tokens also include a
`five-bit CRC field. The generator polynomial is:
`
`G(X) = XS+ X' + 1
`
`The binary bit pattern that represents this polynomial is 00101B. If all token bits are received without error,
`the five-bit residual at the receiver will be O 11 OOB.
`
`8.3.5.2 Data CRCs
`The data CRC is a 16-bit polynomial applied over the data field of a data packet. The generating
`polynomial is:
`
`G(X) =X1'+ X 1s+ X' + 1
`
`The binary bit pattern that represents this polynomial is 1000000000000101 B. If all data and CRC bits are
`received without error, the 16-bit residual will be 100000000000110 IB.
`
`198
`
`PA_0001408
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`8.4 Packet Formats
`
`This section shows packet formats for token, data, and handshake packets. Fields within a packet are
`displayed in these figures in the order in which bits are shifted out onto the bus.
`8.4.1 Token Packets
`
`Figure 8-5 shows the field formats for a token packet. A token consists of a PID, specifying either IN,
`OUT, or SETUP packet type and ADDR and ENDP fields. The PING special token packet also has the
`same fields as a token packet. For OUT and SETUP transactions, the address and endpoint fields uniquely
`identify the endpoint that will receive the subsequent Data packet. For IN transactions, these fields uniquely
`identify which endpoint should transmit a Data packet. For PING transactions, these fields uniquely
`identify which endpoint will respond with a handshake packet. Only the host can issue token packets. An
`IN PID defines a Data transaction from a function to the host. OUT and SETUP PIDs define Data
`transactions from the host to a function. A PING PID defines a handshake transaction from the function to
`the host.
`
`(lsb)
`
`(msb)
`
`Field
`
`PIO
`
`ADDR
`
`ENDP
`
`CRC5
`
`Bits
`
`8
`
`7
`
`4
`
`\
`
`f
`
`5
`
`J
`
`Figure 8-5. Token Format
`
`Token packets have a five-bit CRC that covers the address and endpoint fields as shown above. The CRC
`does not cover the PID, which has its own check field. Token and SOF packets are delimited by an EOP
`after three bytes of packet field data. If a packet decodes as an otherwise valid token or SOF but does not
`terminate with an EOP after three bytes, it must be considered invalid and ignored by the receiver.
`
`8.4.2 Split Transaction Special Token Packets
`USB defines a special token for split transactions: SPLIT. This is a 4 byte token packet compared to other
`nonnal 3 byte token packets. The split transaction token packet provides additional transaction types with
`additional transaction specific information. 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. There are two split transactions defined that use the SPLIT special
`token: a start-split transaction (SSPLIT) and a complete-split transaction (CSPLIT). A field in the SPLIT
`special token, described in the following sections, indicates the specific split transaction.
`
`8.4.2.1 Split Transactions
`A high-speed split transaction is used only between the host controller and a hub when the hub has full(cid:173)
`/low-speed devices attached to it. This high-speed split transaction is used to initiate a full-/low-speed
`transaction via the hub and some full-/low-speed device endpoint. The high-speed split transaction also
`allows the completion status of the full-/low-speed transaction to be retrieved from the hub. This approach
`allows the host controller to start a full-/low-speed transaction via a high-speed transaction and then
`continue with other high-speed transactions without having to wait for the full-/low-speed transaction to
`proceed/complete at the slower speed. See Chapter 11 for more details about the state machines and
`transaction definitions of split transactions.
`
`A high-speed split transaction has two parts: a start-split and a complete-split. Split transactions are only
`defined to be used between the host controller and a hub. No other high-speed or full-/low-speed devices
`ever use split transactions.
`
`199
`
`PA_0001409
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Figure 8-6 shows the packets composing a generic start-split transaction. There are two packets in the token
`phase: the SPLIT special token and a full-/low-speed token. Depending on the direction of data transfer and
`whether a handshake is defined for the transaction type, the token phase is optionally followed by a data
`packet and a handshake packet. Start split transactions can consist of 2, 3, or 4 packets as determined by the
`specific transfer type and data direction.
`
`SSPLIT
`Token
`
`FS/LS Token
`
`1
`I
`I DATAx j
`( _________ _
`
`,---------
`!_Handshake
`
`Token Phase
`Figure 8-6. Packets in a Start-split Transaction
`
`Figure 8-7 shows the packets composing a generic complete-split transaction. There are two packets in the
`token phase: the SPLIT special token and a full-/low-speed token. A data or handshake packet follows the
`token phase packets in the complete-split depending on the data transfer direction and specific transaction
`type. Complete split transactions can consist of 2 or 3 packets as determined by the specific transfer type
`and data direction.
`
`CSPLIT
`Token
`
`FS/LS Token
`
`f l._ D ___ A_T_Ax·-----
`or
`r--------------1
`I Handshake I
`
`Token Phase
`Figure 8-7. Packets in a Complete-split Transaction
`
`L_ _ ______
`
`_
`
`The results of a split transaction are returned by a complete-split transaction. Figure 8-8 shows this
`conceptual "conversion" for an example interrupt IN transfer type. The host issues a start-split (indicated
`with 1) to the hub and then can proceed with other high-speed transactions. The start-split causes the hub to
`issue a full-/low-speed IN token sometime later (indicated by 2). The device responds to the IN token (in
`this example) with a data packet and the hub responds with a handshake to the device. Finally, the host
`sometime later issues a complete-split (indicated by 3) to retrieve the data provided by the device. Note that
`in the example, the hub provided the full-/low-speed handshake (ACK in this example) to the device
`endpoint before the complete-split, and the complete-split did not provide a high-speed handshake to the
`hub.
`
`200
`
`PA_0001410
`
`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`(LSb)
`
`I Port 01 Port 11 Port 2 1 Port 3 1 Port 4 1 Port 5 1 Port 6 1
`
`(MSb)
`
`The S (Speed) field specifies the speed for this inten-upt or control transaction as follows:
`
`Figure 8-11. Port Field
`
`•
`
`•
`
`0 - Full speed
`
`1 - Low speed
`
`For bulk IN/OUT and isochronous IN start-splits, the S field must be set to zero. For bulk/control IN/OUT,
`inten-upt IN/OUT, and isochronous IN start-splits, the E field must be set to zero.
`
`For full-speed isochronous OUT start-splits, the S' (Start) and E (End) fields specify how the high-speed
`data payload con-esponds to data for a full-speed data packet as shown in Table 8-2.
`
`Table 8-2. Isochronous OUT Payload Continuation Encoding
`
`s
`
`E High-speed to Full-speed Data Relation
`
`0
`
`0
`
`High-speed data is the middle of the full-
`speed data payload
`
`0
`
`1 High-speed data is the end of the full-speed
`data payload
`
`1
`
`0
`
`High-speed data is the beginning of the full-
`speed data payload
`
`1
`
`1 High-speed data is all of the full-speed data
`payload.
`
`Isochronous OUT start-split transactions use these encodings to allow the hub to detect various en-or cases
`due to lack ofreceiving stmi-split transactions for an endpoint with a data payload that requires multiple
`start-splits. For example, a large full-speed data payload may require three start-split transactions: a start(cid:173)
`split/beginning, a start-split/middle and a start-split/end. If any of these transactions is not received by the
`hub, it will either ignore the full-speed transaction (if the start-split/beginning is not received), or it will
`force an en-or for the con-esponding full-speed transaction (if one of the other two transactions are not
`received). Other en-or conditions can be detected by not receiving a start-split during a microframe.
`
`The ET (Endpoint Type) field specifies the endpoint type of the full-/low-speed transaction as shown in
`Table 8-3.
`
`' The S bit can be reused for these encodings since isochronous transactions must not be low speed.
`
`203
`
`PA_0001413
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 8-3. Endpoint Type Values in Split Special Token
`
`ET value
`(msb:lsb)
`
`Endpoint
`Type
`
`00
`
`01
`
`10
`
`11
`
`Control
`
`Isochronous
`
`Bulk
`
`Interrupt
`
`This field tells the hub which split transaction state machine to use for this full-/low-speed transaction.
`
`The full-/low-speed device address and endpoint number information is contained in the normal token
`packet that follows the SPLIT special token packet.
`
`8.4.2.3 Complete-Split Transaction Token
`(lsb)
`
`(msb)
`
`Field SPLIT Hub
`PID Addr
`8
`7
`
`Bits
`
`SC Port s u ET
`
`CRC5
`
`1
`
`7
`
`1 1 2
`
`5
`
`Figure 8-12. Complete-split (CSPLIT) Transaction Token
`
`A SPLIT special token packet with the SC field set to one indicates that this is a complete-split transaction
`(CSPLIT).
`
`The U bit is reserved/unused and must be reset to zero(OB).
`
`The other fields of the complete-split token packet have the same definitions as for the start-split token
`packet.
`
`8.4.3 Start-of-Frame Packets
`Start-of-Frame (SOF) packets are issued by the host at a nominal rate of once every 1.00 ms ±0.0005 ms for
`a full-speed bus and 125 µs ±0.0625 µs for a high-speed bus. SOF packets consist of a PID indicating
`packet type followed by an 11-bit frame number field as illustrated in Figure 8-13.
`
`(lsb)
`
`Field
`
`PIO
`
`Bits
`
`8
`
`(msb)
`
`CRC5
`
`5
`
`11
`
`FrameNumber
`
`\...._ ______ }
`f
`
`Figure 8-13. SOF Packet
`
`The SOF token comprises the Loken-only transaction that distributes an SOF marker and accompanying
`frame number at precisely timed intervals corresponding to the start of each frame. All high-speed and full(cid:173)
`speed functions, including hubs, receive the SOF packet. The SOF token does not cause any receiving
`function to generate a return packet; therefore, SOF delivery to any given function cannot be guaranteed.
`
`204
`
`PA_0001414
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`The SOP packet delivers two pieces of timing information. A function is informed that an SOP has
`occurred when it detects the SOP PID. Frame timing sensitive functions, that do not need to keep track of
`frame number (e.g., a full-speed operating hub), need only decode the SOF PID; they can ignore the frame
`number and its CRC. If a function needs to track frame number, it must comprehend both the PID and the
`time stamp. Full-speed devices that have no particular need for bus timing information may ignore the SOP
`packet.
`
`8.4.3.1 USB Frames and Microframes
`USB defines a full-speed 1 ms frame time indicated by a Start Of Frame (SOF) packet each and every lms
`period with defined jitter tolerances. USB also defines a high-speed microframe with a 125 µs frame time
`with related jitter tolerances (See Chapter 7). SOP packets are generated (by the host controller or hub
`transaction translator) every lms for full-speed links. SOP packets are also generated after the next seven
`125 µs periods for high-speed links.
`
`Figure 8-14 shows the relationship between microframes and frames.
`
`Full I low-Speed Frame Size (1 ms)
`1 ms
`1 ms
`
`- -'--i Full-Speed USB Frame
`
`•••
`
`icks ~ Full-Sp ed Isochronous Data Payload
`
`High-Speed Micro-Fra s {125 us)
`
`1111111111111111 111111111111111 1111 ...
`U USB 2.0 Micro-Frame Ticks ~ .
`I High-Speed Isochronous Data Payload
`I (1/Sth Full-Speed Frame)
`
`Figure 8-14. Relationship between Frames and Microframes
`
`High-speed devices see an SOP packet with the same frame number eight times (every 125 µs) during each
`1 ms period. If desired, a high-speed device can locally dete1mine a particular microframe "number" by
`detecting the SOP that had a different frame number than the previous SOP and treating that as the zeroth
`microframe. The next seven SOFs with the same frame number can be treated as microframes 1 through 7.
`
`205
`
`PA_0001415
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`8.4.4 Data Packets
`A data packet consists of a PID, a data field containing zero or more bytes of data, and a CRC as shown in
`Figure 8-15. There are four types of data packets, identified by differing PIDs: DAT AO, DATAl, DATA2
`and MDATA. Two data packet PIDs (DATAO and DATAl) are defined to support data toggle
`synchronization (refer to Section 8.6). All four data PIDs are used in data PID sequencing for high
`bandwidth high-speed isochronous endpoints (refer to Section 5.9). Three data PIDs (MDATA, DAT AO,
`DATAl) are used in split transactions (refer to Sections 11.17-11.21).
`
`(lsb)
`
`Field
`
`PIO
`
`Bits
`
`8
`
`(msb)
`
`CRC16
`
`16
`
`DATA
`
`0-8192
`
`\...._ _______ }
`f
`
`Figure 8-15. Data Packet Format
`
`Data must always be sent in integral numbers of bytes. The data CRC is computed over only the data field
`in the packet and does not include the PID, which has its own check field.
`
`The maximum data payload size allowed for low-speed devices is 8 bytes. The maximum data payload size
`for full-speed devices is 1023. The maximum data payload size for high-speed devices is 1024 bytes.
`
`8.4.5 Handshake Packets
`Handshake packets, as shown in Figure 8-16, consist of only a PID. Handshake packets are used to report
`the status of a data transaction and can return values indicating successful reception of data, command
`acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control
`can return handshakes. Handshakes are always returned in the handshake phase of a transaction and may be
`returned, instead of data, in the data phase. Handshake packets are delimited by an EOP after one byte of
`packet field. If a packet decodes as an otherwise valid handshake but does not terminate with an EOP after
`one byte, it must be considered invalid and ignored by the receiver.
`
`(lsb) (msb)
`
`Field
`
`PIO
`
`Bits
`
`8
`
`There are four types of handshake packets and one special handshake packet:
`
`Figure 8-16. Handshake Packet
`
`• ACK indicates that the data packet was received without bit stuff or CRC errors over the data field and
`that the data PID was received correctly. ACK may be issued either when sequence bits match and the
`receiver can accept data or when sequence bits mismatch and the sender and receiver must
`resynchronize to each other (refer to Section 8.6 for details). An ACK handshake is applicable only in
`transactions in which data has been transmitted and where a handshake is expected. ACK can be
`returned by the host for IN transactions and by a function for OUT, SETUP, or PING transactions.
`
`• NAK indicates that a function was unable to accept data from the host (OUT) or that a function has no
`data to transmit to the host (IN). NAK can only be returned by functions in the data phase of IN
`transactions or the handshake phase of OUT or PING transactions. The host can never issue NAK.
`
`206
`
`PA_0001416
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`NAK is used for flow control purposes to indicate that a function is temporarily unable to transmit or
`receive data, but will eventually be able to do so without need of host intervention.
`
`•
`
`STALL is returned by a function in response to an IN token or after the data phase of an OUT or in
`response to a PING transaction (see Figure 8-30 and Figure 8-38). STALL indicates that a function is
`unable to transmit or receive data, or that a control pipe request is not supported. The state of a
`function after returning a STALL (for any endpoint except the default endpoint) is undefined. The host
`is not permitted to return a STALL under any condition.
`
`The STALL handshake is used by a device in one of two distinct occasions. The first case, known as
`"functional stall," is when the Halt feature associated with the endpoint is set. (The Halt feature is
`specified in Chapter 9 of this document.) A special case of the functional stall is the "commanded
`stall." Commanded stall occurs when the host explicitly sets the endpoint's Halt feature, as detailed in
`Chapter 9. Once a function's endpoint is halted, the function must continue returning STALL until the
`condition causing the halt has been cleared through host intervention.
`
`The second case, known as "protocol stall," is detailed in Section 8.5.3. Protocol stall is unique to
`control pipes. Protocol stall differs from functional stall in meaning and duration. A protocol ST ALL
`is returned during the Data or Status stage of a control transfer, and the ST ALL condition terminates at
`the beginning of the next control transfer (Setup). The remainder of this section refers to the general
`case of a functional stall.
`
`• NYET is a high-speed only handshake that is returned in two circumstances. It is returned by a high(cid:173)
`speed endpoint as part of the PING protocol described later in this chapter. NYET may also be
`returned by a hub in response to a split-transaction when the full-/low-speed transaction has not yet
`been completed or the hub is otherwise not able to handle the split-transaction. See Chapter 11 for
`more details.
`
`• ERR is a high-speed only handshake that is returned to allow a high-speed hub to report an error on a
`full-/low-speed bus. It is only returned by a high-speed hub as part of the split transaction protocol.
`See Chapter 11 for more details.
`
`8.4.6 Handshake Responses
`Transmitting and receiving functions must return handshakes based upon an order of precedence detailed in
`Table 8-4 through Table 8-6. Not all handshakes are allowed, depending on the transaction type and
`whether the handshake is being issued by a function or the host. Note that if an error occurs during the
`transmission of the token to the function, the function will not respond with any packets until the next token
`is received and successfully decoded.
`
`8.4.6.1 Function Response to IN Transactions
`Table 8-4 shows the possible responses a function may make in response to an IN token. If the function is
`unable to send data, due to a halt or a flow control condition, it issues a STALL or NAK handshake,
`respectively. If the function is able to issue data, it does so. If the received token is corrupted, the function
`returns no response.
`
`207
`
`PA_0001417
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 8-4. Function Responses to IN Transactions
`
`Token Received
`Corrupted
`
`Function Tx
`Endpoint Halt
`Feature
`
`Function Can
`Transmit Data
`
`Action Taken
`
`Yes
`
`No
`
`No
`
`No
`
`Don't care
`
`Don't care
`
`Return no response
`
`Set
`
`Not set
`
`Not set
`
`Don't care
`
`Issue STALL handshake
`
`No
`
`Yes
`
`Issue NAK handshake
`
`Issue data packet
`
`8.4.6.2 Host Response to IN Transactions
`Table 8-5 shows the host response to an IN transaction. The host is able to return only one type of
`handshake: ACK. If the host receives a corrupted data packet, it discards the data and issues no response.
`If the host cannot accept data from a function, (due to problems such as internal buffer overrun) this
`condition is considered to be an error and the host returns no response. If the host is able to accept data and
`the data packet is received error-free, the host accepts the data and issues an ACK handshake.
`
`Table 8-5. Host Responses to IN Transactions
`
`Data Packet
`Corrupted
`
`Host Can
`Accept Data
`
`Handshake Returned by Host
`
`Yes
`
`No
`
`No
`
`N/A
`
`No
`
`Yes
`
`Discard data, return no response
`
`Discard data, return no response
`
`Accept data, issue ACK
`
`8.4.6.3 Function Response to an OUT Transaction
`Handshake responses for an OUT transaction are shown in Table 8-6. Assuming successful token decode, a
`function, upon receiving a data packet, may return any one of the three handshake types. If the data packet
`was corrupted, the function returns no handshake. If the data packet was received error-free and the
`function's receiving endpoint is halted, the function returns STALL. If the transaction is maintaining
`sequence bit synchronization and a mismatch is detected (refer to Section 8.6 for details), then the function
`returns ACK and discards the data. If the function can accept the data and has received the data error-free,
`it returns ACK. If the function cannot accept the data packet due to flow control reasons, it returns NAK.
`
`208
`
`PA_0001418
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 8-6. Function Responses to OUT Transactions in Order of Precedence
`
`Data Packet Receiver
`Corrupted
`Halt
`Feature
`
`Sequence Bits Function Can
`Match
`Accept Data
`
`Handshake Returned
`by Function
`
`Yes
`
`No
`
`No
`
`No
`
`No
`
`N/A
`
`Set
`
`Not set
`
`Not set
`
`Not set
`
`N/A
`
`N/A
`
`No
`
`Yes
`
`Yes
`
`N/A
`
`N/A
`
`N/A
`
`Yes
`
`No
`
`None
`
`STALL
`
`ACK
`
`ACK
`
`NAK
`
`8.4.6.4 Function Response to a SETUP Transaction
`SETUP defines a special type of host-to-function data transaction that permits the host to initialize an
`endpoint's synchronization bits to those of the host. Upon receiving a SETUP token, a function must accept
`the data. A function may not respond to a SETUP token with either STALL or NAK, and the receiving
`function must accept the data packet that follows the SETUP token. If a non-control endpoint receives a
`SETUP token, it must ignore the transaction and return no response.
`
`8.5 Transaction Packet Sequences
`
`The packets that comprise a transaction varies depending on the endpoint type. There are four endpoint
`types: bulk, control, interrupt, and isochronous.
`
`A host controller and device each require different state machines to correctly sequence each type of
`transaction. Figures in the following sections show state machines that define the correct sequencing of
`packets within a transaction of each type. The diagrams should not be taken as a required implementation,
`but to specify the required behavior.
`
`Figure 8-17 shows the legend for the state machine diagrams. A circle with a three-line border indicates a
`reference to another (hierarchical) state machine. A circle with a two-line border indicates an initial state.
`A circle with a single-line border represents a simple state.
`
`209
`
`PA_0001419
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`- Contains other state machines
`
`- Initial state of a state machine
`
`- State in a state machine
`
`- Entry and exit of state machine
`
`- Joint used to connect transitions
`
`8
`
`I
`
`I
`
`Condition
`1 --A-c-ti-on_s _ _ ~ - Transition: taken when condition
`is true and performs actions
`
`~ - - - - - - -~
`
`Figure 8-17. Legend for State Machines
`
`The "tab" shapes with arrows are the entry or exit (respectively in the legend) to/from the state machine.
`The entry/exit relates to another state in a state machine at a higher level in the state machine hierarchy.
`
`A diamond Uoint) is used to join several transitions to a common point. A joint allows a single input
`transition with multiple output transitions or multiple input transitions and a single output transition. All
`conditions on the transitions of a path involving a joint must be true for the path to be taken. A path is
`simply a sequence of transitions involving one or more joints.
`
`A transition is labeled with a block with a line in the middle separating the (upper) condition and the (lower)
`actions. The condition is required to be true to take the transition. The syntax for actions and conditions is
`VHDL. The actions are performed if the transition is taken. A circle includes a name in bold and
`optionally one or more actions that are performed upon entry to the state.
`
`The host controller and device state machines are in a context as shown in Figure 8-18. The host controller
`determines the next transaction to run for an endpoint and issues a command (HC _ cmd) to the host
`controller state machines. This causes the host controller state machines to issue one or more packets to
`move over the downstream bus (HSDl).
`
`The device receives these packets from the bus (HSD2), reacts to the received packet, and interacts with its
`function(s) via the state of the corresponding endpoint (in the EP _array). Then the device may respond with
`a packet on the upstream bus (HSUl ). The host controller state machines can receive a packet from the bus
`(HSU2) and provide a result of the transaction back to the host controller (HC _resp). The details of what
`packets are sent on the bus is determined by the transfer type for the endpoint and what bus activity the state
`machines observe.
`
`The state machines are presented in a hierarchical form. Figure 8-19 shows the top level state machines for
`the host controller. The non-split transactions are presented in the remainder of this chapter. The split
`transaction state machines (HC_Do_start and HC_Do_complete) are described and shown in Chapter 11.
`
`210
`
`PA_0001420
`
`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`common to endpoint types are presented first. The lowest level endpoint type specific state machines are
`presented in each following endpoint type section.
`
`HC _Do_ nonsplit
`
`HC HS BCO
`
`HC Do BCINTO
`
`HC Do BCINTI
`
`HC Do IsochO
`
`HC Do Isochl
`
`Figure 8-20. Host Controller Non-split Transaction State Machine Hierarchy Overview
`
`Device Process trans
`
`Dev do OUT
`I Dev Do IsochO
`
`I Dev Do BCINTO
`
`I Dev_HS_BCO
`
`Dev do IN
`I Dev Do Isochl
`
`I Dev Do BCINTI
`
`I Dev_ HS _ping
`
`Figure 8-21. Device Transaction State Machine Hierarchy Overview
`
`212
`
`PA_0001422
`
`

`

`

`

`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`8.5.1 NAK Limiting via Ping Flow Control
`Full-/low-speed devices can have bulk/control endpoints that take time to process their data and, therefore,
`respond to OUT transactions with a NAK handshake. This handshake response indicates that the endpoint
`did not accept the data because it did not have space for the data. The host controller is expected to retry the
`transaction at some future time when the endpoint has space available. Unfortunately, by the time the
`endpoint NAKs, most of the full-/low-speed bus time for the transaction had been used. This means that the
`full-/low-speed bus has poor utilization when there is a high frequency ofNAK'd OUT transactions.
`
`High-speed devices must support an improved NAK mechanism for Bulk OUT and Control endpoints and
`transactions. Control endpoints must support this protocol for an OUT transaction in the data and status
`stages. The control Setup stage must not support the PING protocol.
`
`This mechanism allows the device to tell the host controller whether it has sufficient endpoint space for the
`next OUT transaction. If the device endpoint does not have space, the host controller can choose to delay a
`transaction attempt for this endpoint and instead try some other transaction. This can lead to improved bus
`utilization. The mechanism avoids using bus time to send data until the host controller knows that the
`endpoint has space for the data.
`
`The host controller queries the high-speed device endpoint with a PING special token. The PING special
`token packet is a normal token packet as shown in Figure 8-5 . The endpoint either responds to the PING
`with a NAK or an ACK handshake.
`
`A NAK handshake indicates that the endpoint does not have space for a wMaxPacketSize data payload. The
`host controller will retry the PING at some future time to query the endpoint again. A device can respond to
`a PING with a NAK for long periods of time. A NAK response is not a reason for the host controller to
`retire a transfer request. If a device responds with a NAK in a (micro)frame, the host controller may choose
`to issue the next transaction in the next blnterval specified for the endpoint. However, the device must be
`prepared to receive PIN Gs as sequential transactions, e.g., one immediately after the other.
`
`An ACK handshake indicates the endpoint has space for a wMaxPacketSize data payload. The host
`controller must generate an OUT transaction with a DATA phase as the next transaction to the endpoint.
`The host controller may generate other transactions to other devices or endpoints before the OUT /DAT A
`transaction for this endpoint.
`
`If the endpoint responds to the OUT /DAT A transaction with an ACK handshake, this means the endpoint
`accepted the data successfully and has room for another wMaxPacketSize data payload. The host controller
`continues with OUT/DATA transactions (which are not required to be the next transactions on the bus) as
`long as it has transactions to generate.
`
`If the endpoint instead responds to the OUT/DATA transaction with a NYET handshake, this means that the
`endpoint accepted the data but does not have room for another wMaxPacketSize data payload. The host
`controller must return to using a PING token until the endpoint indicates it has space.
`
`217
`
`PA_0001427
`
`

`

`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`8.5.2 Bulk Transactions
`Bulk transaction types are characterized by the ability to guarantee error-free delivery of data between the
`host and a function by means of error detection and retry. Bulk transactions use a three-phase transaction
`consisting of token, data, and handshake packets as shown in Figure 8-30. Under certain flow control and
`halt conditions, the data phase may be replaced with a handshake resulting in a two-phase transaction in
`which no data is transmitted. The PING and NYET packets must only be used with devices operating at
`high-speed.
`
`oken
`
`ata
`
`andshake
`
`Error
`
`Idle
`
`D Host D
`
`Function
`
`Figure 8-30. Bulk Transaction Format
`
`When the host is ready to receive bulk data, it issues an IN token. The function endpoint responds by
`returning either a data packet or, should it be unable to return data, a NAK or STALL handshake. NAK
`indicates that the function is temporarily unable to return data, while STALL indicates that the endpoint is
`permanently halted and requires USB System Software intervention. If the host receives a valid data
`packet, it responds with an ACK handshake. If the host detects an error while receiving data, it returns no
`handshake packet to the function.
`
`When the host is ready to transmit bulk data, it first issues an OUT token packet followed by a data packet
`( or PING special token packet, see Section 8.5 .1 ). If the data is received without error by the function, it
`will return o