Coverage Metrics
in Formal Verification
Hana Chockler
Hebrew University
1
Plan of the Lecture
 Coverage
in simulation-based verification
 Motivation
 Coverage metrics
 Other directions of research
 Summary
2
Motivation
Fix the model/specification
p
NO
p
p

specification
Did I check what I
meant to check?
Did I check
everything that I
meant to check?
YES
Should I
really believe
this?
3
Coverage in Simulation-Based
Verification
 Coverage
metrics are heuristic measures of
comprehensiveness
of a given
test.
In model-checking
we
Measures the
visit all metrics:
states.
 Differentmay
coverage
percentage of code
Does it mean that
executed by the
 Code-based.
test.
What isisalways
coverage Measures
coverage
the
 Circuit structure-based.
100% checking?
percentage of gates
in model
?
 Functionality-based.
 etc.
 High
coverage indicates that
remained.
visited during the
test.
Measures the
percentage of
fewer
bugs
functionality
checked by the
test.
4
Motivating Example
Specification
The system
every request This
is eventually
granted
problem
canthe
be
satisfies
discoveredspecification
by studying the
In temporal
logic:of local mutations of
effect
There
are
two
the
system
on
the
 : AG(request  Fgrant
)
grants
satisfaction
of for
the one
specification.
What is wrong request!!!
with the
system?
System
request
grant
grant
5
Motivating Example (cont.)
Specification
System
The system
is
This
problem
can
be
every request is eventually
granted
simulated
by the
discovered by studying
themutations
design
effect of local
of
request
Simulation
of
There
are two
the system
on the
As a high-level
design
the system
simulation relation
grantswith
forthe
one
grant
by the
design.
request
grant
*
* request!!!
specification
grant
6
Previous Work
Y.Hoskote,
P.-H.Ho,
X.Zhao.
 S.Katz, T.Kam,
D.Geist,
O.Grumberg.
“Coverage
for symbolic
model checking”.
“Have I estimation
written enough
properties?”
For
subset
of safety
ACTL. formulas.
 For
ACTL
 Observability transformation applied to the specification,
 Checking bisimulation between the system and the
implying
syntax-dependent
algorithm.
reduced
tableau of the
specification.
 Linear in the specification and the system.
 Exponential in the (entire) specification.
 Implementation revealed a bug in a priority buffer!

The idea:
•Introduce a small mutation in the system.
•Check whether the mutant system is still correct
with respect to the specification.
•If yes – this mutation is not covered by the
specification.
•Output the list of uncovered mutations.
7
Our Contribution
Definitions of coverage
[Chockler, Kupferman, Vardi ‘01]
 Distinction between input, output, and control
signals:
Coverage cannot be measured with respect to input
signals, since we cannot affect their values.
 Changing the value of a control signal affects both
the label and the transition relation.
 Changing the value of an output signal affects only
the labeling of a state.

Input signals
Request
for
coffee
serve
coffee
00
request
01
Request
for tea
serve
tea
10
Control signals
Output signals
8
Definitions of coverage [CKV01]

State-based versus logic-based coverage:
In state-based coverage we study the effect of
changing the value of one signal in one state.
 In logic-based coverage we study the effect of
fixing the value of one signal everywhere.

Control
signals are
x and y
Request
for
coffee
serve
coffee
State-based
Logic-based coverage
coverage
00
Request
Flipping
for
Flipping
x to x
0
for tea Fixing
“serve tea”
in
everywhere
the state 10 coffee
10 in the state 10
request Request
01
serve
tea
Original system
serve
coffee
00
request Request
for tea
01
serve
coffee
Mutant
Mutant system
system
9
10
Definitions of coverage
[Chockler,Kupferman,Kurshan,Vardi ‘01]

Different types of mutations with respect to unwinding
the structure to an infinite tree:
Node-based coverage: the value of a signal is changed in
one occurrence of a state in the infinite tree.
 Structure-based coverage: the value of a signal is
changed in all the occurrences of the same state in the
tree.
 Tree-based coverage: the value of a signal
isnot
changed
Satisfies
Does
satisfy in a
subset
infinite
Does notof the occurrences of a state in the
“Always
q or
“Eventually
q” tree.
Satisfies

satisfy
“Always
q or
“Eventually
q”
always
not(q)”
There is no direct
q
unwinding
correlation
between
q
node-based and
q
structure-based
Mutant structure
always not(q)”
Mutant tree
10
Definitions of coverage
[Chockler, Kupferman ‘02]

Coverage with respect to simulation:
A specification is given as a high-level design.
 A correct implementation is simulated by the design.
 A mutation is covered if it is no longer simulated by
the design.
covered
mutation

a
a
b
b
b
b
Implementation
simulation
uncovered
mutation
*
b
Specification
11
Naive Algorithms for
Coverage Computation
Checks each mutation separately.
number of mutations
=
number of states X number of signals
Complexity:
•For CTL specifications: quadratic in the size of the
structure and linear in the size of specification
•For LTL specifications: quadratic in the size of the
structure and exponential in the size of specification
•For simulation: cubic in the size of state space
12
Improving Average Complexity
Mutations differ from each
other only slightly
much
of the model-checking or
simulation can be done once
•Incomplete labeling function permits to label the states
with variables.
•Different assignments to the variables represent
different mutations.
•A part of model-checking (or simulation) can be performed
without assigning the variables.
•The rest can be performed in steps, each time assigning
half of the variables.
13
Improving Average Complexity
Applications [CKV01]
Coverage of CTL specifications:
•Automata-theoretic approach to CTL model-checking
[KVW94] represents a structure with the formula as an
AND-OR graph, which looks like a Boolean circuit.
•Model-checking is equivalent to shrinkage of the graph
with respect to the values of the leaves.
•Mutations differ from each other by the values of the
leaves.
•Assignment to half of the leaves shrinks the circuit in
average by the factor of 2.
•The complexity is O(n log n) on the average.
14
Improving Average Complexity
Example
 w0 , 
  AFp  EXq
