Composant FPGA d'un simulateur d'environnement électromagnétique.

Un simulateur d'environnement électromagnétique est un programme multicartes. Chez Thales LAS, celui-ci repose sur une dizaine de FPGA Xilinx Virtex UltraScale+, sur des cartes du commerce, chacun relié à des composants de conversion analogique/numérique, à ses voisins, à de la mémoire, et au logiciel qui le pilote.

Chacun de ces dialogues a son protocole, ses horloges, ses dizaines de paramètres. Et chacun doit tenir dans la durée, sans ambiguïté sur ce qu'un registre veut dire côté FPGA et côté logiciel. C'est cet ensemble — les liaisons, puis les registres qui les pilotent, puis l'outillage qui les produit — que j'ai pris en charge au sein d'une équipe de sept développeurs FPGA.

J'ai mis en œuvre seul les liaisons du composant : PCIe vers le logiciel hôte, AURORA sur fibre optique entre cartes, JESD204B et JESD204C vers deux composants de conversion analogique/numérique distincts, et la mémoire DDR.

La difficulté n'était pas conceptuelle mais concrète : s'approprier les IP Xilinx, comprendre finement ce que chaque paramètre change dans l'établissement du lien, et surtout ne pas se contenter d'un lien qui semble fonctionner. J'ai développé des outils de mesure embarqués dans le FPGA pour objectiver les performances de chaque liaison plutôt que les supposer.

Chaque FPGA est piloté par des bases de registres accessibles en AXI-Lite, distribuées par des crossbars. Multipliées par une dizaine de cibles, cela représente des milliers de registres, que le FPGA et le logiciel doivent lire exactement de la même façon.

Écrits à la main, ces registres dérivent : entre le code et sa documentation, et surtout entre le FPGA et le logiciel, qui n'évoluent pas au même rythme. À cette échelle, ce n'est plus une gêne mais un risque projet.

En binôme avec un développeur logiciel, j'ai mis en place un atelier où tout part d'une description XML unique. Deux générateurs, en TCL et en Python, en tirent tout le reste : le VHDL des bases de registres, le code de pilotage côté logiciel, la documentation, les crossbars et leurs connexions, et les bancs de test. En quelques secondes, pour l'ensemble des cibles. Ce réflexe d'outillage traverse tout mon parcours — il fait l'objet d'une fiche dédiée.

Avec autant de cibles et de versions, une question revient sans cesse : ce FPGA-là, chargé sur cette carte-là, correspond-il bien à cette base de registres-là ? J'ai automatisé le versionnement et l'identification du FPGA et de ses bases de registres, pour que la réponse soit lisible depuis le logiciel, sans intervention manuelle — un point de rigueur qui compte dans un contexte défense.

Les liaisons sont en place et mesurées ; l'atelier sert à l'ensemble des cibles du programme et a fait disparaître une classe entière d'erreurs de recopie, ainsi que la dérive entre FPGA, logiciel et documentation. Le temps gagné à chaque nouvelle carte s'est reporté sur ce qui compte vraiment : la mise au point des liens eux-mêmes.

Rien de spectaculaire dans le principe — une source unique, tout le reste généré — mais une valeur qui se mesure directement à l'échelle du système et à la rigueur qu'il exige. Ce projet marque aussi mon retour au FPGA après plusieurs années : ce fil-là est raconté dans la fiche rôle.

Deux choses resteront de cette année, et aucune ne se trouve dans le code livré.

La première est le binôme avec un développeur logiciel. Concevoir un outil à deux, chacun depuis son côté de l'interface, oblige à se mettre d'accord sur ce que « la même chose » veut dire pour un registre vu du FPGA et vu du logiciel. C'est une discussion qu'on n'a jamais lorsqu'on écrit les deux côtés soi-même, et elle rend le résultat meilleur.

La seconde est le plaisir de fabriquer l'instrument avant la mesure. Un lien haute vitesse ne se laisse pas observer de l'extérieur : il faut construire, à l'intérieur du composant, de quoi le regarder fonctionner. Passer de « le lien s'établit » à « voici exactement ce qu'il fait » est le moment que j'ai préféré sur ce projet.