Proprio come un linguaggio di programmazione procedurale passa attraverso diversi passaggi (compilazione, assemblaggio, collegamento) per produrre un eseguibile, gli HDL devono passare attraverso diversi processi prima che venga generato un file di configurazione utilizzabile per l'FPGA. Questi includono

• Sintesi --- converti il ​​codice HDL in una netlist che descrive le connessioni tra elementi logici.

• Mappatura --- Converti la netlist in una netlist più raffinata che utilizza le risorse effettivamente disponibili sul tuo dispositivo FPGA.

• Luogo e percorso: selezionare quale delle risorse effettive sul dispositivo verrà utilizzata per ciascuno degli elementi richiesti nell'output del mappatore e scegliere quali risorse di percorso verranno utilizzate per interconnetterle.

• Generazione di file bit --- converte il luogo e il percorso di output nel formato effettivamente utilizzato per programmare il dispositivo.

Quindi se, quando chiedi qual è l'output della sintesi, intendi qual è l'output del primo passaggio di questo processo, allora è un file intermedio utilizzato come input per il mappatore. Se intendi qual è l'output dell'intero processo, è un bitfile che l'FPGA può utilizzare per configurare tutte le sue risorse logiche e di routing.

Register Transfer Logic (RTL) è il risultato della prima fase di traduzione, prima di essere mappato alle risorse specifiche del fornitore, che non sono trasferibili tra fornitori o anche tra diversi FPGA dello stesso fornitore. Essenzialmente RTL mostra sia la logica combinatoria che i registri sincroni (flip flop D), quindi le macchine a stati sono riconoscibili. RTL è abbastanza coerente tra Altera e Xilinx ed è probabilmente la fase più interessante e utile da ispezionare. I problemi di sintesi diventano visibili per la prima volta nella fase RTL e il design è ancora riconoscibile. Una volta che va alla mappatura specifica del fornitore, viene sminuzzato e codificato. Cercare di decodificare un flusso di bit specifico per chip è costoso, a basso vantaggio e sarà inutile quando si passa a un altro fornitore o anche a un FPGA di dimensioni diverse nella stessa famiglia. Puoi vedere quello che devi vedere a livello RTL.

È sempre buona norma testare il codice Verilog o VHDL appena sviluppato istanziandolo all'interno di un banco di prova o un semplice modulo di primo livello e ispezionando il codice RTL. Xilinx ISE è molto utile per ispezionare RTL come schema (anche se a volte manca qualcosa.) I problemi più comuni sono:

• Reti a 1 bit in cui era previsto un bus
• blocchi di logica inaspettatamente rimossi dall'ottimizzatore ... simile a come un semplice ciclo di ritardo di spinlock viene silenziosamente eliminato dall'ottimizzazione del codice.
• output non completamente specificati, a causa dell'approccio procedurale invece dell'approccio della tabella della verità. Se lo strumento pensa che l'output sia sempre 0 o sempre 1, eliminerà tutta la logica che genera quel risultato.
• la logica del modulo viene ridotta perché uno dei sottomoduli è stato ottimizzato a sempre 0 o sempre 1; questo può arrivare a cascata fino al livello superiore

Questa ispezione RTL diventa molto ingombrante a meno che non mantieni i tuoi moduli piccoli e semplici. Usare un testbench è uno strumento importante.

Anch'io provenivo prima dalla programmazione di sistemi embedded e poi da verilog, e il rischio più grande per persone come noi quando imparano la codifica HDL è che sembra un linguaggio di programmazione procedurale, e si sente come un linguaggio di programmazione procedurale (durante la simulazione), ma poi tutto esplode quando provi a sintetizzare codice funzionante. Devi davvero pensare a come deve essere l ' hardware e assicurarti che il codice RTL includa tutto l'hardware che ti aspetti.

A parte il fatto che Verilog / VHDL comporta la digitazione di un codice sorgente in un file di computer, non c'è molta somiglianza con il tradizionale C / C ++ / ecc. Molto poco della tua esperienza di programmazione verrà trasferito. Concentrati sulla suddivisione di grandi problemi in piccoli problemi, documentando tutto in grande dettaglio e scrivendo banchi di prova. Investite anche in un buon oscilloscopio di campionamento digitale se non ne avete già uno. Dai un'occhiata ad alcuni dei codici di esempio pubblicati su opencores.org, poiché con C / C ++ puoi imparare molte tecniche (sia buone che cattive) leggendo il codice di altre persone.

