Formal Processor Verification

1
System Modeling and Verification with UCLID
Randal E. Bryant
Carnegie Mellon University
http//www.cs.cmu.edu/bryant
Contributions by former graduate students Sanjit
Seshia, Shuvendu Lahiri
2
Applying Data Abstraction to Hardware Verification

• Idea
• Abstract details of data encodings and operations
• Keep control logic precise
• Applications
• Verify overall correctness of system
• Assuming individual functional units correct
• Technology
• Use restricted subset of first-order logic
• Implement efficient decision procedures
• Multiple methods of performing verification

3
Challenge System-Level Verification

• Verification Task
• Does processor implement its ISA?
• Why is it Hard?
• Lots of internal state
• Complex control logic
• Complex functionality

Alpha 21264 Microprocessor Microprocessor Report,
Oct. 28, 1996
4
Sources of Complexity

• State
• ISA registers, memory
• Microarchitectural caches, buffers, reservation
  stations
• Conceptually finite state, but practically
  unbounded
• Control
• Pipelines spread execution across multiple cycles
• Out-of-order execution modifies processing order
• Superscalar operation creates parallelism
• Control logic coordinates everything
• Resulting behavior matches that of sequential ISA
  model
• Functionality
• Arithmetic functions, instruction decoding

5
Existing Verification Methods

• Simulators, equivalence checkers, model checkers,
  
• All Operate at Bit Level
• RTL model
• State encoded as words and arrays of words
• Comprised of bits
• Most Operate at Cycle or Subcycle Level
• How each bit of state gets updated
• System Modeling Languages
• Abstract time up to transaction level
• Still view state as collection of bits

6
Word-Level Abstraction
Control Logic

• Data Abstract details of form functions
• Control Keep at bit level
• Timing Keep at cycle level

7
Data Abstraction 1 Bits ? Integers
x0
x1
x2
xn-1

• View Data as Symbolic Words
• Arbitrary integers
• No assumptions about size or encoding
• Classic model for reasoning about software
• Can store in memories registers

8
Modeling Data Selection

• If-Then-Else Operation
• Mulitplexor
• Allows control-dependent data flow

9
Abstracting Data Bits
Control Logic
10
Abstraction 2 Uninterpreted Functions
f

• For any Block that Transforms or Evaluates Data
• Replace with generic, unspecified function
• Only assumed property is functional consistency
• a x ? b y ? f (a, b) f (x, y)

11
Abstracting Functions
Control Logic
Data Path
Com. Log. 1
Com. Log. 1

• For Any Block that Transforms Data
• Replace by uninterpreted function
• Ignore detailed functionality
• Conservative approximation of actual system

12
Modeling Data-Dependent Control
Branch?
Cond
Adata
p
Branch Logic
Bdata

• Model by Uninterpreted Predicate
• Yields arbitrary Boolean value for each control
  data combination
• Produces same result when arguments match
• Pipeline reference model will branch under
  same conditions

13
Abstraction 3 Modeling Memories as Mutable
Functions

• Memory M Modeled as Function
• M(a) Value at location a
• Initially
• Arbitrary state
• Modeled by uninterpreted function m0

14
Effect of Memory Write Operation

• Writing Transforms Memory
• M? Write(M, wa, wd)
• Reading from updated memory
• Address wa will get wd
• Otherwise get whats already in M

• Express with Lambda Notation
• Notation for defining functions
• M?
• ? a . ITE(a wa, wd, M(a))

15
Systems with Buffers
Circular Queue
Unbounded Buffer

• Modeling Method
• Mutable function to describe buffer contents
• Integers to represent head tail pointers

16
Some History of Term-Level Modeling

• Historically
• Standard model used for program verification
• Widely used with theorem-proving approaches to
  hardware verification
• E.g, Hunt 85
• Automated Approaches to Hardware Verification
• Burch Dill, 95
• Tool for verifying pipelined microprocessors
• Implemented by form of symbolic simulation
• Continued application to pipelined processor
  verification

17
UCLID

• Seshia, Lahiri, Bryant, CAV 02
• Term-Level Verification System
• Language for describing systems
• Inspired by CMU SMV
• Symbolic simulator
• Generates integer expressions describing system
  state after sequence of steps
• Decision procedure
• Determines validity of formulas
• Support for multiple verification techniques
• Available by Download
• http//www.cs.cmu.edu/uclid

18
Challenge Model Generation

• How to generate term-level model
• How to guarantee faithfulness to RTL description
• Comparison of Models
• RTL
• Abstracts functional elements from gate-level
  model
• Synthesis allows automatic map to gate level
• Term level
• Abstracts bit-level data representations to words
• Abstracts memories to mutable functions
• No direct connection to synthesizable model

19
Generating Term-Level Model

• Manually Generate from RTL
• How do we know it is a valid abstraction?
• Hard to keep consistent with changing RTL
• Automatically Generate from RTL
• Andraus Sakallah, DAC 04
• Must decide which signals to keep Boolean, which
  to abstract
