Transaction Based Modeling and Verification of Hardware Protocols

1
Transaction Based Modeling and Verification of
Hardware Protocols
Xiaofang Chen, Steven M. German and Ganesh
Gopalakrishnan
Supported in part by SRC Contract TJ1318 Also
supported thru an IBM Summer Internship
2
Hardware Protocols
Abstraction level
Specification
Cycle accurate RTL 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
Multiple steps in low-level
One step in high-level
home
remote
home
remote
router
buf
represents an atomic guarded/command.
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
Category 1 interface vars

l0
l1
l2
Impl



hn2
hn0
hn1
Spec
12
Our Definition of Refinement
Category 2 transactional vars

l0
l1
l2
Impl



hn2
hn0
hn1
Spec
13
Our Definition of Refinement
Category 3 non-observable vars

l0
l1
l2
Impl



hn2
hn0
hn1
Spec
14
Our Refinement Check
Guard for Spec transition must hold
Spec transition
Spec(I)
Spec(I)
Observable vars changed by either must match
Multi-step Impl transaction
I
I
I is a reachable Impl state
15
An Example of Refinement Check
Transaction Rule-1 guard1
action1 Rule-2 guard2
action2 Rule-3 guard3
action3 End
assert spec_guard spec_action
assert impl_var1 spec_var1
assert impl_var2 spec_var2
16
Additional Checks Needed for Refinement

• Write-write conflicts
• Serializability check

17
Workflow of Our Refinement Check
Murphi Spec model
Property check
Muv
Product model in Hardware Murphi
Product model in VHDL
Hardware Murphi Impl model
Check implementation meets specification
18
Driving Benchmark
Dir
Cache
Mem
Buf
Local
Buf
Home
Remote
Buf
Router
Dir
Cache
Mem
Local
Buf
Home
Buf
Remote
Buf
S. German and G. Janssen, IBM Research Tech
Report 2006
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

Monolithic
Product model in VHDL
Compositional
22
Compositional Refinement Check
Guard for Spec transition must hold
Spec transition
Spec(I)
Spec(I)
Observable vars changed by either must match
Multi-step Impl transaction
I
I
I is a reachable Impl state
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-day
Monolithic approach
Compositional approach
30 min
Datapath
1-bit
10-bit
Configuration Node 2, Addr 2
29
Related Work

• Bluespec
• Arvind et al.
• Aggregation of distributed actions
• Park and Dill
• Compositional verification
• Many previous works McMillan97, C. B.
  Jones83, 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
Thanks

• IBM SixthSense, RuleBase
• Cadence IFV

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