and Formal Verification Carnegie Mellon University

Name: and Formal Verification Carnegie Mellon University
Uploaded: 2017-11-27T18:46:46+00:00
Duration: PTM30S34
Description: and Formal Verification Carnegie Mellon University

and Formal Verification Carnegie Mellon University
System Modeling and Formal Verification with UCLID Randal E. Bryant Carnegie Mellon University

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

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 Microprocessor Microprocessor Report, Oct. 28, 1996

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

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

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

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

Abstraction #2: Uninterpreted Functions
ALU f 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)

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

Modeling Data-Dependent Control
Branch? Cond Adata p Branch Logic Bdata 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

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

Effect of Memory Write Operation
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 M a 1 wd = wa

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

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 Real World Applications Recently used by Intel for microcode verification (CAV 2005)

UCLID Term-Level Verification System Available by Download
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

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

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

Generate Both from Common Model
Control Logic Description RTL Data Blocks .hcl UCLID Data Blocks hcl2v hcl2u merge merge Verilog description UCLID description Bryant, 2005 Separate data from control Generate control logic for both models from common source

Underlying Logic Existing Approaches to Formal Verification Our Task
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

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

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

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

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

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 mw Valid Dest Data RF

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)); fd Instr de Arg2 Arg1 RF Decode src1 src2 Write-before-read semantics

Verifying Safety Properties
 Present State Next Inputs (Arbitrary) Bad States Reachable States Reset States Reset 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

Bounded Model Checking
Reachable Bad States • • • Rn R2 R1 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 Reset States

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

Inductive Invariant Checking
 Bad States I Reachable States Reset 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))

An Out-of-order Processor (OOO)
valid tag val incr D E C O dispatch 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 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

Verifying OOO Goal Challenge Lahiri, Seshia, & Bryant, FMCAD 2002
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 ISA Reg. File PC OOO Reg. File PC Reorder Buffer

Adding Shadow State Provides Link Between ISA & OOO Models
Reg. File PC 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

Access Modes for Reorder Buffer
head tail Retire Dispatch result bus ALU execute Directly Addressable Select particular entry for execution Retrieve result value from executed instruction FIFO Insert when dispatch Remove when retire Content Addressable Broadcast result to all entries with matching source tag Global Flush all queue entries when instruction at head causes exception All handled by UCLID lambda notation

OOO Invariants Split into Formulas I1, …, In Invariants for OOO (13)
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

State Consistency Invariants
Register rename unit & reorder buffer encode same information redundantly Rename Unit: Registers  Tags Reorder Buffer: Tags  Registers Reorder Buffer Fields Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op Register Rename Unit valid tag val head tail dispatch

State Consistency Invariant Examples
valid value src1valid src1val src1tag src2valid src2val src2tag dest op valid tag val dispatch Register Renaming invariants (2) Any mapped register 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 ROB entry, the destination should have reg.valid as false and tag should be to this or later instruction robt.[reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t))  reg.tag(rob.dest(t)) < rob.tail]

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

Comparative Verification Effort
Decision Procedures UCLID: Complete reduction to SAT Barcelona DPLL(T): Iterative refinement to SAT base exc exc / br exc / br / mem-simp exc / br / mem Total Invariants 13 34 39 67 71 UCLID time 54 s 236 s 403 s 1594 s 2200 s DPLL(T) time 1 s 4 s 7 s 85 s Person time 2 days 7 days 9 days 24 days 34 days

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

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

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

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

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

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

Generating Concrete Invariant
• • • Rn R2 R1 Reset States A 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 Concretize  Concrete System I Reset States C

Quantified Invariant Generation
(Lahiri & Bryant, VMCAI 2004) User supplies predicates containing free variables Generate globally quantified invariant Example Predicates p1: reg.valid(r) p2: reg.tag(r) = t p3: rob.dest(t) = r Abstract state satisfying (p1  p2  p3) corresponds to concrete state satisfying r,t[reg.valid(r)  reg.tag(r) = t  rob.dest(t) = r] rather than r[reg.valid(r)]  r,t[reg.tag(r) = t]  r,t[rob.dest(t) = r]

Systems Verified with Predicate Abstraction
Model Predicates Iterations UCLID Time DPLL(T) Time Out-Of-Order Execution Unit 25 9 921s 36s German’s Cache Protocol 16 34s 1s German’s Protocol, unbounded channels 26 17 1,119s 23s Lamport’s Bakery Algorithm 32 18 245s 11s Safety properties only

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

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

Future Prospects Evaluation Model Generation is Weakest Link
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

and Formal Verification Carnegie Mellon University

Similar presentations

Presentation on theme: "and Formal Verification Carnegie Mellon University"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

and Formal Verification Carnegie Mellon University

Similar presentations

Presentation on theme: "and Formal Verification Carnegie Mellon University"— Presentation transcript:

Similar presentations

About project

Feedback