Post on 20-Jan-2016
description
1
Selective Term-Level Abstraction with Type-Inference
Bryan Brady
Advisor: Sanjit SeshiaIn collaboration with:
Randy Bryant, Daniel Kroening,
Joel Ouaknine, Ofer Strichman
2
Processor Verification
How to verify? Two options:1. Simulation2. 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
VerificationModel
7
Bridge the GapAutomatically 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
input [3:0] a; //bit-vector input [3:0] b;output [3:0] c;assign c = a + b;
Annotation
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, O’Hallaron, 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
Our focus: SPARC core For now...
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
coprocessorOpenSPARC 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
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
Verilog UCLIDinput [31:0] a;input [31:0] b;input x;assign c = a + b; assign d = a << 2;assign e = x ? a : b;
a : BITVEC[32];b : BITVEC[32];x : TRUTH;c := a +_32 b;d := a <<_32 2;e := case (x == 1) : a; default : b; esac;
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
x
20
Data Abstraction
Data PathData Path
Com.Log.
1
Com.Log.
2
Control LogicControl Logic
Data PathData Path
Com.Log.
1
Com.Log.
1? ?
What do we do about logic functions?
21
Function Abstraction Replace blocks that transform or
evaluate data with generic, unspecified function
Assume only functional consistency
ALUf
a = x b = y f (a, b) = f (x, y)
22
Function Abstraction Conservative approximation Ignores detailed functionality
Data PathData Path
Control LogicControl Logic
Com.Log.
1
Com.Log.
1F1 F2
23
Data Selection If-then-else operator
Its a multiplexor Allows control-dependent data flow
1
0
x
y
p
ITE(p, x, y)1
0
x
y
1
x1
0
x
y
0
y
24
Data-Dependent Control
Model with Uninterpreted Predicate Yields arbitrary Boolean value for each
control + data combination Functional consistency holds
Cond
Adata
Bdata
Branch?B
ran
chL
og
ic
p
25
Memory M modeled as a function
• M(a): Value in memory location a
Initially
• Arbitrary state • Modeled by uninterpreted function m0
Memories as Mutable Functions
Ma
M
a 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(a=wa, wd, M(a))
M
Ma 1
0
wd
=wa
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
OldImplState
NewImplState
OldSpecState
NewSpecState
Flush, Project
Flush, Project
Execute 1 cycle
Execute 1 cycle
SImpl
S’Impl
Sspec
S’spec
Automatic Verification of Pipelined Microprocessor Control, Burch and Dill, CAV 1994
Verify that the spec can simulate (mimic) the pipelined implementation
Compare shared statebefore and after the spec and implementation execute
PC, RF, MEM
30
UCLID
FrontEnd
Symbolic Simulator
Decision Procedure
BackEnd
UCLID
SAT Checker
UCLIDSpecification
VALIDor
COUNTER-EXAMPLE
“Unrolls” model in BMC, Inductive Invariant Checking,
and Correspondence Checking
Deals with function applications, encodes terms/bit-vectors to CNF
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: ALUalu_out :=
alu_fun(alu_cntl,aluA,aluB);Term-level (TERM)
alu_fun :=
case
(alu_cntl = ((0 <S 2) # [1:0])) : (aluA +_32 aluB);
(alu_cntl = ((1 <S 2) # [1:0])) : (aluA -_32 aluB);
(alu_cntl = ((2 <S 2) # [1:0])) : (aluA && aluB);
default : xor_fun(aluA, aluB);
esac;
Bit-vector,
partially interpreted
(BV-ALU-XOR-UF)
alu_fun :=
case
(alu_cntl = ((0 <S 2) # [1:0])) : (aluA +_32 aluB);
(alu_cntl = ((1 <S 2) # [1:0])) : (aluA -_32 aluB);
(alu_cntl = ((2 <S 2) # [1:0])) : (aluA && aluB);
default : aluA ^^ aluB;
esac;
Bit-vector,
fully interpreted
(BV-ALU)
alu_out :=
alu_fun(alu_cntl,aluA,aluB);Bit-vector (BV-BASE)
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(succ^2(f_pc)), iMem(succ^3(f_pc)), iMem(succ^4(f_pc)));
Term-level (TERM)
f_rA := (iMem(( 1 +_32 f_pc ))) # [7:4];f_rB := (iMem(( 1 +_32 f_pc ))) # [3:0];...f_valC := (iMem(( 1 +_32 f_pc )) @ iMem(( 2 +_32 f_pc )) @ iMem(( 3 +_32 f_pc )) @ 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. O’Hallaron. Computer Systems: A Programmer’s 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 doesn’t 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
can’t 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
can’t 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-Qualifiersinput [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”?
48
Type-Inference
1
0b(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;
c(bit-vector)f
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b; //interpret
1
0b(term)
a(bit-vector)
d
?c(bit-vector)
What if “b” is a different size than bit-vector “c” ?
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?
UCLID’s decision procedure figures out the smallest size for terms
Generate run-time warning
50
Type-Inference
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c;
wire d;
assign c = d ? a : b; //interpret
1
0b(term)
a(bit-vector)
d
?c(bit-vector)term2bv
1
0b(bit-vector)
a(bit-vector)
d
?c(bit-vector)
51
Type-Inference Why can’t we convert the bit-vector to a
term? We’re explicitly using a bit-vector because
we need precision We don’t convert bit-vectors to terms,
unless we really want to
52
Type-Inference
input [7:0] a; //bit-vector
input [7:0] b;
wire [7:0] c; //term
wire d;
assign c = d ? a : b; //interpret
1
0b(term)
a(bit-vector)
d
?c(term)bv2term
1
0b(term)
a(bit-vector)
d
? c(term)bv2term
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 [7:0] a;input [7:0] b;wire [7:0] c;
add add(.in1(a), .in2(b), .out(c));
endmodule;
module add(in1, in2, out); //uninterpret... //interpret...... //interpretassign out = ...; //interpretendmodule;
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 Can’t 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