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

Question

Ho guardato sul Web e le discussioni/gli esempi sembrano essere per lo sviluppo del software tradizionale. Poiché Verilog e VHDL (utilizzati per la progettazione di chip, ad esempio FPGA e ASIC) sono simili allo sviluppo di software C e C++, sembrerebbe avere senso. Tuttavia, alcune differenze sono fondamentalmente parallele e richiedono l'hardware per test completi.

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

Modifiche/chiarimenti: 28/10/09: Mi sto particolarmente chiedendo di TDD. Ho familiarità con i banchi di prova, compresi quelli autocontrollati. Sono anche consapevole del fatto che SystemVerilog ha alcune caratteristiche particolari per i banchi di prova.

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

11/29/09: In Empirical Studies Show Test Driven Development Improves Quality riportano per (software) TDD "La pre-release densità di difetti dei quattro prodotti, misurata come difetti per mille linee di codice, diminuito tra il 40% e il 90% rispetto al progetti che non utilizzavano il TDD: la dirigenza dei team ha segnalato soggettivamente un aumento del 15-35% dei tempi di sviluppo iniziale per i team che utilizzavano il TDD, sebbene i team concordassero che ciò fosse compensato da una riduzione dei costi di manutenzione ". I bug ridotti riducono il rischio di intercettazione, a scapito di un impatto moderato sul programma. This ha anche alcuni dati.

29/11/09: Principalmente sto facendo il controllo e il codice datapath, non il codice DSP. Per DSP, la soluzione tipica prevede una simulazione bitmap accurata di Matlab.

03/02/10: Il vantaggio di TDD è che ci si assicura che il test fallisca prima. Suppongo che questo potrebbe essere fatto anche con asserzioni.

Answer 1

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 test. L'osservazione delle forme d'onda avviene sempre ad un certo punto durante il debug, ma non è un buon modo per convalidare il codice (IMHO).

Data la difficoltà di eseguire test corretti nell'hardware reale (i casi d'angolo stimolanti sono particolarmente difficili) e il fatto che una compilazione VHDL impieghi secondi (rispetto a una compilazione "su hardware" che richiede molti minuti (o anche ore)), Non vedo come chiunque possa operare in un altro modo!

Costruisco anche asserzioni nel RTL mentre scrivo per catturare cose che so non dovrebbero mai accadere. Apparentemente questo è visto come un po '"strano", poiché c'è la percezione che gli ingegneri di verifica scrivano asserzioni e i progettisti di RTL no. Ma soprattutto sono il mio tecnico di verifica, quindi forse è per questo!

Answer 2

Le estensioni SystemVerilog dello standard IEEE Verilog includono una serie di costrutti che facilitano la creazione di suite di test complete per la verifica di progetti di logica digitale complessi. SystemVerilog è uno di HVL (Hardware Verification Languages) che viene utilizzato per verificare i progetti di chip ASIC tramite simulazione (al contrario dell'emulazione o dell'utilizzo di FPGA).

vantaggi significativi rispetto a un tradizionale progetto hardware Language (Verilog) sono:

• randomizzazione vincolata
• affermazioni
• raccolta automatica dei dati di copertura funzionale e l'affermazione

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

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

È inoltre possibile eseguire ulteriori ricerche sull'argomento effettuando una ricerca nel forum di Verification Guild .

SystemVerilog non è l'unico HVL e VMM non è l'unica libreria. Tuttavia, suggerirei entrambi, se si ha accesso agli appropriati strumenti . Ho trovato che questa sia una metodologia efficace nella ricerca di errori di progettazione prima del diventando silicio.

Answer 3

Non ho mai provato attivamente TDD su un progetto RTL, ma avevo le mie idee su questo.

Quello che penso sarebbe interessante è provare questo approccio in connessione con le affermazioni. In pratica, dovresti innanzitutto scrivere sotto forma di asserzioni cosa assumi/aspetti dal tuo modulo, scrivi la tua RTL e successivamente puoi verificare queste asserzioni usando strumenti formali e/o simulazione. In contrasto con i "normali" testcases (dove probabilmente dovresti scrivere quelli diretti) dovresti avere una copertura molto migliore e le asserzioni/assunzioni potrebbero essere utili successivamente (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 chiedi, credo che tu abbia qualche idea in testa?

Answer 4

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

La domanda che definirei più pertinente è la seguente: quanto rapidamente i test possono fornire feedback su un progetto? Relativo a quello: quanto velocemente puoi aggiungere nuovi test? E quanto bene i tuoi strumenti supportano il refactoring (cambiare la struttura senza modificare il comportamento) del tuo design?

Il processo TDD dipende molto dalla "morbidezza" del software: i buoni test automatici delle unità vengono eseguiti in pochi secondi (minuti all'esterno) e guidano brevi raffiche di costruzione mirata e refactoring. I tuoi strumenti supportano questo tipo di flusso di lavoro, spostando rapidamente tra scrittura e test in esecuzione e costruendo il sistema sotto test in brevi iterazioni?

Answer 5

Che cos'è TDD per te? Intendi dire che tutto il tuo codice viene esercitato da test automatici in qualsiasi momento, o vai oltre nel dire che i test sono scritti prima del codice e non viene scritto nessun nuovo codice a meno che i test falliscano?

Qualunque sia l'approccio che preferisci, il test del codice HDL non è molto diverso dal test del software. Ha i suoi vantaggi (maggiore copertura e profondità di test) e svantaggi (difficili da configurare e ingombranti relativamente al software).

Ho avuto un'esperienza molto buona con l'impiego di transporter HDL Python e 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 è usato per (1) generare codice VHDL da scenari di test scritti in Python e (2) verifica dei risultati scritti dai gestori di monitoraggio che accettano forme d'onda da il design durante la simulazione.

C'è molto altro da scrivere su questa tecnica, ma non sono sicuro di cosa si voglia mettere a fuoco.

Answer 6

Per quanto riguarda gli strumenti di refactoring per i linguaggi hardware, desidero indicarvi il nostro strumento Sigasi HDT. Sigasi fornisce un IDE con analizzatore VHDL integrato e refactoring VHDL.

Philippe Faes, Sigasi

Answer 7

ANVIL - Un altro Verilog Interazione layer parla di questo un po '. Non l'ho provato