Formal Verification Verification vs Simulation X X 1 2

Formal Verification

Verification vs. Simulation X (X+1)2 X 2+2 X+1 0 1 1 1 4 4 2 9 9 … … … 1 (X+1)2=(X+1) 2 (X+1)=(X+1)X+(X+1)1 3 (X+1)1=X+1 4 (X+1)X=XX+1 X 5 XX=X 2 … …. 2

Simulation 010011 111000 010101 100101 010011 111000 010011 010101 111000 100101 010101 100101 010011 111000 010101 100101 010011 111000 010101 100101 ? 010011 111000 010101 100101 impossible to be exhaustive … 3

11 10 stars 10100, 000 states 4

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

Finding Bugs by Simulation 6

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. 7

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

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

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. 10

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

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

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 15

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 16

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 17

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. Ø Formal. Check is the name of Cadence’s Model Checking tool. Ø Currently the dominant formal verification tool. 18

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

Model Checking Output Space Simulation-based verification Model-based verification P 1 P 2 P 3 : Design Points verified : 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) 20

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. Mc. Millan, D. L. Dill, “Sequential circuit verification using symbolic model checking”, Proc. 27 th ACM/IEEE Design Automation Conf. , June 1990. 21

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 22

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 System. Verilog, design in Verilog. Ø Debugging failures in a property specification has the same difficulty as any other debugging activities. 23

Equivalence Checking

Equivalence Checking • Two Methods: Ø Combinational Equivalence Checking Ø Sequential Equivalence Checking 35

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. 36

Logic Equivalence Checking 2 1 outputs • 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. Reference design 2’ 1’ 1 = 1’ ? 2= 2’ ? Equivalence result outputs • inputs • 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 inputs • • Optimized design 37

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

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. 39

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

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. E 1 and E 2 should remain zero. • Simulation based method won’t be able to exhaustively check even this restricted problem 41

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. x p a y q × b x r a y s b y t xx pr = b xy ps pt xy aa yx qr qs bb yy bb qt yy 42

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. 43

Theorem Proving

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 Proof Goal decomposition | proof Manual Theorem Prover • Assumptions / Background theories / Inference rules Automated 45

Theorem Proving • Example Vdd w 1 Ø CMOS inverter (Gordon’ 92) Ø Using higher order logic • Assumptions Ø Ø • Vdd(y) : = (y=T) Gnd(y) : = (y=F) Ntran(x, y 1, y 2) : = (x->(y 1=y 2)) Ptran(x, y 1, y 2) : = (┐x->(y 1=y 2)) Impl(x, y) : = ∃ w 1, w 2. Vdd(w 1) Λ Ptran(x, w 1, y) Λ Ntran(x, y, w 2) Λ Gnd(w 2) • • Spec(x, y) : = (y=┐x) Proof x y w 2 Gnd CMOS inverter Ø Impl(x, y) = …. . (assumption / thm / axiom) = Spec(x, y) 46

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 47

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 48

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. 49

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), System. Verilog) • Check to make sure that conditions are satisfied Ø Dynamically during simulation Ø Statically using formal Ø Hybrid Assertions could be independent & separated from design description • 50

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

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 spec. describe the behavior (assertions) design assertions 0100111 x 0 test 11111000 pattern 0101 100101 the DUT simulation violation alert 52

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

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 − − 2. 3. 4. 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. A complete system verification is even unnecessary in many cases. (the verification of well-structured and simple parts is not necessary). A complete formalization of the implementation is intractable. Verification tools have to be used together with simulation 56

Applicability • Wrong assumptions: Ø • Facts: Ø • Formal methods can guarantee the perfectness of systems 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. 57

Tools • Verification Languages: Ø "e". Ø Synopsys Vera : Ø System. C SCV • Equivalence Checkers: Ø Cadence Verplex : Ø Synopsys Formality : Ø Mentor Formal. Pro : Ø Prover e. Check : Ø homebrew EC • Assertion Languages: Ø IBM Sugar/PSL Ø 0 -in Checkerware Ø Verplex OVL Ø System Verilog SVA Ø Synopsys Vera OVA 58

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