程序代写代做代考 ER algorithm arm cache flex scheme AMBATM Specification (Rev 2.0)

AMBATM Specification (Rev 2.0)
ARM IHI 0011A

AMBA Specification (Rev 2.0)
© Copyright ARM Limited 1999. All rights reserved.
Release information
Date Issue Change
13th May 1999 A First release
Proprietary notice
Change history
ARM, the ARM Powered logo, Thumb and StrongARM are registered trademarks of ARM Limited.
The ARM logo, AMBA, PrimeCell, Angel, ARMulator, EmbeddedICE, ModelGen, Multi-ICE, ARM7TDMI, ARM7TDMI-S, ARM9TDMI, TDMI and STRONG are trademarks of ARM Limited.
All other products or services mentioned herein may be trademarks of their respective owners.
Neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder.
The product described in this document is subject to continuous developments and improvements. All particulars of the product and its use contained in this document are given by ARM Limited in good faith. However, all warranties implied or expressed, including but not limited to implied warranties or merchantability, or fitness for purpose, are excluded.
This document is intended only to assist the reader in the use of the product. ARM Limited shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product.
Document confidentiality status
This document is Open Access. This document has no restriction on distribution.
Product status
The information in this document is Final (information on a developed product).
ARM web address
http://www.arm.com
ii
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

Preface
This preface introduces the Advanced Microcontroller Bus Architecture (AMBA) specification. It contains the following sections:
• •
About this document on page iv Feedback on page vii.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. iii

About this document
Intended audience
Organization
This document is the AMBA specification.
This document has been written to help experienced hardware and software engineers to design modules that conform to the AMBA specification.
This document is organized into the following chapters:
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Introduction to the AMBA Buses
Read this chapter for an overview of the AMBA buses.
AMBA Signals
Read this chapter for a description of the signals used by AMBA devices.
AMBA AHB
Read this chapter for an introduction to the AMBA Advanced High- performance Bus.
AMBA ASB
Read this chapter for an introduction to the AMBA Advanced System Bus.
AMBA APB
Read this chapter for an introduction to the AMBA Advanced Peripheral Bus.
AMBA Test Methodology
Read this chapter for an introduction to the test methodology used in AMBA buses.
iv
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Typographical conventions
The following typographical conventions are used in this document:
bold
italic
typewriter
typewriter
Highlights ARM processor signal names within text, and interface elements such as menu names. May also be used for emphasis in descriptive lists where appropriate.
Highlights special terminology, cross-references and citations.
Denotes text that may be entered at the keyboard, such as commands, file names and program names, and source code.
Denotes a permitted abbreviation for a command or option. The underlined text may be entered instead of the full command or option name.
typewriter italic
typewriter bold
Denotes arguments to commands or functions where the argument is to be replaced by a specific value.
Denotes language keywords when used outside example code.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. v

Timing diagram conventions
This manual contains one or more timing diagrams. The following key explains the components used in these diagrams. Any variations are clearly labelled when they occur. Therefore, no additional meaning should be attached unless specifically stated.
Clock HIGH to LOW Transient HIGH/LOW to HIGH Bus stable Bus to high impedance
Bus change High impedance to stable bus
Key to timing diagram conventions
Shaded bus and signal areas are undefined, so the bus or signal can assume any value within the shaded area at that time. The actual level is unimportant and does not affect normal operation.
vi
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Feedback
ARM Limited welcomes feedback both on AMBA and the AMBA specification.
Feedback on this document
If you have any comments on this document, please send email to errata@arm.com giving:
• the document title
• the document number
• the page number(s) to which your comments refer
• a concise explanation of your comments.
General suggestions for additions and improvements are also welcome.
Feedback on the AMBA Specification
If you have any comments or suggestions about this product, please contact your supplier giving:
• •
the product name
a concise explanation of your comments.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. vii

Contents
AMBA Specification
Chapter 1
Preface
About this document …………………………………………………………………………………………iv Feedback ……………………………………………………………………………………………………….vii
Introduction to the AMBA Buses
1.1 Overview of the AMBA specification ……………………………………………………. 1-2
1.2 Objectives of the AMBA specification ………………………………………………….. 1-3
1.3 A typical AMBA-based microcontroller …………………………………………………. 1-4
1.4 T erminology …………………………………………………………………………………….. 1-6
1.5 Introducing the AMBA AHB………………………………………………………………… 1-7
1.6 Introducing the AMBA ASB ………………………………………………………………… 1-9
1.7 Introducing the AMBA APB ………………………………………………………………. 1-10
1.8 Choosing the right bus for your system………………………………………………. 1-12
1.9 Notes on the AMBA specification………………………………………………………. 1-14
AMBA Signals
2.1 AMBA signal names………………………………………………………………………….. 2-2
2.2 AMBA AHB signal list………………………………………………………………………… 2-3
2.3 AMBA ASB signal list ………………………………………………………………………… 2-6
2.4 AMBA APB signal list ………………………………………………………………………… 2-8
Chapter 2
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. ix

Chapter 3
AMBA AHB
3.1 About the AMBA AHB……………………………………………………………………….. 3-3
3.2 Bus interconnection ………………………………………………………………………….. 3-4
3.3 Overview of AMBA AHB operation ……………………………………………………… 3-5
3.4 Basic transfer…………………………………………………………………………………… 3-6
3.5 Transfer type …………………………………………………………………………………… 3-9
3.6 Burst operation ………………………………………………………………………………. 3-11
3.7 Control signals ……………………………………………………………………………….. 3-17
3.8 Address decoding …………………………………………………………………………… 3-19
3.9 Slave transfer responses …………………………………………………………………. 3-20
3.10 Data buses ……………………………………………………………………………………. 3-25
3.11 Arbitration ……………………………………………………………………………………… 3-28
3.12 Split transfers…………………………………………………………………………………. 3-35
3.13 Reset ……………………………………………………………………………………………. 3-40
3.14 About the AHB data bus width………………………………………………………….. 3-41
3.15 Implementing a narrow slave on a wider bus ……………………………………… 3-42
3.16 Implementing a wide slave on a narrow bus ………………………………………. 3-43
3.17 About the AHB AMBA components …………………………………………………… 3-44
3.18 AHB bus slave ……………………………………………………………………………….. 3-45
3.19 AHB bus master …………………………………………………………………………….. 3-49
3.20 AHB arbiter ……………………………………………………………………………………. 3-53
3.21 AHB decoder …………………………………………………………………………………. 3-57
AMBA ASB
4.1 About the AMBA ASB ……………………………………………………………………….. 4-2
4.2 AMBA ASB description ……………………………………………………………………… 4-4
4.3 ASB transfers ………………………………………………………………………………….. 4-6
4.4 Address decode……………………………………………………………………………… 4-14
4.5 Transfer response ………………………………………………………………………….. 4-16
4.6 Multi-master operation …………………………………………………………………….. 4-19
4.7 Reset operation ……………………………………………………………………………… 4-23
4.8 Description of ASB signals ………………………………………………………………. 4-25
4.9 About the ASB AMBA components …………………………………………………… 4-46
4.10 ASB bus slave ……………………………………………………………………………….. 4-47
4.11 ASB bus master……………………………………………………………………………… 4-52
4.12 ASB decoder …………………………………………………………………………………. 4-63
4.13 ASB arbiter ……………………………………………………………………………………. 4-71
AMBA APB
Chapter 4
Chapter 5
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8
About the AMBA APB ……………………………………………………………………….. 5-2 APB specification……………………………………………………………………………… 5-4 About the APB AMBA components …………………………………………………….. 5-7 APB bridge ……………………………………………………………………………………… 5-8 APB slave ……………………………………………………………………………………… 5-11 Interfacing APB to AHB …………………………………………………………………… 5-14 Interfacing APB to ASB …………………………………………………………………… 5-20 Interfacing rev D APB peripherals to rev 2.0 APB ……………………………….. 5-22
x
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Chapter 6
AMBA Test Methodology
6.1 About the AMBA test interface ……………………………………………………………. 6-2
6.2 External interface ……………………………………………………………………………… 6-4
6.3 Test vector types………………………………………………………………………………. 6-6
6.4 T est interface controller …………………………………………………………………….. 6-7
6.5 The AHB Test Interface Controller …………………………………………………….. 6-12
6.6 Example AMBA AHB test sequences ………………………………………………… 6-17
6.7 The ASB test interface controller ………………………………………………………. 6-25
6.8 Example AMBA ASB test sequences…………………………………………………. 6-27
Index
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. xi

Chapter 1
Introduction to the AMBA Buses
This chapter introduces the Advanced Microcontroller Bus Architecture (AMBA) specification. The following sections are included:
• Overview of the AMBA specification on page 1-2
• Objectives of the AMBA specification on page 1-3
• A typical AMBA-based microcontroller on page 1-4
• Terminology on page 1-6
• Introducing the AMBA AHB on page 1-7
• Introducing the AMBA ASB on page 1-9
• Introducing the AMBA APB on page 1-10
• Choosing the right bus for your system on page 1-12
• Notes on the AMBA specification on page 1-14.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-1

Introduction to the AMBA Buses
1.1
Overview of the AMBA specification
The Advanced Microcontroller Bus Architecture (AMBA) specification defines an on- chip communications standard for designing high-performance embedded microcontrollers.
Three distinct buses are defined within the AMBA specification:
• the Advanced High-performance Bus (AHB)
• the Advanced System Bus (ASB)
• the Advanced Peripheral Bus (APB).
A test methodology is included with the AMBA specification which provides an infrastructure for modular macrocell test and diagnostic access.
Advanced High-performance Bus (AHB)
The AMBA AHB is for high-performance, high clock frequency system modules.
The AHB acts as the high-performance system backbone bus. AHB supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces with low-power peripheral macrocell functions. AHB is also specified to ensure ease of use in an efficient design flow using synthesis and automated test techniques.
Advanced System Bus (ASB)
The AMBA ASB is for high-performance system modules.
AMBA ASB is an alternative system bus suitable for use where the high-performance features of AHB are not required. ASB also supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces with low-power peripheral macrocell functions.
Advanced Peripheral Bus (APB)
The AMBA APB is for low-power peripherals.
AMBA APB is optimized for minimal power consumption and reduced interface complexity to support peripheral functions. APB can be used in conjunction with either version of the system bus.
1.1.1
1.1.2
1.1.3
1-2
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

1.2 Objectives of the AMBA specification
The AMBA specification has been derived to satisfy four key requirements:
• to facilitate the right-first-time development of embedded microcontroller products with one or more CPUs or signal processors
• to be technology-independent and ensure that highly reusable peripheral and system macrocells can be migrated across a diverse range of IC processes and be appropriate for full-custom, standard cell and gate array technologies
• to encourage modular system design to improve processor independence, providing a development road-map for advanced cached CPU cores and the development of peripheral libraries
• to minimize the silicon infrastructure required to support efficient on-chip and off-chip communication for both operation and manufacturing test.
Introduction to the AMBA Buses
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-3

Introduction to the AMBA Buses
1.3
A typical AMBA-based microcontroller
An AMBA-based microcontroller typically consists of a high-performance system backbone bus (AMBA AHB or AMBA ASB), able to sustain the external memory bandwidth, on which the CPU, on-chip memory and other Direct Memory Access (DMA) devices reside. This bus provides a high-bandwidth interface between the elements that are involved in the majority of transfers. Also located on the high- performance bus is a bridge to the lower bandwidth APB, where most of the peripheral devices in the system are located (see Figure 1-1).
High-performance ARM processor
High-bandwidth on-chip RAM
B R I D G E
UART
Timer
High-bandwidth External Memory Interface
AHB or ASB
APB
Keypad
PIO
AMBA AHB
* High performance
* Pipelined operation * Multiple bus masters * Burst transfers
* Split transactions
AMBA ASB
* High performance
* Pipelined operation * Multiple bus masters
AHB to APB Bridge or
ASB to APB Bridge
AMBA APB
* Low power
* Latched address and control * Simple interface
* Suitable for many peripherals
DMA bus master
Figure 1-1 A typical AMBA system
AMBA APB provides the basic peripheral macrocell communications infrastructure as a secondary bus from the higher bandwidth pipelined main system bus. Such peripherals typically:
• • •
have interfaces which are memory-mapped registers have no high-bandwidth interfaces
are accessed under programmed control.
1-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The external memory interface is application-specific and may only have a narrow data path, but may also support a test access mode which allows the internal AMBA AHB, ASB and APB modules to be tested in isolation with system-independent test sets.
Introduction to the AMBA Buses
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 1-5

Introduction to the AMBA Buses
1.4 Terminology
The following terms are used throughout this specification.
Bus cycle
Bus transfer
A bus cycle is a basic unit of one bus clock period and for the purpose of AMBA AHB or APB protocol descriptions is defined from rising-edge to rising-edge transitions. An ASB bus cycle is defined from falling-edge to falling-edge transitions. Bus signal timing is referenced to the bus cycle clock.
An AMBA ASB or AHB bus transfer is a read or write operation of a data object, which may take one or more bus cycles. The bus transfer is terminated by a completion response from the addressed slave.
The transfer sizes supported by AMBA ASB include byte (8-bit), halfword (16-bit) and word (32-bit). AMBA AHB additionally supports wider data transfers, including 64-bit and 128-bit transfers. An AMBA APB bus transfer is a read or write operation of a data object, which always requires two bus cycles.
A burst operation is defined as one or more data transactions, initiated by a bus master, which have a consistent width of transaction to an incremental region of address space. The increment step per transaction is determined by the width of transfer (byte, halfword, word). No burst operation is supported on the APB.
Burst operation
1-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

1.5 Introducing the AMBA AHB
AHB is a new generation of AMBA bus which is intended to address the requirements of high-performance synthesizable designs. It is a high-performance system bus that supports multiple bus masters and provides high-bandwidth operation.
AMBA AHB implements the features required for high-performance, high clock frequency systems including:
• burst transfers
• split transactions
• single-cycle bus master handover
• single-clock edge operation
• non-tristate implementation
• wider data bus configurations (64/128 bits).
Bridging between this higher level of bus and the current ASB/APB can be done efficiently to ensure that any existing designs can be easily integrated.
An AMBA AHB design may contain one or more bus masters, typically a system would contain at least the processor and test interface. However, it would also be common for a Direct Memory Access (DMA) or Digital Signal Processor (DSP) to be included as bus masters.
The external memory interface, APB bridge and any internal memory are the most common AHB slaves. Any other peripheral in the system could also be included as an AHB slave. However, low-bandwidth peripherals typically reside on the APB.
A typical AMBA AHB system design contains the following components:
AHB master
AHB slave
AHB arbiter
A bus master is able to initiate read and write operations by providing an address and control information. Only one bus master is allowed to actively use the bus at any one time.
A bus slave responds to a read or write operation within a given address-space range. The bus slave signals back to the active master the success, failure or waiting of the data transfer.
The bus arbiter ensures that only one bus master at a time is allowed to initiate data transfers. Even though the arbitration protocol is fixed, any arbitration algorithm, such as highest priority or fair access can be implemented depending on the application requirements.
An AHB would include only one arbiter, although this would be trivial in single bus master systems.
Introduction to the AMBA Buses
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-7

Introduction to the AMBA Buses
AHB decoder
The AHB decoder is used to decode the address of each transfer and provide a select signal for the slave that is involved in the transfer.
A single centralized decoder is required in all AHB implementations.
1-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

1.6 Introducing the AMBA ASB
ASB is the first generation of AMBA system bus. ASB sits above the current APB and implements the features required for high-performance systems including:
• burst transfers
• pipelined transfer operation
• multiple bus master.
A typical AMBA ASB system may contain one or more bus masters. For example, at least the processor and test interface. However, it would also be common for a Direct Memory Access (DMA) or Digital Signal Processor (DSP) to be included as bus masters.
The external memory interface, APB bridge and any internal memory are the most common ASB slaves. Any other peripheral in the system could also be included as an ASB slave. However, low-bandwidth peripherals typically reside on the APB.
An AMBA ASB system design typically contains the following components:
ASB master
ASB slave
ASB decoder
ASB arbiter
A bus master is able to initiate read and write operations by providing an address and control information. Only one bus master is allowed to actively use the bus at any one time.
A bus slave responds to a read or write operation within a given address-space range. The bus slave signals back to the active master the success, failure or waiting of the data transfer.
The bus decoder performs the decoding of the transfer addresses and selects slaves appropriately. The bus decoder also ensures that the bus remains operational when no bus transfers are required.
A single centralized decoder is required in all ASB implementations.
The bus arbiter ensures that only one bus master at a time is allowed to initiate data transfers. Even though the arbitration protocol is fixed, any arbitration algorithm, such as highest priority or fair access can be implemented depending on the application requirements.
An ASB would include only one arbiter, although this would be trivial in single bus master systems.
Introduction to the AMBA Buses
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-9

Introduction to the AMBA Buses
1.7
Introducing the AMBA APB
The APB is part of the AMBA hierarchy of buses and is optimized for minimal power consumption and reduced interface complexity.
The AMBA APB appears as a local secondary bus that is encapsulated as a single AHB or ASB slave device. APB provides a low-power extension to the system bus which builds on AHB or ASB signals directly.
The APB bridge appears as a slave module which handles the bus handshake and control signal retiming on behalf of the local peripheral bus. By defining the APB interface from the starting point of the system bus, the benefits of the system diagnostics and test methodology can be exploited.
The AMBA APB should be used to interface to any peripherals which are low bandwidth and do not require the high performance of a pipelined bus interface.
The latest revision of the APB is specified so that all signal transitions are only related to the rising edge of the clock. This improvement ensures the APB peripherals can be integrated easily into any design flow, with the following advantages:
• high-frequency operation easier to achieve
• performance is independent of the mark-space ratio of the clock
• static timing analysis is simplified by the use of a single clock edge
• no special considerations are required for automatic test insertion
• many Application Specific Integrated Circuit (ASIC) libraries have a better selection of rising edge registers
• easy integration with cycle-based simulators.
These changes to the APB also make it simpler to interface it to the new AHB.
An AMBA APB implementation typically contains a single APB bridge which is required to convert AHB or ASB transfers into a suitable format for the slave devices on the APB. The bridge provides latching of all address, data and control signals, as well as providing a second level of decoding to generate slave select signals for the APB peripherals.
All other modules on the APB are APB slaves. The APB slaves have the following interface specification:
• address and control valid throughout the access (unpipelined)
1-10
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

• zero-power interface during non-peripheral bus activity (peripheral bus is static when not in use)
• timing can be provided by decode with strobe timing (unclocked interface)
• write data valid for the whole access (allowing glitch-free transparent latch implementations).
Introduction to the AMBA Buses
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-11

Introduction to the AMBA Buses
1.8
1.8.1
Choosing the right bus for your system
Before deciding on which bus or buses you should use in your system, you should consider the following:
• Choice of system bus
• System bus and peripheral bus
• When to use AMBA AHB/ASB or APB on page 1-13
Choice of system bus
Both AMBA AHB and ASB are available for use as the main system bus. Typically the choice of system bus will depend on the interface provided by the system modules required.
The AHB is recommended for all new designs, not only because it provides a higher- bandwidth solution, but also because the single-clock-edge protocol results in a smoother integration with design automation tools used during a typical ASIC development.
System bus and peripheral bus
Building all peripherals as fully functional AHB or ASB modules is feasible but may not always be desirable:
1.8.2
•
•
•
•
In designs with a large number of peripheral macrocells the increased bus loading may increase power dissipation and sacrifice performance.
Where timing analysis is required, the slowest element on the bus will limit the maximum performance.
Many simple peripheral macrocells need latched addresses and control signals as opposed to the high-bandwidth macrocells which benefit from pipelined signalling.
Many peripheral functions simply require a selection strobe which conveys macrocell selection and read/write bus operation, without the requirement to broadcast the high-frequency clock signal to every peripheral.
1-12
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

1.8.3 When to use AMBA AHB/ASB or APB
A full AHB or ASB interface is used for:
• bus masters
• on-chip memory blocks
• external memory interfaces
• high-bandwidth peripherals with FIFO interfaces
• DMA slave peripherals.
A simple APB interface is recommended for:
• simple register-mapped slave devices
• very low power interfaces where clocks cannot be globally routed
• grouping narrow-bus peripherals to avoid loading the system bus.
Introduction to the AMBA Buses
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 1-13

Introduction to the AMBA Buses
1.9
1.9.1
1.9.2
1.9.3
Notes on the AMBA specification
The following points should be considered when reading the AMBA specification:
• Technology independence
• Electrical characteristics
• Timing specification.
Technology independence
AMBA is a technology-independent on-chip protocol. The specification only details the bus protocol at the clock cycle level.
Electrical characteristics
No information regarding the electrical characteristics is supplied within the AMBA specification as this will be entirely dependent on the manufacturing process technology that is selected for the design.
Timing specification
The AMBA protocol defines the behavior of various signals at the cycle level. The exact timing requirements will depend on the process technology used and the frequency of operation.
Because the exact timing requirements are not defined by the AMBA protocol, the system integrator is given maximum flexibility in allocating the signal timing budget amongst the various modules on the bus.
1-14
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Chapter 2
AMBA Signals
This chapter introduces the AMBA signals. It contains the following sections:
• AMBA signal names on page 2-2
• AMBA AHB signal list on page 2-3
• AMBA ASB signal list on page 2-6
• AMBA APB signal list on page 2-8.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 2-1

AMBA Signals
2.1
AMBA signal names
All AMBA signals are named such that the first letter of the name indicates which bus the signal is associated with. A lower case n in the signal name indicates that the signal is active LOW, otherwise signal names are always all upper case.
Test signals have a prefix T regardless of the bus type. More information on test signals can be found in Chapter 6 AMBA Test Methodology.
AHB signal prefixes
H indicates an AHB signal.
For example, HREADY is the signal used to indicate that the data portion of an AHB
transfer can complete. It is active HIGH.
ASB signal prefixes
A is a unidirectional signal between ASB bus masters and the arbiter
B is an ASB signal
D is a unidirectional ASB decoder signal.
For example, BnRES is the ASB reset signal. It is active LOW.
APB signal prefixes
P indicates an APB signal.
For example, PCLK is the main clock used by the APB.
2.1.1
2.1.2
2.1.3
2-2
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

2.2 AMBA AHB signal list
This section contains an overview of the AMBA AHB signals (see Table 2-1). A full description of each of the signals can be found in later sections of this document.
All signals are prefixed with the letter H, ensuring that the AHB signals are differentiated from other similarly named signals in a system design.
Name
HCLK
Bus clock
HRESETn
Reset
HADDR[31:0]
Address bus
HTRANS[1:0]
Transfer type
HWRITE
Transfer direction
HSIZE[2:0]
Transfer size
HBURST[2:0]
Burst type
HPROT[3:0]
Protection control
Source
Clock source
Reset controller
Master
Master
Master
Master
Master
Master
Description
Table 2-1 AMBA AHB signals
AMBA Signals
This clock times all bus transfers. All signal timings are related to the rising edge of HCLK.
The bus reset signal is active LOW and is used to reset the system and the bus. This is the only active LOW signal.
The 32-bit system address bus.
Indicates the type of the current transfer, which can be NONSEQUENTIAL, SEQUENTIAL, IDLE or BUSY.
When HIGH this signal indicates a write transfer and when LOW a read transfer.
Indicates the size of the transfer, which is typically byte (8-bit), halfword (16-bit) or word (32-bit). The protocol allows for larger transfer sizes up to a maximum of 1024 bits.
Indicates if the transfer forms part of a burst. Four, eight and sixteen beat bursts are supported and the burst may be either incrementing or wrapping.
The protection control signals provide additional information about a bus access and are primarily intended for use by any module that wishes to implement some level of protection.
The signals indicate if the transfer is an opcode fetch or data access, as well as if the transfer is a privileged mode access or user mode access. For bus masters with a memory management unit these signals also indicate whether the current access is cacheable or bufferable.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 2-3

AMBA Signals
Name
HWDATA[31:0]
Write data bus
HSELx
Slave select
HRDATA[31:0]
Read data bus
HREADY
Transfer done
HRESP[1:0]
Transfer response
Source
Master
Decoder
Slave
Slave
Slave
Table 2-1 AMBA AHB signals (continued) Description
The write data bus is used to transfer data from the master to the bus slaves during write operations. A minimum data bus width of 32 bits is recommended. However, this may easily be extended to allow for higher bandwidth operation.
Each AHB slave has its own slave select signal and this signal indicates that the current transfer is intended for the selected slave. This signal is simply a combinatorial decode of the address bus.
The read data bus is used to transfer data from bus slaves to the bus master during read operations. A minimum data bus width of 32 bits is recommended. However, this may easily be extended to allow for higher bandwidth operation.
When HIGH the HREADY signal indicates that a transfer has finished on the bus. This signal may be driven LOW to extend a transfer.
Note: Slaves on the bus require HREADY as both an input and an output signal.
The transfer response provides additional information on the status of a transfer.
Four different responses are provided, OKAY, ERROR, RETRY and SPLIT.
2-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

AMBA AHB also has a number of signals required to support multiple bus master operation (see Table 2-2). Many of these arbitration signals are dedicated point to point links and in Table 2-2 the suffix x indicates the signal is from module X. For example there will be a number of HBUSREQx signals in a system, such as HBUSREQarm, HBUSREQdma and HBUSREQtic.
Name
HBUSREQx
Bus request
HLOCKx
Locked transfers
HGRANTx
Bus grant
HMASTER[3:0]
Master number
HMASTLOCK
Locked sequence
HSPLITx[15:0]
Split completion request
Source
Master
Master
Arbiter
Arbiter
Arbiter
Slave (SPLIT- capable)
Description
Table 2-2 Arbitration signals
AMBA Signals
A signal from bus master x to the bus arbiter which indicates that the bus master requires the bus. There is an HBUSREQx signal for each bus master in the system, up to a maximum of 16 bus masters.
When HIGH this signal indicates that the master requires locked access to the bus and no other master should be granted the bus until this signal is LOW.
This signal indicates that bus master x is currently the highest priority master. Ownership of the address/control signals changes at the end of a transfer when HREADY is HIGH, so a master gets access to the bus when both HREADY and HGRANTx are HIGH.
These signals from the arbiter indicate which bus master is currently performing a transfer and is used by the slaves which support SPLIT transfers to determine which master is attempting an access.
The timing of HMASTER is aligned with the timing of the address and control signals.
Indicates that the current master is performing a locked sequence of transfers. This signal has the same timing as the HMASTER signal.
This 16-bit split bus is used by a slave to indicate to the arbiter which bus masters should be allowed to re-attempt a split transaction.
Each bit of this split bus corresponds to a single bus master.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 2-5

