EDA/SW/T&M
SoC TESTING
45
- ELETTRONICA OGGI 468 - MARZO 2018
“Portable stimulus”: come
agevolare la transizione
verso una verifica
software-driven
Matthew Ballance
I
progetti diventano ogni giorno più complessi, e
sempre più spesso includono al proprio interno
anche un processore – frequentemente anche più
di uno. Poiché il processore stesso è parte integrante
del progetto, è importante sottoporre a verifica anche
le interazioni esistenti tra il software che verrà ese-
guito sul processore e il resto del progetto. Sarebbe
inoltre del tutto irragionevole posticipare la verifica e
la validazione di tale “area di confine” tra hardware e
software fino alla disponibilità di un prototipo funzio-
nante in laboratorio, data la criticità del software per
l’operatività dei sistemi odierni. O quantomeno, i team
addetti alla verifica siano consapevoli che lo farebbe-
ro a proprio rischio e pericolo. Abbiamo sicuramente
tutti sentito racconti di esperienze da incubo in cui, ad
esempio, un team si è reso conto solo sui primi proto-
tipi in laboratorio che il bus del processore era stato
collegato al resto del progetto in ordine inverso, oppu-
re che il processore non riusciva a risvegliarsi dallo
stato di low-power.
Miglioramento HW/SW passo-passo
Una soluzione ovvia, naturalmente, consiste nell’effet-
tuare una maggiore quantità di verifiche relative all’a-
rea della frontiera hardware/software già nel corso
del tradizionale processo di verifica. Tuttavia, non si
può neppure pensare che sia semplicemente possibile
saltare a piè pari da una classica verifica, puramente
orientata all’hardware, al tentativo di verificare l’e-
secuzione di uno stack applicativo completo. Data la
complessità e le dimensioni dei voluminosi log di de-
bug che si ottengono tentando di eseguire una grande
quantità di software, l’impresa di individuare dei bug,
anche i più semplici, diventa talmente complicata da
essere ingestibile. Un approccio più produttivo consi-
ste invece nel verificare tutto ciò che si riesce all’inter-
no di un ambiente di verifica il più semplice possibile,
purché esso sia ragionevolmente in grado di sollecita-
re la funzionalità target, assicurare la massima visibi-
lità, e contenere la minima quantità di attività estranea
al
test intent
.
Questo articolo si baserà sulla descrizione di un sem-
plice esempio, relativo alla verifica dell’accesso a vari
registri di un SoC. La verifica che gli svariati registri
collegati a una specifica IP possano essere corretta-
mente letti e scritti da parte del processore costituisce
un’attività chiave di qualsiasi processo di verifica di
integrazione. Perfino i SoC più semplici contengono
infatti centinaia di registri, e la creazione dei test ne-
cessari per verificare che il processore riesca ad ac-
cedere correttamente in lettura e scrittura a ognuno di
Chiunque si appresti a pianificare le attività per il testing di
integrazione di un SoC dovrebbe attentamente considerare
quanti vantaggi per il proprio processo di verifica potrebbero
derivare dall’utilizzo delle tecniche di “portable stimulus”,
unite a un approccio di testing progressivo
Fig. 1 – Un semplice sistema SoC