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 [3:0] a; //bit-vector input [3:0] b; output [3:0] 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, 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. Our focus: SPARC core • For now... 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 • 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.  x Data Abstraction • View data as symbolic words • Arbitrary integers, no assumptions on size or encoding x0 x1 x2 xn-1

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

21. ALU 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. F1 F2 Function Abstraction • Conservative approximation • Ignores detailed functionality Control Logic Data Path Com. Log. 1 Com. Log. 1

23. p 1 0 x 1 0 ITE(p, x, y) x x 1 0 1 0 y x y y y 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. M a M m0 a 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. M wa = wd 1 0 a M 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))

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 S’Impl S’spec Automatic Verification of Pipelined Microprocessor Control, Burch and Dill, CAV 1994

30. UCLID Front End Symbolic Simulator Back End VALID or COUNTER- EXAMPLE UCLID Specification Decision Procedure “Unrolls” model in BMC, Inductive Invariant Checking, and Correspondence Checking Deals with function applications, encodes terms/bit-vectors to CNF SAT Checker 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. alu_out := alu_fun(alu_cntl,aluA,aluB); alu_out := alu_fun(alu_cntl,aluA,aluB); Term-level (TERM) Bit-vector (BV-BASE) 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) 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(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. 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); 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); How do we represent “some_func”?

48. d d f a(bit-vector) a(bit-vector) 1 0 1 0 c(bit-vector) ? ? b(term) b(term) What if “b” is a different size than bit-vector “c” ? Type-Inference 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 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? • UCLID’s decision procedure figures out the smallest size for terms • Generate run-time warning

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