Autobús ligero

El bus de medios interchip de baja potencia en serie ( SLIMbus ) es una interfaz estándar entre procesadores de banda base o de aplicaciones y componentes periféricos en terminales móviles. Fue desarrollado dentro de la Alianza MIPI , fundada por ARM , Nokia , STMicroelectronics y Texas Instruments . ^{[ 1 ]} La interfaz admite varios componentes de audio digital simultáneamente y transmite múltiples flujos de datos de audio digital a diferentes frecuencias de muestreo y anchos de bits.

SLIMbus se implementa como una estructura de trama síncrona de 2 hilos con multiplexación por división de tiempo (TDM) configurable. Cuenta con mecanismos de arbitraje de bus y estructuras de mensajes que permiten reconfigurar las características operativas del bus según las necesidades de la aplicación del sistema en tiempo de ejecución. Físicamente, la línea de datos (DATA) y la línea de reloj (CLK) interconectan múltiples componentes SLIMbus en una topología de bus multipunto . Los dispositivos SLIMbus pueden desconectarse y reconectarse dinámicamente al bus según sea necesario, utilizando los protocolos adecuados descritos en la especificación SLIMbus. Cuando se utiliza en un terminal móvil o un producto portátil, SLIMbus puede reemplazar las interfaces de audio digital heredadas, como ^{PCM, I²S [2} ] y SSI ( ^{Interfaz serie} síncrona para audio digital), así como algunas instancias de muchos buses de control digital ^, como I²C ^[ 3], ^{SPI ,} microWire [ 4 ] ^{, UART o} pines GPIO en los componentes de audio digital ^.

• La Alianza MIPI se formó en otoño de 2003.
• Arquitectura de interfaz que incluye un bus de enlace de medios de baja velocidad (LowML), presentada en la reunión presencial de MIPI Alliance en Sophia Antipolis , Francia, en marzo de 2004.
• El Grupo de Investigación sobre el Blanqueo de Petróleo (LML-IG) fue creado en julio de 2004 por la Alianza MIPI. La primera reunión fue una teleconferencia el 3 de agosto de 2004.
• El Grupo de Trabajo sobre LML (LML-WG) se creó en el cuarto trimestre de 2004. El estatuto del LML-WG se presentó a la Junta Directiva de MIPI en diciembre de 2004.
• Primera reunión del Grupo de Trabajo en pleno el 12 de abril de 2005.
• El grupo de trabajo LML-WG publicó el primer borrador de SLIMbus con texto en todos los capítulos (v0.55) el 18 de octubre de 2005.
• La especificación SLIMbus v1.00 se publicó para los usuarios el 16 de mayo de 2007.
• Desde junio de 2007 hasta junio de 2008, se mejoró la especificación SLIMbus (se corrigieron ambigüedades, errores tipográficos y fallos) basándose en los comentarios de los implementadores.
• La especificación SLIMbus V1.01 se publicó para los usuarios el 3 de diciembre de 2008 y se recomienda su implementación.

Las definiciones de clase de dispositivo SLIMbus especifican los requisitos mínimos para los datos de control del dispositivo, su comportamiento y la compatibilidad con el protocolo de transporte de datos. En la versión 1.01 de la especificación SLIMbus se definieron cuatro clases de dispositivo: Administrador, Enmarcador, Interfaz y Genérico. Los sistemas SLIMbus completos pueden implementarse sin necesidad de clases de dispositivo adicionales.

El dispositivo gestor es responsable de configurar SLIMbus y realiza la administración del bus (administración de componentes y dispositivos, configuración del bus y asignación dinámica de canales). Normalmente se encuentra en un procesador de banda base o de aplicación, en lugar de en un componente periférico.

El Framer proporciona una señal de reloj en la línea CLK a todos los componentes SLIMbus, y también contiene la lógica para transmitir los canales de sincronización de trama e información de trama en la línea DATA.

El dispositivo de interfaz proporciona servicios de gestión de bus, supervisa la capa física en busca de errores, informa sobre el estado de un componente SLIMbus y, en general, gestiona el componente para que los dispositivos que contiene funcionen correctamente en el bus.

Para implementar un componente SLIMbus funcional siempre se requiere el uso de un dispositivo de interfaz SLIMbus, además de la función que se va a realizar, como DAC, ADC, amplificador digital , etc.

