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: 1.Simulation 2.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 * Cause: Missing entries in the lookup table used in the hardware divide algorithm Statistical Analysis of Floating Point Flaw, Intel White Paper, CS , 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 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 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 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 VerilogUCLID input [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 x0x0 x1x1 x2x2 x n-1 x 

20 Data Abstraction Data Path Com. Log. 1 Com. Log. 2 Control Logic Data 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 ALUALU f a = x  b = y  f (a, b) = f (x, y)

22 Function Abstraction Conservative approximation Ignores detailed functionality Data Path Control Logic Com. Log. 1 Com. Log. 1 F1F1 F2F2

23 Data Selection If-then-else operator Its a multiplexor Allows control-dependent data flow 1010 x y p ITE(p, x, y) 1010 x y 1 x 1010 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? Branch Logic p

25 Memory M modeled as a function M(a): Value in memory location a Initially Arbitrary state Modeled by uninterpreted function m 0 Memories as Mutable Functions M a M a m0m0

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 M a 1010 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 Old Impl State New Impl State Old Spec State New Spec State Flush, Project Execute 1 cycle S Impl S’ Impl S spec 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 state before and after the spec and implementation execute PC, RF, MEM

30 UCLID Front End Symbolic Simulator Decision Procedure Back End UCLID SAT Checker UCLID Specification VALID or 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: ALU alu_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-Qualifiers 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”?

48 Type-Inference 1010 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; 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 1010 b(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 1010 b(term) a(bit-vector) d ? c(bit-vector) term2bv 1010 b(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 1010 b(term) a(bit-vector) d ? c(term) bv2term 1010 b(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 //interpret assign out =...; //interpret endmodule;

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