I3C (bus)

El diseño inicial de I3C buscaba mejorar I²C de las siguientes maneras: ^{[ 21 ]}

• Interfaz de dos pines que es un superconjunto del estándar I²C. Los dispositivos I²C antiguos se pueden conectar al bus más reciente.
• Diseño de bajo consumo y que ahorra espacio, pensado para dispositivos móviles (teléfonos inteligentes y dispositivos IoT ).
• Interrupciones en banda a través del bus serie en lugar de requerir pines separados. En I²C, las interrupciones de los dispositivos periféricos normalmente requieren un pin adicional no compartido por encapsulado.
• Rendimiento de velocidad de datos única (SDR) de entre 10 y 12,5 Mbit/s utilizando niveles de E/S CMOS.
• Los modos de alta velocidad de datos (HDR) permiten múltiples bits por ciclo de reloj. Estos admiten un rendimiento comparable al de SPI , pero requieren solo una fracción de la potencia del modo rápido de I²C. ^{[ 22 ]}
• Un conjunto estandarizado de códigos de comando comunes
• Soporte para cola de comandos
• Detección y recuperación de errores (verificación de paridad en modo SDR y CRC  de 5 bits para modos HDR)
• Asignación dinámica de direcciones (DAA) para destinos I3C, manteniendo la compatibilidad con direcciones estáticas para dispositivos I²C heredados.
• El tráfico I3C es invisible para los dispositivos I²C heredados cuando están equipados con filtros de picos I²C, lo que se logra mediante tiempos SCL HIGH inferiores a 50  ns.
• Conexión en caliente (algunos dispositivos en el bus pueden encenderse/apagarse durante el funcionamiento).
• Operación con múltiples controladores y un protocolo bien definido para la transferencia entre ellos.

 Tras hacer público el estándar I3C 1.0, la organización publicó posteriormente la especificación I3C Basic, un subconjunto destinado a ser implementado por organizaciones no miembros bajo una licencia RAND-Z . I3C Basic permite la implementación gratuita de I3C y está dirigido a organizaciones que puedan considerar la pertenencia a MIPI como una barrera para su adopción. La versión básica incluye muchas de las innovaciones de protocolo de I3C  1.0, pero carece de algunas de las potencialmente más difíciles de implementar, como los modos opcionales de alta velocidad de datos (HDR) como DDR. No obstante, el modo SDR predeterminado de hasta 12,5 Mbit/s supone una mejora importante en velocidad y capacidad con respecto a I²C. ^{[ 23 ]}

Esta especificación, publicada en diciembre de 2019, solo está disponible para los miembros de MIPI.

Publicada en junio de 2021, esta normativa ha dejado de utilizar los términos "maestro/esclavo" y ahora emplea los términos normativos actualizados "controlador/objetivo". Las definiciones técnicas de dichos dispositivos y sus funciones en un bus I3C permanecen sin cambios.

I3C utiliza los mismos dos pines de señal que I²C, denominados SCL (reloj serie) y SDA (datos serie). La principal diferencia radica en que I²C los opera como salidas de drenaje abierto en todo momento, por lo que su velocidad se ve limitada por el consiguiente tiempo de subida lento de la señal . I3C utiliza el modo de drenaje abierto cuando es necesario para la compatibilidad, pero cambia a salidas push-pull siempre que sea posible e incluye modificaciones en el protocolo para que esto sea posible con mayor frecuencia que en I²C.

• SCL es una señal de reloj digital convencional , controlada con una salida push-pull por el controlador de bus actual durante las transferencias de datos. ( El estiramiento de reloj , ^{[ 24 ]} una característica de I²C poco utilizada ^{[ 25 ]} , no es compatible). En transacciones que involucran dispositivos de destino I²C, esta señal de reloj generalmente tiene un ciclo de trabajo de aproximadamente el 50%, pero al comunicarse con destinos I3C conocidos, el controlador de bus puede cambiar a una frecuencia más alta y/o alterar el ciclo de trabajo para que el período alto de SCL se limite a un máximo de 40  ns.
• La señal SDA transporta el flujo de datos en serie, que puede ser controlado tanto por el controlador como por el dispositivo de destino, pero a una velocidad determinada por la señal SCL del controlador. Para garantizar la compatibilidad con el protocolo I²C, cada transacción comienza con la señal SDA funcionando como una salida de drenaje abierto, lo que limita la velocidad de transmisión. Para los mensajes dirigidos a un dispositivo I²C, el controlador SDA cambia a modo push-pull tras los primeros bits de la transacción, lo que permite aumentar la frecuencia del reloj hasta 12,5  MHz. Esta función de velocidad media se denomina modo de velocidad de datos única (SDR).

