Esta página es la cuarta de una serie de páginas dedicada al transceptor multigigabit (MGT). En las páginas anteriores se han tratado el MGT, algunos protocolos que se usan con él y algunos métodos de codificación.
Introducción
Como ya se mencionó en la primera página de esta serie, un MGT no deja de ser un tipo sofisticado de SERDES. Entre las razones que han llevado a esa sofisticación se encuentran varios bloques internos del MGT cuya función es ayudar a implementar ciertos protocolos concretos. Esta página explica el propósito de algunos de esos bloques.
La parte del MGT que contiene estas unidades se denomina normalmente PCS (Physical Coding Sublayer, es decir, la subcapa de codificación física). Este nombre puede inducir a error, porque parte de la lógica interna del PCS no tiene nada que ver ni con la codificación ni con la decodificación.
Este es un diagrama de bloques de un MGT típico, en el que se muestra la posición del PCS dentro del conjunto.
El PCS comprende todo lo que hay entre el PMA y la lógica de aplicación del usuario. Utilizaré las expresiones Tx PMA y Tx PCS para referirme a las partes del MGT que transmiten datos. Del mismo modo, Rx PMA y Rx PCS serán las expresiones para las partes que reciben datos.
El Tx PCS comienza en los puertos de entrada donde la lógica de aplicación entrega los datos al MGT para su transmisión. El Tx PCS termina su función cuando existe una palabra paralela formada por los bits listos para transmitirse por los cables físicos. Esa palabra paralela se entrega a la parte Tx PMA para que la serialice y la convierta en señal eléctrica.
De forma parecida, el Rx PCS comienza con la palabra paralela de datos que el Rx PMA ha recibido y deserializado, y termina en los puertos de salida donde el MGT entrega los datos a la lógica de aplicación.
Como el PCS está formado por lógica que trabaja únicamente con la palabra paralela, resulta evidente que toda la funcionalidad del PCS puede implementarse en el tejido lógico. Aun así, esa lógica se implementa dentro del MGT por la misma razón por la que muchos bloques se implementan como IP en silicio (hard IP). Algunos protocolos aprovechan las capacidades de codificación del PCS. Otros protocolos (por ejemplo, xillyp2p) confían en sus propios métodos para procesar el flujo de datos, lo que simplifica mucho el uso del MGT, como se muestra en este diseño de ejemplo.
Como cada MGT tiene una estructura interna distinta, es imposible describir el flujo detallado de datos dentro del PCS de un MGT de una manera que sirva para todos los MGT. Las descripciones y explicaciones siguientes se centran, por tanto, en cuál es el objetivo de los bloques funcionales del PCS. La descripción detallada de un PCS y de sus bloques solo puede encontrarse en la documentación del propio MGT. Con las explicaciones de esta página, la lectura de esa documentación resultará más fácil.
Codificación y decodificación
En la página anterior se presentaron varios métodos de codificación: 8b/10b, 64b/66b, 64b/67b, 128b/130b y 128b/132b.
La implementación de 8b/10b forma parte de todos los MGT de FPGA, dentro de su PCS. La implementación incluye la codificación y decodificación de las palabras de 8 bits a palabras de 10 bits y viceversa, así como las demás características mencionadas en la página anterior: símbolos K, sincronización y alineación en respuesta al símbolo de coma (K28.5), y también la respuesta a los símbolos de omisión (K28.0).
En cuanto a los demás métodos de codificación, cada MGT implementa un conjunto distinto de codificaciones. Los MGT también se diferencian en qué características de esas codificaciones están implementadas. A veces el PCS del MGT implementa solo el gearbox necesario, y a veces incluye también el mecanismo de sincronización automática. No existe un conjunto estándar de características.
Gearboxes
A lo largo del PCS, así como en la interfaz con la lógica de aplicación, el flujo de datos del canal físico se representa mediante una palabra paralela. La anchura de esta palabra puede cambiar según los datos atraviesan las distintas etapas de procesamiento dentro del PCS. Por ejemplo, cuando los datos pasan por un codificador 8b/10b, la anchura de la palabra pasa de 8 bits a 10 bits.
Sin embargo, la interfaz para transmitir los datos de aplicación hacia y desde el MGT consta de puertos de entrada y salida con una anchura que siempre es múltiplo de 8. Normalmente, esa anchura es una de las siguientes: 16, 32, 40, 64, 80, 128 o 160 bits.
Pero ¿qué ocurre, por ejemplo, si se utiliza la codificación 64b/66b? Con esta codificación, el flujo de datos en el canal físico está formado por segmentos de 66 bits cada uno. Si estos datos se presentan con una palabra paralela de 64 bits de anchura, el comienzo de cada segmento aparecerá cada vez en una posición distinta dentro de esa palabra. Ninguna de las anchuras permitidas para la interfaz con la lógica de aplicación evita este problema.
Para eso sirve un gearbox (adaptador de anchura de palabra): un módulo lógico que reorganiza los datos que llegan a su puerto de entrada en una palabra paralela con una anchura distinta.
Por ejemplo, supongamos que queremos transmitir datos que han sido codificados con 64b/66b con ayuda de un MGT, y que el codificador está implementado en la lógica de aplicación. La salida del codificador tiene 66 bits de anchura, pero la entrada del MGT puede ser de 64 o de 80 bits (u otras alternativas aún menos relevantes). Para resolverlo necesitaríamos implementar un gearbox que reorganizara la palabra paralela existente (de 66 bits) en una palabra que el MGT pueda aceptar (de 64 bits). Es una situación que conviene evitar.
Por esta razón, los MGT suelen incluir uno o varios gearboxes en su parte PCS. En particular, cuando el MGT incorpora un codificador 64b/66b (u otros similares, como 128b/130b), también hay un gearbox adecuado dentro del MGT. De este modo, el MGT se encarga de todas las tareas necesarias para transmitir datos codificados: primero los datos se codifican con su codificador, y después el gearbox cambia la anchura de la palabra paralela para que pueda entregarse al Tx PMA para su transmisión. Para recibir datos se utiliza una solución parecida.
Como las palabras a cada lado del gearbox tienen anchuras distintas, el número de bits que entran en el gearbox es diferente del número de bits que salen. Si la palabra paralela de entrada es más ancha, el gearbox debe rechazar de vez en cuando una palabra para compensar la diferencia. Del mismo modo, si la palabra de salida es más ancha, el gearbox no siempre tendrá algo válido en su puerto de salida. Así que, si el gearbox trabaja con un único reloj, debe existir también una señal de control de flujo (flow control) que compense la distinta cantidad de bits a cada lado. En la terminología de Xilinx / AMD, esto se denomina gearbox síncrono.
Alternativamente, el gearbox puede depender de dos relojes. Las frecuencias de estos relojes se eligen de modo que compensen la relación entre las anchuras de palabra a ambos lados del gearbox. La ventaja de este método es que el flujo de datos nunca se detiene en ninguno de los dos lados. Sin embargo, un gearbox de este tipo requiere dos relojes y funciona en dos dominios de reloj (clock domains). Esta solución se denomina gearbox asíncrono.
Búfer Tx (Tx FIFO)
El búfer de transmisión (Tx buffer), denominado a menudo FIFO de transmisión o FIFO Tx, es una pequeña FIFO dentro del Tx PCS. Su profundidad suele ser de 16 o 32 elementos de datos y normalmente está medio lleno durante el funcionamiento normal. La necesidad de esta FIFO es algo complicada y se explica a continuación. Sin embargo, esta explicación no responde a la única pregunta que suele importar al configurar un MGT: ¿debe activarse el búfer Tx o no?
La respuesta es que, en la mayoría de los casos, el búfer Tx debe estar activado. La única razón para evitar el búfer Tx es que su retardo cause un problema: usar un búfer Tx implica un retardo incierto entre el momento en que una palabra paralela se entrega al MGT y el momento en que esa palabra se transmite por la capa física. En la mayoría de las aplicaciones, esto supone una incertidumbre del orden de 0,1 μs o menos, por lo que el protocolo es indiferente a ese retardo.
En cuanto al porqué de esta FIFO, la explicación es la siguiente.
Dentro del Tx PCS hay al menos dos dominios de reloj: el primer reloj se utiliza para la interfaz con la lógica de aplicación. El segundo reloj (a veces llamado XCLK) se utiliza donde el Tx PCS entrega la palabra paralela para su transmisión al Tx PMA.
El tema de la generación de relojes dentro de un MGT se trata aparte en otra página. Por ahora basta con entender por qué tienen que existir dos relojes separados. Para explicarlo, compararemos el MGT con un SERDES normal.
Supongamos, por ejemplo, que queremos transmitir datos a 1000 Mbits/s con ayuda de un pin de salida normal. La mayoría de las FPGA actuales tienen un SERDES asociado a cada pin de salida para este fin. Para este ejemplo, supongamos que la lógica de aplicación alimenta al SERDES con una palabra paralela de 8 bits. El reloj de esta palabra será por tanto de 125 MHz.
En consecuencia, el SERDES recibe dos relojes: uno de 125 MHz y otro de 500 MHz. El SERDES utiliza ambos flancos del reloj de 500 MHz, de modo que los datos se transmiten a la velocidad deseada de 1000 MHz.
Los dos relojes que recibe el SERDES deben estar alineados. Por ejemplo, el flanco ascendente del reloj de 500 MHz debe ocurrir a la vez que el flanco ascendente del reloj de 125 MHz. Esto es necesario para que el SERDES funcione correctamente. Esa alineación se consigue utilizando un único PLL para generar ambos relojes y usando búferes de reloj que tengan el mismo retardo de propagación (propagation delay). Es un método habitual para garantizar que los relojes estén alineados: véase la explicación sobre relojes relacionados (related clocks).
Pero ¿y si queremos transmitir 5000 Mbits/s? Eso es demasiado para un pin de salida normal, así que se necesita un MGT. Dentro del MGT también hay un SERDES. Supongamos que la palabra paralela que va a ese SERDES tiene una anchura de 32 bits. En consecuencia, el reloj asociado a esa palabra tiene una frecuencia de 156,25 MHz. Supongamos también que la interfaz con la lógica de aplicación consiste en una palabra paralela de 32 bits. Por tanto, la frecuencia de reloj de esa interfaz también es de 156,25 MHz. ¿Pero se trata de la misma señal de reloj?
Para transmitir la palabra paralela, el SERDES del MGT debe estar conectado a un reloj de 2500 MHz (se transmite un bit nuevo en cada flanco del reloj). Esa frecuencia es demasiado alta para los PLL de propósito general de la FPGA. Tampoco es posible utilizar los búferes de reloj de la FPGA ni el resto de recursos de enrutado para esa señal. Por tanto, el MGT debe tener sus propios PLL y sus propios caminos de distribución para generar los dos relojes alineados que necesita el SERDES. Más detalles en la página sobre la generación de relojes del MGT.
Ahora ya podemos entender por qué hay al menos dos dominios de reloj dentro del Tx PCS. En este ejemplo, el Tx PCS alimenta al Tx PMA con una palabra paralela de 32 bits. El reloj de esta palabra es de 156,25 MHz. Este reloj lo genera el PLL del MGT para garantizar la alineación con el reloj de 2500 MHz. La interfaz entre la lógica de aplicación y el MGT se basa exactamente en la misma frecuencia de reloj, pero la lógica de aplicación no puede utilizar la misma señal de reloj a pesar de ello: el reloj de la lógica de aplicación debe pasar por el búfer de reloj del tejido lógico para que llegue a todos los elementos lógicos sin ningún desfase de reloj (clock skew). Debido al retardo de este búfer de reloj, el reloj de la lógica de aplicación no está alineado de forma natural con el reloj de 2500 MHz.
La forma más directa de realizar un cruce entre dominios de reloj (clock domain crossing) es utilizar una FIFO (como se menciona en una página dedicada a este tema). El búfer Tx es esa FIFO.
Los MGT que ofrecen la opción de omitir el búfer Tx ofrecen también otros métodos para garantizar la alineación necesaria entre los relojes dentro del Tx PCS. Sin embargo, estos métodos son complicados y propensos a errores.
Búfer Rx (Rx FIFO)
El búfer de recepción (Rx buffer), denominado a menudo FIFO de recepción o FIFO Rx, es una pequeña FIFO dentro del Rx PCS. En principio, este búfer es igual que el búfer Tx, de modo que todo lo dicho sobre el búfer Tx vale también para el búfer Rx. En particular, la respuesta a si este búfer debe activarse es la misma: el búfer Rx debe estar activado en la mayoría de las aplicaciones, salvo cuando el retardo que introduce sea inaceptable.
El búfer Rx tiene, sin embargo, un propósito adicional: permite que el Rx PCS trabaje con dos relojes cuyas frecuencias difieren ligeramente. Veamos ahora por qué puede darse esa diferencia.
Ante todo, recordemos que esta discusión se centra en la parte del MGT que recibe el flujo de datos. Sin embargo, ese flujo de datos lo genera otro MGT, que depende de otro reloj de referencia (en la mayoría de los casos). El MGT que recibe el flujo de datos a menudo no tiene acceso al reloj del transmisor. En su lugar, el receptor crea una réplica de ese reloj basándose únicamente en el flujo de datos (esto se llama recuperación de reloj y datos, CDR, del inglés Clock Data Recovery).
Como resultado, el Rx PMA trabaja con un reloj que se adapta a la velocidad de datos del transmisor. La frecuencia de este reloj es incierta, dentro de una tolerancia definida. El protocolo define siempre cuánto puede desviarse la frecuencia con respecto a un valor especificado, pero siempre hay un cierto grado de incertidumbre.
Por tanto, la interfaz que entrega palabras paralelas del Rx PMA al Rx PCS depende de un reloj que se adapta al transmisor. El Rx PCS debe ser síncrono con un reloj ajeno.
Pero ¿por qué esto es distinto del Tx PCS? Recordemos la discusión sobre el búfer Tx: hay dos dominios de reloj dentro de la parte del Tx PCS. Aunque esos dos relojes no son la misma señal de reloj, tienen exactamente la misma frecuencia, porque se basan en el mismo reloj de referencia.
De forma parecida, en la parte del Rx PCS hay dos dominios de reloj. Uno de los relojes tiene una frecuencia desconocida. ¿Y el otro reloj? La respuesta es que depende de los requisitos de la lógica de aplicación. En la mayoría de los escenarios, un MGT se utiliza para implementar un protocolo bidireccional. Ese protocolo implica transmitir datos en respuesta a datos recibidos. Por tanto, conviene que toda la lógica de aplicación sea síncrona con un único reloj. Más concretamente, la solución más habitual es que toda la lógica de aplicación sea síncrona con el reloj utilizado para la transmisión. Esto significa que la interfaz entre el Rx PCS y la lógica de aplicación es síncrona con el mismo reloj que el Tx PCS.
Con este enfoque, los dos relojes dentro del Rx PCS no tienen la misma frecuencia. Como resultado, el Rx PCS recibe datos del Rx PMA a un ritmo distinto del ritmo al que se los entrega a la lógica de aplicación. El búfer Rx es capaz de absorber temporalmente esa diferencia: si la lógica de aplicación extrae datos más lentamente, el búfer Rx acumulará el excedente. Si la lógica de aplicación extrae datos más rápido, el búfer Rx se irá vaciando.
Por supuesto, se trata de una solución muy temporal. El búfer Rx acabará, antes o después, desbordándose (overflow) o quedándose vacío (empty) si no se hace algo para mantener su nivel de ocupación en torno a la mitad de su capacidad. Existen distintos mecanismos para ello. Por ejemplo, recuerda de la página anterior que si se utiliza la codificación 8b/10b, se pueden insertar símbolos de omisión (skip symbols) para compensar las diferencias entre las frecuencias de reloj. El mecanismo que aprovecha los símbolos de omisión está implementado dentro del Rx PCS: si el búfer Rx está más de medio lleno, el Rx PCS no escribe símbolos de omisión en el búfer Rx. Esto reduce el nivel de ocupación. Por otro lado, si el búfer Rx está menos de medio lleno, el Rx PCS lee repetidamente símbolos de omisión del búfer Rx. Así, los datos nuevos llenan el búfer al mismo tiempo que este no se vacía. Por tanto, el nivel de ocupación del búfer Rx aumenta.
Al búfer Rx se le llama a menudo búfer elástico (elastic buffer) por esta capacidad de absorber temporalmente diferencias en su nivel de ocupación. Es importante señalar que esta capacidad no siempre es necesaria: si la lógica de aplicación se comunica con el Rx PCS mediante un reloj que tiene la misma frecuencia que el reloj del Rx PMA, el búfer Rx se comporta en principio igual que el búfer Tx. Con este enfoque, la lógica de aplicación es responsable de implementar el cruce entre dominios de reloj, si es que hace falta. Este enfoque permite también desactivar el búfer Rx si es necesario (en particular, para evitar el retardo). Xillyp2p es un ejemplo de lógica de aplicación que recibe los datos con el reloj del Rx PMA, pero permite utilizar el búfer Rx para simplificar la generación de relojes.
Características relacionadas con secuencias pseudoaleatorias
Una secuencia binaria pseudoaleatoria (PRBS, del inglés Pseudo-Random Bit Sequence) es una secuencia de bits que parece aleatoria, pero que en realidad no lo es: una PRBS se repite periódicamente. Como es fácil generar una PRBS con periodos muy largos (de varios millones de bits), las propiedades estadísticas de una PRBS se parecen a las de una secuencia de bits realmente aleatoria.
La forma más habitual de generar una PRBS es mediante un registro de desplazamiento con realimentación lineal (LFSR, del inglés Linear-Feedback Shift Register). Esta lógica consiste en unos pocos biestables (flip-flops) y puertas XOR, así que un LFSR no requiere muchos recursos para implementarse. Un ejemplo de LFSR muy utilizado puede encontrarse en una página aparte que trata un tema matemático relacionado con los LFSR.
La parte PCS de un MGT suele tener algunas funciones relacionadas con las PRBS. En particular, el MGT puede incluir una implementación de codificador de aleatorización (scrambler). Cuando la sincronización del scrambler está implementada en el Rx PCS, esto puede ahorrar mucho trabajo.
Otro uso muy común de una PRBS es probar el canal físico en busca de errores. Es un método útil porque el receptor puede generar fácilmente la secuencia de bits correcta con ayuda de un LFSR. Los errores en el canal físico se detectan comparando la secuencia de bits generada localmente con el flujo de datos que llega. Este mecanismo no es difícil de implementar en el tejido lógico, pero algunos MGT lo incorporan integrado.
Desgraciadamente, el canal físico no puede utilizarse para transmitir datos mientras se realiza una prueba de errores con una PRBS. Por tanto, es imposible supervisar la calidad del canal mientras está en uso. Algunos protocolos disponen de mecanismos para notificar errores, pero normalmente un error solo se notifica si ha alterado los datos transmitidos. Una excepción es xillyp2p, que también notifica errores que se producen cuando el enlace está inactivo.
Con esto concluye la cuarta página de esta serie sobre los MGT. La página siguiente comienza a tratar el PMA y su capacidad para compensar canales físicos difíciles, así como su capacidad para realizar un escaneo del ojo (eye scanning).