Formal Verification

2 Verification vs. Simulation ……… X 2 +2X+1(X+1) 2 X ….… XX=X 2 5 (X+1)X=XX+1X4 (X+1)1=X+13 (X+1)(X+1)=(X+1)X+(X+1)12 (X+1) 2 =(X+1)(X+1)1

3 Simulation ? impossible to be exhaustive …

4 10 states 100, stars 11

5 Exhaustive Simulation Time Design: a 256-bit RAM = possible combinations of initial states and inputs Assume:  Use all matter in our galaxy (10 17 kg) to build computers.  Each computer is of the size of single electron ( kg).  Each computer simulates cases per second.  we started at the time of the Big Bang about years ago  We would just have reached the 0.05% mark of completing our task

6 Finding Bugs by Simulation

7 Finding Errors Reminder:  ~ 70% of project development cycle: design verification −Every approach to reduce this time has a considerable influence on economic success of a product.

8 Time-to-Market  For a high-end microprocessor, a delay of one week = a revenue of at least $20M [1] −[1] Kropf, T., Introduction to Formal Hardware Verification, Springer, 1999.

9 Detecting Design Faults To check the new implementation for functional correctness, we need: 1.a reference description: −either a specification −or a previous “golden” implementation. 2.a new implementation, resulting from −a refinement (synthesis) of the specification −or an optimization of the reference implementation. 3.a correctness relation which has to be established between the two specifications –(e.g. behavioral correctness).

10 Hardware Verification Definition: Hardware verification  is the proof that a circuit or a system (the implementation) behaves according to a given set of requirements (the specification). Formal verification  uses mathematical reasoning to prove that an implementation satisfies a specification Consideration of all cases is implicit in formal verification.

11 Formal Verification Logic Synth. Floorplanning Funct. Spec RTL Gate-level Net. ….

12 Why Formal Verification? All Behaviors Required Behaviors Simulation Formal Verification (model checking) reference:

13 Simulation vs. FV Simulation is input-driven, FV is output-driven:  Mind-set in simulation: first to generate input vectors and then to derive reference outputs  In FV: user starts out by stating what output behavior is desirable and then lets the formal checker prove or disprove it.

14 Simulation vs. FV FV uses extensive memory and long run time  Applicable to moderate-size circuits (e.g. blocks or modules)

15 Formal Verification Methods Equivalence Checking  Compares optimized/synthesized model against original model Model Checking  Checks if a model satisfies a given property Theorem Proving  Proves implementation is equivalent to specification in some formalism

16 What is Model Checking? Model Checking (Property Checking):  An automatic technique for verifying finite-state reactive systems, (such as sequential digital circuits or communication protocols). −A reactive FSM is an FSM whose inputs come from the environment.  For checking that a desired property holds in a finite state model of a system  Was pioneered by Edmund Clarke, professor in the CS Dept of CMU, in 1981 −(E.M. Clarke and E.A. Emerson. "Synthesis of Synchronization Skeletons for Branching Time Temporal Logic", in Logic of Programs workshop, Yorktown Heights, NY, May 1981.). reference: Lectures by Karsten Schmidt, Dong Wang Sergey Berezin, Carnegie Mellon University, Jeannette M. Wing

17 What is Model Checking? (cont.) Relies on exhaustive state space search.  exhaustive state space search is guaranteed to terminate, as the model is finite. Major challenge:  To fight state-explosion problem Can uncover subtle design errors Can handle large state spaces (10^120) Quicker to start testing  as it does not require vectors or a testbench. Successfully used to find bugs in published standards

18 What is Model Checking? (cont.)  Typically used during RTL code development to debug the RTL model prior to synthesis.  Used concurrently with and/or prior to simulation.  FormalCheck is the name of Cadence ’ s Model Checking tool.  Currently the dominant formal verification tool.

19 How does Model Checking work? System Finite State Model Model Checker Properties meets or not

20 Model Checking Output Space Simulation-based verification : Design Points verified Model-based verification : Properties verified Sim-based: checks one output point at a time, FV: checks a group of output points at time. Idea: Search the entire state space for important points: (i.e. points that fail the property) P1 P2 P3

21 Process of Model Checking Modeling:  convert a design (hardware or software) into a formalism accepted by a model checker Specification:  to state the properties as golden behavior  use temporal logic to assert how the behavior of the system evolves over time Verification:  automatic process Reference: J. R. Burch, E. M. Clarke, K. L. McMillan, D. L. Dill, “Sequential circuit verification using symbolic model checking”, Proc. 27th ACM/IEEE Design Automation Conf., June 1990.

22 Classification of property specification Functional correctness:  Does the encoder correctly encode?  Does the multiplier multiply? Temporal behavior:  Does the bus master start the bus access in 6 clocks after it is granted? Safety properties:  At a traffic intersection, are the traffic lights for both paths green?  Does the elevator door only open after the elevator has come to a complete standstill at some floor? Liveness properties:  Does the traffic light become green eventually? Fairness properties :  Is every requesting master eventually granted by the bus arbiter

23 Model Checking  Property is a partial specification of the design, −essentially a duplicate description of the design (redundancy in specification).  As equally prone to errors as the design. Practical Issues:  ~70% of verification time is spent on getting correct constraints!  Debugging is difficult when the property is written in a language other than that of the design. −e.g. property in SystemVerilog, design in Verilog.  Debugging failures in a property specification has the same difficulty as any other debugging activities.

24 [Property Checking] To specify (describe) the properties of the concurrent system using branching-time temporal logic called CTL("Computation Tree Logic")

25 [Computational Tree Logic (CTL)] CTL is a logic used to express properties for model checking CTL is useful because there is an efficient technique to check it A temporal logic is a logic which can express aspects of time CTL makes statements about the computational tree of a state machine Traffic light FSM Computational tree for FSM R GY R G Y R RGG

26 [CTL Formulae] A CTL formula is built from three things: 1.Atomic propositions - These are the variables 2.Boolean connectives - AND, OR, NOT, etc. 3.Temporal operators - Express something about paths in the computational tree A temporal operator has two parts: 1.A path quantifier - A (for all paths) or E (there exists a path) 2.A temporal modality - Describe the ordering of events in time

27 [Model Checking (2/2)] Idea (Clarke, Emerson ’81)  Unroll transition system to an infinite computation tree −Start state is the root (S1)  Define properties using −On all paths (A) −On some path (E) −Always / Globally (G) −Eventually (F)  Some examples −EG p −AG p −EF p −AF p State space explosion  What next ? s1 s4s3 s2 Transition system s1 s2s4 s3s4 s2s4 Computation Tree

28 [Temporal Modalities] Assume that p is a CTL formula. F p - “p holds sometime in the future” Is true of a path is there exists a state on the path where p is true G p - “p is true globally” Is true of a path if p is true at all states on the path X p - “p holds in the next state” Is true of a path if p is true in the state immediately after the current state p1 U p2 - “p1 holds until p2 holds” Is true if p2 is true in a state and p1 is true in all preceding states

29 [A CTL Property] All temporal modalities, except G, are evaluated from the start state of the path AG (req -> AF ack) For all reachable states, if req is asserted then we must reach a state where ack is asserted AG is interpreted relative to the start state AG selects all states reachable from start state AF is interpreted relative to where req is asserted

30 [Another CTL Property] AG AF enabled For every reachable state, for all paths starting at that state we must reach another state where enabled is asserted AG EF restart From any reachable state, there must exist a path reaching a state where restart is asserted In other words, it must always be possible to reach the restart state

31 [Traffic Light Controller Constraint] AG ( !((farm_light = GREEN) * (hwy_light = GREEN)) ); Both lights can’t be green at the same time

32 [Strengths and Weaknesses ] Temporal logic is a very precise and mostly convenient formalism for expressing desired properties of the system. The decision procedure is completely automated.  Thus the user never needs to be aware of the CTL structure but can simply interact with the model checker to determine that the dynamic behavior of the design satisfies the specification. An interesting observation is that the CTL structure is very general.  Hence the same model checker can be used to reason about both hardware and software systems.

33 [ Strengths and Weaknesses] Often difficult to judge whether the temporal formulas that has been checked completely characterizes the desired behavior of the system  E.g.. it is easy to forget to check some property. Temporal logic formulas can sometimes become exceedingly difficult to understand  a danger of misunderstanding what properties actually have been verified Its decision procedure:  In order to determine the validity of a temporal logic formula, it is necessary to extract the CTL structure for the device.  The problem is that the state space S for most interesting systems is extremely large. −E.g. if the system consists of many asynchronous communicating state machines, the complete state space is often enormous −This problem is usually referred to as the state explosion problem −The topic of how to deal with the state explosion problem is currently a very active area of research

Equivalence Checking

35 Equivalence Checking Two Methods:  Combinational Equivalence Checking  Sequential Equivalence Checking

36 Equivalence Checking Combinational Equivalence Checking: 1.The functions of the two circuits to be compared are converted into canonical representations of Boolean functions, typically Binary Decision Diagrams (BDDs). 2.The BDDs are then structurally compared. −Unable to compare the RTL model with a behavioral model.

37 Logic Equivalence Checking Task : Check functional equivalence of two designs Inputs  Reference (golden) design  Optimized (synthesized) design  Logic segments between registers, ports or black boxes Output  Matched logic segment equivalent/not equivalent This is achieved by dividing the model into logic cones between registers, latches or black-boxes. The corresponding logic cones are then compared between original and optimized models. 1 = 1’ ? 2= 2’ ? inputs output s 1 2 inputsoutput s 1’ 2’ Equivalence result Reference design Optimized design

38 Combinational Equivalence Checking Circuit/Implementation A FTFT Circuit/Implementation (comb. ckt) BDD (Binary Decision Diagram) isomorphic ? Circuit/Implementation B

39 Sequential Equivalence Checking Sequential Equivalence checking:  verifies the equivalence between two sequential designs at each valid state.  This is achieved by creating a finite state machine representation of the two systems and checking whether a state can be reached from initial states where two corresponding outputs of the models differ.  Can verify the equivalence between RTL and the behavioral model.  Suffers from the state space explosion problem due to creating a full finite state representation of two systems.

40 Sequential Equivalence Checking Common input A drives the two Models State Vectors are held in S1 and S2 and initialised to a common value – all zeroes for instance. The outputs Z1 and Z2 are compared by XORing them If E remains zero then the two models are equivalent The state space explosion rules out this approach

41 Boolean Equivalence Checking(BEC) Assuming that the two FSMs are the same with same encoding of states it is enough to prove that the two combinational logics are equivalent Equivalence is established without having to do state space exploration Next state logic and output logic are checked for equivalence. E1 and E2 should remain zero. Simulation based method won’t be able to exhaustively check even this restricted problem

42 FSM Equivalence Checking Task : Check if implementation is equivalent to spec Inputs  FSM for specification (Ms)  FSM for implementation (Mi) Output  Do Mi and Ms give same outputs for same inputs ? Idea (Devadas, Ma, Newton ’87)  Compute Mi×Ms  Qf(Mi×Ms) = States which have different outputs for Mi and Ms  Check if any state in Mi×Ms is reachable. p q x y a b r s x y a b t y b pr qr pspt qs qt xx yx xy yy aa bb × =

43 Applications of EC Applications: 1.Before and after scan insertion: 1.to make sure that adding scan chain does not alter functionality. 2.Ensure integrity of a layout vs. RTL version  First circuit extraction to transistor netlist. 3.Prove that ECO changes are restricted to the scope intended.

Theorem Proving

45 Theorem Proving Task :  Prove implementation is equivalent to spec in given logic Inputs  Formula for specification in given logic (spec)  Formula for implementation in given logic (impl)  Assumptions about the problem domain −Example : Vdd is logic value 1, Gnd is logic value 0  Background theory −Axioms, inference rules, already proven theorems Output  Proof for spec = impl AutomatedManual Proof Goal Assumptions / Background theories / Inference rules decomposition | proof Theorem Prover

46 Theorem Proving Example  CMOS inverter (Gordon’92)  Using higher order logic Assumptions  Vdd(y) := (y=T)  Gnd(y) := (y=F)  Ntran(x,y1,y2) := (x->(y1=y2))  Ptran(x,y1,y2) := (┐x->(y1=y2)) Impl(x,y) := ∃ w1, w2. Vdd(w1) Λ Ptran(x,w1,y) Λ Ntran(x,y,w2) Λ Gnd(w2) Spec(x,y) := (y=┐x) Proof  Impl(x,y) = ….. (assumption / thm / axiom) = ….. (assumption / thm / axiom) = ….. (assumption / thm / axiom) = Spec(x,y) Vdd Gnd xy w1 w2 CMOS inverter

