01signal.com

Exorcisme électronique : pourquoi les FPGA se comportent parfois comme s’ils étaient possédés

中文 | 日本語 | 한국어 | Français | Deutsch | Español | English

Quand les choses deviennent bizarres

Les FPGA sont, d’une manière générale, des composants extrêmement fiables. Cependant, comme toute technologie, ils ne donnent pas le meilleur d’eux-mêmes s’ils sont mal utilisés.

Malheureusement, les outils de conception FPGA disponibles ne nous aident pas vraiment, nous autres humains, à éviter les erreurs, ce qui mène trop souvent à des résultats peu fiables et imprévisibles. Plus précisément, les outils FPGA ne garantissent un fonctionnement fiable que si certaines pratiques de conception sont respectées, avec l’hypothèse implicite que nous savons ce que nous faisons. Contrairement aux compilateurs logiciels, qui refusent de générer du code exécutable si le code source contient une erreur, les outils FPGA se contentent de dire : « Voici votre bitstream, essayez‑le si vous voulez ; au fait, il y a 200 avertissements, et si vous comprenez ce que signifie l’avertissement n°143, vous comprendrez aussi qu’il y a un sérieux problème à corriger ».

Il n’est pas rare que les personnes qui travaillent avec des FPGA aient l’impression que l’électronique est possédée par une force magique et que plus rien n’a de sens. Un problème peut apparaître et disparaître à la suite de modifications totalement sans rapport, sans qu’aucune explication rationnelle ne se profile. Beaucoup d’ingénieurs correctement formés ont tendance à adopter des théories absurdes sur les FPGA pour tenter de trouver une explication à ce comportement étrange.

C’est ce qu’on appelle le « mode magie noire » : le moment où des gens sensés cessent de croire qu’il existe une explication rationnelle à leur problème et cherchent plutôt une solution fondée sur leur expérience. Tout fonctionne quand le FPGA est vraiment froid ? Très bien, mettez un gros dissipateur. Le problème n’apparaît que sur certaines cartes et pas d’autres ? Pas grave, on teste chaque carte et on jette celles qui ne marchent pas. Et ainsi de suite.

À quoi cela ressemble

Voici une liste partielle de problèmes qui peuvent faire basculer un ingénieur dans un état d’esprit irrationnel. Cela commence toujours par « tout fonctionne parfaitement, sauf quand... »

Cela s’accompagne souvent de la conviction que l’électronique elle‑même est défectueuse et ne respecte pas sa fiche technique. Les théories du complot selon lesquelles une grande entreprise expédie des composants défectueux ne sont pas rares.

Il ne s’agit donc pas simplement d’un bug. Les bugs peuvent rendre fou, c’est vrai, mais ils ont tendance à être au moins partiellement reproductibles, et ils n’apparaissent sûrement pas et ne disparaissent pas à cause de la climatisation. Je n’ai jamais entendu un ingénieur logiciel accuser le PC lui‑même d’un bug (même si c’est en réalité le cas dans de très rares occasions). En revanche, les erreurs de conception FPGA peuvent tout à fait provoquer des dysfonctionnements au niveau matériel. Il n’y a qu’un pas de là à accuser le monde entier.

Il existe pourtant une explication logique. Vraiment.

Et elle est accessible. Pas forcément facilement.

Ayant travaillé pas mal de temps comme indépendant dans ce domaine, et ayant parfois réparé des situations de ce genre, croyez‑moi quand je vous dis : sauf dans des cas extrêmement rares, le FPGA est parfaitement sain, et le problème vient probablement du bitstream.

La mauvaise nouvelle, c’est que, très souvent, il n’y a pas qu’un seul défaut dans la conception FPGA, et que ces défauts peuvent être à l’origine du problème visible. Il peut donc y avoir beaucoup de choses à corriger. Plus d’une fois, on m’a demandé de réparer une conception FPGA « quasi fonctionnelle », pour me rendre compte rapidement que l’on s’attendait, de façon irréaliste, à ce que « ce petit problème » soit réglé vite fait. Stabiliser une conception signifie souvent travailler énormément sans aucun progrès visible.

