Selective Term-Level Abstraction with Type-Inference

1
Selective Term-Level Abstraction with
Type-Inference

• Bryan Brady
• Advisor Sanjit Seshia
• In collaboration with
• Randy Bryant, Daniel Kroening,
• Joel Ouaknine, Ofer Strichman

2
Processor Verification

• How to verify? Two options
• Simulation
• Formal Verification

OpenSPARC T1 Microarchitecture Specification, Sun
Microsystems, Inc., 2006
3
Processor Verification

• Simulation
• Advantages
• Can test actual design
• No verification model needed
• Disadvantages
• Misses corner cases
• Takes too long to fully test design

4
Example Pentium FDIV

• Certain input data results in inaccuracies
• Fraction of input space prone to failure
• 1.14 10-10
• Cause Missing entries in the lookup table used
  in the hardware divide algorithm

Statistical Analysis of Floating Point Flaw,
Intel White Paper, CS-013007, 1994
5
Processor Verification

• Formal Verification
• Advantages
• Can mathematically prove correctness
• Implicitly tests all input combinations
• Disadvantages
• Requires a separate verification model
• Computationally hard.

6
Bridge the Gap

• Two extremes
• Manually
• Tedious, error prone process
• Time consuming
• Automatically
• Abstract away everything
• Model precisely, abstract nothing
• Somewhere in between

HDL
Verification Model
7
Bridge the Gap

• Automatically generate verification model
• Abstract everything
• Spurious counter-examples will result
• Need some level of precision
• Model precisely
• Models become very large
• Not scalable
• Need to find the sweet spot
• Precise enough, but still scalable

8
Our Goals

• Remove the burden of creating a verification
  model
• Develop a scalable approach to large scale
  processor verification

9
Semi-Automatic, Selective Abstraction via
Type-Inference

• Designer partially annotates Verilog with
  abstraction information
• Our algorithm
• Determine the level of abstraction for
  non-annotated variables using type-inference
• Generate abstracted verification model

Annotation
input 30 a //bit-vector input 30
b output 30 c assign c a b
10
OpenSPARC

• Industrial scale 300K lines of Verilog
• 100K lines of Verilog in SPARC core
• Open source, industrial scale designs are hard to
  come by without an NDA
• Want reproducible results

11
Currently

• We have been using a toy example
• Y86 Bryant, OHallaron, 2002
• Simplified version of x86
• 5 stage, single-threaded, in-order pipeline
• 7 versions of varying complexity
• Will revisit this later...
• OpenSPARC is much larger

12
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Abstraction using Type-Inference
• Summary

13
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Abstraction using Type-Inference
• Summary

14
OpenSPARC

• OpenSPARC T1 processor
• 8 SPARC V9 CPU cores
• 4 threads per core
• Crossbar interconnect between CPUs (x8), L2 cache
  (x4), FPU (x1), I/O Bus (x1)
• 64-bit data path

OpenSPARC T1 Microarchitecture Specification, Sun
Microsystems, Inc., 2006
15
OpenSPARC SPARC core

• 4 threads, hardware supported
• Windowed register file, 8 per thread
• Shared Instr/Data Caches
• Single-issue, 6 stage pipeline
• Stream based crypto coprocessor

OpenSPARC T1 Microarchitecture Specification, Sun
Microsystems, Inc., 2006
16
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Abstraction using Type-Inference
• Summary

17
Bit-vector Modeling
Verilog UCLID
input 310 a input 310 b input x assign c a b assign d a ltlt 2 assign e x ? a b a BITVEC32 b BITVEC32 x TRUTH c a _32 b d a ltlt_32 2 e case (x 1) a default b esac

• View each register or memory bit as a state
  variable
• Each variable is defined by a Boolean function
• Conceptually simple, allow high degree of
  automation
• State space can be very large

18
Modeling with Abstraction

• Abstract details of data encodings and operations
• Keep control logic precise
• Assume functional units are correct, verify
  overall correctness

19
Data Abstraction

• View data as symbolic words
• Arbitrary integers, no assumptions on size or
  encoding