Generalmente, SDA se modifica justo después del flanco descendente de SCL, y el valor resultante se recibe en el siguiente flanco ascendente. Cuando el controlador transfiere SDA al dispositivo de destino, también lo hace en el flanco descendente de SCL. Sin embargo, cuando un dispositivo de destino I3C devuelve el control de SDA al controlador (por ejemplo, después de confirmar su dirección antes de una escritura), libera SDA en el flanco ascendente de SCL, y el controlador es responsable de mantener el valor recibido (reiniciando una copia del bit del dispositivo de destino) mientras SCL permanece en estado alto. Dado que el controlador gestiona SCL, verá primero el flanco ascendente, por lo que habrá un breve período de solapamiento cuando ambos gestionen SDA, pero como ambos gestionan el mismo valor, no se produce contención en el bus .

Todas las comunicaciones en I²C e I³C requieren tramas para su sincronización. Dentro de una trama, los cambios en la línea SDA siempre deben ocurrir mientras SCL se encuentra en estado bajo, de modo que SDA pueda considerarse estable durante la transición de bajo a alto de SCL. Las violaciones de esta regla general se utilizan para la generación de tramas (al menos en los modos de velocidad de datos estándar y heredados).

Entre tramas de datos, el controlador del bus mantiene SCL en estado alto, deteniendo así el reloj, y los controladores SDA se encuentran en un estado de alta impedancia, lo que permite que una resistencia de polarización los eleve a un nivel alto. Una transición de alto a bajo en SDA mientras SCL está en estado alto se conoce como símbolo de INICIO e indica el comienzo de una nueva trama de datos. Una transición de bajo a alto en SDA mientras SCL está en estado alto es el símbolo de PARADA, que finaliza una trama de datos.

Un STOP sin un STOP previo, denominado "START repetido", puede utilizarse para finalizar un mensaje y comenzar otro dentro de una misma transacción de bus.

En I²C, el símbolo START suele ser generado por un controlador de bus, pero en I3C, incluso los dispositivos de destino pueden poner SDA en nivel bajo para indicar que desean iniciar una trama. Esto se utiliza para implementar algunas funciones avanzadas de I3C, como interrupciones en banda, compatibilidad con múltiples controladores y conexiones en caliente. Tras el inicio, el controlador de bus reinicia el reloj activando SCL e inicia el proceso de arbitraje del bus.

Al inicio de una trama, varios dispositivos pueden competir por el uso del bus, y el proceso de arbitraje del bus sirve para seleccionar qué dispositivo obtiene el control de la línea SDA. Tanto en I²C como en I³C, el arbitraje del bus se realiza con la línea SDA en modo de drenaje abierto, lo que permite que los dispositivos que transmiten un 0 binario (bajo) tengan prioridad sobre los que transmiten un 1 binario. Los dispositivos que compiten supervisan la línea SDA mientras la controlan en modo de drenaje abierto. Cuando un dispositivo detecta un estado bajo (  bit 0) en la línea SDA mientras transmite un estado alto (  bit 1), pierde el arbitraje y debe dejar de competir hasta que comience la siguiente transacción.

Cada transacción comienza con la dirección de destino, y la implementación da prioridad a las direcciones de destino con números más bajos. La diferencia radica en que I²C no tiene límite en la duración del arbitraje (en la rara pero legal situación de que varios dispositivos compitan por enviar un mensaje al mismo dispositivo, la contención no se detectará hasta después del byte de dirección). Sin embargo, I³C garantiza que el arbitraje se completará antes de que finalice el primer byte. Esto permite utilizar controladores push-pull y frecuencias de reloj más rápidas en la gran mayoría de los casos.

Esto se hace de varias maneras:

• I3C admite varios controladores, pero no son simétricos; uno es el controlador actual y se encarga de generar el reloj. Otros dispositivos que envían un mensaje en el bus (interrupciones en banda o controladores secundarios que desean usar el bus) deben utilizar su propia dirección antes de enviar cualquier otro dato. Por lo tanto, no existen dos mensajes válidos en el bus que compartan el primer byte, salvo que el controlador y otro dispositivo se comuniquen simultáneamente.
• I3C, al igual que I²C, permite múltiples mensajes por transacción separados por símbolos de "INICIO repetido". El arbitraje se realiza por transacción, por lo que estos mensajes subsiguientes nunca están sujetos a arbitraje.
• La mayoría de las transacciones del controlador I3C comienzan con la dirección reservada 0x7E(1111110 ₂ ). Como esta tiene una prioridad menor que cualquier dispositivo I3C, una vez que ha pasado el arbitraje, el controlador sabe que ningún otro dispositivo está compitiendo por el bus.
• Como caso especial, si a los dispositivos I3C se les asignan direcciones bajas (I3C admite la asignación dinámica de direcciones controlada por el controlador), entonces tan pronto como la 0x7Edirección haya ganado la arbitraje para suficientes bits iniciales para distinguirla de cualquier dirección asignada, el controlador sabe que la arbitraje ha finalizado y puede cambiar a la operación push-pull en SDA. Si todas las direcciones asignadas son menores que 0x40, esto es después del primer bit. Si todas las direcciones son menores que 0x60, esto es después del segundo bit, y así sucesivamente.
• En el caso descrito anteriormente, donde el controlador actual inicia una transacción con la dirección de un dispositivo que también está compitiendo por el uso del bus, ambos transmitirán sus bytes de dirección correctamente. Sin embargo, cada uno esperará que el otro confirme la dirección (poniendo SDA en nivel bajo) para el siguiente bit de confirmación. En consecuencia, ninguno lo hará, y ambos observarán la falta de confirmación. En este caso, el mensaje no se envía, pero el controlador gana la arbitraje: puede enviar un inicio repetido, seguido de un reintento que será exitoso.

Una escritura dirigida a la dirección reservada 0x7Ese utiliza para realizar varias operaciones especiales en I3C. Todos los dispositivos I3C deben recibir e interpretar las escrituras dirigidas a esta dirección, además de las dirigidas a sus direcciones individuales.

En primer lugar, una escritura que consiste únicamente en el byte de dirección y sin bytes de datos no afecta a los destinos I3C, pero puede utilizarse para simplificar la arbitraje I3C. Como se describió anteriormente, este prefijo puede acelerar la arbitraje (si el controlador admite la optimización de cambiar a byte intermedio push-pull) y simplifica el controlador al evitar un caso de arbitraje algo complejo.

Si a la escritura le sigue un byte de datos, este codifica un "código de comando común", una operación I3C estandarizada. Los códigos de comando son comandos de difusión dirigidos a todos los destinos I3C. Pueden ir seguidos de parámetros adicionales específicos del comando. Los códigos de comando son comandos directos dirigidos a destinos individuales. Estos van seguidos de una serie de comandos START repetidos y escrituras o lecturas en destinos específicos.0–0x7F0x80–0xFE

Mientras un comando directo está en vigor, las escrituras o lecturas por destino transmiten parámetros específicos del comando. Esta operación sustituye la respuesta normal del destino a un mensaje I3C. Un comando directo puede ir seguido de varios mensajes por destino, cada uno precedido por un START repetido. Este modo especial finaliza al término de la transacción (símbolo STOP) o con el siguiente mensaje dirigido a 0x7E.

Algunos códigos de comando existen tanto en formato de difusión como directo. Por ejemplo, los comandos para habilitar o deshabilitar interrupciones en banda pueden enviarse a dispositivos individuales o difundirse a todos. Los comandos para obtener parámetros de un dispositivo (por ejemplo, el comando GETHDRCAP para preguntarle qué modos de alta velocidad de datos admite) solo existen en formato directo.

El modo HDR-DDR utiliza señalización de doble velocidad de datos en la línea SDA con un  reloj de 12,5 MHz para lograr una velocidad de datos bruta de 25 Mbit/s ( 20 Mbit/s efectivos). Esto requiere cambiar la línea SDA mientras SCK está en alto, lo que constituye una violación del protocolo I²C, pero como el pulso ascendente solo  dura 40 ns, los dispositivos I²C lo ignorarán y, por lo tanto, no detectarán la violación.

HDR-DDR acompaña cada palabra de datos de 16 bits con un preámbulo de 2 bits y un postámbulo de paridad impar de 2 bits , lo que da un total de 20 bits. Cada palabra comienza con un flanco ascendente en SCK. El preámbulo tiene tres estados posibles:

• 01: A continuación se muestra la palabra de comando (antes de los datos) o la palabra CRC (después de los datos).
• 10: A continuación, se muestra la primera palabra de datos. Si se detecta posteriormente, el controlador abortará la operación.
• 11: A continuación, se muestra la siguiente palabra de datos. NACK por parte del objetivo si se encuentra inicialmente.

