Introduction to SMV

Arie Gurfinkel (SEI/CMU)

based on material by Prof. Clarke and

others

© 2011 Carnegie Mellon University

Symbolic Model Verifier (SMV)

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 ROBDDs

Automatically verifies specification or produces a

counterexample

2/18/2005
2
© 2011 Carnegie Mellon University 2
 Overview of SMV
SMV Input
Language Backend

Finite
State
Kripke OBDD based Yes
Structure Symbolic Model
Checking

Specification –
CTL Formula
No

CounterExample

2/18/2005
3
© 2011 Carnegie Mellon University 3
 SMV Variants

Cadence
SMV

NuSMV
l Strong abstraction functions
CMU l GUI
SMV
l New language
Two versions
l 2.x: Open Source, many
l Oldest Version new features, BDD and SAT
l No GUI based backends
l 1.x: Original version, had a
GUI

© 2011 Carnegie Mellon University 4

NuSMV2 Architecture

© 2011 Carnegie Mellon University 5

SMV Language

Allows description of completely synchronous to

asynchronous systems, detailed to abstract systems

Modularized and hierarchical descriptions

Finite data types: Boolean and enumerated

Parallel-assignment syntax

Non-determinism

© 2011 Carnegie Mellon University 6

A Sample SMV Program (short.smv)

MODULE  main  
VAR  
         request:  boolean;  
         state:  {ready,  busy};  
ASSIGN  
         init(state)  :=  ready;  
         next(state)  :=    
 case  
     state=ready  &  request:  busy;  
     TRUE  :  {ready,  busy};  
 esac;  
SPEC  AG(request  -­‐>  AF  (state  =  busy))  

2/18/2005
7
© 2011 Carnegie Mellon University 7
 Kripke structure Computation tree

ready
request
ready busy
!request !request
busy busy
!request request

holds after one step

busy
request
ready busy
request request
holds in the initial state

AG(request  -­‐>  AF  (state  =  busy))

8 © 2011 Carnegie Mellon University 8

A Sample SMV Program (short.smv)
MODULE  main   what if AF is
VAR   changed to AX ?
         request:  boolean;  
         state:  {ready,  busy};  
ASSIGN  
         init(state)  :=  ready;  
         next(state)  :=    
 case  
   state=ready  &  request:  busy;  
   TRUE            :  {ready,  busy};  
 esac;  
 
SPEC  AG(request  -­‐>  AX  (state  =  busy))  

2/18/2005
9
© 2011 Carnegie Mellon University 9
 AG(request  -­‐>  AX  (state  =  busy))  is false

ready busy
!request !request

ready busy
request request

10 © 2011 Carnegie Mellon University 10

SMV Syntax: Expressions

Expr  ::    
               atom                                            -­‐-­‐  symbolic  constant  
           |  number                                        -­‐-­‐  numeric  constant  
           |  id                                                -­‐-­‐  variable  identifier  
           |  “!”  Expr                                    -­‐-­‐  logical  not  
           |  Expr  &  Expr        -­‐-­‐  logical  and  
           |  Expr  |  Expr                              -­‐-­‐  logical  or    
           |  Expr  -­‐>  Expr                            -­‐-­‐  logical  implication  
           |  Expr  <-­‐>  Expr                          -­‐-­‐  logical  equivalence  
           |  “next”  “(“  id  “)”                  -­‐-­‐  next  value  
           |  Case_expr                            
           |  Set_expr  
 

© 2011 Carnegie Mellon University 11

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

Cases must be exhaustive

It is an error if all expressions on the left hand side evaluate to FALSE

© 2011 Carnegie Mellon University 12

Variables and Assignments

Decl  ::  “VAR”  

                   atom1  “:”  type1  “;”  
                   atom2  “:”  type2  “;”  
                         …  
 
Decl  ::  “ASSIGN”    
                   dest1  “:=“  Expr1  “;”  
                   dest2  “:=“  Expr2  “;”  
                               …  
Dest  ::            atom        -­‐-­‐  current  
                     |  “init”  “(“  atom  “)”    -­‐-­‐  initial    
                     |  “next”  “(“  atom  “)”    -­‐-­‐  next-­‐state    
 

© 2011 Carnegie Mellon University 13

Variables and Assignments (cont’d)

State is an assignment of values to a set of state variables

Type of a variable – boolean, scalar, user defined module, or array.

Assignment to initial state:

• init(value)  :=  FALSE;  
Assignment to next state (transition relation)
• next(value)  :=  value  xor  carry_in;  
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

© 2011 Carnegie Mellon University 14

Circular Definitions

… are not allowed

init(a)  :=  0;  

