Alan Mishchenko UC Berkeley The First Taste of Formal Verification (a tutorial to be given at ICCAD 2011) Alan Mishchenko UC Berkeley

Overview Introduction Verification engines Transformers, bug-hunters, provers Examples of verification engines Retiming, simulation, PDR Integrated verification flow Representations used in the tools BDDs, CNFs, AIGs Conclusion Side notes: Working for industry in academia

Introduction Importance Scope of this talk Problem formulation Safety vs. liveness property verification Bounded vs. unbounded verification Model checking (MC) vs. equivalence checking (EC) Outcomes of verification Sequential miter Certifying verification Inductive invariant

Scope of This Talk In this talk, we limit ourselves to Synchronous designs Verifying safety properties Designs represented as bit-level sequential logic circuits with the initial state(s) Extensions not covered Analog designs Verifying liveness properties Word-level designs and properties Symbolic trajectory evaluation (STE) etc

Safety vs. Liveness Verification Finite State System Safety property: “bad thing” never happens AGp (¬p describes a “bad thing”) g r y all paths every state on these paths Infinite Computation Tree r g y ... Liveness property: “good thing” eventually happens AFp (p describes a “good thing”) all paths some state on these paths 5

Bounded vs. Unbounded Verification Bounded-depth verification Verifies property in the first few time frames Important for quick checking of properties Works well even for relatively large designs Unbounded-depth verification Verifies property for infinite time frames Requires elaborate and scalable engines Runs out of resources for complex properties in large designs

Problem Formulation Property checking Model checking (MC) works on the design the property (In the case of SEC, verification works on two versions of the design) Design and property are combined to form a sequential miter The output of the miter has to be proved ‘true’ in all reachable states Often it does not matter, if the miter comes from MC or SEC D T p Equivalence checking D2 D1 T =

Outcomes of Verification Success The property holds in all reachable states Failure A finite-length counter-example (CEX) is found Undecided A limit on resources (such as runtime) is reached

Logic gates + memory elements Sequential Miter The design and the property are put together to form a sequential miter The miter is a logic circuit composed of A set of primary inputs A set of memory elements with initial state A set of logic gates One primary output The property holds iff the value of the primary output is ‘true’ in all states reachable from the initial state(s) In some tools, ‘true’ is represented as value 0 ? y=true Primary output Logic gates + memory elements Primary inputs

Certifying Verification How do we know that the answer produced by a verification tool is correct? If the result is “SAT”, re-run the resulting CEX to make sure that it is valid If the result is “UNSAT”, an inductive invariant may be generated and checked by a third-party tool

Inductive Invariant An inductive invariant is a Boolean function in terms of register variables, such that It is true for the initial state(s) It is inductive assuming that is holds in one (or more) time-frames allows us to prove it in the next time-frame It does not contain “bad states” where the property fails State space Bad Invariant Reached Init

Inductive Invariant (cont.) It does not matter how inductive invariant is computed If it is available in any form (as a circuit, BDD or CNF), it can be checked for correctness using a third-party tool This way, verification proof can be certified Comment 1: If the property is true, the set of all reachable states is an inductive invariant Comment 2: In practice, computing the set of all reachable states is often impossible. In such cases, an inductive invariant can be an over-approximation of reachable states. This allows for proving properties composed of thousands of memory elements, well beyond the limits of exact reachability.

Verification Engines Bug-hunters Provers Transformers random simulation bounded model checking (BMC) hybrids of the above two (“semi-formal”) Provers K-step induction, with or without uniqueness constraints BDDs (exact reachability) Interpolation (over-approximate reachability) Property directed reachability (over-approximate reachability) Interval property checking Transformers Combinational synthesis Retiming etc

Integrated Verification Flow Deriving logic for gates or RTL Modeling clocks, multi-phase clocking Representing initialization logic, etc Structural hashing, sequential cleanup, etc Applying engine sequences (concurrently) Using abstraction, speculation, etc Trying to prove or find a bug with high resource limits Creating sequential miter Initial simplification Progressive solving Last-gasp solving

Data Structures in Formal Verification Binary decision diagrams (BDDs) Conjunctive normal form (CNFs) And-Inverter Graphs (AIGs) Each representation has strengths and weaknesses. A well-tuned combination of them is typically used in a specific verification engine.

