Universal Serial Bus Specification Revision 2.0
`
`be returned to the high-speed Idle state ( using the SendEOR state). After this, the port will return to the
`Enabled state. The high-speed status of the port is maintained throughout the suspend-resume cycle.
`
`Figure 11-17 and Figure 11-18 show the timing relationships for an example remote-wakeup sequence.
`This example illustrates a device initiating resume signaling through a suspended hub ('B') to an awake hub
`('A'). Hub 'A' in this example times and completes the resume sequence and is the "Controlling Hub".
`The timings and events are defined in Section 7 .1. 7. 7.
`
`Full/low speed Bus driving
`Full/low speed Bus driving -
`repeat
`Full/low speed Bus Idle or
`driven at other end
`High speed idle state
`
`(DS) /I Controlling Hub
`
`+
`R
`II. H b D ·
`C
`t
`on ro mg u
`rives esume
`____o,,,J',
`sends EOR ending
`~ 20ms (nominal)
`i--------------------i:
`resume
`Idle ('J') :_· ____ ::· ___ 'J, __ Resume(_('K')
`\
`.A~--~-----------~:.,_\ ____ i?le
`~ !.- Controlling. Hub Reflects Resume
`,
`!
`l
`l
`l
`l
`.
`.
`:
`:
`
`Everything
`below Hub 'A'
`in Suspend
`state
`
`-
`
`Hub
`Upstream
`Port
`
`,
`i
`i
`.
`:
`
`,
`
`(DS) 900µs
`
`_J Hub 'B' generates
`I EOP ending resume
`
`/
`
`,
`
`Enabled DS
`
`_Idle ('J')~---~,_R_e_s..,um~e-('K_'_)-;,---;i
`
`::: :
`
`:
`
`: : i \_ _j_~l-e ('~')-
`
`~ ""'''"'
`
`~
`
`:+- Hub 'B' Drives Res~me (US and DS)
`
`·
`
`[e.g., 1pms]
`
`1
`I
`I
`
`1
`I
`I
`
`Device
`Hub Port
`
`,._Hub 'B' Reflects Resume (US and DS)
`·
`900µs
`
`Device
`
`Device
`
`I~~~·~·~] Resume ('KD
`
`Device r.·':_ . .
`
`Remote
`Wakeup
`
`~
`to 1
`t1 :
`
`t2 :
`
`r---
`------------~
`/Idle ('J')
`:\
`'
`:---------------~J-. ..L·-·
`
`,._ Qevice Drives Resume
`[e.g., 10ms]
`·
`·
`t,:
`t, :
`
`Figure 11-17. Example Remote-wakeup Resume Signaling With Full-flow-speed Device
`
`333
`
`PA_0001543
`
`

`

`~ Controlling Hub
`suspended DS
`Port
`
`-
`
`Hub
`Upstream
`Port
`
`\l["""'o~
`
`Enabled DS
`
`1
`I
`I
`
`1
`I
`I
`
`Device
`Hub Port
`
`Device
`
`(DS) 900µs
`
`j
`
`!
`
`!
`
`i
`
`_Idle ('J') i __ J Resume ('K')
`
`~
`
`idle
`......... ................. :.: -----
`Hub 'B' Drives Resume (US and DS)
`[e.g., 1pms]
`
`Universal Serial Bus Specification Revision 2.0
`
`Everything
`below Hub 'A'
`in Suspend
`state
`
`Full/low speed Bus driving
`Full/low speed Bus driving -
`repeat
`Full/low speed Bus Idle or
`driven at other end
`High speed idle state
`
`. /i Controlling Hub
`
`Controlling Hub Drives Resume (DS)
`~ sends EOR ending
`20ms (nominal)
`---..:
`,_· - - - - - - - - - - - - - - - .=
`·
`·
`resume
`Idle ('J ') i.· ___ i. ___ ,J, Resumei_('K')
`\
`.Ji,----;---.;..--------.;.,!\ ___ __ idle
`l
`l
`1+- Controlling. Hub Reflects Resume
`i
`
`Device
`
`l~I~~·~·~] Resume ('Ki)
`
`De v i ce~•!_ . .
`Remote
`~
`to !
`Wakeup
`11 ,
`
`t,,
`
`:
`:
`:
`:
`~H~b 'B' Refiects Resume (US and DS)
`900µs
`
`-----------i
`''
`idle
`'.---------------~j _ ____ _
`._ Qevice Drives Resume
`·
`·
`[e.g., 10ms]
`t,l
`t,l
`
`Figure 11-18. Example Remote-wakeup Resume Signaling With High-speed Device
`
`Here is an explanation of what happens at each t,,:
`
`t0 Suspended device initiates remote-wakeup by driving a K' on the data lines.
`
`t, Suspended hub 'B' detects the 'K' on its downstream facing port and wakes up enough within 900 µs
`to filter and then reflect the resume upstream and down through all enabled ports.
`
`t2 Hub 'A' is not suspended (implication is that the port at which 'B' is attached is selectively
`suspended), detects the 'K' on the selectively suspended port where 'B' is attached, and filters and
`then reflects the resume signal back to 'B' within 900 µs.
`
`t1 Device ceases driving 'K' upstream.
`t, Hub 'B' ceases driving 'K' upstream and down all enabled ports and begins repeating upstream
`signaling to all enabled downstream facing ports.
`
`t5 Hub 'A' completes resume sequence, after appropriate timing interval, by driving a speed-appropriate
`end of resume downstream. (End of resume will be an Idle state for a high-speed device or a low(cid:173)
`speed EOP for a full-/low-speed device.)
`
`The hub reflection time is much smaller than the minimum duration a USB device will drive resume
`upstream. This relationship guarantees that resume will be propagated upstream and downstream without
`any gaps.
`
`11.10 Hub Reset Behavior
`Reset signaling to a hub is defined only in the downstream direction, which is at the hub's upstream facing
`port. Reset signaling required of the hub is described in Section 7 .1. 7 .5.
`
`A suspended hub must interpret the start of reset as a wakeup event; it must be awake and have completed
`its reset sequence by the end of reset signaling.
`
`334
`
`PA_0001544
`
`

`

`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
`
`11.12.2 Hub Information Architecture and Operation
`Figure 11-20 shows how status, status change, and control information relate to device states. Hub
`descriptors and Hub/Port Status and Control are accessible through the Default Control Pipe. The Hub
`descriptors may be read at any time. When a hub detects a change on a port or when the hub changes its
`own state, the Status Change endpoint transfers data to the host in the form specified in Section 11.12.4.
`
`Hub or port status change bits can be set because of hardware or Software events. When set, these bits
`remain set until cleared directly by the USB System Software through a ClearPortFeature() request or by a
`hub reset. While a change bit is set, the hub continues to report a status change when polled until all change
`bits have been cleared by the USB System Software.
`
`Status Information
`(static)
`
`Change Information
`(due to hardware
`events)
`
`Hardware Events -
`
`Device Control
`
`Control Information
`( change device state)
`
`Software Device
`Control
`
`Figure 11-20. Relationship of Status, Status Change, and Control Information to Device States
`
`The USB System Software uses the interrupt pipe associated with the Status Change endpoint to detect
`changes in hub and port status.
`
`11.12.3 Port Change Information Processing
`
`Hubs report a port's status through port commands on a per-port basis. The USB System Software
`acknowledges a port change by clearing the change state corresponding to the status change reported by the
`hub. The acknowledgment clears the change state for that port so future data transfers to the Status Change
`endpoint do not report the previous event. This allows the process to repeat for further changes (see
`Figure 11-21).
`
`337
`
`PA_0001547
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Begin
`
`System Software requests Interrupt Pipe notification for Status Change Information
`
`Hub NAKs
`status change
`IN token
`
`Interrupt Pipe returns Hub and Port Status Change Bitmap
`
`Interrupt Pipe notification retired
`
`System Software reads Hub or Port status (for affected ports)
`
`Yes
`
`• Accumulate change information
`• System Software clears
`corresponding change state
`
`System Software processes accumulated change information
`
`Re-initialize Interrupt Pipe for Status Change endpoint
`
`Return to
`beginning
`
`Figure 11-21. Port Status Handling Method
`
`11.12.4 Hub and Port Status Change Bitmap
`The Hub and Port Status Change Bitmap, shown in Figure 11-22, indicates whether the hub or a port has
`experienced a status change. This bitmap also indicates which port(s) has had a change in status. The hub
`returns this value on the Status Change endpoint. Hubs report this value in byte-increments. That is, if a
`hub has six ports, it returns a byte quantity, and reports a zero in the invalid port number field locations.
`The USB System Software is aware of the number of ports on a hub (this is reported in the hub descriptor)
`and decodes the Hub and Port Status Change Bitmap accordingly. The hub reports any changes in hub
`status in bit zero of the Hub and Port Status Change Bitmap.
`
`The Hub and Port Status Change Bitmap size varies from a minimum size of one byte. Hubs report only as
`many bits as there are ports on the hub, subject to the byte-granularity requirement (i.e., round up to the
`nearest byte).
`
`338
`
`PA_0001548
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`II
`
`I 1-------------------- I :-------------------1 2
`
`1
`
`I
`
`0
`
`I
`
`I
`
`N
`
`I
`
`Port N change detected g_
`
`~
`
`:::
`
`~
`
`I
`
`'
`
`:::
`
`~
`
`:::
`
`:::
`
`~
`
`Port 2 change detected
`Port 1 change detected
`Hub change detected
`
`~
`
`~
`
`~
`
`Figure 11-22. Hub and Port Status Change Bitmap
`
`Any time the Status Change endpoint is polled by the host controller and any of the Status Changed bits are
`non-zero, the Hub and Port Status Change Bitmap is returned. Figure 11-23 shows an example creation
`mechanism for hub and port change bits.
`
`Hub and Port Status Change Bitmap
`
`I
`
`_____ J
`
`I I
`N
`
`Figure 11-23. Example Hub and Port Change Bit Sampling
`
`11.12.5 Over-current Reporting and Recovery
`USB devices must be designed to meet applicable safety standards. Usually, this will mean that a self(cid:173)
`powered hub implement current limiting on its downstream facing ports. If an over-current condition
`occurs, it causes a status and state change in one or more ports. This change is reported to the USB System
`Software so that it can take corrective action.
`
`A hub may be designed to report over-current as either a port or a hub event. The hub descriptor field
`wHubCharacteristics is used to indicate the reporting capabilities of a particular hub (see Section 11.23.2).
`The over-current status bit in the hub or port status field indicates the state of the over-current detection
`when the status is returned. The over-current status change bit in the Hub or Port Change field indicates if
`the over-current status has changed.
`
`When a hub experiences an over-current condition, it must place all affected ports in the Powered-off state.
`If a hub has per-port power switching and per-port current limiting, an over-current on one po1i may still
`
`339
`
`PA_0001549
`
`

`

`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
`
`11.14.1.3 Multiple Transaction Translators
`A hub has two choices for organizing transaction translators (TTs). A hub can have one TT for all
`downstream facing ports that have full-/low-speed devices attached or the hub can have one TT for each
`downstream facing port. The hub must report its organization in the hub class descriptor.
`
`11.14.2 Transaction Translator Scheduling
`As the high-speed handler accepts start-splits, the full-/low-speed transaction information and data for
`OUTs or the transaction information for IN s accumulate in buffers awaiting their service on the downstream
`bus. The host manages the periodic TT transaction buffers differently than the non-periodic transaction
`buffers.
`
`11.14.2.1 TT Isochronous/Interrupt (Periodic) Transaction Buffering
`Periodic transactions have strict timing requirements to meet on a full-/low-speed bus (as defined by the
`specific endpoint and transfer type). Therefore, transactions must move across the high-speed bus, through
`the TT, across the full-/low-speed bus, back through the TT, and onto the high-speed bus in a timely
`fashion. An overview of the microframe pipeline of buffering in the TT is shown in Figure 11-26. A
`transaction begins as a start-split on the high-speed bus, is accepted by the high-speed handler, and is stored
`in the stmi-split transaction buffer. The full-/low-speed handler uses the next start-split transaction at the
`head of the stmi-split transaction buffer when it is time to issue the next periodic full-/low-speed transaction
`on the downstream bus. The results of the transaction are accumulated in the complete-split transaction
`buffer. The TT responds to a complete-split from the host and extracts the appropriate response from the
`complete-split transaction buffer. This completes the flow for a periodic transaction through the TT. This
`is called the periodic transaction pipeline.
`
`High Speed Start-Split
`
`High Speed Complete-Split
`
`TT
`
`Start-split
`FIFO
`
`Complete-split
`FIFO
`
`Figure 11-26. TT Microframe Pipeline for Periodic Split Transactions
`
`The TT implements a traditional pipeline of transactions with its periodic transaction buffers. There is
`separate buffer space for start-splits and complete-splits. The host is responsible for filling the start-split
`transaction buffer and draining the complete-split transaction buffer. The host software manages the host
`controller to cause high-speed split transactions at the correct times to avoid over/under runs in the TT
`periodic transaction buffers. The host controller sends data "just in time" for full-/low-speed OUTs and
`retrieves response data from full-/low-speed INs to ensure that the periodic transaction buffer space required
`in the TT is the minimum possible. See Section 11.18 for more detailed information.
`
`USB strictly defines the timing requirements of periodic transactions and the isochronous transport
`capabilities of the high-speed and full-/low-speed buses. This allows the host to accurately predict when
`
`344
`
`PA_0001554
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`data for periodic transactions must be moved on both the full-/low-speed and high-speed buses, whenever a
`client requests a data transfer with a full-flow-speed periodic endpoint. Therefore, the host can "pipeline"
`data to/from the TT so that it moves in a timely manner with its target endpoint. Once the configuration of
`a full-/low-speed device with periodic endpoints is set, the host streams data to/from the TT to keep the
`device's endpoints operating normally.
`
`11.14.2.2 TT Bulk/Control (Non-Periodic) Transaction Buffering
`Non-periodic transactions have no timing requirements, but the TT supports the maximum full-/low-speed
`throughput allowed. A TT provides a few transaction buffers for bulk/control full-/low-speed transactions.
`The host and TT use simple flow control (NAK) mechanisms to manage the bulk/control non-periodic
`transaction buffers. The host issues a start-split transaction, and ifthere is available buffer space, the TT
`accepts the transaction. The full-/low-speed handler uses the buffered information to issue the downstream
`full-/low-speed transaction and then uses the same buffer to hold any results (e.g. , handshake or data or
`timeout). The buffer is then emptied with a corresponding high-speed complete-split and the process
`continues. Figure 11-27 shows an example overview of a TT that has two bulk/control buffers.
`
`High Speed Start-/Complete-Split
`
`TT
`
`Full/Low Speed Transaction
`
`Figure 11-27. TT Nonperiodic Buffering
`
`11.14.2.3 Full-flow-speed Handler Transaction Scheduling
`The full-flow-speed handler uses a simple, scheduled priority scheme to service pending transactions on the
`downstream bus. Whenever the full-/low-speed handler finishes a transaction on the downstream bus, it
`takes the next start-sp