transaction based modeling and verification of hardware protocols
DESCRIPTION
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 . Hardware Protocols. Abstraction level. Specification. - PowerPoint PPT PresentationTRANSCRIPT
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