1. 1 Coverage Metrics in Formal Verification Hana Chockler Hebrew University

2. 2 Plan of the Lecture u Coverage in simulation-based verification u Motivation u Coverage metrics u Other directions of research u Summary

3. 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. 4 u Coverage metrics are heuristic measures of comprehensiveness of a given test. u Different coverage metrics:  Code-based.  Circuit structure-based.  Functionality-based.  etc. u 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. 5 Motivating Example Specification In temporal logic: every request is eventually granted request grant System What is wrong with the system? 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. 6 As a high-level design Motivating Example (cont.) Specification every request is eventually granted request grant System request * grant * Simulation of the system by the specification grant There are two grants for one request!!! The system is simulated by the design This problem can be discovered by studying the effect of local mutations of the system on the simulation relation with the design.

7. 7 u 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! u 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. 8 Our Contribution Definitions of coverage [Chockler, Kupferman, Vardi ‘01] u 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 serve coffee serve tea Input signals 00 1001 Control signals Output signals

9. 9 Definitions of coverage [CKV01] u 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 serve coffee serve tea 00 1001 Request for coffee Request for tea Original system request serve coffee serve coffee 00 1001 Request for coffee Request for tea Mutant system Flipping x in the state 10 Mutant system request serve coffee 00 01 Request for coffee Request for tea Logic-based coverage Fixing x to 0 everywhere request serve coffee 00 01 Request for coffee Request for tea Mutant system

10. 10 There is no direct correlation between node-based and structure-based coverage! Definitions of coverage [Chockler,Kupferman,Kurshan,Vardi ‘01] u 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. q unwinding q q Mutant 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. 11 Definitions of coverage [Chockler, Kupferman ‘02] u 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 uncovered mutation covered mutation Specification Implementation

12. 12 Naive Algorithms for Coverage 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. 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. 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. 15 Improving Average Complexity Example F FT TT q pqp Structure K Values of p are variables Observable signal is p xy z Shrink the circuit T error! Assign half of the variables FF T

16. 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. 17 Symbolic Algorithms for Coverage CTL specifications [CKV01]: Compute the set of pairs of states 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 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 2n2n 3n3n

18. 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 of fair path characterization of these states

19. 19 Coverage information Recommended Workflow with Coverage Check Re-check with the new specification/ model low coverage high coverage NO YES p p p specification Fix the model/specification Verificatio n is complete! Write a better specification or change the model

20. 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 S vacuously 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

21. 21 Other directions of research: Responsibility [Chockler,Halpern,Kupferman] Motivating example – Coverage of existential properties qq System A qqq … 100 successors System B Specification: “There exists a successor labeled with q” In both systems all successors are uncovered Each successor is 1/2-responsible Each successor is 1/100-responsible

22. 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. 23 Property testing instead of model checking? NO YES Fix the model/specification p p p specification There is surely a bug Does not always mean that the system is correct! The complexity is constant!

24. 24 Property testing.. instead of model checking? NO YES Fix the model/specification p p p specification Usually the systems contain many bugs falsification! = Continue with model checking...

25. 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. 26 Summary u Positive answer of model checker does not mean that the system is correct. u The specification can cover only part of the system. u We described efficient algorithms for coverage computation for CTL, LTL, and simulation. u We presented verification methodology that contains property testing algorithms before (instead of) model checking and vacuity and coverage check after model checking.

27. 27 Future Work u Coverage algorithms for different types of modifications: code coverage, circuit structure coverage, branch coverage, FSM coverage … u Coverage algorithms for other temporal logics. u Coverage algorithms for SAT solvers. u Implementation of coverage algorithms. u Useful presentation of coverage information.