VHDL, das FPGA beschädigen kann

Ich habe irgendwo gelesen, dass schlechter VHDL-Code zu FPGA-Schäden führen kann.

Ist es überhaupt möglich, ein FPGA mit VHDL-Code zu beschädigen? Welche Art von Bedingungen würde dies verursachen und was sind die Worst-Case-Szenarien?

Das einzige Szenario, das mir einfällt, ist ein Design, bei dem viele, viele FFs getaktet werden, um das FPGA zu erwärmen.
Nun, es kann in eine schlecht entworfene Schaltung eingebaut werden, die bei nicht richtiger Programmierung einige Ströme um brennendes Zeug herumfließen lässt.
Das Worst-Case-Szenario ist wahrscheinlich, dass das FPGA für maschinelles Lernen verwendet wird und eine Schurken-KI erstellt, die die Welt und das Universum zerstört. Noch ernsthafter, wenn Sie ungeprüften Code in einem mit dem Computer verbundenen FPGA verwenden, kann dieser diesen Computer infizieren. Auch wenn es zur Steuerung von Hochleistungsgeräten verwendet wird, können Sie ein Gebäude niederbrennen.

Antworten (4)

Ergänzend zur Antwort von @Anonymous gibt es Designs, die Sie erstellen können und die das Gewebe eines FPGA beschädigen können.

Für den Anfang, wenn Sie ein sehr großes Design bauen, das aus riesigen Mengen von Registern besteht (z. B. 70% des FPGA), die alle mit der maximalen Frequenz des FPGA getaktet werden, ist es möglich, das Silizium erheblich zu erhitzen. Ohne ausreichende Kühlung kann dies zu physischen Schäden führen. Wir haben ein 13.000-Dollar-FPGA verloren, weil es aufgrund des schrecklichen Kühlsystems des Entwicklungskits überhitzt war.

Ein anderer einfacherer Fall können Kombinationsschleifen sein. Wenn Sie beispielsweise drei in einem Ring verkettete Nicht-Gatter instanziieren und die Warnungen des Synthesizers vor einer solchen Struktur deaktivieren oder ignorieren, können Sie etwas bilden, das für ein FPGA sehr schlecht ist. In diesem Beispiel würden Sie einen Multi-GHz-Oszillator bauen, der auf sehr kleinem Raum viel Wärme erzeugen und wahrscheinlich das ALM und die umgebende Logik beschädigen könnte.

Kombinatorische Schleifen werden manchmal als echte Zufallszahlengeneratoren vorgeschlagen. Ich habe keine Erfahrung mit Ringoszillatoren , aber ich bezweifle, dass nur drei Tore schaden werden. Das Treiben seiner Ausgabe zu vielen Gates wird jedoch wahrscheinlich Schaden anrichten.
thx Ich habe 2-3 Boards, die jetzt wegen Designfehlern mit Spartan 6 unbrauchbar sind. Das werde ich ausprobieren :P
Es ist auch möglich, einen Bitstrom zu laden, der das Laden anderer Bitströme verhindert oder zumindest ziemlich erschwert.

Code ist in diesem Zusammenhang nicht das richtige Wort. Während Verilog oder VHDL wie ein Programm aussehen, ist die Ausgabe des Compilers eine Konfiguration, die in den FPGA-Chip geladen wird, der darin eine elektronische Schaltung bildet.

Zwei Arten fallen mir ein:

  • physischer Schaden: Beispielsweise sind mehrere FPGA-Pins miteinander (oder mit einem anderen Gerät) verbunden und beginnen gleichzeitig, unterschiedliche logische Spannungen auszugeben. Strom fließt – möglicherweise übermäßiger Strom – der schließlich das Gate (die Gates) beschädigt;
  • Logischer Schaden: Die Schaltung kann den Flash-Chip oder das Konfigurationsgerät falsch handhaben und das darin enthaltene Datenabbild beschädigen, dieses gesamte Gerät funktioniert schließlich nicht mehr.
