Liste des protocoles de communication entre FPGA avec des transcepteurs multi-gigabits

Cette page est la deuxième d’une série de pages présentant le transcepteur multi-gigabits (MGT).

Introduction

Les transcepteurs multi-gigabits (MGT) constituent la brique de base de nombreux protocoles bien connus : PCIe, SATA, Gigabit Ethernet, SuperSpeed USB, Thunderbolt et DisplayPort. Tous ces protocoles ont un point commun : un ordinateur est impliqué. Il existe également plusieurs protocoles de télécommunications destinés à transporter des appels téléphoniques sur une liaison par fibre optique.

Les MGT sont également utiles pour échanger des données entre deux FPGA. Quelques points à connaître lorsqu’on utilise un MGT à cette fin sont énumérés sur une page précédente. Il faut de toute évidence une forme ou une autre de protocole pour garantir que les données soient transmises correctement et avec une fiabilité acceptable sur le canal physique. La mise en œuvre d’un tel protocole est assez compliquée ; la question est donc de savoir s’il existe des protocoles prêts à l’emploi ou d’autres briques susceptibles d’aider.

Cette page tente de résumer les principales alternatives. Elles sont présentées ci-dessous par ordre croissant de complexité de la logique applicative, la moins complexe en premier.

Tous les protocoles ci-dessous peuvent fonctionner aussi bien en liaison bidirectionnelle (full duplex) qu’en liaison unidirectionnelle (half duplex), sauf indication contraire.

Xillyp2p

Xillyp2p est un protocole propriétaire qui assure un transport fiable de plusieurs flux de données entre deux FPGA. Le protocole gère la transmission, l’ordonnancement, la retransmission et le contrôle de flux (flow control) des données applicatives, à la manière dont TCP/IP transporte des données sur un réseau : il est garanti que toutes les données arrivent correctement de l’autre côté.

La logique applicative interagit avec l’implémentation du protocole par l’intermédiaire de FIFO standard. Le protocole crée l’illusion d’une FIFO standard qui relie les deux FPGA : le côté écriture de cette FIFO virtuelle se trouve sur un FPGA et le côté lecture sur l’autre FPGA.

Dans chacun des deux FPGA, un côté de la FIFO est connecté à la logique applicative et l’autre côté interagit avec la logique du protocole. Ainsi, la logique applicative du côté émetteur écrit des données dans une FIFO, et la logique applicative du côté récepteur lit des données dans une autre FIFO. Le protocole a pour rôle de transférer les données de la FIFO située dans le FPGA émetteur vers la FIFO située dans le FPGA récepteur. Le contrôle de flux du protocole garantit que la FIFO du FPGA destinataire ne devienne jamais full (pleine).

Le protocole peut desservir plusieurs FIFO dans les deux directions. Un ordonnanceur équitable de transmission garantit une utilisation efficace de la bande passante du MGT. Les données de la FIFO du côté émetteur sont consommées assez rapidement, de sorte que cette FIFO ne devienne pas full (pleine), à condition que la bande passante le permette et que les données soient consommées depuis la FIFO de l’autre côté.

Le protocole propose également une interface distincte pour la transmission de paquets (à l’aide d’un port EOP).

Une option half-duplex est également prise en charge. Dans ce cas, le protocole garantit que toutes les données reçues sont correctes. Si une erreur binaire se produit sur le canal physique, le flux de données est interrompu avant que les données erronées n’atteignent la logique applicative.

Gigabit Ethernet

Bien que Gigabit Ethernet soit destiné à la communication entre ordinateurs, il est possible d’utiliser ce protocole simple pour envoyer des paquets entre deux FPGA. Un cœur IP adapté (IP core) est généralement fourni par le fabricant du FPGA. La logique applicative est donc chargée de créer et de recevoir les paquets Ethernet via l’une des interfaces standard (GMII, RGMII, XGMII, etc.).

Comme pour toute liaison Ethernet, c’est à la logique applicative qu’il revient d’organiser les données en paquets et de gérer les erreurs sur la liaison (par exemple au moyen d’une retransmission).

