Verifica della CPU soft


18

Attualmente sto progettando una semplice CPU in VHDL usando Xilinx ISE e ISIM. La parte del design sta andando molto bene, ma non riesco a capire un modo per fare la verifica in modo coerente.

In questo momento ho un banco di prova VHDL che aggiorno per testare la funzione su cui sto lavorando in un determinato momento. Questo è molto ad-hoc e non mi aiuta a rilevare le regressioni e non può essere utilizzato per verificare la conformità con le specifiche / le istruzioni.

Ho pensato di sviluppare una vasta suite di test, ma il problema è che lo stato potenziale di una parte di uso generale come CPU è enorme rispetto a componenti meno generici.

Sto cercando un metodo che mi permetta di eseguire la progettazione e il collaudo in modo più controllato. Una specie di "TDD hardware" se vuoi. Esiste una cosa del genere? Può essere applicato relativamente facilmente a parti di uso generale come una CPU?

Risposte:


16

L'intero problema della verifica della CPU è molto grande e difficile. Ci sono persone che fanno carriera proprio con questo. Ti darò solo una panoramica ...

  1. Scrivi un programma di linguaggio assembly che testa ogni istruzione e ogni piccolo dettaglio di ogni istruzione. Ad esempio, durante il test dell'istruzione ADD è possibile testarlo con numeri che sono entrambi positivi, entrambi negativi e uno di ciascuno (due volte). Dovresti quindi testare il flag carry, il flag zero, ecc. Altre caratteristiche speciali della CPU (come la previsione del ramo, ecc.) Avrebbero la loro parte speciale di questo test.

  2. Scrivi, usando C / C ++ o qualcosa del genere, un modello della tua CPU. Questa è la tua CPU virtuale. Questa è anche la tua "CPU d'oro", nel senso che questa è la CPU a cui viene confrontato tutto il resto. Idealmente, la persona che ha scritto il VHDL NON è la stessa persona che scrive il modello C / C ++.

  3. Scrivi / Crea un sistema in cui è possibile eseguire il modello C / C ++ e il modello VHDL fianco a fianco e confrontare i risultati ciclo per ciclo. Eseguire il programma di assemblaggio dal passaggio 1 e assicurarsi che i due modelli corrispondano.

  4. Esegui i tuoi due modelli su "istruzioni" casuali. Fondamentalmente, riempire "ram" con dati casuali ed eseguire quei dati casuali come se fossero vere istruzioni. Esegui gli stessi dati casuali su entrambi i modelli VHDL e C / C ++ e confronta i risultati. Questo modello C / C ++ verrebbe eseguito su alcune workstation e / o server (non sulla nuova CPU stessa).

  5. Configurare una macchina o più macchine per ripetere il passaggio 4 essenzialmente per sempre. Anche se la tua CPU è "finita" ed è in produzione da almeno un anno, eseguirai comunque questo test.

  6. Ripeti questi passaggi ogni volta che ci sono più cose da simulare. Ad esempio, lo avresti eseguito sul VHDL post-route con i tempi quando è disponibile.

Non vi è alcuna garanzia che il confronto tra le versioni VHDL e C / C ++ rileverà ogni singolo bug, ma in realtà non esiste un modo migliore. E testare la CPU su istruzioni casuali richiede tempo, ma è anche molto utile. L'unica vera alternativa a questo è assumere un sacco di gente per scrivere semplicemente codice tutto il giorno per testare diverse parti della CPU - e le aziende più grandi lo fanno, ma fanno anche roba di dati casuali.

Per una sola persona che scrive codice VHDL, di solito è solo il passaggio 1 a essere fatto. Ma se hai intenzione di vendere la CPU, almeno alcuni degli altri passaggi dovrebbero essere fatti (e davvero, dovresti farli tutti).


Ottima risposta, grazie! Questo ha molto senso. La "CPU d'oro" è in effetti il ​​pezzo mancante del puzzle che ti consente di effettuare una verifica ciclo per ciclo durante i test. Dal momento che questo è principalmente un progetto giocattolo, penso che mi conformerò alla prima frase dell'ultimo paragrafo e farò solo il primo passo. Ma sapendo quello che dovrebbe essere fare è inestimabile.
drxzcl,

Puoi anche avere un modello C ++ dorato, ma non accurato per il ciclo, che gli consente di essere molto più semplice e quindi più probabile che sia corretto, utile per testare ad esempio la funzionalità ALU ("2 + 2 = 4 e alcuni flag, I non importa quando "anziché" 2 + 2 = 4 dopo un segno di spunta e le bandiere dopo 2 segni di spunta ")
Martin Thompson,

Inoltre, esegui la copertura del codice (per verificare che tu abbia esercitato tutto) e la copertura del test (per verificare che tutti i test siano stati testati sia per il pas che per il fallimento)
Martin Thompson,

Follow-up: usando la procedura "passo uno", sono riuscito a trovare molti guasti ... nel mio assemblatore: P Il core stesso sembra essere relativamente ok.
drxzcl,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.