Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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)
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.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
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.
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.
10
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
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