Quoi qu’il en soit, on n’a pas le choix. Sur cette page, je vais essayer de ramener la pensée rationnelle, notamment en énumérant les causes possibles de ce qui ressemble à un fantôme dans l’électronique.

Bien sûr, le mieux est encore d’éviter cette situation dès le départ. Suivre les Règles d’or que j’ai listées sur une autre page est un bon début.

Pourquoi les choses se gâtent

La réponse courte est qu’il y a quelque chose qui ne va pas dans la conception FPGA. Et lorsque c’est le cas, il y a en principe deux possibilités. La possibilité relativement heureuse est celle d’un dysfonctionnement visible et constant de ce que le FPGA est censé faire. C’est comme un bug logiciel : on le trouve, on le corrige, on constate que cela fonctionne après la correction, terminé.

La possibilité moins heureuse, c’est que le FPGA fonctionne, mais que c’est surtout un heureux hasard. Lorsque certaines conditions changent, le FPGA cesse soudainement de fonctionner correctement, puis peut‑être se remet‑il à fonctionner. Mais pourquoi cela se produit‑il ?

Voici donc le point important : un FPGA est un composant électronique et, à ce titre, sa fabrication comporte des imprécisions. Plus important encore, lorsque la température du silicium change, la vitesse à laquelle les transistors changent d’état change aussi, et il en va de même pour la vitesse à laquelle les signaux se propagent dans la matrice logique. Des variations de la tension d’alimentation influencent également la rapidité avec laquelle les choses se passent à l’intérieur du FPGA.

Ainsi, si le FPGA devient un peu plus chaud ou plus froid, un signal peut arriver à une bascule un peu plus tard ou un peu plus tôt, par rapport à l’horloge. Cela peut suffire à faire manquer à cette bascule le signal qu’elle aurait dû échantillonner, ou à lui faire échantillonner un signal qu’elle rate habituellement. Même un échauffement local du silicium peut provoquer cela, lorsque la logique voisine (et éventuellement sans rapport) de la puce devient moins ou plus active.

De même, les FPGA présentent des imprécisions de fabrication. Même si tous les FPGA qui sortent de l’usine ont réussi des tests garantissant qu’ils sont conformes à leurs spécifications, certains FPGA peuvent avoir un silicium plus rapide que d’autres. C’est pourquoi une conception logique mal réalisée peut fonctionner sur un FPGA et pas sur un autre.

Tous ces paramètres aléatoires influencent le moment où les petits composants changent d’état dans la matrice logique, et cette différence de temporisation peut faire la différence entre quelque chose qui fonctionne parfaitement et une catastrophe. De petites variations de fabrication, de température et de tensions peuvent donc avoir un effet visible.

Alors, comment un FPGA peut‑il être fiable ? Lorsque la conception FPGA est réalisée correctement, les outils de conception FPGA font en sorte que tout fonctionne toujours comme défini. Ou, plus précisément, que tout fonctionne sur n’importe quel FPGA ayant passé les tests de fabrication et utilisé dans le cadre des exigences de la fiche technique. Cela revient à avoir une température ambiante dans la plage requise (avec un refroidissement si nécessaire) et des tensions correctes sur les broches du FPGA.

Mais si les bonnes pratiques de conception FPGA ne sont pas respectées, les outils ne garantissent pas non plus un fonctionnement correct. Autrement dit, les paramètres qui ne devraient faire aucune différence deviennent cruciaux, et toute la carte cesse puis reprend de fonctionner selon des choses qui ne devraient pas avoir d’importance. Il n’y a pas de limite à l’étrangeté que cela peut atteindre.

Au risque de me répéter, voici quelques exemples :

Cela vaut la peine de le répéter encore et encore : lorsque la conception FPGA est faite correctement, tout cela n’arrive jamais. Ou du moins, extrêmement rarement. Peu de gens réalisent à quel point l’électronique est fiable lorsqu’on lit et respecte les fiches techniques, et que l’on utilise correctement le FPGA.

Mais je suppose que ce sermon arrive un peu trop tard pour ceux qui lisent cette page — le problème est déjà là. Je me suis donc appuyé sur ma propre expérience pour lister quelques raisons courantes d’un FPGA apparemment hanté. Si vous êtes confronté à un tel problème, il y a de bonnes chances que ce soit l’une d’elles.

Raison n°1 : les contraintes temporelles

Dans une large mesure, les outils garantissent le fonctionnement stable du FPGA en satisfaisant les contraintes de temporisation (timing constraints) que vous leur avez données. C’est l’accord passé entre vous et les outils : vous exprimez avec précision les exigences temporelles, et les outils veillent à ce qu’elles soient satisfaites sur n’importe quel FPGA utilisé, à condition que celui‑ci fonctionne dans sa plage de températures et de tensions autorisées.

Il n’est pas rare que les contraintes de temporisation se réduisent à une seule contrainte, qui contient la fréquence de l’horloge de référence. Cela peut suffire, mais si vous avez simplement copié cette ligne d’une autre conception en vous disant « bon, ça marche », il y a tout lieu de revoir votre copie.

En réalité, il s’agit de faire les choses correctement du point de vue de la temporisation en général. Et ce n’est pas une tâche triviale, même pour le concepteur FPGA le plus expérimenté. Cela signifie être certain que chaque chemin (path) de signal de la conception est gouverné par une contrainte qui garantit que la bascule en bout de chemin reçoit toujours le signal correctement. Sauf pour les chemins qui n’ont pas besoin d’être contraints.

Donc, la première chose à vérifier : la conception a‑t‑elle satisfait aux contraintes de temporisation ? C’est vraiment basique, mais comme la plupart des outils FPGA génèrent un bitstream quoi qu’il arrive, les débutants en FPGA peuvent tomber dans ce piège.

Ensuite, il faut passer en revue les contraintes de temporisation. Il y a une page séparée consacrée à cette vérification, mais en bref : comprenez‑vous exactement ce que signifient les contraintes de temporisation ? Leur sens est‑il exactement ce qu’il devrait être ? S’il existe des contraintes sélectives — c’est‑à‑dire qu’elles couvrent certains chemins avec des conditions de filtrage — agissent‑elles effectivement sur les bons chemins ?

Et puis, le rapport de timing doit être lu attentivement. Encore une fois, cette page séparée approfondit le sujet.

Autre chose à examiner : les passages entre domaines d’horloge (clock domain crossings). Y a‑t‑il des signaux qui passent d’un domaine d’horloge (clock domain) à un autre de façon non sûre ? Cela pourrait venir d’un manque d’attention quant à la logique associée à chaque horloge. Les passages entre domaines d’horloge sont‑ils effectués uniquement avec les FIFO créées par les outils FPGA ? Si ce n’est pas le cas, ces passages sont‑ils faits correctement et sans danger ?

Raison n°2 : des remises à zéro incorrectes

Cela peut ne pas sembler lié, mais si l’état initial de la logique n’est pas garanti, il est fort possible que cela débouche sur un comportement de magie noire.

La règle est simple : si vous n’avez pas sérieusement réfléchi aux remises à zéro et au réveil de la logique, il y a de fortes chances que vous vous y soyez mal pris.

En particulier, considérez cet exemple :

   always @(posedge clk or negedge resetn)
     if (!resetn)
       the_reg <= 0;
     else
       the_reg <= [ ... ] ;

Si votre vision des resets consiste à écrire du code comme celui‑ci, sans vous occuper explicitement de ce qui se passe lorsque @resetn est désactivé (c’est‑à‑dire passe à l’état haut dans cet exemple), vous devriez absolument consulter cette page.

Quoi qu’il en soit, il est bon de vérifier qu’il y a des remises à zéro là où il devrait y en avoir, et qu’elles font correctement leur travail. Ce que cela signifie est discuté dans une courte série de pages sur ce sujet.

Raison n°3 : la gestion des horloges

La qualité des horloges est sans doute le sujet le plus sous‑estimé en conception numérique. C’est souvent : « oui, elle passe de haut en bas et inversement, utilisons‑la comme horloge ».

Les horloges utilisées avec la logique FPGA doivent être stables et avoir une gigue (jitter) satisfaisante. Tout aussi important, la connexion physique de l’horloge vers le FPGA doit être stable et fiable.