Una cosa che mi fa impazzire dello sviluppo FPGA è che il controllo del codice sorgente non è qualcosa che i fornitori di toolchain sembrano ritenere una caratteristica importante. Xilinx Vivado è particolarmente pessimo in questo senso, il loro consiglio sembra essere quello di rigenerare i file di progetto da zero quando si effettua un nuovo checkout. Provare a consegnare un progetto con più di 100 MB di file zip è scoraggiante.

L'altra cosa che mi fa impazzire dello sviluppo FPGA è che gli strumenti Quartus / ISE / Vivado non hanno un modo soddisfacente per reprimere il flusso di messaggi di avviso. Quando scrivo programmi C / C ++, mi aspetto di essere in grado di affrontare ogni messaggio di avviso individualmente e di correggerlo o di sanzionarlo, in modo da poter finalmente ottenere una compilazione pulita con zero avvisi. Non ho mai visto nessuno raggiungere questo obiettivo nello sviluppo di FPGA; altri sviluppatori FPGA (che sono più intelligenti di me) sembrano accettare semplicemente che un normale progetto ha molti messaggi diagnostici, che spesso ignorano semplicemente, lasciandosi fare il lavoro di laboratorio e la verifica su hardware reale.

Se dovessi mai sviluppare la tua scheda FPGA (cosa che non consiglio), assicurati di mettere in evidenza tutti i pin I / O inutilizzati da qualche parte in un'intestazione, quanti ne puoi gestire, perché sarà la tua ancora di salvezza quando devi eseguire il debug del codice FPGA o implementare una patch dell'undicesima ora.

Hai menzionato la programmazione in linguaggio assembly come un modo per esercitare un controllo preciso su ciò che il computer sta facendo, ed è possibile esercitare un controllo altrettanto preciso sul codice FPGA utilizzando primitive non portatili e specifiche del fornitore. Questo sarà diverso per ogni fornitore e ogni FPGA, proprio come il linguaggio assembly è diverso per le diverse CPU. Per Xilinx dovresti scrivere un file di vincoli (diverso per toolchain ISE o toolchain Vivado). Il file dei vincoli richiama istanze specifiche o reti specifiche e specifica i requisiti temporali. In genere i CLB / LUT / qualunque unità di basso livello sono disposti in una griglia, in modo da poter individuare una specifica primitiva di basso livello per vivere in una specifica posizione della griglia X, Y. Cerca il vecchio Xilinx "FPGA Editor" per la serie Spartan 3, che incoraggiavano le persone a usarlo in quel modo. Penso che la nuova serie 7 e i chip Zynq non siano supportati. Come l'assemblaggio, è molto specifico per la tecnologia ed è quindi una specie di set di abilità volatile.

Simile all'assembly, per qualsiasi cosa diversa da un banale esercizio di "compiti a casa", vuoi davvero ridurre al minimo la quantità di assembly che scrivi;usa C / C ++ per il 98% -99% e scrivi solo assembly per l'1% che è sensibile alle prestazioni.Se, ad esempio, hai un design FPGA che richiede che alcuni sottoprocessi funzionino a 200 MHz, vale la pena immergersi nella mappatura di basso livello per vedere cosa stanno facendo gli strumenti.Il miglior guadagno per l'ottimizzazione è se riesci a eliminare fasi di lavoro non necessarie.Solo dopo aver ridotto gli elementi caldi al minimo indispensabile, solo allora vale la pena iniziare a instradare manualmente gli IOB a cui appartengono le posizioni della griglia.Lascia che sia la macchina a fare la maggior parte del lavoro, così puoi concentrare i tuoi sforzi.

La primitiva fisica di un FPGA è un blocco logico configurabile (CLB).

A ogni blocco logico viene assegnata una posizione dedicata in memoria, la cosiddetta memoria di configurazione, che determina come è configurato e dove si connette.

HDL finisce per diventare un insieme di uno e zero, un cosiddetto bitstream che viene inserito in questa memoria di configurazione.

La maggior parte degli FPGA non ha una memoria di configurazione non volatile integrata. Invece, il bitstream di configurazione è memorizzato su una FLASH ROM di configurazione esterna e all'accensione l'FPGA carica quel bitstream dalla memoria non volatile esterna nella sua SRAM di configurazione interna che è direttamente collegata e controlla i CLB.

A differenza del software, questo bitstream non viene "eseguito". Viene appena caricato e poi semplicemente "è". È meno simile a istruzioni in esecuzione e più simile a registri contenenti impostazioni.