Interlaken

Interlaken est un protocole ouvert pour la communication de paquets entre puces. Il repose sur le codage 64b/67b : le flux de données de bas niveau consiste à transmettre en continu des segments de 64 bits. Avant chaque segment, 3 bits sont ajoutés afin de distinguer les données applicatives des mots de contrôle. Le protocole est défini pour une liaison simplex (canal physique unidirectionnel). Si l’on utilise une liaison full duplex (canal physique bidirectionnel), le fonctionnement est identique à celui d’une liaison simplex, à ceci près que des messages de contrôle de flux (flow control) peuvent être envoyés dans le sens opposé.

L’unité de transmission de base du protocole est une rafale (burst) de longueur variable. Un mot de contrôle est transmis immédiatement avant et après chacune de ces rafales. Ces deux mots de contrôle contiennent des informations qui fournissent une abstraction des paquets et des canaux. On y trouve notamment :

• Numéro de canal : un nombre compris entre 0 et 255, qui associe la rafale de données suivante à un canal. Il est possible d’étendre le nombre de canaux jusqu’à 65 536.
• SOP : un indicateur (flag) signalant que les données qui suivent correspondent au début d’un paquet.
• EOP : un indicateur signalant que les données qui précèdent le mot de contrôle correspondent à la fin d’un paquet. L’EOP indique également le nombre d’octets valides dans le dernier mot de la rafale, ainsi que la présence éventuelle d’erreurs dans le paquet.

La longueur de chaque rafale ne doit pas dépasser BurstMax ni être inférieure à BurstShort. BurstShort et BurstMax sont des paramètres choisis pour une application donnée. BurstShort est d’au moins 32 octets (et doit être un multiple de 8), et BurstMax doit être un multiple de 64 octets.

Le contenu du mot de contrôle et de la rafale de données qui le précède éventuellement est vérifié pour détecter d’éventuelles erreurs binaires au moyen d’un CRC24.

Si une rafale échoue au test CRC24 (c’est-à-dire si une erreur binaire est détectée), une retransmission peut être demandée, comme défini dans le document de définition de l’extension de retransmission Interlaken (Interlaken Retransmit Extension Protocol Definition). Selon le mécanisme proposé, cette demande est envoyée du récepteur vers l’émetteur au moyen de trois fils physiques distincts. Ces fils portent les noms FC_CLK, FC_DATA et FC_SYNC, et sont à l’origine prévus pour le contrôle de flux hors bande (out-of-band flow control, OOBFC). Un protocole simple de transmission série est défini pour l’envoi des demandes de contrôle de flux. Si la retransmission est activée, l’un de ces bits, appelé « RT », sert à demander une retransmission. En d’autres termes, le protocole ne définit pas de moyen d’envoyer la demande de retransmission sur la liaison MGT elle-même, mais plutôt sur les trois fils physiques hors bande distincts.

La demande de retransmission ne précise pas à partir de quelle rafale la retransmission doit commencer. Le côté émetteur doit plutôt conserver une quantité définie de données de rafales dans un tampon (buffer). Lorsqu’une demande de retransmission arrive, toutes les rafales contenues dans le tampon sont retransmises. Le tampon doit donc être assez grand pour contenir la rafale perdue. En revanche, s’il est trop grand, les retransmissions seront plus longues que nécessaire. Pour définir la taille du tampon, il faut calculer soigneusement le temps d’aller-retour (round-trip time) entre la remise d’une rafale à la logique qui implémente le protocole Interlaken et l’arrivée d’une demande de retransmission.

Le récepteur détecte les rafales retransmises à l’aide d’un compteur qui est incrémenté pour chaque rafale transmise pour la première fois (il est aussi possible de l’incrémenter toutes les 2, 4, 8 rafales, etc.). La valeur de ce compteur est transmise dans la partie à usages multiples (Multiple-Use) des mots de contrôle émis avant et après chaque rafale. Le récepteur utilise ce compteur pour distinguer une nouvelle rafale d’une rafale retransmise.

