Contrôle de flux : méthodes et protocoles pour MGT

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

Introduction

Le contrôle de flux (flow control) est un mécanisme souvent utilisé dans différents types de liaisons de données. Son but est d’éviter une situation où la quantité de données transmises dépasse ce que le côté récepteur peut absorber.

Les protocoles liés aux MGT offrent différents niveaux de prise en charge de cette fonctionnalité. Par exemple, la logique qui implémente le protocole PCIe n’accepte jamais un paquet pour la transmission si les tampons (buffers) du destinataire sont pleins. La logique applicative qui utilise le protocole PCIe n’a rien à implémenter à cet égard. En effet, l’interface entre la logique applicative et la logique du protocole PCIe permet à celui-ci de refuser temporairement d’accepter de nouvelles données (par exemple à l’aide des ports AXI-S tels que VALID et READY). De même, la logique applicative est autorisée à refuser temporairement d’accepter des données provenant de l’autre côté. Ce faisant, la logique applicative se protège contre un débordement (overflow).

Il ne faut pas confondre le contrôle de flux avec les mécanismes qui évitent le débordement du tampon élastique (elastic buffer) propre au MGT. Le contrôle de flux n’a rien à voir avec les symboles Skip mentionnés sur la page consacrée aux tampons du MGT. Le contrôle de flux protège plutôt les tampons de la logique applicative. Et comme il existe souvent plusieurs canaux de données qui se partagent le MGT en tant que ressource commune, le contrôle de flux est appliqué à chacun de ces canaux séparément et indépendamment.

D’une manière générale, les protocoles qui définissent une communication avec un ordinateur prennent en charge le mécanisme de contrôle de flux. La logique applicative n’a alors qu’à s’interfacer avec la logique du protocole au moyen de simples ports de poignée de main (handshake), comme avec beaucoup d’autres blocs logiques. Outre PCIe, SuperSpeed USB et SATA gèrent eux-mêmes le contrôle de flux.

Malheureusement, les protocoles de communication entre FPGA ne prennent généralement pas en charge le contrôle de flux à ce niveau. Le seul protocole qui prend entièrement en charge le contrôle de flux est Xillyp2p. Les autres protocoles pour FPGA ne possèdent que quelques fonctionnalités qui peuvent aider à mettre en œuvre le contrôle de flux dans la logique applicative.

Cette page passe en revue quelques techniques de mise en œuvre du contrôle de flux. Un bref résumé de la manière dont Aurora et Interlaken aident pour le contrôle de flux est donné plus bas. Il est néanmoins important de se rappeler que, sauf lorsqu’on utilise Xillyp2p, c’est à la logique applicative qu’il incombe d’éviter un débordement.

Techniques de contrôle de flux

L’objectif ultime du contrôle de flux est d’éviter que le côté qui reçoit des données en reçoive plus qu’il ne peut en traiter. En général, le côté récepteur stocke les données qui arrivent dans des tampons (buffers) ou une FIFO, ce qui revient donc à garantir qu’il reste de la place dans ces tampons pour toutes les données qui arrivent.

Le contrôle de flux est plus difficile à mettre en œuvre pour les MGT, principalement parce que le canal physique présente un délai important. Il faut donc un certain temps pour que la demande d’arrêter la transmission parvienne à l’émetteur. De plus, il s’écoule un certain temps entre le moment où l’émetteur cesse d’émettre et le moment où les données cessent d’arriver au récepteur.

Une autre difficulté propre aux MGT est qu’une erreur binaire sur le canal physique peut entraîner la perte d’une demande d’arrêt de transmission.

Outre ces deux difficultés, le débit des MGT est élevé, et l’on s’attend généralement à utiliser ce canal physique de manière efficace.

Par rapport à des canaux de communication plus simples, comme un port série (RS-232), le contrôle de flux pour un MGT doit être plus sophistiqué afin de garantir qu’aucun débordement ne se produise. Les trois techniques suivantes sont présentées ci-dessous :

• XON / XOFF
• XOFF limité dans le temps (« Pause »)
• Crédits (credits)

Lorsqu’on envisage un protocole pour un projet, il est important de se poser les deux questions suivantes :

• Que doit implémenter la logique applicative en matière de contrôle de flux ? La réponse est peut-être que rien ne doit être implémenté, comme avec PCIe, SuperSpeed USB et Xillyp2p.
• Si les données applicatives appartiennent à des canaux différents : le mécanisme de contrôle de flux permet-il de mettre en pause la communication sur chaque canal séparément, ou affecte-t-il tout le trafic du canal physique ?