• Confused by bit field extraction primitives of
  HDL
• Synthesize RTL from Word-Level Model
• Difficult to make efficient

20
Underlying Logic

• Existing Approaches to Formal Verification
• E.g., symbolic model checking
• State encoded as fixed set of bits
• Finite state system
• Amenable to Boolean methods (SAT, BDDs)
• Our Task
• State encoded with unbounded data types
• Arbitrary integers
• Functions over integers
• Must use decision procedures
• Determine validity of formula in some subset of
  first-order logic
• Adapt methods historically used by automated
  theorem provers

21
EUF Equality with Uninterp. Functs

• Decidable fragment of first order logic
• Formulas (F ) Boolean Expressions
• ?F, F1 ? F2, F1 ? F2 Boolean connectives
• T1 T2 Equation
• P (T1, , Tk) Predicate application
• Terms (T ) Integer Expressions
• ITE(F, T1, T2) If-then-else
• Fun (T1, , Tk) Function application
• Functions (Fun) Integer ? Integer
• f Uninterpreted function symbol
• ? x1, , xk . T Function lambda expression
• Predicates (P) Integer ? Boolean
• p Uninterpreted predicate symbol

22
UCLID Operation
file.ucl
UCLID Formula
Model Specification
Lambda Expansion
?-free Formula
Function Predicate Elimination

• Operation
• Series of transformations leading to
  propositional formula
• Except for lambda expansion, each has polynomial
  complexity

Term Formula
Finite Instantiation
Boolean Formula
Boolean Satisfiability
23
UCLID Example
Boolean state

• DLX Pipeline
• Single-issue, 5-stage pipeline

Integer state
Function state
Pipeline
Write Back
Fetch
Decode
Execute
Memory
24
Writing Reading Register File
25
Writing Register File
initRF rf0 ( Uninterpreted Function )
nextRF Lambda(a) . case mw_Valid
(a mw_Dest) mw_Data default
RF(a) esac
Write Back
RF
26
Reading Register File
initde_Arg1 dea10 ( Initially
arbitary ) nextde_Arg1 nextRF(src1(fd_In
str)) initde_Arg2 dea20 (
Initially arbitary ) nextde_Arg2
nextRF(src2(fd_Instr))
Write-before-read semantics
27
Verifying Safety Properties
Bad States
Reachable States
Reset States
Reset

• State Machine Model
• State encoded as Booleans, integers, and
  functions
• Next state function expresses how updated on each
  step
• Prove System will never reach bad state

28
Bounded Model Checking
Bad States
R2

• Repeatedly Perform Image Computations
• Set of all states reachable by one more state
  transition
• Easy to Implement
• Underapproximation of Reachable State Set
• But, typically catch most bugs with 810 steps

R1
Reset States
29
True Model Checking
Bad States
R2

• Impractical for Term-Level Models
• Many systems never reach fixed point
• Can keep adding elements to buffer
• Convergence test undecidable

R1
Reset States

• Reach Fixed-Point
• Rn Rn1 Reachable

30
Inductive Invariant Checking
Bad States
Reachable States
Reset States

• Key Properties of System that Make it Operate
  Correctly
• Formulate as formula I
• Prove Inductive
• Holds initially I(s0)
• Preserved by all state changes I(s) ? I(?(i, s))

31
An Out-of-order Processor (OOO)
valid tag val
D E C O D E
incr
dispatch
Program memory
valid value src1valid src1val src1tag src2valid sr
c2val src2tag dest op
result
PC
Register Rename Unit
1st Operand
result bus
retire
2nd Operand
ALU

Reorder Buffer
execute
head
tail
Reorder Buffer Fields

• Data Dependencies Resolved by Register Renaming
• Map register ID to instruction in reorder buffer
  that will generate register value
• Inorder Retirement Managed by Retirement Buffer
• FIFO buffer keeping pending instructions in
  program order

32
Verifying OOO

• Lahiri, Seshia, Bryant, FMCAD 2002
• Goal
• Show that OOO implements Instruction Set
  Architecture (ISA) model
• For all possible execution sequences
• Challenge
• OOO holds partially executed instructions in
  reorder buffer
• States of two systems match only when reorder
  buffer flushed

33
Adding Shadow State

• McMillan, 98
• Arons Pnueli, 99
• Provides Link Between ISA OOO Models
• Additional entries in ROB
• Do not affect OOO behavior
• Generated when instruction dispatched
• Predict values of operands and result
• From ISA model

OOO
Reg. File
PC
Reorder Buffer
34
Invariant Checking

• Formulas I1, , In
• Ij(s0) holds for any initial state s0, for 1 ? j
  ? n
• I1(s) ? I2(s) ? ? In(s) ? Ij(s? ) for any
  current state s and successor state s? for 1 ? j
  ? n
