Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo"— Presentation transcript:

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

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

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

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

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

6 6 System-level design & verification 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  System-level RTL Transistor level Bugs fix time Cost due to the delay/late time-to-market revenue loss 3 minutes delay 3 days delay 3 weeks delay

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

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

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

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

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

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

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

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

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

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

17 Cycle-based Simulation l Take advantage of the fact that most digital designs are largely synchronous l Synchronous circuit: state elements change value on active edge of clock l Only boundary nodes are evaluated l Compute steady-state response of the circuit u at each clock cycle at each boundary node Internal Node Boundary Node LatchesLatches LatchesLatches

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

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

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

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

22 22  C1C1C1C1 CONFLICT! DPLL algorithm for SAT Given : CNF formula f(v 1,v 2,..,v k ), and an ordering function Next_Variable Example : C1C1 C2C2 C3C3 1  C3C3C3C3  C2C2C2C2 SAT! 1 c10 b 0 a 0 [Davis, Putnam, Logemann, Loveland 1960,62]

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

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

25 25 Conflict driven search pruning (GRASP) SAT  Non-chronological backtracking  Conflict-clause recording x k-1 xkxkxkxk xkxkxkxk x2x2x2x2 x2x2x2x2 x1x1x1x1 x1x1x1x1 xjxjxjxj xjxjxjxj 1 2 Silva & Sakallah ‘95

26 26 Conflict analysis: An example Decision Assignment: Current Assignment:

27 27 Example continued: Implication graph x 2 = x 11 = x 6 = x 5 = x 1 = x 9 = x 4 = x 3 = x 10 =  3333 3333 1111 2222 2222 4444 4444 5555 5555 6666 6666

28 28 Example continued…. x1x Decision Level x 7 = x 13 = x 12 = x 8 = ```` ```` 9999 9999 9999 7777 7777 8888 x 1 = x 9 = x 10 = x 11 =

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

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

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

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

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

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

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

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

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

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

39 39 From circuits to BDD X1X1 X2X2 X2X X1X1 X2X X1X1 X2X X1X1 X2X X2X X1X X1X1 X2X2 G1 G2 G3 G4

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

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

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

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

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

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

46 46 First-order logic l First-Order Logic u theory in symbolic logic u formalizes quantified statements  E.g: “there exists an object such that…” or “for all objects, it is the case that…” l Statements in first-order logic built using: u Variablesx, y u Constants0, C,  u Functionsf (x ), x + y u Predicatesp (x ), x > y, x = y u Boolean connectives , , ,  u Quantifiers , 

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

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

49 49 Validity checking & undecidability l Given a theory  in first-order logic and an expression  we wish to prove that  is valid in  u Validity of  in  is written as  |=  u 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 u However with appropriate restrictions on  and  the theory can be made decidable and practical programs can be built around l Many practical problems can be posed as formulas in a certain theory or a combination of theories l A proof of validity of this formula results in a solution to the problem u Example  Scheduling of complex operations in a manufacturing plant

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

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

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

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

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

55 55 Overall flow of SVC l Given an expression whose validity has to be checked u Choose an atomic formula ƒ in the expression u 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 ) Example: ( x < y )  ( y < x )  ( x = y )  Choose f = ( x < y ) u Case split on f to get two subformulas Simplify ( true )  ( y < x ) true ( false )  ( y < x )  ( x = y ) ( y < x )  ( x = y )

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

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

58 58 How is validity checking done? l 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 u A literal is an atomic formula or its negation u The core decision procedure depends on the theory  e.g. a Satisfiability Solver can be used for Propositional Logic l SVC proposes u use of several decision theories targeted to several theories u gives the strongest decision procedure

59 59 Need for Multiple Theories l Why are multiple theories needed? u 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 l A decision procedure is u a combination of theories must be able to combine decision procedures that reason in each of these theories!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

76 76 CEC in Practice Key Observation: The circuits being verified usually have a number of internal equivalent functions To prove f () = f’ () To prove f (i 1, i 2,…i n ) = f’ (i 1, i 2,…i n ) x 1 (i 1, i 2,…i n ) = x 1 ’(i 1, i 2,…i n ) x 2 (i 1, i 2,…i n ) = x 2 ’(i 1, i 2,…i n ) x k (i 1, i 2,…i n ) = x k ’(i 1, i 2,…i n ) f(x 1, x 2,…x k ) = f’(x 1 ’, x 2 ’,…x k ’) i2i2 i1i1 f inin f’f’ xkxk x2x2 x1x1 x1’x1’ x2’x2’ xk’xk’ Check

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

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

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

80 80 Reachability-based Equivalence Checking l Build product machine of M 1 and M 2 l Traverse state-space of product machine starting from reset states S 0, S 1 l Test equivalence of outputs in each state l Can use any state-space traversal technique M1M1 M2M2 =? Outputs Inputs S0S0 S1S1 Product Machine S0 S1

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

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

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

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

85 85 Upcoming: Transaction-Based EC l The states in RTL that correspond to states in system-level model (SLM), are referred to as synchronizing states SLM RTL Refinement mapping Transient states Complete Verification or Sequential counterexample

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

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

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

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

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

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

92 92 Classification of properties l Safety properties u “undesirable things never happen” u “desirable things always happen” u 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 l Liveness (progress) properties u “desirable state repeatedly reached” u “desirable state eventually reached” u Examples:  Every bus request is eventually granted  A car at a traffic light is eventually allowed to pass

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

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

95 95 Syntax of CTL l Every atomic proposition is a CTL formula l If f and g are formulae then so are   f, (f  g), (f  g), (f  g), (f  g) u AG f - in all paths, in all state f (in all future, f) u EG f - in some path, in all states f u AF f - in all paths, in some state f (in every future f) u EF f - in some future f u A(f U g) - in all paths, f holds until g u E(f U g) - in some path, f holds until g u AX f - in every next state, f holds u EX f - in some next state f holds l Examples  AG ¬ (EW_light_go  NS_light_go)  AG (car_at_intersection  AF(light_green)) u AG (EF Restart)  EF (Start  ¬Ready)

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

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

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

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

100 100 Model checking approaches l Explicit state model checking u Requires explicit enumeration of states u Impractical for circuits with large state spaces u Useful tools exist: Murphi, SPIN, … l Symbolic model checking u Representation & manipulation in terms of ROBDDs or SAT solvers u 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

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

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

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

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

105 105 Generating OBDD from network Task: Represent output functions of gate network as OBDDs. Network Evaluation Resulting Graphs ABC T1T2 Out 01 a 01 c 01 b 01 b a 01 c b c b 01 b a 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);

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

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

108 108 Reachability analysis Task u Compute set of states reachable from initial state Q 0 u Represent as Boolean function R(S) u Never enumerate states explicitly R state0/1  old state new state 0/1 GivenCompute Initial

109 109 R0R0 00 Breadth-First reachability analysis l R i – set of states that can be reached in i transitions l Reach fixed point when R n = R n+1 u Guaranteed since finite state R1R1 R0R R2R2 R1R1 R0R R3R3 R2R2 R1R1 R0R

110 110 Iterative computation R i  R i  R i+1 old new do until ALGORITHM

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

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

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

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

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

116 116 SAT-based reasoning on ILAs PI PO LATCHES NS PS CL CL 1 CL 2 CL k NS k PI 2 PO k PI 1 PI k PO 1 PO 2 PS 3 PS 2 PS k NS 1 NS 2 NS k-1 PS 1 Unroll k-Steps Popularized by the BMC work (Biere et al) Current SAT solvers have shown good results

117 117 SAT-based inductive reasoning P I0I0 ‘1’ Base Case P CL k+1 P ‘1’ Induction Step Simple Induction UNSAT AG P is TRUE + l I 0 never satisfies ~ P l If I i never satisfies ~ P, then I i+1 never satisfies ~P l It is never the case that (I 0 satisfies P) and (I i+1 satisfies ~P)

