supratik chakraborty iit bombay - ernetsak/courses/foav/model-checking-basics.pdf · may 13, 2005...

1

ModelModel CheckingChecking

Supratik Chakraborty

IIT Bombay

May 13, 2005 NWCV 2005, DA-IICT 2

Why Model Check?Why Model Check?

Widespread use of complex hardware systemsIncorrect operation highly undesirable

Safety, economic … reasonsCan we mathematically prove thata model of the system satisfies aformal property?

Large class of practical systemsSystem model: Finite stateProperty: Temporal logic formula

Above question answerable automaticallyMethod involved: Model checking

BUS

Arbiter

Peripheral

Peripheral

Peripheral

May 13, 2005 NWCV 2005, DA-IICT 3

A Glimpse of Capability A Glimpse of Capability

PCI Bus3 peripherals, 1 arbiterPeripheral: Application controller +

Bus interface controller Arbiter: Fixed arbitration schemeBus: Negligible delays

Global behaviourComposition of component FSMs

Properties verifiable using model checking:For arbitrary sequences of bus transactions

Only one peripheral can be master at any timeA peripheral requesting to be master eventually becomes one ...

BUS

Arbiter

Peripheral

Peripheral

Peripheral

May 13, 2005 NWCV 2005, DA-IICT 4

OutlineOutline

What is Model Checking?Modeling basicsProperty specification in temporal logicCTL model checkingRelated techniquesConclusion

May 13, 2005 NWCV 2005, DA-IICT 5

What is Model Checking?What is Model Checking?

Given:Finite state model of system: M

An abstraction of system behaviourA temporal logic formula: ϕ

Specification of desired propertyDetermine:

Does M satisfy ϕ: M ϕ ?Logic vocabulary: “ Is M a model of ϕ ? ”Hence “ model checking ”

Yes ⇒ System model exhibits specified propertyNo ⇒ System model violates property

Counterexample trace desirable

May 13, 2005 NWCV 2005, DA-IICT 6

Model Checking Basics Model Checking Basics

Three essential componentsFormalism for system modeling (M)Formalism for property specification (ϕ)Automatic decision procedure to check if M ϕ

Additional desirable features for practical useCounterexample generation in case M ϕ

Useful for debugging, understanding errorsIntuitive (at least partial) nature of formalismsComputational efficiency

May 13, 2005 NWCV 2005, DA-IICT 7

OutlineOutline


May 13, 2005 NWCV 2005, DA-IICT 8

Modeling System Modeling System BehaviourBehaviour

Model: Abstraction of actual behaviourChoice of right level of abstraction important

a

b

c

clk

System

clk

c

b

a

Behaviour at low abstr level

000 001 010 011

100101110111

Behaviour at higher abstr level

abc

May 13, 2005 NWCV 2005, DA-IICT 9

Modeling System Modeling System BehaviourBehaviourChoosing right level of abstraction

Depends on property of interestModel must have details relevant for checking propertyDetails unrelated to property to be abstracted away

Property: When c is at 0.5V, clk can’t be at 1V

Property: a,b,c have logic 1 value infinitely often

a

b

c

clk

clkc

ba

000 001 010 011

100101110111

abc

May 13, 2005 NWCV 2005, DA-IICT 10

Modeling System Modeling System BehaviourBehaviour

Level of abstraction must be judiciously chosen

A model is not the same as the original systemModel checking determines if the model satisfies a property

Distinct from checking if actual system satisfies propertyWith incorrect models, spurious conclusions about system behaviour may resultChoosing a correct model for checking a property crucial

Abstraction levelLow High

Details of physical behaviour representedHigh Low

Computational complexity of analyzing modelHigh Low

Sizes of systems model checkable in practiceSmall Large

May 13, 2005 NWCV 2005, DA-IICT 11

Modeling In Design FlowModeling In Design FlowA (pre-) design activity

Start with highest level model (ignoring most impl. details)Model check against desired properties

Allows early detection of bugsExposes design errors even before implementationAllows easier exploration of design space

If no bugs foundRefine model to next lower level

Introduce some more impl detailsIf bugs found

Fix bugs at current level of abstractionRepeat model checking step & refine until impl obtained

May 13, 2005 NWCV 2005, DA-IICT 12

Formal ModelingFormal Modeling

