slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Carnegie Mellon University PowerPoint Presentation
Download Presentation
Carnegie Mellon University

Loading in 2 Seconds...

play fullscreen
1 / 49

Carnegie Mellon University - PowerPoint PPT Presentation


  • 133 Views
  • Uploaded on

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. Applying Data Abstraction to Hardware Verification. Idea

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Carnegie Mellon University' - horace


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

applying data abstraction to hardware verification
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
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

sources of complexity
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
existing verification methods
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

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
data abstraction 1 bits integers

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

modeling data selection

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
abstracting data bits

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

abstraction 2 uninterpreted functions

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

abstracting functions

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

modeling data dependent control
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

abstraction 3 modeling memories as mutable functions

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

wa

=

wd

a

M

1

0

Effect of Memory Write Operation
systems with buffers
Systems with Buffers

Circular Queue

Unbounded Buffer

  • Modeling Method
    • Mutable function to describe buffer contents
    • Integers to represent head & tail pointers
some history of term level modeling
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
uclid
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

challenge model generation
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
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
underlying logic
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
euf equality with uninterp functs
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

uclid operation

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

uclid example

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

writing reading register file

Write

Back

Decode

fd

de

mw

Arg1

src1

RF

Arg2

Instr

src2

Data

Dest

Valid

Writing & Reading Register File
writing register file

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

reading register file

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

verifying safety properties

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

bounded model checking

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

true model checking
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

inductive invariant checking

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

an out of order processor ooo
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

verifying ooo

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
adding shadow state

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

invariant checking
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
ooo invariants
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
state consistency invariant examples
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)

extending the ooo processor
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
Comparative Verification Effort

(Person time shown cumulatively)

i just want a loaf of bread
“I Just Want a Loaf of Bread”

Ingredients

Result

Recipe

cooking with invariants
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
Automatic Recipe Generation

Ingredients

  • Want Something More
    • Given any set of ingredients
    • Generate best recipe possible

Result

Recipe Creator

automatic predicate abstraction
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

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

abstract state machine

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

generating concrete invariant

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

systems verified with predicate abstraction
Systems Verified with Predicate Abstraction
  • Very general models
    • Unbounded processes, buffers, cache lines, …
  • Safety properties only
automatic predicate discovery
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
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
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