Esp - Usb3.0 by Jigc

ESPECIFICACIONES USB 3.
0
[Escriba aqu una descripcin breve del documento. Una descripcin breve es un resumen corto del contenido del documento. Escriba aqu una descripcin breve del documento. Una descripcin breve es un resumen corto del contenido del documento.] Juan Isidoro Garca Cifuentes I.T.I. Especialidad Electricidad & Electrnica Industrial
I.T.I. especialidad Electricidad & Electrnica Industrial
Juan Isidoro Garca Cifuentes
Informtica Industrial
INDICE
1. Visin General de la Arquitectura USB 3.0 1.1. Descripcin del Sistema USB 3.0 1.1.1. Interfaz fsica del USB 3.0 1.1.1.1. Mecnica del USB 3.0 1.1.2. Potencia del USB 3.0 1.1.3. Configuracin del sistema USB3.0 1.1.4. Resumen de la arquitectura del USB 3.0 1.2. Arquitectura SS 1.2.1. Capa fsica 1.2.2. Capa de enlace 1.2.3. Protocolo de capas 1.2.4. Robustez 1.2.4.1. Deteccin de errores 1.2.4.2. Control de errores 1.2.5. Adeministracin de la energa del SS 1.2.6. Dispositivos 1.2.6.1. Dispositivos Perifricos 1.2.6.2. Hubs/Concentradores 1.2.7. Hosts 1.2.8. Modelos del flujo de datos Modelo del flujo de datos SS 2.1. Implementacin de los Viewpoints 2.2. Flujo de comunicacin SS 2.2.1. Pipes/Tuberas/Conexiones virtuales 2.3. Descripcin del protocolo SS 2.3.1. Diferencias con USB 2.0 2.3.1.1. Comparativa de transacciones del USB 2.0 y SS 2.3.1.2. Introduccin a los paquetes SS 2.4. Descripcin General de las transferencias 2.4.1. Data Bursting 2.4.2. Transferencias de Entrada 2.4.3. Transferencias de Salida 2.4.4. Administracin de Energa y del Rendimiento 2.4.5. Transferencias de Control 2.4.5.1. Transferencia de Control. Tamao del Paquete de datos 2.4.5.2. Transferencias de Control. Requisitos del Ancho de Banda 2.4.5.3. Transferencias de Control. Secuencias de datos 2.4.6. Transferencias por Bloques 2.4.6.1. Transferencias por Bloques. Tamao del paquete de datos 2.4.6.2. Transferencias por Bloques. Requisitos del Ancho de Banda 2.4.6.3. Transferencias por Bloques. Secuencias de datos 2.4.6.4. Flujo por bloques (Bulk Streams) 2.4.7. Transferencias por Interrupciones 2.4.7.1. Transferencias por Interrupciones. Tamao del paquete de datos 2.4.7.2. Transferencias por Interrupciones. Requisitos del Ancho de Banda 2.4.7.3. Transferencias por Interrupciones. Secuencias de datos
2.
1. Visin general de la Arquitectura USB 3.0
Este captulo presenta una visin general de la arquitectura del Bus de Serie Universal 3.0 y conceptos clave. USB 3.0 es similar a las versiones anteriores de USB donde un cable (bus) soporta el intercambio de datos entre un equipo host y una amplia gama de perifricos simultneamente accesibles. Los perifricos adyacentes comparten el ancho de banda y estn conectados a travs de un protocolo de host programado. El bus permite adjuntar perifricos, configurar, usar, y desconectar mientras que el host y otros perifricos estn en funcionamiento. USB 3.0 utiliza una arquitectura de bus dual que ofrece compatibilidad con USB 2.0. Proporciona un funcionamiento simultneo de operacin de Super Velocidad ( a partir de ahora: SuperSpeed SS) y sin Super velocidad (non-SSo velocidad del USB2.0). Este captulo est organizado en dos reas de enfoque. El primero se centra en la arquitectura y los conceptos relativos a los elementos que abarcan los buses duales. El segundo se centra en las especificaciones y conceptos de la arquitectura SS. En captulos posteriores se describen los distintos componentes y los requisitos especficos de SS USB con ms detalle. Se espera que el lector tenga conocimientos bsicos de la arquitectura del USB 2.0. Consulte las especificaciones del Bus Serie Universal, Revisin 2.0 para completar los detalles.
1.1. Descripcin del sistema USB 3.0

El USB 3.0 fsicamente est combinado en paralelo con el USB 2.0 (fig 3-1). Este componente tiene una arquitectura similar al USB2.0, como:
- Interconexiones USB 3.0 - Dispositivos USB 3.0 - Host USB 3.0 Mediante el interconexionado los dispositivos USB2.0 y USB3.0 se conectan paralelamente y se comunican con el host USB3.0. La interconexin USB 3.0 hereda su ncleo de los elementos de la arquitectura del USB2.0 aunque se acomodan a la arquitectura del bus dual. La estructura base empleada es igual al USB2.0. Esta consiste en una topologa piramidal en estrella, que tiene el host principal en el primer nivel y en los niveles inferiores encontraremos los host secundarios para conectar los dispositivos. El modelo de conexin USB3.0 permite interconectar a distintos niveles dispositivos USB3.0 y 2.0 sin distinciones. El modelo de conexin USB3.0 permite realizar las conexiones de los USB2.0 y 3.0 sin distinciones y de forma similar los dispositivos USB3.0 pueden ser conectados al bus del USB2.0. La compatibilidad mecnica y elctrica se lleva a cabo gracias a un cable compuesto y a los grupos de conectores asociados que forman la arquitectura del bus dual. Los dispositivos USB3.0 logran su compatibilidad
con las versiones anteriores al incluir las interfaces de SS y non-SS de igual forma el host USB3.0 (que tambin incluye ambas) las necesita para el funcionamiento paralelo de ambos buses. El modelo USB3.0 permite que cualquier dispositivo soporte la mayor velocidad permitida por estos, ya que la velocidad queda limitada por el host y por los dispositivos. Los hubs o concentradores (a partir de ahora llamados hub/s) USB 3.0 son unos dispositivos que permiten proporcionar conexiones adicionales al bus, adems de los proporcionados por el propio host. En esta especificacin nos referiremos a los no-hubs como los dispositivos perifricos para diferenciarlo de los dispositivos hubs. En las especificaciones del USB2.0 el trmino funcin era empleado en ocasiones de forma intercambiable con el dispositivo, pero en esta especificacin una funcin se referir a una entidad lgica relacionada con el interior del dispositivo (host). Las arquitecturas de SS en hosts y dispositivos se describen con detalle en la seccin 3.2.
1.1.1. Interfaz fsica del USB 3.0