Dans la bande et hors bande

Avant d’examiner séparément ces trois techniques, il est important de distinguer le contrôle de flux dans la bande (in-band) du contrôle de flux hors bande (out-of-band).

Dans tout mécanisme de contrôle de flux, le côté récepteur doit envoyer des demandes ou des informations au côté émetteur afin de réguler le flux de données. Dans de nombreux scénarios pratiques, il existe un canal physique de données dans les deux sens. Autrement dit, le côté récepteur dispose lui aussi d’un canal physique équivalent dans le sens opposé pour transmettre des données.

Si un tel canal physique dans le sens opposé existe, la question est de savoir s’il sert à envoyer des demandes de contrôle de flux. Si c’est le cas, le mécanisme est appelé contrôle de flux dans la bande. Dans le cas contraire, on parle de contrôle de flux hors bande.

D’une manière générale, le contrôle de flux hors bande est une solution moins élégante, notamment parce qu’il exige des fils physiques séparés à cette fin. Toutefois, si le canal du MGT est unidirectionnel, c’est la seule possibilité.

Ce sujet est approfondi plus bas à propos de la manière dont Interlaken met en œuvre le contrôle de flux.

Et maintenant, passons aux trois techniques de contrôle de flux.

XON / XOFF

XON / XOFF signifie « transmit on / off », c’est-à-dire activation / désactivation de la transmission. C’est le mécanisme de contrôle de flux le plus simple, mais il présente quelques défauts notables.

Cette méthode peut être mise en œuvre de nombreuses manières, mais l’idée est toujours la même : le récepteur envoie à l’émetteur une sorte de message signifiant « arrête maintenant d’émettre » lorsqu’il ne peut plus accepter de données. C’est ce que signifie XOFF. Plus tard, lorsque le récepteur peut de nouveau accepter des données, un XON est envoyé pour demander la reprise du flux. Ces demandes étant simples, elles se prêtent aussi bien à une transmission dans la bande que hors bande.

Toutes les difficultés mentionnées ci-dessus à propos du contrôle de flux avec un MGT se manifestent avec la méthode XON / XOFF. La première difficulté est qu’il faut un certain temps pour que la demande XOFF parvienne à l’émetteur : l’émetteur continue d’envoyer des données jusqu’à la réception de cette demande. De plus, les données qui se trouvent déjà sur le canal physique au moment où la demande arrive continueront d’arriver au récepteur.

Le récepteur doit donc envoyer un XOFF assez tôt pour que les données qui arrivent ensuite puissent encore être traitées. Mais à quel point faut-il être assez tôt ? Cela dépend du temps d’aller-retour (round-trip time) du canal physique. Dans certains scénarios, ce paramètre est connu, ou du moins on sait que le temps d’aller-retour est court.

Par exemple, le protocole SATA utilise XON / XOFF. Cela a du sens, car ce protocole est destiné à la communication avec des disques durs, qui se trouvent physiquement près du contrôleur SATA. Si la distance entre les deux partenaires de la liaison est inconnue et potentiellement grande, il peut être difficile de définir un moment optimal pour demander un XOFF.

Autre facteur à prendre en compte : l’émetteur peut-il s’arrêter immédiatement lorsqu’il reçoit un XOFF ? Par exemple, lorsque le contenu transmis est constitué de paquets, le protocole peut ne pas permettre d’interrompre la transmission au milieu d’un paquet. Tous les scénarios doivent être pris en compte pour définir la condition d’envoi d’un XOFF ou d’un XON.

Autre problème : que se passe-t-il si le message XOFF est perdu à cause d’une erreur binaire ou d’un autre défaut du canal physique ? Dans ce cas, l’émetteur peut poursuivre le flux de données, provoquant un débordement. Le protocole doit donc garantir que la transmission est interrompue lorsqu’il y a une possibilité qu’une demande XOFF ait été perdue. Voir plus bas comment Interlaken aborde ce problème.

Résumons ce mécanisme : XON / XOFF repose sur un concept simple, mais il est malheureusement difficile d’utiliser cette méthode pour garantir qu’un débordement ne se produise jamais, car elle exige une attention particulière aux scénarios imprévus. La méthode des crédits (credits), présentée plus bas, en est l’image inversée : difficile à comprendre, mais simple à mener à son but.

XOFF limité dans le temps (« Pause »)

