Esperienze con Test Driven Development (TDD) per la progettazione logica (chip) in Verilog o VHDL

StackOverflow https://stackoverflow.com/questions/1633559

Domanda

Ho cercato sul web e le discussioni / esempi sembrano essere per lo sviluppo di software tradizionale. Poiché Verilog e VHDL (utilizzati per la progettazione di chip, ad esempio FPGA e ASIC) sono simili allo sviluppo software C e C ++, sembrerebbe avere senso. Tuttavia, presentano alcune differenze sostanzialmente parallele e che richiedono hardware per eseguire test completi.

Quali esperienze, buone e cattive, hai avuto? Qualche link che puoi suggerire su questa specifica applicazione?

Modifiche / chiarimenti: 28/10/09: In particolare, chiedo TDD. Conosco i banchi di prova, compresi quelli autocontrollati. Sono anche consapevole che SystemVerilog ha alcune caratteristiche particolari per i banchi prova.

28/10/09: Le domande implicite includono 1) scrivere un test per qualsiasi funzionalità, non usare mai forme d'onda per la simulazione e 2) scrivere prima test / testbenches.

29/11/09: In Studi empirici mostrano lo sviluppo guidato dai test migliora Qualità segnalano per (software) TDD " La densità di difetto pre-release dei quattro prodotti, misurata come difetto per mille righe di codice, è diminuita tra il 40% e il 90% rispetto ai progetti che non hanno utilizzato TDD . La gestione dei team ha riferito soggettivamente di un aumento del 15% del 35% nei tempi di sviluppo iniziale per i team che utilizzano TDD, sebbene i team abbiano concordato che questo è stato compensato da costi di manutenzione ridotti. & Quot; I bug ridotti riducono il rischio di uscita del nastro, a scapito di un moderato impatto sulla pianificazione. Questo contiene anche alcuni dati.

29/11/09: Sto principalmente eseguendo il controllo e il codice datapath, non il codice DSP. Per DSP, la soluzione tipica prevede una simulazione accurata dei bit di Matlab.

03/02/10: Il vantaggio di TDD è di assicurarsi che il test fallisca per primo. Suppongo che ciò potrebbe essere fatto anche con affermazioni.

È stato utile?

Soluzione

Scrivo codice per FPGA, non ASICS ... ma TDD è ancora il mio approccio preferito. Mi piace avere una suite completa di test per tutto il codice funzionale che scrivo e provo (non sempre con successo) a scrivere prima il codice di test. Fissare le forme d'onda si verifica sempre a un certo punto durante il debug, ma non è un buon modo per convalidare il codice (IMHO).

Data la difficoltà di eseguire test adeguati nell'hardware reale (stimolare casi angolari è particolarmente difficile) e il fatto che una compilazione VHDL richiede pochi secondi (rispetto a una compilazione hardware che richiede molti minuti (o persino ore) ), Non vedo come chiunque possa operare in altro modo!

Costruisco anche affermazioni in RTL mentre scrivo per catturare cose che so che non dovrebbero mai accadere. Apparentemente questo è visto come un po '"strano", dato che esiste la percezione che gli ingegneri della verifica scrivano affermazioni e i progettisti RTL no. Ma soprattutto sono il mio ingegnere di verifica, quindi forse è per questo!

Altri suggerimenti

Uso VUnit per lo sviluppo guidato dai test con VHDL.

VUnit è una libreria Python che richiama il compilatore e il simulatore VHDL e legge i risultati della simulazione. Fornisce inoltre diverse librerie VHDL che semplificano notevolmente la scrittura di banchi di prova migliori, come una comunicazione libreria , libreria di registrazione e una verifica della libreria .

Ci sono molte possibilità poiché è invocato da Python. È possibile sia generare dati di test sia verificare i dati di output dal test in Python. Ho visto questo esempio l'altro giorno in cui hanno usato Octave - una copia Matlab - per tracciare i risultati dei test .

VUnit sembra molto attivo e sono stato più volte in grado di porre domande direttamente agli sviluppatori e ho ottenuto aiuto abbastanza rapidamente.

Un aspetto negativo è che è più difficile eseguire il debug degli errori di compilazione poiché ci sono così tante varianti di funzione / procedura con lo stesso nome nelle librerie. Inoltre, alcune cose vengono fatte dietro le quinte preelaborando il codice, il che significa che alcuni errori potrebbero apparire in luoghi inaspettati.

