# Formal verification of SoC designs (targeting logic verification only)

## Presentation on theme: "Formal verification of SoC designs (targeting logic verification only)"— Presentation transcript:

Formal verification of SoC designs (targeting logic verification only)
Lectures Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo

Backgrounds technology in formal verification: Methods for reasoning about mathematical models (Lecture 2) Boolean function (Propositional logic) SAT (Satisfiability checker) BDD (Binary Decision Diagrams) Use of first-order and higher-order logic Logic of uninterpreted functions with equality Theorem proving methods Basic formal verification techniques Equivalence checking (Lecture 3) Combinational Sequential Model (property) checking (Lecture 4) Explicit/implicit state based Bounded model checking Real formal verification tools Enhancing Formal Verification Capacity (Lecture 5) Abstraction-refinement Assume guarantee/Compositional Reasoning Approximation Symmetry reduction Partial Order Reduction Industrial and Research Tool Offerings Semi-formal verification techniques (Lecture 6) Advanced topics System level formal verification (Lecture 7) Synchronization verification Equivalence checking for C programs

Lecture 1: Introduction to SoC verification
System-on-Chip (SOC) design Increase of design complexity Move to higher levels of abstraction Level Number of components 1E0 1E1 1E2 1E3 1E4 1E5 1E6 1E7 System level Algorithm Abstraction Accuracy RTL Gate Transistor

System-on-Chip (SoC) design
Specification to architecture and down to implementation Behavior (functional) to structure System level: system specification to system architecture RT/IS level: component behavior to component micro-architecture Memory µProcessor Interface Comp. IP Bus Custom HW System architecture + estimates Processors IPs Memories Busses RTL/IS Implementation + results Registers ALUs/FUs Memories Gates Mem RF State Control ALU Datapath PC Pipeline IF FSM IP Netlist RAM IR Memory Specification + constraints

Verification challenge
Bottlenecks in Design Cycles: Survey of 545 engineers by EETIMES 2000

System-level design & verification
3 minutes delay System-level 3 days delay RTL 3 weeks delay Transistor level Cost due to the delay/late time-to-market revenue loss Bugs fix time Remove as many bugs as possible in the earlier stages Do not introduce new design errors when refining designs Formal verification in system-level designs: Property checking and equivalence checking

Design representation in higher level
Super state: Need multiple cycles for executions Variables, functions: Boolean ⇒ Integer, Term rewriting Op2 Op3 Op4 Op6 Op1 Op5 PS3 PS1 PS2 a = 42; while (a<100) { b = b + a; if (b > 50) c = c + d; a = a + c; } SFSMD model S1 S2 S3 Op2 Op3 Op4 Op6 Op1 Op5 FSMD model Datapath circuits Control Establish mapping

Verification methods: simulation/emulation
Traditional, basic, and flexible technique Applicable at any design levels Difficulties in preparing “good” simulation patterns Getting harder to cover corner cases Emulation Can handle software simultaneously Cost and time for preparation: not ignorable Corner case problems still remain

Why formal verification?
Traditional method (testing & simulation) Formal Verification Test properties Test results System Model Deadlock ... True or False Find counter-example Test vectors Patterned vectors Design Under Test Equivalent to simulating all cases in simulation No bug (according to the property) Property (model) checking and Equivalence checking Cannot cover all possible cases Possibility of surviving subtle (corner case) bugs

Formal verification “Prove” the correctness of designs
Both design and spec must be represented with mathematical models Mathematical reasoning Equivalent to “all cases” simulations Possible mathematical models Boolean function (Propositional logic) How to represent and manipulate on computers First-order logic Need to represent “high level” designs Higher-order logic Theorem proving = Interactive method Front-end is also very important Often, it determines the total performance of the tools Spec Design Front-end tool Mathematical models Verification engines

Formal vs simulation based verification
Example: Verification of Exclusive-OR circuits: z = ~x&y + x&~y ( ‘~’ means compliment) b x G2 a z G4 G1 y G3 c

Example: Formal vs simulation (Cont.)
Verification of Exclusive-OR circuit with “simulation” z and ~x&y+x&~y are equal for all four cases Need to simulate 2**N cases where N is #ins x y z ~x&y+x&~y x y a b c z 1

Example: Formal vs simulation (Cont.)
Verification of Exclusive-OR circuit with “formal verification” z = ~b + ~c b = ~x + ~a c = ~a + ~y a = ~x + ~y = ~(~x + ~a) + ~(~a + ~y) = a&x + a&y = (~x + ~y)&x + (~x + ~y)&y = x&~y + ~x&y Axiomatic and mathematical transformation of expressions to reach the specification This is a mathematical proof ! x y a b c z

RTL Simulation Semantics
D delay model each operation takes negligible time operations are scheduled in terms of clock boundaries explicitly specified delay may be used functional simulation may be different from later stage timing simulation 4 valued logic is usually used (0, 1, X, Z) more complex logic possible e.g. std_logic_vector in VHDL Blocking and Non-blocking assignments using syntax blocking assignments are sequentially executed non blocking assignments are executed in parallel at end of a clock boundary Value Change Dump (VCD) file captures changes in values of variables with time

Event-driven Simulation
Event: change in logic value at a node, at a certain instant of time  (V,T) Event-driven: only considers active nodes Efficient Performs both timing and functional verification All nodes are visible Glitches are detected Most heavily used and well-suited for all types of designs

Event-driven Simulation
1 3 1 1 4 6 a c D=2 D=1 e 1 b 5 1 d b(1)=1 d(5)=1 c(3)=0 e(4)=0 e(6)=1

Cycle-based Simulation
Take advantage of the fact that most digital designs are largely synchronous Boundary Node L a t c h e s L a t c h e s Internal Node Synchronous circuit: state elements change value on active edge of clock Only boundary nodes are evaluated Compute steady-state response of the circuit at each clock cycle at each boundary node

Simulation CAD Tools Event-driven simulators Cycle-based simulators
Synopsys VCS, Sirocco VCS is a fast Verilog simulator Sirocco is a VHDL simulator Cadence NCSim (VHDL, Verilog, mixed) Model Tech. Modelsim (VHDL, Verilog, mixed) Cycle-based simulators Quickturn SpeedSim (VHDL) Synopsys PureSpeed (Verilog) Cadence Cobra

Debugging Tools VCD dump viewer Integrated debugging environment xxxx
e.g. Cadence Signalscan Integrated debugging environment more sophisticated tool cross references code, VCD waveform viewer, coverage analysis etc. integrates software debug features and hardware debug features e.g. Novas Software Debussy clk a b bus[0:3] xxxx 5H 3H time

Lecture 2: Backgrounds technology in formal verification
Methods for reasoning about mathematical models Boolean function (Propositional logic) SAT (Satisfiability checker) BDD (Binary Decision Diagrams) First-order logic Logic of uninterpreted functions with equality Higher-order logic Theorem proving = Interactive method (skipped in this tutorial) Spec Design Front-end tool Mathematical models Verification engines

SAT Problem definition
Given a CNF formula, f : A set of variables, V (a,b,c) Conjunction of clauses (C1,C2,C3) Each clause: disjunction of literals over V Does there exist an assignment of Boolean values to the variables, V which sets at least one literal in each clause to ‘1’ ? Example : a = b = c = 1 C1 C2 C3

DPLL algorithm for SAT [Davis, Putnam, Logemann, Loveland 1960,62] Given : CNF formula f(v1,v2,..,vk) , and an ordering function Next_Variable Example : b a c 1 C1 C2 C3 1 1 C1 C3 C2 CONFLICT! SAT!

DPLL algorithm: Unit clause rule
Rule: Assign to true any single literal clauses. = c = 1 Apply Iteratively: Boolean Constraint Propagation (BCP)

Anatomy of a modern SAT solver
DPLL Algorithm Efficient BCP Clause database management Discard useless clauses (e.g. inactive or large clauses) Efficient garbage collection Search Restarts To correct for bad choices in variable ordering Restart algorithm “periodically” Retain some/all recorded clauses SAT Solver Conflict-driven learning

Conflict driven search pruning (GRASP)
Silva & Sakallah ‘95 x1 Non-chronological backtracking Conflict-clause recording x2 xj 2 SAT xk-1 1 xk

Conflict analysis: An example
Current Assignment: Decision Assignment:

Example continued: Implication graph
4 x2= x5= 1 4 3 6 x1= x4= 3 2 5 6 x3= 2 x6= 5 x9= x11=

Example continued….  3 5 6 x1 x9= 0@1 x8= 1@6 Decision Level 8 9
7 5 x7= x11= 7 x12= 6 x1

Variable ordering Significantly impacts size of search tree
Ordering schemes can be static or dymamic Conventional wisdom (pre-chaff): Satisfy most number of clauses OR Maximize BCP e.g. DLIS, MOMs, BOHMs etc.

Variable ordering: New ideas
New wisdom: Recorded clauses key in guiding search Conflict-driven variable ordering: Chaff (DAC’01): Pick var. appearing in most number of recent conflict clauses BerkMin (DATE’02): Pick var. involved in most number of recent conflicts Semi-static in nature, for efficiency Statistics updated on each conflict Side-effect: Better cache behavior

Efficient Boolean Constraint Propagation
Observation: BCP almost 80% of compute time, under clause recording Traditional implementation: Each clause: Counter for #literals set to false Assgn. to variable ‘x’: Update all clauses having x, x New Idea: Only need to monitor event when # free literals in a clause goes from 2 to 1 Need to watch only 2 literals per clause : SATO (Zhang’97),Chaff (DAC’01) x1 w1 w2 xk

SAT solvers today Capacity: Tool offerings:
Formulas upto a million variables and 3-4 million clauses can be solved in few hours Only for structured instances e.g. derived from real-world circuits & systems Tool offerings: Public domain GRASP : Univ. of Michigan SATO: Univ. of Iowa zChaff: Princeton University BerkMin: Cadence Berkeley Labs. Commercial PROVER: Prover Technologies

Binary Decision Diagram: Decision structures
Truth Table Decision Tree x x x x 1 1 2 3 f x x 1 2 2 1 1 1 1 x x x x 1 3 3 3 3 1 1 1 1 1 1 1 1 1 1 1 1 Vertex represents decision Follow green (dashed) line for value 0 Follow red (solid) line for value 1 Function value determined by leaf value Source: Prof. Randal Bryant

Variable ordering Assign arbitrary total ordering to variables
e.g. x1 < x2 < x3 Variables must appear in ascending order along all paths OK Not OK x x x x 1 1 3 1 x x 2 2 x x x x 3 3 1 1 Properties No conflicting variable assignments along path Simplifies manipulation

Reducing OBDDs: Rule #1 1 1 1 Eliminate duplicate terminals x x x x x
2 2 2 2 x x x x x x x x 3 3 3 3 3 3 3 3 1 1 1 1

Reducing OBDDs: Rule #2 Merge isomorphic nodes, i.e. nodes that reference the same variable and point to the same successors a a a 1 1 1 b c b c x x 1 1 x x x x 2 2 2 2 x x x x x x 3 3 3 3 3 3 1 1

Reducing OBDDs: Rule #3 Eliminate a node if its 0 and 1 edges lead to the same node a 1 b 1 b 1 x x 1 1 x x x 2 2 2 x x x 3 3 3 1 1

Example OBDD Canonical representation of Boolean function
Initial Graph Reduced Graph x x ( x + x ) x 1 1 1 2 3 x x x 2 2 2 x x x x x 3 3 3 3 3 1 1 1 1 Canonical representation of Boolean function For given variable ordering Two functions equivalent if and only if graphs isomorphic Can be tested in linear time Desirable property: simplest form is canonical.

From circuits to BDD X1 X2 G2 G4 G1 G3 X1 X1 X1 X2 X1 X2 X1 X2 X2 X2
X1 X2 1 X1 1 1 1 X2 X2 X2 X2 1 1 1 1 1 1 1 1

Effect of variable ordering
Good Ordering Bad Ordering a a 1 1 b a a 1 2 2 a a a a a 2 3 3 3 3 b b b b b 2 1 1 1 1 a b b 3 2 2 b b 3 3 1 1 Linear Growth Exponential Growth

ROBDD sizes & variable ordering
Bad News  Finding optimal variable ordering NP-Hard Some functions have exponential BDD size for all orders e.g. multiplier Good News  Many functions/tasks have reasonable size ROBDDs Algorithms remain practical up to 500,000 node OBDDs Heuristic ordering methods generally satisfactory What works in Practice  Application-specific heuristics e.g. DFS-based ordering for combinational circuits Dynamic ordering based on variable sifting (R. Rudell)

Variants of decision diagrams
Multiterminal BDDs (MTBDD) – Pseudo Boolean functions Bn  N, terminal nodes are integers Ordered Kronecker FunctionalDecision Diagrams (OKFDD) – uses XOR in OBDDs Binary Moment Diagrams (BMD) – good for arithmetic operations and word-level representation Zero-suppressed BDD (ZDD) – good for representing sparse sets Partitioned OBDDs (POBDD) – highly compact representation which retains most of the features of ROBDDs BDD packages – CUDD from Univ. of Colorado, Boulder, CMU BDD package from Carnegie Mellon Univ. In addition, companies like Intel, Fujitsu, Motorola etc. have their own internal BDD packages

Symbolic logic Symbolic logic deals with the structure of reasoning
It defines ways to deal with relationships between concepts Provides ways to compose proofs of statements Provides ways to express statements in a precise, compact and symbolic manner More precisely, a formal symbolic logic consists of A notation (symbols and syntax) A set of axioms (facts) A set of inference rules (deduction scheme)

Types of symbolic logic
Propositional Logic – commonly known as Boolean algebra Variables in this algebra  {0,1} First Order Logic Existential () and Universal () quantifiers over variables Higher Order Logic Existential and Universal quantification over sets and functions

