1 / 47

Introduction to SMV

Introduction to SMV. Symbolic Model Verifier. Ken McMillan, Symbolic Model Checking: An Approach to the State Explosion Problem , 1993. Finite-state Systems described in a specialized language Specifications given as CTL formulas Internal representation using OBDDs

Download Presentation

Introduction to SMV

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. Introduction to SMV

  2. Symbolic Model Verifier • Ken McMillan, Symbolic Model Checking: An Approach to the State Explosion Problem, 1993. • Finite-state Systems described in a specialized language • Specifications given as CTL formulas • Internal representation using OBDDs • Automatically verifies specification or produces a counterexample

  3. Overview of SMV SMV Input Language Backend Finite State Kripke Structure OBDD based Symbolic Model Checking Yes Specification – CTL Formula No CounterExample

  4. Language Characteristics • Allows description of completely synchronous to asynchronous systems, detailed to abstract systems • Modularized and hierarchical descriptions • Finite data types: Boolean and enumerated

  5. Language Characteristics (cont..) • Parallel-assignment syntax • Non-determinism

  6. A Sample SMV Program MODULE main VAR request: boolean; state: {ready, busy}; ASSIGN init(state) := ready; next(state) := case state=ready & request: busy; 1: {ready, busy}; esac; SPEC AG(request -> AF (state = busy))

  7. SMV Syntax - Expressions Expr :: atom ;; symbolic constant | number ;; numeric constant | id ;; variable identifier | “!” expr ;; logical not | expr1 <op> expr2 | “next” “(“ id “)” ;; next value | case_expr | set_expr

  8. The Case Expression Case_expr :: “case” expr_a1 “:” expr_b2 “;” … expr_an “:” expr_bn “;” “esac” • Guards are evaluated sequentially. • The first one that is true determines the resulting value • If none of the guards are true, result is numeric value 1

  9. State Variables Decl :: “VAR” atom1 “:” type1 “;” atom2 “:” type2 “;” … • State is an assignment of values to a set of state variables • Type of a variable – boolean, scalar, user defined module, or array.

  10. ASSIGN declaration Decl :: “ASSIGN” dest1 “:=“ expr1 “;” dest2 “:=“ expr2 “;” … Dest :: atom | “init” “(“ atom “)” | “next” “(“ atom “)”

  11. Variable Assignments • Assignment to initial state: init(value) := 0; • Assignment to next state (transitionrelation)next(value) := value + carry_in mod 2; • Assignment to current state (invariant)carry_out := value & carry_in; • Either init-next or invar should be used, but not both • SMV is a parallel assignment language

  12. Circular definitions • … are not allowed! • This is illegal: • a := next(b);next(b) := c;c := a; • This is o.k. • init(a) := 0;next(a) := !b;init(b) := 1;next(b) := !a;

  13. Nondeterminism • Completely unassigned variable can model unconstrained input. • {val_1, …, val_n} is an expression taking on any of the given values nondeterministically. • Nondeterministic choice can be used to: • Model an implementation that has not been refined yet • Abstract behavior

  14. ASSIGN and DEFINE • VARa: boolean;ASSIGNa := b | c; • declares a new state variable a • becomes part of invariant relation • DEFINEd:= b | c; • is effectively a macro definition, each occurrence of d is replaced by b | c • no extra BDD variable is generated for d • the BDD for b | c becomes part of each expression using d

  15. SPEC declaration • Decl :: “SPEC” ctlform • Ctlform :: expr ;; bool expression | “!” ctlform | ctlform1 <op> ctlform2 | “E” pathform | “A” pathform • Pathform :: “X” ctlform | “F” ctlform | “G” ctlform | ctlform1 “U” ctlform2

  16. Modules and Hierarchy • Modules can be instantiated many times, each instantiation creates a copy of the local variables • Each program has a module main • Scoping • Variables declared outside a module can be passed as parameters • Parameters are passed by reference.

  17. Pass by reference DEFINE a := 0; VAR b : bar(a); … MODULE bar(x) DEFINE a := 1; y := x;

  18. Pass by reference … VAR a : boolean; b : foo(a); … MODULE foo(x) ASSIGN x:=1;

  19. MODULE main VARbit0 : counter_cell(1); bit1 : counter_cell(bit0.carry_out); bit2 : counter_cell(bit1.carry_out); SPEC AG AF bit2.carry_out MODULE counter_cell(carry_in) VARvalue : boolean; ASSIGN init(value) := 0; next(value) := value + carry_in mod 2; DEFINEcarry_out := value & carry_in;

  20. Module Composition • Synchronous composition • All assignments are executed in parallel and synchronously. • A single step of the resulting model corresponds to a step in each of the components. • Asynchronous composition • A step of the composition is a step by exactly one process. • Variables, not assigned in that process, are left unchanged.

  21. Asynchronous Composition MODULE main VARgate1: process inverter(gate3.output); gate2: process inverter(gate1.output); gate3: process inverter(gate2.output); SPEC (AG AFgate1.output) & (AG AF!gate1.output) MODULE inverter(input) VAR output: boolean; ASSIGN init(output) := 0; next(output) := !input;

  22. Fairness • FAIRNESS ctl_formulae • Assumed to be true infinitely often • Model checker only explores paths satisfying fairness constraint • Each fairness constraint must be true infinitely often • If there are no fair paths • All existential formulas are false • All universal formulas are true • FAIRNESSrunning

  23. With Fairness.. MODULE main VARgate1: process inverter(gate3.output); gate2: process inverter(gate1.output); gate3: process inverter(gate2.output); SPEC (AG AFgate1.output) & (AG AF!gate1.output) MODULE inverter(input) VAR output: boolean; ASSIGN init(output) := 0; next(output) := !input; FAIRNESS running

  24. Counter revisited MODULE main VAR count_enable : boolean; bit0 : counter_cell(count_enable); bit1 : counter_cell(bit0.carr_out); bit2 : counter_cell(bit1.carry_out); SPEC AG AF bit2.carry_out FAIRNESS count_enable

  25. Synchronous vs Asynchronous • In Asynchronous process, need not combine transition relation of each process • Complexity of representing set of states reachable in n steps higher in asynchronous processes occassionally due to higher number of interleavings

  26. Implicit Modelling • TRANS - boolean valued expr restricting transition relation of system • INIT - boolean valued expression giving initial states • INVAR - boolean valued expression restricting set of all states of model

  27. Implicit Modelling Example MODULE main VAR gate1 : inverter(gate3.output); gate2 : inverter(gate1.output); gate3 : inverter(gate2.output); SPEC (AG AF gate1.out) & (AG AF !gate1.out) MODULE inverter(input) VAR Output : boolean; INIT output = 0; TRANS next(output) = !input | next(output) = output

  28. TRANS Advantages • Group assignments to different variables • Good for modelling guarded commands Disadvantages • Logical absurdities can lead to unimplementable descriptions

  29. Shared Data Example Two Users assign pid to shared data in turn MODULE main VAR data : boolean; turn : boolean; user0 : user(0, data, turn); user1 : user(1, data, turn); ASSIGN next(turn) := !turn; SPEC AG (AF data & AF (!data))

  30. Shared data example (cont..) Using ASSIGN and CASE statement won’t work(constraining sema all the time) MODULE user(pid, data, turn) ASSIGN next(data) := case turn: pid; 1 : data; esac; Line 3: multiple assignment: next(data)

  31. Using TRANS TRANS useful for changing shared data in synchronous system between modules. MODULE user(pid, turn, data) TRANS turn -> next(data) = pid

  32. Guarded Commands Guard1 : action1 Guard2 : action2 .. Otherwise nop TRANS (guard1 & action1)| (guard2 & action2)| … (!guard1 & !guard2 & … & “nop”)

  33. TRANS Pitfall True -> next(b) = 0 & True -> next(b) = 1 & … Results in an empty transition relation

  34. TRANS Guidelines • Try using ASSIGN instead • Write in a disjunction of conjunction format • Try covering all cases • Try make guards disjoint

  35. SMV Steps • Read_Model : read model from input smv file • Flatten_hierarchy : instantiate modules and processes • Build_model : compile the model into BDDs (initial state, invar, transition relation) • Check_spec : checking specification bottom up

  36. Run SMV • smv [options] inputfile • -c cache-size for BDD operations • -k key-table-size for BDD nodes • -v verbose • -int interactive mode • -r • prints out statistics about reachable state space

  37. SMV Options • –f • computes set of reachable states first • Model checking algorithm traverses only the set of reachable states instead of complete state space. • useful if reachable state space is a small fraction of total state space

  38. SMV Options: Reordering vars • Variable reordering is crucial for small BDD sizes and speed. • Generally, variables which are related need to be close in the ordering. • –i filename –o filename • Input, output BDD variable ordering to given file. • -reorder • Invokes automatic variable reordering

  39. SMV Options: Transition relation smv -cp part_limit • Conjunctive Partitioning: Transition relation not evaluated as a whole, instead individual next() assignments are grouped into partitions that do not exceed part_limit • Uses less memory and benefits from early quantification

  40. SMV options: -inc • Perform incremental evaluation of the transition relation • At each step in forward search, transition relation restriced to reached state set • Cuts down on size of transition relation with overhead of extra computation

  41. Example: Client & Server MODULE client (ack) VAR state : {idle, requesting}; req : boolean; ASSIGN init(state) := idle; next(state) := case state=idle : {idle, requesting}; state=requesting & ack : {idle, requesting}; 1 : state; esac; req := (state=requesting);

  42. MODULE server (req) VAR state : {idle, pending, acking}; ack : boolean; ASSIGN next(state) := case state=idle & req : pending; state=pending : {pending, acking}; state=acking & req : pending; state=acking & !req : idle; 1 : state; esac; ack := (state = acking);

  43. Is the specification true? MODULE main VAR c : client(s.ack); s : server(c.req); SPEC AG (c.req -> AF s.ack) • Need fairness constraint: • Suggestion:FAIRNESS s.ack • Why is this bad? • Solution:FAIRNESS (c.req -> s.ack)

  44. NuSMV • Specifications expressible in CTL, LTL and Real time CTL logics • Provides both BDD and SAT based model checking. • Uses a number of heuristics for achieving efficiency and control state explosion • Higher number of features in interactive mode

  45. Cadence SMV • Provides “compositional techniques” to verify large complex systems by decomposition to smaller problems. • Provides a variety of techniques for refinement verification, symmetry reductions, uninterpreted functions, data type reductions.

  46. Useful Links • SMV sources, binaries and manualshttp://www.cs.cmu.edu/~modelcheck/smv.html • SMV man page http://www.cs.cmu.edu/~dongw/smv.txt • SMV manualhttp://www.cs.cmu.edu/~modelcheck/smv/smvmanual.ps • Tutorial on verification techniques using Cadence SMVhttp://www-cad.eecs.berkeley.edu/~kenmcmil/tutorial.ps • SMV Input Language documentationhttp://www-cad.eecs.berkeley.edu/~kenmcmil/psdoc.html

  47. Downloads • SMV www.cs.cmu.edu/~modelcheck/smv.html • NuSMV http://nusmv.irst.itc.it/ • Cadence SMV http://wwwcad.eecs.berkeley.edu/~kenmcmil/smv

More Related