È un file come * .bit. Non esiste un formato standard. Non sono sicuro del motivo per cui vorresti scrivere un simulatore da solo quando gli strumenti di sviluppo FPGA sono dotati di un simulatore. Viene fatto un grande sforzo e loro conoscono i loro dispositivi meglio di chiunque altro perché, a differenza del software, ogni primitiva specificata nel bitstream deve essere fisicamente situata da qualche parte sul die FPGA e la planimetria può creare o distruggere alcuni progetti.

quali byte vengono scritti durante la programmazione di un FPGA?

Questo è meno responsabile in generale, perché è specifico al 100% del produttore e del dispositivo. Alcuni produttori pubblicano schede tecniche per questo; altri produttori considerano questo un "segreto commerciale" e sarebbe necessario firmare un accordo di non divulgazione per scoprirlo.

Con un compilatore C (o qualsiasi altro linguaggio) comunque, i byte grezzi non sono la parte più elementare. La parte più semplice è la serie di istruzioni del processore che implementano il tuo programma, ei byte grezzi sono semplicemente il modo in cui dici al processore quali sono quelle istruzioni. Queste istruzioni fanno sì che il processore esegua operazioni utilizzando i suoi vari servizi hardware come sommatori, moltiplicatori e simili e memorizzi o recuperi dati in registri e memorie.

È molto simile in un FPGA, tranne per il fatto che inizi a un livello inferiore. Invece di avere un elenco di istruzioni da eseguire, quello che hai è un elenco di come ogni gate nell'FPGA dovrebbe essere interconnesso. La maggior parte degli FPGA contiene anche sezioni specializzate per RAM e altre funzionalità e il programma includerà anche il modo in cui vengono collegate.

Ciò che si ottiene allora è una netlist , come se si progettasse un PCB con un milione di chip logici. Questo è concettualmente l'output più basilare del tuo compilatore FPGA per dirti cosa sta facendo, allo stesso modo in cui un elenco di assemblatori è concettualmente l'output più basilare del tuo compilatore C per dirti cosa sta facendo il processore.

Ovviamente il compilatore continua a produrre un file binario che programmerà l'FPGA con quella netlist, allo stesso modo in cui un compilatore C continua a produrre un file binario che programma il tuo micro con quell'assemblatore.

"quali byte vengono scritti durante la programmazione di un FPGA?"

Semplicisticamente, questi byte contengono le informazioni per:

1) Configurazione dei blocchi I / O & logici FPGA (si desidera che questo blocco sia un registro, un multiplexer, una tabella di ricerca per uso generale) e

2) Configurare l'interconnessione sull'FPGA per agganciare i blocchi logici tra loro e per connettersi poi al mondo esterno.

Tante risposte che non le ho lette tutte, essendo qualcuno che siede su entrambi i lati del recinto, hardware e software ...

Quindi, sebbene in ogni modo si tratta di un linguaggio di programmazione che viene compilato in altri linguaggi di livello idealmente inferiore (C in asm o codice macchina, JAVA in bytecode o altro linguaggio o assembly o codice macchina, ecc.). Ci sono molti più passaggi e gli obiettivi sono molto più vari di isa che sono tanto comuni quanto diversi: add, mov, jne, push, pop, ecc.

Il codice macchina per fpgas o asics non è solo transistor discreti, ma una libreria di cose. Per gli asics per una particolare fonderia e processo ci sono una o più librerie di celle disponibili e avranno porte semplici e eo ma anche cose più grandi e complicate, perché costruire un latch di componenti discreti quando gli autori della libreria possono creare alcune dimensioni comuni quelli e imballarli in modo efficiente (immobiliare). Così come con qualsiasi compilatore o autore di alto livello, scorri l'elenco delle opzioni e ne scegli alcune. compreso un lungo elenco di sram di varie larghezze e profondità. Per un FPGA si tratta di LUT o moduli generici fissi che possono agire come vari moduli che sono più complicati di un semplice and, or, xor gate.

Al mondo FPGA piace tenere le cose vicino al petto, inoltre cercano di essere molto più convenienti degli strumenti asic, decine di migliaia di dollari all'anno anziché milioni. E come qualsiasi altro ambiente integrato, a volte hai vari fornitori che sono stati acquistati o concessi in licenza e gli strumenti incollati insieme (spesso non molto belli).

