Extensible Host Controller Interface: Difference between revisions

Revision as of 23:07, 3 March 2012

Revision as of 14:25, 11 March 2012

Line 1:

'''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 to USB 1.0, 2.0, and 3.0 compatible devices. The specification is also referred to as the USB 3.0 Host Controller specspecification.

== Architectural Goalsgoals ==

The xHCI is a radical break from the previous generations of USB host controller interface architectures (i.e. the Open Host Controller Interface - OHCI, the Universal Host Controller Interface - UHCI, and the Enhanced Host Controller Interface - EHCI) on many counts.

Following are the key goals of the xHCI architecture:

Line 12 ⟶ 13:

* 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

== Architectural Detailsdetails ==

=== Support for all Speedsspeeds ===

The OHCI and UHCI controllers support only USB 1 speed devices (1.5 Mb/s and 12 Mb/s), and the EHCI only supports USB 2 devices (480 Mb/s).

* The xHCI architecture was designed to support all USB speeds, including SuperSpeed (5 Gb/s) and future speeds, under a single driver stack.

=== Power Efficiency ===

When USB was originally developed in 1995, it was targeted at desktop platforms to stem the proliferation of connectors that were appearing on PCs, e.g. PS-2, Serial Port, Parallel Port, Game Port, etc., and host power consumption was not an important consideration at the time. Since then, mobile platforms have become the platform of choice, and their batteries have made power consumption a key consideration. The architectures of the legacy USB host controllers (OHCI, UHCI, and EHCI) were very similar in that the “schedule” for the transactions to be performed on the USB were built by software in host memory, and the host controller hardware would continuously read the schedules to determine what transactions needed to be driven on the USB, and when, even if no data was moved. Additionally, in the case of reads from the device, the device was polled each schedule interval, even if there was no data to read.

=== Power Efficiencyefficiency ===

When USB was originally developed in 1995, it was targeted at desktop platforms to stem the proliferation of connectors that were appearing on PCs, e.g. [[PS-/2 connector|PS/2]], Serial[[serial Portport]], Parallel[[parallel Portport]], Game Port, etc., and host power consumption was not an important consideration at the time. Since then, mobile platforms have become the platform of choice, and their batteries have made power consumption a key consideration. The architectures of the legacy USB host controllers (OHCI, UHCI, and EHCI) were very similar in that the “schedule”"schedule" for the transactions to be performed on the USB were built by software in host memory, and the host controller hardware would continuously read the schedules to determine what transactions needed to be driven on the USB, and when, even if no data was moved. Additionally, in the case of reads from the device, the device was polled each schedule interval, even if there was no data to read.

* The xHCI eliminates host memory based USB transaction schedules, enabling zero host memory activity when there is no USB data movement.

* The xHCI eliminates the need for periodic device polling by allowing the device to notify the host controller when it has data available to read.

* The xHCI does not requires that implementations provide support for all advanced USB 2 and 3 power management features, including USB 2 LPM, USB 3 U1 and U2 states, HERD, LTM, Function Wake, etc. But these features are required to realize all of the advantages of xHCI.

=== Virtualization Supportsupport ===

Legacy USB host controller architectures exhibit some serious shortcomings when applied to virtualized environments. Legacy USB host controller interfaces define a relatively simple hardware data pump; where critical state related to overall bus management (Bandwidthbandwidth allocation, Addressaddress assignment, etc.) reside in the software of the host controller driver. Trying to apply the standard hardware IO virtualization technique, of replicating IOI/O interface registers, to the legacy USB host controller interface is problematic because critical state that must be managed across Virtualvirtual Machinesmachines (VMs) is not available to hardware. The xHCI architecture moves the control of this critical state into hardware, enabling USB resource management across VMs. The xHCI virtualization features also provide for:

* Direct-Assignment of individual USB devices (irrespective of their ___location in the bus topology) to any VM.

* Minimizing run-time inter-VM communications.

* Support for native USB device sharing.

* Support of PCIe SR-IOV.

=== Simplified Driverdriver Architecturearchitecture ===

The EHCI utilizes OHCI or UHCI controllers as “companion controllers”, where USB 2 devices are managed through the EHCI stack, and the port logic of the EHCI allows a USB 1 or 2 device to be routed to a port of a “companion” UHCI or OHCI controller, where the USB 1 and 2 devices are managed through the respective UHCI or OHCI stack. For example, a USB 2 PCIe host controller card that presents 4 USB “Standard A” connectors typically presents one 4-port EHCI and two 2-port OHCI controllers to system software. When a USB 2 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 USB 1 device is attached to connectors 1 or 2 they will be routed to the root hub ports of one of the OHCI controllers for management, and USB 1 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 USB 1 and 2 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 Supportsupport ===

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 to 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 42 ⟶ 46:

* 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.

* A vendor can further take advantage of xHCI architectural features to scale its internal resources to match its target usage models. For instance, if through usability testing a vendor determines that 95% of tablet users will never connect more than 4 USB devices, and each USB device typically defines 4 endpoints (or less), then internal caching for 16 Endpoint Contexts will ensure that under normal conditions there will be no system memory activity due to Endpoint Context paging.

== History ==

The Open Host Controller Interface (OHCI) specspecification was defined by a consortium of companies (Compaq, Microsoft, and National Semiconductor) as open specification to support USB 1.0 devices. The Universal Host Controller Interface (UHCI) refers to a specification that [[Intel]] originally defined as a proprietary interface to support USB 1.0 devices. The UHCI specspecification was eventually made public, but only after the rest of industry had adopted the OHCI specspecification.

The EHCI specspecification was defined by Intel to support USB 2.0 devices. The EHCI architecture was modeled after the UHCI and OHCI controllers, which required software to build the USB transaction schedules in memory, and to manage bandwidth and address allocation. To eliminate a redundant industry effort of defining an open version of a USB 2.0 host controller interface, Intel made the EHCI specspecification available to the industry with no licensing fees. This licensing model was continued for the xHCI specspecification.

The xHCI specspecification was also defined by Intel, however with a greatly expanded industry contribution. Over 100 companies have contributed to the xHCI specification. The [[USB Implementers Forum]] (USB-IF) has also funded a set of xHCI Compliance Tests to maximize the compatibility of the various xHCI implementations. xHCI controllers have been shipping since December of 2009. [[Linux]] drivers are available online. Windows drivers for XP, Vista, and WinWindows 7 are available from the respective xHCI vendors. xHCI drivers for embedded system are available from MCCI, Jungo, and other software vendors. xHCI IP blocks are also available from several vendors for customization in SOC environments.

=== Version history ===

The xHCI specification uses “errata”"errata" files to define updates and clarifications to a specific release. The changes in the errata files are accumulated in each release. Refer to the associated errata files for the details of specific changes.

Most changes defined in the xHCI errata files are clarifications, grammatical or spelling corrections, additional cross-references, etc., which do not affect a driver implementation. Changes that are determined to be ''architectural'' utilize a ''Capability'' flag to determine whether a particular feature is supported by an xHCI implementation, and an ''Enable'' flag to turn on the feature.

==== Prereleases ====

Line 60 ⟶ 65:

* ''xHCI 1.0, errata files 1-6'': Released in March 18, 2011. <br />Clarifications.

* ''xHCI 1.0, errata files 1-7'': Released in June 13, 2011. <br />Clarifications.

== External links ==

{{Commons category|USB}}

{{wikibooks|Serial Programming:USB Technical Manual|USB connectors}}

* [http://www.usb.org/ USB official website (USB Implementers Forum, Inc.)]

* [ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf Open Host Controller Interface (OHCI)]

Line 69 ⟶ 74:

* [http://download.intel.com/technology/usb/download/ehci-r10.pdf Intel Enhanced Host Controller Interface (EHCI)]

* [http://www.intel.com/technology/usb/download/xHCI_Specification_for_USB.pdf Intel eXtensible Host Controller Interface (xHCI)]

{{DISPLAYTITLE:eXtensible Host Controller Interface (xHCI)}}

[[Category:Universal Serial Bus]]