a              :=  next(b);   next(a)  :=  !b;  
next(b)  :=  c;    
c              :=  a;   init(b)  :=  1;  
next(b)  :=  !a;  

© 2011 Carnegie Mellon University 15

Nondeterminism

Completely unassigned variable model unconstrained input

{val_1,  …,  val_n}  is an expression taking on any of the

given values nondeterministically
• next(b)  :=  {TRUE,  FALSE};  

Nondeterministic choice can be used to:

• Model an environment that is outside of the control of the system
• Model an implementation that has not been refined yet
• Abstract behavior

© 2011 Carnegie Mellon University 16

ASSIGN and DEFINE

VAR  a:  boolean;  

ASSIGN  a  :=  b  |  c;  

• declares a new state variable a

• becomes part of invariant relation

DEFINE  d  :=  b  |  c;  

• 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

© 2011 Carnegie Mellon University 17

SPEC Declaration

Decl        ::  “SPEC”  ctlform  

 
Ctlform  ::      expr                                      -­‐-­‐  bool  expression  
                     |  “!”  ctlform  
                     |  Ctlform  <op>  Ctlform  
                     |  “E”  Pathform  
                     |  “A”  Pathform  
 
Pathform  ::    “X”  Ctlform  
                     |  “F”  Ctlform  
                     |  “G”  Ctlform  
                     |  Ctlform  “U”  Ctlform  

© 2011 Carnegie Mellon University 18

Modules

Modules can be instantiated many times, each instantiation

creates a copy of the local variables

Each program must have a module main

Scoping
• Variables declared outside a module can be passed as
parameters

Parameters are passed by reference.

© 2011 Carnegie Mellon University 19

Pass by reference

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

20
© 2011 Carnegie Mellon University 20
Pass by reference

VAR  
     a  :  boolean;  
VAR  
     b  :  foo(a);  
   a      :  boolean;  
…  
   b.y  :  boolean;  
MODULE  foo(x)  
ASSIGN  
VAR    
   a      :=  TRUE;  
     y  :  boolean;  
   b.y  :=  FALSE;  
ASSIGN    
 
     x  :=  TRUE;  
     y  :=  FALSE;  

21
© 2011 Carnegie Mellon University 21
A Three-Bit Counter
MODULE  main  
VAR  
   bit0  :  counter_cell(TRUE);  
   bit1  :  counter_cell(bit0.carry_out);  
   bit2  :  counter_cell(bit1.carry_out);  
 
SPEC    AG  AF  bit2.carry_out  
 
MODULE  counter_cell(carry_in)  
VAR  
   value  :  boolean;  
ASSIGN  
   init(value)  :=  FALSE;   value  +  carry_in  mod  2  
   next(value)  :=  value  xor  carry_in;  
DEFINE  
   carry_out  :=  value  &  carry_in;  

© 2011 Carnegie Mellon University 22

 module instantiations

val
in out
bit0

module declaration

val val
in out in out
bit1

val
in out
bit2

© 2011 Carnegie Mellon University 23

 AG AF bit2.carry_out is true

in 1 1 1 1 1 1 1 1 1
bit0 val 0 1 0 1 0 1 0 1 0
out 0 1 0 1 0 1 0 1 0

in 0 1 0 1 0 1 0 1 0
bit1 val 0 0 1 1 0 0 1 1 0
out 0 0 0 1 0 0 0 1 0

in 0 0 0 1 0 0 0 1 0
bit2 val 0 0 0 0 1 1 1 1 0
out 0 0 0 0 0 0 0 1 0

bit2.carry_out is ture

© 2011 Carnegie Mellon University 24

A Three-Bit Counter
MODULE  main  
VAR  
   bit0  :  counter_cell(TRUE);  
   bit1  :  counter_cell(bit0.carry_out);  
   bit2  :  counter_cell(bit1.carry_out);  
 
SPEC  AG  (!bit2.carry_out)  
 
MODULE  counter_cell(carry_in)  
VAR  
   value  :  boolean;  
ASSIGN  
   init(value)  :=  FALSE;  
   next(value)  :=  value  xor  carry_in;  
DEFINE  
   carry_out  :=  value  &  carry_in;  

© 2011 Carnegie Mellon University 25

 AG (!bit2.carry_out) is false

in 1 1 1 1 1 1 1 1 1
bit0 val 0 1 0 1 0 1 0 1 0
out 0 1 0 1 0 1 0 1 0

in 0 1 0 1 0 1 0 1 0
bit1 val 0 0 1 1 0 0 1 1 0
out 0 0 0 1 0 0 0 1 0