AMBA Signals
2.3
AMBA ASB signal list
Table 2-3 lists the AMBA ASB signals.
Table 2-3 AMBA ASB signals
Name
AGNTx
Bus grant
AREQx
Bus request
BA[31:0]
Address bus
BCLK
Bus clock
BD[31:0]
Data bus
BERROR
Error response
BLAST
Last response
BLOK
Locked transfers
BnRES
Reset
Description
A signal from the bus arbiter to a bus master x which indicates that the bus master will be granted the bus when BWAIT is LOW. There is an AGNTx signal for each bus master in the system, as well as an associated bus request signal, AREQx.
A signal from bus master x to the bus arbiter which indicates that the bus master requires the bus. There is an AREQx signal for each bus master in the system, as well as an associated bus grant signal, AGNTx.
The system address bus, which is driven by the active bus master.
This clock times all bus transfers. Both the LOW phase and HIGH phase of BCLK are used to control transfers on the bus.
This is the bidirectional system data bus. The data bus is driven by the current bus master during write transfers and by the selected bus slave during read transfers.
A transfer error is indicated by the selected bus slave using the BERROR signal. When BERROR is HIGH a transfer error has occurred, when BERROR is LOW then the transfer is successful. This signal is also used in combination with the BLAST signal to indicate a bus retract operation.
When no slave is selected this signal is driven by the bus decoder.
This signal is driven by the selected bus slave to indicate if the current transfer should be the last of a burst sequence. When BLAST is HIGH the decoder must allow sufficient time for address decoding. When BLAST is LOW, the next transfer may continue a burst sequence. This signal is also used in combination with the BERROR signal to indicate a bus retract operation.
When no slave is selected this signal is driven by the bus decoder.
When HIGH this signal indicates that the current transfer and the next transfer are to be indivisible and no other bus master should be given access to the bus. This signal is used by the bus arbiter.
This signal is driven by the active bus master.
The bus reset signal is active LOW and is used to reset the system and the bus. This is the only active LOW signal.
2-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Table 2-3 AMBA ASB signals (continued)
AMBA Signals
Name
BPROT[1:0]
Protection control
BSIZE[1:0]
Transfer size
BTRAN[1:0]
Transfer type
BWAIT
Wait response
BWRITE
Transfer direction
DSELx
Slave select
Description
The protection control signals provide additional information about a bus access and are primarily intended for use by a bus decoder when acting as a basic protection unit. The signals indicate if the transfer is an opcode fetch or data access, as well as if the transfer is a privileged mode access or user mode access. The signals are driven by the active bus master and have the same timing as the address bus.
The transfer size signals indicate the size of the transfer, which may be byte, halfword or word.
The signals are driven by the active bus master and have the same timing as the address bus.
These signals indicate the type of the next transaction, which may be ADDRESS-ONLY, NONSEQUENTIAL or SEQUENTIAL. These signals are driven by a bus master when the appropriate AGNTx signal is asserted.
This signal is driven by the selected bus slave to indicate if the current transfer may complete. If BWAIT is HIGH a further bus cycle is required, if BWAIT is LOW then the transfer may complete in the current bus cycle.
When no slave is selected this signal is driven by the bus decoder.
When HIGH this signal indicates a write transfer and when LOW a read transfer. This signal is driven by the active bus master and has the same timing as the address bus.
A signal from the bus decoder to a bus slave x which indicates that the slave device is selected and a data transfer is required. There is a DSELx signal for each ASB bus slave.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 2-7

AMBA Signals
2.4
AMBA APB signal list
All AMBA APB signals use the single letter P prefix. Some APB signals, such as the clock, may be connected directly to the system bus equivalent signal.
Table 2-4 shows the list of AMBA APB signal names, along with a description of how each of the signals is used.
Name
PCLK
Bus clock
PRESETn
APB reset
PADDR[31:0]
APB address bus
PSELx
APB select
PENABLE
APB strobe
PWRITE
APB transfer direction
PRDATA
APB read data bus
PWDATA
APB write data bus
Description
Table 2-4 AMBA APB signals
The rising edge of PCLK is used to time all transfers on the APB.
The APB bus reset signal is active LOW and this signal will normally be connected directly to the system bus reset signal.
This is the APB address bus, which may be up to 32-bits wide and is driven by the peripheral bus bridge unit.
A signal from the secondary decoder, within the peripheral bus bridge unit, to each peripheral bus slave x. This signal indicates that the slave device is selected and a data transfer is required. There is a PSELx signal for each bus slave.
This strobe signal is used to time all accesses on the peripheral bus. The enable signal is used to indicate the second cycle of an APB transfer. The rising edge of PENABLE occurs in the middle of the APB transfer.
When HIGH this signal indicates an APB write access and when LOW a read access.
The read data bus is driven by the selected slave during read cycles (when PWRITE is LOW). The read data bus can be up to 32-bits wide.
The write data bus is driven by the peripheral bus bridge unit during write cycles (when PWRITE is HIGH). The write data bus can be up to 32-bits wide.
2-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Chapter 3
AMBA AHB
This chapter describes the Advanced High-performance Bus (AHB) architecture. It contains the following sections:
• About the AMBA AHB on page 3-3
• Bus interconnection on page 3-4
• Overview of AMBA AHB operation on page 3-5
• Basic transfer on page 3-6
• Transfer type on page 3-9
• Burst operation on page 3-11
• Control signals on page 3-17
• Address decoding on page 3-19
• Slave transfer responses on page 3-20
• Data buses on page 3-25
• Arbitration on page 3-28
• Split transfers on page 3-35
• Reset on page 3-40
• About the AHB data bus width on page 3-41
• Implementing a narrow slave on a wider bus on page 3-42
• Implementing a wide slave on a narrow bus on page 3-43
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-1

AMBA AHB
• • • • •
About the AHB AMBA components on page 3-44 AHB bus slave on page 3-45
AHB bus master on page 3-49
AHB decoder on page 3-57
AHB arbiter on page 3-53.
3-2
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.1
About the AMBA AHB
AHB is a new generation of AMBA bus which is intended to address the requirements of high-performance synthesizable designs. AMBA AHB is a new level of bus which sits above the APB and implements the features required for high-performance, high clock frequency systems including:
• burst transfers
• split transactions
• single cycle bus master handover
• single clock edge operation
• non-tristate implementation
• wider data bus configurations (64/128 bits).
A typical AMBA AHB-based microcontroller
An AMBA-based microcontroller typically consists of a high-performance system backbone bus, able to sustain the external memory bandwidth, on which the CPU and other Direct Memory Access (DMA) devices reside, plus a bridge to a narrower APB bus on which the lower bandwidth peripheral devices are located. Figure 3-1 shows both AHB and APB in a typical AMBA system.
3.1.1
AMBA AHB
High-bandwidth Memory Interface
High-performance ARM processor
AHB
High-bandwidth on-chip RAM
B R I D G E
APB
UART
Timer
Keypad
PIO
AMBA Advanced High-performance Bus (AHB)
* High performance
* Pipelined operation * Burst transfers
* Multiple bus masters * Split transactions
AHB to APB Bridge
AMBA Advanced Peripheral Bus (APB)
* Low power
* Latched address and control * Simple interface
* Suitable for many peripherals
DMA bus master
Figure 3-1 A typical AMBA AHB-based system
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-3

AMBA AHB
3.2
Bus interconnection
The AMBA AHB bus protocol is designed to be used with a central multiplexor interconnection scheme. Using this scheme all bus masters drive out the address and control signals indicating the transfer they wish to perform and the arbiter determines which master has its address and control signals routed to all of the slaves. A central decoder is also required to control the read data and response signal multiplexor, which selects the appropriate signals from the slave that is involved in the transfer.
Figure 3-2 illustrates the structure required to implement an AMBA AHB design with three masters and four slaves.
Master #1
HRDATA
Arbiter
HADDR
Slave #1
HWDATA
Master #2
HADDR
HWDATA
HRDATA
Master #3
HADDR
HWDATA
HRDATA
HRDATA
HADDR
HWDATA
HWDATA
Slave #2
HRDATA
HADDR
Slave #3
HRDATA
HADDR
HWDATA
Slave #4
Decoder
HADDR HWDATA
Address and control mux
Write data mux Read data mux
HRDATA
Figure 3-2 Multiplexor interconnection
3-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.3 Overview of AMBA AHB operation
Before an AMBA AHB transfer can commence the bus master must be granted access to the bus. This process is started by the master asserting a request signal to the arbiter. Then the arbiter indicates when the master will be granted use of the bus.
A granted bus master starts an AMBA AHB transfer by driving the address and control signals. These signals provide information on the address, direction and width of the transfer, as well as an indication if the transfer forms part of a burst. Two different forms of burst transfers are allowed:
• incrementing bursts, which do not wrap at address boundaries
• wrapping bursts, which wrap at particular address boundaries.
A write data bus is used to move data from the master to a slave, while a read data bus is used to move data from a slave to the master.
Every transfer consists of:
• an address and control cycle
• one or more cycles for the data.
The address cannot be extended and therefore all slaves must sample the address during this time. The data, however, can be extended using the HREADY signal. When LOW this signal causes wait states to be inserted into the transfer and allows extra time for the slave to provide or sample data.
During a transfer the slave shows the status using the response signals, HRESP[1:0]:
OKAY
ERROR
RETRY and SPLIT
The OKAY response is used to indicate that the transfer is progressing normally and when HREADY goes HIGH this shows the transfer has completed successfully.
The ERROR response indicates that a transfer error has occurred and the transfer has been unsuccessful.
Both the RETRY and SPLIT transfer responses indicate that the transfer cannot complete immediately, but the bus master should continue to attempt the transfer.
In normal operation a master is allowed to complete all the transfers in a particular burst before the arbiter grants another master access to the bus. However, in order to avoid excessive arbitration latencies it is possible for the arbiter to break up a burst and in such cases the master must re-arbitrate for the bus in order to complete the remaining transfers in the burst.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-5

AMBA AHB
3.4
Basic transfer
An AHB transfer consists of two distinct sections:
• The address phase, which lasts only a single cycle.
• The data phase, which may require several cycles. This is achieved using the
HREADY signal.
Figure 3-3 shows the simplest transfer, one with no wait states.
Address phase
Data phase
HCLK
HADDR[31:0]
Control
HWDATA[31:0]
HREADY
HRDATA[31:0]
A
Control
Data (A)
Data (A)
In a simple transfer with no wait states:
•
•
The master drives the address and control signals onto the bus after the rising edge of HCLK.
The slave then samples the address and control information on the next rising edge of the clock.
Figure 3-3 Simple transfer
3-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

• After the slave has sampled the address and control it can start to drive the appropriate response and this is sampled by the bus master on the third rising edge of the clock.
This simple example demonstrates how the address and data phases of the transfer occur during different clock periods. In fact, the address phase of any transfer occurs during the data phase of the previous transfer. This overlapping of address and data is fundamental to the pipelined nature of the bus and allows for high performance operation, while still providing adequate time for a slave to provide the response to a transfer.
A slave may insert wait states into any transfer, as shown in Figure 3-4, which extends the transfer allowing additional time for completion.
AMBA AHB
HCLK
HADDR[31:0]
Control
HWDATA[31:0]
HREADY
HRDATA[31:0]
Address phase
Data phase
A
Control
Data (A)
Data (A)
Figure 3-4 Transfer with wait states
Note
For write operations the bus master will hold the data stable throughout the extended cycles.
For read transfers the slave does not have to provide valid data until the transfer is about to complete.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-7

AMBA AHB
When a transfer is extended in this way it will have the side-effect of extending the address phase of the following transfer. This is illustrated in Figure 3-5 which shows three transfers to unrelated addresses, A, B & C.
HCLK
HADDR[31:0]
Control
HWDATA[31:0]
HREADY
HRDATA[31:0]
A
Control (A)
B
Control (B)
Data (A)
Data (A)
C
Control (C)
Data (B)
Data (C)
Data (C)
Data (B)
In Figure 3-5:
• • •
the transfers to addresses A and C are both zero wait state the transfer to address B is one wait state
extending the data phase of the transfer to address B has the effect of extending the address phase of the transfer to address C.
Figure 3-5 Multiple transfers
3-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.5 Transfer type
Every transfer can be classified into one of four different types, as indicated by the HTRANS[1:0] signals as shown in Table 3-1.
Table 3-1 Transfer type encoding
AMBA AHB
HTRANS[1:0] Type
00 IDLE
01 BUSY
10 NONSEQ
11 SEQ
Description
Indicates that no data transfer is required. The IDLE transfer type is used when a bus master is granted the bus, but does not wish to perform a data transfer.
Slaves must always provide a zero wait state OKAY response to IDLE transfers and the transfer should be ignored by the slave.
The BUSY transfer type allows bus masters to insert IDLE cycles in the middle of bursts of transfers. This transfer type indicates that the bus master is continuing with a burst of transfers, but the next transfer cannot take place immediately. When a master uses the BUSY transfer type the address and control signals must reflect the next transfer in the burst.
The transfer should be ignored by the slave. Slaves must always provide a zero wait state OKAY response, in the same way that they respond to IDLE transfers.
Indicates the first transfer of a burst or a single transfer. The address and control signals are unrelated to the previous transfer.
Single transfers on the bus are treated as bursts of one and therefore the transfer type is NONSEQUENTIAL.
The remaining transfers in a burst are SEQUENTIAL and the address is related to the previous transfer. The control information is identical to the previous transfer. The address is equal to the address of the previous transfer plus the size (in bytes). In the case of a wrapping burst the address of the transfer wraps at the address boundary equal to the size (in bytes) multiplied by the number of beats in the transfer (either 4, 8 or 16).
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-9

AMBA AHB
Figure 3-6 shows a number of different transfer types being used.
T1 T2 T3 T4 T5 T6 T7 T8
HCLK
HTRANS[1:0]
HADDR[31:0]
HBURST[2:0] HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x20
BUSY SEQ
0x24 0x24
INCR
Data (0x20)
Data (0x20)
SEQ
0x28
Data (0x24)
Data (0x24)
SEQ
0x2C
Data (0x28)
Data Data
(0x28)
(0x2C)
Data (0x2C)
In Figure 3-6:
• •
•
•
The first transfer is the start of a burst and therefore is NONSEQUENTIAL.
The master is unable to perform the second transfer of the burst immediately and therefore the master uses a BUSY transfer to delay the start of the next transfer. In this example the master only requires one cycle before it is ready to start the next transfer in the burst, which completes with no wait states.
The master performs the third transfer of the burst immediately, but this time the slave is unable to complete and uses HREADY to insert a single wait state.
The final transfer of the burst completes with zero wait states.
Figure 3-6 Transfer type examples
3-10
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.6 Burst operation
Four, eight and sixteen-beat bursts are defined in the AMBA AHB protocol, as well as undefined-length bursts and single transfers. Both incrementing and wrapping bursts are supported in the protocol:
• Incrementing bursts access sequential locations and the address of each transfer in the burst is just an increment of the previous address.
• For wrapping bursts, if the start address of the transfer is not aligned to the total number of bytes in the burst (size x beats) then the address of the transfers in the burst will wrap when the boundary is reached. For example, a four-beat wrapping burst of word (4-byte) accesses will wrap at 16-byte boundaries. Therefore, if the start address of the transfer is 0x34, then it consists of four transfers to addresses 0x34, 0x38, 0x3C and 0x30.
Burst information is provided using HBURST[2:0] and the eight possible types are defined in Table 3-2.
HBURST[2:0] Type
000 SINGLE
001 INCR
010 WRAP4
011 INCR4
100 WRAP8
101 INCR8
110 WRAP16
111 INCR16
Description
Table 3-2 Burst signal encoding
AMBA AHB
Single transfer
Incrementing burst of unspecified length 4-beat wrapping burst
4-beat incrementing burst
8-beat wrapping burst
8-beat incrementing burst
16-beat wrapping burst
16-beat incrementing burst
Bursts must not cross a 1kB address boundary. Therefore it is important that masters do not attempt to start a fixed-length incrementing burst which would cause this boundary to be crossed.
It is acceptable to perform single transfers using an unspecified-length incrementing burst which only has a burst of length one.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-11

AMBA AHB
3.6.1
An incrementing burst can be of any length, but the upper limit is set by the fact that the address must not cross a 1kB boundary
Note
The burst size indicates the number of beats in the burst, not the number of bytes transferred. The total amount of data transferred in a burst is calculated by multiplying the number of beats by the amount of data in each beat, as indicated by HSIZE[2:0].
All transfers within a burst must be aligned to the address boundary equal to the size of the transfer. For example, word transfers must be aligned to word address boundaries (that is A[1:0] = 00), halfword transfers must be aligned to halfword address boundaries (that is A[0] = 0).
Early burst termination
There are certain circumstances when a burst will not be allowed to complete and therefore it is important that any slave design which makes use of the burst information can take the correct course of action if the burst is terminated early. The slave can determine when a burst has terminated early by monitoring the HTRANS signals and ensuring that after the start of the burst every transfer is labelled as SEQUENTIAL or BUSY. If a NONSEQUENTIAL or IDLE transfer occurs then this indicates that a new burst has started and therefore the previous one must have been terminated.
If a bus master cannot complete a burst because it loses ownership of the bus then it must rebuild the burst appropriately when it next gains access to the bus. For example, if a master has only completed one beat of a four-beat burst then it must use an undefined-length burst to perform the remaining three transfers.
Examples are shown on the following pages:
3-12
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A
• • • • •
Figure 3-7 shows a Four-beat wrapping burst on page 3-13 Figure 3-8 shows a Four-beat incrementing burst on page 3-14 Figure 3-9 shows an Eight-beat wrapping burst on page 3-15 Figure 3-10 shows an Eight-beat incrementing burst on page 3-15 Figure 3-11 shows Undefined-length bursts on page 3-16.

The example in Figure 3-7 shows a four-beat wrapping burst with a wait state added for the first transfer.
AMBA AHB
T1 T2 T3 T4 T5 T6 T7
HCLK
HTRANS[1:0]
HADDR[31:0] HBURST[2:0]
HWRITE HSIZE[2:0] HPROT[3:0]
HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x38
0
SEQ SEQ SEQ
x3C 0x30 0x34
WRAP4
Control for burst SIZE = Word
Data Data Data Data (0x38) (0x3C) (0x30) (0x34)
Data Data Data Data (0x38) (0x3C) (0x30) (0x34)
Figure 3-7 Four-beat wrapping burst
As the burst is a four-beat burst of word transfers the address will wrap at 16-byte boundaries, hence the transfer to address 0x3C is followed by a transfer to address 0x30. The only difference with the incrementing burst, shown in Figure 3-8 on page 3-14, is that the addresses continue past the 16-byte boundary.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-13

AMBA AHB
T1 T2 T3 T4 T5 T6 T7
HCLK
HTRANS[1:0]
HADDR[31:0] HBURST[2:0]
HWRITE HSIZE[2:0] HPROT[3:0]
HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x38
0
SEQ SEQ SEQ
x3C 0x40 0x44
INCR4
Control for burst SIZE = Word
Data Data Data Data (0x38) (0x3C) (0x40) (0x44)
Data Data Data Data (0x38) (0x3C) (0x40) (0x44)
Figure 3-8 Four-beat incrementing burst
3-14 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The example in Figure 3-9 is an eight-beat burst of word transfers.
Figure 3-10 Eight-beat incrementing burst
AMBA AHB
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
HCLK
HTRANS[1:0]
HADDR[31:0] HBURST[2:0]
HWRITE HSIZE[2:0] HPROT[3:0]
HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x34
SEQ SEQ
0x38 0x3C
Data Data (0x34) (0x38)
Data Data (0x34) (0x38)
SEQ SEQ
0x20 0x24
WRAP8
Control for burst SIZE = Word
Data Data (0x3C) (0x20)
Data Data (0x3C) (0x20)
SEQ SEQ SEQ
0x28 0x2C 0x30
Data Data Data Data (0x24) (0x28) (0x2C) (0x30)
Data Data Data Data (0x24) (0x28) (0x2C) (0x30)
Figure 3-9 Eight-beat wrapping burst
The address will wrap at 32-byte boundaries and therefore address 0x3C is followed by 0x20.
The burst in Figure 3-10 uses halfword transfers, so the addresses increase by 2 and the burst is incrementing so the addresses continue to increment past the 16-byte boundary.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
HCLK
HTRANS[1:0]
HADDR[31:0]
HBURST[2:0]
HWRITE HSIZE[2:0] HPROT[3:0]
HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x34
SEQ SEQ SEQ SEQ SEQ SEQ SEQ
0x36 0x38 0x3A 0x3C 0x3E 0x40 0x42
INCR8
Control for burst SIZE = Halfword
Data Data Data Data Data Data Data Data (0x34) (0x36) (0x38) (0x3A) (0x3C) (0x3E) (0x40) (0x42)
Data Data Data Data Data Data Data Data (0x34) (0x36) (0x38) (0x3A) (0x3C) (0x3E) (0x40) (0x42)
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-15

AMBA AHB
The final example in Figure 3-11 shows incrementing bursts of undefined length.
T1 T2 T3 T4 T5 T6 T7 T8
HCLK
HTRANS[1:0]
HADDR[31:0]
HBURST[2:0]
HWRITE HSIZE[2:0] HPROT[3:0]
HWDATA[31:0] HREADY HRDATA[31:0]
NONSEQ
0x20
SEQ NONSEQ SEQ
0x22 0x5C 0x60
INCR
SEQ
0x64
Data Data (0x60) (0x64)
Data Data (0x60) (0x64)
INCR
Control for burst Control for burst SIZE = Halfword SIZE = Word
Data Data Data (0x20) 0x22 (0x5C)
Data Data (0x20) (0x22)
Data (0x5C)
Figure 3-11 shows two bursts:
•
•
Two halfword transfers starting at address 0x20. The halfword transfer addresses increment by 2.
Three word transfers starting at address 0x5C. The word transfer addresses increment by 4.
Figure 3-11 Undefined-length bursts
3-16
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.7
3.7.1
3.7.2
Control signals
As well as the transfer type and burst type each transfer will have a number of control signals that provide additional information about the transfer. These control signals have exactly the same timing as the address bus. However, they must remain constant throughout a burst of transfers.
Transfer direction
Transfer size
When HWRITE is HIGH, this signal indicates a write transfer and the master will broadcast data on the write data bus, HWDATA[31:0]. When LOW a read transfer will be performed and the slave must generate the data on the read data bus
HRDA T A[31:0].
HSIZE[2:0] indicates the size of the transfer, as shown in Table 3-3.
Table 3-3 Size encoding
AMBA AHB
HSIZE[2] HSIZE[1] HSIZE[0]
0 0 0 0 0 1 0 1 0
0 1 1
1 0 0
1 0 1 1 1 0 1 1 1
Size
Description
8bits
16 bits
32 bits
64 bits
128 bits
256 bits
512bits 1024bits-
Byte Halfword Word
–
3.7.3
Protection control
The protection control signals, HPROT[3:0], provide additional information about a bus access and are primarily intended for use by any module that wishes to implement some level of protection (see Table 3-4).
The size is used in conjunction with the HBURST[2:0] signals to determine the address boundary for wrapping bursts.
4-word line 8-word line –
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 3-17

AMBA AHB
The signals indicate if the transfer is:
• an opcode fetch or data access
• a privileged mode access or user mode access.
For bus masters with a memory management unit these signals also indicate whether the current access is cacheable or bufferable.
HPROT[3] HPROT[2] cacheable bufferable
– –
– –
– –
– –
– 0
– 1
0 –
1 –
HPROT[1] HPROT[0] privileged data/opcode
– 0
– 1
0 –
1 –
– –
– –
– –
– –
Description
Opcode fetch Data access
User access Privileged access Not bufferable Bufferable
Not cacheable Cacheable
Table 3-4 Protection signal encodings
Not all bus masters will be capable of generating accurate protection information, therefore it is recommended that slaves do not use the HPROT signals unless strictly necessary.
3-18
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.8 Address decoding
A central address decoder is used to provide a select signal, HSELx, for each slave on the bus. The select signal is a combinatorial decode of the high-order address signals, and simple address decoding schemes are encouraged to avoid complex decode logic and to ensure high-speed operation.
A slave must only sample the address and control signals and HSELx when HREADY is HIGH, indicating that the current transfer is completing. Under certain circumstances it is possible that HSELx will be asserted when HREADY is LOW, but the selected slave will have changed by the time the current transfer completes.
The minimum address space that can be allocated to a single slave is 1kB. All bus masters are designed such that they will not perform incrementing transfers over a 1kB boundary, thus ensuring that a burst never crosses an address decode boundary.
In the case where a system design does not contain a completely filled memory map an additional default slave should be implemented to provide a response when any of the nonexistent address locations are accessed. If a NONSEQUENTIAL or SEQUENTIAL transfer is attempted to a nonexistent address location then the default slave should provide an ERROR response. IDLE or BUSY transfers to nonexistent locations should result in a zero wait state OKAY response. Typically the default slave functionality will be implemented as part of the central address decoder.
Figure 3-12 shows a typical address decoding system and the slave select signals.
AMBA AHB
Master #1
Master #2
Slave #1
Slave #2
Decoder
HSEL_S1
Slave #3
HSEL_S2
HSEL_S3
HADDR_M1[31:0]
HADDR_M2[31:0]
Address and control mux
HADDR to all slaves
Figure 3-12 Slave select signals
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-19

AMBA AHB
3.9
Slave transfer responses
After a master has started a transfer, the slave then determines how the transfer should progress. No provision is made within the AHB specification for a bus master to cancel a transfer once it has commenced.
Whenever a slave is accessed it must provide a response which indicates the status of the transfer. The HREADY signal is used to extend the transfer and this works in combination with the response signals, HRESP[1:0], which provide the status of the transfer.
The slave can complete the transfer in a number of ways. It can:
• complete the transfer immediately
• insert one or more wait states to allow time to complete the transfer
• signal an error to indicate that the transfer has failed
• delay the completion of the transfer, but allow the master and slave to back off the bus, leaving it available for other transfers.
Transfer done
The HREADY signal is used to extend the data portion of an AHB transfer. When LOW the HREADY signal indicates the transfer is to be extended and when HIGH indicates that the transfer can complete.
Note
Every slave must have a predetermined maximum number of wait states that it will insert before it backs off the bus, in order to allow the calculation of the latency of accessing the bus. It is recommended, but not mandatory, that slaves do not insert more than 16 wait states to prevent any single access locking the bus for a large number of clock cycles.
Transfer response
A typical slave will use the HREADY signal to insert the appropriate number of wait states into the transfer and then the transfer will complete with HREADY HIGH and an OKAY response, which indicates the successful completion of the transfer.
The ERROR response is used by a slave to indicate some form of error condition with the associated transfer. Typically this is used for a protection error, such as an attempt to write to a read-only memory location.
3.9.1
3.9.2
3-20
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The SPLIT and RETRY response combinations allow slaves to delay the completion of a transfer, but free up the bus for use by other masters. These response combinations are usually only required by slaves that have a high access latency and can make use of these response codes to ensure that other masters are not prevented from accessing the bus for long periods of time.
A full description of the SPLIT and RETRY operations can be found in Split and retry on page 3-24.
The encoding of HRESP[1:0], the transfer response signals, and a description of each response are shown in Table 3-5.
HRESP[1] HRESP[0]
0 0
0 1
1 0
1 1
Response
OKAY
ERROR
RETRY
SPLIT
Table 3-5 Response encoding Description
When HREADY is HIGH this shows the transfer has completed successfully.
The OKAY response is also used for any additional cycles that are inserted, with HREADY LOW, prior to giving one of the three other responses.
This response shows an error has occurred. The error condition should be signalled to the bus master so that it is aware the transfer has been unsuccessful.
A two-cycle response is required for an error condition.
The RETRY response shows the transfer has not yet completed, so the bus master should retry the transfer. The master should continue to retry the transfer until it completes.
A two-cycle RETRY response is required.
The transfer has not yet completed successfully. The bus master must retry the transfer when it is next granted access to the bus. The slave will request access to the bus on behalf of the master when the transfer can complete.
A two-cycle SPLIT response is required.
AMBA AHB
When it is necessary for a slave to insert a number of wait states prior to deciding what response will be given then it must drive the response to OKAY.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-21

AMBA AHB
3.9.3
Two-cycle response
Only an OKAY response can be given in a single cycle. The ERROR, SPLIT and RETRY responses require at least two cycles. To complete with any of these responses then in the penultimate (one before last) cycle the slave drives HRESP[1:0] to indicate ERROR, RETRY or SPLIT while driving HREADY LOW to extend the transfer for an extra cycle. In the final cycle HREADY is driven HIGH to end the transfer, while HRESP[1:0] remains driven to indicate ERROR, RETRY or SPLIT.
If the slave needs more than two cycles to provide the ERROR, SPLIT or RETRY response then additional wait states may be inserted at the start of the transfer. During this time the HREADY signal will be LOW and the response must be set to OKAY.
The two-cycle response is required because of the pipelined nature of the bus. By the time a slave starts to issue either an ERROR, SPLIT or RETRY response then the address for the following transfer has already been broadcast onto the bus. The two- cycle response allows sufficient time for the master to cancel this address and drive HTRANS[1:0] to IDLE before the start of the next transfer.
For the SPLIT and RETRY response the following transfer must be cancelled because it must not take place before the current transfer has completed. However, for the ERROR response, where the current transfer is not repeated, completion of the following transfer is optional.
Figure 3-13 shows an example of a RETRY operation.
T1 T2 T3 T4 T5
HCLK
HTRANS[1:0]
HADDR[31:0] HWDATA[31:0] HREADY HRESP[1:0]
NONSEQ
A
SEQ IDLE NONSEQ
A+4 A
Data (A)
RETRY
RETRY OKAY
Figure 3-13 Transfer with retry response
3-22
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The following events are illustrated:
• The master starts with a transfer to address A.
• Before the response is received for this transfer the master moves the address on to A + 4.
• The slave at address A is unable to complete the transfer immediately and therefore it issues a RETRY response. This response indicates to the master that the transfer at address A is unable to complete and so the transfer at address A + 4 is cancelled and replaced by an IDLE transfer.
Figure 3-14 shows a transfer where the slave requires one cycle to decide on the response it is going to give (during which time HRESP indicates OKAY) and then the slave ends the transfer with a two-cycle ERROR response.
AMBA AHB
HCLK
HADDR[31:0]
Control
HWDATA[31:0] HREADY HRESP[31:0] HRDATA[31:0]
A Control
OKAY
Data (A)
ERROR
ERROR
Figure 3-14 Error response
3.9.4 Error response
If a slave provides an ERROR response then the master may choose to cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 3-23