Formal Model: Description of behaviour in a formal languageWell-defined syntax Mathematically precise semantics

Examples of formal modeling languages: Finite State MachinesCSP, CCS, SDL, Promela, SMV (Async systems/protocols)

SMV, mv_blif, Verilog, VHDL (Synchr sequential circuits)Esterel, Signal (Embedded controllers)

Statecharts, UML (System level modeling) ...

May 13, 2005 NWCV 2005, DA-IICT 13

Formal ModelingFormal Modeling

Features of a good modeling languageHigh level data typesAbility to represent non-determinism & concurrency Ability to model communication between componentsAbility to represent fairness in execution

We’ll focus on conceptually simplest formalism

Finite state machinesMany variants

Edge labeled - Mealy machinesState labeled - Kripke structuresState and edge labeled - Moore machines

May 13, 2005 NWCV 2005, DA-IICT 14

Models of Hardware CircuitsModels of Hardware Circuits

Hardware blocks are reactive systemsContinuous interaction with environmentBehaviour never terminates; infinite behaviourTiming and causality information importantDifferent from transformational systems

Modeling with FSMs:States determined by values of latches and flip-flopsFinite no. of latches / flip-flops

Finite no. of states: Could be very large though!No final state; no termination of behaviourEdge labels: input/condition and output/action

May 13, 2005 NWCV 2005, DA-IICT 15

An ExampleAn ExampleA Traffic Light Controller

States: Highway green, side road redC - Car in side road, S,L - Short and long timer signalsT,G,R - reset timer, set highway green and side road red

C,L/T,Y,R ~S/Y,R

S/T,R,G

C,~L/R,G~C + L/T,R,Y

~C + ~L/Y,R

~S/R,Y

S/G,R

May 13, 2005 NWCV 2005, DA-IICT 16

NonNon--determinismdeterminism

reqi - request from Master iAbstract model is nondeterministic

In Idle state when req1 and req2 arriveNon-determinism due to abstractionMore than one behaviour for a given input: req1,req2

req1

req2

req2,rel1req1,rel2

rel2, ~req1

rel1, ~req2

chg,~req2

chg,~req1

2-master Arbiter - Detailed

req1

req2

req2,rel1req1,rel2

rel2, ~req1

rel1, ~req2Idle

2-master Arbiter - Abstract

May 13, 2005 NWCV 2005, DA-IICT 17

ConcurrencyConcurrencyA concurrent (and hierarchical) description of 3-bit counter (Statechart syntax)

May 13, 2005 NWCV 2005, DA-IICT 18

Concurrent DescriptionsConcurrent Descriptions

Compact and easy to understandNatural model for hardware and complex systemsClear semantics required

Interleaved model and synchronous modelsAppropriate communication primitivesConcurrent machines composed to yield a single global machineGlobal machine captures all possible executions

Exponential blow-up

May 13, 2005 NWCV 2005, DA-IICT 19

Fairness ConstraintsFairness Constraints

Not every run of FSM model may be validExample:

Abstract arbiterRun that never grants request of master 2

Eliminate such runs without complicating modelFairness constraints rule out certain runs

Models effect of schedulers

Fairness constraints:Every request eventually consideredchg arrives infinitely often

req1

req2

req2,rel1req1,rel2

rel2, ~req1

rel1, ~req2Idle

2-master Arbiter - Abstract

May 13, 2005 NWCV 2005, DA-IICT 20

Fairness ConstraintsFairness Constraints

Not required with a more concrete descriptionBut concrete description too complex to verifyA given property may not require concrete detailsFor verification, abstract designs are preferable

Proof is simplerProof is robust under alternate implementationsFairness constraints eliminate invalid runs without complicating model

May 13, 2005 NWCV 2005, DA-IICT 21

Semantics of Finite State SystemsSemantics of Finite State Systems

Semantics associates behaviorsBranching Time semantics

Tree of states obtained by unwinding the state transition graph

......

......

......

......

State transition graph

Infinite computation tree

May 13, 2005 NWCV 2005, DA-IICT 22

Semantics of Finite State SystemsSemantics of Finite State SystemsLinear Time Semantics