118 118 SAT-based inductive reasoning P P CL 1 CL 2 CL k I0I0 P P ‘1’ Base Case P P CL 1 CL k P CL k+1 P ‘1’ Induction Step Induction with depth ‘k’ (Sheeran et al, Bjesse et al FMCAD 2000)

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

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

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

122 122 Function Representation l Representation of: Init, R i (s), P(s), Tr(s,s’) l 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

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

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

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

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

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

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

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

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

131 131 Abstraction (Cont) l Abstract transition relation is conservative u Abstract next states must contain all concrete successors u And possibly more states RARA Abstract Concrete RCRC s t x y  

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

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

134 134 Abstraction refinement algorithm Build abstract model Model check abstract model Check abstract counterexample on concrete model abstract counterexample True on concrete model true Infeasible abort False on concrete model real counterexample Refinement spurious counterexample

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

136 136 Assume-Guarantee Reasoning R R’ < < S S’ l 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

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

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

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

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

141 141 Symmetry reductions 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:  ( x, z)   ( f(x), f(z)) 0,0 1,1 0,11,0 f: f(0,0) = 1,1 f(1,1) = 0,0 f: f(0,0) = 1,1 f(1,1) = 0,0 f(0,1) = 0,1 f(1,0) = 1,0 f(0,1) = 0,1 f(1,0) = 1,0 e.g. l The set of all automorphisms forms a group! l Automorphism groups induce equivalence classes (orbits) over the state space [ (0,1), (1,0) ] [ (0,1), (1,0) ] [ (0,0), (1,1) ] e.g.

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

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

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

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

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

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

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

149 149 Industrial Model Checkers l FormalCheck (Cadence) u COSPAN (from Bell Labs) under the hood u Support for arbitrary precision arithmetic u Automatic bus-contention, multi-driver violation, tri- state support fir high-impedance check u 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

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

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

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

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

154 154 Symbolic simulation (sequential case) a0a0 b0b0 c a 0 ·b 0 + b 0 ·c a1a1 b1b1 a 1 ·b 1 + b 1 ·(a 0 ·b 0 + b 0 ·c) a 0 ·b 0 + b 0 ·c a0a0 b0b0 a1a1 b1b1 c a 1 ·b 1 + b 1 ·(a 0 ·b 0 + b 0 ·c) Unrolled Circuit Time frame 1 Time frame 2

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

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

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

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

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

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

161 161 Symbolic trajectory evaluation (STE) l Trajectory : Sequence of values of system variables u Example: c = AND (a, b) and delay is 1 u 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 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 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

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

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

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

165 165 SAT-based bounded model checking P P CL 1 CL 2 CL k I0I0 P P ‘1’ Unroll M for k time-frames CNF SAT Solver Counter-example to AG P No Counter- example within k steps SAT UNSAT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

184 184 d a bc time B ef Execution semantics in SpecC (cont.) Possible Schedule l 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) behavior B2 { void main(void) { d.main(); e.main(); f.main();} }; behavior B1 { void main(void) { a.main(); b.main(); c.main();} }; behavior B { void main(void) { par { b1.main(); b2.main();} }}; l Example: concurrency/pallalelism

185 185 Synchronization semantics l 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 l Example: u Notify-wait rule derives: Tend(w) >= Tend(n)  wait cannot proceed until it receives notified event a w b cnd A B thread time ‘wait e1’ starts ‘notify e1’ done ‘wait e1’ succeeds this order is guaranteed! behavior A: a.main(); wait e1; b.main(); behavior B: c.main(); notify e1; d.main();

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

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

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

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

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

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

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

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

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

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

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

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

198 198 Backward slicing for a variable v extracts all codes that affect the variable v Backward slicing for a variable v extracts all codes that affect the variable v 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; Backward slicing

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

