Développement de logique programmable nouvelle génération

Il fut un temps où, avant l'âge de la synthèse logique, un ingénieur aurait pu se voir demander de concevoir un système purement logique. À l'époque, les radars existaient, mais pas les microcontrôleurs, et nous utilisions le traitement des signaux numériques, mais pas de processeurs de signaux numériques prêts à l'emploi. Toutefois, nous avions le radar à traitement numérique.

En ce temps-là, il était attendu d'un ingénieur fraîchement diplômé qu'il sache concevoir du matériel analogique et numérique, et développer des logiciels. Je crains que l'ère de l'ingénieur éclectique et polyvalent ne soit en passe de disparaître, et je m'inquiète pour l'avenir de la conception logique. Il y a un adage qui dit que lorsqu'un menuisier n'a qu'un marteau, chaque problème ressemble à un clou. En est-on arrivé au stade où chaque problème est considéré comme un problème logiciel ?

Si vous cherchez les termes « applications FPGA » sur Internet, vous trouverez une liste d'applications à la pointe de l'ingénierie électrique. Ces applications s'étendent de l'intelligence artificielle et de la reconnaissance vocale aux communications et au traitement d'images. Le problème avec ces applications, c'est qu'elles ne sont pas simples. Elles ne s'adressent pas aux débutants. La courbe d'apprentissage pour maîtriser l'implémentation de ces applications est raide et inclut plusieurs sujets épineux.