Set of all possible `runs' of the system

State transition graph

......

...Set of infinite runs

. . .. . .

. . .

May 13, 2005 NWCV 2005, DA-IICT 23

Generating Formal ModelsGenerating Formal Models

Automatic translation from circuits/HDL descriptionsStates decided by the latches/registers in the circuitExponential blow-up in size (state-explosion problem)Usually abstractions required

Tools automatically extract finite state model from high-level descriptions

VHDL, Verilog SMVmv_blif ….

May 13, 2005 NWCV 2005, DA-IICT 24

OutlineOutline


May 13, 2005 NWCV 2005, DA-IICT 25

Formal SpecificationsFormal Specifications

Model checking: Does a design model meets its specification?

Specification states what the system is supposed to doModel describes how this is done

SpecificationDescribes unambiguously and precisely the expected behavior of a designIn general, a list of propertiesIncludes environment constraintsSymbolic logic or automata formalismsConsistency and Completeness

May 13, 2005 NWCV 2005, DA-IICT 26

Specification of Hardware blocksSpecification of Hardware blocksProperties and constraints specify possible states and transitions

They state set of possible valid `runs'Valid runs:

Infinite sequences or trees of statesFormal specifications:

Properties over infinite sequences or treesClassification of Properties:

Safety properties• "undesirable states are never reached",• "desirable things always happen".

Progress or Liveness Properties• "desirable state repeatedly reached"• "desirable state eventually reached"

May 13, 2005 NWCV 2005, DA-IICT 27

ExamplesExamplesSafety Properties

A bus arbiter never grants requests to two mastersMessage received is always the message sentElevator does not reach a floor unless it is requestedAt any time traffic is let either in the farm road or in the highwayEvery received message was actually sent

Liveness PropertiesCar on farm road is eventually allowed to passElevator attends to every request eventuallyEvery bus request is eventually grantedEvery sent message was received

May 13, 2005 NWCV 2005, DA-IICT 28

Specification FormalismsSpecification Formalisms

Behaviours are infinite runs or trees (reactive systems)Need finite representation of such infinite objects Two major formalisms:

Temporal Logics: Linear and Branching Time Temporal Logics

Automata

May 13, 2005 NWCV 2005, DA-IICT 29

Temporal LogicsTemporal LogicsLogics well-known for precise specification

Amenable to symbolic manipulationsUsed in a variety of contexts:

Propositional Logic/Boolean algebra for combinational HWPredicate logic for softwareHigher order logics for language semanticsTemporal logics for hardware and protocols

Qualitative temporal statementsExamples:

If it is cloudy, eventually it will rainIt never rains here

May 13, 2005 NWCV 2005, DA-IICT 30

Properties of Hardware BlocksProperties of Hardware Blocks

Temporal in natureAt any time only one unit is accessing the busEvery request to access the bus is eventually granted.

Two Kinds of Temporal LogicsLinear Temporal Logic (LTL):

Time is a linear sequence of eventsBranching time temporal logic (CTL, CTL*):

Time is a tree of events

May 13, 2005 NWCV 2005, DA-IICT 31

Computational Tree Logic (CTL)Computational Tree Logic (CTL)

CTL formulae describe properties of Computation TreesComputation Trees are obtained by unwinding the transition system modelBranching structure due to nondeterminismCTL is the simplest branching temporal logicCTL* is more powerful, subsumes CTL

Won’t cover in this tutorial

May 13, 2005 NWCV 2005, DA-IICT 32

Syntax of CTLSyntax of CTL

Every atomic proposition is a CTL formulaIf f and g are formulae then so are

¬f, (f ∧ g), (f ∨ g), (f → g), (f ↔ g)AG f : in all paths, in all states f holds (in all future f)EG f : in some path, in all states f holdsAF f : in all paths, in some state f holds (in every future f)EF f : in some future, f holdsA(f U g) : in all paths, f holds until gE(f U g) : in some path, f holds until gAX f : in every next state, f holdsEX f : in some next state, f holds ...

May 13, 2005 NWCV 2005, DA-IICT 33

ExamplesExamples

AG ¬ (farm_go ∧ high_go_B)AGAF (farm_car → AF(farm_go))AG (mem_wr U mem_ack)EF (req0 U grant0 )

May 13, 2005 NWCV 2005, DA-IICT 34

OutlineOutline


May 13, 2005 NWCV 2005, DA-IICT 35

OutlineOutline

What is Model Checking?Modeling basicsProperty specification in temporal logicCTL model checking

Explicit-state model checkingSymbolic model checking

