Perché gli FPGA non sono onnipresenti?

Leggendo sugli FPGA, se ho capito bene, sono fondamentalmente circuiti di gate logici completamente configurabili. Essendo questo, si può progettare qualsiasi cosa con loro. Si può progettare tutto nel modo più personalizzato possibile e, quindi, soddisfare gli stessi fini in un modo molto più efficiente che può essere ottenuto usando un microcontrollore. Detto questo, sembra che un FPGA batte un microcontrollore in qualsiasi momento, in qualsiasi giorno. Quindi la mia domanda è: se gli FPGA sono davvero così fantastici, cosa li impedisce di essere molto più diffusi dei microcontrollori? Da questo punto di vista, per me sembra che gli FPGA avrebbero dovuto spazzare via i microcontrollori molto tempo fa. Allora perché non è così? È il costo, la difficoltà di programmare un FPGA o completamente qualcos'altro?

Stai ignorando molti fattori che vanno a fare le scelte progettuali:

1. Costo . Gli FPGA sono più costosi dei micro per la stessa complessità della logica.

2. Complessità logica . Il codice eseguibile può implementare una logica molto più complicata rispetto allo stesso numero di gate nel micro utilizzato direttamente.

3. Facilità di sviluppo . È più facile scrivere codice eseguibile che definire la logica per tutti i problemi, tranne piccoli. Anche i progetti di microcontrollori modesti hanno migliaia di righe di codice. Lo sviluppo di definizioni logiche equivalenti richiederebbe molto più tempo ed è molto più difficile eseguire il debug e la verifica.

4. Consumo di energia . Poiché gli FPGA sono destinati ad operazioni ad alta velocità che i micro non sono in grado di gestire (altrimenti si userebbe un micro), non sono ottimizzati per la bassa potenza. Ciò li rende inadatti per alcune applicazioni a bassa potenza. Alcuni micro hanno correnti di sonno inferiori a 1 µA e possono funzionare solo con pochi µA a frequenze di clock lente. Prova a trovare un FPGA in grado di farlo.

Il vantaggio principale degli FPGA rispetto ai micro è che sono più veloci e possono fare più cose in parallelo. A parte questo, preferiresti usare un micro. Pertanto, nel processo di progettazione, di solito inizi con un micro, quindi vai a malincuore a un FPGA quando hai davvero bisogno della velocità e / o delle operazioni simultanee ad alta velocità. Anche allora, implementate solo le parti critiche per la velocità in un FPGA e lasciate le funzioni di controllo della velocità più bassa e simili nel micro.

Una distinzione che non ho visto approfondito qui è che gli FPGA sono usati e si comportano in un modo completamente diverso dai processori.

Un FPGA è davvero bravo a fare esattamente lo stesso compito, ancora e ancora. Ad esempio, l'elaborazione di segnali video, audio o RF. O instradamento di pacchetti Ethernet. O simulando il flusso del fluido. Ogni situazione in cui hai un sacco di lo stesso tipo di dati che ti vengono lanciati molto velocemente e vuoi gestirli tutti allo stesso modo. Oppure vuoi eseguire lo stesso algoritmo ripetutamente. L'FPGA non ha davvero "compiti" che si avviano e si fermano [1], il suo intero compito è fare la stessa cosa con qualunque dato ottenga, finché rimane attivo. Non cambia marcia, non fa nient'altro. È l'ultimo lavoratore della linea di produzione. Farà la stessa cosa ripetutamente, il più velocemente possibile, per sempre.

Le CPU, d'altra parte, sono l'epitome della flessibilità. Possono essere programmati per fare qualsiasi cosa e possono essere programmati per fare più cose contemporaneamente allo stesso tempo. Hanno compiti che si avviano e si fermano, cambiano marcia, multitasking, cambiano e cambiano costantemente le funzioni.

FPGA e CPU sono opposti completi. La merce della CPU è il tempo - deve fare le cose più velocemente. Più veloce viene eseguita l'applicazione, meglio è.

La merce dell'FPGA è lo spazio. Il tuo FPGA è solo così grande, e ci sono solo così tante porte disponibili per eseguire l'attività che desideri. La maggior parte delle volte, il problema è più grande della velocità [2].

È possibile fare in modo che un FPGA si comporti come una CPU. È possibile inserire un core IP CPU in un FPGA, tuttavia è molto difficile giustificarlo a causa dei motivi descritti da altri [3]. L'FPGA e la CPU sono opposti, entrambi hanno i loro punti di forza e di debolezza, ed entrambi hanno il loro posto di conseguenza.

Appunti:

1) Un FPGA potrebbe essere progettato per eseguire diverse attività, ma anche in quel caso sarebbe un numero specifico per il quale è stato pre-progettato.

2) La velocità è anche una specifica di progettazione FPGA. È davvero un compromesso tra velocità e dimensioni.

