Les règles d’or d’une bonne conception FPGA

Introduction

Le métier de concepteur FPGA exige une variété de compétences qu’il m’est bien sûr impossible de résumer en une page. Il existe cependant quelques lignes directrices générales qui s’appliquent tout particulièrement à cette profession. J’ai essayé de les condenser en cinq règles d’or pour la conception FPGA.

Règle n° 1 : Sachez ce que vous faites

C’est la première règle, et la plus difficile à respecter. Elle suppose de comprendre ce que signifie chaque ligne de code, chaque contrainte ou commande de configuration, et quelles en sont les implications. C’est comprendre la théorie sous-jacente de la conception logique, et la manière dont les outils de conception réagissent à ce qu’on leur donne.

C’est tout le contraire de la méthode essai/erreur, que les fournisseurs d’outils de développement high-tech encouragent implicitement en proposant des débogueurs, des simulateurs et toute une panoplie d’outils commercialisés avec l’argument « c’est facile ».

Il n’est pas rare de développer un logiciel en griffonnant quelques lignes, en faisant un essai avec le débogueur, en voyant ce que ça donne, en corrigeant, puis en recommençant. De temps en temps, des extraits de code trouvés dans des exemples sur Internet sont aussi copiés-collés dans le logiciel. Cette habitude de travail itérative peut être assez productive avec des logiciels simples, comme la création de sites web ou d’applications pour smartphones : les petits bugs ne sont pas bien graves et peuvent être corrigés au fur et à mesure, du moins c’est l’attitude courante.

Mais plus le logiciel est sophistiqué, plus cette méthode mène vite à une impasse. Et quand il s’agit de conception FPGA, les pratiques de développement itératif ont tendance à se retourner rapidement et durement contre vous. Les outils de conception FPGA sont loin d’aider à prévenir les erreurs graves ou à en avertir. Vous êtes tout à fait libre de tout gâcher complètement : les outils ne vous mettront pas de bâtons dans les roues.

Règle n° 2 : Garantir que ça fonctionne

Ou : « ça marche » ne suffit pas.

Un FPGA est un circuit électronique, pas un ordinateur. Il est néanmoins tout aussi reproductible et fiable si certains principes de conception sont respectés (voir règle n° 1). Sinon, il peut très bien vous jouer des tours vicieux, pour une raison apparente ou sans aucune raison.

L’absence de bug visible ne prouve pas qu’il n’y a pas de problème — cela vaut dans tous les domaines. Par exemple, si votre plombier termine son travail et qu’aucune fuite ne s’écoule du tuyau, cela ne veut pas dire que le travail a été bien fait. Le tuyau peut se mettre à fuir plus tard parce que la pression de l’eau a augmenté, ou parce que quelqu’un l’a touché par accident.

Et pourtant, nous tombons tous dans le piège qui consiste à faire un test rapide, ou plus poussé, et à considérer que c’est terminé dès que tout semble correct. C’est à peu près acceptable pour une fuite d’eau, pour développer un site web simple ou même un logiciel qui ne fait pas partie d’une application critique. Mais pour un FPGA, ce n’est tout simplement pas suffisant.

Développer une conception pour un FPGA, c’est garantir que la conception fonctionnera. C’est amener les outils de conception à produire un flux de bits (bitstream) infaillible en utilisant les techniques qu’ils offrent pour atteindre précisément cet objectif.

C’est se prouver à soi-même, comme en mathématiques, que la conception logique est correcte, plutôt que d’essayer de raisonner en termes de « si ceci arrive, fais cela ». La logique doit fonctionner même dans les cas limites les plus bizarres, non pas parce que ces possibilités ont été envisagées individuellement, mais pour la même raison qu’une expression mathématique correcte reste vraie quoi qu’il arrive.

Le fait qu’à la fin ça marche n’est pas une raison de célébrer. C’est le résultat naturel d’un travail correct.

Règle n° 3 : Simuler à bon escient (ou pas du tout)

Une des plaintes les plus courantes des débutants en FPGA est que leur simulation fonctionne parfaitement, donc leur conception est bonne, et que le problème doit forcément se trouver ailleurs. Ce qui est bien sûr absurde.

Donc, tout d’abord, posons les choses : si le style de codage Verilog ne respecte pas des règles strictes, la simulation et le matériel peuvent se comporter de manières complètement différentes (c’est pareil avec VHDL, bien sûr). Voir règle n° 1.

Mais les simulations ne couvrent qu’une plage de temps et de scénarios limitée, même lorsqu’elles sont bien faites. Même pour une conception de taille moyenne, simuler ce qui se passe dans le FPGA pendant, disons, 100 ms prend une éternité. De plus, faire tourner réellement la conception sur le matériel expose souvent la logique à des scénarios que le concepteur n’avait pas imaginés, et donc pas simulés. Une conception qui a passé la simulation à la perfection peut donc se révéler un fiasco complet sur le matériel, simplement parce que le FPGA fonctionne beaucoup plus longtemps que la simulation ne le couvre, ou parce que des choses inattendues se sont produites.

Pour empirer les choses, les bugs sont difficiles à trouver sur le matériel, car tout se passe en parallèle. Contrairement au débogage logiciel, il n’y a rarement une séquence d’événements à suivre, et encore moins la possibilité de faire du pas à pas. Il existe bien sûr des outils pour tracer les signaux à l’intérieur du FPGA, mais il n’est pas toujours facile de savoir quels signaux tracer, ni quelle condition utiliser comme déclencheur pour la collecte des données de trace.