Key features of a theory
Expressiveness What kind of statements can be written in the theory Completeness All valid formulas are provable Decidability There exists an algorithm to deduce the truth of any formula in the theory Comparison of types of logic Propositional Least expressive, decidable, complete First Order Logic More expressive, decidable, not complete Higher Order Logic Most expressive, not decidable, not complete

First-order logic First-Order Logic
theory in symbolic logic formalizes quantified statements E.g: “there exists an object such that…” or “for all objects, it is the case that…” Statements in first-order logic built using: Variables x, y Constants 0, C,  Functions f (x ), x + y Predicates p (x ), x > y, x = y Boolean connectives , , ,  Quantifiers , 

First-order theories A first-order theory Example: x. ( x + 0 = x )
a set of first-order statements about a related set of constants, functions, and predicates. Example: A theory of arithmetic might include the following statements about 0 and +: x. ( x + 0 = x ) x,y. (x + y = y + x )

Validity of an expression in a theory
Given A theory and an expression Using Building blocks of that theory If expression evaluates to true for every evaluation, then it is valid in the theory Example: X >= 0 is a valid expression in positive real arithmetic

Validity checking & undecidability
Given a theory  in first-order logic and an expression  we wish to prove that  is valid in  Validity of  in  is written as  |=  Undecidability of FOL A well-known result states that in general it is undecidable whether a FOL formula is valid in a given first-order theory However with appropriate restrictions on  and  the theory can be made decidable and practical programs can be built around Many practical problems can be posed as formulas in a certain theory or a combination of theories A proof of validity of this formula results in a solution to the problem Example Scheduling of complex operations in a manufacturing plant

Proof system A formal proof in a theory Rewrite rules
A set of steps of statements A statement is derived from a previous statement using a set of defined inference rules Rewrite rules Deal with mechanical massaging of statements irrespective of the meaning of the statements Key requirement of a proof system Soundness : All provable formulas are logically true! A proof system need not be complete or decidable in order to be useful!

Automated vs. interactive theorem proving
John Rushby, SRI, asserts “There are no fully automatic theorem provers”. For best performance most theorem provers require user guidance Variable ordering, weighting of literals, function symbols, strategy selection, orientation of equations, invention of ordering lemmas, induction hints Automation in certain domains Propositional logic using SAT solvers, BDDs Linear arithmetic – integer/linear programming Temporal logic – model checking Induction (Boyer-Moore heuristics)

Example theorem prover: PVS
Owre et al., 1992 at SRI System model PVS File Proofs Formulae To be proved System model is translated either automatically or manually Formulae to be proved are also translated from their native forms Proofs are usually carried out interactively A

PVS Methodology Automate everything that is decidable
Propositional calculus, linear arithmetic, finite-state model checking Heuristic automation for obvious cases for other problems Hashing conditional rewriter integrated with decision procedures Instantiation, induction Human control for things difficult to automate Sequent calculus presentation Tactic language for defining higher-level proof strategies

Stanford validity checker (SVC)
Started with applications to processor verification [Burch and Dill ‘94] [Jones et al. ‘95] Applications since release Symbolic simulation [Su et al. ‘98] Software specification checking [Park et al. ‘98] Infinite-state model checking [Das and Dill ‘01] Theorem prover proof assistance [Heilmann ‘99] Integration into programming languages [Day et al. ‘99]

Overall flow of SVC Given an expression whose validity has to be checked Choose an atomic formula ƒ in the expression Case split on the atomic formula Create two subformulas, for ƒ = 0, and ƒ = 1 Simplify the two subformulas Iteratively check the validity of the two subformulas Example: ( x < y )  ( y < x )  ( x = y ) Choose f = ( x < y ) Case split on f to get two subformulas Simplify ( true )  ( y < x ) true Simplify ( false )  ( y < x )  ( x = y ) ( y < x )  ( x = y )

Example (continued) ( y < x )  ( x = y ) Choose f = ( y < x )
Case splitting gives two subformulas true  ( x = y ) true false  ( x = y ) ( x = y ) Case splitting on f = ( x = y ) gives two subformulas true and false The only false node is formula: ( x  y )  ( y  x )  ( x  y ) Simplify Simplify If this formula can be proved unsatisfiable by theory then formula is a tautology

Decision procedure for higher level designs: Uninterpreted functions with equality
Ignore each functionality in the functions It is called Logic of Uninterpreted Functions Arithmetic operations are handled as symbols Fucntion returns a value If the arguments are the same, it returns the same value (a=b)(x=y)  [f(a,x)=f(b,y)] Very useful for analysis of symbolic simulation results Equivalence checking: Both send f(b) to x Design1: if a=b then x <- f(a) else x <- f(b) Design2: x<- f(b) Transform into formulae Design1: ((a=b)->(x’=f(a)))&((~(a=b)->(x’=f(b))) Design2: x’=f(b) Decision procedure similar to SAT confirms Design1=Design2 f Y x y c Y:= if c then x else f(x,y) 1

How is validity checking done?
The validity checker is built on top of a core decision procedure for satisfiability in a theory  of a set of literals in the theory A literal is an atomic formula or its negation The core decision procedure depends on the theory e.g. a Satisfiability Solver can be used for Propositional Logic SVC proposes use of several decision theories targeted to several theories gives the strongest decision procedure

Need for Multiple Theories
Why are multiple theories needed? Most real-life problems when cast into a problem of proving validity of a formula span a set of theories Propositional logic Bit-vectors and arrays Real, linear arithmetic Uninterpreted functions & predicates A decision procedure is a combination of theories must be able to combine decision procedures that reason in each of these theories!

Basic formal verification techniques
Equivalence checking: Basics and real tools (Lecture 3) Combinational Sequential Model (property) checking: Basics (Lecture 4) Explicit/implicit state based Bounded model checking

Formal Equivalence Checking
Given two designs, prove that for all possible input stimuli their corresponding outputs are equivalent Design A =? Yes/No Input Design B Product Machine

Formal equivalence checking: The targets
Equivalence checking can be applied at or across various levels System Level Gate Level Device Level RTL

Combinational Equivalence Checking (CEC)
Currently most practical and pervasive equivalence checking technology Nearly full automation possible Designs of up to several million gates verified in a few hours or minutes Hierarchical verification deployed Full chip verification possible Key methodology: Convert sequential equivalence checking to a CEC problem! Match Latches & extract comb. portions for EC

CEC in Today’s ASIC Design Flow
RTL Design CEC Synthesis & optimization Routing CEC CEC ECO DFT insertion CEC IO Insertion CEC Placement CEC Clock tree synthesis

Solving Seq. EC as Comb. EC
PI Comb. Logic PO Combinational Equiv. Checking CIRCUIT 1 NS1 PS1 PO Comb. Logic 1 MATCH PI LATCHES NS = ? PO PS Comb. Logic 2 NS PS2 NS2 CIRCUIT 2 Comb. Logic PI PO

Combinational EC with BDD and SAT
PI Comb. Logic PO Combinational Equiv. Checking CIRCUIT 1 NS1 PS1 PO Comb. Logic 1 MATCH PI LATCHES NS = ? PO PS Comb. Logic 2 NS PS2 NS2 CIRCUIT 2 Comb. Logic Represent logic functions for this entire circuit with BDD or SAT PI PO

Methods for Latch Mapping
Incomplete Methods Regular expression-based using latch names Using simulation (Cho & Pixley ‘97): Group latches with identical simulation signatures Group based on structural considerations e.g. cone of influence Incomplete run of complete method below (Anastasakis et al DAC ‘02) Complete Methods Functional fixed-point iteration based on Van Eijk’s algorithm (van Eijk ’95)

Van Eijk’s Method for Latch Mapping
Initial Latch Mapping Approximation Comb. Logic 1 NS Verify Latch Mapping Assumptions = ? PI Apply Latch Mapping Assumptions PS Comb. Logic 2 NS Iterate No Fixed-point ? Yes Done !!

If-Then-Else operation
Concept Basic technique for building OBDD from logic network or formula. Arguments I, T, E Functions over variables X Represented as OBDDs Result OBDD representing composite function (I T)  (I  E)

If-Then-Else execution example
Argument I Argument T Argument E Recursive Calls A 1 a 1 A , B a B 1 1 1 A 2 b A , B 2 2 c A 6 A , B A , B c B 5 6 2 6 5 A 3 d A , B A , B A , B B 2 d 3 2 5 2 3 4 A 4 1 A 5 A , B A , B B 3 1 B 4 4 3 5 4 Optimizations Dynamic programming Early termination rules Apply reduction rules bottom-up as return from recursive calls (Recursive calling structure implicitly defines unreduced BDD)

Derived algebraic operations
Other operations can be expressed in terms of If-Then-Else If-Then-Else(F, G, 0) And(F, G) X G If-Then-Else(F, 1, G) Or(F, G) X G

Generating OBDD from network
Task: Represent output functions of gate network as OBDDs. Evaluation A  new_var ("a"); B  new_var ("b"); C  new_var ("c"); T1  And (A, 0, B); 　　　　If-Then-Else(A, B, 0) T2  And (B, C); If-Then-Else(B,C, 0) Out  Or (T1, T2); If-Then-Else(A, 1, B) Network Out Resulting Graphs a T1 T2 A B C a b b b a b c b c c 1 1 1 1 1 1

Solving circuit problems as SAT
h b f c d g i e Input Vector Assignment ? Primary Output ‘i’ to 1 ?

SAT formulas for simple gates
c c b b a a b c b

Solving circuit problems as SAT
Set of clauses representing function of each gate Unit literal clause asserting output to ‘1’ a h b f c d g i e

CEC in Practice Key Observation: The circuits being verified usually have a number of internal equivalent functions f’ f To prove f (i1, i2,…in) = f’ (i1, i2,…in) Check x1’ x2’ x1(i1, i2,…in) = x1’(i1, i2,…in) xk’ x2(i1, i2,…in) = x2’(i1, i2,…in) xk x1 x2 xk(i1, i2,…in) = xk’(i1, i2,…in) f(x1, x2,…xk) = f’(x1’, x2’,…xk’) i1 i2 in

Internal Equiv. Based CEC Algorithm
Comb. Logic 1 PO Random Simulation PI NS = ? PS Comb. Logic 2 PO NS Gather PENs Combinational miter after latch mapping PENs: Potentially equivalent nodes, i.e. nodes with identical simulation signature Is there an unjustified PEN pair x,y ? No Done! BDD/ATPG/SAT Yes Refine PEN sets using counter-example No Is x=y? Yes Structurally merge x,y

Anatomy of Typical CEC Tools
Circuit A Quick Synthesis Latch Mapper Circuit B Structural methods Multi-engine solver Counter-example viewer Learning BDD SAT ATPG Error Diagnosis Engine

Major Industrial Offerings of CEC
Formality (Synopsys) Conformal Suite (Verplex, now Cadence) FormalPro (Mentor Graphics) Typical capabilities of these tools: Can handle circuits of up to several million gates flat in up to a few hours of runtime Comprehensive debug tool to pinpoint error-sources Counter-example display & cross-link of RTL and gate-level netlists for easier debugging Ability to checkpoint verification process and restart from same point later What if capability (unique to FormalPro)

Reachability-based Equivalence Checking
M1 Inputs Outputs S0 =? M2 S1 Product Machine Build product machine of M1 and M2 Traverse state-space of product machine starting from reset states S0, S1 Test equivalence of outputs in each state Can use any state-space traversal technique S0 S1

Move to System-Level Design
Architecture exploration System-level design Barrier to adoption of System-level design Methodology! Errors! Manual effort RTL Current design iterations Gate-level design

System-Level Verification
Property & Model Checking Manual effort Equivalence Checking RTL Gate-level design

System-level Synthesis
System-level design Automatic Synthesis Manual effort RTL Gate-level design

Scope of Today’s EC Technology
Re-encoding of state Bit-accurate Identical data types Composite data types Precision/rounding differences Serial vs parallel interfaces Sequential differences scheduling pipelining Combinational EC FFs match Data representation differences

Upcoming: Transaction-Based EC
The states in RTL that correspond to states in system-level model (SLM), are referred to as synchronizing states Define the notion of synchronizing states and how they will be used in the process of equivalence checking Complete Verification SLM Refinement mapping Transient states or Sequential counterexample RTL

Transactions : State View
SL transaction SLM Refinement mapping RTL RTL transaction Encapsulates one or more units of computation for the design being verified Self-contained since it brings the machine back to a synchronizing state Some EDA vendor is about to offer a formal verification tools that can deal with SLM, such as Calypto

Equivalence Checking: Conclusions
Currently equivalence checking based on latch mapping+CEC Methodology premised on structural similarity of designs under comparison Efficient & scalable Maybe applicable to system-level problems More general sequential EC somewhat less explored Might be needed for system level equivalence checking

Model (property) checking: Basics (Lecture 4)
Basic model checking algorthm States are explicitly represented States are “implicitly” represented Symbolic model checking with BDDs Model checking using SAT

Sequential logic circuit
Y = c  ( a  b ) a AND OR b y c NOT XOR Combinational Circuit Logic Gates INPUTS OUTPUTS a o CombLogic c b Present states Next States p D n Q LATCHES Sequential Circuit

Temporal logic model checking
Verify Reactive Systems Construct state machine representation of reactive system Nondeterminism expresses range of possible behaviors “Product” of component state machines Express desired behavior as formula in temporal logic (TL) Determine whether or not property holds Traffic Light Controller Design FSM rep. Model Checker True Property in some TL e.g. CTL, LTL “It is never possible to have a green light for both N-S and E-W.” False + Counterexample

MoC: Finite State Machine (FSM)
0/0 INPUTS CombLogic OUTPUTS S1 Next States 1/1 1/1 Present states 0/0 S3 S2 LATCHES 0/0 1/0 State Transition Graph Mealy FSM: I, S, , S0, O, ) I: input alphabet S: finite, non-empty set of states  : S  I  S, next-state function S0  S : set of initial (reset) states O: output alphabet  : S  I  O , output function x = 0 x = 1 S1 S1,0 S2,1 S2 S1,0 S2,0 S3 S3,0 S1,1 State Transition Table