Un dispositivo genérico es un dispositivo distinto de un administrador, un enmarcador o una interfaz. Generalmente, se considera que un dispositivo genérico proporciona ciertas funcionalidades de la aplicación, por ejemplo, la conversión de audio digital a analógico (DAC) y viceversa (ADC).

Un componente SLIMbus contiene dos o más dispositivos SLIMbus. Un componente SLIMbus tendrá un único dispositivo de interfaz SLIMbus (INTERFACE) y podrá tener uno o más tipos de dispositivos SLIMbus que realicen una función específica (FUNCTION).

Un puerto SLIMbus (P) proporciona la ruta de conexión para el flujo de datos entre dispositivos. Los puertos SLIMbus se utilizan normalmente para el flujo de datos de audio digital, pero también pueden utilizarse para otros flujos de datos digitales.

Las capacidades de los puertos varían según el dispositivo y deben especificarse en la hoja de datos del componente. Los atributos típicos de un puerto incluyen la dirección de los datos (solo entrada, solo salida o entrada y salida), los protocolos de transporte compatibles y el ancho de banda de los datos.

En la Figura 1, a continuación, se muestra un ejemplo sencillo de un componente SLIMbus, y en la Figura 2, a continuación, se muestra un ejemplo complejo de un componente SLIMbus.

Todos los dispositivos SLIMbus utilizan DATA y CLK para sincronizarse con la configuración del bus en uso, para recibir o transmitir mensajes y datos, y para implementar la arbitraje del bus, la detección de colisiones y la resolución de conflictos entre dispositivos.

Para todos los componentes SLIMbus (excepto aquellos que contienen un dispositivo de enmarcado), el terminal CLK es solo de entrada. Si un componente SLIMbus es el dispositivo de enmarcado o contiene uno, la señal CLK es bidireccional.

En todos los componentes de SLIMbus, la línea de datos es bidireccional y transporta toda la información enviada o recibida en el bus mediante codificación NRZI ( Non-Return-to-Zero Inverted ).

La línea DATA se activa en el flanco positivo y se lee en el flanco negativo de la línea CLK. La línea DATA puede activarse en nivel alto, en nivel bajo o mantenerse en nivel alto o bajo mediante un circuito interno de retención de bus , según el modo de funcionamiento específico del dispositivo SLIMbus.

Las líneas DATA y CLK de la interfaz SLIMbus utilizan señales de modo de voltaje de riel a riel, de terminación simple, referenciadas a tierra y similares a las de CMOS . Los voltajes de señalización se especifican con respecto al voltaje de alimentación de la interfaz (se permiten +1,8 Vdd o +1,2 Vdd). Por motivos de rendimiento EMI, se han especificado límites de velocidad de cambio para SLIMbus.

La frecuencia de la línea CLK del SLIMbus está determinada por un rango de frecuencias de reloj "Raíz" de hasta 28 MHz y 10 niveles de reloj (Clock Gears) para modificar la frecuencia de reloj en potencias de 2 en un rango de 512x desde el nivel más bajo hasta el más alto. La frecuencia raíz se define como 2 ^(10-G) veces la frecuencia de la línea CLK. Para G=10, la frecuencia de la línea CLK y la frecuencia raíz son iguales.

El SLIMbus CLK también puede detenerse y reiniciarse.

Las frecuencias CLK y los protocolos de transporte de datos de SLIMbus admitirán todas las frecuencias de sobremuestreo comunes de los convertidores de audio digital y las tasas de muestreo asociadas.

La estructura de bastidores de SLIMbus consta de cinco bloques básicos: celdas, ranuras, bastidores, subbastidores y superbastidores.

Una celda se define como una región de la señal de DATOS delimitada por dos flancos positivos consecutivos de la línea CLK y que contiene un único bit de información.

Una ranura se define como cuatro celdas contiguas (transmisión de 4 bits en orden de MSB a LSB). La asignación de ancho de banda para diversas organizaciones de datos, desde 4 bits hasta 32 bits o más, se puede realizar agrupando ranuras de 4 bits.

Una trama se define como 192 (del 0 al 191) ranuras contiguas y se transmiten como S0, seguidas de S1, S2...S191 en ese orden. La primera ranura (ranura 0) de cada trama es una ranura de espacio de control que contiene el símbolo de sincronización de trama de cuatro (4) bits. La ranura S96 de cada trama también es una ranura de espacio de control que contiene cuatro (4) bits de información de trama.

