Esta página es la primera de una serie de páginas dedicada al transceptor multigigabit (MGT, del inglés Multi-Gigabit Transceiver), además de una visión general de lo que se tratará en esta serie.
Introducción
Los transceptores multigigabit (MGT) desempeñan un papel importante en la comunicación entre distintas partes de un ordenador o de un sistema electrónico. Varias interfaces muy conocidas dentro de un ordenador se basan en MGT, por ejemplo PCIe y SATA. Otras interfaces muy conocidas se utilizan para la comunicación entre un ordenador y sus periféricos, por ejemplo Gigabit Ethernet, SuperSpeed USB, Thunderbolt y DisplayPort.
Los MGT también se utilizan para conectar componentes electrónicos entre sí, por ejemplo dos FPGA. En ese caso, la comunicación suele basarse en uno de los protocolos menos conocidos, o incluso en un protocolo no estándar. Pero también es posible usar MGT para conectar una FPGA con otro tipo de componente, o bien conectar entre sí otros componentes, por ejemplo con Xillyp2p.
Por ejemplo, los transceptores de fibra óptica suelen ser módulos estándar (sobre todo en formato SFP+) que se conectan directamente a los MGT, como se muestra en este diseño de ejemplo. Algunos ADC/DAC de alta velocidad también utilizan MGT para transferir los datos de muestra (normalmente basado en el protocolo JESD204). Algunos protocolos están pensados para transferir datos de vídeo (por ejemplo, algunos de los protocolos de MIPI para la capa física).
Aunque los MGT se usan a menudo en protocolos bidireccionales, cada MGT consta en realidad de dos partes independientes: un transmisor y un receptor. Por eso es posible utilizar un MGT para una transmisión unidireccional apagando una de las dos partes. En la mayoría de los MGT de FPGA, además, se pueden configurar los parámetros del transmisor y del receptor de manera independiente.
En resumen, los MGT se emplean en muchas aplicaciones. A menudo el nombre de la interfaz no revela que se estén usando MGT (por ejemplo, Gigabit Ethernet, SATA o DisplayPort), pero la capa física está formada por MGT.
Conviene mencionar que Xilinx (y posteriormente AMD) da nombres distintos a sus MGT: RocketIO, GTX, GTH, GTY, GTP, GTM, etc. Cada nombre corresponde a una implementación de hardware específica del transceptor, de modo que el nombre indica algo sobre las velocidades de datos y otras prestaciones del transceptor.
Esta serie de páginas explica los fundamentos de los MGT y algunos términos técnicos de uso frecuente en relación con ellos. La idea es facilitar la lectura de la documentación técnica y, en particular, que puedas reconocer qué parámetros son relevantes para tu proyecto y cuáles no.
¿Qué es un MGT?
Es importante darse cuenta de que, tras toda la complejidad, un MGT no es más que un SERDES: un bloque electrónico que recibe y transmite datos. La interfaz eléctrica del MGT con el mundo exterior consiste en dos cables que forman un par diferencial. Cuando la tensión en el primer cable (el positivo, o de signo más) es mayor que la tensión en el otro cable (el negativo, o de signo menos), el estado físico corresponde a un ‘1’. En caso contrario, es un ‘0’. Es el mismo principio que en las interfaces diferenciales, como LVDS.
Otra similitud con un SERDES es que la interfaz del MGT con la lógica de aplicación es una palabra paralela: por cada ciclo del reloj de la lógica de aplicación se transfieren varios bits entre la lógica y el MGT. Esta disposición es necesaria porque la velocidad de datos es muy superior a la frecuencia de reloj máxima que puede alcanzar una FPGA.
Sin embargo, hay algunas diferencias importantes entre un SERDES normal y un MGT. Estas son algunas de ellas:
- Los MGT pueden alcanzar velocidades de datos mucho mayores que las de un SERDES normal.
- Al receptor de un SERDES hay que proporcionarle el reloj del transmisor junto con el flujo de datos. En cambio, el receptor de un MGT puede basarse únicamente en la señal del flujo de datos: el propio MGT genera un reloj que se ajusta a dicha señal y lo utiliza en su lugar. Esta capacidad se llama recuperación de reloj y datos (clock data recovery, CDR). Incluso cuando el receptor del MGT tiene acceso al reloj del transmisor, este se usa solo como reloj de referencia y no como reloj de datos.
- Los errores de bit son algo permitido y normal en un enlace que utiliza MGT. Normalmente se espera que la tasa de error de bit (BER) esté por debajo de 10-12 o 10-15. Si se produce un error de bit en un SERDES normal, se considera un mal funcionamiento, pero no ocurre lo mismo con un MGT.
- Cuando se utiliza un MGT, el contenido del flujo de datos transmitido por el par de cables está sujeto a restricciones. Siempre se exige que el flujo de datos esté equilibrado en corriente continua (DC balanced). Es decir, el número de ‘0’ y de ‘1’ debe ser igual en promedio. También se exige a menudo que los bits transmitidos sean estadísticamente independientes entre sí. Más sobre esto más abajo.
- Un MGT es capaz de generar y detectar señales fuera de banda (out-of-band signals, OOB). Estas señales se transmiten cuando se detiene el flujo normal de datos para ahorrar energía. Su finalidad es principalmente despertar al receptor del otro extremo para reanudar la transmisión de bits de datos.
Entonces, ¿por qué es tan complicado un MGT?
Cualquiera que haya intentado configurar un bloque MGT para un proyecto de FPGA sabe que hay una gran cantidad de parámetros y opciones. ¿Por qué tiene que ser así?
En realidad no tiene por qué ser complicado: como se muestra en este diseño de ejemplo, cuando el MGT se usa simplemente como SERDES, desaparece gran parte de la complicación.
Sin embargo, lo habitual es que el uso de un MGT sea complicado, y hay principalmente tres razones. La primera es que el bloque MGT implementa muchos módulos que podrían implementarse en el tejido lógico, pero que se incluyen dentro del MGT por eficiencia. Por ejemplo, todos los MGT tienen capacidad para codificar y decodificar 8b/10b, aunque la lógica de aplicación podría hacerlo. Pero como esta técnica de codificación se utiliza tanto, el MGT puede encargarse de ello.
La segunda razón tiene que ver con la generación de relojes: para que un MGT funcione correctamente se necesitan varios relojes. Para complicarlo más, los requisitos sobre la calidad del reloj (en particular, la fluctuación de fase o jitter) son más estrictos que en los relojes del tejido lógico de una FPGA. Y a veces se usa también la modulación de reloj por espectro ensanchado (SSC, del inglés Spread Spectrum Clocking), lo que añade aún más complicación.
Hacer bien la parte de los relojes no es, a veces, menos difícil que elegir los parámetros correctos del MGT en general.
La tercera razón es que los MGT se diseñan para dar soporte a varios protocolos de comunicación estándar. En consecuencia, los nombres de las características necesarias para un protocolo concreto suelen salir de la especificación del protocolo. Esa jerga no significa nada para quien no conoce el protocolo correspondiente. Esto hace difícil decidir qué características activar al configurar un bloque MGT para una FPGA.
Todos estos temas se tratan con más detalle en el resto de esta serie de páginas.
Cosas que conviene tener en cuenta
En la mayoría de los casos, los MGT se utilizan como capa física de otro protocolo bien establecido, en particular PCIe. En estas situaciones, las herramientas de FPGA se ocupan de los detalles y no hace falta entender mucho de lo que ocurre a bajo nivel.
No obstante, si pretendes conectar tu lógica de aplicación directamente a un MGT, es importante ser consciente de varios retos que esa lógica deberá afrontar. Algunos de estos problemas los resuelven los protocolos pensados para el uso entre FPGAs.
Esta es una breve lista de temas a tener en cuenta. Cada uno se trata con más detalle en el resto de esta serie de páginas.
- Alineación de palabras: Igual que cualquier SERDES, un MGT no sabe de antemano dónde empieza un byte o una palabra mayor. En un SERDES, este problema suele resolverse desplazando la palabra paralela de un bit en un bit (lo que se conoce como bit slipping), hasta que el flujo de datos que llega tenga sentido. Los protocolos basados en MGT suelen emplear para esto una palabra de sincronización.
- Los bits en los cables físicos deben estar equilibrados en corriente continua. La solución más fácil es usar codificación 8b/10b, pero hay otras posibilidades que a veces resultan más adecuadas.
- Aleatorización de datos (scrambling): Casi siempre es buena idea usar un ecualizador (equalizer) en el MGT receptor. El ecualizador compensa las imperfecciones del medio físico y, con ello, reduce la BER. Esto es especialmente cierto cuando la velocidad de datos es alta, cuando se usa cableado de bajo coste o cuando la distancia física es larga. Ahora bien, algunos tipos de ecualizadores exigen que los datos transmitidos sean estadísticamente aleatorios: no se permite ninguna correlación entre un bit y otro en el flujo transmitido. La solución habitual es emplear un codificador de aleatorización (scrambler), que realiza una XOR entre los datos de carga útil y una secuencia pseudoaleatoria de bits. El receptor realiza la XOR con la misma secuencia pseudoaleatoria y de este modo recupera el flujo de datos original.
- Errores de bit: Los datos pueden llegar con errores al MGT receptor. La lógica que consume esos datos debe estar diseñada para tolerarlos. En algunas aplicaciones se considera que los errores son lo bastante raros como para ignorarlos (por ejemplo, al transmitir datos de vídeo sin procesar y la BER es inferior a 10-15). En otras, se necesita un mecanismo de detección de errores o de retransmisión para que el enlace de datos sea fiable.
- Diferencias entre las frecuencias de reloj: Cuando un MGT recibe un flujo de datos, esa señal está basada en el reloj del otro lado (es decir, el reloj del transmisor). Puede que este reloj tenga una frecuencia ligeramente distinta de la del reloj disponible en el lado del receptor. Sin embargo, la interfaz entre el MGT y la lógica de aplicación suele estar basada en el reloj local. Por lo tanto, si el reloj del transmisor es más rápido que el del receptor, el MGT recibe datos más rápido de lo que puede entregarlos a la lógica de aplicación. Como consecuencia, los datos sobrantes se acumulan dentro del bloque MGT y acaba produciéndose algún tipo de desbordamiento (overflow). A la inversa, si la velocidad de llegada de los datos es menor que la del reloj local, el MGT no puede entregar datos en todos los ciclos de reloj. Estos problemas aparecen incluso cuando el reloj de referencia se transfiere del transmisor al receptor junto con el flujo de datos: basta una pequeña fluctuación en la frecuencia del reloj para provocar problemas de esta clase. El protocolo suele resolverlo con palabras de relleno (idle words).
- Consumo de energía: Los MGT tienden a consumir bastante energía. Esto se debe en parte a la alta velocidad de datos, y a menudo los PLL de alta calidad consumen mucha energía. Por eso casi siempre interesa desconectar un MGT cuando no se usa, incluso por periodos muy cortos. Por ejemplo, un enlace SuperSpeed USB suele desactivar su flujo de datos si no se ha transmitido nada durante un periodo de tan solo 50 μs. Entonces se utiliza un handshake fuera de banda (OOB) para reanudar el funcionamiento cuando haga falta.
PMA, PCS y la generación de relojes
Este diagrama de bloques muestra las partes de un MGT y su interacción con la lógica de aplicación:
La funcionalidad de un MGT se suele dividir en tres partes:
- Generación de relojes: Como se ha dicho, el funcionamiento de un MGT requiere varios relojes. Aunque las herramientas de FPGA configuran automáticamente los parámetros de estos relojes, conviene, aun así, saber cómo se generan.
- PMA (Physical Medium Attachment): Esta parte contiene el SERDES del MGT y los subsistemas de señal analógica (señales OOB, detección de receptor, ecualizador, preénfasis, etc.). Esta parte también implementa la CDR.
- PCS (Physical Coding Sublayer): Esta parte contiene lógica que puede resultar útil para implementar el protocolo de comunicación: codificadores y decodificadores, alineación de palabras, gearboxes, FIFOs, etc. La mayor parte de la funcionalidad del PCS podría implementarse en el tejido lógico, pero se implementa dentro del MGT para mayor simplicidad y eficiencia.
Estos temas se amplían en esta serie de páginas.
La interfaz PIPE
Vale la pena mencionar el estándar PIPE: define las conexiones entre un MGT y la lógica que implementa PCIe, SuperSpeed USB o SATA. Esto incluye los puertos que se usan para comunicar los datos, las señales de control y las señales de estado.
En este estándar, el MGT se denomina capa PHY, y el protocolo se denomina capa MAC. Esta terminología la emplean también los estándares que definen Ethernet, USB 1.x y USB 2.0. Normalmente, esos estándares se implementan con dos chips separados. Por ejemplo, para implementar Ethernet en un chip de procesador, la capa MAC se implementa en ese chip y la capa PHY en un chip aparte. El estándar PIPE está concebido con el mismo espíritu, aunque PCIe, SuperSpeed USB o SATA están prácticamente siempre implementados por completo en el mismo chip. Las conexiones entre la capa MAC y la capa PHY definidas por el estándar PIPE ocurren dentro del chip y rara vez son visibles desde fuera.
Una consecuencia importante del estándar PIPE es que un MGT de FPGA que se precie siempre implementa la interfaz PIPE necesaria para PCIe. La interfaz PIPE para SATA también suele estar implementada. Eso es útil, obviamente, a la hora de implementar esos dos protocolos; pero hay otro beneficio importante: distintas FPGA ofrecen una interfaz similar con el MGT. En particular, hay ciertos elementos funcionales que se encuentran en prácticamente todos los MGT.
Conclusión
En esta página se ha presentado una visión general del MGT y de su complejidad. En el resto de esta serie de páginas se explican muchos de los conceptos mencionados. Pero antes, empezaremos con un breve resumen de los protocolos que se utilizan a menudo al conectar dos MGT de FPGA.