48 / 86
EDA/SW/T&M
SoC TESTING
48
- ELETTRONICA OGGI 468 - MARZO 2018
rifica a livello di sottosistema. All’interno del nostro
ambiente UVM per la verifica a livello di sottosistema,
il modello RTL del processore è stato sostituito con un
modello BFM (Bus Functional Model), che avrà pura-
mente il compito di accedere ai registri attraverso lo
strato di interconnessione. Il grafo per il testing dei
registri verrà quindi incapsulato all’interno di una
vir
-
tual sequence
UVM, che effettuerà l’accesso ai registri
tramite il BFM.
La virtual se-
quence di que-
sta ‘CPU’ di tipo
minimale con-
sente al model-
lo BFM di acce-
dere ai registri
mediante l’uti-
lizzo delle API
di una apposi-
ta classe, che
supporta ope-
razioni di lettu-
ra e di scrittura con dati di svariate dimensioni. Al codi-
ce è stata aggiunta una specifica sequence ‘memcheck’
che provvede a effettuare scrittura, rilettura e control-
lo all’interno di un task denominato ‘do_memcheck’,
come mostrato in figura 9.
Le informazioni di mappatura necessarie per collegare
il grafo per il test dei registri al task do_memcheck del-
la
virtual sequence
sono
state specificate all’in-
terno di un apposito file
– target.rseg in questo
caso. Tali informazioni
di mappatura sono illu-
strate in figura 10.
Le informazioni di map-
patura specificano:
Che il grafo deve essere incapsulato all’interno di una
classe che estende la classe base
or1k_memcheck_vseq
.
all’interno dell’ambiente UVM deve essere utilizzata la
classe or1k_memcheck_c.
or1k_soc_
regacc
verrà invocata la
action
‘body’, ciò che dovrà
in effetti essere chiamato è il task
do_memcheck
.
Con la semplice aggiunta di queste poche linee di
codice, il grafo per il testing dei registri è ora in gra-
do di essere eseguito all’interno dell’ambiente UVM.
Ciò consente di sottoporre a verifica le funzionalità di
base della connettività con i registri, e di debuggare
qualsiasi sua problematica utilizzando i normali tool di
debugging disponibili per UVM e per SystemVerilog.
Mappatura verso l’ambiente del software embedded
Tuttavia, la conferma che il modello BFM sia in gra-
do di accedere correttamente ai registri di memoria
ovviamente non può garantire in modo definitivo che
anche il processore sarà in grado di farlo. È perciò
importante poter successivamente ri-eseguire tutti i
medesimi test di accesso ai registri anche mediante
software embedded realmente eseguito sul proces-
sore. Nella sua forma più semplice, un tale ambiente
di verifica dell’intero SoC può assumere l’aspetto mo-
strato in figura 11.
In questo caso, verranno quindi prodotti una serie di
test scritti in linguaggio C, contenenti codice che scri-
ve dei valori nei registri e successivamente li rilegge,
utilizzando il processore. Anche questi test, per effet-
tuare le effettive operazioni di scrittura, rilettura e con-
trollo, opereranno tramite una funzione
do_memcheck
.
Il codice di tale funzione è mostrato in figura 12.
Fig. 8 – Ambiente per la verifica a livello di sottosistema
Fig. 11 – Ambiente di verifica Software-Driven
Fig. 9 – Il task UVM do_memcheck
Fig. 10 – Mappatura della
sequence target in UVM