Le protocole Interlaken comporte également un contrôle CRC32 à des fins de diagnostic (une fois par Meta Frame). Toutefois, si une erreur est détectée grâce à ce test, elle concerne un large segment de données et non une rafale ou un paquet précis. En d’autres termes, si des données ont passé le test CRC24 malgré une erreur binaire, l’erreur ne sera détectée que plus tard, sans qu’il soit possible d’identifier la rafale qui contient les données erronées.

Il est possible de concevoir et de mettre en œuvre un mécanisme de retransmission qui s’appuie sur le flux de données du MGT dans l’autre sens. Le protocole Interlaken ne propose pas de méthode pour un tel mécanisme, mais il est néanmoins possible de réserver un canal dédié aux paquets demandant une retransmission. Une telle solution peut présenter un avantage significatif, car elle permet de demander plus précisément ce qui doit être retransmis. Il est également possible d’appliquer un meilleur CRC, éventuellement sur des paquets plutôt que sur des rafales. En revanche, si l’on opte pour cette approche, tout le mécanisme doit être implémenté dans la logique applicative.

Les mécanismes de contrôle de flux d’Interlaken sont présentés sur une page séparée.

Aurora

Aurora est un protocole développé par Xilinx (désormais AMD) pour ses propres FPGA. L’unité de transmission de base de ce protocole est un mot unique (dont la largeur est fixe et dépend du nombre de MGT utilisés). Le protocole prend toutefois aussi en charge la transmission de paquets (appelés trames). La logique applicative découpe le flux de données en paquets grâce à une entrée « last ».

Il existe deux variantes d’Aurora : avec le codage 8b/10b et avec le codage 64b/66b. Le codage 64b/66b est plus efficace, il faut donc privilégier cette variante lorsque c’est possible.

Aurora est défini pour une liaison simplex (canal physique unidirectionnel) ainsi que pour une liaison full duplex (canal physique bidirectionnel). Du point de vue de la logique applicative, la différence entre les deux options est négligeable, si ce n’est que le contrôle de flux (flow control) n’a pas de sens sur une liaison simplex.

À noter que, contrairement à Interlaken, le protocole Aurora ne mentionne aucun canal. Autrement dit, toutes les données transmises sur le canal physique appartiennent à un seul et même flux de données. Dans la terminologie du protocole, le mot « canal » désigne le canal physique, et non une division des données en flux indépendants. Si une telle division est souhaitée, c’est à la logique applicative de la mettre en œuvre, éventuellement en ajoutant un en-tête à chaque paquet.

Le protocole ne corrige pas les erreurs binaires sur le canal physique. Toutefois, lorsque le protocole est utilisé pour transmettre des paquets, l’émetteur peut éventuellement ajouter un CRC à la fin de chaque paquet (dans l’implémentation de Xilinx). L’implémentation du protocole vérifie ce CRC du côté récepteur et informe la logique applicative si une erreur a été détectée dans le paquet. Si Aurora est utilisé sans paquets (sans signal « last »), la détection d’erreur n’est pas prise en charge par le protocole.

Les informations de contrôle propres au protocole sont transmises sans aucune protection contre les erreurs binaires. Aucun CRC n’est appliqué à ce type de trafic. S’il y a des erreurs binaires sur la liaison physique, le protocole peut présenter toutes sortes de dysfonctionnements.

La logique applicative doit mettre en œuvre tout mécanisme de retransmission, de multiplexage de canaux multiples ou d’ordonnancement de transmission éventuel. Une page séparée traite des possibilités de mise en œuvre du contrôle de flux avec Aurora.

Serial Lite

Altera propose une série de protocoles et de cœurs IP (IP cores) portant le nom de Serial Lite :

