Table of Contents Table of Contents
Previous Page  45 / 86 Next Page
Information
Show Menu
Previous Page 45 / 86 Next Page
Page Background

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