Cette page est la quatrième d'une série de cinq pages consacrée au métier de concepteur FPGA. Cette fois, je passe en revue quelques compétences moins importantes pour débuter. Je commence par expliquer l'intérêt de faire cela en premier lieu.
Pourquoi mentionner quelque chose d'accessoire ?
Cela peut sembler un peu étrange d'écrire une page sur des compétences et de dire en même temps « non, ce n'est pas si important ». Mais cette série ne consiste pas à vous dire quoi faire. J'essaie plutôt d'expliquer pourquoi chaque sujet est important (ou pas si important). Il est donc logique de faire de même pour les sujets moins importants.
Certaines compétences pratiques sont souvent utiles mais surestimées. Ce sont des compétences que vous pourriez avoir besoin d'acquérir à un moment donné, mais il y a aussi des chances que vous n'en ayez jamais besoin. La raison pour laquelle un sujet peut être surestimé est qu'il apparaît souvent dans les exemples de conception pour les cartes. Pas parce qu'il est important, mais parce qu'il est relativement facile de faire une démo jolie et impressionnante avec une technique spécifique.
Pour que ce soit bien clair : toutes les compétences mentionnées ci-dessous sont utiles. C'est juste qu'elles sont souvent acquises au fur et à mesure des besoins pour travailler sur un projet, avec tout un tas d'autres sujets techniques spécifiques aux exigences de ce projet.
I2C et SPI
Vous pouvez travailler toute votre vie comme concepteur FPGA sans rien connaître de ces deux-là. Mais en réalité, il y a de bonnes chances que vous les rencontriez assez vite dans votre travail pratique.
L'I2C (IIC, Inter-Integrated Circuit), les protocoles très similaires, et le SPI (Serial Peripheral Interface) sont de loin les standards les plus courants pour transmettre des données depuis et vers un composant électrique sur un PCB. Ils reposent sur une configuration maître / esclave (master / slave), où le maître initie une opération de lecture ou d'écriture, et l'esclave y répond éventuellement. Dans la plupart des cas, le maître est un processeur ou un composant relativement sophistiqué, et l'esclave est un composant plus simple assurant une fonction périphérique dans la conception électronique.
L'I2C et les protocoles qui en dérivent ont un débit de données très faible (généralement autour de 100 kbit/s) et servent principalement à configurer les paramètres d'un composant. Par exemple, si le composant est un convertisseur A/N, l'I2C peut servir à sélectionner la référence de tension que le composant utilisera, et si sa sortie doit être donnée sous forme d'entier signé ou non signé. Le principal avantage de ce protocole est que la connexion ne consiste qu'en deux fils : horloge (SCL) et données (SDA). Il y a aussi une connexion à la masse (GND), mais celle-ci se fait généralement via la masse commune du PCB et ne nécessite pratiquement jamais de fil séparé.
Le protocole est en fait un bus, donc chaque cycle d'échange de données comprend une adresse de 7 bits. Par conséquent, plusieurs composants peuvent être connectés en parallèle à cette paire de fils. Chaque composant doit alors avoir une adresse différente.
Le standard I2C a été breveté à l'origine par Philips. Parce qu'il était si utile, beaucoup de variantes frappantes de ressemblance sont couramment utilisées, par exemple SMBus, PMBus et DDC2. Ces standards reprennent les idées principales de l'I2C, mais ont des paramètres légèrement différents (en particulier les débits de données) et des scénarios d'utilisation principaux différents. Par exemple, tous les écrans d'ordinateur vendus aujourd'hui ont une petite mémoire flash, contenant des informations sur les modes graphiques qu'ils prennent en charge. Le câble entre la carte graphique de l'ordinateur et l'écran comporte deux fils connectés à cette mémoire flash. Cela permet à la carte graphique de lire les données de cette mémoire avec le protocole DDC2, qui est effectivement identique à l'I2C.
Donc si vous comprenez l'I2C, vous savez comment beaucoup de composants différents communiquent entre eux.
Ensuite, le SPI. Ce protocole nécessite généralement quatre fils entre les composants maître et esclave (SCLK, MOSI, MISO, SSn). Parfois, ce protocole est utilisé pour configurer un composant, tout comme l'I2C et ses variantes. Cependant, l'usage principal du SPI est de transmettre des données à des débits plus élevés. Il n'est pas rare que des composants prennent en charge une fréquence SCLK de 20–50 MHz, c'est donc un protocole pratique pour transmettre des données applicatives. Par exemple, un convertisseur A/N pour deux canaux audio génère 48 000 Hz × 2 × 16 bits = 1,536 Mbit/s. Ce débit est un jeu d'enfant pour le SPI. Et en effet, il existe plusieurs puces audio qui utilisent le SPI pour transmettre des échantillons (samples).
Il vaut aussi la peine de mentionner que la connexion entre le FPGA et la mémoire flash depuis laquelle il lit son flux de configuration (bitstream) est souvent du QSPI. Cette interface est comme le SPI classique, mais avec quatre fils de données au lieu d'un, ce qui rend le transfert de données plus rapide.
Donc, pour conclure : devriez-vous apprendre l'I2C et le SPI dans le cadre de votre parcours de concepteur FPGA ? Mon avis est qu'ils n'ont rien à voir avec la conception FPGA en eux-mêmes. Mais si vous travaillez dans une petite équipe développant un produit électronique, il y a de fortes chances que vous deviez configurer l'un des composants avec l'I2C. Ou que l'un des composants connectés au FPGA utilise le SPI pour communiquer. Ou peut-être utiliser directement depuis votre propre logique la mémoire flash contenant le flux de configuration (bitstream) du FPGA.
Il y a beaucoup de cas d'usage pour ces deux protocoles, mais le plus important est de les reconnaître, eux et leurs variantes, quand ils apparaissent dans les fiches techniques. Souvent, un composant utilise l'un de ces protocoles, mais n'en mentionne pas explicitement le nom. Si vous connaissez les principes derrière l'I2C, vous ne pouvez pas le manquer quand la fiche technique décrit une interface similaire. Il en va de même pour le SPI.
Et si vous vous présentez à un entretien d'embauche en prétendant être un concepteur FPGA expérimenté, mais que vous ne connaissez rien à ces deux protocoles, cela risque de ne pas être très impressionnant.
De plus, voici une suggestion de projet pour acquérir un peu d'expérience : il est assez facile de trouver un capteur de température bon marché ou un autre type de composant simple qui utilise l'I2C ou l'une de ses variantes. Achetez un composant de ce genre, connectez-le à votre carte FPGA avec des fils Dupont ou une autre méthode bricolée. Puis écrivez depuis zéro tout ce qu'il faut pour interagir avec lui via l'I2C. Si vous avez un oscilloscope, utilisez-le pour surveiller les signaux. Cela pourrait être votre premier projet fait maison.
Conception par blocs (block design)
La plupart des outils de conception FPGA offrent la possibilité de connecter des blocs de conception logique (logic design blocks) via une interface graphique. En principe, utiliser cette interface équivaut à peu près à instancier (instantiation) des modules en Verilog. Les fils dessinés graphiquement sont comme les connexions de ports en Verilog. Un outil de conception par blocs (block design) offre souvent quelques capacités supplémentaires, par exemple insérer automatiquement de petits morceaux de logique qui garantissent que les connexions faites dans l'interface graphique font ce que l'utilisateur voulait.
La méthode de conception par blocs (block design) est à son meilleur quand tous ou la plupart des blocs sont fournis par le fournisseur du FPGA (sous forme de blocs IP (IP blocks)). En particulier, quand un processeur est impliqué, une conception par blocs (block design) est généralement la façon naturelle de le connecter à des blocs IP (IP blocks) implémentant des fonctions périphériques : contrôleurs d'interruptions, contrôleurs DMA, arbitres de bus, etc. Il y a aussi des périphériques plus « classiques », par exemple les contrôleurs Ethernet.
Outre les blocs évidents liés au processeur, il existe aussi une large sélection de blocs IP (IP blocks) qui implémentent un large éventail de fonctions couramment implémentées dans un FPGA. Cela va des éléments du FPGA comme les ressources d'horloge et la logique adjacente aux broches d'E/S, en passant par de simples unités arithmétiques, jusqu'aux filtres numériques et à une logique encore plus complexe. On dirait que l'idée était de rendre possible la création d'une conception FPGA entière en utilisant uniquement une conception par blocs (block design).
Cela dit, je n'ai jamais entendu parler de quelqu'un qui ait construit un projet FPGA vraiment utile uniquement avec ces blocs IP (IP blocks) prêts à l'emploi. Sauf pour un projet consistant uniquement en un processeur et ses périphériques, mais si vous ne voulez qu'un processeur, pourquoi utilisez-vous un FPGA ? C'est bien plus cher et compliqué.
Mais une conception par blocs (block design) entière peut, et est habituellement, instanciée (instantiation) dans un module Verilog, comme n'importe quel autre module Verilog ou IP. En conséquence, la conception par blocs (block design) fait généralement partie d'un projet plus vaste, basé sur Verilog. Dans ce contexte, une conception par blocs (block design) contenant seulement un processeur et ses périphériques a du sens : c'est juste un module à l'intérieur d'un projet plus grand.
Alors qu'est-ce que cela signifie en termes de compétences que vous devriez, ou peut-être ne devriez pas, apprendre ?
La compétence la plus simple est de créer des conceptions par blocs (block designs), ajouter des blocs et les connecter. Il y a plein de tutoriels qui vous disent quoi cliquer et quand. Comme ces tutoriels sont si faciles à suivre et à terminer, pourquoi ne pas en parcourir un ou deux ? Et si vous le faites, ne vous embêtez pas à comprendre chaque étape et chaque sélection faite tout au long du processus. L'important est d'avoir une idée de la façon dont on fait une conception par blocs (block design). Plongez dans les détails si et quand cela devient pertinent.
La compétence suivante est d'inclure une conception par blocs (block design) dans un projet, et de l'instancier (instantiation) dans un module Verilog. C'est aussi assez simple, et il y a beaucoup d'exemples pour cela. Ce n'est pas différent de l'utilisation de n'importe quel IP dans votre projet. Si vous savez utiliser un IP de FIFO dans votre projet Verilog, vous savez aussi faire de même avec une conception par blocs (block design).
La compétence la plus significative est de transformer quelque chose que vous avez écrit en Verilog en un bloc utilisable dans une conception par blocs (block design). Et plus significatif encore, rendre ce bloc configurable avec l'interface graphique de Vivado (ou quelle que soit la suite de développement que vous utilisez). Je ne recommanderais pas d'apprendre à faire cela à moins qu'il n'y ait un objectif direct. La plupart des concepteurs FPGA n'ont jamais besoin de faire quoi que ce soit de ce genre.
Alors, quel est le bilan ? Comme avec tout outil graphique, jouez un peu avec, puis apprenez progressivement autant que nécessaire pour accomplir une tâche. En particulier, ne vous attendez pas à tout faire avec une conception par blocs (block design), même si l'ensemble des blocs disponibles peut vous induire en erreur en vous laissant croire que c'est la voie à suivre.
Travailler avec des processeurs à l'intérieur du FPGA
Beaucoup de projets, en particulier les produits électroniques autonomes, ont du logiciel qui tourne en leur sein, et impliquent donc un processeur. Ce processeur peut être un bloc à l'intérieur du FPGA ou un composant physique séparé à l'extérieur. Les défis sont complètement différents dans chaque cas.
Je vais commencer par le scénario du processeur à l'intérieur du FPGA. Cela peut être un « processeur matériel » (hard processor), comme ceux de la famille Zynq d'AMD, qui ont un processeur ARM intégré au silicium. Un « processeur matériel » (hard processor) est comme n'importe quel autre élément logique à l'intérieur du FPGA, comparable aux unités arithmétiques, aux PLL et aux mémoires en blocs. Sauf qu'un bloc processeur est relativement gros et a tout un tas de broches.
Si un FPGA n'a pas de « processeur matériel » (hard processor), il peut quand même exécuter du logiciel sur un « processeur logiciel » (soft processor). Par exemple, les processeurs Microblaze d'AMD et Nios d'Altera. La différence est que le processeur est implémenté avec les éléments logiques ordinaires du FPGA (la « matrice logique » (logic fabric)). Cette méthode est plus lente, consomme plus d'énergie et utilise des ressources logiques, mais elle est souvent suffisamment bonne et constitue un choix économique.
Les « processeurs matériels » (hard processors) comme les « processeurs logiciels » (soft processors) sont en principe comme n'importe quel module Verilog qui se connecte à la logique du FPGA comme n'importe quel autre IP. Il est donc tout naturel de les considérer comme faisant partie du FPGA et donc de considérer le concepteur FPGA comme responsable d'eux.
Configurer le processeur dans la conception logique est généralement la tâche relativement facile, car il y a beaucoup d'exemples et de modèles pour cela. Mais cela se termine rarement là. Le processeur doit avoir certains périphériques, et ceux-ci doivent être accessibles au logiciel à des adresses connues dans l'espace mémoire du processeur. Les périphériques ont souvent des sorties de demande d'interruption qui doivent être correctement connectées au processeur et configurées correctement.
L'équipe logicielle s'attend généralement à ce que quelqu'un d'autre prenne en charge le morceau de logiciel qui s'exécute quand le processeur s'allume ou reçoit un signal de réinitialisation (reset). Ce logiciel consiste en des routines qui, entre autres, écrivent dans les propres registres matériels du processeur afin de le faire fonctionner comme configuré. Ce n'est pas aussi difficile que cela en a l'air, car les outils de développement créent du code C destiné à être inclus dans le projet logiciel plus vaste à cette fin. Mais qui est responsable de la génération de ces fichiers et de veiller à ce qu'ils soient synchronisés avec le reste de la conception FPGA ? Dans une petite équipe de développement, c'est le concepteur FPGA.
Et si cela ne suffit pas, le concepteur FPGA peut être tenu de créer des périphériques pour le processeur qui implémentent une logique spécifique au produit développé. Écrire les pilotes (drivers) pour cette logique en C est généralement plus que bienvenu.
Alors — est-ce quelque chose à commencer à apprendre dans le cadre du parcours de concepteur FPGA ? Si vous voulez travailler à l'intersection entre le logiciel et le matériel, je dirais que oui, peut-être. Si vous êtes déjà programmeur C et que vous aimez la programmation bas niveau, cela peut être pour vous. Et en particulier, si cela ne vous dérange pas de lire le très épais manuel d'utilisation du processeur de temps en temps. C'est là que vous trouverez la réponse à « Comment puis-je avoir deux unités de périphérique X et trois de périphérique Y ? »
Quels sujets devriez-vous apprendre, alors ? Je dirais qu'il s'agit d'acquérir une compréhension de base de la façon dont les processeurs exécutent du logiciel, comment ils accèdent à la mémoire, comment fonctionnent les interruptions, et comment les processeurs démarrent à la mise sous tension. Regardez la carte d'adresses d'un processeur, voyez comment les régions de mémoire sont divisées en différents segments (RAM interne à la puce, RAM externe, registres internes, segments d'accès au bus externe, etc.) et comprenez comment tout cela fonctionne.
Je suggère aussi de comprendre les principes des protocoles AMBA (AXI3, AXI4, AXI4 Lite, etc.), en particulier la poignée de main (handshake) VALID / READY. Si vous concevez un jour un périphérique, il y a de fortes chances que vous deviez implémenter un esclave AXI. Et même si vous travaillez avec un processeur qui n'utilise pas l'AXI nativement (par exemple, les processeurs d'Altera), les principes seront les mêmes.
Vous serez probablement aussi responsable du logiciel qui s'exécute à la mise sous tension et à la réinitialisation (reset) du processeur. Se familiariser avec la façon dont ce logiciel est créé et comment il se rapporte aux propres registres matériels du processeur pourrait donc aider. Et c'est plus facile si vous écrivez vous-même les routines de pilote (driver) pour accéder aux éventuels périphériques que vous pourriez avoir à concevoir. Pour ces raisons, vous n'irez pas très loin sans être bon en programmation C. Même si vous utilisez l'IA pour écrire le code à votre place, vous devez comprendre exactement ce que ce code fait.
Mais surtout, sachez que vous n'apprendrez pas grand-chose en parcourant un long projet d'exemple, où vous avez configuré un processeur et cliqué, cliqué, cliqué et à la fin quelque chose de très impressionnant s'est produit sur votre carte. Tout ce qui vaut la peine d'être appris a déjà été fait pour vous, et vous avez sauté les parties importantes en cliquant jusqu'à la ligne finale. S'il y a quoi que ce soit de précieux dans un tel projet d'exemple, c'est ce qui se passe après que vous avez terminé : qu'avez-vous compris de l'exemple ? Que pouvez-vous changer dans le projet ? Que pouvez-vous essayer vous-même ?
Travailler avec des processeurs à l'extérieur du FPGA
Assez souvent, le processeur est un composant autonome ou fait partie d'une carte séparée dans un projet impliquant un FPGA. Il n'est pas rare d'avoir un PC complet, soit un ordinateur de bureau classique, soit une carte mère industrielle x86, comme partie centrale d'un produit. Dans ces configurations, il est courant de considérer le FPGA comme un périphérique. Même si le rôle du FPGA varie d'un projet à l'autre, le processeur (ou le PC) est généralement considéré comme le centre du projet, et le FPGA (ainsi que l'électronique qui l'entoure) comme une partie contrôlée et gérée par le logiciel.
Comme le processeur est une partie physique séparée, il y a généralement une équipe distincte qui s'occupe de tout ce qui le concerne, y compris le logiciel. Les tâches du concepteur FPGA liées au processeur consistent principalement à s'interfacer avec lui. Si le processeur ne doit que contrôler le comportement du FPGA, il est possible que la communication ne consiste qu'en des commandes, éventuellement par lecture ou écriture de registres. Dans ce cas, des protocoles plus simples sont souvent utilisés, en particulier l'I2C et le SPI. J'ai déjà traité ces deux-là plus haut. Le SPI peut aussi être choisi pour l'échange de données à des débits relativement faibles.
Il vaut la peine de mentionner que l'I2C et le SPI ne sont couramment utilisés qu'avec des processeurs embarqués. Ces protocoles sont moins courants avec des périphériques spécifiques au projet quand une carte mère de PC est impliquée. Même si le SMBus est souvent utilisé pour contrôler les ventilateurs et obtenir des relevés de température, il est moins courant d'utiliser des protocoles de ce genre avec vos propres périphériques.
Avec les processeurs embarqués (et les DSP), il arrive aussi que l'interface avec le FPGA se fasse via une interface spécifique au processeur (ou à une famille de processeurs d'un fournisseur donné). Par exemple, le processeur peut avoir de nombreuses broches physiques connectées au FPGA pour y accéder via une interface de type bus adresse / données. Implémenter la logique s'interfaçant avec ce bus nécessite une compréhension précise du protocole (pas toujours conçu intelligemment) défini par le fournisseur du processeur. Il y a aussi des exigences temporelles (timing requirements) à respecter. Cependant, cela ne sert à rien de se préparer à une tâche de ce genre, car elle ne diffère pas de l'interfaçage avec n'importe quel autre composant externe ayant un protocole d'E/S compliqué.
L'interfaçage avec des PC et des processeurs embarqués haut de gamme se fait généralement avec l'interface PCIe (PCI Express). C'est un canal de communication robuste et bien pris en charge qui permet un débit de 200 Mo/s (de données utiles) dans sa configuration la plus simple, mais le ciel est la limite : de nouvelles versions du protocole PCIe sortent à intervalles réguliers, et le débit augmente à chaque nouvelle version. La limite réelle de débit est souvent ce que le processeur lui-même peut gérer.
L'inconvénient du PCIe est que c'est un protocole compliqué, destiné principalement aux puces périphériques d'ordinateur. Il est implicitement présumé que si vous implémentez quelque chose pour le PCIe, vous avez alloué de la main-d'œuvre spécifique au développement de la logique s'interfaçant avec l'ordinateur, ainsi qu'une équipe logicielle pour développer le pilote (driver). Cette tâche devient nettement plus facile si Xillybus est utilisé, car cette solution prend en charge la complication des deux côtés.
Alors, quelles compétences devriez-vous apprendre pour vous préparer à un scénario avec un processeur externe ? Avant tout, cela peut beaucoup aider si vous êtes bon en programmation C, afin de pouvoir écrire les routines de pilote (driver) pour accéder au FPGA depuis le processeur, ou au moins proposer du code d'exemple. L'IA peut écrire ce code pour vous, mais si vous ne comprenez pas précisément ce que fait le code, vous pourriez finir avec un bug en C qui ressemble à s'y méprendre à un problème venant du FPGA.
À part cela, il n'y a pas grand-chose que je recommanderais d'apprendre à l'avance. Les compétences techniques requises dépendent beaucoup de la façon dont le processeur et le FPGA sont connectés, ce qui diffère d'un projet à l'autre.
Autres standards d'interface
Si vous passez en revue plusieurs cartes de développement FPGA disponibles, vous verrez que certains composants et connecteurs spécifiques ont tendance à être présents plus couramment que d'autres. Cela peut être interprété comme une indication des technologies souvent utilisées dans un projet FPGA. C'est en partie vrai, et je vais en passer quelques-uns en revue.
HDMI
Un connecteur HDMI est souvent présent sur les cartes FPGA. Le but est généralement de permettre au FPGA de générer une sortie vidéo à afficher sur un écran d'ordinateur. Les fils du connecteur vont souvent directement au FPGA, car celui-ci est capable de générer les signaux haute vitesse requis à l'aide du SERDES du bloc d'E/S. Sur certaines cartes, il y a un composant séparé (« encodeur vidéo ») entre le FPGA et le connecteur HDMI.
L'omniprésence de ce connecteur reflète en effet la réalité : beaucoup de projets FPGA impliquent une forme de traitement et de sortie vidéo. Connecter la carte FPGA à un écran d'ordinateur et expérimenter cette configuration peut être utile à l'avenir. En particulier, apprenez les bases du VGA, comment l'écran est balayé horizontalement et verticalement, et les différents modes d'affichage standards qui existent. Si le connecteur HDMI est connecté directement au FPGA, vous pouvez essayer d'implémenter la logique qui génère les signaux, mais je ne suis pas sûr que cela vaille l'effort. Ce n'est pas un protocole simple à apprendre, et s'il ne fonctionne pas, il est difficile de déboguer un tel projet : le débit sur les fils est très élevé, et l'écran d'ordinateur ne vous dira pas ce qui ne va pas quand il refuse de répondre à la sortie du FPGA. Il existe des blocs IP (IP blocks) prêts à l'emploi pour cela. Je suggère de les utiliser, et de vous concentrer plutôt sur la génération des données vidéo.
Et un petit conseil : vous voulez probablement envoyer des pixels RVB à l'écran. Dans ce cas, suivez le protocole DVI (qui est lié au VGA), et non le HDMI. Les signaux du DVI et du HDMI sont interchangeables. Mais le HDMI est un protocole plus strict destiné à la télévision haute définition standard, et possède un ensemble étroit de modes d'affichage. Les pixels des modes d'affichage couramment utilisés sont représentés au format YCbCr, ce qui constitue une difficulté inutile. Le connecteur HDMI est utilisé parce que le connecteur DVI et son câble sont gros et encombrants. Mais les signaux vers un écran d'ordinateur suivent presque toujours le standard DVI, pas le HDMI.
Si vous essayez un projet de sortie vidéo, vous découvrirez vite que les propres BRAM du FPGA ne suffisent souvent pas pour contenir une trame d'image. Cela m'amène au sujet suivant.
Mémoires DDR
La RAM propre au FPGA est une ressource relativement rare. Quand le projet nécessite de manipuler des mégaoctets et des gigaoctets, une mémoire externe est nécessaire. C'est souvent le cas dans les projets impliquant de la vidéo, mais aussi dans d'autres applications, comme le coprocessing / l'accélération matérielle, la commutation réseau et bien d'autres.
De loin, les RAM externes les plus couramment utilisées sont les DDR SDRAM, du même type que celles utilisées dans les ordinateurs. C'est pourquoi elles apparaissent souvent sur les cartes de développement FPGA, parfois sous forme de SODIMM et plus souvent soudées directement à la carte. Elles ont un prix bas et une excellente bande passante, mais elles sont conçues en pensant aux ordinateurs. En conséquence, elles sont efficaces en bande passante quand les requêtes d'accès sont de longues rafales de plages d'adresses contiguës. Le fait moins connu à leur sujet est qu'elles ont des performances vraiment lamentables quand le motif d'accès est moins discipliné : même si on les appelle « mémoire à accès aléatoire » (RAM, Random Access Memory), leur bande passante s'effondre de façon spectaculaire avec d'autres motifs d'accès. Par exemple, si un élément de données est requis à la fois, et chaque fois depuis une adresse sans rapport avec la précédente, ces mémoires se comportent extrêmement mal.
Le protocole d'interface avec les mémoires DDR est très compliqué, cependant il est rarement nécessaire que les concepteurs FPGA en connaissent grand-chose : chaque fournisseur de FPGA réputé fournit un contrôleur de mémoire DDR fiable et assez efficace sous forme d'IP core (IP core) gratuit pour une utilisation avec ses FPGA. Le concepteur FPGA n'a donc qu'à s'interfacer avec cet IP, en utilisant AXI4 ou un protocole similaire.
Les mémoires DDR sont-elles un sujet qui vaut la peine d'être appris ? Je dirais qu'il y a une assez bonne raison de le faire, car elles sont souvent utilisées dans les projets FPGA dans divers domaines. Un projet qui implique des mémoires DDR et qui génère peut-être une sortie vidéo peut être un bon exercice. Il est aussi recommandé de parcourir la fiche technique d'une mémoire DDR afin de comprendre la structure matricielle de la mémoire et la nécessité de sélectionner des lignes avant d'accéder à leurs données. Cela vaut aussi la peine de regarder les exigences de délai entre différentes opérations (CAS, RAS, refresh, etc.) afin de saisir comment elles peuvent réduire l'efficacité de la bande passante. La chose la plus importante à savoir sur ces mémoires est quand il ne faut pas les utiliser.
Cage SFP+
Beaucoup de cartes de développement, en particulier les cartes officielles des fournisseurs, ont une cage SFP+. Cette partie se démarque visuellement, car c'est un composant métallique relativement grand sur le bord de la carte. Ce connecteur n'est présent que lorsque le FPGA possède des émetteurs-récepteurs multi-gigabits (MGT, appelés GTX, GTH, GTY, etc. sur les FPGA AMD). À l'intérieur de la cage, un connecteur établit une connexion directe à un ou plusieurs des MGT du FPGA.
Un MGT est une unité fonctionnelle permettant une communication bidirectionnelle à des débits gigabit, généralement 1 Gbit/s et plus. C'est le cheval de trait derrière plusieurs protocoles bien connus, en particulier PCIe, SuperSpeed USB, SATA, Gigabit / 10G Ethernet et DisplayPort. Il y a toute une série de pages sur les MGT sur ce site, en commençant par une page expliquant les MGT en général.
L'usage principal de la cage SFP+ est d'y insérer un module à fibre optique. Cela permet de connecter deux cartes FPGA avec un câble à fibre optique, ou de connecter la carte FPGA à une autre unité disposant d'une interface similaire, par exemple un routeur de réseau à fibre optique. Le module à fibre optique n'est généralement pas inclus dans le kit de la carte de développement FPGA, mais ceux-ci ne sont pas très chers. Il existe aussi des câbles permettant de connecter directement deux connecteurs SFP+, sans fibre.
Le fait que les cages SFP+ soient si courantes sur les cartes FPGA signifie-t-il que vous devriez devenir expert en MGT dès que possible ? Je ne dirais pas cela. Elles apparaissent beaucoup sur les cartes, entre autres parce que le composant sur la carte est bon marché et ne nécessite pas de composants supplémentaires ni beaucoup de connectivité. C'est aussi un moyen élégant de connecter deux cartes FPGA comparé aux alternatives (qui consistent généralement en quatre câbles RF connectés à chaque MGT).
Et les MGT ne sont pas faciles à utiliser : ils sont à certains égards similaires à des canaux radio numériques. Il y a des erreurs de bits sur la liaison, la fréquence d'horloge de l'émetteur n'est souvent pas exactement la même que celle du récepteur, le récepteur doit trouver le début des trames de données dans le canal de données, et la liste continue.
Il est donc courant que les MGT soient utilisés avec un bloc IP (IP block) qui gère le protocole de communication. En particulier, pratiquement tous les FPGA dotés de MGT ont aussi un bloc IP matériel implémentant le protocole PCIe. Il existe aussi des IP cores (IP cores) pour plusieurs autres protocoles bien connus utilisés avec les ordinateurs. Pour une connexion entre deux FPGA, Xillyp2p présente une interface simple.
Donc même si les MGT sont partout, ce sujet n'est pas nécessairement la première chose à apprendre.
Ethernet
Beaucoup de cartes de développement FPGA ont un connecteur Ethernet. La raison derrière cela dépend du type de FPGA.
Le cas le plus simple à expliquer est celui où le FPGA contient un processeur, par exemple les dispositifs Zynq d'AMD. Sur ces cartes, le connecteur Ethernet est presque toujours connecté aux broches dédiées du processeur à cette fin. C'est exactement comme le connecteur Ethernet sur n'importe quelle carte avec un processeur embarqué.
Et les cartes avec des FPGA sans processeur ? D'abord, même un tel FPGA peut contenir un « processeur logiciel » (soft processor) (par exemple MicroBlaze ou Nios). Un tel processeur peut faire le même bon usage d'un connecteur Ethernet que n'importe quel autre. Ce n'est pas nécessairement un scénario d'usage courant, mais pendant longtemps les fournisseurs de FPGA ont tenté de promouvoir l'idée d'utiliser des FPGA dans les centres de données. Ils voulaient vraiment établir un lien mental entre les FPGA et les ordinateurs. Le connecteur Ethernet en fait partie.
S'il n'y a aucun processeur sur le FPGA, le connecteur Ethernet peut servir à communiquer avec un ordinateur. TCP/IP est peut-être la première chose qui vient à l'esprit, mais ce protocole est taillé pour une implémentation logicielle. L'implémenter en logique est compliqué et donne des fonctionnalités limitées. La pile de protocoles doit aussi répondre aux requêtes ARP et de préférence aussi aux paquets ICMP.
Par conséquent, la seule façon pratique d'utiliser Ethernet pour connecter une carte FPGA (sans processeur) à un ordinateur est avec des paquets de diffusion (broadcast) : la carte FPGA et l'ordinateur sont connectés point à point. Les trames Ethernet transmises sur le câble ont toutes l'adresse MAC de diffusion. Cela se fait souvent en utilisant des paquets UDP/IP de diffusion. C'est donc à des kilomètres de la façon dont on connecte habituellement un ordinateur à un réseau Ethernet.
Outre le fait de ne pas être élégante, cette solution a un inconvénient important : le protocole Ethernet ne garantit pas la livraison des paquets. S'il y a une erreur de bit dans un paquet Ethernet, il est abandonné silencieusement. La carte réseau de l'ordinateur peut aussi abandonner un paquet au hasard, sans aucune raison. Cela passe inaperçu en usage normal.
Par conséquent, si la perte de données n'est pas permise, le FPGA doit garder toutes les données qu'il transmet dans un tampon afin de faire des retransmissions. Un protocole avec un mécanisme de détection d'erreur doit être appliqué afin de demander ces retransmissions. Bien faire cela sur Ethernet devient vraiment compliqué.
Alternativement, la possibilité de perte de données est acceptée. Ou, comme cela arrive souvent dans les projets d'étudiants et de bricoleurs, cette possibilité est ignorée, parce que cela ne se produit pas quand le système est testé. Ce qui est suffisamment bon quand le projet n'est pas professionnel.
En résumé : utilisez absolument le connecteur Ethernet s'il y a un processeur qui tourne sur votre carte, en particulier s'il exécute Linux. Mais je ne suggérerais pas d'aller plus loin que cela.
C'est la fin de la quatrième page de cette série, et cela conclut aussi la discussion des compétences professionnelles. La page suivante prend une direction complètement différente : quel type de personnalité est préféré pour ce métier ?