Come ottenere un design FPGA che funzionerà sicuramente su hardware reale

Ho appena iniziato a studiare la progettazione della logica digitale con FPGA e ho sviluppato molti progetti. Il più delle volte (dato che sono una specie di noob), ho un design che simula perfettamente (simulazione comportamentale) ma non si sintetizza correttamente.

Quindi, la mia domanda è "quali sono le fasi di progettazione che posso incorporare nel mio flusso di lavoro, che mi assicureranno di avere un design funzionante che funzioni direttamente sul mio FPGA?"

Ho due aree principali in cui mi aspetto consigli, ma questo è assolutamente basato su un mio punto di vista molto stretto come principiante, e altri sono i benvenuti:

• Quali sono tutti i passaggi (visualizzazione dello schema RTL, simulazione post-sintesi, ...) che dovrei intraprendere l'apprendimento per la migliore pratica.
• Cosa devo tenere a mente durante la progettazione della mia logica (ad esempio circuiti di FSM o circuiti sequenziali) per evitare risultati imprevisti.

Sto usando Xilinx Spartan 6 FPGA e Xilinx ISE Design suite per il mio lavoro.

In un posto in cui ho lavorato c'erano due campi di progettisti FPGA. Un campo che ho chiamato simula, simula, simula o è al cubo. L'altro campo riguardava il design.

I ragazzi al cubo usavano un simulatore come modelsim, avrebbero escogitato un progetto iniziale tramite metodi di codifica e \ o blocchi nella suite di design. Quindi avrebbero simulato e trovato le cose che non funzionavano, quindi avrebbero cambiato il codice. Questo processo è stato ripetuto più volte fino a quando non hanno avuto un design che ha funzionato.

Il campo di progettazione (che ho preferito) avrebbe disegnato la forma d'onda su carta (o carta digitale come visio), esattamente ciò che era richiesto. Quindi elaborare uno schema logico. Questo è un processo di auto-documentazione. Quindi il diagramma è stato tradotto in codice (il codice e il diagramma erano 1: 1 se c'era qualcosa nel diagramma, c'era un processo per esso nel codice). Quindi è stato simulato e la forma d'onda di simulazione è stata confrontata con la forma d'onda progettata su carta e ci si aspettava che fosse la stessa.

Ho finito per fare entrambe le cose, a volte sarei entrato in modalità cubo, e non è stato molto divertente. Ho scoperto di aver perso di vista il mio obiettivo a volte. Ad esempio, cambierei uno stato in una macchina a stati e il cambiamento si ridurrebbe allo stato successivo, quindi dovrei sistemarlo. Ho finito per passare più tempo che a pensarci.

In quale campo preferiresti essere? Penso che ci debba essere un design rigoroso, fare ciò che funziona per te, ma penso che più sei dettagliato e rigoroso nel progettare, meno problemi avrai a lungo termine. Ho fornito alcuni esempi di ciò che è possibile, potrebbero non adattarsi alla struttura organizzativa del luogo di lavoro. Il motivo per cui i dettagli di progettazione e un'attenta pianificazione sono così utili, è che ti costringe a pensare a cosa stai facendo. Semplifica il debug. Sviluppa un flusso di lavoro di progettazione che consenta che ciò accada. Inoltre, acquisisci familiarità con gli strumenti di simulazione e scrivi buoni banchi di prova che testeranno tutte le condizioni che potrebbero verificarsi sul dispositivo simulato. Questo ovviamente deve essere bilanciato con il tempo. Ad esempio, scrivi il codice ADL HDL che simulerà il dispositivo nelle tue simulazioni.

Lo strumento più prezioso da avere nella progettazione FPGA (a mio avviso) è una buona procedura di test che ti permetterà di testare completamente il tuo progetto ed eseguirlo a pieno ritmo. Non ci si può aspettare che un design FPGA "funzioni", ci vuole uno sforzo per assicurarsi che tutti i pezzi funzionino. Se riscontri errori, torna alla simulazione e al design e scopri quali sono le differenze tra un FPGA simulato e RTL. Ciò deriva principalmente dall'esperienza, ma se il design funziona in simulazione ma non nell'hardware, è necessario scoprire perché c'è una differenza.

Alcune cose chiave che ho imparato:
1) Disinfetta i tuoi input, i circuiti di clock e reset devono essere puliti o puoi far propagare la metastablità attraverso il tuo sistema. Scopri cos'è un sincronizzatore a doppio rango. Esistono molte topologie diverse per i circuiti di reset, sanno come usarle (c'è un ottimo articolo sul web, non ce l'ho a portata di mano).
2) Ottieni i requisiti del progetto in anticipo e poi disegna intorno a quelli. Se le persone intorno a te non ti daranno requisiti precisi, allora inventane alcuni per conto tuo.
3) La casella degli strumenti a punto fisso Matlab è ottima per simulare i sistemi di controllo e le applicazioni DSP, ma potresti non averne accesso. È un ottimo modo per dimostrare un progetto prima di codificare.
4) Il design viene prima di tutto, poi codifica, quindi simulazione.
5) Fortemente digitato, mantiene anche i nomi dei segnali coerenti sullo schema del pcb e sull'HDL. (Questo è anche il motivo per cui preferisco di gran lunga VHDL rispetto a Verilog.

