Ist es möglich FPGA zu zerstören/beschädigen?

[Andreas (Gast)]

Hi,

Ich hätte mal ne blöde Frage:

Ist es eigentlich möglich ein FPGA zu beschädigen indem man es mit einem 
"Programm" konfiguriert, welches in der Simulation 'x' als Ergebnis 
liefert? Also wenn 2 Anweisungen auf dasselbe Signal schreiben?

mfg
Andreas

[Valerij M. (fpga-dev)]

Hallo Andreas,

Das ist bei modernen Altera-FPGAs nicht mehr möglich, da die 
Verdrahtungsarchitektur nur Verbindungen von Signalquellen zu 
Signalsenken erlaubt. Stichwort: unidirektionale Verdrahtungssegmente. 
Es ist zu vermuten, dass für die Xilinx FPGAs das gleiche gilt (nur 
belegen lässt sich nicht, weil die bisher kaum was Verwertbares zu 
diesem Thema veröffentlicht haben).


Deshalb sind bei einem modernen (Xilinx-, Altera-)FPGA auch keine 
Einschaltstromimpulse zu beobachten, denn auch bei einer beliebigen 
Konfiguration (die ja im Einschaltaugenblick nicht definiert ist) 
enstehen keine Kurzschlüsse in der Verdrahtung.

Schöne Grüße,

Valerij (fpga-dev.de)

[Christian R. (supachris)]

Auch bei Xilinx gibts schon lange keine bidirektionalen Verbindungen 
mehr intern. Außerdem wird das Design gar nicht erst übersetzt, wenn du 
mit 2 Quellen auf eine Senke gehst. Kaputt bekommt man die allenfalls 
durch die Außenbeschaltung.

[Max M. (max93)]

>Das ist bei modernen Altera-FPGAs nicht mehr möglich,

Theoretisch ist das richtig (also wenn alle Sicherheitsmaßnahmen so 
implementiert wären, wie vorgesehen). Laut Hersteller stimmt das auch in 
der Praxis.

Du findest aber einschlägige Hinweise auf bösartige 
FPGA-Konfigurationen. (Theoretisch ist auch Windows gegen Viren 
geschützt. Doch ist dieses Bekenntnis bestenfalls einen Lacher wert. 
Warum sollte es bei FPGAs anders sein?)

Max

[Daniel R. (daniel_r)]

@Max

>>(Theoretisch ist auch Windows gegen Viren
>>geschützt. Doch ist dieses Bekenntnis bestenfalls einen Lacher wert.
>>Warum sollte es bei FPGAs anders sein?)

Dazu ein kleiner Vergleich, den mein Digitaltechnik-Professor nannte:

Intel stand wegen eines fehlerhaften Rechenwerks einmal knapp vor dem 
Ruin, obwohl die Benutzung genau dieses Rechenwerks softwaretechnisch 
noch umgangen hätte werden können. In der IC-Entwicklung gilt: Entweder 
fehlerfrei, oder Dein Arbeitsplatz existiert nicht mehr.
Und wen interessieren Softwarefehler in Windows? Keine Sau.

Es gibt also einen gewaltigen Unterschied zuwischen Soft- und 
Hardware-Entwicklung.

Daniel

[neeeee (Gast)]

Natuerlich kann man ein FPGA zerkonfigurieren. zB unbeschaltete Pins als 
Eingaenge schalten. Dann gehen die auf einen unbestimmten Zusatnd und 
ziehen Strom wie bloed. Das Powersupply bringt die Spannung nicht mehr 
und mit der halben Spannung kann nicht neu programmiert werden. Nach 
einer halben Minute ist der Chip kapput.

[Morin (Gast)]

> Ist es eigentlich möglich ein FPGA zu beschädigen indem man es mit einem
> "Programm" konfiguriert, welches in der Simulation 'x' als Ergebnis
> liefert? Also wenn 2 Anweisungen auf dasselbe Signal schreiben?

Es gibt meines Wissens 3 Möglichkeiten wie sowas passiert:

1. Du schreibst eine entsprechende VHDL-Datei, die sowohl '0' als auch 
'1' zuweist. Dies wird von den Synthesetools abgelehnt, da es keine 
sichtbaren internen Tristate-Busse (mehr) gibt.

2. Du umgehst die Synthesetools um kofigurierst die Schalter im FPGA 
manuell so, dass sowohl ein '0'- als auch ein '1'-Treiber an einem Bus 
hängen. Nur möglich, wenn es "unsichtbare" interne Tristate-Busse gibt, 
die von den Synthesetools immer "richtig" beschaltet werden, manuell 
aber auch "falsch" beschaltet werden können. Siehe dazu den Hinweis auf 
die Herstellerangaben vs. Gerüchten über "bösartige" Konfigurationen.

3. Du gibst ein Signal auf einem Pin aus, der auch von externer Seite 
getrieben wird. Das ist in der Praxis der wirklich kritische Fall, weil 
es vom Synthesetool nicht abgefangen werden kann. Je nach FPGA gibt es 
evtl. Strombegrenzer in den IOBs die ein Durchbrennen verhindern, 
ansonsten -> Ende Gelände.

[Uli W. (uliw2008)]

schadcode?

hab ich was verpasst ?

[Bastler (Gast)]

>Also wenn 2 Anweisungen auf dasselbe Signal schreiben?

Das ginge, wenn überhaupt, nur in einem Bussystem mit Tristatetreibern 
(alles andere endet in VHDL mit einer Fehlermeldung).
Da FPGAs aber keine internen Tristatereiber haben (jedenfalls keine mir 
bekannten), wird das mit Multiplexern realisiert mit denen das Problem 
nicht auftauchen kann. Also: Nein!

[ralf (Gast)]

In einem Projekt hab ich mal ein Spartan II XC2S150 durch das größere 
XC2S200 ersetzt. Blöderweise hab ich beim ersten Test vergessen das 
Configuration File anzupassen. Nach der Configuration zog das FPGA über 
10A. Zum Glück hatte das Schaltnetzteil eine Strombegrenzung, die 
Spannung ist zuammengebrochen und das FPGA war wieder im Grundzustand. 
Das hab ich einige male wiederholt bis ich den Fehler bemerkte. Das FPGA 
hat das alles unbeschadet überstanden und läuft seit einigen Jahren 
fehlerfrei.

[Gibts hier was umsonst? (Gast)]

Ralf, habe ich etwas verpasst? Wurde ein Preis ausgeschrieben für 
denjenigen, der nachweisen kann, FPGAs in der am dümmsten anzunehmenden 
Weise missbraucht zu haben, oder wieso prahlen hier alle mit ihrer 
Unfähigkeit?

[Andreas (Gast)]

Hi,

Danke für die Info.

Code war sowas wie das:

process(clk,rst)
begin
  if rst = '1' then
    a <= '0';
  end if;
  if rising_edge(clk) then
    ..
    a <= '1';
    ..
  end if;
end process;

Eigentlich wollte ich ja statt dem zweiten if ein elsif schreiben...hab 
ich aber beim späteren hinzufügen vergessen...
Das ganze hat sich synthetisieren lassen, hat dann halt nicht 
funktioniert..was ja auch klar war.

Bis jetzt hab ich noch einige andere Konfigurationen ausprobiert 
(funktionierende...), konnte nie ein Problem damit feststellen.

mfg
Andreas

[Valerij M. (fpga-dev)]

Hallo Andreas,

Anweisungen innerhalb eines Prozess-Blocks werden sequentiell 
(nacheinander) abgearbeitet. Die Zuweisungs des Wert zu einem Signal 
erfogt erst am  Prozessende. Somit ist es kein Beispiel für Deine 
ursprüngliche Frage.

Gruß,

Valerij

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas wrote:
>

> process(clk,rst)
> begin
>   if rst = '1' then
>     a <= '0';
>   end if;
>   if rising_edge(clk) then
>     ..
>     a <= '1';
>     ..
>   end if;
> end process;
>

Der ist gut   :-D
Ein FF, bei dem der Takt Vorrang vor dem Reset hat,
sowas wollte ich schon lange ;-)