Boolean function representationModel checking algorithm

Related techniquesConclusion

May 13, 2005 NWCV 2005, DA-IICT 36

CTL model checkingCTL model checking

[Clarke and Emerson, Clarke, Emerson and Sistla, Quielle and Sifakis]

GivenFinite state transition system (Kripke structure) MCTL formula ϕ

There is an O(|M|.|ϕ|) algorithm to check if M ϕ

May 13, 2005 NWCV 2005, DA-IICT 37

EXAMPLEEXAMPLE

Which of the following hold ?AG p, EF¬q, AX p, AG ¬q, EG ¬q, AX(p ∨ q)

May 13, 2005 NWCV 2005, DA-IICT 38

ExplicitExplicit--state CTL Model Checkingstate CTL Model Checking

Iterative labeling algorithm that labels all the states with sub formulaeStart from initial labels: atomic propositionsIteratively add sub formulae as labels of each state based on the following equations:

EF p = p ∨ EX p ∨ EX(EX p) ∨ . . . EG p = p ∧ EX p ∧ EX(EX p) ∧ . . . E (q U p) = p ∨ (q ∧ EX p)

∨ (q ∧ EX(q ∧ EX p))∨ . . .

May 13, 2005 NWCV 2005, DA-IICT 39

CTL Model CheckingCTL Model Checking

Iteration terminates since states and subformulae are finite.If initial states of model are labeled with the given formula then model checking succeedsIf it fails, counterexample can be generated

May 13, 2005 NWCV 2005, DA-IICT 40

Computing EF pComputing EF p

To compute EF p which is:

EF p = p ∨ EX(p) ∨ EX(EX(p)) ∨ . . .

May 13, 2005 NWCV 2005, DA-IICT 41


Iterative computationI step :

May 13, 2005 NWCV 2005, DA-IICT 42


II step :

III step :

May 13, 2005 NWCV 2005, DA-IICT 43


Computation terminates EF p: Holds in all striped statesComputation involves backward breadth first traversal and calculation of Strongly Connected Subgraphs (cycles)

May 13, 2005 NWCV 2005, DA-IICT 44

Computing EG p Computing EG p

EG p = p ∧ EX p ∧ EX(EX p) ∧ . . .

May 13, 2005 NWCV 2005, DA-IICT 45

Computing EG pComputing EG p

Start with

I iteration

May 13, 2005 NWCV 2005, DA-IICT 46

Computing EG pComputing EG p

II iteration

III iteration

Iteration terminates

May 13, 2005 NWCV 2005, DA-IICT 47

Is This Sufficient Enough?Is This Sufficient Enough?

Algorithm involves backward traversalLinear on sizes of both formula and modelSize of model: Exponential in number of latches !!!

Small sized systems verifiableReduction techniques:

Symbolic model checking Compositional verificationSymmetry based reductionPartial order reduction

May 13, 2005 NWCV 2005, DA-IICT 48

Explicit Explicit vs vs Symbolic Model Checking Symbolic Model Checking

Explicit state model checkingRequires explicit enumeration of statesImpractical for circuits with large state spaces Useful tools exist: EMC, Murphi, SPIN, SMC …

Symbolic model checkingRepresent transition relations and sets of states implicitly (symbolically)BDDs used to manipulate implicit representationsScales well to large state spaces (few 100 flip flops)Fairly mature tools exist: SMV, VIS, FormalCheck ...

May 13, 2005 NWCV 2005, DA-IICT 49

OutlineOutline





May 13, 2005 NWCV 2005, DA-IICT 50

Boolean Function RepresentationBoolean Function Representation

Boolean logic: Foundation of reasoning strategiesNeed to represent and manipulate Boolean functions efficientlyCommon representations:

Truth table, Karnaugh map, Canonical sum-of-products

Size always 2n for n-argumentsOperations (e.g. AND, NOT) inefficientInappropriate for practical applications

E.g., representing carry-out function of 64-bit adder

May 13, 2005 NWCV 2005, DA-IICT 51

Binary Decision Diagrams (Binary Decision Diagrams (BDDsBDDs))A graphical representation [Bryant ’96]

Allows efficient representation & manipulation of Boolean functionsWorst-case behavior still exponential

Example: f = x1.x2 + x3’Represent as binary treeEvaluating f:

Start from rootFor each vertex xi

left branch if xi = 0else right branch