Classification of properties
Safety properties “undesirable things never happen” “desirable things always happen” Examples: A bus arbiter never grants the requests to two masters Elevator does not reach a floor unless it is requested Message received is the message sent Liveness (progress) properties “desirable state repeatedly reached” “desirable state eventually reached” Every bus request is eventually granted A car at a traffic light is eventually allowed to pass

Fairness constraints In general, not every run in a state machine is a valid behavior But all runs are included in transition systems Fairness constraints rule out certain runs Properties only checked for fair paths !! Fairness constraints can be expressed as CTL formulas A fair path must satisfy each formula infinitely often Path quantifiers are restricted to only the fair paths Fairness examples An arbiter arbitrates each requestor infinitely often In a communication channel a continuously transmitted message is received infinitely often

Temporal logics Precise specification
Amenable to symbolic manipulation Two kinds of temporal logics (TL) Linear Temporal Logic (LTL): Time is a linear sequence of events Branching time temporal logic (CTL, CTL*): Time is a tree of events CTL Formulae describe properties of computation trees Computation Trees are obtained by unwinding the transition system model Branching structure due to nondeterminism CTL* is more powerful, includes CTL and LTL

Syntax of CTL Every atomic proposition is a CTL formula
If f and g are formulae then so are Øf, (f Ù g), (f Ú g), (f ® g), (f « g) AG f - in all paths, in all state f (in all future, f) EG f - in some path, in all states f AF f - in all paths, in some state f (in every future f) EF f - in some future f A(f U g) - in all paths, f holds until g E(f U g) - in some path, f holds until g AX f - in every next state, f holds EX f - in some next state f holds Examples AG ¬ (EW_light_go Ù NS_light_go) AG (car_at_intersection ® AF(light_green)) AG (EF Restart) EF (Start Ù ¬Ready)

CTL model checking M╞ F M: Transition System, F: CTL formulae
(Clarke and Emerson, Quielle and Sifakis) M╞ F M: Transition System, F: CTL formulae M defines a tree (unwind the transition system) F specifies existence of one or all paths satisfying some conditions Verification checks whether these conditions hold for the tree defined by M Specifically: Compute the set of states of M satisfying F M ╞ F iff initial states of M are in this set

CTL Model checking example 1
Compute EFp EF p = p Ú EX(p) Ú EX(EX(p)) Ú . . . STEP 2 STEP 1 P P Fixed Point !! Computation terminates EF p Holds in all dark states Computation involves backward breadth first traversal Calculation of Strongly Connected Subgraphs (cycles) STEP 3 P

CTL Model checking example 2
Compute EG p EG p = p Ù EX p Ù EX(EX p) Ù . . . Initial:STEP 1 STEP 2 P P P P P P STEP 3 TERMINATION P P P P P P

Checking safety conditions
S0: Initial states Z : Bad states Start from S0 (Z) = set of initial (bad) states Perform forward (backward) reachability analysis to compute a reached state set R (B) Determine if R (B) intersects Z (S0) S0 S0 B R Z Z Forward Reachability Backward Reachability

Model checking approaches
Explicit state model checking Requires explicit enumeration of states Impractical for circuits with large state spaces Useful tools exist: Murphi, SPIN, … Symbolic model checking Representation & manipulation in terms of ROBDDs or SAT solvers Core tasks: Represent state machine (transition relation) and sets of states Forward/backward reachability analysis Based on computing image/pre-image of set of states Fixed-point detection

Symbolic manipulation with OBDDs
Strategy Represent data as set of OBDDs Identical variable orderings Express solution method as sequence of symbolic operations Implement each operation by OBDD manipulation Key Algorithmic Properties Arguments: OBDDs with identical variable orders Result is OBDD with same ordering Each step polynomial complexity

If-Then-Else operation
Concept Basic technique for building OBDD from logic network or formula. Arguments I, T, E Functions over variables X Represented as OBDDs Result OBDD representing composite function (I T)  (I  E)

If-Then-Else execution example
Argument I Argument T Argument E Recursive Calls A 1 a 1 A , B a B 1 1 1 A 2 b A , B 2 2 c A 6 A , B A , B c B 5 6 2 6 5 A 3 d A , B A , B A , B B 2 d 3 2 5 2 3 4 A 4 1 A 5 A , B A , B B 3 1 B 4 4 3 5 4 Optimizations Dynamic programming Early termination rules Apply reduction rules bottom-up as return from recursive calls (Recursive calling structure implicitly defines unreduced BDD)

Derived algebraic operations
Other operations can be expressed in terms of If-Then-Else If-Then-Else(F, G, 0) And(F, G) X G If-Then-Else(F, 1, G) Or(F, G) X G

Generating OBDD from network
Task: Represent output functions of gate network as OBDDs. Evaluation Network A  new_var ("a"); B  new_var ("b"); C  new_var ("c"); T1  And (A, 0, B); T2  And (B, C); Out  Or (T1, T2); Out Resulting Graphs a T1 T2 A B C a b b b a b c b c c 1 1 1 1 1 1

Characteristic functions
Concept A  {0,1}n Set of bit vectors of length n Represent set A as Boolean function A of n variables X  A if and only if A(X ) = 1 Set Operations Union Intersection

Symbolic FSM representation
Nondeterministic FSM Symbolic Representation n 1 00 01 n 2 o , o encoded 1 2 o old state 1 n , n encoded 1 2 10 11 new state o o 2 2 1 Represent set of transitions as function (Old, New) Yields 1 if can have transition from state Old to state New Represent as Boolean function Over variables encoding states

Reachability analysis
Task Compute set of states reachable from initial state Q0 Represent as Boolean function R(S) Never enumerate states explicitly Given Compute old state R d state 0/1 0/1 new state Initial

00 01 10 R2 R1 R0 00 01 R1 R0 00 01 R0 00 00 01 10 10 11 Ri – set of states that can be reached in i transitions Reach fixed point when Rn = Rn+1 Guaranteed since finite state

Iterative computation
+1 R i \$ old d new R i do until ALGORITHM

BDD-based MC: Current status
Symbolic model checkers can analyze sequential circuits with ~ flip flops For specific circuit types, larger state spaces have been analyzed Challenges Memory/runtime bottlenecks Adoption of TLs for property specification Frontier constantly being pushed Abstraction & approximation techniques Symmetry reduction Compositional reasoning Advances in BDD technology …

Solving circuit problems as SAT
h b f c d g i e Input Vector Assignment ? Primary Output ‘i’ to 1 ?

SAT formulas for simple gates
c c b b a a b c b

Solving circuit problems as SAT
Set of clauses representing function of each gate Unit literal clause asserting output to ‘1’ a h b f c d g i e

SAT-based unbounded MC
SAT-based Inductive reasoning Exact image computation Use SAT solver just for fixed-point detection Image computation using SAT solver McMillan CAV’02, Kang & Park DAC’02 Approximate image computation Using Craig Interpolants (McMillan CAV’03) Abstraction refinement Discussed later in the tutorial

SAT-based reasoning on ILAs
PI Popularized by the BMC work (Biere et al) Current SAT solvers have shown good results PO CL NS PS LATCHES Unroll k-Steps PI1 PI2 PIk NS1 NS2 NSk-1 PS1 CL1 CL2 CLk NSk PS2 PS3 PSk PO1 PO2 POk

SAT-based inductive reasoning
I0 never satisfies ~ P Simple Induction P UNSAT Base Case ‘1’ I0 + AG P is TRUE P ‘1’ ‘1’ UNSAT Induction Step CLk+1 P ‘1’ If Ii never satisfies ~ P, then Ii+1 never satisfies ~P It is never the case that (I0 satisfies P) and (Ii+1 satisfies ~P)

SAT-based inductive reasoning
P P Base Case P ‘1’ I0 CL1 CL2 CLk P P ‘1’ ‘1’ P ‘1’ P Induction Step CLk CL1 CLk+1 P ‘1’ Induction with depth ‘k’ (Sheeran et al, Bjesse et al FMCAD 2000)

Not k - depth inductive for any k ! Unreachable state-space
SAT-based induction Can prove or disprove properties k-depth induction: Can check more properties for larger k Base case is simply k-length BMC But not complete ! Example: Not k - depth inductive for any k ! P P Unreachable state-space

SAT-based inductive reasoning
Unique paths Induction: Restrict unrolled ILA to be loop-free Sheeran et al, Bjesse et al FMCAD’00 Unrolling upto recurrence diameter i.e. length of longest loop-free path Stronger induction methods can be expensive But, some properties very easy to prove by induction, very hard by state-space traversal Simple induction can be cheap, first step in verification flow Complete!

SAT-based image computation
Issues: Function representation Quantification do or until SAT Solver Fixed-point Bug found !

Function Representation
Representation of: Init, Ri(s), P(s), Tr(s,s’) Converted to CNF for SAT solving x z y Reduced Boolean Circuit (RBC) Boolean Expression Diagram (BED) Abdulla et al, TACAS 2000 Williams et al, CAV 2000

Quantification Apply definition of existential quantification:
Mitigate formula blow-up by: Inherent reduction rules of function rep. Special case quantification rules: Limitation: Suitable only when small number of variables to be quantified Inlining: where Scope Reduction: where

Exact image computation using SAT
McMillan, CAV 2002 CTL Model Checking procedure AG(p) Let Z = Q = p while Z  1 let Z = (W · pi/si)Q let Q = Q  Z return Q Solve W · f Solution: Express f in CNF: fCNF Drop all wi literals from fCNF Core problem: Express a given formula f in CNF

Computing a CNF representation for f
e.g. f = (ab)c Basic Algorithm Create CNF(f) Solve SAT(CNF(f)  Øvf) Compute blocking clause for each satisfying assignment Collect all blocking clauses  fCNF a vab b vf c CNF(f) Blocking Clauses Must: Contain only original vars. of f Be false under some sat. assgn. of CNF(f)  Øvf Be implied by CNF(f)  vf Blocking Clauses : (bc) , (ac) fCNF= (bc) (ac)

Some issues Issues: Conclusions:
Blocking clauses expressed in terms of original variables of f Extracted from a separate implication graph Quantification of W vars. can be performed on each generated blocking clause: Combine both steps into one!! Conclusions: Technique promising where BDDs blow up BDDs superior as a general purpose technique Proposed technique needs more polishing

Lecture 5 Enhancing formal verification capacity
Abstraction-refinement Assume guarantee/Compositional Reasoning Approximation Symmetry reduction Partial Order Reduction Industrial and research tool offerings

Abstraction Limitations of symbolic model checking
Suffers from state explosion Concurrency Data domains Abstraction of state space Represent the state space using a smaller model Pay attention to preserving the checked properties. Do not affect the flow of control.

Example Use smaller data objects HDL Code: X:= f(m); Y:=g(n);
if (X*Y>0) then … else … X, Y never used again. Assign values {-1, 0, 1} to X and Y. Based on the following connection: sgn(X) = 1 if X>0, if X=0, and if X<0. sgn(X)*sgn(Y)=sgn(X*Y). Change f and g to produce abstract values for X and Y 6

Abstraction vs. simplification
Not every simplified system is an abstraction The key question is: If we prove or disprove a property of the simplified system, what have we learned about the original system?

Abstraction (Cont) Abstract transition relation is conservative
Abstract next states must contain all concrete successors And possibly more states t RA s Abstract g g Concrete x y RC

Abstract counter-example
If model checking fails an abstract counter-example is produced Concrete transitions are present for each pair of consecutive abstract states But concrete counter-example may not be present! Spurious Trace g Abstract g g Concrete y’ Real Trace x z y’’

Abstraction refined Abstraction is refined by adding more states
prevents previous spurious counter example Model checking is repeated on new abstraction iterate New Trace gi gi Abstract gi gi Concrete y1 Real Trace x z y’’

Abstraction refinement algorithm
Build abstract model Refinement spurious counterexample Model check abstract model Check abstract counterexample on concrete model Bad states are called goals True on concrete model true Build an abstract model Generate an error trace on abstract model Error is impossible ? Goal is unreachable, done Replay trace on concrete model Verified ? Goal is reachable, done Failed? Failure analysis Iterate until resource limit Infeasible abort False on concrete model real counterexample

Assume-Guarantee Reasoning
S and R are just too large to be verified at the same time Like to verify S and R separately ! || Sender Receiver has Property S R <

Assume-Guarantee Reasoning
First try to find something intermediate, S’ and R’ between the designs and the specification, such that it is easy to verify that S’ and R’ satisfy the property S R < S’ R’ <

Assume-Guarantee Reasoning
If we can verify individual cases separately, we are done ! R < R’ S < S’ S R < S’ R’ <

Assume-Guarantee Reasoning
But normally we cannot due to unconstrained inputs Inputs are unconstrained R < R’ S Inputs are unconstrained < S’ S R < S R <

Assume-Guarantee Reasoning
Use S’ and R’ to constrain inputs ! R S’ < R’ S R’ < S’ S R < S’ R’ <

Assume-Guarantee Reasoning
This is a theorem !AG reasoning: Example R S & -> R S & R -> S S R & -> S & R

Symmetry reductions f: f(0,0) = 1,1 f(1,1) = 0,0
Idea: If state space is symmetric, explore only a symmetric “quotient” of the state space A permutation function f : S  S is an automorphism if: 0,0 1,1 0,1 1,0 ( x, z)  ( f(x), f(z)) f: f(0,0) = 1,1 f(1,1) = 0,0 f(0,1) = 0,1 f(1,0) = 1,0 e.g. The set of all automorphisms forms a group! Automorphism groups induce equivalence classes (orbits) over the state space [ (0,0), (1,1) ] e.g. [ (0,1), (1,0) ]