Why AIGs in Verification? Easy to construct, relatively compact, robust 1M AIG nodes = 40Mb RAM Can be efficiently stored on disk AIGER: 3-4 bytes / AIG node (1M AIG = 4Mb file) Unifying representation for different engines Used by bug-hunters, provers, transformers Easy to pass around between the engines Compatible with latest SAT solvers Efficient AIG-to-CNF conversion available AIGs + simulation + SAT recently replaced BDDs in most (but not all) applications

Examples of Verification Engines Transformer Retiming Bug-hunter Simulation Prover Property directed reachability (PDR)

Retiming Engine Uses most-forward retiming to “canonicize” register positions (before register correspondence) Uses min-register retiming (A. Hurst, DAC’08) to reduce the number of registers (before signal correspondence) Exposes combinational logic for optimization Minimizes the size of state-space Derives a new register boundary

Simulation Engine Generates random/guided input sequences and simulates them through the design, beginning in the initial state(s), going as far as resource limits allow If the property failed, a counter-example is produced If a resource limit is reached, the problem is undecided Can be used to find bugs in very large designs Can find very deep bugs, which other methods cannot find Efficient implementation uses Bit-parallel simulation Optimized memory management Smart selection of input patterns, based on Scoring Machine learning etc

PDR: Property Directed Reachability Pioneering work of Aaron Bradley A surprise (3d place) winner at HWMCC’10! Remarkable features Efficiently tackles both SAT and UNSAT instances Lends itself to localization abstraction and parallelism Conceptually simple, relatively tuning-free The best single-engine verification tool to date Outperforms interpolation and induction on average Outperforms simulation and BMC for hard SAT cases Solves many instances previous solved only by BDDs

PDR (In a Nutshell) PDR is a way of computing an inductive invariant Constructs over-approximations (F0, F1, …, Fk) of states reachable after each time step as sets of CNF clauses Additionally, requires containment of sets of clauses Termination criteria If a counter-example is found, return SAT If an over-approximation is inductive, return UNSAT The algorithm constructs over-approximations In a property directed way the property is used to decide what clauses to include With an inductive flavor induction is used to prove that a clause holds in a frame

PDR (Illustration) T  Time frame Time frame 0 Time frame 1 Comb Logic Primary inputs Property output Comb Logic … Register outputs Register inputs Initial State States where property fails State space of time frame 0 State space of time frame 1 Initial states a1 a2 Bad Bad a3 Cubes (a1, a2, a3) are covering bad states and not including reached states. The product of their complements is a property-directed over-approximation F1 of reachable states at frame 1. T  Init Init Reached

What’s Next? In addition to expanding into new directions Satisfiability Modulo Theories (SMT) Software verification Using concurrency, etc Improved bit-level engines are in high demand Application-specific SAT solvers A modern BDD package Improved sequential logic simulators combining random, guided and symbolic simulation Improved abstraction refinement … and may be a new engine or two 

Conclusions Reviewed verification fundamentals Discussed a typical verification flow Considered verification engines Transformers, bug-hunters, provers Introduced a recently-discovered engine (PDR) Looked into the future

Working for Industry in Academia The focus of our research group at Berkeley (BVSRC) shifted to formal verification in 2007 This was motivated by our attempts to apply new sequential synthesis in the verification domain The effort succeeded in a number of ways Early on we got a number of industrial examples from several companies, which helped us stay on track with industrial requirements Having hard, realistic examples is key for academic research! Currently we support an open-source integrated verification tool distributed as part of ABC The tools is widely used in industry and academia

Abstract This talk focuses on formal verification of synchronous hardware. We review the definition of sequential equivalence, representations of sequential circuits used in the tools, as well as typical algorithms employed to solve verification problems. The representations discussed include And-Inverter Graphs (AIGs), Binary Decision Diagrams (BDDs), and Conjuntive Normal Forms (CNFs). Different types of verification engines presented include transformers that simplify the problem, bug-hunters that detect failures after a finite number of clock cycles, and provers that prove a property to hold for infinite number of clock cycles. Strengths and weaknesses of different representations and engines are discussed, based on the experience of developing an industrial-strength verification system.