Cette page est la première d'une série de pages présentant les transcepteurs multi-gigabits (MGT), et donne un aperçu de ce qui vous attend dans cette série.
Introduction
Les MGT jouent un rôle important dans la communication entre les différentes parties d'un ordinateur ou d'un système électronique. Plusieurs interfaces bien connues à l'intérieur d'un ordinateur sont basées sur des MGT, par exemple PCIe et SATA. D'autres interfaces bien connues servent à la communication entre un ordinateur et ses périphériques, par exemple Gigabit Ethernet, SuperSpeed USB, Thunderbolt et DisplayPort.
Les MGT servent aussi à relier des composants électroniques, par exemple deux FPGA. Dans ce cas, la communication est souvent basée sur l'un des protocoles moins connus, voire sur un protocole non standard. Mais il est aussi possible d'utiliser des MGT pour connecter un FPGA à un autre type de composant, ou pour relier d'autres composants entre eux, par exemple avec Xillyp2p.
Par exemple, les transcepteurs à fibre optique sont souvent des modules standard (notamment au format SFP+) qui se connectent directement aux MGT, comme le montre cet exemple de conception. Certains ADC/DAC rapides utilisent aussi des MGT pour transférer les données échantillonnées (généralement sur la base du protocole JESD204). Certains protocoles sont destinés au transfert de données vidéo (par exemple certains protocoles de la couche physique de MIPI).
Même si les MGT sont souvent utilisés pour des protocoles bidirectionnels, chaque MGT est en réalité constitué de deux parties indépendantes : un émetteur et un récepteur. Il est donc possible d'utiliser un MGT pour une transmission unidirectionnelle en désactivant l'une des deux parties. Avec la plupart des MGT de FPGA, il est aussi possible de configurer indépendamment les paramètres de l'émetteur et du récepteur.
En résumé, les MGT sont utilisés dans de nombreuses applications. Souvent, le nom de l'interface ne laisse pas deviner que des MGT sont utilisés (par exemple Gigabit Ethernet, SATA et DisplayPort), mais la couche physique est constituée de MGT.
Il convient de mentionner que Xilinx (puis AMD) donne à ses MGT des noms différents : RocketIO, GTX, GTH, GTY, GTP, GTM, etc. Chaque nom correspond à une implémentation matérielle spécifique du transcepteur ; ce nom renseigne donc sur les débits et autres caractéristiques de performance du MGT.
Cette série de pages explique les bases des MGT et quelques termes techniques couramment utilisés à leur sujet. Le but est de faciliter la lecture de la documentation technique et, en particulier, de vous aider à reconnaître les paramètres pertinents pour votre projet et ceux qui ne le sont pas.
Qu'est-ce qu'un MGT ?
Il est important de comprendre que, derrière toutes ces fonctionnalités compliquées, un MGT n'est qu'un SERDES : un bloc électronique qui reçoit et émet des données. L'interface électrique du MGT avec le monde extérieur est constituée de deux fils formant une paire différentielle. Lorsque la tension sur le premier fil (le fil « plus » ou « positif ») est supérieure à la tension sur l'autre fil (le fil « moins » ou « négatif »), l'état physique correspond à un « 1 ». Sinon, c'est un « 0 ». C'est le même principe que pour les interfaces différentielles telles que LVDS.
Autre similitude avec un SERDES : l'interface du MGT avec la logique applicative se présente sous la forme d'un mot parallèle. Pour chaque cycle de l'horloge de la logique applicative, un certain nombre de bits sont échangés entre la logique applicative et le MGT. Cette disposition est nécessaire, car le débit est bien supérieur à la fréquence d'horloge maximale possible pour un FPGA.
Il y a toutefois quelques différences importantes entre un SERDES ordinaire et un MGT. En voici quelques-unes :
- Les MGT peuvent atteindre des débits bien plus élevés qu'un SERDES ordinaire.
- Le récepteur d'un SERDES doit recevoir l'horloge de l'émetteur en même temps que le flux de données. Un récepteur MGT, en revanche, peut se contenter du seul signal du flux de données : le MGT génère une horloge adaptée à ce signal et l'utilise à la place. Cette capacité s'appelle la récupération d'horloge et de données (clock data recovery, CDR). Même si un récepteur MGT a accès à l'horloge de l'émetteur, celle-ci ne sert que d'horloge de référence, et non d'horloge de données.
- Les erreurs binaires sont tolérées et normales sur une liaison de données utilisant un MGT. Le taux d'erreur binaire (BER) est généralement attendu sous 10-12 ou 10-15. Si une erreur binaire se produit sur un SERDES ordinaire, on la considère comme un dysfonctionnement, mais pas avec un MGT.
- Lorsqu'on utilise un MGT, il y a des restrictions sur le contenu du flux de données transmis sur la paire de fils électriques. Le flux de données doit toujours être équilibré en courant continu (DC balanced). En d'autres termes, le nombre de « 0 » et de « 1 » dans le flux doit être égal en moyenne. Il est aussi souvent exigé que les bits transmis soient statistiquement indépendants les uns des autres. Nous y reviendrons plus bas.
- Un MGT est capable de produire et de détecter des signaux hors bande (out-of-band signals, OOB). Ces signaux sont transmis lorsque le flux de données normal est interrompu pour économiser de l'énergie. Leur but principal est de réveiller le récepteur de l'autre côté afin de reprendre la transmission des bits de données.
Alors pourquoi un MGT est-il si compliqué ?
Quiconque a déjà tenté de configurer un bloc MGT pour un projet FPGA sait qu'il y a énormément de paramètres et de choix. Pourquoi faut-il que ce soit ainsi ?
En réalité, ce n'est pas forcément compliqué : comme le montre cet exemple de conception, si le MGT est utilisé simplement comme un SERDES, une grande partie de la complexité disparaît.
Cependant, l'utilisation d'un MGT est généralement compliquée, et cela tient principalement à trois raisons. Premièrement, le bloc MGT intègre de nombreux éléments fonctionnels qui pourraient être réalisés dans la logique programmable, mais qui sont intégrés au MGT pour des raisons d'efficacité. Par exemple, tous les MGT sont capables de coder et de décoder le 8b/10b, même si cette tâche pourrait être effectuée par la logique applicative. Mais comme cette technique de codage est très courante, c'est le MGT qui s'en charge.
La deuxième raison est liée à la génération des horloges (clocking) : plusieurs horloges sont nécessaires au bon fonctionnement d'un MGT. Pour compliquer encore les choses, les exigences de qualité des horloges — en particulier la gigue (jitter) — sont plus sévères que pour les horloges de la logique programmable du FPGA. Et il arrive aussi que l'on utilise une horloge à spectre étalé (SSC, Spread Spectrum Clocking), ce qui complique encore plus l'ensemble.
Réussir cette partie n'est donc parfois pas moins difficile que de choisir les bons paramètres du MGT en général.
La troisième raison est que les MGT sont conçus pour prendre en charge plusieurs protocoles de communication standard. Par conséquent, les noms des fonctionnalités nécessaires à un protocole donné proviennent souvent de la spécification de ce protocole. Ce jargon ne signifie rien pour quelqu'un qui ne connaît pas le protocole concerné. Il est donc difficile de décider quelles fonctionnalités activer lors de la configuration d'un bloc MGT pour un FPGA.
Tous ces sujets sont examinés plus en détail dans le reste de cette série de pages.
Ce qu'il faut savoir
Dans la plupart des cas d'utilisation, les MGT servent de couche physique pour un autre protocole bien établi, en particulier PCIe. Dans ces situations, les outils FPGA s'occupent des détails, et il n'est pas nécessaire de bien comprendre ce qui se passe au niveau bas.
Cependant, si vous comptez connecter directement votre logique applicative à un MGT, il est important d'être conscient de plusieurs difficultés que cette logique devra gérer. Certains de ces problèmes sont pris en charge par les protocoles destinés à une utilisation entre FPGA.
Voici une courte liste de sujets à prendre en compte. Chacun d'eux est examiné plus en détail dans le reste de cette série de pages.
- Alignement de mots : comme pour tout SERDES, un MGT ne sait pas à l'avance où commence un octet ou un mot plus long. Avec un SERDES, ce problème est généralement résolu en décalant le mot parallèle d'un bit à la fois (bit slipping), jusqu'à ce que le flux de données arrivé devienne cohérent. Les protocoles fondés sur les MGT utilisent généralement un mot de synchronisation à cette fin.
- Les bits sur les fils physiques doivent être équilibrés en courant continu (DC balanced). La solution la plus simple consiste à utiliser le codage 8b/10b, mais il existe d'autres possibilités, parfois plus appropriées.
- Embrouillage (scrambling) : il est presque toujours bon d'utiliser un égaliseur (equalizer) du côté du MGT récepteur. L'égaliseur compense les imperfections du support physique et réduit ainsi le BER. C'est particulièrement vrai lorsque le débit est élevé, lorsqu'on utilise des câbles bon marché ou lorsque la distance physique est grande. Certains types d'égaliseurs exigent toutefois que les données transmises soient statistiquement aléatoires : aucune corrélation entre deux bits n'est admise dans le flux de données émis. La solution courante consiste à utiliser un embrouilleur (scrambler), qui effectue un XOR entre les données utiles et une séquence pseudo-aléatoire de bits. Le récepteur effectue lui aussi un XOR avec la même séquence pseudo-aléatoire et retrouve ainsi le flux de données d'origine.
- Erreurs binaires : les données peuvent arriver entachées d'erreurs au MGT récepteur. La logique qui consomme ces données doit être conçue pour faire face à de telles erreurs. Dans certaines applications, on estime que les erreurs sont assez rares pour être ignorées (par exemple lors de la transmission de données vidéo brutes avec un BER inférieur à 10-15). Dans d'autres applications, un mécanisme de détection d'erreurs et/ou de retransmission est nécessaire pour garantir la fiabilité de la liaison.
- Écarts de fréquence d'horloge : lorsqu'un MGT reçoit un flux de données, ce flux repose sur l'horloge de l'autre côté, c'est-à-dire l'horloge de l'émetteur. Cette horloge peut avoir une fréquence légèrement différente de celle disponible du côté du récepteur. Or, l'interface entre le MGT et la logique applicative est souvent basée sur l'horloge locale. Si l'horloge de l'émetteur est plus rapide que celle du récepteur, le MGT reçoit les données plus vite qu'il ne peut les fournir à la logique applicative. Ces données excédentaires s'accumulent dans le bloc MGT et provoquent à terme une sorte de débordement (overflow). Inversement, si les données arrivent à un débit inférieur à celui de l'horloge locale, le MGT ne peut pas fournir de données à chaque cycle. Ces problèmes se produisent même si l'horloge de référence est transmise de l'émetteur au récepteur avec le flux de données : de petites fluctuations de fréquence suffisent à les déclencher. Le protocole résout généralement le problème à l'aide de mots d'inactivité (idle words).
- Consommation d'énergie : les MGT ont tendance à consommer beaucoup d'énergie. Cela tient en partie au débit élevé, et souvent les PLL de haute qualité s'avèrent très énergivores. Il est donc souvent souhaitable d'éteindre un MGT lorsqu'il n'est pas utilisé, même pour de très courtes périodes. Par exemple, une liaison SuperSpeed USB coupe souvent son flux de données si aucune donnée n'a été transmise pendant une durée aussi courte que 50 μs. Une négociation OOB (handshake) est alors utilisée pour reprendre le fonctionnement en cas de besoin.
PMA, PCS et génération des horloges
Le schéma fonctionnel représente les parties d'un MGT ainsi que son interaction avec la logique applicative :
Le fonctionnement d'un MGT se répartit généralement en trois parties :
- Génération des horloges (clocking) : comme mentionné plus haut, plusieurs horloges sont nécessaires au fonctionnement d'un MGT. Même si les outils FPGA configurent automatiquement les paramètres de ces horloges, il est nécessaire de comprendre comment elles sont générées.
- PMA (Physical Medium Attachment, c'est-à-dire la sous-couche d'attache au support physique) : cette partie contient le SERDES du MGT ainsi que les sous-systèmes de signaux analogiques (signaux OOB, détection du récepteur, égaliseur, préaccentuation, etc.). Cette partie met également en œuvre la CDR.
- PCS (Physical Coding Sublayer, c'est-à-dire la sous-couche de codage physique) : cette partie contient de la logique qui peut aider à mettre en œuvre le protocole de communication : codeurs et décodeurs, alignement de mots, modules de conversion de largeur de mots (gearboxes), FIFO, etc. La plupart des fonctions du PCS peuvent être réalisées dans la logique programmable, mais elles sont intégrées au MGT par souci de simplicité et d'efficacité.
Ces sujets sont approfondis dans cette série de pages.
L'interface PIPE
Le standard PIPE mérite d'être mentionné : il définit les connexions entre un MGT et la logique qui implémente PCIe, SuperSpeed USB ou SATA. Cela comprend les ports utilisés pour la communication des données, des signaux de commande et des signaux d'état.
Dans ce standard, le MGT est appelé couche PHY et la partie protocole est appelée couche MAC. On retrouve cette terminologie dans les normes Ethernet, USB 1.x et USB 2.0. Ces normes sont généralement mises en œuvre au moyen de deux puces séparées. Par exemple, pour implémenter Ethernet sur une puce de processeur, la couche MAC est implémentée dans cette puce, et la couche PHY dans une puce séparée. Le standard PIPE a été conçu dans le même esprit, même si PCIe, SuperSpeed USB ou SATA sont pratiquement toujours entièrement implémentés sur la même puce. Les connexions entre les couches MAC et PHY définies par le standard PIPE se font à l'intérieur de la puce et sont rarement visibles de l'extérieur.
Un impact important du standard PIPE est qu'un MGT de FPGA digne de ce nom implémente toujours l'interface PIPE requise pour PCIe. L'interface PIPE pour SATA est aussi souvent prise en charge. C'est évidemment utile pour implémenter ces deux protocoles, mais il y a un autre avantage important : différents FPGA présentent une interface similaire avec le MGT. En particulier, on retrouve certains éléments fonctionnels dans pratiquement tous les MGT.
Conclusion
Cette page a présenté un aperçu du MGT et de sa complexité. Dans le reste de cette série de pages, bon nombre des concepts mentionnés ci-dessus seront expliqués. Mais avant cela, nous commencerons par un court aperçu des protocoles souvent utilisés pour connecter deux MGT de FPGA.