Transaction Based Modeling and Verification of Hardware Protocols

Xiaofang Chen, Steven M. German and Ganesh Gopalakrishnan

Supported in part by SRC Contract TJ1318Also supported thru an IBM Summer Internship

2

Cycle accurate RTL level

Hardware Protocols

Specification

Abstraction level

Model size

3

Problem Addressed

Specifications – Usually verifiable

– But do they correctly represent the implementations?

RTL implementations– Real designs usually too complex to be verified– Even if verifiable, does the impl meet the spec?

Our goal– Develop a practical approach to check refinement

4

Outline

Our approach of refinement check Compositional refinement check Experimental results and related work

5

Differences in Modeling: Specs vs. Impls

home remote

One step in high-level

Multiple steps in low-level

represents an atomic guarded/command.

home

router

buf

remote

6

Differences in Execution: Specs vs. Impls

Interleaving in HL

Concurrency in LL

7

Our Approach of Refinement

Modeling– Specification: Murphi

– Implementation: Hardware Murphi

Use transactions in Impl to relate to Spec Verification

– Muv: Hardware Murphi synthesizable VHDL

– Tool: IBM SixthSense

8

Hardware Murphi

Murphi extension by German and Janssen Concurrent guarded/commands with shared variables

– On each cycle• Multiple transitions execute concurrently• Exclusive write to a variable• Shared reads to variables• Write immediately visible within the same transition• Write visible to other transitions on the next cycle

Support transactions, signals, etc

9

What Are Transactions?

Group a multi-step execution in implementations

Spec

Impl

10

Tool: Muv Initially developed by German and Janssen Hardware Murphi synthesizable VHDL Other usages:

– Write verification drivers/checkers

– Prototype VHDL implementations

– Cycle-accurate modeling

11

Our Definition of Refinement

…l0

…hn0

l1 l2

hn1 hn2… …

Impl:

Spec:

Category 1: interface vars

12

Our Definition of Refinement

…l0

…hn0

l1 l2

hn1 hn2… …

Impl:

Spec:

Category 2: transactional vars

13

Our Definition of Refinement

…l0

…hn0

l1 l2

hn1 hn2… …

Impl:

Spec:

Category 3: non-observable vars

14

Our Refinement Check

Spec(I)

I

Spec(I’)Spec

transition

Multi-step Impl

transactionI’

Guard for Spec transition must

hold

I is a reachable Impl state

Observable vars changed

by either must match

15

An Example of Refinement Check

Transaction

Rule-1 guard1 action1; Rule-2

guard2 action2;

Rule-3 guard3 action3;

End;

assert impl_var1 = spec_var1;assert impl_var2 = spec_var2; …

assert spec_guard; spec_action;

16

Additional Checks Needed for Refinement

Write-write conflicts Serializability check

17

Workflow of Our Refinement Check

Hardware MurphiImpl model

Product model inHardware Murphi

Product model in VHDL

MurphiSpec model

Property check

Muv

Check implementation meets specification

18

Driving Benchmark

Buf

Buf

Buf Remote

Dir Cache Mem

Router

Buf

Buf

Buf

LocalHome

Remote

Dir Cache Mem

S. German and G. Janssen, IBM Research Tech Report 2006

LocalHome

19

Bugs Found with Refinement Check

Benchmark satisfies cache coherence already Bugs still found

– Bug 1: router unit loses messages

– Bug 2: home unit replies twice for one request

– Bug 3: cache unit gets updated twice from one reply

Refinement check is a convenient way of constructing checks

20

Outline

Our approach of refinement check Compositional refinement check Experimental results and related work

21

Model Checking Approaches

Monolithic– Product model + property check

Compositional– Divide and conquer

Product model in VHDL

Monolithic

Compositional

22

Compositional Refinement Check

Spec(I)

I

Spec(I’)Spec

transition

Multi-step Impl

transactionI’

Guard for Spec transition must

hold

I is a reachable Impl state

Observable vars changed

by either must match

23

Basic Techniques of Our Compositional Approach

Abstraction – Removing details to make verification easier

– A sound approach

Assume guarantee– A form of induction which introduces assumptions and

justifies them

24

Abstraction

Change variables to free input variables Add all transitions that write to a variable to the

submodel If a read of a variable is self-sourced, this read is

conservatively abstract

25

Assume Guarantee Reasoning

Assume reads of an observable variable v– Spec_v = Impl_v

Guarantee this for all writes to v

26

Additional Checks Needed for Abstraction & A/G

Write-write conflicts Serializability check Read-write dependencies between transactions

Currently performed on the monolithic model Only involve the control logic

27

Outline

Our approach of refinement check Compositional refinement check Experimental results and related work

28

Experiment Results with SixthSense

Verification Time

1-bit 10-bit

1-day

Datapath30 min

Monolithic approachCompositional approach

* Configuration: Node = 2, Addr = 2

29

Related Work

Bluespec– Arvind et al.

Aggregation of distributed actions – Park and Dill

Compositional verification– Many previous works: McMillan[97], C. B. Jones[83], etc.

30

Conclusion

Developed a formal theory of refinement Developed the monolithic refinement check Developed a compositional approach Obtained promising experimental results

31

Future Work

Simulation-based check– VHDL design + Hardware Murphi test cases

Planned Work– Mechanize assertion generation of refinement in muv– More case studies, eg. pipelining

32

IBM SixthSense, RuleBase Cadence IFV

Thanks

33

Questions?

34

Project Summary

This paper– Basic refinement theory and implementation

– Preliminary experiment results

More experiment results– A complete case study on a benchmark protocol– Bugs found– Verification time: over a day 30 min