Interfaz de controlador de host extensible

La interfaz de controlador de host extensible ( xHCI ) es una especificación técnica que proporciona un marco detallado para el funcionamiento del controlador de host de un ordenador para el bus serie universal (USB). Conocida también como la especificación del controlador de host USB 3.0 , xHCI está diseñada para ser retrocompatible, admitiendo una amplia gama de dispositivos USB, desde las versiones antiguas de USB 1.x hasta las más recientes de USB 3.x.

A diferencia de sus predecesores, la Interfaz de Controlador de Host Abierta (OHCI), la Interfaz de Controlador de Host Universal (UHCI) y la Interfaz de Controlador de Host Mejorada (EHCI), xHCI ofrece varias mejoras tecnológicas. En concreto, está diseñada para gestionar múltiples velocidades de transferencia de datos (baja, completa, alta y SuperSpeed) dentro de un único estándar unificado. Esto la hace más eficiente en la gestión de recursos computacionales y de energía, una característica especialmente beneficiosa para dispositivos móviles con capacidades de energía limitadas, como tabletas y teléfonos inteligentes. Además, xHCI simplifica la arquitectura necesaria para admitir una combinación de dispositivos de baja y alta velocidad, lo que agiliza el desarrollo de controladores y software de sistema.

xHCI supone una mejora significativa con respecto a sus predecesores, la Interfaz de controlador de host abierta (OHCI), la Interfaz de controlador de host universal (UHCI) y la Interfaz de controlador de host mejorada (EHCI), en varios aspectos clave:

1. Compatibilidad con múltiples velocidades : A diferencia de OHCI, UHCI y EHCI, que se limitaban a velocidades USB específicas, xHCI es capaz de gestionar múltiples velocidades de transferencia de datos (baja, completa, alta y SuperSpeed) bajo un único estándar. Esto elimina la necesidad de varios controladores de host o mecanismos de conmutación complejos al trabajar con distintos tipos de dispositivos USB, lo que mejora la eficiencia.
2. Administración de energía : xHCI mejora las funciones de administración de energía, como la suspensión selectiva USB ^{[ 1 ]} , y permite una distribución de energía más granular ^{[ 2 ]} . Esto es especialmente beneficioso para dispositivos móviles con batería de duración limitada, como tabletas y portátiles, ya que ayuda a maximizar el uso de la energía y prolongar la duración de la batería.
3. Arquitectura optimizada : La arquitectura de xHCI está diseñada para ser más simple y directa, reduciendo la complejidad del desarrollo de controladores. En arquitecturas más antiguas como OHCI, UHCI y EHCI, la compatibilidad con dispositivos de baja y alta velocidad requería algoritmos complejos y múltiples traductores de transacciones. xHCI simplifica esto al integrar estas funciones en el propio controlador host, lo que facilita el trabajo de los desarrolladores de software de sistema y controladores.

Al mejorar la compatibilidad con múltiples velocidades, optimizar la administración de energía y simplificar la arquitectura subyacente, xHCI se consolida como un estándar más eficiente y unificado para los controladores de host USB.

La arquitectura xHCI representa una ruptura radical con las generaciones anteriores de arquitecturas de interfaz de controlador de host USB (es decir, la Interfaz de Controlador de Host Abierta (OHCI), la Interfaz de Controlador de Host Universal (UHCI) y la Interfaz de Controlador de Host Mejorada (EHCI)) en muchos aspectos. A continuación, se detallan los objetivos clave de la arquitectura xHCI:

• Funcionamiento eficiente: el consumo de energía en reposo y el rendimiento son superiores a las arquitecturas de controladores de host USB tradicionales.
• Un modelo de programación a nivel de dispositivo que sea totalmente coherente con el modelo de software USB existente.
• Desacoplar la interfaz del controlador host que se presenta al software de los protocolos USB subyacentes.
• Minimizar los accesos a la memoria del host, eliminándolos por completo cuando los dispositivos USB estén inactivos.
• Eliminar las escrituras en registros y minimizar las lecturas de registros para transferencias de datos normales.
• Eliminar el modelo "Controlador complementario"
• Habilite los modos de "conmutación por error" del hardware en situaciones con recursos del sistema limitados para que los dispositivos sigan siendo accesibles, pero quizás con un rendimiento/potencia menos óptimo.
• Proporcionar la capacidad para que los diferentes mercados diferencien las capacidades del hardware, por ejemplo, las compensaciones entre potencia, rendimiento y coste del controlador host objetivo para mercados específicos.
• Definir una arquitectura extensible que proporcione una vía sencilla para nuevas especificaciones y tecnologías USB, como interfaces de mayor ancho de banda, medios de transmisión óptica, etc., sin necesidad de definir otra interfaz de controlador de host USB.

Los controladores OHCI y UHCI solo admiten dispositivos con velocidad USB 1 (1,5 Mbit/s y 12 Mbit/s), y el EHCI solo admite dispositivos USB 2 (480 Mbit/s).

La arquitectura xHCI se diseñó para admitir todas las velocidades USB, incluyendo SuperSpeed ​​(5 Gbit/s) y velocidades futuras, bajo una única pila de controladores.

Cuando se desarrolló originalmente el USB en 1995, estaba dirigido a plataformas de escritorio para frenar la proliferación de conectores que aparecían en las PC, por ejemplo, PS/2 , puerto serie , puerto paralelo , puerto de juegos , etc., y el consumo de energía del host no era una consideración importante en ese momento. Desde entonces, las plataformas móviles se han convertido en la plataforma preferida, y sus baterías han hecho que el consumo de energía sea una consideración clave. Las arquitecturas de los controladores de host USB anteriores (OHCI, UHCI y EHCI) eran muy similares en el sentido de que el "plan" para las transacciones que se realizarían en el USB se creaba mediante software en la memoria del host, y el hardware del controlador del host leía continuamente los planes para determinar qué transacciones debían ejecutarse en el USB y cuándo, incluso si no se transferían datos. Además, en el caso de lecturas del dispositivo, el dispositivo se sondeaba en cada intervalo del plan, incluso si no había datos para leer.

• El xHCI elimina la programación de transacciones USB basada en la memoria del host, lo que permite que no haya actividad en la memoria del host cuando no hay movimiento de datos USB.
• El xHCI reduce la necesidad de sondeo periódico de dispositivos al permitir que un dispositivo USB 3.0 o posterior notifique al controlador host cuando tenga datos disponibles para leer, y traslada la gestión del sondeo de dispositivos USB 2.0 y 1.1 que utilizan transacciones de interrupción del controlador USB controlado por la CPU al controlador host USB. Los controladores host EHCI, OHCI y UHCI gestionarían automáticamente el sondeo para la CPU si no hay cambios que deban realizarse y si ningún dispositivo tiene interrupciones que enviar, pero todos dependen de la CPU para establecer la programación de los controladores. ^{[ 3 ] [ 4 ] [ 5 ]} Si algún dispositivo USB que utiliza transacciones de interrupción tiene datos para enviar, entonces un controlador host xHCI enviará una interrupción para notificar a la CPU que hay una transacción de interrupción USB que necesita ser procesada. Dado que la CPU ya no tiene que gestionar el sondeo del bus USB, puede pasar más tiempo en estados de bajo consumo.
• La interfaz xHCI no exige que las implementaciones ofrezcan compatibilidad con todas las funciones avanzadas de administración de energía de USB 2 y 3, incluidas USB 2 LPM, los estados U1 y U2 de USB 3, HERD, LTM, Function Wake, etc.; pero estas funciones son necesarias para aprovechar todas las ventajas de xHCI.

