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

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

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
Category:

less

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)


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

2
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

3
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

4
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

5
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
6
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

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

9
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

?
ytrue
Primary output
Logic gates memory elements
Primary inputs
10
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

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

13
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
    constraints
  • BDDs (exact reachability)
  • Interpolation (over-approximate reachability)
  • Property directed reachability (over-approximate
    reachability)
  • Interval property checking
  • Transformers
  • Combinational synthesis
  • Retiming
  • etc

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

16
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

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

18
Retiming Engine
  • Uses most-forward retiming to canonicize
    register positions (before register
    correspondence)
  • Uses min-register retiming (A. Hurst, DAC08) 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

19
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

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

21
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

22
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
a1
a2
Bad
Bad
a3
T
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.
?
Init
Init
Reached
23
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 ?

24
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

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

27
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.
About PowerShow.com