• Invariants for OOO (13)
• Refinement maps (2)
• Show relation between ISA and OOO models
• Shadow state (3)
• Shadow values correctly predict OOO values
• State consistency (8)
• Properties of OOO state that ensure proper
  operation
• Overall Correctness
• Follows by induction on time

35
Access Modes for Reorder Buffer

• FIFO
• Insert when dispatch
• Remove when retire

• Content Addressable
• Broadcast result to all entries with matching
  source tag

• Global
• Flush all queue entries when instruction at head
  causes exception

All handled by UCLID lambda notation
36
OOO Invariants

• Split into Formulas I1, , In
• Ij(s0) holds for any initial state s0, for 1 ? j
  ? n
• I1(s) ? I2(s) ? ? In(s) ? Ij(s? ) for any
  current state s and successor state s? for 1 ? j
  ? n
• Invariants for OOO (13)
• Refinement maps (2)
• Show relation between ISA and OOO models
• State consistency (8)
• Properties of OOO state that ensure proper
  operation
• Added state (3)
• Shadow values correctly predict OOO values
• Overall Correctness
• Follows by induction on time

37
State Consistency Invariant Examples

• Register Renaming invariants (2)
• Tag in a rename-unit should be in the ROB, and
  the destination register should match
• ?r.?reg.valid(r)? (rob.head ? reg.tag(r) lt
  rob.tail ? rob.dest(reg.tag(r)) r )
• For any entry, the destination should have
  reg.valid as false and tag should contain this or
  later instruction
• ?robt.(?reg.valid(rob.dest(t)) ?
• t ? reg.tag(rob.dest(t)) lt rob.tail)

38
Extending the OOO Processor

• base
• Executes ALU instructions only
• exc
• Handles arithmetic exceptions
• Must flush reorder buffer
• exc/br
• Handles branches
• Predicts branch speculatively executes along
  path
• exc/br/mem-simp
• Adds load store instructions
• Store commits as instruction retires
• exc/br/mem
• Stores held in buffer
• Can commit later
• Loads must scan buffer for matching addresses

39
Comparative Verification Effort
(Person time shown cumulatively)
40
I Just Want a Loaf of Bread
Ingredients
Result
Recipe
41
Cooking with Invariants
Ingredients Predicates
rob.head ? reg.tag(r)
Recipe Invariants
?r,t.?reg.valid(r) ? reg.tag(r) t ?
(rob.head ? reg.tag(r) lt rob.tail ?
rob.dest(t) r )
reg.valid(r)
reg.tag(r) t
Result Correctness
rob.dest(t) r
42
Automatic Recipe Generation
Ingredients
Result
Recipe Creator

• Want Something More
• Given any set of ingredients
• Generate best recipe possible

43
Automatic Predicate Abstraction

• Graf Saïdi, CAV 97
• Idea
• Given set of predicates P1(s), , Pk(s)
• Boolean formulas describing properties of system
  state
• View as abstraction mapping States ? 0,1k
• Defines abstract FSM over state set 0,1k
• Form of abstract interpretation
• Do reachability analysis similar to symbolic
  model checking
• Implementation
• Early ones had weak inference capabilities
• Call theorem prover or decision procedure to test
  each potential transition
• Recent ones make better use of symbolic encodings

44
Abstract State Space
Abstraction
Concretization
Abstract States
Abstract States
Concrete States
Concrete States
45
Abstract State Machine
Abstract System
Concrete System

• Transitions in abstract system mirror those in
  concrete

46
Generating Concrete Invariant

• Reach Fixed-Point on Abstract System
• Termination guaranteed, since finite state
• Equivalent to Computing Invariant for Concrete
  System
• Strongest possible invariant that can be
  expressed by formula over these predicates

Abstract System
47
Systems Verified with Predicate Abstraction

• Very general models
• Unbounded processes, buffers, cache lines,
• Safety properties only

48
Automatic Predicate Discovery

• Strength of Predicate Abstraction
• If give it right set of predicates, PA will put
  them together into invariant
• Weakness
• Gets nowhere without right set of predicates
• Typical failure mode Generate true as
  invariant
• Challenges
• Too many predicates will overwhelm PA engine
• Our use of quantified invariants precludes
  counterexample-generated refinement techniques

49
Implementation of Predicate Discovery

• Lahiri Bryant, CAV 04
• Initially Extract predicates from verification
  condition
• Iterate Add new predicates by composing
  next-state formulas
• With some heuristics thrown in
• Experience
• Can automatically generate invariants for real
  examples
• 10X slower than for hand-selected predicates

50
Future Prospects

• Evaluation
• Important to abstract data data functions while
  maintaining details about control
• Demonstrated ability to verify complex,
  parameterized systems
• Model Generation is Weakest Link
• Big jump from bit-level to term-level
• Look at intermediate levels of abstraction with
  bit-vectors
• Need algorithmic connection between our model and
  RTL
• Predicate Abstraction Shows Promise
• Provides key automation advantage of model
  checking