Las arquitecturas de controladores de host USB heredadas presentan serias deficiencias al aplicarse a entornos virtualizados. Las interfaces de los controladores de host USB heredadas definen una bomba de datos de hardware relativamente simple, donde el estado crítico relacionado con la gestión general del bus (asignación de ancho de banda, asignación de direcciones, etc.) reside en el software del controlador de host (HCD). Intentar aplicar la técnica estándar de virtualización de E/S de hardware (replicación de registros de interfaz de E/S) a la interfaz del controlador de host USB heredada resulta problemático, ya que el estado crítico que debe gestionarse entre máquinas virtuales (VM) no está disponible para el hardware. La arquitectura xHCI traslada el control de este estado crítico al hardware, lo que permite la gestión de recursos USB entre máquinas virtuales. Las características de virtualización de xHCI también ofrecen:

• Asignación directa de dispositivos USB individuales (independientemente de su ubicación en la topología del bus) a cualquier máquina virtual.
• minimizando las comunicaciones entre máquinas virtuales en tiempo de ejecución
• Compatibilidad con el uso compartido nativo de dispositivos USB
• Compatibilidad con PCIe SR-IOV ( virtualización de E/S de raíz única )

El EHCI utiliza controladores OHCI o UHCI como "controladores complementarios", donde los dispositivos USB 2 se gestionan a través de la pila EHCI, y la lógica de puertos del EHCI permite que un dispositivo USB de baja o alta velocidad se enrute a un puerto de un controlador UHCI u OHCI "complementario", donde los dispositivos USB de baja o alta velocidad se gestionan a través de la pila UHCI u OHCI correspondiente. Por ejemplo, una tarjeta controladora host PCIe USB 2 que presenta 4 conectores USB "Estándar A" normalmente presenta un controlador EHCI de 4 puertos y dos controladores OHCI de 2 puertos al software del sistema. Cuando se conecta un dispositivo USB de alta velocidad a cualquiera de los 4 conectores, el dispositivo se gestiona a través de uno de los 4 puertos raíz del controlador EHCI. Si un dispositivo USB de baja o alta velocidad se conecta a los conectores 1 o 2, se enrutará a los puertos del concentrador raíz de uno de los controladores OHCI para su administración, y los dispositivos USB de baja y alta velocidad conectados a los conectores 3 o 4 se enrutarán a los puertos del concentrador raíz del otro controlador OHCI. La dependencia de EHCI de controladores de host separados para dispositivos USB de alta velocidad y el grupo de dispositivos USB de baja y alta velocidad da como resultado interacciones y dependencias complejas entre los controladores EHCI y OHCI/UHCI.

• La arquitectura xHCI elimina la necesidad de controladores complementarios y sus pilas de controladores independientes.
• La incorporación al hardware xHCI de las funciones de programación, gestión de ancho de banda y asignación de direcciones de dispositivos USB, que anteriormente realizaba el controlador, permite una pila de software más sencilla, optimizada y con menor latencia para el xHCI.

Se añadió compatibilidad con Streams a la especificación USB 3.0 SuperSpeed, principalmente para permitir operaciones de almacenamiento de alto rendimiento a través de USB. Tradicionalmente, existía una relación 1:1 entre un punto final USB y un búfer en la memoria del sistema, siendo el controlador host el único responsable de dirigir todas las transferencias de datos. Streams cambió este paradigma al proporcionar una asociación de uno a muchos entre el punto final y el búfer, permitiendo que el dispositivo indicara al controlador host a qué búfer transferir datos. Las transferencias de datos USB asociadas a un punto final USB Stream se programan mediante el xHCI del mismo modo que cualquier otro punto final de transferencia masiva; sin embargo, el búfer de datos asociado a una transferencia lo determina el dispositivo.

• La compatibilidad con la transmisión USB de xHCI permite asociar hasta 64 KB de búfer a un único punto final.
• La compatibilidad con el protocolo xHCI Streams permite que un dispositivo USB seleccione qué búfer transferirá el xHCI cuando se programe el punto final.

