MIPI I3C (también conocido como SenseWire ) es una especificación [1] para permitir la comunicación entre chips de computadora mediante la definición de la conexión eléctrica entre los chips y los patrones de señalización que se utilizarán. El estándar define la conexión eléctrica entre los chips como un bus de datos en serie de dos cables, compartido ( multipunto ), un cable ( ) se usa como reloj para definir los tiempos de muestreo, el otro cable ( ) se usa como línea de datos cuyo voltaje se puede muestrear. El estándar define un protocolo de señalización en el que varios chips pueden controlar la comunicación y, por lo tanto, actuar como maestro de bus . SCL
SDA
Tipo | Bus de comunicación serial | ||
---|---|---|---|
Historial de producción | |||
Diseñador | Grupo de trabajo de sensores de MIPI Alliance | ||
Diseñado | 2016 | ||
Conectable en caliente | cierto | ||
Eléctrico | |||
Señal | CMOS | ||
Datos | |||
Señal de datos | Desagüe abierto o Empujar / Tirar | ||
Ancho | 2 cables [datos + reloj] | ||
Bitrate | 12,5 Mbit / s (SDR, estándar), 25 Mbit / s (DDR), 33 Mbit / s (ternario), | ||
Protocolo | Serie , semidúplex |
La especificación I3C toma su nombre, utiliza las mismas conexiones eléctricas y permite cierta compatibilidad con el bus I²C , un estándar de facto para la comunicación entre chips, ampliamente utilizado para periféricos y sensores de baja velocidad en sistemas informáticos. El estándar I3C está diseñado para mantener cierta compatibilidad con el sistema I²C, lo que permite en particular diseños en los que los dispositivos I²C existentes se pueden conectar a un bus I3C pero aún así el bus puede cambiar a una velocidad de datos más alta para la comunicación a velocidades más altas entre I3C compatibles dispositivos. El estándar I3C combina así la ventaja de la arquitectura I²C simple de dos hilos con las velocidades de comunicación más altas comunes a buses más complicados como la Interfaz de Periférico Serial (SPI).
El estándar I3C se desarrolló como un esfuerzo de colaboración entre empresas relacionadas con la electrónica y la informática bajo los auspicios de la Mobile Industry Processor Interface Alliance ( MIPI Alliance ). El estándar I3C se lanzó por primera vez al público a fines de 2017, [2] [3] aunque el acceso requiere la divulgación de información privada. Google e Intel han respaldado I3C como estándar de interfaz de sensor para dispositivos de Internet de las cosas (IoT). [4]
Historia
Los objetivos del esfuerzo del Grupo de trabajo de sensores MIPI se anunciaron por primera vez en noviembre de 2014 en el Congreso Ejecutivo de MEMS en Scottsdale AZ. [5]
Los proveedores de herramientas de automatización de diseño electrónico, incluidos Cadence , [6] Synopsys [7] y Silvaco [8], han lanzado bloques IP de controlador y software de verificación asociado para la implementación del bus I3C en nuevos diseños de circuitos integrados.
En diciembre de 2016, Lattice Semiconductor integró el soporte I3C en su nueva FPGA conocida como iCE40 UltraPlus. [9]
En 2017, Qualcomm anunció el SOC móvil Snapdragon 845 con soporte maestro I3C integrado. [10] [ verificación fallida ]
En diciembre de 2017, la especificación I3C 1.0 se publicó para revisión pública. [4] [11] Aproximadamente al mismo tiempo, Boris Brezillon propuso un parche del kernel de Linux que introducía soporte para I3C. [12]
En junio de 2020, Renesas Electronics presentó los productos I3C. [13]
Metas
Antes de la publicación pública de la especificación, se publicó una cantidad sustancial de información general al respecto en forma de diapositivas de la MIPI DevCon 2016. [14] Los objetivos de esta interfaz se basaron en una encuesta de las organizaciones miembros de MIPI y miembros de MEMS Industry Group (MIG). Los resultados de esta encuesta se han hecho públicos. [15]
I3C V1.0
El diseño inicial de I3C buscaba mejorar el I²C de las siguientes maneras: [16]
- Interfaz de dos pines que es un superconjunto del estándar I²C. Los dispositivos esclavos I²C heredados se pueden conectar al bus más nuevo.
- Diseño de bajo consumo de energía y uso eficiente del espacio destinado a dispositivos móviles (teléfonos inteligentes y dispositivos IoT ).
- En banda se interrumpe a través del bus serie en lugar de requerir pines separados. En I²C, las interrupciones de los dispositivos periféricos generalmente requieren un pin adicional no compartido por paquete.
- Rendimiento de velocidad de datos estándar (SDR) entre 10 y 12,5 Mbit / s utilizando niveles de E / S CMOS.
- Modos de alta velocidad de datos (HDR) que permiten múltiples bits por ciclo de reloj. Estos soportan un rendimiento comparable al SPI mientras que requieren solo una fracción de la potencia del modo rápido I²C. [17]
- Un conjunto estandarizado de códigos de comando comunes
- Soporte de 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 esclavos I3C, sin dejar de admitir direcciones estáticas para dispositivos heredados I²C
- El tráfico I3C es invisible para los dispositivos I²C heredados cuando están equipados con filtros de picos I²C, logrados por tiempos de SCl ALTOS de menos de 50ns
- Hot-join (algunos dispositivos en el bus pueden encenderse / apagarse durante el funcionamiento)
- Operación multimaestro con un protocolo bien definido para la transferencia entre maestros
Especificación básica I3C
Después de hacer que el estándar I3C 1.0 sea accesible al público, 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 . La versión básica incluye muchas de las innovaciones de protocolo en 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 es una mejora importante de velocidad / capacidad con respecto a I²C. [18]
I3C V1.1
Publicada en diciembre de 2019, esta especificación solo está disponible para miembros de MIPI.
Nomenclatura
Pines de señal
I3C utiliza los mismos dos pines de señal que I²C, denominados SCL (reloj en serie) y SDA (datos en serie). La principal diferencia es que I²C las opera como salidas de drenaje abierto en todo momento, por lo que su velocidad está limitada por el tiempo de aumento lento de la señal resultante . I3C usa el modo de drenaje abierto cuando es necesario para la compatibilidad, pero cambia a salidas push-pull siempre que es posible e incluye cambios de protocolo para hacerlo posible con más frecuencia que en I²C.
- SCL es una señal de reloj digital convencional , impulsada con una salida push-pull por el maestro de corriente del bus actual durante las transferencias de datos. (El alargamiento del reloj, una función I²C poco utilizada, no es compatible.) En transacciones que involucran dispositivos esclavos I²C, esta señal de reloj generalmente tiene un ciclo de trabajo , de aproximadamente 50%, pero cuando se comunica con esclavos I3C conocidos, el bus maestro 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.
- SDA transporta el flujo de datos en serie, que puede ser impulsado por maestro o esclavo, pero es impulsado a una velocidad determinada por la señal SCL del maestro. Para compatibilidad con el protocolo I²C, cada transacción comienza con SDA operando como una salida de drenaje abierto, lo que limita la velocidad de transmisión. Para los mensajes dirigidos a un esclavo I3C, el modo de controlador SDA cambia a push-pull después de los primeros bits de la transacción, lo que permite aumentar aún más el reloj hasta 12,5 MHz. Esta función de velocidad media se denomina modo de velocidad de datos estándar (SDR).
Generalmente, SDA se cambia justo después del flanco descendente de SCL, y el valor resultante se recibe en el siguiente flanco ascendente. Cuando el maestro entrega SDA al esclavo, también lo hace en el borde descendente de SCL. Sin embargo, cuando el esclavo devuelve el control de SDA al maestro (por ejemplo, después de reconocer su dirección antes de una escritura), libera SDA en el flanco ascendente de SCL, y el maestro es responsable de mantener el valor recibido durante la duración de SCL elevado. (Debido a que el maestro controla SCL, primero verá el borde ascendente, por lo que habrá un breve período de superposición cuando ambos controlen SDA, pero como ambos controlan el mismo valor, no se produce ninguna contención del bus ).
Enmarcado
Todas las comunicaciones en I²C e I3C requieren entramado para la sincronización. Dentro de una trama, los cambios en la línea SDA siempre deben ocurrir mientras SCL está en el estado bajo, de modo que SDA pueda considerarse estable en la transición de baja a alta de SCL. Las infracciones de esta regla general se utilizan para el encuadre (al menos en los modos de velocidad de datos estándar y heredados).
Entre tramas de datos, el maestro de bus mantiene SCL alto, de hecho, detiene el reloj, y los controladores SDA están en un estado de alta impedancia, lo que permite que una resistencia pull-up lo haga flotar en alto. Una transición de alto a bajo de SDA mientras SCL es alto se conoce como símbolo de INICIO y señala el comienzo de una nueva trama de datos. Una transición de bajo a alto en SDA mientras SCL es alto es el símbolo STOP, que finaliza una trama de datos.
Un INICIO sin una PARADA anterior, llamado "INICIO repetido", puede usarse para finalizar un mensaje y comenzar otro dentro de una sola transacción de bus.
En I²C, el símbolo de INICIO generalmente lo genera un bus maestro, pero en I3C, incluso los dispositivos esclavos pueden reducir el SDA para indicar que desean iniciar una trama. Esto se usa para implementar algunas características avanzadas de I3C, como interrupciones en banda, soporte multimaestro y hot-joins. Después del inicio, el bus maestro reinicia el reloj accionando SCL y comienza el proceso de arbitraje del bus.
Noveno bit
Como I²C, I3C usa 9 ciclos de reloj para enviar cada byte de 8 bits. Sin embargo, el noveno ciclo se usa de manera diferente. I²C utiliza el último ciclo para un acuse de recibo enviado en la dirección opuesta a los primeros 8 bits. I3C opera de la misma manera para el primer byte (dirección) de cada mensaje y para los mensajes compatibles con I²C, pero cuando se comunica con esclavos I3C, los bytes del mensaje después del primer uso, el noveno bit es un bit de paridad impar en las escrituras y un final -of-indicador de datos en lecturas.
Las escrituras solo pueden ser canceladas por el maestro.
Tanto el maestro como el esclavo pueden terminar una lectura. El esclavo establece SDA bajo para indicar que no hay más datos disponibles; el maestro responde asumiendo SDA y generando un STOP o START repetido. Para permitir que la lectura continúe, el esclavo impulsa SDA alto mientras que SCL está bajo antes del noveno bit, pero deja que SDA flote (drenaje abierto) mientras SCL está alto. El maestro puede hacer que el SDA sea bajo (una condición de INICIO repetida) en este momento para abortar la lectura.
Arbitraje de autobús
Al comienzo 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 I3C, el arbitraje de bus se realiza con la línea SDA en modo de drenaje abierto, lo que permite a los dispositivos que transmiten un 0 binario (bajo) anular los dispositivos que transmiten un 1. binario. Los dispositivos rivales monitorean la línea SDA mientras la conducen en abierto. modo de drenaje. Siempre que un dispositivo detecta una condición baja (0 bit) en SDA mientras transmite una alta (1 bit), ha perdido 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 es que I²C no tiene límite sobre la duración del arbitraje (en la situación poco común pero legal de varios dispositivos que compiten por enviar un mensaje al mismo dispositivo, la disputa no se detectará hasta después del byte de dirección). Sin embargo, I3C garantiza que el arbitraje se completará a más tardar al final del primer byte. Esto permite utilizar controladores push-pull y velocidades de reloj más rápidas la gran mayoría de las veces.
Esto se hace de varias formas:
- I3C admite varios maestros, pero no son simétricos; uno es el maestro actual y responsable de generar el reloj. Otros dispositivos que envían un mensaje en el bus (interrupciones en banda o maestros secundarios que deseen utilizar el bus) deben arbitrar utilizando su propia dirección antes de enviar cualquier otro dato. Por lo tanto, no hay dos mensajes de bus legal que compartan el mismo primer byte, excepto si el maestro y otro dispositivo se comunican simultáneamente entre sí.
- I3C, como I²C, permite múltiples mensajes por transacción separados con símbolos de "INICIO repetidos". El arbitraje es por transacción, por lo que estos mensajes posteriores nunca están sujetos a arbitraje.
- La mayoría de las transacciones maestras de I3C comienzan con la dirección reservada
0x7E
(1111110 2 ). Como tiene una prioridad más baja que cualquier dispositivo I3C, una vez que ha pasado el arbitraje, el maestro 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 maestro), tan pronto como la
0x7E
dirección haya ganado el arbitraje por suficientes bits iniciales para distinguirla de cualquier dirección asignada, el maestro sabe que el arbitraje está completo y puede cambiar a la operación push-pull en SDA. Si todas las direcciones asignadas son menores que0x40
, esto es después del primer bit. Si todas las direcciones son menores que0x60
, esto es después del segundo bit, y así sucesivamente. - En el caso descrito anteriormente en el que el maestro actual comienza una transacción con la dirección de un dispositivo que está compitiendo por el uso del bus, ambos transmitirán sus bytes de dirección con éxito. Sin embargo, cada uno esperará que el otro reconozca la dirección (bajando SDA) para el siguiente bit de reconocimiento. En consecuencia, ninguno lo hará, y ambos observarán la falta de reconocimiento. En este caso, el mensaje no se envía, pero el maestro gana el arbitraje: puede enviar un inicio repetido, seguido de un reintento que será exitoso.
Códigos de comando comunes
Una escritura dirigida a la dirección reservada 0x7E
se utiliza para realizar una serie de operaciones especiales en I3C. Todos los dispositivos I3C deben recibir e interpretar escrituras en esta dirección además de sus direcciones individuales.
En primer lugar, una escritura que consta solo del byte de dirección y sin bytes de datos no tiene ningún efecto en los esclavos I3C, pero puede usarse para simplificar el arbitraje I3C. Como se describió anteriormente, este prefijo puede acelerar el arbitraje (si el maestro admite la optimización del cambio a push-pull mid-byte) y simplifica el maestro al evitar un caso de arbitraje ligeramente complicado.
Si la escritura va seguida de un byte de datos, el byte codifica un "código de comando común", una operación I3C estandarizada. Los códigos de comando 0–0x7F
son comandos de transmisión dirigidos a todos los esclavos I3C. Pueden ir seguidos de parámetros adicionales específicos del comando. Los códigos de comando 0x80–0xFE
son comandos directos dirigidos a esclavos individuales. Estos son seguidos por una serie de INICIOS repetidos y escrituras o lecturas en esclavos específicos.
Mientras un comando directo está en efecto, las escrituras o lecturas por esclavo transmiten parámetros específicos del comando. Esta operación reemplaza la respuesta normal del esclavo a un mensaje I3C. Un comando directo puede ir seguido de varios mensajes por esclavo, cada uno precedido por un INICIO repetido. Este modo especial finaliza al finalizar la transacción (símbolo STOP) o al siguiente mensaje dirigido 0x7E
.
Algunos códigos de comando existen tanto en forma de transmisión como directa. Por ejemplo, los comandos para habilitar o deshabilitar las interrupciones en banda pueden enviarse a esclavos individuales o transmitirse a todos. Los comandos para obtener parámetros de un esclavo (por ejemplo, el comando GETHDRCAP para preguntarle a un dispositivo qué modos de alta velocidad de datos admite) solo existen en forma directa.
Clases de dispositivos
En un bus I3C en su modo predeterminado (SDR), se pueden admitir cuatro clases diferentes de dispositivos:
- Maestro principal I3C
- Maestro secundario I3C
- Esclavo I3C
- I²C esclavo (dispositivos heredados)
Opciones de alta velocidad de datos (HDR)
Cada transacción de bus I3C comienza en modo SDR, pero el maestro I3C puede emitir un comando de transmisión CCC "Enter HDR" que le dice a todos los esclavos I3C que la transacción continuará en un modo HDR especificado. Los esclavos I3C que no admiten HDR pueden ignorar el tráfico del bus hasta que vean una secuencia específica de "salida HDR" que les informe que es hora de volver a escuchar el bus. (El maestro sabe qué esclavos admiten HDR, por lo que nunca intentará usar HDR para comunicarse con un esclavo que no lo admita).
Algunos modos HDR también son compatibles con dispositivos I²C si los dispositivos I²C tienen un filtro de picos de 50 ns en la línea SCL; es decir, ignorarán un nivel alto en la línea SCL que dure menos de 50 ns. Esto es requerido por la especificación I²C, pero no implementado universalmente, y no todas las implementaciones ignoran los picos que se repiten con frecuencia, [19] por lo que se debe verificar la compatibilidad con I3C HDR. Los modos HDR compatibles usan pulsos SCL de 45 ns como máximo, de modo que los dispositivos I²C los ignorarán.
El modo HDR-DDR utiliza señalización de velocidad de datos doble con un reloj de 12,5 MHz para lograr una velocidad de datos sin procesar de 25 Mbit / s (20 Mbit / s efectivos). Esto requiere cambiar la línea SDA mientras SCK es alto, una violación del protocolo I²C, pero los dispositivos I²C no verán el breve pulso alto en SCL y, por lo tanto, no notarán la violación.
Los modos HDR-TSP y HDR-TSL utilizan uno de los tres símbolos como dígitos ternarios (trits):
- Una transición de SDA y SCL (recibidos con 12,8 ns entre sí),
- Una transición de SCL solamente, o
- Solo una transición de SDA.
Dos bytes más dos bits de paridad (18 bits en total) se dividen en seis tripletes de 3 bits, y cada triplete se codifica como dos trits. Enviado a 25 Mtrit / s, esto logra una tasa de datos efectiva de 33,3 Mbit / s.
El par trit que consta de dos transiciones de SDA solamente no se usa para codificar datos, sino que se usa para enmarcar, para marcar el final de una secuencia HDR. Aunque esto limita el tiempo máximo entre transiciones SCL a tres tiempos trit, eso excede el límite de 50 ns para dispositivos I²C heredados, por lo que el modo HDR-TSP (símbolo ternario, puro) solo se puede usar en un bus sin dispositivos I²C heredados.
Para permitir buses que incluyan dispositivos I²C (con un filtro de picos), se debe utilizar el modo HDR-TSL (símbolo ternario, heredado). Esto mantiene la compatibilidad I²C mediante el relleno de trit : después de cualquier flanco ascendente en SCL, si el trit siguiente no es 0, el remitente inserta un trit 1 (transición solo en SCL) y el receptor lo ignora. Esto asegura que la SCL nunca sea alta por más de un tiempo.
Funciones I²C no compatibles con I3C
- Las resistencias pull-up las proporciona el maestro I3C. Ya no se necesitan resistencias pull-up externas.
- Alargamiento del reloj: se espera que los dispositivos sean lo suficientemente rápidos para operar a la velocidad del bus. El maestro I3C es la única fuente de reloj.
- Direcciones I²C extendidas (10 bits). Todos los dispositivos de un bus I3C se direccionan mediante una dirección de 7 bits. Los dispositivos I3C nativos tienen una dirección única de 48 bits que se usa solo durante las asignaciones de direcciones dinámicas.
Referencias
- ^ "MIPI I3C y I3C Basic" . mipi.org .
- ^ "MIPI Alliance abre el acceso a su especificación de interfaz de sensor MIPI I3C" .
- ^ "MIPI Alliance lanza la especificación de interfaz de sensor MIPI I3C" . www.evaluationengineering.com .
- ^ a b "MIPI hace que el mercado impulse la interfaz de sensor I3C" . 14 de diciembre de 2017.
- ^ http://www.eetimes.com/document.asp?doc_id=1324598
- ^ http://ip.cadence.com/uploads/1075/Cadence_Brochure_MIPI_I3C_Slave_Controller-pdf
- ^ "IP de verificación de VC para MIPI I3C" . www.synopsys.com .
- ^ "Familia MIPI I3C para aplicaciones de sensores e IoT" (PDF) . silvaco.com .
- ^ "Lattice le da al iCE40 más potencia, E / S y memoria" . 12 de diciembre de 2016.
- ^ "Especificaciones SDM845" .
- ^ "MIPI I3C" . mipi.org .
- ^ "LKML: Boris Brezillon: [PATCH v2 0/7] Agregar el subsistema I3C" . lkml.org .
- ^ "Renesas presenta nuevos productos de extensión de bus I3C" . 6 de junio de 2020.
- ^ Inc, MIPI Alliance. "Sesiones de sensores MIPI I3C en MIPI DevCon2016" . resources.mipi.org .
- ^ http://mipi.org/sites/default/files/MIPI%20+%20MIG%20Member%20Sensor%20Interface%20Survey%20Results%20final.pdf
- ^ Alianza MIPI (23 de septiembre de 2016). "MIPI DevCon 2016: una guía del desarrollador para la implementación de MIPI I3C" .
- ^ Alianza MIPI (23 de septiembre de 2016). "MIPI DevCon 2016: modos de alta velocidad de datos MIPI I3C" .
- ^ Grupo, Ken Foust, Presidente del Grupo de Trabajo MIPI I3C y Trabajo Ad Hoc Básico de MIPI I3C. "MIPI Alliance ofrece nueva especificación básica I3C" . resources.mipi.org . Consultado el 6 de abril de 2020 .
- ^ " Hoja de datos EEPROM de bus I 2 C serie de 8 Kbit " (PDF) . STMicroelectronics. Octubre de 2017. p. 27. DocID 023924 Rev 6. Archivado (PDF) desde el original el 18 de octubre de 2019 . Consultado el 19 de noviembre de 2019 .
- Analizadores-de-protocolo-I2C-vs-I3C-Diferencias-y-similitudes
enlaces externos
- MIPI I3C