200 200 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); } Source codeDependence graph

201 201 Example : Interprocedural slicing with summary edge Source codeDependence graph 1st stage 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); }

202 202 Example : Interprocedural slicing with summary edge Source codeDependence graph 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 l Dependence graph gives all dependency informations on the programs and is used here

203 203 Equivalence checking of C descriptions based on symbolic simulation l Problem u 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 l Solution u Reducing areas to be simulated symbolically  Based on difference between descriptions  See the following slide for intuitive explanation u Textual differences may become a good hint to identify which portions of programs are different

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

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

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

207 207 An example of verification l 1 st line: textually different u Create 2 EqvClasses separately E1 (a_1, 3 * in2_1) E2 (a_2, in1_2 * in2_2) u Check their equivalence … nonequivalent u Identify the statements affected by a_1 or a_2  5 th line is identified 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; 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 E E E E E Note: Input: in1, in2 Output: out

208 208 An example of verification l 2 nd, 3 rd, 4 th line: textually equivalent and not affected by nonequivalent variables u These pairs are clearly equivalent  can skip checking u 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), 2408 * (in2_1 + in2_2)) E5 (d_1, d_2, c_1 – 4017 * b_1, c_2 – 4017 * b_2) 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; 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 E E E E E

209 209 An example of verification l 5 th line: affected by nonequivalent variable a_1 and a_2 u Create 2 EqvClasses separately E6 (e_1, 1108 * (a_1 + b_1)) E7 (e_2, 1108 * (a_2 + b_2)) u Check their equivalence … nonequivalent u Identify the statements affected by e_1 or e_2  6 th line is identified 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; 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 E E E E E

210 210 An example of verification l 6 th line: textually equivalent, but affected by nonequivalent variables e_1 and e_2 u Create 2 EqvClasses separately E8 (out_1, (d_1 + e_1) >> 8) E9 (out_2, (d_2 + e_2) >> 8) u Check their equivalence … nonequivalent u Terminate with the results “nonequivalent” 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; 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 E E E E E

211 211 Experiments (MPEG4) l Optimization of IDCT functions (idct_row & idct_col) in MPEG4 u Sizes  Whole MPEG4 program … more than 17k lines  Target IDCT functions … about 50 lines u 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

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

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

214 214 Synchronization verification: Overview In system-level design … In system-level design … u Communication among parallel processes is necessary u To operate properly, those parallel processes must be correctly scheduled/synchronized l Synchronization verification  Guarantee the order of execution of statements as designers ’ intended u 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

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