Le XOFF limité dans le temps est une variante de la méthode XON / XOFF : un nombre est joint à la demande de contrôle de flux. Ce nombre indique pendant combien de temps l’émetteur doit faire une pause dans la transmission des données, à partir du moment où il reçoit cette demande. Plus précisément, c’est le nombre de cycles d’horloge pendant lesquels l’émetteur ne doit pas envoyer de données. Cette méthode ressemble à une trame Pause Ethernet.

L’avantage de cette méthode est qu’un XON n’est pas nécessaire par la suite. Cette particularité peut être utile dans certaines situations précises, mais l’avantage reste alors assez mince.

La seule raison pour laquelle le XOFF limité dans le temps est mentionné ici est que cette méthode fait partie du protocole Aurora.

Crédits (credits)

Les crédits (credits) constituent une limite sur le nombre d’éléments de données qu’il est permis de transmettre depuis l’initialisation du canal de communication. Ce nombre est envoyé du récepteur à l’émetteur par l’intermédiaire d’une sorte de canal de contrôle défini par le protocole. Le récepteur contrôle ainsi la quantité de données qui lui sont envoyées.

Un exemple simple permettra de mieux comprendre : supposons que le tampon du récepteur puisse initialement recevoir 1000 éléments de données. Le récepteur envoie donc à l’émetteur un message indiquant que le crédit est de 1000 éléments de données. L’émetteur peut envoyer 1000 éléments immédiatement, ou peut-être plus tard. Toutefois, tant que le crédit n’est pas mis à jour, le nombre total d’éléments envoyés par l’émetteur ne dépasse pas 1000.

Quelque temps passe, et 500 éléments sont arrivés au récepteur. Pendant ce temps, la logique applicative en a consommé 100. Dans cette situation, le tampon contient 400 mots de données, il y a donc de la place pour 600 éléments supplémentaires dans le tampon.

À ce stade, le récepteur envoie un autre message, portant le crédit à 1100. Cela reflète le fait que 500 éléments sont déjà arrivés et que 600 autres sont autorisés, même si la logique applicative ne consomme aucune donnée du tampon. Le tampon est donc rempli lorsque l’émetteur a envoyé au total 1100 éléments depuis le début. Autre façon de voir les choses : le récepteur augmente toujours le crédit du nombre d’éléments consommés depuis le tampon.

Ce mécanisme garantit l’absence de débordement, car l’émetteur n’envoie jamais plus de données que ce que le récepteur autorise. Deux petits points délicats subsistent toutefois avec cette méthode.

Le premier point est que le récepteur et l’émetteur doivent se mettre d’accord sur un point de départ où le nombre d’éléments transmis est nul. Cela exige une sorte de procédure d’initialisation, où les deux côtés remettent leurs compteurs à zéro. Tous les protocoles qui utilisent des crédits comportent une procédure initiale de ce genre. Cela complique le protocole, car les deux côtés doivent être capables de changer d’état simultanément.

Le second point est que le flux de données doit pouvoir se poursuivre indéfiniment. Le crédit ne cesse d’augmenter. Comment est-il possible d’envoyer le crédit sous la forme d’un nombre dont la représentation binaire a un nombre limité de bits ? La réponse est qu’il suffit d’envoyer la partie basse de la représentation binaire du crédit (c’est-à-dire uniquement les bits de poids faibles, LSbs). L’émetteur utilise le même nombre de bits pour représenter le nombre d’éléments de données qu’il a transmis.

Cela suffit, car l’émetteur n’utilise le crédit que pour calculer le nombre d’éléments de données qui peuvent encore être transmis. Ce nombre se calcule comme le crédit moins le nombre d’éléments déjà transmis. Le résultat ne peut pas dépasser la taille du tampon du récepteur. Si ce nombre est inférieur à 2ⁿ, tous les bits au-dessus des n bits de poids faible sont nuls. Il est donc inutile de les calculer. Il suffit d’effectuer la soustraction sur n bits seulement. Par conséquent, seuls les n bits de poids faible de la représentation binaire du crédit sont nécessaires dans les demandes de contrôle de flux.

Par exemple, le contrôle de flux de PCIe repose sur la transmission du crédit sous la forme d’un mot binaire de 8 bits ou de 12 bits, selon le type de tampon que le contrôle de flux protège.

L’utilisation de crédits présente de nombreux avantages :

