Tendenze nella verifica

La verifica, soprattutto nel contesto del software, è da molto tempo una delle principali aree di crescita dell’Eda, in particolare sotto la spinta di due fattori chiave quali l’emulazione hardware e la prototipazione basata su Fpga. Ciò che è diventato chiaro negli ultimi due anni è la crescente esigenza di specificità applicative nei flussi di sviluppo. Uno dei temi comuni per tutta la gamma di progetti basati su Eda è l’Internet delle Cose. La portata dell’IoT si estende su più domini applicativi e fa sentire i propri effetti su prodotti che vanno dall’elettronica indossabile ai dispositivi mobili, passando attraverso case intelligenti connesse, set-top box e connected-car dotate di assistenza alla guida e collegamenti car-to-car, e arrivando via via all’automazione aziendale declinata su sanità, smart-city e gestione energetica. I clienti sono ormai perfettamente consci che le priorità che guidano gli sviluppi dell’elettronica, e di conseguenza anche quelle che riguardano i tool, sono molto diversificate. In passato, potenza, prestazioni e costi rappresentavano i principali fattori chiave. Nell’era dell’Internet delle Cose si sono aggiunte altre priorità, come sicurezza, connettività e aggiornabilità. Oltre a dover essere considerate e bilanciate, le nuove priorità cambiano radicalmente in funzione dell’applicazione finale. Per esempio, nei progetti relativi ai nodi IoT edge, come i tracker per fitness o i prodotti indossabili, il costo viene per primo, seguito da potenza e connettività. Per dispositivi come questi, che devono essere implementati in grandi volumi e devono essere attivi - cioè accesi - per periodi ragionevoli, anche le considerazioni legate all’energy harvesting giocano un ruolo importante. Al contrario, quando si considerano i sistemi sanitari impiantati - come i defibrillatori - sicurezza e protezione assumono la priorità più alta. In dispositivi come questi, nulla può essere lasciato al caso e la sicurezza deve sempre vincere su tutto il resto. Date le conseguenze a livello chirurgico sul corpo umano, la aggiornabilità è una priorità meno stringente. Al contrario, la durata dell›elettronica è cruciale in quanto permette di evitare un intervento invasivo solo per cambiare una batteria. In altri settori, ad esempio le applicazioni reattive attinenti l’assistenza alla guida avanzata o la robotica, la velocità viene prima di tutto, seguita da connettività e aggiornabilità. Un ritardo di risposta all’allarme di un sistema di assistenza alla guida può mettere a repentaglio la vita umana. Quindi, in questi sistemi, il tempo di reazione rappresenta la considerazione principale. La portata e la distribuzione dell’infrastruttura in cui operano oggetti come le vetture, ad esempio gli impianti semaforici, fanno della aggiornabilità la massima priorità, seguita da sicurezza e costi.

Verifica veloce e intelligente

Per essere in grado di affrontare le specifiche esigenze applicative indicate sopra, i processi di verifica e sviluppo del software devono essere molto flessibili. I team di progettazione devono poter scegliere il miglior “engine” di sviluppo per l’attività individuale in corso, senza dover ripartire da zero passando da un motore all’altro. Di conseguenza, le tendenze 2017 possono essere suddivise in due grandi categorie. In primo luogo, miglioramento dei motori di base utilizzati per la verifica (verifica formale, simulazione, emulazione e prototipazione basata su Fpga), che continueranno a richiedere livelli superiori di velocità, capacità e utilizzo delle risorse. In secondo luogo, ricorso a una verifica più intelligente e in grado di sfruttare meglio i motori di base, migliorando la capacità di scegliere a chi e a quale combinazione di motori assegnare l’attività. A partire dai motori di base, nel 2017 la simulazione parallela vivrà una grande diffusione. In tal senso, il 2016 è stato un anno di grandi cambiamenti che ha visto l’acquisizione di Rocketick da parte di Cadence. Insieme ai flussi e alle metodologie per la sicurezza automobilistica e alle applicazioni digitali/mixed-signal, la simulazione Rtl parallela diventerà un ingrediente chiave nei progetti di verifica di successo. Nell’area dello sviluppo hardware assistito, la differenziazione per emulazione sarà determinata sempre più dai modelli di utilizzo che abilitano. I modelli di utilizzo dell’emulazione di base, come l’accelerazione di verifica, la verifica a bassa potenza, l’analisi di potenza dinamica e la validazione post-silicio, spesso condizionati da un contenuto software sempre crescente, si estenderanno ulteriormente. Oltre a convalidare i progetti con ambienti hardware reali, anche la virtualizzazione giocherà un ruolo chiave, con sempre più connessioni e componenti di I/O virtuali. La competizione sulle prestazioni sottolineerà ancor più chiaramente la differenza tra emulazione basata su processore ed emulazione basata su Fpga, per la quale le prestazioni variano a seconda delle dimensioni del progetto e del grado di debug. Nella prototipazione basata su Fpga, la differenziazione si sposterà negli strati software, assicurando un bring-up più veloce e un debug software più avanzato. La congruenza tra emulazione e prototipazione basata su Fpga, utilizzando una compilazione multi-struttura che permette la mappatura sia nell’emulazione sia nella prototipazione basata su Fpga, aumenterà la produttività degli utenti in modo significativo. La verifica formale, come engine principale non dinamico, diventerà ancora più facile da usare grazie a nuove applicazioni che andranno a sommarsi alle capacità formali di base. Essa si integrerà maggiormente anche con gli engine di verifica dinamica per la verifica dinamica assistita dalla formale.

Integrazione orizzontale

Migliorando le capacità dei quattro engine principali - simulazione, emulazione formale e prototipazione basata su Fpga - l’integrazione guadagnerà ulteriore importanza, rendendo la verifica più intelligente e garantendo un equilibrio ottimale tra di essi. Nel 2017 la differenziazione dei flussi di verifica sarà sempre più determinata da collegamenti intelligenti tra i motori dinamici e nelle tecniche formali. Planning di verifica cross-engine, debug e verifica software-driven - in cui il software diventa il test bench è di uso comune a livello SoC - permetteranno di migliorare ulteriormente il riutilizzo della verifica tra motori e l’ottimizzazione cross-engine. Il maggiore riutilizzo degli ambienti di verifica tra motori, permetterà ai team di progettazione di contare su una maggiore flessibilità e su nuove opportunità per scegliere il miglior motore di base per l’attività in corso, un aspetto cruciale legato a tutte le diverse priorità determinate dagli sviluppi applicativi specifici. Oltre a poter usufruire di una maggiore integrazione orizzontale tra i engine di verifica, i team di progettazione avranno l’opportunità di poter prendere decisioni più intelligenti sul livello di astrazione da utilizzare. Questo, grazie all’integrazione verticale tra livelli di astrazione. Ad esempio, per l’analisi dinamica di bassa potenza, i dati relativi all’attività creati dall’esecuzione Rtl in emulazione possono essere collegati a informazioni di potenza estratte dal file di tecnologia .lib utilizzando rappresentazioni a livello di gate o stime della potenza da Rtl. Ciò consente ai progettisti di valutare il consumo energetico basato sull’hardware nel contesto del software: di conseguenza i flussi diventano più prevedibili, con informazioni d’implementazione annotate più precocemente nella verifica pre-Rtl e Rtl durante il flusso di sviluppo.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome