Cette page est la première d’une série de pages consacrée au timing.
La récompense : la tranquillité d’esprit
Le timing – et plus particulièrement les contraintes de timing (timing constraints) – est un immense défi pour le concepteur FPGA. La difficulté ne tient pas seulement à ce que le timing soit difficile à comprendre. Le véritable défi est de surmonter la tentation d’ignorer tout ce sujet lorsqu’on travaille sur une conception FPGA, parce que tout fonctionne correctement. Il est beaucoup trop facile de tomber dans le piège qui consiste à se contenter d’une conception lorsqu’aucun problème visible n’apparaît.
Il n’est pas rare d’entendre des concepteurs FPGA dire qu’ils savent que leur conception laisse à désirer côté timing, mais tant pis, l’électronique fonctionne comme un mécanisme d’horlogerie. Et effectivement, s’assurer que le timing est bien fait peut sembler une perte de temps à ce moment-là. Un responsable impatient de développer de nouvelles fonctionnalités ne sera pas ravi de voir deux semaines s’écouler sans progrès apparent sur le projet. En réalité, un examen approfondi du timing d’une conception peut révéler des problèmes difficiles à résoudre. Pour les observateurs extérieurs, cela peut donner l’impression d’inventer des problèmes qui n’existent pas, puis de perdre un temps précieux à les résoudre.
La vérité, c’est que, bien souvent, la stratégie consistant à ignorer le timing se révèle payante à court terme. Mais il arrive très souvent qu’un manque d’attention à ce sujet mène aux problèmes les plus exaspérants, et ils ont tendance à surgir aux moments les plus inopportuns. Par exemple, l’électronique peut tomber en panne une fois toutes les quelques heures au cours des essais de recette finale, peut-être lorsque le système est testé sur toute la plage de températures. Ou pire encore : les réclamations des clients commencent à arriver plusieurs années après la sortie du produit. Après des efforts acharnés pour trouver la raison de ces réclamations, on s’aperçoit que les FPGA de ces produits proviennent d’un lot de fabrication différent. Ainsi, même si tous les FPGA satisfont aux exigences de la fiche technique, des différences dans leur silicium ont fait que les nouveaux FPGA se comportent de manière légèrement différente.
Les FPGA se sont forgé une mauvaise réputation en raison d’incidents de ce genre. Pourtant, lorsque le timing est correctement traité, vous pouvez être à peu près certain que ce genre de choses n’arrive pas. Les FPGA sont extrêmement fiables lorsque la conception est bien faite.
Alors, rendez-vous service : prenez le temps d’apprendre le timing, puis assurez-vous d’en tirer toujours pleinement parti. Vous éviterez ainsi la peur permanente qu’un imprévu survienne dans la conception si vous changez quelque chose. Vous vous épargnerez aussi la course sans fin après des bugs qui apparaissent et disparaissent. Et surtout, vous vous habituerez à considérer le FPGA comme un composant fiable, solide comme un roc.
L’importance des contraintes de timing
La logique d’un FPGA ne peut fonctionner de manière fiable que si les exigences de timing sont satisfaites sur chaque élément synchrone de la conception. Pour en garantir le bon fonctionnement, il faut examiner tous les chemins (paths) possibles. Même avec une conception logique simple, il est impossible d’effectuer tous ces calculs à la main.
Les outils ont donc pour mission de garantir que toutes les exigences de timing sont satisfaites. Pour cela, ils doivent avoir reçu toutes les informations nécessaires pour faire les calculs demandés. Par exemple, les outils doivent connaître les fréquences de toutes les horloges, ainsi que le comportement temporel des composants externes. Ces informations sont données aux outils au moyen de contraintes de timing (timing constraints), qui se présentent généralement comme un fichier texte avec une syntaxe particulière.
Si les contraintes de timing sont mal écrites, ou si elles ne couvrent pas toutes les informations nécessaires, les outils ne peuvent pas garantir un fonctionnement fiable de la conception logique. Les outils se fient aux informations contenues dans les contraintes de timing ; si ces informations sont incorrectes ou partielles, les calculs de timing le sont aussi. Des contraintes de timing mal rédigées sont une cause fréquente de comportement non fiable du FPGA.
L’accord tacite avec les outils est donc le suivant : nous leur disons tout ce qu’ils doivent savoir sur le timing, et ils veillent à ce qu’aucune violation de timing n’apparaisse dans la conception.
Mais parfois, les outils n’arrivent pas à éviter les violations de timing. Lorsque cela arrive, ils émettent un message d’avertissement qui le signale. Ce message n’est qu’un avertissement et non une erreur ; les outils FPGA continuent donc à générer un fichier contenant un flux de bits (bitstream) qui peut être chargé dans le FPGA. Il est par conséquent important de toujours vérifier que les outils confirment que les contraintes de timing sont satisfaites. Cette confirmation se présente en général sous la forme d’un message du type « All timing constraints are met ».
Mais il n’y a pas que les contraintes de timing
En réalité, l’accord tacite entre vous et le logiciel FPGA va encore plus loin : vous respectez plusieurs règles sur la manière dont la conception FPGA doit être faite, et les outils garantissent que le FPGA ne défaillira pas. Mais si vous enfreignez les règles, les outils vous le font payer.
Bien maîtriser le timing compte pour une grande part dans ces règles. Et le timing ne se résume pas à écrire des contraintes de timing. Il y a trois aspects distincts à garder à l’esprit.
Le premier aspect est la conception logique elle-même, c’est-à-dire le code Verilog (ou VHDL). Il y a bien sûr l’exigence évidente que la logique soit « assez rapide » (ou plus précisément, que la conception logique permette à l’horloge de fonctionner à la fréquence voulue). En plus de cela, il y a plusieurs autres points à ne pas oublier :
- Les règles de base d’un Verilog (ou VHDL) correct doivent être respectées, notamment le paradigme RTL. Sinon, les outils ne pourront pas appliquer les contraintes de timing à la logique générée par le synthétiseur (synthesizer).
- Des techniques appropriées sont utilisées pour les changements de domaine d’horloge (clock domain crossing). Vous trouverez plus d’informations ici.
- Les horloges doivent être organisées de manière à éviter les confusions. En particulier, il importe d’éviter les changements de domaine d’horloge involontaires.
Le deuxième aspect consiste à écrire les contraintes de timing. Cette partie est parfois très simple, parfois elle demande un travail minutieux. Une erreur courante consiste à copier des contraintes de timing d’une autre conception (en particulier une simple contrainte de période) et à croire que le travail est terminé.
Le troisième aspect consiste à générer et à lire les rapports de timing afin de s’assurer que les outils ont rempli leur office : ils doivent garantir que la conception fonctionne de manière fiable. C’est la partie la plus difficile, car elle exige de comprendre le fonctionnement interne du FPGA. En effet, les rapports de timing sont rédigés en termes des plus petites briques du FPGA. Sans cette compréhension du FPGA, il est difficile d’en tirer une conclusion utile.
On lit en général les rapports de timing pour résoudre un problème, notamment lorsque les outils n’arrivent pas à satisfaire les exigences des contraintes de timing. Ce processus de résolution s’appelle la convergence temporelle (timing closure). Le problème le plus courant est la fréquence d’horloge trop élevée pour la conception logique (on peut dire aussi que la logique est trop lente pour l’horloge).
Comme déjà mentionné, il est fortement recommandé d’examiner de temps en temps le timing d’une conception FPGA, même lorsque les contraintes de timing sont satisfaites et que tout fonctionne parfaitement. Cela implique en particulier de consulter les rapports de timing, mais aussi de vérifier que les contraintes de timing reflètent fidèlement les besoins de la logique. La difficulté, c’est qu’un tel examen n’est pas gratifiant à court terme : il demande du temps et des efforts, et se termine soit sans aucun résultat, soit par la découverte d’un problème. Autrement dit, si l’examen est fructueux, il représente en réalité davantage de travail pour résoudre un problème que personne ne voit.
Comment ces pages sur le timing sont-elles organisées ?
Ces pages se concentrent sur les deuxième et troisième aspects de l’accord tacite entre vous et les outils FPGA : l’écriture des contraintes de timing et la lecture des rapports de timing. Ces compétences exigent à la fois des connaissances théoriques et des outils pratiques.
Les aspects pratiques des contraintes de timing sont relativement faciles à apprendre. Le plus difficile est de comprendre leur signification exacte et leur influence sur la conception. La page suivante de cette série parcourt les concepts théoriques de base. Dans les pages qui suivent, la discussion théorique se poursuit à l’aide de plusieurs exemples de rapports de timing. Toute l’histoire se joue dans les petits détails de l’analyse de timing.
Après la page suivante, deux pages traitent de la contrainte de timing la plus importante et la plus utile : la contrainte de période. Ces deux pages discutent en détail des rapports de timing, étant donné leur importance.
Elles sont suivies de deux pages consacrées à la convergence temporelle (timing closure). C’est peut-être un peu tôt pour ce sujet, mais cela explique le but de ce qui va suivre : cinq pages sur les contraintes de timing (au format SDC) relatives à la structure logique, puis deux pages sur les contraintes de timing des entrées/sorties.
La dernière page de cette série est consacrée à l’inspection d’une conception existante. Cette page ne contient rien de nouveau. Elle reprend plutôt les sujets déjà traités, mais cette fois sous la forme d’une liste de points à examiner.
Les sujets sont présentés dans un ordre qui permet de lire cette série du début à la fin. Toutefois, tous les sujets sont liés entre eux, et il y a donc beaucoup de renvois entre les pages.
Le meilleur point de départ pour continuer est la page suivante. Il n’est jamais inutile de se plonger dans la théorie du timing.