La arquitectura xHCI se diseñó para ser altamente escalable, capaz de admitir de 1 a 255 dispositivos USB y de 1 a 255 puertos de concentrador raíz. Dado que cada dispositivo USB puede definir hasta 31 puntos finales, un xHCI que admitiera 255 dispositivos tendría que admitir un total de 7906 puntos finales. Clásicamente, cada búfer de memoria asociado a un punto final se describe mediante una cola de bloques de memoria física, donde la cola requiere un puntero de cabeza, un puntero de cola, una longitud y otros registros para definir su estado. Existen muchas maneras de definir el estado de la cola; sin embargo, si se asumiera un espacio de registro de 32 bytes para cada cola, se requerirían casi 256 KB de espacio de registro para admitir 7906 colas. Normalmente, solo se conecta un número reducido de dispositivos USB a un sistema a la vez, y en promedio, un dispositivo USB admite de 3 a 4 puntos finales, de los cuales solo un subconjunto está activo simultáneamente. El xHCI mantiene el estado de la cola en la memoria del sistema como estructuras de datos de contexto de punto final. Estos contextos están diseñados para que el xHCI pueda almacenarlos en caché y paginarlos en función de la actividad del punto final. De este modo, un proveedor puede escalar el espacio y los recursos de la caché interna de contexto de punto final del xHCI para adaptarlos a los modelos de uso práctico previstos para sus productos, en lugar de a las limitaciones arquitectónicas que estos admiten. Idealmente, el espacio de caché interno se selecciona de forma que, en condiciones normales de uso, el xHCI no realice paginación de contexto. Además, la actividad de los puntos finales USB tiende a ser intermitente. Es decir, en cualquier momento, un gran número de puntos finales pueden estar listos para transferir datos, pero solo un subconjunto los está transfiriendo activamente. Por ejemplo, el punto final de interrupción IN de un ratón puede no transferir datos durante horas si el usuario se ausenta de su escritorio. Los algoritmos específicos del proveedor del xHCI podrían detectar esta situación y convertir ese punto final en un candidato para paginar si otros puntos finales se encuentran ocupados.

• La arquitectura xHCI permite valores máximos elevados para el número de dispositivos USB, puertos, vectores de interrupción, etc., compatibles; sin embargo, una implementación solo necesita definir la cantidad necesaria para cumplir con sus requisitos de marketing. Por ejemplo, un proveedor podría optar por limitar a 16 el número de dispositivos USB compatibles con una implementación xHCI para tabletas.
• Un proveedor puede aprovechar aún más las características arquitectónicas de xHCI para escalar sus recursos internos y adaptarlos a sus modelos de uso objetivo. Por ejemplo, si mediante pruebas de usabilidad un proveedor determina que el 95 % de los usuarios de tabletas nunca conectarán más de 4 dispositivos USB, y cada dispositivo USB define normalmente 4 puntos finales (o menos), entonces el almacenamiento en caché interno para 16 contextos de punto final garantizará que, en condiciones normales, no haya actividad de memoria del sistema debido a la paginación de contextos de punto final.

La especificación Open Host Controller Interface (OHCI) fue definida por un consorcio de empresas ( Compaq , Microsoft y National Semiconductor ) como una especificación abierta para admitir dispositivos USB 1.0. La Universal Host Controller Interface (UHCI) se refiere a una especificación que Intel definió originalmente como una interfaz propietaria para admitir dispositivos USB 1.0. La especificación UHCI se hizo pública posteriormente, pero solo después de que el resto de la industria hubiera adoptado la especificación OHCI.

La especificación EHCI fue definida por Intel para dar soporte a dispositivos USB 2.0. La arquitectura EHCI se basó en los controladores UHCI y OHCI, que requerían software para generar los planes de transacciones USB en memoria y gestionar el ancho de banda y la asignación de direcciones. Para evitar un esfuerzo redundante por parte de la industria al definir una versión abierta de la interfaz del controlador host USB 2.0, Intel puso la especificación EHCI a disposición de la industria sin coste de licencia.

