A methodology for the design of AHB bus master wrappers

1
A methodology for the design of AHB bus master
wrappers

• Marc Bertola, Guy Bois
• Euromicro Symposium on Digital System Design
• Presenter Yao-Jui Chang

2
Outline

• Whats the problem?
• Abstract
• Introduction
• The three steps of the methodology
• Protocol requirement
• Correspondences
• State machine
• Case study
• ARM7TDMI
• SYS32-TM
• Conclusion

3
Whats the problem?

• Bus protocols play a major role in the field of
  intellectual property reuse, so adapting our IP
  to a specific protocol quickly is become more and
  more important.

4
Abstract

• This paper proposes a methodology and a basic
  structure for the design of wrappers used to
  adapt cores for use as bus masters. The AMBA AHB
  protocol is used as a case study in this paper.
  The first step is to identify the
  responsibilities of the master. The designer
  must then develop correspondences between the
  behavior of the core and the requirements
  specified by the protocol. The final step is to
  build a state machine progressively, adding
  states to compensate for the core's inability to
  produce compliant behavior. An example of a
  wrapper for the ARM7TDMI is then presented.

5
Introduction

• Bus protocol plays an important role in the field
  of intellectual property reuse.
• The current approach is to design a core, and
  then adapt the interface to a specific protocol
  by using a wrapper.
• Several protocol currently enjoy a certain degree
  of popularity.
• IBMs CoreConnect
• Silicores Wishbone
• ARMs AMBA

6
The three steps of the methodology

• Protocol requirement
• Correspondences
• State machine

7
Step1 Protocol requirement (1/5)

• The AHB protocol specifies a certain behavior
  that must to be respected.
• Pipeline rule
• The master must perform pipelined accesses
• First comes an address phase during which the
  address and control signals are driven.
• At the end of this phase, the slave module
  selected by the address samples the address and
  control signals and begins its response during
  the data phase.
• Stretch rule
• Arbitration rule
• Lock rule
• Exception rule

8
Step1 Protocol requirement (2/5)

• The AHB protocol specifies a certain behavior
  that must to be respected.
• Pipeline rule
• Stretch rule
• The extensibility of length of the bus cycle.
• The slave can drive HREADY low to stretch the
  length of a bus cycle.
• The master must be able to stall its execution to
  respect the slaves request.
• Arbitration rule
• Lock rule
• Exception rule

9
Step1 Protocol requirement (3/5)

• The AHB protocol specifies a certain behavior
  that must to be respected.
• Pipeline rule
• Stretch rule
• Arbitration rule
• The AHB protocol also has provisions for several
  masters.
• Only one master can access the slaves at the
  given time.
• All of the other masters must respect this and
  wait until the bus is assigned to them.
• Lock rule
• Exception rule

10
Step1 Protocol requirement (4/5)

• The AHB protocol specifies a certain behavior
  that must to be respected.
• Pipeline rule
• Stretch rule
• Arbitration rule
• Lock rule
• The AHB protocol offers the possibility of
  performing locked access sequences, which are
  bursts of data that arbiter cant interrupt to
  grant the bus to another master.
• HLOCK must be asserted on the bus cycle that
  precedes the first address phase of the locked
  sequence, and to be de-asserted during the last
  address phase.
• Exception rule

11
Step1 Protocol requirement (5/5)

• The AHB protocol specifies a certain behavior
  that must to be respected.
• Pipeline rule
• Stretch rule
• Arbitration rule
• Lock rule
• Exception rule
• Every cycle, the master must observe the status
  of HRESP. If RETRY or SPLIT is given, the master
  must immediately drive the IDLE value on its
  HTRANS output.
• On the followed bus cycle, the master must retry
  the access that had cause the unusual response.

12
Step2 Correspondences(1/4)

• To establish correspondences between the cores
  actual behavior and the requirement of the
  protocol.
• Requirement An depth understanding of both the
  protocol and the cores timing diagrams.
• Goal Attempt to determine how it is possible to
  use the cores signals to obtain the same timing
  as specified in the protocol.
• Three categories of connections can be found.
• Direct correspondences
• Indirect correspondences
• No correspondences

13
Step2 Correspondences(2/4)

• Direct correspondences
• Implicate very little processing.
• AHB outputs or cores input can be obtain easily
  from other signals by renaming, inverting or
  stripping bits from them.
• Indirect correspondences
• No correspondences

14
Step2 Correspondences(3/4)