x3

x1x2

x3x3

1 0 1 11 0 1 0

x3

x2

0 1

May 13, 2005 NWCV 2005, DA-IICT 52

BDDsBDDsUnderlying principle: Shannon decomposition

f(x1, x2, x3) = x1.f(1, x2, x3) + x1’.f(0, x2, x3)= x1. (x2 + x3’) + x1’. (x3’)

Apply recursively to f(1, x2, x3) and f(0, x2, x3)Extend to n arguments

Number of nodes can beexponential in number ofarguments f = x1.x2 + x3’

x1 x2

x3x3

1 0 1 11 0 1 0

x3

x2

x3

May 13, 2005 NWCV 2005, DA-IICT 53

Restrictions on Restrictions on BDDsBDDsOrdering of variables

In all paths from root to leaf, variable labels of nodes in specified order

Reduced graphsNo two distinct vertices represent same functionEach non-leaf vertex has distinct children

REDUCED ORDERED BDDs (ROBDDs): DAG

x1 x2

x3x2

1 0 1 11 0 1 0

x2

x3x3

f = x1’.x2’ + x1.x2 + x1.x3’

May 13, 2005 NWCV 2005, DA-IICT 54

ROBDDsROBDDs

Example:

PropertiesUnique representation of f for given variable ordering

Checking f1 = f2: ROBDD isomorphismShared subgraphs: size reductionEvery path might not have all labelsEvery non-leaf vertex has path(s) to 0 and 1

So far good !

f = x1.x2 + x3’

10

x1 x2

x3

x1 x2

x3x3

1 0 1 11 0 1 0

x3

x2

May 13, 2005 NWCV 2005, DA-IICT 55

Variable Ordering ProblemVariable Ordering Problem

1

0 1

3 3

5 5 5 5

2 2 2 2

4 4

6

10

3

5

2

4

6

1

f = x1.x2 + x3.x4 + x5.x6

Order 1,3,5,2,4,6

Order 1,2,3,4,5,6

May 13, 2005 NWCV 2005, DA-IICT 56

Variable Ordering ProblemVariable Ordering ProblemROBDD size extremely sensitive to variable ordering

f = x1.x2 + x3.x4 + … + x2n-1.x2n

2n+2 vertices for order 1, 2, 3, 4…2n-1, 2n2n+1 vertices for order 1, n+1, 2, n+2,…n, 2n

f = x1.x2.x3….xn

n+2 vertices for all orderings Output functions of integer multipliers

Exponential size for all orderings [Bryant ‘91]

May 13, 2005 NWCV 2005, DA-IICT 57

• Determining best variable order to minimize BDD size• NP-complete [Bollig, Wegener ‘96]

• Heuristics:• Static and dynamic ordering [Fujita et al ‘92, Rudell

‘93]• Sampling based schemes [Jain et al‘98]

Variable Ordering ProblemVariable Ordering Problem

May 13, 2005 NWCV 2005, DA-IICT 58

Operations on Operations on BDDsBDDs

Operation ComplexityReduce O(|G|)

G reduced to canonical form

Apply O(|G1||G2|)Any binary Boolean op: AND, XOR …

Compose O(|G1|2|G2|)g1(x1, x2, x5) composed with g2(x3, x4)at position of x2: g1(x1, g2(x3,x4), x5)

May 13, 2005 NWCV 2005, DA-IICT 59

Operations on Operations on BDDsBDDs (Contd.)(Contd.)

Operation ComplexitySatisfy-one O(n)

Assignment of x1, … xn

for which f(x1,… xn) = 1

Restrict O(|G|)ROBDD for f(x1, x2, …,1, ... xn)or f (x1, x2, … 0 … xn)

May 13, 2005 NWCV 2005, DA-IICT 60

Operations on Operations on BDDsBDDsOperators: Take ROBDD arguments, return ROBDD result.Complexity polynomial in BDD size

BDD size limiting factor in most applicationsOngoing research on avoiding BDD blowup

Variable ordering, Partitioned BDDs, Implicitly conjoined BDDs etc.

Quantification with BDDsx1. f(x1, x2, x3) = f(0, x2, x3) + f(1, x2, x3)x1. f(x1, x2, x3) = f(0, x2, x3) . f(1, x2, x3)

Useful in Symbolic Model Checking

∃∀

