Extensible Host Controller Interface: Difference between revisions

Revision as of 12:11, 10 June 2016

Revision as of 22:09, 4 August 2016

Line 1:

{{More footnotes|date=April 2014}}

'''eXtensible Host Controller Interface''' ('''xHCI)''') is a computer interface specification that defines a register-level description of a host controller for [[Universal Serial Bus]] (USB), which is capable of interfacing with USB 1.x, 2.0, and 3.x compatible devices. The specification is also referred to as the [[USB 3.0]] host controller specification.

== Architectural goals ==

Line 10:

* Minimize host memory accesses, fully eliminating them when USB devices are idle

* Eliminate register writes and minimize register reads for normal data transfers

* Eliminate the “Companion"Companion Controller”Controller" model

* Enable hardware “fail"fail-over”over" modes in system resource constrained situations so devices are still accessible, but perhaps at less optimal power/performance point

* Provide the ability for different markets to differentiate hardware capabilities, e.g. target host controller power, performance and cost trade-offs for specific markets

* Define an extensible architecture that provides an easy path for new USB specifications and technologies, such as higher bandwidth interfaces, optical transmission medium, etc., without requiring the definition of yet another USB host controller interface

Line 36:

=== Simplified driver architecture ===

The EHCI utilizes OHCI or UHCI controllers as “companion"companion controllers”controllers", where USB 2 devices are managed through the EHCI stack, and the port logic of the EHCI allows a low-speed or full-speed USB device to be routed to a port of a “companion”"companion" UHCI or OHCI controller, where the low-speed or full-speed USB devices are managed through the respective UHCI or OHCI stack. For example, a USB 2 PCIe host controller card that presents 4 USB “Standard"Standard A”A" connectors typically presents one 4-port EHCI and two 2-port OHCI controllers to system software. When a high-speed USB device is attached to any of the 4 connectors, the device is managed through one of the 4 root hub ports of the EHCI controller. If a low-speed or full-speed USB device is attached to connectors 1 or 2, it will be routed to the root hub ports of one of the OHCI controllers for management, and low-speed and full-speed USB devices attached to connectors 3 or 4 will be routed to the root hub ports of the other OHCI controller. The EHCI dependence on separate host controllers for high-speed USB devices and the group of low-speed and full-speed USB devices results in complex interactions and dependencies between the EHCI and OHCI/UHCI drivers.

* The xHCI architecture eliminates the need for companion controllers and their separate driver stacks.

* The incorporation of the schedule, bandwidth management, and USB device address assignment functions, that were previously performed by the driver in to the xHCI hardware enable a simpler, leaner, lower latency software stack for the xHCI.

=== Stream support ===

Support for Streams was added to the USB 3.0 SuperSpeed specification, primarily to enable high performance storage operations over USB. Classically there has been a 1:1 relationship between a USB endpoint and a buffer in system memory, and the host controller solely responsible for directing all data transfers. Streams changed this paradigm by providing a 1-to-many “endpoint"endpoint to buffer”buffer" association, and allowing the device to direct the host controller as to which buffer to move. The USB data transfers associated with a USB Stream endpoint are scheduled by the xHCI the same as any other bulk endpoint is, however the data buffer associated with a transfer is determined by the device.

* The xHCI USB Stream support allows up to 64K buffers to be associated with a single endpoint.

* The xHCI Streams protocol support allows a USB device to select which buffer that the xHCI will transfer when the endpoint is scheduled.

Line 47:

=== Scalability ===

The xHCI architecture was designed to be highly scalable, capable of supporting 1 to 255 USB devices and 1 to 255 root hub ports. Since each USB device is allowed to define up to 31 endpoints, an xHCI that supported 255 devices would have to support 7,906 separate total endpoints. Classically, each memory buffer associated with an endpoint is described by a queue of physical memory blocks, where the queue requires a head pointer, tail pointer, length and other registers to define its state. There are many ways to define queue state, however if one were to assume 32 bytes of register space for each queue, then almost a 256KB of register space would be required to support 7,906 queues. Typically only a small number of USB devices are attached to a system at one time, and on the average a USB device supports 3-4 endpoints, of which only a subset of the endpoints are active at the same time.

The xHCI maintains queue state in system memory as Endpoint Context data structures. The contexts are designed so that they can be cached by the xHCI, and “paged”"paged" in and out as a function of endpoint activity. Thus a vendor can scale their internal xHCI Endpoint Context cache space and resources to match the practical usage models expected for their products, rather than the architectural limits that they support. Ideally the internal cache space is selected so that under normal usage conditions, there is no context paging by the xHCI.

Also USB endpoint activity tends to be bursty. That is, at any point in time a large number of endpoints may be ready to move data, however only a subset are actively moving data. For instance, the interrupt IN endpoint of a mouse may not transfer data for hours if the user is away from their desk. xHCI vendor specific algorithms could detect this condition and make that endpoint a candidate for paging out if other endpoints become busy.

* The xHCI architecture allows large maximum values for the number of USB devices, ports, interrupt vectors, etc. supported, however an implementation only needs to define the number necessary to meet its marketing requirements. For instance, a vendor could choose to limit the number of USB devices that it supported for a tablet xHCI implementation to 16 devices.