Observable signal is p w0 , AFp 
Structurew0
qValues of p
K
are variables

z
T
w0 , p F
Shrink
pq
p
the circuit
w1
w1 , AFp 
 w0 , EXq
T
T
w1 , q w2 , q

w2 , AFp
w2
x
F
Assign half w1 , p T
of the variables
K | 
F
y
F
T
w2 , p
error!
15
Improving Average Complexity
Applications [CK02]
Coverage in simulation:
•Enumerative algorithm of [HHK95] starts with the
maximal relation (with respect to the labeling function)
and reduces it in each step.
•The complexity of simulation is O(n m ), where n is the
size of the state space and m is the size of the transition
relation.
•In the same way we can start with the maximal relation
with respect to the incomplete labeling function.
•We never perform the same work twice!
•The average complexity of “simulation by steps” is
O(n m log n).
16
Symbolic Algorithms for Coverage
CTL specifications [CKV01]:
•Compute the set of pairs of states <w,v> such that w
satisfies the specification in the mutant where the value
of the observable signal is flipped in v.
2n
4n OBDD
Simulation [CK02]:
variables
P( p)  w, v : p  L( w)
•Compute the set of triples <w,v,w’> such that w’ simulates
(qthe
)  mutant
w, v : wwhere
 v, q the
L(wvalue
)  w
: qobservable
 L(w)
wPin
of, wthe
signal
is flipped in v.
P( EX1 )  PairEX
(OBDD
P(1 ))
6n
3n
variables
Early quantification
and variable
interleaving



 

17
LTL [CKKV01]
Node Coverage in FormalCheck:
•Can be done by introducing a new variable that nondeterministically sets the step where we check the
mutant instead of the original structure.
Reducing coverage to model checking for LTL:
•Checking coverage of an LTL formula is equivalent to
global model-checking
of the
indicator formula, which is in
The product
automaton
path
. -calculus and might be exponential in the size fair
of the

original formula.
existence of
reachability
flipping q
fair path
characterization
of these states
18
Recommended Workflow
with Coverage Check
Fix the model/specification
p
NO
p
p

specification
Re-check
with
the new
specification/
model
YES
low
high
Coverage
coverage information coverage
Write a better
specification or
change the model
Verificatio
n is
complete!
19
Other directions of research:
Vacuity [Chockler,Kupferman]
Specification: every request is eventually granted
System S:
satisfies
the
TheWhere
specification
is
satisfied
in S
is
the
There are no
specification!
vacuously
problem?
requests!!!
Previous work: [BBER], [KV]
Best known complexity =
complexity of model
checking X
size of the specification
Our contribution [CK02]:
•Improving average complexity for vacuity detection
•Algorithm with complexity = complexity of model
checking for LTL ACTL
20
Other directions of research:
Responsibility [Chockler,Halpern,Kupferman]
Motivating example – Coverage of existential properties
System A
System B
q
q
Each successor is
1/2-responsible
q
q
…
q
100 successors
In both systems
all
Each successor
is
successors are
uncovered
1/100-responsible
Specification:
“There exists a successor labeled with q”
21
Other directions of research:
Property Testing
The idea [Goldreich,Goldwasser,Ron ‘98]: distinguish
between good and very bad instances with high probability
by sampling a constant number of bits from the input.
having
Might
be useful for
the given
checking the
property
-far from
having the
property
Has a constant
outputs of random
Previous
work [Alon,Krivelevich,Newman,Szegedy
complexity!‘99]:
simulator
(Intel).
property testing algorithm for regular languages.
Our contribution [Chockler,Kupferman ‘02]: property
testing algorithm for  -regular languages and lassoshaped input words.
22
Property testing instead
of model checking?
Fix the model/specification
p
p
NO
p

specification
Does not always
mean that the
system is correct!
YES
There is
surely a bug
The
complexity
is constant!
23
.
Property
testing instead
.
=
offalsification!
model checking?
Fix the model/specification
p
p
NO
p

specification
YES
Continue with
model checking ...
Usually the
systems contain
many bugs
24
Work in progress:
Checking branching
temporal properties on trees
[Chockler,Kupferman,Shpilka]
Purely existential properties are trivially testable, since
they have no “bad” trees.
It is enough to change a
Universal properties are testable
with anumber
constant
constant
of
number of queries.
paths in a tree to make
it satisfy an existential
-calculus properties are not testable.
property

25
Summary
Positive answer of model checker does not
mean that the system is correct.
 The specification can cover only part of the
system.
 We described efficient algorithms for
coverage computation for CTL, LTL, and
simulation.
 We presented verification methodology that
contains property testing algorithms before
(instead of) model checking and vacuity and
coverage check after model checking.

26
Future Work
 Coverage
algorithms for different types of
modifications: code coverage, circuit
structure coverage, branch coverage, FSM
coverage …
 Coverage algorithms for other temporal
logics.
 Coverage algorithms for SAT solvers.
 Implementation of coverage algorithms.
 Useful presentation of coverage
information.
27