System Modeling and Verification with UCLID by Randal E. Bryant

1. System Modeling and Verification with UCLID Randal E. Bryant Carnegie Mellon University http://www.cs.cmu.edu/~bryant Contributions by former graduate students: Sanjit Seshia, Shuvendu Lahiri

2. Applying Data Abstraction to Hardware Verification • Idea • Abstract details of data encodings and operations • Keep control logic precise • Applications • Verify overall correctness of system • Assuming individual functional units correct • Technology • Use restricted subset of first-order logic • Implement efficient decision procedures • Multiple methods of performing verification

3. Challenge: System-Level Verification • Verification Task • Does processor implement its ISA? • Why is it Hard? • Lots of internal state • Complex control logic • Complex functionality Alpha 21264 Microprocessor Microprocessor Report, Oct. 28, 1996

4. Sources of Complexity • State • ISA: registers, memory • Microarchitectural: caches, buffers, reservation stations • Conceptually finite state, but practically unbounded • Control • Pipelines spread execution across multiple cycles • Out-of-order execution modifies processing order • Superscalar operation creates parallelism • Control logic coordinates everything • Resulting behavior matches that of sequential ISA model • Functionality • Arithmetic functions, instruction decoding

5. Existing Verification Methods • Simulators, equivalence checkers, model checkers, … • All Operate at Bit Level • RTL model • State encoded as words and arrays of words • Comprised of bits • Most Operate at Cycle or Subcycle Level • How each bit of state gets updated • System Modeling Languages • Abstract time up to transaction level • Still view state as collection of bits

6. Data Path Com. Log. 1 Com.Log. 2 Word-Level Abstraction Control Logic • Data: Abstract details of form & functions • Control: Keep at bit level • Timing: Keep at cycle level

7.  x Data Abstraction #1: Bits → Integers x0 • View Data as Symbolic Words • Arbitrary integers • No assumptions about size or encoding • Classic model for reasoning about software • Can store in memories & registers x1 x2 xn-1

8. p 1 0 x 1 0 ITE(p, x, y) x x 1 0 1 0 y x y y y Modeling Data Selection • If-Then-Else Operation • Mulitplexor • Allows control-dependent data flow

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

10. ALU Abstraction #2: Uninterpreted Functions • For any Block that Transforms or Evaluates Data: • Replace with generic, unspecified function • Only assumed property is functional consistency: a = x b = y f(a, b) = f(x, y) f

11. F1 F2 Abstracting Functions Control Logic • For Any Block that Transforms Data: • Replace by uninterpreted function • Ignore detailed functionality • Conservative approximation of actual system Data Path Com. Log. 1 Com. Log. 1

12. Modeling Data-Dependent Control Branch? Cond • Model by Uninterpreted Predicate • Yields arbitrary Boolean value for each control + data combination • Produces same result when arguments match • Pipeline & reference model will branch under same conditions Adata p Branch Logic Bdata

13. M a M m0 a Abstraction #3: Modeling Memories as Mutable Functions • Memory M Modeled as Function • M(a): Value at location a • Initially • Arbitrary state • Modeled by uninterpreted function m0

14. Writing Transforms Memory M = Write(M, wa, wd) Reading from updated memory: Address wa will get wd Otherwise get what’s already in M Express with Lambda Notation Notation for defining functions M = a . ITE(a = wa, wd, M(a)) M wa = wd a M 1 0 Effect of Memory Write Operation

15. Systems with Buffers Circular Queue Unbounded Buffer • Modeling Method • Mutable function to describe buffer contents • Integers to represent head & tail pointers

16. Some History of Term-Level Modeling • Historically • Standard model used for program verification • Widely used with theorem-proving approaches to hardware verification • E.g, Hunt ’85 • Automated Approaches to Hardware Verification • Burch & Dill, ’95 • Tool for verifying pipelined microprocessors • Implemented by form of symbolic simulation • Continued application to pipelined processor verification

17. UCLID • Seshia, Lahiri, Bryant, CAV ‘02 • Term-Level Verification System • Language for describing systems • Inspired by CMU SMV • Symbolic simulator • Generates integer expressions describing system state after sequence of steps • Decision procedure • Determines validity of formulas • Support for multiple verification techniques • Available by Download http://www.cs.cmu.edu/~uclid

18. Challenge: Model Generation • How to generate term-level model • How to guarantee faithfulness to RTL description • Comparison of Models • RTL • Abstracts functional elements from gate-level model • Synthesis allows automatic map to gate level • Term level • Abstracts bit-level data representations to words • Abstracts memories to mutable functions • No direct connection to synthesizable model

