Alternative Approaches to Hardware Verification (Symbolic Simulation)

1
Alternative Approaches to Hardware
Verification(Symbolic Simulation)

• David L. Dill
• Computer Systems Laboratory
• Stanford University
• dill_at_cs.stanford.edu

2
Model checking

• Advantages
• Effective for control-dominated systems
• Works well with temporal logic
• Disadvantages
• Limited capacity (100 state bits, after
  reductions)
• Work-arounds are painful
• manual abstraction of design -- subject to false
  negatives
• automatic abstraction -- not reliable
• extracting sub-design -- difficult to specify
  environmental assumptions/correctness conditions

3
Outline

• Introduction
• Symbolic simulation
• Basics
• States vs. Predicates
• High-level and low-level simulators
• Verification methods
• Generalized pre- and post- conditions
• Abstraction functions
• Self comparison
• Conclusions

4
Symbolic Simulation
a
b
c
Input expressions result in output expressions
5
Symbolic Simulation

• Advantages
• Can deal with larger designs than model
  checking.
• Possibly more natural for non-formalists.
• Amenable to partial verification.
• Disadvantages
• Not good with state machines (possibly better
  with data paths).
• Does not support temporal logic
• Requires ingenuity to prove properties.

6
Symbolic Simulation(sequential case)
a0
a0b0 b0 c
b0
c
7
Symbolic Simulation(sequential case)
a1
a1b1 b1(a0b0 b0c)
b1
a0b0 b0c
8
Symbolic Simulation as unrolling
a1b1 b1(a0b0 b0c)
a1
a0
b1
b0
Logically equivalent to unrolled circuit
c
9
Symbolic Simulation
Some inputs can be constants
Resulting in simpler output expressions
1
bbc bc
b0
c
10
Symbolic Simulation
Input expressions can also be related
Resulting in simpler output expressions
ab
bbc bc
b
c
11
Symbolic states

• Def a state is an assignment of values to state
  variables.
• Def a symbolic state is an assignment of
  expressions to state variables
• Variables appearing in symbolic expressions are
  called parameters.

12
Predicates vs. symbolic states

• A symbolic state represents a set of states.
• E.g., xa, ya1 represents states x0,y1,
  x1,y2, etc.
• A state predicate is a predicate over the state
  variables.
• A state predicate holds on a symbolic state if it
  holds for all values of the parameters.
• Implication parameter renaming does not affect
  truth value of state predicates.

13
Generality of symbolic states

• Preorder s ? t if P(t) ? P(s) for all state
  predicates P.
• Example xa,ya1 ? xa,yb
• Most general symbolic state assigns a unique
  parameter to each state variable.
• State can be generalized by replacing an
  expression by a fresh variable.

14
Symbolic simulators

• Using BDDs as the symbolic representation
• Work at gate and MOS transistor level
• Variables represent individual bits
• Bits can have X value (meaning value is
  unknown).
• Systems COSMOS Bryant et al, CMU, Voss Seger
  et al, UBC and Intel

15
Symbolic simulators

• High-level symbolic simulation
• Datatypes integers, reals, bitvectors, arrays,
  records
• Operations logical, arithmetic, equality,
  uninterpreted functions
• Coupled with decision procedure for
  quantifier-free first order logic
• Primary application microprocessor verification
  Dill et al, Stanford Burch, Stanford and
  Cadence

16
Verification of properties

• Systems can be verified using symbolic simulation
  by three methods
• Generalized pre- and post-conditions
• Abstraction
• Self-consistency checking

17
Pre- and Post-conditions

• Specification If current state satisfies P,
  next state satisfies property Q.
• Obvious method compute
• post_state ssim(mgs_state)
• (mgs_state most general symbolic state)
• then prove
• P(mgs_state) ? Q(post_state)

18
Pre- and Post-conditions

• Problem with previous approach
• Result of symbolic simulation may be too large
  because of inputs not satisfying pre-condition.

Complex logic
Simple logic
select
If precondition implies select 1, no need to
simulate complex logic.
19
Parameterization

• Solution Start with a symbolic state that is
  equivalent to precondition (not most general
  state).
• Parameterization of a state predicate find most
  general symbolic state satisfying the predicate.
• Ex State predicate P(x,y) (x ? y)
• Symbolic state xa, y(a ? b)
• There is a general algorithm for parameterization
  of BDDs see Aagard, Seger, Jones, DAC 99

20
Inductive invariants

• For hardware (and other reactive systems), often
  need to show property holds for all reachable
  states.
• Standard approach use induction
• Prove that P holds on initial state
• Prove that if P is true at time t, it remains
  true at time t1.
• Use symbolic simulation with P as pre- and post-
  condition for inductive step.
• Note power of model checking is ability to prove
  non-inductive invariants, automatically.

21
Generalized invariants

• Problem Intermediate states in multi-step
  transactions complicate invariants.
• Solution Use multi-step symbolic simulation to
  skip over intermediate states Su et al, FMCAD
  98

C
C
and assuming conditions that enable this
path (path constraints)
Assuming invariant here
Prove invariant here
22
Generalized invariants

• Identify control FSMs and clean states in the
  design.
• Extract regular expressions from FSMs that
  describe all paths between clean states.
• Symbolically simulate all the paths.
• Intuition computes next state function from
  clean states to clean states, skipping over dirty
  states.
