` Degli Studi di Verona

Universita

Appunti di
SOFTWARE PER SISTEMI EMBEDDED
- VERIFICA A.A. 2013/2014

Alex Malfatti
alex.malfatti@gmail.com
Nicola Residori
nicola residori@icloud.com

Indice
1 Verifica Funzionale . . . . . . . . . . . . . . .
1.1 Verifica Dinamica . . . . . . . . . . . . . . .
1.1.1 Simulazione Logica . . . . . . . . . .
1.1.2 Simulazione di Guasto . . . . . . . .
1.1.3 Emulazione . . . . . . . . . . . . . .
1.2 Verifica Statica . . . . . . . . . . . . . . . .
1.2.1 Theroem Proving . . . . . . . . . . .
1.2.2 Equivalence Checking . . . . . . . .
1.2.3 Model Checking . . . . . . . . . . .
1.3 Verifica Semi-Formale . . . . . . . . . . . .
1.3.1 Verifica Basata su Asserzioni (ABV)

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

1
1
1
2
2
2
2
2
3
3
3

2 Property Mining . . . . . . .
2.1 Antecedent initialization .
2.2 Mining consequent . . . .
2.3 Antecedent set enrichment
2.4 Complessit`
a . . . . . . . .
2.5 Property Ranking . . . .
2.6 Conclusioni . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

6
6
7
7
7
7
7

3 Property qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Mutation analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Mutation testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8
8
8

4 Analisi di Incompletezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Property coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Witness coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9
9
10

