Universal Serial Bus Specification Revision 2.0
`
`Table 9-12. Standard Interface Descriptor
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0
`
`1
`
`2
`
`3
`
`4
`
`bLength
`
`bDescriptorType
`
`blnterfaceNumber
`
`bA/ternateSetting
`
`bNumEndpoints
`
`1
`
`1
`
`1
`
`1
`
`1
`
`Number
`
`Size of this descriptor in bytes
`
`Constant
`
`INTERFACE Descriptor Type
`
`Number
`
`Number of this interface. Zero-based
`value identifying the index in the array of
`concurrent interfaces supported by this
`configuration.
`
`Number
`
`Value used to select this alternate setting
`for the interface identified in the prior field
`
`Number
`
`Number of endpoints used by this
`interface (excluding endpoint zero). If this
`value is zero, this interface only uses the
`Default Control Pipe.
`
`5
`
`blnterfaceC/ass
`
`1
`
`Class
`
`Class code (assigned by the USB-IF).
`
`6
`
`blnterfaceSubC/ass
`
`1
`
`SubClass
`
`A value of zero is reserved for future
`standardization.
`
`If this field is set to FFH, the interface
`class is vendor-specific.
`
`All other values are reserved for
`assignment by the USB-IF.
`
`Subclass code (assigned by the USB-IF).
`These codes are qualified by the value of
`the blnterfaceC/ass field.
`
`If the blnterfaceC/ass field is reset to zero,
`this field must also be reset to zero.
`
`If the blnterfaceC/ass field is not set to
`FFH, all values are reserved for
`assignment by the USB-IF.
`
`268
`
`PA_0001478
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 9-12. Standard Interface Descriptor (Continued)
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`7
`
`blnterfaceProtoco/
`
`1
`
`Protocol
`
`8
`
`ilnterface
`
`1
`
`Index
`
`Protocol code (assigned by the USB).
`These codes are qualified by the value of
`the blnterfaceC/ass and the
`blnterfaceSubC/ass fields. If an interface
`supports class-specific requests, this code
`identifies the protocols that the device
`uses as defined by the specification of the
`device class.
`
`If this field is reset to zero, the device
`does not use a class-specific protocol on
`this interface.
`
`If this field is set to FFH, the device uses
`a vendor-specific protocol for this
`interface.
`
`Index of string descriptor describing this
`interface
`
`9.6.6 Endpoint
`Each endpoint used for an interface has its own descriptor. This descriptor contains the information
`required by the host to determine the bandwidth requirements of each endpoint. An endpoint descriptor is
`always returned as part of the configuration information returned by a GetDescriptor(Configuration)
`request. An endpoint descriptor cannot be directly accessed with a GetDescriptor() or SetDescriptor()
`request. There is never an endpoint descriptor for endpoint zero. Table 9-13 shows the standard endpoint
`descriptor.
`
`Table 9-13. Standard Endpoint Descriptor
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0
`
`1
`
`2
`
`bLenath
`
`bDescriptorTvoe
`
`bEndpointAddress
`
`1
`
`1
`
`1
`
`Number
`
`Size of this descriptor in bvtes
`
`Constant ENDPOINT Descriptor Tvpe
`
`Endpoint
`
`The address of the endpoint on the USB device
`described by this descriptor. The address is
`encoded as follows:
`
`Bit 3 ... 0: The endpoint number
`Bit 6 .. .4: Reserved, reset to zero
`Direction, ignored for
`Bit 7:
`control endpoints
`0 = OUT endpoint
`1 = IN endpoint
`
`269
`
`PA_0001479
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 9-13. Standard Endpoint Descriptor (Continued)
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`3
`
`bmAttributes
`
`1
`
`Bitmap
`
`This field describes the endpoint's attributes when it is
`configured using the bConfigurationVa/ue.
`
`Bits 1 .. 0: Transfer Type
`00 = Control
`01 = Isochronous
`10 = Bulk
`11 = Interrupt
`
`If not an isochronous endpoint, bits 5 .. 2 are reserved
`and must be set to zero. If isochronous, they are
`defined as follows:
`
`Bits 3 .. 2: Synchronization Type
`
`00 = No Synchronization
`01 = Asynchronous
`10 = Adaptive
`11 = Synchronous
`
`Bits 5 . .4: Usage Type
`
`00 = Data endpoint
`01 = Feedback endpoint
`10 = Implicit feedback Data endpoint
`11 = Reserved
`
`Refer to Chapter 5 for more information.
`
`All other bits are reserved and must be reset to zero.
`Reserved bits must be iqnored by the host.
`
`270
`
`PA_0001480
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 9-13. Standard Endpoint Descriptor (Continued)
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`4
`
`wMaxPacketSize
`
`2
`
`Number Maximum packet size this endpoint is capable of
`sending or receiving when this configuration is
`selected.
`
`For isochronous endpoints, this value is used to
`reserve the bus time in the schedule, required for the
`per-(micro)frame data payloads. The pipe may, on an
`ongoing basis, actually use less bandwidth than that
`reserved. The device reports, if necessary, the actual
`bandwidth used via its normal, non-USB defined
`mechanisms.
`
`For all endpoints, bits 10 .. 0 specify the maximum
`packet size (in bytes).
`
`For high-speed isochronous and interrupt endpoints:
`
`Bits 12 .. 11 specify the number of additional transaction
`opportunities per microframe:
`
`00 = None (1 transaction per microframe)
`01 = 1 additional (2 per microframe)
`10 = 2 additional (3 per microframe)
`11 = Reserved
`
`Bits 15 .. 13 are reserved and must be set to zero.
`
`Refer to Chapter 5 for more information.
`
`Interval for polling endpoint for data transfers.
`Expressed in frames or microframes depending on the
`device operating speed (i.e., either 1 millisecond or
`125 µs units).
`
`6
`
`blnterval
`
`1
`
`Number
`
`1·
`
`For full-/high-speed isochronous endpoints, this value
`must be in the range from 1 to 16. The blnterval value
`is used as the exponent for a 2bl"0
`1 value; e.g., a
`"'"
`blnterval of 4 means a period of 8 (24
`1
`
`.
`
`).
`
`For full-flow-speed interrupt endpoints, the value of
`this field may be from 1 to 255.
`
`For high-speed interrupt endpoints, the blnterval value
`is used as the exponent for a 2blcte,val·1 value; e.g., a
`1
`blnterval of 4 means a period of 8 (24
`). This value
`must be from 1 to 16.
`
`.
`
`For high-speed bulk/control OUT endpoints, the
`blnterval must specify the maximum NAK rate of the
`endpoint. A value of O indicates the endpoint never
`NAKs. Other values indicate at most 1 NAK each
`blnterval number of microframes. This value must be
`in the range from O to 255.
`
`See Chapter 5 description of periods for more detail.
`
`The bmAttributes field provides information about the endpoint's Transfer Type (bits 1..0) and
`Synchronization Type (bits 3 .. 2). In addition, the Usage Type bit (bits 5 . .4) indicate whether this is an
`endpoint used for normal data transfers (bits 5 . .4=00B), whether it is used to convey explicit feedback
`information for one or more data endpoints (bits 5 . .4=0IB) or whether it is a data endpoint that also serves
`
`271
`
`PA_0001481
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`as an implicit feedback endpoint for one or more data endpoints (bits 5 . .4=10B). Bits 5 .. 2 are only
`meaningful for isochronous endpoints and must be reset to zero for all other transfer types.
`
`If the endpoint is used as an explicit feedback endpoint (bits 5 . .4=0IB), then the Transfer Type must be set
`lo isochronous (bilsl..O = OIB) and the Synchronization Type must be sel lo No Synchronization
`(bits 3 .. 2=00B).
`
`A feedback endpoint (explicit or implicit) needs to be associated with one (or more) isochronous data
`endpoints to which it provides feedback service. The association is based on endpoint number matching. A
`feedback endpoint always has the opposite direction from the data endpoint(s) it services. If multiple data
`endpoints are to be serviced by the same feedback endpoint, the data endpoints must have ascending
`ordered-but not necessarily consecutive-endpoint numbers. The first data endpoint and the feedback
`endpoint must have the same endpoint number (and opposite direction). This ensures that a data endpoint
`can uniquely identify its feedback endpoint by searching for the first feedback endpoint that has an endpoint
`number equal or less than its own endpoint number.
`
`Example: Consider the extreme case where there is a need for five groups of OUT asynchronous
`isochronous endpoints and at the same time four groups of IN adaptive isochronous endpoints. Each group
`needs a separate feedback endpoint and the groups are composed as shown in Figure 9-7.
`
`OUT
`Group
`
`Nr of OUT
`Endpoints
`
`IN
`Group
`
`Nr of IN
`Endpoints
`
`1
`
`2
`
`3
`
`4
`
`5
`
`1
`
`2
`
`2
`
`3
`
`3
`
`6
`
`7
`
`8
`
`9
`
`1
`
`2
`
`3
`
`4
`
`Figure 9-7. Example of Feedback Endpoint Numbers
`
`The endpoint numbers can be intertwined as illustrated in Figure 9-8 .
`
`2
`
`3
`
`4
`
`5
`
`OUT
`
`2
`
`D Data Endpoint 0 Feedback Endpoint
`
`3
`
`4
`
`IN
`
`Figure 9-8. Example of Feedback Endpoint Relationships
`
`272
`
`PA_0001482
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`High-speed isochronous and interrupt endpoints use bits 12 .. 11 ofwMaxPacketSize to specify multiple
`transactions for each microframe specified by blnterval. If bits 12 .. 11 ofwMaxPacketSize are zero, the
`maximum packet size for the endpoint can be any allowed value (as defined in Chapter 5). If bits 12 .. l l of
`wMaxPacketSize are not zero (0), the allowed values for wMaxPacketSize bits 10 .. 0 are limited as shown in
`Table 9-14.
`
`Table 9-14. Allowed wMaxPacketSize Values for Different ~umbers of Transactions per Microframe
`
`wMaxPacketSize
`bits 12 .. 11
`
`00
`
`01
`
`10
`
`11
`
`wM axPacketSize
`bits 10 .. 0 Values
`Allowed
`
`1 -1024
`
`513 -1024
`
`683 - 1024
`
`NIA; reserved
`
`For high-speed bulk and control OUT endpoints, the blnterval field is only used for compliance purposes;
`the host controller is not required to change its behavior based on the value in this field.
`
`9.6.7 String
`String descriptors are optional. As noted previously, if a device does not support string descriptors, all
`references to string descriptors within device, configuration, and interface descriptors must be reset to zero.
`
`String descriptors use UNICODE encodings as defined by The Unicode Standard, Worldwide Character
`Encoding, Version 3.0, The Unicode Consortium, Addison-Wesley Publishing Company, Reading,
`Massachusetts (URL: http://www.unicode.com). The strings in a USB device may support multiple
`languages. When requesting a string descriptor, the requester specifies the desired language using a sixteen(cid:173)
`bit language ID (LANGID) defined by the USB-IF. The list of currently defined USB LANGIDs can be
`found at http://www.usb.org/developers/docs.htrnl. String index zero for all languages returns a string
`descriptor that contains an array of two-byte LANGID codes supported by the device. Table 9-15 shows the
`LANGID code array. A USB device may omit all string descriptors. USB devices that omit all string
`descriptors must not return an array ofLANGID codes.
`
`The array of LANG ID codes is not NULL-terminated. The size of the array (in bytes) is computed by
`subtracting two from the value of the first byte of the descriptor.
`
`Table 9-15. String Descriptor Zero, Specifying Languages Supported by the Device
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0
`
`1
`
`2
`
`...
`
`N
`
`bLength
`
`bDescriptorType
`
`wLANG/0[0]
`
`...
`
`wLANGID[x]
`
`1
`
`1
`
`2
`
`...
`
`2
`
`N+2
`
`Size of this descriptor in bytes
`
`Constant
`
`STRING Descriptor Type
`
`Number
`
`LANGID code zero
`
`...
`
`...
`
`Number
`
`LANGID codex
`
`273
`
`PA_0001483
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`The UNICODE string descriptor (shown in Table 9-16) is not NULL-terminated. The string length is
`computed by subtracting two from the value of the first byte of the descriptor.
`
`Table 9-16. UNICODE String Descriptor
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0
`
`1
`
`2
`
`bLength
`
`bDescriptorType
`
`bString
`
`1
`
`1
`
`N
`
`Number
`
`Size of this descriptor in bytes
`
`Constant
`
`STRING Descriptor Type
`
`Number
`
`UNICODE encoded string
`
`9.7 Device Class Definitions
`All devices must support the requests and descriptor definitions described in this chapter. Most devices
`provide additional requests and, possibly, descriptors for device-specific extensions. In addition, devices
`may provide extended services that are common to a group of devices. In order to define a class of devices,
`the following information must be provided to completely define the appearance and behavior of the device
`class.
`
`9.7.1 Descriptors
`If the class requires any specific definition of the standard descriptors, the class definition must include
`those requirements as part of the class definition. In addition, if the class defines a standard extended set of
`descriptors, they must also be fully defined in the class definition. Any extended descriptor definitions must
`follow the approach used for standard descriptors; for example, all descriptors must begin with a length
`field.
`
`lnterface(s) and Endpoint Usage
`9.7.2
`When a class of devices is standardized, the interfaces used by the devices, including how endpoints are
`used, must be included in the device class definition. Devices may further extend a class definition with
`proprietary features as long as they meet the base definition of the class.
`
`9.7.3 Requests
`All of the requests specific to the class must be defined.
`
`274
`
`PA_0001484
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Chapter 10
`USB Host: Hardware and Software
`
`The USB interconnect suppmis data traffic between a host and a USB device. This chapter describes the
`host interfaces necessary to facilitate USB communication between a software client, resident on the host,
`and a function implemented on a device. The implementation described in this chapter is not required.
`This implementation is provided as an example to illustrate the host system behavior expected by a USB
`device. A host system may provide a different host software implementation as long as a USB device
`experiences the same host behavior.
`
`10.1 Overview of the USB Host
`
`10.1.1 Overview
`The basic flow and interrelationships of the USB communications model are shown in Figure 10-1.
`
`Host
`
`Interconnect
`
`Device
`
`Client
`
`Function
`
`USB Device
`
`USB Bus
`Interface
`
`USB Bus
`Interface
`
`•
`
`•
`
`Actual communications flow
`
`Logical communications flow
`
`Figure 10-1. Interlayer Communications Model
`
`The host and the device are divided into the distinct layers depicted in Figure 10-1. Vertical arrows
`indicate the actual communication on the host. The corresponding interfaces on the device are
`implementation-specific. All communications between the host and device ultimately occur on the
`physical USB wire . However, there are logical host-device interfaces between each horizontal layer.
`These communications, between client software resident on the host and the function provided by the
`device, are typified by a contract based on the needs of the application cmTently using the device and the
`capabilities provided by the device.
`
`This client-function interaction creates the requirements for all of the underlying layers and their interfaces.
`
`275
`
`PA_0001485
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`This chapter describes this model from the point of view of the host and its layers. Figure 10-2 illustrates,
`based on the overall view introduced in Chapter 5, the host's view of its communication with the device.
`
`Host
`
`•
`
`Client
`
`manages interfaces
`
`,
`
`Interconnect
`
`• .,.,
`
`I
`
`..
`j
`
`I
`
`I
`
`I
`
`•
`•
`
`..
`Pipe Bundle..,
`
`I
`
`'
`
`to an interface
`
`IRPs
`
`Configuration
`
`"'
`USB Driver
`
`Host
`Software
`
`' ..
`
`HC Driver
`
`USB System
`manages pipes
`
`HW-Defined
`
`I
`
`I
`
`Default Pipe
`
`to Endpoint Zero
`
`V
`
`Host
`Controller
`
`USB Bus
`Interface
`
`.. •
`a
`
`HC-
`Defined
`
`USB Wire
`
`Pipe: Represents connection
`abstraction between two horizontal
`layers
`
`Optional
`Component
`
`•
`
`Interprocess Communication
`
`Figure 10-2. Host Communications
`
`276
`
`PA_0001486
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`There is only one host for each USB. The major layers of a host consist of the following:
`
`• USB bus interface
`
`• USB System
`
`• Client
`
`The USB bus interface handles interactions for the electrical and protocol layers (refer to Chapter 7 and
`Chapter 8). From the interconnect point of view, a similar USB bus interface is provided by both the USB
`device and the host, as exemplified by the Serial Interface Engine (SIE). On the host, however, the USB
`bus interface has additional responsibilities due to the unique role of the host on the USB and is
`implemented as the Host Controller. The Host Controller has an integrated root hub providing attachment
`points to the USB wire.
`
`The USB System uses the Host Controller to manage data transfers between the host and USB devices.
`The interface between the USB System and the Host Controller is dependent on the hardware definition of
`the Host Controller. The USB System, in concert with the Host Controller, performs the translation
`between the client's view of data transfers and the USB transactions appearing on the interconnect. This
`includes the addition of any USB feature support such as protocol wrappers. The USB System is also
`responsible for managing USB resources, such as bandwidth and bus power, so that client access to the
`USB is possible.
`
`The USB System has three basic components:
`
`• Host Controller Driver
`
`• USB Driver
`
`• Host Software
`
`The Host Controller Driver (HCD) exists to more easily map the various Host Controller implementations
`into the USB System, such that a client can interact with its device without knowing to which Host
`Controller the device is connected. The USH Driver (USHD) provides the basic host interface (USHDl) for
`clients to USB devices. The interface between the HCD and the USBD is known as the Host Controller
`Driver Interface (HCDI). This interface is never available directly to clients and thus is not defined by the
`USB Specification. A particular HCDT is, however, defined by each operating system that supports various
`Host Controller implementations.
`
`The USBD provides data transfer mechanisms in the form ofl/0 Request Packets (IRPs), which consist of
`a request to transport data across a specific pipe. In addition to providing data transfer mechanisms, the
`USBD is responsible for presenting to its clients an abstraction of a USB device that can be manipulated for
`configuration and state management. As part of this abstraction, the USBD owns the default pipe (see
`Chapter 5 and Chapter 9) through which all USB devices are accessed for the purposes of standard USB
`control. This default pipe represents a logical communication between the USBD and the abstraction of a
`USB device as shown in Figure 10-2.
`
`In some operating systems, additional non-USB System Software is available that provides configuration
`and loading mechanisms to device drivers. In such operating systems, the device driver shall use the
`provided interfaces instead of directly accessing the USBDI mechanisms.
`
`The client layer describes all the software entities that are responsible for directly interacting with USB
`devices. When each device is altached to the system, these clients might interact directly with the
`peripheral hardware. The shared characteristics of the USB place USB System Software between the client
`and its device; that is, a client cannot directly access the device's hardware.
`
`277
`
`PA_0001487
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Overall, the host layers provide the following capabilities:
`
`• Detecting the attachment and removal of USB devices
`
`• Managing USB standard control flow between the host and USB devices
`
`• Managing data flow between the host and USB devices
`
`• Collecting status and activity statistics
`
`• Controlling the electrical interface between the Host Controller and USB devices, including the
`provision of a limited amount of power
`
`The following sections describe these responsibilities and the requirements placed on the USBDI in greater
`detail. The actual interfaces used for a specific combination of host platform and operating system are
`described in the appropriate operating system environment guide.
`
`All hubs (see Chapter 11) report internal status changes and their port change status via the status change
`pipe. This includes a notification of when a USB device is attached to or removed from one of their ports.
`A USBD client generically known as the hub driver receives these notifications as owner of the hub's
`Status Change pipe. For device attachments, the hub driver then initiates the device configuration process.
`In some systems, this hub driver is a part of the host software provided by the operating system for
`managing devices.
`
`10.1.2 Control Mechanisms
`Control information may be passed between the host and a USB device using in-band or out-of-band
`signaling. In-band signaling mixes control information with data in a pipe outside the awareness of the
`host. Out-of-band signaling places control information in a separate pipe.
`
`There is a message pipe called the default pipe for each attached USB device. This logical association
`between a host and a USB device is used for USB standard control flow such as device enumeration and
`configuration. The default pipe provides a standard interface to all USB devices. The default pipe may
`also be used for device-specific communications, as mediated by the USBD, which owns the default pipes
`of all of the USB devices.
`
`A particular USB device may allow the use of additional message pipes to transfer device-specific control
`information. These pipes use the same communications protocol as the default pipe, but the information
`transferred is specific to the USB device and is not standardized by the USB Specification.
`
`The USBD supports the sharing of the default pipe, which it owns and uses, with its clients. It also
`provides access to any other control pipes associated with the device.
`
`10.1.3 Data Flow
`The Host Controller is responsible for transferring streams of data between the host and USB devices.
`These data transfers are treated as a continuous stream of bytes. The USB supports four basic types of data
`transfers:
`
`• Control transfers
`
`•
`
`•
`
`Isochronous transfers
`
`Interrupt transfers
`
`• Bulk transfers
`
`For additional information on transfer types, refer to Chapter 5.
`
`Each device presents one or more interfaces that a client may use to communicate with the device. Each
`interface is composed of zero or more pipes that individually transfer data between the client and a
`particular endpoint on the device. The USBD establishes interfaces and pipes at the explicit request of the
`Host Software. The Host Controller provides service based on parameters provided by the Host Software
`when the configuration request is made.
`
`278
`
`PA_0001488
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`A pipe has several characteristics based on the delivery requirements of the data to be transferred.
`Examples of these characteristics include the following:
`
`•
`
`The rate at which data needs to be transferred
`
`• Whether data is provided at a steady rate or sporadically
`
`• How long data may be delayed before delivery
`
`• Whether the loss of data being transferred is catastrophic
`
`A USB device endpoint describes the characteristics required for a specific pipe. Endpoints are described
`as part of a USB device's characterization information. For additional details, refer to Chapter 9.
`
`10.1.4 Collecting Status and Activity Statistics
`As a common communicant for all control and data transfers between the host and USB devices, the USB
`System and the Host Controller are well-positioned to track status and activity information. Such
`information is provided upon request to the Host Software, allowing that software to manage status and
`activity information. This specification does not identify any specific information that should be tracked or
`require any particular format for reporting activity and status information.
`
`10.1.5 Electrical Interface Considerations
`The host provides power to USB devices attached to the root hub. The amount of power provided by a port
`is specified in Chapter 7.
`
`10.2 Host Controller Requirements
`In all implementations, Host Controllers perform the same basic duties with regard to the USB and its
`attached devices. These basic duties are described below.
`
`The Host Controller has requirements from both the host and the USB. The following is a brief overview
`of the functionality provided. Each capability is discussed in detail in subsequent sections.
`
`State Handling
`
`As a component of the host, the Host Controller reports and manages
`its states.
`
`Serializer/Deserializer
`
`For data transmitted from the host, the Host Controller converts
`protocol and data information from its native format to a bit stream
`transmitted on the USB. For data being received into the host, the
`reverse operation is performed.
`
`(micro)frame Generation
`
`The Host Controller produces SOF tokens at a period of 1 ms when
`operating with full-speed devices, and at a period of 125 ~ts when
`operating with high-speed devices.
`
`Data Processing
`
`The Host Controller processes requests for data transmission to and
`from the host.
`
`Protocol Engine
`
`The Host Controller supports the protocol specified by the USB.
`
`Transmission Error
`Handling
`
`Remote Wakeup
`
`All Host Controllers exhibit the same behavior when detecting and
`reacting to the defined error categories.
`
`All Host Controllers must have the ability to place the bus into the
`Suspended state and to respond to bus wakeup events.
`
`279
`
`PA_0001489
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Root Hub
`
`The root hub provides standard hub function to link the Host
`Controller to one or more USB ports.
`
`Host System Interface
`
`Provides a high-speed data path between the Host Controller and host
`system.
`
`The following sections present a more detailed discussion of the required capabilities of the Host
`Controller.
`
`10.2.1 State Handling
`The Host Controller has a series of states that the USB System manages. Additionally, the Host Controller
`provides the interface to the following two areas ofUSB-relevant state:
`
`•
`
`State change propagation
`
`• Root hub
`
`The root hub presents to the hub driver the same standard states as other USB devices. The Host Controller
`supports these states and their transitions for the hub. For detailed discussions ofUSB states, including
`their interrelations and transitions, refer to Chapter 9.
`
`The overall state of the Host Controller is inextricably linked with that of the root hub and of the overall
`USB. Any Host Controller state changes that are visible to attached devices must be reflected in the
`corresponding device state change information such that the resulting Host Controller and device states are
`consistent.
`
`USB devices request a wakeup through the use of resume signaling (refer to Chapter 7). The Host
`Controller must notify the rest of the host of a resume event through a mechanism or mechanisms specific
`to that system's implementation. The Host Controller itself may cause a resume event through the same
`signaling method.
`
`10.2.2 Serializer/Deserializer
`The actual transmission of data across the physical USB takes places as a serial bit stream. A Serial
`Interface Engine (SIE), whether implemented as part of the host or a USB device, handles the serialization
`and deserialization ofUSB transmissions. On the host, this SIE is part of the Host Controller.
`
`10.2.3 Frame and Microframe Generation
`It is the Host Controller's responsibility to partition USB time into quantities called "frames" when
`operating with full-speed devices, and "microframes" when operating with high-speed devices. Frames and
`microframes are created by the Host Controller through issuing Start-of-Frame (SOF) tokens as shown in
`Figure 10-3. The SOF token is the first transmission in the (micro)frame period. Host controllers operating
`with high-speed devices generate SOF tokens at 125 µs intervals. Host controllers operating with full(cid:173)
`speed devices generate SOF tokens at 1.00 ms intervals. After issuing an SOF token, the Host Controller is
`free to transmit other transactions for the remainder of the (micro )frame period. When the Host Controller
`is in its normal operating state, SOF tokens must be continuously generated at appropriate periodic rate,
`regardless of other bus activity or lack thereof. If the Host Controller enters a state where it is not
`providing power on the bus, it must not generate SOFs. When the Host Controller is not generating SOFs,
`it may enter a power-reduced state.
`
`280
`
`PA_0001490
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`(micro)frame N-1
`
`(micro)frame N
`
`micro frame N+1
`
`V
`EOF Interval (micro)frame N-1)
`
`EOF Interval (micro)frame N)
`
`EOF Interval (micro)frame N+1)
`
`Figure 10-3. Frame and Microframe Creation
`
`The SOF token holds the highest priority access to the bus. Babble circuitry in hubs electrically isolates
`any active transmitters during the End-of-microframe or End-of-Frame (EOF) interval, providing an idle
`bus for the SOF transmission.
`
`The Host Controller maintains the current (micro )frame number that may be read by the USB System.
`
`The following apply to the current (micro )frame number maintained by the host:
`
`• Used to uniquely identify one (micro)frame from another
`
`•
`
`Incremented at the end of every ( micro )frame period
`
`• Valid through the subsequent (micro)frame
`
`Host controllers operating with full-speed devices maintain a current frame number (at least 11 bits) that
`increments at a 1 ms period. The host transmits the lower 11 bits of the current frame number in each SOF
`token transmission.
`
`Host controllers operating with high-speed devices maintain a current microframe number (at least 14 bits)
`that increments at a 125 µs period. The host transmits bits 3 through 13 of the current microframe number
`in each SOF token transmission. This results in the same SOF packet value being transmitted for eight
`consecutive microframes before the SOF packet value increments.
`
`When requested from the Host Controller, the current (micro)frame number is the (micro)frame number in
`existence at the time the request was fulfilled. The current (micro )frame number as returned by the host
`(Host Controller or HCD) is at least 32 bits, although the Host Controller itself is not required to maintain
`more than 11 bits when operating with full-speed devices or 14 bits when operating with high-speed
`devices.
`
`The Host Controller shall cease transmission during the EOF interval. When the EOF interval begins, any
`transactions scheduled specifically for the ( micro )frame that has just passed are retired. If the Host
`Controller is executing a transaction at the time the EOF interval is encountered, the Host Controller
`terminates the transaction.
`
`10.2.4 Data Processing
`The Host Controller is responsible for receiving data from the USB System and sending it to the USB and
`for receiving data from the USB and sending it to the USB System. The particular format used for the data
`c01mnunications between the USB System and the Host Controller is implementation specific, within the
`rules for transfer behavior described in Chapter 5.
`
`10.2.5 Protocol Engine
`The Host Controller manages the USB protocol level interface. It inserts the appropriate protocol
`information for outgoing transmissions. It also strips and interprets, as appropriate, the incoming protocol
`information.
`
`281
`
`PA_0001491
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`10.2.6 Transmission Error Handling
`The Host Controller must be capable of detecting the following transmission error conditions, which are
`defined from the host's point of view:
`
`•
`
`Timeout conditions after a host-transmitted token or packet. These errors occur when the addressed
`endpoint is umesponsive or when the structure of the transmission is so badly damaged that the
`targeted endpoint does not recognize it.
`
`• Data errors resulting in missing or invalid transmissions:
`
`The Host Controller is unable to completely send or receive a packet for host specific reasons, for
`example, a transmission extending beyond EOF or a lack of resources available to the Host
`Controller.
`
`An invalid CRC field on a received data packet.
`
`•
`
`Protocol errors:
`
`An invalid handshake PID, such as a malformed or inappropriate handshake
`
`A false EOP
`
`A bit stuffing error
`
`For each bulk, control, and interrupt transaction, the host must maintain an error count tally. Errors result
`from the conditions described above, not as a result of an endpoint NAKing a request. This value reflects
`the number of times t