• Guess loop invariants by substituting fresh
  variables.
• Prove that invariants hold on clean states.
• We found several bugs in the instruction fetch
  unit of the Stanford Torch microprocessor design
  using this approach.

23
X value

• In transistor-level circuits, it is necessary to
  model unknown values
• Maybe electrical 0, 1, or in-between
• X value represents unknown
• Xs are useful for abstraction (deleting values).
• Bryant, IEEE TCAD 1991 verified a RAM with
  non-symbolic simulation, by exploiting Xs

X
0
0
X
X
24
Symbolic trajectory evaluation

• Symbolic trajectory evaluation is result of
  dealing with symbolic simulation over this
  lattice.
• Antecedent - user constraint on values
• Consequent - result of simulation

25
STE Success Stories

• Verification of arrays (memories, TLBs, etc) in
  PowerPC architecture.
• Several tricks e.g., exploitation of Xs,
  symmetry
• Manish Pandey PhD thesis CMU-CS-97-162.
• Pandey and Bryant, IEEE TCAD July 1999.
• x86 Instruction length decoder for Intel
  processor
• Combined symbolic simulator with theorem prover
• Parameterization used heavily.
• Aagard, Jones, Seger, DAC98
• Intel FP adder
• Aagard, Jones, Seger, DAC99
• Case splits to get around BDD blowup from
  variable shift in adder.

26
Abstraction functions
Abstraction functions are useful for comparing an
implementation with an executable specification.
An abstraction function maps every execution of
the implementation to an execution of the
specification.
Initial specification state
Abstraction
Initial implementation state
27
Abstraction functions
28
Abstraction and symbolic simulation

• Key idea Symbolically simulate everything
• Implementation
• Specification
• Abstraction function

29
Decision procedures

• Need to check equivalence of states which may
  have very different expressions.
• Quantifier-free first-order logic is
• appropriately expressive
• decidable
• Example SVC (Stanford Validity Checker)
• Barrett, Dill, Levitt FMCAD 96

30
Microprocessor verification

• Specification Instruction set architecture
  (ISA)
• programmers view of machine
• not pipelined
• single-cycle per instruction
• Implementation Microarchitecture (MA)
• pipelined
• may have stalls, bypass
• likely to have bugs.
• Proof by abstraction function

31
Flushing

• Defining inductive abstraction is hard because of
  partially executed instructions.
• Solution Abstraction function should
• Flush pipeline to get to a clean MA state,
• Then extract ISA state from clean MA state.
• Flushing Burch Dill, CAV 94

Flushing function often can be defined
automatically by symbolic simulation of design
32
Dout1
Dout2
Asrc_ex 5
Result_wb 1
Din
BSrc_ex 1
RegFile

R1
OP
A1
B1
A2
B2
R2
Src1
Addr
Src2
Dst
Dest_wb
33
Flushing and Abstraction
ISA_step
Extract ISA state
Extract ISA state
Abstraction
flush
flush
MA_step
34
Microprocessor Verification using STE

• Combines BDD-based simulation with SVC-like
  formulas.
• Successful on several realistic designs
• Perhaps a convergence of high-level and low-level
  approaches.
• Many other tricks used (e.g., efficient modeling
  of memories using BDDs, encoding tricks).
• Velev Bryant (e.g., this CAV)

35
Self-consistency checking

• Problem specifications usually dont exist.
• Cost of writing them adds to verification cost.
• Idea compare design to itself, running in two
  different but equivalent modes.
• High performance designs often have several ways
  of computing same result.
• Examples
• with and without interrupts
• compare pipelined with one instruction at a time
  (e.g. insert NOPs to space instructions).

36
Self-consistency checking

• x86 instruction decoder
• Robert Jones, PhD thesis (to appear later this
  summer).
• Retirement logic of an x86 microprocessor
• Jones, Seger, Dill FMCAD 96 (not full formal
  verification).
• Out-of-order processor design
• Combines several ideas, including
  self-consistency.

37
Incremental flushing
Jones, Skakkebaek, Dill FMCAD 98
38
Summary

• Symbolic simulation is better than model checking
  for circuits with nontrivial data path
  computations.
• Memories
• Pipelines
• even data path with FSM controllers (sometimes)

39
Summary

• Symbolic simulation can be done at high or low
  levels of abstraction
• Low level is good for transistor-level designs
• and for post hoc verification of existing designs
  (can get useful results without major methodology
  shift).
• and X values can be useful for abstraction

40
Summary

• High-level simulation gives access to a variety
  of nice abstract data types
• Integers, reals, arrays, uninterpreted functions
• Hide data widths, functions, memory size
• No one knows how to model check at this level
  (reliably).
• Symbolic simulation may be require more
  cleverness to use effectively than model checking
• New ideas are fermenting rapidly at this time.

41
Summary

• Invariants are the Achilles heel
• Almost always need characterization of reachable
  states
• Can prove them using symbolic simulation if
  theyre inductive.
• Finding inductive invariants is often the hardest
  part of a proof
• Automatic invariant finding techniques (for
  hardware) are inadequate.
• Model checking finds invariants automatically

42
Problems and future directions

• Better solutions to invariant finding are needed.
• Convergence of low and high-level symbolic
  simulation
• New verification methodologies
• Design for verification
• Faster, more powerful decision procedures