Sia che stiate progettando dei blocchi di proprietà intellettuale o dei System on chip, l’analisi degli errori rappresenta tradizionalmente un'operazione manuale che richiede molto tempo. Oggi, la maggior parte dei tecnici utilizza un'analisi post-simulazione delle forme d'onda abbinata all'analisi dei messaggi presenti nei file di log. Dal momento che questa metodologia implica il fatto che l'ingegnere sappia a priori dove aggiungere le istruzioni per il salvataggio dei messaggi e quali segnali tenere sotto controllo, essa espone all'esecuzione di ulteriori iterazioni per l’analisi degli errori qualora le informazioni necessarie non fossero presenti alla fine del ciclo. I progetti di nuova generazione, essendo più complessi e sempre più di maggiori dimensioni, stanno costringendo gli ingegneri a investire, in media, il 50% del loro impegno complessivo nella verifica degli errori, operazione che comprende la classificazione delle anomalie e l'analisi dei risultati di simulazione. Le metodologie di analisi non sono state in grado, fino ad ora, di tenere il passo con questa evoluzione e la maggior parte ingegneri impegnati nelle verifiche sta ancora utilizzando lo stesso processo tradizionale da più di 20 anni. In questo articolo, vedremo come una nuova metodologia basata sull'analisi automatizzata Rca (Root Cause Analysis) e sulla cattura di una ampia quantità di dati può aiutare ad identificare gli errori in tempi ridotti fino al 50% rispetto ai metodi tradizionali.
L’analisi degli errori
Quando parliamo di misurazione delle prestazioni per l’analisi degli errori, dobbiamo prendere in considerazione un approccio olistico che coinvolge: cicli del motore di verifica (rendimento di simulazione su un determinato server) e cicli ingegneristici ( quantità di tempo che un ingegnere investe nell'analisi degli errori al fine di isolare gli stessi). Man mano che la complessità dei progetti aumenta, le prestazioni del motore di verifica diventano un contributo sempre più marginale nell'equazione complessiva relativa alle prestazioni per l’analisi degli errori. Le simulazioni possono essere eseguite in background rispetto ad altre attività che un ingegnere svolge quotidianamente. L'analisi, invece, richiede la completa attenzione e, di conseguenza, sta diventando sempre più il collo di bottiglia che impedisce di aumentare le prestazioni di analisi. L'obiettivo numero uno per aumentare le prestazioni di analisi è di utilizzare i cicli ingegneristici nel modo più efficiente possibile.
L'analisi root-cause oggi
Con l'attuale metodologia Rca, l'ingegnere lancia una simulazione rilevando un'uscita errata attraverso dei testbench. Potenzialmente, la fonte del problema potrebbe essere identificata utilizzando le tecniche di analisi oggi disponibili, come ed esempio: dichiarazioni Print; tracciamento dei segnali; breakpoint/esecuzione passo-passo. Quando utilizza queste tecniche, l'ingegnere è costretto ad effettuare nuovamente la simulazione dopo aver modificato il progetto, scoprendo spesso che deve aggiungere altre dichiarazioni print oppure che, forse, ha tralasciato di salvare tutti i segnali rilevanti. Tutto ciò comporta ulteriori cicli di simulazione. Questo ciclo di iterazioni può essere ripetuto più volte, fino a quando l'ingegnere riesce ad avere informazioni sufficienti per individuare l’errore. In condizioni normali, ogni iterazione di simulazione può durare da pochi minuti a molte ore. Per illustrare questo scenario, si consideri questo esempio: cosa succede se abbiamo un pacchetto che contiene un numero intero per il codice di sicurezza e un generatore del codice di sicurezza con un numero intero (S1)? Il codice di sicurezza effettivamente utilizzato è di 16 bit. Se in S1 iniettiamo valori casuali può capitare di ottenere alcuni di essi con i bit più significativi ad 1 che provocano un fallimento sull'uscita. Di conseguenza si analizza S1 e si impostano i vincoli per evitare la generazione di valori errati. Tuttavia con questa analisi non possiamo riconoscere che il problema di base è che il campo di sicurezza deve essere di 16 bit, in modo da evitare simili errori che possono manifestarsi in S2, S3, S4. Se non abbiamo dei test "sporchi" per S2, S3, S4 non potremo mai trovare il problema di base.
Cattura e analisi Big Data
Il termine Big Data si riferisce generalmente a una raccolta passiva di un insieme completo di dati che permette di effettuare potenti e dettagliate analisi ad un costo molto basso. Questo approccio è in contrasto con il metodo tradizionale basato sul campionamento, che concentra l'analisi su un piccolo insieme di dati attentamente selezionati e strettamente vincolati. L'approccio basato sul campionamento richiede una valutazione preliminare e offre possibilità di analisi limitate. Per contro, un approccio Big Data, benché in molti casi basato su dati grezzi, richiede poco sforzo preliminare e offre molte più opportunità di analisi avanzate successivamente alla raccolta dei dati stessi. L'approccio Big Data permette di effettuare in una volta sola l’analisi di tutto l'insieme di dati (messaggi, forme d'onda, ordine di esecuzione del sorgente, stack delle chiamate, thread attivi, ecc.), consentendo agli ingegneri (e agli strumenti di analisi) di analizzare e riprodurre la simulazione più è più volte. Gli ingegneri possono quindi: approfondire l'analisi di quello che è realmente accaduto durante il ciclo di simulazione; evidenziare le casualità; potenzialmente individuare le correlazioni che con un metodo basato sul campionamento passerebbero inosservate. Inoltre, gli approcci tradizionali - basati su file di log e forme d'onda - costringono spesso l'ingegnere ad effettuare innumerevoli passaggi per l’analisi dei file di log e delle forma d'onda. Se non vi sono abbastanza informazioni disponibili, l'ingegnere può anche essere costretto a modificare il codice sorgente aggiungendo delle dichiarazioni di print, lanciare una nuova simulazione e analizzare nuovamente i risultati. È facile immaginare il risparmio di tempo che può essere ottenuto avendo a disposizione una serie completa di informazioni memorizzate ed effettuare l'analisi con un'interfaccia grafica singola. Invece di dover affrontare cambi di contesto permette di passare in modo trasparente dagli aspetti di analisi correlati al testbench a quelli legati all'Rtl, sfruttando i dati memorizzati per ciascun dominio. Grazie a questo approccio, è potenzialmente possibile individuare gli errori in pochi minuti, anziché ore o addirittura giorni. Diminuendo il numero di iterazioni per l’analisi si può anche sfruttare al meglio le licenze di simulazione disponibili. Invece di lanciare più iterazioni per l’analisi degli errori, è infatti possibile utilizzare le licenze per individuare ulteriori errori attraverso regressioni incrementali.
Piattaforma unificata e integrata per individuare gli errori all’origine
La nuova piattaforma di analisi degli errori Indago proposta da Cadence è stata sviluppata sulla base di una tecnologia Rca automatizzata e brevettata e di tecniche di cattura Big Data. Rispetto ai metodi di analisi tradizionali, che operano a livello di segnale o di transazione, essa aumenta il livello di astrazione arrivando a ridurre del 50% il tempo necessario per identificare gli errori. La piattaforma supporta attività di analisi per le proprietà intellettuali sino a sistemi integrati come i SoC. La soluzione supporta motori di verifica di Cadence e di terze parti, offrendo un'unica e coerente piattaforma di analisi per Rtl, testbench, IP di verifica e hardware/software. Essendo una piattaforma unificata e sincronizzata, i tempi di apprendimento sono ridotti al minimo permettendo il rapido passaggio dell’analisi degli errori da un contesto all’altro. La piattaforma viene fornita con tre applicazioni integrate:
- Indago Debug Analyzer App, che estende la possibilità di effettuare Rca su testbench e (Ieee1647), SystemC (Ieee1666) e SystemVerilog (Ieee1800) e fornisce funzionalità interattive di post-simulazione.
- Indago Embedded Software Debug App, che sincronizza il debug dei codici sorgenti hardware e software per individuare gli errori associati alle applicazioni embedded. Questa applicazione è ottimizzata per la piattaforma di simulazione Cadence Incisive e per la piattaforma di emulazione Cadence Palladium XP.
- Indago Protocol Debug App, che offre un’intuitiva analisi degli errori utilizzando le IP di verifica Cadence Verification IP per i protocolli avanzati quali Ddr4, Arm Amba Axi, e Arm Amba Ace.
Potenti algoritmi
La maggior parte degli ingegneri rileverà come il modo più naturale per effettuare il l’analisi di un problema sia quello di partire dal punto dove si manifesta l'anomalia e lavorare a ritroso. Ad esempio, quando si effettua l’analisi delle cause di transizione di un segnale Rtl per un valore particolare, gli sviluppatori tracciano a ritroso nel tempo e nello spazio le sorgenti dei segnali, cercando di trovare la prima occorrenza della condizione che ha portato a tale valore. A differenza della maggior parte di soluzioni di analisi, che limitano l'Rca all'Rtl, la Debug Platform Indago applica l'Rca sia all'Rtl che al testbench, in modo da poter effettuare l’analisi di un'anomalia che ha origine nel testbench SystemVerilog o e altrettanto facilmente come se si trattasse di un'anomalia a livello Rtl. Ad esempio, se si manifesta un messaggio di errore Uvm durante la simulazione, ci si potrebbe chiedere quali condizioni lo hanno generato o perché le variabili all'interno del messaggio hanno assunto determinati valori. Attraverso la cattura e l'analisi dei Big Data, la piattaforma di debug Indago utilizza dei potenti algoritmi per evidenziare ogni punto di analisi durante la navigazione attraverso il codice del Testbench o Rtl. Ad ogni punto, la piattaforma identifica le relazioni causali per le domande più tipiche di analisi, che vengono presentate attraverso un'intuitiva interfaccia grafica Rca. Utilizzando il componente Rca, è possibile seguire intuitivamente il percorso che porta allo scenario completo dell'anomalia, identificando rapidamente la causa della stessa senza costringere l'ingegnere ad un’analisi dettagliata del codice RTL o del Tesbench. Ogni decisione di analisi presa nel componente Rca viene salvata in un albero di ricerca, in modo da consentire di tornare sui propri passi in qualunque momento. Poiché la piattaforma di debug Indago registra l'ordine di esecuzione completo del codice sorgente, è possibile esaminare, in ogni punto del processo Rca, lo stack delle chiamate, i thread attivi e i valori delle variabili locali, così come è possibile procedere passo-passo in avanti o indietro per riprodurre il risultato della simulazione. Gli strumenti Rca della piattaforma possono aiutare a capire meglio lo scenario completo dell'anomalia e a diagnosticare l’errore molto più rapidamente rispetto agli approcci tradizionali. Una volta individuate le cause degli errori è possibile modificare il progetto e rieseguire l'iterazione di verifica solo una volta.