Quotient machine Map each state to its representative in the orbit
0,0 1,1 0,1 1,0 [ (0,0),(1,1) ] [ (0,1), (1,0) ] Map each state to its representative in the orbit Do model checking analysis on the quotient machine Quotient machine

Symmetry reductions Difficulty Solutions
Identifying symmetry groups Computing function mapping states to representatives Solutions Ask user to tell you where the symmetries are Be satisfied with multiple representatives for each orbit Tools: Mur, Nitpick, RuleBase

Over-approximate reachability
Exact reachability captures the exact reachable state-space Problem: BDD-blowup in many real designs Solution: Compute over-approximation of the reachable states R+ Often sufficient to prove properties correct Error could be a false negative Can trade off BDD-size and runtime with accuracy of approximation R2+ R1+ R R1 R2 I0

Over-approx. reachability techniques
Split FSM into sub-machines by partitioning state-vars Perform (exact) reachability on each machine Cross-product of reached state spaces gives over-approx. for original FSM LATCHES PI PO NS PS CL X X

Over-approx: more issues
Communicate between sub-FSMs to tighten approximation After each time-frame After least fixpoint computation for a sub-FSM Computing partitions Heuristic and/or manual Disjoint partitions (Cho et al) Overlapping partitions (Govindaraju et al) Can capture limited interaction among sub FSMs Tighter approximation May not increase BDD sizes much

Partial order reduction
Factor out independent state transitions! (typical for asynchronous communication as in Software- and Protocol-Checking) May result in exponential reduction in the number of states Process B transition A Synchronization Irrelevant States One Relevant Trace of States

Model Checkers - Research Tools
SMV (CMU, Cadence) VIS (UC Berkeley) Mocha (UC Berkeley, compositional reasoning) Verisoft (AT&T, C-model checker) Bandera (Java model checker)

Industrial Model Checkers
FormalCheck (Cadence) COSPAN (from Bell Labs) under the hood Support for arbitrary precision arithmetic Automatic bus-contention, multi-driver violation, tri-state support fir high-impedance check Powerful design reduction techniques Removal of portions of design that do not affect the property being proven Constant & constraint propagation Iterative reduction guarantees that queries proven on the reduced design hold on the entire design

EDA Vendor Tool Offerings
Verplex (Cadence) Blacktie IBM RuleBase @HDL works on Verilog RTL static assertion checks automatic property extraction clock domain synchronization errors Real Intent Verix slimilar Averant Solidify Jasper design automation Jasper Gold

Lecture 6: Semi-formal verification
Coverage Existing Formal Verification FV Augmented Simulation (Falsification) Manual test w/ coverage Random simulation GATES 2K 20K 200K 2M FV + Complete coverage - Limited capacity FV Augmented Simulation + Good coverage + Good capacity Simulation +Unlimited capacity - Poor coverage

Section outline Symbolic simulation
Symbolic trajectory evaluation (STE) SAT-based bounded model checking Sequential ATPG-based model checking Guided search Smart simulation

Problem: Too many constant input combinations to simulate !!
Symbolic simulation Conventional simulation: Input & outputs are constants (0,1,X,…) 1 a Problem: Too many constant input combinations to simulate !! 1 b a·b+b·c 1 c Symbolic simulation: Symbolic expressions used for inputs Expressions propagated to compute outputs Equivalent to multiple constant simulations !! Ref: Prof. David Dill, CAV ’99c

Symbolic simulation (sequential case)
a1·b1+ b1·(a0·b0 + b0·c) a1 a0 a0·b0 + b0 ·c b1 b0 Time frame 1 Time frame 2 c a0·b0 + b0·c a1 a0 b1 a1·b1+ b1·(a0·b0 + b0·c) b0 c Unrolled Circuit

Inputs can be constants Input expressions can be related
Symbolic simulation Inputs can be constants 1 b c b + c a b c a·b + b ·c a+b b c b + c Simulate certain set of patterns Model signal correlations Can result in simpler output expressions Input expressions can be related

Symbolic simulation Use BDDs as the symbolic representation
Work at gate and MOS transistor level Can exploit abstraction capabilities of ’X’ value Can be used to model unknown/don’t care values Common use in representing uninitialized state variables Boolean functions extended to work with {0,1,X} Two BDD (binary) variables used to represent each symbolic variable

Can handle larger designs than model checking Can use a large variety of circuit models Possibly more natural for non-formalists. Amenable to partial verification. Disadvantages Not good with state machines (possibly better with data paths). Does not support temporal logic Requires ingenuity to prove properties.

Practical deployment Systems: Exploiting hierarchy
COSMOS [bryant et al], Voss[Seger et al Intel] Magellan [Synopsys] Innologic Exploiting hierarchy Symbolically encode circuit structure Based on hierarchy in circuit description Simulator operates directly on encoded circuit Use symbolic variables to encode both data values & circuit structure Implemented by Innologic, Synopsys (DAC ‘02) Greatest success in memory verification (Innologic)

High-level symbolic simulation
Data Types: Boolean, bitvectors, int, reals, arrays Operations: logical, arithmetic, equality, uninterpreted functions Final expression contains variables and operators Coupled with Decision procedures to check correctness of final expression Final expressions can also be manually checked for unexpected terms/variables, flagging errors e.g. in JEM1 verification [Greve ‘98]

High-level symbolic simulation
Manipulation of symbolic expressions done with Rewrite systems like in PVS Boolean and algebraic simplifiers along with theories of linear inequalities, equalities and uninterpreted functions Extensively used along with decision procedures in microprocessor verification Pipelined processors: DLX Superscalar processors: Torch (Stanford) Retirement logic of Pentium Pro Processors with out of order executions

Symbolic trajectory evaluation (STE)
Trajectory : Sequence of values of system variables Example: c = AND (a, b) and delay is 1 A possible trajectory : (a,b,c) = (0, 1, X), (1, 1, 0), (1, 0, 1), (X, X, 0), (X, X, X),… Express behavior of system model as a set of trajectories I and desired property as a set of trajectories S Determine if I is inconsistent with S Inconsistent: I says 0 but S says 1 for a signal at time t Consistent: I says 0 but S says X or 0 for a signal at time t

If apply input a then 4 cycles later will get output a
STE: An example 4-Bit Shift Register Din Dout Assert X X X X a X T = 0 Specification Din Dout a X X X T = 1 Din = a  NNNN Dout = a X X Din Dout If apply input a then 4 cycles later will get output a X a X X X X T = 2 Din Dout X X a X T = 3 X X Din Dout X X X a X a T = 4 Din Dout Ref: Prof. Randal Bryant, 2002 Din = a  NNNN Dout = a Check

STE: Pros, cons & u Advantage: Higher capacity than symbolic model checking Disadvantage: Properties checkable not as expressive as CTL Practical success of STE Verification of arrays (memories, TLBs etc.) in Power PC architecture x86 Instruction length decoder for Intel processor Intel FP adder Microprocessor verification

SAT-based bounded model checking
FSM M Property F PI PO LATCHES NS PS CL Example F: AG P ? P Question: Does M have a counter-example to F within k transitions ? Biere et al (TACAS’99, DAC’99)

SAT-based bounded model checking
P P P ‘1’ I0 CL1 CL2 CLk P Unroll M for k time-frames SAT Counter-example to AG P SAT Solver CNF No Counter-example within k steps UNSAT

SAT-based BMC Primarily used for finding bugs !
Verification complete if k > sequential depth of M Sequential depth computation or tight estimation intractable in practice Can express both safety and liveness properties (bounded semantics) All LTL formulas Unbounded fairness by detecting loops Open problem!!

SAT-based BMC: Pros & cons
Advantages: SAT-BMC good at producing counter-examples upto medium depths (upto 50-60) SAT solvers less sensitive to size of design: SAT-BMC can handle larger designs SAT solvers require less parameter tuning: Productivity gain Drawbacks: Incomplete method: Cannot verify properties Ineffective at larger depths: Slow, CNF blow-up Cannot describe all CTL properties

Enhancements to basic SAT-BMC
CNF generation for BMC Bounded cone-of-influence: Biere et al CAV’99 Circuit-graph compression: Ganai et al VLSID’02 Binary time-frame expansion: Fallah ICCAD’02 Decision variable ordering BMC-specific static ordering: Strichman CAV’00 Tuning VSIDS for BMC: Shacham et al MTV’02 Addition of clauses/constraints Sharing clauses across BMC runs: Strichman CHARME’01 Learning clauses from BDDs: Gupta et al DAC’03 Using BDD reachability over-approx: Cabodi et al DATE’03

Sequential ATPG for MC AG p EF p e.g. p
Proposed by Boppana, Rajan, Takayama & Fujita, CAV ‘99 AG p EF p e.g. CIRCUIT AUTOMATA TEST NETWORK from property stuck-at fault INPUT CIRCUIT s-a-0 fault INPUT p

vs BDDs vs SAT-BMC No explicit storage of states No need to build transition relation Good balance of DFS and BFS traversal of state-space Can model real-world primitives, e.g. tri-state buses, high impedence value No explicit unrolling of time-frames Uses circuit-based heuristics to guide or speed-up search

Sequential ATPG for BMC
ORIGINAL CIRCUIT MONITOR PROPERTY n stuck-at fault TEST NETWORK Recent work by Abraham et al (ITC’02, VLSID’03) Model both safety & liveness properties (bounded) start 1 2 n-1 n p Example: EG p

ATPG-MC: Current status
Attempts to use simulation-based ATPG for falsification (Hsiao et al HLDVT’01, DAC’02) No research characterizing fragment of language (e.g. CTL, LTL) checkable through ATPG-based MC Some works report dramatic improvements of seq. ATPG-BMC vs. SAT-BMC Current efforts towards combining SAT solvers and sequential ATPG (SATORI ICCAD’03)

Guided search State-space search optimized for bug-searching (Yang & Dill, DAC 98) Use prioritized search Cost function to pick next state to search Hamming distance to error states Breadth-first Search Prioritized Search Error State Error State

Improving guided search
Without Target Enlargement Target enlargement also Yuan et al CAV 97 Reset State Error States Improved cost function Tracks Compute series of approximate preimages Use the approximate pre-image to estimate distance to enlarged target Guideposts Designer provided hints/necessary pre-conditions for assertion violation Bias search to explore search with those pre-conditions Enlarged Error States

Smart simulation I : SIVA
[Ganai, Aziz, Kuehlmann DAC ‘99] Combines random simulation with BDDs and combinational ATPG Identify targets Indicator variables, coverage goals, fail states etc. Lighthouses: Several per target “Sub-targets” to guide SIVA to reach a target At each state identify targets with constant simulation signature Advance simulation by visiting states which causes such targets to toggle value Search for such next state by ATPG/BDDs

SIVA - a run R1’ R1 R5000’ INITIAL R2 RANDOM BDD R5000 D1’ ATPG D1 D2 Key: Determination of appropriate targets, lighthouses etc. to guide the search 3

Smart simulation II: Magellan
[Ho et al, ICCAD 2000 (Synopsys)] Coverage-driven test generation Identify few interesting signals (typically <64): coverage signals Goal: Maximize state-coverage on coverage signals Test generation Interleave random simulation with symbolic simulation & SAT-BMC Unreachability analysis (under-approx) Identify unreachable coverage states to reduce coverage target

Symbolic simulation / SAT-BMC
Magellan methodology Random simulation Initial state Symbolic simulation / SAT-BMC Coverage state Random simulation: Deep narrow search SAT-BMC: Short-range exhaustive (wide) search (<10 steps) Symbolic simulation: Middle range exhaustive (wide) search (10-50 steps)

Smart simulation III: 0-in search
Approach: Test amplification Identify “seed states” reached through simulation i.e. directed or random simulation Explore exhaustively behavior around seed states using formal methods SAT-BMC, BDDs, symbolic simulation + = Formal Simulation 0-In Search

Methodology: Assertion-based Verification
Use checkers (written in HDL) to: Specify targets for simulation/formal methods Capturing buggy conditions Specify environment of a module Can be synthesized into constraints Specify interfaces between components Inserting checkers: From 0-in CheckerWare library (~60 checkers) Specified by the user in Verilog Created automatically from RTL directives By 0-in Check functional tool Suggested by 0-in Checklist while analyzing RTL A kind of sophisticated lint checking

Source: 0-in Design Automation Verification White-paper
0-in search: Tool flow Source: 0-in Design Automation Verification White-paper Instrumented Verilog RTL Verilog Files with 0-in Checkers Verilog Tests and Testbench Standard Verilog Simulator No firings in Verilog output Simulation Trace (Seed) Checker Control File 0-in Search 0-in Confirm Verilog simulator (Firing Replay) Firings Log Standard Waveform Tool 0-in View GUI

Lecture 7: Formal verification in C-based (SpecC/SystemC) based design methodology
C based design descriptions from specification (functional) level down to RTL Incremental refinement on the C/C++ descriptions Equivalence checking between refinements Between sequential and parallel descriptions Between two same control structures Property checking on each refinement Please note that in system level designs, both SpecC and SystemC have similar description mechanisms

Execution semantics in SpecC
Sequentiality rule: Tstart(B1) <= Tstart(a) < Tend(a) <= Tstart(b) < Tend(b) <= Tstart(c) < Tend(c) <= Tend(B1) Sequential execution within a thread Example behavior B1 { void main(void) { a.main(); b.main(); c.main(); } }; B1 a b c time

Execution semantics in SpecC (cont.)
Sequentiality rule: Tstart(B) <= Tstart(a) < Tend(a) <= Tstart(b) < Tend(b) <= Tstart(c) < Tend(c) <= Tend(B) Tstart(B) <= Tstart(d) < Tend(d) <= Tstart(e) < Tend(e) <= Tstart(f) < Tend(f) <= Tend(B) Example: concurrency/pallalelism Possible Schedule behavior B { void main(void) { par { b1.main(); b2.main();} }}; B d e f behavior B1 { void main(void) { a.main(); b.main(); c.main();} }; behavior B2 { void main(void) { d.main(); e.main(); f.main();} }; a b c time

