59 / 86
EDA/SW/T&M
VERIFICATION IP
59
- ELETTRONICA OGGI 455 - GIUGNO/LUGLIO 2016
lo per arrivare all’RTL. Sempre per
quanto riguarda le tecniche, la mag-
gior parte dei progetti prevede l’uso
di una combinazione di blocchi RTL
portati nel design da sorgenti ester-
ne – IP sia di terze parti sia svilup-
pate da gruppi interni specializzati
– e di blocchi RTL creati dal team di
progettazione. Ovviamente, una buo-
na dose di verifica può essere effet-
tuata anche su blocchi IP. Se i bloc-
chi rappresentano delle interfacce
esterne come USB o DDRX, di soli-
to sono disponibili delle soluzioni
IP di verifica (VIP) che permettano
di valutare se il blocco implementa
correttamente il protocollo. I blocchi
creati internamente raramente sono dotati di vere funzioni
VIP. In tale contesto, il progettista crea il blocco, mentre gli in-
gegneri specializzati effettuano la verifica. Lo strumento prin-
cipale in questo caso è la simulazione RTL.
Quando l’RTL si rende disponibile, la prototipazione virtuale
diventa un mezzo ideale per validare le interfacce hardwa-
re/software di sistema, per facilitare lo sviluppo anticipato
del software, per validare in forma continuativa l’integrazio-
ne hardware/software e per accelerare il debug hardware/
software.
Una soluzione complementare alla simulazione è l’approccio
formale, che sta diventando sempre più importante nel ciclo
di verifica. Questo è in parte dovuto al fatto che la tecnolo-
gia formale è ormai abbastanza semplice da utilizzare e non
richiede più una preparazione a livello di dottorato. I motori
di verifica formale sono migliorati sostanzialmente in termini
di potenza e prestazioni. Inoltre, alcuni blocchi sono parti-
colarmente indicati per le tecniche formali. Ad esempio, in
presenza di blocchi che gestiscono la sicurezza delle chiavi
di crittografia è veramente importante avere le certezze ga-
rantite da una verifica formale invece di affidarsi a tecniche
che indicano una “copertura apparentemente valida” (che è
il meglio che una simulazione possa offrire).
Test del SoC in un ambiente reale
Man mano che il progetto progredisce, la verifica deve evol-
vere verso un approccio basato sul software, dove lo stack
di codice che verrà eseguito sul sistema viene utilizzato con-
temporaneamente per testare il software e per verificare che
l’hardware operi correttamente. Ciò richiede l’emulazione,
poiché la simulazione è troppo lenta per avviare un sistema
operativo, per quanto ridotto possa essere (senza conside-
rare colossi come Linux o Android). L’accesso ai dispositivi
virtualizzati offre l’opportunità di testare il SoC nel suo am-
biente, scrivendo e leggendo i dati da e verso il mondo reale.
Un altro approccio, che in assoluto offre le migliori presta-
zioni ma che è ancora abbastanza difficile da usare, è la
prototipazione FPGA. Questo metodo permette di creare un
dispositivo il più vicino possibile al SoC senza dovere effet-
tuare il tape out del chip, attività che ovviamente di solito
non rientra nel processo di progettazione. Ciò consente di
eseguire il software facendo girare il sistema con prestazioni
le più vicine possibili a quelle reali.
Superare il collo di bottiglia del debug
Tutte queste tecnologie di verifica devono portare ai risultati
previsti; in caso contrario è evidente la presenza di un’ano-
malia. Nel secondo caso, l’ingegnere di verifica deve analiz-
zare i dettagli per capire cosa sia successo. Questa processo
è denominato debug della verifica.
Il debug è diventato uno degli aspetti della verifica più one-
rosi in termini di tempo. Utilizzando le tecniche di analisi ro-
ot-cause manuali, non è raro che i team di verifica investano
più del 50% del loro tempo nel debug. E, più grande è il SoC,
più difficile diventa questo processo. Tuttavia, le tecnologie
che consentono di eseguire il debug del software embed-
ded in esecuzione su processori implementati come RTL, ed
eseguiti in simulazione o in emulazione, possono aiutare a
superare il collo di bottiglia del debug.
Man mano che i SoC diventano più grandi e complessi, l’ap-
proccio olistico alla verifica, comprendente una serie diver-
sificata di motori, garantisce la strategia più efficace. I tempi
in cui la verifica coinvolgeva semplicemente la simulazione
RTL sono ormai un ricordo. Oggi, per realizzare un progetto
ottimizzato, è necessario un intero portafoglio di tecnologie
di verifica.
Fig. 2 – Verificare un progetto richiede oggi una vasta gamma di tecniche che coprono tutti gli
aspetti del SoC