Dans une expression comme celle‑ci,

always @(posedge clk)

tout ce qui est utilisé comme @clk doit être traité avec le plus grand soin. Idéalement, cette horloge provient d’un composant dédié de génération d’horloge (un oscillateur), qui garantit une horloge stable et à faible gigue. D’une manière générale, il vaut mieux utiliser cette horloge externe comme horloge de référence d’une PLL plutôt que de la connecter directement à la logique. Cela reste vrai même si la PLL ne change pas la fréquence de l’horloge.

En effet, l’utilisation d’une PLL permet de surveiller le détecteur de verrouillage de la PLL. La logique qui dépend de cette horloge peut donc être maintenue dans un état de remise à zéro lorsque la PLL est déverrouillée. Cela réduit considérablement les risques de problèmes si l’horloge de référence a des problèmes de stabilité (en particulier juste après la mise sous tension).

On peut prendre une PLL pour une source de problèmes, et lui attribuer des remises à zéro apparemment inutiles parce qu’elle perd son verrouillage de façon sporadique. On peut alors « réparer » le problème à tort en retirant la PLL et en connectant l’horloge externe directement à la logique, et tout paraît alors fonctionner correctement. Dans un tel cas, il y a fort à parier que le problème vient de l’horloge de référence. Retirer la PLL ne résout pas le problème ; cela le repousse dans la matrice logique, en créant peut‑être une situation de magie noire.

Jusqu’ici, j’ai parlé des horloges issues d’oscillateurs dédiés, ce qui est en réalité le cas facile. Cela se gâte avec d’autres sources : les horloges créées par un processeur ou par l’un de ses périphériques doivent être utilisées avec précaution, si tant est qu’on les utilise. Ces horloges peuvent être arrêtées momentanément par le processeur ou produire de temps à autre des formes d’onde non conformes. Cela peut venir du fait que le logiciel écrit dans les registres matériels concernés, éventuellement dans le cadre d’une tâche sans rapport. De tels événements brefs peuvent ne pas être visibles lorsqu’on examine l’horloge à l’oscilloscope, mais ils n’en provoquent pas moins d’étranges dysfonctionnements.

Une autre source fréquente de problèmes est la mauvaise gestion d’une horloge synchrone à la source (source-synchronous clock). Autrement dit, quand un composant externe fournit un signal d’horloge et un ou plusieurs signaux de données, de sorte que les données soient synchrones de l’horloge. En général, les signaux de données ne doivent changer d’état que lors des fronts montants de l’horloge (ou uniquement sur les fronts descendants).

Une méthode courante, mais plutôt dangereuse, consiste à connecter l’horloge synchrone à la source directement à la logique applicative dans le FPGA. Le problème vient en partie du fait qu’une horloge synchrone à la source n’a souvent pas été conçue pour servir d’horloge continue ; elle peut donc s’arrêter momentanément ou présenter des impulsions parasites.

Un autre problème possible est que les interfaces synchrones à la source sont souvent reliées au FPGA par un connecteur physique, par exemple lorsque la source de données est une caméra connectée à la carte principale par un câble. Même si les connecteurs sont généralement fiables, une perte de contact physique d’une nanoseconde due à des vibrations peut suffire à produire une impulsion non conforme sur le signal d’horloge. Cela peut arriver aussi avec les signaux de données, bien entendu, mais c’est généralement moins grave, en particulier lorsque la source de données est une caméra. En revanche, lorsqu’un tel signal d’horloge est connecté directement à la logique applicative, une impulsion d’une nanoseconde peut très certainement semer la pagaille.

La meilleure solution pour les interfaces synchrones à la source avec horloge et données consiste donc à traiter l’horloge et les données comme des signaux ordinaires. Ainsi, l’horloge synchrone à la source et les signaux de données sont échantillonnés (sampling) avec des bascules, à l’aide d’une horloge nettement plus rapide, stable et sûre. De préférence, cela se fait avec les bascules dédiées adjacentes aux broches d’entrée‑sortie.

