Quali sono le migliori pratiche per i linguaggi di descrizione dell'hardware (Verilog, VHDL ecc.) [Chiuso]

Question

Quali sono le migliori pratiche da osservare durante l'implementazione del codice HDL?

Quali sono i punti in comune e le differenze rispetto ai più comuni campi di sviluppo software?

Answer 1

Il miglior libro su questo argomento è Manuale di metodologia di riutilizzo . Comprende sia VHDL che Verilog.

E in particolare alcuni problemi che non hanno una corrispondenza esatta nel software:

• Nessun fermo
• Fai attenzione ai ripristini
• Controlla i tuoi tempi interni ed esterni
• Utilizza solo codice sintetizzabile
• Registra le tue uscite di tutti i moduli
• Fai attenzione alle assegnazioni di blocco e non di blocco
• Fai attenzione agli elenchi sensibili per la logica combinatoria (o usa @ (*) in Verilog)

Alcuni uguali includono

• Usa CM
• Revisioni del codice
• Verifica (simula) il tuo codice
• Riutilizzare il codice quando appropriato
• Avere un programma aggiornato
• Avere una specifica o casi d'uso o un cliente Agile

Answer 2

Ordinamento di un vecchio thread, ma volevo inserire $ 0,02. Questo non è proprio specifico per Verilog / VHDL .. altro sulla progettazione hardware in generale ... design specificamente sintetizzabile per ASIC personalizzati.

Questa è la mia opinione basata su anni di esperienza nel settore (anziché accademica) nel campo del design. Non sono in un ordine particolare

La mia dichiarazione ombrello è di Design per l'esecuzione della convalida. Nella progettazione hardware, la convalida è fondamentale. I bug sono molto più costosi se trovati nel silicone reale. Non puoi semplicemente ricompilare. Pertanto, al pre-silicio viene data molta più attenzione.

• Conoscere la differenza tra percorsi di controllo e percorsi dati. Ciò consente di creare un codice molto più elegante e gestibile. Ti consente anche di salvare gate e minimizzare la propagazione X. Ad esempio, i percorsi di dati non dovrebbero mai aver bisogno di flop ripristinabili, i percorsi di controllo dovrebbero sempre averne bisogno.

• Prova la funzionalità prima della convalida. O attraverso un approccio formale o attraverso forme d'onda. Questo ha molti vantaggi, spiegherò 2. In primo luogo, ti farà risparmiare tempo a sbucciare la cipolla attraverso problemi. A differenza di molti progetti a livello di applicazione (specialmente durante l'apprendimento) e della maggior parte dei corsi, il tempo di inversione delle modifiche al codice è molto ampio (da 10 minuti a giorni, a seconda della complessità). Ogni volta che si modifica il codice, è necessario eseguire l'elaborazione, il controllo dei filamenti, la compilazione, la visualizzazione della forma d'onda e infine la simulazione effettiva che può richiedere ore. In secondo luogo, è molto meno probabile che si verifichino casi difficili. Si noti che ciò riguarda la validazione pre-silicio. Questi sicuramente colpiranno il post-silicio che ti costa un sacco di $$$. Fidati di me, il costo iniziale della dimostrazione della funzionalità riduce al minimo i rischi e ne vale la pena. A volte è difficile convincere i laureati più recenti.

• Hanno " bocconcini di pollo " ;. I bit di pollo sono bit in MMIO impostati tramite il driver per disabilitare una funzione in silicio. Ha lo scopo di ripristinare le modifiche apportate in cui la fiducia non è elevata (la fiducia è direttamente proporzionale agli sforzi di convalida). È quasi impossibile colpire ogni stato possibile nel pre-silicio. La fiducia nel tuo design non può davvero essere soddisfatta fino a quando non viene dimostrata in post-silicio. Anche se c'è solo 1 stato che viene colpito allo 0,000005% delle volte che espone il bug, COLPISCE in post-silicio, ma non necessariamente in pre-silicio.

