Esta página es la segunda de una serie de páginas dedicada al transceptor multigigabit (MGT, del inglés Multi-Gigabit Transceiver).
Introducción
Los transceptores multigigabit (MGT) son el componente básico de muchos protocolos conocidos: PCIe, SATA, Gigabit Ethernet, SuperSpeed USB, Thunderbolt y DisplayPort. Todos estos protocolos tienen algo en común: hay un ordenador de por medio. También existen varios protocolos para telecomunicaciones, pensados para transportar llamadas telefónicas a través de un enlace de fibra óptica.
Los MGT también son útiles para intercambiar datos entre dos FPGA. En una página anterior se enumeran algunas cosas a tener en cuenta al usar un MGT con este fin. Evidentemente, se necesita algún tipo de protocolo para asegurar que los datos se transmitan correctamente y con una fiabilidad aceptable por el canal físico. La implementación de un protocolo así es bastante complicada, así que la pregunta es si existen protocolos ya preparados u otros elementos que puedan ayudar.
Esta página pretende resumir las principales alternativas. Están ordenadas a continuación según el nivel de complejidad de la lógica de aplicación, empezando por la menos compleja.
Salvo que se indique lo contrario, todos los protocolos siguientes pueden funcionar como enlace bidireccional (full duplex) o como enlace unidireccional (half duplex).
Xillyp2p
Xillyp2p es un protocolo propietario que proporciona un transporte fiable de múltiples flujos de datos entre dos FPGA. El protocolo gestiona la transmisión, la planificación, la retransmisión y el control de flujo (flow control) de los datos de aplicación de forma similar a como el protocolo TCP/IP transporta datos por una red: se garantiza que todos los datos llegan correctamente al otro lado.
La lógica de aplicación interactúa con la implementación del protocolo a través de FIFOs estándar. El protocolo crea la ilusión de una FIFO estándar que se extiende entre las dos FPGA: el lado de escritura de esta FIFO virtual está en una FPGA, y el lado de lectura, en la otra.
En cada una de las dos FPGA, un lado de la FIFO se conecta a la lógica de aplicación y el otro lado interactúa con la lógica del protocolo. Por tanto, la lógica de aplicación del lado transmisor escribe datos en una FIFO y la lógica de aplicación del lado receptor lee datos de otra FIFO. El protocolo se encarga de mover los datos desde la FIFO de la FPGA transmisora hasta la FIFO de la FPGA receptora. El control de flujo del protocolo se asegura de que la FIFO de la FPGA de destino nunca llegue a estar full (llena).
El protocolo puede atender varias FIFOs en ambos sentidos. Un planificador de transmisión de datos justo garantiza un aprovechamiento eficiente del ancho de banda del MGT. Los datos de la FIFO del lado transmisor se consumen con la suficiente rapidez, de modo que esta FIFO no llegará a estar full (llena), siempre que el ancho de banda lo permita y que los datos se consuman desde la FIFO del otro lado.
El protocolo ofrece también una interfaz distinta para transmitir paquetes, mediante un puerto EOP (End Of Packet).
También existe una opción semidúplex (half-duplex). En ese caso, el protocolo garantiza que todos los datos recibidos sean correctos. Si se produce un error de bit en el canal físico, el flujo de datos se detiene antes de que los datos erróneos lleguen a la lógica de aplicación.
Gigabit Ethernet
Aunque Gigabit Ethernet está pensado para la comunicación entre ordenadores, es posible utilizar este protocolo tan sencillo para enviar paquetes entre dos FPGA. Lo habitual es que el fabricante de la FPGA proporcione un núcleo de IP (IP core) adecuado. Por lo tanto, la lógica de aplicación se encarga de crear y recibir paquetes Ethernet a través de una de las interfaces estándar (GMII, RGMII, XGMII, etc.).
Como en cualquier enlace Ethernet, es responsabilidad de la lógica de aplicación organizar los datos en paquetes, así como gestionar los errores en el enlace (por ejemplo, mediante retransmisiones).
Interlaken
Interlaken es un protocolo abierto para la comunicación de paquetes entre chips. Se basa en la codificación 64b/67b: el flujo de datos de bajo nivel consiste en transmitir repetidamente segmentos de 64 bits. Antes de cada segmento se añaden 3 bits para distinguir entre datos de aplicación y palabras de control. El protocolo está definido para un enlace símplex (canal físico unidireccional). Si se utiliza un enlace full duplex (canal físico bidireccional), funciona igual que un enlace símplex, salvo que los mensajes de control de flujo pueden enviarse en la dirección opuesta.
La unidad básica de transmisión del protocolo es una ráfaga (burst) de longitud variable. Antes y después de cada ráfaga se transmite una palabra de control. Estas dos palabras de control contienen información que permite abstraer paquetes y canales. Esta información incluye, entre otros:
- Número de canal: un número entre 0 y 255 que asocia la ráfaga de datos que le sigue con un canal. Es posible ampliar el número de canales hasta 65536.
- SOP: un indicador (flag) que señala que los datos que le siguen son el comienzo de un paquete.
- EOP: un indicador (flag) que señala que el paquete anterior a la palabra de control era el último dato de un paquete. EOP indica también el número de bytes válidos en la última palabra de la ráfaga, y si el paquete contiene errores.
La longitud de cada ráfaga no debe superar BurstMax ni ser inferior a BurstShort. Tanto BurstMax como BurstShort son parámetros elegidos para cada aplicación concreta. BurstShort debe ser como mínimo de 32 bytes (y un múltiplo de 8), mientras que BurstMax debe ser un múltiplo de 64 bytes.
El contenido de la palabra de control y de la ráfaga de datos que (posiblemente) la antecedía se verifica en busca de errores de bit mediante un CRC24.
Si una ráfaga no supera la prueba CRC24 (es decir, se detecta un error de bit), se puede solicitar una retransmisión según se define en la Interlaken Retransmit Extension Protocol Definition. Según el mecanismo propuesto, esta solicitud se envía desde el receptor al transmisor mediante un conjunto de tres cables físicos, denominados FC_CLK, FC_DATA y FC_SYNC, que originalmente estaban pensados para el control de flujo fuera de banda (out-of-band flow control, OOBFC). Se define un protocolo simple de transmisión serie para enviar las solicitudes de control de flujo. Si la retransmisión está activada, uno de estos bits se llama “RT” y se utiliza para solicitar una retransmisión. En otras palabras, el protocolo no define cómo enviar la solicitud de retransmisión por el propio enlace MGT, sino por los tres cables físicos separados fuera de banda.
La solicitud de retransmisión no incluye información sobre a partir de qué ráfaga debe retransmitirse. En su lugar, se exige que el lado transmisor guarde una cantidad determinada de ráfagas de datos en un búfer (buffer). Cuando llega una solicitud de retransmisión, se retransmiten todas las ráfagas del búfer. Por tanto, el tamaño del búfer debe ser suficiente para contener la ráfaga perdida. No obstante, si el búfer es demasiado grande, las retransmisiones serán más largas de lo necesario. Para fijar el tamaño del búfer hay que calcular cuidadosamente el tiempo de ida y vuelta (round-trip time) desde que se entrega una ráfaga a la lógica que implementa el protocolo Interlaken hasta que llega una solicitud de retransmisión.
El receptor detecta las ráfagas retransmitidas mediante un contador que se incrementa por cada ráfaga que se transmite por primera vez (también es posible incrementar el contador cada 2, 4, 8, etc. ráfagas). El valor de este contador se transmite en la parte de uso múltiple (Multiple-Use) de las palabras de control que se envían antes y después de cada ráfaga. El receptor utiliza este contador para distinguir entre una ráfaga nueva y una ráfaga retransmitida.
El protocolo Interlaken tiene también una comprobación CRC32 con fines de diagnóstico (una vez por cada Meta Frame). Sin embargo, si se detecta un error mediante esta comprobación, este se refiere a un segmento de datos grande y no a una ráfaga o paquete concreto. En otras palabras, si unos datos superaron la prueba CRC24 a pesar de un error de bit, esto solo se detectará más tarde, y sin poder señalar la ráfaga que contiene los datos erróneos.
Es posible diseñar e implementar un mecanismo de retransmisión basado en el flujo de datos del MGT en la otra dirección. El protocolo Interlaken no propone un método para semejante mecanismo de retransmisión, pero es posible asignarle un canal dedicado para paquetes que soliciten retransmisiones. Tal solución puede tener una ventaja significativa, porque permite pedir de forma más específica qué se debe retransmitir. También es posible utilizar un CRC mejor, quizás a nivel de paquetes en lugar de ráfagas. Sin embargo, si se opta por este enfoque, todo el mecanismo debe implementarse en la lógica de aplicación.
Los mecanismos de control de flujo de Interlaken se tratan en una página aparte.
Aurora
Aurora es un protocolo desarrollado por Xilinx (ahora AMD) para sus propias FPGA. La unidad básica de transmisión de este protocolo es una palabra (de anchura fija, que depende del número de MGT que intervengan). No obstante, el protocolo también soporta la transmisión de paquetes (denominados tramas, frames). La lógica de aplicación divide el flujo de datos en paquetes con ayuda de un puerto de entrada llamado “last”.
Existen dos variantes de Aurora: con codificación 8b/10b y con codificación 64b/66b. La codificación 64b/66b es más eficiente, por lo que conviene preferir esta variante siempre que sea posible.
Aurora está definido para un enlace símplex (canal físico unidireccional) y también para un enlace full duplex (canal físico bidireccional). Desde el punto de vista de la lógica de aplicación no hay una diferencia significativa entre ambas opciones, salvo que el control de flujo no tiene sentido en un enlace símplex.
Observa que, a diferencia de Interlaken, el protocolo Aurora no menciona canales. En otras palabras, todos los datos transmitidos a través del canal físico pertenecen a un único flujo de datos. Cuando el protocolo utiliza la palabra “canal”, se refiere al canal físico, y no a una división de los datos en flujos independientes. Si se desea esa división, es responsabilidad de la lógica de aplicación implementarla, posiblemente añadiendo una cabecera (header) a cada paquete.
El protocolo no corrige los errores de bit en el canal físico. Sin embargo, cuando se utiliza para transmitir paquetes, el transmisor añade opcionalmente un CRC al final de cada paquete (en la implementación de Xilinx del protocolo). La implementación verifica ese CRC en el lado receptor e informa a la lógica de aplicación si se ha detectado algún error en el paquete. Si Aurora se utiliza sin paquetes (sin la señal “last”), el protocolo no ofrece detección de errores.
La información de control del propio protocolo se transmite sin ninguna protección contra errores de bit. No hay CRC en ese tráfico. Si hay errores de bit en el enlace físico, el protocolo puede funcionar mal de muy diversas maneras.
Cualquier mecanismo de retransmisión, multiplexación de varios canales y planificación de la transmisión debe implementarlo la lógica de aplicación. Una página aparte trata las posibilidades de implementar control de flujo con Aurora.
Serial Lite
Altera tiene una serie de protocolos y núcleos de IP (IP cores) que comparten el nombre Serial Lite:
- SerialLite II: interfaz basada en paquetes o no basada en paquetes para recibir y transmitir datos (llamada “Atlantic Interface”). Soporta retransmisión en respuesta a errores de bit. Solo es aplicable a FPGA antiguas (desde Arria II hasta las FPGA de la serie V).
- Serial Lite III: soporta los modos Continuous (continuo) y Burst (ráfagas). En el modo Continuous, el flujo de datos puede circular sin interrupciones ni huecos entre el transmisor y el receptor. Para ello es necesario que ambos lados utilicen el mismo reloj de referencia. Este protocolo se basa internamente en Interlaken, pero sin soporte de canales ni de SOP/EOP. En consecuencia, el ancho de la interfaz es de 64 bits multiplicados por el número de MGT utilizados. Los errores de bit en el enlace físico se notifican como un evento de diagnóstico relacionado con el MGT que los provocó, pero no con un segmento de datos concreto. Aplicable a FPGA de la serie V y de la serie 10.
- Serial Lite IV: basado en la interfaz de streaming Avalon, con señales de inicio y fin de paquete (MAC). El transmisor inserta opcionalmente un CRC al final de los paquetes y el receptor lo verifica. Hay también un modo Basic, sin división en paquetes. Aplicable a Stratix 10 y Agilex E-tile.
Los núcleos de IP (IP cores) no son compatibles entre los distintos miembros de esta serie de protocolos. Solo SerialLite II puede iniciar retransmisiones.
RapidIO
RapidIO es un protocolo basado en paquetes, similar a PCIe en el sentido de que los tipos de paquete que soporta corresponden a operaciones requeridas por una CPU, entre otras:
- Escritura (Write): escribe datos en una dirección. Esta operación tiene varias variantes; una de ellas requiere una respuesta que indique que la operación se ha completado.
- Lectura (Read): una solicitud para leer datos de una dirección. El destino envía un paquete de respuesta a esta solicitud.
- Lectura-modificación-escritura atómica (atomic read-modify-write): solicitud de escribir datos en una dirección después de leer el valor anterior, como operación atómica. Entre las operaciones soportadas se incluyen: incremento atómico y decremento atómico, intercambio atómico (atomic swap), comparar e intercambiar (compare and swap), etc.
- Varias solicitudes de mantenimiento para descubrimiento, control y estado. Al igual que el espacio de registros de configuración del protocolo PCI, estas solicitudes de mantenimiento acceden a los registros de capacidad (capability registers, CAR) y a los registros de comando y estado (command and status registers, CSR).
La principal diferencia funcional entre RapidIO y PCIe es que el protocolo PCIe exige que una unidad central (un Root Complex, normalmente una CPU) configure todos los endpoints del sistema. Un sistema RapidIO no necesita una unidad central de este tipo.
Otra diferencia con PCIe es que la retransmisión de paquetes es opcional. La retransmisión se produce únicamente para los paquetes enviados como tráfico fiable (reliable traffic, RT). Los paquetes también pueden enviarse como tráfico continuo (continuous traffic, CT). Estos paquetes no se confirman ni se retransmiten.
El protocolo RapidIO define todos los aspectos de la comunicación, desde la especificación eléctrica hasta los formatos de paquete, la retransmisión y el control de flujo.
RapidIO puede no ser un candidato atractivo para una simple conexión punto a punto entre dos FPGA, debido a la complejidad del protocolo. RapidIO puede ser más adecuado como interconexión entre varias FPGA a través de un conmutador (switch), en particular si PCIe no es adecuado por necesitar una CPU en el sistema.
Resumen
Se han presentado varios protocolos para transmitir datos de aplicación. Cada uno presenta métodos distintos para implementar el transporte de datos, controlar su flujo y responder a los errores de bit (si es que los hay). El protocolo adecuado para una aplicación es un equilibrio entre las prestaciones que ofrece el protocolo y el esfuerzo necesario para implementar en la lógica de aplicación las partes que le falten.
Con esto concluye la segunda página de esta serie sobre los MGT. La página siguiente presenta algunos métodos de codificación utilizados a menudo con los MGT.