Lorsque l’horloge synchrone à la source passe de l’état bas à l’état haut, cela se traduit par un changement comparable sur la sortie de la bascule qui échantillonne ce signal. Par conséquent, on peut détecter les fronts montants de l’horloge synchrone à la source avec de la logique synchrone, par le simple fait que la sortie de cette bascule passe de l’état bas à l’état haut. Cette logique est bien sûr fondée sur l’horloge plus rapide et stable. Lorsqu’elle détecte un tel front montant, elle marque les données comme valides. Autrement dit, les sorties des bascules qui contiennent les valeurs des entrées de données sont marquées comme étant des données valides.

L’avantage évident de cette méthode d’échantillonnage des signaux 0/1 (01-signal sampling) est que, quoi qu’il arrive au signal d’horloge, la logique du FPGA continue de s’appuyer sur une horloge sûre. C’est à la logique qui détecte les fronts de répondre de manière adéquate si l’horloge synchrone à la source devient folle.

Cette technique est possible pour des fréquences relativement faibles de l’horloge synchrone à la source (typiquement jusqu’à 200‑300 MHz, selon la vitesse du FPGA et selon que l’on utilise un échantillonnage DDR ou non).

Pour des sources plus rapides, la solution préférée consiste à alimenter une PLL avec l’horloge de la source, puis à utiliser la sortie de la PLL avec la logique applicative. Comme mentionné plus haut, la logique doit être remise à zéro lorsque la PLL indique qu’elle n’est pas verrouillée. C’est probablement aussi la bonne solution pour une autre raison : lorsque la fréquence est trop élevée pour l’échantillonnage 0/1 des signaux que je viens de suggérer, il y a fort à parier que la seule façon d’assurer un échantillonnage correct est de trouver le bon timing par décalage de phase de l’horloge. Concrètement, la temporisation est ajustée automatiquement par la logique jusqu’à ce qu’aucune erreur ne soit détectée dans les signaux échantillonnés. Cette technique requiert de toute façon l’utilisation d’une PLL.

Raison n°4 : les règles de conception RTL non respectées

Un code Verilog (ou VHDL) correct pour la synthèse doit suivre des règles strictes, en particulier le paradigme RTL (Register Transfer Level). Cela signifie, entre autres, que tout élément logique qui constitue une sorte de mémoire (par exemple une bascule) ne change d’état qu’en conséquence d’un front d’horloge. La seule exception est une remise à zéro asynchrone (asynchronous reset), qui ne peut pas être n’importe quel signal.

Lorsqu’un outil de synthèse (synthesizer) rencontre du code Verilog qui enfreint ces règles, il tente généralement de se montrer coopératif et génère une logique qui risque de ne pas se comporter exactement comme le laisse voir la simulation. Une autre possibilité est que le résultat de la synthèse corresponde au comportement attendu la plupart du temps, mais échoue de manière aléatoire.

Par exemple, considérons cette conception erronée d’un compteur entre 0 et 14 :

reg [3:0] counter;
wire      reset_cnt;

assign reset_cnt = (counter == 15); // This is so wrong!

always @(posedge clk or posedge reset_cnt)
  if (reset_cnt)
    counter <= 0;
  else
    counter <= counter + 1;

L’erreur horrible est d’utiliser @reset_cnt comme une remise à zéro asynchrone.

Mais commençons par expliquer comment cela fonctionne en simulation : @counter compte sur les fronts montants de @clk. Mais lorsque @counter atteint la valeur 15, @reset_cnt passe à ’1’ et remet @counter à zéro de manière asynchrone. Ainsi, lorsque @counter est échantillonné avec @clk, il affiche les valeurs de 0 à 14, comme prévu.

En matériel, cela peut ne pas fonctionner. Le problème est que @reset_cnt est une fonction de logique combinatoire (combinatorial logic) de @counter. Lorsque @counter passe de 7 à 8, la logique qui calcule @reset_cnt peut brièvement voir la valeur de @counter comme 15. En effet, 7 s’écrit 0111 en binaire et 8 s’écrit 1000. Si le bit 3 a le délai de propagation le plus court jusqu’à la logique qui calcule @reset_cnt, ce signal peut être à ’1’ brièvement. Par conséquent, @counter comptera parfois de 0 à 14, et parfois de 0 à 7. La température et d’autres facteurs sans rapport peuvent influencer l’option observée.