3) L'inserimento di una CPU in un FPGA viene eseguito relativamente spesso, tuttavia viene fatto caso per caso, a seconda delle applicazioni specifiche. Ad esempio, se hai bisogno di un microcontrollore davvero minuscolo e hai spazio FPGA aggiuntivo.

E infine: questa risposta è una grande semplificazione: gli FPGA sono utilizzati in modi estremamente vari e complessi e questa è una breve panoramica sul modo in cui vengono utilizzati in generale.

Come dice Olin, qualcosa come un micro è più efficiente per molte attività e quasi sempre troverai un micro usato ovunque appaia un FPGA. La superficie coltivata del silicio utilizzato (che si traduce in costi in modo non lineare) e i consumi energetici sono molto inferiori. Per questo motivo, non è raro implementare un MCU "soft" su un FPGA, ma i costi e le prestazioni di un tale micro sono deludenti.

Alcuni FPGA moderni contengono uno o più core "duri" come l'onnipresente serie ARM. Inoltre, possono contenere blocchi di memoria dedicati poiché è davvero inefficiente liberare memoria dai gate. Un micro core a 32 bit occupa una piccola parte dell'area di silicio in un tipico FPGA, il che ti dà un'idea dei costi relativi.

Lo sviluppo è significativamente più difficile e l'IP tende a non essere così liberamente disponibile come per i micro e le soluzioni SOC dedicate, ad esempio controller LCD, interfacce PCI, MAC Ethernet. Il motivo è in parte il fatto che, rivelando le descrizioni logiche dell'HDL, trasferiscono il progetto non solo l'istanza del progetto. Un altro motivo è che le prestazioni dipendono dal layout della logica nell'FPGA, il che richiede molto sforzo durante lo sviluppo.

Un'ulteriore complicazione è che gli FPGA più complessi sono basati su RAM per la configurazione e i costi di processo sono tali che è necessaria memoria esterna non volatile per memorizzare la memoria di configurazione e programma per qualsiasi MCU a bordo. Questa memoria deve essere caricata nella RAM all'accensione.

Gli FPGA sono strumenti estremamente utili nella casella degli strumenti, ma presto non sostituiranno universalmente MCU o ASIC.

Il miglior uso del silicio per un lavoro è un ASIC, niente sprecato, ma hanno un'enorme curva di apprendimento, NRE e inflessibilità.

Esistono due modi per integrare la flessibilità in un chip. a) Avere un ALU ottimizzato per lo spazio e riutilizzarlo più volte sui dati memorizzati. Questo si chiama MCU e richiede una vasta area di silicio che "non sta facendo nulla", la memoria del programma, ampi bus che vanno da un'unità all'altra e interruttori di accesso al bus. b) Avere una logica a grana fine, con alcune parti opzionali ottimizzate nello spazio come moltiplicatori, piccole RAM e semplici CPU. Questo è chiamato FPGA e richiede una vasta area di silicio che "non fa nulla", interruttori programmabili e linee di connessione.

Ovviamente con queste strutture, le MCU funzionano meglio per le attività che possono essere suddivise in blocchi seriali e le FPGA funzionano meglio per le attività che richiedono operazioni parallele ad alta velocità. Quando l'applicazione è pesante e il costo è dominato dal costo del silicio, è così che verranno naturalmente utilizzati i due tipi.

Quando l'applicazione è leggera ma ad alto volume, il costo è dominato dall'imballaggio piuttosto che dal silicio, ed entrambi i tipi sono praticabili. Altera ha alcuni FPGA molto piccoli a bassissima potenza per competere con MCU da un dollaro a manciata.

Per le app a basso volume, il costo di sviluppo tende a dominare e lì gli MCU vincono, supponendo che abbiano la velocità

In termini di consumo energetico e utilizzo del silicio, un FPGA è molto scarso rispetto a un microprocessore.

Un FPGA consuma gran parte della sua area di silicio nei circuiti di configurazione logica qualcosa che non si applica a un micro. Devono essere disponibili molte più interconnessioni di quante sarebbero necessarie su un'implementazione dedicata di un microprocessore.

L'FPGA consuma più energia di un ASIC dedicato come un microprocessore poiché la logica non viene implementata in modo efficiente.

Qualsiasi funzione che può essere implementata in un FPGA può essere eseguita in modo più efficiente, più economico, con un consumo di energia inferiore, minore spazio sulla scheda ecc. In un ASIC dedicato. Ciò presuppone che i volumi siano abbastanza grandi da compensare l'NRE.

I sistemi basati su microprocessore, e successivamente i microcontrollori, sono stati in grado di raggiungere un enorme grado di funzionalità grazie alla loro capacità di utilizzare molti dei singoli circuiti in essi contenuti per svolgere molti compiti diversi in momenti diversi. Penso che sia istruttivo confrontare la macchina arcade Tank, progettata nel 1976, con il gioco Combat che gira sulla seconda macchina da gioco al mondo controllata da microprocessore, l'Atari 2600. Mentre ci sono alcune differenze nel gameplay, l'hardware Atari 2600 è stato essenzialmente progettato implementare giochi come Tank a costi minimi; il fatto che potesse essere fatto per giocare a giochi diversi inserendo cartucce ROM diverse era un bel vantaggio.

