Automatic Abstraction of Microprocessors for Verification

1. Automatic Abstraction of Microprocessors for Verification Bryan Brady CS252

2. Processor Verification How to verify? Two options: Simulation Formal Verification OpenSPARC T1 Microarchitecture Specification, Sun Microsystems, Inc., 2006

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

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

6. Abstraction Experiment: Y86 • 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. 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”?

12. 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)

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. d a(bit-vector) 1 0 bv2term c(term) ? b(term) d a(bit-vector) 1 0 c(term) ? bv2term b(term) 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

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.  x Data Abstraction • View data as symbolic words • Arbitrary integers, no assumptions on size or encoding x0 x1 x2 xn-1

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

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

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

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