Cependant, cette explication de la raison pour laquelle cet exemple est erroné est très simplifiée. Les outils sont libres d’implémenter la logique combinatoire de la manière la plus créative qui soit : pratiquement n’importe quoi peut se produire entre deux fronts d’horloge. La seule chose que les outils garantissent, c’est que les signaux sont stables conformément aux exigences temporelles des bascules destinataires (temps de préparation (setup time) et temps de maintien (hold time)).

Donc, à moins que la conception logique ne suive strictement les règles de la conception RTL, des choses bizarres peuvent très certainement se produire.

Raison n°5 : température et alimentations

Ce n’est pas une cause fréquente de problèmes, et c’est facile à vérifier. Néanmoins, la température et les alimentations peuvent être la cause première d’étranges dysfonctionnements.

Naturellement, si la température du silicium sort de la plage autorisée, aucun fonctionnement n’est garanti. Les raisons les plus courantes sont une surchauffe due à un dimensionnement thermique insuffisant ou des ventilateurs encrassés par la poussière.

Du côté des alimentations, elles peuvent produire une sortie défectueuse pour diverses raisons. Un simple contrôle à l’oscilloscope révèle souvent si la tension est dans la plage prévue. Notez cependant que la tension doit rester dans cette plage en permanence. Il ne suffit pas que la tension moyenne soit correcte : ni le bruit que produisent toujours les alimentations à découpage, ni les pointes occasionnelles ne doivent dépasser les limites.

Notez qu’une pointe d’une durée d’à peine 1 μs peut sembler anodine, mais cela représente des dizaines à des centaines de cycles d’horloge à l’intérieur du FPGA : c’est donc une période significative pendant laquelle le FPGA est alimenté avec une tension incorrecte. Il est préférable de mesurer la tension sur les condensateurs de découplage proches du FPGA, afin de voir la tension qui y arrive réellement. Pensez aussi à régler le déclenchement (trigger) de l’oscilloscope sur les seuils de tension haut et bas, et assurez‑vous qu’il ne se déclenche pas sur ces seuils en fonctionnement normal. Il n’est pas facile de remarquer de brèves pointes sur l’écran de l’oscilloscope, mais le déclenchement les attrapera.

Certains problèmes d’alimentation sont parfois la conséquence directe d’une mauvaise conception de carte. Beaucoup de modules d’alimentation ont un courant de charge minimal qui est souvent négligé. Si ce courant minimal n’est pas soutiré du module d’alimentation, celui‑ci peut devenir instable et produire une tension hors spécification, voire présenter des oscillations occasionnelles, ce qui est encore pire.

Une autre erreur courante consiste à utiliser une alimentation à découpage là où il faudrait un régulateur de tension. En particulier, il existe des oscillateurs d’horloge à faible gigue qui nécessitent une alimentation très propre. Si un tel oscillateur est alimenté par une source bruyante, ce bruit se retrouve sous forme de gigue sur la sortie d’horloge. Si un émetteur‑récepteur Gigabit utilise cette horloge (par exemple PCIe, USB 3.x, fibre optique, etc.), cela se traduit souvent par une liaison de données peu fiable.

De même, lorsque des mémoires DDR font partie de la conception, une alimentation fournissant une tension de référence est nécessaire. Cette tension est utilisée à la fois par le FPGA et par les mémoires DDR comme seuil entre un ’0’ et un ’1’ sur les fils qui relient ces deux composants. Si cette tension est générée par une alimentation à découpage, il y a fort à parier que le bruit de l’alimentation rendra plus difficile, voire impossible, la transmission de données sans erreur entre le FPGA et les mémoires DDR.

Raison n°6 : vous vous moquez de moi ?

Parfois, la raison de la situation de magie noire est un défaut si énorme qu’on se demande comment quoi que ce soit a pu fonctionner. Par exemple, lorsque le câblage sur le circuit imprimé (PCB) est totalement déconnecté de la broche du FPGA concernée, et que le bon signal arrive pourtant au FPGA par diaphonie ou par capacité parasite.