Il faut étudier les dispositifs logiques programmables eux-mêmes, leur environnement de développement intégré (IDE, propre à chaque fabricant), les nouveaux paradigmes de programmation (c'est-à-dire les langages de description de matériel [HDL] et leur adaptation à la concurrence et au concept de temps), et il faut comprendre l'application elle-même. Ces aspects sont pratiquement insurmontables, sauf pour des experts. Cela n'est pas de bon augure pour la prochaine génération de concepteurs de logique qui souhaitent mettre à profit leurs compétences en logique programmable. La première marche est trop haute. Je pense que cela en dissuade plus d'un d'investir le terrain, ce qui réduit la proportion de ceux qui pourraient devenir les fanatiques de la logique programmable de demain. On trouve sur Internet de nombreux récits de personnes qui expriment leur frustration quant à l'état actuel de la conception logique programmable, et plusieurs communautés open-source essaient d'y apporter une réponse. Nombreux sont ceux qui pensent que le salut viendra de la métaprogrammation, une technique de programmation selon laquelle un programme traite un autre programme comme ses propres données.

Les entreprises spécialisées en logique programmable sont en mauvaise posture. D'un côté, leurs investisseurs leur demandent de développer des puces toujours plus performantes et onéreuses, et de l'autre, il y a de moins en moins de personnes capables de les utiliser. Leur solution est de transformer les développeurs logiciels en concepteurs matériels, et cela se fait grâce à de nouveaux outils.

Les compilateurs HLS (High Level Synthesis) font passer l'abstraction de conception à un niveau encore plus élevé, et cela nous éloigne encore plus des racines de la conception logique. Il est remarquable que nous puissions produire des conceptions matérielles sophistiquées à partir de descriptions purement logicielles, mais on perd alors l'attrait viscéral que la conception logique peut avoir sur les gens. Je ne vais pas dire qu'on peut « désoptimiser » un ordinateur, mais je maintiens qu'il était plus facile de concevoir des circuits simples avant. Le problème, c'est que les circuits simples sont plus difficiles à concevoir aujourd'hui qu'ils ne l'étaient auparavant.

Je me souviens de mon immense bonheur le jour où j'ai vu ma conception logique artisanale fonctionner sous la forme d'un circuit. Mon ingéniosité m'avait permis de réduire le nombre de dispositifs nécessaires. Quand j'ai étudié la logique programmable au début des années 1990, j'étais enchanté de pouvoir appliquer mes propres connaissances en conception de circuits pour mettre en œuvre ma logique dans un dispositif de 128 éléments logiques, avec mon cerveau ayant choisi chacun de ces éléments logiques. Je ne dépendais pas de l'intelligence d'un quelconque développeur d'algorithmes.

Si la conception logique évolue, il en va de même pour la conception logicielle. Le monde de la programmation est aujourd'hui largement orienté objet (OOP), et les bibliothèques de modèles de conception courants sont bien documentées et facilement accessibles dans les bibliothèques de code. Mon livre de modèles de conception est un texte autrefois populaire d'Erich Gamma, et al., intitulé Design Patterns, Elements of Reusable Object-Oriented Software (Design patterns. Catalogue de modèles de conception réutilisables). Je trouve intéressant que la conception matérielle ait commencé en étant orientée objet, mais que son développement ait été retardé par l'introduction des langages HDL. Même si les langages HDL permettent la réutilisation des conceptions, les bibliothèques de conception renferment la plupart des fonctionnalités fondamentales. Cherchez « liste de circuits intégrés série 7400 » sur Internet, et vous trouverez certains des premiers modèles de conception matérielle. Je trouve intéressant que Meilir Page-Jones, dans son livre Fundamentals of Object-Oriented Design in UML, référence les circuits intégrés comme des exemples de conception d'objets adéquate, à haute cohésion et faible couplage. Or, dans la quête de dispositifs logiques programmables toujours plus complexes, nous avons perdu ce qui nous reliait à une conception logique simple et directe. Les méthodologies de conception actuelles dépendent d'un algorithme informatisé pour implémenter notre logique. Je pense que cette approche constitue une barrière pour les débutants en logique programmable.

Vous vous demandez peut-être combien il y avait de lignes de code dans le premier jeu vidéo Pong que nous utilisions sur nos téléviseurs. La réponse est zéro. C'était purement matériel (voir la Figure 1), il n'y avait aucun logiciel ! Je doute qu'il y ait beaucoup d'ingénieurs fraîchement diplômés capables de concevoir Pong sans utiliser de logiciel. Ils se demanderaient pourquoi faire sans. Et je leur répondrais : « Pour la perspective, et pour savoir que vous pouvez vous en passer. C'est plus simple que ce que vous pensez. »

Figure 1 : Schéma de Pong. (Image : trouvée via le blog Adafruit, d'origine inconnue)

Début 2019, l'IEEE a publié une liste des langages de programmation aimés et détestés des ingénieurs. On y apprend que les ingénieurs adorent Python. Cela ne m'étonne pas. Il y a plusieurs années, j'ai été juge lors d'un concours de conception de Texas Instruments et j'y ai appris que, sur les dix équipes universitaires, neuf avaient utilisé Python pour leur projet. Le langage de description du matériel VHSIC (VHDL) et le langage Verilog ne figurent pas sur la liste des langages aimés ou détestés. Les éditeurs de l'IEEE ne considèrent peut-être pas les HDL comme des langages de programmation, mais je pense plutôt qu'aucune des personnes interrogées n'a en fait envisagé les langages HDL. Si tel est le cas, cela montre à quel point peu d'ingénieurs pensent à ces langages ou même à la conception logique, ce qui est plutôt mauvais signe pour ce domaine.

Alors, que faire ? Comment créer chez les nouveaux ingénieurs l'état d'esprit nécessaire pour considérer la solution d'un problème d'un point de vue logiciel ou matériel ? Après tout, la plupart des problèmes peuvent être résolus de l'une ou l'autre des façons. J'ai une idée.

Je pense que la plateforme Arduino a poussé une multitude de jeunes gens à s'intéresser aux logiciels. Ils entrent dans des écoles pour devenir ingénieurs et informaticiens. Comment la plateforme a-t-elle entraîné cela ? Arduino a réduit la courbe d'apprentissage nécessaire pour développer des logiciels. Elle a rendu le développement logiciel moins intimidant.

En définissant une carte, les fichiers de commande de l'éditeur de liens ont pu être éliminés, les noms de signaux sont devenus standard et l'IDE a masqué les détails de compilation. L'une des merveilles du langage Python, c'est qu'il requiert un formatage strict : les indentations doivent être uniformes, par exemple. Cela élimine les choix arbitraires à faible valeur, avec pour effet de faciliter l'ensemble du processus de développement. Ainsi, les développeurs sont plus productifs. Il nous faut la même chose pour la logique programmable, et c'est au secteur de la logique programmable de collaborer sur une norme.

Voici quelques-uns des attributs que je préconise pour cette norme. Arduino n'ayant pas la capacité inhérente et robuste de modifier son architecture sous-jacente (par exemple pour accueillir des interruptions imbriquées), supposons que les problèmes de logique à résoudre sur cette plateforme sont suffisamment simples pour que les dispositifs logiques programmables actuels puissent répondre à toutes les contraintes de temporisation. La carte de dispositif logique programmable (PLDB) équivalente d'Arduino doit avoir une horloge suffisamment lente pour que toute conception de 1000 éléments logiques fonctionne. Cela signifie que seule une vérification fonctionnelle est requise par la plateforme.

Comme tout le monde adore Python, je propose que la carte PLDB soit prise en charge par Python et basée sur une structure comme nMigen ou MyHDL (voir la Figure 2), ou même sur Yosys avec RTLIL. Cela permettrait aux débutants de simuler leurs conceptions logiques avec un langage interprété, de produire des tables de vérité et d'accéder à toute autre bibliothèque Python disponible. En parlant de bibliothèque Python, l'utilisation de Python permet aussi à la communauté d'utiliser PyPI (Python package index) pour distribuer des blocs matériels réutilisables, ce qui aide à répondre au manque de modèles de conception robustes partagés. nMigen, comme Python, prend en charge la métaprogrammation, donc, même si cette structure prend uniquement en charge des conceptions simples, la plateforme est évolutive pour prendre en charge des conceptions complexes.

Figure 2 : Structure basée sur Python. (Sources des images : MyHDL.org et m-labs.hk)

L'interface d'un PC hôte vers une carte PLDB doit être de type USB avec un microcontrôleur à PLDB embarquée, avec une API que le PC hôte peut utiliser pour connaître la configuration PLDB afin de pouvoir configurer automatiquement l'environnement Python pour le développement logique programmable. Le résultat de cette configuration sera de masquer les détails de la synthèse, de l'emplacement et du routage, et d'effectuer la programmation tout en facilitant la simulation fonctionnelle sur le PC et l'exécution sur le matériel réel.

Au cas où certains lecteurs penseraient qu'il n'y a plus de problèmes de logique simples à résoudre, laissez-moi vous montrer quelques statistiques sur les ventes de microcontrôleurs de Digi-Key. La Figure 3 montre la répartition des catégories de microcontrôleurs que les clients achètent et la Figure 4 montre combien d'unités de chaque catégorie sont vendues. En tout, Digi-Key affiche plus de 80 000 références de microcontrôleurs et stocke plus de 19 000 microcontrôleurs prêts à être expédiés partout dans le monde. Les chiffres montrent que les processeurs 8 bits simples sont utilisés par un plus grand nombre d'ingénieurs et que Digi-Key expédie plus de microcontrôleurs 8 bits que n'importe quelle autre catégorie de processeurs. Cela m'amène à penser qu'il y a plus de problèmes simples que de problèmes complexes.

Figure 3 : Nombre de clients Digi-Key par type de microcontrôleur acheté. (Source de l'image : Digi-Key Electronics)

Figure 4 : Nombre d'unités vendues par type de microcontrôleur de Digi-Key. (Source de l'image : Digi-Key Electronics)

Notre objectif devrait être de faire de tous, même de ceux qui n'ont pas reçu d'éducation formelle en conception logique, des passionnés de logique programmable ; mais nous devons pour cela changer les paradigmes de développement.