Extensible Host Controller Interface: Difference between revisions

Revision as of 14:38, 15 September 2023

Latest revision as of 19:09, 11 August 2025

(5 intermediate revisions by 4 users not shown)

Line 1:

{{Redirect|XHCI|the radio station|XHCI-FM}}openai chboi
{{short description|Computer interface specification}}

{{More footnotes|date=April 2014}}

The '''eXtensible Host Controller Interface''' ('''xHCI''') is a technical specification that provides a detailed framework for the functioning of a computer's [[host controller]] for [[Universal Serial Bus]] (USB). Known alternately as the [[USB 3.0]] host controller specification, xHCI is designed to be backward compatible, supporting a wide range of USB devices from older USB 1.x to the more recent USB 3.x versions.

Distinct from its predecessors, the [[Open Host Controller Interface]] (OHCI) and, the [[Universal Host Controller Interface]] (UHCI) and the [[Host controller interface (USB, Firewire)#EHCI|Enhanced Host Controller Interface]] (EHCI), xHCI offers several technological improvements. Specifically, it is designed to handle multiple data transfer speeds (low, full, high, and SuperSpeed) within a single unified standard. This makes it more efficient in managing computational and power resources, a feature particularly beneficial for mobile devices with limited power capabilities like tablets and smartphones. Additionally, xHCI simplifies the architecture needed to support a mixture of low-speed and high-speed devices, which streamlines the development of drivers and system software.

xHCI marks a significant improvement over its predecessors, the Open Host Controller Interface (OHCI) and, the Universal Host Controller Interface (UHCI) and the Enhanced Host Controller Interface (EHCI), in several key ways:

# '''Multi-Speed Support''': Unlike OHCI, UHCI and UHCIEHCI, which were limited to specific USB speeds, xHCI is capable of managing multiple data transfer speeds—low, full, high, and SuperSpeed—under a single standard. This eliminates the need for multiple host controllers or complex switching mechanisms when dealing with various types of USB devices, thereby improving efficiency.

# '''Power Management''': xHCI includes advanced power management features that allow for selective suspension of USB devices and more granular power distribution. This is especially beneficial for mobile devices with limited battery life, such as tablets and smartphoneslaptops, as it helps to maximize power utilization and extend battery life.

# '''Streamlined Architecture''': xHCI's architecture is designed to be simpler and more straightforward, reducing the complexity of driver development. In older architectures like OHCI, UHCI and UHCIEHCI, supporting a mix of low-speed and high-speed devices required complicated algorithms and multiple transaction translators. xHCI simplifies this by integrating these functions into the host controller itself, thus easing the burden on system software and driver developers.

By enhancing support for multiple speeds, optimizing power management, and simplifying the underlying architecture, xHCI serves as a more efficient and unified standard for USB host controllers.

Line 28 ⟶ 29:

== Architectural details ==

=== Support for all speeds ===

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

The xHCI architecture was designed to support all USB speeds, including SuperSpeed (5  Gbit/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 connector|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.

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

* The xHCI reduces the need for periodic device polling by allowing a USB 3.0 or later device to notify the host controller when it has data available to read, and moves the management of polling USB 2.0 and 1.1 devices that use interrupt transactions from the CPU-driven USB driver to the USB host controller. EHCI, OHCI, and UHCI host controllers would automatically handle polling for the CPU if there are no changes that need to be made and if no device has any interrupts to send but they all rely on the CPU to set the schedule up for the controllers.<ref>{{cite web|url=http://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf |title=UHCI11D.DOC |website=Ftp.netbsd.org |date= |accessdate=2017-01-09}}</ref><ref>{{cite web |url=http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf |title=Archived copy |accessdate=2014-07-02 |url-status=dead |archiveurl=https://web.archive.org/web/20150810175253/http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf |archivedate=2015-08-10 }}</ref><ref>[ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf] {{dead link|date=JanuaryMay 20172025|bot=medic}}{{cbignore|bot=medic}} </ref> If any USB device using interrupt transactions does have data to send, then an xHCI host controller will send an interrupt to notify the CPU that there is a USB interrupt transaction that needs handling. Since the CPU no longer has to manage the polling of the USB bus, it can spend more time in low power states.

* The xHCI does not require 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.

Line 47 ⟶ 48:

=== Simplified driver architecture ===

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 low-speed or full-speed USB device to be routed to a port of a "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 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.

Line 57 ⟶ 58:

=== 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 256KB256&nbsp;KB 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" 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.

Line 90 ⟶ 91:

==== xHCI 1.1 ====

* ''xHCI 1.1'': Released on December 21, 2013. Specified USB 3.1 data rate of ''10&nbsp;Gbit/s'' (''SuperSpeed+''). This incorporates xHCI 1.0 errata files 1-21. Allows controller to require a larger number of scratchpad buffers (up to 1023) in HCSPARAMS2 capability register.

==== xHCI 1.2 ====

Line 101 ⟶ 102:

{{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)]{{dead link|date=September 2017May 2025|bot=InternetArchiveBot medic}}{{cbignore|fix-attemptedbot=yes medic}}

* [http://www.usbman.com/WebDrivers/usbpdffiles/UHCI%20Intel%20Specification.pdf Intel Universal Host Controller Interface (UHCI)] [https://web.archive.org/web/20100326195950/http://www.usbman.com/WebDrivers/usbpdffiles/UHCI%20Intel%20Specification.pdf Archived there]

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