El modelo de licenciamiento EHCI se mantuvo para la especificación xHCI de Intel, aunque con una contribución de la industria mucho mayor. Más de 100 empresas han contribuido a la especificación xHCI. El USB Implementers Forum (USB-IF) también ha financiado un conjunto de pruebas de conformidad xHCI para maximizar la compatibilidad de las diversas implementaciones de xHCI.

Los controladores xHCI 1.0 se comercializan desde diciembre de 2009. Los kernels de Linux desde 2009 incluyen controladores xHCI, ^{[ 6 ]} pero para kernels más antiguos hay controladores disponibles en línea. Los controladores para Windows XP , Vista y Windows 7 están disponibles a través de los respectivos proveedores de xHCI. Los controladores xHCI para sistemas embebidos están disponibles a través de MCCI , Jungo y otros proveedores de software. También hay bloques IP xHCI disponibles a través de varios proveedores para su personalización en entornos SOC. Los controladores y dispositivos xHCI 1.1 comenzaron a comercializarse en 2015.

La especificación xHCI utiliza archivos de erratas para definir actualizaciones y aclaraciones de una versión específica. Los cambios en estos archivos se acumulan en cada versión. Consulte los archivos de erratas correspondientes para obtener detalles sobre los cambios específicos. La mayoría de los cambios definidos en los archivos de erratas de xHCI son aclaraciones, correcciones gramaticales u ortográficas, referencias cruzadas adicionales, etc., que no afectan la implementación del controlador. Los cambios que se consideran de índole arquitectónica utilizan un indicador de capacidad para determinar si una función en particular es compatible con una implementación xHCI, y un indicador de habilitación para activarla.

La especificación xHCI evolucionó a través de varias versiones antes de su lanzamiento oficial en 2010:

• xHCI 0.9 : Lanzado en agosto de 2008.
• USB 0.95 : Lanzado en diciembre de 2008.
• USB 0.96 : Lanzado en agosto de 2009.
• USB 0.96a : Versión candidata 1.0, publicada en abril de 2010. Primeros dispositivos comerciales basados ​​en esta versión.

• xHCI 1.0 : Primera versión pública, 21 de mayo de 2010. Velocidades de datos USB especificadas de 1,5 Mbit/s ( baja velocidad ), 12 Mbit/s ( velocidad completa ), 480 Mbit/s ( alta velocidad ) y 5 Gbit/s ( supervelocidad ).
• xHCI 1.0, archivos de erratas 1-4 : Publicado el 17 de enero de 2011. Incorpora los comentarios iniciales de una audiencia pública más amplia de la versión 1.0, aclaraciones sobre la función Guardar-Restaurar y compatibilidad con LPM de hardware.
• xHCI 1.0, archivos de erratas 1-6 : Publicado el 18 de marzo de 2011. Aclaraciones.
• xHCI 1.0, archivos de erratas 1-7 : Publicado el 13 de junio de 2011. Aclaraciones.

• xHCI 1.1 : Publicado el 21 de diciembre de 2013. Especifica una velocidad de datos USB 3.1 de 10 Gbit/s ( SuperSpeed+ ). Incorpora los archivos de erratas 1-21 de xHCI 1.0. Permite que el controlador requiera un mayor número de búferes de memoria temporal (hasta 1023) en el registro de capacidad HCSPARAMS2.

• xHCI 1.2 : Fecha: mayo de 2019. Especifica velocidades de datos USB 3.2 de 10 Gbit/s ( SuperSpeedPlus Gen1x2 ) y 20 Gbit/s ( SuperSpeedPlus Gen2x2 ). ^{[ 7 ]}

• Sitio web oficial de USB (USB Implementers Forum, Inc.)
• Interfaz de controlador de host abierta (OHCI)
• Interfaz de controlador de host universal de Intel (UHCI) archivada allí
• Interfaz de controlador de host mejorada de Intel (EHCI)
• Interfaz de controlador de host extensible de Intel (xHCI)