Puoi davvero rompere un FPGA programmandolo in modo errato?

Puoi effettivamente rompere un FPGA programmandolo in modo errato?

Sono un ragazzo software davvero. Non è un segreto che se il tuo software è sbagliato, potresti distruggere tutti i tipi di dati importanti e forse persino mandare in crash l'intero computer. Ma è davvero difficile danneggiare fisicamente un computer semplicemente programmandolo.

(Esistono rumori infiniti di un'istruzione Halt-And-Catch-Fire o la possibilità di eseguire il reflash del firmware del sistema per bloccare la scheda madre o programmare valori errati nella scheda grafica per friggere il monitor. Ma tutto sembra essere esattamente quello : voci. E tutto sull'hardware obsoleto da lungo tempo. Sembra davvero, davvero difficile rompere le moderne apparecchiature informatiche con una cattiva programmazione.)

Con un FPGA, si collegano (almeno nominalmente) i singoli circuiti insieme. Sembra del tutto plausibile che si possano verificare danni fisici in caso di errore.

Ad esempio, è possibile scrivere alcuni VHDL che richiedono che due uscite vengano collegate insieme. Se emettessero livelli logici diversi, immagino che probabilmente friggerebbe qualcosa. ( Spero che il tuo strumento di sintesi ti gridi di non farlo ... ma non so se tali strumenti implementano effettivamente quel livello di controllo degli errori.)

Sembra anche del tutto possibile scegliere accidentalmente il modello sbagliato di FPGA nello strumento di sintesi, e quindi finire per provare a programmare il proprio chip con un flusso di bit destinato a un modello totalmente diverso. Non so che cosa farebbe, ma sospetto che sarebbe "cattivo".

Del resto, potresti sicuramente collegare il chip FPGA al resto del circuito in modo errato. Ad esempio, se si confondono i numeri dei pin, si potrebbe finire con la scheda che prova a pilotare un pin I / O che anche lo stesso FPGA sta cercando di guidare. I pin I / O hanno in genere una "protezione" da un simile errore? O la patatina friggerà?

Sembra anche del tutto possibile scegliere accidentalmente il modello sbagliato di FPGA nello strumento di sintesi, e quindi finire per provare a programmare il proprio chip con un flusso di bit destinato a un modello totalmente diverso.

Tipicamente il software di programmazione interroga la parte programmata per il suo numero di parte e rifiuta di programmare in un bitstream pensato per un diverso modello di FPGA.

La parte stessa generalmente rifiuta di avviarsi se programmata con un flusso di bit che non è esattamente della lunghezza corretta (ed è molto raro che i flussi di bit per chip diversi abbiano la stessa lunghezza).

potresti sicuramente collegare il chip FPGA al resto del circuito in modo errato. Ad esempio, se si confondono i numeri dei pin, si potrebbe finire con la scheda che prova a pilotare un pin I / O che anche lo stesso FPGA sta cercando di guidare.

Questo è il modo più probabile per danneggiare un FPGA con una programmazione errata.

