Pouvez-vous réellement casser un FPGA en le programmant mal?

Pouvez-vous réellement casser un FPGA en le programmant incorrectement?

Je suis vraiment un logiciel. Ce n'est un secret pour personne que si votre logiciel est erroné, vous pourriez détruire toutes sortes de données importantes, et peut-être même planter toute la machine. Mais il est vraiment difficile d' endommager physiquement un ordinateur simplement en le programmant.

(Il y a une rumeur sans fin d'une instruction Halt-And-Catch-Fire, ou d'être capable de reflasher le firmware du système pour briquer la carte mère, ou de programmer des valeurs incorrectes dans la carte graphique pour faire frire votre moniteur. Mais tout cela semble être exactement cela : rumeurs. Et tout ce qui concerne le matériel obsolète depuis longtemps. Il semble vraiment très difficile de casser un équipement informatique moderne avec une mauvaise programmation.)

Avec un FPGA, vous connectez (au moins nominalement) des circuits individuels ensemble. Il semble tout à fait plausible que des dommages physiques puissent survenir en cas d'erreur.

Par exemple, vous pouvez écrire du VHDL demandant que deux sorties soient liées ensemble. S'ils produisent différents niveaux logiques, j'imagine que cela ferait probablement frire quelque chose. ( J'espère que votre outil de synthèse vous hurlera de ne pas le faire ... mais je ne sais pas si ces outils implémentent réellement ce niveau de vérification des erreurs.)

Il semble également tout à fait possible de choisir accidentellement le mauvais modèle de FPGA dans l'outil de synthèse, et donc d'essayer de programmer votre puce avec un train de bits destiné à un modèle totalement différent. Je ne sais pas ce que cela ferait, mais je pense que ce serait "mauvais".

Pour cette question, vous pouvez certainement connecter la puce FPGA au reste du circuit de manière incorrecte. Par exemple, si vous gâchez les numéros de broches, vous pourriez vous retrouver avec la carte essayant de piloter une broche d'E / S que le FPGA lui-même essaie également de piloter. Les broches d'E / S ont-elles généralement une "protection" contre une telle erreur? Ou la puce va-t-elle simplement frire?

Il semble également tout à fait possible de choisir accidentellement le mauvais modèle de FPGA dans l'outil de synthèse, et donc d'essayer de programmer votre puce avec un train de bits destiné à un modèle totalement différent.

Généralement, le logiciel de programmation interroge la pièce en cours de programmation pour son numéro de pièce et refuse de programmer dans un flux binaire destiné à un modèle différent de FPGA.

La partie elle-même refusera généralement de démarrer si elle est programmée avec un train de bits qui n'est pas exactement de la bonne longueur (et il est très rare que les trains de bits pour différentes puces soient de la même longueur).

vous pourriez certainement connecter incorrectement la puce FPGA au reste du circuit. Par exemple, si vous gâchez les numéros de broches, vous pourriez vous retrouver avec la carte essayant de piloter une broche d'E / S que le FPGA lui-même essaie également de piloter.

C'est le moyen le plus probable d'endommager un FPGA avec une mauvaise programmation.

Une autre façon pourrait être de programmer une conception très gourmande en ressources et de l'exécuter à une fréquence élevée (de sorte qu'une puissance élevée soit consommée), puis de l'exécuter sur un FPGA sans dissipateur thermique adéquat.

Les broches d'E / S ont-elles généralement une "protection" contre une telle erreur? Ou la puce va-t-elle simplement frire?

Les broches de sortie survivent «souvent» à un court-circuit pendant quelques secondes, voire quelques minutes. Mais rien n'est garanti.

À quelques exceptions près, les outils ne vous donnent généralement pas accès aux véritables primitives de silicium, il est donc difficile pour un ingénieur utilisateur final de charger une conception électriquement non valide * dans un FPGA basé sur SRAM, sauf peut-être en découvrant par inadvertance un outil punaise.

