Cette page est la quatrième d’une série de pages présentant le transcepteur multi-gigabits (MGT). Les pages précédentes ont abordé le MGT ainsi que quelques protocoles qui lui sont associés, et certaines méthodes de codage.
Introduction
Comme déjà mentionné dans la première page de cette série, un MGT n’est qu’un type de SERDES sophistiqué. Parmi les raisons de cette sophistication, on trouve dans un MGT quelques blocs fonctionnels qui aident à implémenter certains protocoles spécifiques. Cette page explique la raison d’être de certains de ces blocs.
La partie du MGT qui contient ces unités est généralement appelée PCS (Physical Coding Sublayer, sous-couche de codage physique). Cette appellation est trompeuse, car une partie de la logique du PCS n’a rien à voir ni avec le codage ni avec le décodage.
Ceci est un schéma fonctionnel d’un MGT typique, montrant la place du PCS dans un contexte plus large.
Le PCS comprend tout ce qui se trouve entre le PMA et la logique applicative de l’utilisateur. J’emploierai les expressions Tx PMA et Tx PCS pour désigner les parties du MGT utilisées pour transmettre les données. De même, Rx PMA et Rx PCS désigneront les parties utilisées pour recevoir les données.
Le Tx PCS commence aux ports d’entrée par lesquels la logique applicative remet au MGT les données à transmettre. Son rôle s’achève lorsqu’un mot parallèle contient les bits prêts à être transmis sur les fils physiques. Ce mot parallèle est alors remis à la partie Tx PMA, qui se charge de la sérialisation et de la conversion en signal électrique.
De même, le Rx PCS commence avec le mot parallèle de données que le Rx PMA a reçu et désérialisé, et se termine aux ports de sortie par lesquels le MGT remet les données à la logique applicative.
Le PCS étant constitué d’une logique qui n’agit que sur le mot parallèle, il est évident que toutes ses fonctions peuvent être implémentées dans la logique programmable. Cette logique est toutefois intégrée à l’intérieur du MGT pour la même raison qui conduit à implémenter de nombreux blocs fonctionnels dans des IP matérielles (hard IPs). Certains protocoles exploitent les capacités de codage du PCS. D’autres protocoles (par exemple xillyp2p) s’appuient sur leurs propres méthodes pour traiter le flux de données, ce qui simplifie beaucoup l’utilisation du MGT, comme le montre cet exemple de conception.
Chaque MGT ayant une structure interne différente, il est impossible de décrire le flux détaillé des données à l’intérieur du PCS d’une manière qui vaille pour tous les MGT. Les descriptions et explications ci-dessous se concentrent donc sur l’objectif des blocs fonctionnels du PCS. Seule la documentation propre du MGT peut fournir une description détaillée de son PCS et de ses blocs. Les explications qui suivent devraient toutefois rendre cette documentation plus facile à lire.
Codage et décodage
Plusieurs méthodes de codage ont été présentées à la page précédente : 8b/10b, 64b/66b, 64b/67b, 128b/130b et 128b/132b.
L’implémentation du 8b/10b fait partie de tous les MGT de FPGA, dans leur PCS. Elle comprend le codage et le décodage des mots de 8 bits en mots de 10 bits, et inversement, ainsi que les autres fonctionnalités mentionnées à la page précédente : les symboles K, la synchronisation et l’alignement en réponse au symbole Comma (K28.5), ainsi que la gestion des symboles Skip (K28.0).
En ce qui concerne les autres méthodes de codage, chaque MGT implémente un ensemble de codages différent. Les MGT diffèrent également dans les fonctionnalités de ces codages qui sont implémentées. Parfois, le PCS du MGT ne contient que le module de conversion de largeur de mots (gearbox) nécessaire ; parfois, il inclut aussi le mécanisme de synchronisation automatique. Il n’existe pas d’ensemble de fonctionnalités standard.
Modules de conversion de largeur
Dans tout le PCS, ainsi que dans l’interface avec la logique applicative, le flux de données du canal physique est représenté par un mot parallèle. La largeur de ce mot parallèle peut changer au fil des différentes étapes de traitement dans le PCS. Par exemple, lorsque les données traversent un codeur 8b/10b, la largeur du mot passe de 8 bits à 10 bits.
L’interface qui sert à faire transiter les données applicatives vers le MGT et depuis celui-ci est toutefois constituée de ports d’entrée et de sortie dont la largeur est toujours un multiple de 8. Typiquement, cette largeur vaut l’une des valeurs suivantes : 16, 32, 40, 64, 80, 128 ou 160 bits.
Mais que se passe-t-il, par exemple, si l’on utilise le codage 64b/66b ? Avec ce codage, le flux de données sur le canal physique est composé de segments de 66 bits chacun. Si ce flux est présenté sous la forme d’un mot parallèle de 64 bits de large, le début de chaque segment apparaîtra à une position différente dans ce mot à chaque fois. Aucune des largeurs autorisées pour l’interface avec la logique applicative ne permet d’éviter ce problème.
C’est précisément le rôle d’un module de conversion de largeur de mots (gearbox) : il s’agit d’un module logique qui réorganise les données arrivant sur son port d’entrée en un mot parallèle de largeur différente.
Supposons, par exemple, que l’on veuille transmettre des données codées en 64b/66b à l’aide d’un MGT, et que le codeur soit implémenté dans la logique applicative. La sortie du codeur est large de 66 bits, mais l’entrée du MGT ne peut avoir qu’une largeur de 64 ou de 80 bits (ou d’autres alternatives encore moins pertinentes). Pour résoudre ce problème, il faudrait implémenter un module de conversion de largeur (gearbox) qui transforme le mot parallèle existant (66 bits) en un mot que le MGT puisse accepter (64 bits). C’est une situation qu’il vaut mieux éviter.
Pour cette raison, les MGT comportent souvent un ou plusieurs modules de conversion de largeur de mots (gearboxes) dans leur partie PCS. En particulier, lorsque le MGT intègre un codeur 64b/66b (ou un codeur analogue, comme le 128b/130b), un module de conversion adapté est également présent dans le MGT. Ainsi, le MGT effectue toutes les tâches nécessaires à la transmission de données codées : d’abord, les données sont codées par le codeur du MGT, puis le module de conversion change la largeur du mot parallèle afin que celui-ci puisse être remis à la partie Tx PMA pour transmission. Une solution analogue est employée pour la réception des données.
Parce que les mots de part et d’autre du module de conversion sont différents, le nombre de bits qui y entrent diffère du nombre de bits qui en sortent. Si le mot parallèle d’entrée est plus large, le module doit occasionnellement refuser de recevoir un mot pour compenser cette différence. De même, si le mot parallèle de sortie est plus large, le module ne présente pas toujours une donnée valide sur son port de sortie. Si le module fonctionne avec une seule horloge, il faut donc aussi un signal de contrôle de flux (flow control) qui compense la différence du nombre de bits de chaque côté. Dans la terminologie de Xilinx / AMD, on parle alors de module de conversion synchrone.
Autre possibilité : le module de conversion peut s’appuyer sur deux horloges. Leurs fréquences sont choisies de manière à compenser le rapport entre les largeurs des mots de part et d’autre du module. L’avantage de cette méthode est que le flux de données n’est jamais interrompu d’un côté ni de l’autre. Un tel module exige toutefois deux horloges et fonctionne dans deux domaines d’horloge (clock domains). Cette solution est appelée module de conversion asynchrone.
Tampon Tx (Tx FIFO)
Le tampon Tx (souvent appelé Tx FIFO) est une petite FIFO située dans le Tx PCS. Sa profondeur est en général de 16 ou 32 éléments, et il est normalement à moitié plein en conditions de fonctionnement ordinaires. La raison d’être de cette FIFO est un peu complexe et elle est expliquée ci-dessous. Cette explication ne répond toutefois pas à la seule question qui compte en général lors de la configuration d’un MGT : faut-il activer ou non le tampon Tx ?
La réponse est que, dans la plupart des cas, le tampon Tx doit être activé. La seule raison de s’en passer est que son délai pose problème : utiliser un tampon Tx introduit un délai inconnu entre le moment où un mot parallèle est remis au MGT et le moment où ce mot est transmis sur la couche physique. Dans la plupart des applications, cela représente une incertitude de l’ordre de 0,1 μs ou moins, un délai auquel le protocole est indifférent.
Quant à savoir pourquoi cette FIFO est nécessaire, voici l’explication.
Un Tx PCS contient au moins deux domaines d’horloge (clock domains) : la première horloge sert à l’interface avec la logique applicative. La seconde (parfois appelée XCLK) est utilisée là où le Tx PCS remet le mot parallèle au Tx PMA pour transmission.
La question de la génération des horloges (clocking) à l’intérieur d’un MGT est traitée séparément dans une autre page. Pour l’instant, il suffit de comprendre pourquoi il doit y avoir deux horloges distinctes. Pour l’expliquer, nous allons comparer le MGT à un SERDES ordinaire.
Supposons, par exemple, que l’on veuille transmettre des données à 1000 Mbits/s à l’aide d’une broche de sortie ordinaire. La plupart des FPGA actuels possèdent un SERDES rattaché à chaque broche de sortie à cette fin. Pour cet exemple, supposons que la logique applicative alimente le SERDES avec un mot parallèle de 8 bits de large. L’horloge de ce mot parallèle est donc de 125 MHz.
En conséquence, le SERDES reçoit deux horloges : une horloge à 125 MHz et une seconde à 500 MHz. Le SERDES utilise les deux fronts de l’horloge à 500 MHz, si bien que les données sont transmises au débit voulu de 1000 Mbits/s.
Les deux horloges reçues par le SERDES doivent être alignées. Par exemple, le front montant de l’horloge à 500 MHz doit se produire en même temps que le front montant de l’horloge à 125 MHz. C’est indispensable au bon fonctionnement du SERDES. Cet alignement est obtenu en utilisant une seule PLL pour générer les deux horloges et des tampons d’horloge ayant le même délai de propagation (propagation delay). C’est une méthode courante pour garantir l’alignement des horloges : voir l’explication sur les horloges liées (related clocks).
Mais que se passe-t-il si l’on veut transmettre à 5000 Mbits/s ? Cela dépasse les capacités d’une broche de sortie ordinaire, d’où la nécessité d’un MGT. Le MGT contient lui aussi un SERDES. Supposons que le mot parallèle qui alimente ce SERDES ait une largeur de 32 bits. L’horloge associée à ce mot a donc une fréquence de 156,25 MHz. Supposons également que l’interface avec la logique applicative utilise un mot parallèle de 32 bits également. La fréquence d’horloge de cette interface est donc elle aussi de 156,25 MHz. Mais s’agit-il du même signal d’horloge ?
Pour transmettre le mot parallèle, le SERDES du MGT doit être connecté à une horloge de 2500 MHz (un nouveau bit est transmis sur chaque front d’horloge). Cette fréquence est trop élevée pour les PLL généralistes du FPGA. Il est également impossible d’utiliser les tampons d’horloge ou les autres ressources de routage du FPGA pour cette horloge. Le MGT doit donc posséder ses propres PLL et ses propres lignes internes afin de générer les deux horloges alignées dont le SERDES a besoin. Plus de détails à ce sujet dans la page consacrée à la génération des horloges (clocking) du MGT.
Nous sommes maintenant en mesure de comprendre pourquoi il y a au moins deux domaines d’horloge (clock domains) dans le Tx PCS. Dans cet exemple, le Tx PCS alimente le Tx PMA avec un mot parallèle de 32 bits. L’horloge de ce mot est à 156,25 MHz. Cette horloge est créée par la PLL du MGT afin de garantir son alignement avec l’horloge à 2500 MHz. L’interface entre la logique applicative et le MGT utilise exactement la même fréquence d’horloge, mais la logique applicative ne peut pas employer le même signal d’horloge pour autant : l’horloge de la logique applicative doit passer par le tampon d’horloge de la logique programmable afin que ce signal atteigne tous les éléments logiques sans décalage (skew). En raison du délai de ce tampon d’horloge, l’horloge de la logique applicative n’est pas naturellement alignée avec l’horloge à 2500 MHz.
La façon la plus directe d’effectuer un changement de domaine d’horloge (clock domain crossing) consiste à utiliser une FIFO (comme indiqué sur une page consacrée à ce sujet). Le tampon Tx joue le rôle de cette FIFO.
Les MGT qui offrent la possibilité de contourner le tampon Tx proposent aussi d’autres méthodes pour garantir l’alignement nécessaire entre les horloges internes du Tx PCS. Ces méthodes sont toutefois compliquées et sujettes aux erreurs.
Tampon Rx (Rx FIFO)
Le tampon Rx (souvent appelé Rx FIFO) est une petite FIFO située dans le Rx PCS. Ce tampon est en principe identique au tampon Tx, si bien que tout ce qui a été dit plus haut à propos du tampon Tx vaut également pour le tampon Rx. La réponse à la question de savoir s’il faut l’activer est la même : le tampon Rx doit être activé dans la plupart des applications, sauf lorsque le délai qu’il introduit est inacceptable.
Le tampon Rx a toutefois un rôle supplémentaire : il permet au Rx PCS de travailler avec deux horloges dont les fréquences diffèrent légèrement. Voyons à présent pourquoi cette différence peut se produire.
Tout d’abord, rappelons que cette discussion porte sur la partie du MGT qui reçoit un flux de données. Or ce flux est produit par un autre MGT, qui s’appuie sur une autre horloge de référence (dans la plupart des scénarios). Le MGT qui reçoit le flux n’a souvent pas accès à l’horloge utilisée par l’émetteur. Le récepteur crée plutôt une réplique de cette horloge à partir du seul flux de données (c’est ce qu’on appelle la CDR, Clock Data Recovery).
Par conséquent, le Rx PMA travaille avec une horloge qui s’adapte au débit de l’émetteur. La fréquence de cette horloge est incertaine, dans une tolérance définie. Le protocole définit toujours l’écart de fréquence autorisé par rapport à une valeur spécifiée, mais il subsiste toujours une part d’incertitude.
L’interface qui transmet les mots parallèles du Rx PMA au Rx PCS dépend donc d’une horloge qui s’adapte à l’émetteur. Le Rx PCS doit être synchrone avec une horloge étrangère.
Mais en quoi cela diffère-t-il du Tx PCS ? Rappelons, d’après la discussion sur le tampon Tx, qu’il existe deux domaines d’horloge dans le Tx PCS. Même si ces deux horloges ne sont pas le même signal, elles ont exactement la même fréquence, car elles sont issues de la même horloge de référence.
De même, il y a deux domaines d’horloge dans le Rx PCS. L’une des horloges a une fréquence inconnue. Et l’autre ? La réponse dépend des besoins de la logique applicative : dans la plupart des cas, un MGT sert à mettre en œuvre un protocole bidirectionnel. Ce protocole implique de transmettre des données en réponse à celles qui sont reçues. Il est donc commode que toute la logique applicative soit synchrone avec une seule horloge. Plus précisément, la solution la plus courante consiste à rendre toute la logique applicative synchrone avec l’horloge utilisée pour l’émission. Cela signifie que l’interface entre le Rx PCS et la logique applicative est synchrone avec la même horloge que celle du Tx PCS.
Avec cette approche, les deux horloges du Rx PCS n’ont pas la même fréquence. Par conséquent, le Rx PCS reçoit les données du Rx PMA à un rythme différent de celui auquel il les transmet à la logique applicative. Le tampon Rx est capable d’absorber temporairement cette différence : si la logique applicative prélève les données plus lentement, le tampon Rx accumule le surplus. Si elle les prélève plus vite, le tampon Rx se vide progressivement.
Cette solution n’est évidemment que très temporaire. Le tampon Rx finira tôt ou tard par déborder (overflow) ou par se vider, à moins que l’on ne maintienne son niveau de remplissage autour de la moitié de sa capacité. Il existe différents mécanismes à cette fin. Rappelons par exemple, d’après la page précédente, que si le codage 8b/10b est utilisé, des symboles Skip peuvent être insérés pour compenser les écarts de fréquence entre les horloges. Le mécanisme qui exploite les symboles Skip est implémenté dans le Rx PCS : si le tampon Rx est rempli à plus de la moitié, le Rx PCS n’écrit pas les symboles Skip dans le tampon Rx. Cela fait baisser le niveau de remplissage. En revanche, si le tampon Rx est rempli à moins de la moitié, le Rx PCS lit les symboles Skip dans le tampon Rx de façon répétée. Ainsi, les nouvelles données remplissent le tampon pendant que celui-ci n’est pas vidé. Le niveau de remplissage du tampon Rx augmente donc.
Le tampon Rx est souvent appelé tampon élastique (elastic buffer) en raison de sa capacité à absorber temporairement les variations de son niveau de remplissage. Il est important de noter que cette capacité n’est pas toujours nécessaire : si la logique applicative dialogue avec le Rx PCS au moyen d’une horloge ayant la même fréquence que celle du Rx PMA, le tampon Rx se comporte en principe comme le tampon Tx. Dans cette approche, la logique applicative est responsable du changement de domaine d’horloge (clock domain crossing), si un tel changement est nécessaire. Cette approche permet aussi de désactiver le tampon Rx si nécessaire (notamment pour éviter son délai). Xillyp2p est un exemple de logique applicative qui reçoit les données avec l’horloge du Rx PMA, tout en permettant d’utiliser le tampon Rx pour simplifier la génération des horloges (clocking).
Fonctionnalités liées aux séquences pseudo-aléatoires
Une séquence binaire pseudo-aléatoire (PRBS) est une suite de bits qui paraît aléatoire, mais ne l’est pas vraiment : une PRBS se répète périodiquement. Comme il est facile de générer une PRBS sur de très longues périodes (plusieurs millions de bits), ses propriétés statistiques ressemblent à celles d’une suite de bits véritablement aléatoire.
La méthode la plus courante pour générer une PRBS consiste à utiliser un registre à décalage à rétroaction linéaire (LFSR, Linear-Feedback Shift Register). Cette logique ne comporte que quelques bascules (flip-flops) et portes XOR, de sorte qu’un LFSR ne demande que peu de ressources à implémenter. Un exemple de LFSR couramment utilisé figure sur une page séparée traitant d’un sujet mathématique lié aux LFSR.
La partie PCS d’un MGT comporte généralement quelques fonctionnalités liées aux PRBS. Le MGT peut notamment offrir une implémentation d’embrouilleur (scrambler). Lorsque la synchronisation de l’embrouilleur est implémentée dans le Rx PCS, cela peut faire gagner beaucoup de travail.
Une autre utilisation très courante d’une PRBS consiste à tester le canal physique pour détecter d’éventuelles erreurs. C’est une méthode intéressante, car le récepteur peut facilement générer la séquence de bits correcte à l’aide d’un LFSR. Les erreurs sur le canal physique sont détectées en comparant la séquence de bits générée localement au flux de données qui arrive. Ce mécanisme n’est pas difficile à implémenter dans la logique programmable, mais certains MGT disposent néanmoins de cette capacité de manière intégrée.
Malheureusement, le canal physique ne peut pas servir à transmettre des données pendant qu’un test d’erreurs est effectué à l’aide d’une PRBS. Il est donc impossible de surveiller la qualité du canal pendant qu’il est réellement utilisé. Certains protocoles disposent de mécanismes de signalement d’erreurs, mais en général une erreur n’est signalée que si elle a perturbé des données transmises. Une exception est xillyp2p, qui signale aussi les erreurs survenant lorsque la liaison est inactive.
Ceci clôt la quatrième page de cette série consacrée aux MGT. La page suivante commence à aborder le PMA et sa capacité à compenser les difficultés du canal physique, ainsi que sa capacité à effectuer un balayage d’œil (eye scanning).