Quindi tutti i passaggi menzionati da altre persone sono avvenuti. che è più del software e i formati di file sono molto proprietari e non ci si aspetta che siano documentati o supportati, ogni versione potrebbe cambiare. Ancora una volta queste persone sembrano essere competitive e riservate (se dovessero aprirsi potremmo avere strumenti significativamente migliori e potrebbero vendere più prodotti IMO, ma potrebbero ridurre i soldi del supporto che è forse ciò di cui vivono con i loro strumenti scadenti) .

Quando la gente dice netlist, il verilog è compilato in una netlist, quelli che ho visto sono anche in verilog o vhdl come questi linguaggi lo coprono. alla fine dovrai quindi prendere di mira lo specifico qualunque, fpga, cpld, asic, ecc. Essendo un obiettivo già cablato / fisso, alla fine ti ritroverai con un elenco di fusibili o interruttori se lo desideri, prendi un lut generico e collega questo ingresso a quello e quell'input a quello aprendo e chiudendo le connessioni nell'enorme rete di cose. Che finisce per essere una sorta di semplice elenco di on e off. E penso che potrebbe esserci uno standard jedec su questo, ma spesso chiamato bitstream e almeno usiamo un lettore bitstream per caricare.

I CPLD in generale si programmano queste informazioni nella parte stessa sia che si tratti di un flash a bordo che poi apre / chiude le cose all'accensione e / o la memoria non volatile all'interno si accende con gli elementi cablati.

Gli FPGA in genere hanno un flash esterno e all'accensione le informazioni per collegare le cose vengono caricate da questo, quindi il resto della parte viene visualizzato utilizzando quella configurazione. Quelli che so su di te possono anche caricare queste informazioni nella parte ed effettuare tutte le connessioni, ma queste informazioni vengono perse quando la parte viene spenta. quindi, a seconda del design, potresti avere qualche altra soluzione e non utilizzare il flash. Il formato flash è probabilmente prioprietario, non ho guardato personalmente, quando entri attraverso l'interfaccia di programmazione che passa attraverso l'fpga alla flash in modo che possa andare così com'è o potrebbe essere convertito nel suo percorso in qualcos'altro.

Con il software specialmente questa volta e in questo posto siamo abituati per lo più ad aprire cose, strumenti gratuiti piuttosto buoni che molte persone usano. Il che significa anche che i formati di file sono documentati e in qualche modo comuni, alcuni avevano una cronologia prima di questa volta .com e .exes e altri per altri sistemi operativi del giorno. Ma ancora una volta il mondo del software è più comune che diverso, idealmente stai mirando al codice macchina o al bytecode. Con la logica si passa da un livello alto a un livello inferiore, ma a un certo punto si utilizza lo stesso linguaggio. Quindi potresti prendere di mira un simulatore che ha la sua libreria di moduli o fpga n con la sua libreria o fpga m con la sua libreria e così via. E quelle persone sono molto protettive nei confronti delle informazioni.

Clifford e il progetto IceStorm IMO sono la strada giusta, è finora l'unica volta che ho costruito qualcosa per un fpga che è semplice, funziona, senza avvisi o errori che spesso piacciono alla gente del software.Ho passato innumerevoli notti cercando di ottenere la cosa più semplice da costruire per un fpga da tutti i principali fornitori senza avvertimenti ... e mi arrendevo sempre.Dal verilog alla parte programmata ci sono almeno tre progetti separati, il che implica che ci sono file intermedi che entrambe le parti devono supportare in modo che i formati di file siano lì.ma ci si aspetterebbe che sia specifico del progetto e non necessariamente come un file elf ampiamente utilizzato per più di un caso d'uso.

Comprendi che il mondo dei chip, inclusi gli fpgas, è follemente costoso, quindi è guidato dal denaro, il che spesso significa vendere strumenti e, soprattutto, contratti di supporto annuali.Il che significa sorgente chiusa, informazioni chiuse, formati di file non documentati pubblicamente.

Prima di arrivare alla sintesi, puoi verificare il progetto in simulazione.In questo caso, il tuo progetto viene trattato come software e per almeno un simulatore (GHDL open source, non sorprendentemente per VHDL) il compilatore può utilizzare i backend gcc o LLVM per generare un normale eseguibile.

In genere si incorpora il progetto effettivo in un "banco di prova" (scritto anche in VHDL) che genera segnali di input e rapporti sulla correttezza degli output - sia alla console (tramite dichiarazioni Assert / Report) o utilizzando strumenti di verifica e registrazionecome OSVVM, in un framework di test di unità (VUnit).

Se tutto il resto fallisce, puoi scaricare e ispezionare le forme d'onda in una GUI.

Una volta che tutto funziona, procedi alla sintesi come descritto nelle altre risposte.