AMBA AHB
3.9.5
Split and retry
The SPLIT and RETRY responses provide a mechanism for slaves to release the bus when they are unable to supply data for a transfer immediately. Both mechanisms allow the transfer to finish on the bus and therefore allow a higher-priority master to get access to the bus.
The difference between SPLIT and RETRY is the way the arbiter allocates the bus after a SPLIT or a RETRY has occurred:
• For RETRY the arbiter will continue to use the normal priority scheme and therefore only masters having a higher priority will gain access to the bus.
• For a SPLIT transfer the arbiter will adjust the priority scheme so that any other master requesting the bus will get access, even if it is a lower priority. In order for a SPLIT transfer to complete the arbiter must be informed when the slave has the data available.
The SPLIT transfer requires extra complexity in both the slave and the arbiter, but has the advantage that it completely frees the bus for use by other masters, whereas the RETRY case will only allow higher priority masters onto the bus.
A bus master should treat SPLIT and RETRY in the same manner. It should continue to request the bus and attempt the transfer until it has either completed successfully or been terminated with an ERROR response.
3-24
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.10 Data buses
In order to allow implementation of an AHB system without the use of tristate drivers separate read and write data buses are required. The minimum data bus width is specified as 32 bits, but the bus width can be increased as described in About the AHB data bus width on page 3-41.
3.10.1 HWDATA[31:0]
The write data bus is driven by the bus master during write transfers. If the transfer is extended then the bus master must hold the data valid until the transfer completes, as indicated by HREADY HIGH.
All transfers must be aligned to the address boundary equal to the size of the transfer. For example, word transfers must be aligned to word address boundaries (that is A[1:0] = 00), halfword transfers must be aligned to halfword address boundaries (that is A[0] = 0).
For transfers that are narrower than the width of the bus, for example a 16-bit transfer on a 32-bit bus, then the bus master only has to drive the appropriate byte lanes. The slave is responsible for selecting the write data from the correct byte lanes. Table 3-6 on page 3-26 and Table 3-7 on page 3-26 show which byte lanes are active for a little- endian and big-endian system respectively. If required, this information can be extended for wider data bus implementations. Burst transfers which have a transfer size less than the width of the data bus will have different active byte lanes for each beat of the burst.
The active byte lane is dependent on the endianness of the system, but AHB does not specify the required endianness. Therefore, it is important that all masters and slaves on the bus are of the same endianness.
3.10.2 HRDATA[31:0]
The read data bus is driven by the appropriate slave during read transfers. If the slave extends the read transfer by holding HREADY LOW then the slave only needs to provide valid data at the end of the final cycle of the transfer, as indicated by HREADY HIGH.
For transfers that are narrower than the width of the bus the slave only needs to provide valid data on the active byte lanes, as indicated in Table 3-6 and Table 3-7. The bus master is responsible for selecting the data from the correct byte lanes.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-25

AMBA AHB
3.10.3 Endianness
A slave only has to provide valid data when a transfer completes with an OKAY response. SPLIT, RETRY and ERROR responses do not require valid read data.
Table 3-6 Active byte lanes for a 32-bit little-endian data bus
Transfer Address DATA DATA DATA DATA size offset [31:24] [23:16] [15:8] [7:0]
Word 0 ä ä ä ä Halfword 0 – – ää Halfword 2 ä ä – – Byte 0 – – – ä Byte 1 – – ä – Byte 2 – ä – – Byte 3ä—
Table 3-7 Active byte lanes for a 32-bit big-endian data bus
Transfer Address DATA DATA DATA DATA size offset [31:24] [23:16] [15:8] [7:0]
Word 0 ä ä ä ä Halfword 0 ä ä – – Halfword 2 – – ä ä Byte 0ä— Byte 1 – ä – – Byte 2 – – ä – Byte 3 – – – ä
In order for the system to function correctly it is essential that all modules are of the same endianness and also that any data routing or bridges are of the same endianness.
3-26
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Dynamic endianness is not supported, because in the majority of embedded systems, this would lead to a significant silicon overhead that is redundant.
For module designers it is recommended that only modules which will be used in a wide variety of applications should be made bi-endian, with either a configuration pin or internal control bit to select the endianness. For more application-specific blocks, fixing the endianness to either little-endian or big-endian will result in a smaller, lower power, higher performance interface.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-27

AMBA AHB
3.11 Arbitration
3.11.1
The arbitration mechanism is used to ensure that only one master has access to the bus at any one time. The arbiter performs this function by observing a number of different requests to use the bus and deciding which is currently the highest priority master requesting the bus. The arbiter also receives requests from slaves that wish to complete SPLIT transfers.
Any slaves which are not capable of performing SPLIT transfers do not need to be aware of the arbitration process, except that they need to observe the fact that a burst of transfers may not complete if the ownership of the bus is changed.
Signal description
A brief description of each of the arbitration signals is given below:
HBUSREQx
HLOCKx
HGRANTx
HMASTER[3:0]
HMASTLOCK
The bus request signal is used by a bus master to request access to the bus. Each bus master has its own HBUSREQx signal to the arbiter and there can be up to 16 separate bus masters in any system.
The lock signal is asserted by a master at the same time as the bus request signal. This indicates to the arbiter that the master is performing a number of indivisible transfers and the arbiter must not grant any other bus master access to the bus once the first transfer of the locked transfers has commenced. HLOCKx must be asserted at least a cycle before the address to which it refers, in order to prevent the arbiter from changing the grant signals.
The grant signal is generated by the arbiter and indicates that the appropriate master is currently the highest priority master requesting the bus, taking into account locked transfers and SPLIT transfers.
A master gains ownership of the address bus when HGRANTx is HIGH and HREADY is HIGH at the rising edge of HCLK.
The arbiter indicates which master is currently granted the bus using the HMASTER[3:0] signals and this can be used to control the central address and control multiplexor. The master number is also required by SPLIT-capable slaves so that they can indicate to the arbiter which master is able to complete a SPLIT transaction.
The arbiter indicates that the current transfer is part of a locked sequence by asserting the HMASTLOCK signal, which has the same timing as the address and control signals.
3-28
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

HSPLIT[15:0] The 16-bit Split Complete bus is used by a SPLIT-capable slave to indicate which bus master can complete a SPLIT transaction. This information is needed by the arbiter so that it can grant the master
access to the bus to complete the transfer.
Further information is provided in:
• Requesting bus access
• Granting bus access on page 3-30
• Early burst termination on page 3-33
• Locked transfers on page 3-34.
3.11.2 Requesting bus access
A bus master uses the HBUSREQx signal to request access to the bus and may request the bus during any cycle. The arbiter will sample the request on the rising of the clock and then use an internal priority algorithm to decide which master will be the next to gain access to the bus.
Normally the arbiter will only grant a different bus master when a burst is completing. However, if required, the arbiter can terminate a burst early to allow a higher priority master access to the bus.
If the master requires locked accesses then it must also assert the HLOCKx signal to indicate to the arbiter that no other masters should be granted the bus.
When a master is granted the bus and is performing a fixed length burst it is not necessary to continue to request the bus in order to complete the burst. The arbiter observes the progress of the burst and uses the HBURST[2:0] signals to determine how many transfers are required by the master. If the master wishes to perform a second burst after the one that is currently in progress then it should re-assert the request signal during the burst.
If a master loses access to the bus in the middle of a burst then it must re-assert the HBUSREQx request line to regain access to the bus.
For undefined length bursts the master should continue to assert the request until it has started the last transfer. The arbiter cannot predict when to change the arbitration at the end of an undefined length burst.
It is possible that a master can be granted the bus when it is not requesting it. This may occur when no masters are requesting the bus and the arbiter grants access to a default master. Therefore, it is important that if a master does not require access to the bus it drives the transfer type HTRANS to indicate an IDLE transfer.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-29

AMBA AHB
3.11.3
Granting bus access
The arbiter indicates which bus master is currently the highest priority requesting the bus by asserting the appropriate HGRANTx signal. When the current transfer completes, as indicated by HREADY HIGH, then the master will become granted and the arbiter will change the HMASTER[3:0] signals to indicate the bus master number.
Figure 3-15 shows the process when all transfers are zero wait state and the HREADY signal is HIGH.
T1 T2 T3 T4 T5 T6
HCLK HBUSREQx HGRANTx HMASTER[3:0] HADDR[31:0] HWDATA[31:0]
#
1
A
A+4
Data (A)
Figure 3-15 Granting access with no wait states
Figure 3-16 shows the effect of wait states on the bus handover.
T1 T2 T3 T4 T5 T6 T7 T8 T9
Master asserts request
A number of cycles later arbiter asserts grant
Master drives address after both HGRANT and HREADY are high
Address sampled and data starts when HREADY high
HCLK HBUSREQx HGRANTx HMASTER[3:0] HADDR[31:0] HWDATA[31:0] HREADY
#1
A
A+4
Data (A)
Figure 3-16 Granting access with wait states
3-30
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The ownership of the data bus is delayed from the ownership of the address bus. Whenever a transfer completes, as indicated by HREADY HIGH, then the master that owns the address bus will be able to use the data bus and will continue to own the data bus until the transfer completes. Figure 3-17 shows how the ownership of the data bus is transferred when handover occurs between two bus masters.
AMBA AHB
HCLK HGRANT_M1 HGRANT_M2 HMASTER
HTRANS[31:0] HADDR[31:0]
HREADY HWDATA[31:0]
T1 T2 T3 T4 T5 T6 T7 T8 T9
#1
Master 1 owns Address and Control
#2
Master 2 owns Address and Control
SEQ
SEQ
NONSEQ
SEQ
A+8
A + 12
Master 1 owns Data
B
B+4
Master 2 owns Data
Data (A + 4)
Data (A + 8)
Data (A + 12)
Data (B)
Figure 3-17 Data bus ownership
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-31

AMBA AHB
Figure 3-18 shows an example of how the arbiter can hand over the bus at the end of a burst of transfers.
T1 T2 T3 T4 T5 T6 T7 T8 T9
HCLK HBUSREQ_M1 HBUSREQ_M2 HGRANT_M1 HGRANT_M2 HMASTER[3:0]
HTRAN[1:0]
HADDR[31:0]
HBURST[2:0] HWRITE HSIZE[2:0]
HPROT[3:0] HWDATA[31:0]
HREADY
#
1
#2
NONSEQ
SEQ
SEQ
SEQ
A
A+4
A+8
A + 12
Control for burst
Data (A)
Data (A + 4)
Data (A + 8)
Data (A + 12)
Figure 3-18 Handover after burst
The arbiter changes the HGRANTx signals when the penultimate (one before last) address has been sampled. The new HGRANTx information will then be sampled at the same point as the last address of the burst is sampled.
3-32
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 3-19 shows how HGRANTx and HMASTER signals are used in a system.
Note
H
AMBA AHB
Decoder
HMASTER[3:0]
HGRANT_M1
GRANT_M2
HGRANT_M3
HADDR_M1[31:0]
HADDR_M2[31:0]
HADDR_M3[31:0]
HADDR to all slaves
Address and control multiplexor
Master #1
Master #2
Master #3
Figure 3-19 Bus master grant signals
Because a central multiplexor is used, each master can drive out the address of the transfer it wishes to perform immediately and it does not need to wait until it is granted the bus. The HGRANTx signal is only used by the master to determine when it owns the bus and hence when it should consider that the address has been sampled by the appropriate slave.
A delayed version of the HMASTER bus is used to control the write data multiplexor.
3.11.4 Early burst termination
Normally the arbiter will not hand over the bus to a new master until the end of a burst of transfers. However, if the arbiter determines that the burst must be terminated early in order to prevent excessive access time to the bus then it may transfer the grant to another bus master before a burst has completed.
If a master loses ownership of the bus in the middle of a burst it must re-arbitrate for the bus in order to complete the burst. The master must ensure that the HBURST and HTRANS signals are adapted to reflect the fact that it no longer has to perform a complete 4, 8 or 16-beat burst.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-33

AMBA AHB
3.11.5
For example, if a master is only able to complete 3 transfers of an 8-beat burst, then when it regains the bus it must use a legal burst encoding to complete the remaining 5 transfers. Any legal combination can be used, so either a 5-beat undefined length burst or a 4-beat fixed length burst followed by a single-beat undefined length burst would be acceptable.
Locked transfers
The arbiter must observe the HLOCKx signal from each master to determine when the master wishes to perform a locked sequence of transfers. The arbiter is then responsible for ensuring that no other bus masters are granted the bus until the locked sequence has completed.
After a sequence of locked transfers the arbiter will always keep the bus master granted for an additional transfer to ensure that the last transfer in the locked sequence has completed successfully and has not received either a SPLIT or RETRY response. Therefore it is recommended, but not mandatory, that the master inserts an IDLE transfer after any locked sequence to provide an opportunity for the arbitration to change before commencing another burst of transfers.
The arbiter is also responsible for asserting the HMASTLOCK signal, which has the same timing as the address and control signals. This signal indicates to any slave that the current transfer is locked and therefore must be processed before any other masters are granted the bus.
Default bus master
Every system must include a default bus master which is granted the bus if all other masters are unable to use the bus. When granted, the default bus master must only perform IDLE transfers.
If no masters are requesting the bus then the arbiter may either grant the default master or alternatively it may grant the master that would benefit the most from having low access latency to the bus.
Granting the default master access to the bus also provides a useful mechanism for ensuring that no new transfers are started on the bus and is a useful step to perform prior to entering a low-power mode of operation.
The default master must be granted if all other masters are waiting for SPLIT transfers to complete.
3.11.6
3-34
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.12 Split transfers
SPLIT transfers improve the overall utilization of the bus by separating (or splitting) the operation of the master providing the address to a slave from the operation of the slave responding with the appropriate data.
When a transfer occurs the slave can decide to issue a SPLIT response if it believes the transfer will take a large number of cycles to perform. This signals to the arbiter that the master which is attempting the transfer should not be granted access to the bus until the slave indicates it is ready to complete the transfer. Therefore the arbiter is responsible for observing the response signals and internally masking any requests from masters which have been SPLIT.
During the address phase of a transfer the arbiter generates a tag, or bus master number, on HMASTER[3:0] which identifies the master that is performing the transfer. Any slave issuing a SPLIT response must be capable of indicating that it can complete the transfer, and it does this by making a note of the master number on the HMASTER[3:0] signals.
Later, when the slave can complete the transfer, it asserts the appropriate bit, according to the master number, on the HSPLITx[15:0] signals from the slave to the arbiter. The arbiter then uses this information to unmask the request signal from the master and in due course the master will be granted access to the bus to retry the transfer. The arbiter samples the HSPLITx bus every cycle and therefore the slave only needs to assert the appropriate bit for a single cycle in order for the arbiter to recognize it.
In a system with multiple SPLIT-capable slaves the HSPLITx buses from each slave can be ORed together to provide a single resultant HSPLIT bus to the arbiter.
In the majority of systems the maximum capacity of 16 bus masters will not be used and therefore the arbiter only requires an HSPLIT bus which has the same number of bits as there are bus masters. However, it is recommended that all SPLIT-capable slaves are designed to support up to 16 masters.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-35

AMBA AHB
3.12.1
Split transfer sequence
The basic stages of a SPLIT transaction are:
1. The master starts the transfer in an identical way to any other transfer and issues address and control information
2. If the slave is able to provide data immediately it may do so. If the slave decides that it may take a number of cycles to obtain the data it gives a SPLIT transfer response.
During every transfer the arbiter broadcasts a number, or tag, showing which master is using the bus. The slave must record this number, to use it to restart the transfer at a later time.
3. The arbiter grants other masters use of the bus and the action of the SPLIT response allows bus master handover to occur. If all other masters have also received a SPLIT response then the default master is granted.
4. When the slave is ready to complete the transfer it asserts the appropriate bit of the HSPLITx bus to the arbiter to indicate which master should be regranted access to the bus.
5. The arbiter observes the HSPLITx signals on every cycle, and when any bit of HSPLITx is asserted the arbiter restores the priority of the appropriate master.
6. Eventually the arbiter will grant the master so it can re-attempt the transfer. This may not occur immediately if a higher priority master is using the bus.
7. When the transfer eventually takes place the slave finishes with an OKAY transfer response.
Multiple split transfers
The bus protocol only allows a single outstanding transaction per bus master. If any master module is able to deal with more than one outstanding transaction it requires an additional set of request and grant signals for each outstanding transaction that it can handle. At the protocol level a single module may appear as a number of different bus masters, each of which can only have one outstanding transaction.
It is, however, possible that a SPLIT-capable slave could receive more transfer requests than it is able to process concurrently. If this happens then it is acceptable for the slave to issue a SPLIT response without recording the appropriate address and control information for the transfer and it is only necessary for the slave to record the bus master number. The slave can then indicate that it can process another transfer by asserting the appropriate bits on the HSPLITx bus for all masters that the slave has previously SPLIT, but that the slave has not recorded the address and control information.
3.12.2
3-36
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The arbiter is then able to regrant the masters access to the bus and they will retry the transfer, giving the address and control information required by the slave. This means that a master may be granted the bus a number of times before it is finally allowed to complete the transfer it requires.
3.12.3 Preventing deadlock
Both the SPLIT and RETRY transfer responses must be used with care to prevent bus deadlock. A single transfer can never lock the AHB as every slave must be designed to finish a transfer within a predetermined number of cycles. However, it is possible for deadlock to occur if a number of different masters attempt to access a slave which issues SPLIT or RETRY responses in a manner which the slave is unable to deal with.
Split transfers
For slaves that can issue a SPLIT transfer response, bus deadlock is prevented by ensuring that the slave can withstand a request from every master in the system, up to a maximum of 16. The slave does not need to store the address and control information for every transfer, it simply needs to record the fact that a transfer request has been made and a SPLIT response issued. Eventually all masters will be at a low priority and the slave can then work through the requests in an orderly manner, indicating to the arbiter which request it is servicing, thus ensuring that all requests are eventually serviced.
When a slave has a number of outstanding requests it may choose to process them in any order, although the slave must be aware that a locked transfer will have to be completed before any other transfers can continue.
It is perfectly legal for the slave to use a SPLIT response without latching the address and control information. The slave only needs to record that a transfer attempt has been made by that particular master and then at a later point the slave can obtain the address and control information by indicating that it is ready to complete the transfer. The master will be granted the bus and will rebroadcast the transfer, allowing the slave to latch the address and control information and either respond with the data immediately, or issue another SPLIT response if a number of additional cycles are required.
Ideally the slave should never have more outstanding transfers than it can support, but the mechanism to support this is required to prevent bus deadlock.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-37

AMBA AHB
Retry transfers
A slave which issues RETRY responses must only be accessed by one master at a time. This is not enforced by the protocol of the bus and should be ensured by the system architecture. In most cases slaves that issue RETRY responses will be peripherals which need to be accessed by just one master at a time, so this will be ensured by some higher level protocol.
Hardware protection against multiple masters accessing RETRY slaves is not a requirement of the protocol, but may be implemented as described in the following paragraph. The only bus-level requirement is that the slave must drive HREADY HIGH within a predetermined number of clock cycles.
If hardware protection is required then this may be implemented within the RETRY slave itself. When a slave issues a RETRY it can sample the master number. Between that point and the time when the transfer is finally completed the RETRY slave can check every transfer attempt that is made to ensure the master number is the same. If it ever detects that the master number is different then it can take an alternative course of action, such as:
• • • •
an ERROR response
a signal to the arbiter
a system level interrupt a complete system reset.
3-38
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.12.4 Bus handover with split transfers
The protocol requires that a master performs an IDLE transfer immediately after receiving a SPLIT or RETRY response allowing the bus to be transferred to another master. Figure 3-20 shows the sequence of events that occur for a split transfer.
AMBA AHB
HCLK
HGRANT
HTRAN[1:0]
HADDR[31:0]
HBURST[2:0] HWRITE HSIZE[2:0] HPROT[3:0]
HREADY HRESP[1:0]
T1 T2
Slave signals split
T3
Arbiter changes grant
New master drives
T4 address T5
IDLE
SPLIT
NONSEQ SEQ
A A+4
Control (A)
SPLIT
NONSEQ
B
Control (B)
OKAY
Figure 3-20 Handover after split transfer
The following points should be noted:
• The address for the transfer is on the bus after time T1. The slave returns the two-cycle SPLIT response after the clock edges at T2 and T3.
• At the end of the first response cycle, T3, the master can detect that the transfer will be SPLIT and so it changes the control signals for the following transfer to show an IDLE transfer.
• Also at time T3 the arbiter samples the response signals and determines that the transfer has been SPLIT. The arbiter can then adjust the arbitration priorities and the grant signals change during the following cycle, such that the new master can be granted the address bus after time T4.
• The new master is guaranteed immediate access because the IDLE transfer always completes in a single cycle.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-39

AMBA AHB
3.13 Reset
The reset, HRESETn, is the only active LOW signal in the AMBA AHB specification and is the primary reset for all bus elements. The reset may be asserted asynchronously, but is deasserted synchronously after the rising edge of HCLK.
During reset all masters must ensure the address and control signals are at valid levels and that HTRANS[1:0] indicates IDLE.
3-40
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.14 About the AHB data bus width
One way to improve bus bandwidth without increasing the frequency of operation is to make the data path of the on-chip bus wider. Both the increased layers of metal and the use of large on-chip memory blocks (such as Embedded DRAM) are driving factors which encourage the use of wider on-chip buses.
Specifying a fixed width of bus will mean that in many cases the width of the bus is not optimal for the application. Therefore an approach has been adopted which allows flexibility of the width of bus, but still ensures that modules are highly portable between designs.
The protocol allows for the AHB data bus to be 8, 16, 32, 64, 128, 256, 512 or 1024-bits wide. However, it is recommended that a minimum bus width of 32 bits is used and it is expected that a maximum of 256 bits will be adequate for almost all applications.
For both read and write transfers the receiving module must select the data from the correct byte lane on the bus. Replication of data across all byte lanes is not required.
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-41

AMBA AHB
3.15
Implementing a narrow slave on a wider bus
Figure 3-21 shows how a slave module, which has been originally designed to operate with a 32-bit data bus, can be easily converted to operate on a wider 64-bit bus. This only requires the addition of external logic, rather than any internal design changes, and therefore the technique is applicable to hard macrocells.
HWDATA[64:32]
HWDATA[31:0]
HADDR[2] HREADY HCLK
Address and control
WDATA[31:0]
HREADY HRESP[1:0]
RDATA[31:0]
Transfer response
HRDATA[64:32]
HRDATA[31:0]
DQ CE
AHB slave
Figure 3-21 Narrow slave on a wide bus
For the output, when converting a narrow bus into a wider bus, do one of the following:
• Replicate the data onto both halves of the wide bus (as shown in the diagram above)
• Use an addition level of logic to ensure that only the appropriate half of the bus is changed. This will lead to a reduction in power consumption.
A slave can only accept transfers that are as wide as its natural interface. If a master attempts a transfer that is wider than the slave can support then the slave can use the ERROR transfer response.
3-42
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.16 Implementing a wide slave on a narrow bus
3.16.1 Masters
Figure 3-22 Wide slave on a narrow bus
Bus masters can easily be modified to work on a wider bus than originally intended, in the same way that the slave is modified to work on a wider bus, by:
• multiplexing the input bus
• replication of the output bus.
However, bus masters cannot be made to work on a narrower bus than originally intended, unless there is some mechanism included within the master to limit the width of transfers that the bus master attempts. The master must never attempt a transfer where the width (as indicate by HSIZE) is wider than the data bus to which it is connected.
The example in Figure 3-22 shows a wide slave being implemented on a narrow bus. Again only external logic is required and hence predesigned or imported blocks can be easily modified to work with a different width of data bus.
AMBA AHB
Address and control
HWDATA[64:32]
HWDATA[31:0]
HREADY HRESP[1:0]
HRDATA[64:32]
Transfer response
HRDATA[31:0]
AHB slave
HWDATA[31:0]
HRDATA[31:0]
HADDR[2] HREADY HCLK
DQ CE
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-43

AMBA AHB
3.17
About the AHB AMBA components
This section describes each of the elements in an AHB-based AMBA system and provides the generic timing parameters that are required to analyze an AMBA design.
The following notation is used for the timing parameters:
• • • •
Tis – input setup time Tih – input hold time Tov – output valid time Toh – output hold time.
3-44
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.18
3.18.1
AHB bus slave
An AHB bus slave responds to transfers initiated by bus masters within the system. The slave uses a HSELx select signal from the decoder to determine when it should respond to a bus transfer. All other signals required for the transfer, such as the address and control information, will be generated by the bus master.
Interface diagram
Figure 3-23 shows an AHB bus slave interface.
AMBA AHB
Select
Address and control
Data
Reset
Clock
HSELx
HADDR[31:0]
HWRITE HTRANS[1:0] HSIZE[2:0] HBURST[2:0]
HWDATA[31:0]
HRESETn HCLK HMASTER[3:0] HMASTLOCK
AHB slave
HREADY
HRESP[1:0] Transfer
response
HRDATA[31:0] Data
HSPLITx[15:0]
Split-capable slave
Figure 3-23 AHB bus slave interface
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 3-45

AMBA AHB
3.18.2
Timing diagrams
The following diagrams show the timing parameters related to an access to an AHB bus slave operating in an AMBA system:
3-46
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A
• • •
Figure 3-24 shows the AHB slave reset timing parameters Figure 3-25 shows the main AHB slave timing parameters
Figure 3-26 shows the additional timing parameters for split-capable AHB slaves.
HCLK HRESETn
HCLK HSELx
Tissel
Tistr
Tisa
Tisctl
Tisrst
HTRANS[1:0]
HADDR[31:0]
HWRITE HSIZE[2:0] HBURST[2:0]
HWDATA[31:0]
HREADY
HRESP[1:0]
HRDATA[31:0]
NONSEQ
A
Control
Tiswd
Tovrdy
Tovrsp
Tovrd
Tihsel
Tihtr
Tiha
Tihctl
Data (A)
OKAY
Data (A)
Tihwd
Tohrdy
Tohrsp
Tohrd
Tihrst
Figure 3-24 AHB slave reset timing
Figure 3-25 AHB timing parameters

3.18.3 Timing parameters
Figure 3-26 Additional split-capable slave parameters
The timing parameters related to an AHB bus slave are given for input signals in Table 3-8 and for output signals in Table 3-9.
Table 3-8 AHB slave input parameters
AMBA AHB
HCLK
HMASTER[3:0]
Tismst
HMASTLOCK
Tismlck
HSPLITx[15:0]
Tihmst
Tihmlck
Tovsplt
Tohsplt
Parameter
Tclk Tisrst Tihrst Tissel Tihsel Tistr Tihtr Tisa Tiha Tisctl
Description
HCLK minimum clock period
HRESETn deasserted setup time before HCLK
HRESETn deasserted hold time after HCLK
HSELx setup time before HCLK
HSELx hold time after HCLK
Transfer type setup time before HCLK
Transfer type hold time after HCLK
HADDR[31:0] setup time before HCLK
HADDR[31:0] hold time after HCLK
HWRITE, HSIZE[2:0] and HBURST[2:0] control signal setup time before HCLK
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-47