Si un controlador ve un preámbulo de "11" inmediatamente después de un comando, esto indica que ningún objetivo responde y se trata como un NACK en modo SDR. Para garantizar que la línea SDA se vea en estado alto si ningún objetivo responde, el bit adicional en la palabra de comando y dirección se configura de manera que el último bit de paridad enviado por el controlador sea 1.

Para las palabras subsiguientes durante las operaciones de lectura (del dispositivo de destino al controlador), el dispositivo de destino activa el primer bit del preámbulo, pero libera el bus (lo que permite que las resistencias pull-up mantengan SDA en alto) para el segundo bit. El controlador puede activar SDA en bajo durante el tiempo del segundo bit (el flanco descendente de SCL) para solicitar que se aborte la lectura.

Si no se aborta, un mensaje finaliza con una palabra CRC de 13 bits. Esta tiene un preámbulo de 01, un patrón fijo de 1100 (otros patrones están reservados para uso futuro), luego una comprobación de redundancia cíclica de 5 bits sobre el mensaje completo (incluida la palabra de comando/dirección, pero no el preámbulo ni los bits de paridad, ni ninguna parte de la palabra CRC), y dos bits "1" (el primero activado, el segundo mantenido pasivamente en alto para que el controlador pueda tomar el control). Esto deja el bus con SCK y SDA en alto, después de lo cual el controlador debe generar un reinicio HDR o salir.

Los modos HDR-TSP y HDR-TSL utilizan uno de tres símbolos como dígitos ternarios (trits):

Dos bytes más dos bits de paridad par (18 bits en total) se dividen en seis tríos de 3 bits, y cada trío se codifica como dos trits. (Los 3 bits se toman comenzando por el bit más significativo para producir un valor de 0 a 7, que luego se convierte en dos trits usando los valores numéricos de la lista anterior, y se envía primero el trit más significativo). Enviado a 25 Mtrit/s , esto logra una tasa de datos efectiva de 33,3 Mbit/s .

El par trit 22, que consta de dos transiciones SDA únicamente, no se utiliza para codificar datos, sino para codificar las secuencias de reinicio y salida HDR que finalizan un mensaje. Si bien esto limita el tiempo máximo entre transiciones SCL a tres tiempos trit, excede el  límite de 50 ns para los dispositivos I²C heredados, por lo que el modo HDR-TSP (símbolo ternario puro) solo puede utilizarse en un bus sin dispositivos I²C heredados.

Para permitir buses que incluyan dispositivos I²C (con filtro de picos), se debe usar el modo HDR-TSL (símbolo ternario, heredado). Esto mantiene la compatibilidad con I²C mediante el relleno de trits : después de cualquier flanco ascendente en SCL, si el trit siguiente no  es 0, el emisor inserta un trit 1 (transición solo en SCL), que el receptor ignora. Esto garantiza que SCL nunca esté en alto durante más de un tiempo de trit, pero a costa de transmitir 2,67  trits por cada 3  bits de carga útil, una tasa de datos efectiva de 25 Mbit/s (suponiendo datos aleatorios).

En el modo de símbolo ternario, el controlador finaliza una orden de lectura dejando las líneas SDA y SCL en estado alto, tras lo cual el dispositivo de destino las activa a la velocidad que desee. El controlador no puede interrumpir la operación de lectura; si no confía en que el dispositivo de destino se detenga a tiempo, debe elegir un modo de transmisión diferente. Una vez finalizada la transmisión, el dispositivo de destino devuelve el bus al controlador de la siguiente manera:

• El objetivo establece SDA en alto y SCL en bajo. Si el bus no se encontraba ya en este estado, el controlador interpretará la transición como un trit, pero la ignorará ya que no forma parte de un grupo de 12 trits.
• El objetivo conmuta SDA tres veces (trit 2), dejando tanto SDA como SCL en estado bajo, y luego libera (deja de controlar) el bus dentro de un tiempo de trit (medio ciclo de reloj).
• En cuanto el controlador detecta el tercer flanco solo de SDA, toma el control y pone SDA y SCL en bajo. Tras al menos un tiempo trit (medio ciclo de reloj), pone SDA en alto y continúa completando, según lo desee, un reinicio de HDR (poniendo SCL en alto) o una salida de HDR (alternando SDA tres veces más y luego poniendo SCL en alto).

Tenga en cuenta que el modo de datos ternario no incluye un CRC.