La Interfaz fsica del USB3.0 est comprendida por la parte elctrica del USB2.0 (Captulo 7 de las especificaciones del USB2.0), mecnica (Captulo 5) y las especificaciones fsicas del SS para los buses (Captulo 6). La capa fsica de SS est descrita en la Seccin 3.2.1.
1.1.1.1. Mecnica del USB 3.0 Las especificaciones mecnicas para cables y conectores del USB3.0 estn previstas en el captulo 5. Todos los dispositivos USB tienen conexiones denominadas upstream (aguas arriba). Los host y hubs(definidos posterioremente) poseen una o ms conexiones dowstream (aguas abajo). Las conexiones Upstream y Downstream no son mecnicamente intercambiables, eliminando as el posible retorno de las conexiones a los hubs. Los cables USB3.0 tienen ocho conductores: 3 pares trenzados para seales de datos y un par de fuerza (alimentacin y tierra). La figura 3-2 ilustra la disposicin bsica para el cable USB3.0. De los 3 pares de cables para el envio de datos, dos de ellos sern empleados para el envio de la seal SS, empleando uno para RX y otro para TX (es decir: recepcin y transmisin).
Los receptores upstream y downstream son compatibles con las conexiones del USB2.0. Los cables y conectores del USB 3.0 no estn destinados a ser compatibles con los receptores upstream del USB 2.0. Como ayuda para los usuarios las partes 3
plsticas de las conexiones (hembras y macho) del USB3.0 se encuentran coloreadas. El rendimiento elctrico (prdida de insercin, de retorno, cruce de datos crosstalk) del USB3.0 est definido por los cables en s, sus montajes y los requisitos de conformidad incluidos en las especificaciones de los test. Del mismo modo, la mecnica (insercin, extraccin de fuerzas, durabilidad) y requerimientos ambientales (temperatura, mezclas con gases) son definidos y establecidos a travs de pruebas establecidas por test industriales en las especificaciones. 1.1.2. Potencia del USB 3.0 La especificacin cubre dos aspectos referidos a la potencia: -La distribucin de potencia en USB3.0 se realiza de forma parecida al USB 2.0, con la diferencia que es capaz de diferenciar (downstream) cuando se necesita potencia para un dispositivo de 3.0 o de 2.0, dndole la potencia que necesita a cada uno. -La administracin de energa tratar de repartir de forma eficiente la energa en el host, dispositivo, hubs y el software que administra la operacin en el bus. La gestin de energa del bus USB 2.0 es invariable. El modelo de distribucin de potencia del SuperSpeed es descrito en el Apndice C. 1.1.3. Configuracin del sistema USB3.0 USB 3.0 soporta todos los dispositivos USB (de cualquier velocidad) conectados en cualquier momento. Por lo que el software debe adaptarse a los cambios dinmicos en la unidad fsica del bus. La arquitectura de los elementos para conocer la conexin y desconexin de los dispositivos USB son idnticos al USB2.0. Existen mejoras proporcionadas para manejar los detalles del bus SS para la configuracin y administracin de energa. La arquitectura dual-bus permite la activacin de cada uno de los buses de forma independiente y proporciona a los dispositivos USB la velocidad mxima del bus y ms alta permitida por el dispositivo. 1.1.4. Resumen de la Arquitectura USB 3.0 USB 3.0 es una Arquitectura Dual-Bus que incorpora USB2.0 y el bus de SuperSpeed. La tabla 3-1 resume las principales diferencias entre la arquitectura del USB SuperSpeed y USB2.0.
Caractersticas Velocidad de datos
SuperSpeed USB 5.0 Gbps
USB 2.0 Velocidad Baja (1.5 Mbps), Completa (12 Mbps) y Alta (480 Mbps)
Caractersticas SuperSpeed USB USB 2.0
Interfaz de datos
Dual-simplex, cuatro hilos para flujo de datos bidireccional (SS) y otro par para los datos del USB2.0.
Sealizacin diferencial Half-duplex de forma unidireccional (no simultaneas)
Cable de datos
Seis: Cuatro para la ruta de datos del SS. Dos para la ruta de datos del non-SS.
Dos: para la ruta de datos con velocidades Baja/Completa /Alta.
Protocolo para transacciones del bus
Host dirigido, el flujo asncrono, el trfico de paquetes de datos se encaminan directamente
Host dirigido, trfico de flujo encuestado. El trfico de paquetes es difundido a todos los dispositivos.
Control de Energa
Enlace multinivel de control de energa que soporta los estados: inactivo, reposo y suspensin. Control de energa en los niveles de enlace, dispositivo y funcin. Tal como el USB 2.0 con un 50 % de incremento en la energa no configurable, y un incremento de un 80 % en la energa configurable.
Nivel de los puertos con dos niveles latentes de entrada / salida.
Energa del Bus
Dispositivos alimentados por bus con lmites de energa menores para dispositivos no configurados y suspendidos (stand by).
Estado del puerto
El hardware del puerto detecta los eventos de conexin y trae el puerto en estado operativo listo para la comunicacin de datos SS.
El hardware del puerto detecta los eventos de conexin. El software del sistema utiliza comandos para la transicin a estado activo del puerto (es decir, puede hacer la comunicacin de flujo de datos a travs del USB).
Tipos de transferencias de datos
Es un tipo de USB 2.0 con limitaciones establecidad por el Cuatro tipos de transferencia de datos: SuperSpeed. Los Bulk poseen por interrupcin, por bloque, iscrona y mayor capacidad (consultar de control. Seccin 3.2.8)
1.2. Arquitectura SS El bus de SS es una arquitectura de comunicaciones por capas, que estn compuestas por los siguientes elementos: - Interconectores SS. La interconexin SuperSpeed es la forma en la que los dispositivos son conectados y comunicados con el host a travs del bus de SuperSpeed. Esto incluye la topologa de los dispositivos conectados al bus, las comunicaciones entre capas, la relaciones entre ellos y cmo interactan para llevar a cabo intercambios de informacin entre el host y los dispositivos. - Dispositivos. Los dispositivos SS son fuentes de intercambio de informacin. Implementan el requerido y ltimo dispositivo, comunicaciones entre capas SS para llevar a cabo el intercambio de informacin entre un conductor en el host y la funcin lgica en el dispositivo. - Host. Un host SS es una fuente de informacin. Estos implementan el host final, las comunicaciones entre capas para llevar a cabo el intercambio de informacin a travs del bus. Poseen la capacidad de programar la actividad de SS y administrar el bus SS y todos los dispositivos conectados a este La figura 3.3. muestra un diagrama de referencia de las interconexiones del SS, representadas como comunicaciones por capas a travs de la topologa host, de cero a cinco niveles de hubs y el dispositivo.
Las filas (dispositivo o host, protocolo, enlace y fsico) realizan la comunicacin entre capas de las interconexiones SS. Las secciones 3.2.1 a la 3.2.3 ofrecen una visin general de la arquitectura para cada una de las comunicaciones entre capas. Las 3 capas ms a la izquierda (host, hub y dispositivo) muestran las relaciones topolgicas 6
entre los dispositivos conectados al bus de SS; consulte la informacin general en las secciones 3.2.6 a la 3.2.7. La columna de la derecha muestra la influencia de los mecanismos de administracin de energa a travs de las comunicaciones por capas; referidas en la seccin 3.2.5. 1.2.1. Capa fsica Las especificaciones de la capa fsica para SS son detalladas en el captulo 6. La capa fsica define una porcin de capa fsica (a partir de ahora PHY de PHYsical layer) de un puerto y la conexin fsica entre un puerto downstream (en un host o hub) y un puerto aguas arriba en un dispositivo. La conexin fsica del SS est comprendida por dos partes diferenciadas, una parte de transmisin (TX) y otra de recepcin (RX) (Figura 3-2). La velocidad de transferencia de datos es de 5Gbps. Las trayectorias elctricas quedan definidos como: transmisor, canal y receptor; estos colectivamente representan un enlace diferencial unidireccional. Cada enlace diferencial est acoplado en AC mediante condensadores localizados en el lado de transmisin del enlace. El canal incluye caractersticas elctricas de los cables y conectores. A nivel elctrico cada enlace diferencial es inicializado al activar el receptor su terminacin. El transmisor es responsable de detectar el extremo y recibir la terminacin como una indicacin de un bus conectado e informado sobre la capa de enlace conectada y teniendo en cuenta la operacin de enlace y gestin. Cuando las terminaciones recibidas estn presente pero sin seal es cuando sucede el enlace diferencial, este es considerado como un estado inactivo. Cuando este estado, tiene una seal peridica de baja frecuencia (LFPS) es usada como seal de inicializacin y administracin de la informacin de energa. El LFPS es relativamente simple con lo genera, detecta y usa muy poca energa. Cada PHY tiene su propio reloj denominado Reloj con Dispersin en Espectro (Spread Spectrum Clocking denominado a partir de ahora SSC) para modulacin. El cable USB3.0 no incluye reloj de referencia por eso los dominios de reloj en cada extremo de las conexiones fsicas no estn explcitamente conectadas. El tiempo de sincronizacin de cada bit de nivel se basa en receptores alineados locales estos bits de recuperacin del reloj transmiten seales de reloj en fase de bloqueo para la seal de transmisin de la trama de bits recibidos. El receptor necesita de bastantes transiciones fiables de recuperacin del reloj y del flujo de datos de bits. Para asegurar una adecuada transicin debe ocurrir que fluya una corriente independientes de bits de datos contenidos para empezar a trasmitir, el transmisor codifica los datos y controla la codificacin de datos en smbolos 8b/10b. El control de smbolos es usado para archivar bytes alineados y son usados para encuadrar los datos y gestionar el enlace. Las caractersticas especiales hacen que el control de smbolos sea nico y se identifiquen desde los smbolos de datos. 7
Se emplean una serie de tcnicas para mejorar el rendimiento de un canal. Por ejemplo, para evitar saturar y mejorar el margen de error hasta el receptor, se debe hacer ms nfasis en el transmisor cuando se envan tramas de bits con la misma polaridad. Tambin ecualizar debera ser usado en el receptor con las caractersticas que ms se adapten al perfil ecualizador, como parte del entrenamiento de enlace. Los trminos y condiciones que afectan a las caractersticas elctricas (caractersticas de CC, capacidad del canal,) y tipos de seales (de sincronizacin, desviaciones/fluctuaciones de tolerancia) de los enlaces del SS, son definidos en vista a los tipos de seales. La capa fsica recibe 8 bits de datos desde la capa de enlace y los codifica para reducir las Interferencias Electromagnticas (proviene de ElectroMagnetic Interference a partir de ahora EMI). Los datos obtenidos son enviados por tramas que incluyen el espectro disperso adems de las bajas emisiones EMI. El flujo de bits es recuperado desde el enlace diferencial por el receptor, reunidos en smbolos de 10 bits, se descodifican y descifradan, produciendo los 8 bits de datos que son enviados a la capa de enlace para su posterior procesamiento. 1.2.2. Capa de enlace Las especificaciones de la capa de enlace para la SS son detalladas en el Capitulo 7. Un enlace de SS es una conexin lgica y fsica de dos puertos. Los puertos conectados son llamados enlaces acoplados (a partir de ahora link partner). Un puerto tiene una parte fsica (referido en la Seccin 3.2.1) y una parte lgica. La capa de enlace define la parte lgica de un puerto y las comunicaciones entre enlaces acoplados. La parte lgica de un puerto tiene: - Mquinas de estados para gestionar el final de la conexin fsica. Esto incluye la capa fsica inicializada y los eventos de administracin, es decir, conectados, eliminados y administracin de energa. - Mquina de estados y buffering para la administracin de la informacin intercambiada con el link partner. Esto implementa el protocolo para el control de flujo, distribucin segura (puerto a puerto) de los encabezados de los paquetes, y la administracin del enlace de energa. Los diferentes tipos de paquetes son definidos en el Captulo 7. - Almacenamiento para datos y elementos de informacin para el protocolo de capas. La parte lgica de un puerto tambin: - Proporciona una elaboracin de secuencias de bytes en los paquetes durante la transmisin, por ejemplo la insercin de paquetes delimitados. - Detecta los paquetes recibidos, incluyendo los separadores de paquetes y chequeo de errores de los encabezados de los paquetes (para una entrega fiable). 8
- Proporciona y aporta una interfaz adecuada para el protocolo de capas a travs de los paquetes de intercambio de informacin. La capa fsica proporciona un puerto lgico y una interfaz aunque esta puede ser activada para: - Gestionar el estado de la PHY (es decir los extremos con las conexiones fsicas), incluyendo la administracin de energa y eventos (conexiones, eliminacin y raz). - Transmisin y recepcin de tramas de bits, con seal adicional que cuantifica las tramas como secuencias de control o datos. La capa fsica incluye trasmisiones discretas y recibe enlaces fsicos, por lo tanto, un puerto activado simultneamente transmite y recibe el control y datos de control. El protocolo entre las conexiones de enlace usa una secuencia codificada de control. Nota: esta secuencia de control es codificada por la tolerancia y el tamao 2 los bits de errores. Control de secuencias usadas para el encabezado de los paquetes. 1.2.3. Protocolo de capas Las especificaciones del protocolo de capas para el SS se encuentran detalladas en el Captulo 8. Este protocolo de capas define de un extremo al otro las reglas de comunicaciones entre el host y el dispositivo (ver Figura 3-3). El protocolo SS proporciona el intercambio de informacin que se realiza entre el host y el endpoint del dispositivo. Esta comunicacin es llamada como pipe. Es un protocolo de host directo, lo que significa que el host determina cuando se transfieren datos de aplicacin entre el host y el dispositivo. El protocolo de SS no es en forma de lotera sino que se realiza de forma asncrona, necesitando en nombre del host un servicio de endpoint particular. Todos los protocolos de comunicacin entre capas se llevan a cabo a travs de paquetes. Los paquetes son una secuencia de bits de datos, los cuales especifican la secuencia de control la cual se emplea como delimitador para la capa de enlace. El host transmite los paquetes que son enroutados (encaminados) a travs de hubs directamente hasta el dispositivo perifrico. Los paquetes no atraviesan las rutas del bus que no forman parte del camino directo entre el host y el dispositivo perifrico. Los dispositivos perifricos esperan a ser dirigidos por las indicaciones de los paquetes recibidos. El dispositivo solo transmitir paquetes de datos aguas arribas hasta el host. La cabecera de los paquetes son la base del protocolo de capas ya que fijan el tamao, el tipo de datos y subtipo de datos codificados bajo unas condiciones especficas. Un pequeo registro dentro de la cabecera es utilizada por la capa de enlace (puerto a puerto) para dirigir el camino de los paquetes de datos. Las cabeceras de los paquetes son entregadas por la capa de enlace de forma fiable. Los campos restantes son utilizados por el protocolo end-to-end. La aplicacin de datos es transmitida dentro de la carga til del paquete de datos. El paquete de datos de la carga til est precedido (en el protocolo) por una codificacin especial para la cabecera del paquete de datos. El paquete de 9
datos de la carga til no se libera de forma fiable a travs de la capa de enlace (sin embargo, los encabezados de los paquetes de datos que se acompaan se entregan de forma mas fiable). El protocolo de capas libera los paquetes de datos reconocidos como corruptos o perdidos. No todos los intercambios de informacin utilizan el reconocimiento de datos. Los datos pueden ser transmitidos en rfagas o en secuencias de paquetes de datos uno tras otro (dependiendo de la programacin del host). El protocolo permite un uso eficiente del bus por transmisin y recepcin sobre el enlace. Por ejemplo, un transmisor (el host o dispositivo) puede enviar mltiples paquetes de datos (uno tras otro) en forma de rfagas, mientras que el receptor transmitir datos reconocidos sin interrupcin. El nmero de paquete de datos en una rfaga determinada lo establece el host. Pero, por otro lado, el host puede programar mltiples salidas para activar al mismo tiempo ciertas entradas. El protocolo proporciona un control del flujo segn el tipo de dato transferido. Un dispositivo inicializado en control de flujo es sealado por un dispositivo de vas definido por el paquete de protocolo. Para recibir los eventos de control de flujo, el host debera eliminar el proceso de comunicacin (denominado pipe) programado. La reanudacin del proceso de comunicacin programado se deber realizar desde el host o el dispositivo. El endpoint del dispositivo deber avisar al host de estar preparado (para la fuente o sumidero) a travs de una transmisin asncrona que el paquete est listo para enviar. Tras recibir la notificacin de listo, el host deber fijar el camino y certificar que an tiene buffer disponible. Independientemente, el flujo de informacin puede ser definido y multiplexado en la transferencia. Esto significa que a travs de un nico canal, ms de un flujo de datos que pueden ser etiquetado e identificado. El protocolo proporciona al dispositivo de forma directa cual es la conexin que est activa. Los dispositivos pueden transmitir de forma asncrona notificaciones al host. Estas notificaciones se utilizan para transmitir un cambio en el dispositivo o en el estado de la funcin. Un host transmite una cabecera especial al paquete que incluye al host el registro de tiempo (A partir de ahora Timestamp). Adems este valor es usado para mantener el dispositivo en sincronizacin con el host. En contraste al otro tipo de paquete, el paquete de indicacin se transmite por todos los caminos, no en un estado de baja energa. El registro de tiempo o Timestamp se transmite programando al host en un determinado periodo de tiempo especficado. 1.2.4. Robustez Son varios las propiedades del SS que contribuyen a su robustez: - La totalidad de la seal emplea drivers diferenciales, receptores y apantallamiento. - La proteccin de Comprobacin de Redundancia Cclica (a partir de ahora CRC) para las cabeceras y los paquetes de datos. 10
- Reintentos de las cabeceras de los paquetes de los enlaces a nivel para asegurar una entrega fiable. - El protocolo realiza varios intentos finales de entrega de paquete para asegurar una transmisin fiable. - Los recursos del sistema son detectados, separados y configurados a nivel. - Los datos y el proceso de comunicacin, asegura la independencia de las interacciones entre funciones. 1.2.4.1. Deteccin de errores La capa fsica del USB SS posee una tasa de error de bits, que se supone menor a 1012 bits. Esto proporciona proteccin contra bit de errores ocasionales, elaboracin de paquetes y comandos de enlaces suficientes para una redundancia simple, para tolerar errores de bits. Cada paquete incluye un CRC para proporcionar la deteccin de mltiples bits de errores. Cuando la integridad de los datos requieren una recuperacin de errores se acude al hardware o software. El protocolo separa un CRC para las cabeceras y otro para los datos. Adicionalmente, el control de enlace tiene si propio CRC para las palabras (en cada paquete de la cabecera). Un fallo de CRC en la cabecera o palabras del enlace de control est considerado como un serio problema, lo cual dar como resultado un reintento de recuperar el error. Un fallo de CRC en la carga til del paquete de datos est considerado para la indicacin de datos corruptos y pueden ser manejados por el protocolo de capas quien requiere de una solicitud para volver a enviar el paquete de datos. La capa de enlace y la capa fsica trabajan juntos para proporcionar una transmisin de la cabecera correcta. La capa de enlace usa un chequeo de recogida de error para eliminar errores y retransmitirlos de las cabeceras de los paquetes adems de reducir el rango de error de la cabecera del paquete. Control de errores Los errores son manejados por el Software y el Hardware. El Hardware incluye manejo de errores, incluye la presentacin de informes y vuelve a intentar de nuevo la entrega. *El controlador USB del host debera transmitir que codificaciones de cabecera fallara. El software del cliente puede ser recuperado implementando un camino especfico.
1.2.4.2.
1.2.5. Administracin de la energa del SS SS ofrece una administracin de la energa en las distintas reas de la arquitectura del bus, del enlace y de las funciones del dispositivo (Ver Figura 33). Las reas de administracin no estn directamente acopladas, pero tienen 11
ciertas dependencias; la mayora se ocupa de las transiciones de estados de energa basados en los enlaces, dispositivos y funciones. La gestin de la energa se produce de forma asncrona en cada enlace (al mismo nivel) en conexiones jerrquicas. La administracin de la energa en el enlace debera ser realizada por el dispositivo, el host o una combinacin de ambos. El estado de la energa del enlace debera ser activada por el dispositivo o por el puerto aguas abajo con temporizadores de inactividad que son programados por el host. La energa del enlace es propagada por el puerto aguas arriba a travs del hub (es decir, cuando todos los puertos aguas abajo estn en un estado de poca energa, el hub requiere hacer una transaccin de energa aguas arriba hacia estos puertos). La decisin de cambiar el estado del enlace se realiza de forma local. El host no sigue directamente la va que siguen los estados de energa individuales. Ya que solo estos enlaces entre el host y el dispositivo son los que participan en un intercambio de datos determinado, los enlaces no llegan a ser utilizados para la comunicacin de datos puerto pueden ser puestos en estado bajo de potencia. El host no controla directamente o no tiene poder sobre los estados individuales de los enlaces. Este implica que uno o ms enlaces en el camino entre el host y el dispositivo puedan reducir el estado de energa cuando el host inicializa una comunicacin en el bus. Existen protocolos de bandas para este tipo de mecanismos que fuerzan a los enlaces a que sucedan las transiciones al estado de potencia operativa y notifiquen al host que una transicin ha sido producida. Los host desconocidos conocen (pueden calcular) en el peor de los casos el tiempo en realizar una transicin de un dispositivo, de un estado activo o listo, segn el uso de los mecanismos. De forma similar un dispositivo de inicializacin de comunicacin con el bus realiza el estado de ahorro de energa, realizando su primera transicin a un estado funcional que har que todos los vnculos entre ste y el host puedan pasar al estado de operacin. Los puntos clave de la gestin de potencia de enlace son: - Los dispositivos envan notificaciones de listo al host. - Los paquetes son enroutados, permitiendo que no participen en la comunicacin de datos para transmitir o para permanecer en un estado bajo. - Los paquetes que encuentran puertos en estado de baja potencia, son causa de aquellos puertos que transmiten fuera del estado de bajo consumo con indicaciones de los eventos de transmisin. - Multiples host o dispositivos son accionados por los estados de enlace con poca energa o incrementando la salida de latencias. Como el bus de USB2.0, los dispositivos pueden ser suspendidos explcitamente de forma similar al mecanismo de suspensin de los puertos. Esto establece el vnculo con el estado de enlace de bajo consumo y establece un lmite en el consumo de energa requerido por el dispositivo.
12
SS proporciona soporte para la distribucin de energa, adems de gestionar la energa del dispositivo. Para los dispositivos multifuncin (compuestos), cada funcin se colocar de forma independiente en un estado de bajo consumo. Tenga en cuenta que un dispositivo pasar al estado de suspensin cuando se dirija por el host a travs de un comando del puerto. El dispositivo no har de forma automtica la suspensin del estado hasta que todas las funciones individuales son suspendidas. Las funciones de los dispositivos pueden ser capaces de ser fuentes de activacin remotas. La funcin de activacin remota en una funcin debe de ser explcitamente activada por el host. As mismo un protocolo es activado por una funcin mediante una seal remota que crea un evento que puede ser asociado con una funcin de la fuente. Todas las activaciones remotas se realizan a travs de todas las posibles combinaciones de estado individuales entre el dispositivo y el host. 1.2.6. Dispositivos Todos los dispositivos SS comparten la base de su arquitectura con el USB2.0. Ellos requieren llevar informacin para su auto-identificacin y configuracin genrica. Ellos tambin tienen la obligacin de demostrar un comportamiento coherente con los estados del dispositivo SS definido. Todos los dispositivos tienen asignados una direccin de USB que es seleccionada por el host. Cada dispositivo soporta uno o ms procesos de comunicaciones pipes a travs de los cuales el host se comunica con el dispositivo. Todos los dispositivos deberan de soportar una designacin establecida por el endpoint0 que establece la configuracin del dispositivo. Todos los dispositivos soportan un mecanismo de acceso comn para acceder a la informacin del control por defecto del sistema de conexionado. Esta informacin se completa con la definicin del control de conexiones en el Captulo 9. SS hereda las categoras de informacin soportadas por el control de conexiones del USB2.0. Las especificaciones del USB3.0 definen dos conjuntos de dispositivos USB que se pueden conectar a un host SS. Estos son descritos brevemente a continuacin. 1.2.6.1. Dispositivos Perifricos Un dispositivo perifrico USB3.0 debe proporcionar soporte para el SS y el non-SS. El requerimiento mnimo para un non-SS es tras ser detectado como USB2.0 por el host, que permita que el software indique al usuario que el puerto es capaz de emplear un SS. Un dispositivo puede funcionar perfectamente trabajando en modo nonSS. El funcionamiento simultaneo de los modos SS y non-SS no es posible en un dispositivo perifrico. Los paquetes fsicos individuales de dispositivos USB 3.0 (es decir en un nico perifrico) pueden consistir en un nmero funcional de 13
topologas incluyendo una funcin simple, mltiples funciones en un solo dispositivo perifrico (dispositivo compuesto), y sujeto de manera permanente a otros dispositivos perifricos integrados en el hub (dispositivo combinado). (Ver figura 3-4).
1.2.6.2.
Hubs/Concentradores Las especificaciones para la parte de los hubs USB3.0 son detallados en el captulo 10. Los Hubs siempre han sido un elemento clave en la arquitectura plug and play (PnP) del USB. Los Hubs proporcionan un nmero especfico de puertos aguas abajo para la conexin de los dispositivos. Los hubs adems proporcionan puertos aguas abajo adicionales por lo que proporcionan a los usuarios un mecanismo simple de conectividad para la expansin de los dispositivos adicionales USB. Con el fin de soportar la arquitectura de bus dual USB3.0, un hub USB3.0 es una combinacin lgica de dos hubs: un Hub para USB 2.0 y otro para SS (Ver Figura 3-1). La alimentacin y la tierra provienen desde el cable en un puerto aguas arriba que es compartido por ambas unidades a travs del hub USB 3.0. El hub USB2.0 est conectado a una unidad de lnea de datos del USB2.0 y el hub SS se mantiene conectado a la unidad de lnea de datos del SS. El hub SS gestiona los puertos SS y el USB2.0 sus correspondientes puertos aguas-abajo. Cada puerto fsico tiene un bus especfico de control/registro de estado. Consultar la Especificacin del Bus Serie Universal, Revisin 2.0 para los detalles sobre el hub USB 2.0. Un hub SS consiste en dos componentes lgicos: un hub que controla el SS y otro que funciona como repetidor/promotor del SS. Este ltimo es un protocolo controlado y enroutado entre los puertos aguas arriba y aguas abajo del SS. Tambin tiene un hardware que soporta el reseteo, suspensin y reanudacin de la seal. El SS es controlado para responder al estndar del hub especfico para el control y estado de los 14
comandos que son usados por el host para configurar el hub y para monitorizar y controlar estos puertos. El hub SS participa activamente en el protocolo end-to-end de varias formas, incluyendo: - Routear los paquetes de salida destinados aguas-debajo de forma explcita. - Agrega paquetes de entrada a los puertos de subida. - Propaga paquetes Timestamp a todos los puertos de bajada con bajo poder de consumo. - Detecta los paquetes encontrados cuando un puerto est en bajo consumo. Las transiciones del hub son dirigidas al puerto de salida de los estados con bajo nivel y notifican al host y al dispositivo (en banda) que el paquete encontrado en el puerto tiene poco poder de consumo. 1.2.7. Hosts Un host USB3.0 interacta con el dispositivo USB a travs del controlador del host. Para soportar la arquitectura dual-bus del USB3.0, el controlador del host incluye ambos elementos SS y USB2.0, los cuales pueden dirigir el control simultneamente, el estado y el intercambio de informacin entre el host y un dispositivo sobre cada bus. El host incluye una implementacin especfica del nmero de puertos descendentes o races descendentes para la SS y USB2.0. A travs de este puerto el host: - Detecta el accesorio y elimina el dispositivo USB. - Gestiona el flujo de control entre el host y el dispositivo USB. - Administra el flujo de datos entre el host y el dispositivo USB. - Recopila estadsticas de estados y actividades. - Proporciona energa a los dispositivos USB conectados. El sistema del software USB hereda la arquitectura requerida desde el USB2.0, que incluye: - Enumeracin y configuracin de dispositivos. - Programacin de las transferencias de datos peridicas y asncronas. - La gestin de energa de dispositivos y funciones. - Gestin de la informacin del dispositivo y del bus. 1.2.8. Modelos del flujo de datos Los modelos de flujo de datos son descritos en el captulo 4. El USB SS hereda el modelo de flujo de datos del USB2.0, incluyendo: - Intercambio de datos y control entre el host y los dispositivos a travs de conjuntos unidireccionales o conexiones bidireccionales (bidirectional pipes). - La transferencia de datos ocurre entre el software y un endpoint en particular del dispositivo. Estas asociaciones entre el software del host y los endpoints estn relacionados con funciones particulares llamadas 15
pipes. Un dispositivo deberas tener ms de un pipe activado. Hay dos tipos de enlaces virtuales conocidos: stream y message. Los datos Stream no estn definidos en la estructura USB, mientras que Message s. Pipes tienen asociaciones de ancho de banda, transferencias de tipos de servicios(ver mas abajo) y caractersticas de los endpoints, buenas direcciones y tamaos de memorias. - Muchos de estos enlaces virtuales (pipes) existen cuando el dispositivo esta configurado como software. Sin embargo, un mensaje, de control por defecto del Pipe, siempre existe una vez que el dispositivo se ha encendido y se mantiene en su estado por defecto, proporcionar acceso a las configuraciones del dispositivo, estado y control de la informacin. - Los enlaces virtuales soportan los cuatro tipos de transferencia definidos para USB2.0 (por interrupcin, por bloques, iscrona y por control). Elementos bsicos de la arquitectura de estos tipos de transferencias que son mantenidos sin cambios desde USB2.0. - La transferencia por bloques en SS es denominada Streams. Streams proporciona en banda, apoyo a nivel del protocolo para multiplexar de forma independiente varios flujos de datos lgicos a travs de una transferencia de bloque estndar. 2. Modelo del flujo de datos SS En este captulo se presenta una descripcin de alto nivel sobre como los datos y la informacin se mueve a travs del SS. Consulte el captulo del Protocolo de Capas para obtener ms detalles sobre el protocolo de bajo nivel. Este captulo proporciona informacin general sobre el dispositivo, que ser expandida an ms en su captulo correspondiente. Todas los implementadores deben leer este captulo para comprender los conceptos claves de SS. 2.1. Implementacin de los Viewpoints SS es muy similar a USB2.0 en que proporciona servicios de comunicacin entre un Host USB y el dispositivo USB adjunto. El modelo de comunicacin conserva la arquitectura de capas del USB2.0 y los componentes bsicos de comunicacin de flujo (es decir, punto a punto, algunos tipos de transferencias, etc.). Consulte el Captulo 5 en las especificaciones del Bus Serie Universal, Revisin 2.0 para ms informacin sobre el flujo de comunicaciones USB2.0. Este captulo describe las diferencias (desde USB2.0) de cmo datos y control de informacin son comunicados entre un host SS y los dispositivos SS conectados. Con el fin de entender el flujo de datos de SS, debemos conocer los siguientes conceptos: - Modelo de Flujo de Comunicacin: La Seccin 4.2 describe como se establece el flujo de comunicacin entre el host y el dispositivo a travs del bus SS. - Descripcin del Protocolo SS: En la Seccin 4.3 se da un alto nivel de descripcin acerca del protocolo SS y es comparado con el protocolo del USB2.0. 16
- Descripcin general de las transferencias: La seccin 4.4 proporciona una visin general de cmo funciona la transferencia de datos en SuperSpeed y definen la limitaciones de cada operacin en cada transferencia. - Notificaciones del dispositivo: En la seccin 4.4.9 se proporciona una descripcin de las Notificaciones del Dispositivo, una caracterstica que permite que un dispositivo notifique de forma asncrona los eventos o estados del dispositivo al host. - Fiabilidad y Eficiencia: En la Seccin 4.4.10 y 4.4.11 se resume la informacin y mecanismos disponibles en SS para asegurar la fiabilidad y el incremento de la eficiencia. 2.2. Flujo de comunicacin SS SS conserva los conceptos y mecanismos que son establecidos para los endpoints, pipes y tipos de transferencias. Referidos en la Especificacipn del USB, Revisin 2.0 para ms detalles. Como ocurre en el USB2.0 el ltimo consumidor/productor de datos es un endpoint. Las caractersticas de los endpoints (Tamao mximo de los paquetes, tamao de los bloques) son informados en el Compaero Descriptor SS del endpoint. Como un USB2.0, el endpoint es identificado su uso en direccionamiento triple {Direccin de dispositivo, Nmero de endpoint y Direccin). Todos los dispositivos SS deben implementar como mnimo el Control por Defecto del Endpoint ) ( endpoint 0 ). El control por defecto del Pipe es en una tubera virtual y es definida por la Especificaciones USB, revisin 2.0. 2.2.1. Pipes/Tuberias/Conexiones virtuale Un Pipe SuperSpeed est asociado entre los Endpoint y un dispositivo o software en el host. Los Pipes (tuberas o conexiones virtuales) representan la habilidad que tienen los datos para moverse desde el software a travs del host y un endpoint en un dispositivo para tener un comportamiento definido por las especificaciones del USB, Revisin 2.0. La principal diferencia est en que cuando un endpoint no iscrono en SS est ocupado debe una respuesta Not Ready (NRDY) y deber responder con un Endpoint Ready (ERDY) cuando quiera dar nuevos servicios. El host ser responsable de programar la transicin entre la siguiente oportunidad disponible dentro de las limitaciones segn el tipo de transferencia. 2.3. Descripcin del protocolo SS Como mencion en el captulo de la Descripcin de la Arquitectura del USB3.0, el protocolo del SS toma las ventajas de la capa fsica Dual-Simplex. Todos los tipos de transferencias de USB2.0 son soportadas por el protocolo SuperSpeed. Las diferencias entre el protocolo USB2.0 y el protocolo SS son discutidas a continuacin en una breve descripcin de los paquetes empleados para el SS. 2.3.1. Diferencias con USB 2.0 17
El SS es compatible con los niveles de trabajo del USB2.0. Sin embargo, hay algunas diferencias fundamentales entre el protocolo del USB-2.0 y el SS. - USB2.0 usa 3 tipos de transiciones (Token, Data y Handshake) mientras que el SS usa las mismas partes de forma diferente. Para las salidas, el Token es incorporado en el paquete de datos; mientras que para las entradas el Token es reemplazado por el Handshake. - USB2.0 no soporta bursting mientras que SS soporta un bursting continuo. - USB2.0 se transmite de forma semidplex a travs del bus, mientras que SS es dual simplex hasta el bus para permitir las transaciones de ES. - USB2.0 emplea un modelo de red informtica (a partir de ahora polling) mientras que SS usa notificaciones asncronas. - USB2.0 no tiene capacidad para corrientes de flujo (Streaming) mientras que SS soporta flujos para endpoints de bloques. - USB2.0 no ofrece un mecanismo iscrono para la entrada del bajo consumo a travs de los intervalos de mantenimiento de estados para el BUS. SS permite que los dispositivos capaces de entrar automticamente en el estado de bajo consumo entre los distintos estados de actividad. El Host SS deber transmitir paquetes PING para dirigir los dispositivos iscronos que permiten dar tiempo a la respuesta y activar el estado de energa antes de iniciar la transferencia iscrona. - USB2.0 no ofrece ningn mecanismo para informar al host cuando la latencia del dispositivo puede tolerar si el sistema entra en el estado de bajo consumo. As un host no puede entrar en este estado, ya que si no afectara al rendimiento del dispositivo, ya que carece de compresin de una poltica de energa para el dispositivo. USB3.0 permite un mecanismo para conseguir que el dispositivo consiga informar al host de la tolerancia de latencia usando el establecer la poltica de sistemas de encendido. - USB2.0 transmite intervalos de SOF/uSOF de hasta 1 ms/125 us. Un controlador de dispositivos puede cambiar los intervalos de ajustes que limitan la funcin de host y del sistema de software. El mecanismo que agrega USB3.0 para el envo de mensajes ajustados a travs del Bus es usador por el host para ajustes desde 125 us, para intervalos del bus ascendentes hasta +/-13.333 us. Adems, el host debe enviar ITP (Isochronous Timestamp Packet) definido por el bus. - La gestin de energa del USB2.0, es siempre directamente iniciado por el host. El enlace de gestin de la energa del SS soporta adems que sea iniciado por otras capas. As, cada enlace puede entrar de forma independiente a los estados de bajo consumo y salir cada vez que necesite ser comunicado. - USB2.0 se encarga de la deteccin de errores de transiciones y la recuperacin y control del flujo final para cada nivel de transaccin. SS divide estas funciones entre el end-to-end y los niveles de enlaces. 2.3.1.1. Comparativa de transacciones del USB 2.0 y SS La capa fsica del SS permite que la informacin viaje de forma dualsimplex es decir simultneamente en ambas direcciones. El protocolo 18
SS permite enviar mltiples paquetes de datos despus de recibir un handshake. Para las transferencias al exterior, la informacin contenida en el Token (paquete de datos) del USB2.0 es incorporada en la cabecera del paquete de datos por lo que no se requiere el Token por separado. Para las transferencias de entrada, un handshake es enviado para el dispositivo hasta que se solicitan los datos. El dispositivo debera responder por cualquiera de los datos que regresan, devolviendo un STALL handshake, o devolviendo un NOT READY (NRDY) handshake para aplazar la transferencia hasta que el dispositivo est listo. El USB2.0 transmite paquetes a todos los puertos aguas abajo activos. Cada dispositivo debe decodificar las tres direcciones {direccin del dispositivo, endpoint, y direccin de cada paquete} para determinar si este necesita una respuesta. Los paquetes unicast SS; son paquetes enviados aguas abajo directamente desde la direccin entre el dispositivo y el host. Los paquetes ruteados cuentan con informacin que el hubs usa para determinar cual de los puerto aguas abajo necesita atravesar para alcanzar al dispositivo. Aunque existe una excepcin, los Paquetes Iscronos Timestamp (ITP) que son multicast que activan todos los puertos. Las notificaciones por sondeo del USB2.0, han sido reemplazadas por las notificaciones asncronas. Las transacciones en el SS son iniciadas por el host haciendo una solicitud seguida de una respuesta desde el dispositivo. Si el dispositivo puede cumplir la solicitud, acepta o enva los datos. Si se detiene al final, el dispositivo responder con un STALL Handshake y si no se puede cumplir la condicin por no tener espacio en el buffer o datos, se responder a con un (NRDY) para decir que el host no es capaz de procesar la solicitud en ese momento. Cuando el dispositivo se puede honrar a la solicitud, se enviar un Endpoint Ready (ERDY) al host que luego reprogramar la transaccin. El movimiento de unicast y multicast limitado de paquetes junto con las notificaciones asncronas permiten a los vnculos que no estn pasando activamente a los paquetes que se pongan en estado de bajo consumo. Los puertos Upstream y Downstream cooperan para poner sus enlaces en estados de bajo consumo de energa. Se permiten parejas de enlace para el control independiente de los estados de bajo nivel en los enlaces y propagaciones de los hubs con altos niveles de energa para ver que unos son puertos downstream hasta otros upstream, poniendo el puerto en el estado de energa ms bajo, rpidamente. 2.3.1.2. Introduccin a los paquetes SS Los paquetes SS comienzan con 16 bytes de cabecera. Algunos paquetes solo se componen de la cabecera. Todos los paquetes comienzan con la Informacin acerca del Tipo de Paquete usado para 19
decidir cmo manejarlos. Las cabeceras estn protegidas por 16 bits de CRC (CRC-16) y acaban con 2 bytes de palabras de control de enlace. Dependiendo el tipo, muchos paquetes cuentan con un Route String (cadena de caminos a seguir) y dispositivos con triplo direccin {direccin del dispositivo, endpoints y direccin}. El Route String es usado para dirigir los paquetes que son enviados por el host en una direccin dirigida segn la topologa empleada. Los paquetes son enviados por el dispositivo de forma implcita, ruteados desde el hub directamente. Hay cuatro tipos de paquetes bsicos: Los Paquetes de Gestion (Link Management Packets LMP), los paquetes de Transaccin (Transaction Packet TP), Paquetes de datos (Data Packets DP) y los paquetes Iscronos TimeStamp (Isochronous Timestamp Packets ITP): - Un LMP solo atraviesa un par de puertos directamente y es primordialmente usado para administrar ese enlace. - Un TP atraviesa todos los enlaces que se encuentran conectados entre el Host y un dispositivo. Son usados para el control de flujo de los paquetes de datos, configurar los dispositivos y hubs, etc. Se debe tener presente que un paquete de datos No tiene efectos de carga til de datos. - Un DP atraviesa todos los enlaces del camino directamente conectados al host y al dispositivo. Los DP consisten en dos partes: Una Cabecera (Data Packet Header DPH) la cual es similar al TP y una Crga til (Data Packet Payload DPP) la cual consiste en un bloque de datos de ms de 32 bits de CRC (CRC-32) usados para asegurar la integridad delos datos. - EL ITP es un paquete multicast enviado por el host a todos los enlaces activos. 2.4. Descripcin General de las transferencias Cada paquete de dato no iscrono enviado a un receptor es reconocido por el handshake (llamado ACK en las transacciones de paquetes). Sin embargo, debido al hecho de que el SS tiene transmisiones independientes y las rutas recibidas, el transmisor no tiene que esperar de forma explcita al handshake, para que cada paquete de datos sea transferido antes de enviar el siguiente paquete. SS conserva todos los flujos de datos bsicos y conceptos de transferencias definidos en USB2.0, incluyendo el tipo de transferencia, pipes, y modelos de flujo bsicos. Las diferencias con USB2.0 son discutidas en esta seccin, empezando por el protocolo de nivel, seguido por las restricciones de los tipos de transferencias. Las especificaciones del USB2.0 utilizan un modelo de transaccin en serie. Esto esencialmente significa una gran transaccin de inicio a fin a travs del bus {Token, Datos, Handshake} antes de empezar la siguiente transaccin. La divisin de transacciones se adhiere a este mismo modelo, ya que estn compuestos por transacciones de alta velocidad {Token, Datos, Handshake} que son comprendidos bajo el mismo modelo que otras transacciones. 20
SS mejora el protocolo de transaccin del USB2.0 mediante la transmisin independiente y recibo de rutas. Estos resultados son del protocolo de transacciones del USB SS, que es esencialmente un protocolo de transacciones dividida, que permite mas de una salida bus transaction al igual que ms de una entradas bus transaction para ser actividas en el bus al mismo tiempo. El orden en el cual responden los dispositivos, es fijado en base a un punto final (por ejemplo, si un endpoint recibi tres DPs, el endpoint debe devolver un ACK TPs por cada uno, en el orden que han sido recibidos los DPs). La orden de respuesta de un dispositivo ante los ACKs o DPs es enviada a distintos endpoints del mismo dispositivo, hasta que se implementa un dispositivo y software independiente que no puede esperar que ocurran o terminen en un orden particular. Las escalas de protocolos son bien divididas (a travs de mltiples transacciones para las funciones de los mltiples endpoints) con tasas de bits que no estn sujetas a desfases. El protocolo USB2.0 completa una entrada o salida completa en la transaccin {Token, Data, Handshake} antes de continuar a la siguiente transaccin del bus para la siguiente funcin del endpoint programado. Todas las transmisiones desde el host son esencialmente transmitidas en el bus USB2.0. En cambio, el protocolo SS no reparte todos los paquetes (excepto el ITPs) y paquetes transversos que solo necesita alcanzar al destinatario. El host empieza todas las transiciones enviando un handshake o datos de respuesta por cada dato o handshake. Si un dispositivo no tiene datos disponibles o no puede aceptar los datos, este responde con un paquete de estado, que demuestra que no es capaz de hacerlo. Con posterioridad, cuando un dispositivo est listo para recibir o transmitir datos y enviar notificaciones para el host este indica que puede estar listo para reanudar las operaciones. Adems, se le proporciona la habilidad de SS a los estados con baja energa. Los estados con enlaces de poco nivel son asignados, bien a travs de software o por hardware bajo el control autnomo despus de ser habilitados por software. Estos mecanismos proporcionan la transicin automtica de todos los enlaces entre el host y el dispositivo de un estado inoperativo de energa a uno de actividad. Los dispositivos informan del tamao mximo de cada endpoint en las descripciones de estos. El tamao indica la longitud de carga til que no incluye la parte de enlace y nivel de protocolo. La distribucin del ancho de banda para el SS es similar al USB2.0. 2.4.1. Data Bursting El Desencadenamiento/Rfaga de datos (Data Bursting) mejora la eficiencia mediante la eliminacin del tiempo del reconocimiento por cada paquete de datos bsico. Cada endpoint en los dispositivos SS indica el nmero de paquetes que ese puede enviar/recibir (llamando como el mximo tamao de Data bursting) antes esto deba esperar para un handshake de forma explcita. El tamao mximo de Data Bursting son capacidades individuales de cada endpoint; un endpoint mximo del descriptor Endpoint SS asociado a cada endpoint (referido en la seccin 9.6.7). El host puede cambiar dinmicamente el tamao del burst en un par de transacciones en base a las configuradas por el tamao de este. Por ejemplo 21
cuando un host puede usar diferentes tamaos en los data bursting, pero no de forma limitada, se intenta mantener una poltica justa de intentos de interrupcin en el flujo de datos. Cuando el endpoint est como salida, el host puede gestionar fcilmente el tamao de los burst (el receptor deber gestionar las transacciones). Cuan do un endopoint acta como salida, el host puede limitar el tamao de los burst para los endpoint en un par de transacciones a travs del camino, gracias al reconomiento de los paquetes enviados por el dispositivo. 2.4.2. Transferencias de Entrada El host y el dispositivo debern adaptarse a las restricciones establecidas por el tipo de transferencia y las caractersticas del endpoint. Un host inicia la transferencia mediante el envo de paquetes de entrada que son reconocidos por el dispositivo. Este paquete de confirmacin contiene la informacin de direccionamiento necesaria para encaminar el paquete hasta el endpoint. El host le dice al dispositivo la cantidad de paquetes de datos que pueden ser enviados en secuencia desde el dispositivo. En respuesta el endpoint transmite el paquete de datos con el nmero de vueltas realizadas. El reconocimiento del paquete implica tambin el reconocimiento previo al recibir el paquete de datos de forma satisfactoria. Se tendr en cuenta que a pesar de que el host envia paquetes de confirmacin por cada dato de paquete recibido, el dispositivo puede enviar paquetes de datos sin importar cuantos, sin esperar confirmacin. El protocolo de transacciones de entrada en el SS queda reflejado en la figura 4-1. Las transferencias al bus SS lo constituyen entre una o ms transacciones de entrada por uno o mas paquetes y se completa cuando se cumplen cualquiera de las siguientes condiciones: - Todas las transferencias de datos han sido completamente recibidas. - El endpoint responde con un paquete de datos que tiene menor peso Que el tamao mximo de los endpoints. - El endpoint responde con un error.
22
2.4.3. Transferencias de Salida El host y el dispositivo debern adaptarse a las restricciones establecidas por el tipo de transferencia y las caractersticas del endpoint. El host inicia la transferencia tras el reconocimiendo de los datos (burst) de entrada al dispositivo. Cada paquete de datos contiene informacin sobre las direcciones requeridas para el enrutamiento de los paquetes hasta el endpoint. Tambin incluye la secuencia de nmeros de cada paquete de datos. Para las transacciones no iscronas, el dispositivo devuelve un reconocimiento de paquetes incluyendo el nmero de paquetes para el siguiente envo y su correspondiente reconocimiento. Se tendr en cuenta siempre que el dispositivo requiere enviar un reconocimiento de datos por cada paquete recibido, el host puede enviar como mximo el tamao de los burst de datos de cada paquete del dispositivo sin esperar su reconocimiento. El protocolo de transacciones de salida del SS queda ilustrado en la Figura 4-2. Una transferencia de salida consiste en una o ms transacciones de salidas de uno o ms paquetes, completndose cuando una o ms de estas condiciones suceden: - Todos los datos de la transferencia son completamente transmitidos. - El host enva un paquete con menor peso que el mximo soportado de los endpoints. - El endpoint responde con un error.
2.4.4. Administracin de Energa y del Rendimiento El uso de temporizadores de actividad y gestin de potencia de los enlaces conductores proporcionan la capacidad de gestionar de forma agresiva la energa. Cuando el host enva un paquete a un dispositivo detrs de un hub con el puerto inactivo, el paquete no ser capaz de atravesar el enlace hasta que no vuelva a estar activo. En caso de las transacciones de entrada, el host no ser capaz de iniciar otra transaccin de entrada hasta que la transaccin 23
actual no haya concluido. El efecto de este comportamiento podra tener un significado importante sobre el rendimiento general. Para que el balance de energa aporte un buen rendimiento, el concepto de un aplazamiento (tanto para las entradas como para las salidas) es usado. Cuando el host realiza una transaccin sobre un enlace inactivo, una respuesta es enviada por el hub para decirle al host que este camino no tiene potencia suficiente para atender la transaccin. Este mecanismo informa al host de la latencia aadida debido a la administracin de energa y permite al host mitigar el rendimiento que resulta de la gestin de energa en el enlace. 2.4.5. Transferencias de Control El propsito y las caractersticas de las transferencias de control son idnticas a los definidos en la seccin 5.5 de la Especificacin del USB, Revisin 2.0. El protocolo de capas de esta especificacin describe los detalles de los paquetes, transacciones de bus, y transacciones de secuencias usadas para lograr las transferencias de control. El captulo de las estructuras del dispositivo de esta especificacin define por completo los cdigos empleados por el estndar para este tipo de dispositivos. Cada dispositivo requiere implementar por defecto mensajes y control para los pipes. El pipe es entendido como la inicializacin y gestin para los dispositivos. El pipe es usado para acceder a las descripciones de los dispositivos y hacer solicitaciones de los comportamientos de los dispositivos (para los dispositivos a nivel). El control de transferencias debera cumplir algunas de las definiciones establecidas por las Especificaciones del USB, Revisin 2.0. El sistema SS har el mejor esfuerzo para soportar la entrega y control de transferencias entre el host y el dispositivo. Como el USB2.0, una funcin y el cliente del software no requieren especificaciones de ancho de banda para estos controles de transferencias. 2.4.5.1. Transferencia deControl. Tamao del Paquete de datos El control de los endpoints tienen establecido una transferencia de carga til de 512 bytes y tienen un mximo de tamao burst para cada uno. Este mximo es aplicado para todas las transacciones de datos durante las fases y control de datos. Para mas detalles en la seccin 8.12.2 se hace referencia a la configuracin y estado de control en las transferencias en SS. Un dispositivo SS debera informar del valor 09H en el Tamao mximo del paquete en el campo del dispositivo descriptor. Las reglas de decodificacin mximas por defecto para el Control por Defecto del Pipe, se dan en la seccin 9.6.1. El control por defecto del Pipie debe soportar una secuencia de valor mximo de 32. (es decir secuencia de valores que son usados en el rango [0-31]). Los requerimientos para la entrega y conclusin de los datos del dispositivo al host y del host al dispositivo son etapas de datos que 24
generalmente no cambian entre el USB2.0 y SS (podemos verlo en la seccin 5.5.3. de la Revisin 2.0, de la especificacin del USB). 2.4.5.2. Transferencias por Control. Requerimientos del Ancho de Banda Un dispositivo no tiene forma de indicar el ancho de banda necesitado para el control del pipe. Un host equilibra al bus de los requisitos de acceso y control requeridos adems de las transacciones pendientes en los pipes para proporcionar un mejor esfuerzo de entrega entre el cliente del software y la funcin del dispositivo. Esta poltica es igual que en el USB2.0. SS requiere que el ancho de banda del bus sea reservado para ser disponible de usar por el control de transferencias como las que siguen: - Las transacciones de una transferencia de control se puede programar para hacerlas coincidir con las transacciones de otros endpoint para cualquier tipo de transferencia. - Los reintentos en las transferencias de control no tienen prioridad sobre los esfuerzos de transacciones. - Si hay transferencias bulk y por control se esperarn pos mltiples endpoints, para transferir y seleccionar los servicios acordados por el dispositivo, para tener un acceso justo a la poltica del host que es controlado por implementaciones dependientes. - Cuando el endpoint de control enva un evento de control de flujo (como se define en la seccin 8.10.1), el host eliminar el endpoints programados. El host reanuda la transferencia para el endpoint tras recibir la notificacin desde el dispositivo. Este requerimiento permite controlar las transferencias entre el host y un dispositivo para regular el movimiento de datos a travs del bus SS con mejor esfuerzo. El comportamiento discreto del software queda definido en la Seccin 5.5.4. en las Especificaciones del USB, en su Revisin 2.0 y es aplicado igualmente para el control de las transferencias para SS.
2.4.5.3.
Transferencias por Control. Secuencias de datos SS conserva el formato del mensaje y la secuencia general de fase de las transferencias de control definidos en la Seccin 5.5.5. de la especificacin del USB, Revisin 2.0. El protocolo del SS define algunos cambios en la Instalacin y en los estados de las etapas de control de transferencias. Sin embargo, todos los requerimientos de secuencias para los escenarios normales y recuperaciones de error quedan definidos y directamente asignados en la Seccin 5.5.5. de la especificacin del USB, Rev.2.0 para el protocolo del SS. 25
2.4.6. Transferencias por Bloques El propsito y las caractersticas de las transferencias por bloques (Bulk), son similares a los definidos en la Seccin 5.8 de la Especificacin del USB, Rev.2.0, Seccin 8.12.1. en esta especificacin se describe con detalles los paquetes, transiciones del bus y transiciones de las secuencias usadas para lograr las transferencias de los Bulk. La transferencia tipo Bulk es destinada a apoyar a los dispositivos que quieren comunicarse con grandes cantidades de datos y de forma variable en el tiempo, la transferencia podr emplear cualquier ancho de banda disponible. Los endpoints de los bulk disponen las siguientes funciones: - Acceso para el bus SS en un ancho de banda de base disponible. - Garantiza la entrega de datos, pero no garantiza la latencia del ancho de banda del SS el cual conserva las siguientes caractersticas de los bulk pipes: - Ninguna estructura de contenido de datos se impone en el flujo de comunicacin para los bulk pipes. - Un bloque de pipes est formado por un flujo de pipe y, por lo tanto, siempre tiene flujo de comunicaciones ya sea dentro o fuera del host para cualquier instancia de pipe. Si en una aplicacin se requiere un flujo de bloques bi-direccionales, dos bloques de pipes deberan ser usados (una entrada y una salida). El estndar USB proporciona la capacidad de mover el flujo de datos de los bulk pipes. SS aade el concepto de Streams que dan soporte a nivel de protocolo para un modelo multi-stream. 2.4.6.1. Transferencias por Bloques. Tamao del paquete de datos Un endpoint en las transferencias a bulk tienen establecidos un tamao para la carga til de 1024 bytes. Tambin se especifica el tamao del bloque que el endpoint puede aceptar desde la transmisin al bus SS. El tamao del bloque para un endpoint deber estar en el rango del 1 al 16. Todos los endpoints de paquetes SS apoyarn valores comprendidos en el rango [0-31]. Un host requiere un soporte para cualquier paquete de endpoint SS. El host es compatible con todos los tamaos de los bulk. El host se asegura de que no hay carga til de ningn paquete de datos en las transacciones que son enviados para los endpoints que son mayores que el tamao mximo de los paquetes. Adicionalmente, esto no envan ms paquete que los que son informados por el peso mximo de los burst. Una funcin del endpoint bulk siempre son transmitidos por cargas tiles con campos de datos menores o iguales a 1024 bytes. Si la transferencia de los paquetes tienen ms datos que estos, todos las transacciones de cargas de bloques requerirn una longitud de 1024 26
bytes en longitud excepto para los ltimos datos transmitidos por bloques, que puede contener los datos restantes. Una transferencia masiva puede abarcar varias transacciones en el bus. Una transferencia de bloques se completa cuando: - Se transfieren todos los datos esperados. - Se transfieren paquetes de datos con carga til menor a 1024 bytes. - Se obtiene una respuesta con STALL handshake. 2.4.6.2. Transferencias por Bloques. Requerimientos del Ancho de Banda Como con USB 2.0 una funcin de bloque endpoint no tiene un modo para indicar un ancho de banda deseado. Las transacciones de los bloques en SS se producen en el bus con ancho de banda disponible. SS establece un buen esfuerzo en la entrega de los bloques de datos entre el cliente de software y funciones del dispositivo. El movimiento de las transferencias de control sobre el bus SS tiene prioridad sobre el movimiento de las transacciones de los bloques. Cuando hay transferencias de bloques pendientes para mltiples endpoints, el host proporciona oportunidades de transaccin para los endpoints individuales de acuerdo a una poltica de acceso equitativa, siendo el host implementado de forma dependiente. Todas las transferencias pendientes en un sistema compiten por el mismo tiempo. Un endpoint y el cliente del software no pueden asumir la velocidad de servicio para transferencia de bloques. El tiempo en el que el bus est disponible para un cliente de software y estos endpoint pueden ser cambiado como otros dispositivos insertando o eliminndolo del sistema o como si se solicitara las transferencias de bloques para otros criterios de valoracin. El software del cliente no puede asumir la ordenacin entre los paquetes de bloques y control de transferencias; es decir, en algunas situaciones, los bloques de transferencias pueden ser entregados por delante de las transferencias de control. El host puede utilizar cualquier tamao de burst entre 1 y el mximo reportado en transacciones con bloques por los endpoint con mas eficacia el ancho de banda disponible, por lo que el host puede emplear una poltica de uso de pequeas burst de datos por transacciones para ofrecer un servicio justo a todos los flujos de datos bulk pendientes. Por ejemplo, pueden haber ms transferencias que el ancho de banda disponible, por eso un host puede emplear una poltica de uso de pequeos bloques de datos para las transacciones pendientes de flujos de datos en bloques. Cuando un endpoint de bloque entrega un flujo de eventos de control (como se define en la Seccin 8.10.1), el host deber eliminar los endpoints programados. El host reanudar la transferencia para los endpoint tras la recepcin del dispositivo. 27
2.4.6.3.
Transferencias por Bloques. Secuencias de datos Las transacciones por bloques usan el estndar secuencial de bloques para una entrega de datos fiables, que estn definidos en la Seccin 8.10.2. Los bulk endpoints son inicializados en una transmisin inicial o al recibir el nmero de secuencia y tamao del bloque (consultar la Seccin 8.12.1.2 y la Seccin 8.12.1.3) mediante una transferencia de control adecuado (SetConfiguration, SetInterface, ClearEndPointFeature). Del mismo modo un host asume la secuencia inicial de transmisin o recepcin de nmeros y el tamao de burst para los pipes despus de que tenga xito completando el control de transferencia como se mencion anteriormente. La interrupcin de condiciones para un SS del bulk pipe tiene un efecto definido por el endpoint bulk del UB2.0. La recuperacin de las condiciones de interrupciones son idnticas para el USB2.0 (consultar la Seccin 5.8.5. de la Revisin 2.0 del USB). La condicin de las interrupciones del bulk pipe incluyen una respuesta de handshake STALL a una transaccin o agotamiento de las transaccin del host, por reintentos de la poltica debido a errores de transmisin. Flujo por bloques (Bulk Streams) El estndar de USB Bulk Pipe representa la habilidad para mover el stream simple de (FIFO) datos entre el host y a travs de un dispositivo de buffer de memoria que utiliza la comunicacin de flujo por pipes (revisar la Seccin 5.3.2 de la Especificacin USB, Rev.2.0). El flujo y gestin entre el host y el dispositivo usan el Protocolo de flujo. A cada flujo se les asigna un identificador Stream ID (SID). Los flujos son dirigidos entre el host y el dispositivos usando el protocolo de flujo. A cada Flujo se le asigna un identificador. El protocolo define un handshake, que permite al dispositivo o host establecer flujos de corriente con identificadores asociados a cada endpoint. El host emplea el CStream ID para seleccionar el comando de operacin u operacin especfica para los buffer del endpoint que debern usar subsecuencias de datos transferidos a travs del pipe. El dispositivo Usa el CStream ID para seleccionar las funciones de buffers de datos que sern usados.
2.4.6.4.
28
Por ejemplo la Figura 4-3 representa una entrada pipe por bloques, donde un nmero elevado de flujos han sido establecidos. Los cuales estn asociados cada Flujo a la memoria del host con uno o ms Buffer Endpoint que reciben los datos. En los dispositivos, hay Funciones de Datos especficas que han de transmitirse al host. Cuando el dispositivo tiene disponible datos para emitir un flujo especfico (Por ejemplo G), estos emiten un ERDY etiquetado con el ID CStream y el host comienza a emitir Entradas ACK TP para el dispositivo que esta etiquetado con CStream ID. El dispositivo responder devolviendo un DPs que contine la funcin de datos asociados con el CStream ID que son tabien etiquetados con el CStream ID. Cuando el host recibe el dato, este usa el CStream para seleccionar el ajuste de los Buffers Endpoint que recibir el dato. Cuando los datos de la funcin se agotan, el dispositivo acaba el flujo (referirse a la Seccin 8.12.1.4). El host tambin permite acabar el flujo si se queda sin espacio de buffer. El flujo debera ser usado, por ejemplo, para soportar las rdenes de transferencias de datos de entrada requeridos para el almacenamiento masivo de comandos de los dispositivos que permanecen en cola. Un bloque endpoint estndar fija los Buffers Endpoint asociados con el. El flujo amplia el nmero de host buffers accesibles por un endpoint desde 1 hasta los 65533. Con asignaciones asignadas de 1:1 entre el host buffer y un Stream ID. Las clases de dispositivos emplean mtodos que se usan para coordinar el Stream IDs, que son usados por el host para seleccionar los Buffers Endpoint y el dispositivo seleccionado en funcin de los datos asociados a un flujo en particular. Normalmente esto se realiza a travs de un mecanismo fuera de banda (por ejemplo, otro endpoint) que es usado para pasar la lista de ID vlida de flujo entre el host y el dispositivo. La seleccin de secuencias de flujos se inicializan por el host o por el dispositivo y, en otro caso, el Protocolo de Flujo proporciona un 29
mtodo de seleccin para rechazarlo. Por ejemplo, el host podr rechazar una seleccin de flujos iniciadas por el dispositivo si no tiene Buffers Endpoint disponibles para este. O el dispositivo puede rechazar una seleccin de flujos iniciadas por el host si no tiene datos de funciones disponibles para ello. Las clases de dispositivos definen cuando un flujo debe ser seleccionado por el host o por l dispositivo, y las acciones que se tomarn cuando el flujo es rechazado (referido en la Seccin 8.12.1.4). Una combinacin de vendor y clases de dispositivos definen algoritmos que determinan como se programa el flujo de un dispositivo. El protocolo de flujo proporciona mtodos para empezar, parar, y interrumpir el flujo (referidos en la Seccin 8.12.1.4). Los mecanismos definidos por el Protocolo de flujos permiten al dispositivo o el host controlar el flujo de corrientes. El host tambin puede iniciar o detener el flujo. Cuando el host controla las condiciones del dispositivo, este puede cambiar el flujo o esperar y continuar la misma secuencia cuando el host reciba ms buffers. El protocolo de flujo tambin proporciona un mecanismo que permite al host informar de forma asncrona al dispositivo cuando se han aadido pipes. Esto es til en los casos en los que el host debe terminar la secuencia porque sino se queda sin Buffers Endpoint; sin embargo el dispositivo an tiene mas funciones de transferencias de datos. Sin este mecanismo, el dispositivo tendra que intentar de forma peridica iniciar el flujo (afectando la administracin de energa), o una larga latencia fuera del mtodo necesario. Los flujos son ejecutados desde standard bulk pipe, un error se detendr el pipe, interrumpiendo la actividad. La eliminacin de la condicin de parada se logra a travs de un software independiente de control del pipe ya que es como un estndar bulk pipe. Finalmente, los flujos incrementan significativamente de un bloque endpoint, mientras tienen un mnimo impacto en el hardware adicional requerido para soportar la funcin de hosts y dispositivos. 2.4.7. Transferencias por Interrupciones El propsito y las caractersticas de las transferencias por interrupciones son similares a las definidas en el USB2.0 (ver la Seccin 5.7 de la Especificacin USB, Rev.2.0). Las interrupciones de los tipos de transferencias SS son destinados para soportar dispositivos que requieren altos mtodos de confiabilidad para comunicar pequeas cantidades de datos con limitados intervalos de servicio. El captulo del protocolo de capas de esta especificacin describe los detalles de los paquetes, transacciones de bus y transacciones de secuencias usadas para lograr las transferencias por interrupciones. Las transferencias por interrupciones proporcionan las siguientes caractersticas: - Garantizan un mximo servicio integral. 30
- Garantizan reintentos de transferencias para distintos intervalos de servicio. Las transferencias por interrupcin se intentan cada intervalo de servicio para un endpoint. El ancho de banda reservado garantiza una transferencia de cada intervalo. Una vez que una transferencia es exitosa, no se realiza otro intento de transferencia hasta el prximo servicio. Si el endpoint responde con una notificacin de no estar listo no podr aceptar mas paquetes, el host no intentar otra transferencia hasta ese endpoint, hasta que no reciba el aviso de listo/preparado. El host debe dar servicio al endpoint (a) dentro del intervalo de servicio, y (b) el dispositivo acarrear el ltimo servicio, despus de dar la notificacin de listo. El intervalo de servicio solicitado al endpoint se describe en el endpoint descriptor. Las pipes de interrupcin tienen las siguientes caractersticas: - Ninguna estructura de datos impone el flujo de comunicacin para las pipes de interrupcin. - Una interrupcin de pipe es un flujo de pipe y, por lo tanto, es siempre unidireccional.
2.4.7.1.
Transferencias por Interrupciones. Tamao del paquete de datos. Una interrupcin de un endpoint especfico tiene una mxima carga til del paquete de datos y este puede ser aceptado o transmitido por el bus del SS. El mximo tamao de la carga til de datos slo ser permisible en endpoints de 1024 bytes para las interrupciones de los endpoints que soporten apoyan un burst de tamao desde 1 a 1024 para un endpoint con tamao de burst igual a uno. El mximo permitido por el tamao de burst para las interrupciones de los endpoints son tres. Todas las interrupciones de endpoints soportan valores en el rango [0-31]. Las interrupciones de los endpoints estn destinadas al traslado de pequeas cantidades de datos con un intervalo de servicio acotado. El protocolo SS no requiere transacciones de interrupciones para tamaos mximos. Se requiere un host para apoyar las interrupciones de los endpoint SS. Un host apoyar toda combinacin de paquetes y tamaos de burst. El host se asegura de que no hay carga til de paquete de datos en las transacciones y se enviarn al endpoint que es mayor que el tamao mximo de los paquetes de endpoints. Tambin, el host no enviar ms paquetes de datos en una transaccin de burst que el tamao mximo de paquetes. Una interrupcin endpoint siempre transmitir carga de datos con campos de datos menores o iguales que el tamao mximo de los paquetes en los endpoints. Si la transferencia de interrupcin tiene ms informacin que la que se ajuste al tamao mximo del paquete 31
para el endpoint, todos los datos de la transaccin de bloques estn obligados a ser de tamao mximo, excepto los ltimos datos de carga til en las transacciones por bloques, en las cuales deberan permanecer los datos restantes. Una transferencia de interrupcin puede abarcar mltiples transacciones de bloques. Una transferencia por interrupcin queda completada cuando uno de los endpoints: - Tiene transferidos la cantidad de paquetes esperados. - Transfiere un paquete de datos con carga til menor al peso mximo del paquete. - Responde con un STALL handshake. 2.4.7.2. Transferencias por interrupciones. Requerimientos del Ancho de Banda. Los Endpoints finales deberan tener asignados un 90% del ancho de banda total disponible en el SS. Un endpoint para una interrupcin especfica esta diseado para dar intervalos de servicio en los descriptores endpoint. Una interrupcin endpoint puede especificar un periodo de diseo de 2(bIntevalo-1)125 s, cuando el intervalo est comprendido en el rango de 1 (incluido) hasta 16. El sistema de software USB debe usar esta informacin para determinar un periodo que puede ser sostenido. El periodo previsto por el sistema puede ser menor que lo esperado por el dispositivo hasta el periodo ms corto definido por el SS (125 s que tambin se conoce como un intervalo de bus). Se tendr en cuenta que los errores en el bus pueden prevenir una transaccin por interrupcin si es entregada con xito desde el bus y en consecuencia superar el periodo deseado. Una interrupcin extrema SS puede mover hasta tres paquetes de tamao mximo (3x1024 bytes) por intervalo de servicio. Las transferencias de interrupcin se mueven a travs del USB accediendo a un endpoint con cada intervalo de servicio. Para las interrupciones de endpoints, el host no tiene una forma de determinar si el endpoint es usado como fuente /sincronizacin de datos sin acceder al endpoint y solicitar una transferencia de interrupcin. Si una entrada de Endpoint de interrupcin no tiene datos de transmisiones o interrupciones de salida de endpoint que tengan insuficiente buffer para aceptar los datos cuando acceden por el host, y no responden al control de flujo. Un endpoint debera proporcionar solo interrupciones de datos cuando son interrupciones pendientes para evitar tener un cliente de software errneo notificado de una transferencia finalizada. Una carga de datos de longitud cero es una carga til y vlida solo para algunas implementaciones. El host puede acceder a un endpoint en cualquier momento durante el intervalo de servicio. La interrupcin del endpoint 32
no debe suponer una separacin fija entre intentos de transacciones. La interrupcin endpoint solo puede tomar transacciones dentro del intervalo de servicio vinculado. Los errores pueden impedir que el xito del intercambio de datos dentro del intervalo de servicio asociado se realice y un host no est obligado a realizar la misma operacin con los mismos intervalos y solo es requerido para volver a intentar la operacin en el siguiente intervalo de servicio. 2.4.7.3. Transferencias por Interrupciones. Secuencias de datos Las operaciones de interrupcin utilizan la secuencia de bloques para una entrega de datos fiables definidos por un protocolo fiable en la Seccin 8.10.2. Las interrupciones de los endpoints son inicializadas para una transferencia inicial o recibe nmeros y tamaos de bloques (referido en la Seccin 8.12.4.1. y Seccin 8.12.4.2.) por una transferencia de control apropiada (SetConfiguration, SetInterface, ClearEndpointFeature). Un host establece la transmisin inicial o recibe secuencias y tamaos de rfagas para interrupciones de pipes despus de haber completado con xito la transferencia de control apropiada. Las condiciones para deterner una interrupcin SS tienen los efectos secundarios idnticos a los definidos para una interrupcin de endpoint del USB 2.0. La recuperacin de las condiciones de detencin son idnticas a las del USB2.0, referidas en la Seccin 5.7.5. en las Especificaciones del USB, Rev. 2.0. Una interrupcin para detener las condiciones del pipe son incluidas en STALL handshake que responden a las transacciones o agotamiento del host tras reintentos de la poltica debida a los errores de transmisin.
33

Esp - Usb3.0 by Jigc

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Esp - Usb3.0 by Jigc

Hochgeladen von

Copyright:

Verfügbare Formate

ESPECIFICACIONES USB 3.

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

1.1. Descripcin del sistema USB 3.0

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

1.1.1. Interfaz fsica del USB 3.0

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

Caractersticas Velocidad de datos

SuperSpeed USB 5.0 Gbps

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

Sealizacin diferencial Half-duplex de forma unidireccional (no simultaneas)

Dos: para la ruta de datos con velocidades Baja/Completa /Alta.

Protocolo para transacciones del bus

Host dirigido, el flujo asncrono, el trfico de paquetes de datos se encaminan directamente

Nivel de los puertos con dos niveles latentes de entrada / salida.

Energa del Bus

Estado del puerto

Tipos de transferencias de datos

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes

I.T.I. especialidad Electricidad & Electrnica Industrial

Juan Isidoro Garca Cifuentes