1 / 57

Selective Term-Level Abstraction with Type-Inference

Selective Term-Level Abstraction with Type-Inference. Bryan Brady Advisor: Sanjit Seshia In collaboration with: Randy Bryant, Daniel Kroening, Joel Ouaknine, Ofer Strichman. Processor Verification. How to verify? Two options: Simulation Formal Verification.

psyche
Download Presentation

Selective Term-Level Abstraction with Type-Inference

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related