Fixez-vous donc comme objectif d’utiliser le moins possible les simulations. Si vous vous servez de la simulation pour corriger votre conception dans tous les sens afin de « la faire marcher », il y a de fortes chances que vous rencontriez des problèmes lorsque vous l’essaierez sur le matériel.

Au contraire, essayez d’écrire la conception FPGA pour qu’elle fonctionne parfaitement du premier coup. Cela demande de bien réfléchir avant d’écrire la première ligne de code, et de savoir ce que l’on fait (règle n° 1 ci-dessus). La simulation ne devrait servir qu’à confirmer que vous avez bien fait les choses, ou éventuellement à détecter une faute de frappe idiote. Atteindre cet objectif est un processus d’apprentissage et d’amélioration, mais il en vaut la peine. Au bout du compte, les simulations deviennent une perte de temps, car elles ne trouvent plus jamais rien à corriger.

Ce n’est pas seulement un gain de temps : les bugs à corriger sur le matériel deviennent plus rares et plus faciles à repérer.

Je suis bien conscient que la première leçon habituelle en conception FPGA est « d’abord on simule, ensuite on exécute sur le matériel », mais c’est bien pour une première leçon.

Règle n° 4 : Ne tentez pas le diable

Ou : tenez-vous-en à un style de codage bien établi.

Verilog n’est pas un langage de programmation lorsqu’il est utilisé pour la synthèse. La principale différence est que si vous écrivez quelque chose de syntaxiquement correct dans n’importe quel langage de programmation, le compilateur (ou l’interpréteur) est garanti d’exécuter exactement ce que la syntaxe signifie. Ou au pire, de signaler une erreur.

Les synthétiseurs (synthesizers), en revanche, génèrent une logique à partir d’un ensemble limité d’éléments logiques. Il est donc très facile d’écrire du code Verilog qui aboutit à une logique peu fiable, voire à du code impossible à implémenter sur un FPGA. Pour empirer les choses, s’il n’existe aucun moyen d’implémenter le code Verilog sous forme de logique sur le FPGA, les synthétiseurs produisent souvent une logique dont le comportement est différent. Il arrive très souvent que le synthétiseur fasse cela sans émettre le moindre avertissement. En d’autres termes, la logique du FPGA fait quelque chose de différent du comportement attendu (c’est-à-dire simulé), et cela sans aucun avertissement.

Et pour empirer encore les choses, les bugs dans les synthétiseurs sont beaucoup plus courants que dans les compilateurs. Un style de codage créatif peut très certainement révéler de tels bugs.

Tout ce qui précède vaut également pour le VHDL, bien sûr.

La seule façon d’éviter ce genre de problèmes est donc d’adopter un style de codage largement utilisé par d’autres. La question à garder à l’esprit est : « si le synthétiseur est perturbé par cet extrait de code, combien de personnes seront en colère à part moi ? » Si la réponse est « beaucoup de monde », vous êtes du bon côté.

S’en tenir à un style de codage éprouvé présente un autre avantage : la portabilité. Qu’on le veuille ou non, aujourd’hui vous travaillez avec un synthétiseur, et demain vous vous retrouverez avec un FPGA complètement différent et des outils de développement différents.

Pour vous faire une idée de ce à quoi ressemble un style de codage éprouvé, regardez le code Verilog que les outils génèrent pour leurs propres IP intégrées (IP cores). Il y a une certaine diversité selon les auteurs du code, mais certains schémas de codage reviennent plus souvent que d’autres. Ce sont ceux-là qu’il faut imiter.

Inutile de préciser qu’il faut travailler selon le paradigme RTL. Ce n’est pas seulement un style de codage éprouvé, c’est aussi ce que les outils FPGA attendent.

Les manuels et tutoriels sur Verilog peuvent être trompeurs, car ils essaient généralement d’être exhaustifs. Ils couvrent donc souvent beaucoup de possibilités syntaxiquement correctes, mais rarement utilisées, et parfois même inadaptées à la synthèse.

Règle n° 5 : Le timing est primordial

La conception logique n’est pas de la programmation logicielle. Il ne suffit pas d’obtenir la bonne valeur dans les signaux (wires) et registres Verilog ; il est tout aussi important qu’elle apparaisse au bon endroit au bon moment. Et que les horloges soient correctement gérées.

Voici, à peu près, les principaux sujets à traiter :

• Réfléchissez à comment et quand les données circulent dans les différents étages du pipeline, en particulier lorsque le pipeline peut être bloqué (en totalité ou en partie). En réalité, c’est valable pour tout flux de données.
• Assurez-vous que les contraintes de timing (timing constraints) sont correctes. En particulier, lisez les fiches techniques (datasheets) des composants externes et faites les calculs. Cette page aborde la vérification du timing.
• Faites attention aux horloges : sont-elles stables dès le premier instant où elles sont utilisées ? Leur gigue (jitter) est-elle suffisamment faible pour l’usage prévu ?
• Changement de domaine d’horloge (clock domain crossing) : faut-il une logique de resynchronisation ? Si oui, garantit-elle une transmission sans faille du signal d’un domaine d’horloge (clock domain) à un autre ? Vous en saurez plus ici.

En bref, contrairement aux programmes informatiques, la conception logique ne consiste pas seulement à savoir ce qui va se passer, mais aussi à savoir quand cela se passe.

Résumé

Personne n’a dit que la conception FPGA était facile, et aucune de ces cinq règles n’est facile à suivre. Chacune exige à la fois des connaissances et une certaine autodiscipline. Et pourtant, il vaut vraiment la peine de s’y tenir. Cela évite bien des frustrations, en particulier dans la dernière phase du projet, alors que tout est censé fonctionner tout simplement.