• Evita eccezioni nel percorso di controllo a tutti i costi. Ogni nuova eccezione che hai raddoppia i tuoi sforzi di convalida. Questo è difficile da spiegare. Diciamo che esiste un blocco DMA che salverà i dati in memoria che un altro blocco utilizzerà. Supponiamo che la struttura dei dati salvata dipenda da alcune funzioni. Se hai deciso di progettare in modo tale che la struttura dei dati salvata fosse diversa tra le diverse funzioni, hai semplicemente moltiplicato i tuoi sforzi di convalida per il numero di funzioni DMA. Se si segue questa regola, la struttura dei dati salvata sarebbe un superinsieme di tutti i dati disponibili per ogni funzione in cui le posizioni dei contenuti sono codificate. Una volta convalidata la logica di salvataggio DMA per 1 funzione, viene convalidata per tutte le funzioni.

• Riduci a icona le interfacce (leggi minimizza i percorsi di controllo). Ciò è legato alla riduzione al minimo delle eccezioni. Innanzitutto, ogni nuova interfaccia richiede la convalida. Ciò include nuovi checker / tracker, asserzioni, punti di copertura e modelli funzionali del bus nel banco di prova. In secondo luogo, può aumentare esponenzialmente i tuoi sforzi di convalida! Supponiamo che tu abbia 1 interfaccia per la lettura dei dati nella cache. Ora diciamo (per qualche strana ragione) che decidi di volere un'altra interfaccia per leggere la memoria principale. Hai appena quadruplicato i tuoi sforzi di convalida. Ora devi convalidare queste combinazioni in qualsiasi momento n :

  • nessuna lettura della cache, nessuna lettura della memoria
  • nessuna lettura cache, lettura memoria
  • cache read, no memo

Answer 3

HDL come Verilog e VHDL sembrano davvero incoraggiare il codice spaghetti. La maggior parte dei moduli è costituita da diversi blocchi "sempre" (Verilog) o "processo" (VHDL) che possono essere in qualsiasi ordine. L'algoritmo generale o la funzione del modulo sono spesso totalmente oscurati. Capire come funziona il codice (se non l'hai scritto) è un processo doloroso.

Qualche anno fa mi sono imbattuto questo documento che delinea un metodo più strutturato per Design VHDL. L'idea di base è che ogni modulo ha solo 2 blocchi di processo. Uno per il codice combinatorio e l'altro per il sincrono (i registri). È ottimo per la produzione di codice leggibile e gestibile.

Answer 4

• in HDL, alcune parti del codice possono funzionare contemporaneamente, ad esempio due righe di codice "possono funzionare" allo stesso tempo, questo è un vantaggio, da usare saggiamente. questo è qualcosa che un programmatore che è abituato alle lingue riga per riga può trovare difficile da capire all'inizio:

  • È possibile creare pipeline lunghe e specifiche per le proprie esigenze.
  • Puoi far funzionare i tuoi grandi moduli contemporaneamente.
  • invece di un'unità per eseguire un'azione ripetuta su dati diversi, puoi creare più unità e svolgere il lavoro in parallelo.

• Particolare attenzione dovrebbe essere data al processo di avvio: una volta che il tuo chip è funzionante, hai fatto un modo enorme.

Il debug sull'hardware di solito è molto più difficile del debug del software, quindi:

• Il codice semplice è preferito, a volte ci sono altri modi per velocizzare il codice, dopo è già in esecuzione, ad esempio utilizzando un chip ad alta velocità, ecc. '.

• Evita " intelligente " protocolli tra i componenti.

• Un codice funzionante in HDL è più prezioso che su altri software, poiché l'hardware è così difficile da eseguire il debug, quindi il riutilizzo e considera anche l'utilizzo di "librerie" di moduli che alcuni sono gratuiti e altri venduti.

La progettazione di

• dovrebbe considerare non solo i bug nel codice HDL, ma anche i guasti sul chip che si sta programmando e su altri dispositivi hardware che si interfacciano con il chip, quindi si dovrebbe davvero pensare a un design facile da dai un'occhiata.

Alcuni suggerimenti per il debug:

• Se un progetto include diversi blocchi predefiniti, si vorrebbe probabilmente creare linee dalle interfacce tra quei blocchi ai punti di test esterni al chip.