47 Theorem Proving Example  AND Logic 4 steps:  Specify the implementation of the AND gate,  Specify the behavioral models for the NAND and NOT gates,  Specify the intended behavior of the AND gate,  Prove that the implementation satisfies its intended behavior. Implementation of AND

48 Drawbacks of Theorem Proving  Not easy to deploy in industry −Most designers don’t have background in math logic −Models must be expressed as logic formulas  Limited automation −Extensive manual guidance to derive proof sub-goals

49 Theorem Proving  Theorem prover is less automatic than a model checker (more of an assistance to the user): −User: 1.assembles relevant info for the tool, 2.sets up intermediate goals (i.e. lemmas) −Tool: −Attempts to achieve the intermediate goals based on input data.  Effective use of it requires −a solid understanding of the internal operations of the tool and −familiarity with the mathematical proof process.

50 Assertion-Based Verification An assertion is a statement that a specific condition, or sequence of conditions, in a design must be true. Describe expected or unexpected conditions (assertions) in device under test (DUT)  Specialized languages (e.g. e, Sugar/PSL)  Language extensions or features (Open Verification Library (OVL), SystemVerilog) Check to make sure that conditions are satisfied  Dynamically during simulation  Statically using formal  Hybrid Assertions could be independent & separated from design description

51 Assertion-based Verification - Usage modes Static formal  no pattern required describe the behavior (assertions) check engine assertions describe the design DUT violate ? exhaustively proven (no violation) an example of an errant behavior (counterexample) spec. NY

52 Assertion-based Verification - Usage modes Dynamic check  similar as simulation, but check the properties from assertions  input pattern required  the proof depends on the coverage of input pattern describe the behavior (assertions) assertions describe the design DUT violation alert spec. simulation x test pattern

53 Assertion-based Verification - Usage modes describe the behavior (assertions) assertions describe the design DUT spec. simulation x test pattern Dynamic formal (semi- formal) check engine violate ? NY exhaustively proven (no violation) (counterexample)

54 Profile of Verification Methodologies high Property checking (formal) medium highmediumRandom testing low Directed testing setup costlearning costcoveragecomputing resource usage Meth. Dimensions

55 Applicability Well accepted techniques in industry  Simulation with assertions  Static assertions  Equivalence checking

56 Applicability Wrong assumptions:  A puristic claim: −A verification run was considered to be successful only if the complete system had been verified. Facts: 1.The systems are too large −If it can be shown that verification is able to find more faults than simulation in the same time, then it is cost-effective and should be used. −  Methodology: only the critical parts of the system are verified. 2.  A complete system verification is even unnecessary in many cases. (the verification of well-structured and simple parts is not necessary). 3.A complete formalization of the implementation is intractable. 4.Verification tools have to be used together with simulation

57 Applicability Wrong assumptions:  Formal methods can guarantee the perfectness of systems Facts:  can significantly enhance the trust, but not able to guarantee flawlessness. Reasons:  Only makes correctness statements with regard to a formal specification which can be faulty itself.  Faults in verification program.  Only design faults but not fabrication faults or faults during system usage.

58 Tools Verification Languages:  "e".  Synopsys Vera :  SystemC SCV Equivalence Checkers:  Cadence Verplex :  Synopsys Formality :  Mentor FormalPro :  Prover eCheck :  homebrew EC Assertion Languages:  IBM Sugar/PSL  0-in Checkerware  Verplex OVL  System Verilog SVA  Synopsys Vera OVA

59 References  W. Lam, Hardware Design Verification, Simulation and Formal Method-Based Approaches, Prentice- Hall,  Kropf, T., Introduction to Formal Hardware Verification, Springer,  D. Gajski and S. Abdi, "System Debugging and Verification: A New Challenge," Verify 2003, Tokyo, Japan, November 20, 2003.

60

61 References [12] Cadence, Course on how to use FormalCheck. Cadence Internet LearningS eries, FormalCheck Version 2.3: Module 1: Technology and Product Overview. [02 Sept. 2002] [3] A. Ireland, Presentation slides on ‘Formal Verification’. Dept of Computing and Electrical Engineering, Heriot-Watt University, Edinburgh. URL: [24 June 2002]