216 216 Synchronization in SpecC l Add notify/wait of event e for sync.  ‘ wait ’ will stop process until it is ‘ notify ’ AB void A() { } void B() { } void main() { par { A.main(); B.main(); } notify e1; wait e2; wait e1; notify e2; 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

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

218 218 Synchronization in SpecC (cont.) y = 20 (always) l Tas=Tbs, Tae=Tbe l Tas<=T1s

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

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

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

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

223 223Example(2) l Par behavior1 {notify e1; a; waitfor(10); wait e2; b} Behavior2 {wait e1; waitfor(10); c; notify e2; d} u e1 < a, a + 10 < e2, e2 < b, e < c, c < e2, e2 < d u a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correct u Moreover, b 0 are satisfied ? → Yes, the design is correct u Moreover, b – e1 < 20 is satisfied ? → No, this is not satisfied notify e1await e2b wait e1cnotify e2d w aitfor(10) notify e1await e2b wait e1cnotify e2d w aitfor(10)

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

225 225 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() { void main(){ if (C0) { notify e... } if (C1) {. Refining Abstraction refinement Abstraction

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

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

228 228 Abstraction refinement 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() { void main(){ if (C0) { notify e... } if (C1) {. Abstraction refinement Abstraction Constructing Control Flow Graph (CFG) Check validity Symbolic sim & theorem prover Find & Modify Predicates Refining

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

230 230 Example: Sleeping barber problem

231 231Example 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; } else { 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; } }; behavior Main () { void main() { par { barber.main(); customer.main(); } };

232 232 /* Barber */ void main() { while(1) { if (!waitCustomer) DayDreaming(); (A1) else { if (chairOccupied) { KeepCutting(); (A2) chairOccupied = false; (A3) } else { notify call; (A4) chairOccupied = true; (A5) } }; /* Customer */ void main() { while(1) { if (!waitCustomer) waitCustomer = true; (B1) else { waitCustomer = false; (B2) if (!chairOccupied) wait call; (B3) } }; /* Barber */ void main() { while(a0) { if (a1)... else { if (a2) {... } else { notify call;... } }; /* Customer */ void main() { while(b0) { if (b1)... else {... 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) Abstract

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

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

235 235 l 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) 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); } }; This loop creates infinite numbers of notify(clk16) This loop creates infinite numbers of wait(clk16) With multiple of 16 ‘wait(clk16)’ each time How to deal with loops ?

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

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

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

239 239 What does CBMC do? l CBMC checks if or not C programs satisfy the properties the user specify u Input … C Program with assertions as properties u 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); Success char a, b; int c; if (a < b) c = b – a; else c = a – b; assert (c != 0); Fail Counter example (a = 39, b = 39)

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

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

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

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

244 244Renaming 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

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

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

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

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

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

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

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

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

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

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

255 255 Verification with SAT Solver l Satisfiability Problem (SAT Problem) u Formula F is satisfiable if there is more than one input pattern that makes F true u Ex. F1 = a ∧ b … satisfiable (when a = true, b = true) u 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

256 256 Checking over bound access to array l CBMC can detect the over bound access to array indices u This program is faulty since array[3] is accessed when i = 3 l If (i <= 3) is replaced by (i < 3), this program becomes correct 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

257 257 Assertion checking l CBMC can verify data- dominant properties u 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 >i); ai = (a<

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

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

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

261 261 Bibliography on verification

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

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

264 264Papers High Level Design and Verification Modeling l l D. D. Gajski, ``IP-Based Design Methodology'', Proc. of the 36th Design Automation Conference, pp. 43, New Orleans, June l l D. Kroening and E. Clarke, “Behavioral consistency of C and Verilog programs using bounded model checking,” in Proc. DAC, June l l 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 l l T. Matsumoto and M. Fujita, “Equivalence checking of C-based hardware descriptions by using symbolic simulation and program slicer,” in Proc. IWLS, May l l T. Ball and S. Rajamani, “Checking Temporal Properties of Software with Boolean Programs”, in Proc. Computer Aided Verification 2000, [Microsoft SLAM project] l l 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., l l S. Singh, “Design and Verification of CoreConnectTM IP using Esterel,” in Proc CHARME 2003 l l S. Sutherland, “System Verilog 3.1 Its what the DAVEs in you company asked for”. in Proc. DVCON 2003 l l S. Abdi, D. Shin and D. Gajski, "Automatic Communication Refinement for System Level Design,” Proceedings of Design Automation Conference, Anaheim, CA, June l l W. Mueller, R. Dömer, A. Gerstlauer, "The Formal Execution Semantics of SpecC," in Proceedings of International Symposium on System Synthesis, October 2002.

265 265Papers 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. 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. C. M. Angelo, “Formal Hardware Verification ina Silicon Compilation Environment by means of Theorem Proving”, Ph.D. Dissertation, Katholieke Universiteit Leuven (February, 1994).

266 266Papers 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, S. P. Rajan, N. Shankar and M. Srivas, “An Integration of Model-Checking with Automated Proof Checking”, 7th Conference on Computer-Aided Verification, July, 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

267 267Papers 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

268 268Papers 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

269 269Papers R. H. Beers and P. J. Windley, `Abstracting Signals: The waveform Library', in Supplementary Proceedings of the 9 th 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).

270 270Papers Formal Verification: SAT Solvers l l J. Marques-Silva and K. Sakallah, “GRASP: A Search Algorithm for Propositional Satisfiability”, IEEE Transactions on Computers, 48(5): , May 1999 l l 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 l l M.H. Moskewicz et. al., “Chaff: engineering an efficient SAT solver,” in Proc. Design Automation Conf., June l l E. Goldberg and Y. Novikov, “BerkMin: a Fast and Robust Sat-Solver”, Proceedings of Design Automation and Test in Europe, pp , March Formal Verification: BDDs l l R. E. Bryant, “Graph Based Algorithms for Boolean Function Manipulation”, IEEE Transactions on Computers, Vol. C-35-8, pp , August 1986 l l R. Rudell, “Dynamic Variable Ordering for Ordered Binary Decision Diagrams”, Proceedings of ICCAD 1993, pp l l 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 l l 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 l l 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 l l R. Bryant, “Symbolic Boolean Manipulation with Ordered Binary Decision Diagrams”, slides from a presentation by Prof. Bryant in August 1999

271 271Papers Formal Verification: Symbolic Model Checking (BDDs) l l D. L. Dill, “The Mur  Verification System”, , CAV96. l l 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 l l 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 l l J. Burch, E. Clarke, D. Long, K. McMillan, D. Dill, “Symbolic Model Checking for Sequential Circuit Verification”, IEEE Trans. Computer Aided Design, 13, 1994, l l 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 l l H. Iwashita and T. Nakata, `` Forward Model Checking Techniques Oriented to Buggy Designs'', Proceedings of ICCAD, pp , l l 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, l l A. J. Hu, “Formal Hardware Verification with BDDs : An Introduction”, ACM Transactions on Programming Languages and Systems, l M. Kaufmann, A. Martin, and C. Pixley, "Design Constraints in Symbolic Model Checking", Proc. CAV-98, pp , l K. L. McMillan, "Fitting formal methods into the design cycle", Proceedings of the 31st Design Automation Conference, pp , 1994

272 272Papers Formal Verification with SAT solvers l l 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 l l P. Williams et al, “Combining Decision Diagrams and SAT Procedures for Efficient Symbolic Model Checking”, Proc. of the 12 th CAV, pp , July 2000 l l M. Sheeran, S. Singh and G. Stalmarck, “Checking Safety Properties Using Induction and a SAT Solver”, Proc. of the 3 rd Intl. Conference on Formal Methods in CAD (FMCAD), pp , Nov l l P. Bjesse and K. Claessen, “SAT-based Verification without State Space Traversal”, Proc. of the 3 rd FMCAD, pp , Nov l l K.L. McMillan, “Applying SAT Methods in Unbounded Model Checking”, Proc. of the 14 th CAV, pp , July 2002 l l K.L. McMillan, “Interpolation and SAT-based Model Checking”, Proc. of the 15 th CAV, July 2003 l l I. Park and H. Kang, “SAT-based unbounded symbolic model checking”, Proceedings of DAC, pp , June 2003

273 273Papers Equivalence Checking l l D. Brand, “Verification of Large Synthesized Designs”, Proceedings of ICCAD, November 1993, pp l l A. Kuehlmann and F. Krohm, “Equivalence Checking using Cuts and Heaps”, Proceedings of DAC 1997, pp l l Y. Matsunaga, “An Efficient Equivalence Checker for Combinational Circuits”, Proceedings of DAC 1996, pp l l 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 l l 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 l l K. Ng, M. Prasad, R. Mukherjee and J. Jain, “Solving the Latch Mapping Problem in an Industrial Setting”, Proceedings of DAC 2003, pp l l C.A.J. van Eijk, “Sequential Equivalence Checking Based on Structural Similarities”, IEEE Transactions on CAD, 19(7): , July 2000 l l 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

274 274Papers Semi-Formal Verification l l R. E. Bryant, “Symbolic Simulation -- Techniques and Applications”, Proceedings of DAC 1990 l l R.B. Jones, “Applications of Symbolic Simulation to the Formal Verification of Microprocessors”, Ph.D. Thesis, Computer Systems Laboratory, Stanford University, August 1999 l l R.E. Bryant and C.J.H. Seger, “Formal hardware verification by symbolic trajectory evaluation,” in Proc. Design Automation Conf., June l l 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 l l 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 l l O. Shtrichman, “Tuning SAT Checkers for bounded model checking,” in Proc. Int. Conf. on Computer-Aided Verification, July l l F. Fallah, “Binary Time-Frame Expansion”, Proc. of ICCAD, pp , Nov l l A. Gupta et al, “Learning from BDDs in SAT-based bounded model checking,” in Proc. Design Automation Conf., June l l V. Boppana, S. Rajan, K. Takayama and M. Fujita, “Model Checking Based on Sequential ATPG”, Proceedings of CAV, pp , July l l J. Abraham, V. Vedula and D. Saab, “Verifying Properties Using Sequential ATPG”, Proceedings of International Test Conference, October 2002

275 275Papers l l D. Dill and S. Tasiran, "Simulation meets Formal Verification?", slides from a presentation at ICCAD'99. l l D. Dill, "Alternative Approaches to Formal Verification (Symbolic Simulation)", slides from a presentation at CAV l l C. H. Yang and D. L. Dill, “Validation with Guided Search of the State Space”, Proceedings of DAC 1998 l l M. Ganai et al, “SIVA: A System for Coverage Directed State Space Search”, In Journal of Electronic Testing: Theory and Applications (JETTA), February 2001 l l P.-H. Ho et al, “Smart Simulation Using Collaborative Formal and Simulation Engines”, Proceedings of ICCAD, pp , November 2000 l l 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 l l 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, Model Checking in Practice l l 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.

276 276Papers l l K. L. McMillan, "A compositional rule for hardware design refinement", Computer Aided Verification (CAV97), O. Grumberg (Ed.), Haifa, Israel, pp , l l 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 , l l G. Mosensoson, “Practical Approaches to SoC Verification”, DATE l l 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 l l 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 l l 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, l l 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, l l T. Henzinger, X. Liu, S. Qadeer and S. Rajamani, “Formal Specification and Verification of a Dataflow Processor Array,”Proceedings of ICCAD 1999 l l D. Wang, “SAT based Abstraction Refinement for Hardware Verification”, Ph.D. thesis, ECE Dept., Carnegie Mellon University, May 2003 l l Shankar G. Govindaraju, David L. Dill, Alan J. Hu, and Mark A. Horowitz. "Approximate Reachability with BDDs using Overlapping Projections,” in Proc. DAC 1998 l l Gaurishankar Govindaraju, "Approximate Symbolic Model Checking using Overlapping Projections" Ph.D. thesis, Stanford University, August 2000.

277 277Papers Simulation Based Verification l l 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 l l 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 l l 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 l l S. Ravi, G. Lakshminarayana, and N.K. Jha, ``TAO: Regular expression based high-level testability analysis and optimization,'' in Int. Test Conf., pp , Oct l l 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 l l L. Zhang, I. Ghosh and M. Hsiao, “Efficient sequential ATPG for functional RTL circuits,” in Proc. International Test Conference, Oct l l L. Zhang, I. Ghosh and M. Hsiao, “Automatic design validation framework for HDL descriptions via RTL ATPG,” in Proc. Asian Test Symposium, Nov l l 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 l l K. Ara and K. Suzuki, “A proposal for transaction level verification with component wrapper language,” Proc. Design Automation and Test in Europe, March l l A. U. Shankar, "An Introduction to Assertional Reasoning for Concurrent Systems", ACM Computing Surveys, Sept. 1993, Vol 25, No. 3, pp

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

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

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

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


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

Similar presentations


Ads by Google