Un altro modo potrebbe essere quello di programmare un progetto molto dispendioso in termini di risorse ed eseguirlo ad alta frequenza (in modo che venga consumata un'alta potenza) e quindi eseguirlo su un FPGA senza un adeguato dissipatore di calore.

I pin I / O hanno in genere una "protezione" da un simile errore? O la patatina friggerà?

I pin di uscita "spesso" sopravvivranno a una condizione di corto circuito per alcuni secondi o addirittura minuti. Ma nulla è garantito.

Con alcune eccezioni note, gli strumenti generalmente non ti danno accesso alle primitive di silicio effettive, quindi è difficile per un ingegnere dell'utente finale caricare un progetto elettricamente non valido * in un FPGA basato su SRAM, tranne forse scoprendo inavvertitamente uno strumento bug.

Gli FPGA basati su Flash potrebbero avere la riprogrammabilità danneggiata da determinati carichi non validi. Gli FPGA OTP implicitamente vengono "danneggiati" anche da un carico di configurazione valido , poiché non può mai essere modificato.

In definitiva, ciò che si avvicina di più a quello che sembra che tu stia chiedendo, e al tuo esempio di HCF, sarebbe una configurazione che produceva intollerabili stress termici . Il consumo di energia è guidato direttamente dalla frequenza di clock e dall'attività del volume * della logica utilizzata, quindi se riesci a ingannare gli strumenti per attivare inutilmente la maggior parte degli infradito sul chip al massimo clock (ci sono modi ...) allora puoi produrre un riscaldatore piuttosto efficace che supererebbe la maggior parte dei sistemi di raffreddamento per un normale utilizzo. Quindi è solo una domanda se qualcosa lo spegne in modo protettivo prima che cucini. E naturalmente ci sono modelli di stima della potenza negli strumenti, che sono probabilmente ragionevolmente predittivi se non li stai mentendo sul segnale di clock fornito.

(* Esiste un'interessante classe di problemi elettrici non-bug che puoi causare mentendo agli strumenti, che non è necessariamente distruttivo dal punto di vista fisico, ma comunque sorprendente. Se dai da mangiare a un orologio diverso da quello che hai detto o semplicemente instabile, puoi violare i tempi di configurazione degli indirizzi sulle celle RAM a blocchi sincroni e fare qualcosa sulla falsariga di metterli in cortocircuito e corromperne il contenuto - così puoi ad esempio vedere che i contenuti di qualcosa designato come una ROM nella progettazione cambiano effettivamente in fase di esecuzione semplicemente provando a letto con una brutta orologio. Ma io non credo che questo è fisicamente distruttivo)

La cosa più probabile è violare la valutazione attuale sui GPIO guidando un pin che è già stato guidato. Alcuni FPGA hanno limiti di corrente impostabili o driver di output modificabili, quindi questo può aiutarti o ferirti se non riesci a fare correttamente la tua mappa delle porte. Dovresti comunque ricontrollare il tuo elenco di porte prima di programmare poiché errori come lo scambio di pin possono richiedere ore per essere risolti, è meglio anticipare gli errori e sapere esattamente cosa il firmware intendeva fare. (a meno che non ti piaccia il brivido di trovare un errore)

Le HDL da sole di solito non ti consentono di collegare due uscite allo stesso filo e smetteranno di sintetizzarti e ti faranno correggere l'errore se hai un codice che lo fa.

Un posto che potrebbe causare problemi sono le porte bidirezionali, ma dovresti avere resistori limitatori di corrente su quelle.

Come per i microcontrollori, è sempre possibile superare la massima corrente totale per IO bank estraendo una corrente massima (o più) da ciascun pin. A meno che l'FPGA non abbia una protezione integrata contro tale situazione, ciò può causare danni.

Un'altra possibilità è quella di creare un loop combinatorio che periodicamente diventa meta-stabile o oscilla a una frequenza molto più elevata di quella che il tessuto FPGA è progettato per gestire (diversi GHz). Ciò causerà un surriscaldamento molto localizzato che potrebbe causare danni fisici prima che la protezione termica a livello di chip entri in azione. Cioè, supponendo che ci sia una tale protezione: se la sovratemperatura non porta allo spegnimento, puoi semplicemente trovare un circuito molto affamato di potenza e lasciarlo funzionare con un raffreddamento insufficiente.

La riconfigurazione dinamica può anche aggirare le protezioni contro la configurazione non valida di primitive interne che possono essere applicate dagli strumenti di sviluppo in caso di una configurazione statica. Ad esempio, è possibile configurare un PLL in un modo che superi la sua massima frequenza interna o alimentare la stessa linea di interconnessione da due sorgenti contemporaneamente o forzare un pin da un banco IO ad alta tensione per utilizzare il suo ricetrasmettitore a bassa tensione come LVDS .