Le cose principali sono:

• Codifica attenta per evitare strutture non sintetizzabili
• Ridurre al minimo i livelli logici per migliorare le prestazioni di temporizzazione (rendere la logica tra i registri il più semplice possibile)
• test, test, test per garantire la correttezza funzionale e controllare cose come reg non inizializzati e fili scollegati
• sintesi e controllare i log di sintesi per gli avvisi, assicurarsi che gli avvisi non indichino problemi (ad esempio, l'avviso di registro rimosso potrebbe essere intenzionale (non ha utilizzato un output del modulo) o involontario (dimenticato di collegare output del modulo / errore di battitura / ecc.))
• mappare e controllare il rapporto della mappa per i dati di utilizzo, assicurarsi che l'FPGA non sia troppo pieno
• luogo e percorso e analisi dei tempi, assicurati che il tuo progetto funzionerà alla velocità di clock richiesta

Ho avuto diversi progetti piuttosto complessi che funzionano correttamente (o almeno per lo più correttamente) sul primo test su un FPGA reale seguendo quanto sopra. Non è necessario controllare lo schema RTL, che è estremamente ingombrante e una completa perdita di tempo per progetti di grandi dimensioni. Una simulazione post-sintesi sarebbe molto più utile.

Tutto il tuo codice sintetizzabile deve essere espressibile come:

• LUT
• Infradito
• Primitive specifiche del fornitore

Le primitive specifiche del fornitore sono istanziate esplicitamente o generate dalla procedura guidata del fornitore o inferite da schemi di codifica molto specifici, quindi non dovrebbe esserci alcuna ambiguità lì.

In VHDL, ad esempio, non è possibile utilizzare wait fornel codice sintetizzabile. Per capire perché, prova a esprimere in modo deterministico wait for 100 nsusando LUT o le infradito. Non puoi.

Ciò non significa che non è possibile implementarlo impostando un contatore con una frequenza di clock nota (con periodo che può dividere 100 ns) e utilizzare il suo conteggio per sapere quando il tempo è scaduto. Ma il motore di sintesi non presenterà questo schema automaticamente, è necessario essere espliciti sull'architettura in termini di logica combinatoria (porte / LUT) e registri.

Quindi la cosa principale da tenere a mente per generare codice sintetizzabile è avere un quadro relativamente chiaro di come il tuo codice diventa porte logiche e infradito. Questo è tutto.

Il primo passo più ovvio è controllare gli avvisi.

Gli strumenti Xilinx producono file di registro che avvertono di tutto ciò che potrebbe non essere quello che intendeva il programmatore. A volte questo è fastidioso, quando hai risme di avvertimenti su segnali inutilizzati che sai perfettamente non vengono utilizzati. Ma a volte cattura bug genuini. Se sei un principiante, le possibilità che tu commetta un errore sono significativamente più alte.

Quindi è necessario impostare i vincoli di temporizzazione. Quanto tempo dopo un fronte di salita sull'orologio A è necessario impostare la linea dati B? O per quanto tempo deve essere mantenuta la linea dati B prima di un fronte di discesa sull'orologio A? I vincoli temporali ti permetteranno di specificare tutto questo. Se non hai vincoli di temporizzazione, il compilatore potrebbe presumere che non ti interessi particolarmente e che possa indirizzare i tuoi segnali ovunque. Se si hanno vincoli di temporizzazione, il compilatore funzionerà per assicurarsi che i segnali soddisfino tali vincoli spostando il posizionamento. E se non è in grado di soddisfare i vincoli di temporizzazione, verrà visualizzato un avviso.

Se il tuo problema è che le uscite non stanno facendo quello che ti aspetti, guarda in dettaglio i blocchi I / O. Ogni pin I / O ha un po 'di logica associata e un flip-flop. L'ordine in cui specifichi la tua logica e le variabili di stato nel tuo codice potrebbe non consentire al tuo codice di adattarsi a questa architettura, in modo da ottenere un ulteriore ritardo da qualsiasi luogo si trovi. Gli avvisi sui vincoli di temporizzazione ti diranno se ciò accade (supponendo che tu abbia impostato i tuoi vincoli di temporizzazione), ma la correzione richiede di comprendere l'hardware e il modo in cui il tuo progetto verrà mappato nell'hardware. Generalmente questo è solo un problema quando inizi a colpire alte frequenze, ma vale la pena menzionarlo.