What is a Hi-Speed USB Host Controller?

EXtensible Host Controller Interface ( xHCI ) is a computer interface specification that defines a register-level description for a universal serial bus (USB) host controller. Interface with 3.x compatible devices. This specification is also called the USB 3.0 host controller specification.

In many ways, xHCI has a fundamental breakthrough compared to previous generations of USB host controller interface architectures. The previous generations were: Open Host Controller Interface (OHCI), Universal Host Controller Interface (UHCI), and Enhanced Host Controller Interface (EHCI). The following are the main goals of the xHCI architecture:

• Efficient operation idle power consumption and performance are better than traditional USB host controller architecture;

• Device-level programming model that is completely consistent with the existing USB software model;

• Decouple the host controller interface provided to the software from the underlying USB protocol;

• Minimize host memory access and completely eliminate host memory access when USB devices are idle;

• Eliminate register writes and minimize register reads during normal data transfers;

• Eliminate the "Companion Controller" mode;

• Enable hardware "failover" mode when system resources are limited, so the device is still accessible, but may have unfavorable power / performance;

• Ability to provide different hardware functions in different markets, such as host controller power, performance and cost tradeoffs for specific markets;

• Define an extensible architecture to provide a simple path for new USB specifications and technologies, such as higher bandwidth interfaces, optical transmission media, etc., making it unnecessary to define a USB host controller interface. ^[1]

  Scalable host controller interface supports all speeds

  OHCI and UHCI controllers only support USB 1 speed drivers (1.5 Mbit / s and 12 Mbit / s) while EHCI only supports USB 2 drivers (480 Mbit / s).

  The xHCI architecture is designed to support all USB speeds, including SuperSpeed (5 Gbit / s) and future speeds, and requires only a single driver stack.

  Scalable host controller interface power efficiency

  When USB was first developed in 1995, it was designed for desktop platforms to prevent the ever increasing number of connectors on the PC (such as PS / 2, serial port, parallel port, game port, etc.). Not an important consideration. Since then, mobile platforms have become one of the options, and its battery makes power consumption a key consideration. The architecture of traditional USB host controllers (OHCI, UHCI, and EHCI) is very similar. The "schedule" of transactions performed on USB is built by software in the host's memory, and the host controller hardware will continuously read and schedule to determine the Need to drive transactions, even if no data has been moved. In addition, when reading from a device, the device is polled at every scheduling interval even if there is no data to be read.

  • xHCI eliminates the host memory based on the USB transaction schedule and enables zero host memory activity when there is no USB data movement.

  • xHCI allows USB 3.0 or later devices to notify the host controller when data can be read, thereby reducing the need to periodically poll the device; and will use USB 2.0 and 1.1 devices that use interrupt handling to manage USB drivers driven from the CPU The program moves to the USB host controller. The EHCI, OHCI, and UHCI host controllers automatically handle polling for the CPU if no changes are needed and if there are no interrupts to send from any device, but they all rely on the CPU to set a schedule for the controller. If any USB device using an interrupt transaction has data to send, the xHCI host controller will send an interrupt to notify the CPU of a USB interrupt transaction that needs to be processed. Since the CPU no longer needs to manage the polling of the USB bus, it can stay longer in low-power states.

  • xHCI does not require its implementation to support all advanced USB 2 and 3 power management functions, including USB 2 LPM, USB 3 U1 and U2 status, HERD, LTM, wake-on-function, etc. But these functions are necessary to realize all the advantages of xHCI. ^[2]

  Scalable host controller interface virtualization support

  The traditional USB host-controller architecture shows some serious flaws when applied to a virtualized environment. The traditional USB host-controller interface defines a relatively simple hardware data pump; key states related to overall bus management (bandwidth allocation, address allocation, etc.) reside in the software of the host adapter driver (HCD). Attempting to apply standard hardware IO virtualization technology (copying I / O interface registers) to traditional USB host controller interfaces is problematic because critical state management across virtual machines (VMs) is not applicable to hardware. The xHCI architecture transfers control of this critical state to hardware, thereby enabling USB resource management across virtual machines. xHCI virtualization functions also provide:

  • Each USB device (regardless of its position in the bus topology) is directly assigned to any virtual machine;

  • Minimize communication between virtual machines at runtime;

  • Support native USB device sharing;

  • Supports PCIe SR-IOV.

  Extensible host controller interface simplifies driver architecture

  EHCI uses OHCI or UHCI controllers as "peer controllers", where USB 2 devices are managed through the EHCI stack, and EHCI's port logic allows routing low- or full-speed USB devices to "peer" UHCI or OHCI controllers, where low-speed or Full-speed USB devices are managed through the corresponding UHCI or OHCI stack. For example, a USB 2 PCIe host controller card that provides four USB "standard A" connectors will typically provide the system software with a 4-port EHCI and two 2-port OHCI controllers. When a high-speed USB device is connected to one of the four connectors, the device is managed by one of the four root hub ports of the EHCI controller. If a low-speed or full-speed USB device is connected to connector 1 or 2, it will be routed to the root hub port of one of the OHCI controllers for management, and low-speed and full-speed USB devices connected to connector 3 or 4 will be routed to the other The root hub port of an OHCI controller.

  • The xHCI architecture eliminates the need for a companion controller and its separate driver stack.

  • The schedule consolidation, bandwidth management, and USB device address assignment functions previously performed by the driver are now transferred to xHCI hardware, which makes the xHCI software stack simpler, streamlined, and lower latency.

  Scalable host controller interface stream support

  The USB 3.0 SuperSpeed specification adds streaming support, which is mainly for high-performance storage operations via USB. The relationship between the USB endpoint and the system memory buffer is usually 1: 1. The host controller is only responsible for directing all data transfers. Streams change this paradigm by providing a one-to-many "buffer" association and allow the device to directly tell the host controller to which buffer to move. The USB data transfer associated with the USB stream endpoint is scheduled by the same batch endpoint owned by xHCI, but the data buffer associated with the transfer is determined by the device. The xHCI USB stream supports up to 64K buffers associated with a single endpoint.

  • The xHCI stream protocol support allows USB devices to choose which buffer to use for transmission when scheduling xHCI. ^[3]

  Scalable host controller interface scalability

  The xHCI architecture is designed to be highly scalable, capable of supporting 1 to 255 USB devices and 1 to 255 root hub ports. Because each USB device defines a maximum of 31 endpoints, xHCI supporting 255 devices can support up to 7,906 individual total endpoints. Generally speaking, each memory buffer associated with an endpoint is described by a queue in a physical memory block, where the queue needs head pointer, tail pointer, length and other registers to define its state. There are many ways to define queue status, but if each queue occupies 32 bytes of register space, almost 256KB of register space is required to support 7,906 queues. Generally, only a small number of USB devices are connected to a system at the same time, and on average, a USB device supports 3-4 endpoints, and some of them are active at the same time. xHCI maintains the queue state in system memory as a context data structure for the endpoint. Contexts are designed so that they can be cached by xHCI and "paged" by the activity of the endpoint. Therefore, vendors can adjust the space and resources of their internal xHCI endpoint context caches based on the actual usage patterns expected by their products, without having to design in accordance with the constraints of the architecture itself. In the case where the internal cache space is selected ideally and the conditions are normal use, xHCI does not appear context paging. USB endpoint activity is often sudden. That is, at any point in time, there may be a large number of endpoints ready for mobile data, but only a subset is active on mobile data. For example, if the user leaves the device, the interrupted endpoint of the mouse may not transmit data for several hours. An algorithm designed by the xHCI vendor can detect this situation and make that endpoint a paging candidate when the other endpoint becomes busy.

  • The maximum value of the xHCI architecture design allows a large number of USB devices, ports, interrupt vectors, ... but the definition of the corresponding implementation only needs to meet the values claimed by its marketing. For example, vendors can implement xHCI on their tablets to support only up to 16 USB devices.

  • Vendors can further leverage xHCI architecture features to adjust their internal resources to match target usage patterns. For example, if a vendor has passed usability testing to determine that 95% of tablet users will never connect more than 4 USB devices, and each USB device typically defines 4 endpoints (or less), then it can be determined that the internal cache is normally 16 One endpoint context is sufficient, there will be no system memory activity due to endpoint context paging. ^[4]