• Si une demande de contrôle de flux est perdue, il n’y a pas de risque de débordement : le crédit donne la permission d’envoyer davantage de données, contrairement à XON / XOFF qui demande d’arrêter la transmission. Par conséquent, si une mise à jour du crédit est perdue, l’émetteur enverra moins que ce qui est autorisé. Aucun débordement ne peut en résulter.
• Le mécanisme de crédits est efficace, même lorsque le délai du canal physique est inconnu et potentiellement grand. Il n’est pas nécessaire de faire une pause préventive dans le flux de données pour compenser le délai des demandes de contrôle de flux.
• L’émetteur sait à l’avance s’il peut transmettre un paquet sans avoir à s’arrêter au milieu à cause du contrôle de flux. Il est donc possible de garantir une émission continue des paquets.

Contrôle de flux avec Interlaken

Le protocole Interlaken est brièvement présenté sur une autre page.

Dans le cadre du contrôle de flux, notons que ce protocole attribue un numéro de canal (généralement entre 0 et 255) à chaque rafale (burst) de données. Autrement dit, le protocole repose sur le concept de plusieurs flux de données applicatives se partageant le canal physique. En conséquence, les mécanismes de contrôle de flux contrôlent chaque flux de données applicatives indépendamment.

Ce protocole propose deux types de mécanismes de contrôle de flux : le contrôle de flux dans la bande (in-band) et le contrôle de flux hors bande (out-of-band flow control, OOBFC). Les deux sont des mécanismes XON/XOFF. L’état est transmis au moyen d’un unique bit pour chaque canal. Ce bit vaut « 1 » lorsque ce canal est prêt à recevoir des données (XON), et « 0 » sinon (XOFF).

La différence entre ces deux mécanismes réside dans la manière dont ces bits sont transmis : le contrôle de flux dans la bande s’appuie sur le fait qu’un mot de contrôle est transmis avant et après chaque rafale. Ce mot de contrôle comporte 64 bits, dont 16 bits sont réservés au contrôle de flux. Cela permet jusqu’à 16 demandes XON / XOFF par mot de contrôle. Cela ne suffit toutefois pas pour prendre en charge jusqu’à 256 canaux : chaque canal possède son propre bit XON / XOFF. Pour résoudre ce problème, les informations de contrôle de flux sont réparties sur plusieurs mots de contrôle. Cette méthode est appelée le calendrier (calendar). Le bit 56 du mot de contrôle s’appelle « Reset Calendar ». Lorsque ce bit vaut « 1 », le mot de contrôle contient les demandes XON / XOFF relatives aux canaux 0 à 15. Dans le mot de contrôle qui suit, on trouve les demandes pour les canaux 16 à 31, et ainsi de suite. Lorsque tous les canaux ont été couverts (éventuellement avec un seul mot de contrôle), la séquence est redémarrée grâce à « Reset Calendar ».

Lorsqu’une erreur binaire est détectée grâce au CRC24 de la rafale, tous les canaux passent à l’état XOFF. La raison est que le CRC24 couvre également le mot de contrôle ; la partie contrôle de flux est donc ignorée si une erreur est détectée. Il n’est donc pas prudent de transmettre sur un canal après un tel événement. Le fonctionnement normal reprend progressivement en fonction des demandes de contrôle de flux contenues dans les mots de contrôle qui suivent.

Le principal inconvénient du contrôle de flux dans la bande est que l’acheminement des demandes XON / XOFF dépend des rafales de données transmises dans le même sens. Si ces rafales sont longues, ou si aucune rafale n’est transmise pendant un certain temps, l’acheminement des XON / XOFF peut prendre plus de temps. Cela peut être en partie justifié, car il est inévitable que le transport des données et les messages de contrôle de flux envoyés sur le même canal physique se disputent la bande passante. Toutefois, d’autres protocoles donnent généralement la priorité aux messages de contrôle de flux afin de garantir un délai maximal constant.

La solution du contrôle de flux hors bande (OOBFC) évite la concurrence avec les rafales de données. Avec cette méthode, les demandes XON / XOFF sont transmises par l’intermédiaire de trois fils physiques supplémentaires (FC_CLK, FC_DATA et FC_SYNC). Les bits XON / XOFF de tous les canaux sont transmis dans une seule longue trame.

Le signal FC_SYNC est au niveau haut pendant le premier bit de cette trame. La fréquence de FC_CLK est comprise entre 0 et 100 MHz, et une horloge DDR est autorisée. Un CRC de 4 bits (CRC-4) est inséré après 64 demandes XON / XOFF ou après la dernière. Si une erreur est détectée grâce au CRC, tous les canaux passent à l’état XOFF.

Le choix entre le contrôle de flux dans la bande et le contrôle de flux hors bande dépend bien entendu des exigences du projet.