Il gioco Tank consente a due giocatori di guidare carri armati intorno allo schermo e sparare colpi l'uno contro l'altro. Ha segnalini "slip" per la posizione X e Y di ogni carro armato, la posizione X e Y dei colpi di ciascun giocatore, il contatore su / giù per l'angolo di ciascun giocatore e l'angolo di ciascun giocatore, un contatore per il punteggio di ciascun giocatore, raggio di raggi X e Y contatori di posizione e molti circuiti di controllo oltre a queste cose. Ha hardware per recuperare i dati del campo di gioco dalla ROM e visualizzarli, così come hardware per recuperare le forme per i carri armati dei due giocatori e punteggi dalla ROM e visualizzarli.

L'Atari 2600 ha un contatore di scorrimento per le posizioni orizzontali di ciascuno dei due oggetti giocatore, ciascuno dei due oggetti missilistici e un oggetto aggiuntivo chiamato "palla" che non è usato in combattimento ma è usato in alcuni altri giochi. Per ciascuno degli oggetti giocatore, ha l'hardware per produrre un pattern memorizzato in un latch a 8 bit, così come un latch "ritardato" a otto bit per ogni giocatore che viene copiato nel latch primario a 8 bit ogni volta che l'altro la forma è aggiornata. Ha anche un contatore di posizione del raggio orizzontale e un fermo a forma di campo di gioco a 20 bit che viene emesso sullo schermo due volte per linea di scansione, con la copia del lato destro che appare come ripetizione o riflesso della sinistra. Ha hardware per rilevare le collisioni, ma non per fare nulla in conseguenza di esse. Lo fa Non non ha hardware per le posizioni verticali di alcun oggetto, né per la posizione verticale del raggio raster (!), né ha hardware associato alla conservazione del punteggio, alla visualizzazione del punteggio, alla durata del gioco, ecc.

Tutte le funzioni per le quali il 2600 omette l'hardware sono gestite dal software nella cartuccia. È necessario solo verificare la posizione verticale di ciascun oggetto rispetto alla posizione del raggio raster una volta per linea di scansione, è necessario solo aggiornare il punteggio del giocatore e il tempo di gioco rimanente al massimo uno per fotogramma, i punteggi dei giocatori sono memorizzati su linee di scansione sopra il campo di gioco e quindi potrebbe condividere lo stesso hardware utilizzato per il campo di gioco, ecc.

L'approccio normale all'implementazione di un gioco come "Tank" in un FPGA sarebbe quello di utilizzare circuiti separati per funzioni diverse più o meno allo stesso modo della macchina arcade del 1976. Un tale approccio funzionerebbe, ma userebbe una notevole quantità di hardware. Un approccio basato su microprocessore potrebbe eliminare più della metà dell'hardware in cambio dell'aggiunta di un microprocessore, che conterrebbe probabilmente meno circuiti rispetto all'hardware che ha sostituito (il 2600 potrebbe implementare giochi molto più sofisticati di Tank, che richiederebbe molto più hardware se non utilizzavano un microprocessore).

Gli FPGA sono eccellenti nei casi in cui è necessario un dispositivo in grado di eseguire contemporaneamente molte attività semplici . I sistemi basati su microprocessore (o basati su microcontrollore) sono generalmente migliori, tuttavia, nei casi in cui ci sono molte attività che devono essere eseguite, ma non devono essere elaborate contemporaneamente, perché rendono facile l'uso di una piccola quantità di circuiti per realizzare un gran numero di scopi distinti.

È interamente il costo. Quando un micro può arrivare a un minimo di 30 centesimi, un FPGA economico si trova nel territorio di $ 5. Il costo potrebbe non sembrare così alto, ma quando si guadagna un milione di un nuovo giocattolo scoreggia da vendere a $ 10, il prezzo dell'FPGA uccide i tuoi profitti.

Solo per aggiungere altre ottime risposte, penso che l'adozione di FPGA sia anche una questione di dominio: ad esempio, per i dispositivi neuromorfi, le schede FPGA stanno diventando abbastanza onnipresenti perché c'è un enorme bisogno di parallelismo, che è un punto di forza di FPGA.

Se estrapoli la tendenza che vediamo per i dispositivi neuromorfi, si può immaginare che altri campi che sono basati, o che richiedono criticamente, il parallelismo probabilmente adotteranno molto di più gli FPGA. Quindi forse FPGA non diventerà onnipresente per i prodotti di qualità consumer, ma può essere per domini specifici come sembra stia accadendo attualmente per i dispositivi neuromorfi.