Das Thema des physischen Schadens könnte der Ursprung des Zitats des OP sein. Als Softwareentwickler wurde mir als allgemeine Regel gesagt, dass "Software" dem Gerät keinen physischen Schaden zufügen kann, während "Firmware" Schäden verursachen kann, z. B. wenn zwei Taucher miteinander verbunden werden.
@CortAmmon "z. B. zwei Taucher miteinander verbinden" - Was ist das, ein Luftschlauch-Querverbindungsschalter?
@immibis Du hast mich! Die eigentliche Regel lautete: „Verlasse dich nicht auf die Software/Squishyware im Kopf deines Kumpels, während der Kumpel atmet, sondern halte deinen Atemregler immer fest im Griff.“ ;-)
@CortAmmon nur Interesse. Als ziemlich spezieller Fall habe ich vor Jahrzehnten gesehen, wie jemand Code in einen PC eingab und ein einfaches Programm zum Laufen brachte, das aufeinanderfolgende Bildschirme in Weiß und Schwarz auf eine Weise auf den Monitor schrieb, die die Monitorelektronik laut unter Last "beschweren" ließ . Ob dies eine Fehlfunktion der Stromversorgung oder des Netzoszillators war oder ??? Ich weiß nicht. Ich hatte den Eindruck, dass der Monitor zerstört worden wäre, wenn dieser weitergelaufen wäre. Ob BASIC oder Maschinensprache oder ??? und wie weiß ich auch nicht. Vielleicht Bereich der 1970er bis 1980er Jahre.

Die falsche Konfiguration eines Blocks von Eingangspins als Ausgänge könnte dies tun, wenn das, was sie sonst noch antreibt, steif genug ist.

Ich weiß nicht, ob das Konfigurieren einiger Pins für LVDS oder einen der LVCMOS-Standards, während die IO-Bank mit einer zu hohen Spannung versorgt wird (z. B. 3,3 V Leistung mit einem 1,8-V-IO-Standard oder das Gegenteil an einem Eingang), ausreichen würde es?

Offensichtlich können thermische Probleme eine Möglichkeit sein, indem Sie etwas Dummes tun, wie viele, viele Ringoszillatoren zu instanziieren.

Der E/A-Standard, der als Einschränkungen für das Design angegeben ist, dient nur für Timing-Berechnungen. Wenn die I/O-Bank eine 3,3-V-Bank ist und mit 3,3 V versorgt wird, passiert nichts, wenn Sie einen 1,8-V-Standard wählen.
@Paebbels, ich bin mir nicht sicher, welches Tool Sie verwenden, aber wenn Sie einen E / A-Standard festlegen, steuert er normalerweise die Spannung dieses E / A-Standorts. Wenn ein FPGA-Eingangspin auf eine viel niedrigere Spannung eingestellt ist als das, was das externe Gerät in diesen Pin treibt, kann dieser FPGA-Eingang beschädigt werden.
@Ciano das stimmt nicht. Die Pin-Spannung hängt von der I/O-Bankspannung ab, nicht von einer Beschränkung.

FPGAs können zur Laufzeit mit einem neuen (Teil-)Bitstrom rekonfiguriert werden. Normalerweise wird dieser Stream von einer externen Quelle geladen, Sie können ihn aber auch selbst im FPGA erstellen (z. B. durch eine eingebettete Softcore-CPU). Die Verwendung einer solchen Lösung zum Beispiel zum dynamischen Verschieben von Subdesigns bietet nicht alle Konsistenzprüfungen, wie sie von den Anbieter-Tools durchgeführt werden. Wenn Ihr Algorithmus also kaputt ist, können Sie die Transistoren mit falschem Pfad in einem FPGA aktivieren und sie brennen.

Sie könnten auch falsche Betriebsmodi für FPGA-Primitive wie PLLs oder Transceiver auswählen.

Dynamische Rekonfiguration ist wie sich selbst modifizierender Code in Software.