May 13, 2005 NWCV 2005, DA-IICT 61

BDD Packages/Libraries Out ThereBDD Packages/Libraries Out ThereCUDD package (Colorado University)http://vlsi.colorado.edu/~fabio/CUDD/cuddIntro.html

Carnegie Mellon BDD packagehttp://www-2.cs.cmu.edu/

afs/cs/project/modck/pub/www/bdd.htmlTiGeR BDD library (commercial package)CAL (University of California, Berkeley)http://www-cad.eecs.berkeley.edu/

Respep/Research/bdd/cal_bdd/BuDDyhttp://www.itu.dk/research/buddy

May 13, 2005 NWCV 2005, DA-IICT 62

BDD Packages/Libraries Out ThereBDD Packages/Libraries Out There• ABCD

http://i10www.ira.uka.de/armin/abcd/index.html• BDDNOW

http://www.diku.dk/students/lordtime/bddnow.tar.gz• PPBF

http://www-2.cs.cmu.edu/~bwolen/software/ppbf/• ...

May 13, 2005 NWCV 2005, DA-IICT 63

OutlineOutline





May 13, 2005 NWCV 2005, DA-IICT 64

Symbolic Model Checking ofSymbolic Model Checking ofHardware Sequential CircuitsHardware Sequential Circuits

Given: A sequential circuit

Finite state transition graphFlip-flops with next-state logicTransition relation between present and next states

A property in temporal logic

Prove that MODEL satisfies SPECIFICATIONIn case of failure, counterexample desirable

MODEL

SPECIFICATION

May 13, 2005 NWCV 2005, DA-IICT 65

Example: 3Example: 3--bit Counterbit Counter

x2

x1

x0X0

X1

X2

Clk

ModelState transition graphdefined byX0 = NOT(x0)X1 = XOR(x1, x0)X2 = XOR(x2, x0. x1)

PropertyState x0, x1, x2 = 111is reached infinitely often starting from state 000

May 13, 2005 NWCV 2005, DA-IICT 66

Symbolic Model CheckingSymbolic Model Checking

Reachability analysisFind all states reachable from an initial set S0 of statesCheck if a safety condition is violated in any reachable state

CTL property checkingExpress property as formula in Computation Tree Logic (CTL)Check if formula is satisfied by initial state in state transition graph

May 13, 2005 NWCV 2005, DA-IICT 67

Symbolic Model CheckingSymbolic Model Checking

For 3-bit counter, set of states x0, x1, x2 = {000, 010, 011, 001} can be represented by S (x0, x1, x2) = S(x) = x0’.

BDD:

Set of state transitions can be represented by N (x0, x1, x2, X0, X1, X2) = N (x, X) = (X0 x0’) (X1 x1 x0)(X2 x2 (x1 x0)) BDD:

1 0

x0

x0

∧

1 0

∧∧

May 13, 2005 NWCV 2005, DA-IICT 68

S0S1

Forward Forward ReachabilityReachability

Start from set S0 of statesSet of states reachable in at most 1 step:S1 = S0 U { X | x in S0 N(x, X) = 1}

Expressed as Boolean functions:Given S0 (x0, x1, x2), S1 (X0, X1, X2) = S0 (X0, X1, X2)

x0, x1, x2 . [S0 (x0, x1, x2) N(x0, x1, x2, X0, X1, X2)]

Given BDDs for S0 and N, BDD for S1 can be obtained

∃

∃ ∧∨

∧

May 13, 2005 NWCV 2005, DA-IICT 69

Reachablestates

Forward Forward ReachabilityReachabilityCompute S1 from S0, S2 from S1, S3 from S2, …

Predicate transformer F: Si+1 = F (Si)Continue until Sk+1 = F (Sk) = Sk

Least fixed point of FSk = Set of all states reachable from S0

Computed symbolically -- using BDDsVery large state sets can be represented compactly

S0

May 13, 2005 NWCV 2005, DA-IICT 70

Z0

Backward Backward ReachabilityReachability

Give a set Z0 of statesCompute set of states from which some state in Z0 can be reached.Analogous to forward reachability with minor modifications

May 13, 2005 NWCV 2005, DA-IICT 71

Checking Safety ConditionsChecking Safety Conditions

Safety condition must ALWAYS holdE.g. Two bits in 1-hot encoded state can’t be 1 simultaneously

