Automatic Abstraction of Microprocessors for Verification Bryan Brady CS252

Processor Verification How to verify? Two options: Simulation Formal Verification simulation: advantages: can test actual design, no verification model needed disadvantages: misses corner cases, takes too long to fully test formal verification: advantages: can mathematically prove correctness, implicitly tests all inputs disadvantages: requires a separate verification model, computationally hard example: pentium FDIV. certain inputs result in inaccurate results for fdiv. 1.14*10^-10 of input space. missing entry in lookup table OpenSPARC T1 Microarchitecture Specification, Sun Microsystems, Inc., 2006

Bridge the Gap Two extremes: Manually Automatically Tedious, error prone process Time consuming Automatically Abstract away everything Model precisely, abstract nothing Somewhere in between HDL Verification Model

Goals Remove the burden of creating a verification model Develop a scalable approach to large scale processor verification Not limited to processors

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 Old Impl State Flush, Project 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

Abstraction Experiment: 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

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

Abstraction Experiment: Y86

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

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

Type-Qualifiers How do we represent “some_func”? 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”?

Type-Inference b(term) a(bit-vector) d ? 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; input [7:0] a; //bit-vector input [7:0] b; wire [7:0] c; wire d; assign c = d ? a : b; //interpret 1 b(term) a(bit-vector) d ? 1 b(term) a(bit-vector) d ? c(bit-vector) f c(bit-vector) What if “b” is a different size than bit-vector “c” ?

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

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

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

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

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)

Questions/Comments

Abstraction Experiment: Y86

Modeling with Abstraction Abstract details of data encodings and operations Keep control logic precise Assume functional units are correct, verify overall correctness

Data Abstraction  View data as symbolic words Arbitrary integers, no assumptions on size or encoding x0 x1 x  x2 xn-1

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

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) conservative approximation, ignores detailed functionality ALU f

Data Selection If-then-else operator Its a multiplexor Allows control-dependent data flow 1 x y p ITE(p, x, y)

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

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 M a M a m0