EO_494

PUBBLIREDAZIONALE NXP SEMICONDUCTORS - SIEMENS EDA L e complesse architetture di reset presenti nei mo- derni SoC per il settore automobilistico richiedono una specifica metodologia di verifica, per l’iden- tificazione dei bug critici legati ai fenomeni di RDC (Re- set Domain Crossing). Se propagati fino al silicio, infatti, questi bug possono portare a costosi respin del progetto, nonché ad uno spreco di ore-uomo delle preziose risorse ingegneristiche. Purtroppo, l’identifi- cazione di questi bug non è possibi- le mediante l’utilizzo dei tradizionali strumenti STA o CDC per la verifica dei progetti. Per ottenere una risolu- zione pulita dei problemi di RDC è sta- to quindi messo a punto un flusso di tipo sistematico, composto di quattro passaggi, eseguibile utilizzando stru- menti standard per la verifica RDC (nel caso analizzato, il tool Questa RDC prodotto da Siemens EDA). Sie- mens EDA ha pubblicato un apposito whitepaper dedicato, Systematic Me- thodology to Solve Reset Challenges in Automotive SoCs, che descrive la procedura in ogni dettaglio, insieme ai risultati della sua applicazione al progetto di un SoC automobilistico molto complesso, contenente oltre 1,7 milioni di registri e 4 RAM. Nel presente testo viene presentato un succinto riepilogo dei quattro passaggi della metodologia. 1. Censimento dei segnali di reset noti presenti nel pro- getto. Questo è un passaggio preliminare che consente di calibrare l’identificazione delle sorgenti dei segnali di reset, sia sincroni che asincroni, mediante l’uso dello strumento di verifica RDC. Questa attività aiuta a stabilire una correlazione ottimistica tra sorgenti di reset localiz- zate e sorgenti di reset di tipo primario, il che consente di ridurre il rumore inevitabilmente presente nei risultati. 2. Verifica della struttura ad albero dei segnali di re- set. La verifica di tipo strutturale dell’architettura di re- set, condotta mediante uno strumento di verifica RDC, produce un modello digitale dell’architettura stessa. Tale modello identifica tutti i segnali di reset localizzati e non specificati presenti nel progetto, sulla base dei template RTL della codifica dei reset, sia sincroni che asincroni. La generazione di un albero dettagliato dei reset con- sente l’esecuzione di controlli strutturali dell’architettura di reset, consentendo una tempestiva identificazione di eventuali problematiche già nelle fasi iniziali della pro- gettazione, ancor prima dell’analisi RDC. 3. Mappatura dell’intento progettuale nell’albero dei reset. Questo passaggio comporta l’identificazione del- le relazioni asincrone tra le diverse sorgenti dei segnali di reset. L’idea di fondo è che i segnali di reset pro- venienti da una stessa sorgente ven- gano asseriti contemporaneamente e non possano portare a metastabilità del progetto. Nei SoC per impieghi in campo automobilistico esistono hard reset di tipo globale, come un reset PoR, e altri reset più profondi e localizzati, di tipo più specifico. L’as- serzione di un reset del primo tipo tipicamente conduce all’asserzione di uno o più reset del secondo tipo; il contrario, invece, può non essere sempre vero. 4. Verifica dei domini dei reset. Il passaggio finale consiste nell’anali- si dei percorsi di RDC. Il progettista deve verificare se i percorsi dei dati che attraversano diversi domini di reset possono comportare dei rischi di metastabilità del sistema, ed in tal caso porre in essere tutte le opportune strategie di mitigazione, al fine di evita- re ogni possibile bug di RDC. Conclusioni Le sfide poste dalla verifica dei problemi di reset sono difficili da fronteggiare, utilizzando solo le tecniche di ve- rifica convenzionali. Questa nuova metodologia può of- frire un significativo sostegno ai progettisti, aiutandoli a velocizzare il processo per la verifica di RDC. NXP Semiconductors - Siemens EDA Come risolvere, con un procedimento in quattro fasi, i casi di corruzione dei dati per attraversamento dei domini di reset nei SoC per il settore automotive Diagramma di flusso della metodologia per la verifica RDC di Ankush Sethi and Aniruddha Gupta, NXP Semiconductors; Kurt Takara, Siemens Digital Industries Software 35 - ELETTRONICA OGGI 494 - MAGGIO 2021