El Framer activo escribe toda la información de trama en la línea de datos en el momento adecuado.

Un subframe se define como la división de la estructura de trama en la que se intercalan el espacio de control y el espacio de datos . Un subframe se divide en una o más ranuras de espacio de control, seguidas de cero o más ranuras de espacio de datos.

Como se muestra en la Figura 4, la longitud del subframe es programable a 6, 8, 24 o 32 ranuras contiguas (24, 32, 96 o 128 celdas). Por lo tanto, el número de subframes posibles por frame es de 32, 24, 8 o 6, respectivamente. La configuración del subframe se puede modificar dinámicamente según los requisitos de flujo de datos de las aplicaciones que se estén utilizando.

Cuatro de las ranuras del espacio de control están reservadas para un símbolo de sincronización de trama, cuatro bits para una palabra de información de trama y ocho bits para el byte guía. El espacio restante está disponible para mensajes de control más generales.

Cualquier espacio no asignado al espacio de control se considera espacio de datos.

Un superfotograma se define como ocho fotogramas contiguos (1536 ranuras). Los fotogramas dentro de un superfotograma se etiquetan del fotograma 0 al fotograma 7.

La duración de un Superframe es fija en términos de Ranuras (y, por lo tanto, de Celdas), pero no en términos de tiempo. La frecuencia del Superframe se puede modificar dinámicamente en SLIMbus para adaptarla a la aplicación específica, cambiando la Frecuencia Raíz de SLIMbus, el Reloj o ambos.

La información de la línea DATA del SLIMbus se asigna a los canales del Espacio de Control y del Espacio de Datos.

El espacio de control contiene información de configuración y sincronización del bus, así como comunicación de mensajes entre dispositivos. El espacio de control puede programarse dinámicamente para utilizar todo el ancho de banda del bus SLIM según sea necesario, incluso hasta el 100 % en ocasiones.

Cuando está presente, el espacio de datos contiene información específica de la aplicación, como flujos de datos isócronos y asíncronos .

Los componentes SLIMbus transmiten información de control y datos entre sí mediante canales de control y datos con protocolos de transporte para lograr el funcionamiento del sistema requerido. Los mensajes se utilizan para las funciones de control.

Se pueden establecer canales entre un par de dispositivos (comunicación entre dispositivos), entre un dispositivo y muchos dispositivos (comunicación de difusión) o, en el caso del canal de mensajes, desde todos los dispositivos a todos los demás dispositivos (compartido).

El espacio de control se divide en tres tipos de canales: Tramado, Guía y Mensaje.

El canal de trama ocupa las ranuras 0 y 96 de cada trama. (Dado que todas las longitudes de subtrama son divisores de 96, estas ranuras siempre están disponibles para este propósito). La ranura 0 contiene un símbolo de sincronización de trama fijo (1011 ₂ ), mientras que la ranura 96 ​​contiene 4 bits de una palabra de información de trama. A lo largo de una supertrama, hay 32 bits de información de trama disponibles. Algunos de estos contienen un patrón de bits fijo utilizado para adquirir la sincronización de la supertrama (0 x 011 xxx ₂ ), mientras que los demás contienen otra información de configuración crítica.

El canal guía consta de las dos primeras ranuras de control que no son de trama en cada superfotograma. Este "byte guía" normalmente es 0, pero si un mensaje de control abarca el límite de un superfotograma, indica el número de bytes hasta el final de dicho mensaje.

El canal de mensajes consta de todas las ranuras restantes. Transporta diversos tipos de información, incluidos anuncios de configuración del bus, control del dispositivo y estado del dispositivo.

El formato del espacio de control se determina mediante un identificador de modo de subfotograma de 5 bits transmitido en la palabra de información de trama. Este identificador comunica la longitud del subfotograma y el número de ranuras de control. El número de ranuras de control está limitado a las opciones 1, 2, 3, 4, 6, 8, 12, 16 o 24. Si se añade la limitación de que el número de ranuras de control debe ser menor que la longitud del subfotograma, se obtienen 26 combinaciones válidas. Una codificación especial para el "espacio de control al 100%", en cuyo caso la longitud del subfotograma no importa, produce 27 modos válidos. (Los modos 1-3, 20 y 30 no son válidos).