Synchronization semantics
wait/notify rule in time-interval formalism: wait cannot proceed until it receives a notified event notified event is valid until a wait or waitfor statement is reached Example: Notify-wait rule derives: Tend(w) >= Tend(n) wait cannot proceed until it receives notified event behavior A: a.main(); wait e1; b.main(); behavior B: c.main(); notify e1; d.main(); ‘wait e1’ starts ‘wait e1’ succeeds thread A a w b this order is guaranteed! B c n d ‘notify e1’ done time

Incremental refinement steps
Starting with a functional model, make each part more detailed A1, B1, and C1 are refinement of A, B, and C respectively void A() { } void B() { void main() { A(); B(); C(); void C() { A void A1() { } void B1() { void main() { A1(); B1(); C1(); void C1() { A1 B B1 C C1

Incremental refinement steps
Change of control structures IF-THEN-ELSE Sequential to parallel void A1() { } void B1() { void main() { A1(); B1(); C1(); void C1() { A1 void A1() { } void B1() { void main() { par{ A1.main(); B1.main(); C1.main(); void C1() { A1 B1 notify wait B1 C1 C1

Incremental refinement steps
Again make each part more detailed A2, B2, and C2 are refinement of A1, B1, and C1 respectively void A1() { } void B1() { void main() { par{ A1.main(); B1.main(); C1.main(); void C1() { void A1() { } void B1() { void main() { par{ A1.main(); B1.main(); C1.main(); void C1() { A1 B1 A2 B2 notify wait notify wait C1 C2

Equivalence checking of two descriptions with same control
If A and A1, B and B1, C and C1 are equivalent, then entire descriptions are equivalent Comparison of two “similar” descriptions void A() { } void B() { void main() { par{ A.main(); B.main(); C.main(); void C() { void A1() { } void B1() { void main() { par{ A1.main(); B1.main(); C1.main(); void C1() { A B A1 B1 notify wait notify wait C C1

Equivalence checking between sequential and parallel versions
Based on synchronization verification, prove equivalence Extraction of synchronization and dependency analysis void A() { } void B() { void main() { A(); B(); C(); void C() { A void A() { } void B() { void main() { par{ A.main(); B.main(); C.main(); void C() { A B notify wait B C C notify-wait pair are supposed to communicate !

Symbolic simulation in higher-level designs
Symbolic execution of designs All variables and operations are expressed as symbols Expressions among them are also symbols Efficient simulation for all possible input patterns A symbol expression (a + b) requires many patterns in conventional Boolean level symbolic simulation 256 * 256 patterns when a, b are 8-bit variables

Symbolic simulation example
Example of equivalence checking based on symbolic simulation Checking (add1 == add2) , when v1, v2 are equivalent in both designs Equivalent variables are collected into EqvClass a = v1; b = v2; add1 = a + b; Symbolic simulation Description 1 EqvClass add2 = v1 + v2; We are going to check the equivalence between add1 and add2 Description 2

Symbolic simulation example
Example of equivalence checking based on symbolic simulation Checking (add1 == add2) , when v1, v2 are equivalent in both designs Equivalent variables are collected into EqvClass a = v1; b = v2; add1 = a + b; E1 (a, v1) E2 (b, v2) E3 (add1, a+b) Symbolic simulation Description 1 EqvClass add2 = v1 + v2; Description 2 Description1 is simulated

Symbolic simulation example
Example of equivalence checking based on symbolic simulation Checking (add1 == add2) , when v1, v2 are equivalent in both designs Equivalent variables are collected into EqvClass a = v1; b = v2; add1 = a + b; E1 (a, v1) E2 (b, v2) E3 (add1, a+b) E4 (add2, v1+v2) Symbolic simulation Description 1 EqvClass add2 = v1 + v2; Description 2 Description2 is simulated

Symbolic simulation example
Example of equivalence checking based on symbolic simulation Checking (add1 == add2) , when v1, v2 are equivalent in both designs Equivalent variables are collected into EqvClass a = v1; b = v2; add1 = a + b; E1 (a, v1) E2 (b, v2) E3 (add1, a+b) E4 (add2, v1+v2) Symbolic simulation Description 1 EqvClass add2 = v1 + v2; Due to the equivalences in E1, E2 Description 2

Symbolic simulation example
Example of equivalence checking based on symbolic simulation Checking (add1 == add2) , when v1, v2 are equivalent in both designs Equivalent variables are collected into EqvClass a = v1; b = v2; add1 = a + b; E1 (a, v1) E2 (b, v2) E3’ (add1, a+b, add2, v1+v2) Symbolic simulation Description 1 EqvClass add2 = v1 + v2; E3 & E4 are merged into E3’ Description 2

Program slicing for SpecC/C++
Can extract a portion of a program based on dependence analysis Can be applied to formal methods, since it can reduce problems to be analyzed Two types of slicing Backward slicing … extracting the portion that can affect a variable at a certain line of codes Forward slicing … extracting the portion that can be affected by a variable at a certain line of codes Based on C/C++ slicer, SpecC/SystemC/VHDL slicer can be developed [Shankar et al.] Since they are similar to C/C++, a little bit of extension is sufficient

Backward slicing Backward slicing for a variable v extracts all codes that affect the variable v Backward slicing a = 2; b = 3; c = 5; a = a + 10; b = a * c; /start/ c = c + a; a = a * b; a = 2; b = 3; c = 5; a = a + 10; b = a * c; /start/ c = c + a; a = a * b;

Forward slicing Forward slicing for a variable v extracts all codes that are affected by the variable v Forward slicing a = 2; b = 3; c = 5; a = a + 10; b = a * c; /start/ c = c + a; a = a * b; a = 2; b = 3; c = 5; a = a + 10; b = a * c; /start/ c = c + a; a = a * b;

Example : Interprocedural slicing with summary edge
int sq(int x){ return(x*x); } void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d); 関数呼び出しのスライシングの際に、別の呼び出し点に戻るエッジを辿らないように スライシングを２段階に分けます。 Summary Edgeというエッジを関数の引数(actual in)から返値(actual out)に引き、 関数呼び出しが有った場合は、まず関数の中ではなくこのエッジを辿り、 呼び出した先の関数内は後で辿ることで問題を解決できます。 summary edgeは、各関数内でのそれぞれの引数から返値までの依存関係を、 前の例と同様の方法で求めることで引くことが出来ます。 Source code Dependence graph

Example : Interprocedural slicing with summary edge
int sq(int x){ return(x*x); } void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d); 1st stage 関数呼び出しのスライシングの際に、別の呼び出し点に戻るエッジを辿らないように Summary Edgeというエッジを関数の引数(actual in)から返値(actual out)に引き、 関数呼び出しが有った場合は、まず関数の中ではなくこのエッジを辿り、 呼び出した先の関数内は後で辿ることで問題を解決できます。 summary edgeは、各関数内でのそれぞれの引数から返値までの依存関係を、 前の例と同様の方法で求めることで引くことが出来ます。 Source code Dependence graph

Example : Interprocedural slicing with summary edge
int sq(int x){ return(x*x); } void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d); 2nd stage 関数呼び出しのスライシングの際に、別の呼び出し点に戻るエッジを辿らないように Summary Edgeというエッジを関数の引数(actual in)から返値(actual out)に引き、 関数呼び出しが有った場合は、まず関数の中ではなくこのエッジを辿り、 呼び出した先の関数内は後で辿ることで問題を解決できます。 summary edgeは、各関数内でのそれぞれの引数から返値までの依存関係を、 前の例と同様の方法で求めることで引くことが出来ます。 Source code Dependence graph Dependence graph gives all dependency informations on the programs and is used here

Equivalence checking of C descriptions based on symbolic simulation
Problem Symbolic simulation of a whole design takes a very long time, when the design is large Computational efforts exponentially increase with the numbers of conditional branches Solution Reducing areas to be simulated symbolically Based on difference between descriptions See the following slide for intuitive explanation Textual differences may become a good hint to identify which portions of programs are different

Efficient equivalence checking in SpecC/C++
Comparison of two similar design descriptions Extract textual differences Dependence analysis by program slicing type techniques Symbolically simulate the real difference and analyze the results : textual differences return a; return a; return a; return a; Description1 Description2 Description1 Description2

Verification flow Desc. 1 Desc. 2
Definition of Input/Output Variables and Program Slicing Identification of the Textual Differences & Extracting Functions to be Checked A Naïve way is to simulate both descriptions separately. Following slide introduces a more efficient simulation method Symbolic Simulation Report of Results

More efficient simulation method
A lot of internal equivalence checking are carried out during verification Most of them do not directly contribute to prove output equivalence More efficient simulation method Do not simulate the descriptions separately Both descriptions are simulated in parallel Utilizing textual correspondence Only checking equivalence of corresponding statements Utilizing textual difference Equivalence checking can be skipped if two statements are obviously equivalent

An example of verification
a_1 = 3 * in2_1; b_1 = in1_1; c_1 = 2408 * (in1_1 + in2_1); d_1 = c_1 – 4017 * b_1; e_1 = 1108 * (a_1 + b_1); out_1 = (d_1 + e_1) >> 8; D a_2 = in1_2 * in2_2; b_2 = in1_2; c_2 = 2408 * (in1_2 + in2_2); d_2 = c_2 – 4017 * b_2; e_2 = 1108 * (a_2 + b_2); out_2 = (d_2 + e_2) >> 8; E E E E E 1st line: textually different Create 2 EqvClasses separately E1 (a_1, 3 * in2_1) E2 (a_2, in1_2 * in2_2) Check their equivalence … nonequivalent Identify the statements affected by a_1 or a_2 5th line is identified Note: Input: in1, in2 Output: out

An example of verification
a_1 = 3 * in2_1; b_1 = in1_1; c_1 = 2408 * (in1_1 + in2_1); d_1 = c_1 – 4017 * b_1; e_1 = 1108 * (a_1 + b_1); out_1 = (d_1 + e_1) >> 8; D a_2 = in1_2 * in2_2; b_2 = in1_2; c_2 = 2408 * (in1_2 + in2_2); d_2 = c_2 – 4017 * b_2; e_2 = 1108 * (a_2 + b_2); out_2 = (d_2 + e_2) >> 8; E E E E E 2nd, 3rd, 4th line: textually equivalent and not affected by nonequivalent variables These pairs are clearly equivalent  can skip checking Simply create an EqvClass for each pair E3 (b_1, b_2, in1_1, in1_2) E4 (c_1, c_2, 2408 * (in1_1 + in2_1), * (in2_1 + in2_2)) E5 (d_1, d_2, c_1 – 4017 * b_1, c_2 – 4017 * b_2)

An example of verification
a_1 = 3 * in2_1; b_1 = in1_1; c_1 = 2408 * (in1_1 + in2_1); d_1 = c_1 – 4017 * b_1; e_1 = 1108 * (a_1 + b_1); out_1 = (d_1 + e_1) >> 8; D a_2 = in1_2 * in2_2; b_2 = in1_2; c_2 = 2408 * (in1_2 + in2_2); d_2 = c_2 – 4017 * b_2; e_2 = 1108 * (a_2 + b_2); out_2 = (d_2 + e_2) >> 8; E E E E E 5th line: affected by nonequivalent variable a_1 and a_2 Create 2 EqvClasses separately E6 (e_1, 1108 * (a_1 + b_1)) E7 (e_2, 1108 * (a_2 + b_2)) Check their equivalence … nonequivalent Identify the statements affected by e_1 or e_2 6th line is identified

An example of verification
a_1 = 3 * in2_1; b_1 = in1_1; c_1 = 2408 * (in1_1 + in2_1); d_1 = c_1 – 4017 * b_1; e_1 = 1108 * (a_1 + b_1); out_1 = (d_1 + e_1) >> 8; D a_2 = in1_2 * in2_2; b_2 = in1_2; c_2 = 2408 * (in1_2 + in2_2); d_2 = c_2 – 4017 * b_2; e_2 = 1108 * (a_2 + b_2); out_2 = (d_2 + e_2) >> 8; E E E E E 6th line: textually equivalent, but affected by nonequivalent variables e_1 and e_2 Create 2 EqvClasses separately E8 (out_1, (d_1 + e_1) >> 8) E9 (out_2, (d_2 + e_2) >> 8) Check their equivalence … nonequivalent Terminate with the results “nonequivalent”

Experiments (MPEG4) Optimization of IDCT functions (idct_row & idct_col) in MPEG4 Sizes Whole MPEG4 program … more than 17k lines Target IDCT functions … about 50 lines Note 9 lines are different between descriptions (of each function) Each function has 8 conditional branches (i.e. 256 execution paths have to be proved)  functions were unrolled 8 times

Experiments (MPEG4) An example of different parts (below) Results
Each pair of functions was proved to be equivalent idct_row … 680 sec idct_col … 2190 sec tmp = x6; x6 = W3 * x7 + W5 * tmp; x7 = W3 * tmp – W5 * x7; x8 = x0 + x1; x8 = W3 * (x6 + x7); x6 = x8 – (W3 – W5) * x6; x7 = x8 – (W3 + W5) * x7; x8 = x0 + x1; Optimization Description 1 Desciption 2

Experiments (AES) Changes in AES (American Encryption Standard)
Target: Encryption function in Rijndael Rijndael is an implementation of AES Size: 120 lines Case 1 (equivalent changes) 4 different parts were inserted Result … equivalent, Verification time … 6 sec Case 2 (not equivalent changes) 8 different parts were inserted Result … not equivalent, Verification time … 344 sec Case 2 took longer time because many statements were affected by nonequivalent variables

Synchronization verification: Overview
In system-level design… Communication among parallel processes is necessary To operate properly, those parallel processes must be correctly scheduled/synchronized Synchronization verification Guarantee the order of execution of statements as designers’ intended Problem size can be significantly reduced (focus on some, not all, parts of the design) More confident when “SV” and “property checking” than “property checking” alone

Par statement in SpecC C Language SpecC Language A A B B C C
void A() { } void B() { void main() { A(); B(); C(); void C() { A void A() { } void B() { void main() { par{ A.main(); B.main(); C.main(); void C() { A B B C C

Synchronization in SpecC
Add notify/wait of event e for sync. ‘wait’ will stop process until it is ‘notify’ void A() { } void B() { void main() { par { A.main(); B.main(); notify e1; wait e2; wait e1; notify e2; A B wait e1 Process B stops and wait until e1 is notified notify e1 B resumes wait e2 Process A stops and wait until e2 is notified notify e2 A resumes

Synchronization in SpecC
Ambiguous results on y causing from x = 10; /*st1*/ x = 20; /*st3*/ y = 20 (always)

Synchronization in SpecC (cont.)
y = 20 (always) Tas=Tbs, Tae=Tbe Tas<=T1s<T1e<=T2s<T2e<=Tas Tbs<=T3s<T3e<=Tbe T2e<=T3s

Synchronization verification for two concurrent processes (1)
Check if wait/notify can acutually communicate in while loops (or nested loops) First approach: Delete while loop In each iteration notify/wait must communicate while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt wait e1 notify e1 wait e1 notify e1 notify e2 notify e2 wait e2 wait e2 } } } }

Synchronization verification for two concurrent processes (2)
Unfold by N and M times N is 1 to n, M is 1 to m, any combinations while (1) { } notify e2 wait e1 if stmnt switch stmnt while (1) { while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt while (1) { } notify e2 wait e1 if stmnt switch stmnt if stmnt switch stmnt notify e1 wait e1 wait e2 notify e1 } notify e2 while (1) { if stmnt switch stmnt while (1) { } notify e2 wait e1 if stmnt switch stmnt wait e2 notify e1 wait e2 } } }

Synchronization verification for two concurrent processes (3)
While loops are converted into FSM (nested loops can be treated in the same way) Basically need regular model checking while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt switch stmnt if stmnt wait e1 notify e1 wait e1 notify e1 notify e2 switch stmnt notify e2 wait e2 wait e2 if stmnt } }

Example(1) Par behavior1 {notify e1; a; wait e2; b}
Behavior2 {wait e1; c; notify e2; d} e1 < a, a < e2, e2 < b, e1 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, so the description is correct behavior1 {wait e2; a; notify e1; b} e2 < a, a < e1, e1 < b, e1 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → No, since a < c and c < a. This means a deadlock ! notify e1 a wait e2 b wait e1 c notify e2 d wait e2 a notify e1 b wait e1 c notify e2 d

Example(2) Par behavior1 {notify e1; a; waitfor(10); wait e2; b}
Behavior2 {wait e1; waitfor(10); c; notify e2; d} e1 < a, a + 10 < e2, e2 < b, e < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correct Moreover, b<c is satisfied ? → No, the result says c<b behavior1 {notify e1; a; wait e2; waitfor(10); b} e1 < a, a < e2, e < b, e < c, c < e2, e2 < d Moreover, b – e1 < 20 is satisfied ? → No, this is not satisfied wait e1 　ｗaitfor(10) c notify e2 d notify e1 a wait e2 　ｗaitfor(10) b wait e1 　ｗaitfor(10) c notify e2 d

Verification flows Goals: Based on:
Check whether given SpecC codes (with ‘par’, ‘notify/wait’) are properly synchronized If checking fails, counter-examples should be generated (trace to source of errors) Based on: Boolean SpecC, a little theorem prover, SVC/CVC, Program Slicing, ...

Abstraction refinement
Verification Flows behavior A(out event e, inout int x, inout int y) { void main(){ if (x > 1) { notify e; y = x - 1; } if (y > 3) { . SpecC Verify with a theorem prover Correct Error-trace Boolean SpecC behavior A() { if (C0) { notify e ... if (C1) { Refining Abstraction refinement Abstraction

Boolean Program Proposed by Ball and Rajamani under SLAM project at Microsoft Research Think of SW like a model (like FSM in HW) and verify it by first abstracting away unnecessary statements with user-defined predicates BP abstracts the original program: if properties on BP hold, so as original one

Our Boolean SpecC is a subset of original SpecC program
‘if-else’ conditions are replaced by propositional vars. e.g. if(x<y) -> if(c0) Statements other than ‘notify/wait’ and ‘if’, (ones that don’t effect the sync.) are abstracted away (abstract unnecessary info.) Only for verification of synchronization

Abstraction refinement
Refining SpecC Boolean SpecC Correct behavior A(out event e, inout int x, inout int y) { void main(){ if (x > 1) { notify e; y = x - 1; } if (y > 3) { . Verify with a theorem prover behavior A() { void main(){ if (C0) { notify e ... } if (C1) { . Abstraction Error-trace Constructing Control Flow Graph (CFG) Check validity Symbolic sim & theorem prover Find & Modify Predicates Abstraction refinement

Abstraction refinement
SpecC => boolean SpecC & build Control Flow Graph (CFG) Verify with theorem provers. If result is satisfied, terminate, else go to next step Use CFG to find related path and symbolically simulate along the path Use theorem provers on the validity of the path If not a feasible path, analyze and generate conditions on Boolean program variables using SpecC program slicing Use those conditions and modify boolean SpecC Go to 2

Example: Sleeping barber problem

Example behavior Main () { void main() { par { barber.main();
customer.main(); } }; behavior barber (inout event call, inout bool chairOccupied, inout bool waitCustomer) { void main() { while(1) { if (waitCustomer == false) DayDreaming(); else { if (chairOccupied == true) { KeepCutting(); chairOccupied = false; } notify call; chairOccupied = true; }; behavior customer (inout event call, inout bool chairOccupied, inout bool waitCustomer) { void main() { while(1) { if (waitCustomer == false) waitCustomer = true; else { waitCustomer = false if (chairOccupied == false) wait call; } };

Property to be verified:
Abstract /* Barber */ void main() { while(1) { if (!waitCustomer) DayDreaming(); (A1) else { if (chairOccupied) { KeepCutting(); (A2) chairOccupied = false; (A3) } notify call; (A4) chairOccupied = true; (A5) }; /* Customer */ waitCustomer = true; (B1) waitCustomer = false; (B2) if (!chairOccupied) wait call; (B3) /* Barber */ void main() { while(a0) { if (a1) ... else { if (a2) { } notify call; }; /* Customer */ while(b0) { if (b1) if (b2) wait call; Construct model + Verify Property to be verified: ‘notify’ is not reached, ‘wait’ is reached, then Synchronization error! A4 is not reached and B3 is reached Error!!! (Deadlock)

   a2  chairOccupied==true a1  waitCustomer==false /* Barber */
void main() { while(1) { if (!waitCustomer) DayDreaming(); else { if (chairOccupied) { KeepCutting(); chairOccupied = false; } notify call; chairOccupied = true; }; /* Customer */ waitCustomer = true; waitCustomer = false; if (!chairOccupied) wait call; /* Barber */ void main() { while(1) { if (a1) ... else { if (a2) { } notify call; }; /* Customer */ if (b1) if (b2) wait call; /* Barber */ void main() { while(1) { if (a1) ... else { if (a2) { !a2 } notify call; a2 }; /* Customer */ if (b1) if (!a2) wait call; /* Barber */ void main() { while(1) { if (a1) ... else { if (a2) { !a2 } notify call; a2 }; /* Customer */ !a1 a1 if (!a2) wait call;

Evaluation of the synchronization verification methods(1)
We injected ‘wait’ statements into the original SpecC descriptions (to cause deadlock, and verify it) Focusing only synchronization (notify/wait under par{ }), problem size can be significantly reduced Running on Linux machine, P3 1.1GHz & 2GB RAM, deadlock can be detected within few minutes

How to deal with loops ? Loops that create numbers of ‘notify/wait’ have to be unwound to get the equal numbers of notify and wait (analysis on loops of ‘notify/wait’ can be considered as another interesting research topic) This loop creates infinite numbers of wait(clk16) With multiple of 16 ‘wait(clk16)’ each time This loop creates infinite numbers of notify(clk16) behavior gen_clk16() { void main() { while(1) { waitfor(10); notify(clk16); } }; behavior tx_clk() { void main() { while(1) { for(i = 0; i < 16; i++) wait(clk16); notify(bit_event); } };

Experimental results FIFO example Point-to-point protocol
~260 lines 3 behaviors and 2 interfaces Point-to-point protocol ~850 lines 5 behaviors have sync. semantic, 12 behaviors total Elevator control system ~2000 lines 3 behaviors have sync. semantic, 13 behaviors total MPEG4 ~48,000 lines 3 behaviors have sync. semantic, XX behaviors total

Experimental results Properties: checking for deadlock
When consider only parallel behaviors Problem size (# of lines) can be reduced

C Bounded Model Checking
CBMC Developed at CMU, 2003 [1] Hardware Verification using ANSI-C Programs as a Reference (Proc. of ASPDAC’03) Characteristics Modeling … C program -> Bit vector equation Specifying properties … inserting assertions in C programs Verification … using SAT solver C program Modeling Bit Vector Equation Specifying properties Verification 　　　using SAT solver Result

What does CBMC do? CBMC checks if or not C programs satisfy the properties the user specify Input … C Program with assertions as properties Output … Result (Success/Fail). If fails, a counter example is reported char a, b; int c; if (a < b) c = b – a; else c = a – b; assert (c >= 0); char a, b; int c; if (a < b) c = b – a; else c = a – b; assert (c != 0); Success Fail Counter example (a = 39, b = 39)

Bounded Model Checking (BMC)
A kind of Model Checking techniques Checking whether the design satisfies the property up to certain finite numbers of execution cycles (bound) on the system Correctness of the design is guaranteed only up to the bound BMC is useful when the design is too large to handle for other formal methods BMC can detect many bugs although it only guarantees that there is no counter examples up to the bound number of execution cycles

BMC for C Programs What does “bound” mean in C program?
In C programs, cycle is not explicit “bound” means the number of loop unwinding Combinati- onal circuit Combinati- onal circuit Combinati- onal circuit Satisfies given properties? Input Output BMC in RTL (behavior of only 3 cycles are verified) Loop Loop Loop Loop Unwinding BMC of a loop in C program

Process of CBMC Modeling SAT solver (Chaff)
Given C program & properties Bit vector equation Generating SAT formula SAT solver (Chaff) Result (success/fail) counter example

Transforming ANSI-C (1)
Renaming After renaming, each variable appears only once in the left hand side of assignments α is the number of assignments made to variable v

Renaming x, y in right hand are not assigned yet x in left hand is assigned at the 1st time This x is equivalent to the x after the 1st assignment This x is assigned at the 2nd time ・・・

Transforming ANSI-C (2)
Transformation into bit vector equation Formula C describes the Constraint of the verification Formula P describes the Property to be verified Checking if or not “C -> P” is always true

Formal definition of transformation from C into bit vector equation
C(p, g) and P(p, g) C(p,g) computes the assignments P(p,g) computes the properties p … program block g … guard (condition that p is operated)

Example of transformation
S … assignment S’ … conditional branch If the program is a sequential composition, C (p, g) is split by using ∧ operator Apply this rule ※At the start of the program, 　“guard” is always “true”

Example of transformation
S … assignment S’ … conditional branch If program is an assignment v = e, C (p, g) is generally described as Apply this rule

Example of transformation
S … assignment S’ … conditional branch If program is a conditional branch if(c) I; else I’;, C (p, g) is generally described as Apply this rule

Example of transformation
Assertion Computation of P formula from assertions Apply this rule ※ In this case, guard is true

Loop unwinding CBMC makes loops unwind finite times Unwinding process
Because “Bounded” Model Checking Only the finite number of statements are verified The number of unwinding can be determined by the user Unwinding process Do loop unwinding n times by the following transformation The last while loop is replaced by assert(!e); (“unwinding assertion”) If “unwinding assertion” is satisfied, the number of unwinding is sufficient while (e) inst; → if (e) { inst; while (e) inst; }

Unwinding assertion Unwinding n times if (e) { inst; if (e) {
assert(!e); } } } while (e) inst; Original loop unwinding assertion Verification Is “unwinding assertion” violated? yes no Unwound loop Need to unwind more Unwinding is sufficient

Removing pointers Pointer dereferences are removed in the process of transformation Example. if (x) p = &a; else p = &b; *p =1; x = true -> *p = a x = false -> *p = b What does this pointer dereference? How do we remove pointers automatically? Introducing the φ function to analyze pointer dereferences

Removing pointers by using the φ function
Definition e … sub-expression to be dereferenced g … guard (condition that the dereference is operated) o … offset Renaming

Verification with SAT Solver
Satisfiability Problem (SAT Problem) Formula F is satisfiable if there is more than one input pattern that makes F true Ex. F1 = a ∧ b … satisfiable (when a = true, b = true) Ex. F2 = a ∧ ￢a … not satisfiable If (C -> P) is always true, ￢（C -> P） is not satisfiable Verification with SAT solver (Chaff) Bit vector equation from C program

int exam () { int array[3], i, sum=0; for (i=0; i<=3; i++) { array[i] = input(); sum = sum + array[i]; } return sum; } This means the value is input at this point CBMC can detect the over bound access to array indices This program is faulty since array[3] is accessed when i = 3 If (i <= 3) is replaced by (i < 3), this program becomes correct

Assertion checking CBMC can verify data-dominant properties
<-> control-dominant properties as “safety properties” int main () { unsigned char a, b; unsigned char ai, bi; unsigned int result = 0, i; a = input; b = input; for (i = 0; i < 8; i++) { bi = (b>>i); ai = (a<<i); if ( bi & 1) result += ai; } assert (result == a * b); } Suppose i=1 101 (a) × (b) bi = 1 ai = 10100 This corresponds to the sub-product of (a) * (2nd digit of b)

Experimental results Using CBMC, the behavioral consistency of C and Verilog programs can be checked Some experimental results are reported below* PS/2 interface 700 lines of Verilog, unwinding bound 48, run time 51 sec. DLX processor Verilog design with 1219 latches, 550 lines of C, run time 97 sec., detected a counter example of length 5 cycles Behavioral consistent? Verilog C *: Behavioral Consistency of C and Verilog Using Bounded Model Checking (Proc. of DAC’03)

Final remarks: Verification directions
Driven by design flow Higher levels of abstraction Formal specification languages Mapping verification problems to lower level engines Design reuse Interface verification System level verification Tackling larger designs in formal verification Efficient formal engines Sequential equivalence checkers Filter based techniques Using multiple engines Hybrid engines E.g. BDD/SAT/ATPG combination Higher level reasoning Need to automate

Final remarks: Research issues
Design and verification at high levels of abstraction New modeling issues Eg: what if Spec is in UML How to generate problem, map problem Faster engines More efficient BDDs Efficient and automatic abstraction-refinement Faster SAT solvers Better learning and pruning techniques Combining engines ATPG/SAT combination BDD/SAT combination Use of higher level information to guide search Methodology issues Interface specification and verification Automatic static checks

Bibliography on verification

Books B. Berard et. al., “Systems and Software Verification: Model Checking Techniques and Tools”, Springer Verlag, 2001. J. Bergeron, “Writing Testbenches: Functional Verification of HDL Models”, Kluwer Academic Publishers, Boston, 2000. D.D. Gajski et. al., “SpecC: Specification Language and Methodology”, Kluwer Academic Publishers, Boston, 2000. J. Bhasker, “ A SystemC Primer ”, Star Galaxy Press, Allentown, 2002. M. Suart and D. Dempster, “ Verification Methodology Manual for Code Coverage in HDL Designs”, Teamwork International, Hampshire, UK, 2000. K. L. McMillan, Symbolic Model Checking'', Kluwer Academic Publishers, 1993. Z. Manna and A. Pnueli, “Temporal Specification and Verification of Reactive Systems” Vol. I and II, Springer 1995. Ching-Tsun Chou, "The Mathematical Foundation of Symbolic Trajectory Evaluation", Springer-Verlag 1999. Thomas Kropf: "Introduction to Formal Hardware Verification", (Springer Verlag; ISBN: , 299 pages, January 2000) E. M. Clarke, O. Grumberg and D. Peled, "Model Checking", (MIT Press; ISBN: ; 330 pages; January 2000) G. J. Holzmann, “Design and Validation of Computer Protocols”, Prentice Hall, 1991. M. P. Fourman, “Formal System Design”, Formal Methods for VLSI Design, IFIP, 1990, North-Holland. C. Meinel and T. Theobald, “Algorithms and Data Structures in VLSI Design”, Springer-Verlag, 1998. Hassan Gomaa, “Designing Concurrent, Distributed and Real-Time Applications with UML”, Addison-Wesley, July 2000.

Books L. Bening and H. Foster, “Principles of Verifiable RTL Design: Functional Coding Style Supporting Verification Processes in Verilog”, published by Kluwer Academic Publishers, 2000. R. P. Kurshan, “Computer Aided Verification of Coordinating Processes”, Princeton University Press, 1994. Robert B. Jones, “Symbolic Simulation Methods for Industrial Formal Verification”, Kluwer Academic Publishers, Boston, 2002. M. Yoeli, "Formal Verification of Hardware Design", IEEE Computer Society Press, (Book containing a collection of papers) G. J. Holzmann, “Design and Validation of Computer Protocols”, Prentice Hall, 1991. M. P. Fourman, “Formal System Design”, Formal Methods for VLSI Design, IFIP, 1990, North-Holland. C. Meinel and T. Theobald, “Algorithms and Data Structures in VLSI Design”, Springer-Verlag, 1998. M. Kaufmann, P. Manolios, and J S. Moore, "Computer-Aided Reasoning: An Approach", (Kluwer Academic Publishers, June 2000; ISBN ) Robert B. Jones, Symbolic Simulation Methods for Industrial Formal Verification, Kluwer Academic Publishers, Boston, 2002. M. Keating and P. Bricaud “Reuse Methodology Manual for System-On-A-Chip Designs,” Kluwer Academic Publishers, June 1998.

Papers High Level Design and Verification Modeling
D. D. Gajski, IP-Based Design Methodology'', Proc. of the 36th Design Automation Conference, pp. 43, New Orleans, June 1999. D. Kroening and E. Clarke, “Behavioral consistency of C and Verilog programs using bounded model checking,” in Proc. DAC, June T. Sakunkonchak and M. Fujita, “Verification of synchronization in SpecC description with the use of difference decision diagram,” IEICE Trans. Fundamentals, Vol. E85-A, Jan 2002. T. Matsumoto and M. Fujita, “Equivalence checking of C-based hardware descriptions by using symbolic simulation and program slicer,” in Proc. IWLS, May 2003. T. Ball and S. Rajamani, “Checking Temporal Properties of Software with Boolean Programs”, in Proc. Computer Aided Verification 2000, [Microsoft SLAM project] R. Bryant et . al. “Processor Verification Using Efficient Reductions of the Logic of Uninterpreted Functions to Propositional Logic” in ACM Trans. on Computational Logic, Vol 2., 2001. S. Singh, “Design and Verification of CoreConnectTM IP using Esterel,” in Proc CHARME S. Sutherland, “System Verilog 3.1 Its what the DAVEs in you company asked for”. in Proc. DVCON 2003 S. Abdi, D. Shin and D. Gajski, "Automatic Communication Refinement for System Level Design,” Proceedings of Design Automation Conference, Anaheim, CA, June 2003. W. Mueller, R. Dömer, A. Gerstlauer, "The Formal Execution Semantics of SpecC," in Proceedings of International Symposium on System Synthesis, October 2002.

Papers Theorem Proving & Decision Procedures
S. Owre and S. Rajan and J.M. Rushby and N. Shankar and M.K. Srivas, “PVS: Combining Specification, Proof Checking, and Model Checking”, , CAV96. D. Cyrluk, S. Rajan, N. Shankar and M. K. Srivas, “Effective Theorem Proving for Hardware Verification”, pp , TPCD94. S. J. Garland and J. V. Guttag, “An Overview of LP: the Larch Prover”, Proceedings of the Third International Conference on Rewriting Techniques and Applications, 1989, Springer-Verlag. J. Staunstrup and M. Greenstreet, “Synchronized Transitions”, Formal Methods for VLSI Design, 1990, IFIP, North-Holland. R. Vemuri, “How to Prove the Completeness of a Set of Register Level Design Transformations”, Proceedings of the 27th ACM/IEEE Design Automation Conference, 1990, 207—212. C. M. Angelo, “Formal Hardware Verification ina Silicon Compilation Environment by means of Theorem Proving”, Ph.D. Dissertation, Katholieke Universiteit Leuven (February, 1994).

Papers R. Vemuri, “How to Prove the Completeness of a Set of Register Level Design Transformations”, Proceedings of the 27th ACM/IEEE Design Automation Conference, 1990, 207—212. Jeffrey J. Joyce and Carl-Johan H. Seger, “Linking Bdd Based Symbolic Evaluation to Interactive Theorem Proving”, Proceedings of the 30th Design Automation Conference, 1993. S. P. Rajan, N. Shankar and M. Srivas, “An Integration of Model-Checking with Automated Proof Checking”, 7th Conference on Computer-Aided Verification, July, 1995. M.D. Aagard, R.B. Jones and C.-J.H. Seger, “Combining Theorem Proving and Trajectory Evaluation in an Industrial Environment”, Proceedings of DAC 1998, pp C.W. Barrett, D.L. Dill and J.R. Levitt, “A Decision Procedure for Bit-Vector Arithmetic”, Proceedings of DAC 1998 J.R. Burch and D.L. Dill, “Automatic Verification of Pipelined Microprocessor Control”, Proceedings of CAV 1994 J.X. Su, D.L. Dill and C.W. Barrett, “Automatic Generation of Invariants in Processor Verification”, Proceedings of FMCAD 1996 M. Aagaard, M. E. Leeser, and P. J. Windley, “Toward a Super Duper Hardware Tactic”, in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August : Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp F. Andersen, K. D. Petersen, and J. S. Pettersson, A Graphical Tool for Proving UNITY Progress', in Higher Order Logic Theorem Proving and Its Applications: 7th International Workshop, Valletta, Malta, September 1994: Proceedings, edited by T. F. Melham and J. Camilleri, Lecture Notes in Computer Science, Volume 859 (Springer-Verlag, 1994), pp

Papers S. Agerholm, Domain Theory in HOL', in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August : Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp S. Agerholm, Formalising a Model of the lambda-calculus in HOL-ST' Technical Report Number 354, University of Cambridge Computer Laboratory (1994). S. Agerholm, “A HOL Basis for Reasoning about Functional Programs”, Ph.D. Dissertation, BRICS Technical Report RS-94-44, Department of Computer Science, University of Aarhus (December 1994). S. Agerholm, “LCF Examples in HOL”, The Computer Journal, vol. 38, no. 2 (July 1995), pp S. Agerholm, Mechanizing Program Verification in HOL', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp S. Agerholm, Mechanizing Program Verification in HOL', M.Sc. Dissertation, DAIMI Report Number IR-111, Department of Computer Science, University of Aarhus (April 1992). S. Agerholm “Non-Primitive Recursion Function Definition”, in Higher Order Logic Theorem Proving and Its Applications: 8th International Workshop, Aspen Grove, Utah, September 1995: Proceedings, edited by E. T. Schubert, P. J. Windley, and J. Alves-Foss, Lecture Notes in Computer Science, Volume 971 (Springer-Verlag, 1995), pp F. Andersen and K. D. Petersen, Recursive Boolean Functions in HOL', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp

Papers C. M. Angelo, L. Claesen, and H. De Man, “Degrees of Formality in Shallow Embedding Hardware Description Languages in HOL”, in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August : Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp C. M. Angelo, L. Claesen, and H. De Man, The Formal Semantics Definition of a Multi-Rate DSP Specification Language in HOL', in Higher Order Logic Theorem Proving and its Applications: Proceedings of the IFIP TC10/WG10.2 International Workshop, Leuven, September 1992, edited by L. J. M. Claesen and M. J. C. Gordon, IFIP Transactions A-20 (North-Holland, 1993), pp C. M. Angelo, L. Claesen, and H. De Man, “Modeling Multi-rate DSP Specifiction Semantics for Formal Transformational Design in HOL”, Formal Methods in System Design, vol. 5, nos. 1/2 (July 1994), pp R. J. R. Back and J. von Wright, Predicate Transformers and Higher Order Logic', in Semantics: Foundations and Applications: REX Workshop, Beekbergen, June 1992, edited by J. W. de Bakker, W.-P. de Roever, and G. Rozenberg, Lecture Notes in Computer Science, Volume 666 (Springer-Verlag, 1993), pp R. J. R. Back and J. von Wright, Refinement Concepts Formalised in Higher Order Logic', Formal Aspects of Computing, Vol. 2, No. 3 (July-September 1990), pp S. Bainbridge, A. Camilleri, and R. Fleming, Industrial Application of Theorem Proving to System Level Design', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp F. Andersen, K. D. Petersen, and J. S. Pettersson, Program Verification using HOL-UNITY', in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August : Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp

Papers R. H. Beers and P. J. Windley, Abstracting Signals: The waveform Library', in Supplementary Proceedings of the 9th International Conference on Theorem Proving in Higher Order LogicsL TPHOLs ’96, edited by J. von Wright, J. Grundy, and J. Harrison, TUCS General Publication No 1, Turku Centre for Computer Science (August, 1996), pp G. Birtwistle and B. Graham, Verifying SECD in HOL', in Formal Methods for VLSI Design: IFIP WG 10.2 Lecture Notes, edited by J. Staunstrup (North-Holland, 1990), pp G. Birtwistle, B. Graham, and S.-K. Chin, “New theory HOL: An Introduction to Hardware Verification in Higher Order Logic”, (August 1994). [Published electronically.] R. Boulton, Boyer-Moore Automation for the HOL System', in Higher Order Logic Theorem Proving and its Applications: Proceedings of the IFIP TC10/WG10.2 International Workshop, Leuven, September 1992, edited by L. J. M. Claesen and M. J. C. Gordon, IFIP Transactions A-20 (North-Holland, 1993), pp R. Boulton, “Combining Decision Procedures in the HOL System”, in Higher Order Logic Theorem Proving and Its Applications: 8th International Workshop, Aspen Grove, Utah, September 1995: Proceedings, edited by E. T. Schubert, P. J. Windley, and J. Alves-Foss, Lecture Notes in Computer Science, Volume 971 (Springer-Verlag, 1995), pp R. J. Boulton, “Efficiency in a Fully-Expansive Theorem Prover”, Ph.D. Dissertation, Technical Report Number 337, University of Cambridge Computer Laboratory (May 1994).

Papers Formal Verification: SAT Solvers Formal Verification: BDDs
J. Marques-Silva and K. Sakallah, “GRASP: A Search Algorithm for Propositional Satisfiability”, IEEE Transactions on Computers, 48(5): , May 1999 M. Sheeran and G. Stalmarck, “A tutorial on Stalmarck’s proof procedure for propositional logic”, Formal Methods in System Design, 16(1):23-58, January 2000 M.H. Moskewicz et. al., “Chaff: engineering an efficient SAT solver,” in Proc. Design Automation Conf., June 2001. E. Goldberg and Y. Novikov, “BerkMin: a Fast and Robust Sat-Solver”, Proceedings of Design Automation and Test in Europe, pp , March 2002. Formal Verification: BDDs R. E. Bryant, “Graph Based Algorithms for Boolean Function Manipulation”, IEEE Transactions on Computers, Vol. C-35-8, pp , August 1986 R. Rudell, “Dynamic Variable Ordering for Ordered Binary Decision Diagrams”, Proceedings of ICCAD 1993, pp R. E. Bryant, “On the Complexity of VLSI Implementations and Graph Representations of Boolean Functions with Application to Integer Multiplication”, IEEE Transactions on Computers, Vol. 40, No. 2, pp, , February 1991 B. Bollig and I. Wegener, “Improving the variable ordering for OBDDs is NP-complete”, IEEE Transactions on Computers, Vol. 45, No. 9, pp , September 1996 M. Fujita, H. Fujitsawa and Y. Matsunaga, “Variable Ordering Algorithms for Ordered Binary Decision Diagrams and their Evaluation”, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 12, No. 1, pp , January 1993 R. Bryant, “Symbolic Boolean Manipulation with Ordered Binary Decision Diagrams”, slides from a presentation by Prof. Bryant in August 1999

Papers Formal Verification: Symbolic Model Checking (BDDs)
D. L. Dill, “The Mur Verification System”, , CAV96. R. Bryant, E. Clarke, K. McMillan and A. Emerson, “Binary Decision Diagrams and Symbolic Model Checking”, slides from a presentation at Symposium on Algorithms in the Real World, May, 2000 E. M. Clarke, E. A. Emerson and A. P. Sistla, Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications'', ACM Trans. on Programming Language and Systems, Vol.8, No.2, pp , April 1986. J. Burch, E. Clarke, D. Long, K. McMillan, D. Dill, “Symbolic Model Checking for Sequential Circuit Verification”, IEEE Trans. Computer Aided Design, 13, 1994, C. Kern and M. Greenstreet, "Formal Verification in Hardware Design: A Survey", ACM Transactions on Design Automation of E. Systems, Vol. 4, April 1999, pp H. Iwashita and T. Nakata,  Forward Model Checking Techniques Oriented to Buggy Designs'', Proceedings of ICCAD, pp , 1997. K. Takayama, T. Satoh, T. Nakata, and F. Hirose, An approach to Verify a Large Scale System-on-a-chip Using Symbolic Model Checking'', Proceedings of ICCD, 1998. A. J. Hu, “Formal Hardware Verification with BDDs : An Introduction”, ACM Transactions on Programming Languages and Systems, 1997. M. Kaufmann, A. Martin, and C. Pixley, "Design Constraints in Symbolic Model Checking", Proc. CAV-98, pp , 1998. K. L. McMillan, "Fitting formal methods into the design cycle", Proceedings of the 31st Design Automation Conference, pp , 1994

Papers Formal Verification with SAT solvers
P. Abdulla, P. Bjesse and N. Een, “Symbolic Reachability Analysis Based on SAT Solvers”, Proceedings of Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pp , March 2000 P. Williams et al, “Combining Decision Diagrams and SAT Procedures for Efficient Symbolic Model Checking”, Proc. of the 12th CAV, pp , July 2000 M. Sheeran, S. Singh and G. Stalmarck, “Checking Safety Properties Using Induction and a SAT Solver”, Proc. of the 3rd Intl. Conference on Formal Methods in CAD (FMCAD), pp , Nov. 2000 P. Bjesse and K. Claessen, “SAT-based Verification without State Space Traversal”, Proc. of the 3rd FMCAD, pp , Nov. 2000 K.L. McMillan, “Applying SAT Methods in Unbounded Model Checking”, Proc. of the 14th CAV, pp , July 2002 K.L. McMillan, “Interpolation and SAT-based Model Checking”, Proc. of the 15th CAV, July 2003 I. Park and H. Kang, “SAT-based unbounded symbolic model checking”, Proceedings of DAC, pp , June 2003

Papers Equivalence Checking
D. Brand, “Verification of Large Synthesized Designs”, Proceedings of ICCAD, November 1993, pp A. Kuehlmann and F. Krohm, “Equivalence Checking using Cuts and Heaps”, Proceedings of DAC 1997, pp Y. Matsunaga, “An Efficient Equivalence Checker for Combinational Circuits”, Proceedings of DAC 1996, pp R. Mukherjee, J. Jain, K. Takayama, M. Fujita, J. Abraham and D. Fussell, “An Efficient Filter Based Approach for Combinational Verification”, in IEEE Transactions on CAD, 18: , Nov. 1999 H. Cho and C. Pixley, “Apparatus and Method for deriving correspondences between storage elements of a first circuit model and storage elements of a second circuit model”, U.S. Patent 5,638,381, June 1997 K. Ng, M. Prasad, R. Mukherjee and J. Jain, “Solving the Latch Mapping Problem in an Industrial Setting”, Proceedings of DAC 2003, pp C.A.J. van Eijk, “Sequential Equivalence Checking Based on Structural Similarities”, IEEE Transactions on CAD, 19(7): , July 2000 S.-Y. Huang, K.-T. Cheng, K.-C. Chen and F. Brewer, “AQUILA: An Equivalence Checking System for Large Sequential Circuits”, IEEE Transactions on Computers, 49(5), May 2000

Papers Semi-Formal Verification
R. E. Bryant, “Symbolic Simulation -- Techniques and Applications”, Proceedings of DAC 1990 R.B. Jones, “Applications of Symbolic Simulation to the Formal Verification of Microprocessors”, Ph.D. Thesis, Computer Systems Laboratory, Stanford University, August 1999 R.E. Bryant and C.J.H. Seger, “Formal hardware verification by symbolic trajectory evaluation,” in Proc. Design Automation Conf., June 1991. C.-J.H. Seger and R.E. Bryant, “Formal Verification by Symbolic Evaluation of Partially Ordered Trajectories”, Formal Methods in System Design, Vol. 6, No. 2, pp , 1995 E. Clarke, A Biere, R. Raimi and Y. Zhu, “Bounded Model Checking Using Satisfiability Solving”, in Formal Methods in System Design, 19(1): 7-34, July 2001, Kluwer Academic Publishers O. Shtrichman, “Tuning SAT Checkers for bounded model checking,” in Proc. Int. Conf. on Computer-Aided Verification, July 2000. F. Fallah, “Binary Time-Frame Expansion”, Proc. of ICCAD, pp , Nov. 2002 A. Gupta et al, “Learning from BDDs in SAT-based bounded model checking,” in Proc. Design Automation Conf., June 2003. V. Boppana, S. Rajan, K. Takayama and M. Fujita, “Model Checking Based on Sequential ATPG”, Proceedings of CAV, pp , July 1999. J. Abraham, V. Vedula and D. Saab, “Verifying Properties Using Sequential ATPG”, Proceedings of International Test Conference, October 2002

Papers Model Checking in Practice
D. Dill and S. Tasiran, "Simulation meets Formal Verification?", slides from a presentation at ICCAD'99. D. Dill, "Alternative Approaches to Formal Verification (Symbolic Simulation)", slides from a presentation at CAV 1999. C. H. Yang and D. L. Dill, “Validation with Guided Search of the State Space”, Proceedings of DAC 1998 M. Ganai et al, “SIVA: A System for Coverage Directed State Space Search”, In Journal of Electronic Testing: Theory and Applications (JETTA), February 2001 P.-H. Ho et al, “Smart Simulation Using Collaborative Formal and Simulation Engines”, Proceedings of ICCAD, pp , November 2000 Y. Hoskote, T. Kam, P. Ho and X. Zhao, Coverage Estimation for Symbolic Model Checking'', Proc. of the 36th Design Automation Conference, New Orleans, June 1999. S. Katz, O. Grumberg and D. Geist, Have I written enough properties? - A method of comparison between specification and implementation'', Technical Report, IBM Haifa Research Laboratory, Haifa, Israel, 1999. Model Checking in Practice S. Berezin, S. Campos and E. M. Clarke, Compositional Reasoning in Model Checking'', Technical Report - CMU-CS , School of Computer Science, Carnegie Mellon University, February, 1998.

Papers K. L. McMillan, "A compositional rule for hardware design refinement", Computer Aided Verification (CAV97), O. Grumberg (Ed.), Haifa, Israel, pp , 1997. T.A.Henzinger, S. Qadeer, and S.K.Rajamani, "You assume, We guarantee : Methodology and Case Studies" CAV98: Computer Aided Verification, Lecture Notes in Computer Science, Springer-Verlag, pp , 1998. G. Mosensoson, “Practical Approaches to SoC Verification”, DATE 2000. J. L. Nielsen, H. R. Andersen, G. Behrmann, H. Hulgaard, K. Kristoffersen and K. G. Larsen, “Verification of Large State/Event Systems using Compositionality and Dependency Analysis”, Proceedings of TACAS 1998, LNCS 1384, April 1998. D. Geist, G. Biran, T. Arons, M. Slavkin, Y. Nustov, M. Farkas, and K. Holtz, “A Methodology for the verification of a System on Chip”, Proc. Of DAC 1999, pp A. Evans, A. Silburt, G. Vrckovnik, T. Brown, M. Dufresne, G. Hall, T. Ho and Y. Liu, “Functional Verification of Large ASICs”, Proc. Of DAC, 1998. S. Taylor, M. Quinn, D. Brown, N. Dohm, S. Hildebrandt, J. Higgins and C. Ramey, “Functional Verification of a Multiple-issue, Out-of-Order, Superscalar Alpha Processor – the DEC Alpha Microprocessor”, Proc. Of DAC, 1998. T. Henzinger, X. Liu, S. Qadeer and S. Rajamani, “Formal Specification and Verification of a Dataflow Processor Array,”Proceedings of ICCAD 1999 D. Wang, “SAT based Abstraction Refinement for Hardware Verification”, Ph.D. thesis, ECE Dept., Carnegie Mellon University, May 2003 Shankar G. Govindaraju, David L. Dill, Alan J. Hu, and Mark A. Horowitz. "Approximate Reachability with BDDs using Overlapping Projections,” in Proc. DAC 1998 Gaurishankar Govindaraju, "Approximate Symbolic Model Checking using Overlapping Projections" Ph.D. thesis, Stanford University, August 2000.

Papers Simulation Based Verification
I. Ghosh and M. Fujita, Automatic test pattern generation for functional register-transferlevel circuits using assignment decision diagrams,'' IEEE. Trans. on Computer-Aided Design, Vol. 20, No. 3, pp , March 2001. F. Fallah, S. Devadas, and K. Keutzer, OCCOM: Efficient computation of observability-based code coverage metrics for functional verification,'' IEEE. Trans. on Computer-Aided Design, Vol. 20, No. 8, pp , Aug F. Fallah, S. Devadas, and K. Keutzer, Functional vector generation for HDL models using linear programming and 3-satisfiability,”{\em IEEE. Trans. on Computer-Aided Design}, Vol. 20, No. 8, pp , Aug S. Ravi, G. Lakshminarayana, and N.K. Jha, `TAO: Regular expression based high-level testability analysis and optimization,'' in Int. Test Conf., pp , Oct I. Ghosh and S. Ravi, “On automatic generation of RTL validation test benches using circuit testing techniques,” in Proc. Great Lakes Symposium on VLSI, April 2003. L. Zhang, I. Ghosh and M. Hsiao, “Efficient sequential ATPG for functional RTL circuits,” in Proc. International Test Conference, Oct L. Zhang, I. Ghosh and M. Hsiao, “Automatic design validation framework for HDL descriptions via RTL ATPG,” in Proc. Asian Test Symposium, Nov. 2003 F. Fallah, I. Ghosh, and M. Fujita, “Event driven observability enhanced coverage analysis of C programs for functional validation,” in {\em Proc. Asia and South Pacific Design Automation Conference}, Jan K. Ara and K. Suzuki, “A proposal for transaction level verification with component wrapper language,” Proc. Design Automation and Test in Europe, March 2003. A. U. Shankar, "An Introduction to Assertional Reasoning for Concurrent Systems", ACM Computing Surveys, Sept. 1993, Vol 25, No. 3, pp

Papers S. Ramesh and P. Bhaduri, “Validation of Pipelined Processor Designs using Esterel Tools: A Case Study”, Proc. of CAV '99, LNCS Vol. 1633, 1999. C. Eisner et. al. “The Temporal Logic Sugar” in Proc. Int Conf. on Computer-aided Verification 2001. Miscellaneous J. Jain, W. Adams and M .Fujita, “Sampling Schemes for Computing OBDD Variable Orderings”, Proceedings of ICCAD 1998, pp J. Jain, R. Mukherjee and M. Fujita, “Advanced Verification Technique Based on Learning”, Proceedings of DAC 1995, pp C. H. Yang and D. L. Dill, “Validation with Guided Search of the State Space”, Proceedings of DAC 1998 A. Jain, “Formal Hardware Verification by Symbolic Trajectory Evaluation”, Ph.D. Thesis, Dept. of Electrical and Computer Engineering, Carnegie Mellon University, August 1997 C.-J.H. Seger and R.E. Bryant, “Formal Verification by Symbolic Evaluation of Partially Ordered Trajectories”, Formal Methods in System Design, Vol. 6, No. 2, pp , 1995

Important web-sites vis (Universal Modelling Language HOME-PAGE)

Conference Proceedings
Computer Aided Verification (CAV) Formal Methods in Computer Aided Design (FMCAD) International Conference on Computer-Aided Design (ICCAD) International Conference on Computer Design (ICCD) Design Automation Conference (DAC) Asia South Pacific Design Automation Conference (ASPDAC) International Conference on VLSI Design (VLSI) Advanced Research Working Conference on Correct Hardware Design and Verification Methods (CHARME)

Journals/Magazines IEEE Design and Test of Computers
IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems IEEE Transactions on Computers IEEE Transactions on VLSI Systems ACM Transactions on Design Automation of Electronic Systems Formal Methods in System Design Formal Aspects of Computing