x0
x1
x2
xn-1
20
Data Abstraction
Control Logic
21
Function Abstraction

• Replace blocks that transform or evaluate data
  with generic, unspecified function
• Assume only functional consistency

• a x ? b y ? f (a, b) f (x, y)

f
22
Function Abstraction

• Conservative approximation
• Ignores detailed functionality

Control Logic
Data Path
Com. Log. 1
Com. Log. 1
23
Data Selection

• If-then-else operator
• Its a multiplexor
• Allows control-dependent data flow

24
Data-Dependent Control

• Model with Uninterpreted Predicate
• Yields arbitrary Boolean value for each control
  data combination
• Functional consistency holds

Branch?
Cond
Adata
p
Branch Logic
Bdata
25
Memories as Mutable Functions

• Memory M modeled as a function
• M(a) Value in memory location a
• Initially
• Arbitrary state
• Modeled by uninterpreted function m0

26
Memories as Mutable Functions

• Writing Transforms Memory
• M Write(M, wa, wd)
• Reading from updated memory
• Address wa gets wd
• Otherwise, return what was there
• Express with Lambda notation
• M ?a.ITE(awa, wd, M(a))

27
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Abstraction using Type-Inference
• Summary

28
UCLID

• Tool for verifying infinite-state systems
• Originally developed at CMU by Seshia Lahiri
• Multiple uses
• Bounded Model Checking (BMC)
• Inductive invariant checking
• Correspondence checking
• Tailored for pipelined processor verification

29
Correspondence Checking
SImpl
Sspec
Verify that the spec can simulate (mimic) the
pipelined implementation Compare shared
state before and after the spec and
implementation execute PC, RF, MEM
Flush, Project
Old Impl State
Old Spec State
Execute 1 cycle
Execute 1 cycle
New Impl State
New Spec State
Flush, Project
SImpl
Sspec
Automatic Verification of Pipelined
Microprocessor Control, Burch and Dill, CAV 1994
30
UCLID
31
UCLID

• Bit-vector modeling
• Finite precision bit-vector operators
• Arithmetic, logical, relational
• Extraction, concatenation
• Boolean operators
• Term-level modeling
• Term-level operators
• successor, predecessor, relational
• Boolean operators

32
UCLID

• Both terms and bit-vectors
• Uninterpreted functions
• Uninterpreted predicates
• Lambda expressions
• Just a way to specify functions, like memory

33
UCLID Example ALU
34
UCLID Example Bit Ops
f_rA getHi(iMem(succ(f_pc))) f_rB
getLo(iMem(succ(f_pc))) ... f_valC
quadmerge(iMem(succ(f_pc)),
iMem(succ2(f_pc)),
iMem(succ3(f_pc)),
iMem(succ4(f_pc)))
Term-level (TERM)
f_rA (iMem(( 1 _32 f_pc ))) 74 f_rB
(iMem(( 1 _32 f_pc ))) 30 ... f_valC
(iMem(( 1 _32 f_pc )) _at_ iMem(( 2 _32 f_pc ))
_at_ iMem(( 3 _32 f_pc )) _at_ iMem(( 4 _32
f_pc )))
Bit-vector, interpreted (BV-BIT)
35
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Term-Level Abstraction using
  Type-Inference
• Summary

36
Experiment Y86

• Y86
• 5 stage pipeline
• single-threaded
• in-order execution
• simplified x86

R. E. Bryan and D. R. OHallaron. Computer
Systems A Programmers Perspective.
Prentice-Hall 2002
37
Experiment Y86

• Compare runtimes between various encodings of Y86
• Term-level
• Bit-vector, uninterpreted
• Bit-vector, partially interpreted
• Bit-vector, fully interpreted
• We still represent memory and the register file
  as a mutable function

38
Experiment Y86

• 7 versions of Y86 of varying complexity
• Some use forwarding, some do not
• Varying methods of branch prediction
• Backward taken, forward not taken
• None
• One version has a single write port for the
  register

39
Experiment Y86
40
Experiment Y86

