Highlevel Specification and Automatic Generation of IP Interface Monitors

1
High-level Specification and Automatic Generation
of IP Interface Monitors

• Marcio T. Oliveira Alan J. Hu
• Department of Computer Science
• University of British Columbia

2
Outline

• Interface Specification Why?
• Related Work
• Specification Style
• Translation into Monitor Circuits
• Conclusion

3
Interface Specification
Interface between Block and System
Block
Rest of System

• Standard design practice is block-based
• Interface
• negotiated face-to-face among designers
• written as an English document

4
Why Do We Need Formal Interface Specification
Methods?

• Higher complexity of designs
• Face-to-face negotiation does not scale well
• Extreme pressure for complex functionality and
  quick time-to-market
• Reuse pre-designed and pre-verified IP blocks
• Ambiguity and vagueness of natural language specs

5
What Is a Monitor?
Monitor
Error
Block
Rest of System

• Circuit that watches the interface between a
  block and the rest of the system
• Flags any violations of the interface protocol

6
Monitor Advantages

• Easier to design than an active stub to model the
  environment
• Precisely documents the interface
• Symmetric between the block and the restof the
  system, can be used with formal verification to
• Verify the block with the system abstracted
• Verify the system with the block abstracted
• Can be automatically converted into a testbench
  for simulation-based verification

7
Higher-Level Monitor Specification
High Level Spec
Automatic Translation
Monitor (VHDL, Verilog, )
8
(No Transcript)
9
ARM AMBA AHB Bus
Arbiter
Master 1
Slave 1
Master 2
Slave 2
Decoder

• Pipelined operation
• Multiple bus masters

• Split transactions

10
Regular Expressions

• Operators
• Choice a b
• Concatenation a, b
• Kleene Star a
• Example
• slave -gt (idle transfer)
• idle -gt (!HSEL) (HSEL !HREADY)
• transfer -gt idle_trans busy_trans
  nonseq_trans seq_trans

11
Primitive Expressions

• Boolean formulas on the interface wires
• !HTRANS0 !HTRANS1
• define statements
• define idle !HTRANS0 !HTRANS1
• define busy HTRANS0 !HTRANS1
• define nonseq !HTRANS0 HTRANS1
• define seq HTRANS0 HTRANS1

12
Productions

• error_resp -gt (!HREADY error) ,
• (HREADY error)
• error_resp is an abbreviation for theright-hand
  side
• Productions can not be recursive
• Specifications correspond tofinite-state
  machines
• Production Based SpecificationSeawright, Brewer
  1992

13
What Is Wrong With Regular Expressions?

• Persistent storage of information
• Pipelining

14
Persistent State

• Example 1 Slave can split any request from a
  master
• Slave must remember which masterswere split
• Example 2 In a write transfer the master must
  holdthe data stable during the extended cycles
• Encoding this information with regular
  expressions is possible, but painful

15
Storage Variables

• Finite-state variables
• Values can be assigned to variables
• Variables are available in any Boolean primitive
  expression
• split_resp -gt
  ((!HREADY split) ,
  (HREADY split)) m_splitmaster lt- 1
• unsplit -gt
  (HSPLITmaster m_splitmaster)
  m_splitmaster lt- 0

16
Pipelining

• Most high-performance interface protocols are
  pipelined to some degree
• AMBA AHB address phase and data phase

• Cycle-by-cycle spec is possible but error-prone
  and may result in an unreadable spec

17
Support for Pipelining

• Introduce new operator _at_ for pipelining

• Idle_trans -gt (idle HSEL HREADY) , okay_resp

Idle_trans -gt (idle HSEL HREADY) _at_ okay_resp
18
Semantics of Pipeline Operator

• (Addr , Data)

(Addr _at_ Data)
19
Specification Style Restrictions

• Expression contained within a Kleene star can not
  accept the empty string
• Ex (a b)
• Choice must be deterministic
• Ex (a (a , b)) is illegal
  (a (b, c)) is legal
• At most one thread at a time is allowed to
  execute in a pipeline stage
• Ex (a _at_ (b, c)) generates an error in the
  second cycle

20
Translation Into Monitor Circuits

• Find threads in the parse tree
• Ex ((a, b) _at_ (c, d))

21
Translation Into Monitor Circuits

• Translate each thread into circuits with outputs
• Activate signal tracks thread of execution
• Enable thread is enabled
• OK it is possible to match an inputprimitive
  expression
• Create the monitor circuit using thread outputs
• For each thread, if the thread is enabledthen it
  must be OK

22
Base Case
f
Let f be a primitive expression
23
Concatenation Operator

• X , Y

X
Y
24
Concatenation Operator

• X , Y

X
Y
25
Concatenation Operator

• X , Y

X
Y
26
Pipeline Operator

• X _at_ Y

X
Y
27
Results

• Specification of the ARM AMBA AHBbus master and
  slave, and versionsof the Sonics OCP
• E.g. AHB slave without split is 40 lines
• Tool that translates specifications into Verilog
  or VHDL monitor circuits
• E.g. AHB slave without split
• 2 seconds run-time (Pentium IV 1.4 GHz)
• 69 registers

28
Conclusion

• Novel, high-level specification stylefor
  interface monitors
• Efficient algorithm to translate intomonitor
  circuits
• Preliminary experiments are promising

29
Future Work

• Improve the translation tool
• Gain experience on additional real interface
  protocols
• Investigate if non-deterministic choice can be
  added
• Investigate different classes of storage variables