Z = set of states violating safety conditionGiven S0 = set of initial states of circuit,

Compute R = set of all reachable statesDetermine if Z intersects R, i.e. (Z R) 0

If YES, safety condition violatedSatisfying assignment of (Z R): counterexampleIf NO, circuit satisfies safety condition

All computations in terms of BDDs

∧ ≠

∧

May 13, 2005 NWCV 2005, DA-IICT 72

Checking Safety ConditionsChecking Safety ConditionsStart from Z = set of “bad” statesFind by backward reachability set of states B that can lead to a state in ZDetermine if S0 intersects B

S0

R

Z

S0

Z

B

Forward Reachability Backward Reachability

May 13, 2005 NWCV 2005, DA-IICT 73

CTL PropertiesCTL Properties“Once req goes high, grant eventually goes high”

Not expressible as safety propertyUse formulae in Computation Tree Logic (CTL)CTL formulae at state S0Atomic proposition: x1 = x2 = x3 = 0AG f: In all paths from S0, f holds globallyAF f: In all paths from S0, f holds finallyAX f: In all paths from S0, f holds in next

stateA[f U g]: In all paths from S0, g holds

finally, and f holds until then

S0

Computation tree of states

May 13, 2005 NWCV 2005, DA-IICT 74

Recap of CTL Recap of CTL EG f, EF f, EX f, E [f U g] defined similarly

“There exists a path from current state …”f and g can themselves be CTL formulaeE.g., AG AF (x1 x2)

x1 or x2 is satisfied infinitely often in the future

Recall 3-bit counter example:“ The state x0, x1, x2 = 111 is reached infinitely

often starting from 000”¬ x0 ∧ ¬ x1 ∧ ¬ x2 → AG AF (x0 ∧ x1 ∧ x2)

∨

May 13, 2005 NWCV 2005, DA-IICT 75

Symbolic CTL Model CheckingSymbolic CTL Model Checking

Burch, Clarke, Long, McMillan, Dill gave algorithm for CTL model checking with BDDs [Burch et al’94]Suffices to have algorithms for checking EG f, EX f, and E [f U G]

Other formulae expressed in terms of theseEF f = E [true U f]AF f = ¬ (EG (¬ f))

May 13, 2005 NWCV 2005, DA-IICT 76

Symbolic CTL Model CheckingSymbolic CTL Model CheckingGiven a model with set S0 of initial states and a CTL formula f

To determine if f is satisfied by all states in S0Convert f to g that uses only EX, EG, E[p U q]CHECK(g) returns set of states satisfying g

If g = atomic proposition (e.g., x1. x2 + x3), CHECK returns BDD for gIf g = EX p, EG p, E[p U q], CHECK uses reachability analysis to return BDD for set of statesWorst-case exponential complexity

Finally, determine if S0 CHECK(g)⊆

May 13, 2005 NWCV 2005, DA-IICT 77

State of the ArtState of the Art

Techniques to address memory/runtime bottlenecks Partitioned transition relations

Addresses BDD blowup in representing transitionsEarly quantification of variables

Addresses BDD blowup during image computationIterative squaring

Exponential reduction in number of steps to fixed point

May 13, 2005 NWCV 2005, DA-IICT 78


Techniques to address memory/runtime bottlenecks (contd.)

Use domain knowledge to order BDD variables and order quantified variablesModified breadth first search

To explore state space of loosely coupled systemsActive ongoing research …

May 13, 2005 NWCV 2005, DA-IICT 79


Symbolic model checkers can analyze sequential circuits with ~ 300 flip flops

For specific circuit types, larger state spaces have been analyzedFrontier constantly being pushedAbstract, Avant!, IBM, Cadence, Intel. Fujitsu, Motorola (internal) ...

May 13, 2005 NWCV 2005, DA-IICT 80


Specifying properties in specialized logic often daunts engineers

Better interfaces needed for property specificationMonitor-based model checking

Monitor observes system states and flags when something “bad” happensProperty to check: “Does monitor ever raise flag?”

May 13, 2005 NWCV 2005, DA-IICT 81

OutlineOutline


May 13, 2005 NWCV 2005, DA-IICT 82

Related techniquesRelated techniques

Model checking for bugsPrioritize state space search to direct it towards bugs

