Cortex-R5 TRM
Cortex-R5 TRM
Revision: r1p2
Change history
Proprietary Notice
Words and logos marked with ® or ™ are registered trademarks or trademarks of ARM® in the EU and other countries,
except as otherwise stated below in this proprietary notice. Other brands and names mentioned herein may be the
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 in good faith. However, all warranties implied or
expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded.
This document is intended only to assist the reader in the use of the product. ARM 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.
Where the term ARM is used it means “ARM or any of its subsidiaries as appropriate”.
Confidentiality Status
This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license
restrictions in accordance with the terms of the agreement entered into by ARM and the party that ARM delivered this
document to.
Product Status
Web Address
[Link]
Preface
About this book ......................................................................................................... viii
Feedback ................................................................................................................... xii
Chapter 1 Introduction
1.1 About the processor ................................................................................................. 1-2
1.2 Compliance .............................................................................................................. 1-3
1.3 Features ................................................................................................................... 1-4
1.4 Interfaces ................................................................................................................. 1-5
1.5 Configurable options ................................................................................................ 1-6
1.6 Test features .......................................................................................................... 1-12
1.7 Product documentation, design flow, and architecture .......................................... 1-13
1.8 Changes from previous version ............................................................................. 1-15
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. iii
ID092411 Non-Confidential
Contents
Chapter 12 Debug
12.1 Debug systems ...................................................................................................... 12-2
12.2 About the debug unit .............................................................................................. 12-3
12.3 Debug register interface ........................................................................................ 12-5
12.4 Debug register descriptions ................................................................................. 12-10
12.5 Management registers ......................................................................................... 12-33
12.6 Debug events ....................................................................................................... 12-40
12.7 Debug exception .................................................................................................. 12-42
12.8 Debug state ......................................................................................................... 12-45
12.9 Cache debug ....................................................................................................... 12-50
12.10 External debug interface ...................................................................................... 12-51
12.11 Using the debug functionality ............................................................................... 12-54
12.12 Debugging systems with energy management capabilities ................................. 12-70
Appendix E Revisions
This preface introduces the Cortex-R5 Technical Reference Manual. It contains the following
sections:
• About this book on page viii
• Feedback on page xii.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. vii
ID092411 Non-Confidential
Preface
Note
• The Cortex-R5F processor is a Cortex-R5 processor that includes the optional Floating
Point Unit (FPU) extension.
• In this book, references to the Cortex-R5 processor also apply to the Cortex-R5F
processor, unless the context makes it clear that this is not the case.
The rnpn identifier indicates the revision status of the product described in this book, where:
rn Identifies the major revision of the product.
pn Identifies the minor revision or modification status of the product.
Intended audience
This book is written for system designers, system integrators, and programmers who are
designing or programming a System-on-Chip (SoC) that uses the Cortex-R5 processor.
Chapter 1 Introduction
Read this for an introduction to the processor and descriptions of the major
functional blocks.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. viii
ID092411 Non-Confidential
Preface
Chapter 12 Debug
Read this for a description of the debug support.
Appendix E Revisions
Read this for a description of the technical changes between released issues of this
book.
Glossary
The ARM Glossary is a list of terms used in ARM documentation, together with definitions for
those terms. The ARM Glossary does not contain terms that are industry standard unless the
ARM meaning differs from the generally accepted meaning.
Conventions
Typographical
monospace Denotes text that you can enter at the keyboard, such as commands, file
and program names, and source code.
monospace Denotes a permitted abbreviation for a command or option. You can enter
the underlined text instead of the full command or option name.
monospace bold Denotes language keywords when used outside example code.
< and > Enclose replaceable terms for assembler syntax where they appear in code
or code fragments. For example:
MRC p15, 0 <Rd>, <CRn>, <CRm>, <Opcode_2>
Timing diagrams
The figure named Key to timing diagram conventions explains the components used in timing
diagrams. Variations, when they occur, have clear labels. You must not assume any timing
information that is not explicit in the diagrams.
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.
Clock
HIGH to LOW
Transient
HIGH/LOW to HIGH
Bus stable
Bus change
Timing diagrams sometimes show single-bit signals as HIGH and LOW at the same time and
they look similar to the bus change shown in Key to timing diagram conventions. If a timing
diagram shows a single-bit signal in this way then its value does not affect the accompanying
description.
Signals
Signal level The level of an asserted signal depends on whether the signal is
active-HIGH or active-LOW. Asserted means:
• HIGH for active-HIGH signals
• LOW for active-LOW signals.
Lower-case m At the end of a signal name denotes a value that is 0 or 1, to indicate the
CPU to which the signal applies.
In a single processor system, m is always 0.
Additional reading
ARM publications
This book contains information that is specific to this product. See the following documents for
other relevant information:
• ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition (ARM DDI 0406)
Other publications
Feedback
ARM welcomes feedback on this product and its documentation.
If you have any comments or suggestions about this product, contact your supplier and give:
• An explanation with as much information as you can provide. Include symptoms and
diagnostic procedures if appropriate.
Feedback on content
Note
ARM tests the PDF only in Adobe Acrobat and Acrobat Reader, and cannot guarantee the
quality of the represented document when used with any other PDF reader.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. xii
ID092411 Non-Confidential
Chapter 1
Introduction
This chapter introduces the processor and its features. It contains the following sections:
• About the processor on page 1-2
• Compliance on page 1-3
• Features on page 1-4
• Interfaces on page 1-5
• Configurable options on page 1-6
• Test features on page 1-12
• Product documentation, design flow, and architecture on page 1-13
• Changes from previous version on page 1-15.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-1
ID092411 Non-Confidential
Introduction
Interrupt latency is kept low by interrupting and restarting load-store multiple instructions, and
by use of a dedicated peripheral port that enables low-latency access to an interrupt controller.
The processor has Tightly-Coupled Memory (TCM) ports for low-latency and deterministic
accesses to local RAM, in addition to caches for higher performance to general memory.
Error Checking and Correction (ECC) is used on the Cortex-R5 processor ports and in Level 1
(L1) memories to provide improved reliability and address safety-critical applications.
Many of the features, including the caches, TCM ports, and ECC are configurable so that a given
processor implementation can be tailored to the application for efficient area usage.
JTAG
DMA
Private peripherals
Shared peripherals
ROM RAM
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-2
ID092411 Non-Confidential
Introduction
1.2 Compliance
The processor implements the ARMv7-R architecture and ARMv7 debug architecture. In
addition, the Cortex-R5F processor implements the VFPv3-D16 architecture. This includes the
VFPv3 instruction set.
The Cortex-R5 processor complies with, or implements, the specifications described in:
• ARM architecture
• Trace macrocell
• Advanced Microcontroller Bus Architecture.
• Debug architecture.
The Cortex-R5 processor implements the ARMv7-R architecture profile that includes the
following architecture extensions:
• Advanced Single Instruction Multiple Data (SIMD) architecture extension for integer and
floating-point vector operations
The Cortex-R5 processor implements the ETM v3.3 architecture profile. See the CoreSight
ETM-R5 Technical Reference Manual.
This Cortex-R5 processor complies with the AMBA 3 protocol. See AMBA AXI Protocol
Specification and AMBA 3 APB Protocol Specification.
The Cortex-A9 processor implements the ARMv7 Debug architecture that includes support for
Security Extensions and CoreSight. See the CoreSight Architecture Specification.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-3
ID092411 Non-Confidential
Introduction
1.3 Features
The features of the processor include:
• optional and separately licensable Floating Point Unit (FPU) implementing the VFPv3
instruction set, fully or as single-precision only
• dynamic branch prediction with a global history buffer, and a 4-entry return stack
• the ability to implement and use redundant CPU logic for fault detection
• an L2 memory interface:
— 64-bit master AXI3 interface for accessing memory and shared peripherals
— optional 64-bit slave AXI3 interface to TCM memories and cache RAM blocks for
DMA of instructions or data and online RAM test
— 32-bit master AXI3 peripheral interface for accessing local peripherals
— optional 32-bit master AHB peripheral interface for accessing legacy peripherals
— optional ACP for hardware coherency between peripheral data transfers and data
cache.
• non-maskable interrupt
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-4
ID092411 Non-Confidential
Introduction
1.4 Interfaces
The processor has the following interfaces:
• 64-bit AXI-master interfaces, one per CPU, for instruction fetch and data access
• 32-bit AXI and AHB master interfaces, per CPU, for data accesses, particularly to
peripherals
• 64-bit AXI-slave interfaces, one per CPU, for external access to TCMs and cache RAMs
• TCM interfaces, per CPU, for access to local memory containing instructions and data
• ACP pass through interface, comprising AXI master and slave, up to 64 bits wide,
providing limited hardware coherency functions
• VIC interfaces, one per CPU, for the connection of a PL192 VIC
• configuration signals for customizing the behavior of the processor, particularly from
reset
• interrupt and event outputs providing information about the behavior of the processor to
the wider system
• 32-bit APB slave interfaces and various debug handshake signals, one per CPU, for
connection to CoreSight components providing debug features
• ETM interfaces, one per CPU, for connection to a CoreSight ETM-R5 providing
instruction and data trace
• Memory Built-In Self Test (MBIST) interfaces and scan signals, one per CPU, enabling
test during manufacture of local RAMs and logic.
All the processor AMBA interfaces conform to one of the following AMBA 3 specifications:
• AMBA AXI Protocol Specification
• AMBA AHB-Lite Protocol Specification
• AMBA APB Protocol Specification.
The debug interfaces are CoreSight compliant, see the CoreSight Architecture Specification.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-5
ID092411 Non-Confidential
Introduction
Build-configuration
Feature Options Sub-options
or pin-configuration
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-6
ID092411 Non-Confidential
Introduction
Build-configuration
Feature Options Sub-options
or pin-configuration
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-7
ID092411 Non-Confidential
Introduction
Build-configuration
Feature Options Sub-options
or pin-configuration
AXI-slave includedb -
Enabled -
Even parity -
ACP included -
AXI and AHB peripheral AHB peripheral port region size: 4KB, Build and pin
ports 8KB, 16KB, 32KB, 64KB, 128KB,
256KB, 512KB, 1MB, 2MB, 4MB, or
8MB. 16MB, 32MB, 64MB, 128MB,
256MB, 512MB, 1GB, 2GB, 4GBb
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-8
ID092411 Non-Confidential
Introduction
Build-configuration
Feature Options Sub-options
or pin-configuration
Table 1-2 describes the various features that can be pin-configured to be either enabled or
disabled at reset. It also shows which CP15 register field provides software configuration of the
feature when the processor is out of reset. All of these fields exist in either the SCTLR, or one
of the auxiliary control registers.
Exception vector table Base address for exception vectors: 0x00000000/0xFFFF0000a SCTLR.V
BTCM ECC check enabled, for B0TCM and B1TCM togetherab ACTLR.B0TCMPCEN/
ACTLR.B1TCMPCEN
BTCM external error enable, for B0TCM and B1TCM independently ACTLR.B0TCMECEN/
ACTLR.B1TCMECEN
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-9
ID092411 Non-Confidential
Introduction
c. Can only be enabled if the appropriate TCM is not configured with 32-bit ECC.
d. Can only be enabled if the AHB peripheral port is included.
A Cortex-R5 processor group can consist of either one or two CPUs. The number of CPUs
included and the behavior of these CPUs within the group depends on the configuration used.
This section describes the CPU arrangements supported and the functionality of each
arrangement.
Single CPU
Twin CPU
This configuration includes two individual and decoupled CPUs, and a single, optional ACP. It
offers higher performance than a standard single CPU configuration. Each CPU has its own
cache RAMs, debug logic and bus interfaces to the rest of the SoC. There is only one ACP port
in the group. Accesses on this port are kept coherent with both CPUs in the group. For more
information about ACP coherency, see Accelerator Coherency Port interface on page 9-53. The
CPUs do not interact within the processor group boundary but might interact elsewhere in the
SoC. Contact your system integrator for more information about programming a device that
includes a twin-CPU configuration.
You can configure some aspects of the two CPUs separately, for example cache size. See
Table 1-1 on page 1-6 for more information about which configuration options can be
configured independently.
There is no internal hardware to maintain coherency between the two CPUs in a twin CPU
Cortex-R5 group. Loss of coherency occurs if one CPU tries to access dirty data that is in the
cache of the other CPU. For example, if CPU0 attempts to transfer a frame of data to CPU1,
using a write-back cacheable memory region, then the frame valid bit might miss in the CPU0
cache and be updated in level-2 memory, while some or all of the frame data can hit in the CPU0
cache and not be updated in level-2 memory. This represents a loss of coherency, because CPU1
can detect a valid frame but reads out-of-date frame data. For more information about
coherency, see Coherency on page 3-6.
Redundant CPU
In this configuration, there is a single functional CPU and an optional ACP. The configuration
also includes a second redundant copy of the majority of the CPU logic, and a redundant copy
of the ACP logic if an ACP is configured. The redundant logic is driven by the same inputs as
the functional logic. In particular, the redundant CPU logic shares the same cache RAMs as the
functional CPU. Therefore only one set of cache RAMs is required. The redundant logic
operates in lock-step with the CPU, but does not directly affect the processor behavior in any
way. The processor outputs to the rest of the system, and the CPU outputs to the cache RAMs,
are driven exclusively by the functional CPU.
Comparison logic can be included, during implementation, to compare the outputs of the
redundant logic and the functional logic. These comparators can detect a single fault that occurs
in either set of logic because of radiation or circuit failure. When used in conjunction with RAM
error detection schemes, the system can be protected from faults.
The input signals DCCMINP[7:0] and DCCMINP2[7:0] and the output signals
DCCMOUT[7:0] and DCCMOUT2[7:0] enable the comparators to communicate with the rest
of the SoC.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-10
ID092411 Non-Confidential
Introduction
ARM provides example comparison logic, but you can change this during implementation. If
you are implementing a Redundant CPU configuration, contact ARM for more information.
Split/Lock
Two CPUs are included in this configuration. If an ACP is configured, a functional ACP and a
redundant copy of the ACP logic is included. The processor group can operate in one of two
modes:
Locked mode Operates as a redundant CPU configuration. Also known as safety mode.
Switching between these modes is only permitted while the processor group is held in power-on
reset. The input signals SLCLAMP and SLSPLIT are provided to enable the system to control
the mode of the processor group. For more information about how to effect a change in
processor mode, contact your system integrator.
If you are implementing a Split/Lock configuration, contact ARM for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-11
ID092411 Non-Confidential
Introduction
If the AXI-slave interface is included, production test of the processor cache and TCM RAMs
can be done through the dedicated, pipelined MBIST interface. This interface shares some of
the multiplexing present in the processor design.
In addition, you can use the AXI slave interface to read and write the cache RAMs and TCM.
You can use this feature to test the cache RAMs in a running system. This might be required in
a safety-critical system. The TCM can be read and written directly by the program running on
the processor. You can also use the AXI slave interface for swapping a test program in to the
TCMs for the processor to execute. See Accessing RAMs using the AXI slave interface on
page 9-25 for more information about how to access the RAMs using the AXI slave interface.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-12
ID092411 Non-Confidential
Introduction
See Additional reading on page xi for more information about the books described in this
section. For information about the relevant architectural standards and protocols, see
Compliance on page 1-3.
1.7.1 Documentation
Integration Manual
The Integration Manual (IM) describes how to integrate the Cortex-R5 processor
into a SoC. It describes the pins that the integrator must tie off to configure the
macrocell for the required integration. Some of the integration is affected by the
configuration options used when implementing the Cortex-R5 processor.
The IM is a confidential book that is only available to licensees.
The Cortex-R5 processor is delivered as synthesizable RTL. Before it can be used in a product,
it must go through the following process:
Implementation
The implementer configures and synthesizes the RTL to produce a hard
macrocell. This might include integrating RAMs into the design.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-13
ID092411 Non-Confidential
Introduction
Integration The integrator connects the implemented design into a SoC. This includes
connecting it to a memory system and peripherals.
Programming
This is the last process. The system programmer develops the software required
to configure and initialize the Cortex-R5 processor, and tests the required
application software.
Each process can be performed by a different party. Implementation and integration choices
affect the behavior and features of the Cortex-R5 processor. The implementer can implement a
macrocell that includes some of the SoC components in addition to the Cortex-R5 processor. In
this situation, they must perform some of the integration before implementation. The integrator
of such a macrocell has fewer integration tasks to perform, and fewer option choices to make.
Build configuration
The implementer chooses the options that affect how the RTL source files are
pre-processed. These options usually include or exclude logic that affects one or
more of the area, maximum frequency, and features of the resulting macrocell.
For example, the BTCM interface can be configured to have zero, one (B0TCM)
or two (B0TCM and B1TCM) ports. If one port is chosen, the logic for the second
port is excluded from the macrocell, although the pins remain, and the second port
(B1TCM) cannot be used on that macrocell.
Configuration inputs
The integrator configures some features of the Cortex-R5 processor by tying
inputs to specific values. These configurations affect the start-up behavior before
any software configuration is made. They can also limit the options available to
the software.
For example, if the build configuration for the macrocell includes both BTCM
ports, the integrator can choose how many ports to actually use, and therefore
how many RAMs must be integrated with the macrocell. If the integrator only
wants to use one BTCM port, they can connect RAM to the B0TCM port only,
and tie the ENTCM1IFm input to zero to indicate that the B1TCM is not
available.
Software configuration
The programmer configures the Cortex-R5 processor by programming particular
values into registers. This affects the behavior of the Cortex-R5 processor.
For example, the enable bit in the BTCM Region Register controls whether or not
memory accesses are performed to the BTCM interface. However, the BTCM
cannot, and must not, be enabled if the build configuration does not include any
BTCM ports, or if the pin configuration indicates that no RAMs have been
integrated onto the BTCM ports.
Note
This manual refers to implementation-defined features that are applicable to build configuration
options. Reference to a feature that is included means that the appropriate build and pin
configuration options are selected. Reference to an enabled feature means one that has also been
configured by software.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-14
ID092411 Non-Confidential
Introduction
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 1-15
ID092411 Non-Confidential
Chapter 2
Functional Description
This chapter describes the functionality of the Cortex-R5 processor. It contains the following
sections:
• About the functions on page 2-2
• Interfaces on page 2-10
• Clocking and resets on page 2-12
• Operation on page 2-18.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-1
ID092411 Non-Confidential
Functional Description
Processor
CPU0 CPU1
μSCU
ETM Debug
CPU
ETM Debug
interface interface
Data
Processing Load/Store
Prefetch Unit Unit Unit
FPU
Level one
memory system
L1 Memory L1 μSCU
instruction Protection data cache
Tightly- cache control Unit control
ATCM
Coupled
B1TCM Memory
(TCM)
B0TCM interface L1 L1
instruction data
cache RAM cache RAM
The PreFetch Unit (PFU) fetches instructions from the memory system, predicts branches, and
passes instructions to the Data Processing Unit (DPU). The DPU executes all instructions and
uses the Load/Store Unit (LSU) for data memory transfers. The PFU and LSU interface to the
L1 memory system that contains L1 instruction and data caches and the TCM interfaces. The
L1 caches in turn connect to the L2 memory system, and the LSU has a more direct connection
to the L2 memory system by means of the peripheral port. The L1 data cache interfaces to the
µSCU to perform cache maintenance as required for coherency with ACP transactions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-2
ID092411 Non-Confidential
Functional Description
The DPU holds most of the program-visible state of the processor, such as general-purpose
registers, status registers and control registers. It decodes and executes instructions, operating
on data held in the registers in accordance with the ARM architecture. Instructions are fed to the
DPU from the PFU through a buffer. The DPU performs instructions that require data to be
transferred to or from the memory system by interfacing to the LSU. See Chapter 3
Programmers Model for more information.
The Floating Point Unit (FPU) is an optional part of the DPU that includes the VFP register file
and status registers. It performs floating-point operations on the data held in the VFP register
file. See Chapter 11 FPU Programmers Model for more information.
The LSU manages all load and store operations, interfacing with the DPU to the TCMs, caches,
peripheral ports, and L2 memory interfaces.
The PFU obtains instructions from the instruction cache, the TCMs, or from external memory
and predicts the outcome of branches in the instruction stream. See Chapter 5 Prefetch Unit for
more information.
Branch prediction
The branch predictor is a global type that uses history registers and a 256-entry pattern history
table.
Return stack
The PFU includes a 4-entry return stack to accelerate returns from procedure calls.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-3
ID092411 Non-Confidential
Functional Description
You can configure the processor to include separate instruction and data caches. The caches
have the following features:
• Support for independent configuration of the instruction and data cache sizes between
4KB and 64KB.
• 8-word cache line length. Cache lines can be either write-back or write-through,
determined by MPU region.
• Streaming of sequential data from LDM and LDRD operations, and sequential instruction
fetches.
• Implementation of all the cache RAM blocks and the associated tag and valid RAM
blocks using standard ASIC RAM compilers.
An optional MPU provides memory attributes for embedded control applications. You can
configure the MPU to have eight or twelve regions, each with a minimum resolution of 32 bytes.
MPU regions can overlap, and the highest numbered region has the highest priority.
The MPU checks for protection and memory attributes, and some of these can be passed to an
external L2 memory system.
TCM interfaces
Because some applications do not cache well, there are two TCM interfaces that permit
connection to configurable memory blocks of Tightly-Coupled Memory (ATCM and BTCM).
These ensure high-speed access to code or data. As an option, the BTCM can have two memory
ports for increased bandwidth.
An ATCM typically holds interrupt or exception code that must be accessed at high speed,
without any potential delay resulting from a cache miss.
A BTCM typically holds a block of data for intensive processing, such as audio or video
processing.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-4
ID092411 Non-Confidential
Functional Description
The TCMs are external to the processor. This provides flexibility in optimizing the TCM
subsystem for performance, power, and RAM type. The INITRAMAm and INITRAMBm
pins enable booting from the ATCM or BTCM, respectively. Both the ATCM and BTCM
support wait states.
To increase the tolerance of the system to soft memory faults, you can configure the caches for
either:
• parity generation and error correction/detection
• ECC code generation, single-bit error correction, and two-bit error detection.
Similarly, you can configure the TCM interfaces for ECC code generation, single-bit error
correction, and two-bit error detection.
The L2 AXI interfaces enable the L1 memory system to have access to peripherals and to
external memory using an AXI master and AXI slave port and the peripheral ports. See
Chapter 9 Level Two Interface for more information.
The AXI master interface provides a high bandwidth interface to second level caches, on-chip
RAM, peripherals, and interfaces to external memory. It consists of a single AXI port with a
64-bit read channel and a 64-bit write channel for instruction and data fetches.
The AXI master can run at the same frequency as the processor, or at a lower synchronous
frequency. If asynchronous clocking is required an external asynchronous AXI slice is required.
The AXI slave interface enables AXI masters, including the AXI master port of the processor,
to access data and instruction cache RAMs and TCMs on the AXI system bus. You can use this
for DMA into and out of the TCM RAMs and for software test of the TCM and cache RAMs.
The slave interface can run at the same frequency as the processor or at a lower, synchronous
frequency. If asynchronous clocking is required an external asynchronous AXI slice is required.
Bits in the Auxiliary Control Register and Slave Port Control Register can control access to the
AXI slave. Access to the TCM RAMs can be granted to any master, to only privileged masters,
or completely disabled. Access to the cache RAMs can be separately controlled in a similar way.
Peripheral interfaces
The peripheral interfaces provide low latency interfaces to on-chip RAM and peripherals for
non-cached data accesses only. They consist of a single 32-bit AXI port, accessed through two
interfaces, and a single 32-bit AHB port accessed through a single interface.
The peripheral interfaces can run at the same frequency as the processor, or at a lower
synchronous frequency. If asynchronous clocking is required, an external asynchronous AXI
slice and asynchronous AHB bridge is required.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-5
ID092411 Non-Confidential
Functional Description
The processor can be implemented with a second, redundant copy of most of the logic. This
second core shares the input pins and the cache RAMs of the master core, so only one set of
cache RAMs is required. The master core drives the output pins and the cache RAMs.
Comparison logic can be included during implementation that compares the outputs of the
redundant core with those of the master core. If a fault occurs in the logic of either core, because
of radiation or circuit failure, this is detected by the comparison logic. Used in conjunction with
the RAM error detection schemes, this can help protect the system from faults. The inputs
DCCMINP[7:0] and DCCMINP2[7:0] and the outputs DCCMOUT[7:0] and
DCCMOUT2[7:0] enable the comparison logic inside the processor to communicate with the
rest of the system.
ARM provides example comparison logic, but you can change this during implementation. If
you are implementing a processor with dual-redundant cores, contact ARM for more
information. If you are integrating a Cortex-R5 macrocell with dual-redundant cores, contact the
implementer for more information.
2.1.7 Split/lock
The Cortex-R5 processor can be configured so that it can be switched, under reset, between a
twin-CPU performance mode and a dual-redundant safety mode. This feature imposes extra
constraints on the software usage model. Contact ARM for information on how it can be used.
The error correction features of the processor are targeted at soft errors. The processor contains
features that enable it to recover from a limited set of hard errors. Contact ARM for information
on hard error effects and these features.
2.1.9 Debug
Each CPU has a CoreSight compliant Advanced Peripheral Bus version 3 (APBv3) debug
interface. This permits system access to debug resources, for example, the setting of
watchpoints and breakpoints.
The processor provides extensive support for real-time debug and performance profiling.
This is a group of counters that you can configure to monitor the operation of the processor and
memory system. For more information, see About the PMU on page 6-6.
ETM interface
The Embedded Trace Macrocell (ETM) interface enables you to connect an external ETM unit
to the processor for real-time code tracing of the core in an embedded system.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-6
ID092411 Non-Confidential
Functional Description
The ETM interface collects various processor signals and drives these signals from the
processor. The interface is unidirectional and runs at the full speed of the processor. The ETM
interface connects directly to the external ETM unit without any additional glue logic. You can
disable the ETM interface for power saving. For more information, see the CoreSight ETM-R5
Technical Reference Manual.
Each CPU contains an EmbeddedICE logic unit to provide real-time debug facilities. It has:
• up to eight breakpoints
• up to eight watchpoints
• a Debug Communications Channel (DCC).
Note
The number of breakpoints and watchpoints is configured during implementation, see
Configurable options on page 1-6.
The EmbeddedICE logic monitors the internal address and data buses. You access the
EmbeddedICE logic through the memory-mapped APB interface.
The processor implements the ARMv7 Debug architecture, including the extensions of the
architecture to support CoreSight.
Halt mode On a debug event, such as a breakpoint or watchpoint, the debug logic stops the
processor and forces it into debug state. This enables you to examine the internal
state of the processor, and the external state of the system, independently from
other system activity. When the debugging process completes, the processor and
system state are restored, and normal program execution resumes.
The system control coprocessor provides configuration and control of the memory system and
its associated functionality. Other system-level operations, such as cache maintenance
operations, are also managed through the system control coprocessor.
For more information, see System control and configuration on page 4-2.
Interrupt handling in the processor is compatible with previous ARM architectures, but has
several additional features to improve interrupt performance for real-time applications.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-7
ID092411 Non-Confidential
Functional Description
VIC port
The core has a dedicated port that enables an external interrupt controller, such as the ARM
PrimeCell Vectored Interrupt Controller (VIC), to supply a vector address along with an
Interrupt Request (IRQ) signal. This provides faster interrupt entry, but you can disable it for
compatibility with earlier interrupt controllers.
Note
If you do not have a VIC in your design, you must ensure the nIRQm and nFIQm signals are
asserted, held LOW, and remain LOW until the exception handler clears them.
On receipt of an interrupt, the processor abandons any pending restartable memory operations.
Restartable memory operations are the multiword transfer instructions LDM, LDRD, STRD, STM, PUSH,
and POP that can access Normal memory.
To minimize the interrupt latency, ARM recommends that you do not perform:
• multiple accesses to areas of memory marked as Device or Strongly Ordered
• SWP operations to slow areas of memory.
Exception processing
• Accurate branch and return prediction, reducing the number of incorrect instruction fetch
and decode operations.
• The caches use sequential access information to reduce the number of accesses to the tag
RAMs and to unmatched data RAMs.
• Extensive use of gated clocks and gates to disable inputs to unused functional blocks.
Because of this, only the logic actively in use to perform a calculation consumes any
dynamic power.
Run mode This mode is the normal mode of operation where all of the functionality
of the CPU is available.
Standby mode This mode disables most of the clocks of the CPU, while keeping the
device powered up. This reduces the power drawn to the static leakage
current and the minimal clock power overhead required to enable the
device to wake up from the Standby mode.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-8
ID092411 Non-Confidential
Functional Description
Dormant mode The processor can be implemented in such a way as to support Dormant
mode. Dormant mode is a power saving mode in which the CPU logic, but
not the TCM and cache RAMs, is powered down. The CPU state, apart
from the cache and TCM state, is stored to memory before entry into
Dormant mode, and restored after exit.
Contact ARM for more information on preparing the Cortex-R5 processor
to support Dormant mode.
Shutdown mode This mode has the entire CPU powered down. All state, including cache
and TCM state, must be saved externally. After power-up, the assertion of
reset returns the CPU to the run state.
For more information on the power management features, see Chapter 10 Power Control.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-9
ID092411 Non-Confidential
Functional Description
2.2 Interfaces
The processor has the following interfaces for external access:
• AXI master interface
• Peripheral interfaces
• AXI slave interface
• TCM interfaces
• ACP interface
• Interrupt and VIC interface
• Configuration interface
• Interrupt and event outputs on page 2-11
• APB Debug interface on page 2-11
• ETM interface on page 2-11
• Test interface on page 2-11.
AXI master interface on page 9-5 describes the AXI master interface. AXI master port on
page A-9 and AXI master port error detection signals on page A-11 describe the associated
signals. The AMBA AXI Protocol Specification describes the AXI protocol.
Peripheral interfaces on page 9-36 describes the peripheral interfaces. AXI peripheral port on
page A-18 to AHB peripheral port error detection signals on page A-21 describe the associated
signals. The AMBA AXI Protocol Specification and the AMBA 3 AHB-Lite Protocol
Specification describe the AXI and AHB-Lite protocols respectively.
AXI slave interface on page 9-21 describes the AXI slave interface. AXI slave port on page A-12
and AXI slave port error detection signals on page A-14 describe the associated signals. The
AMBA AXI Protocol Specification describes the AXI protocol.
About the TCMs on page 8-13 describes the TCM interfaces. TCM interface signals on
page A-22 describes the associated signals.
Accelerator Coherency Port interface on page 9-53 describes the ACP interface. ACP slave port
on page A-15 to ACP master port error detection signals on page A-17 describe the associated
signals. The AMBA AXI Protocol Specification describes the AXI protocol.
Interrupts on page 3-19 describes the interrupts. Interrupt signals, including VIC interface
signals on page A-8 describes the associated signals.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-10
ID092411 Non-Confidential
Functional Description
Chapter 6 Events and Performance Monitor describes events and the interrupts they can
generate. Exceptions on page 11-14 describes the FPU exception outputs. Interrupt signals,
including VIC interface signals on page A-8, ETM interface signals on page A-28, Validation
signals on page A-31, and FPU signals on page A-32 describe the associated signals.
AMBA APBv3 is used for debugging purposes. CoreSight is the ARM architecture for
multi-processor trace and debug. CoreSight defines what debug and trace components are
required and how they are connected. See the CoreSight Architecture Specification for more
information. Debug interface signals on page A-26 describes the debug APB interface signals.
Note
The APB debug interface can also connect to a DAP-Lite. For more information on the
DAP-Lite, see the CoreSight DAP-Lite Technical Reference Manual.
You can connect an ETM-R5 to the processor through the ETM interface. The ETM-R5
provides instruction and data trace for the processor. The CoreSight ETM-R5 Technical
Reference Manual describes how the ETM-R5 connects to the processor.
ETM interface signals on page A-28 describes the associated signals. Event bus interface on
page 6-20 describes the event bus.
The test interface provides support for test during manufacture of the processor using Memory
Built-In Self Test (MBIST). MBIST signals on page A-30 describes the test interface signals.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-11
ID092411 Non-Confidential
Functional Description
2.3.1 Resets
DBGRESETmn CPU debug reset. Resets core-domain debug logic. This includes
breakpoints, watchpoints and the DCC registers.
PRESETDBGmn CPU debug reset. Resets debug-domain debug logic and the APB interface
of the CPU.
Note
• For more information about the split between core-domain and debug-domain logic, see
the ARM Architecture Reference Manual.
• Cortex-R5 implements separate core and debug domains with the minimal architected set
of debug domain registers.
The Cortex-R5 processor group, containing one or two CPUs, has the following resets:
ACPRESETn ACP reset. Resets the ACP logic and both the ACP slave and master AXI
interfaces.
nSYSPORESET Power-on reset. Resets the entire processor group including all
implemented CPUs, debug logic and ACP. See Effects of resets on debug
registers on page 12-8.
nCPUHALTm This signal, when asserted, stops the CPU from fetching instructions out
of reset.
All these signals are active-LOW and are suitably synchronized within the processor. You must
take care when generating these reset signals, for example, to ensure that they are glitch-free.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-12
ID092411 Non-Confidential
Functional Description
The reset signals in the processor enable you to reset different parts of the design independently.
Table 2-1 shows the reset signals, and the combinations and possible applications that you can
use them in.
All reset signals are synchronized within the processor. You do not have to synchronize either
edge of any of the reset signals. Unless otherwise stated, whenever nRESETm is asserted, it
must be held asserted for at least four CLKIN cycles to ensure correct reset operation.
Note
If you are implementing either a dual-redundant core or a Split/Lock configuration, contact
ARM for additional reset requirements.
Power-on reset
You must apply power-on or cold reset to the processor when power is first applied to the
system. A power-on reset must consist of one of the following:
• Assert nSYSPORESET and keep it asserted for at least four CLKIN cycles. See
Figure 2-3 on page 2-14.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-13
ID092411 Non-Confidential
Functional Description
CLKIN
nSYSPORESET
CLKIN
nRESETm
nSYSPORESET
The processor implements synchronizers for nSYSPORESET. You do not have to synchronize
either edge of nSYSPORESET.
After applying power-up reset to the processor, you must initialize various registers. See
Initialization on page 2-18 for more information.
CPU reset
A CPU or warm reset initializes the majority of the CPU logic, excluding the ACP and debug
logic. Typically, you use CPU reset to reset a system that has been operating for some time, for
example when a watchdog timer expires. The processor debug logic remains active, to permit
debugging of the reset handling software.
You can safely reset either or both of the CPUs independently of the ACP.
It you are implementing a twin-CPU configuration you must ensure that a given CPU is
quiescent before resetting it independently of the other CPU. A CPU is quiescent when all of
the following are true:
• either nWFEPIPESTOPPEDm or nWFIPIPESTOPPEDm is LOW
• all transactions to the CPU from the system have completed
• the system cannot issue new stimulus to the CPU.
You must apply a CPU power-up reset when the processor wakes up from either dormant or
shutdown mode. A CPU power-up reset must consist of the following:
• Assert nRESETm and DBGRESETnm together and keep them asserted for at least four
CLKIN cycles on wake-up from dormant or shutdown mode.
• Assert nRESETm only and keep it asserted for at least four CLKIN cycles on wake-up
from emulated dormant or emulated shutdown mode. The processor debug logic is kept
active to permit debugging of the wake-up software.
After applying power-up reset to a CPU, you must initialize various registers. See Initialization
on page 2-18 for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-14
ID092411 Non-Confidential
Functional Description
Debug Reset
A debug reset initializes all the debug and non-debug logic of the processor, excluding the ACP
logic. This reset causes a debugger to lose connection to the processor, and therefore ARM
recommends you apply it only on request by the debugger, for example on detection of a fatal
error condition.
ACP reset
An ACP reset resets the internal ACP logic and the ACP master and slave AXI ports. You can
use ACP reset when the peripheral connected to the ACP port is reset. You must not assert ACP
reset independently of the CPU resets, unless the ACP is quiescent. The ACP is quiescent when
both of the following are true:
• ACPIDLE is asserted
• the system cannot issue new transactions to the ACP.
Normal operation
During normal operation, neither processor reset nor power-on reset is asserted. If the
EmbeddedICE-RT logic is not used, the value of PRESETDBGmn does not matter.
Halt operation
When nCPUHALTm is asserted, and nSYSPORESET and nRESETm are deasserted, the
CPU is out of reset, but the PFU is inhibited from fetching instructions. When the CPU is halted
in this way, you can, for example, use the AXI slave interface to store instructions in the TCMs
using DMA. You can then deassert nCPUHALTm and the PFU starts fetching the preloaded
instructions from TCMs. When the CPU has started to fetch, nCPUHALTm must not be
asserted again except when the CPU is reset.
Independent resets
When the Cortex-R5 processor is configured with an ACP, you can reset the CPU or CPUs
independently of the ACP. In a twin-CPU configuration it is possible to reset the CPUs
independently of each other. Each CPU and the ACP has its own AMBA ports, and in a typical
system some or all of these are ultimately connected to the same bus infrastructure. In such a
system, to preserve ongoing transactions from other masters, the bus infrastructure is not
normally reset when only one of the CPUs or the ACP is reset. To avoid loss of synchronization
between bus infrastructure that is not reset and logic that is reset, you must ensure that the logic
is quiescent before reset is applied to it. If reset is applied to the bus infrastructure at the same
time as the connected logic, the logic does not have to be quiescent.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-15
ID092411 Non-Confidential
Functional Description
2.3.3 Clocking
The processor has a single clock input, CLKIN, that is used for the CPU or both CPUs in a
twin-CPU configuration. The same clock is used for the ACP ports and logic, and the
debug-APB interfaces.
The additional clock input, CLKIN2, is related to the dual-redundant core functionality, if
included. If you are integrating a Cortex-R5 processor with dual-redundant core, contact the
implementer of that macrocell for information about how to connect the clock inputs.
The AXI master, AXI slave, ACP, debug-APB, and AXI and AHB peripheral ports must be
connected to the AMBA systems that are synchronous to the processor clock, CLKIN, even if
this might be at a lower frequency. This means that every rising edge on the AMBA system
clock must be synchronous to a rising edge on CLKIN.
The AXI master interface clock enable signal ACLKENMm, the AXI slave interface clock
enable signal ACLKENSm, ACP clock enable ACLKENC, debug-APB block enable
PCLKENDBGm, and AHB and AXI peripheral port clock enables ACLKENP and
HCLKENP respectively must be asserted on every CLKIN rising edge for which there is a
simultaneous rising edge on the AXI system clock.
Figure 2-5 shows an example in which the processor is clocked at 400MHz (CLKIN), while the
AXI system connected to the AXI master interface is clocked at 200MHz (ACLKM). The
ACLKENMm clock indicates the relationship between the two clocks.
CLKIN
ACLKM
ACLKENMm
If the AMBA system connected to an interface is clocked at the same frequency as the processor,
then the corresponding clock enable signal must be tied HIGH.
Clock gating
In Standby Mode, the CPU can gate its own clock to save power. See Chapter 10 Power Control
for more information about Standby Mode. You can use the nCLKSTOPPEDm output to gate
the clock to the TCMs when the CPU is gating its own clock in Standby mode. If you do, you
must design the logic so that the TCM clock starts running in time for the third rising edge for
which nCLKSTOPPEDm is deasserted.
Figure 2-6 on page 2-17 shows an example of an ATCM access occurring immediately after
CPU0 exits Standby Mode. nCLKSTOPPED0 indicates when the CPU internal clock, shown
as CPU_CLK0, has been restarted. The clock to the ATCM, shown as ATCM_CLK0, has been
gated off in Standby Mode and is restarted in time for the third rising edge, for which
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-16
ID092411 Non-Confidential
Functional Description
nCLKSTOPPEDm is deasserted. This enables the ATCM to respond to the access that CPU0
presents by asserting ATCEN00. This example shows the worst-case, that is, the earliest TCM
access that the CPU can generate after exiting Standby Mode.
CLKIN
nCLKSTOPPED0
CPU_CLK0
ATCEN00
ATCM_CLK0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-17
ID092411 Non-Confidential
Functional Description
2.4 Operation
When you power-up the Cortex-R5 processor, you must first reset it, as described in Clocking
and resets on page 2-12. When it is out of reset, and no longer halted, it starts to fetch and
execute instructions from an address and according to the instruction set as described in Reset
on page 3-19. The processor initially fetches instructions from, and transfers data to and from
either the TCM interfaces or the level-2 memory interfaces.
The processor also responds to stimulus received on its interfaces, for example interrupts, or
transactions received on the AXI slave interface.
2.4.1 Initialization
When the processor has started executing, but before you can run application software on the
processor, it must be initialized, including loading the appropriate software-configuration. This
section describes the steps that the software must take to initialize the processor after reset.
Most of the architectural registers in the processor, such as r0-r14, and s0-s31 and d0-d15 when
floating-point is included, are not reset. Because of this, you must initialize these for all modes
before they are used, using an immediate-MOV instruction, or a PC-relative load instruction.
The Current Program Status Register (CPSR) is given a known value on reset. This is described
in the ARM Architecture Reference Manual. The reset values for the CP15 registers are
described along with the registers in Chapter 4 System Control.
In addition, before you run the application, you might want to:
• program particular values into various registers, for example, stack pointers
• enable various processor features, for example, error correction
• program particular values into memory, for example, the TCMs.
MPU
If the processor has been built with an MPU, before you can use it you must:
• program and enable at least one of the regions
• enable the MPU in the SCTLR.
See c6, MPU memory region programming registers on page 4-53. Do not enable the MPU
unless at least one MPU region is programmed and active. If the MPU is enabled, before using
the TCM interfaces you must program MPU regions to cover the TCM regions to give access
permissions to them.
FPU
If the processor has been built with a Floating Point Unit (FPU) you must enable it before VFP
instructions can be executed:
• enable access to the FPU in the coprocessor access control register, see c1, Coprocessor
Access Control Register on page 4-47
• enable the FPU by setting the EN-bit in the FPEXC register, see Floating-Point Exception
Register, FPEXC on page 11-9.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-18
ID092411 Non-Confidential
Functional Description
Note
Floating-point logic is only available with the Cortex-R5F processor.
Caches
If the processor has been built with instruction or data caches, these must be invalidated before
they are enabled, otherwise Unpredictable behavior can occur. See Cache operations on
page 4-60.
If you are using an error checking scheme in the cache, you must enable this by programming
the Auxiliary Control Register before invalidating the cache, to ensure that the correct error
code or parity bits are calculated when the cache is invalidated. See c1, Auxiliary Control
Register on page 4-41. An invalidate all operation never reports any ECC or parity errors.
If you are using the ACP, you must perform the data cache invalidation before initiating
coherent ACP transactions. Until then, you must not depend on the coherency maintenance
information signals.
TCM
The processor does not initialize the TCM RAMs. It is not essential to initialize all the memory
attached to the TCM interface but ARM recommends that you do. In addition, the main
application might require you to preload instructions or data into the TCM. This section
describes various ways that you can perform data preloading. You can also configure the
processor to use the TCMs from reset.
Preloading TCMs
You can write data to the TCMs using either store instructions or the AXI slave interface.
Depending on the method you choose, you might require:
• particular hardware on the SoC that you are using
• boot code
• a debugger connected to the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-19
ID092411 Non-Confidential
Functional Description
The error codes in the TCM RAM, if configured with an error scheme, are not initialized by the
processor. Before a RAM location is read with ECC checking enabled, the error codes must be
initialized. To calculate the error code correctly, the logic must have all the data in the data
chunk that those bits protect. Therefore, when the TCM is being initialized, the writes must be
of the same width and aligned to the data chunk that the error scheme protects.
You can initialize the TCM RAM with error checking turned on or off, according to the
following rules. See c1, Auxiliary Control Register on page 4-41. The error code written to the
TCM are valid for the data provided, even if the error checking is turned off.
If the slave port is used, write transactions must be used that write to the TCM memory as
follows:
• If the error scheme is 32-bit ECC, the write transaction must start at a 32-bit aligned
addresses and write a continuous block of memory, containing a multiple of 4 bytes. All
bytes in the block must be written, that is, have their byte lane strobe asserted.
• If the error scheme is 64-bit ECC, the write transaction must start at a 64-bit aligned
addresses and write a continuous block of memory, containing a multiple of 8 bytes. All
bytes in the block must be written, that is, have their byte lane strobe asserted.
If initialization is done by running code on the processor, this is best done by a loop of stores
that write to the whole of the TCM memory as follows:
• If the scheme is 32-bit ECC, use Store Word (STR), Store Two Words (STRD), or Store
Multiple Words (STM) instructions to 32-bit aligned addresses.
• If the scheme is 64-bit ECC, use STRD or STM that has an even number of registers in
the register list, with a 64-bit aligned starting address.
Note
You can use the alignment-checking features of the processor to ensure that memory accesses
are 32-bit aligned, but there is no checking for 64-bit alignment. If you are using STRD or STM,
an alignment fault is generated if the address is not 32-bit aligned. For the same behavior with
STR instructions, enable strict-alignment-checking by setting the A-bit in the SCTLR. See c1,
System Control Register on page 4-38.
If the error scheme is 64-bit ECC, a simpler way to initialize the TCM is:
• Turn on 64-bit store behavior using CP15. See c15, Secondary Auxiliary Control Register
on page 4-44.
• Write to the TCM using any store instructions, or any AXI write transactions. The
processor performs read-modify-write accesses to ensure that all writes are to 64-bit
aligned quantities, even though error checking is turned off.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-20
ID092411 Non-Confidential
Functional Description
Note
You can enable error checking and 64-bit store behavior on a per-TCM interface basis.
References in this section, to these controls relate to whichever TCM is being initialized.
The processor can be pin-configured to enable the TCM interfaces from reset, and to select the
address at which each TCM appears from reset. See TCM initialization on page 8-15 for more
information. This enables you to configure the processor to boot from TCM but, to do this, the
TCM must first be preloaded with the boot code. The nCPUHALTm pin can be asserted while
the processor is in reset to stop the processor from fetching and executing instructions after
coming out of reset. While the processor is halted in this way, the TCMs can be preloaded with
the appropriate data. When the nCPUHALTm pin is deasserted, the processor starts fetching
instructions from the reset vector address in the normal way.
Note
When nCPUHALTm has been deasserted to start the processor fetching, nCPUHALTm must
not be asserted again except when the processor is under processor or power-on reset, that is,
nRESETm asserted. The processor does not halt if the nCPUHALTm pin is asserted while the
processor is running.
Peripheral Interfaces
The memory regions used by the peripheral interfaces are fixed during integration. Before you
access any peripherals that are in those regions, and attached to the peripheral ports, you must
enable the peripheral interfaces. The AXI peripheral interface and the AHB peripheral interface
can be enabled from reset by tying INITPPXm and INITPPHm HIGH respectively. If they are
not enabled at reset your software must enable them by writing to the appropriate CP15 region
register. See Peripheral interface region registers on page 4-84. The virtual AXI peripheral
interface can only be enabled by software.
Note
The virtual peripheral interface region is a sub-region of the AXI peripheral interface region. If
the AXI peripheral interface is enabled, but the virtual AXI peripheral interface is not, then all
accesses to this region of memory use the AXI peripheral port. Enabling the virtual AXI
peripheral interface affects only the ordering and ID behavior of the transactions, not the
physical port that they use.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 2-21
ID092411 Non-Confidential
Chapter 3
Programmers Model
This chapter describes the processor registers and provides an overview for programming the
processor. It contains the following sections:
• About the programmers model on page 3-2
• Modes of operation and execution on page 3-3
• Memory model on page 3-5
• Coherency on page 3-6
• Data structures on page 3-8
• Registers on page 3-9
• Program status registers on page 3-12
• Exceptions on page 3-17
• Acceleration of execution environments on page 3-28
• Unaligned and mixed-endian data access support on page 3-29
• Big-endian instruction support on page 3-30.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-1
ID092411 Non-Confidential
Programmers Model
For more information on the ARM and Thumb instruction sets, see the ARM Architecture
Reference Manual. This chapter describes some of the main features of the architecture but, for
a complete description, see the ARM Architecture Reference Manual.
This chapter also makes reference to older versions of the ARM architecture that the processor
does not implement. These references are included to contrast the behavior of the Cortex-R5
processor with other processors you might have used that implement an older version of the
architecture.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-2
ID092411 Non-Confidential
Programmers Model
ARM state The processor executes 32-bit, word-aligned ARM instructions in this
state.
Thumb state The processor executes 32-bit and 16-bit halfword-aligned Thumb
instructions in this state.
Note
Transition between ARM state and Thumb state does not affect the processor mode or the
register contents.
Switching state
The instruction set state of the processor can be switched between ARM state and Thumb state:
• Using the BX and BLX instructions, by a load to the PC, or with a data-processing instruction
that does not set flags, with the PC as the destination register. Switching state is described
in the ARM Architecture Reference Manual.
Note
When the BXJ instruction is used the processor invokes the BX instruction.
The processor enables you to mix ARM and Thumb code. For more information about
interworking ARM and Thumb, see the RealView Compilation Tools Developer Guide.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-3
ID092411 Non-Confidential
Programmers Model
Modes other than User mode are collectively known as Privileged modes. Privileged modes are
used to service interrupts or exceptions, or access protected resources.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-4
ID092411 Non-Confidential
Programmers Model
The processor can treat words of data in memory as being stored in either:
• Byte-invariant big-endian format
• Little-endian format.
Additionally, the processor supports mixed-endian and unaligned data accesses. For more
information, see the ARM Architecture Reference Manual.
In byte-invariant big-endian (BE-8) format, the processor stores the most significant byte of a
word at the lowest-numbered byte, and the least significant byte at the highest-numbered byte.
Figure 3-1 shows byte-invariant big-endian (BE-8) format.
Memory Register
Address
7 0
A[31:0]
31 24 23 16 15 8 7 0
B0 msbyte B0 B1 B2 B3
+1 B1
+2 B2
+3 B3 lsbyte
In little-endian format, the lowest-numbered byte in a word is the least significant byte of the
word and the highest-numbered byte is the most significant. Figure 3-2 shows little-endian
format.
Memory Register
Address
7 0
A[31:0]
31 24 23 16 15 8 7 0
b0 lsbyte b3 b2 b1 b0
+1 b1
+2 b2
+3 b3 msbyte
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-5
ID092411 Non-Confidential
Programmers Model
3.4 Coherency
In a system with multiple bus masters, memory coherency problems can occur when the masters
access the same memory locations, if one or more of the masters has an associated cache. For
example if there are two masters, A and B, each with its own level-one cache, the following
problems can occur:
• Master A writes to a location in level-2 memory, but write-back caching is used so that
the new value resides in the cache belonging to master A. Subsequent reads of the same
address, by master B, access the old value held in the level-2 memory. This might continue
indefinitely.
• Master B reads a location in level-2 memory and caches the value read in its own cache.
Master A writes to the same location, as in the previous paragraph, except that the write
data propagates to the level-2 memory. If master B reads the same location it gets the old
value held in its cache, rather than the new value that master A wrote.
In a twin-CPU configuration of the Cortex-R5 processor, each CPU can have its own level-1
cache. The Cortex-R5 processor might also be integrated into a system with other bus masters.
In both cases the coherency problems can occur.
Software coherency
Cache maintenance operations can be used to manipulate the caches so that
shared data is visible to other bus masters. In the first example, after master A
writes into its cache data that is to be shared by master B, it must also clean the
appropriate cache locations to ensure that the level-2 memory has been updated.
In the second example, after master A writes data to the level-2 memory, it must
cause master B to invalidate the appropriate cache locations in its cache so that
master B reads the new value from level-2 memory.
The requirement for cache-clean operations can be avoided by using
write-through caching, but invalidate operations are always required. In all cases,
barrier operations are required to ensure that the level-2 memory updates have
taken place before the cache maintenance operations are performed. Cortex-R5
cache maintenance operations are described in Cache operations on page 4-60.
Hardware coherency
Coherency logic, associated with the masters and their caches, performs the
appropriate cache manipulation operations to ensure coherency of data that is
shared between the masters. ARM multi-processing (MP) technology provides
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-6
ID092411 Non-Confidential
Programmers Model
hardware coherency between multiple CPUs and their associated caches within a
cluster, for data that is in a shared memory region. A twin-CPU Cortex-R5 group
is not an MP-cluster. No hardware coherency is provided between the two CPUs,
see CPU configurations on page 1-10 for more information. The Cortex-R5
processor does provide hardware coherency with an external master in limited
situations using the ACP. See Accelerator Coherency Port interface on page 9-53
for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-7
ID092411 Non-Confidential
Programmers Model
Note
• When any of these types are described as unsigned, the N-bit data value represents a
non-negative integer in the range 0 to +2N-1, using normal binary format.
• When any of these types are described as signed, the N-bit data value represents an integer
in the range -2N-1 to +2N-1-1, using two’s complement format.
For best performance you must align these data types in memory as follows:
• doubleword quantities aligned to 8-byte boundaries, doubleword aligned
• word quantities aligned to 4-byte boundaries, word aligned
• halfword quantities aligned to 2-byte boundaries halfword aligned
• byte quantities can be placed on any byte boundary.
The processor supports mixed-endian and unaligned access. For more information, see
Unaligned and mixed-endian data access support on page 3-29.
Note
You cannot use LDRD, LDM, STRD, or STM instructions to access 32-bit quantities if they are not
32-bit aligned.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-8
ID092411 Non-Confidential
Programmers Model
3.6 Registers
The processor has a total of 37 program registers:
• 31 general-purpose 32-bit registers
• six 32-bit status registers.
These registers are not all accessible at the same time. The processor state and operating mode
determine the registers that are available to the programmer.
In the processor the same register set is used in both the ARM and Thumb states. Sixteen general
registers and one or two status registers are accessible at any time. In Privileged modes,
alternative mode-specific banked registers become available. Figure 3-3 on page 3-11 shows the
registers that are available in each mode.
The register set contains 16 directly-accessible registers, R0-R15. Another register, the Current
Program Status Register (CPSR), contains condition code flags, status bits, and current mode
bits. Registers R0-R12 are general-purpose registers that hold either data or address values.
Registers R13, R14, R15, and the CPSR have these special functions:
Stack pointer Software normally uses register R13 as a Stack Pointer (SP). The SRS and
RFE instructions use Register R13.
Link Register Register R14 is used as the subroutine Link Register (LR).
Register R14 receives the return address when a Branch with Link (BL or
BLX) instruction is executed.
You can use R14 as a general-purpose register at all other times. The
corresponding banked registers R14_svc, R14_irq, R14_fiq, R14_abt, and
R14_und similarly hold the return values when interrupts and exceptions
are taken, or when BL or BLX instructions are executed within interrupt or
exception routines.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-9
ID092411 Non-Confidential
Programmers Model
In Privileged modes, another register, the Saved Program Status Register (SPSR), is accessible.
This contains the condition code flags, status bits, and current mode bits saved as a result of the
exception that caused entry to the current mode.
Banked registers have a mode identifier that indicates which mode they relate to. Table 3-1lists
these identifiers.
User usra
Interrupt irq
Supervisor svc
Abort abt
System usra
Undefined und
FIQ mode has seven banked registers mapped to R8–R14 (R8_fiq–R14_fiq). As a result, many
FIQ handlers do not have to save any registers.
The Supervisor, Abort, IRQ, and Undefined modes each have alternative mode-specific
registers mapped to R13 and R14, permitting a private stack pointer and link register for each
mode.
Figure 3-3 on page 3-11 shows the register set, and those registers that are banked.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-10
ID092411 Non-Confidential
Programmers Model
= banked register
Note
For 16-bit Thumb instructions, the high registers, R8–R15, are not part of the standard register
set. You can use special variants of the MOV instruction to transfer a value from a low register, in
the range R0–R7, to a high register, and from a high register to a low register. The CMP instruction
enables you to compare high register values with low register values. The ADD instruction
enables you to add high register values to low register values. For more information, see the
ARM Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-11
ID092411 Non-Confidential
Programmers Model
31 30 29 28 27 26 25 24 23 20 19 16 15 10 9 8 7 6 5 4 0
The N, Z, C, and V bits are the condition code flags. You can optionally set them with arithmetic
and logical operations, and also with MSR instructions and MRC instructions to R15. The processor
tests these flags in accordance with an instruction's condition code to determine whether to
execute that instruction.
In ARM state, most instructions can execute conditionally on the state of the N, Z, C, and V bits.
The exceptions are:
• BKPT
• CPS
• LDC2
• MCR2
• MCRR2
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-12
ID092411 Non-Confidential
Programmers Model
• MRC2
• MRRC2
• PLD
• RFE
• SETEND
• SRS
• STC2.
In Thumb state, the processor can only execute the Branch instruction conditionally. Other
instructions can be made conditional by placing them in the If-Then (IT) block. For more
information about conditional execution in Thumb state, see the ARM Architecture Reference
Manual.
Certain multiply and fractional arithmetic instructions can set the Sticky Overflow, Q, flag:
• QADD
• QDADD
• QSUB
• QDSUB
• SMLAD
• SMLAxy
• SMLAWy
• SMLSD
• SMUAD
• SSAT
• SSAT16
• USAT
• USAT16.
The Q flag is sticky in that, when an instruction sets it, this bit remains set until an MSR instruction
writing to the CPSR explicitly clears it. Instructions cannot execute conditionally on the status
of the Q flag.
To determine the status of the Q flag you must read the PSR into a register and extract the Q flag
from this. For information of how the Q flag is set and cleared, see individual instruction
definitions in the ARM Architecture Reference Manual.
IT[7:5] encodes the base condition code for the current IT block, if any. It contains b000 when
no IT block is active.
IT[4:0] encodes the number of instructions that are to be conditionally executed, and whether
the condition for each is the base condition code or the inverse of the base condition code. It
contains b00000 when no IT block is active.
When an IT instruction is executed, these bits are set according to the condition in the
instruction, and the Then and Else (T and E) parameters in the instruction. During execution of
an IT block, IT[4:0] is shifted to:
• reduce the number of instructions to be conditionally executed by one
• move the next bit into position to form the least significant bit of the condition code.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-13
ID092411 Non-Confidential
Programmers Model
For more information on the operation of the IT execution state bits, see the ARM Architecture
Reference Manual.
Note
You cannot use an MSR to change the J bit in the CPSR.
Software must not modify the Do Not Modify (DNM) bits. These bits are:
• Readable, to preserve the state of the processor, for example, during process context
switches.
• Writable, to enable the processor to restore its state. To maintain compatibility with future
ARM processors, and as good practice, use a read-modify-write strategy when you
change the CPSR.
Some of the SIMD instructions set GE[3:0] as greater-than-or-equal bits for individual
halfwords or bytes of the result, as Table 3-2 shows.
Signed
Unsigned
UADD16 [31:16] + [31:16] ≥ 216 [31:16] + [31:16] ≥ 216 [15:0] + [15:0] ≥ 216 [15:0] + [15:0] ≥ 216
UADDSUBX [31:16] + [15:0] ≥ 216 [31:16] + [15:0] ≥ 216 [15:0] - [31:16] ≥ 0 [15:0] - [31:16] ≥ 0
USUBADDX [31:16] - [15:0] ≥ 0 [31:16] - [15:0] ≥ 0 [15:0] + [31:16] ≥ 216 [15:0] + [31:16] ≥216
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-14
ID092411 Non-Confidential
Programmers Model
Note
GE bit is 1 if A op B ≥ C, otherwise 0.
The SEL instruction uses GE[3:0] to select which source register supplies each byte of its result.
See the ARM Architecture Reference Manual for more information.
ARM and Thumb instructions are provided to set and clear the E bit. The E bit controls
load/store endianness. See the ARM Architecture Reference Manual for information on where
the E bit is used.
The A bit is set automatically by certain exceptions and is written by privileged software. It
disables asynchronous Data Aborts. For more information on how to use the A bit, see
Asynchronous abort masking on page 3-24.
Software can use MSR, CPS, MOVS pc, SUBS pc, LDM ..,{..pc}^, or RFE instructions to change the
values of the I and F bits. They are also set automatically by some exceptions.
When NMFIs are enabled, updates to the F bit are restricted. For more information see
Non-maskable fast interrupts on page 3-20.
Note
Never use an MSR instruction to force a change to the state of the T bit in the CPSR. The processor
ignores any attempt to modify the T bit using an MSR instruction.
M[4:0] are the mode bits. These bits determine the processor operating mode as Table 3-3
shows.
M[4:0] Mode
b10000 User
b10001 FIQ
b10010 IRQ
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-15
ID092411 Non-Confidential
Programmers Model
M[4:0] Mode
b10011 Supervisor
b10111 Abort
b11011 Undefined
b11111 System
Note
• In Privileged mode an illegal value programmed into M[4:0] causes the processor to enter
System mode.
In the ARMv7-R architecture each CPSR bit falls into one of these categories:
• Bits that are freely modifiable from any mode, either directly by MSR instructions or by
other instructions whose side-effects include writing the specific bit or writing the entire
CPSR.
Bits in Figure 3-4 on page 3-12 that are in this category are N, Z, C, V, Q, GE[3:0], and E.
• Bits that an MSR instruction must never modify, and so must only be written as a side-effect
of another instruction. If an MSR instruction tries to modify these bits, the results are
architecturally Unpredictable. In the processor these bits are not affected.
The bits in Figure 3-4 on page 3-12 that are in this category are the execution state bits
[26:24], [15:10], and [5].
• Bits that can only be modified from Privileged modes, and that instructions completely
protect from modification while the processor is in User mode. Entering a processor
exception is the only way to modify these bits while the processor is in User mode, as
described in Exceptions on page 3-17.
Bits in Figure 3-4 on page 3-12 that are in this category are A, I, F, and M[4:0].
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-16
ID092411 Non-Confidential
Programmers Model
3.8 Exceptions
Exceptions are taken whenever the normal flow of a program must temporarily halt, for
example, to service an interrupt from a peripheral. Before attempting to handle an exception, the
processor preserves the critical parts of the processor state so that the original program can
resume when the handler routine has finished.
Note
When the processor is in debug halt state, and an exception occurs, it is handled differently to
normal. See Exceptions in debug state on page 12-48 for more information
Table 3-4 summarizes the PC value preserved in the relevant R14 on exception entry, and the
instruction ARM recommends for exiting the exception handler.
Previous state
Exception Recommended return
Notes
or entry instruction
ARM R14_x Thumb R14_x
SVCa MOVS PC, R14_svc IA + 4 IA + 2 Where the IA is the address of the SVC or
Undefined Instruction.
UNDEF Variesb IA + 4 IA + 2
PABT SUBS PC, R14_abt, #4 IA + 4 IA + 4 Where the IA is the address of instruction that had
the Prefetch Abort.
FIQ SUBS PC, R14_fiq, #4 IA + 4 IA + 4 Where the IA is the address of the instruction that
was not executed because the FIQ or IRQ took
IRQ SUBS PC, R14_irq, #4 IA + 4 IA + 4 priority.
DABT SUBS PC, R14_abt, #8 IA + 8 IA + 8 Where the IA is the address of the Load or Store
instruction that generated the Data Abort.
a. Formerly SWI.
b. The return instruction you must use after an Undefined Instruction exception has been handled depends on whether you want to retry the
undefined instruction or not and, if not, on the size of the Undefined instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-17
ID092411 Non-Confidential
Programmers Model
Taking an exception
1. Preserves the address of the next instruction in the appropriate R14(LR). When the
exception is taken from:
ARM state
The processor writes the address of the instruction into the LR, offset by a value
(current IA + 4 or IA + 8 depending on the exception) that causes the program
to resume from the correct place on return.
Thumb state
The processor writes the address of the instruction into the LR, offset by a value
(current IA + 2, IA + 4 or IA + 8 depending on the exception) that causes the
program to resume from the correct place on return.
2. Copies the CPSR into the appropriate SPSR. Depending on the exception type, the
processor might modify the IT execution state bits of the CPSR prior to this operation to
facilitate a return from the exception.
3. Forces the CPSR mode bits to a value that depends on the exception and clears the IT
execution state bits in the CPSR.
4. Sets the E bit based on the state of the EE bit in the SCTLR, see c1, System Control
Register on page 4-38.
5. The T bit is set based on the state of the TE bit in the SCTLR, see c1, System Control
Register on page 4-38.
6. Forces the PC to fetch the next instruction from the relevant exception vector.
The processor can also set the interrupt disable flags to prevent otherwise unmanageable nesting
of exceptions.
Leaving an exception
When an exception has completed, the exception handler must move the LR, minus an offset,
to the PC. The offset varies according to the type of exception, as Table 3-4 on page 3-17 shows.
Typically the return instruction is an arithmetic or logical operation with the S bit set and Rd =
R15, so the processor copies the SPSR back to the CPSR. Alternatively, an LDM ..,{..pc}^ or
RFE instruction can perform a similar operation if the return state has been pushed onto a stack.
Note
The action of restoring the CPSR from the SPSR:
• Automatically restores the T, E, A, I, and F bits to the value they held immediately prior
to the exception.
• Normally resets the IT execution state bits to the values held immediately prior to the
exception. If the exception handler wants to return to the following instruction, these bits
might require to be manually advanced to avoid applying the incorrect condition codes to
that instruction. For more information about the IT instruction elements and Undefined
instructions, and an example of the exception handler code, see the ARM Architecture
Reference Manual.
Because SVC handlers are always expected to return after the SVC instruction, the IT
execution state bits are automatically advanced when an exception is taken prior to
copying the CPSR into the SPSR.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-18
ID092411 Non-Confidential
Programmers Model
3.8.2 Reset
When the nRESETm signal is driven LOW a reset occurs, and the processor abandons the
executing instruction.
When nRESETm and nCPUHALTm are driven HIGH again the processor:
1. Forces CPSR M[4:0] to b10011 (Supervisor mode) and sets the A, I, and F bits in the
CPSR. The E bit is set based on the state of the CFGEE pin. Other bits in the CPSR are
indeterminate.
2. Forces the PC to fetch the next instruction from the reset vector address.
3. Reverts to ARM state or Thumb state depending on the state of the TEINIT pin, and
resumes execution.
After reset, all register values except the PC and CPSR are indeterminate.
See Resets on page 2-12 for more information on the reset behavior for the processor.
3.8.3 Interrupts
The processor has two interrupt inputs, for normal interrupts (nIRQm) and fast interrupts
(nFIQm). Each interrupt pin, when asserted and not masked, causes the processor to take the
appropriate type of interrupt exception. See Exceptions on page 3-17 for more information. The
CPSR.F and CPSR.I bits control masking of fast and normal interrupts respectively.
A number of features exist to improve the interrupt latency, that is, the time taken between the
assertion of the interrupt input and the execution of the interrupt handler. By default, the
processor uses the Low Interrupt Latency (LIL) behaviors introduced in version 6 and later of
the ARM architecture. The processor also has a port for connection of a Vectored Interrupt
Controller (VIC), and supports Non-Maskable Fast Interrupts (NMFI).
Interrupt request
The IRQ exception is a normal interrupt caused by a LOW level on the nIRQm input. An IRQ
has a lower priority than an FIQ, and is masked on entry to an FIQ sequence. You must ensure
that the nIRQm input is held LOW until the processor acknowledges the interrupt request,
either from the VIC interface or the software handler.
Irrespective of whether the exception is taken from ARM state or Thumb state, an IRQ handler
returns from the interrupt by executing:
SUBS PC, R14_irq, #4
You can disable IRQ exceptions within a Privileged mode by setting the CPSR.I bit to b1. See
Program status registers on page 3-12. IRQ interrupts are automatically disabled when an IRQ
occurs, by setting the CPSR.I bit. You can use nested interrupts but it is up to you to save any
corruptible registers and to re-enable IRQs by clearing the CPSR.I bit.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-19
ID092411 Non-Confidential
Programmers Model
The Fast Interrupt Request (FIQ) reduces the execution time of the exception handler relative
to a normal interrupt. FIQ mode has eight private registers to reduce, or even remove the
requirement for register saving (minimizing the overhead of context switching).
An FIQ is externally generated by taking the nFIQm input signal LOW. You must ensure that
the nFIQm input is held LOW until the processor acknowledges the interrupt request from the
software handler.
Irrespective of whether exception entry is from ARM state or Thumb state, an FIQ handler
returns from the interrupt by executing:
SUBS PC, R14_fiq, #4
If Non-Maskable Fast Interrupts (NMFIs) are not enabled, you can mask FIQ exceptions by
setting the CPSR.F bit to b1. For more information see:
• Program status registers on page 3-12
• Non-maskable fast interrupts.
FIQ and IRQ interrupts are automatically masked by setting the CPSR.F and CPSR.I bits when
an FIQ occurs. You can use nested interrupts but it is up to you to save any corruptible registers
and to re-enable interrupts.
When NMFI behavior is enabled, FIQ interrupts cannot be masked by software. Enabling NMFI
behavior ensures that when the FIQ mask, that is, the CPSR.F bit, has been cleared by the reset
handler, fast interrupts are always taken as quickly as possible, except during handling of a fast
interrupt. This makes the fast interrupt suitable for signaling critical events. NMFI behavior is
controlled by a configuration input signal CFGNMFIm, that is asserted HIGH to enable NMFI
operation. There is no software control of NMFI.
Software can detect whether NMFI operation is enabled by reading the NMFI bit of the SCTLR:
NMFI == 0 Software can mask FIQs by setting the CPSR.F bit to b1.
NMFI == 1 Software cannot mask FIQs.
For more information see c1, System Control Register on page 4-38.
Low Interrupt Latency (LIL) is a set of behaviors that reduce the interrupt latency for the
processor, and is enabled by default. That is, the FI bit [21] in the SCTLR is Read-as-One.
LIL behavior enables accesses to Normal memory, including multiword accesses and external
accesses, to be abandoned part-way through execution so that the processor can react to a
pending interrupt faster than would otherwise be the case. When an instruction is abandoned in
this way, the processor behaves as if the instruction was not executed at all. If, after handling the
interrupt, the interrupt handler returns to the program in the normal way using instruction SUBS
pc, r14, #4, the abandoned instruction is re-executed. This means that some of the memory
accesses generated by the instruction are performed twice.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-20
ID092411 Non-Confidential
Programmers Model
Memory that is marked as Strongly Ordered or Device type is typically sensitive to the number
of reads or writes performed. Because of this, instructions that access Strongly Ordered or
Device memory are never abandoned when they have started accessing memory. These
instructions always complete either all or none of their memory accesses. The same is true of all
accesses to the AXI peripheral port, regardless of the memory type. Therefore, to minimize the
interrupt latency, you must avoid the use of multiword load/store instructions to memory
locations that are marked as Strongly Ordered or Device or are in the AXI or virtual AXI
peripheral interface.
Interrupt controller
The processor includes a VIC port for connection of a Vectored Interrupt Controller (VIC). An
interrupt controller is a peripheral that handles multiple interrupt sources. Features usually
found in an interrupt controller are:
• multiple interrupt request inputs, one for each interrupt source, and one or more
amalgamated interrupt request outputs to the processor
In a system with an interrupt controller with these features, software is still required to:
• determine from the interrupt controller which interrupt source is requesting service
• determine where the service routine for that interrupt source is loaded
• mask or clear that interrupt source, before re-enabling processor interrupts to permit
another interrupt to be taken.
A VIC does all these in hardware to reduce the interrupt latency. It supplies the starting address
of the service routine corresponding to the highest priority asserted interrupt source directly to
the processor. When the processor has accepted this address, it masks the interrupt so that the
processor can re-enable interrupts without clearing the source. The PL192 VIC is an Advanced
Microcontroller Bus Architecture (AMBA) compliant, System-on-Chip (SoC) peripheral that is
developed, tested, and licensed by ARM.
You can use the VIC port to connect a PL192 VIC to the processor. See the ARM PrimeCell
Vectored Interrupt Controller (PL192) Technical Reference Manual for more information about
the PL192 VIC. You can enable the VIC port by setting the VE bit in the SCTLR. When the VIC
port is enabled and an IRQ occurs, the processor performs an handshake over the VIC interface
to obtain the address of the handling routine for the IRQ.
Figure 3-5 on page 3-22 is a flowchart for processor interrupt recognition. It shows all the
necessary decisions and actions for a complete interrupt entry.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-21
ID092411 Non-Confidential
Programmers Model
Start
!VE || VIC
TRUE handshake
complete
FALSE
!((nFIQ||F)
&& FALSE VE==1
(nIRQ||I))
TRUE FALSE
SPSR_irq = CPSR
!(nFIQ||F) FALSE
LR_irq = RA+4
TRUE
CPSR[4:0] = IRQ mode
SPSR_fiq = CPSR
CPSR[5] = TE
LR_fiq = RA+4
CPSR[7] = 1
CPSR[4:0] = FIQ mode
CPSR[5] = TE
V==1 FALSE VE==1
CPSR[7] = 1, CPSR[6] = 1
TRUE
FALSE
V==1 Is VIC ready to
TRUE FALSE provide handler
address?
For information on the I and F bits that Figure 3-5 shows, see Program status registers on
page 3-12. For information on the V and VE bits that Figure 3-5 shows, see c1, System Control
Register on page 4-38.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-22
ID092411 Non-Confidential
Programmers Model
3.8.4 Aborts
When the processor memory system cannot complete a memory access successfully, an abort is
generated. Aborts can occur for a number of reasons, for example:
• a permission fault indicated by the MPU
• an error response to a transaction on the AMBA memory bus
• an error detected in the data by the ECC checking logic.
An error occurring on an instruction fetch generates a prefetch abort. Errors occurring on data
accesses generate data aborts. Aborts are also categorized as either synchronous, previously
known as precise, or asynchronous, previously known as imprecise.
When a prefetch or data abort occurs, the processor takes the appropriate type of exception. See
Exception entry and exit summary on page 3-17 for more information. Additional information
about the type of abort is stored in registers, and signaled as events. See Fault handling on
page 8-7 for more information about the types of fault that can cause an abort and the
information that the processor provides about these faults.
Prefetch aborts
When a Prefetch Abort (PABT) occurs, the processor marks the prefetched instruction as
invalid, but does not take the exception until the instruction is to be executed. If the instruction
is not executed, for example because a branch occurs while it is in the pipeline, the abort does
not take place.
Data aborts
An error occurring on a data memory access can generate a data abort. If the instruction
generating the memory access is not executed, for example, because it fails its condition codes,
or is interrupted, the data abort does not take place.
A Data Abort (DABT) can be either synchronous or asynchronous, depending on the type of
fault that caused it.
The Cortex-R5 processor implements the base restored Data Abort model, as opposed to a base
updated Data Abort model.
With the base restored Data Abort model, when a Data Abort exception occurs during the
execution of a memory access instruction, the processor hardware always restores the base
register to the value it contained before the instruction was executed. For more information, see
the ARM Architecture Reference Manual.
Synchronous aborts
A synchronous abort, also known as a precise abort, is one for which the exception is guaranteed
to be taken on the instruction that generated the aborting memory access. The abort handler can
use the value in the Link Register (r14_abt) to determine which instruction generated the abort,
and the value in the Saved Program Status Register (SPSR_abt) to determine the state of the
processor when the abort occurred.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-23
ID092411 Non-Confidential
Programmers Model
Asynchronous aborts
An asynchronous abort, also known as an imprecise abort, is one for which the exception is
taken on a later instruction than the instruction that generated the aborting memory access. The
abort handler cannot determine which instruction generated the abort, or the state of the
processor when the abort occurred. Therefore, asynchronous aborts are normally fatal.
The nature of asynchronous aborts means that they can occur while the processor is handling a
different abort. If an asynchronous abort generates a new exception in such a situation, the
r14_abt and SPSR_abt values are overwritten. If this occurs before the data is pushed to the
stack in memory, the state information about the first abort is lost. To prevent this from
happening, the CPSR contains a mask bit to indicate that an asynchronous abort cannot be
accepted, the A-bit. When the A-bit is set, any asynchronous abort that occurs is held pending
by the processor until the A-bit is cleared, when the exception is actually taken. The A-bit is
automatically set when abort, IRQ or FIQ exceptions are taken, and on reset. You must only
clear the A-bit in an abort handler after the state information has either been stacked to memory,
or is no longer required.
Only one pending asynchronous abort of each asynchronous abort type is supported. The
processor supports the following pending asynchronous aborts:
• AXI peripheral port external error from either main or virtual interface access.
If a subsequent AXI peripheral port error is signalled while another one is pending, the
later one is ignored and only one abort is taken.
Memory barriers
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-24
ID092411 Non-Confidential
Programmers Model
When a memory access generates an abort, the instruction generating that access is abandoned,
even if it has not completed all its memory accesses, and the abort exception is taken. The abort
handler can then do one of the following:
• fix the error and return to the instruction that was abandoned, to re-execute it
• perform the appropriate data transfers on behalf of the aborted instruction and return to
the instruction after the abandoned instruction
If the abort handler returns to the abandoned instruction, some of the memory accesses
generated are repeated. The effect is that multiword load/store instructions can access the same
memory location twice. The first access occurs before the abort is detected, and the second when
the instruction is restarted.
In Strongly Ordered or Device type memory, repeating memory accesses might have
unacceptable side-effects. Therefore, if the abort handler can fix the error and re-execute the
aborted instruction, you must ensure that for all memory errors on multiword load/store
instructions, either:
• all side effects of repeating accesses are inconsequential
• the error must either occur on the first word accessed or not at all.
• All forms of ARM instructions LDM, and LDRD, all forms of STM, STRD including VFP
variants, and unaligned LDR, STR, LDRH, and STRH
• Thumb instructions LDMIA, LDRD, SDRD, PUSH, POP, and STMIA including VFP variants, and
unaligned LDR, STR, LDRH, and STRH.
Abort handler
If you configure the processor with parity or ECC on the caches or the TCMs, and the abort
handler is in one of these memories, then it is possible for a parity or ECC error to occur in the
abort handler. If the error is not recoverable, then a synchronous abort occurs and the processor
loops until the next interrupt. The LR and SPSR values for the original abort are also lost.
Therefore, you must construct software that ensures that no synchronous aborts occur when in
the abort handler. This means the abort handler must be in external memory and not cached.
You can use the SuperVisor Call (SVC) instruction (formerly SWI) to enter Supervisor mode,
usually to request a particular supervisor function. The SVC handler reads the opcode to extract
the SVC function number. A SVC handler returns by executing the following instruction,
irrespective of the processor operating state:
MOVS PC, R14_svc
This action restores the PC and CPSR, and returns to the instruction following the SVC.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-25
ID092411 Non-Confidential
Programmers Model
The processor modifies the IT execution state bits on exception entry so that the values that the
processor writes into the SPSR are correct for the instruction following the SVC. This means
that the SVC handler does not have to perform any special action to accommodate the IT
instruction. For more information on the IT instruction, see the ARM Architecture Reference
Manual.
Software can use this mechanism to extend the ARM instruction set by emulating Undefined
coprocessor instructions. Undefined Instruction exceptions also occur when a UDIV or SDIV
instruction is executed, the value in Rm is zero, and the DZ bit in the SCTLR is set.
If the handler is required to return after the instruction that caused the Undefined Instruction
exception, it must:
• Advance the IT execution state bits in the SPSR before restoring SPSR to CPSR. This is
so that the correct condition codes are applied to the next instruction on return. The
pseudo-code for advancing the IT bits is:
Mask = SPSR[11,10,26,25];
if (Mask != 0) {
Mask = Mask << 1;
SPSR[12,11,10,26,25] = Mask;
}
if (Mask[3:0] == 0) {
SPSR[15:12] = 0;
}
• Obtain the instruction that caused the Undefined Instruction exception and return
correctly after it. Exception handlers must also be aware of the potential for both 16-bit
and 32-bit instructions in Thumb state.
After testing the SPSR and determining the instruction was executed in Thumb state, the
Undefined handler must use the following pseudo-code or equivalent to obtain this
information:
addr = R14_undef - 2
instr = Memory[addr,2]
if (instr >> 11) > 28 { /* 32-bit instruction */
instr = (instr << 16) | Memory[addr+2,2]
if (emulating, so return after instruction wanted) }
R14_undef += 2 //
} //
}
After this, instr holds the instruction (in the range 0x0000-0xE7FF for a 16-bit instruction,
0xE8000000-0xFFFFFFFF for a 32-bit instruction), and the exception can be returned from
using a MOVS PC, R14 to return after it.
IRQs are disabled when an Undefined Instruction trap occurs. For more information about
Undefined instructions, see the ARM Architecture Reference Manual.
A breakpoint (BKPT) instruction operates as though the instruction causes a Prefetch Abort.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-26
ID092411 Non-Confidential
Programmers Model
A breakpoint instruction does not cause the processor to take the Prefetch Abort exception until
the instruction is to be executed. If the instruction is not executed, for example because a branch
occurs while it is in the pipeline, the breakpoint does not take place.
After dealing with the breakpoint, the handler executes the following instruction irrespective of
the processor operating state:
SUBS PC, R14_abt, #4
This action restores both the PC and the CPSR, and retries the breakpointed instruction.
Note
If the ETM-R5 is configured into Halt debug-mode, a breakpoint instruction causes the
processor to enter debug state. See Halting debug-mode debugging on page 12-3.
You can configure the location of the exception vector addresses by setting the V bit in CP15 c1
System Control Register to enable HIVECS, as Table 3-5 shows.
Exception vector
Value of V bit
base location
0 0x00000000
1 (HIVECS) 0xFFFF0000
Table 3-6 shows the exception vector addresses and entry conditions for the different exception
types.
Offset from
Exception Mode on entry A bit on entry F bit on entry I bit on entry
vector base
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-27
ID092411 Non-Confidential
Programmers Model
Table 3-7 shows the Jazelle register instruction summary and the response to the instructions.
Jazelle main configuration MRC p14, 7, <Rd>, c2, c0, 0 Read as zero
MCR p14, 7, <Rd>, c2, c0, 0 Ignore writes
Note
Because no hardware acceleration is present in the processor, when the BXJ instruction is used,
the BX instruction is invoked.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-28
ID092411 Non-Confidential
Programmers Model
The processor supports byte-invariant big-endianness BE-8 and little-endianness LE. The
processor does not support word-invariant big-endianness BE-32. Bit [7] of c1, Control Register
is always 0.
For more information on unaligned and mixed-endian data access support, see the ARM
Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-29
ID092411 Non-Confidential
Programmers Model
Note
The facility to use big-endian or little-endian instruction format is an implementation option,
and you can therefore remove it in specific implementations. If this facility is not present, the
CFGIE pin is still reflected in the SCTLR but the instruction format is always little-endian. The
Build Options Register indicates whether the processor has been built with instruction
endianness control. See Build Options Registers on page 4-79.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 3-30
ID092411 Non-Confidential
Chapter 4
System Control
This chapter describes the system control registers, their structure, operation, and how to use
them. It contains the following sections:
• About system control on page 4-2
• Register summary on page 4-7
• Register descriptions on page 4-9.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-1
ID092411 Non-Confidential
System Control
The system control coprocessor, CP15, controls and provides status information for the
functions implemented in the processor. The main functions of the system control coprocessor
are:
• overall system control and configuration
• cache configuration and management
• Memory Protection Unit (MPU) configuration and management
• system performance monitoring.
The system control coprocessor does not exist in a distinct physical block of logic.
The system control and configuration registers provide overall management of:
• memory functionality
• interrupt behavior
• exception handling
• program flow prediction
• coprocessor access rights for CP0-CP13, including the VFP, CP10-11.
The system control and configuration registers also provide the processor ID and information
on configured options.
The system control and configuration registers consist of 18 read-only registers and seven
read/write registers. Figure 4-1 shows the arrangement of registers in this functional group.
Some of the functionality depends on how you set external signals at reset.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-2
ID092411 Non-Confidential
System Control
The MPU control and configuration registers consist of one read-only register and 11 read/write
registers. Figure 4-2 shows the arrangement of registers in this functional group.
• provide information on the size and architecture of the instruction and data caches
• control cache maintenance operations that include clean and invalidate caches, drain and
flush buffers, and address translation
The cache control and configuration registers consist of three read-only registers, one read/write
register, and a number of write-only registers. Figure 4-3 on page 4-4 shows the arrangement of
the registers in this functional group.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-3
ID092411 Non-Confidential
System Control
The interface control and configuration registers consist of two read-only registers and six
read/write registers. Figure 4-4 shows the arrangement of registers.
The system performance monitor consists of 12 read/write registers. Figure 4-5 on page 4-5
shows the arrangement of registers in this functional group.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-4
ID092411 Non-Confidential
System Control
System performance monitoring counts system events, such as cache misses, pipeline stalls, and
other related features to enable system developers to profile the performance of their systems.
It can generate interrupts when the number of events reaches a given value.
For more information on the programmers model of the performance counters, see the ARM
Architecture Reference Manual. See Chapter 6 Events and Performance Monitor for more
information on the registers.
The system validation registers extend the use of the system performance monitor registers to
provide some functions for validation. You must not use them for other purposes. The system
validation registers schedule and clear:
• resets
• interrupts
• fast interrupts
• external debug requests.
The system validation registers consist of nine read/write registers and one write-only register.
Figure 4-6 shows the arrangement of registers.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-5
ID092411 Non-Confidential
System Control
You can only change the cache size to a size supported by the cache RAMs implemented in your
design.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-6
ID092411 Non-Confidential
System Control
Table 4-1 shows the overall functionality for the system control coprocessor, provided through
the registers. The registers are listed in their functional groups.
Table 4-2 on page 4-9 lists the registers in the system control processor, in register order, and
gives the reset value for each register.
Coprocessor Access Control c1, Coprocessor Access Control Register on page 4-47
Secondary Auxiliary Control Register c15, Secondary Auxiliary Control Register on page 4-44
Software compatibility Thread And Process ID c13, Thread and Process ID Registers on page 4-67
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-7
ID092411 Non-Confidential
System Control
MPU control and Data Fault Status c5, Data Fault Status Register on page 4-49
configuration
Auxiliary Fault Status c5, Auxiliary Fault Status Registers on page 4-51
Instruction Fault Status c5, Instruction Fault Status Register on page 4-50
Instruction Fault Address c6, Instruction Fault Address Register on page 4-53
Data Fault Address c6, Data Fault Address Register on page 4-53
Region Base Address c6, MPU Region Base Address Registers on page 4-54
Region Size and Enable c6, MPU Region Size and Enable Registers on page 4-55
Region Access Control c6, MPU Region Access Control Registers on page 4-56
Memory Region Number c6, MPU Region Number Register on page 4-59
Correctable Fault Location Register Correctable Fault Location Register on page 4-77
Cache control and Cache Type c0, Cache Type Register on page 4-15
configuration
Current Cache Size Identification c0, Cache Size ID Register on page 4-34
Cache Size Selection c0, Cache Size Selection Register on page 4-37
Interface control and TCM Status c0, TCM Type Register on page 4-16
configuration
Region c9, BTCM Region Register on page 4-63
c9, ATCM Region Register on page 4-64
c9, TCM Selection Register on page 4-65
Slave Port Control c11, Slave Port Control Register on page 4-65
Peripheral Port Region Registers. Peripheral interface region registers on page 4-84
a. Known as the ID Code Register on previous designs. Returns the device ID code.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-8
ID092411 Non-Confidential
System Control
For more information on using the system control coprocessor and the general method of how
to access CP15 registers, see the ARM Architecture Reference Manual.
Table 4-2 shows a summary of address allocation and reset values for the registers in the system
control coprocessor where:
• CRn is the register number within CP15
• Op1 is the Opcode_1 value for the register
• CRm is the operational register
• Op2 is the Opcode_2 value for the register.
CRn Op1 CRm Op2 Register or operation Type Reset value Page
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-9
ID092411 Non-Confidential
System Control
CRn Op1 CRm Op2 Register or operation Type Reset value Page
2-6 Undefined - - -
3-7 Undefined - - -
c1-c15 0-7
2-7 Undefined - - -
2-7 Undefined - - -
c2-c15 0-7
1 Undefined - - -
3-7 Undefined - - -
1 Undefined - - -
3 Undefined - - -
5-7 Undefined - - -
1-7 Undefined - - -
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-10
ID092411 Non-Confidential
System Control
CRn Op1 CRm Op2 Register or operation Type Reset value Page
c3-c15 1-7
c7 0 c0 0-3 Undefined - - -
5-7 Undefined - - -
c1-c4 0-7
2-3 Undefined - - -
5 Undefined - - -
c6 0 Undefined - - -
3-7 Undefined - - -
c7-9 0-7
c10 0
3 Undefined - - -
6-7 Undefined - - -
c11 0
2-7 Undefined - - -
c12 0-7
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-11
ID092411 Non-Confidential
System Control
CRn Op1 CRm Op2 Register or operation Type Reset value Page
c13 0
1 NOP Write-only - -
2-7 Undefined - - -
c14 0
c14 2 Clean and invalidate data cache line by Write-only - page 4-61
Set/Way
3-7 Undefined - - -
c15 0-7
c9 0 c0 0-7 Undefined - - -
2-7 Undefined - - -
1-7 Undefined - - -
c3-c11 0-7
6-7 Undefined - - -
3-7 Undefined - - -
3-7 Undefined - - -
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-12
ID092411 Non-Confidential
System Control
CRn Op1 CRm Op2 Register or operation Type Reset value Page
c15 0-7
c0 1-7 Undefined - - -
c1-c15 0-7
5-7 Undefined - - -
4-7 Undefined - - -
2-6 Undefined - - -
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-13
ID092411 Non-Confidential
System Control
CRn Op1 CRm Op2 Register or operation Type Reset value Page
c3 1-7 Undefined - - -
c4 0-7
1-7 Undefined - - -
c6-c13 0-7
1-7 Undefined - - -
c15 0-7
a. The value of bits [23:20,3:0] of the MIDR depend on product revision. See the register description for more information.
b. Reset value depends on number of MPU regions.
c. Reset value depends on which caches are implemented and their sizes.
d. See register description for more information.
Purpose Returns the device ID code that contains information about the processor
31 24 23 20 19 16 15 4 3 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-14
ID092411 Non-Confidential
System Control
[23:20] Variant Identifies the major revision of the processor. This is the major revision number n in the rn part of
the rnpn description of the product revision status.
[3:0] Revision Identifies the minor revision of the processor. This is the minor revision number n in the pn part of
the rnpn description of the product revision status.
Note
If an MRC instruction is executed with CRn = c0, Opcode_1 = 0, CRm = c0, and an Opcode_2
value corresponding to an unimplemented or reserved ID register, the system control
coprocessor returns the value of the MIDR.
For more information on the processor features, see The Processor Feature Registers on
page 4-19.
Purpose Determines the instruction and data minimum line length in bytes, to
enable a range of addresses to be invalidated.
31 28 27 24 23 20 19 16 15 14 13 4 3 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-15
ID092411 Non-Confidential
System Control
[19:16] DMinLine Indicates log2 of the number of words in the smallest cache line of the data and unified caches controlled
by the processor:
0x3 = Eight words in an L1 data cache line.
[3: 0] IMinLine Indicates log2 of the number of words in the smallest cache line of the instruction caches controlled by the
processor:
0x3 - Eight words in an L1 instruction cache line.
Purpose Informs the processor of the number of ATCMs and BTCMs in the system
31 30 29 28 19 18 16 15 3 2 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-16
ID092411 Non-Confidential
System Control
[28:19] - SBZ.
[18:16] BTCM Specifies the number of BTCMs implemented. This is always set to b001 because the processor has one BTCM.
[15:3] - SBZ.
[2:0] ATCM Specifies the number of ATCMs implemented. Always set to b001. The processor has one ATCM.
Note
• The ATCM and BTCM fields in the TCMTR occupy the same space respectively as the
ITCM and DTCM fields as defined by the ARM architecture. These fields, and the
corresponding TCM interfaces, can be considered equivalent to those defined in the
architecture.
• The ARM architecture requires only the ITCM to be accessible from both instruction and
data sides. In the Cortex-R5 processor, both ATCM and BTCM are accessible from both
instruction and data sides.
Purpose Holds the value for the number of instruction and data memory regions
implemented in the processor.
31 16 8 7 1 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-17
ID092411 Non-Confidential
System Control
[31:16] - SBZ.
[15:8] DRegion Specifies the number of unified MPU regions. Set to 0, 12, or 16 data MPU regions.
[7:1] - SBZ.
[0] S Specifies the type of MPU regions, unified or separate, in the processor.
Always set to 0, the processor has unified memory regions.
31 30 29 24 23 16 8 7 0
Multiprocessor extensions
[29:24] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-18
ID092411 Non-Confidential
System Control
There are two Processor Feature Registers, PFR0 and PFR1. This section describes:
• c0, Processor Feature Register 0
• c0, Processor Feature Register 1 on page 4-20.
Purpose Provides information about the execution state support and programmers
model for the processor.
31 16 15 12 11 8 7 4 3 0
[31:16] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-19
ID092411 Non-Confidential
System Control
[11:8] State2 Indicates support for acceleration of execution environments in hardware or software.
0x1 = the processor supports acceleration of execution environments in software.
[7:4] State1 Indicates type of Thumb encoding that the processor supports.
0x3 = the processor supports Thumb encoding with all Thumb instructions.
Purpose Provides information about the execution state support and programmers
model for the processor.
31 12 11 8 7 4 3 0
Reserved
[31:12] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-20
ID092411 Non-Confidential
System Control
[11:8] Microcontroller programmers model Indicates support for Microcontroller programmers model:
0x0 = no support.
[3:0] ARMv4 programmers model Indicates support for standard ARMv4 programmers model:
0x1 = the processor supports the ARMv4 model.
Purpose Provides information about the debug system for the processor.
31 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved
[31:24] - SBZ.
[23:20] Microcontroller Debug Indicates support for the microcontroller debug model - memory mapped:
model - memory mapped 0x0 = no support.
[19:16] Trace debug model - Indicates support for the trace debug model - memory mapped:
memory mapped 0x1 = trace supported, memory mapped access.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-21
ID092411 Non-Confidential
System Control
[15:12] Trace debug model - Indicates support for the trace debug model - coprocessor:
coprocessor 0x0 = no support.
[11:8] Core debug model - Indicates the type of embedded processor debug model that the processor supports:
memory mapped 0x4 = ARMv7 based model - memory mapped.
[7:4] Secure debug model Indicates the type of secure debug model that the processor supports:
0x0 = no support.
[3:0] Core debug model - Indicates the type of applications processor debug model that the processor supports:
coprocessor 0x0 = no support.
There are four Memory Model Feature Registers, MMFR0 to MMFR3. They are described in
the following subsections:
• c0, Memory Model Feature Register 0
• c0, Memory Model Feature Register 1 on page 4-23
• c0, Memory Model Feature Register 2 on page 4-24
• c0, Memory Model Feature Register 3, MMFR3 on page 4-26.
Purpose The ID_MMFR0 provides information about the memory model, memory
management, and cache support operations of the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-22
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Innermost Auxiliary TCM Shareability Outermost
FCSE PMSA VMSA
shareability Registers support levels shareability
[27:24] FCSE Indicates support for Fast Context Switch Extension (FCSE).
0x0 = no support.
[19:16] TCM support Indicates support for TCM and associated DMA.
0x1 = implementation defined.
[7:4] PMSA Indicates support for Physical Memory System Architecture (PMSA).
0x3 = the processor supports PMSAv7 (subsection support).
[3:0] VMSA Indicates support for Virtual Memory System Architecture (VMSA).
0x0 = no support.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-23
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Branch predictor
L1 test clean operations
L1 cache maintenance operations (unified)
L1 cache maintenance operations (Harvard)
L1 cache line maintenance operations - Set and Way (unified)
L1 cache line maintenance operations - Set and Way (Harvard)
L1 cache line maintenance operations - MVA (unified)
L1 cache line maintenance operations - MVA (Harvard)
[27:24] L1 test clean operations Indicates support for test and clean operations on data cache, Harvard or unified architecture.
0x0 = no support.
[23:20] L1 cache maintenance Indicates support for L1 cache, entire cache maintenance operations, unified architecture.
operations (unified) 0x0 = no support.
[19:16] L1 cache maintenance Indicates support for L1 cache, entire cache maintenance operations, Harvard architecture.
operations (Harvard) 0x0 = no support.
[15:12] L1 cache line maintenance Indicates support for L1 cache line maintenance operations by Set and Way, unified
operations - Set and Way architecture.
(unified) 0x0 = no support.
[11:8] L1 cache line maintenance Indicates support for L1 cache line maintenance operations by Set and Way, Harvard
operations - Set and Way architecture.
(Harvard) 0x0 = no support.
[7:4] L1 cache line maintenance Indicates support for L1 cache line maintenance operations by address, unified architecture.
operations - MVA (unified) 0x0 = no support.
[3:0] L1 cache line maintenance Indicates support for L1 cache line maintenance operations by address, Harvard architecture.
operations - MVA 0x0 = no support.
(Harvard)
Purpose The ID_MMFR2 provides information about the memory model, memory
management, and cache support operations of the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-24
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Hardware Memory
WFI
access flag barrier
[31:28] Hardware access flag Indicates support for Hardware Access Flag.
0x0 = no support.
[19:16] TLB maintenance Indicates support for TLB maintenance operations, unified architecture.
operations (unified) 0x0 = no support.
[15:12] TLB maintenance Indicates support for TLB maintenance operations, Harvard architecture.
operations (Harvard) 0x0 = no support.
[11:8] L1 cache maintenance Indicates support for cache maintenance range operations, Harvard architecture.
range operations (Harvard) 0x0 = no support.
[7:4] L1 background prefetch Indicates support for background prefetch cache range operations, Harvard architecture.
cache operations 0x0 = no support.
[3:0] L1 foreground prefetch Indicates support for foreground prefetch cache range operations, Harvard architecture.
cache operations 0x0 = no support.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-25
ID092411 Non-Confidential
System Control
Purpose Provides information about the two cache line maintenance operations for
the processor.
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved Reserved
Supersection support
Coherent walk
Maintenance broadcast
Branch predictor maintenance operations
Hierarchical cache maintenance operations by Set and Way
Hierarchical cache maintenance operations by MVA
[27:24] - SBZ
[19:16] - SBZ
[15:12] Maintenance broadcast Indicates whether cache maintenance operations are broadcast.
0x0 = cache maintenance operations only affect local structures.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-26
ID092411 Non-Confidential
System Control
[11:8] Branch predictor maintenance Indicates support for branch predictor maintenance operations in systems with
operations hierarchical cache maintenance operations.
0x2 = supports invalidate entire branch predictor array and invalidate branch predictor
by MVAa.
[7:4] Hierarchical cache maintenance Indicates support for hierarchical cache maintenance operations by Set and Way.
operations by Set and Way 0x1 = the processor supports invalidate cache, clean and invalidate, and clean by Set and
Way.
[3:0] Hierarchical cache maintenance Indicates support for hierarchical cache maintenance operations by address.
operations by MVA 0x1 = the processor supports:
• Invalidate data cache by address
• Clean data cache by address
• Clean and invalidate data cache by address
• Invalidate instruction cache by address
• Invalidate all instruction cache entries.
a. Both of these operations are NOP on Cortex-R5.
There are eight Instruction Set Attributes Registers, ID_ISAR0 to ID_ISAR7, but three of these
are unused. This section describes:
• c0, Instruction Set Attributes Register 0
• c0, Instruction Set Attributes Register 1 on page 4-28
• c0, Instruction Set Attributes Register 2 on page 4-30
• c0, Instruction Set Attributes Register 3 on page 4-31
• c0, Instruction Set Attributes Register 4 on page 4-33
• c0, Instruction Set Attributes Register 5 on page 4-34.
• c0, Instruction Set Attributes Registers 6-7 on page 4-34.
Purpose Provides information about the instruction set that the processor supports,
beyond the basic set.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-27
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved
Divide instructions
Debug instructions
Coprocessor instructions
Compare and branch instructions
Bitfield instructions
Bit count instructions
Atomic instructions
[31:28] - SBZ
[19:16] Coprocessor instructions Indicates support for coprocessor instructions other than separately attributed feature registers,
such as CP15 registers and VFP.
0x0 = no support.
[15:12] Compare and branch Indicates support for combined compare and branch instructions.
instructions 0x1 = the processor supports combined compare and branch instructions, CBNZ and CBZ.
[7:4] Bit counting instructions Indicates support for bit counting instructions.
0x1 = the processor supports CLZ.
[3:0] Atomic instructions Indicates support for atomic load and store instructions.
0x1 = the processor supports SWP and SWPB.
Purpose Provides information about the instruction set that the processor supports
beyond the basic set.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-28
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Jazelle instructions
Interworking instructions
Immediate instructions
ITE instructions
Extend instructions
Exception 2 instructions
Exception 1 instructions
Endian instructions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-29
ID092411 Non-Confidential
System Control
Purpose The ID_ISAR2 provides information about the instruction set that the
processor supports beyond the basic set.
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reversal instructions
PSR instructions
Unsigned multiply instructions
Signed multiply instructions
Multiply instructions
Interruptible instructions
Memory hint instructions
Load/store instructions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-30
ID092411 Non-Confidential
System Control
[3:0] Load/store Indicates support for additional load and store instructions.
instructions 0x1 = the processor supports LDRD and STRD.
Purpose Provides information about the instruction set that the processor supports
beyond the basic set.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-31
ID092411 Non-Confidential
System Control
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
ThumbEE extension
True NOP instructions
Thumb copy instructions
Table branch instructions
Synchronization primitive instructions
SVC instructions
SIMD instructions
Saturate instructions
[11:8] SVC instructions Indicates support for SVC (formerly SWI) instructions.
0x1 = the processor supports SVC.
[7:4] SIMD Indicates support for Single Instruction Multiple Data (SIMD) instructions.
instructions 0x3 = the processor supports:
PKHBT, PKHTB, QADD16, QADD8, QASX, QSUB16, QSUB8, QSAX, SADD16, SADD8, SASX, SEL, SHADD16, SHADD8, SHASX,
SHSUB16, SHSUB8, SHSAX, SSAT, SSAT16, SSUB16, SSUB8, SSAX, SXTAB16, SXTB16, UADD16, UADD8, UASX, UHADD16,
UHADD8, UASX, UHSUB16, UHSUB8, USAX, UQADD16, UQADD8, UQASX, UQSUB16, UQSUB8, UQSAX, USAD8, USADA8, USAT,
USAT16, USUB16, USUB8, USAX, UXTAB16, UXTB16, and the GE[3:0] bits in the PSRs.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-32
ID092411 Non-Confidential
System Control
Purpose Provides information about the instruction set that the processor supports
beyond the basic set.
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
SWP_frac
Unprivileged instructions
PSR_M_instrs With shift instructions
Exclusive instructions Write-back instructions
Barrier instructions SMC instructions
[27:24] PSR_M_instrs Indicates support for M-profile instructions for modifying the PSRs.
0x0 = no support.
[15:12] SMC instructions Indicates support for Secure Monitor Call (SMC) (formerly SMI) instructions.
0x0 = no support.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-33
ID092411 Non-Confidential
System Control
ID_ISAR6 and ID_ISAR7 are not implemented, and their positions in the register map are
Reserved. They correspond to CP15 accesses with:
MRC p15, 0, <Rd>, c0, c2, 6 ; Read ID_ISAR6
MRC p15, 0, <Rd>, c0, c2, 7 ; Read ID_ISAR7
These registers are read-only, and are accessible in Privileged mode only.
Purpose Provides information about the size and behavior of the instruction or data
cache. Architecturally, there can be up to eight levels of cache, containing
instruction, data, or unified caches. This processor contains L1 instruction
and data caches only. The CSSELR determines which CCSIDR to select,
see c0, Cache Size Selection Register on page 4-37.
31 30 29 28 27 13 12 2 0
W W R W Line
NumSets Associativity
T B A A Size
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-34
ID092411 Non-Confidential
System Control
The LineSize field is encoded as 2 less than log(2) of the number of words in the cache line. For
example, a value of 0x0 indicates there are four words in a cache line, that is the minimum size
for the cache. A value of 0x1 indicates there are eight words in a cache line.
Table 4-21 shows the individual bit field and complete register encodings for the CCSIDR. Use
this to match the cache size and level of cache set by the Current Cache Size Selection Register
(CSSR). See c0, Cache Size Selection Register on page 4-37.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-35
ID092411 Non-Confidential
System Control
31 30 29 27 26 24 23 21 20 18 17 15 14 12 11 10 8 6 5 3 2 0
Reserved
[31:30] - SBZ
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-36
ID092411 Non-Confidential
System Control
Purpose Holds the value that the processor uses to select the CSSELR to use.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-37
ID092411 Non-Confidential
System Control
31 4 3 1 0
Reserved Level
InD
[31: 4] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-38
ID092411 Non-Confidential
System Control
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 7 6 3 2 1 0
IE SW
TE RR
AFE SBZ
TRE SBO
NMFI BR
SBZ SBO
EE DZ
VE SBZ
FI
[29] AFE Access Flag Enable. On the processor this bit is SBZ.
[28] TRE TEX Remap Enable. On the processor this bit is SBZ.
[26] - SBZ.
[23:22] - SBO.
[20] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-39
ID092411 Non-Confidential
System Control
[18] - SBO.
[16] - SBO.
[15] - SBZ.
[14] RR Round-robin bit, controls replacement strategy for instruction and data caches:
0 = random replacement strategy
1 = round-robin replacement strategy.
The reset value of this bit is 0. The processor always uses a random replacement strategy, regardless of the state
of this bit.
[9:7] - SBZ.
[6:3] - SBO.
[1] A Enables strict alignment of data to detect alignment faults in data accesses:
0 = strict alignment fault checking disabled. This is the reset value.
1 = strict alignment fault checking enabled.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-40
ID092411 Non-Confidential
System Control
To use the SCTLR, ARM recommends that you use a read-modify-write technique. To access
the SCTLR, read or write CP15 with:
MRC p15, 0, <Rd>, c1, c0, 0 ; Read SCTLR
MCR p15, 0, <Rd>, c1, c0, 0 ; Write SCTLR
Attempts to read or write the SCTLR from User mode results in an Undefined Instruction
exception.
Purpose Controls:
• branch prediction
• performance features
• error and parity logic.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 3 2 1 0
BP CEC
DICDI ATCMECEN
DIB2DI B0TCMECEN
DIB1DI B1TCMECEN
DIADI DILS
B1TCMPCEN sMOV
B0TCMPCEN FDSnS
ATCMPCEN FWT
AXISCEN FORA
AXISCUEN DNCH
DILSM ERPEG
DEOLP DLFO
DBHE DBWR
FRCDIS RSDIS
Reserved
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-41
ID092411 Non-Confidential
System Control
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-42
ID092411 Non-Confidential
System Control
[18] - SBZ.
[11] DNCH Disable data forwarding for Non-cacheable accesses in the AXI master:
0 = Normal operation. This is the reset value.
1 = Disable data forwarding for Non-cacheable accesses.
[10] FORA Force outer read allocate (ORA) for outer write allocate (OWA) regions:
0 = No forcing of ORA. This is the reset value.
1 = ORA forced for OWA regions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-43
ID092411 Non-Confidential
System Control
[7] sMOV sMOV of a divide does not complete out of order. No other instruction is issued until the divide is finished.
0 = Normal operation. This is the reset value.
1 = sMOV out of order disabled.
[5:3] CEC Cache error control for cache parity and ECC errors.
See Table 8-2 on page 8-21 and Table 8-3 on page 8-22 for more information about how these bits are
used. The reset value is b100.
Purpose Controls:
• branch prediction
• performance features
• error and parity logic.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-44
ID092411 Non-Confidential
System Control
Figure 4-29 shows the Secondary Auxiliary Control Register bit assignments.
31 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 4 3 2 1 0
Reserved
DCHE ATCMRMW
DR2B BTCMRMW
ATCMECC
DF6DI
B0TCMECC
DF2DI
DDI Reserved
DOODPFP IDC
DOOFMACS DZC
Reserved IOC
IXC UFC
OFC
Table 4-26 shows the Secondary Auxiliary Control Register bit assignments.
[31:23] - SBZ.
[21] DR2Bb Enable random 2-bit error generation in cache RAMs. This bit has no effect unless ECC is configured, see
Configurable options on page 1-6.
0 = Disabled. This is the reset value.
1 = Enabled.
Note
This bit controls error generation logic during system validation. A synthesized ASIC typically does not
have such models and this bit is therefore redundant for ASICs.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-45
ID092411 Non-Confidential
System Control
[15:14] - SBZ.
[7:4] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-46
ID092411 Non-Confidential
System Control
[1] BTCMRMW Enables 64-bit stores for the BTCMs. When enabled, the processor uses read-modify-write to ensure that
all reads and writes presented on the BTCM ports are 64 bits wide.e
0 = Disabled
1 = Enabled.
The primary input RMWENRAMm[1] defines the reset value.
[0] ATCMRMW Enables 64-bit stores for the ATCM. When enabled, the processor uses read-modify-write to ensure that all
reads and writes presented on the ATCM port are 64 bits wide.e
0 = Disabled
1 = Enabled.
The primary input RMWENRAMm[0] defines the reset value.
a. This bit is RAZ if both caches have neither ECC nor parity.
b. This bit is only supported if parity error generation is implemented in your design.
c. This bit has no effect unless the Floating Point Unit (FPU) has been configured, see Configurable options on page 1-6.
d. This bit has no effect unless TCM ECC logic has been configured for the respective TCM interface, see Configurable options on page 1-6.
e. This feature is not available when the TCM interface has been built with 32-bit ECC.
To access the Secondary Auxiliary Control Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c0, 0 ; Read Secondary Auxiliary Control Register
MCR p15, 0, <Rd>, c15, c0, 0 ; Write Secondary Auxiliary Control Register
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-47
ID092411 Non-Confidential
System Control
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cp13 cp12 cp11 cp10 cp9 cp8 cp7 cp6 cp5 cp4 cp3 cp2 cp1 cp0
Reserved
D32DIS
ASEDIS
[25:24] cp12
[17:16] cp8
[15:14] cp7
[13:12] cp6
[11:10] cp5
[9:8] cp4
[7:6] cp3
[5:4] cp2
[3:2] cp1
[1:0] cp0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-48
ID092411 Non-Confidential
System Control
The processor reports the status and address of faults that occur during its operation. For both
data and instruction faults there are two Fault Status Registers (FSRs) and one Fault Address
Register (FAR).
Fields within the Data and Instruction FSRs indicate the priority and source of a fault and the
validity of the address in the corresponding FAR. Table 4-28 shows this encoding for the FSRs.
Purpose Holds status information regarding the source of the last data abort.
31 13 12 11 10 9 8 7 4 3 0
RW
SD
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-49
ID092411 Non-Confidential
System Control
[31:13] - SBZ.
[12] SD Distinguishes between an AXI Decode or Slave error on an external abort. This bit is only valid for external
aborts. For all other aborts types of abort, this bit is set to zero:
0 = AXI Decode error (DECERR), or AHB error, caused the abort
1 = AXI Slave error (SLVERR), or unsupported exclusive access, for example exclusive access using the AHB
peripheral port, caused the abort.
[7:4] Domain SBZ. This is because domains are not implemented in this processor.
[3:0]a Status Indicates the type of fault generated. To determine the data fault, you must use bit [12] and bit [10] in
conjunction with bits [3:0].
a. For more information on how these bits are used in reporting faults, see Table 4-28 on page 4-49.
Purpose Holds status information regarding the source of the last instruction abort.
31 13 12 11 10 9 8 7 4 3 0
Reserved
Reserved
SD
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-50
ID092411 Non-Confidential
System Control
[31:13] - SBZ.
[12] SD Distinguishes between an AXI Decode or Slave error on an external abort. This bit is only valid for external
aborts. For all other aborts types of abort, this bit is set to zero:
0 = AXI Decode error (DECERR) caused the abort
1 = AXI Slave error (SLVERR) caused the abort.
[11] - SBZ.
[9:8] - SBZ.
[7:4] Domain SBZ. This is because domains are not implemented in this processor.
[3:0]a Status Indicates the type of fault generated. To determine the instruction fault, bit [12] and bit [10] must be used in
conjunction with bits [3:0].
a. For more information on how these bits are used in reporting faults, see Table 4-28 on page 4-49.
Purpose Provide additional information about data and instruction parity, ECC, and
external TCM errors.
Figure 4-33 on page 4-52 shows the auxiliary fault status registers bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-51
ID092411 Non-Confidential
System Control
31 28 27 24 23 22 21 20 19 14 13 5 4 0
CacheWay SideExt
Side Recoverable error
Table 4-31 shows the auxiliary fault status registers bit assignments.
[31:28] - SBZ.
[27:24] CacheWaya The value returned in this field indicates the cache way or ways in which the error occurred.
[23:22] Side The value returned in this field indicates the source of the error. See Table 4-32 for the encodings.
[21] Recoverable The value returned in this field indicates if the error is recoverable.
error 0 = Unrecoverable error.
1 = Recoverable error. This includes all correctable parity/ECC errors and recoverable TCM external errors.
[20] SideExt The value returned in this field indicates the source of the error. See Table 4-32 for the encodings.
[19:14] - SBZ.
[13:5] Indexb This field returns the index value for the access giving the error.
[4:0] - SBZ.
a. This field is only valid for data cache store parity/ECC errors, otherwise it is Unpredictable.
b. This field is only valid for data cache store parity/ECC errors. On the AIFSR, and for TCM accesses, this field SBZ.
Table 4-32 shows the encodings for the SideExt and Side bits.
Bit values
Meaning
SideExt Side
0 00 Cache/AXIM
0 01 ATCM
0 10 BTCM
0 11 Reserved
1 00
1 11 Reserved
To access the auxiliary fault status registers, read or write CP15 with:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-52
ID092411 Non-Confidential
System Control
MRC p15, 0, <Rd>, c5, c1, 0 ; Read Auxiliary Data Fault Status Register
MCR p15, 0, <Rd>, c5, c1, 0 ; Write Auxiliary Data Fault Status Register
MRC p15, 0, <Rd>, c5, c1, 1 ; Read Auxiliary Instruction Fault Status Register
MCR p15, 0, <Rd>, c5, c1, 1 ; Write Auxiliary Instruction Fault Status Register
Purpose Holds the address of the fault when a synchronous abort occurs.
Attributes The DFAR bits [31:0] contain the address where the synchronous abort
occurred.
A write to this register sets the DFAR to the value of the data written. This is useful for a
debugger to restore the value of the DFAR.
The processor also updates the DFAR on debug exception entry because of watchpoints. See
Effect of debug exceptions on CP15 registers and DBGWFAR on page 12-43 for more
information.
Purpose Holds the address of the instruction that caused a prefetch abort.
Attributes The IFAR bits [31:0] contain the Instruction Fault address.
A write to this register sets the IFAR to the value of the data written. This is useful for a
debugger to restore the value of the IFAR.
The MPU memory region programming registers program the MPU regions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-53
ID092411 Non-Confidential
System Control
There is one register that specifies which one of the sets of region registers is to be accessed.
See c6, MPU Region Number Register on page 4-59. Each region has its own registers to
specify:
• region base address
• region size and enable
• region access control.
You can implement the processor with 12 or 16 regions, or without an MPU entirely. If you
implement the processor without an MPU, then there are no regions and no region programming
registers.
Note
• When the MPU is enabled:
— The MPU determines the access permissions for all accesses to memory, including
the TCMs. Therefore, you must ensure that the memory regions in the MPU are
programmed to cover the complete TCM address space with the appropriate access
permissions. You must define at least one of the regions in the MPU.
— An access to an undefined area of memory normally generates a background fault.
• For the TCM space the processor uses the access permissions but ignores the region
attributes from MPU.
CP15, c9 sets the location of the TCM base address. For more information see c9, BTCM
Region Register on page 4-63 and c9, ATCM Region Register on page 4-64.
Purpose Describes the base address of the region specified by the Memory Region
Number Register.
Figure 4-34 shows the MPU Region Base Address Registers bit assignments.
31 5 4 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-54
ID092411 Non-Confidential
System Control
Table 4-33 shows the MPU Region Base Address Registers bit assignments.
[31:5] Base address Defines bits [31:5] of the base address of a region
[4:0] - SBZ
To access an MPU Region Base Address Register, read or write CP15 with:
MRC p15, 0, <Rd>, c6, c1, 0 ; Read MPU Region Base Address Register
MCR p15, 0, <Rd>, c6, c1, 0 ; Write MPU Region Base Address Register
Purpose • Specifies the size of the region specified by the Memory Region
Number Register.
• Identifies the address ranges that are used for a particular region.
• Enables or disables the region, and its sub-regions, specified by the
Memory Region Number Register.
Usage constraints The MPU Region Size and Enable Registers are:
• 32-bit read/write registers
• accessible in Privileged mode only.
Figure 4-35 shows the MPU Region Size and Enable Registers bit assignments.
31 16 15 8 7 6 5 1 0
Reserved
Enable
Figure 4-35 MPU Region Size and Enable Registers bit assignments
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-55
ID092411 Non-Confidential
System Control
Table 4-34 shows the MPU Region Size and Enable Registers bit assignments.
[31:16] - SBZ.
- SBZ.
[5:1] Region size Defines the region size: b01100 = 8KB b10110 = 8MB
b00000 - b00011=Unpredictable b01101 = 16KB b10111 = 16MB
b00100 = 32 bytes b01110 = 32KB b11000 = 32MB
b00101 = 64 bytes b01111 = 64KB b11001 = 64MB
b00110 = 128 bytes b10000 = 128KB b11010 = 128MB
b00111 = 256 bytes b10001 = 256KB b11011 = 256MB
b01000 = 512 bytes b10010 = 512KB b11100 = 512MB
b01001 = 1KB b10011 = 1MB b11101 = 1GB
b01010 = 2KB b10100 = 2MB b11110 = 2GB
b01011 = 4KB b10101 = 4MB b11111 = 4GB.
To access an MPU Region Size and Enable Register, read or write CP15 with:
MRC p15, 0, <Rd>, c6, c1, 2 ; Read Data MPU Region Size and Enable Register
MCR p15, 0, <Rd>, c6, c1, 2 ; Write Data MPU Region Size and Enable Register
Writing a region size that is outside the range results in Unpredictable behavior.
Purpose Holds the region attributes and access permissions for the region specified
by the Memory Region Number Register.
Figure 4-36 on page 4-57 shows the MPU Region Access Control Registers bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-56
ID092411 Non-Confidential
System Control
31 13 12 11 10 8 7 6 5 3 2 1 0
Reserved XN AP TEX S C B
Reserved
Table 4-35 shows the MPU Region Access Control Registers bit assignments.
[31:13] - SBZ.
[11] - Reserved.
[10:8] AP Access permission. Defines the data access permissions. For more information on AP bit values,
see Table 4-38 on page 4-58.
[7:6] - SBZ.
[1] C C bita:
[0] B B bita:
Table 4-36 shows the encoding for the TEX[2:0], C, and B regions.
001 0 1 Reserved. - -
001 1 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-57
ID092411 Non-Confidential
System Control
010 0 1 Reserved. - -
010 1 X Reserved. - -
011 X X Reserved. - -
When TEX[2] == 1, the memory region is Cacheable memory, and the rest of the encoding
defines the Inner and Outer cache policies:
TEX[1:0] defines the Outer cache policy
C,B defines the Inner cache policy
The same encoding is used for the Outer and Inner cache policies. Table 4-37 shows the
encoding.
00 Non-cacheable
01 Write-back, write-allocate
10 Write-through, no write-allocate
11 Write-back, no write-allocatea
Table 4-38 shows the AP bit values that determine the permissions for Privileged and User data
access.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-58
ID092411 Non-Confidential
System Control
To access the MPU Region Access Control Registers read or write CP15 with:
MRC p15, 0, <Rd>, c6, c1, 4 ; Read MPU Region Access Control Register
MCR p15, 0, <Rd>, c6, c1, 4 ; Write MPU Region Access Control Register
Purpose Multiple registers with one register for each memory region implemented.
The value contained in the RGNR determines which of the multiple
registers is accessed.
31 4 3 0
Reserved Region
[31:4] - SBZ.
[3:0] Region Defines the group of registers to be accessed. Read the MPUIR to determine the number of
supported regions, see c0, MPU Type Register on page 4-17.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-59
ID092411 Non-Confidential
System Control
The purpose of c7 is to manage the associated caches. The maintenance operations are formed
into two management groups:
• Set and Way:
— clean
— invalidate
— clean and invalidate.
• Address, usually labelled MVA for Modified Virtual Address, but on this processor all
addresses are identical:
— clean
— invalidate
— clean and invalidate.
Figure 4-38 on page 4-61 shows the arrangement of the functions in this group that operate with
the MCR and MRC instructions.
Note
• The following operations, as Figure 4-38 on page 4-61 shows, are implemented as No
Operation, NOP, on the processor:
— Wait For Interrupt, CRm= c0, Opcode_2 = 4
— Invalidate all branch predictors Inner Shareable, CRm= c1, Opcode_2 = 6
— Invalidate Entire Branch Predictor Array, CRm= c5, Opcode_2 = 6
— Invalidate Branch Predictor Array Line using MVA, CRm= c5, Opcode_2 = 7
• The Wait For Interrupt (WFI) instruction provides the Wait For Interrupt function. For
more information see the ARM Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-60
ID092411 Non-Confidential
System Control
In addition to the register c7 cache management functions in this processor, an Invalidate all
data caches operation is provided as a c15 operation. For convenience, this c15 operation is also
described in this section.
Note
• Writing c7 with a combination of CRm and Opcode_2 not listed in Figure 4-38 results in
an Undefined Instruction exception.
• All accesses to c7 can only be executed in a Privileged mode of operation, except for the
Instruction Synchronization Barrier, Data Synchronization Barrier, and Data Memory
Barrier operations. These can be performed in User mode. Attempting to execute a
Privileged instruction in User mode results in an Undefined Instruction exception.
The terms that describe the invalidate, clean, and prefetch operations are defined in the ARM
Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-61
ID092411 Non-Confidential
System Control
31 30 29 S+5 S+4 5 4 0
[29:S+5] - SBZ.
[S+4:5] Set Indicates the cache set to invalidate or clean. Because the cache sizes are configurable, the width
of the Set field is unique to the cache size. See Table 4-41.
[4:0] - SBZ.
Table 4-41 shows the cache sizes and the resultant bit range for Set.
Size Set
4KB [9:5]
8KB [10:5]
16KB [11:5]
32KB [12:5]
64KB [13:5]
See c0, Cache Type Register on page 4-15 for more information on cache sizes.
Address format
Figure 4-40 shows the invalidate and clean operations bit assignments.
31 5 4 0
Address Reserved
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-62
ID092411 Non-Confidential
System Control
Table 4-42 shows the invalidate and clean operations bit assignments.
The purpose of the Data Synchronization Barrier operation is to ensure that all outstanding
explicit memory transactions complete before any following instructions begin. This ensures
that data in memory is up to date before the processor executes any more instructions.
For more information about memory barriers, see the ARM Architecture Reference Manual.
The purpose of the Data Memory Barrier operation is to ensure that all outstanding explicit
memory transactions complete before any following explicit memory transactions begin. This
ensures that data in memory is up to date before any memory transaction that depends on it.
For more information about memory barriers, see the ARM Architecture Reference Manual.
Figure 4-41 on page 4-64 shows the BTCM Region Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-63
ID092411 Non-Confidential
System Control
31 12 11 7 6 2 1 0
Reserved
Enable
[31:12] Base Base address. Defines the base address of the BTCM. The base address must be aligned to the size of the
address BTCM. Any bits in the range [(log2(RAMSize)-1):12] are ignored.
At reset, if LOCZRAMAm is set to:
0 =The initial base address is 0x0.
1 =The initial base address is implementation-defined. See Configurable options on page 1-6.
[6:2] Size Size. Indicates the size of the BTCM on reads. On writes this field is ignored. See About the TCMs on
page 8-13.
[1] - SBZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-64
ID092411 Non-Confidential
System Control
31 12 11 7 6 2 1 0
Reserved
Enable
[31:12] Base Base address. Defines the base address of the ATCM. The base address must be aligned to the size of the
address ATCM. Any bits in the range [(log2(RAMSize)-1):12] are ignored.
At reset, if LOCZRAMAm is set to:
0 = The initial base address is implementation-defined. See Configurable options on page 1-6
1 = The initial base address is 0x0.
[6:2] Size Size. Indicates the size of the ATCM on reads. On writes this field is ignored. See About the TCMs on
page 8-13.
[1] - SBZ.
The TCM Selection Register determines the TCM region register that the processor writes to.
The processor only supports one TCM region for each TCM interface, and the TCM Selection
Register Reads-As-Zero and ignores writes. It is only accessible in Privileged mode.
Purpose • Enables or disables TCM access to the AXI slave port in Privileged
or User mode.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-65
ID092411 Non-Confidential
System Control
• Enables access to the cache RAMs through the AXI slave port. See
c1, Auxiliary Control Register on page 4-41.
Figure 4-43 shows the Slave Port Control Register bit assignments.
31 2 1 0
Reserved
Privileged access
Table 4-45 shows the Slave Port Control Register bit assignments
[31:2] - RAZ/UNP.
[0] AXI slave enable Enables or disables the AXI slave port for TCM accesses:
0 = Enables AXI slave port, reset value
1 = Disables AXI slave port.
To access the Slave Port Control Register, read or write CP15 with:
MRC p15, 0, <Rd>, c11, c0, 0 ; Read Slave Port Control Register
MCR p15, 0, <Rd>, c11, c0, 0 ; Write Slave Port Control Register
This processor does not support Fast Context Switch Extension (FCSE).
The FCSE Process IDentifier (PID) Register is accessible in Privileged mode only. This register
reads as zero and ignores writes.
Purpose • Holds a process IDentification (ID) value for the running process.
• The Embedded Trace Macrocell (ETM) and the debug logic use this
register. The ETM can broadcast its value to indicate the process that
is running. You must program each process with a unique number.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-66
ID092411 Non-Confidential
System Control
The Thread and Process ID Registers provide locations to store the IDs of software threads and
processes for Operating System (OS) management purposes.
To access the Thread and Process ID registers, read or write CP15 with:
MRC p15, 0, <Rd>, c13, c0, 2 ; Read User read/write Thread and Proc. ID Register
MCR p15, 0, <Rd>, c13, c0, 2 ; Write User read/write Thread and Proc. ID Register
MRC p15, 0, <Rd>, c13, c0, 3 ; Read User Read Only Thread and Proc. ID Register
MCR p15, 0, <Rd>, c13, c0, 3 ; Write User Read Only Thread and Proc. ID Register
MRC p15, 0, <Rd>, c13, c0, 4 ; Read Privileged Only Thread and Proc. ID Register
MCR p15, 0, <Rd>, c13, c0, 4 ; Write Privileged Only Thread and Proc. ID Register
Reading or writing the Thread and Process ID registers has no effect on processor state or
operation. These registers provide OS support, and the OS must manage them.
You must clear the contents of all Thread and Process ID registers on process switches to
prevent data leaking from one process to another. This is important to ensure the security of data.
The reset value of these registers is 0.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-67
ID092411 Non-Confidential
System Control
Figure 4-44 shows the nVAL IRQ Enable Set Register bit assignments.
31 3 2 1 0
C Reserved
Table 4-46 shows the nVAL IRQ Enable Set Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-68
ID092411 Non-Confidential
System Control
Table 4-46 nVAL IRQ Enable Set Register bit assignments (continued)
To access the nVAL IRQ Enable Set Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 0 ; Read nVAL IRQ Enable Set Register
MCR p15, 0, <Rd>, c15, c1, 0 ; Write nVAL IRQ Enable Set Register
On reads, this register returns the current setting. On writes, interrupt requests can be enabled
by writing a 1 to the appropriate bits. If an interrupt request has been enabled it is disabled by
writing to the nVAL IRQ Enable Clear Register, see c15, VAL IRQ Enable Clear Register on
page 4-72.
If one or more of the IRQ request fields (P2, P1, P0, and C) is enabled, and the corresponding
counter overflows, then an IRQ request is indicated by nVALIRQm being asserted LOW. This
signal might be passed to a system interrupt controller.
Figure 4-45 shows the nVAL FIQ Enable Set Register bit assignments.
31 3 2 1 0
C Reserved
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-69
ID092411 Non-Confidential
System Control
Table 4-47 shows the nVAL FIQ Enable Set Register bit assignments
To access the FIQ Enable Set Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 1 ; Read FIQ Enable Set Register
MCR p15, 0, <Rd>, c15, c1, 1 ; Write FIQ Enable Set Register
On reads, this register returns the current setting. On writes, interrupt requests can be enabled
by writing a 1 to the appropriate bits. If an interrupt request has been enabled it is disabled by
writing to the FIQ Enable Clear Register, see c15, nVAL FIQ Enable Clear Register on
page 4-73.
If one or more of the FIQ request fields (P2, P1, P0, and C) is enabled, and the corresponding
counter overflows, then an FIQ request is indicated by nVALFIQm being asserted LOW. This
signal can be passed to a system interrupt controller.
• A read/write register.
Figure 4-46 on page 4-71 shows the nVAL Reset Enable Set Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-70
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
Table 4-48 shows the nVAL Reset Enable Set Register bit assignments.
To access the nVAL Reset Enable Set Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 2 ; Read nVAL Reset Enable Set Register
MCR p15, 0, <Rd>, c15, c1, 2 ; Write nVAL Reset Enable Set Register
On reads, this register returns the current setting. On writes, reset requests can be enabled by
writing a 1 to the appropriate bits. If a reset request has been enabled, it is disabled by writing
to the nVAL Reset Enable Clear Register. See c15, nVAL Reset Enable Clear Register on
page 4-74.
If one or more of the reset request fields (P2, P1, P0, and C) is enabled, and the corresponding
counter overflows, then a reset request is indicated by nVALRESETm being asserted LOW.
This signal can be passed to a system reset controller.
Usage constraints The VAL Debug Request Enable Set Register is:
• A read/write register.
• Always accessible in Privileged mode. The PMUSERENR Register
determines access in User mode, see c9, User Enable Register on
page 6-16.
Figure 4-47 on page 4-72 shows the VAL Debug Request Enable Set Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-71
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
Figure 4-47 VAL Debug Request Enable Set Register bit assignments
Table 4-49 shows the VAL Debug Request Enable Set Register bit assignments.
Table 4-49 VAL Debug Request Enable Set Register bit assignments
To access the VAL Debug Request Enable Set Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 3 ; Read VAL Debug Request Enable Set Register
MCR p15, 0, <Rd>, c15, c1, 3 ; Write VAL Debug Request Enable Set Register
On reads, this register returns the current setting. On writes, debug requests can be enabled by
writing a 1 to the appropriate bits. If a debug request has been enabled, it is disabled by writing
to the VAL Debug Request Enable Clear Register. See c15, VAL Debug Request Enable Clear
Register on page 4-75.
If one or more of the reset request fields (P2, P1, P0, and C) is enabled, and the corresponding
counter overflows, then a debug reset request is indicated by VALEDBGRQm being asserted
HIGH. This signal can be passed to an external debugger.
Purpose Disables overflow IRQ requests from any of the PMXEVCNTR Registers,
PMXEVCNTR0-PMXEVCNTR2, and CCNT, for which they have been
enabled.
Figure 4-48 on page 4-73 shows the VAL IRQ Enable Clear Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-72
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
P2
Cycle count overflow Performance monitor counter
P1
IRQ request disable overflow IRQ request disables
P0
Table 4-50 shows the VAL IRQ Enable Clear Register bit assignments.
To access the VAL IRQ Enable Clear Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 4 ; Read VAL IRQ Enable Clear Register
MCR p15, 0, <Rd>, c15, c1, 4 ; Write VAL IRQ Enable Clear Register
On reads, this register returns the current setting. On writes, overflow interrupt requests that are
enabled can be disabled by writing a 1 to the appropriate bits.
For more information of how to enable IRQ requests on counter overflows, and how the requests
are signaled, see c15, nVAL IRQ Enable Set Register on page 4-68.
Purpose Disables overflow FIQ requests from any of the PMXEVCNTR Registers,
PMXEVCNTR0-PMXEVCNTR2, and CCNT, that are enabled.
Figure 4-49 on page 4-74 shows the nVAL FIQ Enable Clear Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-73
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
P2
Cycle count overflow Performance monitor counter
P1
FIQ request disable overflow FIQ request disables
P0
Table 4-51 shows the nVAL FIQ Enable Clear Register bit assignments
To access the FIQ Enable Clear Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 5 ; Read FIQ Enable Clear Register
MCR p15, 0, <Rd>, c15, c1, 5 ; Write FIQ Enable Clear Register
On reads, this register returns the current setting. On writes, overflow interrupt requests that are
enabled can be disabled by writing a 1 to the appropriate bits.
For information on how to enable FIQ requests on counter overflows, and how the requests are
signaled, see c15, nVAL FIQ Enable Set Register on page 4-69.
Figure 4-50 on page 4-75 shows the nVAL Reset Enable Clear Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-74
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
P2
Cycle count overflow Performance monitor counter overflow
P1
reset request disable reset request disables
P0
Table 4-52 shows the nVAL Reset Enable Clear Register bit assignments.
To access the nVAL Reset Enable Clear Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 6 ; Read nVAL Reset Enable Clear Register
MCR p15, 0, <Rd>, c15, c1, 6 ; Write nVAL Reset Enable Clear Register
On reads, this register returns the current setting. On writes, overflow reset requests that are
enabled can be disabled by writing a 1 to the appropriate bits.
For more information of how to enable reset requests on counter overflows, and how the
requests are signaled, see c15, nVAL Reset Enable Set Register on page 4-70.
Usage constraints The VAL Debug Request Enable Clear Register is:
• A read/write register.
• Always accessible in Privileged mode. The PMUSERENR Register
determines access in User mode, see c9, User Enable Register on
page 6-16.
Figure 4-51 on page 4-76 shows the VAL Debug Request Enable Clear Register bit
assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-75
ID092411 Non-Confidential
System Control
31 3 2 1 0
C Reserved
P2
Cycle count overflow Performance monitor counter overflow
P1
debug request disable debug request disables
P0
Figure 4-51 VAL Debug Request Enable Clear Register bit assignments
Table 4-53 shows the VAL Debug Request Enable Clear Register bit assignments.
Table 4-53 VAL Debug Request Enable Clear Register bit assignments
To access the VAL Debug Request Enable Clear Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c1, 7 ; Read VAL Debug Request Enable Clear Register
MCR p15, 0, <Rd>, c15, c1, 7 ; Write VAL Debug Request Enable Clear Register
On reads, this register returns the current setting. On writes, overflow debug requests that are
enabled can be disabled by writing a 1 to the appropriate bits.
For more information of how to enable debug requests on counter overflows, and how the
requests are signaled, see c15, VAL Debug Request Enable Set Register on page 4-71.
Purpose Overwrites the caches size fields in the main register. This enables you to
choose a smaller instruction and data cache size than is implemented.
Figure 4-52 shows the Cache Size Override Register bit assignments.
31 16 15 8 7 4 3 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-76
ID092411 Non-Confidential
System Control
Table 4-54 shows the Cache Size Override Register bit assignments.
[31:8] - SBZ.
[7:4] Dcache Defines the data cache size. See Table 4-55.
[3:0] Icache Defines the instruction cache size. See Table 4-55.
Table 4-55 shows the encodings for the instruction and data cache sizes.
b0000 4kB
b0001 8kB
b0011 16kB
b0111 32kB
b1111 64kB
Note
The VAL Cache Size Override Register can only be used to select cache sizes for which the
appropriate RAM has been integrated. Larger cache sizes require deeper data and tag RAMs,
and smaller cache sizes require wider tag RAMs. Therefore, it is unlikely that you can change
the cache size using this register except using a simulation model of the cache RAMs. ARM
recommends that you read the CCSIDR to check the actual cache sizes after writing to the Cache
Size Override Register.
Purpose Indicates the location of the last correctable error that occurred during
cache or TCM operations.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-77
ID092411 Non-Confidential
System Control
Every correctable error that causes a CFLR update also has an associated event. See Table 6-1
on page 6-2 for the events that are related to CFLR updates. If two correctable errors occur
simultaneously, for example an AXI slave error and an LSU or PFU error, the LSU or PFU write
takes priority. If multiple errors occur, the value in the CFLR reflects the location of the latest
event.
The same register is updated by all correctable errors. You can read bits [25:24] to determine
whether the error was from a cache or TCM access.
Figure 4-53 shows the CFLR bit assignments, when it indicates a correctable cache error.
31 30 29 26 25 24 23 14 13 5 4 2 1 0
Reserved Reserved
Table 4-56 shows the CFLR bit assignments, when it indicates a correctable cache error.,
[31:30] - RAZ.
[25:24] Side Indicates the source of the error. For cache errors, this value is always 0b00.
[23:14] - RAZ.
[13:5] Index Indicates the index of the location where the error occurred.
[4:2] - RAZ.
[1:0] Type Indicates the type of access that caused the error:
0b00 = Instruction cache
0b01 = Data cache
0b11 = ACP.
Figure 4-54 on page 4-79 shows the CFLR bit assignments, when it indicates a correctable TCM
error.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-78
ID092411 Non-Confidential
System Control
31 26 25 24 23 22 3 2 1 0
Reserved Reserved
Table 4-57 shows the CFLR bit assignments, when it indicates a correctable TCM error.
[31:26] - RAZ.
[23] - RAZ.
[22:3] Address Indicates the address in the TCM where the error occurred.
[2] - RAZ.
[1:0] Type Indicates the type of access that caused the error:
0b00 = Instruction
0b01 = Data
0b10 = AXI slave.
To access the Correctable Fault Location Register, read or write CP15 with:
MRC p15, 0, <Rd>, c15, c3, 0 ; Read CFLR
MCR p15, 0, <Rd>, c15, c3, 0 ; Write CFLR
Note
In a twin-CPU system, some options can be configured independently for each CPU. For these
options, the Options Register reflects the options for the CPU containing the register. Other
options are shared, and the options register contains the same value for both CPUs.
Purpose Reflects the build configuration options used to build the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-79
ID092411 Non-Confidential
System Control
31 11 10 2 1 0
TCM_HI_INIT_ADDR Reserved
FLOAT_PRECISION
PP_BUS_ECC
[11:2] - SBZ.
[0] PP_BUS_ECC Indicates whether the peripheral ports were built with bus-ECC:
0 = bus-ECC not included on peripheral ports
1 = bus-ECC included on peripheral ports.
Purpose Reflects the build configuration options used to build the processor.
Table 4-59 on page 4-81 shows the bit arrangement for the Build Options 2 Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-80
ID092411 Non-Confidential
System Control
31 30 29 28 27 26 25 24 23 22 21 20 19 17 16 14 13 12 11 10 9 8 7 6 5 4 3 2 0
NUM_CPU
LOCK_STEP
NO_ICACHE
NO_DCACHE
ATCM_ES
BTCM_ES
NO_IE
NO_FPU
MPU_REGIONS
BREAK_POINTS
WATCH_POINTS
NO_A_TCM_INF
NO_B0_TCM_INF
NO_B1_TCM_INF
TCMBUSPARITY
NO_AXIS
ICACHE_ES
DCACHE_ES
N0_HARD_ERROR_CACHE
AXI_BUS_ECC
SL
AHB_PP
MICRO_SCU
Table 4-59 shows how the bit values correspond with the Build Options 2 Register.
[30] LOCK_STEP Indicates whether the CPU has redundant logic running in lock step for checking
purposes:
0 = no redundant logic
1 = redundant logic included.
[27:26] ATCM_ES Indicates whether an error scheme is implemented on the ATCM interface:
00 = no error scheme
10 = 32-bit error detection and correction
11 = 64-bit error detection and correction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-81
ID092411 Non-Confidential
System Control
[25:24] BTCM_ES Indicates whether an error scheme is implemented on the BTCM interface(s):
00 = no error scheme
10 = 32-bit error detection and correction
11 = 64-bit error detection and correction.
[22] NO_FPU Indicates whether the CPU contains a floating point unit:
0 = CPU contains a floating point unit
1 = CPU does not contain a floating point unit.
[21:20] MPU_REGIONS Indicates the number of regions in the included CPU MPU:
0b00 = no regions, the MPU has not been included
0b10 = MPU included, with 12 regions
0b11 = MPU included, with 16 regions.
[19:17] BREAK_POINTS Indicates the number of break points implemented in each CPU in the processor, minus 1.
[16:14] WATCH_POINTS Indicates the number of watch points implemented in each CPU in the processor, minus 1.
[10] TCMBUSPARITY Indicates whether the processor contains TCM address bus parity logic:
0 = processor does not contain TCM address bus parity logic
1 = processor contains TCM address bus parity logic.
[9] NO_SLAVE Indicates whether the CPU contains an AXI slave port:
0 = CPU contains an AXI slave port
1 = CPU does not contain an AXI slave port.
[8:7] ICACHE_ES Indicates whether an error scheme is implemented for the instruction cache:
0b00 = no error scheme
0b01 = 8-bit parity error detection
0b11 = 64-bit error detection and correction.
If the CPU does not contain an I-Cache, these bits are set to 0b00.
[6:5] DCACHE_ES Indicates whether an error scheme is implemented for the data cache:
0b00 = no error scheme
0b01 = 8-bit parity error detection
0b10 = 32-bit error detection and correction.
If the CPU does not contain a D-Cache, these bits are set to 0b00.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-82
ID092411 Non-Confidential
System Control
[4] NO_HARD_ERROR_CACHE Indicates whether the processor contains cache for corrected TCM errors:
0 = processor contains TCM error cache
1 = processor does not contain TCM error cache.
[3] AXI_BUS_ECC Indicates whether the processor contains AXI bus ECC logic.
0 = processor does not contain AXI bus ECC logic
1 = processor contains AXI bus ECC logic.
[2] SL Indicates whether the processor has been built with split/lock logic:
0 = no split/lock logic
1 = split/lock logic included.
[1] AHB_PP Indicates whether the CPU contain AHB peripheral interfaces:
0 = CPUs do not have AHB peripheral interfaces
1 = CPUs have AHB peripheral interfaces.
Purpose Describes the value of any pins that control processor options, that are not
visible because they:
• are exposed in registers
• control the initial value of control registers, and are visible in that
way.
Figure 4-57 on page 4-84 shows the Pin Options Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-83
ID092411 Non-Confidential
System Control
31 5 4 3 2 1 0
Reserved 0 0 0 0 0
DBGNOCLKSTOP
INTSYNCEN
IRQADDRVSYNCEN
SLBTCMSB
PARITYLEVEL
[31:5] - SBZ
There are three peripheral interface region registers, one for each of the:
• AHB peripheral interface
• LLPP Normal AXI
• LLPP Virtual AXI.
Purpose Describe the size and base of the interface, and contain an enable bit for
the interface
Figure 4-58 on page 4-85 shows the Peripheral Interface Region Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-84
ID092411 Non-Confidential
System Control
31 12 11 7 6 2 1 0
Reserved
Table 4-61 shows the Peripheral Interface Region Register bit assignments.
[31:12] BaseAddress RO The base address of the interface, given as bits [31:12] of the address of the
interface in the memory map. This value is configured during integration.
[11:7] - RO Reserved.
[6:2] Size RO Returns the size of the interface configured during integration:
0b00000 = no PP present
0b00011 = 4KB
...
0b10111 = 4GB
[1] - RO Reserved.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 4-85
ID092411 Non-Confidential
Chapter 5
Prefetch Unit
This chapter describes how the PreFetch Unit (PFU), in conjunction with the DPU, uses
program flow prediction to locate branches in the instruction stream and the strategies used to
determine if a branch is likely to be taken or not. It contains the following sections:
• About the prefetch unit on page 5-2
• Branch prediction on page 5-3
• Return stack on page 5-5
• Controlling instruction prefetch and program flow prediction on page 5-6.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-1
ID092411 Non-Confidential
Prefetch Unit
• perform speculative fetch of instructions ahead of the DPU by predicting the outcome of
branch instructions
• format instruction data in a way that aids the DPU in efficient execution.
The PFU fetches instructions from the memory system under the control of the DPU, and the
internal coprocessors CP14 and CP15. In ARM state the memory system can supply up to two
instructions per cycle. In Thumb state the memory system can supply up to four instructions per
cycle.
The PFU buffers up to three instruction data fetches in its FIFO. There is an additional FIFO
between the PFU and the DPU that can normally buffer up to eight instructions. This reduces or
eliminates stall cycles after a branch instruction. This increases the performance of the
processor.
• predicting the outcome of conditional branches using the branch predictor and, for direct
branches, calculating their destination address using the offset encoded in the instruction
The DPU resolves the program flow predictions that the PFU makes.
The PFU starts instruction fetches at a rate that is determined dynamically using a prediction
scheme that aims to ensure that the pipeline is kept fed with instructions, without over-fetching
instructions that are not used. Fetching of unused instructions consumes extra power and can
impact performance.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-2
ID092411 Non-Confidential
Prefetch Unit
The PFU can detect branches in the Pd-stage of the pipeline, predict whether or not the branch
is taken, and determine or predict the target address for a taken branch. This enables the PFU to
start fetching instructions at the destination of a taken branch before the branch has completed
execution in the DPU. The branch instruction is still executed in the DPU to determine the
accuracy of the prediction. If the branch was mispredicted, the pipeline must be flushed and the
correct instruction fetched. In general, more branches are correctly predicted than mispredicted
so fewer pipeline flushes occur and the performance of the processor is enhanced.
Two major classes of branch are addressed in the processor prediction scheme:
1. Direct branches, including B, BL, CZB, and BLX immediate, where the target address is a
fixed offset, encoded in the instruction, from the program counter. If such an instruction
has been fetched, and the program counter is known, predicting the destination of the
branch only involves predicting whether the instruction passes or fails its condition code,
that is, whether the branch is taken or not taken.
2. Indirect branches such as load and Branch and eXchange (BX), instructions that write to
the PC, that can be identified as a likely return from a procedure call. Two identifiable
cases are:
• loads to the PC from an address derived from R13
• BX from R0-R14.
In these cases, if the calling operation can also be identified, the likely return address can
be stored in the return stack. Typical calling operations are BL and BLX instructions.
Note
Unconditional instructions of either class of program flow are always executed, and do not
affect prediction history. Unconditional return stack operations always affect the return stack.
Branch prediction in the processor is dynamic and is based around a global history prediction
scheme. In addition, there is extra logic to handle predictions that thrash and to predict the end
of long loops.
The global history scheme is an adaptive predictor that learns the behavior of branches during
execution, identifying them based on the historical pattern of behavior of the preceding
branches. For each pattern of branch behavior, the history table holds a 2-bit hint value. The
2-bit hint indicates if the next branch must be predicted taken or predicted not-taken based on
the behavior of previous branches. The history table contains 256 entries.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-3
ID092411 Non-Confidential
Prefetch Unit
For loops beyond a certain number of iterations, the branch history is not large enough to learn
the history and predict the loop exit. The PFU includes logic to count the number of iterations
(up to 31) of a loop, and thereby predict the not-taken branch that exits the loop. If the number
of iterations taken exceeds 31, the loop branch is never predicted as not-taken.
If multiple branch histories index into the same hint value, this can cause thrashing in the history
table and reduce accuracy of the branch predictor. Logic in the branch predictor detects these
cases and provides some hysteresis for the hint value.
For direct branches, the target address is calculated statically from the instruction encoding and
the program counter. For indirect branches, the hint value predicts if the branch is taken or
not-taken, and the return stack can sometimes be used to predict the target address. When the
destination of a branch cannot be calculated statically, or popped from the return stack, PFU
assumes the branch to be not-taken.
The PFU updates the history for each occurrence of a branch when the DPU indicates how the
branch was resolved.
The DPU resolves branches that the dynamic branch predictor predicts at the Wr-stage of the
pipeline, see Figure 2-1 on page 2-2. A misprediction causes the PFU to flush the pipeline and
fetch the correct instruction stream.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-4
ID092411 Non-Confidential
Prefetch Unit
The return stack consists of a 4-entry circular buffer. When the PFU detects a taken procedure
call instruction, the PFU pushes the return address onto the return stack. The instructions that
the PFU recognizes as procedure calls are, in both the ARM and Thumb instruction sets:
• BL immediate
• BLX immediate
• BLX Rm.
When the return stack detects a taken return instruction, the PFU issues an instruction fetch from
the location at the top of the return stack, and pops the return stack. The instructions that the
PFU recognizes as procedure returns are, in both the ARM and Thumb instruction sets:
• LDM Rn{!}, {..,pc}
• POP {..,pc}
• LDMIB Rn{!}, {..,pc}
• LDMDA Rn{!}, {..,pc}
• LDMDB Rn{!}, {..,pc}
• LDR pc, [sp], #4
• BX Rm.
• The prediction that a conditional return passed or failed its condition code is not correct.
The return stack has no underflow or overflow detection. Either scenario is likely to cause a
misprediction.
Note
The MOV PC, LR instruction is not decoded and is not predicted as a return.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-5
ID092411 Non-Confidential
Prefetch Unit
The fetch rate predictor can be disabled by setting FRCDIC in the Auxiliary Control Register.
When the predictor is disabled, the PFU fetches instructions at the fastest rate possible.
The dynamic branch predictor is controlled with the BP field in the Auxiliary Control Register.
In normal operation the branch prediction is taken from the global history table. You can also
force the prediction to be always taken, or always not-taken. When the prediction is forced to a
fixed direction, the processor does not update the global history table, and the historic pattern
of branches is frozen. You can also disable the loop prediction logic and the logic for preventing
thrashing, by setting DEOLP and DBHE respectively.
You can disable the return stack by setting RSDIS in the Auxiliary Control Register. When
disabled, pushes onto the stack caused by call instructions are disabled and the stack pointer is
frozen.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 5-6
ID092411 Non-Confidential
Chapter 6
Events and Performance Monitor
This chapter describes the Performance Monitoring Unit (PMU) and event bus interface. It
contains the following sections:
• About the events on page 6-2
• About the PMU on page 6-6
• Performance monitoring registers on page 6-7
• Event bus interface on page 6-20.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-1
ID092411 Non-Confidential
Events and Performance Monitor
The events are made visible on an output event bus, EVNTBUSm, and can be counted using
registers in the Performance Monitoring Unit (PMU). See Event bus interface on page 6-20 for
more information about the event bus, and About the PMU on page 6-6 for more information
about the PMU. Table 6-1 lists the events that are generated, along with the bit position of each
event on the event bus, and the numbers that the PMU uses to refer the events. Event reference
numbers that are not listed are Reserved. See Error detection events on page 8-36 for more
information on the CFLR related events.
- Software increment. The register is incremented only on writes to the Software - 0x00
Increment Register. See c9, Software Increment Register on page 6-12.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-2
ID092411 Non-Confidential
Events and Performance Monitor
[11] B immediate, BL immediate or BLX immediate instruction architecturally executed (taken - 0x0D
or not taken).
[12] Procedure return architecturally executed, other than exception returns, for example, BZ - 0x0E
Rm, "LDM Rn, {..,PC}".
MOV PC, LR does not generate this event, because it is not predicted as a return.
[15] Branches or other change in program flow that could have been predicted by the branch - 0x12
prediction resources of the processor.
- ETMEXTOUTm[0]. - 0x48
- ETMEXTOUTm[1]. - 0x49
[22] Instruction cache tag RAM parity or correctable ECC error. Yes 0x4A
[23] Instruction cache data RAM parity or correctable ECC error. Yes 0x4B
[24] Data cache tag or dirty RAM parity error or correctable ECC error, from data-side or Yes 0x4C
ACP.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-3
ID092411 Non-Confidential
Events and Performance Monitor
[25] Data cache data RAM parity error or correctable ECC error. Yes 0x4D
[26] TCM fatal ECC error reported from the prefetch unit. - 0x4E
[27] TCM fatal ECC error reported from the load/store unit. - 0x4F
- Stall cycle caused by integer divide. This includes the single stall cycle required for all - 0x54
divide instructions to write their result into the register bank.
- PLD instruction that did not initiate a linefill because of a resource shortage. - 0x56
- Store buffer operation has detected that two slots have data in same cache line but with - 0x59
different attributes.
[34] Data cache tag/dirty RAM fatal ECC error, from data-side or ACP. - 0x61
[35] Processor livelock because of hard errors or exception at exception vector. - 0x62
[43] TCM correctable ECC error reported by load/store unit. Yes 0x6A
[44] TCM correctable ECC error reported by prefetch unit. Yes 0x6B
[45] TCM fatal ECC error reported by AXI slave interface. - 0x6C
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-4
ID092411 Non-Confidential
Events and Performance Monitor
[46] TCM correctable ECC error reported by AXI slave interface. Yes 0x6D
[51]-[54] Unused - -
a. If one of the event counters is configured to count this event, then the counter increases by two when a dual-issued pair of instructions are
architecturally executed. The EVNTBUSm[5] signal is asserted for one cycle only in the same situation - use EVNTBUSm[6] to distinguish
this situation.
b. This event is signalled when any one of a number of events occur. It is formed as a logical OR of the constituent events. This means that if
two or more of the constituent events occur at the same time, the composite event is only signaled once and the event counter, if configured
to count this event, is only incremented by one.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-5
ID092411 Non-Confidential
Events and Performance Monitor
All three event counters are read and written through the same CP15 register. The Performance
Counter Selection (PMSELR) Register determines which counter is read or written. The three
Event Selection registers, one per counter, are read and written through one CP15 register in the
same way.
Using the control registers, you can enable or disable each of the event counters individually,
and read and reset the overflow flag for each counter. Any or all of the counters can be enabled
to assert an interrupt request output, nPMUIRQm, on overflow.
The PMU only counts events when non-invasive debug is enabled, that is, when either
DBGENm or NIDENm inputs are asserted. The Cycle Count (PMCCNTR) Register is always
enabled regardless of whether non-invasive debug is enabled, unless the DP bit of the PMCR
register is set. See c9, Performance Monitor Control Register on page 6-7.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-6
ID092411 Non-Confidential
Events and Performance Monitor
Purpose Controls the operation of the three count registers, and the PMCCNTR
Register.
31 24 23 16 15 11 10 6 5 4 3 2 1 0
D
IMP IDCODE N Reserved X D C P E
P
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-7
ID092411 Non-Confidential
Events and Performance Monitor
[5] DP Disable PMCCNTR when prohibited, that is, when non-invasive debug is not enabled:
0 = Count is enabled in prohibited regions. This is the reset value.
1 = Count is disabled in prohibited regions.
[4] X Enable export of the events to the event bus for an external monitoring block, for example the
ETM, to trace events:
0 = Export disabled. This is the reset value.
1 = Export enabled.
[0] E Enable:
0 = Disable all counters, including PMCCNTR. This is the reset value.
1 = Enable all counters including PMCCNTR.
The PMCR Register is always accessible in Privileged mode. To access the register, read or
write CP15 with:
MRC p15, 0, <Rd>, c9, c12, 0 ; Read PMCR Register
MCR p15, 0, <Rd>, c9, c12, 0 ; Write PMCR Register
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-8
ID092411 Non-Confidential
Events and Performance Monitor
• The values in this register are ignored unless the E bit, bit [0], is set
in the PMCR Register, see c9, Performance Monitor Control
Register on page 6-7.
31 3 2 1 0
C Reserved
When reading this register, any enable that reads as 0 indicates the corresponding counter is
disabled. Any enable that reads as 1 indicates the corresponding counter is enabled.
Writing a 1 to a particular count enable bit enables that counter. Writing a 0 to a count enable
bit has no effect. You must use the Count Enable Clear Register to disable the counters. All
counters are disabled at reset.
The PMCNTENSET Register retains its value when the enable bit of the PMCR is clear, even
though its settings are ignored.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-9
ID092411 Non-Confidential
Events and Performance Monitor
31 3 2 1 0
C Reserved
When reading this register, any enable that reads as 0 indicates the corresponding counter is
disabled. Any enable that reads as 1 indicates the corresponding counter is enabled.
When writing this register, any enable written with a value of 0 is ignored, that is, not updated.
Any enable written with a value of 1 clears the counter enable. You must use the Count Enable
Set Register to enable the counters. All counters are disabled at reset.
Writing to bits in this register disables individual counters, and clears the corresponding bits in
the PMCNTENSET Register, see c9, Count Enable Set Register on page 6-8.
You can use the enable, EN, bit [0] of the PMCR Register to disable all performance counters
including PMCCNTR, see c9, Performance Monitor Control Register on page 6-7.
The PMCNTENCLR and PMCNTENSET Registers retain their values when the enable bit of
the PMCR is clear, even though their settings are ignored. The PMCNTENCLR Register can be
used to clear the enabled flags for individual counters even when all counters are disabled in the
PMCR Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-10
ID092411 Non-Confidential
Events and Performance Monitor
Purpose Indicates if event counters have overflowed. All overflow flags are reset
to zero.
31 3 2 1 0
C Reserved
If an overflow flag is set to 1 in the PMOVSR register it remains set until one of the following
happens:
• writing 1 to the flag bit in the PMOVSR Register clears the flag
• the processor is reset.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-11
ID092411 Non-Confidential
Events and Performance Monitor
31 3 2 1 0
Reserved
P2
Performance monitor counters
P1
software increment bits
P0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-12
ID092411 Non-Confidential
Events and Performance Monitor
31 5 4 0
Reserved SEL
Any values programmed in the PMSELR Register other than those specified in Table 6-7 are
Unpredictable.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-13
ID092411 Non-Confidential
Events and Performance Monitor
There are three Event Type Select Registers in the processor, PMXEVTYPER0 to
PMXEVTYPER2, each corresponding to one of the Performance Monitor Count
(PMXEVCNTR) Registers, PMXEVCNTR0 to PMXEVCNTR2. The register to be accessed is
determined by the value in the PMSELR.
31 8 7 0
Reserved SEL
[7:0] SEL Event number selected, see Table 6-1 on page 6-2 for values.
The reset value of this field is Unpredictable.
The absolute counts of events recorded might vary because of pipeline effects. This has
negligible effect except in cases where the counters are enabled for a very short time.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-14
ID092411 Non-Confidential
Events and Performance Monitor
In addition to the counters within the processor, most of the events that Table 6-1 on page 6-2
shows are available to the ETM unit or other external trace hardware to enable monitoring of
the events. For information on how to monitor these events, see the CoreSight ETM-R5
Technical Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-15
ID092411 Non-Confidential
Events and Performance Monitor
• Accessible in:
— Privileged mode
— User mode only when the [Link] bit is set to 1, see c9, User Enable
Register.
To access the current Event Count Registers, read or write CP15 with:
MRC p15, 0, <Rd>, c9, c13, 2 ; Read current PMNx Register
MCR p15, 0, <Rd>, c9, c13, 2 ; Write current PMNx Register
31 1 0
Reserved
EN
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-16
ID092411 Non-Confidential
Events and Performance Monitor
If the EN bit in the PMUSERENR Register is not set, any attempt to access a performance
monitor register or a validation register from User mode causes an Undefined Instruction
exception.
Note
For more information on access permissions to the performance monitor registers and validation
registers, see the ARM Architecture Reference Manual.
31 3 2 1 0
C Reserved
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-17
ID092411 Non-Confidential
Events and Performance Monitor
Reading this register returns the current setting, with a 1 in one of the counter bits indicating that
interrupts are enabled for that counter. Writing a 1 to a particular interrupt bit enables interrupt
generation on overflow of that counter. Writing a 0 has no effect. You can only disable interrupts
by writing to the PMINTENCLR Register.
To access the Interrupt Enable Set Register, read or write CP15 with:
MRC p15, 0, <Rd>, c9, c14, 1 ; Read PMINTENSET Register
MCR p15, 0, <Rd>, c9, c14, 1 ; Write PMINTENSET Register
If this unit generates an interrupt, the processor asserts the pin nPMUIRQm. You can route this
pin to an external interrupt controller for prioritization and masking. This is the only mechanism
that signals this interrupt to the processor.
Note
ARM expects that the Performance Monitor interrupt request signal, nPMUIRQm, connects to
a system interrupt controller.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-18
ID092411 Non-Confidential
Events and Performance Monitor
31 3 2 1 0
C Reserved
Reading this register returns the current setting, with a 1 in one of the counter bits indicating that
interrupts are enabled for that counter. Writing a 1 to a particular interrupt disable bit disables
interrupt generation on overflow of that counter. Writing a 0 has no effect. You can only enable
interrupt requests by writing to the PMINTENSET Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-19
ID092411 Non-Confidential
Events and Performance Monitor
The event bus only signals events when it is enabled. Set the X bit in the Performance Monitor
Control Register to enable the event bus. See c9, Performance Monitor Control Register on
page 6-7.
See Table 6-1 on page 6-2 to see which bit of the event bus each event is signaled on.
Note
If an event is being counted in the PMU, the count might not be incremented in exactly the same
cycle that the event is signaled on the event bus.
The event bus is designed to be connected to the ETM-R5, that enables processor events to
trigger tracing for debug purposes. You can also connect it to event counting registers external
to the processor, or to an interrupt generator.
Because each EVNTBUSm pin is only asserted for one cycle for each occurrence of the event,
it is possible to create composite events by ORing various EVNTBUSm pins together. A
composite event signal like this is asserted when any of the included events occur although, if
multiple events occur in the same cycle, the composite event only occurs once.
The processor also has two event input pins, ETMEXTOUTm[1:0]. This bus is normally
intended for connection to the ETM, and enables the Cortex-R5 performance monitor to count
events generated by the ETM. These inputs can alternatively be used for composite events
generated external to the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 6-20
ID092411 Non-Confidential
Chapter 7
Memory Protection Unit
This chapter describes the Memory Protection Unit (MPU). It contains the following sections:
• About the MPU on page 7-2
• Memory types on page 7-7
• Region attributes on page 7-8
• MPU interaction with memory system on page 7-9
• MPU faults on page 7-10
• MPU software-accessible registers on page 7-11.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-1
ID092411 Non-Confidential
Memory Protection Unit
The MPU enables you to partition memory into regions and set individual protection attributes
for each region. The MPU supports zero, 12, or 16 memory regions.
Note
If the MPU has zero regions, you cannot enable or program the MPU. Attributes are only
determined from the default memory map when zero regions are implemented.
Each region is programmed with a base address and size, and the regions can be overlapped to
enable efficient programming of the memory map. To support overlapping, the regions are
assigned priorities, with region 0 having the lowest priority and region 15 having the highest.
The MPU returns access permissions and attributes for the highest priority enabled region where
the address hits.
The MPU is programmed using CP15 registers c1 and c6, see MPU control and configuration
on page 4-3. Memory region control read and write access is permitted only from Privileged
modes.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-2
ID092411 Non-Confidential
Memory Protection Unit
Before the MPU is enabled, you must program at least one valid protection region. If you do not
do this, the processor enters a state that only reset can recover.
When the MPU is disabled, no access permission checks are performed, and memory attributes
are assigned according to the default memory map. See Table 7-1 on page 7-2.
For more information on how to enable or disable the MPU, see MPU interaction with memory
system on page 7-9.
Depending on the implementation, the MPU has a maximum of 12 or 16 regions. Using CP15
register c6 you can specify the following for each region:
• region base address
• region size
• subregion enables
• region attributes
• region access permissions
• region enable.
The base address defines the start of the memory region. You must align this to a region-sized
boundary. For example, if a region size of 8KB is programmed for a given region, the base
address must be a multiple of 8KB.
Note
If the region is not aligned correctly, this results in Unpredictable behavior.
Region size
The region size is specified as a 5-bit value, encoding a range of values from 32 bytes, a
cache-line length, to 4GB. Table 4-34 on page 4-56 shows the encoding.
Subregions
Each region can be split into eight equal sized non-overlapping subregions. An access to a
memory address in a disabled subregion does not use the attributes and permissions defined for
that region. Instead, it uses the attributes and permissions of a lower priority region or generates
a background fault if no other regions overlap at that address. This enables increased protection
and memory attribute granularity.
All region sizes between 256 bytes and 4GB support eight subregions. Region sizes below 256
bytes do not support subregions, and the subregion disable field is SBZ/UNP for regions of less
than 256 bytes in size.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-3
ID092411 Non-Confidential
Memory Protection Unit
Region attributes
Each region has a number of attributes associated with it. These control how a memory access
is performed when the processor accesses an address that falls within a given region. The
attributes are:
• Memory type, one of:
— Strongly Ordered
— Device
— Normal
• Shared or Non-shared
• Non-cacheable
• Write-through Cacheable
• Write-back Cacheable
• Read allocation
• Write allocation.
See Memory types on page 7-7 for more information about memory types, and Region attributes
on page 7-8 for a description of how to assign types and attributes to a region.
Each region can be given no access, read-only access, or read/write access permissions for
Privileged or all modes. In addition, each region can be marked as eXecute Never (XN) to
prevent instructions being fetched from that region.
For example, if a User mode application attempts to access a Privileged mode access only region
a permission fault occurs.
The ARM architecture uses constants known as inline literals to perform address calculations.
The assembler and compiler automatically generate these constants and they are stored inline
with the instruction code. To ensure correct operation, only a memory region that has permission
for data read access can execute instructions. For more information, see the ARM Architecture
Reference Manual. For information about how to program access permissions, see Table 4-38
on page 4-58.
Instructions cannot be executed from regions with Device or Strongly-Ordered memory type
attributes.
You can program the MPU with two or more overlapping regions. For overlapping regions, a
fixed priority scheme determines attributes and permissions for memory access to the
overlapping region. Attributes and permissions for region 15 take highest priority, those for
region 0 take lowest priority. For example:
Region 2 Is 4KB in size, starting from address 0x3000. Privileged mode has full
access, and User mode has read-only access.
Region 1 Is 16KB in size, starting from address 0x0000. Both Privileged and User
modes have full access.
When the processor performs a data write to address 0x3010 while in User mode, the address
falls into both region 1 and region 2, as Figure 7-1 on page 7-5 shows. Because these regions
have different permissions, the permissions associated with region 2 are applied. Because User
mode is read access only for this region, a permission fault occurs, causing a data abort.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-4
ID092411 Non-Confidential
Memory Protection Unit
0x4000
0x3010 Region 2
0x3000
Region 1
0x0000
You can use overlapping regions for stack protection. For example:
• allocate to region 2 the minimum region size, 32 bytes, and position it at the end of the
stack for the current process
If the current process overflows the stack it uses, a write access to region 2 by the processor
causes the MPU to raise a permission fault.
0x4000
Region 1
0x0000 Region 2
• Set the least-significant subregion disable bit. That is, set the subregion disable field, bits
[15:8], of the CP15 MPU Region Size Register to 0x01.
If the current process overflows the stack it uses, a write access by the processor to the disabled
subregion causes the MPU to raise a background fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-5
ID092411 Non-Confidential
Memory Protection Unit
0x4000
Stack
0x0800
Guard region
0x0000
Overlapping regions increase the flexibility of how the regions can be mapped onto physical
memory devices in the system. You can also use the overlapping properties to specify a
background region. For example, you might have a number of physical memory areas sparsely
distributed across the 4GB address space. If a programming error occurs, the processor might
issue an address that does not fall into any defined region.
If the address that the processor issues falls outside any of the defined regions and the MPU is
enabled, the MPU is hard-wired to abort the access. That is, all accesses for an address that is
not mapped to a region in the MPU generate a background fault. You can override this behavior
by programming region 0 as a 4GB background region. In this way, if the address does not fall
into any of the other 11 regions, the attributes and access permissions you specified for region
0 control the access.
In Privileged modes, you can also override this behavior by setting the BR bit, bit [17], of the
SCTLR. This causes Privileged accesses that fall outside any of the defined regions to use the
default memory map.
Any memory address that you configure to be accessed using a TCM interface is given Normal,
Non-shared type attributes, regardless of the attributes of any MPU region that the address also
belongs to. Access permissions for an address in a TCM region are preserved from the MPU
region that the address also belongs to. For more information, see About the TCMs on page 8-13.
Any memory address accessed using one of the peripheral port interfaces is considered to be
non-cacheable and eXecute-Never (XN), regardless of the attributes of any MPU region that the
address also belongs to. The memory type and other access permissions for such a region are
inherited from the MPU region that the address also belongs to. See Peripheral interface
attributes and permissions on page 9-38.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-6
ID092411 Non-Confidential
Memory Protection Unit
MPU memory regions can each be assigned a memory type attribute. Table 7-2 shows a
summary of the memory types.
Strongly Ordered - All memory accesses to Strongly Ordered memory occur in program order.
All Strongly Ordered accesses are assumed to be shared.
Normal Shared For normal memory that is shared between several processors.
Note
The processor’s L1 cache does not cache shared normal regions.
For more information on memory attributes and types, memory barriers, and ordering
requirements for memory accesses, see the ARM Architecture Reference Manual.
All of the processor interfaces to the external memory system have associated store buffers that
help to improve the throughput of accesses to Normal type memory. See Store buffer on
page 8-18 and Peripheral interfaces on page 9-36 for more information. Because of the
ordering rules that they must follow, accesses to other types of memory typically have a lower
throughput or higher latency than accesses to Normal memory. In particular:
• reads from Device memory must first drain the relevant store buffer of all writes to Device
memory and wait for all Device writes to the relevant interface that have been posted onto
the bus to complete
• all accesses to Strongly Ordered memory must first drain the store buffer completely and
wait for all writes that have been posted onto the buses to complete.
Similarly, when it is accessing Strongly Ordered or Device type memory, the processor's
response to interrupts must be modified, and the interrupt response latency is longer. See Low
interrupt latency on page 3-20 for more information.
To ensure optimum performance, you must understand the architectural semantics of the
different memory types. Use Device memory type for appropriate memory regions, typically
peripherals, and only use Strongly Ordered memory type for memory regions where it is
essential.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-7
ID092411 Non-Confidential
Memory Protection Unit
The Region Access Control Registers use five bits to encode the memory region type. These are
the TEX[2:0], C and B bits. Table 4-36 on page 4-57 shows the mapping of these bits to memory
region attributes.
Note
In earlier versions of the architecture, the TEX, C, and B bits were known as the Type Extension,
Cacheable and Bufferable bits. These names no longer adequately describe the function of the
B, C, and TEX bits.
All memory attributes that are Cacheable, write-back or write-through, are also implicitly
read-allocate. Table 4-36 on page 4-57 shows which attributes are write-allocate.
When the region attributes indicate that the inner cache policy is write-back, no write-allocate,
the Cortex-R5 cache behaves as if the policy were write-back, write-allocate.
In addition, the Region Access Control Registers contain the shared bit, S. This bit only applies
to Normal memory, and determines whether the memory region is Shared (1) or Non-shared (0).
When the processor performs a memory access through its AXI bus master interface:
• the Inner attributes are indicated on the A*INNERMm signals.
• the Outer attributes are indicated on the A*CACHEMm signals.
Similarly, for memory accesses performed through the AXI peripheral port, the Outer attributes
are indicated on the A*CACHEPm signals.
For more information on region attributes, see the ARM Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-8
ID092411 Non-Confidential
Memory Protection Unit
1. Program all relevant CP15 registers. This includes setting up at least one memory region
that covers the executing code, and that the attributes and permissions of that region are
the same as the attributes and permissions of the region in the default memory map that
covers the code, and that the region is executable in Privileged mode.
3. Disable caches.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-9
ID092411 Non-Confidential
Memory Protection Unit
When a fault occurs, the memory access or instruction fetch is synchronously aborted, and a
prefetch abort or data abort exception is taken as appropriate. No memory accesses are
performed on the AXI bus master interface or peripheral ports. For more information about fault
handling, see Fault handling on page 8-7.
A background fault is generated when the MPU is enabled and a memory access is made to an
address that is not within an enabled subregion of an MPU region. A background fault does not
occur if the background region is enabled and the access is Privileged. See Background regions
on page 7-6.
A permission fault is generated when a memory access does not meet the requirements of the
permissions defined for the memory region that it accesses. See Region access permissions on
page 7-4.
An alignment fault is generated if a data access is performed to an address that is not aligned for
the size of the access, and strict alignment is required for the access. A number of instructions
that access memory, for example, LDM and STC, require strict alignment. See the ARM
Architecture Reference Manual for more information. In addition, strict alignment can be
required for all data accesses by setting the A-bit in the SCTLR. See c1, System Control Register
on page 4-38.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-10
ID092411 Non-Confidential
Memory Protection Unit
When the MPU is not present, the c6, MPU memory region programming registers on page 4-53
read as zero and ignore writes in Privileged mode. No Undefined Instruction exceptions are
taken.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 7-11
ID092411 Non-Confidential
Chapter 8
Level One Memory System
This chapter describes the processor Level one (L1) memory system. It contains the following
sections:
• About the L1 memory system on page 8-2
• About the error detection and correction schemes on page 8-4
• Fault handling on page 8-7
• About the TCMs on page 8-13
• About the caches on page 8-18
• Internal exclusive monitor on page 8-34
• Memory types and L1 memory system behavior on page 8-35
• Error detection events on page 8-36.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-1
ID092411 Non-Confidential
Level One Memory System
The instruction-side and data-side can each optionally have their own L1 caches. The cache
architecture is Harvard, that is, only instructions can be fetched from the I-Cache, and only data
can be fetched from the D-Cache. In parallel with each of the caches are two areas of dedicated
RAM accessible to both the instruction and data sides. These are regions of TCM. You can
implement one TCM using the ATCM interface and up to two TCMs using the BTCM interface.
Figure 8-1 on page 8-3 shows this.
Memory accesses, required for fetching instructions and for data transfer instructions, are
performed to the appropriate TCM if the address is in an enabled TCM region. Remaining
instruction accesses and remaining data accesses that are not in a peripheral interface region are
looked up in the appropriate L1 cache if they are cacheable. Accesses that are not serviced by
the L1 memory system are passed to the L2 memory system through the AXI-master interface
or one of the peripheral interfaces. See Chapter 9 Level Two Interface for more information
about the L2 memory system.
Each TCM and cache can be configured at implementation time to have an error detection and
correction scheme to protect the data stored in the memory from errors. Each TCM interface
also has support for logic external to the processor to tell the processor that an error has
occurred.
The MPU handles accesses to both the instruction and data sides. The MPU is responsible for
protection checking, address access permissions, and memory attributes for all accesses. Some
of these attributes can be passed to the L2 memory system through the AXI master or peripheral
ports. See Chapter 7 Memory Protection Unit for more information about the MPU.
The L1 memory system includes a monitor for exclusive accesses. Exclusive load and store
instructions, for example LDREX and STREX, can be used with the appropriate memory monitoring
to provide inter-process or inter-processor synchronization and semaphores. See the ARM
Architecture Reference Manual for more information. The internal monitor can handle some
exclusive monitoring internally to the processor, see Internal exclusive monitor on page 8-34 for
more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-2
ID092411 Non-Confidential
Level One Memory System
AXI masters
Cortex-R5 CPU
LSU AXI slave PFU
Interconnect
Level 1
D-cache I-cache memory
AXI AXI virtual AHB ATCM BTCM
control control system
peripheral peripheral peripheral interface interface
interface interface interface B1 RAM
B0 RAM
AXI AHB
peripheral peripheral
port port A RAM
I-cache
RAMs
D-cache
RAMs
AXI
master
interface
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-3
ID092411 Non-Confidential
Level One Memory System
A number of different error schemes are available, and are described in:
• Parity
• 64-bit ECC on page 8-5
• 32-bit ECC on page 8-5.
Each has different properties in terms of the number of errors that can be detected, and corrected,
and the amount of extra RAM required to store the redundant data. Because different logic is
required for each scheme, the scheme must be chosen in the build-configuration, although you
can enable or disable, or change the behavior of the error schemes using software-configuration.
This section describes the generic properties of each of the schemes. See Appendix C ECC
Schemes for more information about the advantages and disadvantages of each scheme to the
implementer. Operation of the error schemes for the caches is described in Cache error
detection and correction on page 8-20, and for the TCMs in TCM internal error detection and
correction on page 8-14.
The error schemes are each described in terms of their operation on a doubleword, 64 bits, of
data, because this is the amount of data that the processor L1 memory system can transfer each
cycle. The tag and dirty RAMs associated with the caches are different sizes, but the principles
are the same. An error is considered to be a single bit of data that has been inverted relative to
its correct value.
Figure 8-2 shows the error schemes. The shaded areas represent bits with errors.
8.2.1 Parity
For each byte, a parity bit is computed and stored with that byte. This requires eight bits of
parity, or redundant data per doubleword. With a parity scheme, a single error in a byte or its
parity bit can be detected, but not corrected. This means that, provided they are all in different
bytes, eight errors can be detected per doubleword. However, if there are two errors in any
individual byte, this cannot be detected. Odd or even parity can be used, and this can be
pin-configured during integration.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-4
ID092411 Non-Confidential
Level One Memory System
The processor supports Error Checking and Correction (ECC) schemes for either 64-bits or
32-bits of data, and these have similar properties, although though the size of the data chunk that
the ECC scheme applies to is different. For each data chunk, either 32-bits or 64-bits, aligned,
a number of redundant code bits are computed and stored with the data. This enables the
processor to detect up to two errors in the data chunk or its code bits, and correct any single error
in the data chunk or its associated code bits. This is sometimes referred to as a
Single-Error-Correction, Double-Error-Detection (SEC-DED) ECC scheme.
If there are more than two errors in a data chunk and its associated code bits, they might or might
not be detected. The error scheme might interpret such a condition as a single-error and make
an unsuccessful attempt at a correction.
64-bit ECC
Eight code bits are computed for each 64 bits of data. The scheme can correct any single error
occurring in any doubleword, and detect any two errors occurring in any doubleword.
32-bit ECC
Seven code bits are computed for each 32 bits of data, so 14 bits of redundant data are required
for each doubleword. The scheme can correct two errors per doubleword, if they are in different
words. Four errors can be detected per doubleword, if there are two in each word.
8.2.3 Read-Modify-Write
The smallest unit of data that the processor can write is a byte. However, both the ECC schemes
are computed on data chucks that are larger than this. To write any data to a RAM protected with
ECC requires the error code for that data to be recomputed and rewritten. If the entire data chunk
is not written, for example, a halfword, 16-bits, is written to address 0x4 of a RAM with a 32-bit
error scheme, the error code must be computed partly from the data being written, and partly
from data already stored in the RAM. In this example, the halfword in the RAM at address 0x6.
To compute the error code for such a write, the processor must first read data from the RAM,
then merge the data to be written with it, to compute the error code, then write the data to the
RAM, along with the new error code. This process is referred to as read-modify-write.
The errors described in this chapter are all assumed to be soft errors, that is, one or more bits of
the data stored in a RAM chunk are inverted. A new value can still be written to the RAM and
read back correctly, unless another soft error occurs in the meantime.
If the error in the memory is a hard error, that is, a physical failure of the RAM circuit so that a
bit can never be read or written reliably, the processor might not be able to correct and recover
from the error. The processor contains features that enable it to recover from some hard errors.
If you are implementing the processor and require these features, contact ARM to discuss the
features and your requirements.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-5
ID092411 Non-Confidential
Level One Memory System
When a correctable error is detected in data that has been read from a RAM, the processor has
various ways of generating the correct data, that follow two schemes:
Correct inline
The error code bits are used to correct the data read from the RAM, and this data
is used. This is the simplest way of correcting the data.
Correct-and-retry
The error code bits are used to correct the data, and this data is then written back
to the RAM. The processor then repeats the read access by re-executing the
instruction that caused the read, and reads the corrected data from the RAM if no
more errors have occurred. This takes more clock cycles, at least nine, in the event
of an error, but has the side-effect of correcting the data in the RAM so that the
errors in the data cannot become worse.
Note
Because RAM errors generally occur infrequently, the extra cycles required to
perform correct-and-retry do not have a significant impact on average
performance.
The correction method that the processor uses depends on the individual error. The processor
uses correct inline error correction when it detects a correctable error on a TCM read made by
the AXI-slave interface. The processor uses correct-and-retry correction when it detects a
correctable ECC error on a TCM read made by the instruction-side or data-side.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-6
ID092411 Non-Confidential
Level One Memory System
8.3.1 Faults
MPU faults
The MPU can generate an abort for various reasons. See MPU faults on page 7-10 for more
information. MPU faults are always synchronous, and take priority over other types of abort. If
an MPU fault occurs on an access that is not in the TCM, and is to one of the peripheral ports,
is Non-cacheable, or has generated a cache-miss, the AXI/AHB transactions for that access are
not performed.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-7
ID092411 Non-Confidential
Level One Memory System
External faults
A memory access performed through the AXI master interface or the AXI peripheral port can
generate two different types of error response, a slave error (SLVERR) or decode error
(DECERR). These are known as external errors, because they are generated by the AXI system
outside the processor. Synchronous aborts are generated for instruction fetches, data loads,
exclusive stores, and data stores to strongly-ordered-type memory. Non-exclusive stores to
normal-type or device-type memory generate asynchronous aborts.
Note
• An AXI slave that cannot handle exclusive transactions returns OKAY in response to an
exclusive read. This is also treated as an external error, and the processor behaves as if the
response was SLVERR.
If the processor has been configured with the appropriate build options, it can detect data errors
occurring in the cache and TCM RAMs using parity or ECC logic. For more information on
cache errors, see Handling cache parity errors on page 8-21 and Handling cache ECC errors
on page 8-22. For more information on TCM errors, see About the error detection and
correction schemes on page 8-4. Depending on the software configuration of the processor,
these errors are either ignored, generate an abort, are automatically corrected without generating
an abort, or are corrected and generate an abort. If the processor is in debug-halt-state, an error
that is otherwise automatically corrected generates an abort.
Parity and ECC errors can only occur on reads, although these reads might be a side-effect of
store instructions. Aborts generated by loads are always synchronous. Aborts generated by store
instructions to the TCM are also always synchronous, while those to the cache are always
asynchronous. These errors can also occur on some cache-maintenance operations, see Errors
on cache maintenance operations on page 8-23, and generate asynchronous aborts.
Many of the parity and ECC errors are also signaled by the generation of events. See Chapter 6
Events and Performance Monitor. Some of these events are generated when the error is
detected, regardless of whether or not an abort is taken. Aborts are only taken when a memory
access with an error is committed. Others are signaled when and only when the abort is taken.
Any parity or ECC error that can be corrected by the processor is considered to be a correctable
fault, regardless of whether or not the processor is configured to correct the fault.
The TCM port includes signals that can be used to signal an error on a TCM transaction. If
enabled, this causes the processor to take the appropriate type of abort for instruction and data
accesses, or to generate a SLVERR response to an AXI-slave transaction. Write transactions
always generate asynchronous aborts, while read transactions always generate synchronous
aborts.
An error signaled on a read transaction can also signal a retry request, that requests that the
processor retry the same operation rather than take an exception.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-8
ID092411 Non-Confidential
Level One Memory System
A retry request from the TCM port is considered to be a recoverable error. All correctable ECC
faults are also considered to be recoverable.
Debug events
The debug logic in the processor can be configured to generate breakpoints or vector capture
events on instruction fetches, and watchpoints on data accesses. If the processor is
software-configured for monitor-mode debugging, an abort is taken when one of these events
occurs, or when a BKPT instruction is executed. For more information, see Chapter 12 Debug.
See Aborts on page 3-23 for more information about the differences between synchronous and
asynchronous aborts.
When an abort occurs, information about the cause of the fault is recorded in a number of
registers, depending on the type of abort:
• Abort exceptions
• Synchronous abort exceptions on page 8-10
• Asynchronous abort exceptions on page 8-10.
Abort exceptions
The following registers are updated when any abort exception is taken:
Link Register
The r14_abt register is updated to provide information about the address of the
instruction that the exception was taken on, in a similar way to other types of
exception. See Exceptions on page 3-17 for more information. This information
can be used to resume program execution after the abort has been handled.
Note
When a prefetch abort has occurred, ARM recommends that you do not use the
link register value for determining the aborting address, because 32-bit Thumb
instructions do not have to be word aligned and can cause an abort on either
halfword. This applies even if all of the code in the system does not use the extra
32-bit Thumb instructions introduced in ARMv6T2, because the earlier BL and
BLX instructions are both 32 bits long. Use the Fault Address Register instead, as
described in this section.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-9
ID092411 Non-Confidential
Level One Memory System
The following registers are updated when a synchronous abort exception is taken:
The effect of debug events on these registers is described in Debug exception on page 12-42.
Correctable faults are normally automatically corrected by the processor but, depending on the
configuration and on the access that generated the fault, an exception might not be generated,
and the fault status registers might not be updated. In all cases, information about the location
of the fault is recorded in the Correctable Fault Location Register (CFLR).
The CFLR also records information about ACP D-Cache lookups that cause a correctable error.
All correctable faults are recorded in the same register, regardless of whether it was an
instruction-fetch, a data-access, an AXI-slave access, or an ACP coherency maintenance
operation that generated the fault, and whether the fault occurred in the ATCM, BTCM or cache.
The CFLR contains information to identify what sort of access generated the fault, and which
device it occurred in. See Correctable Fault Location Register on page 4-77 for more
information about the format of this register. Each time the CFLR is updated, the information
already in the CFLR is discarded and therefore the CFLR can only contain information about
the most recent correctable fault.
This section describes some ways in which errors can be handled in a system. Exactly how you
program the processor to handle errors depends on the configuration of your processor and
system, and what you are trying to achieve.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-10
ID092411 Non-Confidential
Level One Memory System
If an abort exception is taken, the abort handler reads the information in the link register, SPSR,
and fault status registers to determine the type of abort. Some types of abort are fatal to the
system, and others can be fixed, and program execution resumed. For example, an MPU
background fault might indicate a stack overflow, and be rectified by allocating more stack and
reprogramming the MPU to reflect this. Alternatively, an asynchronous external abort might
indicate that a software error meant that a store instruction occurred to an unmapped memory
address. Such an abort is fatal to the system or process because no information is recorded about
the address the error occurred on, or the instruction that caused the error.
Table 8-1 shows which types of abort are typically fatal because either the location of the error
is not recorded or the error is unrecoverable. Some aborts that are marked as not fatal might turn
out to be fatal in some systems when the cause of the error has been determined. For example,
an MPU background fault might indicate a stack overflow, that can be rectified, or it might
indicate that, because of a bug, the software has accessed a nonexistent memory location, that
can be fatal. These cases can be distinguished by determining the location where the error
occurred. If an error is unrecoverable, that is, it is not a correctable parity or ECC error, and it
is not a TCM external retry request, it is normally fatal regardless of whether or not the location
of the error is recorded. When an abort is taken on an external TCM, parity, or ECC error, the
appropriate Auxiliary Fault Status Register records whether the error was recoverable. See Fault
Status and Address Registers on page 4-49.
Asynchronous External Store to Normal or Device memory using L2 AXI, AHB No Yes
memory interface
Synchronous TCM external error Load/store from/to TCMe TCM Yes Yes
Asynchronous Parity/ECC Cache Store to cache or cache maintenance operationb Cache No Maybec
a. See MPU faults on page 7-10 for more information about the types of MPU fault.
b. See Cache error detection and correction on page 8-20 for more information about parity/ECC errors from the cache.
c. These types of error can be correctable or uncorrectable. Uncorrectable errors are typically fatal. Correctable errors are automatically
corrected by the hardware and might not cause the abort handler to be called. See Cache error detection and correction on page 8-20 and
TCM internal error detection and correction on page 8-14.
d. See TCM internal error detection and correction on page 8-14 for more information about ECC errors from the TCM.
e. Aborts generated by external TCM errors are always unrecoverable, and therefore fatal, see External TCM errors on page 8-16 for more
information about external errors from the TCM.
Correctable errors
In a system in which the processor is configured to automatically correct ECC errors without
taking an abort exception, you can still configure it to respond to such errors. Connect the event
output or outputs that indicate a correctable error to an interrupt controller. When such an event
occurs, the interrupt input to the processor is set, and the processor takes an interrupt exception.
When your interrupt handler has identified the source of the interrupt as a correctable error, it
can read the CFLR to determine where the ECC error occurred. You can examine this
information to identify trends in such errors. By masking the interrupt when necessary, your
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-11
ID092411 Non-Confidential
Level One Memory System
software can ensure that when critical code is executing, the processor corrects the error
automatically, but delays examining information about the error until after the critical code has
completed.
When the processor is in debug halt-state, any correctable error is corrected as appropriate, but
the memory access is not repeated to fetch the correct data, therefore the instruction generating
the error does not complete successfully. Instead, the sticky synchronous abort flag in the
DBGDSCR is set. See CP14 c1, Debug Status and Control Register on page 12-14.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-12
ID092411 Non-Confidential
Level One Memory System
The TCM ports are designed to be connected to RAM, or RAM-like memory, that is,
Normal-type memory. The processor can issue speculative read accesses on these interfaces,
and interrupt store instructions that have issued some but not all of their write accesses.
Therefore, both read and write accesses through the TCM interfaces can be repeated. This
means that the TCM ports are generally not suitable for read- or write-sensitive devices such as
FIFOs. ROM can be connected to the TCM ports, but normally only if ECC is not used. See
Hard errors on page 8-5. If the access is speculative, the processor ignores any error or retry
signaled on the TCM port.
The TCM ports also have wait and error signals to support slow memories and external error
detection and correction. For more information, see External TCM errors on page 8-16.
The PFU can read data using the TCM interfaces. The LSU and AXI slave can each read and
write data using the TCM interfaces.
Each TCM interface has a dedicated base address that you can place anywhere in the physical
address map, and must not be backed by memory implemented externally. The ATCM and
BTCM interfaces must have separate base addresses and must not overlap.
Accesses to the TCMs from the LSU and PFU are checked against the MPU for access
permission. Memory access attributes and permissions are not exported on this interface. Reads
that generate an MPU fault are broadcast on the TCM interface but the abort is taken before the
data is used, ensuring protection is maintained.
Note
Any address in an MPU region with device or strongly-ordered memory type attributes is
implicitly given execute-never (XN) permissions. If such an address is also in a TCM region,
XN permissions are applied to TCM accesses to that address. None of the other device or
strongly-ordered behaviors apply to an address in a TCM region.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-13
ID092411 Non-Confidential
Level One Memory System
You can configure the ATCM interface to be removed, and not included in the processor design.
If implemented, the ATCM can have only a single port.
During implementation, you can configure the ATCM and/or the BTCM to use an
error-protection scheme to protect the data stored in the TCM, see TCM internal error detection
and correction.
The size of each TCM interface is configured during integration. The permissible TCM sizes
are:
• 0KB
• 4KB
• 8KB
• 16KB
• 32KB
• 64KB
• 128KB
• 256KB
• 512KB
• 1MB
• 2MB
• 4MB
• 8MB.
If the BTCM interface has two ports, the size of the RAM attached to each port is half the total
size for the BTCM interface.
The size of the TCM interfaces is visible to software in the TCM Region Registers, see c9,
BTCM Region Register on page 4-63 and c9, ATCM Region Register on page 4-64. All TCM
interface build configuration options can be read from the Build Options Registers, see c15,
Build Options 1 Register on page 4-79 and c15, Build Options 2 Register on page 4-80.
Each TCM interface can be configured with either 32-bit ECC, or 64-bit ECC error schemes.
Both the BTCM ports must have the same error scheme. This section describes these error
schemes.
If a TCM interface has been built with either 32-bit or 64-bit ECC error checking, you can
enable this by setting the appropriate bits in the Auxiliary Control Register. See c1, Auxiliary
Control Register on page 4-41. On the BTCM interface, ECC checking can only be enabled for
both ports or neither port. You can pin-configure the processor to set the enable bits and
therefore enable ECC checking on reset, by tying off the PARECCENRAMm input as
required.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-14
ID092411 Non-Confidential
Level One Memory System
When a fatal error, that is, a 2-bit ECC error, is detected on a TCM read, an error is generated.
Instruction and data reads generate the appropriate type of synchronous abort, and the
AXI-slave interface returns a SLVERR response to the AXI system.
When a correctable error, that is, a 1-bit ECC error, is detected on a TCM read made by the
AXI-slave interface, the processor corrects the data inline before returning to the system.
When a correctable ECC error is detected on a TCM read made by the instruction-side or
data-side, the processor normally generates the correct data and writes it back to the TCM. In
the meantime, the processor retries the read to fetch the correct instruction or data. By setting
the appropriate bits in the Secondary Auxiliary Control Register, you can disable this behavior.
See c15, Secondary Auxiliary Control Register on page 4-44. Instead of correcting the error in
the TCM, the processor generates the appropriate type of synchronous abort.
All ECC code generation and ECC checking must be performed on a complete data chunk,
either 32-bits or 64-bits depending on the configuration. If a read access smaller than the data
chunk is required, the whole chunk is read. If a write smaller than the data chunk is required, the
processor must perform read-modify-write to generate the correct data and ECC code, but it
only does this when ECC error checking is enabled. The data read as part of the
read-modify-write sequence is checked for ECC errors, and the errors are handled in the same
way as for any other TCM read. The ECC code is generated and written to the TCM for every
write, regardless of whether error checking is enabled or not, but the code is only correct if the
write was of a complete data chunk or if the processor performed read-modify-write to generate
the complete data chunk. All data and instruction aborts generated by the ECC logic are
indicated in the appropriate FSR as being a synchronous parity error.
Each TCM port receives requests from the LSU, PFU, and AXI slave. In most cases, the LSU
has the highest priority, followed by the PFU, with the AXI slave having lowest priority.
When a higher-priority device is accessing a TCM port, an access from a lower-priority device
must stall.
When either the LSU or the AXI slave interface is performing a read-modify-write operation on
a TCM port, various internal data hazards exist for either the AXI-slave interface or the LSU.
In these cases, additional stall cycles are generated, beyond those normally required for
arbitration. For optimum performance of the processor when configured with ECC, ensure that
all write bursts to the TCM from the AXI slave interface write an entire data chunk, that is,
32-bits or 64-bits, naturally aligned, depending on the error scheme.
You can enable the processor to boot from the ATCM or the BTCM. The INITRAMAm and
INITRAMBm pins, when tied HIGH, enable the ATCM and the BTCM respectively on leaving
reset. The LOCZRAMAm pin forces one of the TCMs to have its base address at 0x0. If
LOCZRAMAm is tied HIGH, the initial base address of the ATCM is 0x0, otherwise the initial
base address of the BTCM is 0x0. In both cases, the initial base address of the other TCM is
implementation-defined, see Configurable options on page 1-6.
The ATCM Region Register and BTCM Region Register respectively determine the base
address for the ATCM and BTCM. For information on how to read the TCM region registers,
see c9, BTCM Region Register on page 4-63 or c9, ATCM Region Register on page 4-64 as
appropriate. For information about pre-loading data into the TCMs, see TCM on page 2-19.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-15
ID092411 Non-Confidential
Level One Memory System
Each TCM port operates independently to read and write data to and from the memory attached
to it. Information about which memory location is to be accessed is passed on the TCM port
along with write data and associated error code, if appropriate. In addition, the TCM port
provides information about whether the access results from an instruction fetch from the PFU,
a data access from the LSU, or a DMA transfer from the AXI slave interface. Each TCM port
can also be configured to have an associated parity bit, computed from the address and control
signals for that port.
Read data and associated error code or parity bits are read back from the TCM port. In addition,
the TCM memory controller can indicate that the processor must wait one or more cycles before
reading the response, or signal that an error has occurred and must be either aborted or retried.
For more information about TCM errors, see External TCM errors.
Each TCM port has a number of features that support the integration of a TCM RAM with an
error checking scheme implemented in the RAM controller logic outside of the processor, that
is, by the integrator.
Errors can be signaled to each TCM port if the external error checking scheme detects one and,
if enabled, the processor generates an instruction or data abort or an AXI error response as
appropriate. On a TCM read from either the instruction-side or data-side, the TCM controller
can indicate that the read must be retried instead of generating an abort.
You can enable external errors for each TCM port individually by setting the appropriate bits in
the Auxiliary Control Register. See c1, Auxiliary Control Register on page 4-41. If external
errors are not enabled for a TCM port, the processor ignores any error signaled on that port. You
can pin-configure the processor to set the enable bits, and therefore enable external error
checking on reset, by tying off the ERRENRAMm input as required.
In addition, an external error detection scheme might require that data is read and written in
particular sized chunks. The load/store-64 feature, when enabled for a particular TCM interface,
causes all loads and stores to the TCM ports to be of 64-bits of data. This feature is also known
as Read-Modify-Write (RMW), because it causes the processor to generate read-modify-write
sequences for any store of less than 64-bits. You can enable RMW behavior for each TCM
interface individually by setting the appropriate bits in the Secondary Auxiliary Control
Register. See c1, Auxiliary Control Register on page 4-41. You can pin-configure the processor
to set the enable bits and therefore RMW behavior on reset, by tying off the RMWENRAMm
input as required.
Note
The load/store-64 feature is not available on any TCM interface that has been configured with
32-bit ECC.
The error inputs on each TCM port can also be used to signal other types of error, for example,
when an address accessed is out of range for the RAM attached to the TCM port. Errors signaled
on writes from the data-side generate an asynchronous abort. All other aborts generated by
external errors are synchronous. The type of abort is shown in the appropriate FSR as either
synchronous or asynchronous parity error.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-16
ID092411 Non-Confidential
Level One Memory System
The processor has a 64-bit AXI slave interface that provides access to the TCM interfaces from
the AXI bus. This interface is included by default, but can be excluded during configuration of
the processor.
You can use the slave interface for access to the TCM memories. This also enables you to
construct a system with a consistent view of memory. That is, the TCMs can be available at the
same address to the processor and to the system bus.
The AXI slave interface accesses have lower priority than the LSU or PFU accesses.
The MPU does not check accesses from the AXI slave. You can configure the processor to
enable privileged or nonprivileged access to the TCM interfaces from the AXI slave port.
The AXI slave interface does not support locked and exclusive accesses. This means that AXI
masters, other than the processor, cannot safely use semaphores in the TCMs. Although the
Cortex-R5 processor can use semaphores in the TCMs for inter-process synchronization, you
must not use the AXI-slave interface to write to TCM semaphores. The processor has no logic
to preserve its own exclusivity against such writes.
For more information on the AXI slave interface, see AXI slave interface on page 9-21.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-17
ID092411 Non-Confidential
Level One Memory System
Any access that is not for a TCM or peripheral port is handled by the appropriate cache
controller. If the access is to non-shared Cacheable memory, and the cache is enabled, a lookup
is performed in the cache and, if found in the cache, that is, a cache hit, the data is fetched from
or written into the cache. When the cache is not enabled and for Non-cacheable or shared
memory, the accesses are performed using the AXI-master interface.
Both caches allocate a memory location to a cache line on a cache miss because of a read, that
is, all Cacheable locations are Read-Allocate (RA). In addition, the data cache can allocate on a
write access if the memory location is marked as Write-Allocate (WA). When a cache line is
allocated, the appropriate memory is fetched into a linefill buffer by the AXI-master interface
before being written to the cache. See Linefill buffers and the AXI master interface on page 9-6.
The linefill buffers always fetch the requested data first, return it, and then fetch the rest of the
cache line. This enables the data read to be used by the pipeline without waiting for the linefill
to complete and is known as critical word first and non-blocking behavior. If subsequent
instructions require data from the same cache line, this can also be returned when it has been
fetched without waiting for the linefill to complete, that is, the caches also support streaming. If
an error is reported to the AXI-master interface for a linefill, the linefill does not update the
cache RAMs, but an abort is only generated if the error was reported on the critical word.
If all the cache lines in a set are valid, to allocate a different address to the cache, the cache
controller must evict a line from the cache.
Writes accesses that hit in the cache are written into the cache RAMs. If the memory location is
marked as Write-Through (WT), the write is also performed on the AXI-master interface, so that
the data stored in the RAM remains coherent with the external memory system. If the memory
is Write-Back (WB), the cache line is marked as dirty, and the write is only performed on the
AXI-master interface when the line is evicted. When a dirty cache line is evicted, the data is
passed to the Eviction Buffer in the AXI-master interface to be written to the external memory
system. See Eviction buffer on page 9-7 for more information.
The cache controllers also manage the cache maintenance operations described in Cache
maintenance operations on page 8-19.
Each cache can also be configured with either parity or ECC error checking schemes. If an error
checking scheme is implemented and enabled, then the tags associated with each line, and data
read from the cache are checked whenever a lookup is performed in the cache. See Cache error
detection and correction on page 8-20 for more information.
For more information on the general rules about memory attributes and behavior, see the ARM
Architecture Reference Manual.
The cache controller includes a store buffer to hold data before it is written to the cache RAMs
or passed to the AXI master interface. The store buffer has four entries. Each entry can contain
up to 64 bits of data and a 32-bit address. All write requests from the data-side that are not to a
TCM or peripheral interface are stored in the store buffer.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-18
ID092411 Non-Confidential
Level One Memory System
The store buffer has merging capabilities. If a previous write access has updated an entry, other
write accesses on the same line can merge into this entry. Merging is only possible for stores to
Normal memory.
Merging is possible between several entries that can be linked together if the data inside the
different entries belong to the same cache line.
No merging occurs for writes to Strongly Ordered or Device memory. The processor
automatically drains the store buffer as necessary before performing Strongly Ordered accesses
or Device reads.
The store buffer is drained of all stores to Device memory before a load is performed from
Device memory.
All cache maintenance operations are done through the system control coprocessor, CP15. The
system control coprocessor operations supported for the data cache are:
• Invalidate all
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-19
ID092411 Non-Confidential
Level One Memory System
The system control coprocessor operations supported for the instruction cache are:
• Invalidate all
• Invalidate by address.
For more information on cache operations, see Cache operations on page 4-60.
This section describes how the processor detects, handles, reports, and corrects cache memory
errors. Memory errors detected with parity or ECC have Fault Status Register (FSR) values to
distinguish them from other abort causes.
The caches can detect and correct errors depending on the build options used in the
implementation. The build options for the instruction cache can be different to the data cache.
If the parity build option is enabled, the cache is protected by parity bits. For both the instruction
and data cache, the data RAMs include one parity bit per byte of data. The tag RAM contains
one parity bit to cover the tag and valid bit.
• The instruction cache is protected by a 64-bit ECC scheme. The data RAMs include eight
bits of ECC code for every 64 bits of data. The tag RAMs include seven bits of ECC code
to cover the tag and valid bit.
• The data cache is protected by a 32-bit ECC scheme. The data RAMs include seven bits
of ECC code for every 32 bits of data. The tag RAMs include seven bits of ECC code to
cover the tag and valid bit. The dirty RAM includes four bits of ECC to cover the dirty bit
and the two outer attributes bits of each cache line.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-20
ID092411 Non-Confidential
Level One Memory System
The error detection schemes described in this section provide protection against errors that
occur in the data stored in the cache RAMs. Each RAM normally includes a decoder that enables
access to that data and, if an error occurs in this logic, it is not normally detected by these error
detection schemes. The processor includes features that enable it to detect some address decoder
faults. If you are implementing the processor and require these features, contact ARM to discuss
the features and your requirements.
Table 8-2 shows the behavior of the processor on a cache parity error, depending on bits [5:3]
of the Auxiliary Control Register, see c1, Auxiliary Control Register on page 4-41.
Value Behavior
b000 Generate abort on parity errorsa, force write-through, enable hardware recovery
b001
b010
b011 Reserved
b101 Do not generate abort on parity errors, force write-through, enable hardware recovery
b110
b111 Reserved
a. Parity errors caused by ACP coherency maintenance operations do not generate aborts
See Disabling or enabling error checking on page 8-32 for information on how to safely change
these bits.
Hardware recovery
When parity checking is enabled, hardware recovery is always enabled. Memory marked as
write-back write-allocate behaves as write-though. This ensures that cache lines can never be
dirty, therefore the error can always be recovered from by invalidating the cache line that
contains the parity error. The processor automatically performs this invalidation when an error
is detected. The correct data can then be re-read from the L2 memory system.
Parity aborts
If aborts on parity errors are enabled, software is notified of the error by a data abort or prefetch
abort. The error is still automatically corrected by the hardware even if an abort is generated.
If abort generation is not enabled, the hardware recovery including the access retry is invisible
to software. If required, software can use events and the Correctable Fault Location Register to
monitor the errors that are detected and corrected. See Error detection events on page 8-36 and
Correctable Fault Location Register on page 4-77.
Parity errors, caused by ACP coherency maintenance operations, never generate aborts.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-21
ID092411 Non-Confidential
Level One Memory System
Table 8-3 shows the behavior of the processor on a cache ECC error, depending on bits [5:3] of
the Auxiliary Control Register, see c1, Auxiliary Control Register on page 4-41.
Value Behavior
b001
b010 Generate abort on ECC errorsa, force write-through, enable hardware recovery
b011 Reserved
b110 Do not generate abort on ECC errors, force write-through, enable hardware recovery
b111 Reserved
a. ECC errors caused by ACP coherency maintenance operations do not generate aborts
See Disabling or enabling error checking on page 8-32 for information on how to safely change
these bits.
When ECC checking is enabled, hardware recovery is always enabled. When an ECC error is
detected, the processor tries to evict the cache line containing the error. If the line is clean, it is
invalidated, and the correct data is reloaded from the L2 memory system. If the line is dirty, the
eviction writes the dirty data out to the L2 memory system, and in the process it corrects any
1-bit errors. The corrected data is then reloaded from the L2 memory system.
If a 2-bit error is detected in a dirty line, the error is not correctable. If the 2-bit error is in the
tag or dirty RAM, no data is written to the L2 memory system. If the 2-bit error is in the data
RAM, the cache line is written to the L2 memory system, but the AXI master port WSTRBMm
signal is LOW for the data that contains the error. If an uncorrectable error is detected, an abort
is always generated because data might have been lost. It is expected that such a situation can
be fatal to the software process running.
If one of the force write-though settings is enabled, memory marked as write-back write-allocate
behaves as write-though. This ensures that cache lines can never be dirty, therefore the error can
always be recovered from by invalidating the cache line that contains the ECC error.
You can recover from all detectable errors in the instruction cache, because the instruction cache
can never contain dirty data.
ECC aborts
If aborts on ECC errors are enabled, software is notified of the error by a data abort or prefetch
abort. The error is still automatically corrected by the hardware even if an abort is generated.
If abort generation is not enabled, the hardware recovery including the access retry of
correctable errors is invisible to software. If required, software can use events and the
Correctable Fault Location Register to monitor the errors that are detected and corrected. See
Error detection events on page 8-36 and Correctable Fault Location Register on page 4-77.
ECC errors, caused by ACP coherency maintenance operations, never generate aborts.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-22
ID092411 Non-Confidential
Level One Memory System
All parity or ECC errors detected on instruction cache reads are correctable. If aborts are
enabled, a synchronous prefetch abort exception occurs. The instruction FAR gives the address
that caused the error to be detected. The instruction FSR indicates a parity error on a read. The
auxiliary FSR indicates that the error was in the cache and which cache Way the error was in.
If parity or ECC aborts are enabled, or an uncorrectable ECC error is detected, a synchronous
data abort exception occurs. The data FAR gives the address that caused the error to be detected.
The data FSR indicates a synchronous read parity error. The auxiliary FSR indicates that the
error was in the cache and which cache Way the error was in.
If parity or ECC aborts are enabled, or an uncorrectable ECC error is detected, an asynchronous
data abort exception occurs. Because the abort is asynchronous, the data FAR is Unpredictable.
The data FSR indicates an asynchronous write parity error. The auxiliary FSR indicates that the
error was in the cache and which cache Way and Index the error was in.
In write-through cache regions the store that caused the error is written to external memory
using the L2 memory interface so data is not lost and the error is not fatal.
Errors on evictions
If the cache controller has determined a cache miss has occurred, it might have to do an eviction
before a linefill can take place. This can occur on reads, and on writes if write-allocation is
enabled for the region. Certain cache maintenance operations also generate evictions. If it is a
data-cache line that is dirty, an ECC error might be detected on the line being evicted:
• if the error is correctable, it is corrected inline before the data is written to the external
memory using the L2 memory interface
• if there is an uncorrectable error in the tag or dirty RAM, the write is not done and an
asynchronous abort occurs
• if there is an uncorrectable error in the data RAM, the AXI master port WSTRBMm
signal is deasserted for the words with an error, and an asynchronous abort occurs.
An asynchronous abort can also occur on a correctable error depending on the Auxiliary Control
Register bits [5:3], see c1, Auxiliary Control Register on page 4-41. Any detected error is
signaled with the appropriate event.
Note
When parity checking is enabled, force write-though is always enabled. Therefore the cache
lines can never be dirty, and so evictions are not required. Force write-through can also be
enabled with ECC checking.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-23
ID092411 Non-Confidential
Level One Memory System
This operation ignores all errors in the cache and sets all instruction cache entries to invalid
regardless of error events. This operation cannot generate an asynchronous abort, and no error
events are signaled.
This operation ignores all errors in the cache and sets all data cache entries to invalid regardless
of errors. This operation cannot generate an asynchronous abort and no error events are
signaled.
This operation requires a cache lookup. Any errors found in the set that was looked up are fixed
by invalidating that line and, if the address in question is found in the set, it is invalidated.
This operation cannot generate an asynchronous abort. Any detected error is signaled with the
appropriate event.
This operation requires a cache lookup. Any correctable errors found in the set that was looked
up are fixed and, if the address in question is found in the set, it is invalidated.
Any uncorrectable errors cause an asynchronous abort. An asynchronous abort can also be
raised on a correctable error if aborts on RAM errors are enabled in the Auxiliary Control
Register.
This operation does not require a cache lookup. It refers to a particular cache line.
The entry at the given set/way is marked as invalid regardless of any errors. This operation
cannot generate an asynchronous abort. Any detected error is signaled with the appropriate
event.
This operation requires a cache lookup. Any correctable errors found in the set that was looked
up are fixed and, if the address in question is found in the set, the instruction carries on with the
clean operation. When the tag lookup is done, the dirty RAM is checked.
Note
When force write-through is enabled, the dirty bit is ignored.
If the tag or dirty RAM has an uncorrectable error, the data is not written to memory.
If the line is dirty, the data is written back to external memory. If the data has an uncorrectable
error, the words with the error have their WSTRBMm AXI signal deasserted. If there is a
correctable error, the line has the error corrected inline before it is written back to memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-24
ID092411 Non-Confidential
Level One Memory System
Any uncorrectable errors cause an asynchronous abort. An asynchronous abort can also be
raised on a correctable error if aborts on RAM errors are enabled in the Auxiliary Control
Register.
This operation does not require a cache lookup. It refers to a particular cache line.
The tag and dirty RAMs for the cache line are checked.
Note
When force write-through is enabled, the dirty bit is ignored.
If the tag or dirty RAM has an uncorrectable error, the data is not written to memory.
If the line is dirty, the data is written back to external memory. If the data has an uncorrectable
error, the words with the error have their WSTRBMm AXI signal deasserted. If there is a
correctable error, the line has the error corrected inline before it is written back to memory.
Any uncorrectable errors found cause an asynchronous abort. An asynchronous abort can also
be raised on a correctable error if aborts on RAM errors are enabled in the Auxiliary Control
Register.
This operation requires a cache lookup. Any correctable errors found in the set that was looked
up are fixed and, if the address in question is found in the set, the instruction carries on with the
clean and invalidate operation. When the tag lookup is done, the dirty RAM is checked.
Note
When force write-through is enabled, the dirty bit is ignored.
If the tag or dirty RAM has an uncorrectable error, the data is not written to memory.
If the line is dirty, the data is written back to external memory. If the data has an uncorrectable
error, the words with the error have their WSTRBMm AXI signal deasserted. If there is a
correctable error, the line has the error corrected inline before it is written back to memory.
Any uncorrectable errors found cause an asynchronous abort. An asynchronous abort can also
be raised on a correctable error if aborts on RAM errors are enabled in the Auxiliary Control
Register.
This operation does not require a cache lookup. It refers to a particular cache line.
The tag and dirty RAMs for the cache line are checked.
Note
When force write-through is enabled, the dirty bit is ignored.
If the tag or dirty RAM has an uncorrectable error, the data is not written to memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-25
ID092411 Non-Confidential
Level One Memory System
If the line is dirty, the data is written back to external memory. If the data has an uncorrectable
error, the words with the error have their WSTRBMm AXI signal deasserted. If there is a
correctable error, the line has the error corrected inline before it is written back to memory.
Any uncorrectable errors found cause an asynchronous abort. An asynchronous abort can also
be raised on a correctable error if aborts on RAM errors are enabled in the Auxiliary Control
Register.
Coherency maintenance operations are issued to the data cache controller when the ACP
processes coherent write transactions. See Accelerator Coherency Port interface on page 9-53
for more information on the ACP.
These operations require data cache lookups. Any correctable errors found in the set that was
looked up are fixed and, if the address is found in the set and not marked as dirty, it is
invalidated.
Tag RAM
The tag RAMs consist of four ways of up to 512 lines. The width of the RAM depends on the
build options selected, and the size of the cache. The following tables show the tag RAM bits:
• Table 8-4 shows the tag RAM bits when parity is implemented
• Table 8-5 shows the tag RAM bits when ECC is implemented
• Table 8-6 on page 8-27 shows the tag RAM bits when neither parity nor ECC is
implemented.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-26
ID092411 Non-Confidential
Level One Memory System
A cache line is marked as valid by bit [22] of the tag RAM. Each valid bit is associated with a
whole cache line, so evictions always occur on the entire line.
Table 8-7 shows the tag RAM cache sizes and associated RAM organization, assuming no parity
or ECC. For parity, the width of the tag RAMs must be increased by one bit. For ECC, the width
of the tag RAMs must be increased by seven bits.
Dirty RAM
For the data cache only, the dirty RAM stores the following information:
• two bits for line outer attributes for evictions
• one line dirty bit
• four ECC code bits if the ECC build option is selected.
The dirty RAM array consists of one bank of up to 512 12-bit lines, 4 ways x 3 bits. If ECC is
enabled, the dirty RAM is 28 bits wide. Each line of dirty RAM contains all the information of
the four ways for a given index.
Each time a dirty bit is written, the outer bits of the line and, if implemented, the ECC code bits,
are also written. The dirty RAM is bit-enabled. Table 8-8 shows the organization of a dirty RAM
line.
Bits [2:1] Outer attributes that are re-encoded on AWCACHEMm when an eviction is sent to the AXI bus:
01 = WB, WA
10 = WT
11 = WB, no WA
00 = Non-cacheable.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-27
ID092411 Non-Confidential
Level One Memory System
Data RAM
Data RAM is organized as eight banks of 32-bit wide lines, or in the instruction cache as four
banks of 64-bit wide lines. This RAM organization means that it is possible to:
• Perform a cache look-up with one RAM access, all banks selected together. This is done
for nonsequential read operations. Figure 8-3 shows this.
• Select the appropriate bank RAM for sequential read operations. Figure 8-4 shows this.
• Write a line to the eviction buffer in one cycle, a 256-bit read access.
• Fill a line in one cycle from the linefill buffer, a 256-bit write access.
Figure 8-3 shows a cache look-up being performed on all banks with one RAM access.
RAM address
3 Way 1 Way 1 Way 2 Way 2 Way 3 Way 3 Way 0 Way 0
Word 6 Word 7 Word 6 Word 7 Word 6 Word 7 Word 6 Word 7
256-bit wide
Figure 8-3 Nonsequential read operation performed with one RAM access.
Figure 8-4 shows the appropriate bank RAM being selected for a sequential read operation.
RAM address
3 Way 1 Way 1 Way 2 Way 2 Way 3 Way 3 Way 0 Way 0
Word 6 Word 7 Word 6 Word 7 Word 6 Word 7 Word 6 Word 7
Figure 8-4 Sequential read operation performed with one RAM access
The data RAM organization is optimized for 64-bit read operations, because with the same
address, two words on the same way can be selected.
Data RAM sizes depend on the build option selected, and are described in:
• Data RAM sizes without parity or ECC implemented on page 8-29
• Data RAM sizes with parity implemented on page 8-29
• Data RAM sizes with ECC implemented on page 8-30.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-28
ID092411 Non-Confidential
Level One Memory System
Table 8-9 shows the organization for instruction and data caches when neither parity nor ECC
is implemented.
Table 8-11 shows the organization for instruction and data caches when parity is implemented.
For parity error detection, one bit is added per byte, so four bits are added for each RAM bank.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-29
ID092411 Non-Confidential
Level One Memory System
Table 8-13 shows the organization of the data cache RAM bits when parity is implemented.
Parity bits are grouped together in bits[35:32] so that data and parity bits are easily
differentiated. With this design the parity bit is selected alongside the related data byte, so that
when data is updated, the parity bit is also updated.
Table 8-14 shows the organization for the instruction cache when ECC is implemented. For
ECC error detection, eight bits are added per 64 bits, so four bits are added for each RAM bank.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-30
ID092411 Non-Confidential
Level One Memory System
Table 8-15 shows the organization for the data cache when ECC is implemented. For ECC error
detection, seven bits are added per 32 bits, so seven bits are added for each RAM bank.
Table 8-16 shows the organization of the data cache RAM bits when ECC is implemented.
This section describes how to enable or disable the cache RAMs, and to enable or disable error
checking. After you enable or disable the instruction cache, you must issue an ISB instruction to
flush the pipeline. This ensures that all subsequent instruction fetches see the effect of enabling
or disabling the instruction cache.
After reset, you must invalidate each cache before enabling it.
When disabling the data cache, you must clean the entire cache to ensure that any dirty data is
flushed to L2 memory.
Before enabling the data cache, you must invalidate the entire data cache if L2 memory might
have changed since the cache was disabled.
Before enabling the instruction cache, you must invalidate the entire instruction cache if L2
memory might have changed since the cache was disabled.
See Enabling or disabling AXI slave accesses on page 9-24 and Accessing RAMs using the AXI
slave interface on page 9-25 for information about how to access the cache RAMs using the
AXI slave interface.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-31
ID092411 Non-Confidential
Level One Memory System
Software must take care when changing the error checking bits in the Auxiliary Control
Register. If the bits are changed when the caches contain data, the parity or ECC bits in the
caches might not be correct for the new setting, resulting in unexpected errors and data loss.
Therefore the bits in the Auxiliary Control Register must only be changed when both caches are
turned off and the entire cache must be invalidated after the change.
The following code is the sequence ARM recommends to perform the change:
MRC p15, 0, r0, c1, c0, 0 ; Read System Control Register
BIC r0, r0, #0x1 << 2 ; Disable data cache bit
BIC r0, r0, #0x1 << 12 ; Disable instruction cache bit
DSB
MCR p15, 0, r0, c1, c0, 0 ; Write System Control Register
ISB ; Ensures following instructions are not executed from cache
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-32
ID092411 Non-Confidential
Level One Memory System
; Clean entire data cache. This routine depends on the data cache size. It can be
omitted if it is known that the data cache has no dirty data, for example if the cache
has not been enabled yet.
MRC p15, 0, r1, c1, c0, 1 ; Read Auxiliary Control Register
; Change bits 5:3 as required
MCR p15, 0, r1, c1, c0, 1 ; Write Auxiliary Control Register
MCR p15, 0, r0, c15, c5, 0 ; Invalidate entire data cache
MCR p15, 0, r0, c7, c5, 0 ; Invalidate entire instruction cache
MRC p15, 0, r0, c1, c0, 0 ; Read System Control Register
ORR r0, r0, #0x1 << 2 ; Enable data cache bit
ORR r0, r0, #0x1 << 12 ; Enable instruction cache bit
DSB
MCR p15, 0, r0, c1, c0, 0 ; Write System Control Register
ISB
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-33
ID092411 Non-Confidential
Level One Memory System
When a load-exclusive access is performed, the internal exclusive monitor moves to the
exclusive state. It moves back to the open state when a store exclusive access or clear exclusive
instruction is performed. The internal exclusive monitor holds exclusivity state for an individual
Cortex-R5 CPU only. It does not record the address of the memory that a load-exclusive access
was performed to and it does not observe accesses from the other CPU in a twin-CPU group.
Any store exclusive access performed when the state is open fails. If the state is exclusive, the
access passes if it is to non-shared memory but, if it is to shared memory, the access must be
performed as an exclusive using the L2 memory interface. Whether the shared store-exclusive
access passes or fails depends on the state of an external exclusive monitor that can track
accesses made by other processors in the system.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-34
ID092411 Non-Confidential
Level One Memory System
• Only Normal, non-shared memory regions can be cached in the RAMs. Caching only
takes place if the appropriate cache is enabled and the memory type is Cacheable.
• The store buffer can merge any stores to Normal memory. See Store buffer on page 8-18
for more information.
• Only Normal memory is considered restartable, that is, a multi-word transfer can be
abandoned part way through because of an interrupt, to be restarted after the interrupt has
been handled. See Interrupts on page 3-19 for more information about interrupt behavior.
• Only the internal exclusive monitor is used for exclusive accesses to Non-shared memory.
Exclusive accesses to shared memory are checked using the internal monitor and also, if
necessary, any external monitor, using the L2 memory interface.
• Accesses resulting from SWP and SWPB instructions to Normal, non-shared memory are not
marked as locked when performed using the L2 memory interface.
Note
Not all types of exclusive or swap access are permitted to peripheral interface regions. See
Semaphores on page 9-52.
Table 8-17 summarizes the processor memory types and associated behavior.
Memory type Can be cached Merging Restartable Internal exclusives Locked swaps
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-35
ID092411 Non-Confidential
Level One Memory System
TCM ECC error events are only signaled for TCM reads, although this includes the
read-modify-write sequence performed for some stores. Most errors detected by the ECC logic
are signaled twice:
• once on a TCM-centric event
• once on a processor-centric event.
The TCM-centric events consist of two events per TCM port, one for fatal, that is, 2-bit ECC
errors and one for correctable, that is, 1-bit ECC errors. These events are generated three clock
cycles after the data read cycle. Consequently, these events are sometimes signaled on
speculative TCM reads, such as instructions that are prefetched but never executed because of
a branch earlier in the instruction sequence.
Note
When an external error is signaled on a TCM access, the TCM-centric events are still generated
as appropriate, based on the data returned, as if no external error had been signaled.
The processor-centric TCM events are only signaled for errors in data that would have otherwise
been used by the processor. Errors on speculative reads never generate these errors. They consist
of fatal and correctable events for:
• the prefetch unit, to signal errors on instruction fetches
• the load/store unit, to signal errors on data accesses
• the AXI slave interface, to signal errors on DMA accesses.
All parity and ECC errors are correctable in the I-Cache. Therefore there are only two events,
to indicate when an error is detected in a read from the tag RAM, or from the data RAM. These
events are only signaled for non-speculative instruction fetches and certain cache maintenance
operations. See Cache error detection and correction on page 8-20.
The D-Cache can generate fatal and correctable errors, and therefore has four events, one for
each type of error in the data RAM and in the tag or dirty RAMs. These events are only signaled
for non-speculative data accesses, cache line evictions, coherency maintenance operations, and
certain cache maintenance operations. See Cache error detection and correction on page 8-20.
The Correctable Fault Location Register (CFLR) records the location of the last correctable
error detected on a non-speculative access or coherency maintenance operations. See
Correctable Fault Location Register on page 4-77 for more information. Every correctable error
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-36
ID092411 Non-Confidential
Level One Memory System
that is recorded in the CFLR also generates an event. See Table 6-1 on page 6-2 to see which
events are CFLR-related. For correctable cache errors, the CLFR does not record whether the
error occurred in the data RAM or tag/dirty RAM. This distinction is only made by the events.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 8-37
ID092411 Non-Confidential
Chapter 9
Level Two Interface
This chapter describes the features of the Level two (L2) interface not covered in the AMBA AXI
Protocol Specification. It contains the following sections:
• About the L2 interface on page 9-2
• AXI master interface on page 9-5
• AXI master interface transfers on page 9-8
• AXI slave interface on page 9-21
• Enabling or disabling AXI slave accesses on page 9-24
• Accessing RAMs using the AXI slave interface on page 9-25
• Peripheral interfaces on page 9-36
• Accelerator Coherency Port interface on page 9-53.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-1
ID092411 Non-Confidential
Level Two Interface
The processor is designed for use in larger chip designs using the Advanced Microcontroller Bus
Architecture (AMBA) AXI and AHB protocols. Instruction fetches and data accesses that the
L1 memory system does not service, and peripheral accesses, are performed through the
AXI-master interface or one of the peripheral interfaces. See:
• AXI master interface on page 9-5 for more information about the AXI master interface
• AXI peripheral port transfers on page 9-39 for more information about the AXI peripheral
interface
• AHB peripheral port transfers on page 9-46 for more information about the AHB
peripheral interface.
External AXI masters, that can include the processor itself, can use the AXI slave interface to
access the processor RAMs. You can use the AXI slave interface for DMA access into and out
of the TCMs or to perform software test of the cache RAMs. See AXI slave interface on
page 9-21.
The ACP interface enables the Cortex-R5 processor to observe memory transactions that other
AXI masters perform, and keep the L1 caches coherent with those transactions. See Accelerator
Coherency Port interface on page 9-53 for more information about the ACP interface.
You can configure all of the ports associated with the L2 interfaces with bus-ECC. The bus-ECC
feature uses additional signals to communicate redundant information, enabling the detection or
correction of errors that occur on the bus signals. See Bus ECC for more information.
ARM recommends that the memory regions you configure for ATCM, BTCM, the AXI
peripheral port, and the AHB peripheral port do not overlap. However, if one or more regions
do overlap, the processor uses the following priority scheme to determine which interface is
accessed:
1. ATCM (highest priority)
2. BTCM
3. AXI peripheral port
4. AHB peripheral port
5. AXI-M (lowest priority)
The processor also uses this scheme to decide which interface is accessed when any of the
interfaces are disabled. For example, accessing the PP AXI region when the LLPP AXI
interface is disabled results in an access to the AXI-M interface, assuming the address is not in
the LLPP AHB region.
You can configure a Cortex-R5 processor with bus ECC to protect the integrity of AMBA bus
signals. The bus ECC feature of the Low Latency Peripheral Port is configured separately from
the other bus interfaces.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-2
ID092411 Non-Confidential
Level Two Interface
Bus ECC uses both parity and Single Error Correct Double Error Detect (SEC-DED) Error
Correcting Codes (ECC). The Cortex-R5 processor computes and checks parity bits as odd or
even, depending on the value of the PARITYLEVEL primary input, except for AXI handshake
signals that have fixed, odd parity.
ECC and parity errors, detected by the Cortex-R5 processor, do not directly cause aborts,
exceptions or otherwise affect the CPU operation. Instead, event primary outputs notify the
system of correctable or fatal errors. The CPU treats all bus control and response signals as
correct, even if parity errors are reported. It is possible that fatal, that is double-bit, ECC errors
might cause more data corruption. This can result in the CPU operating on corrupted data, or
behaving unpredictably, based on corrupted control or response signals.
Bus ECC functionality checks for errors on every bus transfer the CPU performs. This can
include speculative accesses for which data is later discarded. The CPU:
• reports bus faults for all transfers whose data it uses
• never reports bus data faults for transfers where the bus master sees an error response.
AXI Interfaces
The Cortex-R5 processor uses the following scheme to protect AXI signals:
• Parity on address and control payload signals. Each parity bit protects a maximum of eight
payload bits.
AHB Interfaces
The Cortex-R5 processor uses the following scheme to protect AHB signals:
• Parity on address and control signals. Each parity bit protects a maximum of eight payload
bits
Notifications
• Correctable errors on read data received by the AXI Master and Peripheral Port, through
primary outputs.
• Correctable errors on write data received by the AXI Slave through a primary output.
• Memory chip select and logical address of transfers with correctable errors on the AXI
Slave, to doubleword granularity.
• Fatal errors on AXI ports using one primary output bit per channel per port.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-3
ID092411 Non-Confidential
Level Two Interface
• A correctable bus fault event in the event bus, EVNTBUSm. See About the events on
page 6-2.
• A fatal bus fault event in the event bus, EVNTBUSm. See About the events on page 6-2.
• Increments to correctable and fatal bus fault event counters for the Performance
Monitoring Unit (PMU). See About the events on page 6-2.
The Cortex-R5 event bus and PMU logic monitors bus fault events on all Cortex-R5 AXI and
AHB interfaces simultaneously. It merges bus faults that occur in the same CPU clock cycle, on
different bus interfaces. For example, if correctable errors occur on both the AXI master and
AXI slave, in the same CPU clock cycle, only one event is logged.
The Cortex-R5 processor has one primary output for reporting the logical address of a transfer
with a correctable error, on the AXI master port, or the AXI and AHB Peripheral Ports.
Concurrent correctable bus faults on the AXI master and the Peripheral Port cause the address
to be reported for the AXI master only. Correctable errors do not occur concurrently on the AHB
and AXI Peripheral Ports, see Peripheral interfaces on page 9-36 for more information about
the Cortex-R5 Peripheral Port.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-4
ID092411 Non-Confidential
Level Two Interface
The port is 64 bits wide, and conforms to the AXI3 standard as described in the AMBA AXI
Protocol Specification. Within the AXI standard, the master port uses a number of extension
signals to indicate inner memory attributes and, if configured with bus-ECC, parity or ECC
information. See AXI extensions on page 9-7 for more information about attribute encodings and
Bus ECC on page 9-2 for more information about bus-ECC.
The master interface can run at the same frequency as the processor or at a lower synchronous
frequency. See AMBA interface clocking on page 2-16 for more information.
Note
References in this section to an AXI slave refer to the AXI slave in the external system that is
connected to the Cortex-R5 AXI master port. This is not necessarily the Cortex-R5 AXI slave
port.
The following sections describe the attributes of the AXI master interface, and provide
information about the types of burst generated:
• Identifiers for AXI bus accesses on page 9-6
• Write response on page 9-6
• Linefill buffers and the AXI master interface on page 9-6
• Eviction buffer on page 9-7
• AXI extensions on page 9-7.
• Memory system implications for AXI accesses on page 9-7.
Write issuing capability 4 Made up of four outstanding writes that can be evictions, single writes, or write bursts.a
Read issuing capability 7 Made up of five linefills on the data side, one NC read on the data side, and one read on the
instruction side, that can be NC or linefill.
Write ID capability 2 -
Write interleave capability 1 The AXI master interface presents all write data in order.
Read ID capability 7 Made up of five linefills on the data side, one NC read on the data side, and one linefill or
NC read on the instruction side.
a. When there are three outstanding write transactions, only data is issued for the fourth. Only three outstanding write addresses are issued.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-5
ID092411 Non-Confidential
Level Two Interface
Note
• The AXI master does not generate two outstanding read accesses with the same ID.
• The AXI master does not interleave write data from two different bursts, even if the bursts
have different IDs.
The AXI master requires that the slave does not return a write response until it has received both
the write data and the write address.
On the data side there are two LineFill Buffers (LFBs), LFB0 and LFB1. Each request from the
data cache controller or from the STore Buffer (STB) can be allocated to either LFB0 or LFB1.
On the instruction side, there is one LFB. This is the Instruction LFB (ILFB), that treats
instruction linefill requests or Non-cacheable instruction reads in the same way.
The LFBs are 256 bits wide so that an entire cache line can be written to the cache RAMs in one
cycle. While the LFB is being filled from L2 memory, its bytes can be merged with write data
from the STB.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-6
ID092411 Non-Confidential
Level Two Interface
As soon as a linefill is requested, the selected evicted cache line is loaded into the EViction
Buffer (EVB). The EVB forwards this information to the AXI bus when possible.
The EVB has a structure of 256 bits for data and 32 bits for the address. See Cache line
write-back (eviction) on page 9-14 for more information about the AXI transaction generated.
The EVB is removed if cache RAMs are not implemented for the processor.
The Cortex-R5 AXI master interface uses the ARCACHEMm, AWCACHEMm, AXI signals
and the ARSHAREMm, AWSHAREMm, ARINNERMm, and AWINNERMm extension
signals to indicate the memory attributes of the transfer, as returned by the MPU. Table 9-2
shows the encodings used for these signals. ARCACHEMm and AWCACHEMm of the
master interface are generated from the memory type and outer region attributes.
ARINNERMm and AWINNERMm are generated from the memory type and inner region
attributes. ARSHAREMm and AWSHAREMm are asserted for transactions to shared
memory regions.
Encodinga Meaning
b0001 Device
b0011 Non-cacheable
Additional AXI extension signals on all the AXI master channels are used for bus-ECC and
parity information.
The attributes of the memory being accessed can affect an AXI access. The L1 memory system
can cache any Normal memory address that is marked as either:
• Cacheable, write-back, read- and write-allocate, non-shared
• Cacheable, write-through, read-allocate only, non-shared.
However, Device and Strongly Ordered memory is always Non-cacheable. Also, any unaligned
access to Device or Strongly Ordered memory generates an alignment fault and therefore does
not cause any AXI transfer. This means that the access examples given in this chapter never
show unaligned accesses to Device or Strongly Ordered memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-7
ID092411 Non-Confidential
Level Two Interface
This section also contains tables that show some examples of the types of AXI burst that the
processor generates. However, because a particular type of transaction is not shown here does
not mean that the processor does not generate such a transaction.
Note
An AXI slave device connected to the Cortex-R5 AXI master port must be capable of handling
every kind of transaction permitted by the AXI specification, except where there is an explicit
statement in this chapter that such a transaction is not generated. You must not infer any
additional restrictions from the example tables given. Restrictions described here apply to the
r0p0 to r1p1revisions of the processor, but might not be true for future revisions.
Load and store instructions to Non-cacheable memory might not result in an AXI transfer
because the data might either be retrieved from, or merged into the internal store data buffers.
The exceptions to this are loads or stores to Strongly Ordered or Device memory. These always
result in AXI transfers. See Strongly Ordered and Device transactions on page 9-9.
Restrictions on AXI transfers on page 9-9 describes restrictions on the type of transfers that the
Cortex-R5 AXI master interface generates. If a CPUm exists and is powered up, the buffered
write response and read data channel ready signals, BREADYMm and RREADYMm, are
always asserted. They are, however, deasserted when the CPU enters Dormant or Shutdown
mode. You must not make any other assumptions about the AXI handshaking signals, except
that they conform to the AMBA AXI Protocol Specification.
The following sections give examples of transfers generated by the AXI master interface:
• Restrictions on AXI transfers on page 9-9
• Strongly Ordered and Device transactions on page 9-9
• Linefills on page 9-14
• Cache line write-back (eviction) on page 9-14
• Non-cacheable reads on page 9-14
• Non-cacheable or write-through writes on page 9-16
• AXI transaction splitting on page 9-17
• Normal write merging on page 9-18.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-8
ID092411 Non-Confidential
Level Two Interface
The Cortex-R5 AXI master interface applies the following restrictions to the AXI transactions
it generates:
• No transaction ever crosses a 32-byte boundary in memory. See AXI transaction splitting
on page 9-17.
• The write address channel always issues INCR type bursts, and never WRAP or FIXED.
• If the transfer size is 8 bits or 16 bits then the burst length is always 1 transfer.
• The transfer size is never greater than 64 bits, because it is a 64-bit AXI bus.
• Instruction fetches, identified by ARPROT[2], are always a 64 bit transfer size, and never
locked or exclusive.
• Transactions to Device and Strongly Ordered memory are always to addresses that are
aligned for the transfer size. See Strongly Ordered and Device transactions.
• Exclusive and Locked accesses are always to addresses that are aligned for the transfer
size.
• In addition to these restrictions, there are various limitations to the ID values that the AXI
master interface uses. See Identifiers for AXI bus accesses on page 9-6.
A load or store instruction to or from Strongly Ordered or Device memory always generates
AXI transactions of the same size as implied by the instruction. All accesses using LDM, STM, LDRD,
or STRD instructions to Strongly Ordered or Device memory occur as 32-bit transfers.
LDRB
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-9
ID092411 Non-Confidential
Level Two Interface
LDRH
Note
A load of a halfword from Strongly Ordered or Device memory addresses 0x1, 0x3, 0x5, or 0x7
generates an alignment fault.
Note
A load of a word from Strongly Ordered or Device memory addresses 0x1, 0x2, 0x3, 0x5, 0x6, or
0x7 generates an alignment fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-10
ID092411 Non-Confidential
Level Two Interface
Note
A load-multiple from address 0x1, 0x2, 0x3, 0x5, 0x6, 0x7, 0x9, 0xA, 0xB, 0xD, 0xE, or 0xF generates
an alignment fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-11
ID092411 Non-Confidential
Level Two Interface
STRB
STRH
Note
A store of a halfword to Strongly Ordered or Device memory addresses 0x1, 0x3, 0x5, or 0x7
generates an alignment fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-12
ID092411 Non-Confidential
Level Two Interface
Note
A store of a word to Strongly Ordered or Device memory addresses 0x1, 0x2, 0x3, 0x5, 0x6, or
0x7 generates an alignment fault.
Note
A store-multiple to address 0x1, 0x2, 0x3, 0x5, 0x6, or 0x7 generates an alignment fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-13
ID092411 Non-Confidential
Level Two Interface
9.3.3 Linefills
Loads and instruction fetches from Normal, Cacheable memory that do not hit in the cache
generate a cache linefill when the appropriate cache is enabled. Table 9-11 shows the values of
ARADDRMm, ARBURSTMm, ARSIZEMm, and ARLENMm for cache linefills.
a. These are the bottom five bits of the address of the access that cause the linefill, that is, the
address of the critical word.
When a valid and dirty cache line is evicted from the d-cache, a write-back of the data must
occur. Table 9-12 shows the values of AWADDRMm, AWBURSTMm, AWSIZEMm, and
AWLENMm for cache line write-backs, over the AXI master interface.
Load instructions accessing Non-cacheable Normal memory generate AXI bursts that are not
necessarily the same size or length as the instruction implies. In addition, if the data to be read
is contained in the store buffer, the instruction might not generate an AXI read transaction at all.
The tables in this section give examples of the types of AXI transaction that might result from
various load instructions, accessing various addresses in Non-cacheable Normal memory. They
are provided as examples only, and are not an exhaustive description of the AXI transactions.
Depending on the state of the processor, and the timing of the accesses, the actual bursts
generated might have a different size and length to the examples shown, even for the same
instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-14
ID092411 Non-Confidential
Level Two Interface
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-15
ID092411 Non-Confidential
Level Two Interface
Store instructions to Non-cacheable or write-through Normal memory generate AXI bursts that
are not necessarily the same size or length as the instruction implies. The AXI master port
asserts byte-lane-strobes, WSTRBMm[7:0], to ensure that only the bytes that were written by
the instruction are updated.
The tables in this section give examples of the types of AXI transaction that might result from
various store instructions, accessing various addresses in Non-cacheable Normal memory. They
are provided as examples only, and are not an exhaustive description of the AXI transactions.
Depending on the state of the processor, and the timing of the accesses, the actual bursts
generated might have a different size and length to the examples shown, even for the same
instruction.
In addition, write operations to Normal memory can be merged to create more complex AXI
transactions. See Normal write merging on page 9-18 for examples.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-16
ID092411 Non-Confidential
Level Two Interface
The processor splits AXI bursts when it accesses addresses across a cache line boundary, that
is, a 32-byte boundary. An instruction that accesses memory across one or two 32-byte
boundaries generates two or three AXI bursts respectively. The following examples show this
behavior. They are provided as examples only, and are not an exhaustive description of the AXI
transactions. Depending on the state of the processor, and the timing of the accesses, the actual
bursts generated might have a different size and length to the examples shown, even for the same
instruction.
For example, LDMIA R10, {R0-R5} loads six words from memory. The number of AXI
transactions generated by this instruction depends on the base address, R10:
• If all six words are in the same cache line, there is a single AXI transaction. For example,
for LDMIA R10, {R0-R5} with R10 = 0x1008, the interface might generate a burst of three,
64-bit read transfers, as shown in Table 9-18.
Table 9-18 AXI transaction splitting, all six words in same cache line
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-17
ID092411 Non-Confidential
Level Two Interface
• If the data comes from two cache lines, then there are two AXI transactions. For example,
for LDMIA R10, {R0-R5} with R10 = 0x1010, the interface might generate one burst of two
64-bit reads, and one burst of a single 64-bit read, as shown in Table 9-19.
The STB can detect when it contains more than one write request to the same cache line for
write-through Cacheable or Non-cacheable Normal memory. This means it can combine the
data from more than one instruction into a single write burst to improve the efficiency of the
AXI port. If the AXI master receives several write requests that do not form a single contiguous
burst it can choose to output a single burst, with the WSTRBW signal low for the bytes that do
not have any data.
For write accesses to Normal memory, the STB can perform writes out of order, if there are no
address dependencies. It can do this to best use its ability to merge accesses.
The instruction sequence in Example 9-1 on page 9-19 shows the merging of writes.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-18
ID092411 Non-Confidential
Level Two Interface
If the memory at address 0x4000 is marked as Strongly Ordered or Device type memory, the AXI
transactions shown in Table 9-22 are generated.
Table 9-22 AXI transactions for Strongly Ordered or Device type memory
In Example 9-1, each store instruction produces an AXI burst of the same size as the data written
by the instruction.
Table 9-23 shows a possible resulting transaction if the same memory is marked as
Non-cacheable Normal, or Cacheable write-through.
In this example:
• The store buffer has merged the STRB and STRH writes into one buffer entry, and therefore
a single AXI transfer, the fourth in the burst.
• The writes, that occupy three buffer entries, have been merged into a single AXI burst of
four transfers.
• The write generated by the STR instruction has not occurred, because it was overwritten by
the STM instruction.
• The write transfers have occurred out of order with respect to the original program order.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-19
ID092411 Non-Confidential
Level Two Interface
The transactions shown in Table 9-23 on page 9-19 show this behavior. They are provided as
examples only, and are not an exhaustive description of the AXI transactions. Depending on the
state of the processor, and the timing of the accesses, the actual bursts generated might have a
different size and length to the examples shown, even for the same instruction.
If the same memory is marked as write-back Cacheable, and the addresses are allocated into a
cache line, no AXI write transactions occur until the cache line is evicted and performs a
write-back transaction. See Cache line write-back (eviction) on page 9-14.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-20
ID092411 Non-Confidential
Level Two Interface
The external AXI system must generate the chip select signals. The slave interface routes the
access to the required RAM.
If the processor is configured with bus-ECC, extension signals are also used for parity and ECC
information. See Bus ECC on page 9-2 for more information about bus-ECC.
The slave interface can run at the same frequency as the processor or at a lower, synchronous
frequency. See AMBA interface clocking on page 2-16 for more information. If asynchronous
clocking is required, then an external asynchronous AXI register slice is required.
The AXI slave provides access to the TCMs and competes for access to the TCMs with the LSU
and PFU. Both the LSU and PFU normally have a higher priority than the AXI slave.
If two BTCM ports are used, you can configure these to interleave in the address map, so any
AXI slave access that is denied access to the BTCM on the first cycle of the access gains access
on the second cycle when the LSU is using the other port, and can continue in lock-step with the
LSU, assuming both are accessing sequential data. Accesses to the ATCM are more likely to
encounter a conflict because there is only one port on the interface.
Memory BIST ports are routed through the AXI slave interface logic, to access the RAMs.
Memory BIST access is assumed only to occur when no other accesses are taking place, and
takes highest priority.
Note
You must not use the AXI slave to access the cache RAMs at the same time as the ACP. Ensure
the ACP is idle before initiating AXI slave transactions to the cache RAMs.
You can use the AXI slave for software testing of the cache RAMs in functional mode. When
the AXI slave is enabled to access the RAMs, the processor considers the caches as cache-off,
so that the instruction and data requests cannot interact with AXI slave requests. In this state,
only AXI slave requests can access the cache RAM and instruction and data requests from the
processor are considered as non-cacheable and do not perform any lookup in the caches.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-21
ID092411 Non-Confidential
Level Two Interface
A simple decode of four address bits and four way address bits determines which of the data,
tag, or dirty RAMs is accessed within the caches. The AXI access is given a SLVERR error
response when access to nonexistent cache RAM is indicated.
The TCMs can support ECC, as described in TCM internal error detection and correction on
page 8-14. If a write transaction is issued to the AXI slave, the slave interface calculates the
required ECC bits to store to the TCM. If the write data width is smaller than the ECC chunk
size then a read-modify-write sequence is automatically performed by the AXI slave.
Note
It is important to ensure that all writes to TCMs that do not contain the correct ECC bits for their
data, such as uninitialized RAMs, are performed with a size of at least the ECC chunk size or
with error checking disabled.
If a read transaction is issued to the AXI slave, the slave interface reads the ECC bits and, if
error checking is enabled for the appropriate TCM, checks the data for errors. If the interface
detects a correctable error, it corrects it inline and returns the correct data on the AXI bus. It does
not update the data in the TCM to correct it. If the interface detects an uncorrectable error, it
generates a SLVERR error response to the AXI transaction.
If an error response is given to a TCM access from the AXI slave interface, and external errors
are enabled for the appropriate TCM port, the AXI slave returns a SLVERR response to the AXI
transaction.
The AXI slave ignores late-error and retry responses from the TCM.
When the caches support parity or ECC, the AXI slave interface permits direct read and write
access to the parity or ECC code bits. No errors are detected automatically, and on writes the
AXI slave does not automatically generate the correct parity or ECC code values.
Note
The AXI slave interface provides read/write access to the cache RAMs for functional test. It is
not suitable for preloading the caches.
By default, both privileged and non-privileged accesses can be made to the Cortex-R5 TCM
RAMs through the AXI slave port. To disable non-privileged accesses, you can set bit [1] in the
Slave Port Control Register. You can disable all slave accesses by setting bit [0] of the register.
See c11, Slave Port Control Register on page 4-65.
Access to the cache RAMs can only be made when bit [24] of the Auxiliary Control Register is
set. By default, only privileged accesses can be made to the cache RAMs, but you can enable
non-privileged accesses by setting bit [23] of the Auxiliary Control Register. When cache RAM
access is enabled, both caches are treated as if they were not enabled. See c1, Auxiliary Control
Register on page 4-41.
The AXI access is given a SLVERR error response when access is not permitted.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-22
ID092411 Non-Confidential
Level Two Interface
This section describes the capabilities of the AXI slave interface, and the attributes of its AXI
port. You must not make any other assumptions about the behavior of the AXI slave port except
that it conforms to the AMBA AXI 3 Protocol Specification.
• The AXI slave interface supports merging of data within bursts. When handling an AXI
burst of data less than 64-bits wide, the AXI slave interface attempts to perform the
minimum number of TCM or cache accesses required to read or write the data. When an
ECC error scheme is in use, this sometimes reduces the number of read-modify-write
sequences that the AXI slave must perform.
• The AXI slave interface has no exclusive access monitor. If there are any exclusive
accesses, the AXI slave interface responds with an OKAY response.
• The width of the ID signals for the AXI slave port is 8 bits.
You must avoid building the processor into an AXI system that requires more than 8 bits
of ID. The number of bits of ID required by a system can often be reduced by compressing
the encoding to remove unused values. The AXI master port does not use all possible
values. See Identifiers for AXI bus accesses on page 9-6 for more information.
Write interleave depth 1 All write data must be presented to the AXI slave interface in order
Read data reorder depth 1 The AXI slave interface returns all read data in order, even if the bursts
have different IDs
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-23
ID092411 Non-Confidential
Level Two Interface
The following code is an example of enabling AXI slave accesses to the cache RAMs:
MRC p15, 0, R1, c1, c0, 1 ; Read Auxiliary Control Register
ORR R1, R1, #0x1 <<24
; Ensure ACP is idle, that is. cannot access the cache and that no new ACP transactions
; can be generated
DSB
MCR p15, 0, R1, c1, c0, 1 ; enabled AXI slave accesses to the cache RAMs
ISB
; Clean entire data cache. This routine depends on the data cache size. It can be
; omitted if it is known that the data cache has no dirty data
Fetch from uncached memory
Fetch from uncached memory
Fetch from uncached memory
Fetch from uncached memory
The following code is an example of disabling AXI slave accesses to the cache RAMs. No cache
invalidation is performed because it is assumed that, after accessing the cache RAMs, the AXI
slave interface restored the previously valid data to them.
MRC p15, 0, R1, c1, c0, 1 ; Read Auxiliary Control Register
BIC R1, R1, #0x1 <<24
DSB
MCR p15, 0, R1, c1, c0, 1 ; disabled AXI slave accesses to the cache RAMs
ISB
; Re-enable ACP transactions
Fetch from cached memory
Fetch from cached memory
Fetch from cached memory
Fetch from cached memory
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-24
ID092411 Non-Confidential
Level Two Interface
Table 9-25 shows the bits of the ARCSELSm or AWCSELSm inputs, that determine the target
of a transaction. Each signal is a one-hot 4-bit input, with each bit corresponding to a particular
RAM or group of RAMs.
[0] ATCM
Note
Because AWCSELSm and AWADDRSm are similar to ARCSELSm and ARADDRSm, the
following sections describe their common features as AxCSELSm and AxADDRSm, noting
any differences between them.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-25
ID092411 Non-Confidential
Level Two Interface
AxADDRSm[22:3] indicates the address of the doubleword within the TCM that you want to
access. If you are accessing a TCM that is smaller than the maximum 8MB, then it is possible
to describe an address that is outside of the physical size of the TCM. This is not permitted and
results in a SLVERR error response.
Table 9-26 shows the decode of the AxCSELSm[3:0] signal, and the state of the address signals
for accessing different TCM RAMs. The table also shows the SLBTCMSBm configuration
input signal that determines which address bit is used to select between the banks of a
dual-banked BTCM.
Table 9-27 shows the most significant bit of the address for the different TCM RAM sizes. For
split BTCMs, the TCM size is defined to be the total size of both the B0TCM and B1TCM
combined. In this situation, the particular BTCM accessed is dependent on either
AxADDRSm[MSB], if the input SLBTCMSBm is high, or AxADDRSm[3] otherwise. For
example, if there are split BTCMs and SLBTCMSBm is LOW and AxADDRSm[3] is HIGH,
the access goes to the B1TCM.
0001 - - - - ATCM
0010 1 - - - BTCM
0010 2 0 0 - B0TCM
0010 2 0 1 - B1TCM
0010 2 1 - 0 B0TCM
0010 2 1 - 1 B1TCM
Table 9-27 MSB bit for the different TCM RAM sizes
4KB [11]
8KB [12]
16KB [13]
32KB [14]
64KB [15]
128KB [16]
256KB [17]
512KB [18]
1MB [19]
2MB [20]
4MB [21]
8MB [22]
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-26
ID092411 Non-Confidential
Level Two Interface
The TRANSFER register enables an AXI master to construct a single RAM access from
multiple sub-word accesses, that might be required if the master data width is less than the RAM
data width.
The AUX register provides access to Data RAM ECC and parity data, if implemented.
The RAM-Access region initiates all AXI-slave RAM accesses. Reads from this region return
data and update the TRANSFER and AUX registers. Writes to this region combine with the data
in the TRANSFER and AUX registers, before being committed to the RAM.
Table 9-28 on page 9-28 describes the RAM-Access memory map and Table 9-29 on page 9-29
describes the TRANSFER and AUX memory map.
Any address that is not listed in Table 9-28 on page 9-28 or addresses that are explicitly listed
as illegal returns a SLVERR.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-27
ID092411 Non-Confidential
Level Two Interface
Any fields marked as RAZ/WI refer to the RAMs. The TRANSFER and AUX registers are not
guaranteed to be RAZ/WI.
For tagbc and dirtyad RAMs:[15] = Bank 0[16] = Bank 1[17] = Bank 2[18] = Bank 3.
For tag-RAM reads, only one-hot encodings are supported.
For tag-RAM writes, all combinations are supported, the same data is written to all banks.
For dirty RAM accesses, all combinations are supported.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-28
ID092411 Non-Confidential
Level Two Interface
[22:15] 0x0
[13:4] 0x0
TRANSFER and AUX are intermediate registers that are used by the AXI slave logic to perform
RAM accesses.
Note
The physical integration of the RAMs limits the granularity of RAM accesses. This means that:
• A data chunk and its ECC or parity, if implemented, are always updated together.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-29
ID092411 Non-Confidential
Level Two Interface
• It is not possible to access part of a RAM-word unless the RAM-integration guidelines for
the processor require that the RAM itself must support this feature.
This requirement exists only for the D_Cache data RAMs and dirty RAMs, that must be
implemented by byte-writable RAMs. The AXI slave bus supports the full range of
byte-write support to this RAM only.
Writes to the RAM-Access space update TRANSFER with the write data, then use this register,
and possibly AUX, to write to the selected [Link] from the RAM-Access space read the
RAM contents into TRANSFER, and possibly AUX, and provide the requested portion of the
read data from TRANSFER on the AXI interface.
To perform accesses outside these restrictions, you must perform a read-modify-write sequence.
You can also access the TRANSFER and AUX registers directly using the TRANSFER/AUX
space. Such accesses do not actually perform RAM accesses. In this way RAM accesses are
decoupled from AXI transactions, and a single RAM access can be decomposed into, or
composed from, multiple AXI bus accesses. This enables, for example, a master capable only
of sub-word accesses to get full access to the RAMs.
All accesses to the TRANSFER and AUX registers are cumulative. This means that data written
to the TRANSFER and AUX registers, through direct AXI slave accesses, persists until it is
overwritten. Reads from the cache RAMs, occurring as a side effect of AXI slave accesses to
the RAM-Access space, also update these registers and overwrite any value previously written.
This enables easier read-modify-write (RMW) operation by the master.
The TRANSFER register enables you to transfer data and ECC to the tag and dirty RAMs, and
to transfer data to the data RAMs.
The AUX register is used only for transferring ECC to the data RAMs. If neither cache
implements parity or ECC, direct accesses to the AUX register return a SLVERR.
For writes, you must ensure that all the data to be written to the selected RAM is initialized,
either by prior accesses to TRANSFER/AUX, by the current access to RAM-Access or by a
combination of both.
You can perform writes by a variety of sequences involving the RAM-Access space, and
possibly also the TRANSFER/AUX space. For example, a write to a data RAM can be done by:
• Multiple writes to the TRANSFER register and AUX register, followed by a single write,
with potentially zeroed byte strobes, at the appropriate address to the RAM-Access space
• A single write to the AUX register, if ECC is present, followed by a single write at the
appropriate address to the RAM-Access space.
You can perform reads by a similarly varied number of sequences. For example, a read of a data
RAM can be done by:
• A single 64-bit read of the RAM-Access space followed by a single 64-bit read of the
AUX register
• A byte read of the RAM-Access space followed by several byte-reads to read the rest of
the RAM data from the TRANSFER and AUX registers.
The format of the data, for reads and writes, depends on the RAM accessed and the error
configuration of the RAM. These formats are described in the following tables. All writes must
ensure that the write data is on the correct lane. Reads return data on the lanes described.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-30
ID092411 Non-Confidential
Level Two Interface
This section applies when you are performing a single bank access.
The location from which data bits are read, or to which they are written, depends on bit [0] of
the RAM index. ECC or parity bits are written to, or read from, the lower byte of the AUX
register.
Table 9-36 on page 9-33 describes the format of the AUX register for D_Cache data RAM
accesses, when ECC is configured.
Bit Description
[63:7] RAZ/WI
[6:0] ECC32[6:0]
Table 9-37 on page 9-33 describes the format of the AUX register for data RAM, D_Cache,
when parity is configured.
Bit Description
[63:4] RAZ/WI
Table 9-38 on page 9-33 describes the format of the AUX register for data RAM, D_Cache,
when no error correction is configured.
Table 9-32 Data RAM AUX format, D_Cache, with no error correction
Bit Description
[63:0] RAZ/WI
RAM index[0] = 0
Writing The data bits used are the result of the lower word of TRANSFER multiplexed
with the lower word of the data sent to the RAM-Access space. The values of
WSTRB used for this AXI transaction determine which is multiplexed in:
WSTRB=0
data is taken from TRANSFER
WSTRB=1
data is taken from the data bus
Reading The data bits are written to the lower word of TRANSFER, and appear on the
lower word of the AXI data bus.
The upper word of TRANSFER is set to zero.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-31
ID092411 Non-Confidential
Level Two Interface
RAM index[0] = 1
Writing The data bits used are the result of the upper word of TRANSFER multiplexed
with the upper word of the data sent to the RAM-Access space. The values of
WSTRB used for this AXI transaction determine which is multiplexed in.
Reading The data bits are written to the upper word of TRANSFER, and appear on the
upper word of the AXI data bus.
Table 9-33 describes the format of the AUX register for data RAM, I-cache, when ECC is
configured.
Bit Description
[63:8] RAZ/WI
Table 9-34 describes the format of the AUX register for data RAM, I-cache, when parity is
configured.
Bit Description
[63:8] RAZ/WI
Table 9-35 describes the format of the AUX register for data RAM, I-cache, when no error
correction is configured.
Bit Description
[63:0] RAZ/WI
This section applies when you are performing a normal, or strobed, double bank access.
Normal accesses read or write all bytes of the doubleword being transferred. Strobed accesse
read or write only those bytes specified by the corresponding bit in WSTRB. See Table 9-7 on
page 9-12
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-32
ID092411 Non-Confidential
Level Two Interface
Table 9-36 describes the format of the AUX register for D_Cache data RAM accesses, when
ECC is configured.
Bit Description
[63:15] RAZ/WI
[7] RAZ/WI
Table 9-37 describes the format of the AUX register for data RAM, D_Cache, when parity is
configured.
Bit Description
[63:12] RAZ/WI
[7:4] RAZ/WI
Table 9-38 describes the format of the AUX register for data RAM, D_Cache, when no error
correction is configured.
Bit Description
[63:0] RAZ/WI
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-33
ID092411 Non-Confidential
Level Two Interface
Table 9-39 describes the format of the TRANSFER register for tag RAM, when using ECC.
Bit Description
[63:30] RAZ/WI
Table 9-40 describes the format of the TRANSFER register for tag RAM, when using parity.
Bit Description
[63:24] RAZ/WI
Table 9-41 describes the format of the TRANSFER register for tag RAM, when no error
correction is configured.
Bit Description
[63:23] RAZ/WI
Table 9-42 describes the format of the TRANSFER register for dirty RAM, when ECC is
configured.
Bit Description
[63:31] RAZ/WI
[23] RAZ/WI
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-34
ID092411 Non-Confidential
Level Two Interface
Bit Description
[15] RAZ/WI
[7] RAZ/WI
Table 9-43 describes the format of the TRANSFER register for dirty RAM, when parity, or no
error correction, is configured.
Bit Description
[63:27] RAZ/WI
[23:19] RAZ/WI
[15:11] RAZ/WI
[7:3] RAZ/WI
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-35
ID092411 Non-Confidential
Level Two Interface
The three peripheral interfaces use two physical ports, a 32-bit wide AXI master port that
conforms to the AXI3 standard as described in the AMBA AXI Protocol Specification and an
optional 32-bit wide AHB-Lite master port that conforms to the AHB-Lite standard as described
in the AMBA AHB Protocol Specification.
The LLPP Virtual AXI is independent of the LLPP Normal AXI and the LLPP AHB peripheral
interface from an ordering point of view. Accesses to both the AXI peripheral interfaces use the
same physical AXI port but have different AXI IDs.
The AXI peripheral port has an address buffer and a data buffer, each of which has three entries.
Each entry in the address buffer holds 32 bits of address, and an entry in the data buffer holds
32 bits of data. No merging is possible between the entries of a buffer. The LLPP Normal AXI
and LLPP Virtual AXI share the address and data buffer.
The AHB peripheral port has its own address and data buffers. The address buffer has three
entries and the data buffer has four entries. Each entry holds 32 bits. No merging is possible
between the entries of a buffer.
The maximum number of outstanding write accesses that the processor posts onto the LLPP
Virtual AXI is 3 and 15 for the LLPP Normal AXI.
AHB-Lite does not have the ability to do posted and out-of-order transactions, so the AHB
peripheral port does not have a separate virtual interface.
Write issuing capability of LLPP Normal AXI 15 15 outstanding writes on (non-virtual) AXI peripheral interface
Write issuing capability of LLPP Virtual AXI 3 3 outstanding writes on virtual AXI peripheral interface
Combined issuing capability 19 Maximum number of posted writes on all AXI peripheral interfaces and a
read
Write ID capability 2 -
Write interleave capability 1 The AXI peripheral port presents all write data in order
Read ID capability 2 -
The peripheral ports can run at the same frequency as the processor or at a lower synchronous
frequency. See AMBA interface clocking on page 2-16 for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-36
ID092411 Non-Confidential
Level Two Interface
In addition, the peripheral ports produce or check parity bits for each AXI or AHB channel.
These additional signals are not part of the AXI or AHB specification, though some make use
of AXI extension signals.
You can configure the AHB peripheral port to be removed, and not included in the processor
design. The AXI peripheral port is always included and is not optional.
During implementation, you can configure the peripheral ports to use an error-correction
scheme to detect and correct signals transferred using the peripheral port buses, see Bus ECC
on page 9-2.
The size of each peripheral interface is configured during integration. The permissible LLPP
Normal AXI, LLPP Virtual AXI, or AHB peripheral interface sizes are:
• 4 KB
• 8 KB
• 16 KB
• 32 KB
• 64 KB
• 128 KB
• 256 KB
• 512 KB
• 1 MB
• 2 MB
• 4 MB
• 8 MB
• 16 MB
• 32 MB
• 64 MB
• 128 MB
• 256 MB
• 512 MB
• 1 GB
• 2 GB
• 4 GB.
The LLPP Virtual AXI is either the same size as the LLPP Normal AXI or a sub-region of it.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-37
ID092411 Non-Confidential
Level Two Interface
The size of the peripheral interfaces is visible to software in the Peripheral Port Region
Registers.
The LLPP Normal AXI and AHB peripheral interfaces, but not the LLPP Virtual AXI interface,
can be enabled from reset by configuring the control pins. Peripheral interface region enables
can also be programmed using the System Coprocessor Registers, see Peripheral interface
region registers on page 4-84. Ensure that peripheral interface region programming is done
when the MPU is disabled to prevent unpredictable behavior.
Accesses to the peripheral interfaces from the LSU are checked against the MPU for access
permission. Memory access attributes are exported on this interface. Access permissions for
peripheral interface accesses are the same as the permission attributes that the MPU assigns to
the same address. Instructions cannot be fetched from any of the peripheral interfaces, and
therefore they behave as if they have the eXecute Never (XN) attribute, regardless of the MPU
XN attribute. All instruction fetches from the peripheral interfaces generate a permission fault.
See Chapter 7 Memory Protection Unit for more information about memory attributes, types,
and permissions.
Note
If a peripheral interface region overlaps with a TCM region then the TCM region gets more
priority and the overlapping memory gets the attributes of the TCM region.
The L1 memory system cannot cache any peripheral interface access even if the access is to
Normal memory with a Cacheable attribute. Load or store multiple instructions accessing the
peripheral port are not performed as long bursts, and are not interruptible-restartable, even when
they are in Normal memory. ARM recommends that you do not perform multiples to the
peripheral interface regardless of the memory type, because this might impact the interrupt
latency.
Any unaligned access to Device or Strongly Ordered memory generates an alignment fault and
therefore does not cause any peripheral interface access. This means that the access examples
given in this chapter never show unaligned accesses to Device or Strongly Ordered memory.
Also any shared exclusive double to the AXI peripheral port or any shared exclusive to the AHB
peripheral port generates an abort and therefore does not cause an access.
The AXI peripheral port requires that the slave does not return a write response until it has
received both the write data and the write address.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-38
ID092411 Non-Confidential
Level Two Interface
The AXI peripheral port uses the ARCACHEPm and AWCACHEPm signals to indicate the
memory attributes of the transfer, as returned by the MPU. Table 9-45 shows the encoding used
for the ARCACHEPm and AWCACHEPm signals of the master interface. These are
generated from the memory type and outer region attributes.
Encodinga Meaning
b0001 Device
b0011 Non-cacheable
The processor conforms to the AXI3 specification, but it does not generate all the AXI
transaction types that the specification permits. This section describes the types of AXI
transactions that the Cortex-R5 AXI peripheral port does not generate. If you are designing an
AXI slave to work only with the Cortex-R5 processor AXI peripheral port, you can take
advantage of these restrictions and the interface attributes to simplify the slave.
This section also contains tables that show some examples of the types of AXI burst that the
processor generates. However, because a particular type of transaction is not shown here does
not mean that the processor does not generate such a transaction.
Note
An AXI slave device connected to the Cortex-R5 AXI master port must be capable of handling
every kind of transaction permitted by the AXI specification, except where there is an explicit
statement in this chapter that such a transaction is not generated. You must not infer any
additional restrictions from the example tables given.
Restrictions on AXI peripheral transfers on page 9-40 describes restrictions on the type of
transfers that the Cortex-R5 AXI peripheral port generates. If a CPUm exists and is powered up,
BREADYPm and RREADYPm are always asserted. They are, however, deasserted when the
CPU enters Dormant or Shutdown mode. You must not make any assumptions about the AXI
handshaking signals, except that they conform to the AMBA AXI3 Protocol Specification.
The following sections give examples of transfers generated by the LLPP AXI interface:
• Strongly Ordered and Device transactions on page 9-40
• Normal reads on page 9-43
• Normal Writes on page 9-45.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-39
ID092411 Non-Confidential
Level Two Interface
The Cortex-R5 AXI peripheral port applies the following restrictions to the AXI transactions it
generates:
• If the transfer size is 8-bits or 16-bits then the burst length is always one transfer
• Transactions to Device and Strongly Ordered memory are always to addresses that are
aligned for the transfer size
• Exclusive and Locked accesses are always to addresses that are aligned for the transfer
size
A load or store instruction to or from Strongly Ordered or Device memory always generates
AXI transactions of the same size as the instruction implies. All accesses using LDM, STM, LDRD,
or STRD instructions to Strongly Ordered or Device memory occur as 32-bit transfers.
LDRB
Table 9-46 shows the values of ARADDRPm, ARBURSTPm, ARSIZEPm, and ARLENPm
for LDRB from bytes 0-3 in Strongly Ordered or Device memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-40
ID092411 Non-Confidential
Level Two Interface
LDRH
Table 9-47 shows the values of ARADDRPm, ARBURSTPm, ARSIZEPm, and ARLENPm
for LDRH from halfwords 0-1 in Strongly Ordered or Device memory.
Note
A load of a halfword from Strongly Ordered or Device memory addresses 0x1 or 0x3 generates
an alignment fault.
Table 9-48 shows the values of ARADDRPm, ARBURSTPm, ARSIZEPm, and ARLENPm
for an LDR or an LDM that transfers one register, an LDM1, in Strongly Ordered or Device memory.
Note
A load of a word from Strongly Ordered or Device memory addresses 0x1, 0x2, or 0x3 generates
an alignment fault.
Table 9-49 shows the values of ARADDRPm, ARBURSTPm, ARSIZEPm, and ARLENPm
for an LDM that transfers five registers, an LDM5, in Strongly Ordered or Device [Link]
transfers
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-41
ID092411 Non-Confidential
Level Two Interface
Note
A load-multiple from memory addresses 0x1, 0x2, 0x3, 0x5, 0x6, or 0x7 generates an alignment
fault.
STRB
STRH
Note
A store of a halfword from Strongly Ordered or Device memory addresses 0x1, 0x3, 0x5, or 0x7
generates an alignment fault.
Table 9-52 shows the values of AWADDRm, AWBURSTPm, AWSIZEPm, and AWLENPm
for an STR or an STM that transfers one register, an STM1, to Strongly Ordered or Device memory.
Note
A store of a word to Strongly Ordered or Device memory addresses 0x1, 0x2, or 0x3 generates
an alignment fault.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-42
ID092411 Non-Confidential
Level Two Interface
Table 9-53 shows the values of AWADDRm, AWBURSTPm, AWSIZEPm, and AWLENPm
for an STM that writes five registers, an STM5, over the AXI peripheral port to Strongly Ordered
or Device memory.
Note
A store-multiple to address 0x1, 0x2, 0x3, 0x5, 0x6, or 0x7 generates an alignment fault.
Normal reads
Load instructions accessing Normal memory generate AXI peripheral port bursts that are
always of 32-bit size and not necessarily the same size or length as the instruction implies. The
tables in this section give examples of the types of AXI transaction that might result from
various load instructions, accessing various addresses in Normal memory. They are provided as
examples only, and are not an exhaustive description of the AXI transactions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-43
ID092411 Non-Confidential
Level Two Interface
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-44
ID092411 Non-Confidential
Level Two Interface
Normal Writes
Store instructions accessing Normal memory generate AXI peripheral port bursts that are
always of 32-bit size and not necessarily the same size or length as the instruction implies. The
AXI peripheral port asserts byte-lane strobes, WSTRBPm[3:0], to ensure that only the bytes
that were written by the instruction are updated.
The tables in this section give examples of the types of AXI transaction that might result from
various store instructions, accessing various addresses in Normal memory. They are provided
as examples only, and are not an exhaustive description of the AXI transactions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-45
ID092411 Non-Confidential
Level Two Interface
The processor conforms to the AHB-Lite specification, but it does not generate all the AHB
transaction types that the specification permits. This section describes the types of AHB
transaction that the Cortex-R5 AHB peripheral port does not generate. If you are designing an
AHB slave to work only with the Cortex-R5 processor AHB peripheral port, you can take
advantage of these restrictions and the interface attributes described in previous sections to
simplify the slave.
This section also contains tables that show some of the types of AHB burst that the processor
generates. However, because a particular type of transaction is not shown here does not mean
that the processor does not generate such a transaction.
Note
An AHB slave device connected to the Cortex-R5 AHB master port must be capable of handling
every kind of transaction permitted by the AHB specification, except where there is an explicit
statement in this chapter that such a transaction is not generated. You must not infer any
additional restrictions from the example tables given.
Restrictions on AHB peripheral port transfers describes restrictions on the type of transfers that
the Cortex-R5 AHB peripheral port generates.
The following sections give examples of transfers generated by the AHB peripheral port:
• Strongly Ordered and Device transactions on page 9-47
• Normal reads on page 9-50
• Normal writes on page 9-51.
The Cortex-R5 AHB peripheral port applies the following restrictions to the AHB transactions
it generates:
• All bursts are either single or 1-beat incrementing bursts, that is, HBURSTPm[2:0] is
either SINGLE or INCR.
• The transfer size is never greater than 32 bits because it is a 32-bit AHB bus.
• If the transfer size is 8 bits or 16 bits then the burst length is always one transfer.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-46
ID092411 Non-Confidential
Level Two Interface
• Transactions to Device and Strongly Ordered memory are always to addresses that are
aligned for the transfer size.
• Locked accesses are always to addresses that are aligned for the transfer size.
A load or store instruction, to or from Strongly Ordered or Device memory, always generates
AHB transactions of the size implied by the instruction. All accesses using LDM, STM, LDRD or STRD
instructions to Strongly Ordered or Device memory occur as 32-bit transfers.
LDRB
Table 9-59 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an LDRB
from bytes 0-3 in Strongly Ordered or Device memory.
LDRH
Table 9-60 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an LDRH
from halfwords 0-1 in Strongly Ordered or Device memory.
Note
A load of a halfword from Strongly Ordered or Device memory addresses 0x1 or 0x3 generates
an alignment fault.
Table 9-61 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an LDR or
an LDM that transfers one register, an LDM1, in Strongly Ordered or Device memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-47
ID092411 Non-Confidential
Level Two Interface
Note
A load of a word from Strongly Ordered or Device memory addresses 0x1, 0x02, 0x3, 0x5, 0x06,
or 0x7 generates an alignment fault.
Table 9-62 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an LDM that
transfers five registers, an LDM5, in Strongly Ordered or Device memory.
Note
A load of a word from Strongly Ordered or Device memory addresses 0x1, 0x2, or 0x3 generates
an alignment fault.
STRB
Table 9-63 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an STRB
from bytes 0-3 in Strongly Ordered or Device memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-48
ID092411 Non-Confidential
Level Two Interface
STRH
Table 9-60 on page 9-47 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm
for an STRH from halfwords 0-1 in Strongly Ordered or Device memory.
Note
A store of a halfword to Strongly Ordered or Device memory addresses 0x1 or 0x3 generates an
alignment fault.
Table 9-65 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an STR that
transfers one register, an STR1, in Strongly Ordered or Device memory.
Note
A store of a word to Strongly Ordered or Device memory addresses 0x1, 0x2, or 0x3 generates
an alignment fault.
Table 9-66 shows the values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an STM that
transfers five registers, an STM5, over the AHB master port to Strongly Ordered or Device
memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-49
ID092411 Non-Confidential
Level Two Interface
Note
A store of a word from Strongly Ordered or Device memory addresses 0x1, 0x2, 0x3, 0x5, 0x6, or
0x7 generates an alignment fault.
Normal reads
Load instructions accessing Normal memory generate AHB peripheral port bursts that might not
be the same size or length as the instruction implies. The tables in this section give examples of
AHB transactions that might result from various load instructions, accessing various addresses
in Normal memory. They are examples only, and are not an exhaustive description of the AHB
transactions.
LDRH
Table 9-67 shows possible values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an
LDRH from bytes 0 to 7 in Normal memory.
LDR
Table 9-68 shows possible values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an
LDR from Normal memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-50
ID092411 Non-Confidential
Level Two Interface
Normal writes
Store instructions accessing Normal memory generate AHB peripheral port bursts that might
not be the same size or length as the instruction implies. The tables in this section give examples
of AHB transactions that might result from various store instructions, accessing various
addresses in Normal memory. They are examples only, and are not an exhaustive description of
the AHB transactions.
STRH
Table 9-69 shows possible values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an
STRH from bytes 0 to 3 in Normal memory.
Table 9-70 shows possible values of HADDRPm[1:0], HBURSTPm, and HSIZEPm for an
STR to Normal memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-51
ID092411 Non-Confidential
Level Two Interface
9.7.9 Semaphores
The peripheral interfaces use the internal exclusive monitor of the processor L1 memory system
to manage load, store and clear exclusive instructions to non-shared memory. The internal
monitor checks exclusive accesses to shared memory and also, if necessary, any external
monitor using the L2 memory interface. You can use these instructions to construct semaphores
and ensure synchronization between different processes or processors. See the ARM
Architecture Reference Manual for more information about how these instructions work.
Only exclusive instructions to shared memory result in exclusive accesses on the bus. Exclusive
accesses to non-shared memory are marked as non-exclusive accesses on the bus.
Exclusive doubles to shared memory on LLPP Normal AXI or LLPP Virtual AXI (LDREXD and
STREXD) are aborted. The AHB peripheral port cannot perform any exclusive accesses, so all
exclusive accesses to shared memory on the AHB peripheral interface are aborted. The source
of an abort because of a shared exclusive double to LLPP Normal AXI or LLPP Virtual AXI, or
a shared exclusive to the AHB peripheral interface is encoded in the Data Fault Status Register
(DFSR) as a Synchronous External AXI Slave Error.
The SWP and SWPB instructions can also be used for memory synchronization. Only swap
instructions to shared memory are marked as locked accesses on the bus.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-52
ID092411 Non-Confidential
Level Two Interface
The ACP has an AXI slave interface and an AXI master interface:
• the ACP slave interface has one port with only the AW and B channels
• the ACP master interface has one port with only the AW and B channels.
Each port is 64 bits wide, and conforms to the AMBA 3 AXI standard as described in the AMBA
AXI Protocol Specification.
Within the AXI standard, the ACP slave port uses a number of extension signals to:
• indicate if coherency must be preserved
• give information about coherency maintenance operations
• carry parity information for the bus-ECC feature, if included.
Within the AXI standard, the ACP master port uses a number of extension signals to:
• indicate if coherency must be preserved
• carry parity information for the bus-ECC feature, if included.
See Bus ECC on page 9-2 for more information on parity checking and generation in the ACP.
The ACP ports can run at the same frequency as the processor or at a lower synchronous
frequency. See Clocking on page 2-16 for more information.
The Cortex-R5 ACP memory coherency scheme only provides coherency between an external
master connected to the ACP slave port and a CPU with a data cache in the Cortex-R5 group for
memory regions configured as inner cacheable write-through in the CPU’s MPU. It does not
provide coherency for memory regions configured as cacheable write-back.
Note
In a twin-CPU configuration, the ACP maintains memory coherency between the external
master and each CPU with a data cache in the Cortex-R5 group, but not between the external
master and a CPU without a data cache, or between the two CPUs.
For AXI write transactions going through the ACP and marked as coherent, AW channel
sideband signal AWCOHERENTCS high, the ACP ensures that there is no cached copy of the
data at these addresses in the CPU’s data cache when the AXI write completes.
When an AXI write from the external master appears on the ACP slave port’s AW channel, the
ACP records some information about it and forwards the write transaction to the memory
system on the ACP master port’s AW channel.
When the memory system sends the write response on the ACP master port’s B channel, the
ACP records the response and recalls if the transaction was coherent.
If the transaction is not coherent, the ACP forwards the response to the external master on the
ACP slave port’s B channel.
If the transaction is coherent, the ACP first sends coherency maintenance operations to the
CPU’s data cache controller for the addresses spanned by the write transaction, and waits until
the cache controller has acknowledged that all necessary coherency maintenance operations
have been carried out to forward the write response to the ACP slave port’s B channel, along
with information about the maintenance operations.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-53
ID092411 Non-Confidential
Level Two Interface
Coherency maintenance operations invalidate cache lines when a CPU’s data cache holds a copy
of data at an address spanned by a coherent external write transaction. However if this cache
line is dirty, it is not invalidated and the ACP indicates along with the write response that
coherency was not maintained for this transaction.
• If at least one address was cached and potentially dirty in which case coherency has not
been maintained, sideband signal BHITDIRTYCSm.
If a transaction is not coherent, the ACP always indicates that all addresses were not cached and
never indicates that at least one address was cached and potentially dirty.
If a CPU’s data cache controller cannot process coherency maintenance requests, because, for
example, it is powered down, the ACP always indicates that all addresses were not cached and
indicates that at least one address was cached and potentially dirty, only if coherency was not
maintained for the write transaction.
Note
• The ACP does not reorder transactions:
— write address transactions appear on the ACP master port AW channel in the same
order as they appeared on the ACP slave port AW channel
— responses appear on the ACP slave port B channel in the same order as they
appeared on the ACP master port B channel.
• The ACP master port requires that the slave it connects to does not return a write response
until it has received both the write data and the write address.
• You must not use the ACP at the same time as the AXI slave is accessing the cache RAMs.
If you use the AXI slave to access the cache RAMs, ensure that it is idle before initiating
ACP transactions.
Attribute Value
Attribute Value
Write ID capability 4
Write ID width 2
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 9-54
ID092411 Non-Confidential
Chapter 10
Power Control
This chapter describes the processor power control functions. It contains the following sections:
• About power control on page 10-2
• Power management on page 10-3.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 10-1
ID092411 Non-Confidential
Power Control
• branch and return prediction, reducing the number of incorrect instruction fetch and
decode operations
• the caches use sequential access information to reduce the number of accesses to the tag
RAMs and to unwanted data RAMs.
In the processor, extensive use is also made of gated clocks and gates to disable inputs to unused
functional blocks. Only the logic actively in use to perform a calculation consumes any dynamic
power.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 10-2
ID092411 Non-Confidential
Power Control
If the processor is implemented with twin CPUs, then each CPU can be in a mode independent
of the other, provided CPU1 is never in a higher power mode than CPU0 when CPU0 is in
Dormant or Shutdown mode. Regardless of the state of the CPUs, the logic for the ACP
interfaces and the debug-APB interfaces remain powered up.
A CPU can only enter Dormant or Shutdown modes if it is implemented with the appropriate
power gating circuitry and clamp logic, and is integrated into a system with a power controller.
Run mode is the normal mode of operation where all of the functionality of the CPU is available.
Standby mode enables most of the clocks of the device to be disabled, while keeping the design
powered up. This reduces the power drawn to the static leakage current, plus a tiny clock power
overhead required to enable the device to wake up from the Standby mode.
Entry into Standby mode is performed by executing the Wait For Interrupt (WFI) instruction or
Wait For Event (WFE) instruction. To ensure that the entry into the Standby mode does not affect
the memory system on a Cortex-R5 CPU, the WFI and WFE instructions automatically performs a
Data Synchronization Barrier operation. This ensures that all explicit memory accesses occur
before the WFI or WFE has completed. When this has happened, the CPU stops fetching
instructions and asserts nWFIPIPESTOPPEDm or nWFEPIPESTOPPEDm as appropriate,
to indicate that it is in Standby mode.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 10-3
ID092411 Non-Confidential
Power Control
When the CPU is in Standby mode and it has no outstanding AXI-slave or debug-APB
transactions or ACP invalidate requests, then it stops the clock to the majority of its logic. When
the CPU clocks are stopped the nCLKSTOPPEDm signal is asserted. If the
DBGNOCLKSTOP input is asserted, the CPU does not stop its clocks or assert
nCLKSTOPPEDm when in Standby mode.
When the processor is in Standby mode and the AXI slave interface or debug-APB interface
receives a transaction or an ACP invalidate request is generated, the processor clocks are
temporarily restarted and nCLKSTOPPEDm is deasserted to enable it to service the
transaction, but it does not return to Run mode.
The CPU exits Standby mode and returns to Run mode in response to a variety of events,
depending on whether Standby mode was entered using WFI or WFE.
For WFI, the transition from Standby mode to Run mode is caused by:
• the arrival of an interrupt, whether masked or unmasked
• a debug request, whether debug is enabled or disabled
• a reset.
For WFE, the transition from Standby mode to Run mode is caused by:
• the arrival of an unmasked interrupt
• a debug request, whether debug is enabled or disabled
• an event signalled on the EVENTIm input
• a reset.
The debug request can be generated by an externally generated debug request, using the
EDBGRQm pin on the processor, or from a Debug Halt instruction issued to the processor
through the debug Advanced Peripheral Bus (APB).
Systems using the VIC interface must ensure that the VIC is not masking any interrupts that are
required for restarting the processor when in standby mode.
In Dormant mode, only the CPU logic, but not the CPU TCM and cache RAMs, is powered
down, so that the only power consumption is the static leakage current of the RAMs.
Before entering Dormant mode, you must save the CPU state, except for the cache and TCM
state, in memory. When power is restored to the CPU logic, the CPU is returned to Run mode
by asserting and deasserting nRESETm. You must restore the CPU state as part of the boot
process. Because the cache and TCM are not powered down in Dormant mode, you do not have
to invalidate or initiate them during boot, and the task can access data in the cache without
requiring a cache refill. In Dormant mode, the CPU state, apart from the cache and TCM state,
is stored to memory before entry into this mode, and restored after exit. For more information
on how to implement and use Dormant mode in your design, contact ARM.
In Shutdown mode, the entire CPU is powered down, so that it consumes no power. Before
entering Shutdown mode, you must save all the processor state, including any required cache
and TCM state in the level-2 memory. This typically includes cleaning the whole data cache.
When it is powered up, the CPU is returned to Run mode by asserting and deasserting
nRESETm. As part of the boot process, you must:
• restore the CPU state if required
• invalidate the caches
• initialize the TCMs as part of the boot process.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 10-4
ID092411 Non-Confidential
Power Control
You can only put the CPU into Dormant mode or Shutdown mode if it is integrated into a system
with a memory-mapped Power Management Controller (PMXEVCNTR). The PMXEVCNTR
must respond to software running on the CPU to power down the appropriate logic at the right
time. The PMXEVCNTR must also respond to stimulus from the system, to power up the CPU
logic and return it to Run mode.
Both Standby mode and Dormant mode are entered through Standby mode. You must program
the PMXEVCNTR to indicate which mode you want to enter, then perform the appropriate
state-saving operations. After this is done, execute WFI or WFE to enter Standby mode.
When a CPU is in Standby mode, and a transaction that requires coherency is received by the
ACP, the clock for the CPU is restarted, if required, so that coherency maintenance operations
can be handled as normal. When the ACP is idle again the clock is gated off again, if
appropriate,
When a CPU is in Dormant mode, then its cache contents are live, but it cannot respond to
coherency maintenance operations that the ACP generates. For this CPU, for ACP transactions
requiring coherency, the coherency maintenance operations information signals indicate that all
addresses were not cached, that is, BMISSCS[m] is asserted, and indicate that at least one
address was cached and potentially dirty, BHITDIRTYCS[m]. Because this is usually
considered erroneous, ARM recommends that the system is built so that transactions requiring
coherency cannot be received by the processor, when one or both of the CPUs are in Dormant
mode.
When a CPU is in Shutdown mode, its cache contents are lost and therefore there are no
coherency issues with that cache. For this CPU, the coherency maintenance operations
information signals indicate that all addresses were not cached, that is, BMISSCS[m] is
asserted, and do not indicate that at least one address was cached and potentially dirty, that is,
BHITDIRTYCS[m] is not asserted.
See Accelerator Coherency Port interface on page 9-53 for more information about the ACP.
When one of the Cortex-R5 CPUs is in Standby mode and a debug-APB access to one of the
core registers is received, the clocks for the CPU are restarted, if required, so that the transaction
can be serviced as normal. When the transaction is complete, the clock is, gated off again if
appropriate.
When a CPU is in Shutdown mode or Dormant mode, the core debug registers, for example.
DBGDSCR, are unavailable and an error response is signalled for transactions to these registers.
The debug-APB interface and the debug domain registers, for example DIDR, remain available
as normal. The power-down status is indicated by the DBGPRSR. See Device Power-down and
Reset Status Register on page 12-32.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 10-5
ID092411 Non-Confidential
Chapter 11
FPU Programmers Model
This chapter describes the programmers model of the Floating Point Unit (FPU). It contains the
following sections:
• About the FPU programmers model on page 11-2
• General-purpose registers on page 11-4
• System registers on page 11-5
• Modes of operation on page 11-12
• Compliance with the IEEE 754 standard on page 11-13.
The Cortex-R5F processor is a Cortex-R5 processor that includes the optional FPU. In this
chapter, the generic term processor means only the Cortex-R5F processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-1
ID092411 Non-Confidential
FPU Programmers Model
The FPU is an implementation of the ARM Vector Floating Point v3 architecture, with 16
double-precision registers (VFPv3-D16). It provides floating-point computation functionality
that is compliant with the ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point
Arithmetic, referred to as the IEEE 754 standard. The FPU supports all data-processing
instructions and data types in the VFPv3 architecture as described in the ARM Architecture
Reference Manual.
The FPU fully supports single-precision and double-precision add, subtract, multiply, divide,
multiply and accumulate, and square root operations. It also provides conversions between
fixed-point and floating-point data formats, and floating-point constant instructions. The FPU
does not support any data processing operations on vectors in hardware. Any data processing
instruction that operates on a vector generates an Undefined Instruction exception. The
operation can then be emulated in software if necessary.
Cortex-R5F does not implement either the half-precision conversion or fused-MAC extensions
to the VFPv3 architecture.
Table 11-1 lists the VFP instructions that are Undefined in a single-precision only configuration.
These instructions are <opcode>.<cond>.F64 where opcode is listed in the table:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-2
ID092411 Non-Confidential
FPU Programmers Model
Note
The single-precision variants of these instructions (<opcode>.<cond>.F32) execute as normal.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-3
ID092411 Non-Confidential
FPU Programmers Model
You can reference the VFP register bank using two explicitly aliased views. Figure 11-1 shows
the two views of the register bank and the way the word and doubleword registers overlap.
S0
D0
S1
S2
D1
S3
S4
D2
S5
S6
D3
S7
... ...
S28
D14
S29
S30
D15
S31
For example, you can access the least significant half of the value in D6 by accessing S12, and
the most significant half of the elements by accessing S13.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-4
ID092411 Non-Confidential
FPU Programmers Model
Table 11-2 shows the VFP system registers in the Cortex-R5F FPU.
a. Bits [3:0] of the FPSID depend on the product revision. See the FPSID register description for more information.
Note
The FPSID, MVFR0, and MVFR1 Registers are read-only. Attempts to write these registers are
ignored.
Table 11-3 shows that a Privileged mode is sometimes required to access a VFP system register.
When a Privileged mode is required, an instruction that attempts to access a register in a
nonprivileged mode takes the Undefined Instruction exception.
For a VFP system register to be accessible, it must follow the rules in Table 11-3 and the VFP
must also be accessible according to the CPACR. See c1, Coprocessor Access Control Register
on page 4-47 for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-5
ID092411 Non-Confidential
FPU Programmers Model
Note
All hardware ID information is privileged access only:
31 24 23 22 16 15 8 7 4 3 0
HW
[22:16] Subarchitecture version VFP architecture v3 or later with Common VFP subarchitecture v2a:
0x02
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-6
ID092411 Non-Confidential
FPU Programmers Model
[3:0] Revision When the build-configuration includes the floating point unit, this register identifies the revision
number of the floating-point unit:
0x0 = r0p0
0x1 = r1p0
0x2 = r1p1
0x3 = r1p2
a. For more information about the Common VFP subarchitecture see the ARM Architecture Reference Manual.
Purpose Provides all necessary User level control of the floating-point system.
Usage constraints All bits described as DNM in Figure 11-3 are reserved for future
expansion. These bits must be initialized to zeros. To ensure that these bits
are not modified, any code other than initialization code must use
read-modify-write techniques when writing to FPSCR. Failure to observe
this rule can cause Unpredictable results in future systems.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
QC IDE IXC
AHP IXE UFC
DN UFE OFC
FZ OFE DZC
RMODE DZE IOC
STRIDE IOE
DNM IDC
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-7
ID092411 Non-Confidential
FPU Programmers Model
[29] C Set if comparison produces an equal, greater than, or unordered result, resets to zero
[19] - DNM
[14:13] - DNM
[6:5] - DNM
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-8
ID092411 Non-Confidential
FPU Programmers Model
Purpose Provides global enable and disable control of the VFP extension, and
indicate how the state of this extension is recorded.
31 30 29 28 0
Reserved
DEX
EN
Reserved
[31] - RAZ.
[30] EN VFP enable bit. Setting EN enables VFP functionality. Reset clears EN.
[29] DEX Set when an Undefined Instruction exception is taken because of a vector instruction that would have been
executed if the processor supported vectors. This field is cleared when an Undefined Instruction exception is
taken for any other reason. Resets to zero.
In single-precision only configurations, this bit is not set for any double-precision operations, whether they are
vector operations or not.
[28:0] - RAZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-9
ID092411 Non-Confidential
FPU Programmers Model
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
RM SV SR D TE DP SP RB
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
VFP
Reserved VFP HPFP SP I LS DN FZ
A_SIMD
Table 11-8 on page 11-11 shows the MVFR1 Register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-10
ID092411 Non-Confidential
FPU Programmers Model
[31:28] - Reserved
[7:4] DN Indicates whether the VFP hardware supports only Default NaN mode:
0x1 = hardware supports propagation of NaN values in addition to Default NaN mode.
[3:0] FZ Indicates whether the VFP hardware supports only Flush-to-Zero mode:
0x1 = hardware supports full denormal arithmetic in addition to Flush-to-Zero mode.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-11
ID092411 Non-Confidential
FPU Programmers Model
In full-compliance mode, the FPU processes all operations according to the IEEE 754 standard
in hardware.
Setting the FZ bit, FPSCR[24], enables flush-to-zero mode. In this mode, the FPU treats all
subnormal input operands of arithmetic CDP operations as zeros in the operation. Exceptions that
result from a zero operand are signaled appropriately. VABS, VNEG, and VMOV are not considered
arithmetic CDP operations and are not affected by flush-to-zero mode. A result that is tiny, as
described in the IEEE 754 standard, for the destination-precision is smaller in magnitude than
the minimum normal value before rounding and is replaced with a zero. The IDC flag,
FPSCR[7], indicates when an input flush occurs. The UFC flag, FPSCR[3], indicates when a
result flush occurs.
Setting the DN bit, FPSCR[25], enables default NaN mode. In this mode, the result of any
operation that involves an input NaN, or that generated a NaN result, returns the default NaN.
Propagation of the fraction bits is maintained only by VABS, VNEG, and VMOV operations. All other
CDP operations ignore any information in the fraction bits of an input NaN.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-12
ID092411 Non-Confidential
FPU Programmers Model
See the ARM Architecture Reference Manual for information about VFP architecture
compliance with the IEEE 754 standard.
The following operations from the IEEE 754 standard are not supplied by the VFP instruction
set:
• remainder
• round floating-point number to integer-valued floating-point number
• binary-to-decimal conversions
• decimal-to-binary conversions
• direct comparison of single-precision and double-precision values.
For complete implementation of the IEEE 754 standard, VFP functionality must be augmented
with library functions that implement these operations. See Application Note 98, VFP Support
Code for information on the available library functions.
Some of the implementation choices permitted by the IEEE 754 standard and used in the VFPv3
architecture are described in the ARM Architecture Reference Manual.
NaN handling
All single-precision and double-precision values with the maximum exponent field value and a
nonzero fraction field are valid NaNs. A most significant fraction bit of zero indicates a
Signaling NaN (SNaN). A one indicates a Quiet NaN (QNaN). Two NaN values are treated as
different NaNs if they differ in any bit. Table 11-9 shows the default NaN values in both
single-precision and double-precision.
Single-precision Double-precision
Sign 0 0
Fraction bit [22] = 1, bits [21:0] are all zeros bit [51] = 1, bits [50:0] are all zeros
Processing of input NaNs for ARM floating-point functionality and libraries is defined as
follows:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-13
ID092411 Non-Confidential
FPU Programmers Model
• In default NaN mode, arithmetic CDP instructions involving NaN operands return the
default NaN regardless of the fractions of any NaN operands. SNaNs in an arithmetic CDP
operation set the IOC flag, FPSCR[0]. NaN handling by data transfer and non-arithmetic
CDP instructions is the same as in full-compliance mode.
Instruction Default
With QNaN operand With SNaN operand
type NaN mode
Off The QNaN or one of the QNaN operands, if there IOCa set. The SNaN is quieted and the result
is more than one, is returned according to the rules NaN is determined by the rules given in the
Arithmetic CDP given in the ARM Architecture Reference Manual. ARM Architecture Reference Manual.
Non-arithmetic Off
NaN passes to destination with sign changed as appropriate.
CDP On
Off
Load/store All NaNs transferred.
On
Comparisons
Comparison results modify the flags in the FPSCR Register. You can use the VMRS APSR_nzcv,
FPSCR instruction (formerly FMSTAT) to transfer the current flags from the FPSCR Register to the
CPSR Register. See the ARM Architecture Reference Manual for mapping of IEEE 754 standard
predicates to ARM conditions. The flags used are chosen so that subsequent conditional
execution of ARM instructions can test the predicates defined in the IEEE 754 standard.
Underflow
The Cortex-R5F FPU uses the before rounding form of tininess and the inexact result form of
loss of accuracy as described in the IEEE 754 standard to generate Underflow exceptions.
In flush-to-zero mode, results that are tiny before rounding, as described in the IEEE 754
standard, are flushed to a zero, and the UFC flag, FPSCR[3], is set. See the ARM Architecture
Reference Manual for information on flush-to-zero mode.
When the FPU is not in flush-to-zero mode, operations are performed on subnormal operands.
If the operation does not produce a tiny result, it returns the computed result, and the UFC flag,
FPSCR[3], is not set. The IXC flag, FPSCR[4], is set if the operation is inexact. If the operation
produces a tiny result, the result is a subnormal or zero value, and the UFC flag, FPSCR[3], is
set if the result was also inexact.
11.5.3 Exceptions
The FPU implements the VFPv3 architecture and sets the cumulative exception status flag in
the FPSCR register as required for each instruction. The FPU does not support user-mode traps.
The exception enable bits in the FPSCR read-as-zero, and cannot be written. The processor also
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-14
ID092411 Non-Confidential
FPU Programmers Model
has six output pins, FPIXCm, FPUFCm, FPOFCm, FPDZCm, FPIDCm, and FPIOCm, that
each reflect the status of one of the cumulative exception flags. See FPU signals on page A-32
for a description of these outputs. You can mask each of these outputs masked by setting the
corresponding bit in the Secondary Auxiliary Control Register.
See c1, Auxiliary Control Register on page 4-41 for more information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 11-15
ID092411 Non-Confidential
Chapter 12
Debug
This chapter describes the processor debug unit. These features assist the development of
application software, operating systems, and hardware. This chapter contains the following
sections:
• Debug systems on page 12-2
• About the debug unit on page 12-3
• Debug register interface on page 12-5
• Debug register descriptions on page 12-10
• Management registers on page 12-33
• Debug events on page 12-40
• Debug exception on page 12-42
• Debug state on page 12-45
• Cache debug on page 12-50
• External debug interface on page 12-51
• Using the debug functionality on page 12-54
• Debugging systems with energy management capabilities on page 12-70.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-1
ID092411 Non-Confidential
Debug
Debug
Host computer running RealView Debugger
host
Protocol
For example, RealView ICE
converter
This typical system has three parts, described in the following sections:
• Debug host
• Protocol converter
• Debug target.
The debug host is a computer, for example a personal computer, running a software debugger
such as RealView™ Debugger. The debug host enables you to issue high-level commands such
as setting breakpoint at a certain location, or examining the contents of a memory address.
The debug host connects to the processor development system using an interface such as
Ethernet. The messages broadcast over this connection must be converted to the interface
signals of the debug target. A protocol converter performs this function, for example, RealView
ICE.
The debug target is the lowest level of the system. An example of a debug target is a
development system with a Cortex-R5 test chip or a silicon part with a Cortex-R5 processor.
The debug target must implement some system support for the protocol converter to access the
processor debug unit using the Advanced Peripheral Bus (APB) slave port.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-2
ID092411 Non-Confidential
Debug
You can debug software running on the processor in the following ways:
• Halting debug-mode debugging
• Monitor debug-mode debugging
• Trace debugging, see ETM interface on page 2-11.
The processor debug unit conforms to the ARMv7 debug architecture. For more information see
the ARM Architecture Reference Manual.
When the processor debug unit is in Halting debug-mode, the processor halts program execution
when a debug event, such as a breakpoint, occurs. When the processor is halted, an external
debugger can examine and modify the processor state using the APB slave port. This debug
mode is invasive to program execution.
When the processor debug unit is in Monitor debug-mode, the processor takes a debug
exception instead of halting. A special piece of software, a monitor target, can then take control
to examine or alter the processor state. Monitor debug-mode is essential in real-time systems
where the processor cannot be halted to collect information. Examples of these systems are
engine controllers and servo mechanisms in hard drive controllers that cannot stop the code
without physically damaging the components.
When debugging in Monitor debug-mode, the processor stops execution of the current program
and starts execution of a monitor target. The state of the processor is preserved in the same
manner as all ARM exceptions. The monitor target communicates with the debugger to access
processor and coprocessor state, and to access memory contents and peripherals. Monitor
debug-mode requires a debug monitor program to interface between the debug hardware and the
software debugger.
The processor debug unit is programmed using the APB slave interface. In a twin-CPU
configuration, each CPU has its own APB slave interface and associated registers that operate
independently of the other CPU. See Table 12-3 on page 12-6 for a complete list of
memory-mapped debug registers accessible using the APB slave interface. Some features of the
debug unit that you can access using the memory-mapped registers are:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-3
ID092411 Non-Confidential
Debug
• data address comparators for triggering watchpoints, see Watchpoint Value Registers on
page 12-27 and Watchpoint Control Registers on page 12-27
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-4
ID092411 Non-Confidential
Debug
Although most of the processor debug registers are accessible through the memory-mapped
interface, there are several registers that you can access through a coprocessor interface. This is
important for boot-strap access to the register file. It enables software running on the processor
to identify the debug architecture version that the device implements.
By default, you can access all CP14 debug registers from a nonprivileged mode. However, you
can program the processor to disable user-mode access to all coprocessor registers using bit [12]
of the DBGDSCR, see CP14 c1, Debug Status and Control Register on page 12-14 for more
information. CP14 debug register accesses are always permitted when the processor is in debug
state regardless of the processor mode.
Yes X X Permitted
No User b0 Permitted
No Privileged X Permitted
Table 12-2 on page 12-6 shows a set of valid CP14 instructions for accessing the debug
registers. All CP14 instructions not listed are Undefined.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-5
ID092411 Non-Confidential
Debug
Note
The CP14 debug instructions are defined as having Opcode_1 set to 0.
MRC p14, 0, <Rd>, c0, c0, 0 DBGDIDR Debug Identification Register. See CP14 c0, Debug ID Register on
page 12-10.
MRC p14, 0, <Rd>, c1, c0, 0 DBGDRAR Debug ROM Address Register. See CP14 c0, Debug ROM Address Register
on page 12-12.
MRC p14, 0, <Rd>, c2, c0, 0 DBGDSAR Debug Self Address Register. See CP14 c0, Debug Self Address Offset
Register on page 12-12.
MRC p14, 0, <Rd>, c0, c5, 0 DBGDTRRXint Host to Target Data Transfer Register. See Data Transfer Register on
STC p14, c5, <addressing mode> page 12-18.
MCR p14, 0, <Rd>, c0, c5, 0 DBGDTRTXint Target to Host Data Transfer Register. See Data Transfer Register on
LDC p14, c5, <addressing mode> page 12-18.
MRC p14, 0, <Rd>, c0, c1, 0 DBGDSCRint Debug Status and Control Register. See CP14 c1, Debug Status and Control
MRC p14, 0, APSR_nzcv, c0, c1, 0 Register on page 12-14.
Table 12-3 shows the complete list of memory-mapped registers accessible at the APB slave
interface.
Note
You must ensure that the base address of this 4KB register map is aligned to a 4KB boundary in
physical memory.
Offset Register
Access Mnemonic Description
(hex) number
0x020 c8 R - RAZ
0x028 c10 RW DBGDSCCR Debug State Cache Control Register on page 12-21.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-6
ID092411 Non-Confidential
Debug
Offset Register
Access Mnemonic Description
(hex) number
0x088 c34 RW DBGDSCRext CP14 c1, Debug Status and Control Register on page 12-14.
0x304 c193 R DBGOSLSR Operating System Lock Status Register on page 12-29.
0x310 c196 RW DBGPRCR Device Power-down and Reset Control Register on page 12-31.
0x314 c197 R DBGPRSR Device Power-down and Reset Status Register on page 12-32.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-7
ID092411 Non-Confidential
Debug
a. The actual number of registers depends on the number of breakpoints configured. For non-implemented breakpoints, the
corresponding registers are RAZ.
b. The actual number of registers depends on the number of watchpoints configured. For non-implemented watchpoints, the
corresponding registers are RAZ.
The Vector Catch Register (DBGVCR) sets breakpoints on exception vectors as instruction
addresses.
The Watchpoint Fault Address Register (DBGWFAR) reads an address and a processor state
dependent offset, +8 for ARM and +4 for Thumb.
Cortex-R5 supports separate debug and core power domains to enable debug over power-down.
All accesses to core domain debug registers when the CPU is in Dormant or Shutdown modes
return an error response on the CPU APB interface.
For more information about these registers and the split between core domain and debug domain
registers, see the ARM Architecture Reference Manual.
The processor has the following reset signals that affect the processor debug logic:
nSYSPORESET
This signal resets all processor logic including the debug logic.
DBGRESETmn
This signal resets all the core domain debug logic.
PRESETDBGmn
This signal resets all debug domain debug logic.
See Resets on page 2-12 for more information on resets and reset requirements.
The restrictions for accessing the APB slave port are as follows:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-8
ID092411 Non-Confidential
Debug
When non-privileged software attempts to access the APB slave port, the system must ignore
the access or generate an error response to the access. You must implement this restriction at the
system level because the APB protocol does not have a privileged or user control signal. You
can choose to have the system either ignore the access or generate an error response.
You can place additional restrictions on memory transactions that are permitted to access the
APB port. However, ARM does not recommend this.
Locks permission
You can lock the APB slave port so that access to some debug registers is restricted. ARM
Architecture v7 defines two locks:
Software lock
The external debugger can set this lock to prevent software from modifying the
debug registers settings. A debug monitor can also set this lock prior to returning
control to the application to reduce the chance of erratic code changing the debug
settings. When this lock is set, writes to all debug registers are ignored, except
those generated by the external debugger, that override the lock. This is
summarized in Table 12-4. For more information, see Lock Access Register on
page 12-35.
Note
• These locks are set to their reset values only on reset of the debug logic, provided by
PRESETDBGmn.
• You must set the PADDRDBG31m input signal to 1 for accesses originated from the
external debugger for the Software Lock override feature to work.
Registers
PADDRDBG31m Lock
DBGDRCR, DBGPRCR,
Other Debug registers DBGLAR Other registers
DBGPRSR
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-9
ID092411 Non-Confidential
Debug
Term Description
RW Read or write.
SBZP Should-Be-Zero (SBZ) or Preserved (P). Must be written as 0 or preserved by writing the same value previously
read from the same fields on the same processor. These bits are usually reserved for future expansion.
Purpose Identifies the debug architecture version and specifies the number of
debug resources that the processor implements.
31 28 27 24 23 20 19 16 15 14 13 12 11 8 7 4 3 0
Debug architecture
SE_imp
version
PCSR_imp
nSUHD_imp
DEVID_imp
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-10
ID092411 Non-Confidential
Debug
[23:20] Context Number of Breakpoint Register Pairs (BRP) with context ID comparison capability:
b0000 = 1 BRP has context ID comparison capability.
[11:8] - RAZ.
[7: 4] Variant Implementation-defined variant [Link] is the major revision number n in the rn part
of the rnpn description of the product revision status.
[3: 0] Revision Implementation-defined revision number. This is the minor revision number n in the pn
part of the rnpn description of the product revision status.
The values of the following fields of the DBGDIDR agree with the values in CP15 c0, Main ID
Register:
• DBGDIDR[3:0] is the same as CP15 c0 bits [3:0]
• DBGDIDR[7:4] is the same as CP15 c0 bits [23:20].
See c0, Main ID Register on page 4-14 for more information of CP15 c0, Main ID Register.
The reason for duplicating these fields here is that the DBGDIDR is also accessible through the
APB slave port. This enables an external debugger to determine the variant and revision
numbers without stopping the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-11
ID092411 Non-Confidential
Debug
Purpose Returns a 32-bit Debug ROM Address Register value. This is the address
that indicates where in memory a debug monitor can locate the debug bus
ROM specified by the CoreSight™ multiprocessor trace and debug
architecture. Returns a 32-bit Debug ROM Address Register value. This
is the address that indicates where in memory a debug monitor can locate
the debug bus ROM specified by the CoreSight™ multiprocessor trace and
debug architecture.
31 12 11 2 1 0
Valid bits
[31:12] Debug bus ROM address Indicates bits [31:12] of the debug bus ROM address.
[11: 2] - SBZ.
Purpose The DBGDSAR is a read-only register that returns a 32-bit offset value
from the Debug ROM Address Register to the address of the CPU debug
registers. You can configure the address read in this register during
integration using the DBGSELFADDRm[31:12] and
DBGSELFADDRVm inputs. DBGSELFADDRVm must be tied off to 1
if DBGSELFADDRm[31:12] is tied off to a valid value.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-12
ID092411 Non-Confidential
Debug
31 12 11 2 1 0
Valid bits
[31:12] Debug bus self Indicates bits [31:12] of the two’s complement offset from the debug ROM physical
address offset value address to the physical address where the debug registers are mapped.
[1:0] Valid bits Reads b11 if DBGSELFADDRVm is set to 1, otherwise reads b00. DBGSELFADDRVm
must be set to 1 if DBGSELFADDRm[31:12] is set to a valid value.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-13
ID092411 Non-Confidential
Debug
Purpose Contains status and control information about the debug unit.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 2 1 0
MOE
Reserved SDABORT_l
Reserved
RXfull ADABORT_l
TXfull ExtDCCmode UND_l
Reserved ADAdiscard Reserved
PipeAdv Reserved DBGack
InstrCompl_l MDBGen INTdis
HDBGen UDCCdis
ITRen RESTARTED
HALTED
[25] PipeAdv Sticky pipeline advance read-only bit. This bit enables the debugger to detect whether the processor is
idle. In some situations, this might mean that the system bus port is deadlocked. This bit is set to 1 when
the processor pipeline retires one instruction. It is cleared by a write to DBGDRCR[3].
0 = no instruction has completed execution since the last time this bit was cleared
1 = an instruction has completed execution since the last time this bit was cleared.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-14
ID092411 Non-Confidential
Debug
[24] InstrCompl_l Instruction complete read-only bit. This flag determines whether the processor has completed
execution of an instruction issued through the APB port.
0 = processor is executing an instruction fetched from the DBGITR Register
1 = processor is not executing an instruction fetched from the DBGITR Register.
When the APB port reads the DBGDSCR and this bit is clear, then a subsequent write to the DBGITR
Register is ignored unless DBGDSCR[21:20] is not equal to 0. If DBGDSCR[21:20] is not equal to 0,
the DBGITR write stalls until the processor completes execution of the current instruction. If the
processor is not in debug state, then the value read for this flag is Unpredictable. The flag is set to 1 on
entry to debug state.
[21:20] ExtDCCmode DTR access mode. You can use this field to optimize DTR traffic between a debugger and the
processor.
b00 = Non-blocking mode, this is the reset value
b01 = Stall mode
b10 = Fast mode
b11 = Reserved.
Note
• This field only affects the behavior of DBGDSCRext, DBGDTRRXext, DBGDTRTXext, and
DBGITR accesses through the APB port, and not through CP14 debug instructions.
• Non-blocking mode is the default setting. Improper use of the other modes might result in the
debug access bus becoming deadlocked.
[19] ADAdiscard The Asynchronous Aborts Discarded bit is set when the processor is in debug state and is cleared on
exit from debug state. While this bit is set, the processor does not take asynchronous Data Aborts,
instead, the sticky asynchronous Data Abort bit is set to 1.
0 = do not discard asynchronous Data Aborts
1 = discard asynchronous Data Aborts and set ADABORT_I.
[17] SPNIDdis This bit is the inverse of bit [6] of the DBGAUTHSTATUS, see Authentication Status Register on
page 12-30.
[17] SPIDdis This bit is the inverse of bit [4] of the DBGAUTHSTATUS, see Authentication Status Register on
page 12-30.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-15
ID092411 Non-Confidential
Debug
[10] DbgAck Force Debug Acknowledge bit. If this bit is set to 1, the DBGACKm output signal is forced HIGH,
regardless of the processor state. The external debugger can optionally use this bit to execute pieces of
code in normal state as part of the debugging process for the system to behave as if the processor is in
debug state. Some systems rely on DBGACKm to determine whether data accesses are application or
debugger generated. This bit is 0 on reset.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-16
ID092411 Non-Confidential
Debug
You can use the ExtDCCmode field to optimize data transfer between a debugger and the
processor.
• reads from DBGDTRTXext are ignored, and return an Unpredictable value, if TXfull_l is
set to b0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-17
ID092411 Non-Confidential
Debug
• following a successful read from DBGDTRTXext, TXfull and TXfull_l are cleared to b0
• following a successful write to DBGITR, the internal flags InstrCompl and InstrCompl_l
are cleared to b0.
Debuggers accessing these registers must first read DBGDSCRext. This has the side-effect of
copying RXfull and TXfull to RXfull_l and TXfull_l. The debugger must then:
• write to the DBGDTRRXext if the RXfull flag was b0 (RXfull_l is b0)
• read from the DBGDTRTXext if the TXfull flag was b1 (TXfull_l is b1)
• write to the DBGITR if the InstrCompl_l flag was b1.
However, debuggers can issue both actions together and later determine from the read
DBGDSCR value whether the operations were successful.
In Stall mode, the APB accesses to DBGDTRRXext, DBGDTRTXext, and DBGITR stall under
the following conditions:
• writes to DBGDTRRXext are stalled until RXfull is cleared
• writes to DBGITR are stalled until InstrCompl is set
• reads from DBGDTRTXext are stalled until TXfull is set.
Fast mode is similar to Stall mode except that in Fast mode, the processor fetches an instruction
from the DBGITR when a DBGDTRRXext write or DBGDTRTXext read succeeds. In Stall
mode and Nonblocking mode, the processor fetches an instruction from the DBGITR when a
DBGITR write succeeds.
Note
Read and write are used with respect to the processor.
For information on the use of these registers with the TXfull flag and RXfull flag, see Debug
communications channel on page 12-55. The Data Transfer Register, bits [31:0] contain the data
to be transferred.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-18
ID092411 Non-Confidential
Debug
Table 12-10 shows how the bit values correspond with the DBGDTRRX and DBGDTRTX
functions.
[31:0] Data Reads the Data Transfer Register. This is read-only for the CP14 interface.
Note
Reads of the DBGDTRRXint through the coprocessor interface cause the TXfull flag to be cleared.
However, reads of the DBGDTRRXext through the APB port do not affect this flag.
[31:0] Data Writes the Data Transfer Register. This is write-only for the CP14 interface.
Note
Writes to the DBGDTRTXint through the coprocessor interface cause the RXfull flag to be set.
However, writes to the DBGDTRTXext through the APB port do not affect this flag.
Purpose Holds the address of the instruction that triggers the watchpoint.
31 1 0
Address
Reserved
[31:1] Address This is the address of the watchpointed instruction. When a watchpoint occurs in ARM state, the
DBGWFAR contains the address of the instruction causing it plus an offset of 0x8. When a
watchpoint occurs in Thumb state, the offset is plus 0x4.
[0] - RAZ.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-19
ID092411 Non-Confidential
Debug
Usage constraints • If one of the bits in this register is set and the instruction at the
corresponding vector is committed for execution, the processor
either enters debug state or takes a debug exception.
• Under this model, any prefetch from an exception vector can trigger
a vector catch, not only the ones because of exception entries. An
explicit branch to an exception vector might generate a vector catch
debug event.
• If any of the bits are set when the processor is in Monitor
debug-mode, then the processor ignores the setting and does not
generate a vector catch debug event. This prevents the processor
entering an unrecoverable state. The debugger must program these
bits to zero when Monitor debug-mode is selected and enabled to
ensure forward-compatibility.
31 8 7 6 5 4 3 2 1 0
Reserved
Reset
Undefined
SVC
Prefetch abort
Data abort
Reserved
IRQ
FIQ
[4] Data Abort 0 0x00000010 0xFFFF0010 Vector catch enable, data abort. RW
[3] Prefetch Abort 0 0x0000000C 0xFFFF000C Vector catch enable, prefetch abort. RW
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-20
ID092411 Non-Confidential
Debug
a. If the VIC interface is enabled, the address is the last IRQ handler address supplied by the VIC, whether or not high vectors are in use.
Purpose Controls the L1 cache behavior when the processor is in debug state.
Usage constraints For information on the usage model of the DBGDSCCR register, see
Cache debug on page 12-50.
31 3 2 1 0
Reserved
Not write-through
Instruction cache line-fill
Data cache line-fill
Reset
Bits Name Function
value
[31:3] - 0 Reserved. Do not modify on writes. On reads, the value returns zero.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-21
ID092411 Non-Confidential
Debug
The DBGITR enables the external debugger to feed instructions into the processor for execution
while in debug state. The DBGITR is a write-only register. Reads from the DBGITR return an
Unpredictable value.
The Instruction Transfer Register, bits [31:0] contain the ARM instruction for the processor to
execute while in debug state. The reset value of this register is Unpredictable.
Note
Writes to the DBGITR when the processor is not in debug state or the DBGDSCR[13] execute
instruction enable bit is cleared are Unpredictable. When an instruction is issued to the
processor, the debug unit prevents the next instruction from being issued until the
DBGDSCR[25] instruction complete bit is set.
31 5 4 3 2 1 0
Reserved
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-22
ID092411 Non-Confidential
Debug
[31:5] - RAZ.
[4] Cancel memory If 1 is written to this bit, the processor abandons any pending memory transactions until it can enter
requests debug state. Debug state entry is the acknowledge event that clears this request. Abandoned transactions
have the following behavior:
• abandoned stores might write an Unpredictable value to the target address
• abandoned loads return an Unpredictable value to the register bank.
An abandoned transaction does not cause any exception. Additional instruction fetches or data accesses
after the processor entered debug state have an Unpredictable behavior.
This bit enables the debugger to progress on a deadlock so the processor can enter debug state. For a
debug state entry to occur, a halting debug event must be requested before this bit is set. If you write a 1
to this bit when DBGENm is LOW, the write has no effect.a
[1] Restart request Writing a 1 to this bit requests that the processor leaves debug state. This request is held until the
processor exits debug state. When the debugger makes this request, it polls DBGDSCR[1] until it reads
1. This bit always reads as zero. Writes are ignored when the processor is not in debug state.
[0] Halt request Writing a 1 to this bit triggers a halting debug event, that is, a request that the processor enters debug
state. This request is held until the debug state entry occurs. When the debugger makes this request, it
must poll DBGDSCR[0] until it reads 1. This bit always reads as zero. Writes are ignored when the
processor is already in debug state.
a. Entry into debug state is not expected to be recoverable.
Each DBGBVR is associated with a Breakpoint Control Register (DBGBCR). DBGBCRy is the
corresponding control register for DBGBVRy.
The breakpoint value contained in this register corresponds to either an instruction address or a
context ID. Breakpoints can be set on:
• an instruction address
• a context ID value
• an instruction address and context ID pair.
For an instruction address and context ID pair, two BRPs must be linked. A debug event is
generated when both the instruction address and the context ID pair match at the same time.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-23
ID092411 Non-Confidential
Debug
Table 12-15 shows how the bit values correspond with the Breakpoint Value Registers
functions.
Note
• Only BRPn supports context ID comparison, where n+1 is the number of breakpoint
register pairs implemented in the processor.
• Bits [1:0] of Registers DBGBVR0 to DBGBVR(n-1) are Do Not Modify on writes and
Read-As-Zero because these registers do not support context ID comparisons.
• The contents of the CP15 Context ID Register give the context ID value for a DBGBVR
to match. For information on the Context ID Register, see Chapter 4 System Control.
31 29 28 24 23 22 20 19 16 15 14 13 9 8 5 4 3 2 1 0
Byte
Breakpoint
M Linked BRP Reserved address S B
address mask
select
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-24
ID092411 Non-Confidential
Debug
[28:24] Breakpoint This field sets a breakpoint on a range of addresses by masking lower order address bits out of the
address mask breakpoint comparison.a
b00000 = no mask
b00001 = Reserved
b00010 = Reserved
b00011 = 0x00000007 mask for instruction address
b00100 = 0x0000000F mask for instruction address
b00101 = 0x0000001F mask for instruction address
...
b11111 = 0x7FFFFFFF mask for instruction address.
[23] - -
[19:16] Linked BRP The binary number encoded here indicates another BRP to link this one with.
number
Note
• if a BRP is linked with itself, it is Unpredictable whether a breakpoint debug event is generated
• if this BRP is linked to another BRP that is not configured for linked context ID matching, it is
Unpredictable whether a breakpoint debug event is generated.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-25
ID092411 Non-Confidential
Debug
[8:5] Byte address For breakpoints programmed to match an instruction address, the debugger must write a word-aligned
select address to the DBGBVR. You can then use this field to program the breakpoint so it hits only if certain
byte addresses are accessed.b
If the BRP is programmed for instruction address match:
b0000 = the breakpoint never hits
bxxx1 = the breakpoint hits if the byte at address (DBGBVR & 0xFFFFFFFC) +0 is accessed
bxx1x = the breakpoint hits if the byte at address (DBGBVR & 0xFFFFFFFC) +1 is accessed
bx1xx = the breakpoint hits if the byte at address (DBGBVR & 0xFFFFFFFC) +2 is accessed
b1xxx = the breakpoint hits if the byte at address (DBGBVR & 0xFFFFFFFC) +3 is accessed
b1111 = the breakpoint hits if any of the four bytes starting at address (DBGBVR & 0xFFFFFFFC) +0 is
accessed.
If the BRP is programmed for instruction address mismatch, the breakpoint hits where the corresponding
instruction address breakpoint does not hit, that is, the range of addresses covered by an instruction
address mismatch breakpoint is the negative image of the corresponding instruction address breakpoint.
If the BRP is programmed for context ID comparison, this field must be set to b1111. Otherwise,
breakpoint and watchpoint debug events might not be generated as expected.
[4:3] - -
[2:1] S Supervisor access control. The breakpoint can be conditioned on the mode of the processor:
b00 = User, System, or Supervisor
b01 = Privileged
b10 = User
b11 = any.
DBGBVR[22:20] Meaning
b000 The corresponding DBGBVR[31:2] is compared against the instruction address bus and the state of the
processor against this DBGBCR. It generates a breakpoint debug event on a joint instruction address and state
match.
b001 The corresponding DBGBVR[31:2] is compared against the instruction address bus and the state of the
processor against this DBGBCR. This BRP is linked with the one indicated by DBGBCR[19:16] linked BRP
field. They generate a breakpoint debug event on a joint instruction address, context ID, and state match.
b010 The corresponding DBGBVR[31:0] is compared against CP15 Context ID Register, c13 and the state of the
processor against this DBGBCR. This BRP is not linked with any other one. It generates a breakpoint debug
event on a joint context ID and state match. For this BRP, DBGBCR[8:5] must be set to b1111. Otherwise it is
Unpredictable whether a breakpoint debug event is generated.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-26
ID092411 Non-Confidential
Debug
DBGBVR[22:20] Meaning
b011 The corresponding DBGBVR[31:0] is compared against CP15 Context ID Register, c13. This BRP links
another BRP (of the DBGBCR[21:20]=b01 type), or WRP (with DBGWCR[20]=b1). They generate a
breakpoint or watchpoint debug event on a joint instruction address or data address and context ID match. For
this BRP, DBGBCR[8:5] must be set to b1111, DBGBCR[15:14] must be set to b00, and DBGBCR[2:1] must
be set to b11. Otherwise it is Unpredictable whether a breakpoint debug event is generated.
b100 The corresponding DBGBVR[31:2] and DBGBCR[8:5] are compared against the instruction address bus and
the state of the processor against this DBGBCR. It generates a breakpoint debug event on a joint instruction
address mismatch and state match.
b101 The corresponding DBGBVR[31:2] and DBGBCR[8:5] are compared against the instruction address bus and
the state of the processor against this DBGBCR. This BRP is linked with the one indicated by DBGBCR[19:16]
linked BRP field. It generates a breakpoint debug event on a joint instruction address mismatch, state and
context ID match.
The watchpoint value contained in the DBGWVR always corresponds to a data address and can
be set either on:
• a data address
• a data address and context ID pair.
For a data address and context ID pair, a WRP and the BRP with context ID comparison
capability must be linked. A debug event is generated when both the data address and the
context ID pair match simultaneously.
Bits Function
[1:0] Reserved. Do not modify on writes. On reads, the value returns zero.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-27
ID092411 Non-Confidential
Debug
31 29 28 24 23 21 20 19 16 15 14 13 12 5 4 32 1 0
Watchpoint
E Linked BRP Byte address select L/S
L/S SP W
address mask
Reserved
[28:24] Watchpoint This field watches a range of addresses by masking lower order address bits out of the watchpoint
address comparison.
mask b00000 = no mask
b00001 = Reserved
b00010 = Reserved
b00011 = 0x00000007 mask for data address
b00100 = 0x0000000F mask for data address
b00101 = 0x0000001F mask for data address
...
b11111 = 0x7FFFFFFF mask for data address.
Note
• If DBGWCR[28:24] is not set to b00000, then DBGWCR[12:5] must be set to b11111111. Otherwise
the behavior is Unpredictable.
• If DBGWCR[28:24] is not set to b00000, then the corresponding DBGWVR bits that are not being
included in the comparison Should Be Zero. Otherwise the behavior is Unpredictable.
• To watch for a write to any byte in an 8-byte aligned object of size 8 bytes, ARM recommends that a
debugger sets DBGWCR[28:24] to b00111, and DBGWCR[12:5] to b11111111. This is compatible
with both ARMv7 debug compliant implementations that have an 8-bit DBGWCR[12:5] and with
those that have a 4-bit DBGWCR[8:5] byte address select field.
[19:16] Linked Linked BRP number. The binary number encoded here indicates a context ID holding BRP to link this WRP
BRP with. If this WRP is linked to a BRP that is not configured for linked context ID matching, it is Unpredictable
whether a watchpoint debug event is generated.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-28
ID092411 Non-Confidential
Debug
[12:5] Byte The DBGWVR is programmed with word-aligned address. You can use this field to program the watchpoint
address so it only hits if certain byte addresses are accessed:
select b00000000 The watchpoint never hits.
bxxxxxxx1 The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFFC) +0 is accessed.
bxxxxxx1x The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFFC) +1 is accessed.
bxxxxx1xx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFFC) +2 is accessed.
bxxxx1xxx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFFC) +3 is accessed.
bxxx1xxxx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFF8) +4 is accessed.
bxx1xxxxx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFF8) +5 is accessed.
bx1xxxxxx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFF8) +6 is accessed.
b1xxxxxxx The watchpoint hits if the byte at address (DBGWVR[31:0] & 0xFFFFFFF8) +7 is accessed.
[4:3] L/S Load/store access. The watchpoint can be conditioned to the type of access:
b00 = Reserved
b01 = load, load exclusive, or swap
b10 = store, store exclusive or swap
b11 = either.
A SWP or SWPB triggers on load, store, or either. A load exclusive instruction triggers on load or either. A store
exclusive instruction triggers on store or either, whether it succeeds or not.
[2:1] S Privileged access control. The watchpoint can be conditioned to the privilege of the access:
b00 = reserved
b01 = Privileged, match if the processor does a privileged access to memory
b10 = User, match only on non-privileged accesses
b11 = either, match all accesses.
Note
For all cases, the match refers to the privilege of the access, not the mode of the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-29
ID092411 Non-Confidential
Debug
31 1 0
Reserved
[31:1] - RAZ.
[0] Lock implemented bit Indicates whether the OS lock functionality is implemented:
0 = OS lock not implemented.
Purpose Reads the current values of the configuration inputs that determine the
debug permission level.
31 8 7 6 5 4 3 0
Reserved
[31:8] - - RAZ
[6] Secure non-invasive debug features enabled DBGENm || NIDENm Non-invasive debug enable field
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-30
ID092411 Non-Confidential
Debug
[4] Secure invasive debug features enabled DBGENm Invasive debug enable field
a. The Cortex-R5 processor does not implement the Security Extensions, so all the debug features are considered secure.
Usage constraints The DBGPRCR Register is read-write with more restricted access to some
bits.
31 3 2 1 0
Reserved
[2] Hold internal Hold internal reset bit. This bit can be used to prevent the processor from running again before the debugger
reset detects a power-down event and restores the state of the debug registers in the processor. This bit does not
have any effect on initial system power-up, because nSYSPORESET clears it.
0 = Do not hold internal reset on power-up or warm reset. This is the reset value.
1 = Hold the processor non-debug logic in reset on warm reset until this flag is cleared.
[1] Force When a 1 is written to this bit, the processor asserts the DBGRSTREQm output for four cycles. You can
internal reset connect this output to an external reset controller that, in turn, resets the processor.
[0] No When set to 1, the DBGNOPWRDWN output signal is HIGH. This output connects to the system power
power-down controller and is interpreted as a request to operate in emulate mode, if the system supports this functionality.
In this mode, the processor is not actually powered down when requested by software or hardware
handshakes. This mode is useful when debugging applications on top of working operating systems.
0 = DBGNOPWRDWN is LOW. This is the reset value
1 = DBGNOPWRDWN is HIGH.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-31
ID092411 Non-Confidential
Debug
Purpose Provides information about the reset and power-down state of the
processor.
Usage constraints The DBGPRSR Register is a read-only register, with reads of the register
also resetting some register bits.
31 4 3 2 1 0
Reserved
[3] Sticky reset status Sticky reset status bit. This bit is cleared on read.
0 = the processor has not been reset since the last time this register was read. This is the reset value.
1 = the processor has been reset since the last time this register was read.
This sticky bit is set to 1 when nRESETm is asserted. This bit is reset to 0 by PRESETDBGmn.
[1] Sticky power-down Indicates if the core power domain has been powered down since the DBGPRCR was last read.
statusa 0 = the CPU has not been powered down since the last read. This is the reset value.
1 = the CPU has been powered down since the last read.
If this bit is 1:
• The contents of the core domain debug registers have been lost and must be reprogrammed.
• Debug-APB transactions that access core domain debug registers receive an error response.
This bit is cleared to 0 on a read.
[0] Power-up statusa Indicates the status of the core power domain.
0 = the CPU is powered-down, that is, it is in Dormant or Shutdown mode. Core-domain debug
registers cannot be accessed.
1 = the CPU is powered-up, that is, it is in Run or Standby mode. All debug registers can be accessed.
a. If you are implementing a Split/Lock configuration, contact ARM for more information about the functionality of this bit.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-32
ID092411 Non-Confidential
Debug
Table 12-24 shows the contents of the Management Registers for the processor debug unit.
Offset Register
Access Mnemonic Function
(hex) number
0xFA0 1000 DBGCLAIMSET See Claim Tag Set Register on page 12-34.
0xFA4 1001 DBGCLAIMCLR See Claim Tag Clear Register on page 12-35.
The Processor ID Registers are read-only registers that return the same values as the
corresponding CP15 Main ID Register and Feature ID Registers. See Chapter 4 System Control
for more information about the information contained in these registers.
Table 12-25 shows the offset value, register number, mnemonic, and description that are
associated with each Process ID Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-33
ID092411 Non-Confidential
Debug
The Claim Tag Set Register and the Claim Tag Clear Register enable an external debugger to
claim debug resources.
31 8 7 0
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-34
ID092411 Non-Confidential
Debug
Writing b1 to a specific claim tag set bit sets that claim tag. Writing b0 to a specific claim tag
bit has no effect. This register always reads 0xFF, indicating eight claim tags are implemented.
31 8 7 0
The DBGLAR is a write-only register that controls writes to the debug registers. The purpose
of the DBGLAR is to reduce the risk of accidental corruption to the contents of the debug
registers. It does not prevent all accidental or malicious damage. Because the state of the
DBGLAR is in the debug power domain, it is not lost when the processor powers down.
DBGLAR [31:0] contain a key that controls the lock status. To unlock the debug registers, write
a 0xC5ACCE55 key to this register. To lock the debug registers, write any other value. Accesses to
locked debug registers are ignored. The lock is set on reset.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-35
ID092411 Non-Confidential
Debug
31 3 2 1 0
Reserved
32-bit access
Locked bit
Lock implemented bit
[2] 32-bit access Indicates that a 32-bit access is required to write the key to the DBGLAR. This bit always reads 0.
[0] Lock implemented bit Indicates that the OS lock functionality is implemented. This bit always reads 1.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-36
ID092411 Non-Confidential
Debug
31 8 7 4 3 0
[7:4] Subtype 0x1, indicates that the sub-type of the device is processor.
[3:0] Main class 0x5, indicates that the main class of the device is debug logic.
The Debug Identification Registers are read-only registers that consist of the Peripheral
Identification Registers and the Component Identification Registers. The Peripheral
Identification Registers provide standard information that all CoreSight components require.
Only bits [7:0] of each register are used. The remaining bits Read-As-Zero.
The Component Identification Registers identify the processor as a CoreSight component. Only
bits [7:0] of each register are used, the remaining bits Read-As-Zero. The values in these
registers are fixed.
Table 12-30 shows the offset value, register number, and description that are associated with
each Peripheral Identification Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-37
ID092411 Non-Confidential
Debug
Table 12-31 shows fields that are in the Peripheral Identification Registers.
4KB Count 4 bits Indicates the Log2 of the number of 4KB blocks occupied by the debug device. The processor debug
registers occupy a single 4KB block, therefore this field is always 0x0.
JEP106 4+7 bits Identifies the designer of the processor. This field consists of a 4-bit continuation code and a 7-bit identity
Identity Code code. Because the processor is designed by ARM, the continuation code is 0x4 and the identity code is
0x3B. For more information see JEP106M, Standard Manufacture’s Identification Code.
Part number 12 bits Indicates the part number of the processor. The part number for the processor is 0xC15.
Revision 4 bits Indicates the major and minor revision of the product. The major revision contains functionality changes
and the minor revision contains bug fixes for the product. The revision number starts at 0x0 and increments
by 1 at both major and minor revisions:
0x0 = r0p0
0x1 = r1p0
0x2 = r1p1
0x3 = r1p2.
RevAnd 4 bits Indicates the manufacturer revision number. This number starts at 0x0 and increments by the integrated
circuit manufacturer on metal fixes. For the Cortex-R5 processor, the initial value is 0x0 but this value can
be changed by the manufacturer.
Customer 4 bits Indicates an endorsed modification to the device. On this processor the value is always 0x0.
modified
Table 12-32 shows how the bit values correspond with the Peripheral ID Register 0 functions.
[31:8] - Reserved
[7:0] 0x15 Indicates bits [7:0] of the Part number for the processor
Table 12-33 shows how the bit values correspond with the Peripheral ID Register 1 functions.
[31:8] - Reserved
[7:4] 0xB Indicates bits [3:0] of the JEDEC JEP106 Identity Code
[3:0] 0xC Indicates bits [11:8] of the Part number for the processor
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-38
ID092411 Non-Confidential
Debug
Table 12-34 shows how the bit values correspond with the Peripheral ID Register 2 functions.
[31:8] - Reserved.
[7:4] - Indicates the revision number for the Cortex-R5 processor. This is the major revision number n in the
rn part of the rnpn description of the product revision status.
[3] 0x1 This field is always set to 1. It indicates that the processor uses a JEP 106 identity code.
[2:0] 0x3 Indicates bits [6:4] of the JEDEC JEP106 Identity Code.
Table 12-35 shows how the bit values correspond with the Peripheral ID Register 3 functions.
[31:8] - Reserved.
[7:4] 0x0 Indicates the manufacturer revision number. This value changes based on the metal fixes made by the manufacturer.
Table 12-36 shows how the bit values correspond with the Peripheral ID Register 4 functions.
[31:8] - Reserved.
[7:4] 0x0 Indicates the number of blocks the debug component occupies. This field is always set to 0.
[3:0] 0x4 Indicates the JEDEC JEP106 continuation code. For the processor, this value is 4.
Table 12-37 shows the offset value, register number, and value that are associated with each
Component Identification Register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-39
ID092411 Non-Confidential
Debug
• A BKPT debug event. This occurs when a BKPT instruction is committed for execution.
BKPT is an unconditional instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-40
ID092411 Non-Confidential
Debug
The debugger or the system can cause the processor to enter into debug state by triggering any
of the following halting debug events:
• assertion of the EDBGRQm signal, an External Debug Request
• write to the DBGDRCR[0] Halt Request control bit.
When EDBGRQm is asserted while DBGENm is HIGH, the device asserting this signal must
hold it until the processor enters debug state, that is, until DBGACKm is asserted. The state of
the processor pipeline determines how long this takes. If the request is not held in this way, the
behavior of the processor is Unpredictable. For DBGDRCR[0] halting debug events, the
processor records them internally until it is in a state and mode so that they can be taken.
This section describes how the processor behaves on debug events while not in debug state. See
Debug state on page 12-45 for information on how the processor behaves while in debug state.
When the processor is in Monitor debug-mode, Prefetch Abort and Data Abort vector catch
debug events are ignored. All other software debug events generate a debug exception such as
Data Abort for watchpoints, and Prefetch Abort for anything else.
When debug is disabled, the BKPT instruction generates a debug exception, Prefetch Abort. All
other software debug events are ignored.
1 b00 None Ignore or Prefetch Abort (for BKPT) Debug state entry
Breakpoint, instruction address or CID match, vector catch, and halting debug events have the
same priority. If more than one of these events occurs on the same instruction, it is
Unpredictable which event is taken.
Breakpoint, instruction address or CID match and vector catch cancel the instruction that they
occur on, therefore a watchpoint cannot be taken on such an instruction.
If the watchpointed access is subject to a synchronous data abort, then the synchronous abort
takes priority over the watchpoint because it is a higher priority exception.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-41
ID092411 Non-Confidential
Debug
• sets the CP15 IFSR and IFAR registers as described in Effect of debug exceptions on CP15
registers and DBGWFAR on page 12-43
Note
The Prefetch Abort handler is responsible for checking the IFSR to determine if a debug
exception or other kind of Prefetch Abort exception caused the exception entry. If the cause is
a debug exception, the Prefetch Abort handler must branch to the debug monitor. The R14_abt
register holds the address of the instruction to restart.
If the processor takes a debug exception because of a watchpoint debug event, the processor
performs the following actions:
• sets the CP15 DFSR, DFAR, and DBGWFAR registers as described in Effect of debug
exceptions on CP15 registers and DBGWFAR on page 12-43
Note
The Data Abort handler must check the DFSR to determine if the exception entry was caused
by a Debug exception or other kind of Data Abort exception. If the cause is a Debug exception,
the Data Abort handler must branch to the debug monitor. The R14_abt register holds the
address of the instruction to restart.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-42
ID092411 Non-Confidential
Debug
Table 12-39 shows the values in the link register after exceptions.
Prefetch Abort RA+4 RA+4 Address of the instruction where the execution can resume
Data Abort RA+8 RA+8 Address of the instruction where the execution can resume
a. This is the address of the instruction that the processor can execute first on debug exception return. The
address of the access that hit the watchpoint is in the DBGWFAR.
If the processor takes a debug exception because of a watchpoint debug event, the processor
performs the following actions on these registers:
• it updates the DBGWFAR with the address of the instruction that accessed the
watchpointed address, plus a processor state dependent offset:
— + 8 for ARM state
— + 4 for Thumb state.
If the processor takes a debug exception because of a breakpoint, BKPT, or vector catch debug
event, the processor performs the following actions on these registers:
• it updates the IFSR with the debug event encoding
• it writes an Unpredictable value to the IFAR
• it does not change the DFSR, DFAR, or DBGWFAR.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-43
ID092411 Non-Confidential
Debug
The processor ignores vector catch debug events on the Prefetch or Data Abort vectors while in
Monitor debug-mode because these events would otherwise put the processor in an
unrecoverable state.
The debuggers must avoid other similar cases by following these rules, that apply only if the
processor is in Monitor debug-mode:
The debugger must write DBGBCR[2:1] for the same breakpoint as either b00 or b10, that
selects either match in only USR, SYS, or SVC modes or match in only USR mode,
respectively. The debugger must not program either b01, that is, match in any Privileged mode,
or b11, that is, match in any mode.
You must only request the debugger to write b00 to DBGBCR[2:1] if you know that the abort
handler does not switch to one of the USR, SYS, or SVC mode before saving the context that
might be corrupted by a later debug event. You must also be careful about requesting the
debugger to set a breakpoint or BKPT debug event inside a Prefetch Abort or Data Abort
handler, or a watchpoint debug event on a data address that any of these handlers might access.
In general, you must only set breakpoint or BKPT debug events inside an abort handler after it
saves the abort context. You can avoid breakpoint debug events in abort handlers by setting
DBGBCR[2:1] as previously described.
If the code being debugged is not running in a Privileged mode, you can prevent watchpoint
debug events in abort handlers by setting DBGWCR[2:1] to b10 for match only non-privileged
accesses.
Failure to follow these guidelines can lead to debug events occurring before the handler is able
to save the context of the abort. This causes the corresponding registers to be overwritten, and
results in Unpredictable software behavior.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-44
ID092411 Non-Confidential
Debug
When a debug event occurs while the processor is in Halting debug-mode, it switches to a
special state called debug state so the debugger can take control. You can configure Halting
debug-mode by setting DBGDSCR[14].
If a halting debug event occurs, the processor enters debug state even when Halting debug-mode
is not configured. While the processor is in debug state, the PC does not increment on instruction
execution. If the PC is read at any point after the processor has entered debug state, but before
an explicit PC write, it returns a value as described in Table 12-40, depending on the previous
state and the type of debug event.
Table 12-40 shows the read PC value after debug state entry for different debug events.
External debug request signal activation RA+8 RA+4 Address of the instruction where the execution resumes.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-45
ID092411 Non-Confidential
Debug
Debug state entry request command RA+8 RA+4 Address of the instruction where the execution resumes.
OS unlock event RA+8 RA+4 Address of the instruction where the execution resumes.
CTI debug request signal RA+8 RA+4 Address of the instruction where the execution resumes.
The behavior of the PC and CPSR registers while the processor is in debug state is as follows:
• The PC is frozen on entry to debug state. That is, it does not increment on the execution
of ARM instructions. However, the processor still updates the PC as a response to
instructions that explicitly modify the PC.
• If the PC is read after the processor has entered debug state, it returns a value as described
in Table 12-40 on page 12-45, depending on the previous state and the type of debug
event.
• If the debugger executes a sequence for writing a certain value to the PC and subsequently
it forces the processor to restart without any additional write to the PC or CPSR, the
execution starts at the address corresponding to the written value.
• If the debugger forces the processor to restart without having performed a write to the PC,
the restart address is Unpredictable.
• If the debugger writes to the CPSR, subsequent reads from the PC return an Unpredictable
value, and if it forces the processor to restart without having performed a write to the PC,
the restart address is Unpredictable. However, CPSR reads after a CPSR write return the
written value.
• If the debugger writes to the PC, subsequent reads from the PC return an Unpredictable
value.
• If the debugger forces the processor to execute an instruction that writes to the PC and this
instruction fails its condition codes, the PC is written with an Unpredictable value. That
is, if the debugger forces the processor to restart, the restart address is Unpredictable.
Also, if the debugger reads the PC, the read value is Unpredictable.
• While the processor is in debug state, the CPSR does not change unless written to by an
instruction. In particular, the CPSR IT execution state bits do not change on instruction
execution. The CPSR IT execution state bits do not have any effects on instruction
execution.
• If the processor executes a data processing instruction with Rd==R15 and S==0, then
alu-out[0] must equal the current value of the CPSR T bit, otherwise the processor
behavior is Unpredictable.
In debug state, the processor executes instructions issued through the Instruction Transfer
Register (DBGITR). Before the debugger can force the processor to execute any instruction, it
must enable this feature through DBGDSCR[13].
While the processor is in debug state, it always decodes instructions from the DBGITR as per
the ARM instruction set, regardless of the value of the T and J bits of the CPSR.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-46
ID092411 Non-Confidential
Debug
The following restrictions apply to instructions executed through the DBGITR while in debug
state:
• with the exception of branch instructions and instructions that modify the CPSR, the
processor executes any ARM instruction in the same manner as if it was not in debug state
• instructions that load a value into the PC from memory are Unpredictable.
The only instruction that can update the CPSR while in debug state is the MSR instruction. All
other ARMv7 instructions that write to the CPSR are Unpredictable, that is, the BX, BXJ, SETEND,
CPS, RFE, LDM(exception return), and data processing instructions with Rd==R15 and S==1.
The behavior of the CPSR forms of the MSR and MRS instructions in debug state is different to their
behavior in normal state:
• When not in debug state, an MSR instruction that modifies the execution state bits in the
CPSR is Unpredictable. However, in debug state an MSR instruction can update the
execution state bits in the CPSR. An Instruction Synchronization Barrier (ISB) sequence
must follow a direct modification of the execution state bits in the CPSR by an MSR
instruction.
• When not in debug state, an MRS instruction reads the CPSR execution state bits as zeros.
However, in debug state an MRS instruction returns the actual values of the execution state.
The debugger must execute an ISB sequence after it writes to the CPSR execution state bits using
an MSR instruction. If the debugger reads the CPSR using an MRS instruction after a write to any
of these bits, but before an ISB sequence, the value that MRS returns is Unpredictable. Similarly,
if the debugger forces the processor to leave debug state after an MSR writes to the execution state
bits, but before any ISB sequence, the behavior of the processor is Unpredictable.
12.8.5 Privilege
When the processor is in debug state, ARM instructions issued through the DBGITR are subject
to different rules about whether they can perform privileged actions. The general rule is that all
instructions and operations are permitted in debug state.
The processor always accesses register banks and memory as indicated by the CPSR mode bits,
in both normal and debug state. For example, if the CPSR mode bits indicate the processor is in
User mode, ARM register reads and returns the User mode banked registers, and memory
accesses are presented to the MPU as not privileged.
CP14 and CP15 instructions can always be executed in debug state regardless of processor
mode.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-47
ID092411 Non-Confidential
Debug
The processor non-invasive debug features are the ETM and Performance Monitoring Unit
(PMU). All of these non-invasive debug features are disabled when the processor is in debug
state. For more information, see Chapter 4 System Control and ETM interface on page 2-11.
On entry to debug state, the processor does not update any general-purpose or program status
register. This includes the SPSR_abt and R14_abt registers. In addition, the processor does not
update any coprocessor registers, including the CP15 IFSR, DFSR, DFAR, or IFAR registers,
except for CP14 DBGDSCR[5:2] method-of-entry bits. These bits indicate the type of debug
event that caused the entry into debug state.
Note
On entry to debug state because of a watchpoint debug event, the processor updates the
DBGWFAR register with the address of the instruction accessing the watchpointed address
plus:
• + 8 in ARM state
• + 4 in Thumb state.
Reset This exception is taken as in a normal processor state. This means the processor
leaves debug state because of the system reset.
Prefetch Abort
This exception cannot occur because the processor does not fetch any instructions
while in debug state.
Undefined When an Undefined Instruction exception occurs in debug state, the behavior of
the processor is as follows:
• PC, CPSR, SPSR_und, and R14_und are unchanged
• the processor remains in debug state
• DBGDSCR[8], sticky Undefined bit, is set.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-48
ID092411 Non-Confidential
Debug
• DFSR and DFAR are set to the same values as if the abort had occurred in
normal state.
On entering debug state, the processor executes a Data Synchronization Barrier (DSB)
sequence to ensure that any outstanding asynchronous Data Aborts are detected, before starting
debug operations.
If the DSB operation detects an asynchronous Data Abort, the processor records this event and
its type as if the CPSR A bit was set. The purpose of latching this event is to ensure that it can
be taken on exit from the debug state.
Before forcing the processor to leave debug state, the debugger must execute a DSB sequence
to ensure that all debugger-generated asynchronous Data Aborts are detected, and therefore
discarded, while still in debug state. After exiting debug state, the processor acts on any
previously recorded asynchronous Data Aborts if permitted by the CPSR A bit.
4. Drives the DBGACKm signal LOW, unless the DBGDSCR[11] DbgAck bit is set to 1.
5. Starts executing instructions from the address last written to the PC in the processor mode
and state indicated by the current value of the CPSR. The CPSR IT execution state bit is
restarted with the current value applying to the first instruction on restart.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-49
ID092411 Non-Confidential
Debug
If bit [0] of the Debug State Cache Control Register (DBGDSCCR) is set to 0 while the
processor is in debug state, then the L1 data cache does not perform any line fill.
Note
No special feature is required to prevent L1 instruction cache pollution because instruction side
fetches cannot occur while in debug state.
The debugger can maintain cache coherency in both these situations with the following features:
• If bit [2] of the DBGDSCCR is set to 0 while the processor is in debug state, then the
processor treats any memory access that hits in L1 data cache as write-through, regardless
of the memory region attributes. This guarantees that the L1 instruction cache can see the
changes to the code region without the debugger executing a sequence of cache clean
operations.
• After the code is written to memory, the debugger can execute either a CP15 instruction
cache invalidate all operation, or a CP15 instruction cache invalidate line operation.
Note
The processor can normally execute CP15 instruction cache invalidate all operation or CP15
instruction cache invalidate line operation only in Privileged mode. However, in debug state the
processor can execute these instructions even when invasive debug is not permitted in
Privileged mode. This exception to the rule enables the debugger to maintain coherency.
You can obtain cache usage profiling information using the Performance Monitoring Unit
(PMU). The processor can count cache accesses and misses over a period of time. See Chapter 6
Events and Performance Monitor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-50
ID092411 Non-Confidential
Debug
The APB slave ports are compliant with the AMBA 3 APB Protocol Specification and can be
connected to the Debug Access Port (DAP). This APB slave interface supports 32-bits wide
data, stalls, slave-generated aborts, and ten address bits [11:2] mapping 4KB of memory. An
extra PADDRDBG31m signal indicates to the CPU the source of access.
Table A-21 on page A-26 shows the external debug interface signals.
EDBGRQm
This signal generates a halting debug event, that is, it requests the CPU to enter debug state.
When this occurs, the DBGDSCR[5:2] method-of-debug entry bits are set to b0100. When
EDBGRQm is asserted, it must be held until DBGACKm is asserted. Failure to do so leads to
Unpredictable behavior of the processor.
DBGACKm
The CPU asserts DBGACKm to indicate that the system has entered debug state. It serves as a
handshake for the EDBGRQm signal. The DBGACKm signal is also driven HIGH when the
debugger sets the DBGDSCR[10] DbgAck bit to 1.
DBGNOPWRDWN
The CPU asserts DBGNOPWRDWN when bit [0] of the Device Power down and Reset
Control Register is 1 in either CPU. The processor power controller must work in Emulate mode
when this signal is HIGH.
DBGROMADDR
The DBGROMADDR signal specifies bits [31:12] of the debug ROM physical address. This
is a configuration input and must be tied off or only change while the processor is in reset. In a
system with multiple debug ROMs, this address must be tied off to point to the top-level ROM
address.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-51
ID092411 Non-Confidential
Debug
DBGSELFADDRm
The DBGSELFADDRm signal specifies bits [31:12] of the offset from the debug ROM
physical address to the physical address where the CPU APB port is mapped to the base of the
4KB debug register map. This is a configuration input and must be tied off or only change while
the CPU is in reset.
DBGRESTARTm
The DBGRESTARTm signal is used to bring the CPU out of debug halt state. The CPU
acknowledges DBGRESTARTm by asserting DBGRESTARTEDm, and then starts fetching
instructions when DBGRESTARTm is deasserted.
DBGRESTARTEDm
DBGTRIGGERm
The CPU asserts DBGTRIGGERm to indicate that the system has accepted a debug request
and attempts to enter debug state. It is not a handshake for the EDBGRQm signal. If
DBGACKm does not go HIGH following DBGTRIGGERm, the memory system has stopped
responding and the CPU has not entered debug state.
Table 12-41 shows a list of the valid authentication signals and the associated debug
permissions. Authentication signals are used to configure the CPU so its activity can only be
debugged or traced in a certain subset of CPU modes.
0 0 No
X 1 Yes
1 0 Yes
The NIDENm, and DBGENm input signals are either tied off to some fixed value or controlled
by some external device.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-52
ID092411 Non-Confidential
Debug
If software running on the CPU has control over an external device that drives the authentication
signals, it must make the change using a safe sequence:
2. If step 1 involves any memory operation, issue a Data Synchronization Barrier (DSB)
instruction.
3. Poll the DBGDSCR or DBGAUTHSTATUS to check whether the CPU has already
detected the changed value of these signals. This is required because the system might not
issue the signal change to the CPU until several cycles after the DSB completes.
The software cannot perform debug or analysis operations that depend on the new value of the
authentication signals until this procedure is complete. The same rules apply when the debugger
has control of the CPU through the DBGITR while in debug state.
The values of the DBGENm and NIDENm signals can be determined by polling
DBGDSCR[17:16], DBGDSCR[15:14], or the DBGAUTHSTATUS.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-53
ID092411 Non-Confidential
Debug
A basic function for using the debug state is executing an instruction through the DBGITR.
Example 12-1 shows the sequence for executing an ARM instruction through the DBGITR.
ExecuteARMInstruction(uint32 instr)
{
// Step 1. Poll DBGDSCR until InstrCompl_l is set.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
until (dbgdscr & (1<<24));
// Step 2. Write the opcode to the DBGITR.
WriteDebugRegister(33, instr);
// Step 3. Poll DBGDSCR until InstrCompl is set.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
until (dbgdscr & (1<<24);
}
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-54
ID092411 Non-Confidential
Debug
There are two ways that an external debugger can send data to or receive data from the
processor:
• The debug communications channel, when the processor is not in debug state. It is defined
as the set of resources used for communicating between the external debugger and
software running on the processor.
• The mechanism for forcing the processor to execute ARM instructions, when the
processor is in debug state. For more information, see Executing instructions in debug
state on page 12-46.
• If a read of the DBGDSCRint returns 1 for the RXfull flag, a following read of the
DBGDTRRXint returns valid data and RXfull is cleared. No ISB is required between these
two CP14 instructions.
• If a read of the CP14 DBGDSCRint returns 1 for the TXfull flag, a following write to the
DBGDTRTXext is Unpredictable.
• If a read of the CP14 DBGDSCRint returns 0 for the RXfull flag, a following read of the
CP14 DTR returns an Unpredictable value.
• If a read of the CP14 DBGDSCRint returns 0 for the TXfull flag, a following write to the
CP14 DTR writes the intended 32-bit word, and sets TXfull to 1. No ISB is required
between these two CP14 instructions.
When Nonblocking mode is selected for DTR accesses, the following conditions are true for
memory-mapped DBGDSCR, DBGDTRRXext, and DBGDTRTXext registers:
• If a read of the DBGDSCRext returns 0 for the TXfull flag, a following read of the
memory-mapped DBGDTRTX is ignored. The content of TXfull is unchanged and the
read returns an UNKNOWN value.
• If a read of the DBGDSCRext returns 0 for the RXfull flag, a following write of the
memory-mapped DBGDTRRX passes valid data to the processor and sets RXfull to 1.
• If a read of the DBGDSCRext returns 1 for the TXfull flag, a following read of the
DBGDTRTXext returns valid data and clears TXfull.
• If a read of the DBGDSCRext returns 1 for the RXfull flag, a following write of the
memory-mapped DBGDTRRXext is ignored, that is, both RXfull and DBGDTRRX
contents are unchanged.
Software running on the processor that sends data to the debugger through the target-to-host
channel can use the sequence of instructions that Example 12-2 on page 12-56 shows.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-55
ID092411 Non-Confidential
Debug
Example 12-3 shows the sequence of instructions for sending data to the debugger through the
host-to-target channel.
A debugger can access the DCC through the external interface. The following examples show
the pseudo-code operations for these accesses.
uint32 ReadDCC()
{
// Step 1. Poll DBGDSCR until TXfull is set to 1.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
until (dbgdscr & (1<<29));
// Step 2. Read the value from DBGDTRTX.
dtr_val := ReadDebugRegister(35);
return dtr_val;
}
WriteDCC(uint32 dtr_val)
{
// Step 1. Poll DBGDSCR until RXfull is clear.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-56
ID092411 Non-Confidential
Debug
While the processor is running, if the DCC is used as a data channel, it might be appropriate to
poll the DCC regularly.
PollDCC
{
dbgdscr := ReadDebugRegister(34);
if (dbgdscr & (1<<29))
{
// DBGDTRTX (target -> host transfer register) full
dtr := ReadDebugRegister(35)
ProcessTargetToHostWord(dtr);
}
if (!(dbgdscr & (1<<30)))
{
// DBGDTRRX (host -> target transfer register) empty
dtr := GetNextHostToTargetWord()
WriteDebugRegister(32, dtr);
}
}
When programming a simple breakpoint, you must set the byte address select bits in the control
register appropriately. For a breakpoint in ARM state, this is simple. For Thumb state, you must
calculate the value based on the address.
For a simple breakpoint, you can program the settings for the other control bits as Table 12-42
shows:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-57
ID092411 Non-Confidential
Debug
Example 12-7 shows the sequence of instructions for setting a simple breakpoint.
The simplest and most common type of watchpoint watches for a write to a given address in
memory. In practice, a data object spans a range of addresses but is aligned to a boundary
corresponding to its size, so you must set the byte address select bits in the same way as for a
breakpoint.
For a simple watchpoint, you can program the settings for the other control bits as Table 12-43
shows:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-58
ID092411 Non-Confidential
Debug
Example 12-8 shows the code for setting a simple aligned watchpoint.
Using the byte address select bits, certain unaligned objects up to a doubleword (64 bits) can be
watched in a single watchpoint. However, this cannot cover all cases, and in many cases a
second watchpoint might be required.
Object size First address First byte Second address Second byte
Address of object
in bytes value address mask value address mask
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-59
ID092411 Non-Confidential
Debug
Table 12-44 Example byte address masks for watchpointed objects (continued)
Object size First address First byte Second address Second byte
Address of object
in bytes value address mask value address mask
Example 12-9 shows the code for setting a simple unaligned watchpoint.
12.11.3 Single-stepping
You can use the breakpoint mismatch bit to implement single-stepping on the processor. Unlike
high-level stepping, single-stepping implements a low-level step that executes a single
instruction at a time. With high-level stepping, the instruction is decoded to determine the
address of the next instruction and a breakpoint is set at that address.
Example 12-10 on page 12-61 shows the code for single-stepping off an instruction. The
processor must be configured for halt-mode debugging.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-60
ID092411 Non-Confidential
Debug
SingleStepOff(uint32 address)
{
bkpt := FindUnusedBreakpointWithMismatchCapability();
SetComplexBreakpoint(bkpt, address, 4 << 20);
}
Note
In Example 12-10, the third parameter of SetComplexBreakpoint() indicates the value to set
DBGBCR[22:20].
This method of single-stepping steps off the instruction that might not necessarily be the same
as stepping to the next instruction executed. In certain circumstances, the next instruction
executed might be the same instruction being stepped off.
The simplest example of this is a branch to a self instruction such as (B .). In this case, the
wanted behavior is most likely to step off the branch to self because this is often used as a means
of waiting for an interrupt.
A more complex example is a return from function that returns to the same point. For example,
a simple recursive function might terminate with:
BL ThisFunction
POP {saved_registers, pc}
In this case, the POP instruction loads a link register that is saved at the start of the function, and
if that is the link register created by the BL instruction shown, it points back at the POP
instruction. Therefore, this single step code unwinds the entire call stack to the point of the
original caller, rather than stepping out a level at a time. It is not possible to single step this piece
of code using either the high-level or low-level stepping methods.
On entry to debug state, the debugger can read the processor state, including all registers and
the PC, and determine the cause of the exception from the DBGDSCR method-of-entry bits.
OnEntryToDebugState(PROCESSOR_STATE *state)
{
// Step 1. Read the DBGDSCR to determine the cause of debug entry.
state->dbgdscr := ReadDebugRegister(34);
// Step 2. Issue a DataSynchronizationBarrier instruction if required;
// this is not required by the Cortex-R5 processor but is required for ARMv7
// debug.
if ((state->dbgdscr & (1<<19)) == 0)
{
ExecuteARMInstruction(0xE57FF040)
// Step 3. Poll the DBGDSCR for DBGDSCR[19] to be set.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-61
ID092411 Non-Confidential
Debug
When exiting debug state, the program counter must always be written. If the execution state or
CPSR must be changed, this must be done before writing to the PC because writing to the CPSR
can affect the PC.
Having restored the program state, the debugger can restart by writing to bit [1] of the
DBGDRCR. It must then poll bit [1] of the DBGDSCR to determine if the CPU has restarted.
Example 12-12 shows the code for exit from debug state.
ExitDebugState(PROCESSOR_STATE *state)
{
// Step 1. Update the CPSR value
WriteCPSR(state->cpsr);
// Step 2. Restore any registers corrupted by debug state. The function
// WriteAllRegisters restores all general-purpose registers for all
// processor modes apart from R0.
WriteAllRegisters(state);
// Step 3. Write the return address.
WritePC(state->pc);
// Step 4. Writing the PC corrupts R0 therefore, restore R0 now.
WriteRegister(0, state->r0);
// Step 5. Write the restart request bit in the DBGDRCR.
WriteDebugRegister(36, 1<<1);
// Step 6. Poll the RESTARTED flag in the DBGDSCR.
repeat
{
dbgdscr := ReadDebugRegister(34);
}
until (dbgdscr & (1<<1));
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-62
ID092411 Non-Confidential
Debug
To read a single register, the debugger can use the sequence that Example 12-13 shows. This
sequence depends on two other sequences, Executing an ARM instruction through the DBGITR
on page 12-54 and Target to host data transfer (host end) on page 12-56.
ReadPC()
{
// Step 1. Save R0
saved_r0 := ReadRegister(0);
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-63
ID092411 Non-Confidential
Debug
Note
You can use a similar sequence to write to the PC to set the return address when leaving debug
state or to read the CPSR or coprocessor registers.
WriteCPSR(uint32 cpsr_val)
{
// Step 1. Save R0.
saved_r0 := ReadRegister(0);
// Step 2. Write the new CPSR value to R0.
WriteRegister(0, cpsr_val);
// Step 3. Execute instruction MSR R0, CPSR through the DBGITR.
ExecuteARMInstruction(0xE12FF000);
// Step 4. Execute a PrefetchFlush instruction through the DBGITR.
ExecuteARMInstruction(9xEE070F95);
// Step 5. Restore the value of R0.
WriteRegister(0, saved_r0);
}
Reading memory
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-64
ID092411 Non-Confidential
Debug
return datum;
}
Example 12-18 shows the code for checking for aborts after a memory access.
bool CheckForAborts()
{
// Step 1. Check the DBGDSCR for a sticky abort.
dbgdscr := ReadDebugRegister(34);
if (dbgdscr & ((1<<6) + (1<<7))
{
// Step 2. Clear the sticky flag by writing DBGDRCR[2].
WriteDebugRegister(36, 1<<2);
return true;
}
else
{
return false;
}
}
Note
You can use a similar sequence to read a halfword of memory and to write to memory.
To read or write blocks of memory, substitute the data instruction with one that uses
post-indexed addressing. For example:
LDRB R1, [R0],1
This prevents reloading the address value for each sequential word.
Example 12-19 shows the code for reading a block of bytes of memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-65
ID092411 Non-Confidential
Debug
aborted := CheckForAborts();
return datum;
}
Note
A faster method is available for reading and writing words using the direct memory access
function of the DCC. See Fast memory read/write on page 12-67.
When multiple registers must be read in succession, you can optimize the process by placing the
DCC into stall mode and by writing the value 1 to the DCC access mode bits. For more
information, see CP14 c1, Debug Status and Control Register on page 12-14.
Example 12-21 shows the sequence to change the DTR access mode.
SetDTRAccessMode(int mode)
{
// Step 1. Write the mode value to DBGDSCR[21:20].
dbgdscr := ReadDebugRegister(34);
dbgdscr := (dbgdscr & ~(0x3<<20)) | (mode<<20);
WriteDebugRegister(34, dbgdscr);
}
ReadRegisterStallMode(int Rd)
{
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-66
ID092411 Non-Confidential
Debug
// Step 1. Write the opcode for MCR p14, 0, Rd, c5, c0 to the DBGITR.
// Write stalls until the DBGITR is ready.
WriteDebugRegister(33, 0xEE000E15 + (Rd<<12));
// Step 2. Read the register value through the DCC. Read stalls until
// DBGDTRTX is ready
reg_val := ReadDebugRegister(32);
return reg_val;
}
Note
To transfer a register to the CPU when in stall mode, you are not required to poll the DBGDSCR
each time an instruction is written to the DBGITR and a value read from or written to the DTR.
The CPU stalls using the signal PREADYDBGm until the previous instruction has completed
or the DTR register is ready for the operation.
This section provides example code to enable faster reads from memory by making use of the
DTR access mode.
Example 12-24 shows the sequence for reading a block of words of memory.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-67
ID092411 Non-Confidential
Debug
{
*data++ = ReadDebugRegister(35);
--nwords;
}
// Step 7. Write the value 0b00 to DBGDSCR[21:20] for non-blocking mode.
SetDTRAccessMode(0);
// Step 8. Must wait for the final instruction to complete. If there
// was an abort, this completes immediately.
do
{
dbgdscr := ReadDebugRegister(34);
}
until (dbgdscr & (1<<24));
// Step 9: Check for aborts.
aborted := CheckForAborts();
// Step 10: Read the final word from the DCC.
if (!aborted) *data := ReadDCC();
// Step 11. Restore the corrupted register r0.
WriteRegister(0, saved_r0);
}
Example 12-25 shows the sequence for writing a block of words to memory.
Note
As the amount of data transferred increases, these functions reach an optimum performance of
one debug register access per data word transferred.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-68
ID092411 Non-Confidential
Debug
After writing data to memory, you must execute a data synchronization barrier instruction to
ensure that the memory window updates properly
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-69
ID092411 Non-Confidential
Debug
The different measures that the OS can take to save energy during an idle state are divided into
two groups:
Standby The OS takes measures that reduce energy consumption but maintain the
processor state.
Power down The OS takes measures that reduce energy consumption but do not maintain the
processor state, for example, Dormant or Shutdown mode. Recovery involves a
reset of the processor after the power level has been restored, and reinstallation of
the processor state.
Standby is the least invasive OS energy-saving state because it only implies that the core is
unavailable. It does not clear any of the debug settings. For this case, the processor offers the
following:
• If the processor is in standby and a halting debug event occurs, the processor:
— leaves standby
— retires the Wait-For-Interrupt (WFI) or Wait-For-Event (WFE) instruction
— enters debug state.
• If the processor is in standby and detects an APB port access, it temporarily leaves standby
state to complete the transaction. While the processor wakes up from standby, the APB
access is held by keeping the PREADYDBGm signal LOW.
By writing to bit [0] of the DBGPRCR in either CPU, the debugger causes the processor to
assert the DBGNOPWRDWN output. The expected usage model of this signal is that it
connects to the system power controller and that, when HIGH, it indicates that this controller
must work in emulate mode.
On a power-down request from the processor, if the power controller is in emulate mode, it does
not remove processor power or ETM power. Otherwise, it behaves exactly the same as in normal
mode.
Emulating power down is ideal for debugging applications running on top of operating systems
that are free of errors because the debug register settings are not lost on a power-down event.
However, you must ensure that:
• nIRQm and nFIQm interrupts and EVENTIm events to the processor are externally
masked as part of the emulation to prevent them from retiring the WFI or WFE instruction
from the pipeline.
• The reset controller asserts nRESETm only on emulated power up, rather than combining
it with DBGRESETmn. Asserting DBGRESETmn clears the debug registers inside the
processor.
• The timing effects of power down and voltage stabilization are not factored in the
power-down emulation. This is the case for systems with voltage recovery controlled by
a closed loop system that monitors the processor supply voltage, rather than a fixed timed
for voltage recovery.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-70
ID092411 Non-Confidential
Debug
• The emulation does not model state lost during power down, making it possible to miss
errors in the state storage and recovery routines.
• Attaching the debugger for a postmortem debug session is not possible because setting the
DBGNOPWRDWN signal to 1 might not cause the processor to power up. The effect of
setting DBGNOPWRDWN to 1 when the processor is already powered down is
implementation-defined, and is up to the system designer.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 12-71
ID092411 Non-Confidential
Chapter 13
Integration Test Registers
This chapter describes how to use the Integration Test Registers in the processor. It contains the
following sections:
• About Integration Test Registers on page 13-2
• Summary of the processor registers used for integration testing on page 13-3
• Processor integration testing on page 13-4.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-1
ID092411 Non-Confidential
Integration Test Registers
The Integration Test Registers are programmed using the debug APB interface. For more
information on using the debug APB interface see Chapter 12 Debug.
When programming the Integration Test Registers you must enable all the changes at the same
time.
For more information about the Integration Test Registers and the Integration Mode Control
Register see the ARM Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-2
ID092411 Non-Confidential
Integration Test Registers
Base Default
Register name Type Description
offset value
DBGITETMIF 0xED8 n/aa WO See DBGITETMIF Register (ETM interface) on page 13-5
DBGITMISCOUT 0xEF8 n/a WO See DBGITMISCOUT Register (Miscellaneous Outputs) on page 13-6
DBGITCTRL 0xF00 0 R/W See Integration Mode Control Register (DBGITCTRL) on page 13-8
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-3
ID092411 Non-Confidential
Integration Test Registers
If you want to utilise the integration test registers you must first set bit [0] of the Integration
Mode Control Register to 1.
• You can use the write-only Integration Test Registers to set the outputs of some of the
processor signals. Table 13-2 shows the signals that you can write in this way.
• You can use the read-only Integration Test Registers to read the state of some of the
processor inputs. Table 13-3 on page 13-5 shows the signals that you can read in this way.
Various CoreSight components, including ETM-R5, also include Integration Test Registers that
you can use in conjunction with processor Integration Test Registers for testing the connectivity
between them. For more information see the relevant documentation, for example the ETM-R5
Technical Reference Manual
Table 13-2 Output signals that can be controlled by the Integration Test Registers
DBGRESTARTEDm DBGITMISCOUT [9] See DBGITMISCOUT Register (Miscellaneous Outputs) on page 13-6
EVNTBUSm[54, 0] DBGITETMIF [13:12] See DBGITETMIF Register (ETM interface) on page 13-5
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-4
ID092411 Non-Confidential
Integration Test Registers
Table 13-3 Input signals that can be read by the Integration Test Registers
DBGRESTARTm DBGITMISCIN [11] See DBGITMISCIN Register (Miscellaneous Inputs) on page 13-7
When bit [0] of the Integration Mode Control Register (DBGITCTRL) is set to b1:
• Values written to the write-only Integration Test Registers map onto the specified outputs
of the macrocell. For example, writing b1 to DBGITMISCOUT[0] causes DBGACKm
to be asserted HIGH.
• Values read from the read-only Integration Test Registers correspond to the values of the
specified inputs of the macrocell. For example, if you read DBGITMISCIN[9:8] you
obtain the value of ETMEXTOUTm[1:0].
When you perform integration testing or topology detection, ARM strongly recommends that
the processor is halted, because toggling input and output pins might have an unwanted effect
on the operation of the processor. If you follow this recommendation, you must not set the
DBGITCTRL Register until the processor has halted.
After you perform integration testing or topology detection, that is, the Integration Mode
Control Register has been set, the system must be reset. This is because the signals that are
toggled can have an unwanted effect on connected devices.
The DBGITETMIF Register at offset 0xED8 is write-only. Figure 13-1 on page 13-6 shows the
register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-5
ID092411 Non-Confidential
Integration Test Registers
31 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
EVNTBUSm[54] ETMICTLm[0]
EVNTBUSm[0] ETMICTLm[13]
ETMCIDm[31] ETMIAm[1]
ETMCIDm[0] ETMIAm[31]
ETMDDm[63] ETMDCTLm[0]
ETMDDm[0] ETMDCTLm[11]
ETMDAm[31] ETMDAm[0]
Table 13-4 shows the fields when writing the DBGITETMIF Register. When this register is
written the appropriate output pins take the value written.
The DBGITMISCOUT Register at offset 0xEF8 is write-only. Figure 13-2 on page 13-7 shows
the register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-6
ID092411 Non-Confidential
Integration Test Registers
31 10 9 8 7 6 5 4 3 2 1 0
Reserved
DBGRESTARTEDm
DBGTRIGGERm
Reserved
ETMWFIPENDINGm
nPMUIRQm
Reserved
COMMTXm
COMMRXm
DBGACKm
Table 13-5 shows the fields when writing the DBGITMISCOUT Register. When this register is
written the appropriate output pins take the value written.
The DBGITMISCIN Register at offset 0xEFC is read-only. Figure 13-3 on page 13-8 shows the
register bit assignments.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-7
ID092411 Non-Confidential
Integration Test Registers
31 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
DBGRESTARTm
Reserved
ETMEXTOUTm[1:0]
Reserved
nETMWFIREADYm
Reserved
nFIQm
nIRQm
EDBGRQm
Table 13-6 lists the register bit assignments for the DBGITMISCIN Register.
[5] nETMWFIREADYm Reads the nETMWFIREADYm input pin. Although this pin is active LOW, the value
of this bit matches the physical state of the signal:
0 = input pin is LOW (asserted)
1 = input pin is HIGH (deasserted).
The DBGITCTRL Register, register 0x3C0 at offset 0xF00, is read/write. Figure 13-4 shows the
register bit assignments.
31 1 0
Reserved
INTMODE
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-8
ID092411 Non-Confidential
Integration Test Registers
[0] R/W INTMODE Controls whether the processor is in normal operating mode or integration mode:
b0 = normal operation, this is the reset value
b1 = integration mode enabled.
Writing to the DBGITCTRL register controls whether the processor is in its default functional
mode, or in integration mode, where the inputs and outputs of the device can be directly
controlled for the purpose of integration testing or topology detection. For more information see
the ARM Architecture Reference Manual.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. 13-9
ID092411 Non-Confidential
Appendix A
Signal Descriptions
This appendix describes the processor signals. It contains the following sections:
• About the processor signal descriptions on page A-2
• Global signals on page A-3
• Configuration signals on page A-4
• Interrupt signals, including VIC interface signals on page A-8
• L2 interface signals on page A-9
• TCM interface signals on page A-22
• Redundant CPU signals on page A-25
• Debug interface signals on page A-26
• ETM interface signals on page A-28
• Test signals on page A-29
• MBIST signals on page A-30
• Validation signals on page A-31
• FPU signals on page A-32
• Split/Lock on page A-33
• Power modes on page A-34.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-1
ID092411 Non-Confidential
Signal Descriptions
Many of the signal names have an m suffix, that appears before the n suffix in the case of
negative sense signals. This indicates that the processor has two signals, one for each CPU,
named with m being 0 or 1 for CPU0 and CPU1 respectively.
The Cortex-R5 processor has the same signals regardless of configuration. If a particular feature
is not implemented, the signals associated with that feature are not used.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-2
ID092411 Non-Confidential
Signal Descriptions
ACPRESETn Input ACP reset. Assert with nRESET0 and nRESET1 to reset the whole processor except the
debug registers. This signal can be asserted asynchronously to CLKIN.
nRESETm Input CPU non-debug logic reset. These signals can be asserted asynchronously to CLKIN.
nCPUHALTm Input Processor halt after reset. These signals can be asserted asynchronously to CLKIN.
DBGNOCLKSTOP Input Processor does not stop the clocks when entering standby mode.
nCLKSTOPPEDm Output When LOW, this indicates clock has been stopped because processor is in Standby Mode.
It is never asserted without one of WFIPIPESTOPPEDm or WFEPIPESTOPPEDm.
nWFEPIPESTOPPEDm Output When LOW, this indicates that the CPU is in standby mode because of a WFE instruction.
The CPU pipeline is inactive..
nWFIPIPESTOPPEDm Output When LOW, this indicates the CPU is in standby mode because of a WFI instruction. The
CPU pipeline is inactive.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-3
ID092411 Non-Confidential
Signal Descriptions
VINITHIm Input Reset V-bit value. When HIGH indicates HIVECS mode at reset. See c1, System Control
Register on page 4-38 for more information.
CFGEE Input Reset EE-bit value. When HIGH indicates the implementation uses BE-8 mode for
exceptions at reset. See c1, System Control Register on page 4-38 for more information.
CFGIE Input Instruction side endianness, reflected in the IE-bit. When HIGH indicates that big endian
instruction fetch is used. See c1, System Control Register on page 4-38 for more
information.
INITRAMAm Input Reset value of ATCM enable bit. When HIGH indicates Tightly-Coupled Memory A,
ATCM, enabled at reset. See c9, ATCM Region Register on page 4-64 for more
information.
INITRAMBm Input Reset value of BTCM bit. When HIGH indicates Tightly-Coupled Memory B, BTCM,
enabled at reset. See c9, BTCM Region Register on page 4-63 for more information.
LOCZRAMAm Input When HIGH indicates ATCM initial base address is zero and BTCM base address is
implementation-defined.
When LOW indicates BTCM initial base address is zero and ATCM base address is
implementation-defined.
TEINIT Input Reset TE-bit value. Determines exception handling state at reset. When set to:
0 = ARM
1 = Thumb.
See c1, System Control Register on page 4-38 for more information.
CFGATCMSZm[3:0] Input Selects the ATCM size. The encodings for the TCM sizes are:
b0000 = 0KB
b0011 = 4KB
b0100 = 8KB
b0101 = 16KB
b0110 = 32KB
b0111 = 64KB
b1000 = 128KB
b1001 = 256KB
b1010 = 512KB
b1011 = 1MB
b1100 = 2MB
b1101 = 4MB
b1110 = 8MB.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-4
ID092411 Non-Confidential
Signal Descriptions
CFGBTCMSZm[3:0] Input Selects the BTCM size. The encodings for the TCM sizes are:
b0000 = 0KB
b0011 = 4KB
b0100 = 8KB
b0101 = 16KB
b0110 = 32KB
b0111 = 64KB
b1000 = 128KB
b1001 = 256KB
b1010 = 512KB
b1011 = 1MB
b1100 = 2MB
b1101 = 4MB
b1110 = 8MB.
CFGNMFIm Input When HIGH, enable nonmaskable Fast Interrupts. Reflected in the NMFI bit. See c1,
System Control Register on page 4-38 for more information.
ENTCM1IFm Input Enable B1TCM interface. Use B0TCM only if this signal not tied HIGH.
PARECCENRAMm[2:0] Input TCMs ECC check enable. Tie each bit HIGH to enable ECC checking on the appropriate
TCM at reset. The bit allocations are as follows:
[2] = B1TCMa
[1] = B0TCMa
[0] = ATCM.
See c1, Auxiliary Control Register on page 4-41 for more information.
PARITYLEVEL Input Selects between odd and even parity for caches and buses. See Chapter 8 Level One
Memory System:
Tie LOW for even parity
Tie HIGH for odd parity.
ERRENRAMm[2:0] Input TCMs external error enable. Tie each bit high to enable the external error signals for each
TCM at reset. The bit allocations are as follows:
[2] = B1TCM
[1] = B0TCM
[0] = ATCM.
See c1, Auxiliary Control Register on page 4-41 for more information.
RMWENRAMm[1:0]b Input RMW enable bits reset values. Tie each bit high to enable read-modify-write for TCM
interfaces at reset.c The bit allocations are as follows:
[1] = BTCM
[0] = ATCM.
See c1, Auxiliary Control Register on page 4-41 for more information.
SLBTCMSBm Input Use most significant bit of BTCM address to select B1TCM if this signal is HIGH.
Use bit [3] of the BTCM address if this signal is LOW.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-5
ID092411 Non-Confidential
Signal Descriptions
PPHSIZEm[4:0] Input Size of AHB peripheral interface. See Table A-3 for the size encodings.
PPXBASEm[31:12] Input Base address of AXI peripheral interface. Must be size aligned.
PPXSIZEm[4:0] Input Size of AXI peripheral interface. See Table A-3 for the size encodings.
PPVBASEm[31:12] Input Base address of virtual-AXI peripheral interface. Must be within AXI PP and size-aligned.
The virtual AXI peripheral interface region must be the same size or smaller than the AXI
peripheral interface.
PPVSIZEm[4:0] Input Size of virtual-AXI peripheral interface. See Table A-3 for the size encodings.
a. If the BTCM is configured with ECC, bit[2] and bit[1] must be the same value.
b. Not used if 32-bit ECC is included.
c. Not available in r0px revisions of the processor.
Encoding Size
b00011 4KB
b00100 8KB
b00101 16KB
b00110 32KB
b00111 64KB
b01000 128KB
b01001 256KB
b01010 512KB
b01011 1MB
b01100 2MB
b01101 4MB
b01110 8MB
b01111 16MB
b10000 32MB
b10001 64MB
b10010 128MB
b10011 256MB
b10100 512MB
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-6
ID092411 Non-Confidential
Signal Descriptions
Encoding Size
b10101 1GB
b10110 2GB
b10111 4GB
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-7
ID092411 Non-Confidential
Signal Descriptions
nFIQm Input Fast interrupta. This signal can be asserted asynchronously if INTSYNCEN is HIGH.
nIRQm Input Normal interrupta. This signal can be asserted asynchronously if INTSYNCEN is HIGH.
INTSYNCEN Input Tie HIGH if the interrupt inputs are asynchronous to CLKIN.
Tie LOW if the interrupt inputs are synchronous to CLKIN.
IRQADDRVm Input Indicates IRQADDRm is valid. This signal can be asserted asynchronously if
IRQADDRVSYNCEN is HIGH.
IRQADDRVSYNCEN Input Tie HIGH if the IRQADDRVm input from the VIC is asynchronous to CLKIN.
Tie HIGH if the IRQADDRVm input from the VIC is synchronous to CLKIN.
IRQADDRm[31:2] Input Address of the IRQ. This signal can be asserted asynchronously but must be stable when
IRQADDRVm is asserted.
a. This signal is level-sensitive and must be held LOW until a suitable interrupt response is received from the processor.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-8
ID092411 Non-Confidential
Signal Descriptions
Table A-5 shows the AXI master port signals for the L2 interface. With the exception of the
ACLKENMm, all signals are only sampled or driven on CLKIN edges when ACLKENMm
is asserted, see AMBA interface clocking on page 2-16 for more information.
AWIDMm[3:0] Output The identification tag for the write address group of signals.
AWREADYMm Input Address ready. The slave uses this signal to indicate that it can accept the address.
AWINNERMm[3:0] Output Provides inner attribute information for the write address channel. See Table 9-2 on
page 9-7 for information about the encoding of this signal.a
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-9
ID092411 Non-Confidential
Signal Descriptions
Table A-5 AXI master port signals for the L2 interface (continued)
WIDMm[3:0] Output The identification tag for the write data group of signals.
WREADYMm Input Indicates that the slave is ready to accept write data
WSTRBMm[7:0] Output Write strobes used to indicate which byte lanes must be updated.
BIDMm[3:0] Input The identification tag for the write response signal.
BREADYMm Output Indicates that the CPU is ready to accept write response.
ARIDMm[3:0] Output Identification tag for the read address group of signals
ARREADYMm Input Address ready. The slave uses this signal to indicate that it can accept the address.
ARINNERMm[3:0] Output Provides inner attribute for the read address channel. See Table 9-2 on page 9-7 for
information about the encoding of this signal.a
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-10
ID092411 Non-Confidential
Signal Descriptions
Table A-5 AXI master port signals for the L2 interface (continued)
RIDMm[3:0] Input The identification tag for the read data group of signals.
RREADYMm Output Read ready signal indicating that the bus master can accept read data and response
information.
Table A-6 shows the AXI master port error detection signals. these signals are only generated if
the processor is configured to include AXI bus parity. See Configurable options on page 1-6 for
more information.
ARCTLPTYMm[3:0] Output Parity bits for the rest of the read address channela
AWCTLPTYMm[3:0] Output Parity bits for the rest of the write address channela
AXIMFATALm[4:0] Output Fatal error detected on AXI master, per channel {R, AR, B, W, AW}
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-11
ID092411 Non-Confidential
Signal Descriptions
WCTLPTYMm[2:0] Output Parity bits for the rest of the write data channela
Table A-7 shows the AXI slave port signals for the L2 interface. With the exception of the
ACLKENSm, all signals are only sampled or driven on CLKIN edges when ACLKENSm is
asserted, see AMBA interface clocking on page 2-16 for more information.
AWCSELSm[3:0] Input Memory type select data cache, instruction cache, BTCM or ATCM, one hot.a
AWIDSm[7:0] Input The identification tag for the write address group of signals.
AWREADYSm Output Address ready. The slave uses this signal to indicate that it can accept the address.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-12
ID092411 Non-Confidential
Signal Descriptions
Table A-7 AXI slave port signals for the L2 interface (continued)
WIDSm[7:0] Input The identification tag for the write group of signals.
WREADYSm Output Indicates that the slave is ready to accept write data.
WSTRBSm[7:0] Input Write strobes used to indicate which byte lanes must be updated.
BIDSm[7:0] Output The identification tag for the write response signal.
BREADYSm Input Indicates that the CPU is ready to accept write response.
ARIDSm[7:0] Input Identification tag for the read address group of signals.
ARREADYSm Output Address ready. The slave uses this signal to indicate that it can accept the address.
ARCSELSm[3:0] Input Memory type select {data cache, instruction cache, BTCM or ATCM}, one hot.a
RIDSm[7:0] Output The identification tag for the read data group of signals.
RREADYSm Input Read ready signal indicating that the bus master can accept read data and response
information.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-13
ID092411 Non-Confidential
Signal Descriptions
Table A-8 shows the AXI slave port error detection signals. These signals are only generated if
the processor is configured to include AXI bus parity. See Configurable options on page 1-6 for
more information.
ARCTLPTYSm[3:0] Input Parity bits for the rest of the read address channela
AWCTLPTYSm[3:0] Input Parity bits for the rest of the write address channela
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-14
ID092411 Non-Confidential
Signal Descriptions
ACLKENC Input Clock enable, shared between ACP slave and master port.
AWIDCS[1:0] Input The identification tag for the write address group of signals.
AWPROTCS[2:0] Input Protection signals provide additional information about a bus access.
AWREADYCS Output Address ready. The slave uses this signal to indicate it is ready to accept the address.
BIDCS[1:0] Output The identification tag for the write response signal.
BREADYCS Input Indicates that the CPU is ready to accept write response.
BMISSCS[1:0] Output Access did not hit in either cache, or coherency not required. One bit for each CPU.a
BHITDIRTYCS[1:0] Output Access hit a dirty line, or Dormant CPU, and was not invalidated. One bit for each CPU.a
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-15
ID092411 Non-Confidential
Signal Descriptions
Table A-10 shows the ACP slave port error detection signals. These signals are only generated
if the processor is configured to include AXI bus parity. See Configurable options on page 1-6
for more information.
AWCTLPTYCS[3:0] Input Parity bits for the rest of the write address channela
AWIDCM[1:0] Output The identification tag for the write address group of signals.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-16
ID092411 Non-Confidential
Signal Descriptions
AWREADYCM Input Address ready. The slave uses this signal to indicate it is ready to accept the address.
BIDCM[1:0] Input The identification tag for the write response signal.
BREADYCM Output Indicates that the CPU is ready to accept write response.
Table A-12 shows the ACP master port error detection signals. These signals are only generated
if the processor is configured to include AXI bus parity. See Configurable options on page 1-6
for more information.
AWCTLPTYCM[3:0] Output Parity bits for the rest of the write address channela
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-17
ID092411 Non-Confidential
Signal Descriptions
AWIDPm[3:0] Output The identification tag for the write address group of signals.
AWREADYPm Input Address ready. The slave uses this signal to indicate it is ready to accept the address.
WIDPm[3:0] Output The identification tag for the write data group of signals.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-18
ID092411 Non-Confidential
Signal Descriptions
WSTRBPm[3:0] Output Write strobes used to indicate which byte lanes must be updated.
WREADYPm Input Indicates that the slave is ready to accept write data.
BIDPm[3:0] Input The identification tag for the write response channel.
BREADYPm Output Indicates that the CPU is ready to accept a write response.
ARIDPm[3:0] Output Identification tag for the read address group of signals.
ARREADYPm Input Address ready. The slave uses this signal to indicate it is ready to accept the address.
RIDPm[3:0] Input The identification tag for the read data group of signals.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-19
ID092411 Non-Confidential
Signal Descriptions
RREADYPm Output Read ready signal indicating that the bus master can accept read data and response
information.
Table A-14 shows the AXI peripheral port error detection signals. These signals are only
generated if the processor is configured to include AXI bus parity. See Configurable options on
page 1-6 for more information.
ARCTLPTYPm[3:0] Output Parity bits for the rest of the read address channela
AWCTLPTYPm[3:0] Output Parity bits for the rest of the write address channela
PPXFATALm[4:0] Output Fatal error, one bit for each channel {R,AR,B,W,AW}
RCTLPTYPm[1:0] Input Parity bits for the rest of the read data channela
WCTLPTYPm[2:0] Output Parity bits for the rest of the write data channela
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-20
ID092411 Non-Confidential
Signal Descriptions
Address Phase
HMASTLOCKPm Output Indicates that the current transfer is part of a locked sequence
Data phase
Table A-16 shows the AHB peripheral port error detection signals. These signals are only
generated if the processor is configured to include AHB bus parity. See Configurable options
on page 1-6 for more information.
HCTLPTYPm[1:0] Output Parity bits for the rest of the data channel.
a. This is not parity for HRESP alone, even though that might be suggested by the name.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-21
ID092411 Non-Confidential
Signal Descriptions
ATCEN0m Output Enable for ATCM lower word, bit range [31:0]
ATCEN1m Output Enable for ATCM upper word, bit range [64:32]
a. This signal is ignored when bit [0] of the Auxiliary Control Register is set to 0, see c1, Auxiliary
Control Register on page 4-41.
b. Only generated if the processor is configured to include TCM address bus parity.
c. The MBIST interface has no way of signaling a wait. If it is accessing the TCM, and the TCM
signals a wait, the AXI slave pipeline stalls and the data arrives later. However, no signal is sent
to the MBIST controller to indicate this.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-22
ID092411 Non-Confidential
Signal Descriptions
B0TCEN0m Output Enable for B0TCM lower word, bit range [31:0]
B0TCEN1m Output Enable for B0TCM upper word, bit range [64:32]
B1TCEN0m Output Enable for B1TCM lower word, bit range [31:0]
B1TCEN1m Output Enable for B1TCM upper word, bit range [64:32]
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-23
ID092411 Non-Confidential
Signal Descriptions
a. This signal is ignored when bit [2] of the Auxiliary Control Register is set to 0, see c1, Auxiliary
Control Register on page 4-41.
b. Only generated if the processor is configured to include TCM address bus parity.
c. The MBIST interface has no way of signaling a wait. If it is accessing the TCM, and the TCM
signals a wait, the AXI slave pipeline stalls and the data arrives later. However, no signal is sent to
the MBIST controller to indicate this.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-24
ID092411 Non-Confidential
Signal Descriptions
Signal Direction
CLKIN1 Input
DCCMINP[7:0] Input
DCCMINP2[7:0] Input
DCCMOUT[7:0] Output
DCCMOUT2[7:0] Output
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-25
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-26
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-27
ID092411 Non-Confidential
Signal Descriptions
ETMWFIPENDINGm Output Core is attempting to enter standby state because of a WFI or WFE
nETMWFIREADYm Input ETM FIFO is empty, CPU can enter WFI state
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-28
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-29
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-30
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-31
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-32
ID092411 Non-Confidential
Signal Descriptions
A.14 Split/Lock
Table A-28 shows the Split/Lock signals. If you are implementing a Split/Lock configuration,
contact ARM for more information about the functionality of these signals.
Signal Direction
SLSPLIT Input
SLRESETn Input
SLCLAMP Input
SLERRACPn Input
SLERRDBGn Input
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-33
ID092411 Non-Confidential
Signal Descriptions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. A-34
ID092411 Non-Confidential
Appendix B
Cycle Timings and Interlock Behavior
This appendix describes the cycle timings and interlock behavior of instructions on the
processor. It contains the following sections:
• About cycle timings and interlock behavior on page B-3
• Register interlock examples on page B-6
• Data processing instructions on page B-7
• QADD, QDADD, QSUB, and QDSUB instructions on page B-9
• Media data-processing on page B-10
• Sum of Absolute Differences (SAD) on page B-11
• Multiplies on page B-12
• Divide on page B-14
• Branches on page B-15
• Processor state updating instructions on page B-16
• Single load and store instructions on page B-17
• Load and Store Double instructions on page B-19
• Load and Store Multiple instructions on page B-20
• RFE and SRS instructions on page B-23
• Synchronization instructions on page B-24
• Coprocessor instructions on page B-25
• SVC, BKPT, Undefined, and Prefetch Aborted instructions on page B-26
• Miscellaneous instructions on page B-27
• Floating-point register transfer instructions on page B-28
• Floating-point load/store instructions on page B-29
• Floating-point single-precision data processing instructions on page B-31
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-1
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-2
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Unless stated otherwise, cycle counts and result latencies that this chapter describes are
best-case numbers. They assume:
• all data accesses hit in the data cache, and do not cross protection region boundaries
The instruction execution pipeline has four stages, Iss, Ex1, Ex2, and Wr.
Extensive forwarding to the end of the Iss, Ex1, and Ex2 stages enables many dependent
instruction sequences to run without pipeline stalls. General forwarding occurs from the end of
the Ex2 and Wr pipeline stages. In addition, the multiplier contains an internal multiply
accumulate forwarding path. The address generation unit also contains an internal forwarding
path.
Many instructions do not require data from a register until the Ex2 stage. All result latencies are
given as the number of cycles until the register is available for a following instruction in the Ex2
stage. Most ALU operations require their source registers at the start of the Ex2 stage, and have
a result latency of one. For example, the following sequence takes two cycles:
ADD R1,R3,R4 ;Result latency one
ADD R5,R2,R1 ;Register R1 required by ALU
The PC is the only register that result latency does not affect. An instruction that alters the PC
never causes a pipeline stall because of interlocking with a subsequent instruction that reads the
PC.
Most loads have a result latency of two or higher, because they do not forward their results until
the Wr stage. For example, the following sequence takes three cycles:
LDR R1, [R2] ;Result latency two
ADD R3, R3, R1 ;Register R1 required by ALU
If a subsequent instruction requires the register at the end of the Iss stage then an extra cycle
must be added to the result latency of the instruction producing the required register.
Instructions that require a register at the end of these stages are specified by describing that
register as an Early Reg. The following sequence, requiring an Early Reg, takes four cycles:
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-3
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
The following sequence where R1 is a Very Early Reg takes four cycles:
ADD R3, R1, R2 ;Result latency one plus two cycles
LDR R4, [R3] ;plus two because register R3 is Very Early
Most instructions do not take more or fewer cycles to execute if they fail their condition codes.
The exceptions to this are:
• instructions that alter the PC, such as branches
• integer divide instructions, that require only one execute cycle.
The result latency of most instructions that fail their condition codes is one. The exceptions to
this are:
• all load and store instructions, that have their result latency unaffected
• integer divide instructions, that have a result latency of three.
Most instructions do not take more or fewer cycles to execute if they are flag-setting. The
exceptions to this are certain multiply instructions.
Table B-1 gives descriptions of cycle timing terms used in this appendix.
Term Description
Memory Cycles This is the number of cycles during which an instruction sends a memory access to the cache.
Cycles This is the minimum number of cycles required to issue an instruction. Issue cycles that produce memory
accesses to the cache are included, so Cycles is always greater than or equal to Memory Cycles.
Result Latency This is the number of cycles before the result of this instruction is available to a Normal Reg of the following
instruction. When the Result Latency of an instruction is greater than Cycles and the following instruction
requires the result, the following instruction stalls for a number of cycles equal to Result Latency minus Cycles.
If this value is negative, there are zero stall cycles.
Note
The Result Latency is counted from the first cycle of an instruction.
Normal Reg The specified registers are required at the start of the Ex2 stage.
Late Reg The specified registers are not required until the start of the Wr stage. Subtract one cycle from the Result Latency
of the instruction producing this register.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-4
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Term Description
Early Reg The specified registers are required at the start of the Ex1 stage. Add one cycle to the Result Latency of the
instruction producing this register.
Very Early Reg The specified registers are required at the start of the Iss stage. Add two cycles to the Result Latency of the
instruction producing this register, or one cycle if the instruction producing this register is an LDM, LDR, LDRD,
LDREX, or LDRT. The lower Result Latency does not apply if this register is the base register of the load instruction
producing this register, or if the load instruction is an LDRB, LDRBT, LDRH, LDRSB, or LDRSH.
Interlock There is a data dependency between two instructions in the pipeline, resulting in the Iss stage being stalled until
the processor resolves the dependency.
The syntax used throughout this chapter is unified assembler and the timings apply to ARM and
Thumb instructions.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-5
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
LDR instructions take one cycle, have a result latency of two, and require their base register as a
Very Early Reg.
ADD instructions take one cycle and have a result latency of one.
Instruction
Behavior
sequence
LDR R1, [R2] Takes two cycles because there are no register dependencies.
ADD R6, R5, R4
ADD R1, R2, R3 Takes two cycles because ADD instructions have a result latency of one.
ADD R9, R6, R1
LDR R1, [R2] Takes three cycles because of the result latency of R1.
ADD R6, R5, R1
ADD R2, R5, R6 Takes four cycles because of the use of the result of R2 as a Very Early Reg.
LDR R1, [R2]
LDR R1, [R2] Takes four cycles because of the result latency of R1, the use of the result of R1 as a Very Early Reg,
LDR R5, [R1] and the use of an LDR to generate R1.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-6
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-3 shows the cycle timing behavior for data processing instructions if their destination
is not the PC. You can substitute ADD with any of the data processing instructions identified in
the opening paragraph of this section.
Table B-3 Data Processing Instruction cycle timing behavior if destination is not PC
ADD <Rd>, <Rn>, <Rm>, LSL #<immed> 1 <Rm> - 1 Requires a shifted source register.
ADD <Rd>, <Rn>, <Rm>, LSL <Rs> 1 <Rm>, <Rs> - 1 Requires a register controlled shifted
source register.
MOV <Rd>, <Rm> 1 - <Rm> 1 Simple MOV case. Must not set the flags
or require a shifted source register.
Table B-4 shows the cycle timing behavior for data processing instructions if their destination
is the PC. You can substitute ADD with any data processing instruction except for a CLZ. A CLZ
with the PC as the destination is an Unpredictable instruction.
For condition code failing cycle counts, the cycles for the non-PC destination variants must be
used.
Table B-4 Data Processing instruction cycle timing behavior if destination is the PC
ADD pc, <Rn>, <Rm>, LSL #<immed> 9 <Rm> - - Requires a shifted source register
ADD pc, <Rn>, <Rm>, LSL <Rs> 9 <Rm>, - - Requires a register controlled shifted
<Rs> source register
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-7
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Most data processing instructions are single-cycle and can be executed back-to-back without
interlock cycles, even if there are data dependencies between them. The exceptions to this are
when shifts are used.
Shifter
The registers that the shifter requires are Early Regs and require an additional cycle of result
availability before use. For example, the following sequence introduces a 1-cycle interlock, and
takes three cycles to execute:
ADD R1,R2,R3
ADD R4,R5,R1 LSL #1
The second source register, that is not shifted, does not incur an extra data dependency check.
Therefore, the following sequence takes two cycles to execute:
ADD R1,R2,R3
ADD R4,R1,R9 LSL #1
The register containing the shift distance is an Early Reg. For example, the following sequence
takes three cycles to execute:
ADD R1, R2, R3
ADD R4, R2, R4, LSL R1
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-8
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
These instructions perform saturating arithmetic. They have a result latency of two. The QDADD
and QDSUB instructions must double and saturate the register <Rn> before the addition. This
register is an Early Reg.
Table B-5 shows the cycle timing behavior for QADD, QDADD, QSUB, and QDSUB instructions.
Table B-5 QADD, QDADD, QSUB, and QDSUB instruction cycle timing behavior
QADD, QSUB 1 - 2
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-9
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
All media data-processing instructions are single-cycle issue instructions. These instructions
have result latencies of one or two cycles. Some of the instructions require an input register to
be shifted, or manipulated in some other way before use and therefore are marked as requiring
an Early Reg.
SEL 1 - 1
SASX, SSAX 1 - 1
UASX, USAX 1 - 1
QASX, QSAX 1 - 2
SHASX, SHSAX 1 - 1
UQASX, UQSAX 1 - 2
UHASX, UHSAX 1 - 1
BFC 1 <Rd> 1
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-10
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-8 shows interlock examples using USAD8 and USADA8 instructions.
USAD8 R1,R2,R3 Takes three cycles because USAD8 has a Result Latency of two, and the ADD requires
ADD R5,R6,R1 the result of the USAD8 instruction.
USAD8 R1,R2,R3 Takes three cycles. The MOV instruction is scheduled during the Result Latency of
MOV R9,R9 the USAD8 instruction.
ADD R5,R6,R1
USAD8 R1,R2,R3 Takes two cycles. The Result Latency is one less because the result is used as the
USADA8 R1,R4,R5,R1 accumulate for a subsequent USADA8 instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-11
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
B.7 Multiplies
Most multiply operations cannot forward their result early, except as the accumulate value for a
subsequent multiply. For a subsequent multiply accumulate the result is available one cycle
earlier than for all other uses of the result.
The multiplicand and multiplier are required as Early Regs because they are both required at the
end of the Iss stage.
Table B-9 shows the cycle timing behavior of example multiply instructions.
Example
Cycles Early Reg Late Reg Result latency
instruction
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-12
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Example
Cycles Early Reg Late Reg Result latency
instruction
Note
Result Latency is one less if the result is used as the accumulate value for a subsequent multiply
accumulate. This only applies if the result is the same width as the accumulate value, that is 32
or 64 bits.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-13
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
B.8 Divide
This section describes the cycle timing behavior of the UDIV and SDIV instructions.
The divider unit is separate from the main execute pipeline so the UDIV and SDIV instructions
require one cycle to issue. They execute out-of-order relative to the rest of the pipeline, and
require an additional issue cycle at the end of the divide operation to write the result to the
destination register. This additional cycle is not required if the divide instruction fails its
condition code.
Note
• A divide instruction that fails its condition code or attempts to divide by zero has a Result
Latency of three.
• The value of the (clz(B) - clz(A) + 1)/2 component of these equations must be rounded
down.
• The clz(x) function counts the number of leading zeros in the 32-bit value x. If x is
negative, it is negated before this count occurs.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-14
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
B.9 Branches
This section describes the cycle timing behavior for the B, BL, BLX, BX, BXJ, CBNZ, CBZ, TBB, and TBH
instructions. Branches are subject to dynamic and return stack predictions. Table B-10 shows
example branch instructions and their cycle timing behavior.
Memory
Example instruction Cycles Comments
cycles
BX <cond> <Rm>b 1 - Correct condition prediction and correct return stack prediction
BLX <Rm> 9 - -
8 - Incorrectly predicted
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-15
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
SETEND 1 -
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-16
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-12 shows the cycle timing behavior for stores and loads, other than loads to the PC. You
can replace LDR with any of these single load or store instructions. The following rules apply:
• They are normally single-cycle issue. Both the base and any offset register are Very Early
Regs.
• They are 3-cycle issue if pre-increment addressing with either a negative register offset or
a shift other than LSL #1, 2 or 3 is used. Both the base and any offset register are Very
Early Regs.
• Accesses to addresses not aligned to the access size that cross a 64-bit aligned boundary
generate two memory accesses, and require an additional cycle to issue. This extra cycle
is required if the final address is potentially unaligned, even if the final address turns out
to be aligned.
• PLD (data preload hint instructions) have cycle timing behavior as for load instructions.
Because they have no destination register, the result latency is not-applicable for such
instructions.
Table B-12 Cycle timing behavior for stores and loads, other than loads to the PC
a. See Table B-14 on page B-18 for an explanation of <addr_md_1cycle> and <addr_md_3cycle>.
Table B-13 shows the cycle timing behavior for loads to the PC.
Memory Result
Example instruction Cycles Comments
cycles latency
LDR pc, [sp, #<imm>] (!) 1 1 - Correctly return stack predicted, or conditional
predicted correctly
LDR pc, [sp], #<imm> 1 1 -
LDR pc, [sp, #<imm>] (!) 9 1 - Return stack mispredicted, conditional predicted
correctly
LDR pc, [sp], #<imm> 9 1 -
LDR <cond> pc, [sp, #<imm>] (!) 8 1 - Conditional predicted incorrectly, but return
stack predicted correctly
LDR <cond> pc, [sp], #cns 8 1 -
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-17
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
a. See Table B-14 for an explanation of <addr_md_1cycle> and <addr_md_3cycle>. For condition code failing cycle counts, you must
use the cycles for the non-PC destination variants.
Only cycle times for aligned accesses are given because Unaligned accesses to the PC are not
supported.
The processor includes a 4-entry return stack that can predict procedure returns. Any LDR
instruction to the PC with an immediate post-indexed offset of plus four, and the stack pointer
R13 as the base register is considered a procedure return.
<addr_md_1cycle>
<addr_md_3cycle>
LDR <Rt>, [<Rn>, -<Rm>] (!) <Rn>,<Rm> If pre-increment addressing with a negative
register offset or shift other than LSL #1, 2 or
LDR <Rt>, <Rn>, +/-<Rm> <shift> <cns>] (!) <Rn>,<Rm> 3, then 3-issue cycles
The base register update for load or store instructions occurs in the ALU pipeline. To prevent an
interlock for back-to-back load or store instructions reusing the same base register, there is a
local forwarding path to recycle the updated base register around the address generator. This
only applies when the load or store instruction with base write-back uses pre-increment
addressing, and is a single load or store instruction that is not a load or store double instruction
or load or store multiple instruction.
For example, with R2 aligned the following instruction sequence take three cycles to execute:
LDR R5, [R2, #4]!
LDR R6, [R2, #0x10]!
LDR R7, [R2, #0x20]!
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-18
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
• Are normally single-cycle issue. Both the base and any offset register are Very Early Regs.
• Are 3-cycle issue if offset or pre-increment addressing with a negative register offset is
used. Both the base and any offset register are Very Early Regs.
Table B-15 shows the cycle timing behavior for LDRD and STRD instructions.
Table B-15 Load and Store Double instructions cycle timing behavior
<addr_md_1cycle>
LDRD <Rt>, <Rt2>, [<Rn>, #<imm>] (!) <Rn> If post-increment addressing, pre-increment
addressing with an immediate offset or a positive
LDRD <Rt>, <Rt2>, [<Rn>, <Rm>] (!) <Rn>, <Rm> register offset, then 1-issue cycle
LDRD <Rt>, <Rt2>, [<Rn>], #<imm> <Rn>
<addr_md_3cycle>
LDRD <Rt>, <Rt2>, [<Rn>, -<Rm>] (!) <Rn>,<Rm> If pre-increment addressing with a negative
register offset, then 3-issue cycles
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-19
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
B.13.1 Load and Store Multiples, other than load multiples including the PC
Table B-17 shows the cycle timing behavior of load and store multiples including the PC.
Table B-17 Cycle timing behavior of Load and Store Multiples, other than load multiples including the PC
Cycles with
Memory Result latency Result latency
Example instruction Cycles base register
cycles (LDM) (base register)
write-back
LDMIA <Rn>,{R1} 1 1 1 2 1
LDMIA <Rn>,{R1} 1 2 1 2 2
Note
The Cycle timing behavior that Table B-17 shows also covers PUSH and POP instructions that
behave like store and load multiple instructions with base register write-back.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-20
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
The processor includes a 4-entry return stack that can predict procedure returns. Any LDM to the
PC that does not restore the SPSR to the CPSR, is predicted as a procedure return.
Table B-18 shows the cycle timing behavior of Load Multiples, where the PC is in the register
list.
Table B-18 Cycle timing behavior of Load Multiples, with PC in the register list (64-bit aligned)
Memory Result
Example instruction Cycles Comments
cycles latency
LDMIA <cond> <Rn>,{...,pc} ma nb 2,… Correct condition prediction and correct return stack prediction
LDMIA <cond> <Rn>,{...,pc} ma + 8 nb 2,… Correct condition prediction and incorrect return stack prediction
a. Where m is the number of cycles for this instruction if the PC were treated as a normal register.
b. Where n is the number of memory cycles for this instruction if the PC were treated as a normal register.
Note
The Cycle timing behavior that Table B-18 shows also covers PUSH and POP instructions that
behave like store and load multiple instructions with base register writeback.
The following sequence that has an LDM instruction takes six cycles to execute, because R7 has a
result latency of five cycles:
LDMIA R0, {R1-R7}
ADD R10, R10, R7
The following sequence that has an STM instruction takes five cycles to execute:
STMIA R0, {R1-R7}
ADD R7, R10, R11
The following sequence has a result latency hidden by issue cycles. It takes five cycles to
execute.
LDMIA R0, {R1-R7}
ADD R10, R10, R3
The following sequence that has a POP instruction takes seven cycles to execute, because R9
has a result latency of six cycles:
POP {R1-R9}
ADD R10, R10, R9
The following sequence that has a PUSH instruction takes five cycles to execute:
PUSH {R1-R7}
ADD R10,R10,R7
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-21
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Note
In the examples, R0 and sp are 64-bit aligned addresses. The instructions PUSH and POP always
use the sp register for the base address.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-22
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
These instructions:
• take one or two memory cycles depending on doubleword alignment first address
location.
Table B-19 shows the cycle timing behavior for RFE and SRS instructions.
RFEIA <Rn> 10 1
SRSIA #<mode> 1 1
RFEIA <Rn> 11 2
SRSIA #<mode> 2 2
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-23
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
In all cases the base register, Rn, is a Very Early Reg. Table B-20 shows the synchronization
instructions cycle timing behavior.
CLREX 1 - -
The synchronization instructions DMB, DSB, and ISB stall the pipeline for a variable number of
cycles, depending on the current state of the memory system.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-24
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
The precise timing of coprocessor instructions is tightly linked with the behavior of the relevant
coprocessor. Table B-21 shows the coprocessor instructions cycle timing behavior. Table B-21
shows the best case numbers.
MCR 6 - -
MRC 6 6 -
Note
Some instructions such as cache operations take more cycles.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-25
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
In all cases the exception is taken in the Wr stage of the pipeline. SVC and most Undefined
Instructions that fail their condition codes take one cycle. A small number of Undefined
Instructions that fail their condition codes take two cycles. Table B-22 shows the SVC, BKPT,
Undefined, prefetch aborted instructions cycle timing behavior.
Table B-22 SVC, BKPT, Undefined, prefetch aborted instructions cycle timing behavior
Instruction Cycles
BKPT 9
Prefetch Abort 9
Undefined Instruction 9
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-26
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Example instructions Cycles Early Reg Late Reg Result latency Comments
IT{<v>{<w>{<z>}}} <cond> 1 - - - -
NOP 1 - - - -
The DBG, PLI, and YIELD instructions are all treated the same as NOP, and so have the same cycle
timing behavior.
The WFI and WFE instructions stall the pipeline for a variable number of cycles, depending on the
current state of the memory system.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-27
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
All source operands are Normal Regs, and the result latency for non-system register transfers is
always 1 cycle.
Instructions that write data from the integer register file to the VFP system registers (VMSR) are
blocking, that is, no subsequent instruction can start execution before the VMSR has completed
execution. Consequently, the VMSR instructions take six cycles to execute.
All transfers to and from the VFP system registers are also serializing. This means that if there
are any outstanding out-of-order-completion VFP instructions, the system register transfer
instruction stalls in the iss-stage until these instructions are complete.
VFP instructions that complete out-of-order are VMLA.F32, VMLS.F32, VNMLS.F32, VNMLA.F32,
VDIV.F32, VSQRT.F32, VCVT.F64.F32, and double-precision arithmetic and conversion instructions.
Table B-24 shows the floating-point register transfer instructions cycle timing behavior.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-28
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
• The base address register, and any offset register are Very Early Regs for both loads and
stores.
• For store instructions, the data register (Sd or Dd), or registers are always Late Regs.
• The cycle timing of load and store instructions is affected by the starting address for the
transfer.
Note
The starting address is not always the same as the base address.
• The cycle timing of load and store multiple instructions is also affected by whether or not
the base address register is updated by the instruction, that is, base register writeback.
Table B-25 shows the number of cycles and result latencies for single load and store instructions
and load multiple instructions. Values are shown for each instruction with and without base
register writeback, and with different starting address alignments. Cycle counts and base
register result latencies for store multiple instructions are the same as for the equivalent load
multiple instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-29
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-30
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-26 shows the floating-point single-precision data processing instructions cycle timing
behavior.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-31
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-27 shows the floating-point double-precision data processing instructions cycle timing
behavior
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-32
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
• Both instructions must be available to the issue stage at the same time. This is unlikely if
there are many branches.
• The second instruction must not use the PC as a source register unless it is B #immed.
• Both instructions must belong to the same instruction set, ARM or Thumb.
• There must be no data dependency between the two instructions. That is, the second
instruction must not have any source registers that are destination registers of the first
instruction.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-33
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Table B-28 lists the permitted instruction combinations. Any instruction can be conditional or
flag-setting unless otherwise stated. Only the exact instruction combinations listed in
Table B-28 can be dual issued, provided you ensure the instruction combinations obey the rules
specified in Dual issue rules on page B-33.
Dual issue
First instruction Second instruction
case
Case B1 LDR <Rt>, [<Rn>, #<imm>]c Any data processing instruction that does not
LDR <Rt>, [<Rn>, <Rm>]c require a shift by a register value.d
LDR <Rt>, [<Rn>, <Rm>, LSL #1, 2 or 3]c Any bitfield, saturate or bit-packing instruction.e
Any signed or unsigned extend instruction.f
Any SIMD add or subtract instruction.g
Other miscellaneous instructions.h
Case F1b,m Any single-precision CDPi, excluding “VMOV.S32 <Sd>, #<imm>", As for case C or C-F.
VCVT.F64.F32, VABS.F32, and VNEG.F32.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-34
ID092411 Non-Confidential
Cycle Timings and Interlock Behavior
Dual issue
First instruction Second instruction
case
Case F3b 32-bit transfers to and from the floating-point register filel As for Case F2_st.
"VMOV.F32, <Sd>, <Sm>", VABS.F32, and VNEG.F32.
Case F4b Any instruction that does not set flags, other than load/store Any single-precision CDPi, excluding "VMOV.F32
multiple/double, non-VFP coprocessor operations, multi-cycle <Sd>, #<imm>", VNEG.F32, VABS.F32, VCVT.F64.F32,
multiply instructionsp, double-precision floating point CDP VDIV.F32, and VSQRT.F32.
instructions, VCVT.F64.F32, or a miscellaneous processor control 32-bit transfers to and from the floating-point
instructiona register filel.
a. These are processor state updating instructions, synchronization instructions, SVC, BKPT, prefetch abort and Undefined Instructions.
b. This case can only occur if the optional floating-point functionality has been configured for the Cortex-R5F processor, see Configurable
options on page 1-6.
c. You can substitute LDR with LDRB, LDRH, LDRSB, or LDRSH. You can also substitute STR with STRB or STRH.
d. Data processing instructions are ADC, ADD, ADDW, AND, ASR, BIC, CLZ, CMN, CMP, EOR, LSL, LSR, MOV, MOVT, MOVW, MVN, ORN, ORR, ROR, RRX, RSB, SBC, SUB,
SUBW, TEQ, and TST.
e. Bitfield, saturate, and bit-packing instructions are BFC, BFI, PKHBT, PKHTB, QADD, QDADD, QDSUB, QSUB, SBFX, SSAT, SSAT16, UBFX, USAT, and USAT16.
f. Signed or unsigned extend instructions are SXTAB, SXTAB16, SXTAH, SXTB, SXTB16, SXTH, UXTAB, UXTAB16, UXTAH, UXTB, UXTB16, and UXTH.
g. SIMD add and subtract instructions are QADD16, QADD8, QASX, SQUB16, QSUB8, QSAX, SADD16, SADD8, SASX, SHADD16, SHADD8, SHASX, SHSUB16, SHSUB8,
SHSAX, SSUB16, SSUB8, SSAX, UADD16, UADD8, UASX, UHADD16, UHADD8, UHASX, UHSUB16, UHSUB8, UHSAX, UQADD16, UQADD8, UQASX, UQSUB16, UQSUB8, UQSAX,
USUB16, USUB8, and USAX.
h. Other miscellaneous instructions are RBIT, REV, REV16, REVSH, and SEL.
i. Single-precision CDPs are VABS.F32, VNEG.F32, "VMOV.F32 <Sd>, #<imm>", VMLA.F32, VMLS.F32, VNMLS.F32, VNMLA.F32, VMUL.F32, VNMUL.F32,
VADD.F32, VSUB.F32, VDIV.F32, VSQRT.F32, VCMP.F32, VCMPE.F32, VCVT.F64.F32, VCVT.F32.U32, VCVT.F32.S32, VCVT.F32.U16, VCVT.F32.S16,
VCVTR.U32.F32, VCVT.U32.F32, VCVTR.S32.F32, VCVT.S32.F32, VCVT.U16.F32, and VCVT.S16.F32.
j. Must not be flag-setting.
k. Immediate value must not require a shift.
l. 32-bit transfers to or from the floating point register file include single or half-double floating point register transfers, including "VMOV <Sn>,
<Rt>", "VMOV.F32 <Dn[x]>, <Rt>", "VMOV.F32 <Rt>, <Dn[x]>", and "VMOV <Rt>, <Sn>", but excluding VMRS and VMSR.
m. When the first instruction is a floating point multiply-accumulate, and the second instruction is a 32-bit transfer to the floating-point register
file, case F1 can only occur if the two instructions have different destination registers.
n. Any addressing modes.
o. Single-precision floating-point multiply-accumulate instructions are VMLA.F32, VMLS.F32, VNMLS.F32, and VNMLA.F32.
p. Multi-cycle multiply instructions are SMMUL, SMMLA, SMMLS, MUL, MLA, MLS, SMULL, SMLAL, UMAAL, UMULL, and UMLAL.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. B-35
ID092411 Non-Confidential
Appendix C
ECC Schemes
This appendix describes some of the advantages and disadvantages of the different Error
Checking and Correction (ECC) schemes for the TCMs. It contains the following section:
• ECC scheme selection guidelines on page C-2.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. C-1
ID092411 Non-Confidential
ECC Schemes
For example, if the ATCM is implemented with 32-bit ECC and a program performs an aligned
STR to the memory, the processor can calculate the error correction code using only the data
stored by the program.
If the same memory was implemented with 64-bit ECC, the processor cannot calculate the ECC
code for the doubleword memory chunk being written using only the data stored by the program.
To calculate the ECC code and store the data, the processor must first perform a read of the other
word in that memory chunk. This increases the number of memory accesses required to execute
the program. This increases power consumption, and can also lead to a decrease in performance.
Use the following guidelines to decide which scheme to use. If you are in any doubt, benchmark
your system running typical software to find the best balance between area, power, and
performance for your application.
• For a TCM interface that contains mainly instructions, use 64-bit ECC. The vast majority
of reads requested by the prefetch unit are doubleword.
• Use 64-bit ECC when a TCM contains data that is accessed using:
— LDRD or STRD instructions where the start address is doubleword aligned
— LDM or STM instructions where the start address is doubleword aligned and there are
an even number of registers in the register list.
64-bit ECC requires less RAM area, and does not provide any performance loss or
increased power consumption over 32-bit ECC in these cases.
• When LDM and STM instructions are used to access many registers, the majority of TCM
accesses do not require additional reads with 64-bit ECC.
• 32-bit ECC provides better power consumption and generally better performance
compared to 64-bit ECC when:
— a program performs many unaligned accesses to data in a TCM
— a program performs many byte, halfword, and word accesses to data in a TCM.
You might be able to obtain optimal results by using a different error detection scheme on each
TCM interface, and allocating instructions and data to each interface based on the guidelines
given in this section.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. C-2
ID092411 Non-Confidential
Appendix D
Memory Ordering
This appendix describes the processor memory ordering. It contains the following sections:
• Memory ordering on page D-2
• Virtual AXI peripheral interface on page D-3.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. D-1
ID092411 Non-Confidential
Memory Ordering
To maintain ordering between a write and a subsequent read, the Cortex-R5 processor waits for
the write transaction to complete before starting the read. The writes that the Cortex-R5
processor must wait for are any Device-type writes in its write buffer or bus interface and writes
for which the address and data have been accepted by the bus but for which no response has been
received, that is AXI outstanding writes. The latency of the Device read depends on how many
writes must complete before it starts.
The architectural ordering requirements apply only to individual peripherals so, for example, an
outstanding write to a UART does not have to be completed before a read from an interrupt
controller can be started. However, the Cortex-R5 processor views the memory attached the
each interface as flat, so ordering is preserved for all accesses to a given interface. Accesses to
different Cortex-R5 interfaces are not ordered, so selecting which interface is used can improve
the latency of critical Device read accesses.
For example, if a CPU has a number of write transactions outstanding on the AXI master
interface, a read from an interrupt controller attached to the AXI master interface must wait for
those writes to complete and the latency incurred might impact the interrupt handling
performance. Alternatively, if the interrupt controller were attached to the AXI peripheral
interface, the read could start without waiting for the outstanding writes on the AXI master
interface. However, the read would have to wait for any outstanding writes on the AXI
peripheral interface or its buffers.
Note
• The transaction ordering provided by Device memory is useful in situations where the
access has side effects. For example, if the processor writes to a memory-mapped FIFO,
and then reads a different memory-mapped register that indicates whether the FIFO is full,
the value read must reflect the state of the FIFO after the write otherwise an additional
write could be performed, that causes an overflow.
Writes to Device-type memory always drain from the Cortex-R5 buffers as quickly as possible.
If the memory system attached to a port is perfect, that is the write response is returned in the
cycle after the address and data have been received, outstanding accesses cannot accumulate.
Selecting different interfaces for different peripherals does not improve read latencies in such a
system.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. D-2
ID092411 Non-Confidential
Memory Ordering
The two AXI peripheral interfaces use different AXI IDs to enable the memory system to return
responses out of order. They also have different limits on the number of outstanding writes
permitted so, by selecting a particular interface for a peripheral, you can have some control over
the maximum latency of accesses to that peripheral. If your AXI peripheral port memory system
accepts outstanding write transactions, ARM recommends that you configure the peripheral
interfaces so that the most latency critical peripheral, possibly an interrupt controller, is on the
virtual AXI peripheral interface and all others elsewhere.
Note
• The AXI peripheral interface and virtual AXI peripheral interface share write buffer logic,
and write data is drained in order from this buffer. The interfaces use different IDs, so
write responses can be received out-of-order. If the buffer contains writes to both
interfaces, and the AXI peripheral interface writes are older, a virtual AXI peripheral
interface read cannot start until the virtual AXI peripheral interface writes have all
completed, and this in turn requires that the AXI peripheral interface writes have posted
address and data to the bus though not necessarily completed.
• Similarly, if the memory system on the AXI peripheral port returns all write responses in
order, regardless of ID, this can force reads on one interface to wait for writes on a
different interface. The same effect is possible if two CPU ports connect to a common
memory bus that forces ordering.
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. D-3
ID092411 Non-Confidential
Appendix E
Revisions
This appendix describes the technical changes between released issues of this book.
First release - -
Updated AMBA interface clock gating Clock gating on page 2-16 r1p0
System control register enables SWP and SWPB to be Table 4-24 on page 4-39 r1p0
Undefined
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. E-1
ID092411 Non-Confidential
Revisions
Additional description for c15, Build Options 1 Register c15, Build Options 1 Register on page 4-79 All revisions
Update AXI slave address decode information AXI slave interface for cache RAMs on page 9-21 All revisions
Update AXI slave characteristics AXI slave characteristics on page 9-23 All revisions
Changed RAM access using AXI slave interface Accessing RAMs using the AXI slave interface on r1p0
page 9-25
Correct RVPTYSm signal name Table A-8 on page A-14 All revisions
Add BVPTYCS signal description Table A-10 on page A-16 All revisions
Add ARCTLPTYS[3:0] signal description Table A-8 on page A-14 All revisions
Update RAM-Access space reference Cache RAM access on page 9-27 All revisions
Update validation register short names Validation Registers on page 4-68 All revisions
Update descriptions of product revisions Table 4-3 on page 4-15 All revisions
Update description of clock gating Clock gating on page 2-16 All revisions
Update inner cache policy encoding behavior for Table 4-36 on page 4-57 All revisions
write-back, no write-allocate
Table 4-37 on page 4-58
Update description of stall cycle caused by integer divide Table 6-1 on page 6-2 All revisions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. E-2
ID092411 Non-Confidential
Revisions
Add description of overlapping memory About the L2 interface on page 9-2 All revisions
Update latency values for VDIV.F64 and VSQRT.F64 Table B-27 on page B-32 All revisions
ARM DDI 0460D Copyright © 2010-2011 ARM. All rights reserved. E-3
ID092411 Non-Confidential









