Allegro MicroSystems accelera la verifica ASIC - MATLAB & Simulink

Articoli tecnici

Applicazione della verifica Model-Based nello sviluppo di ASIC per l'automotive

Aswini Tata, Sanjay Chatterjee e Kamel Belhous, Allegro MicroSystems e Surekha Kollepara, Cyient


Poiché le richieste dei clienti diventano sempre più esigenti e i tempi di consegna si riducono, l'approccio di verifica Model-Based che abbiamo adottato sta aiutando i nostri team a fornire algoritmi e sistemi più sofisticati con tempi di immissione sul mercato ridotti.

Nelle aziende di semiconduttori che riforniscono l'industria automotive, ai team di ingegneria viene chiesto di realizzare sistemi sempre più complessi in tempi stretti. Rispettare queste scadenze ravvicinate comporta difficoltà legate ai test in fase avanzata. Ad esempio, attendere che RTL sia disponibile per avviare la verifica funzionale comporta il rischio di sforamenti di costo e ritardi nella consegna. I difetti di progettazione e i problemi relativi ai requisiti individuati in questa fase sono molto più costosi e difficili da risolvere e i team sprecano tempo prezioso nel debug di scenari irrealistici. In questo ambiente, lo shift-left testing, in cui le attività di verifica vengono condotte il più presto possibile nel ciclo di sviluppo, affronta le sfide dei test in fase avanzata.

Alcuni membri del nostro team presso Allegro MicroSystems hanno adottato un nuovo approccio shift-left utilizzando la progettazione Model-Based per blocchi DSP che incorpora la generazione di codice HDL per ASIC a segnale misto, nonché la generazione di testbench Universal Verification Methodology (UVM) per la verifica a livello RTL. Con questo approccio di verifica Model-Based, beneficiamo della verifica funzionale anticipata in Simulink® e una visione a livello di sistema della progettazione che facilita la collaborazione tra ingegneri di sistema e team di verifica (Figura 1). La verifica precoce del modello porta a un HDL di migliore qualità, poiché i problemi di progettazione e i requisiti di alto livello vengono individuati ed eliminati prima della generazione del codice. Ci aspettiamo che questa individuazione precoce dei bug faccia risparmiare due mesi di verifiche. Ulteriori vantaggi derivano dai rigorosi test dell'implementazione HDL nel nostro ambiente UVM e dal riutilizzo di modelli e risorse di test in tutti i progetti.

Un workflow dell'approccio di verifica shift-left, che mostra una vista a livello di sistema in cui gli ingegneri di sistema e i team di verifica collaborano per rilevare ed eliminare i bug.

Figura 1. Verifica Model-Based per test shift-left presso Allegro MicroSystems.

Dai requisiti alle specifiche eseguibili all'implementazione

In un workflow di sviluppo tradizionale, l'ingegnere di sistema crea requisiti basati su testo che vengono utilizzati dal team di progettazione digitale (architetti di sistema e ingegneri RTL) per produrre le specifiche e, da queste, la progettazione RTL. Il nostro gruppo, il team di verifica digitale, sarebbe quindi responsabile della creazione di un piano di test basato sulle specifiche e sulla verifica funzionale per garantire che la progettazione RTL sia conforme alle specifiche. In questo workflow, quando viene rilevato un difetto, solitamente in una fase avanzata del ciclo di sviluppo, può volerci molto tempo per determinare se la causa principale del difetto risiede nell'implementazione, nelle specifiche o nei requisiti originali.

Con il nostro approccio attuale, il workflow è progettato per consentire la verifica dell'architettura e dei requisiti molto prima. Una volta definiti i requisiti in Jama Connect® dall'ingegnere di sistema, il team di progettazione digitale crea un modello di specifica dell'architettura in Simulink. Questo modello funge da specifica eseguibile del sistema. Eseguendo simulazioni con questo modello, il team esegue test unitari e di integrazione model-in-the-loop per validare i requisiti e verificare l'architettura (Figura 2). Nel nostro primo progetto che ha utilizzato questo approccio, queste simulazioni ci hanno aiutato a identificare diversi problemi, tra cui uno scenario in cui le istruzioni condizionali si contraddicevano tra loro, determinando un output non valido per alcune combinazioni di stimoli di input.

Un workflow che mostra i passaggi per la verifica del modello in Simulink e HDL Coder, inclusi vari artefatti di sviluppo, come la specifica dei requisiti e attività di sviluppo, tra cui lo sviluppo e la modellazione dell'architettura.

Figura 2. Un workflow che mostra gli artefatti e le attività di sviluppo per la verifica sia nella progettazione Simulink che nel codice HDL.

Nella fase successiva dello sviluppo, il team traduce il modello di architettura in un modello di implementazione più “hardware-friendly” in preparazione per la generazione del codice con HDL Coder™. Ciò può includere, ad esempio, la conversione di algoritmi da virgola mobile a virgola fissa, oppure il passaggio dall'elaborazione basata sui frame allo streaming.

Modelli di testbench e verifica in Simulink