• Term-level version is faster in every case
• Interpreting the ALU (BV-ALU) greatly increases
  runtime in most cases
• Mostly due to interpreting XOR
• SAT has a hard time with XOR
• Interpreting bit extracts and concats doesnt
  degrade performance (sometimes its faster!)
• Using abstraction in the right places can
  greatly reduce verification time

41
Outline

• OpenSPARC
• Modeling Techniques
• UCLID
• Experimental Results
• Selective Term-Level Abstraction using
  Type-Inference
• Summary

42
Proposed Approach

• Starting with a Verilog design, annotate with
  type-qualifiers, generate a hybrid
  term/bit-vector UCLID model
• Requirements
• Type-qualifiers syntax, usage
• Type-inference rules
• Type-inference algorithm

43
Proposed Approach Benefits

• No need to manually create verification model
• Eliminates human-introduced errors
• Designer has an intuition about what can and
  cant be abstracted
• They know where the data-dependent control is
• Can operate directly on Verilog
• Only need to partially annotate, type-inference
  algorithm takes care of the rest

44
Type-Qualifiers

• Type-qualifiers are used to give extra properties
  to variables
• Example (C/C)
• const int x
• const gives variable x the property that it cant
  be changed
• We will use them to denote what level of
  abstraction to use

45
Type-Qualifiers

• Two kinds of type-qualifiers
• Variables term, bit-vector
• inputs, outputs, wires
• Operations interpreted, uninterpreted
• assignments, modules

46
Type-Qualifiers

• Initially
• All variables are terms (except Booleans)
• All operations are uninterpreted
• Except purely Boolean operations (control)
• Want to use as much abstraction as possible,
  model precisely only when we need to

47
Type-Qualifiers

• input 70 a //bit-vector
• input 70 b
• wire 70 c
• wire d
• assign c d ? a b

a BITVEC8 b TERM c some_func(a,b,d)
How do we represent some_func?
48
Type-Inference
input 70 a //bit-vector input 70 b wire
70 c wire d assign c d ? a b
input 70 a //bit-vector input 70 b wire
70 c wire d assign c d ? a b
//interpret
c(bit-vector)
49
Type-Inference

• Type reconciliation
• Type-cast terms to bit-vectors
• Propagate through circuit
• Only need to do this when function is interpreted
• Use a term2bv function
• If term is smaller, pad with zeros
• If term is bigger, extract low-order bits?
• UCLIDs decision procedure figures out the
  smallest size for terms
• Generate run-time warning

50
Type-Inference
input 70 a //bit-vector input 70 b wire
70 c wire d assign c d ? a b
//interpret
51
Type-Inference

• Why cant we convert the bit-vector to a term?
• Were explicitly using a bit-vector because we
  need precision
• We dont convert bit-vectors to terms, unless we
  really want to

52
Type-Inference
input 70 a //bit-vector input 70 b wire
70 c //term wire d assign c d ? a b
//interpret
53
Type-Inference

• What about uninterpreted ?
• Module with interpreted functions inside, but we
  want to abstract the entire module
• Need to find the right level of abstraction

module top(a,b) input 70 a input 70
b wire 70 c add add(.in1(a), .in2(b),
.out(c)) endmodule module add(in1, in2,
out) //uninterpret ... //interpret ... ...
//interpret assign out ... //interpret endmodul
e
54
Type-Inference

• How to handle certain cases
• An interpreted bit-vector operation applied to
  terms (output a term)
• Everything is converted to bits before SAT
  solver is invoked
• Do we change the types, or just allow a
  bit-vector operation on terms?

55
Todo

• Fully develop type-inference rules, algorithm
• Create various abstractions of OpenSPARC
• Performance evaluation
• runtime, spurious counter-examples
• Compare with purely bit-vector version
• Cant compare to fully term-level version, too
  many spurious counter-examples

56
Summary

• Semi-automatic algorithm to generate term-level
  abstractions of industrial scale designs
• Eliminate human-introduced errors in verification
  modeling
• Reduce verification time, improve verification
  efficiency
• Integrate verification with design

57
Questions/Comments