• Dovrai salvare abbastanza linee nel tuo progetto per deviare i dati interessanti da ispezionare con dispositivi esterni. inoltre puoi usare queste righe e il tuo codice come modo per dirti lo stato corrente di esecuzione, ad esempio se ricevi dati in alcuni punto, scrivi un valore sulle righe, in una fase successiva di esecuzione scrivi un altro valore, ecc. '

  Se il tuo chip è riconfigurabile, questo sarà ancora più utile, dato che puoi personalizzare test specifici e riprogrammare le uscite per ogni test mentre procedi (questo sembra molto buono con i led :). )

Modifica

Con protocolli intelligenti, intendevo dire che se due delle tue unità fisiche dovessero connettersi, dovrebbero comunicare con il protocollo di comunicazione più semplice disponibile. cioè, non usare protocolli sofisticati fatti in casa, tra di loro.

Il motivo è questo: Bug di fidning "dentro" un FPGA / ASIC è estremamente semplice grazie ai simulatori. Quindi, se sei sicuro che i dati arrivano nel modo desiderato e che escono quando il tuo programma li invia, hai raggiunto l'utopia dell'hardware - essere in grado di lavorare a livello di software :) (con il simulatore). Ma se i tuoi dati non ti arrivano, nel modo in cui lo desideri, e devi capire perché ... dovrai connetterti alle linee, e non è così facile.

Trovare un bug sulle linee, è difficile in quanto devi connetterti alle linee con attrezzature speciali, che registrano gli stati delle linee, in tempi diversi, e dovrai assicurarti che le tue linee agiscano in base al protocollo.

Se devi collegare due delle tue unità fisiche, esegui il "protocollo" " il più semplice possibile, fino al punto in cui non verrà chiamato protocollo :) Ad esempio, se le unità condividono un orologio, aggiungono x righe di dati tra loro e fanno scrivere a un'unità e l'altra a leggere, passando così una "parola". che ha x bit tra di loro su ogni caduta di clock, per esempio. Se si dispone di FPGA, se la frequenza di clock originale dovesse essere troppo elevata per i dati paralleli, è possibile controllarne la velocità, in base ai propri esperimenti, ad esempio facendo in modo che i dati rimangano in linea di almeno "t" cicli di clock, ecc. ". Presumo dati paralleli t

Answer 5

Questa è la domanda che richiede i 10 comandamenti di JBDAVID per la progettazione hardware.

1. Usa Revision / Version Control, proprio come nel software. SVN e Hg sono gratuiti.
2. È necessario che il codice passi il controllo della sintassi prima del check-in. Uno strumento LINT è migliore.
3. Utilizza un linguaggio di verifica hardware completo per la verifica del progetto. System-Verilog è quasi una scelta sicura.
4. Traccia bug. Bugzilla e GNATS sono strumenti gratuiti. FogBugz richiede un po 'di $.
5. Usa Asserzioni per rilevare problemi con un uso errato.
6. La Triade di copertura garantisce un design stabile: misura della copertura del codice, copertura funzionale e copertura delle asserzioni sia nella simulazione che negli strumenti formali.
7. Power is King: usa CPF o UPF per acquisire, applicare e verificare il tuo Power-Intent.
8. il vero design è spesso segnale misto, usa un linguaggio a segnale misto per verificare l'analogo con il digitale. Verilog-AMS è una di queste soluzioni. Ma non esagerare. La modellazione del numero reale può realizzare la maggior parte degli aspetti funzionali del comportamento del segnale misto.
9. Usa l'accelerazione hardware per convalidare il software che deve funzionare con il silicio!
10. Sintassi Gli editor di testo consapevoli per il tuo HDL / HVL sono un requisito minimo per l'IDE sviluppatore.

Answer 6

Per gli FPGA, Xilinx ha questa pagina . Quasi tutti si applicherebbero ad altri fornitori FPGA o avrebbero regole equivalenti. Molto è applicabile ai progetti ASIC.

Intel ha raccomandato stili di codifica HDL e consigli di progettazione (PDF) sotto questa pagina .