Cela arrive en particulier avec les horloges, car elles sont souvent câblées un peu partout sur la carte, et leur périodicité améliore leurs chances d’atteindre le FPGA avec une qualité suffisante pour sembler correcte.

Alors, de grâce, prenez un oscilloscope et vérifiez toutes les horloges le plus près possible du FPGA. S’il y a un condensateur de couplage AC pour l’horloge, c’est un bon endroit pour vérifier, d’autant que vous pourriez découvrir que le condensateur manque.

Raison n°7 : de simples bugs

Ou, plus précisément : la conception n’a jamais été élaborée de façon à fonctionner. À aucun moment, personne ne s’est assis pour déterminer comment on garantissait que la logique ferait son travail. Au lieu de cela, le code a été écrit progressivement par essais et erreurs, en partie par simulations et en partie sur le matériel. Le processus s’est arrêté quand les choses semblaient bien fonctionner, mais en regardant le code, on se demande comment il a bien pu fonctionner : comme il a été rafistolé tant de fois pour corriger juste ce petit détail, il est impossible de suivre ce qui se passe, sans parler d’y apporter des modifications.

J’ai mis cette raison en dernier, car ce n’est pas vraiment un comportement de magie noire. C’est juste un bug très pénible. Néanmoins, c’est la raison la plus courante pour laquelle les projets FPGA restent bloqués.

Et si vous pensez encore que c’est la faute du FPGA

Parfois, ce n’est pas de votre faute. Il peut y avoir un bug dans le FPGA lui‑même ou dans le logiciel du fabricant. Cela arrive beaucoup moins souvent que les gens n’ont tendance à accuser le fabricant du FPGA, mais dans de rares cas, c’est bien le cas.

À cause de la tentation naturelle de rejeter la faute sur quelqu’un d’autre, rendez‑vous service : ne concluez pas la séance d’exorcisme en accusant le FPGA, à moins d’avoir l’une des deux choses suivantes, ou les deux :

Si vous terminez sans aucune de ces preuves et parvenez malgré tout à contourner le problème d’une manière ou d’une autre, il y a de bonnes chances que vous le rencontriez à nouveau plus tard.

Le meilleur exemple que j’aie d’un bug dans le FPGA lui‑même remonte à longtemps, avec la FIFO matérielle du Virtex‑4 de Xilinx. C’est‑à‑dire une FIFO double horloge dont la logique de commande était implémentée directement dans le silicium (et non dans la matrice logique).

Le flux de données à travers cette FIFO se bloquait de temps en temps. Après quelques recherches, il s’est avéré que la FIFO maintenait en même temps ses signaux « empty » (vide) et « full » (plein) actifs, après avoir fonctionné correctement pendant un certain temps. C’est une situation interdite, sauf si la FIFO est maintenue en remise à zéro, ce qui n’était pas le cas. Après m’être assuré absolument que j’observais les bons signaux, j’ai conclu qu’il y avait un bug dans la FIFO de ce FPGA. Et je me suis tourné vers des FIFO implémentées dans la matrice logique.

Quelques mois plus tard, j’ai trouvé une notice d’errata concernant ces FIFO, que je n’aurais pas comprise si je n’avais pas connu le problème à l’avance. Mais après avoir lu la description très attentivement, j’ai pu conclure qu’elle confirmait mon observation.

Ce n’était qu’un exemple pour montrer à quel point un bug du FPGA doit être flagrant avant qu’il soit acceptable de déclarer que le problème n’est pas de votre faute.

Résumé

Lorsque le FPGA semble défier les lois de la nature, on est tenté d’adopter des explications qui s’écartent du bon sens. Il est pourtant important de chercher une explication rationnelle — et assez souvent, cette explication peut être trouvée sans avoir besoin de superpouvoirs.

Mais trouver la raison peut exiger une révision approfondie de la conception, ce qui n’est pas nécessairement une mauvaise chose. Aussi frustrante que puisse être une telle chasse, elle peut contribuer de manière significative à la qualité de la conception, quel que soit le résultat.

Cette page a été traduite de l’anglais par une machine. En cas de doute, veuillez vous reporter au texte original
Copyright © 2021-2026. All rights reserved. (dcc38493)