AMBA AHB
Parameter
Tihctl
Tiswd Tihwd Tisrdy Tihrdy Tismst Tihmst Tismlck Tihmlck
Parameter
Tovrsp Tohrsp Tovrdy Tohrdy Tovsplt Tohsplt
Description
Table 3-8 AHB slave input parameters (continued)
HWRITE, HSIZE[2:0] and HBURST[2:0] control signal hold time after HCLK
Write data setup time before HCLK
Write data hold time after HCLK
Ready setup time before HCLK
Ready hold time after HCLK
Master number setup time before HCLK (SPLIT-capable only) Master number hold time after HCLK (SPLIT-capable only) Master locked setup time before HCLK (SPLIT-capable only) Master locked hold time after HCLK (SPLIT-capable only)
Description
Response valid time after HCLK
Response hold time after HCLK
Ready valid time after HCLK
Ready hold time after HCLK
Split valid time after HCLK (SPLIT-capable only) Split hold time after HCLK (SPLIT-capable only)
Table 3-9 AHB slave output parameters
3-48
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.19
3.19.1
AHB bus master
An AHB bus master has the most complex bus interface in an AMBA system. Typically an AMBA system designer would use predesigned bus masters and therefore would not need to be concerned with the detail of the bus master interface.
Interface diagram
The interface diagram of an AHB bus master shows the main signal groups.
3.19.2
Bus master timing diagrams
The following diagrams show the timing parameters related to an AHB bus master operating in an AMBA system:
• Figure 3-28 shows the AHB master reset timing parameters
• Figure 3-29 shows the AHB master transfer timing parameters
• Figure 3-30 shows the AHB master arbitration timing parameters.
Figure 3-28 AHB master reset timing parameters
AMBA AHB
Arbiter grant
Transfer response
Reset Clock
Data
HGRANTx
HREADY HRESP[1:0]
HRESETn HCLK
HRDATA[31:0]
AHB master
HBUSREQx HLOCKx
HTRANS[1:0]
HADDR[31:0]
HWRITE HSIZE[2:0] HBURST[2:0] HPROT[3:0]
Arbiter Transfer type
Address and control
HWDATA[31:0] Data
Figure 3-27 AHB bus master interface diagram
HCLK HRESETn
Tisrst
Tihrst
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-49

AMBA AHB
HCLK HTRANS[1:0]
Tovtr
HWRITE Tova HSIZE[2:0]
HBURST[2:0] HPROT[3:0]Tovctl
HWDATA[31:0] HREADY
HRESP[1:0]
HRDATA[31:0]
NONSEQ
A
Control
Tovwd
Tohtr
Toha
Tohctl
HADDR[31:0]
Figure 3-29 AHB master transfer timing parameters
HCLK HBUSREQx
Tovreq
HLOCKx
Tovlck
HGRANTx
Tohreq
Tohlck
Figure 3-30 AHB master arbitration timing parameters
3-50 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A
Tisrdy
Tohwd
Tihrdy
Tihrsp
Tihrd
Data (A)
OKAY OKAY
Tisgnt
Tihgnt
Tisrsp
Tisrd
Data (A)

3.19.3 Timing parameters
The timing parameters related to an AHB bus master operating in an AMBA system are also shown in textual form in the following two tables. Table 3-10 details the input signals. Table 3-11 details output signals.
Parameter
Tclk Tisrst Tihrst Tisgnt Tihgnt Tisrdy Tihrdy Tisrsp Tihrsp Tisrd Tihrd
Parameter
Tovtr Tohtr Tova Toha Tovctl
Description
Table 3-10 Bus master input timing parameters
HCLK minimum clock period time
Reset deasserted setup time before HCLK Reset deasserted hold time after HCLK HGRANTx setup time before HCLK HGRANTx hold time after HCLK Ready setup time before HCLK
Ready hold time after HCLK
Response setup time before HCLK Response hold time after HCLK
Read data setup time before HCLK
Read data hold time after HCLK
Table 3-11 Bus master output timing parameters
Description
Transfer type valid time after HCLK Transfer type hold time after HCLK Address valid time after HCLK Address hold time after HCLK Control signal valid time after HCLK
AMBA AHB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-51

AMBA AHB
Parameter
Table 3-11 Bus master output timing parameters (continued) Description
Control signal hold time after HCLK Write data valid time after HCLK Write data hold time after HCLK Request valid time after HCLK Request hold time after HCLK
Lock valid time after HCLK Lock hold time after HCLK
Tohctl Tovwd Tohwd Tovreq Tohreq Tovlck Tohlck
3-52
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.20
AHB arbiter
3.20.1
Interface diagram
Figure 3-31 shows the signal interface of an AHB arbiter.
The role of the arbiter in an AMBA system is to control which master has access to the bus. Every bus master has a REQUEST/GRANT interface to the arbiter and the arbiter uses a prioritization scheme to decide which bus master is currently the highest priority master requesting the bus.
Each master also generates an HLOCKx signal which is used to indicate that the master requires exclusive access to the bus.
The detail of the priority scheme is not specified and is defined for each application. It is acceptable for the arbiter to use other signals, either AMBA or non-AMBA, to influence the priority scheme that is in use.
AMBA AHB
Arbiter requests and locks
Address and control
HBUSREQx1 HLOCKx1 HBUSREQx2 HLOCKx2 HBUSREQx3 HLOCKx3
HADDR[31:0]
HSPLITx[15:0] HTRANS[1:0] HBURST[2:0] HRESP[1:0] HREADY
Reset HRESETn Clock HCLK
AHB arbiter
HGRANTx1 HGRANTx2 HGRANTx3
HMASTER[3:0]
HMASTLOCK
Arbiter grants
Figure 3-31 AHB arbiter interface diagram
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 3-53

AMBA AHB
3.20.2
Timing diagrams
The following diagrams show the timing parameters related to an AHB bus arbiter operating in an AMBA system:
• • •
Figure 3-32 shows the AHB arbiter reset timing parameters Figure 3-33 shows the AHB arbiter transfer timing parameters Figure 3-34 shows the AHB arbiter split timing parameters.
Figure 3-32 AHB arbiter reset timing parameters
HCLK HRESETn
Tisrst
Tihrst
HCLK HTRANS[1:0]
HBURST[2:0]
HREADY
HRESP[1:0]
Tistr
Tisctl
NONSEQ
Control
Tisrdy
Tisrsp
Tihtr
Tihctl
OKAY
Tihrdy
Tihrsp
Figure 3-33 AHB arbiter transfer timing parameters
3-54
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

3.20.3 Timing parameters
Figure 3-34 AHB arbiter split timing parameters
The timing parameters related to an AHB arbiter are given in the following tables:
• •
Table 3-12 is for input signals Table 3-13 is for output signals.
Parameter
Tclk Tisrst Tihrst Tisrdy Tihrdy Tisrsp
Description
Table 3-12 AHB arbiter input parameters
AMBA AHB
HCLK
HBUSREQx
Tisreq
HLOCKx
Tislck
HSPLITx[15:0]
Tissplt
HGRANTx
HMASTER[3:0]
HMASTLOCK
Tihreq
Tihlck
Tihsplt
Tovgnt
Tovmast
Tovmlck
Tohgnt
Tohmast
Tohmlck
HCLK minimum clock period
Reset deasserted setup time before HCLK Reset deasserted hold time after HCLK Ready setup time before HCLK
Ready hold time after HCLK
Response setup time before HCLK
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-55

AMBA AHB
Parameter
Tihrsp
Tisreq
Tihreq
Tislck
Tihlck
Tissplt Tihsplt
Tistr Tihtr Tisctl Tihctl
Parameter
Tovgnt Tohgnt Tovmst Tohmst Tovmlck Tohmlck
Table 3-12 AHB arbiter input parameters (continued) Description
Response hold time after HCLK Request setup time before HCLK Request hold time after HCLK Lock setup time before HCLK Lock hold time after HCLK
Split setup time before HCLK
Split hold time after HCLK
Transfer type setup time before HCLK Transfer type hold time after HCLK Control signal setup time before HCLK Control signal hold time after HCLK
Table 3-13 AHB arbiter output parameters
Description
Grant valid time after HCLK
Grant hold time after HCLK
Master number valid time after HCLK Master number hold time after HCLK Master locked valid time after HCLK Master locked hold time after HCLK
3-56
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

3.21
3.21.1
AHB decoder
The decoder in an AMBA system is used to perform a centralized address decoding function, which improves the portability of peripherals, by making them independent of the system memory map.
3.21.2
Timing diagram
Interface diagram
Figure 3-35 shows an AHB decoder.
The timing parameters for an AHB decoder are shown in Figure 3-36.
AMBA AHB
Address HADDR[31:0]
AHB decoder
HSELx1
HSELx2 Select HSELx3
Figure 3-35 AHB decoder interface diagram
HCLK HADDR
HSELx
A
Tadsel
3.21.3
Timing parameter
The timing parameter related to an AHB decoder is given in Table 3-14.
Figure 3-36 AHB decoder timing parameter
Table 3-14 AHB decoder output parameter
Parameter Description
Tadsel
Delay from Address to Select valid
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 3-57

AMBA AHB
3-58 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Chapter 4
AMBA ASB
This chapter introduces the Advanced Microcontroller Bus Architecture (AMBA) Advanced System Bus specification. It contains the following sections:
• About the AMBA ASB on page 4-2
• AMBA ASB description on page 4-4
• ASB transfers on page 4-6
• Address decode on page 4-14
• Transfer response on page 4-16
• Multi-master operation on page 4-19
• Reset operation on page 4-23
• Description of ASB signals on page 4-25
• About the ASB AMBA components on page 4-46
• ASB bus slave on page 4-47
• ASB bus master on page 4-52
• ASB decoder on page 4-63
• ASB arbiter on page 4-71.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-1

AMBA ASB
4.1
About the AMBA ASB
The Advanced System Bus (ASB) specification defines a high-performance bus that can be used in the design of high performance 16 and 32-bit embedded microcontrollers.
AMBA ASB supports the efficient connection of processors, on-chip memories and off- chip external memory interfaces with low-power peripheral macrocell functions. The bus also provides the test infrastructure for modular macrocell test and diagnostic access.
A typical AMBA ASB-based microcontroller
An AMBA-based microcontroller typically consists of a high-performance system backbone bus, able to sustain the external memory bandwidth, on which the CPU and other Direct Memory Access (DMA) devices reside, plus a bridge to a narrower APB bus on which the lower bandwidth peripheral devices are located. Figure 4-1 shows both ASB and APB in a typical AMBA system.
4.1.1
High-performance ARM processor
High-bandwidth on-chip RAM
B R I D G E
UART
Timer
High-bandwidth Memory Interface
ASB
APB
Keypad
PIO
AMBA Advanced System Bus (ASB)
* High performance
* Pipelined operation * Burst transfers
* Multiple bus masters
ASB to APB Bridge
AMBA Advanced Peripheral Bus (APB)
* Low power
* Latched address and control * Simple interface
* Suitable for many peripherals
DMA bus master
Figure 4-1 A typical AMBA system
The external memory interface is application-specific and may only have a narrow data path, but it supports a test access mode which allows the internal ASB and APB modules to be tested in isolation with system-independent test sets.
4-2
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.1.2 AMBA ASB and APB
The APB appears as a local secondary bus that is encapsulated as a single ASB slave device. APB provides a low-power extension to the system bus which builds on ASB signals directly.
The APB bridge appears as a slave module which handles the bus handshake and control signal retiming on behalf of the local peripheral bus. By defining the APB interface from the starting point of the system bus, the benefits of the system diagnostics and test methodology can be exploited.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-3

AMBA ASB
4.2
AMBA ASB description
The ASB is a high-performance pipelined bus, which supports multiple bus masters. The basic flow of the bus operation is:
1. The arbiter determines which master is granted access to the bus.
2. When granted, a master initiates transfers on the bus.
3. The decoder uses the high order address lines to select a bus slave.
4. The slave provides a transfer response back to the bus master and data is transferred between the master and slave.
There are three types of transfer that can occur on the ASB: NONSEQUENTIAL
SEQUENTIAL
ADDRESS-ONLY
Used for single transfers or for the first transfer of a burst.
Used for transfers in a burst. The address of a SEQUENTIAL transfer is always related to the previous transfer.
Used when no data movement is required. The three main uses for ADDRESS-ONLY transfers are for IDLE cycles, for bus master HANDOVER cycles, and for speculative address decoding without committing to a data transfer.
4-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 4-2 shows the use of NONSEQUENTIAL and SEQUENTIAL transfers to perform a burst transaction.
AMBA ASB
BCLK
BTRAN[1:0] N-TRAN
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
DSELx
BWAIT BERROR BLAST
BD[31:0]
S-TRAN
Addr
S-TRAN
Addr + 4
Control
S-TRAN
Addr + 8
S-TRAN
Addr + C
S-TRAN
Transfer 1 Transfer 2 Transfer 3 Transfer 4
WAIT
DONE
DONE
Data (A)
Data (A+C)
DONE
Data (A+4)
DONE
Data (A+8)
Figure 4-2 ASB transfers
The burst starts with a NONSEQUENTIAL transfer to address A. The following SEQUENTIAL transfers are to successive addresses A+4, A+8 and A+12.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-5

AMBA ASB
4.3
ASB transfers
When a master has been granted the bus it can perform the following transfers:
• NONSEQUENTIAL data transfer
• SEQUENTIAL data transfer
• ADDRESS-ONLY transfer.
A transfer is defined as starting at the falling edge of BCLK after the previous transfer has completed, as indicated by BWAIT being LOW, and running until the falling edge of BCLK after a complete transfer response is received, again indicated by BWAIT being LOW.
The type of transfer that a bus master will perform can be determined by the value on the BTRAN signals at the start of the transfer. During the transfer the BTRAN signals will change to indicate the type of the following transfer.
4-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.3.1 Nonsequential transfer
A NONSEQUENTIAL transfer occurs for either a single transfer or at the start of a burst of transfers. Figure 4-3 shows a typical NONSEQUENTIAL read transfer including wait states.
AMBA ASB
Decode cycle
Read access
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
DSELx
BWAIT BERROR BLAST
BD[31:0]
Read
N-TRAN
Addr
Contro
l
DONE WAIT
Start of transfer
DONE
WAIT
WAIT
Data (A+8)
End of transfer
The following points should be noted:
•
•
The address and control signals start to change in the BCLK HIGH phase before the transfer starts.
For a NONSEQUENTIAL transfer a valid address may not be available until very late in the BCLK HIGH phase, or even until the start of the clock LOW phase at the beginning of the transfer.
Figure 4-3 Nonsequential transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-7

AMBA ASB
4.3.2
• The decoder, which requires a stable address in order to select the correct slave, will automatically insert a wait state in the first cycle of NONSEQUENTIAL transfers. This is referred to as a DECODE cycle and provides an adequate time for the decoder to examine the high order address lines and assert the appropriate DSELx during the HIGH phase of the DECODE cycle.
• For the remaining cycles of the transfer, the slave will provide a transfer response and the data exchange will occur between the master and slave.
Note
In certain system designs, which are typically those with a low-frequency system clock, the address is valid early enough in the BCLK HIGH phase before the start of the transfer, allowing the decoder to generate a valid DSELx signal before the falling edge of BCLK. Such systems do not require the addition of a DECODE cycle at the start of the NONSEQUENTIAL transfers and the operation of such a system is described in more detail in Address decode on page 4-14.
• The data bus, BD[31:0], must be valid by the falling edge of BCLK at the end of the transfer. During a write cycle, the bus master is responsible for driving the data bus, which it will do from the start of the clock HIGH phase, in order that the slave may accept valid data by the falling edge of the clock. During a read cycle the appropriate slave must drive the data bus, such that it is valid by the end of the HIGH phase.
• Because a number of different bus slaves may drive data on to the ASB it is necessary to ensure that different slaves do not overlap when driving data onto the bus. An entire phase of non-overlap is provided as slaves and masters may not drive data during the clock LOW phase at the start of a NONSEQUENTIAL transfer.
• As many of the bus signals are shared and have turnaround periods when there is no active driver, it is necessary to ensure that bus hold cells are provided to prevent floating levels being present on the bus.
Sequential transfer
A SEQUENTIAL transfer occurs when the address is related to that of the previous transfer. The control information, as indicated by BWRITE, BPROT and BSIZE, will be the same as the previous transfer.
If the SEQUENTIAL transfer follows a NONSEQUENTIAL or another SEQUENTIAL transfer, the address can be calculated by using the previous size and address. For example a burst of word accesses would be to addresses A, A+4, A+8, whereas a burst of halfword accesses would be to addresses A, A+2, A+4.
4-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

If a SEQUENTIAL transfer follows an ADDRESS-ONLY cycle then the address will be the same as that of the ADDRESS-ONLY cycle. This combination of an ADDRESS- ONLY followed by SEQUENTIAL allows both a single access using a SEQUENTIAL transfer and also allows a burst of transfers to start with a SEQUENTIAL transfer. An example of the use of an ADDRESS-ONLY followed by SEQUENTIAL is shown later in Figure 4-6.
Figure 4-4 shows a SEQUENTIAL transfer with one wait state. This closely resembles a NONSEQUENTIAL transfer.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
BD[31:0] Write
BD[31:0]
Read
BWAIT
BERROR DONE
BLAST
S-TRAN
Read access
Previous address + transfer size
Control
Data
DONE
Data
WAIT
Figure 4-4 Sequential transfer
The main differences are:
• BTRAN signals indicate a SEQUENTIAL transfer
• address is always valid in the BCLK HIGH phase at the start of the transfer
• address is related to the preceding transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-9

AMBA ASB
4.3.3
• control information remains the same as the preceding transfer
• for a write the data bus is driven throughout the entire transfer.
The data bus, BD[31:0], can be driven throughout the entire transfer because, unlike the NONSEQUENTIAL case, there is no requirement to provide a period of time to allow for bus turnaround.
Address-only transfer
An ADDRESS-ONLY transfer indicates that no data transaction is required. During an ADDRESS-ONLY transfer it is possible that the address and control information may also be invalid. The only signals that must be driven to valid levels are:
• BTRAN – to indicate the type of the next transfer
• BLOK – to allow the arbitration process to continue.
As ADDRESS-ONLY transactions do not access slaves on the bus, they only require a single cycle and therefore the BWAIT signal will be LOW. This signal is driven by the bus decoder, as no slave will be selected during the ADDRESS-ONLY cycle. A bus master may perform a number of ADDRESS-ONLY transfers in succession if it does not require the bus for data transfer.
The ADDRESS-ONLY transfer can be used in three different ways:
• •
•
as a true IDLE cycle (when the bus master does not require the bus)
to speculatively broadcast an address for the next transfer, without committing to the transfer
to provide a turnaround cycle during bus master handover.
4-10
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

If the ADDRESS-ONLY transfer is used as a true IDLE cycle then the address and control signals are not required to be valid at any point during the transfer (see Figure 4-5).
AMBA ASB
BCLK
BTRAN[1:0]
BLOK
BWAIT BERROR BLAST
A-TRAN
Decoder drives response
DONE DONE
Start of transfer End of transfer
Figure 4-5 Address-only transfer
The BLOK signal is the only exception and this must be driven to a valid level during all ADDRESS-ONLY transfers to allow the arbitration process to continue.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-11

AMBA ASB
The second use of the ADDRESS-ONLY transfer is to speculatively broadcast the address for a transfer, without actually committing to the transfer (see Figure 4-6).
Address given during Address-only transfer
Burst starts with Sequential transfer
BCLK
BTRAN[1:0] A-TRAN
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
BWAIT BERROR BLAST
DONE
S-TRAN
Address
Control
WAIT
DONE
Figure 4-6 Address-only transfer to start burst
Using an ADDRESS-ONLY transfer to speculatively broadcast the address allows address decoding to be performed by the decoder during the ADDRESS-ONLY cycle. If the bus master then commits to the burst it is possible to start the burst with a SEQUENTIAL transfer, thus removing the need for an extra DECODE cycle before the transfer starts.
4-12
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The final use of an ADDRESS-ONLY transfer is to provide a turnaround period during bus master handover (see Figure 4-7).
AMBA ASB
Address-only transfer for bus handover
First transfer of new bus master
BCLK
BTRAN[1:0] A-TRAN
BA[31:0]
BLOK BWRITE BSIZE[1:0] BPROT[1:0]
BWAIT
BERROR DONE
BLAST
S-TRAN
DONE
Address
Control
WAIT
DONE
Figure 4-7 Address-only transfer for bus master handover
A bus master which becomes granted on the bus must start with an ADDRESS-ONLY transfer and, in this case, the new bus master does not drive the address and control signals immediately, but provides a phase of turnaround before driving the signals in the LOW phase of the transfer.
Note
In this case, the address and control information will not become valid until the LOW phase of BCLK.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-13

AMBA ASB
4.4
Address decode
In an ASB-based AMBA system the address decoding is performed by a centralized decoder.
The decoder uses the type of each transfer to determine which of the following functions should be performed:
• For an ADDRESS-ONLY transfer the decoder will respond with a DONE transfer response and no slaves will be selected. During ADDRESS-ONLY transfers the decoder performs an address decode speculatively in case the ADDRESS-ONLY transfer is followed immediately by a SEQUENTIAL transfer.
• For NONSEQUENTIAL transfers (or when the previous transfer was terminated with a LAST transaction response) the decoder will insert a single wait state at the start of the transfer to allow sufficient time for address decoding (although the additional wait state may not be required in all systems).
The additional wait state inserted by the decoder is referred to as a DECODE cycle and during the DECODE cycle no select signals, DSELx, are asserted.
In the second cycle of the transfer the decoder will either select the appropriate slave or provide an ERROR transfer response.
An ERROR response is provided in the following circumstances:
• there are no slaves present at the address of the transfer
• the transfer is to a protected region of memory
• the alignment of the transfer is not supported by the memory system.
In the more usual case of a valid transfer, the decoder will assert the appropriate slave DSELx signal and allow the selected slave to provide the transfer response for the remaining cycles of the transfer.
• For SEQUENTIAL transfers the decoder asserts the appropriate DSELx signal and the selected slave provides the transfer response. It is not necessary for the decoder to decode the address as this will have been performed in a previous NONSEQUENTIAL or ADDRESS-ONLY transfer.
As the decoder does not perform an address decode on SEQUENTIAL transfers it is necessary for the slave to provide a LAST transfer response if a transfer is about to cross a memory boundary. The decoder is also responsible for generating an internal version of the LAST signal when the decoder detects that a SEQUENTIAL transfer will cross a memory boundary.
The insertion of a DECODE cycle on NONSEQUENTIAL transfers can be used to improve the performance of the system. In a typical design the time required for address decoding will increase the critical path of an access to a slave and often result in the
4-14
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

need for additional wait states. The decoder can be used to reduce this overhead by automatically inserting a DECODE cycle on NONSEQUENTIAL transfers only, but allowing SEQUENTIAL transfers to complete without additional wait states.
In some systems, typically those with a low clock frequency, additional wait states are not required for address decoding and in such systems the decoder may be simplified, such that both SEQUENTIAL and NONSEQUENTIAL transfers occur without the addition of a DECODE cycle.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-15

AMBA ASB
4.5
Transfer response
For every transfer that is initiated by a bus master a response must be generated and this is provided either by the decoder or by the selected bus slave. The transfer response is provided using the BWAIT, BERROR and BLAST signals, which are driven during the LOW phase of the clock.
Figure 4-8 shows an example of how the transfer response is used to insert three wait states in order to extend a transfer.
BCLK
BTRAN[1:0]
BA[31:0]
BD[31:0]
BWAIT BERROR BLAST
S-TRAN
WAIT WAIT WAIT DONE
Data
End of transfer
Start of transfer
Addr
Figure 4-8 Transfer response
The following transfer responses are available:
WAIT The transfer must be extended before it can complete. DONE The transfer has completed successfully.
ERROR The transfer has completed, but an error has occurred. The error condition should be signalled to the bus master so it is aware that
the transfer has been unsuccessful.
4-16
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

LAST The transfer has completed successfully, but the slave is unable to accept further burst transfers or a memory boundary has been
reached. This response is identical to DONE for the bus master, but indicates to the decoder that it must insert a DECODE cycle at the start of the next transfer.
RETRACT The transfer has not yet completed, so the bus master should retry the transfer. The RETRACT response can be used by a slave to
signal to a bus master that the transfer can complete, but this may take a number of bus cycles.
Using the RETRACT response prevents the bus from being locked up by a transfer which may take a long time to complete and frees the bus for use by a higher priority bus master.
Unlike the other response codes, which take a single cycle, the RETRACT response is a two-stage response, as shown in Figure 4-9.
AMBA ASB
BCLK
BA[31:0]
BWAIT
BLAST
BERROR
BD[31:0]
Current transfer
Next transfer
Address
Retract next cycle
Retract
Figure 4-9 Retract operation
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-17

AMBA ASB
The following points should be noted:
• In the first stage the slave signals to the bus master that a RETRACT is going to take place, using the RETNEXT response (BWAIT, BLAST and BERROR all HIGH).
• In the second stage the transfer is completed when the slave provides the RETRACT response (BWAIT LOW, BLAST and BERROR both HIGH).
This two-stage response provides the bus master with adequate warning that it should not consider the transfer to have completed when the BWAIT signal goes LOW.
All bus masters must support the RETRACT mechanism, however not all slaves are required to implement the RETRACT response. Typically, a RETRACT response would only be provided by a slave which does not have a short guaranteed completion time and hence could deadlock the bus for a significant period of time.
For most transfers the response will be provided by the selected bus slave, however the decoder provides the response when:
• • •
the transfer is ADDRESS-ONLY
the transfer is to an area of memory where there are no bus slaves an access violation occurs to a protected region of memory.
4-18
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.6 Multi-master operation
The AMBA bus specification supports multiple bus masters on the high-performance ASB. A simple two-wire request and grant mechanism is implemented between the arbiter and each bus master. The arbiter ensures that only one bus master is active on the bus and also ensures that when no masters are requesting the bus a default master is granted.
The specification also supports a shared lock signal. This allows bus masters to indicate that the current transfer should not be separated from the following transfer and will prevent other bus masters from gaining access to the bus until the locked transfers have completed.
Efficient arbitration is important to reduce dead-time between successive masters being active on the bus. The bus protocol supports pipelined arbitration, such that arbitration for the next transfer is performed during the current transfer.
The arbitration protocol is defined, but the prioritization is flexible and left to the application. Typically, however, the test interface would be given the highest priority to ensure test access under all conditions. Every system must also include a default bus master, which is granted the bus when no bus masters are requesting it.
The request signal, AREQx, from each bus master to the arbiter indicates that the bus master requires the bus. The grant signal from the arbiter to the bus master, AGNTx, indicates that the bus master is currently the highest priority master requesting the bus.
The bus master:
• must drive the BTRAN signals during BCLK HIGH when AGNTx is HIGH
• will become granted when AGNTx is HIGH and BWAIT is LOW on a rising edge of BCLK.
The shared bus lock signal, BLOK, indicates to the arbiter that the following transfer is indivisible from the current transfer and that no other bus master should be given access to the bus.
A bus master must always drive a valid level on the BLOK signal when granted the bus to ensure that the arbitration process can continue, even if the bus master is not performing any transfers.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-19