Mentre il team di progettazione digitale sviluppa i componenti nel modello di implementazione, parallelamente vengono sviluppati modelli di testbench Simulink per tali componenti. Ogni modello di testbench Simulink contiene i seguenti sottosistemi corrispondenti ai componenti UVM: sequenza, driver, DUT, predittore, monitor e scoreboard (Figura 3). Per la generazione del testbench con HDL Verifier™ sono necessari solo i sottosistemi sequenza, DUT e scoreboard.

La struttura del modello generale per i testbench UVM, inclusi sequenza dei componenti, driver, DUT, predittore, monitor e scoreboard, è illustrata sopra un'implementazione Simulink di un testbench per testare un algoritmo CORDIC.

Figura 3. Struttura del modello generale per banchi di prova UVM (sopra) e un'implementazione Simulink di un banco di prova per testare un algoritmo CORDIC (Coordinate Rotation Digital Computer) (sotto).

Il sottosistema sequenza genera stimoli per il dispositivo in prova, oppure il sottosistema DUT sottosistema, che in questo workflow è il modello di implementazione creato in Simulink. Questo sottosistema crea e randomizza gli stimoli utilizzando codice MATLAB® e blocchi Simulink , incluso il blocco Test Sequence. Il suo input seed viene utilizzato per inizializzare il generatore di numeri casuali MATLAB . Il sottosistema scoreboard raccoglie l'output del DUT e lo confronta con l'output previsto tramite blocchi Assertion for DPI-C, che vengono utilizzati per generare componenti DPI-C contenenti asserzioni SystemVerilog (Figura 4). (L'interfaccia di programmazione diretta SystemVerilog [DPI] è un'interfaccia tra SystemVerilog e un linguaggio di programmazione esterno come C. HDL Verifier può generare componenti DPI-C costituiti da codice C con codice wrapper SystemVerilog; i componenti DPI-C risultanti possono quindi essere eseguiti dai simulatori HDL che supportano SystemVerilog.)

Workflow di un'asserzione SystemVerilog utilizzata per verificare che il segnale di input sia inferiore a un limite superiore specificato a ogni passo temporale.

Figura 4. Controllo di asserzione utilizzato per verificare che il segnale di input sia inferiore a un limite superiore specificato a ogni intervallo di tempo.

L'esecuzione di simulazioni in Simulink con il modello di testbench insieme a vari strumenti di verifica e validazione del modello, come Simulink Test™, valida ulteriormente il modello di implementazione rispetto ai requisiti. Estraiamo i risultati di queste simulazioni da Simulink in Jama per facilitare i test basati sui requisiti. Inoltre, Simulink Design Verifier™ può essere utilizzato per identificare la logica del codice morto nella modalità.

Generazione di codice, generazione di testbench e simulazione e test HDL

Una volta che il modello di implementazione e i modelli di testbench sono stati creati e utilizzati per completare la fase di verifica della progettazione del workflow in Simulink, iniziamo la fase successiva: Generazione e verifica del codice HDL. In questa fase utilizziamo HDL Coder per generare codice HDL sintetizzabile dai componenti del modello di implementazione. Utilizziamo anche HDL Verifier, in particolare la funzione uvmbuild dal componente add-on ASIC Testbench: per generare testbench UVM completi dai modelli di testbench Simulink (Figura 5). (Un'altra funzione inclusa in ASIC Testbench, dpigen, genera componenti DPI-C da codice MATLAB o modelli Simulink per i team di progettazione che non utilizzano ambienti UVM.)

Uno screenshot di HDL Coder che mostra il codice generato dalla scoreboard del testbench UVM.

Figura 5. Codice della scoreboard del testbench UVM generato.

Utilizzando il testbench generato, eseguiamo quindi test nel nostro ambiente UVM, rispetto al codice generato dal modello di implementazione, utilizzando un simulatore digitale, come simulatori Cadence® Xcelium™ (Figura 6). Ampliamo il testbench UVM generato secondo necessità per aggiungere randomizzazioni vincolate più complesse, verificatori di asserzioni e gruppi di copertura SystemVerilog per l'analisi della copertura funzionale. Quando un test fallisce nell'ambiente UVM, utilizziamo la configurazione seed e di memoria del test fallito per riprodurre le condizioni di errore in una simulazione Simulink, il che semplifica notevolmente per l'ingegnere progettista il debug e la correzione dell'errore, rispetto al debug diretto a livello HDL.

Workflow che mostra l'ambiente di testbench UVM integrato in un ambiente di test Simulink.

Figura 6. Generazione, integrazione e utilizzo del testbench UVM.

Passaggi successivi

Poiché le richieste dei clienti diventano sempre più esigenti e i tempi di consegna si riducono, l'approccio di verifica Model-Based che abbiamo adottato sta aiutando i nostri team a fornire algoritmi e sistemi più sofisticati con tempi di immissione sul mercato ridotti. Stiamo pianificando di estendere questo concetto di shift-left ad altri progetti, in cui prevediamo che il riutilizzo dei modelli e degli ambienti di test Simulink associati da parte del team di verifica consentirà di risparmiare altri due mesi di sforzi di sviluppo su progetti di media complessità presso Allegro. In futuro, stiamo anche valutando le opportunità per i nostri team di ingegneria dei sistemi e per i nostri clienti di riutilizzare i modelli.

Pubblicato nel 2024

Visualizza articoli per funzionalità correlate

Visualizza articoli per settori correlati