1 / 25

Counterexample Guided Invariant Discovery for Parameterized Cache Coherence Verification

This paper presents a method for parameterized cache coherence verification using counterexample-guided invariant discovery. The method aims to make the verification process at usage level more easy, structured, and practical.

lcoles
Télécharger la présentation

Counterexample Guided Invariant Discovery for Parameterized Cache Coherence Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Counterexample Guided Invariant Discovery for Parameterized Cache Coherence Verification Sudhindra Pandav Konrad Slind Ganesh Gopalakrishnan

  2. Motivation • Parameterized verification methods are of growing importance for large scale verification • Despite the current state of art, parameterized verification • still highly manual and ingenious process • almost inapplicable for large system verification • Using the current technology standards, can we make the verification process at usage level • more easy, more structured and more practical? • Symbiosis --- can we benefit from system designer’s insights?

  3. Contributions • Invariant discovery for parameterized verification of safety properties • Based on syntactic analysis of counterexamples to discover only relevant invariants • Heuristics for directory-based cache coherence protocols (important class of parameterized systems) to minimize the number of predicates in the generated invariants • Case studies: German, FLASH, German-Ring.

  4. Inductive Invariant Checking: Basics • Let θ be the initial state formula. • Let δbe the transition formula. • Let P be the property to be proved. • Generate an inductive invariant Q s.t • θ=> P • Q /\ δ => Q’ • Q => P • How to generate Q ?

  5. Inductive Invariant Checking: Practice all states Auxiliary invariant Q initial states (I) Reachable states (R) General State Verification: For all states s & t, such that s∈R, t ∈R, verify that the property P(s) => P(t) • Inductive invariant checking: • I ⊂ Q • Q(s) => Q(t) • Q(s) /\ P(s) => P(t) d s t • diagrams not up to scale

  6. System Model • We model the system as a tuple <V, q, D> where V = set of system variables q = initial state formula D = set of rules of form: g => a, where g = boolean condition(guard) a = next state assignment of state variables(action) • We also have a set of input variables I, which are assigned arbitrary values in each step of operation. • The guard g consists of variables on (V U I) • Expressions are logical formulae over the theory of equality and uninterpreted functions • Values can be integers, booleans, functions (integer arrays) or predicates (boolean arrays).

  7. Property • Safety properties we verify are of form: "X. A(X) => C(X) where • X is the set of variables (index variables) • A is the antecedent • C is the consequent • Example: • "i,j. ((i != j) & (cache(i) = exclusive)) => (cache(j) = invalid) ;

  8. Invariant Discovery Process: Counterexample Analysis Overview • Since we start from a general state, we are bound to get failure cases • Failure cases classified into three possible classes • Syntactic analysis of failure case: • Pick relevant predicates from • Predicates in the property • Predicates in the transition rule • Interpretation to input variables (I) and index variables (X) • Construct auxiliary invariant by substituting in the formula suggested for the corresponding failure class

  9. Counterexample • Counterexample is a trace consisting of two states and a transition rule that leads one state to another, which violates the property. • Formally, a counterexample C can be expressed as a tuple <ss, d, st >, where • ss is the initial state interpretation • st is the next state interpretation • d is the transition rule of form: g => a

  10. Failure Classes • Counterexample C = <ss, d, st > • Property P: "X.A(X) => C(X) • Since, the initial state satisfies the property and the next state violates it, we can classify counterexamples into three different classes. • (ss|=A, ss|= C) (st |= A, st !|= C) • (ss!|=A, ss !|= C) (st |= A, st !|= C) • (ss !|=A, ss|= C) (st |= A, st !|= C) • We analyze each case and suggest a formula to construct auxiliary invariant

  11. Case I: (ss|=A, ss |= C) (st |= A, st !|= C) A => ~g s t g SC(A,ss) A C A ~C SC(g,ss) • Candidate invariant generated: • SC(A, ss) => ~SC(g,ss) • where SC is the satisfying core under interpretation ss. • SC can be easily computed from the structure of formula

  12. Case II: (ss !|=A, ss !|= C) (st |= A, st !|= C) ~C => ~g SC(g,ss) s t g VC(C, ss) a ~A ~C A ~C retains • Candidate invariant generated: • ~VC(C,ss) => ~SC(g, ss) • where VC is the violating core under interpretationss. • VC can be easily computed from the structure of formula

  13. Case III: (ss !|=A, ss |= C) (st |= A, st !|= C) s t g a ~A C A ~C a • Probably a concrete counterexample, as the action assigns • next state values to variables in both A and C s.t they contradict. • helps identify errors in models

  14. Example: German protocol • "i,j. cache(i) = exclusive => ch2(j) != grant_sh • Counterexample: Start state Next state • j = curr_client • cache(i) = exclusive • ch2(j) = empty • excl_granted = F • ch2(j) = grant_sh • cache(i) = exclusive rule 9 (current_cmd = req_sh) /\ ~excl_granted /\ ch2(curr_client) = empty => cache(curr_client) = grant_sh; … • type I counterexample: SC(A, ss) => ~SC(g,ss) • "i,j. cache(i) = exclusive => ~((current_cmd = req_sh) • /\ ~excl_granted /\ ch2(j) = empty)

  15. Filtering Heuristics • Guards of transition rules are very much complex, containing many predicates. • More the number of predicates in an auxiliary invariant, more the number of counterexamples • Usage-specific heuristics to filter relevant predicates in a structured way • We suggest heuristics for directory based cache coherence protocols based on empirical observations

  16. Heuristics for dir based cache coherence protocols • Order predicates in guard depending on type of the rule (R), msg type (m), client type (c) and state variables. • Type of rules: • P-rule: initiated by requesting node • N-rule: initiated by msg from network • Type of msgs: • Request: req msg from caching node to home node • Grant: msg from home to caching node, acks, … • State variables: • local: variables describing state of cache • directory: variables describing directory • environment: variables describing global state • channel: variables describing msg on network channels • Such categorization is natural for designers.

  17. Filtering Heuristics for dir based cache coherence protocols

  18. Example: German protocol • "i,j. cache(i) = exclusive => ch2(j) != grant_sh • Counterexample: Start state Next state • j = curr_client • cache(i) = exclusive • ch2(j) = empty • excl_granted = F • ch2(j) = grant_sh • cache(i) = exclusive rule 9 (current_cmd = req_sh) /\ ~excl_granted /\ ch2(curr_client) = empty => cache(curr_client) = grant_sh; … • type I counterexample: SC(A, ss) => ~SC(g,ss) • "i,j. cache(i) = exclusive => ~((current_cmd = req_sh) • /\ ~excl_granted /\ ch2(j) = empty) • R = N-rule, m = request, c = home  select predicates on dir variables • "i,j. cache(i) = exclusive => ~excl_granted

  19. Results / Comparison

  20. Conclusions • Counterexample guided invariant discovery for safety property verification of parameterized systems. • Simple heuristics to pick relevant predicates from guards of directory based cache protocols. • Structured way of using verification technology for practical verification. • Applied our methods to cache protocols from small to large scale examples. • Future Work: • Automation • Counterexample analysis steps can be automated • Application to other large examples

  21. References • Counter-example based predicate discovery in predicate abstraction [Das et.al., FMCAD’02] • Parameterized verification of a cache coherence protocol [Baukus et.al., VMCAI’02] • A simple method for parameterized verification of cache coherence protocols [Ching-Tsun Chou et.al., FMCAD’04] • Indexed predicate discovery for unbounded system verification [Lahiri et.al., CAV’04] • Automatic deductive verification with invisible invariants [Pnueli et.al., TACAS’01] • Empirically efficient verification for a class of infinite state systems [Bingham et.al., TACAS’02] • A synthesizer of inductive assertions [German et.al., IEEE trans.’75]

  22. Backup

  23. System Operation At each step of operation, • Input variables are assigned arbitrary values • A rule d ∈ Dis nondeterministically selected for execution • If the guard g is enabled (true), then next state values are assigned to state variables in the action a. • State variables which are not assigned in action retain their values.

  24. Depending on the structure of the counterexample, we construct an auxiliary invariant from • those predicates in the property P, which have been violated • predicates from the guard and ITE (“if-then-else”) conditions in the action

  25. Framework of verification process Punproved Pproved “done” Y Punproved={} N Add P Auxiliary Invariant Pick a property P from Punproved Automated Decision Procedure D Counterexample Analysis Procedure System model M counterexample

More Related