Les FPGA basés sur Flash pourraient théoriquement voir leur reprogrammation endommagée par certaines charges invalides. Les FPGA OTP sont implicitement «endommagés» même par une charge de configuration valide , car ils ne peuvent jamais être modifiés.

En fin de compte, ce qui se rapproche le plus de ce que vous semblez demander, et de votre exemple HCF, serait une configuration qui a produit intolérable une contrainte thermique . La consommation d'énergie est déterminée directement par la fréquence d'horloge et le volume * d'activité de la logique utilisée, donc si vous pouvez inciter les outils à basculer inutilement la plupart des bascules sur la puce à l'horloge maximale (il existe des moyens ...), alors vous pouvez produire un radiateur assez efficace qui dépasserait la plupart des systèmes de refroidissement pour un usage ordinaire. Ensuite, il s'agit simplement de savoir si quelque chose l'arrête de manière protectrice avant de cuire. Et bien sûr, il existe des modèles d'estimation de puissance dans les outils, qui sont probablement raisonnablement prédictifs si vous ne leur mentez pas sur le signal d'horloge fourni.

(* Il y a une classe intéressante de problèmes électriques sans bug que vous pouvez provoquer en mentant aux outils, qui n'est pas nécessairement destructrice physiquement, mais toujours surprenante. Si vous alimentez une horloge différente de celle que vous aviez dite ou simplement instable, vous pouvez violer la synchronisation de la configuration des adresses sur les cellules RAM de bloc synchrone, et faire quelque chose dans le sens de les court-circuiter et de corrompre leur contenu - vous pouvez par exemple voir le contenu de quelque chose désigné comme ROM dans la conception changer réellement au moment de l'exécution simplement en essayant de le lire avec une mauvaise horloge. Mais je ne pense pas que ce soit physiquement destructeur)

La chose la plus probable est de violer la cote actuelle des GPIO en entraînant une broche qui est déjà en cours de conduite. Certains FPGA ont des limites de courant réglables ou des pilotes de sortie modifiables, donc cela peut vous aider / vous blesser si vous ne faites pas votre carte de port correctement. Vous devez de toute façon vérifier votre liste de ports avant de programmer car des erreurs comme l'échange de broches peuvent prendre des heures à résoudre, il est préférable de devancer les erreurs et de savoir exactement ce que le micrologiciel était censé faire. (sauf si vous aimez le plaisir de trouver une erreur)

Les HDL en eux-mêmes ne vous permettent généralement pas de connecter deux sorties au même fil et cesseront de synthétiser et vous feront corriger votre erreur si vous avez du code qui le fait.

Un endroit qui pourrait causer des problèmes est les ports bidirectionnels, mais vous devriez avoir des résistances de limitation de courant sur ceux-ci.

Comme avec les microcontrôleurs, vous pouvez toujours dépasser le courant total maximum par banque d'E / S en tirant un courant maximum (ou plus) de chaque broche. À moins que le FPGA n'ait une protection intégrée contre une telle situation, cela peut entraîner des dommages.

Une autre possibilité consiste à créer une boucle combinatoire qui devient périodiquement méta-stable ou oscille à une fréquence beaucoup plus élevée que la structure FPGA est conçue pour gérer (plusieurs GHz). Cela entraînera une surchauffe très localisée qui peut causer des dommages physiques avant que la protection thermique à l'échelle de la puce ne se déclenche. circuit très énergivore et laissez-le fonctionner avec un refroidissement insuffisant.

La reconfiguration dynamique peut également contourner les protections contre la configuration invalide des primitives internes qui peuvent être appliquées par les outils de développement en cas de configuration statique. Par exemple, vous pouvez configurer une PLL d'une manière qui dépasse sa fréquence interne maximale, ou alimenter la même ligne d'interconnexion par deux sources à la fois, ou forcer une broche d'une banque d'E / S haute tension à utiliser son émetteur-récepteur basse tension comme LVDS .