5 Analisi di Vacuit`
a . . . . . . . .
5.1 Vacuity checking . . . . . . .
5.1.1 Mutation Analysis . .
5.1.2 Interesting Faults . . .
5.1.3 Problema: Tautologia

12
13
13
13
14

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

1 Verifica Funzionale
In generale la Verifica consiste nellaccorgersi di errori di progettazione.
Gli errrori possono avvenire sia in fase di formalizzazione delle specifiche, sia in fase di implementazione del Design a partire dalle specifiche.
La Verifica lavora quindi sulla specifica e sullimplementazione.
La Verifica pu`o essere legata ad aspetti funzionali o non funzionali (Consumo energetico,
timing, aging/invecchiamento,...).
La Verifica Funzionale pu`
o essere di tre tipi:
- Verifica Dinamica: Basata sulla simulazione di scenari diversi attraverso dei Testbench (Simulazione Logica e di Guasto, Emulazione/Simulazione Hardware).
- Verifica Statica (Formale): Controlla che il dispositivo soddisfi le specifiche attraverso metodi
matematici.
- Verifica Semi-Formale: Usa la rigorosit`a dei metodi formali (statici) ma con la velocit`a di
quelli dinamici.

1.1 Verifica Dinamica

Vengono generate sequenze di Stimoli e simulate. La Verifica Dinamica ha bisogno di:
Modello del Design
Simulatore
Testbench
Meccanismo per determinare la correttezza dei risultati
Vantaggi: Veloce.Va bene se voglio trovare molti errori.
Svantaggi: Non `e esaustiva. Verifico solo ci`o che simulo, solo scenari implementati nel Testbench.
La qualit`
a della Verifica `e misurata in termini di:
Code coverage
Fault coverage
1.1.1 Simulazione Logica
Simula il comportamento del Design, basandosi su metriche di Code coverage:
Line coverage: Pu`o vedere se ho eseguito ogni istruzione del programma, ma non in tutti
i modi possibili
Branch coverage: Mi dice se ho coperto tutti i branch
Condition coverage: Mi dice se ho coperto tutti i branch in tutti i modi possibili
Utilizzando tutte le tecniche di Code coverage non si riesce comunque ad avere la certezza di aver
provato tutti i cammini (Path coverage).
La Path coverage non `e calcolabile su circuiti sequenziali, in quanto i suoi Path potrebbero essere
infiniti.

1.1.2 Simulazione di Guasto

Silmula il Design in presenza di un guasto, comparando le uscite del Design con guasto e quelle
senza guasto per capire se il guasto `e testato o meno.
La Simulazione di Guasto si basa su metriche di Fault coverage, che coprono buona parte della
Path coverage nel propagare i guasti alluscita.
I guasti simulati servono per rilevare errori di progettazione (codice morto), ma non per
rilevare difetti fisici (Testing). Inoltre, un minor Fault coverage pu`o essere dovuto ad una verifica
incompleta, cio`e sono stati simulati guasti sbagliati; questo pu`o essere causato da Testbench
scarsi.
1.1.3 Emulazione
LEmulazione consiste nel costruire una versione del sistema utilizzando una logica programmabile
(FPGA) e nellutilizzo di tecniche di verifica dinamica sullemulatore.
LEmulazione permette di simulare molti Testbench in poco tempo, analizzando un numero
elevato di scenari, ma richiede la sintesi del modello e quindi costi elevati.

1.2 Verifica Statica

La Verifica Statica utilizza metodi matematici per dimostrare la correttezza del sistema.
Richiede:
Modello matematico del sistema (Stati e Transizioni)
Descrizione delle propriet`
a in un linguaggio formale
Metodo per dimostrare la consistenza delle specifiche col modello (Dimostrazioni manuali,
semi-automatiche, completamente automatiche)
Vantaggi: Completamente esaustiva e rigorosa.
Svantaggi: Richiede personale altamente qualificato, richiede alti tempi di sviluppo (problemi
NP-Completi molto complessi) e parte dal presupposto che le specifiche siano complete
(nella realt`
a non lo sono mai).
1.2.1 Theroem Proving
Dimostra in modo semi-automatico (tramite suggerimenti dellutente) che la congettura `e vera,
cio`e conseguenza logica di un insieme di ipotesi e assiomi.
1.2.2 Equivalence Checking
Dimostra se due modelli (implementazioni del Design) sono equivalenti, anche a diversi livelli di
astrazione (RTL-GATE, TLM-RTL).
Ci`
o `e facilmente realizzabile per livelli di astrazione che non introducono informazioni aggiuntive
(RTL-GATE); diversamente molto pi`
u complesso (TLM-RTL `e ad oggi un problema aperto).

1.2.3 Model Checking

Verifica in modo completamente automatico (FSM) la valitdit`a di un insieme di propriet`a usando
logica temporale rispetto ad un modello; se una propriet`a non `e valida fornisce un controesempio.
Approccio Clark-Emerson: Costruisce un grafo degli stati del sistema e propaga la
formula da verificare fino ad un punto fisso.
Tale approccio `e computazionalmente oneroso.
Symbolic Model Checking : Codifica il grafo degli stati con OBDD, limitando lesplosione
degli stati e quindi riducendone la complessit`a.

1.3 Verifica Semi-Formale

La Verifica Semi-Formale cerca di mantenere i vantaggi della Verifica Statica e Dinamica.
1.3.1 Verifica Basata su Asserzioni (ABV)
Verifica in modo formale e non ambiguo le specifiche del progettista.
Si basa su asserzioni temporali che possono essere verificate sia in modo statico che dinamico.
Le asserzioni vengono tradotte in Checkers, cio`e automi che stimolati restituiscono o vero o
falso.
Asserzione: Affermazione di intento che pu`o essere usata per specificare in modo preciso il
comportamento del Design; permette di specificare comportamenti interni o esterni.
Il termine Asserzione viene utilizzato generalmente in ambito dinamico o semi-formale.
` sempre attiva. Monitora ingressi e uscite. La sua
Asserzione Dichiarativa: E
esecuzione `e concorrente al Design.
Asserzione Procedurale: Cattura propriet`a implementative. La sua esecuzione `e
sequenziale rispetto al Design.
Categorie:
Invarianti : Sempre vere
Sequenze: Specificano comportamenti nel tempo
a : Specificano comportamenti che prima o poi accadranno (Liveness/Vitalit`a)
Eventualit`
Linserimento di asserzioni nel modello aumenta losservabilit`
a, in quanto lambiente di
verifica non dipende dalla capacit`a degli stimoli (Testbench) di propagare errori e un
comportamento errato o inaspettato viene catturato dalle asserzioni vicino alla sorgente del
problema. Tuttavia, le asserzioni da sole non migliorano la controllabilit`
a.
Propriet`
a: Pura specifica di un comportamento del sistema.
Il termine propriet`
a `e lequivalente dellasserzione per quanto riguarda lambito formale.
Liveness: Esprime leventualit`a che prima o poi si verifichi una condizione buona;
possono rappresentare la terminazione, garanzia di servizio, starvation, ...
Per falsificare una propriet`
a di Liveness Traccia infinita (Testimone)
Per verificare una propriet`
a di Liveness Traccia finita (Controesempio)
Safety : Esprime la necessit`
a che non si verifichi mai una condizione cattiva.
Sono invarianti che specificano sequenze di eventi; garantiscono la sicurezza, affidabilit`
a
del sistema.

Per falsificare una propriet`

a di Safety Traccia finita (Controesempio)
Per verificare una propriet`
a di Safety Traccia infinita (Testimone)
Intersezione di Liveness e Safety (Alpern e Schneider).
Sistemi Reattivi: I Sistemi Digitali sono Sistemi Reattivi, ci`e:
Interagiscono continuamente con lambiente
Sono Sistemi concorrenti
Per verificare Sistemi Reattivi servono Logiche Temporali.
Logiche Temporali: Estendono la logica proposizionale per descrivere Sistemi Reattivi.
Utilizzano operatori temporali attraverso una semantica basata sulla struttura di Kripke
(FSM); tale struttura prevede la conoscenza dellinsieme degli Stati (S), la Relazione di stato
prossimo (R) e una funzione (L) che dato uno stato fornisce linsieme delle proposizione
atomiche vere in tale stato.
Nella struttura di Kripke ogni transizione rappresenta il trascorrere del tempo e vengono
aggiunti gli operatori:
G Gp `e vera al tempo presente se p `e vera sempre nel futuro
F Fp `e vera al tempo presente se p `e vera prima o poi nel futuro
Linear Time Logic (LTL) :
U pUq `e vera al tempo presente se p `e vera sempre finch`e non diventa vera q
Discrete Time Logic (DTL) :
X Xp `e vera nello stato presente se p `e vera nel prossimo stato
Branching Time Logic (BTL) :
Ogni istante ha un passato unico ma un futuro indeterminato; considera tutti i possibili
cammini che partono da uno stato.
A Ap `e vera se per tutti i cammini vale p (necessit`a)
E Ep `e vera se esiste almeno un cammino in cui vale p (eventualit`a)
Computation Tree Logic (CTL) : Sottoinsieme della BTL in cui gli operatori occorrono
solo in coppia A oppure E seguiti da F, G, U oppure X
LTL + CTL = CTL*
Symbolic Model Verifier (SMV): Model Checker che utlizza OBDD (Ordered Binary Decision
Diagrams) e permette di descrivere il modello con un linguaggio proprio e definire propriet`a
in LTL e CTL.
SMV riduce il problema dellesplosione degli stati rispetto alla tecnica di Clarke-Emerson,
ma non lo risolve del tutto; inoltre, non sempre fornisce una risposta.
Linguaggi per la specifica di asserzioni :
Open Verification Library (OVL) Libreria di Checkers scritti in VHDL, Verilog
e SystemVerilog; rappresentano asserzioni dichiarative verificate in simulazione.
Lutente non ha bisogno di scrivere nuovi Checkers, ma pu`o utilizzare i template OVL
gi`
a esistenti.
SystemVerilog Assertion (SVA) Semantica basata su un sottoinsieme della
logica LTL, di cui utilizza solo operatore G e aggiunge le espressioni regolari; supporta
asserzioni procedurali e dichiarative.

 OpenVera Non crea asserzioni, ma Testbench per simulazioni Verilog (e successivamente VHDL).
SystemC Verification Library (SVL) Libreria per SystemC per scrivere Testbench e non asserzioni; non supporta asserzioni temporali.
Property Specification Language (PSL) Linguaggio per la specifica di propriet`a
temporali in modo rigoroso e con una semantica formale; `e basato su CTL e LTL
e permette di esprimere sia propriet`a Safety (verificabili anche via simulazione) che
Liveness (verificabili solo formalmente).
` diviso in 4 livelli: Boolean layer (espressioni booleane sui segnali del design), Temporal
E
layer (definisce propriet`a che valgono nel tempo), Verification layer (definisce direttive
per i tool di verifica) e Modeling layer (permette di inserire codice VHDL, Verilog,
SysyemVerilog o GDL in una specifica PSL pr modellare lambiente in cui effettuare la
verifica).
PSL Simple Subset: Sottoinsieme del PSL che pu`
o essere supportato facilmente sia in
simulazione che formalmente.

2 Property Mining
Il Property Mining `e una tecnica per infierire comportamenti del programma (propriet`
a ) analizzando le tracce desecuzione.
Le propriet`
a infierite possono essere confrontate con le specifiche iniziali per:
Rilevare comportamenti inaspettati (bug)
Mostrare se sono stati implementati comportamenti desiderati
Documentare limplementazione
Verificare il Design a diversi livelli di astrazione
Verificare future evoluzioni del Design
Lo scopo del Property Mining `e quello di generare in modo automatico propriet`a temporali PSL:
su domini Booleani e non-Booleani
su tracce desecuzione di descrizioni HW, protocolli SW e SW embedded
scritte in modo facilmente comprensibile dalluomo
Traccia desecuzione: Sequenza dei valori di tutte le variabili del dispositivo in tutti gli istanti
di tempo.
Le formule PSL sono della forma:
always (a consequent)
consequent pu`
o essere:
next b

Xb

a until b

aUb

a alternating b

G(a b)

a e b sono espressioni aritmetico-logiche tra due o pi`

u variabili.
Il Property Mining si compone delle seguenti fasi:
Antecedent initialization
Mining consequent (next, until, alternating)
Antecedent set enrichment

2.1 Antecedent initialization

Scorre la traccia desecuzione e quando rileva delle invarianti che cambiano valore, le colleziona,
insieme ai loro complementi, nellinsieme degli Antecedenti.
Lanalisi delle sottotracce viene fatta utilizzando il tool Daikon.
Solo in fase di inizializzazione degli Antecedenti vengono fatte length() chiamate a Daikon, dove
`e la lunghezza della traccia desecuzione.

2.2 Mining consequent

- next: Per ogni Antecedente candidato verifica i punti nella traccia desecuzione in cui esso `e
vero e osserva gli istanti successivi; estrae le sottotracce osservate e verifica cosa rimane
sempre vero.
G((a X(???)))
- until: Per ogni Antecedente candidato verifica i punti nella traccia desecuzione in cui esso `e
vero e osserva gli istanti dove smette di esserlo; estrae le sottotracce osservate e verifica cosa
rimane sempre vero.
G((a (a U (???))))
- alternating: Per ogni Antecedente candidato verifica i punti nella traccia desecuzione in cui
esso `e vero e osserva gli istanti in cui non lo `e (alternate); estrae le sottotracce osservate
e verifica cosa rimane sempre vero.
G((a G(a (???))))

2.3 Antecedent set enrichment

Linsieme di antecedenti collezionati nella fase di inizializzazione considerano solo gli invarianti
trovati partendo dallinizio della traccia desecuzione (istante 0).
` necessario quindi arricchire linsieme con i conseguenti trovati nella fase di mining.
E

2.4 Complessit`
a
O(daikon time * (length() + 3 * |antecedent set|))
daikon time: Cubico nel numero di variabili
Lineare nella lunghezza della traccia
: Traccia desecuzione
3 : Pattern (next, until, alternating)
antecedent set: Legato al numero di comportamenti del Design (spaccature temporali)

2.5 Property Ranking

Il Property Ranking fornisce una metrica in termini di relazione causa-effetto tra antecedente e
conseguente per misurare la qualit`a delle propriet`a; lo fa attraverso il rapporto R del numero di
occorrenze di antecedenti e conseguenti.

2.6 Conclusioni
Le propriet`a ottenute sono valide solo per le tracce desecuzione considerate e possono non
catturare comportamenti non esposti nelle tracce; per questo motivo `e fondamentale la qualit`a
del Testbench.
Le propriet`a catturate sono probabilmente vere e nonostante possano fallire su pi`
u tracce diverse,
provano che esiste almeno un percorso desecuzione finito dove occorrono i comportamenti rilevati.
La Scalabilit`
a rimane ancora un problema.

3 Property qualification
La Property qualification mira a valutare la qualit`
a delle propriet`a, cio`e capire se un insieme di
propriet`
a `e un insieme di buona qualit`
a per il Design Target.
Testbench qualification + Property qualification = Functional qualification
La Property qualification si compone di:
Analisi di Incompletezza (Incompleteness analysis)
Analisi di Vacuit`
a (Vacuity analysis)
Analisi su Specifica (Over specification analysis)
La maggior parte degli approcci sono basati su metodi formali.
Gli approcci utilizzati sono:
Mutation analysis
Mutation testing

3.1 Mutation analysis

La Mutation analysis consiste nella mutazione del codice sorgente, inserendo o modificandone
istruzioni; queste istruzioni sono dei ben definiti operatori di mutazione (mutanti ), che simulano
la presenza di errori di progettazione (bug).
I mutanti possono essere inseriti sia sul Design che sui Checkers (propriet`a):
Se i mutanti vengono introdotti sul Design e le propriet`
a non individuano il guasto inserito,
allora le propriet`
a sono incomplete.
a) e la propriet`
a in questione non
Se i mutanti vengono introdotti sui Checkers (propriet`
diventa falsa, allora la propriet`
a `e vacua.

3.2 Mutation testing

Il Mutation testing `e il processo di generazione dei test per migliorare il risultato della Mutation
analysis. Solitamente per la generazione automatica dei test vengono utilizzati degli ATPG
(Automatic Test Pattern Generator).

4 Analisi di Incompletezza
Dato un insieme di propriet`
a, queste propriet`
a sono sufficienti per garantire la completezza del Design?
Lanalisi di Incompletezza misura quanto buono `e linsieme di propriet`a nello scoprire bug; limplementazione potrebbe essere errata anche se soddisfa tutte le propriet`a.
Lanalisi di Incompletezza da solo unanalisi parziale, dice solo se `e presente un buco nel
Design, ma non pu`
o garantire che non ce ne siano.
Per scoprire se mancano delle propriet`a servono delle metriche di copertura:
Property coverage (basata su Verifica Statica)
Witness coverage (basata su Verifica Dinamica)
Allo stato dellarte esistono 2 approcci per verificare la copertura:
Mutation-based
Implementation-based
Lapproccio utilizzato `e basato su EFSM (Extended-FSM ), dove sia il DUV (Design Under
Verification) che lEnvironment (Ambiente) sono modellati come delle ESFM separate.
EFSM (Extended Finite State Machine): Pi`
u compata di una FSM. Le Transizioni sono etichettate ad una funzione dabilitazionee da una funzione daggiornamento.
Lapproccio con EFSM consiste nel perturbare lEFSM e se le propriet`
a risultano ancora vere
anche sulla ESFM perturbata Analisi di Incompletezza:
Si identificano i guasti testabili (che hanno un effetto sulle uscite) con le tecniche utilizzate
nel Testing.
Si ottiene una lista di guasti testabili.
Genero le ESFM perturbate con i guasti rilevati.
Verifico le propriet`
a su queste implementazioni
Se rilevo ancora solo propriet`
a vere... ricomincio lanalisi.

4.1 Property coverage

La Property coverage `e la percentuale dei comportamenti implementati dal modello, che sono
verificati da almeno una propriet`
a.
E-detectable faults: Dato un Design privo di guasti e un Design con i guasti, un guasto f `e:
detectable (testabile): se una sequenza di input tale che PO(I) 6= PO(If )
E-detectable (E-testabile): se una sequenza di input tale che PO(I) 6= PO(If ) sotto
lambiente E
Linsieme di guasti E-Detectable si pu`o identificare, per esempio, con un ATPG.

Property coverage: Dato un modello di guasto, un Design privo di guasti e un Design con i guasti:
p P , f E-det
f p-det se f diventa false su If
f P-det se p P | f p-det
Property coverage (CP ) =

P det
Edet

P `e completo se CP = 1
Fare Model Re-Checking `e per`
o troppo costoso.

4.2 Witness coverage

La Witness coverage non si basa pi`
u su tecniche formali di Model Re-Checking, ma su Testimoni
e Controesempi.
Witness e Controesempi per propriet`
a LTL :
Witness: Cammino computazionale tale che la propriet`a `e vera in modo non vacuo.
Controesempio: Cammino computazionale tale che la propriet`a `e falsa.
Witness e Controesempi per propriet`
a CTL :
Witness (E): Cammino computazionale finito tale che la propriet`a `e vera.
Controesempio (A): Cammino computazionale finito tale che la negazione della
propriet`
a `e vera.
Un Controesempio per una propriet`a con quantificatore Universale (U) `e un Witness
(Testimone) per una propriet`a duale con quantificatore Esistenziale (E).
Witness (Testimoni) e Controesempi possono essere forniti da tool di Model Checking (ed
estesi con ATPG), ma solo per i segnali (Input, Output e di variabili interne) coinvolti nelle
propriet`
a e non per tutti i segnali del modello.
I segnali non coinvolti nelle propriet`a vengono ignorati dal Checker, ma in fase di confronto
del modello faulty con il modello fault-free deve poi ricordare di non confrontare i segnali
ignorati.
Input Witnesses e Controesempi :
Nel calcolo della Witness coverage siamo interessati solo a Witness e Controesempi sui
segnali di Input.
Un Input Witness per una propriet`
a p `e una sequenza finita di valori per gli Input
del DUV tale che p `e soddisfatta in modo non vacuo.
Un Input Controesempio per una propriet`a p `e una sequenza finita di valori per gli
Input del DUV tale che p non `e soddisfatta.
Entrambi sono ottenuti estraendo la proiezione dellinput dei Witness (Controesempi) forniti
dal Model Checker e assegnando il valore di default ai segnali in Input non specificati.
Sia Witness che Controesempi possono avere percorsi infiniti, quindi per renderli finiti se ne considera solo un prefisso finito seguito da una sola iterazione del ciclo infinito.

10

Witness coverage: Data unimplementazione I, un insieme di propriet`

a P, e un guasto f P-det:
un Input Controesempio per p P su If che `e
- un Input Witness per p su I
- una sequenza di test per f su I
f E-det `e wp -det se:
un Input Witness w per p tale che
- w `e una sequenza di test per f
- w `e un Input Controesempio per p su If
WP -det: Insieme di guasti rilevati da fault simulating input witnesses.
Witness coverage (CW ) =

W P det
Edet

Teorema: CP = CW
P `e completo se CW = 1
Non `e richiesto Property Re-Checking.
Il numero di Witness trovati dl Model Checker pu`
o essere incrementato utilizzando ATPG
per generarli.
Le propriet`
a sono convertite in Checkers.
Per propriet`a di Safety loutput del Checker `e sempre VERO finch`e non fallisce; i
Checkers sono connessi alle PO di If .
Per propriet`a di Liveness loutput del Checker `e sempre FALSO finch`e non ha successo;
i Checkers sono connessi alle PO di I.

11

5 Analisi di Vacuit`
a
Dato un insieme di propriet`
a, queste sono tutte significative o qualcuna `e vacua?
Una propriet`a `e vacua se `e banalmente vera, inutile per scopi di verifica e pu`
o portare ad un falso
senso di sicurezza.
Influenza (Affect): Una sotto-formula di una formula influenza in un modello M se esiste
una formula tale che i valori di verit`a di e [ ] sono diversi in M.
se (A B) 6= (A C)
allora
B infuenza A B
Vacuit`
a (Vacuity): Una formula passa in modo vacuo in un modello M se M|= e include
una sotto-formula che non influenza in M.
In questo caso diciamo che `e -vacuo in M.
Non `e necessario analizzare tutte le sotto-formule, ma solo quelle minimali, cio`e che non possono
essere spezzate ulteriormente.
Sotto-formula minimale: Sia S un insieme di sotto-formule. Le sotto-formule minimali di S sono
definite come:
min(S) = { S | @ S tale che }
dove significa che `e una sotto-formula di e ogni sotto-formula `e unica.
S-Vacuit`
a (S-Vacuity): In una logica con polarit`
a, per ogni formula , e un insieme S di sottoformule di , per ogni modello M, `e S-vacua in M se e solo se:
min(S) tale che
M|= [ X]
dove X = f alse se M|= e ha polarit`a positiva, altrimenti X = true.
Si ha polarit`
a positiva quando si ha un numero pari di ;
si ha, invece, polarit`
a negativa quando si ha una numero dispari di .
Le sotto-formule minimali vengono sostituite con true o f alse per ridurre il numero di
check.
[ X] `e una Witness Formula.
non `e -vacua se M 2 [ X]
In questo caso il controesempio `e un interessante Witness che prova la non vacuit`
a di
rispetto .

12

5.1 Vacuity checking

Vantaggi :
Le Witness Formula ottenute dalla sostituzione di sotto-formule con true o f alse in
base alla loro polarit`
a.
Il fallimento delle Witness Formula evidenzia come le sotto-formule sostituite influenzino
la formula originale.
La S-Vacuit`a permette di concentrarsi solo sul Model Checking di dove le sottoformule minimali sono sostituite.
Svantaggi :
Si deve fare Model Checking
I tempi di verifica possono aumentare, causa la verifica di un nuovo insieme di formule.
5.1.1 Mutation Analysis
Un approccio differente per lanalisi di Vacuit`a `e quello della Mutation Analysis, che permette di
evitare Model checking e definizione di Witness Formula, rimanendo comunque efficiente; tale
approccio si basa su Fault Simulation e richiede:
Generazione dei Checkers.
Iniezione dei Guasti (Mutanti) nelle componenti dei Checker che rappresentano sotto-formule
minimali.
Attraverso degli stimoli (Testbench) confronto del modello originale con quello perturbato e
analisi dei risultati.
5.1.2 Interesting Faults
Un Guasto Interessante `e un guasto che va a perturbare le sotto-formule minimali nel Checker.
Le sotto-formule vengono raggruppate come:
Contemporanee: occorrenze della stessa sotto-formula che sono nello stesso scope dello
stesso operatore temporale.
Opposte: occorrenze contemporanee della stessa sotto-formula, ma con polarit`a opposta.
Il loro valore `e legato alla polarit`
a della sotto-formula.
Se i guasti sono rilevati, la formula non passa in modo vacuo.
Linsieme di Guasti Interessanti per un Checker C `e definito come:
F = {stuck-at X su a | a A}
dove X = f alse se la sotto-formula associata allassegnamento a ha polarit`a positiva, X = true
altrimenti.
Sia una formula nella logica con polarit`a e una sua sotto-formula,
allora il guasto f `e testabile se e solo se non `e -vacuo.
Vantaggi : I Checkers rendono la tecnologia indipendente dal motore di verifica.
Svantaggi :
Utilizzo di Testbench non sono esaustivi

13

 Non si possono creare Checker per qualsiasi propriet`a, ma solo per quelle che possono
diventare Checkers simulabili ( PSL Simple Subset) e dove il tempo cresce in modo
monotono.
5.1.3 Problema: Tautologia
Nel problema Tautologia pu`o succedere che due occorrenze separate della stessa sotto-formula non
siano marcate come formule vacue e vengano considerate come sotto-formule differenti; possono
essere marcate come vacue considerandole sotto-formule invece che occorrenze.
Pu`
o comunque succedere che una formula venga marcata non-vacua anche se in alcuni casi lo `e.
Soluzione: Modificare la formula per rimuovere la sovrapposizione temporale tra operatori:
Se le formule sono opposte vengono sostituite simultaneamente
Se le formule sono non opposte vengono sostituite separatamente

14