AMBA ASB
4.6.1
Arbiter
4.6.2
Bus master handover
Bus master handover occurs when a bus master, which is not currently granted the bus, becomes the new granted bus master.
A bus master becomes granted when AGNTx is HIGH and BWAIT is LOW. AGNT HIGH indicates that the bus master is currently the highest priority master requesting the bus and BWAIT LOW indicates the previous transfer has completed.
The arbiter functions as follows:
1. Bus masters assert AREQx during the HIGH phase of BCLK.
2. The arbiter samples all AREQx signals on the falling edge of BCLK.
3. During the LOW phase of BCLK the arbiter also samples the BLOK signal and then asserts the appropriate AGNTx signal:
• if BLOK is LOW, then the arbiter will grant the highest priority bus master
• if BLOK is HIGH, then the arbiter will keep the same bus master granted.
The arbiter can update the grant signals every bus cycle. However, a new bus master can only become granted and start driving the bus when the current transfer completes, as indicated by BWAIT being LOW. Therefore, it is possible for the potential next bus master to change during waited transfers.
The BLOK signal is ignored by the arbiter during the single cycle of handover between two different bus masters.
If no bus masters are requesting the bus then the arbiter must grant the default bus master.
The arbitration protocol is defined, but the prioritization is flexible and left to the application. A simple fixed-priority scheme may be used. Alternatively, a more complex scheme can be implemented if required by the application.
4-20
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 4-10 shows the bus master handover process.
AMBA ASB
BCLK
AREQ
AGNT
BTRAN[1:0]
BA[31:0]
BD[31:0]
BWAIT BERROR BLAST
C0
A-TRAN
Previous transfer address
Previous transfer data
WAIT
A-TRAN
A-TRAN
Last transfer completes
DONE
S-TRAN
Address
Decoder drives response
DONE
C1
Previous transfer
C2
C3
New mast
C4
er granted
WAIT
Data
Slave drives response
DONE
The following points should be noted:
• When AGNTx is asserted a bus master must drive the BTRAN signals during BCLK HIGH. This may continue for many cycles if the previous transfer is waited.
• Prior to handover BTRAN must indicate an ADDRESS-ONLY cycle because the new bus master must commence with an ADDRESS-ONLY cycle to allow for bus turnaround.
• When the previous transfer completes the new bus master will become granted.
• In the last clock HIGH phase of the previous transfer the address bus will stop being driven by the previous bus master.
Figure 4-10 Bus master handover
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-21

AMBA ASB
4.6.3
4.6.4
• The new bus master starts to drive the address bus and control signals during the clock LOW phase. The first transfer may then commence in the following bus cycle.
During a waited transfer, bus master handover may be delayed and it is possible that the AGNTx to a particular bus master may be asserted and then negated, if another higher priority bus master then requests the bus, before the current transfer has completed.
Default bus master
Every system must be designed with a single default bus master, which will be granted when no other bus master is requesting the bus. The default bus master is responsible for driving the following signals to ensure the bus remains active:
• BTRAN must be driven to indicate ADDRESS-ONLY transfer
• BLOK must be driven LOW.
Locked transfers
It is important that bus masters do not attempt to perform locked transfers to slaves which can give a RETRACT response. There are two reasons for this:
• •
The bus could remain locked for a large number of cycles.
If the RETRACT occurs on the last transfer of the locked sequence, then the arbiter could have changed ownership of the bus to the next master before it completes and therefore the final transfer will not have been locked to the sequence.
4-22
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.7
Reset operation
The reset signal, BnRES, is active LOW and may be asserted asynchronously to guarantee the bus is in a safe state. During reset the following actions occur on the bus:
• the arbiter grants the default bus master
• the default bus master must:
• drive BTRAN to indicate ADDRESS-ONLY transfer
• drive BLOK LOW to allow arbitration.
• all other bus masters tristate shared bus signals
• the decoder must:
• de-assert all slave select signals, DSELx
• provide the appropriate transfer response.
• all slaves tristate shared bus signals.
Exit from reset
Figure 4-11 shows an example of the exit from reset sequence.
4.7.1
AMBA ASB
BCLK
BnRES
BTRAN[1:0]
BA[31:0]
BWAIT BERROR BLAST
C0
C1
C2
C3
A-TRAN
S-TRAN
Address
DONE
DONE WAIT
DONE
Figure 4-11 Exiting from reset
The following points should be noted:
• During cycle C1 BnRES is de-asserted during the clock LOW phase.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-23

AMBA ASB
•
•
During the clock HIGH phase of cycle C1 the default bus master may drive the BTRAN signal to indicate that it wishes to start a transfer.
The transfer will start during cycle C2 and, in the example shown, the transfer is waited and continues into cycle C3.
4-24
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.8
Description of ASB signals
4.8.1
4.8.2
Clock
Reset
This section provides more detailed information about all the AMBA ASB signals, including their intended use and phase-accurate timing requirements.
It is necessary to ensure that bus hold cells are provided to prevent floating levels being present on the bus. This is possible because many of the bus signals are shared, and have turnaround periods when there is no active driver.
BCLK is the primary clock, which is used to time all bus transfers. Both edges of the clock are used.
A single active LOW reset signal, BnRES, is supported which is used to reset the bus. The reset signal may be asserted LOW asynchronously during either clock phase, but is always de-asserted during the LOW phase of BCLK.
Figure 4-12 Reset signal
During reset the following actions occur on the bus:
• the arbiter grants the default bus master
• the default bus master must:
• drive BTRAN to indicate ADDRESS-ONLY transfer
• drive BLOK LOW to allow arbitration.
• all other bus masters tristate shared bus signals
• the decoder must:
• de-assert all slave select signals, DSELx
• provide the appropriate transfer response.
• all slaves tristate shared bus signals.
The BnRES signal may be used to reset the bus during time-out conditions.
AMBA ASB
BCLK
BnRES
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-25

AMBA ASB
4.8.3
In the majority of bus masters and slaves the BnRES signal will be used to reset both the bus interface and the main core of the component. However, it is acceptable for some system elements, such as a real-time clock, to use BnRES to only reset the bus interface. Such system elements would typically have a second reset input to allow the component core to be reset at initial power-up and for testing purposes.
Transfer type
Before a transfer starts the bus master indicates which type of the transfer it is, using BTRAN[1:0]. The following transfer types can be set:
• ADDRESS-ONLY
• NONSEQUENTIAL
• SEQUENTIAL.
Table 4-1 shows the encoding of the BTRAN[1:0] signals:
BTRAN [1] [0]
Transfer type
Description
Table 4-1 BTRAN encoding
00 ADDRESS-ONLY
01 –
10 NONSEQUENTIAL
11 SEQUENTIAL
Used when no data movement is required. The three main uses for ADDRESS-ONLY transfers are:
• for IDLE cycles
• for bus master handover cycles
• for speculative address decoding without committing to a data transfer.
Reserved
Used for single transfers or for the first transfer of a burst. The address of the transfer is unrelated to the previous bus access.
Used for successive transfers in a burst. The address of a SEQUENTIAL transfer is always related to the previous transfer.
From the table it can be deduced that BTRAN[1] can be used to determine that a data transfer is required next cycle.
4-26
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

The BTRAN signals are driven by a bus master during the HIGH phase of BCLK when the AGNTx input is HIGH (see Figure 4-13).
AMBA ASB
BCLK BTRAN[1:0]
Transfer type
Figure 4-13 BTRAN timing
In a multi-master system, the bus master that drives BTRAN may change during an extended transfer. Therefore, BTRAN must only be considered valid when the previous transfer has completed, as indicated by BWAIT LOW.
4.8.4 Address and control information
4.8.5 Address bus
The address and control signals are:
• address bus – BA[31:0]
• transfer direction – BWRITE
• transfer size – BSIZE[1:0]
• protection information – BPROT[1:0].
The 32-bit address bus, BA[31:0], provides the address of the transfer. All transfers are memory-mapped and therefore all memory and peripherals within the system must have an address range within which they are accessed. The decoder uses the address bus (usually the higher order bits) to determine which bus slave is to be accessed.
4.8.6 Transfer direction
The BWRITE signal is used to indicate the direction of the transfer (see Table 4-2). When BWRITE is LOW the transfer is a read access and when BWRITE is HIGH the transfer is a write access.
BWRITE
0 1
Table 4-2 BWRITE encoding Transfer direction
Read transfer
Write transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved.
4-27

AMBA ASB
4.8.7
Transfer size
4.8.8
Protection information
The bus master may use the BPROT signals to provide additional information about the transfer it is performing (see Table 4-4). This information is primarily intended for use by the decoder when it is acting as a bus protection unit and the majority of bus slaves will not use these signals.
BSIZE[1:0] encodes the size of a transfer (see Table 4-3). Byte, halfword and word are all defined, with the final encoding being reserved for future use.
BSIZE [1] [0]
0 0
0 1
1 0
1 1
Table 4-3 BSIZE encoding
Transfer width
Byte (8 bits) Halfword (16 bits) Word (32 bits) Reserved
When performing transfers that are narrower than the data bus, such as a byte or halfword transfer, the bus master may replicate the data across the bus, making the bus master effectively bi-endian. When responding to read cycles, a typical slave will not replicate the data on the bus and therefore it is important that the master is expecting data on the same byte lane as that which the slave is driving.
BPROT [1] [0]
– 0
– 1
0 –
1 –
Table 4-4 BPROT encoding
Transfer privilege
Opcode fetch Data access
User access Privileged access
4-28
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

4.8.9 Address and control signal timing
The address and control information is generated by the bus master from the rising edge of BCLK. However, the timing of the address and control information is considered separately for NONSEQUENTIAL and SEQUENTIAL transfer types. This is because a bus master will typically have significantly different timing parameters in each case.
It is a common characteristic that bus masters will have fast address and control output valid timings for SEQUENTIAL transfers, as shown in Figure 4-14. This is because a bus master is usually able to generate a SEQUENTIAL address well before the start of the transfer and therefore the output valid time from the bus master is mainly dependent on the time required to drive the new value onto the bus.
Figure 4-14 Sequential address and control timing
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
S-TRAN
Sequential address
Start of transfer
Sequential control
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-29

