Verifica più rapida dei circuiti integrati di elaborazione del segnale con HDL Verifier

La verifica dei progetti di circuiti integrati (IC) per l'elaborazione del segnale pone diverse sfide particolari che possono mettere a dura prova i metodi di collaudo convenzionali. La complessità algoritmica di filtri, mixer e altre funzioni avanzate di elaborazione del segnale richiede una rigorosa validazione per garantire che il circuito integrato implementato si comporti come previsto con precisione bit-true. Inoltre, poiché i circuiti integrati spesso operano su un'ampia gamma di possibili input e configurazioni, è essenziale valutare i casi limite, ovvero scenari rari ma critici che possono sfuggire ai piani di test incentrati su sequenze predefinite e prevedibili.

Per affrontare queste sfide, il mio team presso NXP ha adottato un nuovo workflow per la verifica dei circuiti integrati. Basato su MATLAB^®, Simulink^® e HDL Verifier™, questo workflow incorpora tecniche di verifica constrained-random e metodologia di verifica universale (UVM) per validare i casi limite ed esplorare lo spazio di stato con input randomizzati mantenendo il controllo attraverso vincoli (Figura 1). In questo workflow, che abbiamo recentemente utilizzato per verificare un circuito integrato di sintonizzazione radio per l'industria automotive, i modelli MATLAB e Simulink vengono esportati come componenti SystemVerilog DPI-C, utilizzando HDL Verifier, e integrati come modelli di riferimento nel banco di prova di verifica per il nostro ambiente di verifica basato su Cadence^® Simulatore Xcelium™. Questo approccio non solo ci ha consentito di ridurre i tempi di verifica del 20-30%, ma ci ha anche consentito di aumentare la copertura dei test e di individuare più difetti di implementazione nelle fasi iniziali dello sviluppo.

Confronto tra vecchi e nuovi workflow

In passato, quando testavamo progetti di circuiti integrati simili, solitamente utilizzavamo MATLAB per generare stimoli di input per il nostro sistema completo. Quindi eseguivamo delle simulazioni in MATLAB o Simulink e raccoglievamo i risultati come modello di riferimento. Una volta completata l'implementazione RTL, applicheremmo gli stessi stimoli al DUT e verificheremmo i suoi risultati confrontandoli con il riferimento golden. Sebbene questo approccio funzionasse, presentava alcuni svantaggi. Inizialmente, la verifica era, per la maggior parte, end-to-end, il che rendeva difficile identificare la causa principale dei difetti, poiché tutti i componenti venivano testati insieme. In secondo luogo, non è stato facile eseguire una verifica casuale vincolata. Di conseguenza, sebbene siano stati verificati scenari e casi d'uso comuni, molti casi limite non lo sono stati. In terzo luogo, non rispettava l'UVM, che nel frattempo è diventato il framework standard per il nostro modo di implementare i testbench.

Al contrario, il nuovo workflow consente il riutilizzo diretto dei nostri modelli di riferimento MATLAB e Simulink esistenti nel nostro ambiente di simulazione HDL (Cadence Xcelium). Ogni componente del modello di riferimento corrisponde alla sua controparte nel DUT. Ad esempio, la catena di elaborazione del segnale mostrata nella Figura 2 include un filtro modellato in Simulink, seguito da un mixer e un secondo filtro modellato in MATLAB. Utilizziamo HDL Verifier per generare il codice C per il modello con il wrapper SystemVerilog DPI-C, consentendoci di integrare ciascun componente nel testbench.

I componenti del modello di riferimento e quelli del DUT vengono eseguiti in parallelo nell'ambiente di simulazione HDL, e i loro output vengono valutati in tempo reale da un checker che funge da scoreboard UVM, eseguendo confronti bit-accurati tra l’output di ciascuna coppia di componenti associati (ad esempio, il mixer del modello di riferimento e quello del DUT) e dell’intera catena end-to-end.

Randomizzazione degli input e visualizzazione dei risultati

Dopo aver eseguito test preliminari— in questo caso con un insieme di stream radio AM, FM e Digital Audio Broadcasting (DAB) predefiniti —sul testbench per verificare la funzionalità di base degli algoritmi di elaborazione del segnale, il passo successivo nel flusso di lavoro è la verifica constrained-random. Questa fase comporta simulazioni approfondite in cui a tutte le impostazioni di configurazione per la progettazione sono stati assegnati valori casuali entro un intervallo vincolato. Ad esempio, variamo le impostazioni del mixer, le impostazioni del filtro, i ritardi, i guadagni e altri parametri di configurazione chiave ed eseguiamo simulazioni per valutare le prestazioni del progetto per ogni set di opzioni di configurazione randomizzate.

Per ciascun test, possiamo esaminare risultati dettagliati, inclusi i parametri specifici utilizzati, gli input usati come stimoli per l’IP, i risultati dell’implementazione del modello di riferimento, i risultati dell’implementazione RTL e l’esito del confronto effettuato dal checker (Figura 3).

Esaminiamo anche i report che mostrano i risultati aggregati per una serie completa di componenti (Figura 4). Questi report mostrano il numero di controlli eseguiti per ciascun componente della catena e il numero di errori, ovvero il numero di discrepanze identificate tra gli output RTL e quelli del modello di riferimento.

Quando viene identificato un errore, controlliamo sia l'implementazione del modello di riferimento in MATLAB o Simulink, sia l'implementazione RTL. In alcuni casi, abbiamo rintracciato la causa della discrepanza nel design di riferimento originale, ma più spesso il problema deriva da un errore nell'implementazione RTL. In entrambi i casi, una volta diagnosticato e corretto il difetto, rieseguiamo le simulazioni di test per verificare che la correzione abbia eliminato completamente tutte le differenze tra il modello di riferimento e l'implementazione RTL.

Miglioramenti chiave e prossimi passi

Uno dei vantaggi evidenti del nostro nuovo flusso di lavoro basato su HDL Verifier è la capacità di identificare rapidamente la fonte dei difetti. Rispetto a un approccio basato esclusivamente su test end-to-end, un approccio orientato alla UVM che consente sia test a livello di componente sia a livello di sistema—come quello che abbiamo adottato—rende molto più semplice individuare il sottosistema affetto dal difetto, così come gli stimoli specifici per quel componente che possono essere utilizzati per replicare il difetto.

Inoltre, poiché le impostazioni randomizzate spesso mettono alla prova il sistema in modi che i progettisti potrebbero non aver previsto, il nuovo workflow facilita l’individuazione dei difetti di implementazione molto prima nel processo di sviluppo, rispetto ai piani di test convenzionali focalizzati su casi d’uso ben definiti. In breve, possiamo trovare difetti senza effettuare controlli manuali e senza perdere tempo a considerare scenari insoliti e casi limite da testare.

Siamo in grado di riutilizzare i nostri modelli MATLAB e Simulink esistenti nelle simulazioni HDL e i vantaggi di questo riutilizzo continuano ad aumentare a ogni successiva versione o revisione dei circuiti integrati. Nel complesso, questi vantaggi hanno contribuito alla significativa riduzione dei tempi di verifica, fino al 30%, che abbiamo ottenuto sui circuiti integrati di elaborazione del segnale radio. Sulla base di questa metrica e degli altri vantaggi che abbiamo riscontrato, altri team NXP stanno cercando di adottare lo stesso workflow per lo sviluppo di un front-end radio per un circuito integrato radar e altri progetti di circuiti integrati.