1 Coverage Metrics in Formal Verification Hana Chockler Hebrew University.

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.