Esta página es la octava y última de una serie de páginas dedicada al transceptor multigigabit (MGT).
Introducción
El control de flujo (flow control) es un mecanismo que se utiliza a menudo en distintos tipos de enlaces de datos. Su finalidad es evitar que la cantidad de datos transmitidos supere lo que el lado receptor puede manejar.
Los protocolos relacionados con los MGT ofrecen distintos niveles de soporte para esta funcionalidad. Por ejemplo, la lógica que implementa el protocolo PCIe nunca acepta un paquete para su transmisión si los búferes del lado receptor están llenos. La lógica de aplicación que utiliza el protocolo PCIe no necesita implementar nada al respecto. Más bien, la interfaz entre la lógica de aplicación y la lógica del protocolo PCIe permite que el protocolo rechace temporalmente aceptar nuevos datos (por ejemplo, con ayuda de puertos AXI-S como VALID y READY). Del mismo modo, a la lógica de aplicación se le permite rechazar temporalmente los datos que llegan del otro lado. Con ello, la lógica de aplicación se protege de un desbordamiento (overflow).
Es importante no confundir el control de flujo con los mecanismos que evitan el desbordamiento en el propio búfer elástico del MGT. El control de flujo no tiene nada que ver con los símbolos de omisión mencionados en la página sobre los búferes del propio MGT. Más bien, el control de flujo protege los búferes de la lógica de aplicación. Y como a menudo hay varios canales de datos que utilizan el MGT como recurso compartido, el control de flujo se aplica a cada canal de forma separada e independiente.
En general, los protocolos que definen la comunicación con un ordenador se encargan del mecanismo de control de flujo. La lógica de aplicación solo necesita comunicarse con la lógica del protocolo mediante puertos de handshake sencillos, igual que con muchos otros bloques lógicos. Además de PCIe, SuperSpeed USB y SATA se ocupan del control de flujo por sí mismos.
Desgraciadamente, los protocolos para la comunicación entre FPGAs no suelen ofrecer control de flujo a este nivel. El único protocolo que se ocupa por completo del control de flujo es Xillyp2p. Otros protocolos para FPGAs solo tienen algunas características que pueden ayudar a la hora de implementar el control de flujo en la lógica de aplicación.
Esta página repasa varias técnicas para implementar el control de flujo. Más adelante se ofrece un breve resumen de cómo Aurora e Interlaken ayudan con el control de flujo. No obstante, conviene recordar que, excepto cuando se utiliza Xillyp2p, la lógica de aplicación es la responsable de evitar un desbordamiento.
Técnicas de control de flujo
El objetivo último del control de flujo es evitar que el lado que recibe datos reciba más de los que puede manejar. Normalmente, el lado receptor almacena los datos que llegan en búferes (o en una FIFO), de modo que todo se reduce a garantizar que en esos búferes quede espacio para todos los datos que lleguen.
El control de flujo es más difícil de implementar cuando se utiliza con MGT, sobre todo porque el canal físico tiene un retardo significativo. Por tanto, la solicitud de detener el envío tarda en llegar al transmisor. Además, hay un cierto tiempo desde que el transmisor deja de enviar datos hasta que estos dejan de llegar al receptor.
Otra dificultad con los MGT es que los errores de bit en el canal físico pueden hacer que se pierda una solicitud de detener el envío.
Además de estas dos dificultades, la velocidad de datos de los MGT es alta, y normalmente se espera aprovechar el canal físico de manera eficiente.
Comparado con canales de comunicación más sencillos, por ejemplo un puerto serie (RS-232), el control de flujo para un MGT necesita ser más sofisticado para garantizar que nunca se produzca un desbordamiento. Las tres técnicas siguientes se explican más abajo:
- XON / XOFF
- XOFF limitado en el tiempo («Pause»)
- Créditos (credits)
Al plantearse un protocolo para un proyecto, es importante hacerse las dos preguntas siguientes:
- ¿Qué necesita implementar la lógica de aplicación en relación con el control de flujo? La respuesta puede ser que no haya que implementar nada, como en PCIe, SuperSpeed USB y Xillyp2p.
- Si los datos de aplicación pertenecen a canales distintos: ¿el mecanismo de control de flujo permite pausar la comunicación de cada canal por separado, o afecta a todo el tráfico del canal físico?
Dentro de banda y fuera de banda
Antes de analizar estas tres técnicas por separado, conviene distinguir entre el control de flujo dentro de banda (in-band) y el control de flujo fuera de banda (out-of-band).
En cualquier mecanismo de control de flujo, el lado receptor debe enviar solicitudes o información al lado transmisor para regular el flujo de datos. En muchas situaciones prácticas existe un canal físico de datos en ambas direcciones. Es decir, el lado receptor dispone también de un canal físico equivalente en la dirección contraria para transmitir datos.
Si existe ese canal físico en la dirección contraria, la cuestión es si se utiliza para enviar las solicitudes de control de flujo. Si el canal se usa así, el mecanismo se denomina control de flujo dentro de banda (in-band flow control). En caso contrario, se aplica control de flujo fuera de banda (out-of-band flow control).
Por lo general, el control de flujo fuera de banda es una solución menos elegante, sobre todo porque requiere cables físicos adicionales. Ahora bien, si el canal del MGT es unidireccional, es la única posibilidad.
Este tema se trata con más detalle más abajo, en relación con cómo Interlaken implementa el control de flujo.
Y ahora pasemos a las tres técnicas de control de flujo.
XON / XOFF
XON / XOFF viene de transmitir activado / desactivado (transmit on / off). Es el mecanismo más sencillo de control de flujo, pero tiene algunos inconvenientes importantes.
Este método puede implementarse de muchas formas, pero la idea es siempre la misma: el receptor envía algún tipo de mensaje al transmisor que significa «deja de transmitir ahora» cuando el receptor no puede aceptar más datos. Eso es lo que significa XOFF. Más adelante, cuando el receptor pueda aceptar datos, se envía un XON para solicitar la reanudación del flujo de datos. Como estas solicitudes son sencillas, sirven tanto para transmitirlas dentro de banda como fuera de banda.
Todas las dificultades mencionadas sobre el control de flujo con un MGT se ponen de manifiesto con el método XON / XOFF. La primera dificultad es que la solicitud XOFF tarda en llegar al transmisor: el transmisor sigue enviando datos hasta que recibe esa solicitud. Además, los datos que ya están en el canal físico cuando llega la solicitud seguirán llegando al receptor.
Por tanto, el receptor debe enviar un XOFF con la antelación suficiente para poder manejar todavía los datos que lleguen después. Pero ¿cuánta antelación es suficiente? Depende del tiempo de ida y vuelta (round-trip time) del canal físico. En algunos escenarios este parámetro se conoce, o al menos se sabe que el tiempo de ida y vuelta es corto.
Por ejemplo, el protocolo SATA utiliza XON / XOFF. Esto tiene sentido, porque ese protocolo está pensado para comunicarse con discos duros, que están físicamente cerca del controlador SATA. Si la distancia entre los dos extremos es desconocida y posiblemente grande, puede resultar difícil definir el momento óptimo para solicitar un XOFF.
Otro factor es si el transmisor puede detenerse inmediatamente cuando recibe un XOFF. Por ejemplo, si el contenido transmitido consiste en paquetes, es posible que el protocolo no permita detener la transmisión a mitad de un paquete. Hay que tener en cuenta todos los escenarios a la hora de definir la condición para enviar un XOFF o un XON.
Otra cuestión es qué ocurre si el mensaje XOFF se pierde por un error de bit o por cualquier otro fallo del canal físico. Si esto ocurre, el transmisor puede continuar con el flujo de datos y provocar un desbordamiento. El protocolo debe, por tanto, garantizar que la transmisión se detenga cuando exista la posibilidad de que se haya perdido una solicitud XOFF. Véase más abajo cómo Interlaken aborda este problema.
Para resumir este mecanismo: XON / XOFF se basa en un concepto fácil, pero desgraciadamente es difícil utilizar este método para garantizar que nunca se produzca un desbordamiento, y exige prestar mucha atención a escenarios inesperados. El método de créditos, que se explica más abajo, es la imagen especular: es complicado de entender, pero alcanza su objetivo con facilidad.
XOFF limitado en el tiempo («Pause»)
El XOFF de duración limitada es una variante del método XON / XOFF: a la solicitud de control de flujo se le añade un número. Ese número indica durante cuánto tiempo debe pausar el transmisor la transmisión de datos, a partir del momento en que recibe la solicitud. Más exactamente, es el número de ciclos de reloj durante los cuales el transmisor no debe enviar datos. Este método se parece a una trama Pause de Ethernet.
La ventaja de este método es que después no hace falta un XON. Esta funcionalidad puede ser útil en algunas situaciones concretas, pero incluso en esas situaciones la ventaja es bastante pequeña.
La única razón por la que se menciona aquí el XOFF de duración limitada es que este método forma parte del protocolo Aurora.
Créditos (credits)
El mecanismo de créditos (credits) es un límite a la cantidad de elementos de datos que se permite transmitir desde que se inicializó el canal de comunicación. Ese número lo envía el receptor al transmisor mediante algún tipo de canal de control definido por el protocolo. Con ello, el receptor controla la cantidad de datos que se le envían.
Se explica mejor con un ejemplo sencillo: supongamos que el búfer del receptor puede recibir inicialmente 1000 elementos de datos. En consecuencia, envía al transmisor un mensaje diciendo que el valor de los créditos es de 1000 elementos de datos. El transmisor puede enviar 1000 elementos de datos inmediatamente, o quizás más tarde. Pero mientras los créditos no se actualicen, el número total de elementos de datos que envíe el transmisor no superará los 1000.
Pasa un tiempo y llegan al receptor 500 elementos de datos. Mientras tanto, la lógica de aplicación ha consumido 100 elementos. En esta situación hay 400 palabras de datos en el búfer, de modo que queda sitio para 600 elementos más.
En ese momento, el receptor envía otro mensaje, actualizando los créditos a 1100. Esto refleja que ya han llegado 500 elementos y que se permiten 600 más, incluso aunque la lógica de aplicación no consuma datos del búfer. Así, el búfer se llena si el transmisor ha enviado en total 1100 elementos desde el principio. Otra forma de verlo: el receptor aumenta siempre los créditos en el número de elementos que se consumen del búfer.
Este mecanismo garantiza que se evita un desbordamiento, porque el transmisor nunca envía más datos de los que el receptor permite. Hay, no obstante, dos pequeños detalles delicados con este método.
El primero es que el receptor y el transmisor deben ponerse de acuerdo en un punto de partida, en el que el número de elementos transmitidos sea cero. Esto exige algún tipo de procedimiento de inicialización, en el que ambos lados pongan sus contadores a cero. Todos los protocolos que utilizan créditos tienen algún tipo de procedimiento de arranque inicial. Esto complica el protocolo, porque los dos lados deben poder pasar de un estado a otro simultáneamente.
El segundo es que el flujo de datos debería poder continuar indefinidamente. Los créditos aumentan todo el tiempo. ¿Cómo es posible enviar los créditos como un número con un número limitado de bits? La respuesta es que basta con enviar la parte baja de la representación binaria de los créditos (es decir, solo los LSB). El transmisor utiliza el mismo número de bits para representar el número de elementos que ha transmitido.
Esto es suficiente porque el transmisor utiliza los créditos solo para calcular el número de elementos de datos que se le permite transmitir. Ese número se calcula como los créditos menos el número de elementos ya transmitidos. El resultado no puede ser mayor que el tamaño del búfer del receptor. Si ese número es menor que 2n, todos los bits por encima de los n LSB son cero. Por tanto, no tiene sentido calcularlos. Basta con hacer la resta con solo n bits. Así pues, solo se necesitan los n bits bajos de la representación binaria de los créditos en las solicitudes de control de flujo.
Por ejemplo, el control de flujo de PCIe se basa en transmitir los créditos como una palabra binaria de 8 o 12 bits, según el tipo de búfer que proteja el control de flujo.
El uso de créditos tiene muchas ventajas:
- Si se pierde una solicitud de control de flujo, no hay riesgo de desbordamiento: los créditos dan permiso para enviar más datos, al contrario que XON / XOFF, que solicitan detener la transmisión. Por tanto, si se pierde una actualización de créditos, el transmisor enviará menos de lo permitido. Como consecuencia, no puede producirse ningún desbordamiento.
- El mecanismo de créditos es eficiente, incluso cuando el retardo del canal físico es desconocido y posiblemente grande. No hace falta pausar el flujo de datos antes de tiempo para compensar el retardo de las solicitudes de control de flujo.
- El transmisor sabe de antemano si puede transmitir un paquete sin detenerse a mitad debido al control de flujo. Así es posible garantizar que los paquetes se envíen de forma continua.
Control de flujo con Interlaken
El protocolo Interlaken se presenta brevemente en otra página.
Para hablar del control de flujo, nótese que este protocolo asigna un número de canal (normalmente entre 0 y 255) a cada ráfaga de datos. En otras palabras, el protocolo se basa en el concepto de múltiples flujos de datos de aplicación que comparten el canal físico. En consecuencia, los mecanismos de control de flujo controlan cada flujo de datos de aplicación de manera independiente.
Este protocolo ofrece dos tipos de mecanismos de control de flujo: dentro de banda y fuera de banda (OOBFC). Ambos son mecanismos XON / XOFF. El estado se transmite mediante un único bit para cada canal. Ese bit vale ‘1’ cuando el canal está listo para recibir datos (XON) y ‘0’ en caso contrario (XOFF).
La diferencia entre ambos mecanismos es cómo se transmiten esos bits: el mecanismo dentro de banda se apoya en que antes y después de cada ráfaga se transmite una palabra de control. Esa palabra de control consta de 64 bits, de los cuales 16 se destinan al control de flujo. Así se permiten hasta 16 solicitudes XON / XOFF por palabra de control. Sin embargo, no basta para soportar hasta 256 canales: cada canal tiene su propio bit XON / XOFF. Para resolverlo, la información de control de flujo se divide en varias palabras de control. Este método se llama calendario (calendar). El bit 56 de la palabra de control se llama «Reset Calendar». Cuando ese bit vale ‘1’, la palabra de control contiene las solicitudes XON / XOFF de los canales 0 a 15. En la palabra siguiente se incluyen las solicitudes de los canales 16 a 31, y así sucesivamente. Cuando se han cubierto todos los canales (posiblemente con una sola palabra de control), la secuencia se reinicia con ayuda de «Reset Calendar».
Cuando se detecta un error de bit gracias al CRC24 de la ráfaga, todos los canales pasan al estado XOFF. La razón es que el CRC24 cubre también la palabra de control, de modo que la parte de control de flujo se ignora si se detecta un error. Por tanto, no es seguro transmitir en ningún canal después de que ocurra un evento de ese tipo. El funcionamiento normal se reanuda gradualmente según las solicitudes de control de flujo de las palabras de control siguientes.
El principal inconveniente del control de flujo dentro de banda es que la entrega de las solicitudes XON / XOFF depende de las ráfagas de datos que se transmiten en el mismo sentido. Si esas ráfagas son largas, o si no se transmite ninguna ráfaga durante un tiempo, la entrega de XON / XOFF puede tardar más. Esto se puede justificar en parte, porque es inevitable que el transporte de datos y los mensajes de control de flujo enviados por el mismo canal físico compitan por el ancho de banda. Sin embargo, otros protocolos suelen priorizar los mensajes de control de flujo de manera que se garantice un retardo máximo constante.
La alternativa de control de flujo fuera de banda (OOBFC) evita la competencia con las ráfagas de datos. Con este método, las solicitudes XON / XOFF se transmiten por tres cables físicos adicionales (FC_CLK, FC_DATA y FC_SYNC). Los bits XON / XOFF de todos los canales se transmiten en una sola trama larga.
La señal FC_SYNC se pone a nivel alto junto con el primer bit de esa trama. La frecuencia de FC_CLK está entre 0 y 100 MHz y se permite el uso de reloj DDR. Se inserta un CRC de 4 bits (CRC-4) después de 64 solicitudes XON / XOFF o después de la última. Si se detecta un error gracias al CRC, todos los canales pasan al estado XOFF.
La elección entre control de flujo dentro de banda y fuera de banda depende, por supuesto, de los requisitos del proyecto.
Interlaken no incluye ningún mecanismo para multiplexar los datos de los canales. Por tanto, es tarea de la lógica de aplicación arbitrar entre las solicitudes de transmisión de los canales y elegir qué canal accede a transmitir una ráfaga (o un paquete completo). Por consiguiente, la lógica de aplicación es también responsable de pausar la transmisión de un canal cuando un XOFF lo exija. La lógica que implementa el protocolo Interlaken solo se encarga de enviar y recibir solicitudes XON / XOFF.
El protocolo menciona los créditos como una posibilidad para implementar control de flujo, pero solo como una invitación abierta a implementar ese método mediante canales dedicados. No hay detalles en el protocolo sobre cómo implementarlo.
Control de flujo con Aurora
El protocolo Aurora se presenta brevemente en otra página. Este protocolo propone dos mecanismos para facilitar el control de flujo: NFC y UFC. A continuación se describen por separado.
Primero, el control de flujo nativo (Native Flow Control, NFC): con este mecanismo, la lógica de aplicación del lado receptor dispone de una interfaz para enviar solicitudes de control de flujo al transmisor. Estas solicitudes tienen dos partes separadas: un bit XOFF y una parte de XOFF limitado en el tiempo («pause») (ambos conceptos se explican más arriba). La lógica del protocolo en el lado transmisor es responsable de obedecer estas solicitudes: si el bit XOFF es ‘0’, el transmisor pausa la transmisión de datos durante el número de ciclos de reloj que corresponda al número de 8 bits incluido en la solicitud de control de flujo. Si ese número es cero, la transmisión de datos se reanuda inmediatamente. Los números de las solicitudes no se acumulan. Más bien, cada solicitud NFC actualiza la cuenta atrás de la pausa con un valor nuevo.
Si el bit XOFF es ‘1’, el transmisor pausa la transmisión de datos indefinidamente. El transmisor solo reanuda la transmisión en respuesta a una solicitud de control de flujo con XOFF = ‘0’. Esa solicitud se procesa como se ha dicho antes.
Nótese que este mecanismo de control de flujo controla todo el tráfico de datos por el canal físico. Por tanto, NFC no es adecuado para controlar individualmente varios canales, si los hay.
El segundo mecanismo es el control de flujo de usuario (User Flow Control, UFC): en la práctica, es un canal aparte para enviar mensajes de hasta 256 bytes al otro lado. Los mensajes UFC tienen una prioridad mayor que la transmisión de datos, de modo que llegan al otro lado con poca latencia.
Como el protocolo no define el formato de estos mensajes, pueden utilizarse para implementar cualquier tipo de control de flujo. Esa implementación se hace completamente en la lógica de aplicación. Los mensajes UFC pueden utilizarse también para transmitir cualquier otro tipo de información de estado.
Nótese que ninguno de los mensajes utilizados en estos dos mecanismos de control de flujo está protegido contra los errores de bit en el enlace físico. Una solicitud de control de flujo puede, por tanto, llegar incorrectamente o no llegar en absoluto, lo que posiblemente provoque un desbordamiento en el receptor.
Como ambos mecanismos de control de flujo se basan en el enlace de datos en la dirección contraria, solo están disponibles en modo full duplex.
Resumen
En esta página se han presentado principalmente dos técnicas de control de flujo: XON / XOFF y créditos. En los protocolos relacionados con ordenadores (por ejemplo, PCIe, SuperSpeed USB y SATA), el control de flujo lo implementa la lógica del protocolo. En cambio, en los protocolos pensados para la comunicación entre FPGAs, la lógica de aplicación es responsable de toda la implementación o de la mayor parte. La única excepción es Xillyp2p, que se ocupa de todos los aspectos de la comunicación de datos, incluidos el control de flujo, la detección de errores y la retransmisión.
Se han presentado las funcionalidades relacionadas con el control de flujo de dos protocolos para FPGAs: Interlaken y Aurora. Como se ha mostrado, estos protocolos dejan la mayor parte de la carga de implementar el control de flujo a la lógica de aplicación, aunque las capacidades propias de los protocolos pueden hacer parte del trabajo en ciertos escenarios de uso.
Con esto concluye la última página de esta serie sobre los MGT.