in 0 0 0 1 0 0 0 1 0
bit2 val 0 0 0 0 1 1 1 1 0
out 0 0 0 0 0 0 0 1 0

bit2.carry_out is ture

© 2011 Carnegie Mellon University 26

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.

© 2011 Carnegie Mellon University 27

Inverter Ring
MODULE  main  
VAR  
   gate1  :  process  inverter(gate3.output);  
   gate2  :  process  inverter(gate1.output);  
   gate3  :  process  inverter(gate2.output);  
 
SPEC  (AG  AF  gate1.output)  &  (AG  AF  !gate1.output)  
 
MODULE  inverter(input)  
VAR  
   output  :  boolean;  
ASSIGN  
   init(output)  :=  FALSE;  
   next(output)  :=  !input;  
 
FAIRNESS  
   running  

© 2011 Carnegie Mellon University 28

 In asynchronous composition, a step of the computation is
a step by exactly one component. The process to execute
is assumed to choose gate0, gate1, and gate2 repeatedly.

in 0 0 0 1 1 1 0 0 0 1
gate0 out 0 1 1 0 0 0 1 1 1 0

in 0 1 1 1 0 0 0 1 1 1
gate1
out 0 0 0 0 1 1 1 0 0 0

in 0 0 0 0 0 1 1 1 0 0
gate2
out 0 0 1 1 1 0 0 0 1 1

(AG AF gate1.output) & (AG AF !gate1.output) is true

© 2011 Carnegie Mellon University 29

Fairness

FAIRNESS  Ctlform  

• 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

FAIRNESS  running  

© 2011 Carnegie Mellon University 30

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
occasionally due to higher number of interleavingn

SMV models asynchronous composition by a

synchronous one

© 2011 Carnegie Mellon University 31

Implicit Modeling

INIT  Expr  

Boolean valued expression giving initial states

INVAR  Expr    

Boolean valued expression restricting set of all states of model

TRANS  Expr  

Boolean valued expression restricting transition relation of system

© 2011 Carnegie Mellon University 32

Implicit Modeling 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  =  FALSE;  
TRANS    
 next(output)  =  !input  |  next(output)  =  output  
 

© 2011 Carnegie Mellon University 33

TRANS

Advantages
• Group assignments to different variables
• Good for modeling guarded commands
– IF guard THEN new state

Disadvantages
• Logical absurdities can lead to unimplementable
descriptions

© 2011 Carnegie Mellon University 34

Shared Data Example
Two users assign PID to Data in turn

MODULE  main   MODULE  user(pid,  data,  turn)  

VAR    
ASSIGN    
     data  :  boolean;  
     turn  :  {0,1};    next(data)  :=    
     user0  :  user(0,  data,  turn);      case  
     user1  :  user(1,  data,  turn);          turn=pid  :  pid;  
ASSIGN            TRUE          :  data;  
     next(turn)  :=  !turn;      esac;  
SPEC    
     AG  (AF  data  &  AF  (!data))  

Error:  multiple  assignment:  next(data)  

© 2011 Carnegie Mellon University 35

Shared Data Example with TRANS

MODULE  main   MODULE  user(pid,  data,  turn)  

VAR    
TRANS  
     data  :  boolean;  
     turn  :  {0,1};      turn=pid  -­‐>  next(data)  =  pid;  
     user0  :  user(0,  data,  turn);  
     user1  :  user(1,  data,  turn);  
ASSIGN    
     next(turn)  :=  !turn;  
SPEC  
     AG  (AF  data  &  AF  (!data))  
 
 

© 2011 Carnegie Mellon University 36

TRANS Pitfalls
TRANS  
     TRUE  -­‐>  next(b)  =  0  &  
     TRUE  -­‐>  next(b)  =  1  &  …  

Inconsistencies in TRANS result in an empty

transition relation

All universal properties are satisfied

All existential properties are refuted

© 2011 Carnegie Mellon University 37

TRANS Guidelines

Use ASSIGN if you can!

Validate your model with simulation and sanity checks

Check that transition relation is total (-ctt option)

Write in a disjunction of conjunction format

Cover all cases

Make guards disjoint

© 2011 Carnegie Mellon University 38
MODULE  main   next  (send)  :=     next  (ack)  :=  
         case        case  
VAR              send=s0:{s0,s1};            recv=r2:TRUE;  
   send  :  {s0,s1,s2};              send=s1:s2;            TRUE:  ack;  
   recv  :  {r0,r1,r2};              send=s2&ack:s0;        esac;  
             TRUE:send;    
   ack  :  boolean;          esac;      next  (req)  :=    
   req  :  boolean;            case  
         next  (recv)  :=                send=s1:FALSE;  
