EO_468

46 / 86

EDA/SW/T&M SoC TESTING
46 - ELETTRONICA OGGI 468 - MARZO 2018
essi può rivelarsi un’attività estremamente onerosa in
termini di tempo. La figura 1 mostra un semplice SoC,
equipaggiato con memorie di tipo flash e DDR, una
memoria TCM (Tightly-Coupled Memory), nonché una
UART e un motore DMA, i cui registri vengono acce-
duti tramite un apposito bus per periferiche a bassa
velocità. Sebbene l’obiettivo finale sia di riuscire a ve-
rificare che del codice in esecuzione sul processore
acceda correttamente ai registri delle varie IP, è possi-
bile procedere inizialmente con una verifica basata pu-
ramente su UVM, che consenta di focalizzarsi meglio
sull’oggetto della verifica stessa. Procedendo dappri-
ma a una verifica in UVM del sottosistema di memoria,
sarà infatti possibile acquisire una maggiore confiden-
za, in vista della successiva fase operabile mediante
software effettivamente in esecuzione sul processore
embedded. L’utilizzo del tool per il portable stimulus
Questa inFact di Mentor, consentirà di esprimere e di
riutilizzare più volte un medesimo test intent, indiriz-
zandolo dapprima verso un ambiente UVM e succes-
sivamente verso un ambiente di software embedded,
risparmiando una significativa quantità di tempo nor-
malmente necessario per lo sviluppo dei test.
Utilizzo dei grafi per descrivere i registri
Questa inFact utilizza una descrizione degli input di tipo
dichiarativo, incentrata sull’utilizzo di grafi, che alla po-
tenza della programmazione basata sui vincoli aggiun-
ge la capacità di specificare logiche decisionali espres-
se in maniera iterativa. Come si vedrà, tale possibilità di
esprimere iterativamente le decisioni si rivela di grande
aiuto quando si giunge al momento di dover specificare
i vincoli per l’accesso ai registri.
Nel nostro esempio, si inizierà catturando gli attributi
fondamentali che caratterizzano, nei test, una operazio-
ne di accesso alla memoria: indirizzo, dimensione del
dato, valore da scrivere e maschera di scrittura. La ma-
schera di scrittura specifica quali sono i bit da leggere/
scrivere, e quali vanno invece ignorati per gli scopi del
test corrente. Una actionrappresenta l’unità di compor-
tamento che dovrà essere eseguita all’interno dell’am-
biente target della verifica. Si vedrà più avanti come la
modifica dell’implemen-
tazione del body di tale
azione consentirà di ri-
dirigere in modo sempli-
ce il test intent di questo
accesso ai registri verso
i diversi ambienti relativi
rispettivamente all’UVM
e al software embedded.
Il descrittore di accesso ai registri mostrato in figu-
ra 2 non include ancora alcun dettaglio relativo alle
differenti tipologie di IP presenti nel sistema. Il pas-
saggio successivo consiste dunque nell’aggiunta di
tali restrizioni specifiche. Il motore DMA utilizzato (in
questo caso il Wishbone DMA Core di
possiede un set di registri core, nonché un array di
registri descrittori dei canali. Utilizzando una descri-
zione basata su grafi è possibile descrivere in modo
iterativo gli indirizzi di tutti i registri in questione.
La descrizione grafica sopra riportata illustra il pro-
cesso di selezione dell’indirizzo di un registro DMA:
coreoppure dell’array dei
registri di controllo dei canali (dma_reg).
-
nali.
- Selezione del canale (dma_ch).
- Selezione del registro di canale da indirizzare (dma_
ch_reg).
La figura 4 mostra la descrizione testuale di questo
stesso processo.
Sono inoltre necessarie, naturalmente, delle indica-
zioni più dettagliate per
specificare l’indirizzo
del registro e la ma-
schera di scrittura, le
quali vengono codifi-
cate mediante il vincolo
Fig. 3 – Selezione dell’indirizzo di un registro DMA
Fig. 2 – Struct di base che speci-
fica l’accesso ai registri Fig. 4 – Regole per la selezione
dell’indirizzo di un registro DMA