Los canales de datos son uno o más segmentos de datos contiguos y son creados dinámicamente por el administrador activo según la aplicación y el tamaño del espacio de datos disponible. Un canal de datos, y por lo tanto la estructura de un segmento, se define mediante parámetros como la velocidad de datos, el tipo, la longitud del campo y el protocolo de transporte requerido.

Los segmentos se repiten a intervalos conocidos y se comportan como buses virtuales con su propia garantía de ancho de banda y latencia.

Un segmento, como se muestra en la Figura 5, tiene dos ranuras para TAG, dos ranuras para AUX y dos ranuras para DATA. Los campos TAG y AUX son opcionales. Si se utilizan, los bits TAG contienen información de control de flujo para el canal de datos, mientras que los bits auxiliares (AUX) contienen información adicional relacionada con el contenido del campo DATA. La carga útil de datos puede o no ocupar la totalidad del campo DATA asignado.

Un canal de datos tiene exactamente una fuente de datos a la vez y puede tener uno o más destinos de datos, dependiendo del protocolo de transporte utilizado en el canal.

El control de flujo en el canal, si es necesario, depende de los dispositivos y del tipo de datos involucrados. Los bits TAG se utilizan para transmitir la información de control de flujo.

Los puertos de dispositivo SLIMbus se asocian a canales de datos mediante mensajes de conexión y desconexión de canal. Para el flujo de datos entre puertos conectados a canales, SLIMbus admite un pequeño grupo de protocolos de transporte de uso frecuente (incluido un protocolo de transporte definido por el usuario) que definen el tipo de flujo de datos, el mecanismo de control de flujo y un canal lateral (si lo hubiera) para cualquier información adicional específica de la aplicación. En la Tabla 1 se muestra un resumen de los protocolos de transporte.

Los protocolos de usuario 1 y 2 se utilizan para ampliar los mecanismos de transmisión de datos de SLIMbus y se supone que un dispositivo conectado a un canal de datos de protocolo de usuario conoce la definición de los bits TAG y AUX y cómo se utilizan.

En la figura 7, a modo de ejemplo, se muestra un sistema SLIMbus. Todos los componentes son diferentes entre sí. Cabe destacar que el componente SLIMbus superior izquierdo de este ejemplo contiene un dispositivo de enmarcado (F), por lo que la señal CLK de este componente es bidireccional.

El componente SLIMbus superior izquierdo también contiene un dispositivo administrador (M). Sin embargo, no es necesario que el dispositivo administrador y el dispositivo de enmarcado se encuentren en el mismo componente SLIMbus.

El dispositivo gestor y/o de enmarcado que se muestra en el componente SLIMbus superior izquierdo también se puede incorporar a los procesadores de banda base y/o de aplicaciones que se utilizan habitualmente para construir terminales móviles.

La figura 8 muestra una representación conceptual de un posible sistema SLIMbus real. Las letras "M" y "F" representan los dispositivos de gestión y de encuadre, respectivamente. Como alternativa, el conjunto de micrófonos múltiples podría reemplazar al micrófono único del sistema. Se podría conectar cualquier combinación de bloques relacionados con el audio.

Puede encontrar una lista parcial de información sobre implementadores de SLIMbus en el siguiente enlace:

• Sistemas de chips Arasan
• Herramientas LNK
• Evatronix

• "MIPI Alliance lanza SLIMbus®" . MIPI Alliance . MIPI Alliance, Inc. 9 de julio de 2007. Consultado el 17 de enero de 2013 .
• Backman, Juha; Boyce, Kenneth; Kavanagh, Peter; Lambrecht, Xavier; Schuessler, James; Travis, Chris; van Vlimmeren, Bernard; Vansteeg, Genevieve (septiembre de 2006). Slimbus: una interfaz de audio, datos y control para dispositivos móviles . 29° Congreso Internacional: Audio para Dispositivos Móviles y Portátiles.
• Lee, Yong-Hwan; Hoon-Ju Chung; Chang-Gu Rho (2008). "Diseño de engranajes de reloj para medios de baja potencia" (PDF) . XXIII Conferencia Técnica Internacional sobre Circuitos/Sistemas, Computadoras y Comunicaciones . Recuperado el 17 de enero de 2013 .
• "MIPI® Alliance presenta siete especificaciones vitales para la interfaz de dispositivos móviles en 2008" . Business Wire . 9 de febrero de 2009. Consultado el 17 de enero de 2013 .