AMBA ASB
For NONSEQUENTIAL transfers the bus master will often have significantly slower output valid times for address and control signals, compared to those for SEQUENTIAL transfers and this is shown in Figure 4-15.
BCLK
BTRAN [1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
BCLK
BTRAN [1:0]
BA [31:0]
BWRITE BSIZE [1:0] BPROT [1:0]
N-TRAN
Nonsequential address
Nonsequential control
Start of transfer
N-TRAN
Start of transfer
Nonsequential address
Nonsequential control
Figure 4-15 Nonsequential address and control timing with low-frequency and high-frequency clocks
In systems where the clock frequency is approaching the maximum possible, it is common for the address and control output valid time to be greater than a clock phase, thus resulting in the address not becoming valid until the BCLK LOW phase at the start of the transfer, as shown in Figure 4-15.
4-30
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

For ADDRESS-ONLY transfers the address and control information is not valid. In the special case of the ADDRESS-ONLY followed immediately by a SEQUENTIAL transfer, as shown in Figure 4-16, the bus master generates the address and control information during the ADDRESS-ONLY transfer, such that it is valid throughout the BCLK HIGH phase before the start of the SEQUENTIAL transfer.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
A-TRAN
S-TRAN
Address
Control
Start of transfer
Figure 4-16 Address-only followed by sequential transfer address and control timing
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-31

AMBA ASB
4.8.10
Tristate enable of address and control signals
A bus master may only drive the address and control signals when the bus master is granted the bus. To allow for a period of bus turnaround, when a bus master is first granted the bus it will not drive in the BCLK HIGH phase before the first transfer. Instead, the bus master must always start a period of bus ownership with an ADDRESS- ONLY transfer and the address and control signals are not driven until the BCLK LOW phase of the ADDRESS-ONLY transfer (see Figure 4-17).
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
Previous bus master
A-TRAN
New bus master
S-TRAN
Previous transfer completes
Address-only after bus turnaround
Sequential transfer
Figure 4-17 Address and control signals during bus master handover
For multi-master systems:
•
•
•
When the master is first granted, the signals are not driven until the first LOW phase of BCLK when the master becomes active on the bus.
When a bus master is granted the bus it drives the address and control signals during both phases of BCLK.
The bus master stops driving the signals in the last BCLK HIGH phase, when the master loses mastership of the bus.
4-32
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.8.11 Slave select signals
Each ASB slave in the system has a DSEL select input signal. This signal indicates that the slave is responsible for supplying a transfer response and that a data transfer is required. The signal name DSELx is used to indicate the DSEL signal to slave x.
There is one DSELx signal for each slave on the ASB and these signals are generated by the decoder. Only one DSELx signal will be active during a transfer and there may be cycles when no DSELx signal is active, such as during ADDRESS-ONLY transfers.
DSELx changes during the BCLK HIGH phase before the start of a transfer and remains valid during the transfer. It will change for the next transfer in the BCLK HIGH phase following a transfer response with BWAIT LOW.
When designing a system there are two options for the implementation of an ASB decoder:
• Decoder with decode cycles
• Decoder without decode cycles on page 4-34.
This choice is fixed at the design stage and will be based on a timing analysis of the system. In general, a system that is operating up to the maximum speed of the processor will require DECODE cycles. It is only those systems which operate at a frequency significantly lower than the possible maximum that do not require DECODE cycles.
Decoder with decode cycles
In systems with a high clock frequency the critical path to decode the address and select a slave within a single clock phase tends to limit the maximum bus clock speed. In such systems the decoder can be used to automatically insert a wait state, or DECODE cycle, at the start of every NONSEQUENTIAL transfer. This implementation allows SEQUENTIAL transfers to continue to operate without the addition of a wait state, as it is known that the address decoding critical path can be avoided on SEQUENTIAL transfers, thus resulting in an overall improvement in bus bandwidth.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-33

AMBA ASB
For NONSEQUENTIAL transfers DSELx is asserted in the BCLK HIGH phase during the DECODE cycle, as shown in Figure 4-18 below.
Decode cycle
BCLK
BTRAN[1:0]
BA [31:0]
DSELx
BWAIT BERROR BLAST
N-TRAN
Nonsequential address
WAIT WAIT DONE
Start of transfer
End of transfer
Figure 4-18 Select signal timing with decode cycle
• When DECODE cycles are implemented the timing of DSELx is dependent only on BTRAN[1:0] and there is no timing dependency on the address and control signals. This is because no DSELx signals are asserted for ADDRESS-ONLY transfers.
• For a NONSEQUENTIAL transfer the DECODE cycle is inserted to provide an entire phase for the address and control information to become valid.
• For SEQUENTIAL transfers the address and control information from the previous cycle is used.
Decoder without decode cycles
In systems with a low clock frequency the address and control information will be valid in time to decode the address and select a slave within a single clock phase. In such systems a DECODE cycle is not required (see Figure 4-19).
4-34
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 4-19 Select signal timing without decode cycle
The select signal becomes valid during the HIGH phase of BCLK before the transfer commences and remains valid throughout the transfer, until the HIGH phase of the last cycle.
When the decoder does not insert DECODE cycles, the timing of DSELx becomes dependent on the timing of the address and control signals generated by the currently granted bus master.
4.8.12 Transfer response
The transfer response signals are used by slave devices to indicate the status of a transfer.
A valid transfer response must be provided during the LOW phase of BCLK. Whenever a slave is selected (as indicated by DSELx being asserted) the slave must provide the response. When no slave is selected, for example during an ADDRESS-ONLY transfer, the response is provided by the decoder.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
DSELx
BWAIT BERROR BLAST
Transfer type
Address
WAIT
DONE
Start of transfer
End of transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-35

AMBA ASB
Wait response
BWAIT is used to indicate when a transfer may complete. BWAIT is asserted HIGH when the slave requires extra bus cycles to complete the current transfer. BWAIT LOW indicates that the transfer may finish. Whether or not the transfer has completed successfully can only be determined by examining the other transfer response signals.
Error response
An error condition is signalled by the BERROR signal. This may be used to indicate a failed transfer, a transfer to an address where there is no slave device or a protection error.
Many simple bus slaves will not implement error logic and will therefore have a fixed response of BERROR LOW.
BERROR is also used in conjunction with BLAST to indicate a RETRACT operation. When both these signals are HIGH this indicates that a bus RETRACT is required.
Last response
BLAST is used to signal if the current transfer must be the last of a burst. This would typically be used to prevent a burst from continuing over a page boundary or other burst length limit.
BLAST is used by the decoder to make sure that the following transfer has the same characteristics as a NONSEQUENTIAL type transfer, rather than a burst transfer. Typically this involves ensuring there is adequate time to perform a new address decode.
Many bus slave devices will be able to accept any number of burst accesses and these slaves will have a fixed response of BLAST LOW.
BLAST is also used in conjunction with BERROR to indicate a RETRACT operation. When both these signals are HIGH this indicates that a bus RETRACT is required.
Bus retract
Slaves that cannot guarantee to complete transfers in a small number of wait states can potentially block the bus and stop higher priority transfers occurring. To prevent such slaves impacting the overall system latency a RETRACT mechanism is provided which allows a slave to indicate that a transfer is unable to complete at present, but the operation should be retried until it is able to complete successfully.
4-36
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

A RETRACT is performed in a two stage process, as shown in Figure 4-20.
AMBA ASB
Current transfer
Next transfer
BCLK
BA[31:0]
BWAIT
BLAST
BERROR
BD[31:0]
Address
Retract next cycle
Retract
Figure 4-20 Retract operation
• First the slave responds with BWAIT, BLAST and BERROR all HIGH, which indicates that a RETRACT is to occur and the transfer will finish in the next bus cycle.
• In the second cycle the transfer response is BWAIT LOW, BLAST and BERROR both HIGH. This indicates that the transfer has RETRACTed and that the bus is free to be used.
Basic slaves, which have a guaranteed completion time, do not need to support the bus RETRACT mechanism.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-37

AMBA ASB
Response combinations
Table 4-5 shows the combinations of the three slave transfer response signals.
Table 4-5 Transfer response combinations
BWAIT BLAST BERROR Status
0 0 0 DONE 0 0 1 ERROR 0 1 0 LAST
0 1 1 RETRACT
1 0 0 WAIT
1 0 1 –
1 1 0 –
1 1 1 RETNEXT
Description
Complete, transfer successful Complete, transfer error
Complete, cannot continue with burst Complete, bus RETRACT Incomplete, insert wait cycle Reserved
Reserved
Bus RETRACT next cycle
To ensure that the bus remains synchronized, a transfer response must be driven every cycle. During bus transfers, when a slave is selected and its appropriate DSELx signal is asserted, the slave is responsible for driving the transfer response signals.
The bus decoder is responsible for driving the transfer response signals during:
• • • • •
ADDRESS-ONLY transfers
DECODE cycles
transfers to an address space where no slave is defined
transfers to protected areas, when the access permissions are not met unaligned transfers which are not supported by the memory system.
4-38
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Transfer response timing
The transfer response signals must be set up valid before the rising edge of BCLK (see Figure 4-20).
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWAIT
BLAST
BERROR
BD[31:0]
Transfer type
Address
Data
Figure 4-21 Transfer response signal timing
The signals are not driven during the HIGH phase of BCLK to allow an entire phase of turnaround between signal drivers.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-39

AMBA ASB
4.8.13
Data bus
The bidirectional data bus, BD[31:0], is used to transfer data between bus masters and slaves. The size and direction of the transfer is given by the control signals, as described in Address and control information on page 4-27.
The data bus must not be driven during the first BCLK LOW phase of a NONSEQUENTIAL transfer. It may be driven, by the appropriate master or slave, at all other times except reset.
During a write transfer:
• the master drives the data bus during all phases of the transfer, except the first
BCLK LOW phase of a NONSEQUENTIAL transfer
• the slave does not drive the bus. During a read transfer:
• The master does not drive the data bus.
• The slave must drive the data bus during the last BCLK HIGH phase of the transfer. For the rest of the transfer, the slave may drive the data bus or leave it tristate, with the provision that it is not driven during the first BCLK LOW phase of a NONSEQUENTIAL transfer.
The following diagrams show some examples of how the data bus is driven.
4-40
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 4-22 shows an example of a NONSEQUENTIAL write transfer.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE
BD[31:0]
N-TRAN
Address
Data
Figure 4-22 Nonsequential write transfer
The data bus is driven by the bus master, except for the BCLK LOW phase of the first cycle. Not driving the data bus at the start of NONSEQUENTIAL transfers provides a full phase of turnaround between different data bus drivers.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-41

AMBA ASB
When a write transfer is extended using BWAIT, the data remains valid through the BCLK LOW phase of the extra cycles that are required to complete the transfer, as shown in Figure 4-23.
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE
BWAIT
BD[31:0]
N-TRAN
Address
Data
Figure 4-23 Extended write transfer
4-42
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

For SEQUENTIAL transfers the bus master may drive data during the LOW phase of BCLK at the start of the transfer, as shown in Figure 4-24. This is permitted as a phase of turnaround is not required for SEQUENTIAL transfers.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE
BD[31:0]
S-TRAN
Address
Data
Figure 4-24 Sequential write transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-43

AMBA ASB
During read cycles the slave drives the data bus and, as in the write cycle case, for NONSEQUENTIAL transfers the data bus is not driven in the BCLK LOW phase of the first cycle (see Figure 4-25). The bus slave may then drive the bus throughout the rest of the transfer.
BCLK
BTRAN[1:0]
BA[31:0]
BWRITE
BD[31:0]
Transfer type
Address
Data
4.8.14
Figure 4-25 Read transfer
There is no requirement for the slave to drive the data bus throughout the transfer. The only requirement is that the data is driven such that it is valid by the end of the last BCLK HIGH phase of the transfer.
Arbitration signals
AREQx – Bus request
AREQx is the request signal from a master to the arbiter which indicates that the master requires the bus. Each master has an AREQx signal, which changes during the HIGH phase of BCLK.
AGNTx – Bus grant
The grant signal from the arbiter to a bus master indicates that the bus master is currently the highest priority master requesting the bus. There is an AGNTx signal for each bus master in the system.
4-44
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

It is important to note that AGNTx does not indicate which master is currently granted the bus. Instead, it shows which master is currently the highest priority and at the completion of a transfer, as indicated by BWAIT LOW, the master which has AGNTx asserted is granted the bus.
AGNTx is changed by the arbiter during the LOW phase of BCLK and remains valid through the HIGH phase.
When AGNTx is HIGH, the master must:
• drive the BTRAN signals during BCLK HIGH
• become granted when BWAIT is LOW.
BLOK – Bus lock
BLOK is the shared bus lock signal. This signal indicates the following transfer is indivisible from the current transfers and no other bus master should be given access to the bus.
A master must always drive a valid level on the BLOK signal when granted the bus, even if the master is not performing any transfers. This is necessary to ensure the arbitration process can continue.
If BLOK is LOW the arbiter will grant the highest priority master requesting the bus. If BLOK is HIGH the arbiter will keep the same master granted.
BLOK is sampled by the arbiter during the LOW phase of BCLK and it must be valid such that the arbiter can generate valid AGNTx outputs before the rising edge of BCLK. BLOK is ignored by the arbiter during the bus master handover cycle.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-45

AMBA ASB
4.9
About the ASB AMBA components
This section describes each of the elements in an AMBA system and provides the generic timing parameters that are required to analyze an ASB-based AMBA design.
The following notation is used for the timing parameters:
• Tis – input setup time
• Tih – input hold time
• Tov – output valid time
• Toh – output hold time.
Unless otherwise stated, the timing parameters apply to both the rising and falling edges of the signal. Tristate enable and disable times are not explicitly specified. All tristate disable times must be less than a phase of BCLK to prevent a bus clash occurring. In certain cases the tristate enable time may need to be factored in to the output valid time if the enabling of the tristate driver is the dominant factor.
4-46
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.10
ASB bus slave
An ASB bus slave responds to transfers initiated by bus masters within the system. The slave uses a DSEL select signal from the decoder to determine when it should respond to a bus transfer. All other signals required for the transfer, such as the address and control information, will be generated by the bus master.
The decoder greatly simplifies the slave interface and removes the need for the slave to understand the different types of transfer that may occur on the bus.
4.10.1
Interface diagram
Figure 4-26 shows an ASB bus slave interface.
4.10.2
Bus slave interface description
The bus slave interface is described in terms of:
• Transfer response
• Data on page 4-48.
Transfer response
A slave must provide a transfer response in the LOW phase of BCLK when DSEL is asserted. Using the BWAIT, BERROR and BLAST signals one of the following responses must be generated.
WAIT The transfer must be extended before it can complete.
AMBA ASB
Select DSEL
Address and control
BA[31:0]
BWRITE BSIZE[1:0]
Reset BnRES Clock BCLK
ASB slave
BWAIT
BERROR Transfer
BLAST
response
BD[31:0] Data
Figure 4-26 ASB bus slave interface
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-47

AMBA ASB
DONE The transfer has completed successfully.
LAST The transfer has completed successfully, but the slave is unable to accept further burst transfers or a memory boundary has been
reached.
ERROR The transfer has not completed successfully. The error condition will be signalled to the bus master so that it is aware the transfer
has not completed correctly.
RETRACT The transfer has not yet completed, so the bus master should retry the transfer. The RETRACT response is used by a slave to prevent the bus from being locked up by a transfer which may take many
cycles to complete.
Many slaves will only use the WAIT and DONE responses and in this case, when a
transfer response is supplied, both BERROR and BLAST will be LOW.
When the slave is not selected, as indicated by DSEL LOW, the transfer response
signals must be tristate. The response signals must also be tristate during reset.
Data
The slave interface is implemented as a simple state machine, operating from the falling edge of the clock to determine when data transfer can occur. During reset the state machine enters the NOT_SELECTED state (see Figure 4-27).
Figure 4-27 ASB slave bus interface state machine
For write transfers the slave samples the data on the falling edge of the clock when in the SELECTED state. If required, the slave may extend the transfer using the transfer response signals described above.
For read transfers the slave must drive the data bus during the last clock HIGH phase of the transfer.
If the transfer is extended, by the insertion of wait cycles, then the slave may either drive the data bus during the additional cycles of the transfer, or alternatively it may leave the data bus tristate until the last phase of the transfer.
NOT_SELECTED
DSEL
!DSEL
SELECTED
4-48
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

To avoid the slave having to determine whether the transfer is SEQUENTIAL or NONSEQUENTIAL it is usually simpler to design a slave which does not drive the data bus during the first phase of any transfer.
During reset or when the slave is NOT_SELECTED the data bus must be tristate.
4.10.3 Timing diagrams
The timing parameters related to an access to an ASB bus slave are shown in Figure 4-28.
AMBA ASB
BCLK
BnRES
Tihnres
DSEL
BA[31:0]
BWRITE BSIZE[1:0]
BD[31:0]
Write
BD[31:0]
Read
BWAIT BERROR BLAST
Tisnres
Tisa
Tisctl
Tclkl
Tclkh
Tisdsel
Address
Control
Tihdsel
Tiha
Tihctl
Data Tisdw
Tihdw Data
Tohdr
Tovresp
Tovdr
Tohresp
Figure 4-28 ASB slave transfer
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 4-49

AMBA ASB
4.10.4
Timing parameters
The timing parameters related to an ASB bus slave are given for input signals in Table 4-6 and for output signals in Table 4-7. Bidirectional signals can be found in both tables.
Table 4-6 ASB slave input parameters
Parameter
Tclkl Tclkh Tisnres Tihnres Tisdsel Tihdsel Tisa Tiha Tisctl Tihctl Tisdw Tihdw
Parameter
Tovresp Tohresp Tovdr Tohdr
Description
BCLK LOW time
BCLK HIGH time
BnRES de-asserted setup to rising BCLK
BnRES de-asserted hold after falling BCLK
DSEL setup to falling BCLK
DSEL hold after rising BCLK
BA[31:0] setup to falling BCLK
BA[31:0] hold after rising BCLK
BWRITE and BSIZE[1:0] setup to falling BCLK BWRITE and BSIZE[1:0] hold after rising BCLK For write transfers, BD[31:0] setup to falling BCLK For write transfers, BD[31:0] hold after falling BCLK
Table 4-7 ASB slave output parameters
Description
BWAIT, BERROR and BLAST valid after falling BCLK BWAIT, BERROR and BLAST hold after rising BCLK For read transfers, BD[31:0] valid after rising BCLK
For read transfers, BD[31:0] hold after falling BCLK
4-50
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

Note
If the bus slave is designed such that the decoder, address and control signals are all sampled on the falling edge of BCLK then an entire phase of input hold time is guaranteed by the bus protocol.
You can ensure that an entire phase of hold time is provided on the data bus by inserting an extra wait state into the transfer.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-51

AMBA ASB
4.11
ASB bus master
An ASB bus master has the most complex bus interface in an AMBA system. Typically an AMBA system designer would use predesigned bus masters and therefore would not need to be concerned with the detail of the bus master interface.
A bus master interface may also include a slave interface, either for test or for programming the operation of the bus master. In such cases a number of the interface signals will become shared between the master interface and slave interface.
Interface diagram
The interface diagram of an ASB bus master shows the main signal groups.
4.11.1
Arbiter AGNT grant
BWAIT
Transfer BERROR
response
BLAST
Reset BnRES Clock BCLK
ASB master
AREQ BLOK
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
BD[31:0]
Arbiter Transfer type
Address and control
Data
4.11.2
Figure 4-29 ASB bus master interface diagram
Bus master interface description
The bus master interface consists of two state machines:
• •
the first state machine determines if the master is currently granted the bus
the second, more complex, state machine is used to control the bus interface of the master.
4-52
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

GRANTED state machine
The GRANTED state machine is used to determine whether or not the bus master has been granted the bus. It is synchronized to the rising edge of BCLK and has only two states, GRANTED and NOT_GRANTED. The state diagram is shown in Figure 4-30.
AMBA ASB
BWAIT + !AGNT
NOT_GRANTED (GRANTED = 0)
!BWAIT & AGNT
!BWAIT & !AGNT
BWAIT + AGNT
GRANTED (GRANTED = 1)
Figure 4-30 Bus master granted state machine
The output from the state machine is the GRANTED signal, which is used in the main bus master state machine.
Note
The AGNT signal may be asserted for a number of clock cycles, but it is only when AGNT is asserted and BWAIT is LOW that the bus master actually becomes GRANTED.
An important design consideration is that the state machine may be asynchronously reset into either state depending on the value of the AGNT signal. During reset one bus master in the system is set as the default bus master, as indicated by AGNT being asserted during reset, and will be reset into the GRANTED state. All other bus masters will be reset into the NOT_GRANTED state.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-53

AMBA ASB
4.11.3
Bus interface state machine
The main bus interface state machine is falling edge triggered and contains six states. The entire state diagram, shown in Figure 4-32, is quite complex but can be considered in four quadrants as shown in Figure 4-31:
NO TRANSFER REQUEST NOT GRANTED
TRANSFER REQUEST NOT GRANTED
NO TRANSFER REQUEST GRANTED
TRANSFER REQUEST GRANTED
Figure 4-31 Bus interface state machine quadrants
The TRANSFER REQUEST GRANTED quadrant contains three states, which handle bus turn around and the RETRACT operation.
The two internal bus master signals, GRANTED and REQUEST, control the majority of the transitions around the state diagram (see Figure 4-32):
• GRANTED is generated from the simpler state machine described above
• REQUEST is generated directly by the bus master.
REQUEST is asserted HIGH when the bus master requires a transfer on the bus and is LOW when the bus master does not need access to the bus.
The only time when a transition around the state diagram is not controlled by GRANTED and REQUEST is when the bus master is in the ACTIVE state. In this state the transition to the next state is determined by the transfer response that is received. WAIT, DONE, LAST, ERROR and RETNEXT shown in the diagram correspond to the encodings of the transfer response signals.
4-54
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

AMBA ASB
NO TRANSFER REQUEST NOT GRANTED
TRANSFER REQUEST NOT GRANTED
!GRANTED & !REQUEST
!GRANTED
IDLE
!GRANTED & REQUEST
GRANTED & REQUEST
GRANTED & !REQUEST
!GRANTED & REQUEST
HOLD
GRANTED
!GRANTED HANDOVER GRANTED
GRANTED
!GRANTED
!GRANTED & !REQUEST
WAIT GRANTED & REQUEST
GRANTED & !REQUEST !GRANTED & !REQUEST
ACTIVE
DONE + LAST + ERROR
RETNEXT
RETRACT
BUSIDLE
GRANTED & !REQUEST
GRANTED & REQUEST !GRANTED & REQUEST
NO TRANSFER REQUEST GRANTED
TRANSFER REQUEST GRANTED
Figure 4-32 Bus master main state machine
Note that the state diagram assumes that once the bus master has made a request for a transfer, as indicated by REQUEST, then REQUEST will remain asserted until the bus master has performed a transfer.
As the main bus master state machine is operating from the falling edge of the clock it is necessary to use latched versions of the transfer response signals BW AIT, BERROR and BLAST to control the exit from the ACTIVE state.
The reset conditions are not shown on the state diagram and, in a similar manner to the granted state machine, the main bus master state machine has a complex reset term. If AGNT is asserted during reset, when BnRES is LOW, the bus master is the default bus master and enters the BUSIDLE state. However, if AGNT is not asserted during reset then the bus master enters the IDLE state.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-55

AMBA ASB
Table 4-8 indicates the actions that must occur in each state.
Name
IDLE
BUSIDLE
HOLD
HANDOVER
ACTIVE
RETRACT
Description
Table 4-8 Actions that must occur in each state Actions
The master does not require the bus and is not granted.
The master does not require the bus, but has been granted anyway.
The master requires the bus, but has not been granted.
This state provides bus turnaround when changing between different bus masters.
Active state when data transfers occur.
Exiting this state is dependent on the transfer response.
Retract state, where the rest of the elements in the system see the transfer finish, but the bus master is not advanced.
Internal BTRAN is ADDRESS-ONLY. Master clock is enabled.
Master address bus is tristate.
Master data bus is tristate.
Internal BTRAN as indicated by master. Master clock is enabled.
Master address bus enable is generated from GRANTED signal.
Master data bus is tristate.
Internal BTRAN is ADDRESS-ONLY. Master clock is disabled.
Master address bus is tristate.
Master data bus is tristate.
Internal BTRAN is SEQUENTIAL. Master clock is disabled.
Master address bus enable is generated from GRANTED signal.
Master data bus is tristate.
Internal BTRAN as indicated by master. Master clock enable is derived from BWAIT Master address bus enable is generated from GRANTED signal.
Master data bus enable is enabled if a write transaction.
Internal BTRAN is ADDRESS-ONLY. Master clock is disabled.
Master address bus enable is generated from GRANTED signal.
Master data bus enable is enabled if a write transaction.
BTRAN[1:0] tristate drivers are enabled when AGNT and BCLK are both HIGH.
Master address bus enable is used to control the tristate enable of BA[31:0], BWRITE, BSIZE[1:0], BPROT[1:0] and BLOK. Master data bus enable is used to control the tristate enable of BD[31:0].
4-56
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.11.4 Bus master timing diagrams
The following diagrams show the timing parameters related to an ASB bus master operating in an AMBA system:
• Figure 4-33 shows an ASB bus master nonsequential transfer
• Figure 4-34 shows an ASB bus master sequential transfer on page 4-58
• Figure 4-35 shows an ASB master address-only transfer on page 4-59
• Figure 4-36 shows ASB bus master arbitration and reset signals on page 4-60.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
Nonsequential
BWRITE BSIZE[1:0] BPROT[1:0]
BD[31:0]
Write
BD[31:0]
Read
BWAIT BERROR BLAST
N-TRAN
Tovtr
Tovan
Tovctln
T ohtr
Nonsequential address
Nonsequential control
Toha
Tohctl
Data
Tisdr
Tovdwn
Tohdw Data
Tisresp
Start of transfer
Tihresp
Response
End of transfer
Tihdr
Figure 4-33 ASB bus master nonsequential transfer
For the NONSEQUENTIAL transfer, shown in Figure 4-33, the address and control signals become valid in the BCLK HIGH phase before the start of the transfer. An important feature of the AMBA protocol is to allow for poor output valid times on NONSEQUENTIAL transfers, which is provided through the automatic insertion of a wait state at the start of every NONSEQUENTIAL transfer by the decoder.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-57

AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
Sequential
BWRITE BSIZE[1:0] BPROT[1:0]
BD[31:0]
Write
BD[31:0]
Read
BWAIT BERROR BLAST
S-TRAN
Tovtr
Tovas
T ohtr
Sequential address
Sequential control
Toha
Tohctl Data
Tovdws
Tohdw
Data
Tisdr
Response
Tisresp
Start of transfer
Tihresp
End of transfer
Tihdr
Figure 4-34 ASB bus master sequential transfer
A SEQUENTIAL transfer has different timing parameters for the address and control signal valid times (see Figure 4-34). In a typical bus master, the output valid times for SEQUENTIAL transfers will be far better than for NONSEQUENTIAL transfers. The output hold times for address, control and data are identical and independent of the transfer type.
The other difference between the SEQUENTIAL and NONSEQUENTIAL transfers is that during a SEQUENTIAL transfer the data may be driven during the first phase of the transfer and hence the data valid parameter is specified from the falling edge of BCLK.
4-58
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

For an ADDRESS-ONLY transfer the address and control signals may be driven in the clock HIGH phase before the start of the transfer, or in the case of bus master handover may only be driven during the clock LOW phase of the transfer itself (see Figure 4-35). The address and control valid timing parameters are only relevant when the ADDRESS- ONLY transfer is followed immediately by a SEQUENTIAL transfer and in this case the address and control signals must be driven such that they are valid during the LOW phase of the ADDRESS-ONLY transfer, which in turn means they are valid throughout the clock HIGH phase that precedes the SEQUENTIAL transfer.
AMBA ASB
BCLK
BTRAN[1:0]
BA[31:0]
address-only
BWRITE BSIZE[1:0] BPROT[1:0] BLOK
BWAIT BERROR BLAST
A-TRAN
Tovtr
T ohtr
Address Tovaa
Control Tovctla
Tisresp
Tihresp
End of transfer
DONE
Start of transfer
Figure 4-35 ASB master address-only transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-59

AMBA ASB
Figure 4-36 shows ASB bus master arbitration and reset signals.
BCLK
BnRES
Tihnres
AGNTx
AREQx
BLOK
Tisnres
Tisagnt
Tovareq
Tovlok
Tihagnt
Tohlok
Tohareq
4.11.5
Figure 4-36 ASB bus master arbitration and reset signals
The BnRES signal may be asserted asynchronously, so there is no setup and hold parameter relating to the assertion of the signal. The AREQ signal, which is an output from the bus master, changes during the HIGH clock phase and the AGNT signal, which is returned from the arbiter changes during the LOW clock phase.
Timing parameters
The timing parameters related to an ASB bus master operating in an AMBA system are also shown in textual form in the following two tables. Table 4-9 details the input signals. Table 4-10 details output signals. Bidirectional signals can be found in both tables.
Table 4-9 Bus master input timing parameters
Parameter
Tclkl Tclkh Tisnres
Description
BCLK LOW time
BCLK HIGH time
BnRES de-asserted setup to rising BCLK
4-60
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Parameter
Tihnres Tisresp Tihresp Tisdr Tihdr Tisagnt Tihagnt
Parameter
Tovtr Tohtr Tovan Tovas Tovaa Toha Tovctln
Tovctla
Tohctl Tovdwn Tovdws Tohdw
Table 4-9 Bus master input timing parameters (continued) Description
BnRES de-asserted hold after falling BCLK
BWAIT, BERROR and BLAST setup to rising BCLK BWAIT, BERROR and BLAST hold after rising BCLK For read transfers, BD[31:0] setup to falling BCLK
For read transfers, BD[31:0] hold after falling BCLK AGNT setup to rising BCLK
AGNT hold after falling BCLK
Table 4-10 Bus master output timing parameters
Description
BTRAN valid after rising BCLK
BTRAN hold after falling BCLK
For NONSEQUENTIAL transfers, BA[31:0] valid after rising BCLK
For SEQUENTIAL transfers, BA[31:0] valid after rising BCLK
For ADDRESS-ONLY transfers, BA[31:0] valid after falling BCLK
BA[31:0] hold after rising BCLK
For NONSEQUENTIAL transfers, BWRITE, BSIZE[1:0] and BPROT[1:0] valid after rising BCLK
For ADDRESS-ONLY transfers, BWRITE, BSIZE[1:0] and BPROT[1:0] valid after falling BCLK
BWRITE, BSIZE[1:0] and BPROT[1:0] hold after rising BCLK
For NONSEQUENTIAL write transfers, BD[31:0] valid after rising BCLK For SEQUENTIAL write transfers, BD[31:0] valid after falling BCLK
For write transfers, BD[31:0] hold after falling BCLK
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-61

AMBA ASB
Parameter
Table 4-10 Bus master output timing parameters (continued) Description
BLOK valid after rising BCLK BLOK hold after rising BCLK AREQ valid after rising BCLK AREQ hold after rising BCLK
Tovlok Tohlok Tovareq Tohareq
4-62
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

4.12 ASB decoder
The decoder in an AMBA system is used to perform a centralized address decoding function, which gives two main advantages:
• It improves the portability of peripherals, by making them independent of the system memory map.
• It simplifies the design of bus slaves, by centralizing the address decoding and bus control functions.
The three main tasks of the decoder are:
• address decoder
• default transfer response
• protection unit.
An ASB decoder generates a select signal for each slave on the ASB bus and, under certain circumstances, will not select any slaves and provide the transaction response itself.
The decoder greatly simplifies the slave interface and removes the need for the slave to understand the different types of transfer that may occur on the bus.
An important feature of the decoder is that it is able to improve the performance of a system by providing DECODE cycles for address decoding. As the decoder is able to recognize if the transfer is SEQUENTIAL or NONSEQUENTIAL it is a simple task for the decoder to only add a DECODE cycle when required.
The decoder actually helps to significantly improve the system performance. In a non- AMBA system the critical path of, for example, a read transfer would be as follows:
1. Address out from master.
2. Address decode to select slave.
3. Data out and response from slave back to bus master.
However, in an AMBA system it is possible to remove the middle stage whenever the bus master is performing a SEQUENTIAL transfer, because it is known that the slave that is selected will be the same as the previous transfer. The decoder can use this fact to improve the system performance by only inserting a wait state for address decoding when needed, which is for NONSEQUENTIAL transfers. This is known as inserting a DECODE cycle.
In designs where the clock frequency is low enough that an additional wait state is not required for address decoding, then the role of the decoder is simplified.
AMBA ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-63

AMBA ASB
4.12.1
Interface diagram
Figure 4-37 shows an ASB decoder.
4.12.2
Decoder description
The decoder is also used to provide a number of bus maintenance functions. Firstly, the decoder can act as a simple protection unit, which can issue an ERROR response to a bus master which attempts to access an illegal or protected area of the memory map. The decoder also provides a transfer response during ADDRESS-ONLY transfers, when no slave is selected.
Transfer type
Address and control
Reset Clock
BTRAN[1:0]
BA[31:0]
BWRITE BSIZE[1:0] BPROT[1:0]
BnRES BCLK
ASB decoder
DSEL1 DSEL1
DSELn
BWAIT
BERROR BLAST
Selects
Transfer response
Figure 4-37 ASB decoder interface diagram
There are two possible implementations of the decoder, depending on the performance requirements of the system design:
•
•
The normal implementation of a decoder will include the insertion of DECODE cycles on NONSEQUENTIAL transfers and to break up burst transfers over memory boundaries.
In some system designs, typically with a low clock frequency, the DECODE cycle will not be required and hence a simpler decoder may be implemented.
4-64
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

With decode cycles
The decoder is implemented as a state machine which operates from the falling edge of the clock and has four states (see Figure 4-38). During reset the state machine should enter the ADDRONLY state.
AMBA ASB
S-TRAN & !DecLast
ERROR
A-TRAN
A-TRAN
ADDRONLY
A-TRAN & !WAIT
N-TRAN +
S-TRAN & DecLast
DECODE
N-TRAN & !WAIT +
S-TRAN & (LAST + DecLast)
S-TRAN & DecError
N-TRAN
S-TRAN & !DecError
DecError
!DecError
SLAVESEL
WAIT + RETNEXT +
S-TRAN & (DONE + ERROR + RETRACT) & !DecLast
!WAIT = DONE + LAST + ERROR + RETRACT
Figure 4-38 Decoder state machine with decode
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-65

AMBA ASB
Transitions around the state machine are controlled by the transfer type for the next transfer, the transfer response from the current transfer and two internal decoder signals, DecLast and DecError. The WAIT, DONE, LAST, ERROR, RETNEXT and RETRACT shown on the state diagram correspond to the encodings of the transfer response signals.
DecLast is generated by the decoder when it detects that a SEQUENTIAL transfer is about to cross a memory boundary and is used in combination with the external BLAST signal to force the address to be decoded, even on SEQUENTIAL transfers.
DecError is another decoder internal signal and is generated when the decoder detects that:
• there are no slaves present at the address of the transfer
• the transfer is to a protected region of memory
• the alignment of the transfer is not supported by the memory system.
The decoder performs the following functions:
•
•
•
•
In the ADDRONLY state:
• speculatively decodes the address
• provides a DONE transfer response during the BCLK LOW phase
• asserts DSELx during the BCLK HIGH phase if the transfer type for the next transfer is S-TRAN and the address is valid.
In the DECODE state:
• • •
In the •
•
decodes the address
provides a WAIT transfer response during the BCLK LOW phase asserts DSELx during the BCLK HIGH phase if the address is valid.
SL AVESEL state:
the transfer response is driven by the selected slave
keeps DSELx asserted while the transfer is waited, or if the next transfer is SEQUENTIAL and no LAST condition is detected.
In the ERROR state:
• provides an ERROR transfer response during the BCLK LOW phase.
4-66
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Without decode cycles
A decoder which does not implement decode cycles has the DECODE state removed. This simplifies the state diagram, as shown in Figure 4-39.
AMBA ASB
A-TRAN
(N-TRAN + S-TRAN) & DecError
ERROR
A-TRAN
ADDRONLY
A-TRAN & !WAIT
(N-TRAN + S-TRAN) & DecError
(N-TRAN + S-TRAN) & !DecError
(N-TRAN + S-TRAN) & !DecError
SLAVESEL
(N-TRAN + S-TRAN) & !WAIT & DecError
WAIT + RETNEXT + ((N-TRAN + S-TRAN) & !DecError) !WAIT = DONE + LAST + ERROR + RETRACT
Figure 4-39 Decoder state machine without decode
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-67

AMBA ASB
4.12.3
Timing diagrams
The timing parameters for an ASB decoder with DECODE cycles are shown in Figure 4-40. The parameters for a decoder without DECODE cycles are shown in Figure 4-41. The main difference between the two diagrams is that when DECODE cycles are not inserted then the timing of the DSEL signal becomes dependent on the address and control signal timing.
BCLK
BnRES
Tihnres
Tisnres
N-TRAN
BTRAN[1:0]
BA[31:0]
BWRITE BPROT[1:0]
Tistr
DSEL
BWAIT BERROR BLAST
Address
Control
Tovdsel
Tohdsel
Decoder response
Slave response
Tovresp
Tisresp Tohresp
Tihresp
Tihtr
Figure 4-40 ASB decoder with decode cycles
4-68
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

AMBA ASB
BCLK
BnRES
Tihnres
Tisnres
N-TRAN
Tadsel
Tctldsel
Decoder response
Tisresp
BTRAN[1:0]
BA[31:0]
BWRITE BPROT [1:0]
Tistr
Ttrdsel
Tihtr
DSEL
BWAIT BERROR BLAST
Tohdsel
Tihresp
Address
Control
4.12.4 Timing parameters
Figure 4-41 ASB decoder without decode cycles
The timing parameters related to an ASB decoder are given in the following tables:
• Table 4-11 is for input signals
• Table 4-12 is for output signals
• Table 4-13 is for combinatorially generated outputs.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-69

AMBA ASB
Parameter
Tclkl Tclkh Tisnres Tihnres Tistr Tihtr Tisresp Tihresp
Parameter
Tovresp Tohresp Tovdsel Tohdsel
Parameter
Ttrdsel Tadsel Tctldsel
Description
Table 4-11 ASB decoder input parameters
BCLK LOW time
BCLK HIGH time
BnRES de-asserted setup to rising BCLK
BnRES de-asserted hold after falling BCLK
BTRAN setup to falling BCLK
BTRAN hold after falling BCLK
BWAIT, BERROR and BLAST setup to rising BCLK BWAIT, BERROR and BLAST hold after rising BCLK
Table 4-12 ASB decoder output parameters
Description
BWAIT, BERROR and BLAST valid after falling BCLK BWAIT, BERROR and BLAST hold after rising BCLK DSEL valid after rising BCLK
DSEL hold after rising BCLK
Table 4-13 ASB decoder combinatorial parameters
Description
Delay from valid BTRAN to valid DSEL
Delay from valid BA to valid DSEL
Delay from valid BWRITE and BPROT[1:0] to valid DSEL
4-70
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.13
ASB arbiter
4.13.1
Interface diagram
Figure 4-42 shows the signal interface of an ASB arbiter.
4.13.2
Arbiter description
The role of the arbiter in an AMBA system is to control which master has access to the bus. Every bus master has a two wire REQUEST and GRANT interface to the arbiter and on every cycle the arbiter uses a prioritization scheme to decide which bus master is currently the highest priority master requesting the bus.
A shared bus lock signal, BLOK, driven by the currently granted bus master is used to indicate that the current transfer is indivisible from the following transfer and no other master should be granted the bus.
The detail of the priority scheme is not specified and is defined for each application. It is acceptable for the arbiter to use other signals, either AMBA or non-AMBA, to influence the priority scheme that is in use.
Figure 4-42 ASB arbiter interface diagram
The bus can be re-arbitrated on every clock cycle. The arbiter samples all the request signals, AREQx, on the falling edge of BCLK and during the LOW phase of BCLK the arbiter asserts the appropriate AGNTx signal using the internal priority scheme and the value of BLOK.
As the arbitration can change every cycle, it is possible that during an extended transfer, the highest priority bus master may change several times before the transfer eventually completes. The bus master that has AGNT asserted when the transfer completes will become the next active bus master.
AMBA ASB
Arbiter requests
Wait Lock
Reset Clock
AREQx1 AREQx2 AREQx3
BWAIT BLOK
BnRES BCLK
ASB arbiter
AGNTx1 AGNTx2 AGNTx3
Arbiter grants
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-71

AMBA ASB
4.13.3
During bus master handover the BLOK signal is not driven and hence the arbiter must assume that this signal is LOW.
The arbiter must retain a copy of which master is currently granted so it can:
• keep the current bus master granted if BLOK is asserted
• determine when the bus master changes, and so determine when there is a cycle of bus master handover.
Timing diagrams
Figure 4-43 shows the arbiter timing parameters.
BCLK
BnRES
Tihnres
AREQ
AGNT
BLOK
BWAIT BERROR BLAST
Tisnres
Tisareq
Tovagnt
Tisresp
Tihareq
Tohagnt
Tlokagnt
Tihresp
Figure 4-43 ASB arbiter parameters
4-72
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

4.13.4 Timing parameters
The timing parameters related to an ASB arbiter are given in the following tables:
• • •
Table 4-14 is for input signals
Table 4-15 is for output signals
Table 4-16 is for combinatorially generated outputs.
Table 4-14 ASB arbiter input parameters
AMBA ASB
Parameter
Tclkl Tclkh Tisnres Tihnres Tisareq Tihareq Tisresp Tihresp
Parameter
Tovagnt Tohagnt
Parameter
Tlokagnt
Description
BCLK LOW time
BCLK HIGH time
BnRES de-asserted setup to rising BCLK BnRES de-asserted hold after falling BCLK AREQ setup to falling BCLK
AREQ hold after rising BCLK
BWAIT setup to rising BCLK
BWAIT hold after rising BCLK
Table 4-15 ASB arbiter output parameters
Description
AGNT valid after falling BCLK AGNT hold after falling BCLK
Table 4-16 ASB arbiter combinatorial parameters Description
Delay from valid BLOK to valid AGNT
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 4-73

Chapter 5
AMBA APB
This chapter introduces the Advanced Microcontroller Bus Architecture (AMBA) Advanced Peripheral Bus (APB) specification in the following sections:
• About the AMBA APB on page 5-2
• APB specification on page 5-4
• About the APB AMBA components on page 5-7
• APB bridge on page 5-8
• APB slave on page 5-11
• Interfacing APB to AHB on page 5-14
• Interfacing APB to ASB on page 5-20
• Interfacing rev D APB peripherals to rev 2.0 APB on page 5-22.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-1

AMBA APB
5.1
About the AMBA APB
The Advanced Peripheral Bus (APB) is part of the Advanced Microcontroller Bus Architecture (AMBA) hierarchy of buses and is optimized for minimal power consumption and reduced interface complexity.
The AMBA APB should be used to interface to any peripherals which are low- bandwidth and do not require the high performance of a pipelined bus interface.
The latest revision of the APB ensures that all signal transitions are only related to the rising edge of the clock. This improvement means the APB peripherals can be integrated easily into any design flow, with the following advantages:
• performance is improved at high-frequency operation
• performance is independent of the mark-space ratio of the clock
• static timing analysis is simplified by the use of a single clock edge
• no special considerations are required for automatic test insertion
• many Application-Specific Integrated Circuit (ASIC) libraries have a better selection of rising edge registers
• easy integration with cycle based simulators.
These changes to the APB also make it simpler to interface it to the new Advanced
High-performance Bus (AHB).
5-2
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

5.1.1 A typical AMBA-based microcontroller
An AMBA-based microcontroller typically consists of a high-performance system backbone bus, able to sustain the external memory bandwidth, on which the CPU and other Direct Memory Access (DMA) devices reside, plus a bridge to a narrower APB bus on which the lower bandwidth peripheral devices are located. Figure 5-1 shows the APB in a typical AMBA system.
AMBA APB
High-performance ARM processor
High-bandwidth on-chip RAM
B R I D G E
UART
Timer
High-bandwidth Memory Interface
AHB or ASB
APB
Keypad
PIO
DMA bus master
APB bridge
AMBA Advanced Peripheral Bus (APB)
* Low power
* Latched address and control * Simple interface
* Suitable for many peripherals
Figure 5-1 The APB in a typical AMBA system
A system bus that includes a Test Interface Controller (TIC) allows modular testing of both system bus and APB modules.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-3

AMBA APB
5.2
5.2.1
APB specification
The APB specification is described under the following headings:
• State diagram
• Write transfer on page 5-5
• Read transfer on page 5-6.
State diagram
The state diagram, shown in Figure 5-2, can be used to represent the activity of the peripheral bus.
IDLE PSELx = 0 PENABLE = 0
Transfer
SETUP PSELx = 1 PENABLE = 0
ENABLE PSELx = 1 PENABLE = 1
No transfer Transfer
No transfer
Figure 5-2 State diagram
Operation of the state machine is through the three states described below:
IDLE SETUP
The default state for the peripheral bus.
When a transfer is required the bus moves into the SETUP state, where the appropriate select signal, PSELx, is asserted. The bus only remains in the SETUP state for one clock cycle and will always move to the ENABLE state on the next rising edge of the clock.
5-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

ENABLE
In the ENABLE state the enable signal, PENABLE is asserted. The address, write and select signals all remain stable during the transition from the SETUP to ENABLE state.
The ENABLE state also only lasts for a single clock cycle and after this state the bus will return to the IDLE state if no further transfers are required. Alternatively, if another transfer is to follow then the bus will move directly to the SETUP state.
It is acceptable for the address, write and select signals to glitch during a transition from the ENABLE to SETUP states.
5.2.2 Write transfer
The basic write transfer is shown in Figure 5-3.
The write transfer starts with the address, write data, write signal and select signal all changing after the rising edge of the clock. The first clock cycle of the transfer is called the SETUP cycle. After the following clock edge the enable signal PENABLE is asserted, and this indicates that the ENABLE cycle is taking place. The address, data and control signals all remain valid throughout the ENABLE cycle. The transfer completes at the end of this cycle.
The enable signal, PENABLE, will be deasserted at the end of the transfer. The select signal will also go LOW, unless the transfer is to be immediately followed by another transfer to the same peripheral.
In order to reduce power consumption the address signal and the write signal will not change after a transfer until the next access occurs.
AMBA APB
PCLK
PADDR PWRITE
PSEL PENABLE PWDATA
T1 T2 T3 T4 T5
Addr 1
Data 1
Figure 5-3 Write transfer
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-5

AMBA APB
5.2.3
Read transfer
Figure 5-4 shows a read transfer.
The protocol only requires a clean transition on the enable signal. It is possible that in the case of back to back transfers the select and write signals may glitch.
PADDR PWRITE
PSEL PENABLE
PRDATA
T1 T2 T3 T4 T5
Addr 1
Data 1
The timing of the address, write, select and strobe signals are all the same as for the write transfer. In the case of a read, the slave must provide the data during the ENABLE cycle. The data is sampled on the rising edge of clock at the end of the ENABLE cycle.
Figure 5-4 Read transfer
5-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

5.3 About the APB AMBA components
The following notation is used for the timing parameters:
• Tis – input setup time
• Tih – input hold time
• Tov – output valid time
• Toh – output hold time.
AMBA APB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-7

AMBA APB
5.4
5.4.1
APB bridge
5.4.2
Figure 5-5 APB bridge interface diagram
APB bridge description
The bridge unit converts system bus transfers into APB transfers and performs the following functions:
The APB bridge is the only bus master on the AMBA APB. In addition, the APB bridge is also a slave on the higher-level system bus.
Interface diagram
Figure 5-5 shows the APB signal interface of an APB bridge.
System bus slave interface
Read data
PRDATA
Reset PRESETn Clock PCLK
APB bridge
PSEL1 PSEL2
PSELn PENABLE
PADDR PWRITE
PWDATA
Selects
Strobe
Address and control
Write data
• •
• • •
Latches the address and holds it valid throughout the transfer.
Decodes the address and generates a peripheral select, PSELx. Only one select signal can be active during a transfer.
Drives the data onto the APB for a write transfer.
Drives the APB data onto the system bus for a read transfer. Generates a timing strobe, PENABLE, for the transfer.
5-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

5.4.3 Timing diagrams
The timing parameters for an APB bridge are shown in Figure 5-6.
AMBA APB
PCLK
PENABLE
PSELxx
PADDR
PWRITE
PWDATA
PRDATA
Tovpen
Tohpen
C1
C2
Tovpsel
Tovpa
Tovpw
Tovpwd
Address
Data
Tohpsel
Tohpa
T ohpw
Tohpwd
Data
Tisprd
Tihprd
Figure 5-6 APB bridge transfer
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 5-9

AMBA APB
5.4.4
Timing parameters
The timing parameters related to an APB bridge are given in Table 5-1 for input signals and Table 5-2 for output signals.
Table 5-1 APB bridge input parameters
Parameter
Tclkl Tclkh Tisnres Tihnres Tisprd Tihprd
Parameter
Tovpen Tohpen Tovpsel Tohpsel Tovpa Tohpa Tovpw Tohpw Tovpwd Tohpwd
Description
PCLK LOW time
PCLK HIGH time
PRESETn de-asserted setup to rising PCLK PRESETn de-asserted hold after rising PCLK
For read transfers, PRDATA setup to rising PCLK For read transfers, PRDATA hold after rising PCLK
Table 5-2 APB bridge output parameters
Description
PENABLE valid after rising PCLK
PENABLE hold after rising PCLK
PSEL valid after rising PCLK
PSEL hold after rising PCLK
PADDR valid after rising PCLK
PADDR hold after rising PCLK
PWRITE valid after rising PCLK
PWRITE hold after rising PCLK
For write transfers, PWDATA valid after rising PCLK For write transfers, PWDATA hold after rising PCLK
5-10
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

5.5
5.5.1
APB slave
5.5.2
APB slave description
The APB slave interface is very flexible.
APB slaves have a simple, yet flexible, interface. The exact implementation of the interface will be dependent on the design style employed and many different options are possible.
Interface diagram
Figure 5-7 shows the signal interface of an APB slave.
Figure 5-7 APB slave interface description
For a write transfer the data can be latched at the following points:
• on either rising edge of PCLK, when PSEL is HIGH
• on the rising edge of PENABLE, when PSEL is HIGH.
The select signal PSELx, the address PADDR and the write signal PWRITE can be combined to determine which register should be updated by the write operation.
For read transfers the data can be driven on to the data bus when PWRITE is LOW and both PSELx and PENABLE are HIGH. While PADDR is used to determine which register should be read.
AMBA APB
Select Strobe
Address and control
Reset Clock
Write data
PSELx PENABLE
PADDR PWRITE
PRESETn PCLK
PWDATA
APB slave
PRDATA Read data
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-11

AMBA APB
5.5.3 Timing diagrams
The timing parameters related to an access to an APB bus slave are shown in Figure 5-8.
C1
C2
PCLK
PENABLE
PSELxx
PADDR
PWRITE
PWDATA
PRDATA
Tispen
T ihpen
Tispsel
Tispa
Tispw
Tispwd
Ad
Tovprd
dress
Data
T ihpsel
T ihpa
T ihpw
Tihpwd Data
Tohprd
Figure 5-8 APB slave transfer
5-12 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

5.5.4 Timing parameters
The timing parameters related to an APB slave are given in Table 5-3 for input signals and Table 5-4 for output signals.
Parameter
Tclkl Tclkh Tisnres Tihnres Tispen Tihpen Tispsel Tihpsel Tispa Tihpa Tispw Tihpw Tispwd Tihpwd
Parameter
Tovprd Tohprd
Description
Table 5-3 APB slave input parameters
PCLK LOW time
PCLK HIGH time
PRESETn de-asserted setup to rising PCLK PRESETn de-asserted hold after falling PCLK PENABLE setup to rising PCLK
PENABLE hold after rising PCLK
PSEL setup to rising PCLK
PSEL hold after rising PCLK
PADDR setup to rising PCLK
PADDR hold after rising PCLK
PWRITE setup to rising PCLK
PWRITE hold after rising PCLK
For write transfers, PWDATA setup to rising PCLK For write transfers, PWDATA hold after rising PCLK
Table 5-4 APB slave output parameters
Description
For read transfers, PRDATA valid after rising PCLK For read transfers, PRDATA hold after rising PCLK
AMBA APB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-13

AMBA APB
5.6
Interfacing APB to AHB
Interfacing the AMBA APB to the AHB is described in:
• Read transfers
• Write transfers on page 5-16
• Back to back transfers on page 5-18
• Tristate data bus implementations on page 5-19.
5.6.1
Read transfers
Figure 5-9 illustrates a read transfer.
HADDR HWRITE HRDATA
HREADY
PADDR PWRITE
PSEL PENABLE
PRDATA
T1 T2 T3 T4 T5
Addr 1
Data 1
Addr 1
Data 1
Figure 5-9 Read transfer to AHB
5-14
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-15
HADDR HWRITE HRDATA HREADY
PADDR PWRITE
PSEL PENABLE PRDATA
Addr 1
Addr 2
Addr 1
Data 1
Addr 3
Addr 2
Addr 4
Addr 3
The transfer starts on the AHB at time T1 and the address is sampled by the APB bridge at T2. If the transfer is for the peripheral bus then this address is broadcast and the appropriate peripheral select signal is generated. This first cycle on the peripheral bus is called the SETUP cycle, this is followed by the ENABLE cycle, when the PENABLE signal is asserted.
During the ENABLE cycle the peripheral must provide the read data. Normally it will be possible to route this read data directly back to the AHB, where the bus master can sample it on the rising edge of the clock at the end of the ENABLE cycle, which is at time T4 in Figure 5-9.
In very high clock frequency systems it may become necessary for the bridge to register the read data at the end of the ENABLE cycle and then for the bridge to drive this back to the AHB bus master in the following cycle. Although this will require an extra wait state for peripheral bus read transfers, it allows the AHB to run at a higher clock frequency, thus resulting in an overall improvement in system performance. A burst of read transfers is shown in Figure 5-10. All read transfers require a single wait state.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11
Data 1
Data 2
Data 3
Data 4
Addr 4
Data 4
Data 2
Data 3
Figure 5-10 Burst of read transfers
AMBA APB

AMBA APB
5.6.2
Write transfers
Figure 5-11 shows a write transfer.
T1 T2 T3 T4 T5 T6
HADDR HWRITE HWDATA HREADY
PADDR PWRITE PSEL
PENABLE PWDATA
Addr 1
Data 1
Addr 1
Data 1
Single write transfers to the APB can occur with zero wait states. The bridge is responsible for sampling the address and data of the transfer and then holding these values for the duration of the write transfer on the APB.
Figure 5-11 Write transfer from AHB
5-16
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

HADDR HWRITE HWDATA HREADY
PADDR PWRITE PSEL
PENABLE PWDATA
Addr 1
Addr 2
Data 1
Addr 3
Data 2
Addr 1
Data 1
Addr 4
Data 3
Addr 2
Data 2
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-17
A burst of write transfers is shown in Figure 5-12.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
While the first transfer can complete with zero wait states, subsequent transfers to the peripheral bus will require a single wait state for each transfer performed.
It is necessary for the bridge to contain two address registers, in order that the bridge can sample the address of the next transfer while the current transfer continues on the peripheral bus.
Data 4
Addr 3
Data 3
Addr 4
Data 4
Figure 5-12 Burst of write transfers
AMBA APB

AMBA APB
5.6.3
HADDR HWRITE HWDATA HRDATA HREADY
PADDR PWRITE PSELx
PENABLE PWDATA PRDATA
Back to back transfers
Figure 5-13 shows a number of back to back transfers. The sequence starts with a write, which is then followed by a read, then a write, then a read.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
5-18
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A
Addr 1
Addr 2
Data 1
Addr 3
Addr 1
Data 1
Addr 4
Data 3
Addr 2
Addr 3
Data 3
Addr 4
Data 2
Data 4
Data 2
Data 4
Figure 5-13 shows that if a read transfer immediately follows a write, then 3 wait states are required to complete the read. In fact, in a processor-based design a write followed by a read does not occur frequently as the processor will perform an instruction fetch between the two transfers and it is unlikely that the instruction memory would reside on the APB.
Figure 5-13 Back to back transfers

5.6.4 Tristate data bus implementations
HADDR HWRITE HWDATA HRDATA HREADY
PADDR PWRITE
PSELx PENABLE PWDATA
PRDATA PDATA
Addr 1
Addr 2
Data 1
Addr 3
Addr 1
Data 1
Data 1
Addr 4
Data 3
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved.
5-19
It is recommended that the AMBA APB is implemented with separate read and write data buses, which allows the use of either a multiplexed bus or OR-bus scheme to interconnect the various slaves on the APB. If a tristate bus is used then the read and write data buses may be combined into a single bus, as read data and write data never occur simultaneously.
Figure 5-14 illustrates that no special consideration is required if the data bus is implemented using tristate buffers. If the data bus is tristate in the SETUP cycle of a read transfer and whenever the bus is in the Idle state then an entire clock cycle of turnaround always occurs between different drivers of the data. For bursts of write transfers there is no turnaround as the bridge will drive data in the SETUP cycle of every transfer, however this is perfectly acceptable as the bridge is the only driver of the data bus for write transfers and therefore no turnaround period is required.
Figure 5-14 shows how the read and write data buses can be successfully combined into a single tristate data bus.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Addr 2
Addr 3
Data 3
Data 3
Addr 4
Data 2
Data 4
Data 2
Data 2
Data 4
Data 4
Figure 5-14 Tristate data bus
AMBA APB

AMBA APB
5.7
5.7.1
Interfacing APB to ASB
Interfacing the AMBA APB to the ASB is described in:
• Write transfer
• Read transfer on page 5-21.
Write transfer
Figure 5-15 illustrates how an interface from ASB to APB can be constructed. The write transfer can occur with zero wait-states, although an additional wait state is required for a burst of writes.
5-20
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A
BCLK
BA BWRITE BD BWAIT
PADDR PWRITE PSEL
PENABLE PWDATA
Addr 1
Data
Addr 1
Data 1
Figure 5-15 Write transfer from ASB

5.7.2 Read transfer
The read transfer will always require a single wait state (see Figure 5-16). In systems with a high clock frequency it may be necessary to insert an additional wait state to ensure that the read data has adequate time to pass through the bridge and become valid on the ASB.
AMBA APB
BCLK BA BWRITE BD BWAIT
PADDR PWRITE PSEL PENABLE PRDATA
Addr 1
Data
Addr
1
D
ata 1
Figure 5-16 Read transfer to ASB
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 5-21

AMBA APB
5.8
Interfacing rev D APB peripherals to rev 2.0 APB
When using a combination of peripherals, some designed to the revision 2.0 specification and others designed to previous revisions, it is recommended that a revision 2.0 bridge is used and the earlier version peripherals are converted for use with the new bridge.
This section shows how a single revision D peripheral may be converted to the latest version of the APB. If a number of peripherals are to be converted it is more efficient to perform the conversion in a single centralized block.
There are two fundamental differences between the rev D and rev 2.0 APB specifications:
• the timing of the strobe signal compared to the enable signal
• the point at which read data is sampled.
To quickly determine whether a peripheral is designed to the rev D or rev 2.0 specification, see if it has a PSTB input (in which case it is rev D) or a PENABLE input (in which case it is rev 2.0). Figure 5-17 shows the two stages that are required to interface an existing revision D peripheral.
PSEL
PCLK
PADDR PWRITE
PWDATA BCLK
DQ
PSTB
Revision D compatible peripheral
Data in Data out
DQ
PRDATA
Figure 5-17 Interfacing a rev D peripheral
Firstly, the PSEL signal may be used to generate a PSTB signal. A fed-back version of the PSTB signal can be used to ensure the signal is only asserted for a single clock cycle.
The second interface stage that may be required is a falling edge triggered register or transparent latch on the output data (read data) from the peripheral. This is only required if the peripheral changes the output data after the falling edge.
5-22
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Chapter 6
AMBA Test Methodology
This chapter describes the test interface used with AMBA module designs. It contains the following sections:
• About the AMBA test interface on page 6-2
• External interface on page 6-4
• Test vector types on page 6-6
• Test interface controller on page 6-7
• The AHB Test Interface Controller on page 6-12
• Example AMBA AHB test sequences on page 6-17
• The ASB test interface controller on page 6-25
• Example AMBA ASB test sequences on page 6-27.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-1

AMBA Test Methodology
6.1
About the AMBA test interface
The AMBA test philosophy allows individual modules in the system to be tested in isolation. Each module is designed so it can be tested only using transfers from the bus and does not rely on the interaction of any other system element. Therefore it is necessary to have access to the inputs and outputs of the peripheral that are not directly connected to the bus and this is provided by a test harness.
Dedicated peripheral inputs
Dedicated peripheral outputs
Test stimuli
Test results
Bus interface
Application peripheral
Figure 6-1 Peripheral test harness
6-2
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

A low gate-count Test Interface Controller (TIC) bus master module is required in the system to allow externally applied test vectors to be converted into internal bus transfers.
The TIC uses a minimal three-wire handshake mechanism to control the application of test vectors and the data path of the External Bus Interface (EBI) is used to provide a high speed 32-bit parallel vector interface.
Control
Address
Data
Figure 6-2 TIC and external bus interface interaction
To support this method of test vector application a 32-bit bidirectional port must be available during test access. For a system with an external data bus interface of 32-bits this is straightforward. 16-bit and 8-bit data bus designs require, for example, 16 or 24 address lines to be reconfigured as bidirectional test port signals for test mode access.
AMBA Test Methodology
TCLK
TREQA TREQB TACK
TBUS[31:0]
Test Interface Controller (TIC)
External Bus Interface (EBI)
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-3

AMBA Test Methodology
6.2
External interface
The external test interface consists of:
• a test clock
• three control signals
• a 32-bit test bus.
Only two dedicated signal pins are required (TREQA and TACK) to control the entry and exit of test mode. The remaining signals can be provided by reusing existing device pins.
Test bus request A
TREQA is the test bus request A input signal and is required as a dedicated device pin.
During normal system operation the TREQA signal is used to request entry into the test mode. This will cause the test bus to become tristated, allowing test vectors to be applied.
During test this signal is used, in combination with TREQB, to indicate the type of test vector that will be applied in the following cycle.
Test bus request B
TREQB is the test bus request B input signal.
During test this signal is used, in combination with TREQA, to indicate the type of test
vector that will be applied in the following cycle.
Test acknowledge
TACK is the test bus acknowledge output signal and is required as a dedicated device pin.
The test bus acknowledge signal gives external indication that the test bus has been granted and also indicates when a test access has completed. When TACK is LOW the current test vector must be extended until TACK becomes HIGH. The TREQA and TREQB signals are only sampled by the TIC when TACK is HIGH.
Table 6-1 and Table 6-2 show the operation of the TREQA, TREQB and TACK signals. The signals have different functions depending on whether or not test mode has been entered.
6.2.1
6.2.2
6.2.3
6-4
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Table 6-1 Test control signals during normal operation
AMBA Test Methodology
TREQA TREQB TACK
0 0 0
1 0 0
0 1 0 – – 1
TREQA TREQB
– – 1 1 1 0 0 1 0 0
TACK
0 1 1 1 1
Description
Normal operation
Enter test mode request
Reserved (for external master request) Test mode entered
Table 6-2 Test control signals during test mode Description
Current access incomplete
Address vector, control vector or turnaround vector Write vector
Read vector
Exit test mode
6.2.4 Test clock
6.2.5 Test bus
TCLK is the test clock input signal.
In test mode, the internal bus clock is driven from the external TCLK source. This pin may be the normal clock oscillator source input or a port replacement signal. The system bus clock must not glitch when switching between normal and test mode.
On entry into test mode the TIC indicates that it has switched to the test clock input by asserting the TACK signal.
TBUS[31:0] is the 32-bit bidirectional test port.
The test bus is used as an input to apply address, control and write vectors. For read vectors the test bus is used as a device output. The test interface protocol ensures that a turnaround period is always provided when changing the direction of the test bus.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-5

AMBA Test Methodology
6.3
Test vector types
There are 5 types of test vector associated with the test interface:
• address vector
• write vector
• read vector
• control vector
• turnaround vector.
Address vector, control vector and turnaround vector are all indicated by the same value on the TREQA and TREQB signals. The following rules may be used to determine which type of vector is being applied.
• •
•
When a single address/control vector is applied it is an address vector.
When a burst of address/control vectors are applied they are all address vectors, apart from the last which is a control vector.
A read vector, or burst of read vectors, is always followed by a turnaround vector. This is the only occurrence of the turnaround vector. The ASB version of the test interface requires a single turnaround vector, while the AHB version requires two.
6-6
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.4
6.4.1
Test interface controller
The Test Interface Controller (TIC) is a bus master that accepts test vectors from the external test bus, TBUS[31:0], and initiates bus transfers. The TIC latches address vectors and, when required, increments the address to allow read and write bursts of test vectors.
Test transfer parameters
The default TIC bus master operation when entering test mode is:
• 32-bit transfer width
• privileged system access.
This is sufficient for testing many embedded system designs and minimizes the on-chip test support logic. In the case of systems that require the above control signals to be dynamically changed, a control vector mechanism is used to update the control signals within the TIC.
Bit 0 of the control vector is used to indicate if the control vector is valid. Thus, if a control vector is applied with bit 0 LOW, the vector will be ignored and will not update the control information. This mechanism allows address vectors which have bit 0 LOW to be applied for many cycles without updating the control information.
Incremental addressing
In order to support burst accesses using the test interface the TIC may support incrementing of the bus address. The number of address bits that are incremented is dependent on the maximum burst access length that is required via the test interface. This is system-dependent but a typical implementation would use an 8-bit address incrementer, allowing burst access up to 1kB boundaries using word transfers.
The control vector also provides a mechanism to enable and disable the address incrementer within the TIC. This allows burst accesses to incremental addresses, as would be used for testing internal RAM. Alternatively, the address increment can be disabled, such that successive accesses of a burst occur to the same address, as would be required to continually read from a single peripheral register.
If the transfer size is changed dynamically then any address incrementer support for burst-mode accesses must be able to support increment by byte, halfword and word offsets, so adaptive address incrementer logic is required.
The address incrementer is disabled by default and must be enabled using a control vector prior to use.
6.4.2
AMBA Test Methodology
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-7

AMBA Test Methodology
6.4.3
Entering test mode
In normal operating mode TREQA will be LOW, indicating that test access is not required and the test bus will be used as required for normal operation, which will usually be part of the external bus interface. Entering test mode allows test vectors to be applied externally that will cause transfers on the internal bus.
The following sequence is required in order to enter test mode:
1. TREQA is asserted to request test bus access.
2. Test mode is entered when the TIC has been granted the internal bus and this is indicated by the assertion of the TACK signal.
3. At this point TCLK will become the source of the internal clock signal.
4. When test mode has been entered TREQB is asserted to initiate an address
vector.
The TIC will not perform any internal transfers until a valid address vector has been applied.
A synchronous tester would not be expected to poll TACK for the bus. Normally the TREQA signal would be asserted for a minimum number of cycles to guarantee to gain access to the bus (completion of the longest wait-state peripheral access or the maximum number of cycles for all bus masters to have completed their current instruction).
Address vectors
An address vector must be applied before any read or write operations can occur. The following sequence is required in order to apply an address vector:
1. TREQA and TREQB are both asserted HIGH indicating an address vector next cycle.
2. In the next cycle the address is applied to TBUS[31:0], while TREQA and TREQB change to reflect the type of test vector that will follow.
In some high-speed systems it may be necessary to apply more than one address vector in succession, to allow sufficient time for the address to propagate from the external test bus through to the internal address bus. In such a case the TIC can negate TACK for the first cycle of the address vector, forcing a second cycle of address vector to be applied.
6.4.4
6-8
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.4.5 Control vector
A control vector is always the last in a sequence of address vectors and is used to update control information within the TIC. The sequence is as follows:
1. TREQA and TREQB are asserted HIGH indicating an address vector next cycle.
2. In the next cycle the address is applied to TBUS[31:0]. TREQA and TREQB both remain HIGH as the control vector will occur in the following cycle.
3. In the next cycle the control information is applied to TBUS[31:0], while TREQA and TREQB change to reflect the type of test vector that will follow.
4. Finally the transfer occurs on the internal bus.
It is possible to apply an invalid control vector, by setting bit 0 of the control vector LOW. This will not change the control information within the TIC.
6.4.6 Write test vectors
Once test mode has successfully been entered, read and write operations may be performed through the test interface. In order to perform a write operation internally it is necessary to supply an address followed by the write data.
The address used for the write transfer will depend on the preceding vectors and a write vector may occur after any of the following:
• a single address vector
• an address/control vector sequence
• another write test vector, forming a burst of writes
• a turnaround vector after a single read or burst of reads.
When an internal bus transfer is extended by the insertion of wait states this is indicated externally by the TACK signal going LOW. During the waited condition the TREQA and TREQB should change to indicate the vector type that will follow when the current vector has completed. However, it is important to note that in the case of a write vector the data should continue to be applied to TBUS[31:0].
AMBA Test Methodology
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-9

AMBA Test Methodology
6.4.7 Read test vectors
In a similar manner to write test vectors, read test vectors may follow a number of different vectors, as listed below, and the address used for the transfer will depend on the preceding vectors:
• a single address vector
• an address/control vector sequence
• another read test vector, forming a burst of reads
• a single write or burst of writes.
A read, or burst of reads, must always be followed by a turnaround vector to prevent bus clash on the external TBUS signals. As for a write vector, if the external transfer is extended then this is indicated externally by the TACK signal going LOW. The read data should not be sampled externally until the internal transfer has completed.
6.4.8 Burst vectors
Multiple write vectors or read vectors may be joined together to form bursts of vectors. This enables test vectors to be applied at a much faster rate by removing the need for an address vector to be associated with each read or write vector.
Burst transfers may use either incrementing addresses or static addresses, depending on whether or not the TIC contains an address incrementer which is enabled. With no address incrementer the TIC will perform non-sequential transfers to a constant address.
If the TIC does contain an enabled address incrementer then the address used for each successive transfer will be incremented by the appropriate amount, which is dictated by the transfer size.
6.4.9 Changing a burst direction
It is possible to change the transfer direction of a burst, from read to write or write to read.
If changing from read to write it is still necessary to insert a turnaround vector. This will not load a new address but will internally cause a new burst to be started allowing internal slaves to observe that the direction of the burst has altered.
6-10 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.4.10 Exiting test mode
Test mode is exited using the following sequence:
1. Apply a single cycle of address vector, which ensures any internal transfers have been completed.
2. TREQA and TREQB are both driven LOW to indicate that test mode is to be exited.
3. When the test interface has been configured for normal system operation TACK will go LOW to indicate that test mode has been exited.
It is important that test mode can be entered and exited cleanly so that diagnostic testing may be performed during system operation.
AMBA Test Methodology
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-11

AMBA Test Methodology
6.5 The AHB Test Interface Controller
The following state diagram illustrates the operation of the TIC.
IDLE SyncTREQA != 1
SyncTREQA = 1
TREQA/B = EXIT START TREQA/B != ADDR
TREQA/B = ADDR
ADDRVEC
TREQA/B = ADDR
TREQA/B = WRITE
TREQA/B = READ
TREQA/B = ADDR or TREQA/B = EXIT
TREQA/B = READ
TREQA/B = ADDR or TREQA/B = EXIT
TREQA/B = !READ
TREQA/B = WRITE
WRITEVEC
TREQA/B = WRITE
READVEC
TREQA/B = !READ
LASTREAD
TURNAROUND
TREQA/B = READ
Figure 6-3 Test Interface Controller state diagram
The following points describe the TIC state diagram operation:
6-12 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

• At reset the TIC is in the IDLE state and will not be requesting use of the AHB. When in the IDLE state TACK is driven LOW to indicate that the test interface cannot be used.
• The TACK signal is used to control all transactions around the state machine, except for the transition from IDLE to START. In all other cases the state machine remains in the same state if the TACK signal is low.
• The TREQA signal is used to move from the IDLE state to the START state. This has been changed from the previous specification, which required TREQA to be high and TREQB to be low, and has the advantage that it is possible to use just TREQA to move from normal operation into test mode.
• In some system implementations it will be necessary to switch from an internal clock source to an external clock TCLK which is used during test mode. When TREQA first goes high this can be used as an indication that the clock source should be changed and a return signal that indicates when the clock switch has occurred successfully can be used to prevent the move into the START state until the test clock is in use.
• If clock switching is being used then it is possible that TREQA is asynchronous to the on-chip clock before test mode is entered and therefore a synchronizer is used to generate a synchronized version of TREQA to control the movement from the IDLE state to the START state.
• The START state is used to ensure that the first vector applied is an address vector to prevent read and write vectors occurring before the address has been initialized. The START state is only exited when TREQA/B indicate an address vector and the following state is ADDRVEC.
• In the ADDRVEC state the TIC registers the address on the TBUS. The ADDRVEC state is used for both address and control vectors, so additional logic is required to determine whether the value on TBUS should be considered as an address or as a control vector. If the previous cycle was an address vector and the following cycle (as indicated by TREQA/B) is not an address vector then the current cycle is a control vector.
• It is possible to stay in the ADDRVEC state for a number of cycles, but usually an address vector will be followed by either read or write transfers.
• If a write transfer is being performed the TIC moves into the WRITEVEC state at the same time that it initiates the transfer on the bus and multiple write transfers can be performed by remaining in the WRITEVEC state. Usually the WRITEVEC will be followed by an address vector, however it is also possible to move directly to read transfer by moving to the READVEC state.
AMBA Test Methodology
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-13

AMBA Test Methodology
6.5.1
• When a read, or a burst of reads is performed the TIC enters the READVEC state. This state indicates that the TIC is starting a read transfer on the bus and it is not until the following cycle that the read data will appear. When the READVEC state is first entered the TBUS will be tristate, but will become driven for further cycles in the READVEC state.
• All read vectors must be followed by two turnaround vectors. For the first of these cycles the TIC will move into the LASTREAD state, during which the last read of the transfer will complete and will be driven out on to the external TBUS. During the LASTREAD state no internal transfers will be started and the TIC will perform IDLE transfers on the bus.
• Following the LASTREAD state the TIC moves into the TURNAROUND state, during which time the external TBUS will be tristate. The TURNAROUND state will usually be followed by an address vector, but it is also possible to go immediately to a write vector or another read.
• The usual method to exit from test is to return to the ADDRVEC state and then set TREQA/TREQB both LOW to return to IDLE and effectively exit from test. In fact, at any point the test mode can be exited by setting both TREQA and TREQB LOW and eventually this will cause the TIC to exit from test.
Note
When applying TIC vectors it is theoretically possible to assert the HLOCK output and then exit from the test. If this happens and then the TIC is granted the bus under normal operation it will effectively lock up the bus. No protection is provided within the TIC to prevent this occurrence.
Control vector
A control vector is included within the TIC to determine the types of transfer it can perform. The control vector is used to set the values of HSIZE, HPROT and HLOCK.
The default TIC bus master operation when entering test mode is:
• 32-bit transfer width – HSIZE[1:0] signifies word transfer
• privileged system access – HPROT[3:0] signifies privileged data access, uncacheable and unbufferable.
Bit 0 of the control vector is used to indicate if the control vector is valid. Thus, if a control vector is applied with bit 0 LOW, the vector will be ignored and will not update the control information. This mechanism allows address vectors which have bit 0 LOW to be applied for many cycles without updating the control information.
6-14
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Although the default settings will be sufficient for testing many embedded system designs, the control vector can be used both to change the control signals of the transfer and also to determine whether the TIC should generate fixed addresses or incrementing addresses.
Table 6-3 defines the bit positions of the control vector. The control vector bit definitions are designed to be backwards compatible with earlier versions of the TIC and therefore not all of the control bits are in obvious positions.
Table 6-3 Control vector bit definitions
0 Control vector valid
1 Reserved
2 HSIZE[0]
3 HSIZE[1]
4 HLOCK
5 HPROT[0]
6 HPROT[1]
7 Address increment enable
8 Reserved
9 HPROT[2]
10 HPROT[3]
There is no mechanism to control the types of burst that the TIC can perform and only incrementing bursts of an undefined length are supported. The TIC only supports 8-bit, 16-bit and 32-bit transfers and therefore HSIZE[2] cannot be altered and will always be low.
In order to support burst accesses using the test interface the Test Interface Controller may support incrementing of the bus address. The TIC increments 8 address bits and the address range that can be covered by this incrementer is dependent on the size of the transfers being performed.
AMBA Test Methodology
Bit position
Description
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-15

AMBA Test Methodology
The control vector provides a mechanism to enable and disable the address incrementer within the TIC. This allows burst accesses to incremental addresses, as would be used for testing internal RAM. Alternatively, the address increment can be disabled such that successive accesses of a burst occur to the same address, as would be required to continually read from a single peripheral register.
If HSIZE[1:0] is changed dynamically then any address incrementer support for burst- mode accesses must be able to support increment by byte, halfword and word offsets, so adaptive address incrementer logic is required.
The address incrementer is disabled by default and must be enabled using a control vector prior to use.
Note
The control vector is primarily used to change signals which have the same timing as the address bus. However the control vector also allows the lock signal to be changed, which is actually required before the locked transfer commences. If the HLOCK signal is used during testing it should be set a transfer before it is required. This difference in timing on the HLOCK signal may in some cases cause an additional transfer to be locked both before and after the sequence that should in fact be locked.
6-16
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.6
Example AMBA AHB test sequences
Example AHB test sequences are described under the following headings:
• Entering test mode
• Write test vectors on page 6-19
• Read transfers on page 6-20
• Control vector on page 6-21
• Burst vectors on page 6-22
• Read-to-write and write-to-read on page 6-23
• Exiting test mode on page 6-24.
Entering test mode
In normal operating mode TREQA will be LOW, indicating that test access is not required and the test bus will be used as required for normal operation, which will usually be part of the external bus interface. Entering test mode allows test vectors to be applied externally that will cause transfers on the internal bus.
The following sequence, as illustrated in Figure 6-4, is required in order to enter test mode:
1. TREQA is asserted to request test bus access.
2. Test mode is entered when the TIC has been granted the internal bus and this is
indicated by the assertion of the TACK signal.
3. At this point TCLK will become the source of the internal HCLK signal.
4. When test mode has been entered TREQB is asserted to initiate an address vector.
5. The TIC will not perform any internal transfers until a valid address vector has been applied.
6.6.1
AMBA Test Methodology
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-17

AMBA Test Methodology
T1 T2 T3 T4 T5 T6
TCLK
TREQA TREQB
TACK TBUS[31:0]
Address Address
Test bus requested
Test bus
available
vector
Figure 6-4 Test start sequence
A synchronous tester is not expected to poll TACK for the bus.
Normally the TREQA signal is asserted for a minimum number of cycles to guarantee access to the bus (completion of the longest wait-state peripheral access or the maximum number of cycles for all bus masters to have completed their current instruction).
6-18
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.6.2 Write test vectors
Figure 6-5 shows the sequence of events when applying a set of write test vectors. Initially an address vector is applied and this is followed by a write test vector.
AMBA Test Methodology
T1 T2 T3 T4 T5 T6 T7 T8
HCLK TREQA TREQB
TACK TBUS[31:0] HTRANS[31:0] HADDR[31:0]
HBURST[2:0] HWRITE HSIZE[2:0]
HPROT[3:0] HWDATA[31:0]
HREADY
Addr
Write1
Write2
Write3
Addr
IDLE
NONSEQ
SEQ
SEQ
IDLE
A
A+4
A+8
Co
ntrol
Data1
Data2
Data3
Address vector
Write vector
Write vector
Write vector
Address vector
Figure 6-5 Write test vector
The following points apply when writing test vectors:
• The TREQA and TREQB signals are pipelined and are used to indicate what type of vector will be applied in the following cycle. Figure 6-5 shows an example of a number of write transfers being performed.
• The TIC samples the address and TREQA/B signals at time T3. Following this it can initiate the appropriate transfer on the AHB.
• In the following cycle the write data is driven on to the TBUS and it is then sampled on the following clock edge, T4, and driven on to the internal bus.
• If the internal transfer is not able to complete then the TACK signal is driven low and this indicates that the external test vector must be applied for another cycle.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-19

AMBA Test Methodology
6.6.3
Read transfers
Read transfers are more complex because they require the TBUS to be driven in the opposite direction and therefore additional cycles are required to prevent bus clash when changing between different drivers of TBUS. Figure 6-6 shows a typical test sequence for reads.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11
HCLK TREQA TREQB
TACK TBUS[31:0] HTRANS[31:0] HADDR[31:0]
HWRITE
HBURST[2:0] HSIZE[2:0] HPROT[3:0]
HRDATA[31:0] HREADY
Addr
Read1
Read2
Read3
Address
Write
IDLE
NONSEQ
SEQ
SEQ
NONSEQ
A
Control
A+4
A+8
A
Control
Read
Read1
Read
Re
ad
Read2
Read3
Address
Address
Write
vector
vector
vector
The following points apply when reading test vectors:
•
•
•
The TREQA and TREQB signals are used in the same way as for a write transfer. Initially, TREQA/B are used to apply an address vector, in the following cycle they are used to indicate that a read transfer is required. For the first cycle of a read the TBUS must be tristate, which ensures that the external equipment driving TBUS has an entire cycle to tristate its buffers before the TIC will enable the on-chip buffers to drive out the read data.
At the end of a burst of reads it is also necessary to allow time for bus turnaround. In this case the TIC must turn off the internal buffers and an entire cycle is allowed before the external test equipment starts to drive.
The end of a burst of reads is indicated by both TREQA and TREQB being HIGH, as for an address vector. In fact they must indicate address vector for two cycles, which allows for both the turnaround cycle at the start of the burst and also the turnaround cycle at the end of the burst.
Figure 6-6 Read test vector
6-20
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.6.4 Control vector
The operation of the TIC may be modified by the use of a control vector. Whenever more than one address vector is applied in succession then the last vector is considered to be a control vector and is not latched as the address. Bit 0 of the control vector is used to determine whether or not the control vector should be considered valid, which allows multiple address vectors to be applied without changing the control information,
Figure 6-7 shows the process of inserting a control vector.
AMBA Test Methodology
T1 T2 T3 T4 T5 T6
HCLK TREQA TREQB
TACK TBUS[31:0] HTRANS[31:0] HADDR[31:0]
HBURST[2:0] HWRITE HSIZE[2:0]
HPROT[3:0] HWDATA[31:0]
HREADY
Addr
Control
Write1
NONSEQ
Write2
Addr
IDLE
IDLE
SEQ
IDLE
A
A+4
Control
Address vector
Control vector
Write vector
Data1
Write vector
Data2
Address vector
Figure 6-7 Control vector
At time T4 the TIC can determine that the TBUS contains a control vector. This is because the previous cycle was an address vector and TREQA/B are indicating that the following cycle is either a read or a write and therefore the current cycle must be a control vector.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-21

AMBA Test Methodology
6.6.5
Burst vectors
The examples of read and write transfers in Figure 6-5 on page 6-19 and Figure 6-6 on page 6-20 also show how additional transfers can be used to form burst transfers on the bus. The TIC has limited capabilities for burst transfers and can only perform undefined-length incrementing bursts.
The TIC contains an 8-bit incrementer and if an attempt is made to perform a burst which crosses the incrementer boundary then the address will wrap and the TIC will signal the transfer as NONSEQUENTIAL. The exact boundary at which this will occur is dependent on the size of the transfer. For word transfers the incrementer will overflow at 1kB boundaries, for halfword transfers it will overflow at 512-byte boundaries and for byte transfers the overflow will occur at 256-byte boundaries.
6-22
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.6.6 Read-to-write and write-to-read
It is possible to switch between read transfers and write transfers without applying a new address vector. Usually this would be done with the address incrementer disabled, so that both the read transfers and the write transfers would be to the same address. It is also possible to do this with the incrementer enabled if the test circumstances require it.
AMBA Test Methodology
HCLK TREQA TREQB
TACK TBUS[31:0] HTRANS[31:0] HADDR[31:0] HWRITE
HBURST[2:0] HSIZE[2:0] HPROT[3:0]
HRDATA[31:0] HWDATA[31:0] HREADY
T1 T2 T3 T4 T5 T6 T7 T8
Addr
Read
Write
IDLE
NONSEQ
IDLE
IDLE
NONSEQ
A
A+4
Control
Read data
Address vector
Read
Write
Write data
Figure 6-8 Read then write transfers
When moving from a read transfer to a write transfer it is also necessary to allow the two cycles for bus handover and therefore TREQA and TREQB should signal address vector for two cycles after the read. This will not cause the address to be changed unless it is followed by a third address vector. Figure 6-8 illustrates the sequence of events.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-23

AMBA Test Methodology
6.6.7
Exiting test mode
Test mode is exited using the following sequence:
1. Apply a single cycle of address vector, which causes an IDLE cycle internally, which ensures any internal transfers have been completed.
2. TREQA and TREQB are both driven LOW to indicate that test mode is to be exited.
3. When the test interface has been configured for normal system operation TACK will go LOW to indicate that test mode has been exited.
It is important that test mode can be entered and exited cleanly so that the TIC can also be used for diagnostic test during system operation, as well as production testing.
6-24
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.7
The ASB test interface controller
Figure 6-9 shows the ASB test interface controller state diagram.
AMBA Test Methodology
!TREQA
NORMAL OPERATION
TREQA
!TREQA & !TREQB
TREQA & !TREQB
ADDRESS OR CONTROL
TREQA & TREQB
ADDRESS OR CONTROL
TREQA & TREQB
!TREQA & TREQB
!TREQA & TREQB
READ
TREQA & !TREQB
!TREQA & TREQB
TREQA & TREQB
TREQA & !TREQB
TURNAROUND
TREQA & TREQB
!TREQA & TREQB
6.7.1
Figure 6-9 Test interface controller state diagram
TREQA and TREQB are sampled on the falling edge of TCLK when TACK is HIGH, except in the NORMAL OPERATION state where TREQA is used asynchronously to transition into the ADDRESS OR CONTROL state. The reset state is NORMAL OPERA TION.
Control vector bit definitions
A control vector is included within the TIC to determine the types of transfer it can perform. The control vector is used to set the values of BSIZE, BPROT and BLOK and to control address incrementing.
Byte 0 of the control packet is used to define the access that will occur on the internal system bus. Byte 1 of the control packet is reserved for clock control and debug.
Table 6-4 shows the control vector bit assignments.
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-25

AMBA Test Methodology
Table 6-4 Control vector bit definitions
Bit position
0 1 2 3 4 5 6 7
Description
Control vector valid Reserved BSIZE[0] BSIZE[1]
BLOK
BPROT[0]
BPROT[1]
Address increment enable
6-26 © Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

6.8
Example AMBA ASB test sequences
Example ASB test sequences are described under the following headings:
• Entering test mode
• Address vectors on page 6-28
• Control vectors on page 6-29
• Write test vectors on page 6-31
• Changing burst direction on page 6-36
• Exiting test mode on page 6-37.
Entering test mode
Test mode is entered, as shown in Figure 6-10, using the following sequence:
1. TREQA is asserted to request test bus access.
2. Test mode is entered when the TIC has been granted the internal bus and this is indicated by the assertion of the TACK signal.
3. At this point TCLK will become the source of the internal BCLK signal.
4. When test mode has been entered TREQB is asserted to initiate an address
vector.
6.8.1
AMBA Test Methodology
Test bus requested
Test bus available
Address vector
TCLK
TREQA
TREQB
TACK
TBUS
Address
Figure 6-10 Test start sequence
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-27

AMBA Test Methodology
6.8.2
Address vectors
An address vector must be applied before a read or write operation can occur. Figure 6-11 shows an example of a single address vector followed by a write vector, the following sequence occurs:
1.
2.
3.
TREQA and TREQB are both asserted HIGH to indicate an address vector next cycle.
In the next cycle the address is applied, while TREQA and TREQB change to indicate the type of test vector that will follow. During this cycle the address appears on the address bus.
In the next cycle the write (or read) vector is applied.
C0 C1 C2
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
A-TRAN
Address vector
N-TRAN
Write 1 vector
A
Write data
Figure 6-11 Address vector
6-28
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.8.3 Control vectors
A control vector must always follow an address vector. Figure 6-12 shows an address and control vector sequence followed by a write vector. The following sequence occurs:
1.
2.
TREQA and TREQB both remain HIGH after the address vector has ended to indicate a control vector next cycle.
In the next cycle control information is applied to TBUS[31:0], while TREQA and TREQB change to reflect the type of test vector that will follow. During this cycle any internal signals, which have been affected by the control vector, will change.
AMBA Test Methodology
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BSIZE
BD
C0 C1 C2
A-TRAN
Address vector
A-TRAN
Control vector
N-TRAN
A
Write vector
Write data
Figure 6-12 Control vector
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved. 6-29

AMBA Test Methodology
Figure 6-13 shows an example of a transfer following an invalid control vector. The TIC performs a SEQUENTIAL transfer on the internal bus because the control signals have not changed.
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BSIZE
BD
C0 C1 C2
A-TRAN
Address vector
A-TRAN
Control vector
S-TRAN
A
Write vector
Write data
Figure 6-13 Invalid control vector
6-30
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.8.4 Write test vectors
Figure 6-14 shows an example of a single write vector following a single address vector.
AMBA Test Methodology
C0 C1 C2
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
A-TRAN
Address vector
N-TRAN
Write 1 vector
A
Write data
Figure 6-14 Write test vectors
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 6-31

AMBA Test Methodology
Figure 6-15 shows an example of extended write vectors following a single address vector.
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
BWAIT
C0 C1 C2 C3
Address vector
N-TRAN
Write vector
A
Write vector
Write data
A-TRAN
Figure 6-15 Extended write test vectors
6-32
© Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 6-16 shows an example of a single address vector, followed by a single read vector and terminated with a single turnaround vector.
AMBA Test Methodology
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
C0 C1 C2 C3 C4
A-TRAN
Address vector
N-TRAN
Read vector
A-TRAN
A
Read data 1
Figure 6-16 Read test vector
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 6-33

AMBA Test Methodology
Figure 6-17 shows SEQUENTIAL transfers to non-incrementing addresses.
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
BWAIT
A-TRAN
C0 C1 C2 C3 C4 C5
Address vector
N-TRAN
Write 1 vector
N-TRAN
N-TRAN
A
Write 1 data
Write 2 vector
N-TRAN
N-TRAN
Write 2 data
Figure 6-17 Burst write vectors with increment disabled
6-34 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

Figure 6-18 shows SEQUENTIAL transfers to incrementing addresses.
AMBA Test Methodology
C0 C1 C2 C3 C4 C5
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
A-TRAN
Address vector
N-TRAN
Write 2 vector
A
S-TRAN
Write 1 data
Write 1 vector
A+4
S-TRAN
Write 2 data
A+8
S-TRAN
Write 3 data
Write 3 vector
A + 12
S-TRAN
Write 4 data
Write 4 vector
Figure 6-18 Burst write vectors with increment enabled
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 6-35

AMBA Test Methodology
6.8.5 Changing burst direction
Figure 6-19 below shows a burst changing direction from read to write.
C0 C1 C2 C3 C4
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
BA
BD
Read vector 1
Read vector 2
S-TRAN
A-TRAN
S-TRAN
AA+4A+
Read Read data 1 data 2
Write vector 1
S-TRAN
Write vector 2
S-TRAN
Write data 2
8 A+C
Write data 1
Figure 6-19 Changing burst direction
6-36 © Copyright ARM Limited 1999. All rights reserved. ARM IHI 0011A

6.8.6 Exiting test mode
Figure 6-20 shows an exit from test mode.
AMBA Test Methodology
C0 C1 C2 C3 C4
TCLK
TREQA
TREQB
TACK
TBUS
BTRAN[1:0]
Write Address vector vector
A-TRAN A-TRAN
BA A
BD
Write data
Normal operation
Figure 6-20 Exiting test mode
ARM IHI 0011A © Copyright ARM Limited 1999. All rights reserved. 6-37

Index
The items in this index are listed in alphabetic order. The references given are to page numbers.
A
Active state 4-56 Address and control signals
AHB 3-1 arbiter 1-7
arbitration signals decoder 1-8
introduction to
master operation signal list signal prefixes slave 1-7
APB 5-1
address bus 2-8
bridge 5-8
bridge interface diagram 5-8 bridge transfer 5-9 components 5-7
in a typical AMBA system 5-3 introduction to 1-10
read data bus 2-8
read transfers 5-6
select 2-8
signal list 2-8
signal prefixes 2-2
slave 5-11
slave interface diagram 5-11 strobe 2-8
timing parameters 5-7, 5-10
transfer direction write data bus 2-8 write transfers 5-5
Arbiter
AHB 1-7
ASB 1-9, 4-20, 4-71 Arbitration and reset signals 4-60
ASB timing
Address bus AHB
APB
4-27 4-29
2-3
2-8
2-6, 4-27
2-5 1-7
ASB Address decoding
2-2 AHB/ASB or APB, when to use
1-13
AHB 3-19
ASB 4-14 Address vectors
2-2 1-4
Address-only transfers
4-10, 4-59
AGNTx
2-6, 4-44
2-8
6-8, 6-28
1-7 3-5
AMBA signal names
AMBA system, typical
AMBA test interface 6-2 AMBA test methodology 6-1
2-3
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved.
Index-i

Index
Arbitration signals AHB 2-5
ASB 4-44 Arbitration, AHB
AREQx 2-6, 4-44 ASB 4-1
3-28
Bursts
incrementing 3-12
of read transfers 5-15 of write transfers 5-17 undefined-length 3-16 wrapping 3-12
Decoder
AHB 1-8
ASB 1-9, 4-63
state machine 4-65, 4-67
with decode cycles 4-33, 4-65
B
Bus request 4-44 AHB 2-5, 3-28
ASB 2-6
Bus retract 4-36
Bus slave interface, ASB 4-47 Bus transfer 1-6
Busidle state 4-56
C
Choosing the right bus 1-12 Clock, ASB 4-25
G
and APB
arbiter
arbiter interface diagram
arbiter timing parameters
bus master 4-52
bus master interface diagram 4-52 bus slave 4-47
bus slave interface
components 4-46
decoder 1-9, 4-63
decoder interface diagram
decoder timing diagrams
decoder timing parameters description 4-4
introduction to
master 1-9
signal description 4-25
signal list 2-6
signal prefixes
slave 1-9
slave bus interface state
test sequence transfers 4-6
6-27
timing diagrams, ASB
4-3
1-9, 4-20, 4-71
backbone 1-4 choosing 1-12
APB 2-8
ASB 2-7 Done response
DSEL 4-33 DSELx 2-7
E
BA
Back to back transfers 5-18 Backbone bus 1-4
Basic transfers 3-6
BCLK 2-6, 4-25
BD 2-6, 4-40
BERROR BLAST
2-6, 4-36 2-6, 4-36
2-7, 4-36 2-7, 4-27 encoding 4-27
BLOK BnRES BPROT
2-6, 4-45
2-6, 4-23, 4-25
2-5, 3-28
2-6, 4-27
2-7, 4-28 encoding 4-28
2-5, 3-28 2-5, 3-28
BSIZE 2-7, 4-28
encoding 4-28
BTRAN 2-7, 4-26
encoding 4-26 timing 4-27
Control signals Control vectors
3-17
6-9, 6-14, 6-21, 6-29
2-5
2-4, 3-25 2-4, 3-20
Burst operation Burst type, AHB
1-6, 3-11 2-3
D
Data bus AHB ASB Deadlock
4-56 2-3, 3-17
Burst vectors
6-10, 6-22
3-25 2-6, 4-40 3-37
1-9
2-2
machine
6-8, 6-17, 6-27 4-16, 4-36, 4-48
4-47
4-48
Exit from reset
Exit test mode
External test interface 6-4
4-71 4-73
4-64 4-68
4-69
peripheral Bus clock
AHB 2-3 APB 2-8 ASB 2-6
Bus cycle 1-6
Bus grant 4-44 AHB 2-5 ASB 2-6
1-12
Bus
Bus interface state machine, ASB
Bus lock 4-45
Bus master
ASB 4-52
default 4-22
granted state machine 4-53 handover 3-29, 4-20 interface, ASB 4-52
main state machine 4-55
4-54
Early burst termination 3-12 Electrical characteristics 1-14 Enable state 5-5
Enter test mode
Error response ASB 2-6
4-57 timing parameters, ASB 4-60
BWAIT BWRITE
bit definitions
6-25
Decode cycles 4-33, 4-65
2-3 2-4, 3-20
without decode cycles Default bus master 4-22 Direction of transfer
4-34, 4-67
4-23
6-11, 6-24, 6-37
Grant signal, AHB 3-28 Granted state machine 4-53
H
HADDR 2-3
Handover 3-29
Handover state 4-56 Handover, bus master 4-20 HBURST 2-3
HBUSREQx
HCLK 2-3 HGRANTx HLOCKx HMASTER HMASTLOCK 2-5
Hold state HPROT HRDA T A HREADY HRESETn HRESP HSELx 2-4
4-16, 4-48
Index-ii
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

HSIZE HSPLITx HTRANS HWDATA HWRITE
PSELx 2-8 PWDA T A 2-8 PWRITE 2-8
R
Read data bus
Read test vectors 6-10 Read transfers 6-20
State machine
ASB slave bus interface 4-48 bus interface, ASB 4-54
bus master, main 4-55
L
Last response ASB 2-6
ASB
ASB
5-4 AHB 2-3
6-8, 6-17, 6-27 6-11, 6-24, 6-37
Multiple transfers
N
3-8
2-6
vector types 6-6 6-3, 6-7
2-3, 3-17 2-5 2-3
2-4, 3-25 2-3, 3-17
Idle state
Incremental addressing
Incrementing burst
Interfacing
APB to AHB
decoder Strobe, APB
T
4-65, 4-67 2-8
I
2-4, 3-25 APB 2-8
Nonsequential transfers
P
P ADDR
PCLK 2-8 PENABLE Peripheral bus 1-12
4-7, 4-57
6-2
AHB APB ASB Size encoding
Size of transfer ASB 2-7
Slave
AHB 1-7
ASB 1-9
Peripheral PRDATA PRESETn Protection
AHB ASB
Protection ASB
test harness 2-8
2-8
control 2-3, 3-17
2-7 signals 4-28
transfer response Slave select
3-20
4-56, 5-4
TACK 6-4
TBUS 6-5
TCLK 6-5
Technology independence 1-14 Termination, early burst 3-12 Terminology 1-6
Test
APB to ASB
revD peripherals 5-22
Reset 4-25
AHB 2-3 APB 2-8
Lock signal, AHB 3-28 Locked sequence, AHB 2-5 Locked transfers
bus request 6-4 clock 6-5 harness 6-2 Interface Controller
ASB 6-25
ASB, state diagram 6-25
Interface Controller (TIC)
Interface Controller state diagram 6-12
AHB ASB
Master AHB
2-5
2-6, 4-22
AHB 2-5 Multi-master operation, ASB
Rev D peripherals
S
Select, APB Sequential transfers
5-22
4-8, 4-58
6-3, 6-7
M
1-7 1-9 Master number
mode entering exiting
2-8
Timing parameters
4-69
2-8
APB APB ASB ASB ASB ASB
5-7, 5-10 slave 5-13
4-46
arbiter 4-73
bus master 4-60 bus slave 4-50
6-7 3-12
4-17, 4-36, 4-48
APB burst of to ASB
5-6, 5-14 5-15 5-21
5-14 5-20
4-19
APB
ASB Signal names
AMBA 2-2 Signal prefixes
AHB
2-6 exit from
transfer parameters 6-7 acknowledge 6-4
4-23 Reset operation, ASB
4-23 3-21
T est
Test bus 6-5
Response encoding
Retract response 4-17, 4-48 Retract state 4-56
Retry transfers 3-38
T est Test T est T est
Test Test
Test
T est
T est
TIC
Timing diagrams
APB bridge 5-9 APB slave 5-12
Setup state
Signal list
sequence ASB 6-27
6-17
AHB
2-4
2-7, 4-33
Timing specification 1-14 Transfer direction
2-8
2-2 2-2 2-2
ASB arbiter
ASB bus slave 4-49 ASB decoder 4-68
2-8
ASB
Split completion request, AHB
2-5
AHB APB ASB
2-3, 3-17 2-8
2-7
Split transfers State diagram
TIC 6-12
3-35, 3-37
3-17
Transfer direction, ASB 4-27
4-72
Index
ARM IHI 0011A
© Copyright ARM Limited 1999. All rights reserved.
Index-iii

Index
Transfer done
AHB 2-4, 3-20
Transfer response 4-47 AHB 2-4, 3-20 ASB 4-16, 4-35
combinations 4-38
timing 4-39 Transfer size
AHB 2-3, 3-17
ASB 2-7, 4-28 Transfer type 3-9, 4-26
AHB 2-3 ASB 2-7 encoding 3-9
Transfers address-only
back to back
basic 3-6
multiple 3-8 nonsequential sequential 4-8, 4-58 split 3-35
with retry response 3-22 with wait states 3-7
TREQA 6-4 TREQB 6-4 Tristate
data bus 5-19
enable of address and control
signals 4-32 Two-cycle response 3-22
Type of transfer 3-9 ASB 2-7
Typical AMBA system AHB-based 3-3 ASB-based 4-2
U
Undefined-length burst
W
1-4, 5-3
3-16
Wait response 4-16, 4-36, 4-47 ASB 2-7
Wait states 3-7 Wrapping burst 3-12 Write data bus
AHB 2-4, 3-25
APB 2-8
Write test vectors 6-9, 6-19, 6-31
Write transfers
APB 5-5, 5-16
burst of
from ASB 5-20
5-17
4-10, 4-59 5-18
4-7, 4-57
Index-iv
© Copyright ARM Limited 1999. All rights reserved.
ARM IHI 0011A

Related Posts