Le estensioni SystemVerilog allo standard IEEE Verilog includono una varietà di costrutti che facilitano la creazione di suite di test approfondite per la verifica di complessi progetti di logica digitale. SystemVerilog è uno di i linguaggi di verifica hardware (HVL) utilizzati per verificare il chip ASIC progetti tramite simulazione (invece di emulazione o utilizzo di FPGA).

Vantaggi significativi rispetto a un linguaggio di progettazione hardware tradizionale (Verilog) sono:

  • randomizzazione vincolata
  • affermazioni
  • raccolta automatica di dati di copertura funzionale e di asserzione

La chiave è avere accesso al software di simulazione che supporta questo recente standard (2005). Non tutti i simulatori supportano completamente le funzionalità più avanzate.

Oltre allo standard IEEE, esiste una libreria SystemVerilog open source dei componenti di verifica disponibili da VMM Central ( http://www.vmmcentral.com ). Fornisce un quadro ragionevole per la creazione di un ambiente di test.

Puoi anche fare ulteriori ricerche sull'argomento cercando in Forum della gilda di verifica.

SystemVerilog non è l'unica HVL e VMM non è l'unica libreria. Ma, raccomanderei entrambi, se hai accesso all'appropriato utensili. Ho trovato che questa è una metodologia efficace nella ricerca del design i bug prima diventano silicio.

Non so molto sulla progettazione di hardware / chip, ma sono profondamente interessato a TDD, quindi posso almeno discutere l'idoneità del processo con te.

La domanda che definirei più pertinente è: quanto velocemente i tuoi test possono darti feedback su un progetto? In relazione a ciò: quanto velocemente puoi aggiungere nuovi test? E in che modo i tuoi strumenti supportano il refactoring (cambiando struttura senza cambiare comportamento) del tuo design?

Il processo TDD dipende molto dalla "morbidezza" di software: buoni test di unità automatizzati vengono eseguiti in pochi secondi (minuti all'esterno) e guidano brevi raffiche di costruzione e refactoring mirati. I tuoi strumenti supportano questo tipo di flusso di lavoro, spostandosi rapidamente tra la scrittura e l'esecuzione dei test e la creazione del sistema sotto test in brevi iterazioni?

Per quanto riguarda gli strumenti di refactoring per i linguaggi hardware, vorrei indicarti il ??nostro strumento Sigasi HDT . Sigasi fornisce un IDE con analizzatore VHDL incorporato e refactoring VHDL.

Philippe Faes, Sigasi

ANVIL & # 8211; Un altro livello di interazione di Verilog ne parla un po '. Non l'ho provato.

Non ho mai provato attivamente TDD su un progetto RTL, ma ci ho pensato.

Quello che penso sarebbe interessante è provare questo approccio in connessione con le asserzioni. Fondamentalmente, prima di tutto scrivi sotto forma di asserzioni ciò che assumi / aspetti dal tuo modulo, scrivi il tuo RTL e in seguito puoi verificare queste asserzioni usando strumenti formali e / o simulazione. Contrariamente a "normale" testcase (dove probabilmente avresti bisogno di scrivere quelli diretti) dovresti avere una copertura molto migliore e le asserzioni / assunzioni potrebbero essere utili in seguito (ad esempio a livello di sistema).

Tuttavia, non mi affiderei completamente alle affermazioni, questo può diventare molto peloso.

Forse puoi esprimere i tuoi pensieri anche su questo, come lo stai chiedendo, immagino che porti alcune idee nella tua testa?

Che cos'è TDD per te? Vuoi dire che tutto il tuo codice viene esercitato in ogni momento dai test automatici, o vai oltre per significare che i test vengono scritti prima del codice e nessun nuovo codice viene scritto a meno che i test falliscano?

Qualunque approccio tu preferisca, il test del codice HDL non è molto diverso dal test del software. Ha i suoi vantaggi (copertura e profondità dei test molto migliori) e svantaggi (difficile da configurare e ingombrante rispetto al software).

Ho avuto un'ottima esperienza nell'impiego di Python e di trattori HDL generici per l'implementazione di test completi e automatici per moduli HDL sintetizzabili. L'idea è in qualche modo simile a ciò che Janick Bergeron presenta nei suoi libri, ma invece di SystemVerilog, Python è abituato a (1) genera codice VHDL da scenari di test scritti in Python e (2) verifica dei risultati scritti dai transattori di monitoraggio che accettano le forme d'onda dal progetto durante la simulazione.

C'è molto altro da scrivere su questa tecnica, ma non sono sicuro su cosa tu voglia concentrarti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top