• Direct correspondences
• Indirect correspondences
• Signals are close to the required signals, but
  dont have exactly the same behavior as them.
• Adapting these requires more processing.
• Ex) delaying, modifying or interpreting the
  signals implicated.
• No correspondences

15
Step2 Correspondences(4/4)

• Direct correspondences
• Indirect correspondences
• No correspondences
• The semantics of the behavior are simply not
  implemented in the protocol or vice versa.
• Sometimes, the wrapper only has to drive a
  constant value, when there is no correspondences
  for a core input.

16
Step3 State machine(1/5)

• Set up an initial state that respects the
  pipeline rule.
• It is assumed here that the core that the wrapper
  is adapting can supply at least this
  functionality via direct correspondences.

17
Step3 State machine(2/5)

• Include the Stretch requirement.
• If no direct correspondence can cater to this
  rule, then the core must somehow be stalled
  during the extra clock cycle of the bus cycle.
• If the core has a static design, then it is
  possible to stall it by modulating the clock
  signal.

18
Step3 State machine(3/5)

• Implement the Arbitration.
• A master that loses the bus has a final bus cycle
  in which it can accomplish its data phase while
  another master prepares its address phase.

19
Step3 State machine(4/5)

• Implement the Lock
• If CORELOCK is asserted or de-asserted early, it
  is possible to remedy the situation by delaying
  it in the RUN state.
• If it is de-asserted late, the bus is locked for
  extra cycle. This doesnt cause any serious
  problems.
• The real problem is the situation where CORELOCK
  is asserted late (i.e. in the same time as the
  first address phase of the lock sequence). In
  this case the master must be delayed by one bus
  cycle in order to allow the arbiter of the bus to
  become aware of the change on HLOCK.

20
Step3 State machine(5/5)

• Observe the Exception rule.
• Core not designed with AHB in mind will rarely
  exhibit any correspondences that will allow them
  to handle the exceptions easily.

21
(No Transcript)
22
Case study ARM7TDMI vs SYS32-TM
Direct correspondences

• ARM7TDMI
• HCLK (Indirect correspondences)
• HBUSREQ ? nMREQ
• HADDR ? A
• HWRITE ? nRW
• HSIZE ? 1b0,MAS
• HPORT? 2b00,nTRANS,nOPC
• HWDATA ? DOUT
• HRDATA ? DIN
• HRESETn ? nRESET
• HLOCK (Indirect correspondences)

• SYS32-TM
• HCLK ? MCLK
• HBUSREQ (No correspondences)
• HADDR ? A
• HWRITE ? nRW
• HSIZE ? 1b0,MAS
• HPORT ? 2b00,nTRANS,nOPC
• HWDATA (Indirect correspondences)
• HRDATA ?
• HRESETn ?nRESET
• HLOCK ? LOCK

23
Case study ARM7TDMI vs SYS32-TM
Indirect correspondences

• SYS32-TM
• HLOCK (Direct correspondences)
• HLOCK ? LOCK
• HTANS
• Can be obtained from nMREQ and SEQ
• ABORT
• When HRESP ERROR
• then ABORThigh
• MCLK (Direct correspondences)
• MCLK ?HCLK
• nWAIT
• When (HGRANThigh and HREADY1)
• then nWAIThigh

• ARM7TDMI
• HLOCK
• Can be obtained from LOCK, but it is only
  asserted on the first address phase of the locked
  sequence
• HTRANS
• Can be obtained from nMREQ and SEQ
• ABORT
• Can be obtained by looking for HRESP01(ERROR)
• MCLK
• Can be obtained by using the inverse of HCLK. It
  can also be blocked (force high) by the various
  state machine
• nWAIT (No correspondences)
• No use

24
Case study ARM7TDMI vs SYS32-TM
No correspondences found

• SYS32-TM
• HBURST ? 3b001
• nWAIT (Indirect correspondences)
• HBUSREQ ? 1b0

• ARM7TDMI
• HBURST ? 3b001
• nWAIT
• No use because the wrapper modulates MCLK to
  control the progress of the master.
• HBUSREQ (Direct correspondences)

25
Conclusion

• This paper propose a methodology for the design
  of bus master wrapper.
• There may be other rules in the current protocol
  that may not yet been identified. Further efforts
  should be made to develop an exhaustive list of
  requirements that will ensure 100 AMBA
  compliance.

26
IBMs CoreConnect Bus
27
Comparison of IBM CoreConnect and ARM AMBA 2.0
Architectures.
28
Silicores WISHBONE Interconnect Bus