Start from error state and current stateCompute pre-image of error states & image of current stateChoose states for further expansion in order of their “proximity” to pre-image of error states

Proximity metrics: Hamming distance, tracks, guideposts [Yang, Dill ‘98]

Helps find bugs in erroneous circuits quicklyNo advantages if circuit is bug-free

May 13, 2005 NWCV 2005, DA-IICT 83

Related techniquesRelated techniquesApproximate Model CheckingRepresenting exact state sets may involve large BDDsCompute approximations to reachable states

Potentially smaller representationOver-approximation :

No bugs found ⇒ Circuit verified correctBugs found may be real or false

Under-approximation : Bug found ⇒ Real bug

No bugs found ⇒ Circuit may still contain bugs

Reachable states

Buggy states

May 13, 2005 NWCV 2005, DA-IICT 84

Related techniquesRelated techniques

Bounded model checkingCheck property within k steps from given set S0 of statesS0 F(S0) F2(S0) … Fk(S0)Unroll sequential machine for k time steps

To check property Z, test satisfiability of (S0 Z) (S0 Z) (S1 Z) … (Sk Z)

Leverages work done on SAT solvers

PI PO

NSPSPI0

S0

PI1

S1 S2

PI2

S3

∨∧ ¬ ∧ ∧ ∧ ∨ ∧

May 13, 2005 NWCV 2005, DA-IICT 85

OutlineOutline


May 13, 2005 NWCV 2005, DA-IICT 86

Where do we stand?Where do we stand?

Scale (gates)

Coverage

1 FSM 50K 250K 2M

Modelchecking

Randomsimulation

Manual testw/ coverage

FSM-basedgeneration

Symbolicsimulation

Based on Dill and Tesiran’99

May 13, 2005 NWCV 2005, DA-IICT 87

Research IssuesResearch Issues

Fundamental complexity hurdles in scaling formal verification methods with design sizesApproximate verification methods, semi-formal methods will be important tools in futureApproximate methods:

Model approximations should be driven by property being checkedAvailable computing resources can be used to guide nature of approximationVerification should give some coverage metric on termination

“Out of memory” after 48 hours not of any use!

May 13, 2005 NWCV 2005, DA-IICT 88


Abstraction of system behavior crucial for analyzing large designs

Must employ right degree of abstraction Can this be done automatically?More research needed

Approximate and semi-formal methods“Test of the pudding” is on large real examplesMost published examples are smallA lot of ideas -- no clear winners so farAn active area of research

May 13, 2005 NWCV 2005, DA-IICT 89


With IP based designs, supplier of IP must provide hints on how to verify IP core

RTL with assertion checksHints on exercising combinations of inputsIP verification test suite with coverage metricFormal verification of IP-based System-on-Chips will be challenging

Success constrained by verifiability, controllability and observability of IP-core

May 13, 2005 NWCV 2005, DA-IICT 90


Runtime/memory bottlenecks of existing formal verification methodologies must be addressed to scale them to larger designs

Active field of ongoing research

Suitable combination of techniques (random simulation, model checking, theorem-proving …) to be selected for each verification task

Understanding which techniques work well under what circumstancesCan this be automated?

May 13, 2005 NWCV 2005, DA-IICT 91

Future Research DirectionsFuture Research Directions

A verification framework involving different cooperating verification methods

What should be the data structure?Design for Verifiability -- is it viable and practical?How do we integrate verification tools with synthesis tools?How do we generate counter-examples for sequential, concurrent, and real-time systems verifiers?Scalability of existing methods to larger designs

May 13, 2005 NWCV 2005, DA-IICT 92

SummarySummary

Formal verification has brought hard-core engineers and theoreticians on a common platformModel checking most successful so farThe gap between VLSI advancements and advancements in FV techinques can be filled to some extent by semi-formal methods

Hard to measure “success” for such techniques?I might not have detected one out of 100000 bugs, but this might be the killer bug

May 13, 2005 NWCV 2005, DA-IICT 93

SummarySummary

Rigorous verification will be an important area in futureSimulation and emulation still predominant techniques used in industry and justifiably soHowever, formal methods ARE NEEDED when applicable and when one can’t afford to miss a bug

Success stories: Protocols, FSMs, specific processors, floating point arithmetic etc.

supratik chakraborty iit bombay - ernetsak/courses/foav/model-checking-basics.pdf · may 13, 2005...

Documents