19. Generating Term-Level Model • Manually Generate from RTL • How do we know it is a valid abstraction? • Hard to keep consistent with changing RTL • Automatically Generate from RTL • Andraus & Sakallah, DAC ‘04 • Must decide which signals to keep Boolean, which to abstract • Confused by bit field extraction primitives of HDL • Synthesize RTL from Word-Level Model • Difficult to make efficient

20. Underlying Logic • Existing Approaches to Formal Verification • E.g., symbolic model checking • State encoded as fixed set of bits • Finite state system • Amenable to Boolean methods (SAT, BDDs) • Our Task • State encoded with unbounded data types • Arbitrary integers • Functions over integers • Must use decision procedures • Determine validity of formula in some subset of first-order logic • Adapt methods historically used by automated theorem provers

21. EUF: Equality with Uninterp. Functs • Decidable fragment of first order logic • Formulas (F ) Boolean Expressions F, F1F2, F1F2 Boolean connectives T1 = T2 Equation P (T1, …, Tk) Predicate application • Terms (T ) Integer Expressions ITE(F, T1, T2) If-then-else Fun (T1, …, Tk) Function application • Functions (Fun) Integer  Integer f Uninterpreted function symbol  x1, …, xk . T Function lambda expression • Predicates (P) Integer  Boolean p Uninterpreted predicate symbol

22. Symbolic Simulation UCLID Operation file.ucl UCLID Formula Model + Specification • Operation • Series of transformations leading to propositional formula • Except for lambda expansion, each has polynomial complexity Lambda Expansion -free Formula Function & Predicate Elimination Term Formula Finite Instantiation Boolean Formula Boolean Satisfiability

23. pc fd de mw em Branch Arg1 Target Arg2 RF Mem Value Instr Instr Arg2 Type Type Data Instr pPC PC PC Dest Type Valid Valid Valid Valid UCLID Example Boolean state Integer state • DLX Pipeline • Single-issue, 5-stage pipeline Function state Pipeline Write Back Fetch Decode Execute Memory

24. Write Back Decode fd de mw Arg1 src1 RF Arg2 Instr src2 Data Dest Valid Writing & Reading Register File

25. mw Data Dest Valid Writing Register File init[RF] := rf0; (* Uninterpreted Function *) next[RF] := Lambda(a) . case mw_Valid & (a = mw_Dest) : mw_Data; default : RF(a); esac; Write Back RF

26. fd de Arg1 Decode Arg2 Instr src1 RF src2 Reading Register File init[de_Arg1] := dea10; (* Initially arbitary *) next[de_Arg1] := next[RF](src1(fd_Instr)); init[de_Arg2] := dea20; (* Initially arbitary *) next[de_Arg2] := next[RF](src2(fd_Instr)); Write-before-read semantics

27. Present State Next State  Inputs (Arbitrary) Verifying Safety Properties • State Machine Model • State encoded as Booleans, integers, and functions • Next state function expresses how updated on each step • Prove: System will never reach bad state Bad States Reachable States Reset States Reset

28. Reachable Rn • • • Bounded Model Checking Bad States • Repeatedly Perform Image Computations • Set of all states reachable by one more state transition • Easy to Implement • Underapproximation of Reachable State Set • But, typically catch most bugs with 8–10 steps R2 R1 Reset States

29. Reach Fixed-Point Rn = Rn+1 = Reachable Impractical for Term-Level Models Many systems never reach fixed point Can keep adding elements to buffer Convergence test undecidable  Rn • • • True Model Checking Bad States R2 R1 Reset States

30.  I Inductive Invariant Checking Bad States • Key Properties of System that Make it Operate Correctly • Formulate as formula I • Prove Inductive • Holds initially I(s0) • Preserved by all state changes I(s)  I((i, s)) Reachable States Reset States

31. An Out-of-order Processor (OOO) valid tag val D E C O D E incr dispatch • Data Dependencies Resolved by Register Renaming • Map register ID to instruction in reorder buffer that will generate register value • Inorder Retirement Managed by Retirement Buffer • FIFO buffer keeping pending instructions in program order Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op result PC Register Rename Unit 1st Operand result bus retire 2nd Operand ALU execute Reorder Buffer head tail Reorder Buffer Fields

32. ISA Reg. File PC OOO Reg. File PC Reorder Buffer Verifying OOO • Lahiri, Seshia, & Bryant, FMCAD 2002 • Goal • Show that OOO implements Instruction Set Architecture (ISA) model • For all possible execution sequences • Challenge • OOO holds partially executed instructions in reorder buffer • States of two systems match only when reorder buffer flushed

33. ISA Reg. File PC Adding Shadow State • McMillan, ‘98 • Arons & Pnueli, ‘99 • Provides Link Between ISA & OOO Models • Additional entries in ROB • Do not affect OOO behavior • Generated when instruction dispatched • Predict values of operands and result • From ISA model OOO Reg. File PC Reorder Buffer

