Langages de Description de Matériel
Si on vous dit langage de description de matériel, vous pensez sûrement au VHDL et au Verilog.
Néanmoins, outre ces HDL (Hardware Description Languages), il existe aussi des technologies de synthèse de haut niveau ou HLS (High-Level Synthesis), ainsi que des technologies de génération de code automatique.
Arthur, ingénieur systèmes embarqués chez ELSYS Design, nous présente ces différentes options, avec leurs avantages et inconvénients.
Sommaire :
Un langage de description de matériel, qu’est-ce que c’est ?
Un langage de description matériel (HDL : Hardware Description Language) est un langage permettant de décrire un circuit électronique à plusieurs niveaux. Son but initial est l’instanciation de composants (comme des portes logiques) et leur interconnexion pour en définir de plus gros.
Ces langages ne sont pas des « langages de programmation » comme peuvent être le C, le JavaScript, ou encore le Python. En effet, ils ne sont pas là pour formuler des algorithmes sous la forme d’une suite d’instructions ; ils fournissent plutôt une description de tout un circuit de manière simultanée au même titre que le HTML décrit l’ensemble d’une page web. Ils intègrent ainsi des paradigmes de parallélisme.
Cependant, il existe tout de même des systèmes d’évènements pour traduire de la logique séquentielle et ainsi pouvoir formuler des algorithmes.
Tout comme le C peut être vu comme un langage haut niveau permettant d’abstraire du code assembleur par l’intermédiaire d’un compilateur, les langages de description hardware ont leur mécanisme de traduction qui s’appelle la synthèse (faite par un synthétiseur).
En réalité, un tel langage « pur » n’existe pas. En effet, comme un peu partout dans le développement, un morceau de code ne vient jamais seul, il est souvent accompagné d’un code de test. Pour des raisons pratiques, ces tests les plus basiques sont rédigés dans le même langage. Ainsi, il a fallu introduire dans le langage des mécanismes pour décrire facilement des suites d’instructions nécessaires pour la rédaction de ces tests. Ces constructions sont dites « non-synthétisables » par opposition aux « constructions synthétisables » qui, elles, ont vocation à être synthétisées. A noter que l’on peut utiliser des constructions synthétisables pour du test.
Il existe plusieurs langages de description matériel, les plus connus étant le VHDL et le Verilog créés uniquement pour résoudre ces problématiques. Mais il existe aussi des sur-ensembles (supersets) et des bibliothèques pour des langages existants afin de les rendre synthétisables.
Aujourd’hui, ces langages sont utilisés dans des composants programmables tels que les FPGA ou les CPLD, mais aussi pour le design d’ASIC. Ils le sont aussi dans une moindre mesure pour de la vérification.
Les HDL traditionnels
VHDL
Le VHDL (VHSIC-HDL : Very High Speed Integrated Circuit Hardware Description Language), issu du standard IEEE 1076, est un langage développé pour l’armée américaine dans les années 80. Il est le premier langage à vraiment s’imposer dans l’industrie.
Sa syntaxe est basée sur l’Ada. Il a connu plusieurs évolutions, les deux dernières datent de 1998 et 2008.
Néanmoins, cette dernière version ne fait pas pleinement l’unanimité partout dans l’industrie, notamment parce que les domaines d’applications liés à ces technologies ont des besoins critiques en sécurité (militaire, spatial, aéronautique, ferroviaire…) ou parce qu’elles doivent s’imposer chez des géants du monde de la microélectronique (Intel, AMD, STMicroelectronics, NXP…).
Aujourd’hui, le VHDL est principalement utilisé en Europe et sur la côte Est des États-Unis.
Il bénéficie aussi de l’extension VHDL-AMS pour des problématiques liées au monde analogique / mixte.
Verilog
Le Verilog est à l’origine un langage propriété de Cadence développé dans le même temps que le VHDL. Cependant, étant donné le succès du VHDL qui était « libre », Cadence a rapidement pris la décision d’ouvrir le standard.
Sa syntaxe est basée sur le C, il a ainsi la réputation d’être moins « verbeux » que le VHDL. Aujourd’hui, il est principalement utilisé sur la côte Ouest des États-Unis.
Lui aussi a connu son extension analogique / mixte sous le nom de Verilog-A.
Contrairement au VHDL, le Verilog n’a pas connu de mise à jour majeure jusqu’à la définition d’un nouveau langage, le SystemVerilog. Ce dernier est beaucoup plus haut niveau avec des propriétés telles que l’orienté-objet, qui donnent la possibilité de créer des bibliothèques et des frameworks complexes. On peut citer l’UVM (Unified Verification Methodology) qui s’est vraiment imposé dans l’industrie pour la vérification d’IP.
Apportons néanmoins une nuance : comme pour le VHDL-2008, le SystemVerilog est loin de s’être imposé pour la partie design (pour les même raisons que nous avons décrites précédemment).
Principaux avantages du VHDL et du Verilog
Les avantages du VHDL et du Verilog sont bien connus, nous allons donc présenter les deux principaux de manière succincte.
Tout d’abord, ces langages sont très bien supportés par tous les outils (nombreux et très complexes dans notre industrie).
Ensuite, ils sont également appréciés pour leur cadre strict : ces langages sont très peu permissifs, ce qui constitue un atout de taille dans un milieu où la moindre erreur coûte très cher. En effet, il n’y a souvent qu’une seule façon de faire les choses, ce qui limite en partie la dette technique par exemple.
Technologies de synthèse de haut niveau (HLS)
HLS : origines
Dans le monde du logiciel, on utilise de plus en plus des langages haut niveau qui viennent s’exécuter sur une plateforme qui a pour sa part été implémentée via des technologies plus bas niveau. On a par exemple le Python et le Java : compilés en pseudo code, ils s’exécutent sur une plateforme virtuelle, le JavaScript, et sont ensuite interprétés par un navigateur web. Cela permet généralement de gagner énormément en productivité et en maintenabilité.
Pour le hardware, cette approche est impossible, on peut certes s’appuyer sur des bibliothèques de composants mais on très vite limité. L’idée est alors apparue de créer un nouveau langage plus haut niveau mais avec un synthétiseur beaucoup plus performant ; ainsi est né le HLS (High-Level Synthesis). En pratique, aucun nouveau langage n’a été créé car toutes ces technologies se basent sur le C/C++.
HLS : fonctionnement
Le choix du C/C++ n’est pas anodin. Il y a trois principaux avantages :
• Sa facilité d’utilisation : tous les développeurs hardware se doivent d’avoir des bases en C/C++.
• Il s’agit d’un langage compilé avec de nombreuses toolchains open sources.
• Enfin, il est possible d’intégrer des directives de compilation à l’intérieur du code (#pragma).
Toute l’idée est d’écrire un programme en C/C++ et d’ajouter ces fameuses directives pour spécifier ce que l’on veut au niveau hardware.
Ces directives peuvent concerner les variables : est-ce qu’on veut utiliser des FF, des BRAM… ?
Il y en a pour les boucles : s’agit-il d’une « boucle itérative » comme en software ou d’un « for generate » comme en hardware ?
Faut-il créer un pipeline pour réduire le temps d’exécution, mais utiliser plus de ressources ?
En fait, ces directives sont là pour fixer les meilleurs compromis souhaités en termes de performances temporelles par rapport à la quantité de ressources à utiliser.
Le workflow classique d’une implémentation HLS consiste à créer un code testbench qui va appeler notre fonction à accélérer avec les bonnes entrées / sorties, puis vérifier l’intégrité des sorties. Il va ensuite itérer sur l’accélérateur jusqu’à obtenir les performances souhaitées en réécrivant certaines parties du code et en jouant sur les directives.
Au final, le compilateur HLS génère des fichiers VHDL ou Verilog qui pourront être intégrés comme tous les autres modules.
En termes de vérification, il en existe deux types :
- La « C Simulation », qui consiste à exécuter tout le code C compilé avec un compilateur classique pour PC.
- La « Co-Simulation », qui consiste à exécuter tout le code C du testbench compilé avec un compilateur classique pour PC et de le simuler via le code RTL généré pour l’accélérateur.
HLS : avantages
Les avantages principaux du HLS sont le temps de développement fortement réduit, la possibilité de faire des changement mineurs dans les spécifications / le code C qui aurait un impact énorme sur le RTL.
Le code RTL généré suit les bonnes pratiques de codage, il est possible de faire un design à fréquence élevée (comme 200MHz sur un Zynq 7’s series), même en étant un designer junior.
Le workflow de vérification est aussi très agréable, en effet, le testbench est écrit en C/C++, s’exécute sur notre machine (x86_64), on peut donc utiliser toute nos librairies standard Linux / Windows ou encore OpenCV, ce qui est vraiment pratique pour lire des images jpeg par exemple (c’est plus compliqué avec un testbench SystemVerilog par exemple) et ceci de manière bien plus rapide. En effet, bien que la Co-Simulation offre des temps de simulation plus faibles (mais relativement proches d’un workflow classique), la C-Simulation offre des temps de simulation facilement 100 fois inférieurs.
Attention tout de même, ce n’est pas un outil pour les développeurs logiciel. Comme en VHDL ou en Verilog, lorsque l’on écrit une ligne de HLS, on doit avoir en tête les implications en termes de ressources ; la connaissance du hardware est donc nécessaire.
Une bonne pratique consiste donc à confier la partie codage à un ingénieur FPGA, avant que l’ingénieur systèmes embarqués puisse dans un deuxième temps se l’approprier et modifier certains paramètres.
Technologies de génération de code automatique
Exemple et définition
Une autre façon d’ajouter un niveau d’abstraction consiste à créer des outils de génération de code. Vous en avez peut-être déjà utilisé si vous avez fait du design FPGA avec le logiciel Vivado de Xilinx. On en retrouve à plusieurs niveaux, par exemple pour de la configuration d’IP. En effet, c’est ce qui se cache derrière certains assistants logiciel (wizards) tels que le générateur d’horloge ou les contrôleurs de mémoire.
Le top-level est également généré par un script à partir du design réalisé en graphique (generate wrapper). Quand on crée une IP, on peut générer automatiquement l’interface AXI en fonction des registres à disposition.
Ces technologies sont aussi utilisées dans le monde de l’ASIC. Elles sont souvent insérées dans les architectures afin que l’on puisse utiliser ces outils, notamment pour de l’interconnexion entre les différentes IP.
Fonctionnement
Leur fonctionnement reste le même, il s’agit :
- D’acquérir des données pour savoir ce qu’il faut générer.
- Vérifier la cohérence des données d’entrée.
- Générer des fichiers sources (VHDL, Verilog).
Ce code peut être vérifié de différentes manières : génération de fichier de test en plus des fichiers sources, vérification formelle etc.
La principale différence entre ces outils vient de l’implémentation. Il s’agit le plus souvent de scripts Perl, Python ou TCL qui analysent des tableaux Excel, y ajoutent un peu de logique et génèrent des fichiers VHDL ou Verilog.
Des solutions plus complexes avec d’autres langages et qui traitent des bases de données plus standard peuvent exister. Néanmoins, on sort du cadre d’une petite équipe d’architectes qui développent leurs scripts ainsi que des implémentations plus poussées de Xilinx.
Avantages
Dans le cas des outils Xilinx, ces technologies permettent de générer rapidement une partie du design, même complexe, ce qui permet de dégager du temps pour se concentrer sur la partie fonctionnelle, mais aussi de garantir la propriété intellectuelle de certains blocs.
Ces outils ont souvent été créés par et pour des architectes. Ils peuvent leur permettre de réaliser plus rapidement des changements dans la spécification.
On peut également avoir plusieurs générateurs pour des mêmes entrées, et ainsi générer différents RTL : un pour la vérification fonctionnelle facile à comprendre, et une version restructurée faisant apparaître les différents domaines de power ou d’horloges avec des IP qui peuvent être séparées en plusieurs morceaux. On peut alors s’assurer de l’équivalence des deux RTL via d’autres outils formels.
Enfin, en termes de rentabilité, on pourrait penser qu’il est plus facile de maintenir les fichiers sources plutôt qu’un script compliqué utilisé à plusieurs endroits. En fait, un script de 2000 lignes de code pourra permettre de générer 20k lignes de code…
Conclusion :
Il y a quelques années, seuls le VHDL et le Verilog permettaient de développer du hardware. Aujourd’hui, les technologies sont multiples, avec chacune leurs avantages et inconvénients.
On n’a pas fini d’en parler !