The First Taste of Formal Verification (a tutorial to be given at ICCAD 2011) - PowerPoint PPT Presentation


PPT – The First Taste of Formal Verification (a tutorial to be given at ICCAD 2011) PowerPoint presentation | free to download - id: 6ac8f2-OGYyY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

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


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

Number of Views:4
Avg rating:3.0/5.0
Date added: 22 February 2020
Slides: 28
Provided by: alan


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The First Taste of Formal Verification (a tutorial to be given at ICCAD 2011)

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

  • 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

  • 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)
all paths
every state on these paths
Infinite Computation Tree
Liveness property good thing eventually
happens AFp (p describes a good thing)
some state on these paths
all paths
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

Equivalence checking
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

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

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

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
  • It does not contain bad states where the
    property fails

State space
Inductive Invariant (cont.)
  • It does not matter how inductive invariant is
  • 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
  • random simulation
  • bounded model checking (BMC)
  • hybrids of the above two (semi-formal)
  • Provers
  • K-step induction, with or without uniqueness
  • BDDs (exact reachability)
  • Interpolation (over-approximate reachability)
  • Property directed reachability (over-approximate
  • 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

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
  • Uses min-register retiming (A. Hurst, DAC08) to
    reduce the number of registers (before signal
  • 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
  • If a resource limit is reached, the problem is
  • 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 HWMCC10!
  • Remarkable features
  • Efficiently tackles both SAT and UNSAT instances
  • Lends itself to localization abstraction and
  • Conceptually simple, relatively tuning-free
  • The best single-engine verification tool to date
  • Outperforms interpolation and induction on
  • Outperforms simulation and BMC for hard SAT cases
  • Solves many instances previous solved only by

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
  • Termination criteria
  • If a counter-example is found, return SAT
  • If an over-approximation is inductive, return
  • The algorithm constructs over-approximations
  • In a property directed way
  • the property is used to decide what clauses to
  • With an inductive flavor
  • induction is used to prove that a clause holds in
    a frame

PDR (Illustration)
Time frame
Time frame 1
Time frame 0
Property output
Primary inputs
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
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.
Whats 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 ?

  • 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

(No Transcript)
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

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