`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`After completion of the reset sequence, a hub is in the following state:
`
`• Hub Controller default address is 0.
`
`• Hub status change bits are set to zero.
`
`• Hub Repeater is in the WFSOPFU state.
`
`•
`
`Transmitter is in the Inactive state.
`
`• Downstream facing ports are in the Not Configured state and SEO driven on all downstream facing
`ports.
`
`11.11 Hub Port Power Control
`Self-powered hubs may have power switches that control delivery of power downstream facing ports but it
`is not required. Bus-powered hubs are required to have power switches. A hub with power switches can
`switch power to all ports as a group/gang, to each port individually, or have an arbitrary number of gangs of
`one or more ports.
`
`A hub indicates whether or not it supports power switching by the setting of the Logical Power Switching
`Mode field in wHubCharacteristics. If a hub supports per-port power switching, then the power to a port is
`turned on when a SetPortFeature(PORT _POWER) request is received for the port. Port power is turned off
`when the port is in the Powered-off or Not Configured states. If a hub supports ganged power switching,
`then the power to all ports in a gang is turned on when any port in a gang receives a
`SetPortFeature(PORT_POWER) request. The power to a gang is not turned off unless all ports in a gang
`are in the Powered-off or Not Configured states. Note, the power to a port is not turned on by a
`SetPortFeature(PORT _POWER) if both C _HUB_ LOCAL _POWER and Local Power Status (in
`wHubStatus) are set to 1B at the time when the request is executed and the PORT_POWER feature would
`be turned on.
`
`Although a self-powered hub is not required to implement power switching, the hub must support the
`Powered-off state for all ports. Additionally, the hub must implement the PortPwrCtr!Mask (all bits set to
`IB) even though the hub has no power switches that can be controlled by the USB System Software.
`
`Note: To ensure compatibility with previous versions ofUSB Software, hubs must implement the Logical
`Power Switching Mode field in wHubCharacteristics. This is because some versions of SW will not use the
`SetPortFeature() request if the hub indicates in wHubCharacteristics that the port does not support port
`power switching. Otherwise, the Logical Power Switching Mode field in wHubCharacteristics would have
`become redundant as of this version of the specification.
`
`The setting of the Logical Power Switching Mode for hubs with no power switches should reflect the
`manner in which over-current is reported. For example, if the hub reports over-current conditions on a per(cid:173)
`port basis, then the Logical Power Switching Mode should be set to indicate that power switching is
`controlled on a per-port basis.
`
`For a hub with no power switches, bPwrOn2PwrGood must be set to zero.
`
`11.11.1 Multiple Gangs
`A hub may implement any number of power and/or over-current gangs. A hub that implements more than
`one over-cLment and/or power switching gang must set both the Logical Power Switching Mode and the
`Over-current Reporting Mode to indicate that power switching and over-current reporting are on a per port
`basis (these fields are in wHubCharacteristics). Also, all bits in PortPwrCtr!Mask must be set to IB.
`
`When an over-current condition occurs on an over-current protection device, the over-current is signaled on
`all ports that are protected by that device. When the over-current is signaled, all the p01is in the group are
`placed in the Powered-off state, and the C _PORT_ OVER-CURRENT field is set to 1B on all the ports.
`When port status is read from any port in the group, the PORT_OVER-CURRENT field will be set to 1B as
`
`335
`
`PA_0001545
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`long as the over-current condition exists. The C_PORT_OVER-CURRENT field must be cleared in each
`port individually.
`
`When multiple ports share a power switch, setting PORT_POWER on any port in the group will cause the
`power to all ports in the group to tum on. IL will not, however, cause the other ports in that group to leave
`the Powered-off state. When all the ports in a group are in the Powered-off state or the hub is not
`configured, the power to the ports is turned off.
`
`lf a hub implements both power switching and over-current, it is not necessary for the over-current groups
`to be the same as the power switching groups.
`
`If an over-current condition occurs and power switches are present, then all power switches associated with
`an over-current protection circuit must be turned off. If multiple over-current protection devices are
`associated with a single power switch then that switch will be turned off when any of the over-cLment
`protection circuits indicates an over-current condition.
`
`11.12 Hub Controller
`The Hub Controller is logically organized as shown in Figure 11-19.
`
`UPSTREAM ONNECTION
`
`Status Change
`Endpoint
`
`ENDPOINT 0:
`Configuration
`lnfonnation
`
`Port 1
`
`Port N
`
`Port 3
`Port 2
`Figure 11-19. Example Hub Controller Organization
`
`11.12.1 Endpoint Organization
`The Hub Class defines one additional endpoint beyond Default Control Pipe, which is required for all hubs:
`the Status Change endpoint. The host system receives port and hub status change notifications through the
`Status Change endpoint. The Status Change endpoint is an interrupt endpoint. If no hub or port status
`change bits are set, then the hub returns an NAK when the Status Change endpoint is polled. When a status
`change bit is set, the hub responds with data, as shown in Section 11.12.4, indicating the entity (hub or port)
`with a change bit set. The USB System Software can use this data to determine which status registers to
`access in order to determine the exact cause of the status change interrupt.
`
`336
`
`PA_0001546
`
`

