1. Automatic Abstraction of Microprocessors for Verification
Bryan Brady
CS252

2. Processor Verification
How to verify? Two options:
Simulation
Formal Verification
simulation:
advantages: can test actual design, no verification model needed
disadvantages: misses corner cases, takes too long to fully test
formal verification:
advantages: can mathematically prove correctness, implicitly tests all inputs
disadvantages: requires a separate verification model, computationally hard
example: pentium FDIV. certain inputs result in inaccurate results for fdiv. 1.14*10^-10 of input space. missing entry in lookup table
OpenSPARC T1 Microarchitecture Specification, Sun Microsystems, Inc., 2006

3. Bridge the Gap Two extremes: Manually Automatically
Tedious, error prone process
Time consuming
Automatically
Abstract away everything
Model precisely, abstract nothing
Somewhere in between
HDL
Verification
Model

4. Goals Remove the burden of creating a verification model
Develop a scalable approach to large scale processor verification
Not limited to processors

5. 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
Old
Impl
State
Flush, Project
Old
Spec
State
Execute 1 cycle
Execute 1 cycle
New
Impl
State
New
Spec
State
Flush, Project
S’Impl
S’spec
Automatic Verification of Pipelined Microprocessor Control, Burch and Dill, CAV 1994

6. Abstraction Experiment: Y86
5 stage pipeline
single-threaded
in-order execution
simplified x86
R. E. Bryant and D. R. O’Hallaron. Computer Systems: A Programmer’s Perspective. Prentice-Hall 2002

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

8. Abstraction Experiment: Y86

9. Semi-Automatic, Selective Abstraction via Type-Inference
Designer partially annotates Verilog with abstraction information
Type-qualifiers
Format strings
Our algorithm
Determine the level of abstraction for non-annotated variables using type-inference
Generate abstracted verification model
Types: bit-vector, term, interpreted, uninterpreted

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

11. Type-Qualifiers How do we represent “some_func”?
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b;
a : BITVEC[8];
b : TERM;
c := some_func(a,b,d);
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b; //interpret
a : BITVEC[8];
b : TERM;
c := some_func(a,b,d);
How do we represent “some_func”?

12. Type-Inference b(term) a(bit-vector) d ? b(term) a(bit-vector) d ?
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b;
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b; //interpret 1
b(term)
a(bit-vector) d ? 1
b(term)
a(bit-vector) d ?
c(bit-vector) f
c(bit-vector)
What if “b” is a different size than bit-vector “c” ?

13. 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 or sign-extend
If term is bigger, extract low-order bits?
UCLID’s decision procedure figures out the smallest size for terms
Generate run-time warning

14. Type-Inference d a(bit-vector) c(term) ? b(term) d a(bit-vector)
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c; //term
wire d;
assign c = d ? a : b; //interpret 1
b(term)
a(bit-vector) d ?
c(term)
bv2term 1
b(term)
a(bit-vector) d ?
c(term)
bv2term

15. Format Strings
If we have a term and need to extract bits, but don’t want to represent it precisely...
input [7:0] flit; //term
modx modx(flit[7:4],flit[3:0]);
s/flit[7:4]/flit_7_4/;
s/flit[3:0]/flit_3_0/;

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

17. Progress Originally wanted to work on OpenSPARC
Too big to do by hand
Identified what needs to be done to automate the modeling process
Working on chip multiprocessor router by hand to further show that selective abstraction is useful (developed by Li-Shiuan Peh at Stanford)

18. Questions/Comments

19. Abstraction Experiment: Y86

20. Modeling with Abstraction
Abstract details of data encodings and operations
Keep control logic precise
Assume functional units are correct, verify overall correctness

21. Data Abstraction  View data as symbolic words
Arbitrary integers, no assumptions on size or encoding x0 x1 x  x2
xn-1

22. What do we do about logic functions?
Data Abstraction
Control Logic
Data Path
Com.
Log. 1
Com.Log. 2
Data Path
Com.
Log. 1 ?
What do we do about logic functions?

23. 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)
conservative approximation, ignores detailed functionality
ALU f

24. Data Selection If-then-else operator Its a multiplexor
Allows control-dependent data flow 1 x y p
ITE(p, x, y)

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

26. 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 M a M a m0