1
Coverage Metricsin Formal Verification
Hana Chockler
Hebrew University
2
Plan of the Lecture
Coverage in simulation-based verification
Motivation Coverage metrics Other directions of research Summary
3
Motivation
NO
YES
p p
p
specification
Fix the model/specification
Should I really
believe this?Did I check what I meant to check?
Did I check everything that I meant to check?
4
Coverage metrics are heuristic measures of comprehensiveness of a given test.
Different coverage metrics: Code-based. Circuit structure-based. Functionality-based. etc.
High coverage indicates that fewer bugs remained.
Coverage in Simulation-Based Verification
Measures the percentage of
code executed by the test.
Measures the percentage of gates visited
during the test.Measures the percentage of functionality
checked by the test.
In model-checking we may visit all
states.Does it mean that coverage is always
100%
?
What is coverage in model checking?
5
Motivating Example
)(: FgrantrequestAG
Specification
In temporal logic:
every request is eventually granted
request
grant
grant
System
What is wrong with the system?
grant
grant
There are two grants for one
request!!!
The system satisfies the specification
This problem can be discovered by studying
the effect of local mutations of the system on the satisfaction of the
specification.
6
As a high-level design
Motivating Example (cont.)
Specification
every request is eventually granted
request
grant
grant
System
request * grant*
Simulation of the
system by the
specification
grant
grant
There are two grants for one
request!!!
The system is simulated bythe design
This problem can be discovered by studying
the effect of local mutations of the system on the simulation relation
with the design.
7
Y.Hoskote, T.Kam, P.-H.Ho, X.Zhao. “Coverage estimation for symbolic model checking”.
For subset of ACTL. Observability transformation applied to the specification, implying syntax-dependent algorithm. Linear in the specification and the system. Implementation revealed a bug in a priority buffer!
S.Katz, D.Geist, O.Grumberg. “Have I written enough properties?” For ACTL safety formulas. Checking bisimulation between the system and the
reduced tableau of the specification. Exponential in the (entire) specification.
Previous Work
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.
8
Our ContributionDefinitions 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.
Request for
coffee
Request for tea
request
servecoffee
servetea
Input signals00
1001
Control signals
Output signals
9
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
State-based coverage
Flipping
“serve tea”in the state 10
request
servecoffee
servetea
00
1001
Request for
coffee
Request for tea
Original system
request
servecoffee
servecoffee
00
1001
Request for
coffee
Request for tea
Mutant system
Flipping x
in the state 10
Mutant system
request
servecoffee
00
01
Request for
coffee
Request for tea
Logic-based coverage
Fixing x to 0everywhere
request
servecoffee
00
01
Request for
coffee
Request for tea
Mutant system
10
There is no direct correlation between
node-based and structure-based
coverage!
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 is changed in a subset of the occurrences of a state in the infinite tree.
qunwindin
gq
qMutant structure Mutant tree
Satisfies “Always q or always not(q)”
Does not satisfy
“Always q or always not(q)”
Does not satisfy
“Eventually q”
Satisfies “Eventually
q”
11
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.a
*
b
a
b
b
b
b
simulation
uncoveredmutation
coveredmutation
SpecificationImplementation
12
Naive Algorithms forCoverage Computation
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
number of mutations=
number of states X number of signals
Checks each mutation separately.
13
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.
14
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.
15
1w 2w
0w
Improving Average Complexity
ExampleEXqAFp
F FT
,0w
EXqw ,0
qw ,2qw ,1
pw ,0
AFpw ,1 AFpw ,2
T
pw ,1
T pw ,2
q
pq p
StructureK
|K
AFpw ,0
Values of p are variables
Observable signal is p
x y
z
Shrink the circuit
T
error!Assign half
of the variables
FF
T
16
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).
17
)(:,)( wLpvwpP )(:,)(,:,)( wLqwwwLqvwvwqP
))(()( 11 PPairEXEXP
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.
Simulation [CK02]: •Compute the set of triples <w,v,w’> such that w’ simulates w in the mutant where the value of the observable signal is flipped in v.
4n OBDD variables
6n OBDD variables Early quantification
and variable interleaving
2n
3n
18
LTL [CKKV01]Node Coverage in FormalCheck: •Can be done by introducing a new variable that non-deterministically 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 . -calculus and might be exponential in the size of the original formula. fair path
flipping q
The product automaton
reachability
existence offair path
characterization of these states
19
Coverageinformation
Recommended Workflowwith Coverage Check
Re-checkwith
the newspecification/
model
low coverage
high coverage
NO
YES
p p
p
specification
Fix the model/specification
Verification is
complete!
Write a better specification or
change the model
20
Other directions of research:Vacuity [Chockler,Kupferman]
Specification: every request is eventually granted
System S: satisfies the specification!
Where is the problem?
There are no
requests!!!
The specification is satisfied in Svacuously
Previous work: [BBER], [KV]
Best known complexity =
complexity of model checking X size of the
specificationOur contribution [CK02]: •Improving average complexity for vacuity detection•Algorithm with complexity = complexity of model checking for LTL ACTL
21
Other directions of research:Responsibility
[Chockler,Halpern,Kupferman]Motivating example – Coverage of existential properties
q q
System A
q qq …
100 successors
System B
Specification:“There exists a successor labeled with q”
In both systems all successors are
uncovered
Each successor is 1/2-
responsibleEach successor
is 1/100-responsible
22
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 the
given property
Previous work [Alon,Krivelevich,Newman,Szegedy ‘99]: property testing algorithm for regular languages.
-far from having the property
Our contribution [Chockler,Kupferman ‘02]: property testing algorithm for -regular languages and lasso-shaped input words.
Might be useful for checking the
outputs of random simulator
(Intel).
Has a constant
complexity!
23
Property testing insteadof model checking?
NO
YES
Fix the model/specification
p p
p
specification
There is surely a
bugDoes not always mean that the
system is correct!
The complexity is constant!
24
Property testing .. insteadof model checking?
NO
YES
Fix the model/specification
p p
p
specification
Usually the systems
contain many bugs
falsification!=
Continue withmodel checking ...
25
Work in progress:Checking branching
temporal properties on trees[Chockler,Kupferman,Shpilka]
-calculus properties are not testable.
Purely existential properties are trivially testable, since they have no “bad” trees.
It is enough to change a constant number of
paths in a tree to make it satisfy an
existential property
Universal properties are testable with a constant number of queries.
26
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.
27
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.