• SerialLite II : interface avec ou sans paquets pour la réception et la transmission de données (appelée « Atlantic Interface »). Prend en charge la retransmission en réponse aux erreurs binaires. Ne s’applique qu’aux FPGA plus anciens (des Arria II jusqu’aux FPGA de la série V).
• Serial Lite III : prend en charge les modes continu (Continuous) et rafale (Burst). En mode continu, le flux de données peut s’écouler sans interruption ni espace entre l’émetteur et le récepteur. Cela exige que les deux côtés utilisent la même horloge de référence. Ce protocole s’appuie en interne sur Interlaken, mais sans prendre en charge les canaux ni les signaux SOP/EOP. Par conséquent, la largeur de l’interface est de 64 bits multipliés par le nombre de MGT utilisés. Les erreurs binaires sur la liaison physique sont signalées comme un événement de diagnostic associé au MGT qui les a causées, et non à un segment de données particulier. S’applique aux FPGA de la série V et aux FPGA de la série 10.
• Serial Lite IV : basé sur l’interface streaming Avalon, avec des signaux de début et de fin de paquets (MAC). Un CRC peut être inséré en option à la fin des paquets par l’émetteur, puis vérifié par le récepteur. Il existe également un mode Basic, sans division en paquets. S’applique à Stratix 10 et Agilex E-tile.

Les cœurs IP ne sont pas compatibles entre les différents membres de cette série de protocoles. Seul SerialLite II peut lancer des retransmissions.

RapidIO

RapidIO est un protocole à base de paquets, comparable à PCIe dans la mesure où les types de paquets qu’il prend en charge correspondent à des opérations demandées par un processeur, notamment :

• Écriture (Write) : écrit des données à une adresse. Il existe plusieurs variantes de cette opération, dont l’une exige une réponse indiquant que l’opération a été effectuée.
• Lecture (Read) : une demande de lecture de données à une adresse. Un paquet de réponse est envoyé par la cible en réponse à cette demande.
• Lecture-modification-écriture atomique (Atomic read-modify-write) : demande d’écrire des données à une adresse après avoir lu l’ancienne valeur, comme opération atomique. Parmi les opérations prises en charge : incrément atomique et décrément atomique, échange atomique, comparaison et échange (compare and swap), etc.
• Plusieurs demandes de maintenance pour la découverte, le contrôle et l’état. Comme l’espace de registres de configuration du protocole PCI, ces demandes de maintenance accèdent aux registres de capacité (capability registers, CAR) et aux registres de commande et d’état (command and status registers, CSR).

La principale différence fonctionnelle entre RapidIO et PCIe est que le protocole PCIe exige qu’une unité centrale (un Root Complex, généralement un processeur) configure tous les endpoints du système. Un système RapidIO ne nécessite pas une telle unité centrale.

Une autre différence avec PCIe est que la retransmission des paquets est facultative. Une retransmission n’a lieu que pour les paquets envoyés en « trafic fiable » (reliable traffic, RT). Les paquets peuvent aussi être envoyés en « trafic continu » (continuous traffic, CT). Ces derniers ne sont ni acquittés ni retransmis.

Le protocole RapidIO définit tous les aspects de la communication, depuis la spécification électrique jusqu’aux formats de paquets, à la retransmission et au contrôle de flux (flow control).

RapidIO n’est peut-être pas un candidat très attrayant pour une simple connexion point à point entre deux FPGA, en raison de la complexité de ce protocole. RapidIO peut être plus adapté comme interconnexion entre plusieurs FPGA via un commutateur (switch), en particulier si PCIe ne convient pas parce qu’il exige un processeur dans le système.

Résumé

Plusieurs protocoles de transmission de données applicatives ont été présentés. Chacun propose différentes méthodes pour mettre en œuvre le transport des données, contrôler son flux et réagir aux erreurs binaires (le cas échéant). Le bon protocole pour une application est un compromis entre les fonctionnalités offertes par le protocole et l’effort nécessaire pour implémenter dans la logique applicative les éléments manquants.

Ceci conclut la deuxième page de cette série consacrée aux MGT. La page suivante présente quelques méthodes de codage souvent utilisées avec les MGT.