`

`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`cause the power on another port to fall below specified minimums. In this case, the affected port is placed
`in the Powered-off state and C _PORT_ OVER_ CURRENT is set for the port, but
`PORT_OVER_CURRENT is not set. If the hub has over-cun-ent detection on a hub basis, then an over(cid:173)
`cun-ent condition on the hub will cause all ports to enter the Powered-off state. However, in this case,
`neither C_PORT_OVER_CURRENT nor PORT_OVER_CURRENT is set for the affected ports.
`
`Host recovery actions for an over-cUil"ent event should include the following:
`
`1. Host gets change notification from hub with over-cun-ent event.
`
`2. Host extracts appropriate hub or port change information (depending on the information in the
`change bitmap).
`
`3. Host waits for over-cun-ent status bit to be cleared to 0.
`
`4. Host cycles power on to all of the necessary ports (e.g., issues a SetPortFeature(PORT_POWER)
`request for each port).
`
`5. Host re-enumerates all affected ports.
`
`11.12.6 Enumeration Handling
`The hub device class commands are used to manipulate its downstream facing port state. When a device is
`attached, the device attach event is detected by the hub and reported on the status change inten-upt. The host
`will accept the status change report and request a SetPortFeature(PORT_RESET) on the port. As part of the
`bus reset sequence, a speed detect is performed by the hub's port hardware.
`
`The Gel_Status(PORT) request invoked by the host will return a "nol PORT_LOW _SPEED and
`PORT_HIGH_SPEED" indication for a downstream facing port operating at high-speed. The
`Get_Status(PORT) will report "PORT_LOW _SPEED" for a downstream facing port operating at low(cid:173)
`speed. The Get_Status(PORT) will report "not PORT_LOW _SPEED and not PORT_HIGH_SPEED" for a
`downstream facing port operating at full-speed.
`
`When the device is detached from the port, the port reports the status change through the status change
`endpoint and the port will be reconnected to the high-speed repeater. Then the process is ready to be
`repeated on the next device attach detect.
`
`11.13 Hub Configuration
`Hubs are configured through the standard USB device configuration commands. A hub that is not
`configured behaves like any other device that is not configured with respect to power requirements and
`addressing. If a hub implements power switching, no power is provided to the downstream facing ports
`while the hub is not configured. Configuring a hub enables the Status Change endpoint. The USB System
`Software may then issue commands to the hub to switch port power on and off at appropriate times.
`
`The USB System Software examines hub descriptor infonnation to determine the hub's characteristics. By
`examining the hub's characteristics, the USB System Software ensures that illegal power topologies are not
`allowed by not powering on the hub's ports if doing so would violate the USB power topology. The device
`status and configuration info1mation can be used to determine whether the hub should be used as a bus or
`self-powered device. Table 11-12 summarizes the information and how it can be used to determine the
`cun-ent power requirements of the hub.
`
`340
`
`PA_0001550
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 11-12. Hub Power Operating Mode Summary
`
`Configuration Descriptor
`
`MaxPower
`
`bmAttributes
`(Self Powered)
`
`Hub
`Device Status
`(Self Power)
`
`Explanation
`
`0
`
`0
`
`0
`
`>0
`
`>0
`
`>0
`
`0
`
`1
`
`1
`
`0
`
`1
`
`1
`
`N/A
`
`N/A
`This is an illegal set of information.
`
`0
`
`1
`
`N/A
`
`0
`
`1
`
`N/A
`A device which is only self-powered, but does
`not have local power cannot connect to the bus
`and communicate.
`
`Self-powered only hub and local power supply is
`good. Hub status also indicates local power
`good, see Section 11.16.2.5. Hub functionality is
`valid anywhere depth restriction is not violated.
`
`Bus-powered only hub. Downstream facing
`ports may not be powered unless allowed in
`current topology. Hub device status reporting
`Self Powered is meaningless in combination of a
`zeroed bmAttributes. Self-Powered.
`
`This hub is capable of both self- and bus-
`powered operating modes. It is currently only
`available as a bus-powered hub.
`
`This hub is capable of both self- and bus-
`powered operating modes. It is currently
`available as a self-powered hub.
`
`A self-powered hub has a local power supply, but may optionally draw one unit load from its upstream
`connection. This allows the interface to function when local power is not available (see Section 7.2.1.2).
`When local power is removed ( either a hub-wide over-current condition or local supply is off), a hub of this
`type remains in the Configured state but transitions all ports (whether removable or non-removable) to the
`Powered-off state. While local power is off, all port status and change information read as zero and all
`SetPortFeature() requests are ignored (request is treated as a no-operation). The hub will use the Status
`Change endpoint to notify the USB System Software of the hub event (see Section 11.24.2.6 for details on
`hub status).
`
`The MaxPower field in the configuration descriptor is used to report to the system the maximum power the
`hub will draw from VBUS when the configuration is selected. For bus-powered hubs, the reported value
`must not include the power for any of external downstream facing ports. The external devices attaching to
`the hub will report their individual power requirements.
`
`A compound device may power both the hub electronics and the permanently attached devices from VBUS .
`The entire load may be reported in the hubs' configuration descriptor with the permanently attached devices
`each reporting self-powered, with zero MaxPower in their respective configuration descriptors.
`
`341
`
`PA_0001551
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.14 Transaction Translator
`A hub has a special responsibility when it is operating in high-speed and has full-/low-speed devices
`connected on downstream facing ports. In this case, the hub must isolate the high-speed signaling
`environment from the full-/low-speed signaling environment. This function is performed by the Transaction
`Translator (TT) portion of the hub.
`
`This section defines the required behavior of the transaction translator.
`
`11.14.1 Overview
`Figure 11-24 shows an overview of the Transaction Translator. The TT is responsible for pmiicipating in
`high-speed split transactions on the high-speed bus via its upstTeam facing port and issuing corresponding
`full-/low-speed transactions on its downstream facing ports that are operating at full-/low-speed. The TT
`acts as a high-speed function on the high-speed bus and performs the role of a host controller for its
`downstream facing ports that are operating at full-/low-speed. The TT includes a high-speed handler to deal
`with high-speed transactions. The TT also includes a full-/low-speed handler that performs the role of a
`host controller on the downstream facing ports that are operating at full-/low-speed.
`
`Full/Low Speed Bus
`
`Figure 11-24. Transaction Translator Overview
`
`The TT has buffers (shown in gray in the figure) to hold transactions that are in progress and tracks the state
`of each buffered transaction as it is processed by the TT. The buffers provide the connection between the
`high-speed and full-/low-speed handlers. The state tracking the TT does for each transaction depends on the
`specific USB transfer type of the transaction (i.e., bulk, control, interrupt, isochrnnous). The high-speed
`handler accepts high-speed start-split transactions or responds to high-speed complete-split transactions.
`The high-speed handler places the start-split transactions in local buffers for the full-/low-speed handler's
`use.
`
`The buffered start-split transactions provide the full-/low-speed handler with the infonnation that allows it
`to issue corresponding full-/low-speed transactions to full-/low-speed devices attached on downstream
`facing ports. The full-/low-speed handler buffers the results of these full-/low-speed transactions so that
`they can be returned with a corresponding complete-split transaction on the high-speed bus.
`
`The general conversion between full-/low-speed transactions and the corresponding high-speed split
`transaction protocol is described in Section 8.4.2. More details about the specific transfer types for split
`transactions are described later in this chapter.
`
`342
`
`PA_0001552
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`The high-speed handler of the TT operates independently of the full-/low-speed handler. Both handlers use
`the local transaction buffers to exchange information where required.
`
`ransact10n Trans ator
`
`Bulk&
`Control
`
`Interrupt &
`Isochronous
`
`Figure 11-25. Periodic and Non-periodic Buffer Sections of TT
`
`The TT has two buffer and state tracking sections (shown in gray in Figure 11-24 and Figure 11-25):
`periodic (for isochronous/intenupt full-/low-speed transactions) and non-periodic (for bulk/control full(cid:173)
`/low-speed transactions). The requirements on the TT for these two buffer and state tracking sections are
`different. Each will be described in turn later in this chapter.
`
`11.14.1.1 Data Handling Between High-speed and Full-flow-speed
`The host converts transfer requests involving a full-/low-speed device into conesponding high-speed split
`transactions to the TT to which the device is attached.
`
`Low-speed Preamble(PRE) packets are never used on the high-speed bus to indicate a low-speed
`transaction. Instead, a low-speed transaction is encoded in the split transaction token.
`
`The host can have a single schedule of the transactions that need to be issued to devices. This single
`schedule can be used to hold both high-speed transactions and high-speed split transactions used for
`communicating with full-/low-speed devices.
`
`11.14.1.2 Host Controller and TT Split Transactions
`The host controller uses the split transaction protocol for initiating full-/low-speed transactions via the TT
`and then determining the completion status of the full-/low-speed transaction. This approach allows the
`host controller to start a full-/low-speed transaction and then continue with other high-speed transactions
`while avoiding having to wait for the slower transaction to proceed/complete at its speed. A high-speed
`split transaction has two parts: a start-split and a complete-split. Split transactions are only used between
`the host controller and a hub. No other high-/full-/low-speed devices ever participate in split transactions.
`
`When the host controller sends a start-split transaction at high-speed, the split transaction is addressed to the
`TT for that device. That TT will accept the transaction and buffer it locally. The high-speed handler
`responds with an appropriate handshake to inform the host controller that the transaction has been accepted.
`Not all split transactions have a handshake phase to the start-split. The start-split transactions are kept
`temporarily in a TT transaction buffer.
`
`The full-/low-speed handler processes start-split periodic transactions stored in the periodic transaction
`buffer (in order) as the downstream full-/low-speed bus is ready for the "next" transaction. The full-/low(cid:173)
`speed handler accepts any result information from the downstream bus (in response to the full-/low-speed
`transaction) and accumulates it in a local buffer for later transmission to the host controller.
`
`At an appropriate future time, the host controller sends a high-speed complete-split transaction to retrieve
`the status/data/result for appropriate full-/low-speed transactions. The high-speed handler checks this high(cid:173)
`speed complete-split transaction with the response at the head of the appropriate local transaction buffer and
`responds accordingly. The specific split transaction sequences are defined for each USB transfer type in
`later sections.
`
`343
`
`PA_0001553
`
`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`While (1) loop
`While (not end of microframe) loop
`-- process next start-split transaction
`If available periodic start-split transaction then
`Process next full-/low-speed periodic transaction
`Else if (available bulk/control transaction) and
`(fits in full-/low-speed 1 ms frame) then
`Process one transaction
`End if
`End loop
`
`Advance~Pipeline();
`End loop
`
`-- see description in Figure 11-67(below)
`
`Figure 11-28. Example Full-flow-speed Handler Scheduling for Start-splits
`
`As described earlier in this chapter, the TT derives the downstream bus's 1 ms SOF timer from the high(cid:173)
`speed 125 µs microframe. This means that the host and the TT have the same 1 ms frame time for all TTs.
`Given the strict relationship between frames and the zeroth microframe, there is no need to have any
`explicit timing information carried in the periodic split transactions sent to the TT. See Section 11.18 for
`more information.
`
`11.15 Split Transaction Notation Information
`The following sections describe the details of the transaction phases and flow sequences of split transactions
`for the different USB transfer types: bulk/control, interrupt, and isochronous. Each description also shows
`detailed example host and TT state machines to achieve the required transaction definitions. The diagrams
`should not be taken as a required implementation, but to specify the required behavior. Appendix A
`includes example high-speed and full-speed transaction sequences with different results to clarify the
`relationships between the host controller, the TT, and a full-speed endpoint.
`
`Low-speed is not discussed in detail since beyond the handling of the PRE packet (which is defined in
`Chapter 8), there are no packet sequencing differences between low- and full-speed.
`
`For each data transfer direction, reference figures also show the possible flow sequences for the start-split
`and the complete-split portion of each split transaction transfer type.
`
`The transitions on the flow sequence figures have labels that correspond to the transitions in the host and TT
`state machines. These labels are also included in the examples in Appendix A. The three character labels
`are of the form: <SI C ><TI DI HIE ><number>. S indicates that this is a start-split label. C indicates
`that this is a complete-split label. T indicates token phase; D indicates data phase; H indicates handshake
`phase; E indicates an error case. The number simply distinguishes different labels of the same case/phase in
`the same split transaction part.
`
`The flow sequence figures fwiher identify the visibility of transitions according to the legend in
`Figure 11-29. The flow sequences also include some indication of states required in the host or TT or
`actions taken. The legend shown in Figure 11-29 indicates how these are identified.
`
`Bold indicates host action
`Italics indicate <hub status> or <hub action>
`Both visible
`Hub visible
`Host visible
`
`Figure 11-29. Flow Sequence Legend
`
`Figure 11-30 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 is a simple state.
`
`346
`
`PA_0001556
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`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 actions are performed if the
`transition is taken. The syntax for actions and conditions is VHDL. A circle includes a name in bold and
`optionally one or more actions that are performed upon entry to the state.
`
`- 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
`
`Condition
`-i~====A=c_t-io:n:s==~~~ - Transition: taken when condition
`is true and perf arms actions
`
`I
`
`Figure 11-30. Legend for State Machines
`
`The descriptions of the split transactions for the four transfer types refer to the status of the full-flow-speed
`transaction on the bus downstream of the TT. This status is used by the high-speed handler to determine its
`response to a complete-split transaction. The status is only visible within a TT implementation and is used
`in the specification purely for ease of explanation. The defined status values are:
`
`• Ready - The transaction has completed on the downstream facing full-flow-speed bus with the result
`as follows:
`
`• Ready/NAK -A NAK handshake was received.
`
`• Ready /trans_err -The full-flow-speed transaction experienced a error in the transaction.
`Possible errors are: PID to PID _invert bits check failure, CRC5 check failure, incorrect PID,
`timeout, CRC16 check failure, incorrect packet length, bitstuffing error, false EOP.
`
`• Ready /ACK-An ACK handshake was received.
`
`• Ready /Stall - A ST ALL handshake was received.
`
`• Ready /Data -A data packet was received and the CRC check passed. (bulk/control IN).
`
`347
`
`PA_0001557
`
`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.16 Common Split Transaction State Machines
`There are several state machines common to all the specific split transaction types. These state machines
`are used in the host controller and transaction translator to determine the specific split transaction type (e.g.,
`interrupt OUT start-split vs. bulk IN complete-split). An overview of the host controller state machine
`hierarchy is shown in Figure 11-32. The overview of the transaction translator state machine hierarchy is
`shown in Figure 11-33. Each of the labeled boxes in the figures show an individual state machine. Boxes
`contained in another box indicate a state machine contained within another state machine. All the state
`machines except the lowest level ones are shown in the remaining figures in this section. The lowest level
`state machines are shown in later sections describing the specific split transaction type.
`
`HC Do start
`
`RC_ Do_ complete
`
`HC Do IsochISS
`
`I HC_Do_IsochICS
`
`HC Do IntISS
`
`HC Do BISS
`
`HC Do IntICS
`I HC _Data_ or_ timeout I
`
`HC Do IsochOSS
`
`I HC_Do_BICS
`
`HC Do IntOSS
`
`I HC_Do_IntOCS
`
`HC Do BOSS
`
`I HC_Do_BOCS
`
`Figure 11-32. Host Controller Split Transaction State Machine Hierarchy Overview
`
`349
`
`PA_0001559
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.17 Bulk/Control Transaction Translation Overview
`Each TT must have at least two bulk/control transaction buffers. Each buffer holds the information for a
`start- or complete-split transaction and represents a single full-flow-speed transaction that is awaiting ( or has
`completed) transfer on the downstream bus. The buffer is used to hold the transaction information from the
`staii-split (and data for an OUT) and then the handshake/result of the full-flow-speed transaction (and data
`for an IN). This buffer is filled and emptied by split transactions from the high-speed bus via the high-speed
`handler. The buffer is also updated by the full-flow-speed handler while the transaction is in progress on the
`downstream bus.
`
`The high-speed handler must accept a start-split transaction from the host controller for a bulk/control
`endpoint whenever the high-speed handler has appropriate space in a bulk/control buffer.
`
`The host controller attempts a start-split transaction according to its bulk/control high-speed transaction
`schedule. As soon as the high-speed handler responds to a complete-split transaction with the results from
`the corresponding buffer, the next staii-split for some (possibly other) full-flow-speed endpoint can be saved
`in the buffer.
`
`There is no method to control the start-split transaction accepted next by the high-speed handler.
`Sequencing of start-split transactions is simply determined by available TT buffer space and the current
`state of the host controller schedule ( e.g., which start-split transaction is next that the host controller tries as
`a normal part of processing high-speed transactions).
`
`The host controller does not need to segregate split transaction bulk (or control) transactions from high(cid:173)
`speed bulk ( control) transactions when building its schedule. The host controller is required to track
`whether a transaction is a normal high-speed transaction or a high-speed split transaction.
`
`The following sections describe the details of the transaction phases, flow sequences, and state machines for
`split transactions used to support full-flow-speed bulk and control OUT and IN transactions. There are only
`minor differences between bulk and control split transactions. In the figures, some areas are shaded to
`indicate that they do not apply for control transactions.
`
`11.17.1 Bulk/Control Split Transaction Sequences
`The state machine figures show the transitions required for high-speed split transactions for full-flow-speed
`bulk/control transfer types for a single endpoint. These figures must not be interpreted as showing any
`particular specific timing. They define the required sequencing behavior of different packets of a
`bulk/control split transaction. In particular, other high-speed or split transactions for other endpoints occur
`before or after these split transaction sequences.
`
`Figure 11-4 7 shows a sample code algorithm that describes the behavior of the transitions labeled with
`Js_new _SS, Js_old_SS and Is_no _space shown in the figures for both bulk/control IN and OUT start-split
`transactions buffered in the TT for any endpoint. This algorithm ensures that the TT only buffers a single
`bulk/control split transaction for any endpoint. The complete-split protocol definition requires an endpoint
`has only a single result buffered in the TT at any time. Note that the "buffer match" test is different for bulk
`and control endpoints. A buffer match test for a bulk transaction must include the direction of the
`transaction in the test since bulk endpoints are unidirectional. A control transaction must not use direction
`as part of the match test.
`
`360
`
`PA_0001570
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`procedure Compare buffs IS
`variable match:boolean:=FALSE;
`
`begin
`
`Is new SS is true when BC buff.status== NEW SS
`Is old SS is true when BC buff.status== OLD SS
`Is=no_space is true when BC_buff.status == NO_SPACE
`
`-
`
`-
`
`-- Assume nospace and intialize index to 0.
`BC buff.status .- NO SPACE;
`BC buff.index
`.- O·
`
`IN Oto num buffs-1 LOOP
`FOR i
`IF NOT match THEN
`Re-use buffer with same Device Address/End point.
`IF (token.endpt = cam(i) .store.endpt AND
`token.dev addr = cam(i) .store.dev addr AND
`((token.direction= cam(i) .store.direction AND
`split.ep type/= CONTROL) OR
`split.ep type= CONTROL)) THEN
`
`If The buffer is already pending/ready this must be a retry.
`IF (cam(i) .match.state= READY OR cam(i) .match.state= PENDING) THEN
`BC_buff.status .- OLD SS;
`ELSE
`BC buff . status .- NEW_SS;
`END IF;
`BC buff.index:= i;
`match:= TRUE;
`
`-- Otherwise use the buffer if it's old.
`ELSIF (cam(i) .match.state= OLD) THEN
`BC buff.status := NEW SS;
`BC-buff.index
`i;
`-
`END IF;
`END IF;
`END LOOP;
`
`end Compare buffs;
`
`Figure 11-47. Sample Algorithm for Compare_buffs
`
`Figure 11-48 shows the sequence of packets for a start-split transaction for the full-/low-speed bulk OUT
`transfer type. The block labeled SSPLIT represents a split transaction token packet as described in
`Chapter 8. It is followed by an OUT token packet (or SETUP token packet for a control setup transaction).
`If the high-speed handler times out after the SSPLIT or OUT token packets, and does not receive the
`following OUT/SETUP or DATA0/1 packets, it will not respond with a handshake as indicated by the
`dotted line transitions labeled "se 1" or "se2". This causes the host to subsequently see a transaction error
`(timeout) (labeled "se2" and indicated with a dashed line). If the high-speed handler receives the DATA0/1
`packet and it fails the CRC check, it takes the transition "se2" which causes the host to timeout and follow
`the "se2" transition.
`
`361
`
`PA_0001571
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Start split
`
`stl
`
`SSPLIT
`st2
`OUT/SETUP
`
`Trans err
`
`Trans err
`..................................................... ........................................................
`
`sdl
`DATA0/1
`
`set
`
`······················································ ··· ·····T
`
`Comppre _ buffs
`..........................................
`
`Is old SS
`
`Is new: SS
`Accept: data
`sh!!
`y
`
`sh2!
`y
`
`]
`[
`ACK
`~1 ______,
`i
`
`i •
`
`Goto
`comp. split
`
`, i
`Tr.ans err
`I
`se2!
`I
`i
`Inc ,rr
`couqt
`
`Is no : space
`
`sh3!
`
`[N~K]
`i •
`
`i
`
`,--···-·-·-·-·1
`..
`se4i
`ses!
`...
`if err count >= 3
`if err_ count < 3
`Retry
`start split retry start split endpoint halt
`I Host I 0
`
`Figure 11-48. Bulk/Control OlJT Start-split Transaction Sequence
`
`The host must keep retrying the start-split for this endpoint until the err_ count reaches three for this
`endpoint before continuing on to some other start-split for this endpoint However, the host can issue other
`start-splits for other endpoints before it retries the start-split for this endpoint. The err_ count is used to
`count how many errors have been experienced during attempts to issue a particular transaction for a
`particular endpoint
`
`If there is no space in the transaction buffers to hold the start-split, the high-speed handler responds with a
`NAK via transition "sh3". This will cause the host to retry this start-split at some future time based on its
`normal schedule. The host does not increase its err_ count for a NAK handshake response. Once the host
`has received a NAK response to a start-split, it can skip other start-splits for this TT for bulk/control
`endpoints until it finishes a bulk/control complete-split
`
`If there is buffer space for the start-split, the high-speed handler takes transition "shl " and responds with an
`ACK. This tells the host it must try a complete-split the next time it attempts to process a transaction for
`this full-/low-speed endpoint After receiving an ACK handshake, the host must not issue a further start(cid:173)
`split for this endpoint until the corresponding complete-split