EO_468

EDA/SW/T&M

SoC TESTING

- ELETTRONICA OGGI 468 - MARZO 2018

Proprio come fatto per l’ambiente UVM, sarà necessa-

rio specificare in quale modo il grafo verrà mappato

sull’ambiente del software embedded. Le informazioni

di mappatura sono quelle mostrate in figura 13.

Le informazioni di mappatura in questo caso specifi-

cano quanto segue:

zione della funzione

action

‘body’,

do_

, passandole come parametri i valori dei

campi

addr, size, wr_data, e wr_mask

Generazione dei test in C

L’aver descritto i test da effettuare sui registri mediante

un modello basato su un grafo garantisce una grande

flessibilità nella successiva generazione degli specifici

set di test da effettuare. La figura 14 illustra un esem-

# $

consentire a inFact di indirizzare lo stimolo verso tutte

effettuare solo cinque

iterazioni attraverso

notare, il test genera-

to consiste in un test

fa uso di valori casua-

li creati da inFact nel

corso del processo di

generazione. Questo specifico test ripeterà esattamente

le stesse operazioni, con gli stessi valori, ogni singola

invece forzare un maggior livello di casualità tra le dif-

# $ !l

spondenza di ogni esecuzione, utilizzando un differente

valore di

seed

per la randomizzazione. Al fine di ottene-

re la copertura di tutti gli obiettivi di accesso ai registri

precedentemente descritti, sarà naturalmente necessa-

( l % )

vengono sempre generati partendo da

# & $ &

estremamente semplice: modificando le

opzioni fornite al programma di genera-

invocazioni della

in ogni

singolo test, a una strategia opposta con-

dei quali effettua molte invocazioni della

rispetto di specifici obiettivi di copertura come, ad

esempio, la generazione di una serie di test focalizzati

solamente sull’accesso ai registri DMA. La scelta di un

approccio progressivo, in più passi, nella verifica delle

tempi di sviluppo, consentendo di individuare i bug fin

dalle fasi iniziali del processo di verifica, quando il de-

bugging e la correzione sono più agevoli. La soluzione

Portable Stimulus permette di generare test di elevata

qualità, partendo da una descrizione del

test intent

ef-

fettuata una singola volta, e successivamente riutilizzata

per indirizzare molteplici ambienti di verifica differenti.

quantità di impegno aggiuntivo necessario per esprime-

re ed eseguire il

test intent

all’interno di molteplici am-

* #

per il software embedded sotto forma di set di singoli

* l

una singola descrizione del

test intent

relativo all’acces-

(

riutilizzarla più volte, indirizzandola in modo semplice

* /01

2 *

realizzare la descrizione del

test intent

)

successive specializzazioni indirizzate verso specifici

ambienti, grazie all’utilizzo del tool di portable stimulus

dovrebbe attentamente considerare quanti vantaggi

per il proprio processo di verifica potrebbero derivare

un approccio di testing progressivo.

Fig. 12 – Funzione C do_memcheck del

software embedded

Fig. 14 – Esempio di test dei registri

Fig. 13 – Mappatura del software

embedded