Interlaken ne comporte aucun mécanisme de multiplexage des données des canaux. Par conséquent, c’est à la logique applicative qu’il revient d’arbitrer entre les demandes d’émission des canaux et de choisir quel canal aura le droit de transmettre une rafale (ou un paquet entier). La logique applicative est donc également responsable de la mise en pause de la transmission pour un canal lorsqu’un XOFF l’exige. La logique qui implémente le protocole Interlaken n’est responsable que de l’envoi et de la réception des demandes XON / XOFF.

Le protocole mentionne les crédits comme une possibilité pour implémenter le contrôle de flux, mais seulement comme une invitation ouverte à mettre en œuvre cette méthode à l’aide de canaux dédiés. Le protocole ne donne aucun détail sur la manière de procéder.

Contrôle de flux avec Aurora

Le protocole Aurora est brièvement présenté sur une autre page. Ce protocole propose deux mécanismes pour faciliter le contrôle de flux : NFC et UFC. Ces deux mécanismes sont décrits séparément ci-dessous.

Tout d’abord, le contrôle de flux natif (Native Flow Control, NFC) : avec ce mécanisme, la logique applicative du côté récepteur dispose d’une interface pour envoyer des demandes de contrôle de flux à l’émetteur. Ces demandes comportent deux parties distinctes : un bit XOFF et une partie XOFF limité dans le temps (« pause ») (ces deux concepts sont expliqués plus haut). La logique du protocole du côté émetteur est chargée d’obéir à ces demandes : si le bit XOFF vaut « 0 », l’émetteur fait une pause dans la transmission des données pendant le nombre de cycles d’horloge correspondant au nombre de 8 bits inclus dans la demande de contrôle de flux. Si ce nombre est nul, la transmission reprend immédiatement. Les nombres contenus dans les demandes ne s’accumulent pas. Chaque demande NFC met plutôt à jour le compte à rebours de la pause avec une nouvelle valeur.

Si le bit XOFF vaut « 1 », l’émetteur interrompt la transmission des données pour une durée indéterminée. Il ne reprend la transmission qu’en réponse à une demande de contrôle de flux avec XOFF = « 0 ». Une telle demande est traitée comme mentionné ci-dessus.

Notons que ce mécanisme de contrôle de flux commande tout le trafic de données sur le canal physique. NFC ne convient donc pas au contrôle individuel de plusieurs canaux, si de tels canaux sont implémentés.

Le second mécanisme est le contrôle de flux utilisateur (User Flow Control, UFC) : il s’agit en pratique d’un canal séparé permettant de transmettre des messages allant jusqu’à 256 octets vers l’autre côté. Les messages UFC ont une priorité plus élevée que la transmission des données, si bien qu’ils atteignent l’autre côté avec une faible latence.

Le protocole ne définissant pas le format de ces messages, ils peuvent servir à implémenter n’importe quel type de contrôle de flux. Une telle implémentation est réalisée entièrement dans la logique applicative. Les messages UFC peuvent aussi servir à transmettre toute autre sorte d’informations d’état.

Notons qu’aucun des messages utilisés dans ces deux mécanismes de contrôle de flux n’est protégé contre les erreurs binaires sur la liaison physique. Une demande de contrôle de flux peut donc arriver de manière incorrecte ou ne pas arriver du tout, ce qui peut éventuellement conduire à un débordement chez le récepteur.

Comme ces deux mécanismes de contrôle de flux reposent sur la liaison de données dans le sens opposé, ils ne sont disponibles qu’en mode full duplex.

Résumé

Cette page a présenté principalement deux techniques de contrôle de flux : XON / XOFF et les crédits. Pour les protocoles liés aux ordinateurs (par exemple PCIe, SuperSpeed USB et SATA), le contrôle de flux est implémenté par la logique du protocole. En revanche, pour les protocoles destinés à la communication entre FPGA, la logique applicative est responsable de la totalité ou de la plus grande partie de l’implémentation. La seule exception est Xillyp2p, qui prend en charge tous les aspects de la communication de données, y compris le contrôle de flux, la détection d’erreurs et la retransmission.

Les fonctionnalités liées au contrôle de flux de deux protocoles pour FPGA ont été présentées : Interlaken et Aurora. Comme on l’a vu, ces protocoles laissent à la logique applicative le plus gros du travail d’implémentation du contrôle de flux, même si leurs propres capacités peuvent accomplir une partie du travail dans certains scénarios d’utilisation.

Ceci clôt la dernière page de cette série consacrée aux MGT.