ASSIGN          case              TRUE:  req;  
 init(ack):=FALSE;              recv=r0&req:r1;          esac;  
 init(req):=FALSE;              recv=r1:r2;  
             recv=r2:r0;  
 init(send):=  s0;              TRUE:  recv;  
 init(recv):=  r0;          esac;  

SPEC  AG  (req  -­‐>  AF  ack)  

© 2011 Carnegie Mellon University 39

Can A TRUE Result of Model Checker be Trusted

Antecedent Failure [Beatty & Bryant 1994]

• A temporal formula AG (p ⇒ q) suffers an antecedent
failure in model M iff M ⊧ AG (p ⇒ q) AND M ⊧ AG (¬p)

Vacuity [Beer et al. 1997]

• A temporal formula ϕ is satisfied vacuously by M iff there
exists a sub-formula p of ϕ such that M ⊧ ϕ[p←q] for every
other formula q
• e.g., M ⊧ AG (r ⇒ AF a) and M ⊧ AG (r ⇒ AF ¬a) and
AG (r ⇒ AF ¬r) and AG (r ⇒ AF FALSE), …

© 2011 Carnegie Mellon University 40

Vacuity Detection: Single Occurrence

ϕ is vacuous in M iff there exists an occurrence of a

subformula p such that
• M ⊧ ϕ[p ← TRUE] and M ⊧ ϕ[p ← FALSE]

M ⊧ AG (req ⇒ AF TRUE) M ⊧ AG (req ⇒ AF FALSE)

M ⊧ AG TRUE M ⊧ AG ¬req

M ⊧ AG (TRUE ⇒ AF ack) M ⊧ AG (FALSE ⇒ AF ack)

M ⊧ AG AF ack M ⊧ AG TRUE

© 2011 Carnegie Mellon University 41

Detecting Vacuity in Multiple Occurrences

Is AG (req ⇒ AF req) vacuous? Should it be?

M ⊧ AG (TRUE ⇒ AF TRUE) M ⊧ AG (FALSE ⇒ AF FALSE)

M ⊧ AG TRUE M ⊧ AG TRUE

Is AG (req ⇒ AX req) vacuous? Should it be?

M ⊧ AG (TRUE ⇒ AX TRUE) M ⊧ AG (FALSE ⇒ AX FALSE)

M ⊧ AG TRUE M ⊧ AG TRUE

© 2011 Carnegie Mellon University 42

Detecting Vacuity in Multiple Occurrences: ACTL

An ACTL ϕ is vacuous in M iff there exists an a

subformula p such that
• M ⊧ ϕ[p ← x] , where x is a non-deterministic variable
Is AG (req ⇒ AF req) vacuous? Should it be?

M ⊧ AG (x ⇒ AF x) Always vacuous!!!
M ⊧ AG TRUE

Is AG (req ⇒ AX req) vacuous? Should it be?

M ⊧ AG (x ⇒ AX x) Can be vacuous!!!
can’t reduce

© 2011 Carnegie Mellon University 43

Run NuSMV

NuSMV  [options]  inputfile  

• -­‐int    interactive  mode  
• -­‐lp    list  all  properties  
• -­‐n  X    check  property  number  X  
• -­‐ctt  check  totality  of  transition  relation  
• -­‐old  compatibility  mode  
• -­‐ofm  file  output  flattened  model      

© 2011 Carnegie Mellon University 44

Using NuSMV in Interactive Mode

Basic Usage
• go  
– prepare model for verification
• check_ctlspec  
– verify properties

Simulation
• pick_state  [-­‐i]  [-­‐r]  
– pick initial state for simulation [interactively] or [randomly]
• simulate  [-­‐i]  [r]  s  
– simulate the model for ‘s’ steps [interactively] or [randomly]
• show_traces  
– show active traces

© 2011 Carnegie Mellon University 45

Useful Links

NuSMV home page

• http://nusmv.fbk.eu/
NuSMV tutorial
• http://nusmv.fbk.eu/NuSMV/tutorial/v25/tutorial.pdf
NuSMV user manual
• http://nusmv.fbk.eu/NuSMV/userman/v25/nusmv.pdf
NuSMV FAQ
• http://nusmv.fbk.eu/faq.html
NuSMV on Andrew
• /afs/andrew.cmu.edu/usr6/soonhok/public/NuSMV-zchaff-2.5.3-x86_64-redhat-
linux-gnu/
NuSMV examples
• <NuSMV>/share/nusmv/examples
Ken McMillan, Symbolic Model Checking: An Approach to the State
Explosion Problem, 1993
• http://www.kenmcmil.com/pubs/thesis.pdf

© 2011 Carnegie Mellon University 46