34. Invariant Checking • Formulas I1, …, In • Ij(s0) holds for any initial state s0, for 1 jn • I1(s)  I2(s)  … In(s)  Ij(s ) for any current state s and successor state s for 1 jn • Invariants for OOO (13) • Refinement maps (2) • Show relation between ISA and OOO models • Shadow state (3) • Shadow values correctly predict OOO values • State consistency (8) • Properties of OOO state that ensure proper operation • Overall Correctness • Follows by induction on time

35. OOO Invariants • Split into Formulas I1, …, In • Ij(s0) holds for any initial state s0, for 1 jn • I1(s)  I2(s)  … In(s)  Ij(s ) for any current state s and successor state s for 1 jn • Invariants for OOO (13) • Refinement maps (2) • Show relation between ISA and OOO models • State consistency (8) • Properties of OOO state that ensure proper operation • Added state (3) • Shadow values correctly predict OOO values • Overall Correctness • Follows by induction on time

36. State Consistency Invariant Examples • Register Renaming invariants (2) • Tag in a rename-unit should be in the ROB, and the destination register should match r.reg.valid(r) (rob.head  reg.tag(r) < rob.tail  rob.dest(reg.tag(r)) = r ) • For any entry, the destination should have reg.valid as false and tag should contain this or later instruction robt.(reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t)) < rob.tail)

37. Extending the OOO Processor • base • Executes ALU instructions only • exc • Handles arithmetic exceptions • Must flush reorder buffer • exc/br • Handles branches • Predicts branch & speculatively executes along path • exc/br/mem-simp • Adds load & store instructions • Store commits as instruction retires • exc/br/mem • Stores held in buffer • Can commit later • Loads must scan buffer for matching addresses

38. Comparative Verification Effort (Person time shown cumulatively)

39. “I Just Want a Loaf of Bread” Ingredients Result Recipe

40. Cooking with Invariants Ingredients: Predicates rob.head  reg.tag(r) Recipe: Invariants r,t.reg.valid(r)  reg.tag(r) = t  (rob.head  reg.tag(r) < rob.tail rob.dest(t) = r ) reg.valid(r) reg.tag(r) = t Result: Correctness rob.dest(t) = r

41. Automatic Recipe Generation Ingredients • Want Something More • Given any set of ingredients • Generate best recipe possible Result Recipe Creator

42. Automatic Predicate Abstraction • Graf & Saïdi, CAV ‘97 • Idea • Given set of predicates P1(s), …, Pk(s) • Boolean formulas describing properties of system state • View as abstraction mapping: States {0,1}k • Defines abstract FSM over state set {0,1}k • Form of abstract interpretation • Do reachability analysis similar to symbolic model checking • Implementation • Early ones had weak inference capabilities • Call theorem prover or decision procedure to test each potential transition • Recent ones make better use of symbolic encodings

43. P1(s), …, Pk(s) Abstraction Function  Concretization Function  s t s t Abstract State Space Abstraction Concretization Abstract States Abstract States Concrete States Concrete States

44. Abstract Transition Concretize  Abstract  Concrete Transition s s t t Abstract State Machine • Transitions in abstract system mirror those in concrete Abstract System Concrete System

45. A I Rn • • • R2 R1 Reset States Concretize  C Concrete System Reset States Generating Concrete Invariant • Reach Fixed-Point on Abstract System • Termination guaranteed, since finite state • Equivalent to Computing Invariant for Concrete System • Strongest possible invariant that can be expressed by formula over these predicates Abstract System

46. Systems Verified with Predicate Abstraction • Very general models • Unbounded processes, buffers, cache lines, … • Safety properties only

47. Automatic Predicate Discovery • Strength of Predicate Abstraction • If give it right set of predicates, PA will put them together into invariant • Weakness • Gets nowhere without right set of predicates • Typical failure mode: Generate “true” as invariant • Challenges • Too many predicates will overwhelm PA engine • Our use of quantified invariants precludes counterexample-generated refinement techniques

48. Implementation of Predicate Discovery Lahiri & Bryant, CAV ’04 • Initially: Extract predicates from verification condition • Iterate: Add new predicates by composing next-state formulas • With some heuristics thrown in • Experience • Can automatically generate invariants for real examples • ~10X slower than for hand-selected predicates

49. Future Prospects • Evaluation • Important to abstract data & data functions while maintaining details about control • Demonstrated ability to verify complex, parameterized systems • Model Generation is Weakest Link • Big jump from bit-level to term-level • Look at intermediate levels of abstraction with bit-vectors • Need algorithmic connection between our model and RTL • Predicate Abstraction Shows Promise • Provides key automation advantage of model checking