1. Introduction to Formal Verification
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”) 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

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 D T p
Equivalence checking D2 D1 T =

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

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

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

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

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

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

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

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.