ARM AMBA 5 CHI Architecture

® ®

Specification

Confidential

Copyright © 2014 ARM. All rights reserved.

ARM IHI 0050A (ID061214)
 ARM AMBA 5 CHI Architecture Specification
Copyright © 2014 ARM. All rights reserved.
Release Information

The Change history lists the changes made to this specification.

Change history

Date Issue Confidentiality Change

12 June 2014 A Confidential First release

Proprietary Notice

This document is CONFIDENTIAL and any use by you is subject to the terms of the agreement between you and ARM or the
terms of the agreement between you and the party authorised by ARM to disclose this document to you.

This document is protected by copyright and other related rights and the practice or implementation of the information contained
in this document may be protected by one or more patents or pending patent applications. No part of this document may be
reproduced in any form by any means without the express prior written permission of ARM. No license, express or implied, by
estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.

Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use
the information: (i) for the purposes of determining whether implementations infringe any third party patents; (ii) for developing
technology or products which avoid any of ARM’s intellectual property; or (iii) as a reference for modifying existing patents or
patent applications or creating any continuation, continuation in part, or extension of existing patents or patent applications; or
(iv) for generating data for publication or disclosure to third parties, which compares the performance or functionality of the ARM
technology described in this document with any other products created by you or a third party, without obtaining ARM’s prior
written consent.

THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR
PURPOSE WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, ARM makes no representation with respect to,
and has undertaken no analysis to identify or understand the scope and content of, third party patents, copyrights, trade secrets, or
other rights.

This document may include technical inaccuracies or typographical errors.

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,
INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR
CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING
OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.

This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure
of this document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof
is not exported, directly or indirectly, in violation of such export laws. Use of the word “partner” in reference to ARM’s customers
is not intended to create or refer to any partnership relationship with any other company. ARM may make changes to this document
at any time and without notice.

If any of the provisions contained in these terms conflict with any of the provisions of any click through or signed written
agreement covering this document with ARM, then the click through or signed written agreement prevails over and supersedes
the conflicting provisions of these terms. This document may be translated into other languages for convenience, and you agree
that if there is any conflict between the English version of this document and any translation, the terms of the English version of
the Agreement shall prevail.

Words and logos marked with ® or ™ are registered trademarks or trademarks of ARM Limited or its affiliates in the EU and/or
elsewhere. All rights reserved. Other brands and names mentioned in this document may be the trademarks of their respective
owners.

Please follow ARM’s trademark usage guidelines at Trademarks, http://www.arm.com/about/trademark-usage-guidelines.php.

Copyright © 2014, ARM Limited or its affiliates. All rights reserved.

ARM Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.

ii Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A

Confidential ID061214
 In this document, where the term ARM is used to refer to the company it means “ARM or any of its subsidiaries as appropriate”.

Note
The term ARM can refer to versions of the ARM architecture, for example ARMv7 refers to version 7 of the ARM architecture.
The context makes it clear when the term is used in this way.”

Confidentiality Status

This document is Confidential. This document may only be used and distributed in accordance with the terms of the agreement
entered into by ARM and the party that ARM delivered this document to.

Product Status

The information in this document is final, that is for a developed product.

Web Address

http://www.arm.com

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. iii
ID061214 Confidential
iv Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Contents
ARM AMBA 5 CHI Architecture Specification

Preface
About this specification ................................................................................................ x
Feedback ................................................................................................................... xv

Chapter 1 Introduction
1.1 Architecture overview ............................................................................................. 1-18
1.2 Topology ................................................................................................................ 1-20
1.3 Terminology ........................................................................................................... 1-21
1.4 Transaction classification ....................................................................................... 1-23
1.5 Coherence overview .............................................................................................. 1-24
1.6 Component naming ................................................................................................ 1-26

Chapter 2 Transactions
2.1 Channels overview ................................................................................................. 2-30
2.2 Channel Fields ....................................................................................................... 2-31
2.3 Transaction structure ............................................................................................. 2-35
2.4 Introduction to identifier fields ................................................................................ 2-49
2.5 Transaction identifier fields .................................................................................... 2-50
2.6 Transaction identifier field flows ............................................................................. 2-52
2.7 Logical Processor Identifier .................................................................................... 2-61
2.8 Address, Control, and Data .................................................................................... 2-62
2.9 Data transfer .......................................................................................................... 2-70
2.10 Request Retry ........................................................................................................ 2-78

Chapter 3 Network Layer

3.1 System address map ............................................................................................. 3-84
3.2 Node ID .................................................................................................................. 3-85
3.3 Target ID determination for messages from an RN .............................................. 3-86
3.4 Network layer flow examples ................................................................................. 3-88

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. v

ID061214 Confidential
Contents

Chapter 4 Coherence Protocol

4.1 Cache line states .................................................................................................... 4-92
4.2 Request types ........................................................................................................ 4-94
4.3 Snoop requests .................................................................................................... 4-100
4.4 Request types and corresponding snoop requests .............................................. 4-101
4.5 Response types .................................................................................................... 4-103
4.6 Silent cache state transitions ................................................................................ 4-109
4.7 Cache state transitions ......................................................................................... 4-110
4.8 Legal snoop response combinations .................................................................... 4-117
4.9 Hazard conditions ................................................................................................. 4-119

Chapter 5 Interconnect Protocol Flows

5.1 Read transaction flows ......................................................................................... 5-124
5.2 Dataless transaction flows .................................................................................... 5-130
5.3 Write transaction flows ......................................................................................... 5-133
5.4 Interconnect hazard conditions ............................................................................ 5-136

Chapter 6 Exclusive Accesses

6.1 Overview .............................................................................................................. 6-142
6.2 Exclusive monitors ............................................................................................... 6-143
6.3 Exclusive transactions .......................................................................................... 6-146

Chapter 7 Ordering
7.1 Multi-copy atomicity .............................................................................................. 7-152
7.2 Completion Response and Ordering .................................................................... 7-153
7.3 Completion acknowledgement ............................................................................. 7-154
7.4 Transaction ordering ............................................................................................ 7-156
7.5 Barriers ................................................................................................................. 7-161

Chapter 8 DVM Operations

8.1 DVM transaction flow ........................................................................................... 8-166
8.2 DVM Operation types ........................................................................................... 8-174
8.3 DVM Operations ................................................................................................... 8-177

Chapter 9 Error Handling

9.1 Error types ............................................................................................................ 9-184
9.2 Error response fields ............................................................................................ 9-185
9.3 Errors and transaction structure ........................................................................... 9-186
9.4 Error response use by transaction type ................................................................ 9-187
9.5 Hardware and software error categories .............................................................. 9-191

Chapter 10 Quality of Service

10.1 Overview ............................................................................................................ 10-194
10.2 QoS priority value ............................................................................................... 10-195
10.3 Repeating a transaction with higher QoS value ................................................. 10-196

Chapter 11 Link Layer

11.1 Introduction ......................................................................................................... 11-198
11.2 Links ................................................................................................................... 11-199
11.3 Flits ..................................................................................................................... 11-200
11.4 Channels ............................................................................................................ 11-201
11.5 Port ..................................................................................................................... 11-203
11.6 Node interface definitions ................................................................................... 11-204
11.7 Channel interface signals ................................................................................... 11-207
11.8 Flit packet definitions .......................................................................................... 11-210
11.9 Protocol flit fields ................................................................................................ 11-215
11.10 Link flit ................................................................................................................ 11-227

vi Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A

Confidential ID061214
 Contents

Chapter 12 Link Handshake

12.1 Clock, and initialization ...................................................................................... 12-230
12.2 Link layer Credit ................................................................................................. 12-231
12.3 Low power signaling .......................................................................................... 12-232
12.4 Flit level clock gating .......................................................................................... 12-233
12.5 Interface activation and deactivation .................................................................. 12-234
12.6 Transmit and receive link Interaction ................................................................. 12-240
12.7 Protocol layer activity indication ......................................................................... 12-246

Chapter 13 Optional Interface Signals

13.1 Broadcast signals ............................................................................................... 13-252

Appendix A Message Field Mappings

A.1 Request message field mappings ........................................................................ A-255
A.2 Response message field mappings ..................................................................... A-256
A.3 Data message field mappings .............................................................................. A-257
A.4 Snoop Request message field mappings ............................................................ A-258

Appendix B Communicating Nodes

B.1 Request communicating nodes ............................................................................ B-260
B.2 Snoop communicating nodes ............................................................................... B-261
B.3 Response communicating nodes ......................................................................... B-262
B.4 Data communicating nodes ................................................................................. B-263

Appendix C Revisions

Glossary

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. vii
ID061214 Confidential
Contents

viii Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Preface

This preface introduces the AMBA 5 CHI Architecture Specification. It contains the following sections:
• About this specification on page x.
• Using this specification on page x.
• Conventions on page xii.
• Additional reading on page xiv.
• Feedback on page xv.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. ix

ID061214 Confidential
Preface
About this specification

About this specification

This specification describes the AMBA 5 Coherent Hub Interface (CHI) architecture.

Intended audience
This specification is written for hardware and software engineers who want to become familiar with the CHI
architecture and design systems and modules that are compatible with the CHI architecture.

Using this specification

This book is organized into the following chapters:

Chapter 1 Introduction
Read this for an introduction to the CHI architecture, and the terminology used in this specification.

Chapter 2 Transactions
Read this for an overview of the communication channels between nodes, the associated packet
fields, and the transaction structure.

Chapter 3 Network Layer

Read this for a description of the Network layer that is responsible for determining the node ID of
a destination node.

Chapter 4 Coherence Protocol

Read this for an introduction to the coherence protocol.

Chapter 5 Interconnect Protocol Flows

Read this for examples of protocol flows for different transaction types.

Chapter 6 Exclusive Accesses

Read this for a description of the mechanisms that the architecture includes to support exclusive
accesses.

Chapter 7 Ordering
Read this for a description of the mechanisms that the architecture includes to support system
ordering requirements.

Chapter 8 DVM Operations

Read this for a description of DVM operations that the protocol uses to manage virtual memory.

Chapter 9 Error Handling

Read this for a description of the error response requirements.

Chapter 10 Quality of Service

Read this for a description of the mechanisms that the protocol includes to support Quality of
Service (QoS).

Chapter 11 Link Layer

Read this for a description of the Link layer that provides a mechanism for packet based
communication between protocol nodes and the interconnect.

Chapter 12 Link Handshake

Read this for a description of the Link layer handshake requirements.

Chapter 13 Optional Interface Signals

Read this for a description of the optional signals that provide flexibility in the mapping of domain
and Snoopable attributes.

x Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A

Confidential ID061214
 Preface
About this specification

Appendix A Message Field Mappings

Read this for the field mappings for messages.

Appendix B Communicating Nodes

Read this for the node pairs that can legally communicate within the protocol.

Appendix C Revisions
Read this for a description of the technical changes between released issues of this specification.

Glossary Read this for definitions of terms used in this specification.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. xi

ID061214 Confidential
Preface
About this specification

Conventions
The following sections describe conventions that this specification can use:
• Typographical conventions.
• Timing diagrams.
• Signals on page xiv.
• Numbers on page xiv.

Typographical conventions
The typographical conventions are:

italic Highlights important notes, introduces special terminology, and denotes internal
cross-references and citations.

bold Denotes signal names, and is used for terms in descriptive lists, where appropriate.

monospace Used for assembler syntax descriptions, pseudocode, and source code examples.
Also used in the main text for instruction mnemonics and for references to other items
appearing in assembler syntax descriptions, pseudocode, and source code examples.

SMALL CAPITALS Used for a few terms that have specific technical meanings.

Timing diagrams
The Key to timing diagram conventions figure 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 to high impedance

Bus change

High impedance to stable bus

Key to timing diagram conventions

Timing diagrams sometimes show single-bit signals as HIGH and LOW at the same time and they look similar to
the bus change that the Key to timing diagram conventions figure shows. If a timing diagram shows a single-bit
signal in this way then its value does not affect the accompanying description.

xii Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Preface
About this specification

Time-Space diagrams
The Key to Time-Space diagram conventions figure explains the format used to illustrate protocol flow.

Protocol
nodes
RN-F HN-F

I I

Initial cache
state

Allocation
REQ

Direction of
message flow

RESP

Lifetime of a
transaction

Allocated but forward

progress is blocked

Deallocation

Forward progress
is unblocked Time
I->UC

Space

Key to Time-Space diagram conventions

In the Time-Space diagram:

• The protocol nodes are positioned along the horizontal axis and time is indicated vertically, top to bottom.

• The lifetime of a transaction at RN-F is from the allocation time to the de-allocation time.

• The initial cache state at the node is shown at the top.

• The diamond shape on the timeline indicates arrival of a request and whether its processing is blocked
waiting for another event to complete.

• The cache state transition, upon the occurrence of an event, is indicated by I->UC.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. xiii
ID061214 Confidential
Preface
About this specification

Signals
The signal conventions are:

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.

Lowercase n At the start or end of a signal name denotes an active-LOW signal.

Numbers
Numbers are normally written in decimal. Binary numbers are preceded by 0b, and hexadecimal numbers by 0x.
Both are written in a monospace font.

Additional reading
This section lists relevant publications from ARM.

See the Infocenter, http://infocenter.arm.com, for access to ARM documentation.

ARM publications
• AMBA AXI and ACE Protocol Specification (ARM IHI 0022).

xiv Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Preface
Feedback

Feedback
ARM welcomes feedback on its documentation.

Feedback on this specification

If you have comments on the content of this specification, send an e-mail to errata@arm.com. Give:
• The title, ARM AMBA 5 CHI Architecture Specification.
• The number, ARM IHI 0050A.
• The page numbers to which your comments apply.
• A concise explanation of your comments.

ARM also welcomes general suggestions for additions and improvements.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. xv

ID061214 Confidential
Preface
Feedback

xvi Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 1
Introduction

This chapter introduces the CHI architecture and the terminology used throughout this specification. It contains the
following sections:
• Architecture overview on page 1-18.
• Topology on page 1-20.
• Terminology on page 1-21.
• Transaction classification on page 1-23.
• Coherence overview on page 1-24.
• Component naming on page 1-26.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-17
ID061214 Confidential
1 Introduction
1.1 Architecture overview

1.1 Architecture overview

The CHI architecture provides a comprehensive layered specification to build small, medium and large systems
comprising of multiple components using a scalable coherent hub interface and on chip interconnect. The CHI
architecture permits flexibility on the topology of the component connections, and this can be driven from the
system performance, power, and area requirements.

The components of CHI based systems can comprise of standalone processors, processor clusters, graphic
processors, memory controllers, I/O bridges, PCIe subsystems and the interconnect itself.

The key features of the architecture are:

• Scalable architecture enabling modular designs that scale from small to large systems.

• Independent layered approach, comprising of Protocol, Network, and Link layer, with distinct functionalities.

• Packet based communication.

• All transactions handled by an interconnect based Home Node that co-ordinates required snoops, cache, and
memory accesses.

• The CHI coherence protocol supports:

— Coherency granule of 64-byte cache line.
— Snoop filter and directory based systems for snoop scaling.
— Both MESI and MOESI cache models.
— Additional partial and empty cache line states.

• The CHI transactions set includes:

— Enriched transaction types that permit performance, area, and power efficient system cache
implementation.
— Support for atomic operations and synchronization within the interconnect.
— Virtual memory management through Distributed Virtual Memory (DVM) operations.

• Request retry to manage protocol resources.

• Support for end-to-end Quality of Service (QoS).

• Configurable data width to meet the requirements of the system.

• ARM TrustZone™ support on transaction by transaction basis.

• Optional handling of barrier functionality completely at the source without propagation into the interconnect.

• Optimized transaction flow for coherent PCIe writes.

• Error reporting and propagation across components and interconnect for system reliability and integrity
needs.

• Power aware signaling on the component interface:

— Enabling flit level clock gating.
— Component activation and deactivation sequence for clock-gate and power- gate control.
— Protocol activity indication for power and clock control.

1-18 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 1 Introduction
1.1 Architecture overview

1.1.1 Architecture layers

Functionality is grouped into the following layers:
• Protocol.
• Network.
• Link.

Table 1-1 describes the primary function of each layer.

Table 1-1 Layers of the CHI architecture

Communication
Layer Primary function
granularity

Protocol Transaction The Protocol layer is the top-most layer in the CHI architecture. The function
of the Protocol layer is to:
• Generate and process requests and responses at the protocol nodes.
• Define the permitted cache state transitions at the protocol nodes that
include caches.
• Define the transaction flows for each request type.
• Manage the protocol level flow control.

Network Packet The function of the Network layer is to:

• Packetize the protocol message.
• Determine, and add to the packet, the source and target node IDs
required to route the packet over the interconnect to the required
destination.

Link Flit The function of the Link layer is to:

• Provide flow control between network devices.
• Manage link channels to provide deadlock free switching across the
network.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-19
ID061214 Confidential
1 Introduction
1.2 Topology

1.2 Topology
The CHI architecture is primarily topology independent. However, certain topology dependent optimizations are
included in this specification to make implementation more efficient. Figure 1-1 shows three examples of topologies
selected to show the range of interconnect bandwidth and scalability options that are available.

0 1 2 3
0 1 2 3

4 5 6 7 Ring

0
8 9 10 11
1
4×4
Crossbar
2
12 13 14 15
3
4×4 Mesh
0 1 2 3

Protocol node such as processor complex, MC, or I/O complex

Router

Figure 1-1 Example interconnect topologies

Crossbar This topology is simple to build, and naturally provides an ordered network with low latency. It is
suitable where the wire counts are still relatively small. This topology is suitable for an interconnect
with a small number of nodes.

Ring This topology provides a good trade-off between interconnect wiring efficiency and latency. The
latency linearly increases with the number of nodes on the ring. This topology is suitable for a
medium size interconnect.

Mesh This topology provides greater bandwidth at the cost of more wires. It is very modular and can be
easily scaled to larger systems by adding more rows and columns of switches. This topology is
suitable for a larger scale interconnect.

1-20 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 1 Introduction
1.3 Terminology

1.3 Terminology
The following terms have a specific meaning in this specification:

Transaction A transaction carries out a single operation. Typically, a transaction either reads from
memory or writes to memory.

Message A Protocol layer term that defines the granule of exchange between two components.
Examples are:
• Request.
• Data response.
• Snoop request.
A single Data response message might be made up of a number of packets.

Packet The granule of transfer over the interconnect between endpoints. A message might be made
up of one or more packets. For example, a single Data response message might be made up
of 1 to 4 packets. Each packet contains routing information, such as destination ID and
source ID that enables it to be routed independently over the interconnect.

Flit The smallest flow control unit. A packet might be made up of one or more flits. All the flits
of a given packet follow the same path through the interconnect.

Note
For CHI, all packets consist of a single flit.

Phit The physical layer transfer unit. A flit might be made up of one or more phits. A phit is
defined as one transfer between two adjacent network devices.

Note
For CHI, all flits consist of a single phit.

PoS Point of Serialization. A point within the interconnect where the ordering between Requests
from different agents is determined.

PoC Point of Coherence. A point at which all agents that can access memory are guaranteed to
see the same copy of a memory location. In a typical CHI based system it is the HN-F in the
interconnect.

Downstream cache A downstream cache is defined from the perspective of a Request node. A downstream
cache for a Request, is a cache that the Request accesses using CHI Request transactions. A
Request Node can allocate cache lines into a downstream cache.

Requester A component that starts a transaction by issuing a Request message. The term Requester can
be used for a component that independently initiates transactions and such a component is
also referred to as a master. The term Requester can also be used for an interconnect
component that issues a downstream Request message as a side-effect of other transactions
that are occurring in the system.

Completer Any component that responds to a transaction it receives from another component. A
Completer can either be an interconnect component or a component, such as a slave, that is
outside of the interconnect.

Master An agent that independently issues transactions. Typically a master is the most upstream
agent in a system. A master can also be referred to as a Requester.

Slave An agent that receives transactions and completes them appropriately. Typically, a slave is
the most downstream agent in a system. A slave can also be referred to as a Completer or
Endpoint.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-21
ID061214 Confidential
1 Introduction
1.3 Terminology

Endpoint Another name for a slave component. As the name implies, an endpoint is the final
destination for a transaction.

Protocol Credit A credit, or guarantee, from a Completer that it will accept a transaction.

Link layer Credit A credit, or guarantee, that a flit will be accepted on the other side of the link. A Link layer
Credit (L-Credit) can be considered to be a credit for a single hop at the Link layer.

ICN A short form of interconnect, which is the CHI transport mechanism that is used for
communication between protocol nodes. An ICN might include a fabric of switches
connected in a ring, mesh, crossbar, or some other topology. The ICN might include
protocol nodes such as Home Node and Misc Node. The topology of the ICN is
IMPLEMENTATION DEFINED.

RN Request Node. Generates protocol transactions, including reads and writes, to the
interconnect.

HN Home Node. Node located within the interconnect that receives protocol transactions from
Request Nodes.

SN Slave Node. Node that receives a Request from a Home Node, completes the required
action, and returns a Response.

IO Coherent node An RN that generates some Snoopable requests in addition to Non-snoopable requests. The
Snoopable requests that an IO Coherent node generates do not result in the caching of the
received data in a coherent state. Therefore, an IO Coherent node does not receive any
Snoop requests.

Write-Invalidate protocol
A protocol in which an RN writing to a cache line that is shared in the system must
invalidate all the shared copies before proceeding with the write. The CHI protocol is a
Write-Invalidate protocol.

In a timely manner The protocol cannot define an absolute time within which something must occur. However,
in a sufficiently idle system, it will make progress and complete without requiring any
explicit action.

Don’t Care A field value that indicates that the field can be set to any value, including reserved or illegal
values. Any component receiving a packet with a field value set to Don't Care must ignore
the value set for that field.

1-22 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 1 Introduction
1.4 Transaction classification

1.4 Transaction classification

A transaction comprises a series of messages passed between component nodes. A transaction typically requires:
• A Request message to be sent from a Requester to the interconnect.
• For a coherent request, the interconnect to spawn additional Snoop transactions to peer Requesters.
• The snooped Requesters to send snoop response messages back to the interconnect, with or without data.
• The interconnect to send a Request message to a slave.
• The slave to send a Response message back to the interconnect, with or without data.
• The interconnect to send a Response message back to the original Requester, with or without data.

The protocol transactions that this specification supports, and their major classification, is as follows:
Read
• ReadNoSnp.
• ReadOnce.
• ReadClean.
• ReadShared.
• ReadUnique.
Dataless
• CleanUnique.
• MakeUnique.
• CleanShared.
• CleanInvalid.
• MakeInvalid.
• Evict.
Write
• WriteNoSnp.
• WriteBack.
• WriteClean.
• WriteEvict.
• WriteUnique.
Other
• DVMOp.
• EOBarrier.
• ECBarrier.
• PCrdReturn.
Snoop
• SnpOnce.
• SnpClean.
• SnpShared.
• SnpUnique.
• SnpCleanShared.
• SnpCleanInvalid.
• SnpMakeInvalid.
• SnpDVMOp.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-23
ID061214 Confidential
1 Introduction
1.5 Coherence overview

1.5 Coherence overview

Hardware coherency enables the sharing of memory by system components without the software requirement to
perform software cache maintenance to maintain coherency between caches.

Regions of memory are coherent if writes to the same memory location by two components are observable in the
same order by all components.

1.5.1 Coherency model

Figure 1-2 shows an example coherent system that includes three master components, each with a local cache and
coherent protocol node. The protocol permits cached copies of the same memory location to reside in the local cache
of one or more master components.

Master 1 Master 2 Master 3

RN-F RN-F RN-F

Optional
Cache Cache Cache
cache

Coherent interconnect
ICN (ICN) Cache

Main
SN-F
memory

Slave 1

Figure 1-2 Example coherency model

The coherence protocol ensures that all masters observe the correct data value at any given address location by
enforcing that no more than one copy exists whenever a store occurs to the location. After each store to a location,
other masters can obtain a new copy of the data for their own local cache, to permit multiple cached copies to exist.

All coherency is maintained at cache line granularity. A cache line is defined as a 64-byte aligned memory region
64-bytes in size.
The protocol does not require main memory to be up to date at all times. Main memory is only required to be updated
before a copy of the memory location is no longer held in any cache.

Note
Although not a requirement, it is acceptable to update main memory while cached copies still exist.

The protocol enables master components to determine whether a cache line is the only copy of a particular memory
location, or if there might be other copies of the same location, so that:

• If a cache line is the only copy, a master component can change the value of the cache line without notifying
any other master components in the system.

• If a cache line might also be present in another cache, a master component must notify the other caches, using
an appropriate transaction.

1-24 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 1 Introduction
1.5 Coherence overview

1.5.2 Cache state model

To determine whether an action is required when a component accesses a cache line, the protocol defines cache
states. Each cache state is based on the following cache line characteristics:

Valid, Invalid When Valid, the cache line is present in the cache. When Invalid, the cache line is not
present in the cache.

Unique, Shared When Unique, the cache line exists only in this cache. When Shared, the cache line might
exist in more than one cache, but this is not guaranteed.

Clean, Dirty When Clean, the cache does not have responsibility for updating main memory. When Dirty,
the cache line has been modified with respect to main memory, and this cache must ensure
that main memory is eventually updated.

Full, Partial, Empty A Full cache line has all bytes valid. A Partial cache line might have some bytes valid, but
not all bytes valid. An Empty cache line has no bytes valid.

Figure 1-3 shows the seven state cache model. Cache line states on page 4-92 gives further information about each
cache state.

Note
A valid cache state name that is not Partial or Empty is considered to be Full. In Figure 1-3 UC, UD, SC, and SD
are all Full cache line states.

Valid Invalid

Unique Shared

UC SC
Clean
UCE
I
UD SD
Dirty
UDP

Figure 1-3 Cache state model

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-25
ID061214 Confidential
1 Introduction
1.6 Component naming

1.6 Component naming

Components are classified by CHI protocol node type:

RN Request Node. Generates protocol transactions, including reads and writes to the interconnect.
An RN is further categorized as:
RN-F Fully coherent Request Node:
• Includes a hardware-coherent cache.
• Permitted to generate all transactions defined by the protocol.
• Supports all snoop transactions.
RN-D IO coherent Request Node with DVM support:
• Receives DVM transactions.
• Does not include a hardware-coherent cache.
• Generates a subset of transactions defined by the protocol.
• Includes snoop functionality to receive DVM transactions.
RN-I IO coherent Request Node:
• Does not include a hardware-coherent cache.
• Does not receive DVM transactions.
• Generates a subset of transactions defined by the protocol.
• Does not require snoop functionality.

HN Home Node. Node located within the interconnect that receives protocol transactions from RNs.
An HN is further categorized as:
HN-F Is expected to receive all Request types except DVMOp and Barrier:
• Includes a Point of Coherence (PoC) that manages coherency by snooping the
required RN-Fs, consolidating the snoop responses for a transaction, and sending
a single response to the requesting RN.
• Is expected to be the Point of Serialization (PoS) that manages order between
memory requests.
• Might include a directory or snoop filter to reduce redundant snoops.
Note
IMPLEMENTATION SPECIFIC, can include an integrated ICN cache.

HN-I Processes a limited subset of request types defined by the protocol:

• Is expected to be the PoS which manages order for requests targeting the IO
subsystem.
• Does not include a PoC and is not capable of processing a Snoopable request.
MN Miscellaneous Node:
• Receives a Barrier or DVM transaction from an RN, completes the required
action, and returns a response.

SN Slave Node. An SN receives a request from an HN, completes the required action and returns a
response.
An SN is further categorized as:
SN-F A slave node type used for Normal memory. It can process Non-snoopable read and
write requests, including exclusive variants of them.
SN-I A slave node type used for peripherals or Normal memory. It can process
Non-snoopable read and write requests, including exclusive variants of them, and
Barriers.

1-26 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 1 Introduction
1.6 Component naming

Figure 1-4 shows various protocol node types connected through an interconnect.

Masters
(Fully coherent)

RN-F0 RN-F1 RN-F2

Master
(IO coherent)
Interconnect (ICN)
MN

RN-I

HN-I HN-F HN-F

SN-I SN-F

Slave Slave
(Peripheral and/or Memory) Slaves (Memory)

Figure 1-4 Protocol node examples

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 1-27
ID061214 Confidential
1 Introduction
1.6 Component naming

1-28 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 2
Transactions

This chapter gives an overview of the communication channels between nodes, the associated packet fields, and the
transaction structure. It contains the following sections:
• Channels overview on page 2-30.
• Channel Fields on page 2-31.
• Transaction structure on page 2-35.
• Introduction to identifier fields on page 2-49.
• Transaction identifier fields on page 2-50.
• Transaction identifier field flows on page 2-52.
• Logical Processor Identifier on page 2-61.
• Address, Control, and Data on page 2-62.
• Data transfer on page 2-70.
• Request Retry on page 2-78.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-29
ID061214 Confidential
2 Transactions
2.1 Channels overview

2.1 Channels overview

Communication between nodes is channel based. Table 2-1 shows the channel naming and the channel designations
at the RN and SN nodes.

This section uses shorthand naming for the channels to describe the transaction structure. Table 2-1shows the
shorthand naming and the physical channel name that exists on the RN or SN component.

See Channels on page 11-201 for the mapping of physical channels on the RN and SN components.

Table 2-1 Channel naming and designation at the RN and SN nodes

Channel RN channel designation SN channel designation

REQ TXREQ. Outbound Request. RXREQ. Inbound Request.

WDAT TXDAT. Outbound Data. RXDAT. Inbound Data.

Used for write data and snoop data. Used for write data.

SRSP TXRSP. Outbound Response. -

Used for Snoop Response and Completion Acknowledge.

CRSP RXRSP. Inbound Response. TXRSP. Outbound Response.

Used for responses from the Completer. Used for responses from the Completer.

RDAT RXDAT. Inbound Data. TXDAT. Outbound Data.

Used for read data. Used for read data.

SNP RXSNP. Inbound Snoop Request. -

2-30 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.2 Channel Fields

2.2 Channel Fields

This section gives a brief overview of the channel fields and indicates which fields will affect the transaction
structure. The fields associated with each channel are described in the following sections:
• Transaction request fields.
• Snoop request fields on page 2-32.
• Data fields on page 2-33.
• Response fields on page 2-34.

2.2.1 Transaction request fields

Table 2-2 shows the fields associated with a Request packet.

The term transaction structure is used to describe the different packets that build a transaction and the transaction
structure can vary depending on a number of factors. Table 2-2 shows which Request fields can affect the
transaction structure. More information on the different transaction structures can be found in Transaction structure
on page 2-35 and Flit packet definitions on page 11-210.

Table 2-2 Request channel fields

Affects
Field Description
structure

QoS No Quality of Service priority. Specifies 1 of 16 possible priority levels for the
transaction with ascending values of QoS indicating higher priority levels. See
Chapter 10 Quality of Service.

TgtID No Target ID. The physical node ID of the port on the interconnect to which the
packet is targeted. See Transaction identifier fields on page 2-50 and System
address map on page 3-84.

SrcID No Source ID. The physical node ID of the port on the interconnect from which the
packet was sent. See Transaction identifier fields on page 2-50.

TxnID No Transaction ID. A transaction has a unique transaction ID per source node. See
Transaction identifier fields on page 2-50.

Opcode Yes Request opcode. Specifies the transaction type and is the primary field that
determines the transaction structure. See Request types on page 4-94 and REQ
channel opcodes on page 11-216.

Size Yes Data size. Specifies the size of the data associated with the transaction. This
determines the number of data packets within the transaction. See Data transfer
on page 2-70.

Addr No Address. The address of the memory location being accessed for read and write
requests. See Address on page 2-62 and Addr on page 11-219.

NS No Non-secure. Determines if the transaction is Non-secure or Secure. See

Non-secure bit on page 2-62 and NS on page 11-219.

LikelyShared No Likely Shared. Provides an allocation hint for downstream caches. See Memory
Attributes on page 2-62.

AllowRetry Yes Allow Retry. Determines if the transaction has a pre-allocated credit and if the
target is permitted to give a Retry response. See Request Retry on page 2-78.

Order Yes Order requirement. Determines the ordering requirement for this request with
respect to other transactions from the same agent. See Chapter 7 Ordering.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-31
ID061214 Confidential
2 Transactions
2.2 Channel Fields

Table 2-2 Request channel fields (continued)

Affects
Field Description
structure

PCrdType No Protocol Credit Type. Indicates the type of Protocol Credit being used by a
request that has the AllowRetry field deasserted. See Request Retry on
page 2-78.

MemAttr No Memory attribute. Determines the memory attributes associated with the
transaction. See Memory Attributes on page 2-62.

SnpAttr No Snoop attribute. Specifies the snoop attributes associated with the transaction.
See Snoop Attribute on page 2-65.

LPID No Logical processor ID. Used in conjunction with the SrcID field to uniquely
identify the logical processor that generated the request. See Logical Processor
Identifier on page 2-61.

Excl No Exclusive access. Indicates that the corresponding transaction is an exclusive

access transaction. See Chapter 6 Exclusive Accesses.

ExpCompAck Yes Expect CompAck. Indicates that the transaction will include a Completion
Acknowledge message. See Transaction structure on page 2-35 and Chapter 7
Ordering.

RSVDC No User defined. See RSVDC on page 11-223.

2.2.2 Snoop request fields

A Snoop request contains a subset of the fields defined for a Request packet. Table 2-3 shows which Request fields
can affect the transaction structure.

Table 2-3 Snoop request fields

Affects
Field Description
structure

QoS No Quality of Service priority. See Chapter 10 Quality of Service.

TxnID No Transaction ID. See Transaction identifier fields on page 2-50.

SrcID No Source ID. See Transaction identifier fields on page 2-50.

Opcode Yes Snoop opcode. See Snoop request fields and SNP channel opcodes on page 11-218.

Addr No Address. The address of the memory location being accessed for snoop requests.
See Address on page 2-62 and Addr on page 11-219.

NS No Non-secure or Secure access. See Non-secure bit on page 2-62 and NS on

page 11-219.

2-32 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.2 Channel Fields

2.2.3 Data fields

Table 2-4 describes the fields associated with a Data packet. Data packets can be sent on the RDAT or WDAT
channels. The fields in a Data packet do not affect the transaction structure.

Table 2-4 Data packet fields

Field Description

QoS Quality of Service priority. See Chapter 10 Quality of Service.

TgtID Target ID. See Transaction identifier fields on page 2-50.

SrcID Source ID. See Transaction identifier fields on page 2-50.

TxnID Transaction ID. See Transaction identifier fields on page 2-50.

Opcode Data opcode. Indicates, for example, if the data packet is related to a Read
transaction, a Write transaction, or a Snoop transaction. See DAT channel
opcodes on page 11-218.

RespErr Response Error status. Indicates the error status of the response. See
Chapter 6 Exclusive Accesses and Error response fields on page 9-185.

Resp Response status. Used to indicate the cache line state associated with a Data
transfer. See Response types on page 4-103.

DBID Data Buffer ID. See Transaction identifier fields on page 2-50 and Chapter 7
Ordering.

CCID Critical Chunk Identifier. Replicates the address offset of the original
transaction request. See Data transfer on page 2-70.

DataID Data Identifier. Provides the address offset of the data provided in the packet.
See Data transfer on page 2-70.

BE Byte Enable. For a data write, or data provided in response to a snoop,

indicates which bytes are valid. See Data transfer on page 2-70.

Data Data payload. See Data transfer on page 2-70.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-33
ID061214 Confidential
2 Transactions
2.2 Channel Fields

2.2.4 Response fields

Table 2-5 describes the fields associated with a Response packet. The fields in a Response packet do not affect the
transaction structure.

Table 2-5 Response packet fields

Field Description

QoS Quality of Service priority. See Chapter 10 Quality of Service.

TgtID Target ID. See Transaction identifier fields on page 2-50.

SrcID Source ID. See Transaction identifier fields on page 2-50.

TxnID Transaction ID. See Transaction identifier fields on page 2-50.

Opcode Response opcode. Specifies the response type. See RSP channel opcodes on
page 11-217.

RespErr Response Error status. Indicates the error status of the response. See
Chapter 6 Exclusive Accesses and Error response fields on page 9-185.

Resp Response status. Used to indicate the cache line state associated with a
Response. See Response types on page 4-103.

DBID Data Buffer ID. See Transaction identifier fields on page 2-50 and Chapter 7
Ordering.

PCrdType Protocol Credit Type. See PCrdType on page 2-80.

2-34 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

2.3 Transaction structure

This section describes the structure of the transactions described in Transaction classification on page 1-23 together
with the channel usage.

The structure of a transaction is described as seen at a single interface. The transaction types presented in this section
are:
• Request transactions without a Retry.
• Request transactions with a Retry.
• Snoop transactions.

For a Request transaction to complete, a Snoop transaction might be required. However, such dependencies are not
visible at the Requester, so these two transaction types are presented separately. See Chapter 5 Interconnect Protocol
Flows for examples of how Request and Snoop flows are related.

All transaction types, except PCrdReturn, can have a Retry sequence at the start of the transaction. For ease of
presentation, the Retry sequence is described separately. See Transaction Retry sequence on page 2-45.

2.3.1 Request transaction structure

The Request transaction structure is described in the following groupings:
• ReadNoSnp, ReadOnce.
• Snoopable Read on page 2-37.
• Snoopable Dataless on page 2-38.
• WriteNoSnp on page 2-39.
• WriteUnique on page 2-41.
• CopyBack on page 2-43.
• Barrier on page 2-44.
• DVM on page 2-44.

ReadNoSnp, ReadOnce
A ReadNoSnp transaction is used to carry out a read when the snooping of other masters is not required.

A ReadOnce transaction is used to carry out a read when the snooping of other masters is required but the Requester
is not going to Allocate the cache line in its own cache.

Note
ReadOnce obtains a snapshot of the coherent data value. If a component holds this value in a local buffer, or cache,
the data value will no longer be coherent.

There are two optional behaviors associated with a ReadNoSnp and ReadOnce transaction that are determined by
fields in the transaction request:
• The Order field of the request determines if the transaction requires a ReadReceipt.
• The ExpCompAck field of the request determines if the transaction requires a CompAck.

The progress of the ReadNoSnp or ReadOnce transaction is as follows:

1. The Requester sends a request with the ReadNoSnp or ReadOnce opcode on the REQ channel.

2. If the request Order field indicates that ordering is required then a ReadReceipt response must be returned on
the CRSP channel when order has been established.

3. The Completer returns the read data and any associated transaction response with the CompData opcode on
the RDAT channel. The read data can be sent using multiple transfers. See Data transfer on page 2-70.

4. If the transaction request ExpCompAck bit is set, the Requester must return an acknowledgement, using the
CompAck opcode on the SRSP channel to indicate that the transaction has completed. This must not be sent
until all transfers of read data have been received.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-35
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Figure 2-1 shows the transaction structure.

RN ICN

ReadNoSnp
REQ
ReadOnce

CRSP ReadReceipt

ReadReceipt is sent if
RDAT CompData Order is set in the
transaction request.

SRSP CompAck

CompAck is sent if
ExpCompAck is set in
the transaction request.

Figure 2-1 ReadNoSnp and ReadOnce structure

The Request/Response rules are:

• ReadReceipt, if part of the transaction:

— Must only be sent by the Completer after the associated request is received.
— Typically is sent by the Completer before CompData. However it is permitted to be sent after
CompData.
— Typically is received by the Requester before CompData. However it is permitted to be received after
CompData.

• CompData must only be sent by the Completer after the associated request is received.

• CompAck, if part of the transaction, must only be sent by the Requester after all transfers of CompData are
received.

• The Requester is permitted, but not required, to wait for the ReadReceipt before sending CompAck.

• The Completer is not permitted to wait for the CompAck before sending the ReadReceipt.

2-36 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

Snoopable Read
The Snoopable Read transactions are:
• ReadClean.
• ReadShared.
• ReadUnique.

Snoopable Read transactions are used by a fully coherent Requester (RN-F) to carry out a read when the snooping
of other Snoopable Requesters (RN-Fs) is required.

The progress of a Snoopable Read transaction is as follows:

1. The Requester sends a request on the REQ channel that includes the opcode for one of the following
transactions:
• ReadClean.
• ReadShared.
• ReadUnique.

2. The Completer returns the read data and any associated transaction response with the CompData opcode on
the RDAT channel. The read data can be sent using multiple transfers. See Data transfer on page 2-70.

3. The Requester returns an acknowledgement that the transaction has completed with the CompAck opcode on
the SRSP channel. This must only be sent after all transfers of read data are received.

Figure 2-2 shows the transaction structure.

RN ICN

Snoopable
REQ
Read

RDAT CompData

SRSP CompAck

Figure 2-2 Snoopable Read transaction structure

The Request/Response rules are:

• CompData must only be sent by the Completer after the associated request is received.
• CompAck must only be sent by the Requester after all transfers of CompData are received.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-37
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Snoopable Dataless
The Snoopable Dataless transactions are:
• CleanUnique.
• MakeUnique.
• CleanShared.
• CleanInvalid.
• MakeInvalid.
• Evict.

These transactions serve a number of functions such as:

• Obtaining permission to store to a cache.
• Performing cache maintenance.
• Updating the state of a snoop filter.

The progress of a Snoopable Dataless transaction is as follows:

1. The Requester sends a request on the REQ channel that includes the opcode for one of the following
transactions:
• CleanUnique.
• MakeUnique.
• CleanShared.
• CleanInvalid.
• MakeInvalid.
• Evict.

2. The Completer returns a Comp response on the CRSP channel. Only a single response is given for Dataless
transactions.

3. If the transaction request ExpCompAck field is set, the Requester must return an acknowledgement that the
transaction has completed with the CompAck opcode on the SRSP channel:
• For CleanUnique and MakeUnique, ExpCompAck must be set.
• For CleanShared, CleanInvalid and MakeInvalid, setting ExpCompAck is optional.
• For Evict, ExpCompAck must not be set.

2-38 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

Figure 2-3 shows the transaction structure.

RN ICN

Snoopable
REQ
Dataless

CRSP Comp

SRSP CompAck

CompAck is sent if
ExpCompAck is set in the
transaction request.

Figure 2-3 Snoopable Dataless transaction structure

The Request/Response rules are:

• Comp must only be sent by the Completer after the associated request is received.
• CompAck must only be sent by the Requester after the associated Comp is received.

WriteNoSnp
The WriteNoSnp transactions are:

• WriteNoSnpPtl, WriteNoSnpFull.

A WriteNoSnp transaction is used to carry out a store where the snooping of other masters is not required.

The progress of the WriteNoSnp transaction is as follows:

1. The Requester sends a request with the WriteNoSnpPtl or WriteNoSnpFull opcode on the REQ channel.

2. The Completer has one of the following options:

• Return separate responses:
— Return a DBIDResp response that provides a data buffer identifier to indicate that it can accept
the write data for the transaction.
— Provide a Comp response to indicate that the transaction is observable by other Requesters.
Both responses are sent on the CRSP channel.
• Return a single combined CompDBIDResp response to indicate:
— It can accept the write data for the transaction.
— The transaction is observable by other Requesters.
The combined response is sent on the CRSP channel.

3. The Requester sends the write data and any associated byte enables with the NonCopyBackWrData opcode
on the WDAT channel. The write data can be sent using multiple transfers. See Data transfer on page 2-70.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-39
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Figure 2-4 shows the transaction structure options.

RN ICN RN ICN

REQ WriteNoSnp REQ WriteNoSnp

DBIDResp
CRSP CRSP CompDBIDResp
Comp

WDAT WriteData WDAT WriteData

WriteData refers to
RN ICN NonCopyBackWrData

REQ WriteNoSnp

Comp response
permitted to wait
CRSP DBIDResp for WriteData

WDAT WriteData

CRSP Comp

Figure 2-4 WriteNoSnp transaction structure options

The Request/Response rules are:

• The separate DBIDResp and Comp, or the combined CompDBIDResp, must only be sent by the Completer
after the associated request is received.

• WriteData must only be sent by the Requester after either DBIDResp or CompDBIDResp is received.

• If the DBIDResp and Comp responses are sent separately:

— The Requester must send the write data after it has received the DBIDResp response. The Requester
must not wait to receive the Comp response before the write data is sent.
— Typically the DBIDResp is sent by the Completer before Comp. However it is permitted for
DBIDResp and Comp to be sent in any order.
— Typically the DBIDResp is received by the Requester before Comp. However it is permitted for
DBIDResp and Comp to arrive in any order.

• The Completer is permitted to wait for the WriteData before sending the Comp response.

2-40 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

WriteUnique
The WriteUnique transactions are:

• WriteUniquePtl, WriteUniqueFull.

WriteUnique transactions are used to perform a store to a location when the snooping of other Snoopable Requesters
(RN-Fs) might be required to obtain permission to store.

There is one optional behavior associated with WriteUnique transactions. The behavior is determined by the Order
field in the transaction request. See Streaming Ordered WriteUnique transactions on page 7-159 for details on the
use of CompAck to force the order in which requests are observed.

Note
When the Order field is non-zero, the Requester must also set the ExpCompAck field and the transaction
must complete with a CompAck transaction acknowledge.

The progress of the WriteUnique transaction is as follows:

1. The Requester sends a request with the WriteUniquePtl or WriteUniqueFull opcode on the REQ channel.

2. The Completer has one of the following options:

• Return separate responses:
— Return a DBIDResp response that provides a data buffer identifier indicating that it can accept
the write data for the transaction.
— Return a Comp response to indicate that the transaction is observable by other Requesters.
Both responses are sent on the CRSP channel.
• Return a single combined CompDBIDResp response to indicate:
— It can accept the write data for the transaction.
— The transaction is observable by other Requesters.
The combined response is sent on the CRSP channel.

3. The Requester sends the write data and any associated byte enables with the NonCopyBackWrData opcode
on the WDAT channel. The write data can be sent using multiple transfers. See Data transfer on page 2-70.

4. If the ExpCompAck field is set in the transaction request, then the transaction completes with a CompAck
transaction acknowledge.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-41
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Figure 2-5 shows the transaction structures.

RN ICN RN ICN

REQ WriteUnique REQ WriteUnique

DBIDResp
CRSP CRSP CompDBIDResp
Comp

WDAT WriteData WDAT WriteData

SRSP CompAck SRSP CompAck

CompAck is sent if CompAck is sent if

ExpCompAck is set in the ExpCompAck is set in the
transaction request. transaction request.

Figure 2-5 WriteUnique transaction structure options

The Request/Response rules are:

• The separate DBIDResp and Comp, or the combined CompDBIDResp, must only be sent by the interconnect
after the associated request is received.

• WriteData must only be sent by the Requester after either DBIDResp or CompDBIDResp is received.

• If the DBIDResp and Comp responses are sent separately:

— The Requester must send the write data after it has received the DBIDResp response. The Requester
must not wait to receive the Comp response before the write data is sent.
— Typically the DBIDResp is sent by the Completer before Comp. However it is permitted for
DBIDResp and Comp to be sent in any order.
— Typically the DBIDResp is received by the Requester before Comp. However it is permitted for
DBIDResp and Comp to arrive in any order.
— The Requester is permitted to wait for the DBIDResp response before sending a CompAck.
— The Completer must not wait for WriteData before sending Comp.

• If the CompAck acknowledge is part of the transaction then CompAck must only be sent by the Requester
after either the Comp or CompDBIDResp response is received.
— The Requester is permitted to send the WriteData and CompAck in any order.

2-42 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

CopyBack
The CopyBack transactions are:
• WriteBackPtl, WriteBackFull.
• WriteCleanPtl, WriteCleanFull.
• WriteEvictFull.

CopyBack transactions, except WriteEvictFull, are used to update main memory or a downstream cache for a
coherent location.

A WriteEvictFull transaction is used to update only a downstream cache for a coherent location.

A WriteEvictFull must not propagate beyond its Snoop domain.

A CopyBack transaction does not require the snooping of other masters.

The progress of a CopyBack transaction is as follows:

1. The Requester sends a request on the REQ channel that includes the opcode for one of the following
transactions:
• WriteBackPtl, WriteBackFull.
• WriteCleanPtl, WriteCleanFull.
• WriteEvictFull.

2. The Completer returns a single combined CompDBIDResp response on the CRSP channel to indicate:
• It can accept the write data for the transaction.
• This request will complete before any snoop to the same address is received.

3. After the Requester has received the CompDBIDResp response it sends the write data, and any associated
byte enables, with the CopyBackWrData opcode on the WDAT channel. The write data can be sent using
multiple transfers. See Data transfer on page 2-70.

Figure 2-6 shows the transaction structure.

RN ICN

REQ CopyBack

CRSP CompDBIDResp

WDAT WriteData

Figure 2-6 CopyBack transaction structure

The Request/Response rules are:

• CompDBIDResp must only be sent by the Completer after the associated request is received.
• WriteData must only be sent by the Requester after the CompDBIDResp response is received.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-43
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Barrier
The Barrier transactions are:
• EOBarrier.
• ECBarrier.
A Barrier transaction is used to ensure ordering of two groups of transactions.

The progress of a Barrier transaction is as follows:

1. The Requester sends a request on the REQ channel that includes the opcode for one of the following
transactions:
• EOBarrier.
• ECBarrier.
2. The Completer returns a single Comp response on the CRSP channel.

Figure 2-7 shows the transaction structure.

RN ICN

REQ Barrier

CRSP Comp

Figure 2-7 Barrier transaction structure

The Request/Response rules are:

• Comp must only be sent by the Completer after the associated request is received.

DVM
The DVM transaction is DVMOp.

A DVM transaction is used to send a Distributed Virtual Memory (DVM) operation.

The progress of the DVM transaction is as follows:

1. The Requester sends a request with the DVMOp opcode on the REQ channel.

2. The Completer returns a DBIDResp response that provides a data buffer identifier indicating that it can
accept the write data for the transaction.

3. The Requester sends the write data for the DVM transaction, with the NonCopyBackWrData opcode, on the
WDAT channel. Only a single data transfer occurs for a DVM transaction.

4. The Completer returns a Comp response on the CRSP channel.

2-44 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

Figure 2-8 shows the transaction structure.

RN ICN

REQ DVMOp

CRSP DBIDResp

WDAT WriteData

CRSP Comp

Figure 2-8 DVM transaction structure

The Request/Response rules are:

• DBIDResp must only be sent by the Completer after the associated request is received.
• WriteData must only be sent by the Requester after the DBIDResp response is received.
• Comp must only be sent by the Completer after the data transfer is received.

2.3.2 Transaction Retry sequence

All Request transactions, as described in Request transaction structure on page 2-35, can begin with a Retry
sequence.

Retry sequence
Request transactions are first sent without a Protocol Credit (P-Credit). If the transaction cannot be accepted at its
Completer, then a RetryAck response must be given that indicates that the transaction has not been accepted and
can be sent again when an appropriate credit is provided. When a transaction is sent once more, with a credit, it is
guaranteed to be accepted.

For further details on the Retry process and the use of credits see Request Retry on page 2-78.

The transaction Retry sequence is as follows:

1. The Requester sends a request, without a P-Credit, on the REQ channel.

2. The Completer provides a RetryAck response on the CRSP channel.

3. The Completer provides a PCrdGrant response on the CRSP channel, when appropriate, to indicate that a
credit is available to re-send the transaction.

4. The Requester sends the transaction again, with a credit, on the REQ channel.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-45
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Figure 2-9 shows the RetryAck sequence.

RN ICN

Transaction
REQ
no Credit

RetryAck
CRSP
PCrdGrant

Transaction
REQ
with Credit

Figure 2-9 Transaction Retry sequence

The transaction Retry sequence rules are:

• RetryAck must only be sent by the Completer after the associated request is received.

• PCrdGrant must only be sent by the Completer after the associated request is received.

• RetryAck is typically sent by the Completer before PCrdGrant. However, it is permitted to send RetryAck
after PCrdGrant.

• RetryAck is typically received by the Requester before PCrdGrant. However, it is permitted to receive
RetryAck after PCrdGrant.

• The transaction with credit must only be sent by the Requester after both the RetryAck response and an
appropriate PCrdGrant response are received.

Cancelled transaction
The protocol supports the cancelling of a transaction between the point that it receives a RetryAck and the point that
it is resent using a credit. The sequence is identical to the transaction Retry sequence that Figure 2-9 shows, except
that the final transaction with credit is sent as a PCrdReturn transaction. This acts as a null transaction and returns
the credit to the Completer.

The sequence and rules are identical to those for a Retry sequence.

Figure 2-10 shows the cancelled transaction sequence.

RN ICN

Transaction
REQ
no Credit

RetryAck
RSP
PCrdGrant

REQ PCrdReturn

Figure 2-10 Cancelled transaction sequence

2-46 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.3 Transaction structure

2.3.3 Snoop transactions

Snoop transactions are sent from the interconnect to a Request Node:

• An RN-F is fully coherent and is required to accept all Snoop transactions.

• An RN-D only accepts a DVM maintenance operation and is only required to support the SnpDVMOp
transaction.

• An RN-F and RN-D must respond to received snoop requests, in a timely manner, without creating any
dependency on completion of outstanding requests.

There are three options for the transaction structure of a snoop:

• Snoop without a data return.
• Snoop with a data return.
• Snoop DVM operation.

The following Snoop transactions always complete without a data response:

• SnpMakeInvalid.

The following Snoop transactions can complete with or without a Data response, as determined by the snooped RN:
• SnpShared.
• SnpClean.
• SnpOnce.
• SnpUnique.
• SnpCleanShared.
• SnpCleanInvalid.

For details on the different Snoop transactions, and if data is returned, see Snoop requests on page 4-100.

Note
Figures relating to Snoop transactions show the snooped Request Node (RN) on the right, and the interconnect
(ICN) on the left. This is consistent with the ordering of the Request/Snoop process.

Snoop without data return

The progress of a Snoop transaction without data is as follows:

1. The interconnect provides a snoop request on the SNP channel that can be any Snoop transaction supported
by the RN.

2. The RN returns the SnpResp snoop response on the SRSP channel.

Figure 2-11 shows the transaction structure.

ICN RN-F

Snoop
SNP
Transaction

SRSP SnpResp

Figure 2-11 Snoop transaction structure without data

The snoop without data rules are:

• SnpResp must only be sent by the RN after the associated snoop request is received.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-47
ID061214 Confidential
2 Transactions
2.3 Transaction structure

Snoop with data return

The progress of a Snoop transaction with data is as follows:

1. The interconnect provides a snoop request on the SNP channel. This can be one of the following Snoop
transactions:
• SnpShared.
• SnpClean.
• SnpOnce.
• SnpUnique.
• SnpCleanShared.
• SnpCleanInvalid.

2. The RN returns the data and associated response using the SnpRespData or SnpRespDataPtl opcode on the
DAT channel.

Figure 2-12 shows the transaction structure.

ICN RN-F

Snoop
SNP
transaction

SDATA SnpRespData

Figure 2-12 Snoop transaction structure with data

The snoop with data rules are:

• SnpRespData or SnpRespDataPtl, as required, must only be sent by the RN-F after the associated snoop
request is received.

Snoop DVMOp
The progress of a SnpDVMOp transaction is as follows:
1. The interconnect provides two snoop requests with the SnpDVMOp opcode on the SNP channel.
2. The RN returns a single SnpResp snoop response on the SRSP channel.

Figure 2-13 shows the transaction structure.

ICN RN

SNP SnpDVMOp
RN-F or RN-D

SRSP SnpResp

Figure 2-13 SnoopDVMOp transaction structure

The SnpDVMOp rules are:

• The SnpResp response must only be sent by the RN after both snoop requests are received.

2-48 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.4 Introduction to identifier fields

2.4 Introduction to identifier fields

Each transaction consists of a number of different packets that are transferred across the interconnect. A set of
identifier fields, within a packet, are used to provide additional information about a packet. The different identifier
fields are:

Target Identifier (TgtID), Source Identifier (SrcID)

These identifiers route packets across the interconnect. See Transaction identifier fields on
page 2-50 and Chapter 3 Network Layer.

Transaction Identifier (TxnID), Data Buffer Identifier (DBID)

These fields relate all the packets associated with a single transaction. See Transaction identifier
fields on page 2-50.

Data Identifier (DataID), Critical Chunk Identifier (CCID)

These fields identify the individual data packets within a transaction. See Data packetization on
page 2-71.

Logical Processor Identifier (LPID)

This field identifies individual processing agents within a single Requester. See Logical Processor
Identifier on page 2-61.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-49
ID061214 Confidential
2 Transactions
2.5 Transaction identifier fields

2.5 Transaction identifier fields

A transaction request includes a TgtID that identifies the target node, and a SrcID that identifies the source node.
These IDs are used to route packets across the interconnect.

A transaction request includes a TxnID that is used to identify the transaction from a given Requester. It is required
that the TxnID must be unique for a given Requester. The Requester is identified by the SrcID. This ensures that
any returning read data or response information can be associated with the correct transaction.

An 8-bit field is defined for the TxnID to accommodate up to 256 outstanding transactions. A Requester is permitted
to reuse a TxnID value after it has received all responses associated with a previous transaction that has used the
same value. Transaction identifier field flows on page 2-52 gives more detailed rules for the different transaction
types.

A transaction that is retried is not required to use the same TxnID. See Request Retry on page 2-78.

This specification includes the concept of a Data Buffer Identifier (DBID). The DBID field is primarily used by
Write transactions and also by transactions that include a CompAck packet. The DBID field permits the Completer
of a transaction to provide its own identifier for a transaction. The Completer sends a response that includes a DBID
value and this value is then used for the TxnID field of the write data or CompAck packet.

The DBID value used by a Completer in responses of a given transaction must be unique for a given Requester in
the following cases:
• Comp or DBIDResp or CompDBIDResp for Write transactions.
• DBIDResp for DVMOp transactions.
• CompData for Read transactions that include CompAck.
• Comp for Dataless transactions that include CompAck.

A Completer is not required to utilize the DBID field for the following:
• Read transactions without CompAck.
• Dataless transactions without CompAck.

A Comp response message sent separate from a DBIDResp message for a Write transaction must include the same
DBID field value in the Comp and DBIDResp message.

A Completer is permitted, but not required, to use the same DBID value for two transactions with different
Requesters. A Completer is permitted to reuse a DBID value after it has received all packets associated with a
previous transaction that has used the same value. Transaction identifier field flows on page 2-52 gives more
detailed rules for the different transaction types.

A typical flow for a Write transaction is as follows:

1. Requester sends Request packet with TxnID field.

2. Completer sends a response to indicate it can accept the data. This Response packet contains the TxnID so
that the Requester can link it to a request. It also has a DBID field, which is the identifier that is used by the
Completer.

3. The Requester sends WriteData, using the supplied DBID in the TxnID field of the write data packets.

4. When the Completer receives the write data packets the TxnID contains the identifier that the Completer sent
in the DBID field enabling it to quickly identify which request the data is associated with.

2-50 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.5 Transaction identifier fields

The advantage of this flow is that the Completer can send the DBID value that it has assigned, for each request that
it receives. Therefore the Completer does not need to perform a lookup using TxnID and SrcID to determine which
transaction write data or completion acknowledge is associated with which request.

Note
If a Completer is using the same DBID value for different Requesters, which it must do if its operation requires more
than 256 DBID responses to be active at the same time, then it must use SrcID in combination with DBID to
determine which request should be associated with a write data or response message.

The DBID response is also used to provide certain ordering guarantees relating to the transaction. See Transaction
ordering on page 7-156.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-51
ID061214 Confidential
2 Transactions
2.6 Transaction identifier field flows

2.6 Transaction identifier field flows

This section shows the use of the TxnID and DBID fields for different transaction types.

In the associated figures:

• The fields included in each packet are:

— For a Request packet: TgtID, SrcID, and TxnID.
— For a Response packet: TgtID, SrcID, TxnID, and DBID.
— For a Data packet: TgtID, SrcID, TxnID, and DBID.

• All fields with the same color are the same value.

• The curved loop-back arrows show how the Requester and Completer use fields from earlier packets to
generate fields for subsequent packets.

• A box containing an asterix [*] indicates when a field is first generated, that is, it indicates the agent that
determines the original value of the field.

• A field enclosed in brackets indicates that the value is effectively a fixed value. Typically this is the case for
the SrcID field when a packet is sent, and the TgtID field when a packet arrives at its destination.

• A field that is crossed-out indicates that the field is not valid. Typically a field that is not valid can take any
value, including a reserved or illegal value.

• It is permitted for the TgtID of the original transaction to be re-mapped by the interconnect to a new value.
This is shown by a box containing the letter R. This is explained in more detail in Chapter 3 Network Layer.

Note
An identifier field, in every packet sent, belongs to one of the following categories:
• New value. An asterix indicates that a new value is generated.
• Generated from an earlier packet. A loop back arrow indicates the source.
• Fixed value. The value is enclosed in brackets.
• Not valid. The field is crossed-out.

2.6.1 Read transactions

This section describes the use of the TxnID and DBID fields for Read transactions.

The identifier field flow includes an optional ReadReceipt response from the Completer, and an optional CompAck
response from the Requester.

For read transactions that include a CompAck response the DBID is used by the Completer to associate the
CompAck with the original transaction.

A read transaction that does not include a CompAck response does not require a valid DBID field in the data
response.

Figure 2-14 on page 2-53 shows the transaction identifier field flow.

2-52 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.6 Transaction identifier field flows

Requester Completer

* TgtID R (TgtID)
REQ * (SrcID) SrcID
ReadReq
* TxnID TxnID

Optional

(TgtID) TgtID
SrcID (SrcID)
CRSP ReadReceipt
TxnID TxnID
DBID DBID

(TgtID) TgtID
SrcID (SrcID)
RDAT
TxnID CompData TxnID
DBID DBID *
Optional

TgtID (TgtID)
(SrcID) SrcID
SRSP CompAck
TxnID TxnID
DBID DBID

Figure 2-14 Identifier field flow for a Read request with ReadReceipt and CompAck

The required steps in the flow that Figure 2-14 shows are:

1. The Requester starts the transaction by sending a Request packet. The identifier fields of the request are
generated as follows:
• The TgtID is determined by the destination of the Request.
Note
The TgtID field can be re-mapped to a different value by the interconnect.

• The SrcID is a fixed value for the Requester.

• The Requester generates a TxnID field that is unique for that Requester.

2. If the transaction includes a ReadReceipt, the Completer receives the Request packet and provides the read
receipt. The identifier fields of the ReadReceipt response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The DBID field is not valid.

3. The Completer receives the Request packet and provides the read data. The identifier fields of the read data
response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The Completer generates a unique DBID value if ExpCompAck in the request is asserted.
• The TgtID, SrcID, TxnID, and DBID fields must be the same value for all read data packets.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-53
ID061214 Confidential
2 Transactions
2.6 Transaction identifier field flows

4. The Requester receives the read data response, and if ExpCompAck was asserted in the request, the
Requester sends CompAck. The identifier fields of the CompAck response are generated as follows:
• The TgtID is set to the same value as the SrcID of the read data. This can be different from the original
TgtID of the request if the value was remapped by the interconnect.
• The SrcID is a fixed value for the Requester.
• The TxnID is set to the same value as the DBID value provided in the read data response.
• The DBID field is not used.

After receiving all read data packets, and if the transaction does not include a ReadReceipt, the Requester can reuse
the same TxnID value for another transaction.

If the transaction includes a ReadReceipt, then the Requester must only reuse the same TxnID after it has received
all read data packets and the ReadReceipt response.

After receiving the CompAck response, the Completer can reuse the same DBID value for another transaction.

2.6.2 Dataless transactions

For dataless transactions that include a CompAck response, the DBID value is used by the Completer to associate
the CompAck with the original transaction.

This applies to the following transactions:

• CleanUnique.
• MakeUnique.
• CleanInvalid.
• CleanShared.
• MakeInvalid.

The use of identifier fields is similar to Read transactions on page 2-52. The only difference is that the response
from the Completer to the Requester is sent as a single packet on the CRSP channel instead of multiple packets on
the RDAT channel.

2.6.3 Write transactions

This section describes the use of the TxnID and DBID fields for Write transactions:
• WriteNoSnp transaction with single response and CopyBack transaction.
• WriteNoSnp transaction with multiple responses on page 2-56.
• WriteUnique transaction on page 2-57.

WriteNoSnp transaction with single response and CopyBack transaction

This section describes the use of the identifier fields for a write transaction with a single combined CompDBIDResp
response. Further details on the meaning of the response fields, and when a combined response is used, can be found
in Response types on page 4-103.

Figure 2-15 on page 2-55 shows the transaction identifier field flow.

2-54 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.6 Transaction identifier field flows

Requester Completer

* TgtID R (TgtID)
REQ * (SrcID) CopyBack or SrcID
* TxnID WriteNoSnp TxnID

(TgtID) TgtID
SrcID (SrcID)
CRSP CompDBIDResp
TxnID TxnID
DBID DBID *

TgtID (TgtID)
(SrcID) SrcID
WDAT
TxnID WriteData TxnID
DBID DBID

Figure 2-15 Identifier flow for a WriteNoSnp with single response and CopyBack

The required steps in the flow that Figure 2-15 shows are:

1. The Requester starts the transaction by sending a Request packet. The identifier fields of the request are
generated as follows:
• The TgtID is determined by the destination of the Request.
Note
The TgtID field can be remapped to a different value by the interconnect.

• The SrcID is a fixed value for the Requester.

• The Requester generates a unique TxnID field.

2. The Completer receives the request packet and generates a CompDBIDResp response. The identifier fields
of the response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The Completer generates a unique DBID value.

3. The Requester receives the CompDBIDResp response and sends the write data. The identifier fields of the
write data are generated as follows:
• The TgtID is set to the same value as the SrcID of the CompDBIDResp response. This can be different
from the original TgtID of the request if the value was remapped by the interconnect.
• The SrcID is a fixed value for the Requester.
• The TxnID is set to the same value as the DBID value provided in the CompDBIDResp response.
• The DBID field in the write data is not used.
• The TgtID, SrcID, and TxnID fields must be the same for all write data packets.
After receiving the CompDBIDResp response, the Requester can reuse the same TxnID value used in the
request packet for another transaction.

4. The Completer receives the write data and uses the TxnID field, which now contains the DBID value that the
Completer generated, to determine which transaction the write data is associated with.
After receiving all write data packets, the Completer can reuse the same DBID value for another transaction.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-55
ID061214 Confidential
2 Transactions
2.6 Transaction identifier field flows

WriteNoSnp transaction with multiple responses

This section describes the use of the identifier fields for a WriteNoSnp transaction with multiple responses.

Figure 2-16 shows the transaction identifier field flow.

Requester Completer

* TgtID R (TgtID)
REQ * (SrcID) SrcID
WriteNoSnp
* TxnID TxnID

(TgtID) TgtID
SrcID (SrcID)
CRSP DBIDResp
TxnID TxnID
DBID DBID *

TgtID (TgtID)
(SrcID) SrcID
WDAT
TxnID WriteData TxnID
DBID DBID

(TgtID) TgtID
SrcID (SrcID)
CRSP Comp
TxnID TxnID
DBID DBID

Figure 2-16 Identifier field flow for a WriteNoSnp with multiple responses

The use of the identifier fields are the same as for a transaction with a combined response with the additional
requirements that:

• The identifier fields used for the separate DBIDResp and Comp responses must be identical.

• The TxnID value must only be reused by a Requester when both the DBIDResp and Comp responses have
been received.

The required steps in the flow that Figure 2-16 shows are:

1. The Requester starts the transaction by sending a Request packet. The identifier fields of the request are
generated as follows:
• The TgtID is determined by the destination of the Request.
Note
The TgtID field can be remapped to a different value by the interconnect.

• The SrcID is a fixed value for the Requester.

• The Requester generates a unique TxnID field.

2. The Completer receives the Request packet and generates a DBIDResp response. The identifier fields of the
response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The Completer generates a unique DBID value.

2-56 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.6 Transaction identifier field flows

3. The Requester receives the DBIDResp response and sends the write data. The identifier fields of the write
data are generated as follows:
• The TgtID is set to the same value as the SrcID of the DBIDResp response. This can be different from
the original TgtID of the request if the value was remapped by the interconnect.
• The SrcID is a fixed value for the Requester.
• The TxnID is set to the same value as the DBID value provided in the DBIDResp response.
• The DBID field in the write data is not used.
• The TgtID, SrcID, and TxnID fields must be the same for all write data packets.

4. The Completer receives the write data and uses the TxnID field, which now contains the DBID value that the
Completer generated, to determine which transaction the write data is associated with.

5. The Completer generates a Comp response when it has completed the transaction. The Comp response is sent
independent of the DBIDResp response and might be sent before or after the write data is received.
The identifier fields of the Comp response must be the same as the DBIDResp response and are generated as
follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The Completer uses the same DBID value as is used in the DBIDResp response.

After receiving both the Comp and DBIDResp response, the Requester can reuse the same TxnID value for another
transaction.

After receiving all write data packets, the Completer can reuse the same DBID value for another transaction.

Note
There is no ordering requirement between the separate DBIDResp and Comp responses. The specification
requirement is that the values used are identical.

WriteUnique transaction
This section describes the use of the identifier fields for a WriteUnique transaction. A WriteUnique transaction can,
under certain circumstances, additionally include a CompAck response from the Requester to the Completer. In this
case, the additional rules for the use of the identifier fields are:

• The TgtID, SrcID, and, TxnID identifier fields of the CompAck response from the Requester to the
Completer must be the same as the fields used for the write data, that is:
— The TgtID is set to the same value as the SrcID of the CompDBIDResp response. If separate Comp
and DBIDResp responses are given, the TgtID is set to the same value as the SrcID of either the Comp
or DBIDResp response because the SrcID value in both must be identical. However, this can be
different from the original TgtID of the request if the value has been remapped by the interconnect.
— The SrcID is a fixed value for the Requester.
— The TxnID is set to the same value as the DBID value provided in the CompDBIDResp response. If
separate Comp and DBIDResp responses are given, the TxnID is set to the same value as the DBID of
either the Comp or DBIDResp response because the DBID value in both must be identical.
— The DBID field in the WriteData and in the CompAck is not used.

• The Completer must receive all items of write data and the CompAck response before reusing the same DBID
value for another transaction.

Figure 2-17 on page 2-58 shows the transaction identifier field flow with a combined CompDBIDResp response.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-57
ID061214 Confidential
2 Transactions
2.6 Transaction identifier field flows

Requester Completer

* TgtID R (TgtID)
REQ * (SrcID) SrcID
WriteUnique
* TxnId TxnID

(TgtID) TgtID
SrcID (SrcID)
CRSP CompDBIDResp
TxnID TxnID
DBID DBID *

TgtID (TgtID)
(SrcID) SrcID
WDAT
TxnID WriteData TxnID
DBID DBID

TgtID (TgtID)
(SrcID) SrcID
SRSP CompAck
TxnID TxnID
DBID DBID

Figure 2-17 Identifier field flow for a WriteUnique

2-58 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.6 Transaction identifier field flows

2.6.4 DVMOp transactions

The use of the TgtID, SrcID, TxnID and DBID identifier fields for a DVMOp transaction is identical to that for the
WriteNoSnp transaction with multiple responses on page 2-56.

2.6.5 Transaction requests with Retry

For transactions that receive a RetryAck response, there are specific rules on how the identifier fields are used. See
Request Retry on page 2-78, for more details on the Retry mechanism, and Protocol Credit Return transactions on
page 2-60, for rules about the return of unused credits.

Figure 2-18 shows the transaction identifier field flow for a transaction request with retry.

Requester Completer

* TgtID R (TgtID)
REQ * (SrcID) SrcID
Request
* TxnID TxnID

(TgtID) TgtID
SrcID (SrcID)
RetryAck
CRSP TxnID TxnID
DBID DBID
PCrdType PCrdType *

(TgtID) TgtID
SrcID (SrcID)
PCrdGrant
CRSP TxnId TxnId
DBID DBID
PCrdType PCrdType

TgtID R (TgtID)
(SrcID) Request SrcID
REQ
* TxnID with Credit TxnID
PCrdType PCrdType

Figure 2-18 Identifier field flow for a transaction request with retry

The required steps in the flow that Figure 2-18 shows are:

1. The Requester starts the transaction by sending a Request packet. The identifier fields of the request are
generated as follows:
• The TgtID is determined by the destination of the Request.
Note
The TgtID field can be remapped to a different value by the interconnect.

• The SrcID is a fixed value for the Requester.

• The Requester generates a unique TxnID field.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-59
ID061214 Confidential
2 Transactions
2.6 Transaction identifier field flows

2. The Completer receives the Request packet and determines that it is going to send a RetryAck response. The
identifier fields of the RetryAck response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.
• The DBID field is not valid.
• The Completer uses a PCrdType value that indicates the type of credit required to retry the transaction.

3. When the Completer is able to accept the retried transaction of a given PCrdType it sends a credit to the
Requester, using the PCrdGrant response. The identifier fields of the PCrdGrant response are generated as
follows:
• The TgtID is set to the same value as the SrcID of the request.
• The SrcID is a fixed value for the Completer. This also matches the TgtID of the request.
• The TxnID field is not used and must be set to zero.
• The DBID field is not used and must be set to zero.
• The PCrdType value is set to the type required to issue the original transaction again.

4. The Requester receives the credit grant and reissues the original transaction by sending a Request packet. The
identifier fields of the request are generated as follows:
• The TgtID is set to either the same value as the SrcID of the RetryAck response, which is also the same
as the SrcID of the PCrdGrant response, or the value used in the original request.
• The SrcID is a fixed value for the Requester.
• The Requester generates a unique TxnID field. This is permitted to be different from the original
request that received a RetryAck response.
• The PCrdType value is set to the PCrdType value in the RetryAck response to the original request,
which is also the same as the PCrdType of the PCrdGrant response.

2.6.6 Protocol Credit Return transactions

A P-Credit Return transaction uses the PCrdReturn Request to return a granted, but no longer required, credit. The
TgtID, SrcID, and TxnID requirements are:

• The Requester sends the Protocol Credit Return transaction by sending a PCrdReturn Request packet. The
identifier fields of the request are generated as follows:
— The TgtID must match the SrcID of the credit that was obtained.
— The SrcID is a fixed value for the Requester.
— The TxnID field is not used and must be set to zero.

The PCrdType must match the value of the PCrdType in the original PCrdGrant that was required to issue the
original transaction again.

There is no response or use made of the DBID field associated with Protocol Credit Return transactions.

2.6.7 Barrier transactions

A Barrier transaction does not make use of the Data Buffer identifier.

The response to a Barrier transaction does not use the DBID field.

The TxnID of a Barrier transaction must only be reused after a completion response has been received.

For more details on Barrier transactions, see Barriers on page 7-161.

2-60 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.7 Logical Processor Identifier

2.7 Logical Processor Identifier

The specification defines a Logical Processor Identifier (LPID) field within a transaction request. This field is used
when a single Requester contains more than one logically separate processing agent.

The LPID must be set to the correct value for the following transactions:

• For any Non-snoopable Non-cacheable or Device access:

— ReadNoSnp.
— WriteNoSnp.

• For exclusive accesses, that can be one of the following transaction types:
— ReadClean.
— ReadShared.
— CleanUnique.
— ReadNoSnp.
— WriteNoSnp.
See Chapter 6 Exclusive Accesses for further details.

Note
For other transactions, the LPID value can be used to indicate the original logical processor that caused a transaction
to be issued. However, this information is not required in CHI and is optional.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-61
ID061214 Confidential
2 Transactions
2.8 Address, Control, and Data

2.8 Address, Control, and Data

A transaction includes attributes defining the manner in which the transaction is handled by the interconnect. These
include the address, memory attributes, snoop attributes, and data formatting. Each attribute is defined in this
section.

2.8.1 Address
The REQ and SNP channel messages include an address field. In the REQ channel it is a 44-bit field labeled
Addr[43:0] and in the SNP channel it is a 41-bit field labeled Addr[43:3]. This field is used by the different message
types as follows:

• For Read, Dataless, and Write transactions the Addr field includes the address of the memory location being
accessed.

• For a snoop request, except SnpDVMOp, the field includes the address of the location being snooped:
— Addr[43:6] is the cache line address and is sufficient to uniquely identify the cache line to be accessed
by the snoop.
— Addr[5:4] identifies the critical chunk being accessed by the transaction. See Critical Chunk Identifier
on page 2-72. The snooped cache must return the data in wrap order with the critical chunk returned
first.
Note
Addr[3] is supplied, but is not used.

• For a DVMOp and SnpDVMOp request the Addr field is used to carry information related to a DVM
operation. See Chapter 8 DVM Operations.

• For ECBarrier, EOBarrier, and PCrdReturn transactions the Addr field value is not used and must be set to
zero.

2.8.2 Non-secure bit

Secure and Non-secure transactions are defined to support Secure and Non-secure operating states.

This bit is defined so that when it is asserted the transaction is identified as a Non-secure transaction.

For Snoopable transactions this field can be considered as an additional address bit that defines two address spaces,
a Secure address space, and a Non-secure address space. Any aliasing between the Secure and Non-secure address
spaces must be handled correctly.

Note
Hardware coherency does not manage coherency between Non-Secure and Secure address spaces.

2.8.3 Memory Attributes

The Memory Attributes (MemAttr) consist of Early Write Acknowledgement (EWA), Device, Cacheable, and
Allocate.

EWA
EWA indicates whether the write completion response for a transaction:
• Is permitted to come from an intermediate point in the interconnect, such as a Home Node.
• Must come from the final endpoint that a transaction is destined for.

If EWA is asserted, the write completion response for the transaction can come from an intermediate point or from
the endpoint. A completion that comes from an intermediate point must provide the same guarantees required by a
Comp as described in Completion Response and Ordering on page 7-153.

2-62 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.8 Address, Control, and Data

If EWA is deasserted, the write completion response for the transaction must come from the endpoint.

Note
It is permitted for an implementation not to use the EWA attribute, in this case completion must be given from the
endpoint.

The EWA assertion requirements are:

• Can take any value in a ReadNoSnp transaction.
• Can take any value in a WriteNoSnp transaction.
• Must be asserted in any Read or Dataless transaction that is not a ReadNoSnp transaction.
• Must be asserted in any Write transaction that is not a WriteNoSnp transaction.
• Is inapplicable in the DVMOp, ECBarrier, EOBarrier or PCrdReturn transaction and must be set to zero.

Device
Device attribute indicates if the memory type is either Device or Normal.

Device memory type

Device memory type must be used for locations that exhibit side-effects. Use of Device memory type for locations
that do not exhibit side-effects is permitted but not recommended in this specification.

The requirements for a transaction to a Device type memory location are:

• A Read transaction must not read more data than requested.

• Prefetching from a Device memory location is not permitted.

• A read must get its data from the endpoint. A read must not be forwarded data from a write to the same
address location that completed at an intermediate point.

• Combining requests to different locations into one request, or combining different requests to the same
location into one request, is not permitted.

• Writes must not be merged.

• Writes to Device memory that obtain completion from an intermediate point must make the write data visible
to the endpoint in a timely manner.

Accesses to Device memory must use the following types, exclusive variants are permitted:
• Read accesses to a Device memory location must use ReadNoSnp.
• Write accesses to a Device memory location must use either WriteNoSnpFull or WriteNoSnpPtl.

Normal memory type

Normal memory type is appropriate for memory locations that do not exhibit side-effects.

Accesses to Normal memory do not have the same restrictions regarding prefetching or forwarding as Device type
memory:
• A Read transaction that has EWA asserted can obtain read data from a Write transaction that has sent its
completion from an intermediate point and is to the same address location.
• Writes can be merged.

Any Read, Dataless, or Write transaction type can be used to access a Normal memory location. The transaction
type used is determined by the memory operation to be accomplished, and the Snoopable attributes.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-63
ID061214 Confidential
2 Transactions
2.8 Address, Control, and Data

Cacheable

The Cacheable attribute indicates if a transaction must perform a cache lookup:

• When Cacheable is asserted the transaction must perform a cache lookup.
• When Cacheable is deasserted the transaction must access the final destination.

The Cacheable attribute value requirements are:

• Must not be asserted for any Device memory transaction.
• Must be asserted for any Read transaction except for ReadNoSnp.
• Must be asserted for any Dataless transaction except for CleanShared, CleanInvalid and MakeInvalid.
• Must be asserted for any Write transaction except WriteNoSnpFull and WriteNoSnpPtl.
• Can take any value for ReadNoSnp, WriteNoSnpFull, and WriteNoSnpPtl to a Normal memory location.
• Can take any value for CleanShared, CleanInvalid and MakeInvalid.
• Is inapplicable in ECBarrier, EOBarrier, DVMOp, and PCrdReturn transactions and must be set to zero.

Note
In a transaction that can take any Cacheable value, the value is typically determined from the page table attributes.

Allocate

The Allocate attribute is a an allocation hint. It indicates the recommended allocation policy for a transaction:

• If Allocate is asserted, it is recommended that the transaction is allocated into the cache for performance
reasons. However, it is permitted to not allocate the transaction.

• If Allocate is deasserted, it is recommended that the transaction is not allocated into the cache for
performance reasons. However, it is permitted to allocate the transaction.

The Allocate attribute value requirements are:

• Can be asserted for transactions that have the Cacheable attribute asserted.

• Must not be asserted for Device memory transactions.

• Must not be asserted for Normal Non-cacheable memory transactions.

• Is inapplicable in DVMOp, ECBarrier, EOBarrier, PCrdReturn and Evict transactions and must be set to zero.

2.8.4 Likely Shared

The LikelyShared attribute is a cache allocation hint. When asserted this attribute indicates that the requested data
is likely to be shared by other Request Nodes within the system. This acts as a hint to shared system level caches
that the allocation of the cache line is recommended for performance reasons.

There is no required behavior associated with this transaction attribute.

2-64 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.8 Address, Control, and Data

2.8.5 Snoop Attribute

An access to a Snoopable memory region can result in the interconnect generating a snoop to the Request Node in
the transaction specified snoop domain.

The snoop domain identifies a set of Request Nodes that for a particular set of address regions:
• Are hardware coherent.
• Generate Snoopable transactions.
• Receive snoops for Snoopable transactions.

The snoop domain can either be Inner or Outer. The characteristics and requirements of a snoop domain are:

• A system can be partitioned into multiple Inner and Outer snoop domains.

• Inner snoop domains must be non-overlapping.

• Outer snoop domains must be non-overlapping.

• An Outer snoop domain can include one or more Inner snoop domains.

• All components in an Inner snoop domain must be in the same Outer snoop domain.

• A Request Node can only belong to one Inner snoop domain.

• A Request Node can only belong to one Outer snoop domain.

• A Request Node does not need to be part of any snoop domain. Such a Request Node does not generate
Snoopable transactions.

For information on the concept of Inner and Outer domains see the AMBA AXI and ACE Protocol Specification
(ARM IHI 0022).

The Snoop Attribute (SnpAttr) indicates if a transaction requires snooping and, if so, the snoop domain for the
transaction.

Table 2-6 shows the SnpAttr field encodings.

Table 2-6 SnpAttr field encodings

SnpAttr[1:0] Snoop attribute

0b00 Non-snoopable

0b01 Inner Snoopable

0b10 Reserved

0b11 Outer Snoopable

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-65
ID061214 Confidential
2 Transactions
2.8 Address, Control, and Data

Table 2-7 shows the snoop attributes for the different transaction types.

Table 2-7 Snoop attributes for the different transaction types

Transaction Non-snoopable Inner or Outer Snoopable

ReadNoSnp Y -

ReadOnce, ReadClean, ReadShared, ReadUnique - Y

CleanUnique, MakeUnique - Y

CleanShared, CleanInvalid, MakeInvalid Y Y

Evict - Y

WriteNoSnp Y -

WriteBack, WriteClean, WriteEvict - Y

WriteUnique - Y

DVMOp, EOBarrier, ECBarrier Y -

Note
For transactions that can take more than one value of SnpAttr, the value is typically determined from page table
attributes.

2-66 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.8 Address, Control, and Data

2.8.6 Transaction attribute combinations

Table 2-8 lists the legal combinations of MemAttr, SnpAttr, and Order field values and the equivalent ARM memory
type. The Order field is described in Chapter 7 Ordering.

Table 2-8 Legal combinations of MemAttr, SnpAttr, and Order field values

MemAttr[3:0] SnpAttr[1:0] Order[1:0] ARM Memory Type

[1] [3] [2] [0] [1] [0] [1] [0]

LikelyShared
Cacheable
Allocate
Device

EWA

1 0 0 0 0 0 0 1 1 Device nRnE

0 0 1 0 0 0 1 1 Device nRE

0 0 1 0 0 0 0/1a 0 Device RE

All other values Not valid

0 0 0 0 0 0 0 0/1a 0 Non-cacheable Non-bufferableb

0 0 1 0 0 0 0/1a 0 Non-cacheable Bufferable

0 1 1 0 0 0 0/1a 0 Non-snoopable WriteBack No-allocate

1 1 1 0 0 0 0/1a 0 Non-snoopable WriteBack Allocate

0 1 1 0 1 0/1c 0/1a 0 Inner Snoopable WriteBack No-allocate

1 1 1 0 1 0/1c 0/1a 0 Inner Snoopable WriteBack Allocate

0 1 1 1 1 0/1c 0/1a 0 Outer Snoopable WriteBack No-allocate

1 1 1 1 1 0/1c 0/1a 0 Outer Snoopable WriteBack Allocate

All other values Not valid

a. Order = 0b10 is permitted in ReadOnce, WriteUnique, ReadNoSnp and WriteNoSnp transactions only.
b. Non-cacheable Non-bufferable is an AXI memory type, not an ARM memory type.
c. LikelyShared = 1 is only permitted for ReadShared, ReadClean, WriteBackFull, WriteCleanFull, WriteEvictFull,
WriteUniqueFull and WriteUniquePtl transactions.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-67
ID061214 Confidential
2 Transactions
2.8 Address, Control, and Data

Memory type
This section specifies the required behavior for each of the memory types that Table 2-8 on page 2-67 shows.

Device nRnE

The required behavior for Device nRnE memory type is:

• The write response must be obtained from the final destination.
• Read data must be obtained from the final destination.
• A read must not fetch more data than is required.
• A read must not be prefetched.
• Writes must not be merged.
• A write must not write to a larger address range than the original transaction.
• All Read and Write transactions from the same source to the same endpoint must remain ordered.

Device nRE

The required behavior for the Device nRE memory type is the same as for the Device nRnE memory type except
that:
• The write response can be obtained from an intermediate point.

Device RE

The required behavior for the Device RE memory type is same as for the Device nRE memory type except that:
• Read and Write transactions from the same source to the same endpoint need not remain ordered.
• Read and Write transactions from the same source to addresses that overlap must remain ordered.

Normal Non-cacheable Non-bufferable

The required behavior for the Normal Non-cacheable Non-bufferable memory type is:
• The write response must be obtained from the final destination.
• Read data must be obtained from the final destination.
• Writes can be merged.
• Read and Write transactions from the same source to addresses that overlap must remain ordered.

Normal Non-cacheable Bufferable

The required behavior for the Normal Non-cacheable Bufferable memory type is:
• The write response can be obtained from an intermediate point.
• Write transactions must be made visible at the final destination in a timely manner.
Note
There is no mechanism to determine when a Write transaction is visible at its final destination.

• Read data must be obtained either from:

— The final destination.
— A Write transaction that is progressing to its final destination.
If read data is obtained from a Write transaction:
— It must be obtained from the most recent version of the write.
— The data must not be cached to service a later read.
• Writes can be merged.
• Read and Write transactions from the same source to addresses that overlap must remain ordered.

2-68 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.8 Address, Control, and Data

Note
For a Normal Non-cacheable Bufferable read, data can be obtained from a Write transaction that is still progressing
to its final destination. This is indistinguishable from the Read and Write transactions propagating to arrive at the
final destination at the same time. Read data returned in this manner does not indicate that the Write transaction is
visible at the final destination.

Write-back No-allocate

The required behavior for the Write-back No-allocate memory type is:

• The write response can be obtained from an intermediate point.

• Write transactions are not required to be made visible at the final destination.

• Read data can be obtained from an intermediate cached copy.

• Reads can be prefetched.

• Writes can be merged.

• A cache lookup is required for read and write transactions.

• Read and Write transactions from the same source to addresses that overlap must remain ordered.

• The No-allocate attribute is an allocation hint, that is, it is a recommendation to the memory system that, for
performance reasons, the transaction is not allocated. However, the allocation of the transaction is not
prohibited.

Write-back Allocate

The required behavior for the WriteBack Allocate memory type is the same as for WriteBack No-allocate memory.
However, in this case, the allocation hint is a recommendation to the memory system that, for performance reasons,
the transaction is allocated.

2.8.7 Mismatched Memory attributes

It is permitted for two different agents to access the same location using mismatched MemAttr or SnpAttr memory
attributes, at the same point in time.

If the memory accesses from the different agents are made with mismatched snoopability or cacheability attributes
it is defined as a software protocol error. A software protocol error can cause a loss of coherency and result in the
corruption of data values. It is required that the system does not deadlock for a software protocol error, and that
transactions always make forward progress.

A software protocol error for an access in one 4KB memory region must not cause data corruption in a different
4KB memory region.

For locations held in Normal memory, the use of appropriate barriers and software cache maintenance can be used
to return memory locations to a defined state.

The use of mismatched memory attributes can result in an RN-F observing a Snoop transaction to the same address
that it is performing a ReadNoSnp or WriteNoSnp transaction to. In this situation there is no defined relationship
between the Snoop transaction and the transaction that the RN-F has issued.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-69
ID061214 Confidential
2 Transactions
2.9 Data transfer

2.9 Data transfer

Read transactions, write transactions, and snoop responses with data, include a data payload. This section defines
the data alignment rules, and the data bytes that are accessed for different combinations of address, transaction size,
and memory type.

2.9.1 Data size

The Size field in a packet is used, in combination with other fields, to determine the number of bytes transferred.
Table 2-9 shows the Size field value encodings. Snoop transactions do not include a Size field. All snoop data
transfers are 64-byte.

Table 2-9 Size field value encodings

Size[2:0] Bytes

0b000 1

0b001 2

0b010 4

0b011 8

0b100 16

0b101 32

0b110 64

0b111 Reserved

2.9.2 Bytes access in memory

The MemAttr[1] bit field determines if the memory type is Device or Normal. See Memory Attributes on page 2-62.
The bytes that are accessed are determined by the memory type as follows:

Normal memory
Transactions with a Normal memory type access the number of bytes defined by the Size field. Data
access is from the Aligned_Address, that is, the transaction address rounded down to the nearest Size
boundary, and ends at the byte before the next Size boundary.
This is calculated as:
Start_Address = Addr field value.
Number_Bytes = 2^Size field value.
INT(x) = Rounded down integer value of x.
Aligned_Address = (INT(Start_Address / Number_Bytes)) x Number_Bytes.
The bytes accessed are from (Aligned_Address) to (Aligned_Address + Number_Bytes) - 1.

Device Transactions with a Device memory type access the number of bytes from the transaction address
up to the byte before the next Size boundary.
The bytes accessed are from (Start_Address) to (Aligned_Address + Number_Bytes) - 1.
For write transactions to Device locations, byte enables must only be asserted for the bytes that are
accessed. See Byte Enables on page 2-71.

2-70 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.9 Data transfer

2.9.3 Byte Enables

Byte Enables, also referred to as BE, are used alongside Write transactions, and snoop responses with data.

For Write transactions, an asserted byte enable indicates that the associated data byte is valid and must be updated
in memory or cache. A deasserted byte enable indicates that the associated data byte is not valid and must not be
updated in memory or cache.

The following Write transactions must have all byte enables asserted during the data transfers:
• WriteNoSnpFull.
• WriteBackFull.
• WriteCleanFull.
• WriteEvictFull.
• WriteUniqueFull.

The following Write transactions are permitted to have any combination of byte enables asserted during the data
transfers. This includes asserting all and asserting none:
• WriteBackPtl.
• WriteCleanPtl.
• WriteUniquePtl.

For the WriteNoSnpPtl transaction the following rules apply:

• For a transaction to Normal memory, any combination of byte enables can be asserted during the data
transfers. This includes asserting all and asserting none.

• For a transaction to Device memory, byte enables must only be asserted for bytes at or above the address
specified in the transaction. Any combination of byte enables can be asserted that meets this requirement.
This includes asserting all and asserting none.

For all Write transactions, byte enables that are not within the data window, specified by Addr and Size, must be
deasserted.

For snoop responses with data that use the SnpRespData opcode, all byte enables must be asserted.

For snoop responses with data that use the SnpRespDataPtl opcode, any combination of byte enables can be asserted
alongside the data transfers. This includes asserting all and asserting none.

2.9.4 Data packetization

For each transaction that involves data, the data bytes can be transferred in multiple packets.

The number of packets required is determined by:

• Number of bytes.
• Data bus width.

The number of bytes transferred in each packet is determined by:

• Data bus width.

This specification supports the following data bus widths:

• 128-bit.
• 256-bit.
• 512-bit.

The Data Identifier and Critical Chunk Identifier fields are used to identify data packets within a transaction.

A transaction size of up to 16-byte is always contained in a single packet. The DataID field value must be set to
Addr[5:4] because the DataID field represents Addr[5:4] of the lowest addressed byte within the packet.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-71
ID061214 Confidential
2 Transactions
2.9 Data transfer

For 32-byte and 64-byte transactions, Table 2-10 shows the relationship between the DataID field and the bytes that
are contained within the packet, for different transaction sizes, and data bus widths. See Size on page 11-219 and
DataID on page 11-225 for the field encodings.

Table 2-10 Bytes contained within a packet for different DataID values and transaction sizes

Number of bytes
Identifier fields Data bus width
within a transaction

Size[2:0] DataID[1:0] 128-bit 256-bit 512-bit

32 101 00 0x00 - 0x0F 0x00 - 0x1F 0x00 - 0x1F

(Addr[5] = 0)
01 0x10 - 0x1F Reserved Reserved

32 101 10 0x20 - 0x2F 0x20 - 0x3F 0x20 - 0x3F

(Addr[5] = 1)
11 0x30 - 0x3F Reserved Reserved

64 110 00 0x00 - 0x0F 0x00 - 0x1F 0x00 - 0x3F

01 0x10 - 0x1F Reserved Reserved

10 0x20 - 0x2F 0x20 - 0x3F Reserved

11 0x30 - 0x3F Reserved Reserved

In Table 2-10, the entries in the data bus width columns represent the byte offset of the data bytes within a 64 byte
cache line.

Within a data packet, all bytes are located at their natural byte positions. This is true even if fewer data bytes are
transferred than the width of the data bus.

The number of data packets used for transactions to Device memory is independent of the address of the transaction.
The number of data packets required is determined only by the Size field and the data bus width.

Note
For some transactions to Device memory, it can be determined from the address at the start of the transaction that
some data packets will not contain valid data and are redundant. However, this specification requires that these data
packets are transferred.

2.9.5 Critical Chunk Identifier

The CCID field is used to identify the data bytes that are the most critical in the transaction request.

The CCID field must match the value of Addr[5:4] of the original request. Transactions which contain multiple data
packets must use the same CCID value for all data packets.

When read data or write data is reordered by the interconnect, the CCID field permits quick identification of the
most critical bytes within a transaction by comparing the CCID value with the DataID value. When the two values
match, the data bytes being transferred are the critical bytes.

2-72 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.9 Data transfer

2.9.6 Data Beat ordering

This specification permits reordering of data packets within a transaction when passing across an interconnect.
However, this specification requires that the original source of data packets must provide the packets in a critical
chunk first, wrap order.

Note
• This requirement ensures that interfacing to protocols that do not support data reordering, such as AXI, can
be done in the most efficient manner when an ordered interconnect is used.

Wrap order is defined as follows:

Start_Address = Addr

Number_Bytes = 2^Size

INT(x) = Rounded down integer value of x

Aligned_Address = (INT(Start_Address / Number_Bytes)) x Number_Bytes

Lower_Wrap_Boundary = Aligned_Address

Upper_Wrap_Boundary = Aligned_Address + Number_Bytes - 1

To maintain wrap order, the order must be:

1. The first data packet must correspond to the data bytes specified by the Start_Address of the transaction.
2. Subsequent packets must correspond to incrementing byte addresses up to the Upper_Wrap_Boundary.
3. Subsequent packets must correspond to the Lower_Wrap_Boundary.
4. Subsequent packets must correspond to incrementing byte addresses up to the Start_Address.

Note
Some of the steps to maintain wrap order might overlap and not be required if the required bytes are included in a
previous step.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-73
ID061214 Confidential
2 Transactions
2.9 Data transfer

2.9.7 Data transfer examples

This section gives a number of examples of the data transfer requirements defined in this specification.

In most of the examples, the size of the transaction is 64-byte and the data bus width is 128-bit. This requires 4 data
packets for each transaction.

In the following examples, the accompanying text highlights some interesting aspects. It is not intended to describe
all aspects of the example.

Example 2-1 Normal memory 64-byte read transaction from an aligned address

Normal Memory
Read Transaction
Size = 0b110 (64B)

Data Size Data Size

Addr = 0x0040
Boundary Boundary

8F 80 7F 70 6F 60 5F 50 4F 40 3F 30 2F 20

Packet 3 Packet 2 Packet 1 Packet 0

DataID = 0x3 DataID = 0x2 DataID = 0x1 DataID = 0x0

CCID = 0x0 CCID = 0x0 CCID = 0x0 CCID = 0x0

• The order of the data packets, as indicated by Packet 0, Packet 1, Packet 2, and Packet 3, is such that they
follow wrap order.

• The DataID changes for each packet, while the CCID field remains constant.

• The packet containing the data bytes specified by the address of the transaction has the same value for the
CCID and DataID fields.

2-74 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.9 Data transfer

Example 2-2 Normal memory 64-byte read transaction from an unaligned address

Normal Memory
Read Transaction
Size = 0b110 (64B)

Data Size Data Size

Addr = 0x0068
Boundary Boundary

8F 80 7F 70 6F 68 67 60 5F 50 4F 40 3F 30 2F 20

Packet 1 Packet 0 Packet 3 Packet 2

DataID = 0x3 DataID = 0x2 DataID = 0x1 DataID = 0x0

CCID = 0x2 CCID = 0x2 CCID = 0x2 CCID = 0x2

• The order of the data packets, as indicated by Packet 0, Packet 1, Packet 2, and Packet 3, is such that they
follow wrap order.

• The DataID changes for each packet, while the CCID field remains constant.

• The packet containing the data bytes specified by the address of the transaction has the same value for the
CCID and DataID fields.

Example 2-3 Normal memory 32-byte read transaction from an unaligned address

Normal Memory
Read Transaction
Size = 0b101 (32B)

Data Size Data Size

Addr = 0x0078
Boundary Boundary

8F 80 7F 78 77 70 6F 60 5F 50 4F 40 3F 30 2F 20

Packet 0 Packet 1

DataID = 0x3 DataID = 0x2

CCID = 0x3 CCID = 0x3

• The size of the transaction is 32-byte and the data bus width is 128-bit, resulting in 2 data packets.
• The order of the data packets, as indicated by Packet 0 and Packet 1, is such that they follow wrap order.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-75
ID061214 Confidential
2 Transactions
2.9 Data transfer

Example 2-4 Normal memory 14-byte consecutive write transaction from an unaligned address

Normal Memory
Write Transaction
Size = 0b110 (64B)

Data Size Addr = 0x0058 Data Size

Boundary 14-bytes written Boundary

8F 80 7F 70 6F 60 5F 58 57 50 4F 40 3F 30 2F 20

Packet 2 Packet 1 Packet 0 Packet 3

DataID = 0x3 DataID = 0x2 DataID = 0x1 DataID = 0x0

CCID = 0x1 CCID = 0x1 CCID = 0x1 CCID = 0x1
BE = 0x0000 BE = 0x003F BE = 0xFF00 BE = 0x0000

• The order of the data packets, as indicated by Packet 0, Packet 1, Packet 2, and Packet 3, is such that they
follow wrap order.

• The DataID changes for each packet, while the CCID field remains constant.

• The packet containing the data bytes specified by the address of the transaction has the same value for the
CCID and DataID fields.

• Fourteen consecutive bytes in memory are written, as indicated by the byte enables. However, other
combinations of byte enables are permitted. See Byte Enables on page 2-71.

2-76 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.9 Data transfer

Example 2-5 Device read transaction from an unaligned address

Device
Read Transaction
Size = 0b110 (64B)

Data Size Data Size

Addr = 0x0058
Boundary Boundary

8F 80 7F 70 6F 60 5F 58 57 50 4F 40 3F 30 2F 20

Packet 2 Packet 1 Packet 0 Packet 3

DataID = 0x3 DataID = 0x2 DataID = 0x1 DataID = 0x0

CCID = 0x1 CCID = 0x1 CCID = 0x1 CCID = 0x1

• The shaded area indicates the valid bytes in the transaction. The valid bytes extend from the transaction
address up to the next Size boundary.

• The transaction includes the transfer of a packet that contains no valid data.

Example 2-6 Device write transaction to an unaligned address

Device
Write Transaction
Size = 0b110 (64B)

Data Size Addr = 0x0068 Data Size

Boundary 24-bytes written Boundary

8F 80 7F 70 6F 68 67 60 5F 50 4F 40 3F 30 2F 20

Packet 1 Packet 0 Packet 3 Packet 2

DataID = 0x3 DataID = 0x3 DataID = 0x3 DataID = 0x3

CCID = 0x2 CCID = 0x2 CCID = 0x2 CCID = 0x2
BE = 0xFFFF BE = 0xFF00 BE = 0x0000 BE = 0x0000

• Byte enables are only permitted to be asserted for the bytes from the transaction address up to the next Size
boundary. It is not required that all byte enables meeting this criteria are asserted.

• Byte enables for bytes below the start address must not be asserted.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-77
ID061214 Confidential
2 Transactions
2.10 Request Retry

2.10 Request Retry

This specification provides a request retry mechanism that ensures when a request reaches a Completer it is either
accepted, or is given a RetryAck response, to prevent blocking of the REQ channel.

A Requester is required to hold all the details of the request until it receives a response indicating that the request
has either been accepted, or must be sent again at a later point in time.

To meet this requirement, the AllowRetry field must be asserted the first time a transaction is sent.

A Completer that is receiving requests is able to give a RetryAck response to a request that it is not able to accept.
Typically, it will not be able to accept a request when it has limited resources and insufficient storage to hold the
current request until some earlier transactions have completed.

When a Completer gives a RetryAck response it is responsible for recording where the request came from, as
determined by the SrcID of the request. The Completer is also responsible for determining and recording the type
of Protocol Credit required to process the request. When required resources become available, at a later point in
time, the Completer must then send a P-Credit back to the Requester, using a PCrdGrant response. The PCrdGrant
response indicates to the Requester that the transaction can be retried.

Note
There is no explicit mechanism to request a credit. A transaction that is given a RetryAck response implicitly
requests a credit.

It is possible that a reordering interconnect can reorder the responses such that the PCrdGrant is received by the
Requester before the RetryAck response for the transaction is received. In this case, the Requester must record the
credit it has received, including the credit type, so that it can assign the credit appropriately when it does receive the
RetryAck response.

Note
It is expected to be rare that a PCrdGrant would be re-ordered with respect to a RetryAck response, as the delay
between a RetryAck and a PCrdGrant response will typically be much longer than any delay caused by interconnect
re-ordering.

When the Requester receives a credit, it can then resend the request with an indication that it has been allocated a
credit. This is done by de-asserting the AllowRetry field. This second attempt to carry out the transaction is
guaranteed to be accepted.

The transaction that is resent must have the same field values as the original request, except for the following:
• TgtID. See Target ID determination for Request messages on page 3-86.
• QoS.
• TxnID.
• AllowRetry, which must be deasserted.
• PCrdType, which must be set to the value in the Retry response for the original transaction.

There is no fixed relationship between credits and particular transactions. If a Requester has received multiple
RetryAck responses for different transactions and it then receives a credit, there is no fixed credit allocation, the
Requester is free to choose the most appropriate.

The retry mechanism supports up to four different credit types. This lets the Completer use different credit types for
different resources. For example, a Completer might use one credit type for the resources associated with Read
transactions, and another credit type for Write transactions. Using different credit types gives the Completer the
ability to efficiently manage its resources by controlling which of the retried requests can be sent again.

The transaction must only be retried by the Requester when a PCrdGrant is received with the correct PCrdType.

Note
If a Completer is only using one credit type, this specification recommends that the PCrdType value of 0b00 is used.
See PCrdType on page 2-80.

2-78 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.10 Request Retry

A Completer that is giving RetryAck responses must be able to record all the RetryAck responses that it has given
to ensure it can correctly distribute credits. If the Completer is using more than one credit type then the RetryAck
responses that have been given for each credit type must be recorded.

A Requester must limit the transactions it issues so that the Completer is never required to track more than 256
transactions that require a PCrdGrant response. This is achieved by limiting the maximum number of outstanding
transactions to 256 for each Requester.

A transaction is outstanding from the cycle that the request is first issued until either:

• The transaction is fully completed, as determined by the return of all the following responses that are
expected for the transaction:
— ReadReceipt, CompData, DBIDResp, Comp and CompDBIDResp.

• It receives RetryAck and PCrdGrant and is either:

— Retried using a credit of the appropriate PCrdType and then is fully completed as determined by the
return of all responses.
— Cancelled and returns the received credit using the PCrdReturn message.

Note
Typically, a Completer would be expected to record up to 256 RetryAck responses for each possible SrcID.

Each transaction request includes a QoS value which can be used by the Completer to influence the allocation of
credits as resources become available. See Chapter 10 Quality of Service for further details.

2.10.1 Credit Return

It is possible for a Requester to be given more credits than it requires.

This specification does not define when this can occur, but two typical scenarios are:

• A transaction is canceled between the first attempt and the point at which it can be resent with P-Credit.

• A transaction is requested multiple times with increasing QoS values. However, only a single completion of
the transaction is required.

Note
If a Requester makes a second request before the first request has been given a RetryAck response then it must be
acceptable for both transactions to occur. However, as an example, this behavior would typically not be acceptable
for accesses to a peripheral device.

A Requester returns a credit by the use of the PCrdReturn transaction. This is effectively a No OPeration (NOP)
transaction that uses the credit that is not required. This transaction is used to inform the Completer that the allocated
resources are no longer required for the given PCrdType.

Any credits that are not required must be returned in a timely manner.

Note
Any unused pre-allocated credit must be returned to avoid components holding on to credits in expectation of using
them later. Such behavior is likely to result in an inefficient use of resources and to make analysis of the system
performance difficult.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-79
ID061214 Confidential
2 Transactions
2.10 Request Retry

2.10.2 Transaction Retry mechanism

The following sections describe the Request transaction fields used by the Retry mechanism.

AllowRetry
The AllowRetry field indicates if the Request transaction can be given a RetryAck response. See Table 11-18 on
page 11-220 for the AllowRetry value encodings. The AllowRetry field must be asserted the first time a transaction
is sent.

The AllowRetry field must be deasserted when the transaction is using a pre-allocated P-Credit.

PCrdType
The PCrdType field indicates the credit type associated with the request and is determined as follows:

• For a Request transaction:

— If the AllowRetry field is asserted, the PCrdType field must be set to 0b00.
— If the AllowRetry field is deasserted, the PCrdType field must be set to the value that was returned in
the RetryAck response from the Completer when the transaction was first attempted.

• A PCrdReturn transaction must have the credit type set to the value of the credit type that is being returned.
See PCrdType on page 11-221 for the PCrdType value encodings.

• Destinations that have a single credit class, or do not implement credit type classification, must set the
PCrdType field to 0b00.

Note
The value a Completer assigns to PCrdType is IMPLEMENTATION DEFINED.

The Completer must implement a starvation prevention mechanism to ensure that all transactions, irrespective of
QoS value or credit type required, will eventually make forward progress, even if over a significantly long time
period. This is done by ensuring that credits are eventually given to every transaction that has received a RetryAck
response. See Chapter 10 Quality of Service for more details on the distribution of credits for the purposes of QoS.

2-80 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 2 Transactions
2.10 Request Retry

2.10.3 Transaction Retry flow

Figure 2-19 shows a typical Transaction Retry flow.

RN-F HN-F

ReadOnce
(AllowRetry = 1) HN-F buffer entry
(PCrdType = 0b00) not gained

(Log credit request)

RetryAck
(PCrdType = n)
PCrdGrant (P-Credit allocated)
(PCrdType = n)
Wait for
P-Credit
ReadOnce
(AllowRetry = 0)
(PCrdType = n)

n = 0b00, 0b01, 0b10 or 0b11

Figure 2-19 Transaction Retry flow

The steps that Figure 2-19 shows are:

1. The Requester sends a ReadOnce request.

• This is done without a credit, so AllowRetry is asserted.

2. The Completer receives the request and sends a RetryAck response because it is not able to process the
transaction at this time.
• The request is logged and a PCrdType is allocated at the Completer.

3. The Completer sends a P-Credit, using the PCrdGrant response, when it has allocated resource for the
transaction.
• The PCrdGrant includes the PCrdType allocated for the original request.

4. The Requester re-sends the transaction with AllowRetry deasserted.

• The request uses the P-Credit and the PCrdType allocated for the original request.

Note
• It is permitted, but not expected, for a Completer to send a PCrdGrant before it has sent the associated
RetryAck response.

• The second attempt at a transaction, must not be sent until both a RetryAck response and an appropriate
P-Credit is received for the transaction.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 2-81
ID061214 Confidential
2 Transactions
2.10 Request Retry

2-82 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 3
Network Layer

This chapter describes the network layer that is responsible for determining the node ID of a destination node. It
contains the following sections:
• System address map on page 3-84.
• Node ID on page 3-85.
• Target ID determination for messages from an RN on page 3-86.
• Network layer flow examples on page 3-88.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 3-83
ID061214 Confidential
3 Network Layer
3.1 System address map

3.1 System address map

Each RN and HN in the system must have a System Address Map (SAM) to determine the target ID of a request.
The scope of the SAM might be as simple as providing a fixed node ID value to all the outgoing requests.

The exact format and structure of the SAM is IMPLEMENTATION DEFINED and is outside the scope of this
specification.

The SAM must provide a complete decode of the entire address space. This specification recommends that any
address that does not correspond to a physical component is sent to an agent that can provide an appropriate error
response.

3-84 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 3 Network Layer
3.2 Node ID

3.2 Node ID
Each Port on the interconnect is assigned a node ID that is used to identify the source and destination of packets
communicated over the interconnect. A Port can be assigned multiple node IDs. A node ID value can be assigned
only to a single Port.

Defining and assigning a node ID for each node in a system is IMPLEMENTATION DEFINED and is outside the scope
of this specification.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 3-85
ID061214 Confidential
3 Network Layer
3.3 Target ID determination for messages from an RN

3.3 Target ID determination for messages from an RN

This section describes how the target ID is determined for the different message types. It contains the following
sections:
• Target ID determination for Request messages.
• Target ID determination for Response messages on page 3-87.
• Target ID determination for Snoop Request messages on page 3-87.

3.3.1 Target ID determination for Request messages

The target ID of a Request message is determined in the following manner using the system address map logic.

Except for PCrdReturn:

• If the request does not use a pre-allocated credit, then the target ID is determined by:
— Opcode for DVMOp, EOBarrier and ECBarrier.
— Address to node ID mapping for all other requests.

• If the request uses pre-allocated credit, the target ID of the request must be obtained from either the source
ID of the RetryAck, provided as a response to the original Request message, or the target ID of the original
request.

For PCrdReturn:

• The target ID provided by the RN must match the source ID included in the prior PCrdGrant which provided
the credit being returned.

For mapping of target ID in requests from the RN, this specification requires the SAM logic to be present in the RN
or in the interconnect. In the case of the interconnect, it might remap the target ID in the Request packet provided
by the RN.

Note
• An RN must expect the interconnect to remap the target ID of a request.

• For transactions from an RN, this specification expects Snoopable transaction to be targeted to HN-F and
Non-snoopable transaction to target HN-I or HN-F. It is legal for a Snoopable transaction to be targeted at an
HN-I. This might occur, for example, due to a software programming error. In this case, the HN-I is required
to respond to the transaction in a protocol compliant manner, but coherency is not guaranteed.

3-86 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 3 Network Layer
3.3 Target ID determination for messages from an RN

3.3.2 Target ID determination for Response messages

Response packets are issued as a result of a received message. The target ID in Response packets must match the
source ID of the received message that resulted in the response being sent. Table 3-1 shows the source of the
Response packet target ID for each Response message type.

Table 3-1 Source of response packet target ID

Response message Target ID obtained from

Comp Request

WriteData DBIDResp or CompDBIDResp

SnpResp Snoop Request

CompAck Comp or CompData

RetryAck Request

PCrdGrant Request

ReadReceipt Request

DBIDResp Request

3.3.3 Target ID determination for Snoop Request messages

A Snoop Request does not include a target ID. The protocol does not include an architectural mechanism to address
and send a Snoop Request to a target. It is expected that this mechanism will be IMPLEMENTATION DEFINED and is
outside the scope of this specification.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 3-87
ID061214 Confidential
3 Network Layer
3.4 Network layer flow examples

3.4 Network layer flow examples

This section shows transaction flows at the network layer. It contains the following sections:
• Simple flow.
• Flow with interconnect based SAM on page 3-89.
• Flow with interconnect based SAM and Retry request on page 3-89.

3.4.1 Simple flow

Figure 3-1 is an example of a simple transaction flow and shows how the TgtID is determined for the requests and
responses:

1. RN0 sends a request with Target ID of HN0 using the SAM internal to RN0.
• The interconnect does not remap the node ID.

2. HN0 looks up an internal SAM to determine the target SN.

3. SN0 receives the request and sends a data response.

• The data response packet has the TgtID derived from the requests SrcID.

4. HN0 receives the data response from SN0.

• HN0 forwards a response to RN0 extracting the TgtID information from the original request.

5. RN0 sends, if required, a CompAck with TgtID of HN0 derived from the SrcID in the Data Response packet
to complete the transaction.

RN0 TgtID=HN0 HN0 TgtID=SN0 SN0

SrcID=RN0 SrcID=HN0
Dec Req Dec Req

Addr

TgtID=RN0 TgtID=HN0
SrcID=HN0 SrcID=SN0
RDATA RDATA

TgtID=HN0
SrcID=RN0
Resp

Figure 3-1 Target ID assignment without remapping

3-88 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 3 Network Layer
3.4 Network layer flow examples

3.4.2 Flow with interconnect based SAM

Figure 3-2 shows a case where remapping of the target ID occurs in the interconnect.

Note
Only the target ID of the request from the RN is remapped. The TgtID in all other packets in the transaction flow is
determined in a similar manner to Simple flow on page 3-88.

Initial target Remapped TgtID

RN0 HN1 SN0

TgtID=HN0 TgtID=HN1 TgtID=SN0
SrcID=RN0 SrcID=RN0 SrcID=HN1
Remap
Dec Req Req Dec Req
Dec
Addr

TgtID=HN1
TgtID=RN0 SrcID=SN0
SrcID=HN1
RDATA
RDATA
TgtID=HN1
SrcID=RN0
Resp

Figure 3-2 Target ID assignment with remapping logic

3.4.3 Flow with interconnect based SAM and Retry request

Figure 3-3 on page 3-90 shows a case of a request getting retried.

1. The interconnect remaps the TgtID provided by RN0 to HN1.

2. The request receives a RetryAck response.

• The RetryAck and PCrdGrant responses get the TgtID information from the SrcID in the received
request.

3. RN0 resends the request once both RetryAck and PCrdGrant responses are received.
• The TgtID in the retried request is the same as the SrcID in the received RetryAck or the TgtID in the
original request. The TgtID must pass through the remapping logic again.

4. The packets in the rest of the transaction flow get the TgtID in a similar manner to Flow with interconnect
based SAM.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 3-89
ID061214 Confidential
3 Network Layer
3.4 Network layer flow examples

Initial target Remapped TgtID

RN0 HN1 SN0

TgtID=HN0 TgtID=HN1
SrcID=RN0 SrcID=RN0
Remap
Dec Req Req Dec
Dec
Addr

TgtID=RN0
SrcID=HN1
Retry
PCrdGrant

TgtID=HN1 TgtID=HN1 TgtID=SN0

SrcID=RN0 SrcID=RN0 SrcID=HN1
Remap
Dec Req Req Dec Req
Dec
Addr

TgtID=RN0 TgtID=HN1
SrcID=HN1 SrcID=SN0
RDATA RDATA
TgtID=HN1
SrcID=RN0
Resp

Figure 3-3 Remapping of TgtID and retried request

3-90 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 4
Coherence Protocol

This chapter describes the coherence protocol and contains the following sections:
• Cache line states on page 4-92
• Request types on page 4-94.
• Snoop requests on page 4-100.
• Request types and corresponding snoop requests on page 4-101.
• Response types on page 4-103.
• Silent cache state transitions on page 4-109.
• Cache state transitions on page 4-110.
• Legal snoop response combinations on page 4-117
• Hazard conditions on page 4-119

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-91
ID061214 Confidential
4 Coherence Protocol
4.1 Cache line states

4.1 Cache line states

The action required when a protocol node accesses a cache line is determined by the cache line state. The protocol
defines the following cache line states:

I Invalid:
• The cache line is not present in the cache.

UC Unique Clean:
• The cache line is present only in this cache.
• The cache line has not been modified with respect to memory.
• The cache line can be modified without notifying other caches.
• The cache line is permitted, but not required, to be forwarded in response to a snoop that
requests data.

UCE Unique Clean Empty:

• The cache line is present only in this cache.
• The cache line is in a unique state but none of the data bytes are valid.
• The cache line can be modified without notifying other caches.
• The cache line must not be forwarded in response to a snoop that requests data.

UD Unique Dirty:
• The cache line is present only in this cache.
• The cache line has been modified with respect to memory.
• The cache line must be written back to next level cache or memory on eviction.
• The cache line can be modified without notifying other caches.
• The cache line must be forwarded in response to a snoop that requests data.

UDP Unique Dirty Partial:

• The cache line is present only in this cache.
• The cache line is unique. Only a part of the cache line is Valid and Dirty.
• The cache line has been modified with respect to memory.
• When the cache line is evicted, it must be merged with data from next level cache or memory
to form the complete Valid cache line.
• The cache line can be modified without notifying other caches.
• The cache line must be forwarded in response to a snoop that requests data.

SC Shared Clean:
• Other caches might have a shared copy of the cache line.
• The cache line might have been modified with respect to memory.
• It is not the responsibility of this cache to write the cache line back to memory on eviction.
• The cache line cannot be modified without invalidating any shared copies and obtaining
unique ownership of the cache line.
• The cache line must not be forwarded in response to a snoop.

4-92 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.1 Cache line states

SD Shared Dirty:
• Other caches might have a shared copy of the cache line.
• The cache line has been modified with respect to memory.
• The cache line must be written back to next level cache or memory on eviction.
• The cache line cannot be modified without invalidating any shared copies and obtaining
unique ownership of the cache line.
• The cache line must be forwarded in response to a snoop that requests data.

Note
A cache can implement a subset of these states.

4.1.1 Clean line data forwarding

The protocol does not permit a cache line that is in SC state to forward data with the Snoop Response. The only
cache line states that are permitted to return data with the Snoop Response are:
• UC.
• UD.
• UDP.
• SD.

In each of these cases, only a single cache will return data, thus avoiding multiple data providers.

4.1.2 Empty cache line ownership

An empty cache line is a cache line that is held in a Unique state, so no other copies of the cache line exist, but none
of the data bytes are Valid. This cache line state is UCE.

The following are examples of when empty cache line ownership can occur:

• A Requester can deliberately obtain an empty cache line:

— Before starting a write, to save system bandwidth, a Requester that expects to write to a cache line can
obtain an empty cache line with permission to store, instead of obtaining a Valid copy of the cache line.

• A Requester can transition into an empty state:

— If the Requester has a copy of the cache line when it requests permission to store, and that copy of the
cache line is invalidated before the Requester obtains permission to store, this results in the Requester
having an empty cache line with permission to store.

4.1.3 Ownership of cache line with partial Dirty data

Once ownership of a cache line without data is obtained, the Requester is permitted to store to the cache line. If the
Requester modifies part of the cache line, the cache line remains partially Unique Dirty,

Such a state must be tracked. This cache line state is UDP.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-93
ID061214 Confidential
4 Coherence Protocol
4.2 Request types

4.2 Request types

Protocol requests are categorized as follows:

• Read requests:
— A data response is provided to the Requester.
— Can result in data movement among other agents in the system.
— Can result in a cache state change at the Requester.
— Can result in a cache state change at other Requesters in the system.

• Dataless requests:
— No data response is provided to the Requester.
— Can result in data movement among other agents in the system.
— Can result in a cache state change at the Requester.
— Can result in a cache state change at other Requesters in the system.

• Write requests:
— Move data from the Requester.
— Can result in data movement among other agents in the system.
— Can result in a cache state change at the Requester.
— Can result in a cache state change at other Requesters in the system.

• Other requests:
— Do not involve any data movement in the system.
— Used for miscellaneous actions such as propagating barriers into the interconnect, and assisting with
Distributed Virtual Memory (DVM) maintenance.

The following subsections enumerate the resulting transactions and their characteristics.

Note
In Read transactions, Dataless transactions on page 4-96 and Write transactions on page 4-97, information is
provided on the expected communicating node pairs. It is also legal for any transaction that is expected to target an
HN-F, but not an HN-I, to target an HN-I. This can occur in the case of an incorrect assignment of memory type for
a transaction. It is required that the HN-I responds to such a transaction in a protocol compliant manner. See
Appendix B Communicating Nodes for complete information on communication node pairs.

4.2.1 Read transactions

ReadNoSnp Read request to a Non-snoopable address region:
• Must not snoop other RNs.
• Data is included with the completion response.
• Data size is up to a cache line length, based on size attribute value in the request,
irrespective of memory attributes.
• Data will not be cached at the Requester in a system coherent manner.
• Can have exclusive attribute asserted. See Chapter 6 Exclusive Accesses for details.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F, HN-I).
— ICN(HN-F) to SN-F.
— ICN(HN-I) to SN-I.

4-94 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.2 Request types

ReadOnce Read request to a Snoopable address region to obtain a snapshot of the coherent data.
• Data is included with the completion response.
• Data size is a cache line length.
• Data will not be cached at the Requester.
Note
It is permitted to retain a copy of the data obtained in a local cache, or buffer, but this
copy of the data will not remain coherent.

• Communicating node pairs:

— RN-F, RN-D, RN-I to ICN(HN-F).

ReadClean Read request to a Snoopable address region:

• Data is included with the completion response.
• Data size is a cache line length.
• Data must be provided to the Requester in clean state only:
— UC, or SC.
• Can have exclusive attribute asserted. See Chapter 6 Exclusive Accesses for details.
• Communicating node pairs:
— RN-F to ICN(HN-F).

ReadShared Read request to a Snoopable address region.

• Data is included with the completion response.
• Data size is a cache line length.
• Requester will accept the data in any valid state:
— UC, UD, SC, or SD.
• Can have exclusive attribute asserted. See Chapter 6 Exclusive Accesses for details.
• Communicating node pairs:
— RN-F to ICN(HN-F).

ReadUnique Read request to a Snoopable address region to carry out a store to the cache line.
• All other cached copies must be invalidated.
• Data is included with the completion response.
• Data size is a cache line length.
• Data must be provided to the Requester in unique state only:
— UC, or UD.
• Communicating node pairs:
— RN-F to ICN(HN-F).

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-95
ID061214 Confidential
4 Coherence Protocol
4.2 Request types

4.2.2 Dataless transactions

CleanUnique Request to a Snoopable address region to change the state to Unique to carry out a store to
the cache line. Typical usage is when the Requester has a shared copy of the cache line and
wants to obtain permission to store to the cache line.
• Data is not included with the completion response.
• Any dirty copy of the cache line at a snooped cache must be written back to the next
level cache or memory.
• Can have exclusive attribute asserted. See Chapter 6 Exclusive Accesses for details.
• Communicating node pairs:
— RN-F to ICN(HN-F).

MakeUnique Request to Snoopable address region to obtain ownership of the line without a data
response. This request is used only when the Requester guarantees that it will carry out a
store to all bytes of the cache line.
• Data is not included with the completion response.
• Any dirty copy of the cache line at a snooped cache must be invalidated without
carrying out a data transfer.
• Communicating node pairs:
— RN-F to ICN(HN-F).

Evict Used to indicate that a Clean cache line is no longer cached by an RN.
• Data is not sent for this transaction.
• The cache line must not remain in the cache.
• Communicating node pairs:
— RN-F to ICN(HN-F).

Cache maintenance transactions

A Cache maintenance operation (CMO) assists with software cache management. The protocol includes the
following three transactions to support a CMO:

CleanShared Ensures that all cached copies are changed to a Non-dirty state and any dirty copy is written
back to memory.
• Data is not included with the completion response.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F).

CleanInvalid Invalidates all cached copies and any dirty copy is written to memory.
• Data is not included with the completion response.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F).

MakeInvalid Invalidates all cached copies and any Dirty copy can be discarded.
• Data is not included with the completion response.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F).

A CMO intended for a particular address must not be sent to the interconnect before all previous transactions sent
to the same address have completed.

A transaction, except Evict and WriteEvictFull, intended for a particular address, must not be sent to the
interconnect before a previous CMO sent to the same address has completed.

4-96 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.2 Request types

4.2.3 Write transactions

Write transactions move data from a Requester to a Completer, this might be the next level cache, memory, or a
peripheral. The data being transferred, depending on the transaction type, can be coherent or non-coherent. Each
write transaction must assert appropriate byte enables with the data.

Note
Any subsequent reference to WriteNoSnp and WriteUnique without a [Full] or [Ptl] suffix is to be read as applying
to both [Full] and [Ptl] versions of the transaction.

WriteNoSnpFull Write a full cache line of data to a Non-snoopable address region.

• Data size is a cache line length.
• All byte enables must be asserted.
• Can have the exclusive attribute asserted. See Chapter 6 Exclusive Accesses.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F, HN-I).
— ICN(HN-F) to SN-F.
— ICN(HN-I) to SN-I.

WriteNoSnpPtl Write to Non-snoopable address region.

• Data size is up to a cache line length.
• Byte enables must be asserted for the appropriate byte lanes within the specified data
size and deasserted in the rest of the data transfer.
• Can have the exclusive attribute asserted. See Chapter 6 Exclusive Accesses.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F, HN-I).
— ICN(HN-F) to SN-F.
— ICN(HN-I) to SN-I.

WriteUniqueFull Write to a Snoopable address region. Write a full cache line of data to the next-level cache
or memory when the cache line is invalid at the Requester.
• Data size is a cache line length.
• All byte enables must be asserted.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F).

WriteUniquePtl Write to a Snoopable address region. Write up to a cache line of data to the next-level cache
or memory when the cache line is invalid at the Requester.
• Data size is up to a cache line length.
• Byte enables must be asserted for the appropriate byte lanes within the specified data
size and deasserted in the rest of the data transfer.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(HN-F).

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-97
ID061214 Confidential
4 Coherence Protocol
4.2 Request types

CopyBack transactions
CopyBack transactions are a subclass of Write transactions. CopyBack transactions move coherent data from a
cache to the next level cache or memory. Each CopyBack transaction must assert the appropriate byte enables with
the data. CopyBack transactions do not require the snooping of other agents in the system.

WriteBackFull Write-back a full cache line of Dirty data to the next level cache or memory.
• Data size is a cache line length.
• All byte enables must be asserted.
• The cache line must not remain in the cache.
• Communicating node pairs:
— RN-F to ICN(HN-F).

WriteBackPtl Write-back up to a cache line of Dirty data to the next level cache or memory.
• Data size is a cache line length.
• All appropriate byte enables, up to all 64, must be asserted.
• The cache line must not remain in the cache.
• Communicating node pairs:
— RN-F to ICN(HN-F).

WriteEvictFull Write-back of UniqueClean data to the next-level cache.

• Data size is a cache line length.
• All byte enables must be asserted.
• The cache line must not remain in the cache.
• Communicating node pairs:
— RN-F to ICN(HN-F).

WriteCleanFull Write-back a full cache line of Dirty data to the next level cache or memory and retain a
Clean copy in the cache.
• Data size is a cache line length.
• All byte enables must be asserted.
• The cache line is expected to be in Clean state at completion of the transaction.
• Communicating node pairs:
— RN-F to ICN(HN-F).

WriteCleanPtl Write-back up to a cache line of dirty data to the next level cache or memory.
• Data size is up to a cache line length.
• All appropriate byte enables, up to all 64, must be asserted.
• The cache line state must be either retained in Unique state, without a copy of the
data, or not retained.
• Communicating node pairs:
— RN-F to ICN(HN-F).

4-98 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.2 Request types

4.2.4 Other transactions

This section describes the protocol transactions that carry out miscellaneous actions.

DVM transactions
DVM transactions are used for virtual memory system maintenance.

DVMOp DVM Operation. Actions include the passing of messages between components within a distributed
virtual memory system. See Chapter 8 DVM Operations for details.
• Communicating node pairs:
— RN-F, RN-D to ICN(MN).

Barrier transactions
Barrier transactions are used to order individual requests or groups of requests.

EOBarrier Endpoint Order Barrier. An EOBarrier transaction is sent by an RN to the ICN to indicate that the
ICN must not permit any requests that are generated after the EOBarrier to reach their respective
endpoint before all requests before the EOBarrier have reached their respective endpoint.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(MN).
— ICN(HN-I) to SN-I.

ECBarrier Endpoint Completion Barrier. Same as EOBarrier. An RN will typically use EOBarrier and
ECBarrier for memory and synchronization barrier requirements respectively.
• Communicating node pairs:
— RN-F, RN-D, RN-I to ICN(MN).
— ICN(HN-I) to SN-I.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-99
ID061214 Confidential
4 Coherence Protocol
4.3 Snoop requests

4.3 Snoop requests

The ICN generates a snoop request either in response to a request from an RN or due to an internal cache or snoop
filter maintenance operation. A snoop transaction, except for SnpDVMOp, operates on the cached data at the RN-F.
A SnpDVMOp transaction carries out a DVM maintenance operation at the target node.

SnpOnce Generated at the ICN on receipt of the ReadOnce request:

• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Optionally returns data with the snoop response if the target state is UC.
• Expected not to change cache state.

SnpClean Generated at the ICN on receipt of the ReadClean request:

• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Optionally returns data with the snoop response if the target state is UC.
• Must not leave the line in Unique state.

SnpShared Generated at the ICN on receipt of the ReadShared request:

• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Optionally returns data with the snoop response if the target state is UC.
• Must not leave the line in Unique state.

SnpUnique Generated at the ICN on receipt of the ReadUnique or WriteUniquePtl request. Might also
be generated by the ICN without a corresponding request:
• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Optionally returns data with the snoop response if the target state is UC.
• Must change the line to Invalid state.

SnpCleanShared Generated at the ICN on receipt of the CleanShared request:

• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Must not leave the cache line in a Dirty state.

SnpCleanInvalid Generated at the ICN on receipt of the CleanUnique, CleanInvalid, or WriteUniquePtl

request. Might also be generated by the ICN without a corresponding request:
• Returns data with the snoop response if the target state is UD, UDP, or SD.
• Must change the line to Invalid state.

SnpMakeInvalid Generated at the ICN on receipt of the MakeUnique or WriteUniqueFull request:

• Does not return data with the snoop response, Dirty data is discarded.
• Must change the cache line to Invalid state.

SnpDVMOp Generated at the ICN, initiated by the DVMOp request:

• A single DVMOp request generates two snoop requests.
• Returns a single snoop response for the two snoop requests.
See Non-sync type DVM transaction flow on page 8-166.

4-100 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.4 Request types and corresponding snoop requests

4.4 Request types and corresponding snoop requests

Table 4-1 shows the Request transactions and typical examples of the corresponding Snoop transactions that are
generated by the interconnect. A Requester can implement a subset of the Request transactions but must be able to
respond to all Snoop transactions.

Table 4-1 Request types and the corresponding snoop requests

Transaction type Request type Snoop request type

Read ReadNoSnp -

ReadOnce SnpOnce

ReadClean SnpClean

ReadShared SnpShared

ReadUnique SnpUnique

Dataless CleanUnique SnpCleanInvalid

MakeUnique SnpMakeInvalid

CleanShared SnpCleanShared

CleanInvalid SnpCleanInvalid

MakeInvalid SnpMakeInvalid

Evict -

Write WriteNoSnp -

WriteUniqueFull SnpMakeInvalid

WriteUniquePtl SnpCleanInvalid or SnpUnique

Write - CopyBack WriteBack -

WriteClean -

WriteEvictFull -

Others EOBarrier -

ECBarrier -

DVMOp SnpDVMOp

PCrdReturn -

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-101
ID061214 Confidential
4 Coherence Protocol
4.4 Request types and corresponding snoop requests

The interconnect has the following behavior when generating a snoop request on receipt of a request from an RN:

• Some transactions, such as ReadNoSnp, must never generate a snoop request.

• This specification supports a snoop filter or directory within the interconnect to track the state of cache lines
present in RN-F caches. The tracking can be as detailed as knowing each RN-F that has a copy of the cache
line, or as nonspecific as knowing that a cache line is present in one of the RN-F caches. Such tracking
permits the ICN to filter unnecessary snooping of an RN-F, for example:
— If the snoop filter indicates that the cache line is not present in any of the RN-F caches, then the
interconnect does not send a snoop request.
— If the cache line in the RN-F caches is already in the required state, for example the received request
is ReadShared and all cached copies of the cache line are in SharedClean (SC) state, then the
interconnect does not send a snoop request.

• It is permitted for the interconnect to generate a snoop request spontaneously without a corresponding request
from an RN. For example, the interconnect can send a SnpUnique or SnpCleanInvalid request as a result of
a backward invalidation from a snoop filter or interconnect cache.

• This specification permits the interconnect to select which snoop request to send. For example:
— For a WriteUniquePtl request, either a SnpCleanInvalid or SnpUnique snoop request can be sent. Both
of these snoop transactions invalidate the cache line and if the cache line is dirty then data is returned
with the response. The write data is written to memory once all snoop responses are received and the
partial data has been merged with any dirty data received with the snoop response.
The only difference in the behavior between the SnpCleanInvalid and SnpUnique snoop requests is
that SnpUnique can return data from the UniqueClean (UC) state but SnpCleanInvalid does not. Using
SnpUnique therefore might result in an unnecessary data transfer. This example shows the
disadvantage of using SnpUnique instead of SnpCleanInvalid in certain circumstances.

• This specification permits the interconnect to:

— Use either SnpShared or SnpClean for ReadClean and ReadShared transactions.
— Use any Snoop request type except SnpMakeInvalid for the ReadOnce transaction.
— Replace any invalidating Snoop request by the SnpUnique or SnpCleanInvalid request.

4-102 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.5 Response types

4.5 Response types

Each request can generate one or more responses. Some responses can also include data. A Response is classified
as follows:
• Completion response.
• WriteData response on page 4-105.
• Snoop response on page 4-106.
• Miscellaneous response on page 4-108.

4.5.1 Completion response

A completion response is required for all transactions except PCrdReturn. It is typically the last message sent, from
the Completer, to conclude a request transaction. The Requester might, however, still need to send a CompAck
response to conclude the transaction. A completion guarantees that the request has reached a PoS or a PoC, where
it will be ordered with respect to requests to the same address from any Requester in the system. See Chapter 7
Ordering for details on the Ordering guarantees.

Completion responses can be further categorized as:

• Read Completion.
• Dataless Completion.
• Write Completion.

Read transaction completion

A Read Completion is sent on the RDAT channel and uses the CompData opcode.

The completion response includes the Resp field that indicates the following:

Cache state The final state the cache line is permitted to be in at the Requester. For ReadNoSnp transactions a
cached copy can be kept at the Requester, but it will not be coherent and the Read completion
indicates that the cache state must be I.

Pass Dirty Indicates if the responsibility for updating memory is passed to the Requester. The assertion of the
Pass Dirty bit is shown by _PD in the response name.

Table 4-2 shows the permitted Read transaction completion, the encoding of the Resp field, and the meaning of the
response.

Table 4-2 Permitted Read transaction completion and Resp field encodings

Response Resp[2:0] Description

CompData_I 0b000 Used for ReadNoSnp and ReadOnce transactions.

Indicates that a coherent copy of the line cannot be kept.

CompData_UC 0b010 The final state of the cache line can be UC, UCE, SC or I.
Responsibility for a Dirty cache line is not being passed.

CompData_SC 0b001 The final state of the cache line can be SC or I.

Responsibility for a Dirty cache line is not being passed.

CompData_UD_PD 0b110 The final state of the cache line can be UD or SD.
Responsibility for a Dirty cache line is being passed.

CompData_SD_PD 0b111 The final state of the cache line must be SD.
Responsibility for a Dirty cache line is being passed.

In a response with an error indication, the cache state is permitted to be any value, including reserved values. See
Errors and transaction structure on page 9-186.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-103
ID061214 Confidential
4 Coherence Protocol
4.5 Response types

Dataless transaction completion

A Dataless Completion is sent on the CRSP channel and uses the Comp opcode.

The completion response includes the Resp field that indicates the following:

Cache state The final state the cache line is permitted to be in at the Requester.

Note
Dataless transactions do not pass responsibility for a Dirty cache line.

Table 4-3 shows the permitted Dataless transaction completion, the encoding of the Resp field, and the meaning of
the response.

Table 4-3 Permitted Dataless transaction completion and Resp field encodings

Response Resp[2:0] Description

Comp_I 0b000 The final state of the cache line must be I

Comp_UC 0b010 The final state of the cache line can be UC, UCE, SC or I

Comp_SC 0b001 The final state of the cache line can be SC or I

In a response with an error indication, the cache state is permitted to be any value, including reserved values. See
Errors and transaction structure on page 9-186.

Write transaction completion

A Write Completion is sent on the CRSP channel and uses the Comp or CompDBID opcode.

No cache state information, or responsibility for a Dirty cache line, is communicated using the Write transaction
completion. The Resp field of a Comp or CompDBIDResp response must be set to zero for a Write transaction
completion. All cache state information and responsibility for a Dirty cache line are communicated with the
WriteData, See WriteData response on page 4-105.

The permitted Write transaction completion responses are:

Comp Used when the Completion response is separate from the DBIDResp response.

CompDBIDResp Used when the Completion response is combined with the DBIDResp response. This
combined response is used by:
• CopyBack transactions. All CopyBack requests must use this completion response
type.
• Non-CopyBack writes, where the Completer can opportunistically combine the
Comp and DBIDResp responses if both are ready to be sent to the Requester.

Miscellaneous transaction completion

A Comp response, with the Resp field set to zero, is always used for Barrier and DVM transaction completion.

4-104 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.5 Response types

4.5.2 WriteData response

The WriteData response is part of Write request and DVMOp transactions. The Requester sends WriteData to the
Completer after receiving a guarantee that a buffer is available to accept the data. Buffer availability is signaled
through a DBIDResp response sent from the Completer.

The WriteData response is sent on the WDAT channel and uses either the CopyBackWrData or
NonCopyBackWrData opcode.

CopyBackWrData • Used for WriteBack, WriteClean, and WriteEvictFull transactions.

• Transfers coherent data from the cache at the Requester to the interconnect.
• Includes an indication of the cache line state prior to sending the WriteData response.

NonCopyBackWrData
• Used for WriteUnique and WriteNoSnp transactions.
• Used for a DVMOp transaction. WriteData provides additional information required
to perform DVM operations.
• The cache state in the response must be I.

The response includes the Resp field, which indicates the following:

Cache state Indicates the state of the cache line before sending the WriteData response. This state can differ from
the state of the cache line when the original transaction request was sent if a snoop request, to the
same address, is received by the Requester after sending the original transaction request, but before
sending the corresponding WriteData response.

Pass Dirty Indicates if the responsibility for updating memory is passed by the Requester. The assertion of the
Pass Dirty bit is shown by _PD in the response name.
Table 4-4 shows the permitted WriteData responses, the Opcode and Resp field encodings, and the meaning of the
response.

Table 4-4 Permitted WriteData responses and Opcode and Resp field encodings

Response DAT Opcode Resp[2:0] Description

CopyBackWrData_I 0x2 0b000 Data corresponding to a CopyBack request.

Cache line state when data was sent is I.

CopyBackWrData_UC 0x2 0b010 Data corresponding to a CopyBack request.

Cache line state when data was sent is UC.

CopyBackWrData_SC 0x2 0b001 Data corresponding to a CopyBack request.

Cache line state when data was sent is SC.

CopyBackWrData_UD_PD 0x2 0b110 Data corresponding to a CopyBack request.

Cache line state when data was sent is UD or UDP.
Responsibility for updating the memory is passed.

CopyBackWrData_SD_PD 0x2 0b111 Data corresponding to a CopyBack request.

Cache line state when data was sent is SD.
Responsibility for updating the memory is passed.

NonCopyBackWrData 0x3 0b000 Data corresponding to a Non-CopyBack Write request.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-105
ID061214 Confidential
4 Coherence Protocol
4.5 Response types

Note
The cache line state at the Requester after the write transaction has completed is not determined from the cache state
information in the WriteData response. It can be determined if the cache line remains Valid or not after the
transaction by the opcode of the transaction:
• A WriteBack or WriteEvict transaction must be in I state.
• A WriteClean transaction can remain allocated and in a Clean state.

The cache line state associated with a WriteData completion can be any value when the WriteData RespErr field
indicates there is a data error.

4.5.3 Snoop response

A Snoop request transaction includes a Snoop response. A Snoop response can be with or without data. The three
forms of Snoop response are:

Snoop response without data

• This Snoop response is used when no data transfer is required.
• It is sent on the SRSP channel and uses the SnpResp opcode.
• It is sent when the combination of Snoop request and the cache line state is one of the
following:
— Any Snoop request and the cache line state is UCE, SC, or I.
— A SnpMakeInvalid Snoop request and any cache line state.
— A SnpCleanInvalid or SnpCleanShared Snoop request and the cache line is UC.
— Optionally, for any Snoop request except SnpMakeInvalid, SnpCleanInvalid, or
SnpCleanShared, and the cache line state is UC.
• Snoop response without data is always used for the response to a SnpDVMOp transaction.

Snoop response with data

• This Snoop response is used when a full cache line of data is transferred to the interconnect.
• It is sent on the WDAT channel and uses the SnpRespData opcode.
• It is sent when the combination of the Snoop request and cache line state is:
— Any Snoop request, except SnpMakeInvalid, and the cache line state is UD or SD.
— Optionally, for any Snoop request except SnpMakeInvalid, SnpCleanInvalid, or
SnpCleanShared, and the cache line state is UC.

Snoop response with partial data

• This Snoop response is used when a partial cache line of data is transferred to the
interconnect.
• It is sent on the WDAT channel and uses the SnpRespDataPtl opcode.
• It is sent when the combination of the Snoop request and cache line state is:
— Any Snoop request except SnpMakeInvalid, and the cache line state is UDP.

The Snoop response includes the Resp field, which indicates the following:

Cache state The final state of the cache line at the snooped node after sending the Snoop response.

Pass Dirty Indicates that the responsibility for updating memory is passed to the Requester or ICN.
Pass Dirty must only be asserted for a Snoop response with data. The assertion of the Pass Dirty bit
is shown by _PD in the response name.

These attributes convey sufficient information for the interconnect to determine the appropriate response to the
initial Requester, and to determine if data must be written back to memory. It is also sufficient to support snoop filter
or directory maintenance in the interconnect.

4-106 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.5 Response types

Note
The Snoop response cache state information provides the state of the cache line after the Snoop response is sent.
This is different from:

• A write data response, where the cache state information provides the state of the cache line at the point the
write data is sent.

• A read data response, where the cache state information indicates the permitted state of the cache line after
the transaction completes.

Table 4-5 shows the permitted Snoop responses without Data, the Opcode and Resp field encodings, and the
meaning of the response.

Table 4-5 Permitted Snoop responses without Data and the Opcode and Resp field encodings

Response RSP Opcode Resp[2:0] Description

SnpResp_I 0x1 0b000 Snoop response without data.

Cache line state is I.

SnpResp_UC 0x1 0b010 Snoop response without data

Cache line state is UC, UCE, SC, or I.

SnpResp_SC 0x1 0b001 Snoop response without data.

Cache line state is SC, or I.

Table 4-6 shows the permitted Snoop responses, the Opcode and Resp field encodings, and the meaning of the
response.

Table 4-6 Permitted Snoop responses with Data and the Opcode and Resp field encodings

Response DAT Opcode Resp[2:0] Description

SnpRespData_I 0x1 0b000 Snoop response with data.

Cache line state is I.

SnpRespData_UC 0x1 0b010 Snoop response with data.

SnpRespData_UD Cache line state is UC or UD.
Note
A single encoding is used to indicate that the cache line is unique.
This encoding is used for UC and UD.

SnpRespData_SC 0x1 0b001 Snoop response with data.

Cache line state is SC.

SnpRespData_SD 0x1 0b011 Snoop response with data.

Cache line state is SD.

SnpRespData_I_PD 0x1 0b100 Snoop response with data.

Cache line state is I.
Responsibility for updating the memory is passed.

SnpRespData_UC_PD 0x1 0b110 Snoop response with data.

Cache line state is UC.
Responsibility for updating the memory is passed.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-107
ID061214 Confidential
4 Coherence Protocol
4.5 Response types

Table 4-6 Permitted Snoop responses with Data and the Opcode and Resp field encodings (continued)

Response DAT Opcode Resp[2:0] Description

SnpRespData_SC_PD 0x1 0b101 Snoop response with data.

Cache line state is SC.
Responsibility for updating the memory is passed.

SnpRespDataPtl_I_PD 0x5 0b100 Snoop response with partial data.

Cache line state is I.
Responsibility for updating the memory is passed.

SnpRespDataPtl_UD 0x5 0b010 Snoop response with partial data.

Cache line state is UDP.

Note
The cache line state associated with a Snoop response, either with or without data, must be a legal value, even if the
RespErr field indicates there is a error.

4.5.4 Miscellaneous response

This section describes responses that cannot be classified as a Completion, WriteData or Snoop response.

For all responses in this section the Resp and RespErr fields have no meaning and must be set to zero.

The miscellaneous responses are:

CompAck
• Sent by the Requester on receipt of the Completion response.
• Used by Read, Dataless, and WriteUnique transactions.
See Transaction structure on page 2-35.

RetryAck
• Sent by a Completer to a Requester if the request is not accepted at the Completer due to lack
of appropriate resources.
• Response is valid for any request transaction except PCrdReturn.
See Transaction Retry sequence on page 2-45.

PCrdGrant
• Grants a Protocol Credit. A subsequent request, sent using the Protocol Credit, is guaranteed
to be accepted by the target.
See Transaction Retry sequence on page 2-45.

ReadReceipt
• Sent for a request that requires Request Order in the interconnect with respect to other
ordered requests from the same Requester.
• Applies to ReadNoSnp and ReadOnce request transactions.
See ReadNoSnp, ReadOnce on page 2-35.

DBIDResp
• Response sent as part of a write transaction to signal to the Requester that resources are
available to accept the WriteData response.
See Transaction structure on page 2-35.

4-108 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.6 Silent cache state transitions

4.6 Silent cache state transitions

A cache can change state due to an internal event without notifying the rest of the system.

The legal silent cache state transitions are shown in Table 4-7. In some cases it is possible, but not required, to issue
a transaction to indicate that the transition has occurred. If such a transaction is issued then the cache state transition
is visible to the interconnect and is not classified as a silent transition.

The RN-F action described in Table 4-7 as Local sharing, describes the case where an RN-F specifies a Unique
cache line as Shared, effectively disregarding the fact that the cache line remains Unique to the RN-F. For example,
this can happen when the RN-F contains multiple internal agents and the cache line becomes shared between them.

For silent cache state transitions:

• Cache eviction and Local sharing transitions can occur at any point and are IMPLEMENTATION DEFINED.

• Store and Cache Invalidate transitions can only occur as the result a deliberate action, which in the case of a
core is caused by the execution of a particular program instruction.

Table 4-7 Legal silent cache state transitions

RN-F action RN-F Cache state Notes

Present Next

Cache eviction UC I Can use Evict or WriteEvictFull transaction

UCE I Can use Evict transaction

SC I Can use Evict transaction

Local sharing UC SC -

UD SD -

Store UC UD Full or partial line store

UCE UDP Partial line store

UCE UD Full line store

UDP UD Store that fills the cache line

Cache Invalidate UD I Can use Evict transaction

UDP I Can use Evict transaction

A cache state change from UC to UCE is not permitted.

Note
Sequences of silent transitions can also occur. Any silent transition that results in the cache line being in UD, UDP,
or SC state can undergo a further silent transition.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-109
ID061214 Confidential
4 Coherence Protocol
4.7 Cache state transitions

4.7 Cache state transitions

This section specifies the cache state transitions and completion responses for the following request transactions:
• Read request transactions.
• Dataless request transactions on page 4-111.
• Write request transactions on page 4-112.
• Other request transactions on page 4-113.
• Snoop request transactions on page 4-113.

4.7.1 Read request transactions

Table 4-8 shows the cache state transitions at the Requester, and the completion responses, for Read request
transactions.

Table 4-8 Cache state transitions at the Requester for Read request transactions

Request type Initial cache state Final cache state Comp Resp

Expected Other Permitted

ReadNoSnp I - I CompData_I

ReadOnce I, UCE - I CompData_I

ReadClean I, UCE - UC CompData_UC

SC CompData_SC

ReadShared I, UCE - SC CompData_SC

UC CompData_UC

SD CompData_SD_PD

UD CompData_UD_PD

ReadUnique I, SC UC, UCE UD CompData_UD_PD

UC CompData_UC

SD UD, UDP UD CompData_UC

Note
• The Other Permitted initial cache states in Table 4-8 are the cache states that are permitted while the
transaction is in progress.

• For any of the transactions in Table 4-8, it is legal to use the transaction if the cache line can silently transition
to any Expected or Other Permitted state. This silent transition must occur before the transaction is issued.

4-110 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.7 Cache state transitions

4.7.2 Dataless request transactions

Table 4-9 shows the cache state transitions at the Requester, and the completion responses, for Dataless request
transactions.

Table 4-9 Cache state transitions at the Requester for Dataless request transactions

Request type Initial cache state Final cache state Comp Response

Expected Other permitted

CleanUnique I UC, UCE UCE Comp_UC

SC UC UC Comp_UC

SD UD UD Comp_UC

MakeUnique I, SC, SD UC, UCE UD Comp_UC

CleanShared I UC, UCE, SC I Comp_UC

Comp_SC

Comp_I

UC - UC Comp_UC

SC - UC Comp_UC

SC Comp_SC

CleanInvalid I - I Comp_I

MakeInvalid I - I Comp_I

Evict I - I Comp_I

Before a CleanInvalid, MakeInvalid or Evict transaction it is permitted for the cache state to be UC, UCE or SC.
However, it is required that the cache state transitions to the I state before the transaction is issued. Therefore
Table 4-9 shows I state as the only initial state.

Note
• The Other Permitted initial cache states in Table 4-9 are the cache states that are permitted while the
transaction is in progress.

• For any of the transactions in Table 4-9, it is legal to use the transaction if the cache line can silently transition
to any Expected or Other Permitted state. This silent transition must occur before the transaction is issued.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-111
ID061214 Confidential
4 Coherence Protocol
4.7 Cache state transitions

4.7.3 Write request transactions

Table 4-10 shows the cache state transitions at the Requester, and the completion and DBID response for Write and
WriteBack request transactions.

Table 4-10 Requester cache state transitions for Write request transactions

Request Type Cache state at Requester WriteData response Comp and Resp

Initial Before WriteData responsea Final

WriteBackFull UD UD I CBWrData_UD_PD CompDBIDResp

UC I CBWrData_UC CompDBIDResp

UD, SD SD I CBWrData_SD_PD CompDBIDResp

SC I CBWrData_SC CompDBIDResp

I I CBWrData_I CompDBIDResp

WriteBackPtl UDP UDP I CBWrData_UD_PD CompDBIDResp

I I CBWrData_I CompDBIDResp

WriteCleanFull UD UD UC CBWrData_UD_PD CompDBIDResp

UC UC CBWrData_UC CompDBIDResp

UD, SD SD SC CBWrData_SD_PD CompDBIDResp

SC SC CBWrData_SC CompDBIDResp

I I CBWrData_I CompDBIDResp

WriteCleanPtl UDP UDP UCE CBWrData_UD_PD CompDBIDResp

I I CBWrData_I CompDBIDResp

WriteUnique I I I NCBWrData_I DBIDResp + Comp or

CompDBIDResp

WriteEvictFull UC UC I CBWrData_UC Comp

SC I CBWrData_SC Comp

I I CBWrData_I Comp

WriteNoSnp I - I NCBWrData_I DBIDResp + Comp or

CompDBIDResp

a. A snoop might be received while a write is pending and result in a cache line state change before the WriteData response.

Note
After completion of a WriteClean transaction, it is possible for the cache line in a Unique state to immediately
transition to a Dirty state.

4-112 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.7 Cache state transitions

4.7.4 Other request transactions

DVMOp, EOBarrier, and ECBarrier requests do not have any cache state transitions associated with them.

4.7.5 Snoop request transactions

Table 4-11 shows, for each snoop type, the initial, expected final, and permitted final cache states, and the valid
completion response from a snooped RN-F.

Table 4-11 Snooped requester cache state transactions and valid completion responses

Snoop request type Initial cache state Final cache state Comp response

Expected Other permitted

SnpOnce I I - SnpResp_I

UC UC I, SC SnpRespData_UC

UC I, SC SnpResp_UC

SC I SnpRespData_SC

SC I SnpResp_SC

I - SnpRespData_I

I - SnpResp_I

UCE UCE I SnpResp_UC

I - SnpResp_I

UD UD SD SnpRespData_UD

SD - SnpRespData_SD

SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

UDP I - SnpRespDataPtl_I_PD

UDP - SnpRespDataPtl_UD

SC SC I SnpResp_SC

I - SnpResp_I

SD SD - SnpRespData_SD

SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-113
ID061214 Confidential
4 Coherence Protocol
4.7 Cache state transitions

Table 4-11 Snooped requester cache state transactions and valid completion responses (continued)

Snoop request type Initial cache state Final cache state Comp response

Expected Other permitted

SnpClean, I I - SnpResp_I
SnpShared
UC SC I SnpRespData_SC

I - SnpRespData_I

SC I SnpResp_SC

I - SnpResp_I

UCE I - SnpResp_I

UD SD - SnpRespData_SD

SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

UDP I - SnpRespDataPtl_I_PD

SC SC I SnpResp_SC

I - SnpResp_I

SD SD - SnpRespData_SD

SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

SnpUnique I I - SnpResp_I

UC I - SnpRespData_I

I - SnpResp_I

UCE I - SnpResp_I

UD I - SnpRespData_I_PD

UDP I - SnpRespDataPtl_I_PD

SC I - SnpResp_I

SD I - SnpRespData_I_PD

4-114 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.7 Cache state transitions

Table 4-11 Snooped requester cache state transactions and valid completion responses (continued)

Snoop request type Initial cache state Final cache state Comp response

Expected Other permitted

SnpCleanShared I I - SnpResp_I

UC UC I, SC SnpResp_UC

SC I SnpResp_SC

I - SnpResp_I

UCE I - SnpResp_I

UD UC I, SC SnpRespData_UC_PD

SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

UDP I - SnpRespDataPtl_I_PD

SC SC I SnpResp_SC

I - SnpResp_I

SD SC I SnpRespData_SC_PD

I - SnpRespData_I_PD

SnpCleanInvalid I I - SnpResp_I

UC I - SnpResp_I

UCE I - SnpResp_I

UD I - SnpRespData_I_PD

UDP I - SnpRespDataPtl_I_PD

SC I - SnpResp_I

SD I - SnpRespData_I_PD

SnpMakeInvalid I I - SnpResp_I

UC I - SnpResp_I

UCE I - SnpResp_I

UD I - SnpResp_I

UDP I - SnpResp_I

SC I - SnpResp_I

SD I - SnpResp_I

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-115
ID061214 Confidential
4 Coherence Protocol
4.7 Cache state transitions

Note
• A response must be either a SnpResp or SnpRespData. In the case of multiple final cache state options, the
response that is used is IMPLEMENTATION DEFINED.

• A Request Node does not have to respond to a snoop with data when in UC state. Except for SnpOnce, the
receiver of the snoop response can not differentiate between:
— A Request Node not responding with data from an UC state.
— A Request Node silently transitioning to SC or I state, prior to receiving the snoop request, and
therefore not including data with the snoop response.

4-116 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.8 Legal snoop response combinations

4.8 Legal snoop response combinations

If a cache line is held in a Unique state, the associated snoop responses from all other Request Nodes must be
SnpResp_I. A cache line that is held in a Unique state is indicated by one of the following responses:
• SnpRespData_UD.
• SnpRespData_UC_PD.
• SnpRespData_UC.
• SnpResp_UC.
• SnpRespDataPtl_I_PD.
• SnpRespDataPtl_UD.
• SnpRespData_SC.

If a cache line is held in any state that permits the returning of data, all the remaining snoop responses associated
with a single transaction must be either SnpResp_I or SnpResp_SC.

Table 4-12 shows the legal combinations of snoop responses from all snooped Requesters for a given snoop
transaction.

Table 4-12 Snoop response combinations corresponding to a single transaction

If one response is: These responses can occur 0 or more times

SnpRespData_UD SnpResp_I

SnpRespData_UC_PD SnpResp_I

SnpRespData_UC SnpResp_I

SnpResp_UC SnpResp_I

SnpRespDataPtl_I_PD SnpResp_I

SnpRespDataPtl_UD SnpResp_I

SnpRespData_SC SnpResp_I

SnpRespData_SD SnpResp_I
SnpResp_SC

SnpRespData_SC_PD SnpResp_I
SnpResp_SC

SnpRespData_I_PD SnpResp_I
SnpResp_SC

SnpRespData_I SnpResp_I

- SnpResp_I
SnpResp_SC

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-117
ID061214 Confidential
4 Coherence Protocol
4.8 Legal snoop response combinations

Alternatively, the legal snoop response combinations can be expressed in Backus–Naur Form (BNF):

(SnpResp_I*

(SnpRespData_UD | SnpRespData_UC_PD | SnpRespData_UC | SnpResp_UC | SnpRespData_SC | SnpRespData_I |

SnpRespDataPtl_I_PD | SnpRespDataPtl_UD)) |

(SnpResp_I* SnpResp_SC*

(SnpRespData_SD | SnpRespData_SC_PD | SnpRespData_I_PD)) |

(SnpResp_I* SnpResp_SC*)

Note
In the BNF representation, a Snoop Response with the suffix * implies that the Snoop Response can occur zero or
more times.

4-118 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.9 Hazard conditions

4.9 Hazard conditions

This section lists the responsibilities of the RN-F to handle address hazards and race conditions among Snoopable
transactions. Ordering among Non-snoopable transactions and among Snoopable transactions is described in
Chapter 7 Ordering.

In addition to many Requesters issuing transactions at the same time, the protocol also permits each Requester to
make multiple outstanding requests, and to receive multiple outstanding snoop requests. It is the responsibility of
the interconnect, that is, ICN(HN-F, HN-I and MN), to ensure that there is a defined order in which transactions to
the same cache line can occur, and that the defined order is the same for all components.

4.9.1 At the RN-F node

An RN-F node must respond to received snoop requests, except for SnpDVMOps, in a timely manner without
creating any Protocol layer dependency on completion of outstanding requests:

• If a pending request to the same cache line is present at the RN-F:

— The snoop request must be processed normally.
— The cache state must transition as applicable for each snoop request type.
— The cached data or CopyBack request data must be returned with the snoop response if required by
the snoop request type and cache state.

• If the pending request is a CopyBack request then the following additional requirements apply:
— Request transaction flow must be completed after receiving the CompDBIDResp.
— The cache state in the WriteData response must be the state of the cache line after the snoop request is
processed, not the state at the time of sending the CopyBack request.

The RN-F might receive multiple snoop requests before it receives a response for a pending CopyBack request for
the same cache line, in which case the data response carries the cache line state after completion of the response to
the last snoop request. Such a scenario is possible because the CopyBack request can be queued behind multiple
Read and Dataless requests at the HN-F.

A CopyBack request must not be cancelled after a snoop response.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-119
ID061214 Confidential
4 Coherence Protocol
4.9 Hazard conditions

4.9.2 Hazard handling examples

The following examples show how a CopyBack-Snoop request hazard condition is handled at the Requester. See
also Read - CopyBack or Dataless - CopyBack hazard at HN-F on page 5-139 for hazard handling at the
interconnect.

CopyBack-Snoop hazard at RN-F

Figure 4-1 on page 4-121 shows a Snoop request to an RN-F hazarding a pending CopyBack request at time C. The
steps required to resolve this hazard are:

1. At time C:
• The SnpShared transaction ignores the hazard and reads the cache line data.
• The cache line state is changed from UD to SC.

2. At time D:
• The CompDBIDResp for the CopyBack is sent to RN-F0.
• RN-F0 sends back a CopyBackWrData_SC response.
• The cache line state is changed from SC to I.
The data is clean for coherence and is not required to be sent to the interconnect for correct functionality.
However, the protocol requires the CopyBack flow to be consistent irrespective of a snoop hazard.
The cache line state in the WriteData response is SC because that is the state of the cache line when the
WriteData response is sent.

4-120 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 4 Coherence Protocol
4.9 Hazard conditions

RN-F0 RN-F1 RN-F2 HN-F SN-F

UD I I
Req1: ReadShared
Req2: WriteBack
ReadNoSnp
A

SnpShared
UD->SC Hazard detected
C Req2 progress
blocked

SnpRespData_SC_PD
Hazard with
CopyBack detected
but ignored

CompData_SC
WriteNoSnp
I->SC

CompAck
CompDBIDResp

B
SC->I
CompDBIDResp NCBWrData
D
CopyBackWrData_SC Req2 progress
(PS = SC, NS(implied) = I) un-blocked
CopyBack
Completed with a
WriteData response

PS = PresentState
NS = NextState

Figure 4-1 CopyBack-Snoop hazard at RN-F example

Note
• The response to a snoop request that hazards with an outstanding Evict must be SnpResp_I.

• During the period between receiving a snoop request and sending a snoop response, including data if
applicable, while a CopyBack request to the same address is pending, the only response that can be received
for the CopyBack request is a RetryAck.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 4-121
ID061214 Confidential
4 Coherence Protocol
4.9 Hazard conditions

Figure 4-2 shows a further example of a snoop request hazarding with an outstanding CopyBack request. In this
example, the snoop request is a SnpOnce request generated as a result of a ReadOnce request from RN-F1. The
SnpOnce request receives a copy of the data with the snoop response but does not change the cache line state. In
this case, the final data response from RN-F0 indicates that the data is Dirty and that HN-F must write the data back
to memory.

RN-F0 RN-F1 RN-F2 HN-F SN-F

UD I I

ReadOnce

WriteBack
SnpOnce

UD->UD

Hazard detected
SnpRespData_UD WriteBack progress
Hazard detected blocked
but ignored

CompData_I

CompAck
ReadOnce
does not
write back
Data

WriteBack progress
CompDBIDResp
un-blocked
UD->I

CBWrData_UD
(PS=UD, NS[implied]=I)

CopyBack WrNoSnp
Completed with a
WriteData response

PS = PresentState
NS = NextState

Figure 4-2 CopyBack-Snoop hazard with no cache state change example

4-122 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 5
Interconnect Protocol Flows

This chapter shows interconnect protocol flows for different transaction types, and interconnect hazard conditions.
The protocol flows are illustrated using Time-Space diagrams. It contains the following sections:
• Read transaction flows on page 5-124.
• Dataless transaction flows on page 5-130.
• Write transaction flows on page 5-133.
• Interconnect hazard conditions on page 5-136.

See Time-Space diagrams on page xiii for details of the conventions used to illustrate protocol flow in this
specification.

In the transaction flow diagrams that follow:

• There are three coherent RNs, an HN-F and a SN-F.

• The HN-F broadcasts snoops because it does not have any means to filter them.

• If the HN-F receives multiple data responses, that is, one response from a snooped RN-F and another from a
SN-F, then the data being forwarded to the Requester is highlighted in bold.

• There is no ICN cache at the HN-F, this results in all requests to the HN-F initiating a request to the SN-F.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-123
ID061214 Confidential
5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1 Read transaction flows

This section gives examples of the interconnect protocol flow for Read transactions.

5.1.1 Read transaction without snoops

An example of this type of flow is the ReadNoSnp transaction. The request does not generate any snoops and
receives the data from a response to a memory read by the HN-F. The steps in the ReadNoSnp transaction flow are:
1. RN-F0 issues a ReadNoSnp transaction.
2. HN-F receives and allocates the request.
Note
HN-F does not send snoops as the request is recognized as a Non-snoopable request type.

3. HN-F sends a ReadNoSnp to SN-F.

4. SN-F returns data response to HN-F.
5. HN-F in turn returns the data to RN-F0. If ExpCompAck was not asserted in the ReadNoSnp request then
HN-F deallocates the request.
6. If ExpCompAck was asserted in the ReadNoSnp request, RN-F0 sends a CompAck response to HN-F.
7. RN-F0 deallocates the request.
8. HN-F receives the CompAck response and deallocates the request.

Figure 5-1 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I

ReadNoSnp

ReadNoSnp

CompData_I

CompData_I

I->I

CompAck

Figure 5-1 ReadNoSnp transaction flow

5-124 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.2 Read transaction with snoops and data from memory

An example of this type of flow is a ReadUnique transaction. The request results in HN-F generating snoops to other
RN-Fs in the system. None of the snoop responses return data, so the data received in the read request to memory
is returned to the Requester.

In this flow, HN-F sends a speculative read to SN-F without waiting for the snoop responses.

Figure 5-2 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I I

Speculative
ReadUnique read

ReadNoSnp

SnpUnique

SnpUnique

SnpResp_I SnpResp_I
CompData_I

CompData_UC

I->UC

CompAck

Figure 5-2 ReadUnique with invalid cache state

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-125
ID061214 Confidential
5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.3 Read transaction with snoop response with data and no memory update
An example of this type of flow is a ReadUnique transaction. RN-F2 has the cache line in UC state and responds to
the snoop with a snoop response with data.

HN-F waits for all the snoop responses and forwards the data received from RN-F2 to the Requester. The Requester
must complete the transaction by sending a CompAck.

In this flow, HN-F sends a speculative read to SN-F without waiting for snoop responses, but discards the data
received from SN-F.

Figure 5-3 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I UC

Speculative
ReadUnique read

ReadNoSnp

SnpUnique

SnpUnique

UC->I

SnpResp_I SnpRespData_I

CompData_I

CompData_UC

I->UC

CompAck

Figure 5-3 ReadUnique with clean data forwarding

5-126 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.4 Read transaction with snoop response with data and memory update
An example of this type of flow is a ReadClean transaction.

RN-F1 has the cache line in UD state and responds to the snoop with a snoop response with data. RN-F1 passes
responsibility of updating memory to HN-F.

HN-F waits for all the snoop responses and forwards the data received from RN-F1 to the Requester. Because the
request is ReadClean, HN-F does not pass responsibility of updating memory to the Requester.

HN-F sends a write request to update memory. HN-F in this case waits for both a CompAck and CompDBIDResp
from SN-F before deallocating the request.

In this flow HN-F also sends a speculative read to SN-F without waiting for snoop responses, but discards the data
received from SN-F.

Figure 5-4 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I UD I

Speculative
ReadClean
read

ReadNoSnp
SnpClean

SnpClean
CompData_I
UD->SC

SnpResp_I

SnpRespData_SC_PD

WriteNoSnp

CompData_SC CompDBIDResp

NCBWrData
I->SC

CompAck

NCBWrData = NonCopyBackWrData

Figure 5-4 ReadClean with Dirty data at snooped node

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-127
ID061214 Confidential
5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.5 Read transaction with snoop response with partial data and no memory update
An example of this type of flow is a ReadUnique transaction.

RN-F1 has the cache line in UDP state. RN-F1 responds to the snoop with a snoop response with partial cache line
data and passes responsibility for updating memory.

HN-F waits for the data response from memory, merges the partial snoop response data with the data response from
memory, and sends the resultant data to the Requester.

HN-F does not update memory because responsibility for updating memory is passed on to the Requester.

Figure 5-5 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I UDP I

ReadUnique

ReadNoSnp

SnpUnique

SnpUnique

UDP->I
SnpRespDataPtl_I_PD SnpResp_I
CompData_I

Merge
data
CompData_UD_PD

I->UD

CompAck

Figure 5-5 ReadUnique with partial data snoop response

5-128 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.6 Read transaction with snoop response with partial data and memory update.
An example of this type of flow is a ReadClean transaction.

RN-F1 has the cache line in UDP state. RN-F1 responds to the snoop with a snoop response with partial cache line
data and passes responsibility for updating memory.

HN-F waits for the data response from memory, merges the partial snoop response data with the data response from
memory, and sends the resultant data to the Requester.

HN-F updates memory as the responsibility for updating memory is not passed on to the Requester.

Figure 5-6 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I UDP I

ReadClean

ReadNoSnp
SnpClean

SnpClean

UDP->I
SnpResp_I

SnpRespDataPtl_I_PD CompData_I

WriteNoSnp
CompData_UC Merge
data
I->UC

CompAck

CompDBIDResp

NCBWrData

NCBWrData = NonCopyBackWrData

Figure 5-6 ReadClean with partial data snoop response

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-129
ID061214 Confidential
5 Interconnect Protocol Flows
5.2 Dataless transaction flows

5.2 Dataless transaction flows

This section gives examples of the interconnect protocol flow for Dataless transactions.

5.2.1 Dataless transaction without memory update

An example of this type of flow is a MakeUnique transaction.

RN-F1 has the cache line in UC state. RN-F1 responds to the snoop with a snoop response without data and changes
the cache line state to I.

HN-F waits for all snoop responses and then sends a Comp_UC response to the Requester.

HN-F does not send a read request to SN-F because the request is a Dataless transaction.

Figure 5-7 shows the transaction flow.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I UC I

MakeUnique

SnpMakeInvalid

SnpMakeInvalid

UC->I
SnpResp_I SnpResp_I

Comp_UC

I->UC

CompAck

Figure 5-7 MakeUnique without memory update

5-130 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.2 Dataless transaction flows

5.2.2 Dataless transaction with memory update

An example of this type of flow is a CleanUnique transaction.

RN-F1 has the cache line in SD state and responds to the snoop with a snoop response with data and PD asserted.

HN-F waits for all snoop responses and then sends a Comp_UC response to the Requester.

HN-F sends a write request to update memory with the data received from RN-F1.

Figure 5-8 shows the transaction flow.

RN-F0 RN-F1 RN-F2 HN-F SN-F

SC SD I

CleanUnique

SnpCleanInvalid

SnpCleanInvalid

SD->I
SnpRespData_I_PD

SnpResp_I
WriteNoSnp

CompDBIDResp

Comp_UC
NCBWrData

SC->UC

CompAck

NCBWrData = NonCopyBackWrData

Figure 5-8 CleanUnique with memory update

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-131
ID061214 Confidential
5 Interconnect Protocol Flows
5.2 Dataless transaction flows

5.2.3 Evict transaction

Figure 5-9 shows the Evict transaction flow.

RN-F0 moves the cache line to I state and issues an Evict transaction.

HN-F receives and allocates the request.

Note
The Evict request is a hint. A Comp response can be given by HN-F without updating the Snoop Filter or Snoop
Directory.

HN-F returns the Comp response and deallocates the request.

RN-F0 deallocates the request.

RN-F0 RN-F1 RN-F2 HN-F SN-F

UC I I

UC->I
Evict

Update
Snoop Filter or
Snoop Directory

Comp_I

Figure 5-9 Evict transaction flow

5-132 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.3 Write transaction flows

5.3 Write transaction flows

This section gives examples of the interconnect protocol flow for Write transactions.

5.3.1 Write transaction with no snoop and separate responses

An example of this type of flow is a WriteNoSnp transaction. The steps in the WriteNoSnp transaction flow are:
1. RN-F0 issues a WriteNoSnp transaction.
2. HN-F receives and allocates the request.
3. HN-F sends DBIDResp without Comp.
4. RN-F0 responds with data.
5. HN-F sends a Comp after it receives CompDBIDResp from SN-F.
Note
This flow example shows Comp is sent after CompDBIDResp is received from SN-F. However, HN-F is
permitted to send Comp anytime after it receives the WriteNoSnp request from RN-F0.

6. RN-F0 waits for Comp from HN-F and deallocates its request.

Figure 5-10 shows the flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I I

WriteNoSnp

DBIDResp

WriteNoSnp
NCBWrData

CompDBIDResp

NCBWrData
Comp

NCBWrData = NonCopyBackWrData

Figure 5-10 WriteNoSnp with separate responses from HN to RN

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-133
ID061214 Confidential
5 Interconnect Protocol Flows
5.3 Write transaction flows

5.3.2 Write transaction with snoop

An example of this type of flow is a WriteUniquePtl transaction.

The Comp_I response from HN-F must be sent when the coherency activity is complete at HN-F.

Figure 5-11 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I UD

WriteUniquePtl

SnpCleanInvalid
SnpCleanInvalid
DBIDResp

UD->I

SnpRespData_I_PD

SnpResp_I
NCBWrData
Merge
data

WriteNoSnp
Comp_I

CompDBIDResp

NCBWrData

NCBWrData = NonCopyBackWriteData

Figure 5-11 WriteUniquePtl with snoop

5-134 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.3 Write transaction flows

5.3.3 CopyBack write transaction to memory

An example of this type of flow is a WriteBackFull transaction.

The data received from RN-F0 is written to SN-F by HN-F using a WriteNoSnp transaction.

Figure 5-12 shows the transaction flow, the copy of data being transferred is marked in bold.

RN-F0 RN-F1 RN-F2 HN-F SN-F

UD I I

WriteBackFull

CompDBIDResp

UD->I

CBWrData_UD_PD

WriteNoSnp

CompDBIDRresp

NCBWrData

CBWrData = CopyBackWrData
NCBWrData = NonCopyBackWrData

Figure 5-12 WriteBackFull returning Data Buffer Identifier

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-135
ID061214 Confidential
5 Interconnect Protocol Flows
5.4 Interconnect hazard conditions

5.4 Interconnect hazard conditions

This section lists the responsibilities of the HN-F to handle address hazards among Snoopable transactions and race
conditions. Ordering among Non-snoopable transactions and among Snoopable transactions is described in
Chapter 7 Ordering.

An HN-F orders transactions to the same cache line by sequencing transaction responses and snoop transactions to
the Requesters. As the interconnect is not required to be ordered, the arrival order of these messages, in certain cases,
might not be the same as the order in which they were issued at the HN-F.

5.4.1 At the ICN(HN-F) node

While a Snoop transaction response is pending, the only transaction responses that are permitted to be sent to the
same address are:
• RetryAck for a CopyBack.
• RetryAck and DBIDResp for a WriteUnique.
• RetryAck and, if applicable, a ReadReceipt for a Read request type.
• RetryAck for a Dataless request type.

Once a completion is sent for a transaction, the HN-F must not send a snoop request to the same cache line until it
receives:

• A CompAck for any Read and Dataless requests except for ReadOnce and ReadNoSnp.
For ReadOnce and ReadNoSnp the HN-F must wait till it receives CompAck, if the request has
ExpCompAck asserted, else the interconnect has to wait until it sends a Comp.

• A WriteData response for CopyBack requests.

• A WriteData response and, if applicable, CompAck for WriteUnique.

If a Response message that includes data requires multiple packets or beats of transfers over the interconnect then
receiving or sending the message implies sending or receiving all the packets corresponding to that message. That
is, when a sender starts sending the message it must send all packets of the message without dependence on
completion of any other Request or Response message.

Similarly, a receiver, when it accepts part of the data message, must accept the remaining packets of that message
without any dependence on forward progress of any other request or response message.

When a subsequent action depends upon receiving a data message, the action must not occur until all data packets
are received.

5-136 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.4 Interconnect hazard conditions

5.4.2 Hazard handling examples

The following examples show how various request to request, and request to snoop request hazard conditions are
handled at the HN-F.

Request hazard at HN-F

If more than one request to the same cache line is ready to be processed at the HN-F, then the HN-F can select the
next request in any order, except for when the two requests have ReqOrder asserted and are from the same source,
then the order of processing must match the order of arrival.

Figure 5-13 on page 5-138 shows an example where a ReadShared and a ReadUnique, for the same cache line,
arrive at the HN-F at approximately the same time. The steps required to resolve this hazard are:

1. At time A:
• ReadUnique from RN-F0 arrives and hazards a ReadShared request from RN-F2 for which the HN-F
has already sent snoop requests.
• ReadUnique progress is blocked at the HN-F.

2. At time B:
• The HN-F has completed the ReadShared transaction request from RN-F2.
• The ReadShared transaction is considered to be complete and the HN-F unblocks the ReadUnique
transaction request from RN-F0.

With the exception of ReadNoSnp, the flows will be similar if the two transactions, that Figure 5-13 on page 5-138
shows, are replaced by any Read request type, or Dataless request type:

• A Read transaction request is completed at the HN-F when both of the following are true:
— All CompData is sent and, if applicable, CompAck is received. A CompAck is only required for
transactions that assert ExpCompAck in the original Request message.
— A memory update is completed if required.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-137
ID061214 Confidential
5 Interconnect Protocol Flows
5.4 Interconnect hazard conditions

RN-F0 RN-F1 RN-F2 HN-F SN-F

SC I I
Req1: ReadShared
Req2: ReadUnique
ReadNoSnp
A
Hazard detected
Req2 progress
SnpShared SnpShared blocked

SnpResp_SC
SnpResp_I

CompData_I

CompData_SC
I->SC
CompAck Req2 progress
un-blocked
B

SnpUnique ReadNoSnp
SnpUnique

SnpResp_I SC->I
SnpResp_I

CompData_I

CompData_UC
SC->UC

CompAck

Figure 5-13 Read-Read request hazard example

5-138 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 5 Interconnect Protocol Flows
5.4 Interconnect hazard conditions

Read - CopyBack or Dataless - CopyBack hazard at HN-F

A hazard between a Read or Dataless request and a CopyBack request at the HN-F is treated similarly to the
Read-Read hazard described in Request hazard at HN-F on page 5-137. See also CopyBack-Snoop hazard at RN-F
on page 4-120.

Figure 5-14 on page 5-140 shows the case where a ReadShared and a WriteBack, for the same cache line, arrive at
the HN-F at approximately the same time. The steps required to resolve this hazard are:

1. At time A:
• A WriteBack encounters a hazarding condition at the HN-F. The reason for the hazard is a ReadShared
transaction that is already in progress.
• The hazard detection results in the WriteBack being blocked.
• The ReadShared transaction receives data with the snoop response and needs to update memory in
addition to sending the data to the Requester.

2. At time B:
• The WriteBack is unblocked because the HN-F has sent the Data response to the Requester and a
WriteData response to memory for the ReadShared transaction.

If the ReadShared request reaches the HN-F, after the HN-F has started processing the WriteBack request, then the
ReadShared request will be blocked until completion of the WriteBack request.

A CopyBack request is completed at HN-F when both of the following are true:
• A Data message corresponding to the CopyBack request is received.
• A memory update is completed if required.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 5-139
ID061214 Confidential
5 Interconnect Protocol Flows
5.4 Interconnect hazard conditions

RN-F0 RN-F1 RN-F2 HN-F SN-F

UD I I
Req1: ReadShared
Req2: WriteBack

SnpShared
Hazard detected
UD->SC Req2 progress
blocked

SnpRespData_SC_PD

CompData_SC
WriteNoSnp
I->SC

CompAck
CompDBIDResp

B
CompDBIDResp NCBWrData
SC->I
CopyBackWrData_SC Req2 progress
(PS = SC, NS(implied) = I) un-blocked

PS = PresentState
NS = NextState

Figure 5-14 Read - CopyBack or Dataless - Copyback hazard example

Request-CompAck to HN-F race hazard

After completion, a request might silently evict the cache line from the cache and generate another request to the
same address. For example:

1. The regenerated request reaches the HN-F before the CompAck response associated with the earlier request.

2. The HN-F detects an address hazard and blocks the processing of the new request until the CompAck
response is received.

In such a scenario, upon arrival at HN-F, the CompAck response deallocates the previous request from the HN-F
and unblocks the processing of the new request.

5-140 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 6
Exclusive Accesses

This chapter describes the mechanisms that the architecture includes to support exclusive accesses. It contains the
following sections:
• Overview on page 6-142.
• Exclusive monitors on page 6-143.
• Exclusive transactions on page 6-146.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 6-141
ID061214 Confidential
6 Exclusive Accesses
6.1 Overview

6.1 Overview
The principles of exclusive accesses are that a Logical Processor (LP) performing an exclusive sequence does the
following:
• Performs an Exclusive Load from a location.
• Calculates a value to store to that location.
• Performs an Exclusive Store to the location.

Two different forms of exclusive access are supported:

• Exclusive accesses to a Snoopable memory location.
• Exclusive accesses to a Non-snoopable memory location.

For a Snoopable memory location, if the location is updated since the Exclusive Load, by a different LP, then the
Exclusive Store must fail. In this case, the store does not occur and the LP does not update the value held at the
location.

For a Non-snoopable memory location, if a write transaction, by any LP, has updated the same address location since
the Exclusive Load, then the Exclusive Store must fail. In this case, the store does not occur and the value held at
the location is not updated.

Note
• The term Exclusive Load is used to describe the action of an LP executing an appropriate program instruction
such as LDREX. This action requires:
— Obtaining the data from the location to which it wants to perform an exclusive sequence.
— Indicating that it is starting an exclusive sequence.

• The term Exclusive Load transaction is used to describe a transaction issued on the interface to obtain data
for an Exclusive Load, if the data is not available in the cache at the LP. Not every Exclusive Load requires
an Exclusive Load transaction.

• The term Exclusive Store is used to describe the action of an LP executing an appropriate program instruction
such as STREX. This action requires:
— Determining if the exclusive sequence had passed or failed.
— If appropriate, updating the data at the location.
An Exclusive Store can pass or fail and this result is known to the executing processor. When an Exclusive
Store passes, the data value at the address location is updated. When an Exclusive Store fails, this indicates
that the data value at the address location has not been updated, and the Exclusive sequence must be restarted.

• The term Exclusive Store transaction is used to describe a transaction issued on the interface that might be
required to complete an Exclusive Store. Not every Exclusive Store requires an Exclusive Store transaction.
An Exclusive Store transaction can pass or fail and this result is made known to the LP using the transaction
response.

6-142 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 6 Exclusive Accesses
6.2 Exclusive monitors

6.2 Exclusive monitors

The progress of an exclusive sequence is tracked by an exclusive monitor. The location of the monitor, and the
request type generated to support the exclusive accesses, is dependent on the memory attributes of the address.

6.2.1 Snoopable memory location

For a Snoopable memory location two monitors are defined:

LP monitor Each LP within an RN-F must implement an exclusive monitor that observes the location used by
an exclusive sequence. The LP monitor is set when the LP executes an Exclusive Load. The LP
monitor is reset when either:
• The location is updated by another LP, which is indicated by an invalidating snoop request to
the same address.
• There is a store to that address within the same RN-F.

Note
It is IMPLEMENTATION DEFINED whether or not a non-exclusive store from the same LP resets the
monitor.

PoC monitor An HN-F must implement a PoC monitor that can pass or fail an Exclusive Store transaction. A pass
indicates that the transaction has been propagated to other coherent RN-Fs. A fail indicates that the
transaction has not been propagated to other coherent RN-Fs and therefore the Exclusive Store
cannot pass.
The monitor is used to ensure that an Exclusive Store transaction from an LP is only successful if
that LP could not have received a snoop transaction, relating to an Exclusive Store to the same
address from another LP, after it issued its own Exclusive Store transaction.
The minimum requirement of the PoC monitor is to record when any LP performs a Snoopable
transaction related to an exclusive sequence.
If an LP has performed a transaction related to an Exclusive sequence, and it then performs an
Exclusive Store transaction before a successful Exclusive Store transaction from another LP is
scheduled, then the Exclusive Store transaction must be successful.
The monitor must support the parallel monitoring of all exclusive-capable LPs in the system.
When the HN-F receives a transaction associated with an Exclusive Load or an Exclusive Store, the
monitor registers that the LP is attempting an exclusive sequence.
When the HN-F receives an Exclusive Store transaction:
• If the PoC monitor has registered that the LP is performing an exclusive sequence, that is, it
has not been reset by an Exclusive Store transaction from another LP, then the Exclusive
Store transaction is successful and is permitted to proceed. In such a case, registered attempts
of all other LPs must be reset. This specification recommends, but does not require, that the
PoC monitor for the successful LP is left as registered.
• If the PoC monitor has not registered that the LP is performing an exclusive sequence, that
is, it has been reset by an Exclusive Store from another LP, then the Exclusive Store
transaction is failed and is not permitted to proceed. The monitor must register that the LP is
attempting an exclusive sequence.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 6-143
ID061214 Confidential
6 Exclusive Accesses
6.2 Exclusive monitors

Note
A successful Exclusive Store transaction from an LP does not have to reset that the LP is
performing an exclusive sequence. The LP can continue to perform a sequence of Exclusive
Store transactions, which will all be successful, until another LP performs a successful
Exclusive Store transaction.
From initial system reset, the first LP to perform an Exclusive Store transaction can be
successful, but this specification does not require it. At that point, all other LPs must then
register the start of their exclusive sequence for their Exclusive Store transaction to be
successful.
When an Exclusive Store transaction from one LP passes and the registered attempts of all
other LPs is reset, the other LPs can only register a new exclusive sequence after the
CompAck response is observed for the Exclusive Store transaction that passed.

Note
An LP and PoC monitor pair are required to support an exclusive access to a Snoopable memory location.

6-144 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 6 Exclusive Accesses
6.2 Exclusive monitors

6.2.2 Additional address comparison

The PoC monitor can be enhanced to include some address comparison. A full address comparison is not required
and it is permitted to only record a subset of address bits. This approach reduces the chances of an Exclusive Store
transaction failing because of another LP’s Exclusive Store transaction to a different address location. The number
of bits of address comparison used is IMPLEMENTATION DEFINED.
Where an additional address comparison monitor is used, the monitored address bits are recorded at the start of an
exclusive sequence on either a Load Exclusive or Store Exclusive transaction. It is reset by a successful Exclusive
Store transaction from another LP to a matching address.

A monitor that includes additional address comparison must still include a minimum monitor of a single bit for
every Exclusive-capable LP to ensure forward progress.

An Exclusive Store transaction is permitted to progress if one of the following occurs:

• The address monitor has registered an exclusive sequence for a matching address from the same LP and has
not been reset by an Exclusive Store transaction from a different LP with a matching address.

• The minimum single-bit monitor has been set by an exclusive sequence from the same LP, and it has not been
reset by an Exclusive Store transaction from a different LP to any address.

Note
• The term matching address is used to describe where a monitor only records a subset of address bits. The
address bits that are recorded are identical, but the address bits that are not recorded can be different.

• An implementation does not require an address monitor for each Exclusive-capable LP. Because the address
monitor provides a performance enhancement it is acceptable to have fewer address monitors and for the use
of these to be IMPLEMENTATION DEFINED. For example, additional address monitors can be used on a
first-come first-served basis, or by allocation to particular LPs. Alternatively, a more complex algorithm
might be implemented.

• Additional PoC exclusive monitor functionality can be provided to prevent interference, or denial of service,
caused by one agent in the system issuing a large number of exclusive access transactions. This specification
recommends that Secure exclusive accesses are permitted to make forward progress independently of the
progress of Non-secure accesses.

6.2.3 Non-snoopable memory location

For a Non-snoopable memory location a single monitor is used:

System monitor The System monitor tracks exclusive accesses to a Non-snoopable region. This monitor
type is set by a ReadNoSnp(Excl) transaction and reset by an update to the location by
another LP.
System monitors can be placed at a PoS or at endpoint devices. Potentially, the number of
devices in the system is much larger than the number of PoS and placing System monitors
at a PoS can:
• Reduce System monitor duplication.
• Reduce the time taken for the system to detect failure of an exclusive access.
A System monitor must be located so it can observe all transactions to the monitored
location.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 6-145
ID061214 Confidential
6 Exclusive Accesses
6.3 Exclusive transactions

6.3 Exclusive transactions

The following transaction types support exclusive accesses through an Excl bit:
• Exclusive Load transaction to a Snoopable location:
— ReadClean.
— ReadShared.
• Exclusive Store transaction to a Snoopable location:
— CleanUnique.
• Exclusive Load transaction to a Non-snoopable location:
— ReadNoSnp.
• Exclusive Store transaction to a Non-snoopable location:
— WriteNoSnp.

The communicating node pairs are:

• For Exclusives to a Snoopable location:
— RN-F to ICN(HN-F).
• For Exclusives to a Non-snoopable location:
— RN-F, RN-D, RN-I to ICN(HN-F, HN-I).
— ICN(HN-F) to SN-F.
— ICN(HN-I) to SN-I.

An exclusive transaction must use the correct LPID value, See Logical Processor Identifier on page 2-61.

6.3.1 Responses to exclusive requests

Transaction responses to exclusive requests are similar to the normal responses to reads and writes. However, the
response must also indicate if the exclusive request has passed or failed. The channel RespErr field in the response
is used for this purpose. See RespErr on page 11-223. The RespErr field value of 0b01, Exclusive Okay, indicates a
pass and a RespErr field value of 0b00, Normal Okay, indicates an exclusive access failure.

The Exclusive Okay response must only be given for a transaction that has the Excl attribute set.

Not all memory locations are required to support exclusive accesses. An Exclusive Load transaction to a location
that does not support exclusive accesses must not be given an Exclusive Okay response.

Whether or not an Exclusive Store transaction to a location that does not support exclusive accesses will update that
location is IMPLEMENTATION DEFINED.
This specification recommends that an Exclusive Store transaction is not performed to a location that does not
support exclusive accesses.

Table 6-1 shows the Snoopable attributes of the request, the relevant monitor type and possible reasons for fail
conditions and response requirements.

Table 6-1 Responses to an exclusive access request

Request type Snoopable Monitor type Fail condition Response

ReadNoSnp(Excl) No System Target does not support Target must return a data
exclusive accesses response

WriteNoSnp(Excl) No System Address content modified The Requester must still

complete the write flow by
Address not present due to sending the data message
monitor overflow

Target does not support

exclusive accesses

6-146 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 6 Exclusive Accesses
6.3 Exclusive transactions

Table 6-1 Responses to an exclusive access request (continued)

Request type Snoopable Monitor type Fail condition Response

ReadShared(Excl) Yes LP, PoC Target does not support Target must return a data
ReadClean(Excl) exclusive accesses response

CleanUnique(Excl) Yes LP, PoC Address content modified Target must return a Comp
response
Address not present due to
monitor overflow

Target does not support

exclusive accesses

6.3.2 System responsibilities

A system that implements the CHI protocol has the following responsibilities:

• Should include a monitor per LP for the efficient handling of exclusive accesses.

• Must have a starvation prevention mechanism for all exclusive requests, whether using the monitor
mechanism or some other means.

• This specification recommends that progress on Secure Exclusive requests is independent of progress on
Non-secure Exclusive accesses.

6.3.3 Exclusive accesses to Snoopable locations

This section describes the behavior of an LP when performing exclusive accesses to a Snoopable address location.

Snoopable Exclusive Load

The LP starts an exclusive sequence with an Exclusive Load. The start of the exclusive sequence must set the LP
exclusive monitor.

An LP wanting to perform an exclusive access to a Snoopable location might already hold the cache line in its local
cache:

• If the LP holds the cache line in a Unique state, then it is permitted, but not recommended by this
specification, that it performs an Exclusive Load transaction.

• If the LP holds the cache line in a Shared state, then it is permitted, but not required by this specification, that
it performs an Exclusive Load transaction.

• If the LP does not hold a copy of the cache line, this specification recommends that the LP uses an Exclusive
Load transaction to obtain the cache line, but is permitted to use ReadClean or ReadShared without the Excl
attribute asserted.

Snoopable Exclusive Load to Snoopable Exclusive Store

After the execution of an Exclusive Load an LP will typically calculate a new value to store to the location before
it attempts the Exclusive Store.

It is not required that an LP always completes an exclusive sequence. For example, the value obtained by the
Exclusive Load can indicate that a semaphore is held by another LP and that the value cannot be changed until the
semaphore is released by the other LP. Therefore, a new exclusive sequence can be started with no attempt to
complete the current exclusive sequence.

During the time between the Exclusive Load and the Exclusive Store the LP exclusive monitor must monitor the
location to determine whether another LP might have updated the location.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 6-147
ID061214 Confidential
6 Exclusive Accesses
6.3 Exclusive transactions

Snoopable Exclusive Store

An LP must not permit an Exclusive Store transaction to be in progress at the same time as any transaction that
registers that it is performing an exclusive sequence. The LP must wait for all messages for any such transaction to
be exchanged, or to receive a RetryAck response, before issuing an Exclusive Store transaction. The transactions
that register that an LP is performing an exclusive sequence are:
• Exclusive Load transactions to any location.
• Exclusive Store transactions to any location.

When an LP executes an Exclusive Store the following behavior is required:

• If the LP exclusive monitor has been reset the Exclusive Store must fail and the LP must not issue an
Exclusive Store transaction. The LP must restart the exclusive sequence.

Note
When the LP monitor has been reset, not issuing a transaction for an Exclusive Store that must eventually fail
avoids unnecessary invalidation of other copies of the cache line.

• If the cache line is held in a Unique state and the LP exclusive monitor is set then the Exclusive Store has
passed and it can update the location without issuing a transaction.

• If the cache line is held in a Shared state and the LP exclusive monitor is set then the LP must issue an
Exclusive Store transaction. A CleanUnique transaction with the Excl attribute asserted must be used. The
LP exclusive monitor must continue to operate and check that the cache line is not updated while the
CleanUnique transaction is in progress.
The transaction will receive a Normal Okay or an Exclusive Okay response.
If the transaction receives an Exclusive Okay response, then this indicates that the transaction has passed and
has completed invalidating all other copies of the cache line. After an exclusive transaction completes with
an Exclusive Okay response the LP must again check the LP exclusive monitor:
— If the LP exclusive monitor is set then the Exclusive Store has passed and the update is performed.
— If the LP exclusive monitor is not set, it indicates that an update to the cache line has occurred between
the point that the Exclusive Store transaction was issued and the point that it completed. The Exclusive
Store must fail and the exclusive sequence must be restarted.
— If the LP has not been able to track the exclusive nature of the cache line, because the cache line has
been evicted, then the Exclusive Store must fail and the exclusive sequence must be restarted.
If the Exclusive Store transaction receives a Normal Okay response then this indicates another LP has been
permitted to progress a transaction associated with an Exclusive Store. The transaction associated with the
Exclusive Store, from this LP, has failed and has not propagated to other LPs in the system. When an
Exclusive Store transaction completes with a Normal Okay response the options are:
— The LP can fail the Exclusive Store and restart the exclusive sequence with or without checking the
state of the cache line when the access completed.
— The LP can check the LP exclusive monitor, and if the LP exclusive monitor has been reset, then the
LP must fail the Exclusive Store and restart the exclusive sequence.
— The LP can check the LP exclusive monitor, and if the LP exclusive monitor is set, then the LP can
repeat the Exclusive Store transaction.

6-148 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 6 Exclusive Accesses
6.3 Exclusive transactions

Exclusive accesses to Non-snoopable locations

The following restrictions apply to exclusive accesses to Non-snoopable locations:

• The address of an exclusive access must be aligned to the total number of bytes in the transaction.

• The number of bytes to be transferred in an exclusive access must be a legal data transfer size, that is, 1, 2,
4, 8, 16, 32, or 64 bytes.

Failure to observe these restrictions results in behavior that is UNPREDICTABLE.

For exclusive Read and Write transactions to be considered a pair, the following criteria must apply:

• The addresses of the exclusive read and the exclusive write must be identical.

• The value of the control signals, that is MemAttr and SnpAttr of the exclusive read and the exclusive write
transaction, must be identical.

• The data size in the exclusive read and the exclusive write must be identical.

• The LPID value of the exclusive read must match the LPID value of the exclusive write transaction.

The minimum number of bytes to be monitored during an exclusive operation is defined by the transaction size. The
System monitor can monitor a larger number of bytes, up to 64, which is the maximum size of an exclusive access.
However, this can result in a successful exclusive access being indicated as failing because a neighboring byte was
updated while the exclusive access was in progress.

Multiple exclusive transactions to Non-snoopable memory locations, either read or write, to the same or different
addresses, from the same LP must not be outstanding at the same time.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 6-149
ID061214 Confidential
6 Exclusive Accesses
6.3 Exclusive transactions

6-150 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 7
Ordering

This chapter describes the mechanisms that the protocol includes to support system ordering requirements. It
contains the following sections:
• Multi-copy atomicity on page 7-152.
• Completion Response and Ordering on page 7-153.
• Completion acknowledgement on page 7-154.
• Transaction ordering on page 7-156.
• Barriers on page 7-161.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-151
ID061214 Confidential
7 Ordering
7.1 Multi-copy atomicity

7.1 Multi-copy atomicity

This specification requires a multi-copy atomic architecture. All compliant components must ensure that all
write-type requests are multi-copy atomic. A write is defined as multi-copy atomic if both of the following
conditions are true:

• All writes to the same location are serialized, that is, they are observed in the same order by all Requesters,
although some Requesters might not observe all of the writes.

• A read of a location does not return the value of a write until all Requesters observe that write.

In this specification, two addresses are considered to be the same with respect to coherence, observability, and
hazarding if their cache line addresses and NS attribute are the same.

7-152 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.2 Completion Response and Ordering

7.2 Completion Response and Ordering

To guarantee the ordering of a transaction with respect to later transactions, either from the same agent or from
another agent, the Comp or CompData response is used as follows:

• For a Read transaction to a Non-cacheable or Device location, a CompData response guarantees that the
transaction is observable to a later transaction from any agent to the same endpoint address range. The size
of the endpoint address range is IMPLEMENTATION DEFINED.

• For a Read transaction to a Cacheable location, a CompData response guarantees that the transaction is
observable to a later transaction from any agent to the same location.

• For a Dataless transaction that is only permitted to a Cacheable memory location, a Comp response
guarantees that the transaction is observable to a later transaction from any agent to the same memory
location.

• For a Write transaction with Early Write Acknowledge (EWA) de-asserted, to a Non-cacheable or Device
location, a Comp response guarantees that the transaction is observable to a later transaction from any agent
to the same endpoint address range. The size of the endpoint address range is IMPLEMENTATION DEFINED.

• For a Write transaction with EWA asserted, to a Non-cacheable or Device location, a Comp response
guarantees that the transaction is observable to a later transaction from any agent to the same location.
If the handling of barriers at source is required, see Barrier transaction flow on page 7-163, then the response
must also guarantee that the transaction is observable to a later transaction from any agent to the same
endpoint address range.

• For a Write transaction to a Cacheable location, a Comp response guarantees that the transaction is
observable to a later transaction from any agent to the same location.

Note
• The size of an endpoint address range is IMPLEMENTATION DEFINED. Typically, this is:
— The size of a peripheral device, for a region used for peripherals.
— The size of a cache line, for a region used for memory.

• A Cacheable location can be determined by the assertion of the MemAttr[2] Cacheable bit in the request. A
Non-cacheable or Device location can be determined by the de-assertion of the MemAttr[2] Cacheable bit
in the request.

If the Comp response for a Write transaction, with EWA asserted, to a Non-cacheable or Device location does not
guarantee that the transaction is observable to a later transaction from any agent to the same endpoint address range,
then one of the following techniques can be used to ensure ordering to the same endpoint address range:

• If the Write transaction has an Endpoint Order requirement, then a later transaction from the same agent that
also has an Endpoint Order requirement and is to the same endpoint address range will be ordered. See
Transaction ordering on page 7-156.

• A Barrier transaction ensures the ordering with respect to a later transaction from any agent to any location
within the same endpoint address range. See Barrier transaction flow on page 7-163.

• The CompData response of a later Read transaction to the same location ensures the ordering of the Write
transaction with respect to a later transaction from any agent to any location within the same endpoint address
range.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-153
ID061214 Confidential
7 Ordering
7.3 Completion acknowledgement

7.3 Completion acknowledgement

The relative ordering of transactions issued by a Requester, and Snoop transactions caused by transactions from
different Requesters, is controlled by the use of a Completion Acknowledgment response. This ensures that a Snoop
transaction that is ordered after the transaction from the Requester is guaranteed to be received after the transaction
response.

The sequencing of the completion of a transaction and the sending of CompAck is as follows:
1. An RN-F sends a CompAck after receiving Comp or CompData.
2. An HN-F waits for CompAck before sending a subsequent snoop to the same address.

This sequence guarantees that an RN-F receives completion for a transaction and a snoop to the same cache line in
the same order as they are sent from an HN-F. This ensures transactions to the same cache line are observed in the
correct order.

The use of CompAck for a transaction is determined by the Requester setting the ExpCompAck field in the original
request. The rules for an RN setting the ExpCompAck field and generating a CompAck response are as follows:

• An RN-F must include a CompAck response in all Read and Dataless transactions except ReadNoSnp,
ReadOnce, and Evict.

• Although not required, an RN-F is permitted to include a CompAck response in ReadNoSnp and ReadOnce
transactions.

• An RN-F must not include a CompAck response in Evict transactions.

• An RN-I or RN-D is permitted, but not required, to include a CompAck response in Read and Dataless
transactions.

• For Write transactions, CompAck can only be used for WriteUnique transactions. See Streaming Ordered
WriteUnique transactions on page 7-159.

For transactions between an RN and an HN, where the HN is the Completer, the HN must support the use of
CompAck for all transactions that are required or permitted to use CompAck.

An SN is not required to support the use of CompAck.

A Requester, such as an HN-F or HN-I that communicates with an SN-F or SN-I respectively, must not send a
CompAck response.

Table 7-1 shows the request types that require a CompAck response, and the corresponding Requester types that are
required to provide that response.

Table 7-1 Requester CompAck requirement

Request type CompAck Required

RN-F RN-D, RN-I

ReadNoSnp Optional Optional

ReadOnce Optional Optional

ReadClean Yes -

ReadShared Yes -

ReadUnique Yes -

CleanUnique Yes -

MakeUnique Yes -

CleanShared Yes Optional

7-154 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.3 Completion acknowledgement

Table 7-1 Requester CompAck requirement (continued)

Request type CompAck Required

RN-F RN-D, RN-I

CleanInvalid Yes Optional

MakeInvalid Yes Optional

WriteBack No -

WriteClean No -

WriteUnique Optional Optional

Evict No -

WriteEvictFull No -

WriteNoSnp No No

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-155
ID061214 Confidential
7 Ordering
7.4 Transaction ordering

7.4 Transaction ordering

In addition to using a Comp response to order a sequence of requests from a Requester, this specification also
defines mechanisms for Request Order between an RN, HN pair and a HN-I, SN-I pair. These mechanisms do not
apply for transactions between an HN-F, SN-F pair.

Requester Order between an RN, HN pair and a HN-I, SN-I pair is supported by the Order field in a request. The
Order field indicates that the transaction requires one of the following forms of ordering:

Request Order This guarantees the order of multiple transactions, from the same agent, to the same address
location. For WriteNoSnp transactions this further guarantees order of transactions to the
same address location from any agent.

Endpoint Order This guarantees the order of multiple transactions, from the same agent, to the same
endpoint address range. This guarantee also includes the guarantee of Request Order.

Ordered Write Observation

This guarantees the observation order by other agents in the system, for a sequence of write
transactions from a single agent.

Table 7-2 shows the Order field encodings.

Table 7-2 Order field encodings

Order[1:0] Description

0b00 No ordering required

0b01 Reserved

0b10 Request Order/Ordered Write Observation required

0b11 Endpoint Order required, which includes Request Order

7.4.1 Ordering requirements

The Order field must only be set to a non-zero value for the following transactions:
• ReadNoSnp.
• ReadOnce.
• WriteNoSnp.
• WriteUnique.

When a ReadNoSnp or ReadOnce transaction requires Request Order or Endpoint Order:

• The RN requires a ReadReceipt to determine when it can send the next ordered request.

• At the Completer a ReadReceipt means the request has reached the next ordering point that will maintain
requests in the order they were received:
— For requests that require Request Order it will maintain order between requests to the same address
from the same source.
— For requests that require Endpoint Order it will maintain order between requests to the same endpoint
address range from the same source.

When a WriteNoSnp transaction requires Request Order or Endpoint Order:

• The RN requires a DBIDResp to determine when it can send the next ordered request.

• The Completer sending a DBIDResp response means that a data buffer is available, and that the write request
has reached a PoS that will maintain requests in the order they were received:
— For requests that require Request Order it will maintain order between requests to the same address
from the same source.

7-156 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.4 Transaction ordering

— For requests that require Endpoint Order it will maintain order between requests to the same endpoint
address range from the same source.
— In addition, for requests that require Request Order or Endpoint Order, it will also maintain order
between all requests to the same address, from any source.

When a WriteUnique transaction requires Ordered Write Observation:

• The RN requires a DBIDResp.

• The Completer is a PoS. A PoS sending DBIDResp means:

— A data buffer is available.
— The PoS guarantees that the completion of the coherence action on this write does not depend on
completion of the coherence action on a subsequent write that requires Ordered Write Observation.
— The write is not made visible until CompAck is received.

Table 7-3 shows the ordering guarantee that is obtained for different combinations of transactions that require order.

The transactions that Table 7-3 shows as First Transaction and Second Transaction are from the same Requester.

When transactions from the same Requester specify a different ordering requirement, the ordering guarantee that is
provided is the least restrictive of the two.

Table 7-3 Order between transactions

First Transaction Second Transaction Order Guarantee

No ordering No ordering No ordering

No ordering Request Order No ordering

No ordering Endpoint Order No ordering

Request Order No ordering No ordering

Request Order Request Order Request Order

Request Order Endpoint Order Request Order

Endpoint Order No ordering No ordering

Endpoint Order Request Order Request Order

Endpoint Order Endpoint Order Endpoint Order

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-157
ID061214 Confidential
7 Ordering
7.4 Transaction ordering

Read Request Order example

Figure 7-1 shows the request ordering of three read requests.

RN HN

ReadNoSnp-1
Request
accepted

ReadReceipt-1
ReadNoSnp-2 is sent
after ReadReceipt-1
is received
ReadNoSnp-2

Request gets
a Retry
ReadNoSnp-3 waits response
for ReadNoSnp-2 to RetryAck-2
make progress

PCrdGrant

ReadNoSnp-2 waits
for a CreditGrant

ReadNoSnp-2
ReadNoSnp-3 is sent
after Read Receipt-2
ReadReceipt-2
is received
ReadNoSnp-3

ReadReceipt-3

CompData_I-3

Figure 7-1 Series of ordered read requests

Three ordered requests are sent from RN to HN as follows:

1. RN sends the ReadNoSnp-1 request to HN.
2. HN accepts the request and returns the ReadReceipt-1 response to RN.
3. After the ReadReceipt-1 response is received, RN sends the ReadNoSnp-2 request to HN.
4. HN cannot immediately accept the ReadNoSnp-2 request and returns the RetryAck-2 response to RN.
5. RN must now wait for a PCrdGrant to be sent from HN before resending the ReadNoSnp-2 request. RN does
not send ReadNoSnp-3 at this point. as it wants to order ReadNoSnp-3 behind ReadNoSnp-2. This ordering
requires that ReadNoSnp-2 must be accepted at HN before ReadNoSnp-3 is sent to HN.
6. After receipt of an appropriate PCrdGrant, RN resends the ReadNoSnp-2 request.
7. HN accepts the request and returns a ReadReceipt-2 response to RN.
8. After receipt of the ReadReceipt-2 response, RN sends the ReadNoSnp-3 request to HN.
9. HN accepts the request and returns the ReadReceipt-3 response to RN.
10. HN completes the Request transactions by sending a combined Completion and Data response to the RN for
each request.

7-158 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.4 Transaction ordering

Note
Figure 7-1 on page 7-158 shows a single ordered stream of three reads from RN. However, an RN can have multiple
streams of reads, in which case requests must be ordered within a stream, but ordering dependency does not exist
between streams. One example of this is when the streams are from different threads within the RN, in which case,
the RN waits for the ReadReceipt of the previous request from the same stream only before sending out the next
ordered request from that stream.

7.4.2 CopyBack Request Order

An RN-F must wait for the CompDBIDResp response to be received for an outstanding CopyBack transaction
before issuing another request to the same cache line.

7.4.3 Streaming Ordered WriteUnique transactions

If a Requester requires a sequence of WriteUnique transactions to be observed in the same order as they are issued,
then the Requester can wait for completion for a WriteUnique before issuing the next WriteUnique in the sequence.
Such an observation ordering is typically termed Ordered Write Observation. This specification provides a
mechanism termed Streaming Ordered WriteUniques to more efficiently stream such ordered WriteUnique
transactions.

The Streaming Ordered WriteUniques mechanism relies on the use of the Ordered Write Observation ordering
requirement and CompAck. Responsibilities of Requesters and HN-F when utilizing the Streaming Ordered
WriteUnique solution are:

• The Requester must set the Order field to require Ordered Write Observation and ExpCompAck on the
WriteUnique request.

• The Ordered Write Observation requirement in a WriteUnique request indicates to the HN-F that the
completion of coherence action on this write must not depend on completion of coherence action on a
subsequent write.

• The Requester must wait for DBIDResp for a WriteUnique transaction before sending the next WriteUnique
request.

• The Requester must send a CompAck response after receiving Comp for the corresponding WriteUnique, as
well as Comp responses for all earlier ordered WriteUniques.

Note
Waiting to send CompAck until all prior ordered WriteUniques have received their Comp responses ensures
that they have completed their operations at their respective HN-Fs and any Requester observing the
WriteUnique for which CompAck is sent will also observe all prior ordered WriteUniques.

• HN-F must wait for a CompAck response from RN before de-allocating a WriteUnique transaction and
making the write visible to other observers.

Optimized Streaming Ordered WriteUniques

The Streaming Ordered WriteUniques mechanism can be further optimized. If a previously sent WriteUnique is to
a different target, then the Requester does not need to wait for the DBIDResp for the request before sending the next
ordered WriteUnique. However, if the interconnect can remap the TgtID, then the Requester must presume that all
WriteUniques are targeting the same HN-F and must not use the optimized version of the Streaming Ordered
WriteUniques flow.

An implementation using an optimized or non-optimized Streaming Ordered WriteUniques solution must avoid
deadlock and livelock situations.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-159
ID061214 Confidential
7 Ordering
7.4 Transaction ordering

Note
A technique for avoiding resource related deadlock or livelock issues is to limit Streaming Ordered WriteUniques
optimization to one Requester in the system. All other Requesters in the system can use the Streaming Ordered
WriteUniques solution without the optimization.

In a typical system, the optimized Streaming Ordered WriteUniques solution is most beneficial to an RN-I that is a
conduit for PCIe style, non-relaxed order, Snoopable writes. In most systems, one RN-I hosting this type of PCIe
traffic is adequate.

Figure 7-2 shows a typical transaction flow in which an RN-I uses Streaming Ordered WriteUniques. This flow
prevents a read acquiring the new value of Write-B before Write-A has completed.

Note
For clarity, in Figure 7-2 the Write-B DBIDResp and the NCBWrData flow is omitted.

RN-F1 RN-F2 HN-F RN-I

I I I

WriteUnique-A Request B is sent

after receiving
SnpCleanInvalid-A DBIDResp-A DBIDResp for
request A

SnpResp_I-A NCBWrData-A

WriteUnique-B

SnpCleanInvalid-A
SnpCleanInvalid-B

SnpCleanInvalid-B
SnpResp_I-B

SnpResp_I-A
SnpResp_I-B

Comp-B

Comp-A CompAck for B is

not sent until the
Comp for A is
CompAck-A received

CompAck-B

Figure 7-2 Streaming Ordered WriteUniques transaction flow

7-160 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.5 Barriers

7.5 Barriers
Barriers are an ordering mechanism for use with a weakly ordered memory model. Barriers can be used to provide
order between groups of memory transactions, and to ensure ordering of endpoint completion for some classes of
operations. Endpoint for an address in this specification is defined as a peripheral or memory.

Barrier transactions are only used to ensure ordering of Normal Non-cacheable, and Device type transactions. It is
the responsibility of the RN to ensure the required observation of Cacheable transactions, by waiting for the
appropriate transaction response.

A barrier guarantees that all Normal Non-cacheable, and Device type Write transactions targeting an HN-I, that are
issued before the barrier, will reach a single endpoint before any Normal Non-cacheable, or Device type transactions
to the same endpoint that are issued by any agent after the barrier completion. In order to guarantee this ordering a
barrier might need to be propagated into the system beyond the CHI interconnect.

In this specification, barriers are supported by two transaction types:

EOBarrier Endpoint Order Barrier.

ECBarrier Endpoint Completion Barrier.

This specification does not require the interconnect to handle the two barrier transaction types in exactly in the same
manner provided that the interconnect provides the guarantees required.

Note
An RN might prefer to track its original barrier intent by mapping memory barriers and synchronization barriers to
EOBarrier and ECBarrier transactions respectively.

7.5.1 RN requirements
The responsibilities of an RN that issues barrier requests are:

• An RN must wait until all Normal Non-cacheable writes, and all Device type writes, that are targeting an
HN-I, have received a completion response before issuing an EOBarrier or an ECBarrier request. An RN in
a system that cannot guarantee that the TgtID will not be re-assigned by the interconnect must presume that
the potential target of any Normal Non-cacheable, and Device memory request it generates is to an HN-I.

• An RN must send a transaction that is required to be ordered by the barrier only after:
— The barrier response is received.
— Comp responses are received for all read requests that are before the barrier.
— Comp responses are received for all Non-snoopable Cacheable Write Requests that are before the
barrier.
— Comp responses are received for all write requests targeting an HN-F that are before the barrier. If it
cannot be guaranteed that the TgtID will not be remapped then the RN must presume that all write
requests are targeting an HN-F.

• This specification recommends that an RN only issues an EOBarrier or ECBarrier if it has issued a Normal
Non-cacheable, or Device type memory write request since previously completing an EOBarrier or
ECBarrier.

Note
This is not a strict requirement, as it is functionally correct for an RN to issue more barriers than are required.

• An RN is not required to issue barriers if a completion response for a write request targeting an HN-I
guarantees that requests from any source received, after the write completion, will be ordered behind those
writes to the same endpoint address range.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-161
ID061214 Confidential
7 Ordering
7.5 Barriers

7.5.2 HN-I requirements

An HN-I that receives a barrier can provide the required barrier guarantees as follows:

1. The HN-I marks all writes received before the barrier where the writes have the same SrcID and LPID as the
barrier.

2. The HN-I can then handle the barrier using one of the following methods:
• Respond then track:
1. Responds to the barrier with a barrier completion.
2. Reads and writes requests from any agent that are to the same endpoint, as the marked writes
are ordered with respect to those writes.
• Track then respond:
1. The HN-I receives a downstream completion response for all the marked writes.
2. The HN-I sends a barrier completion without having to hazard and block any requests.

Note
• It is acceptable for an HN-I to handle a barrier in either manner. In some circumstances, track then respond
might be the preferred option. In this case, the barrier is not required to block any transactions in the
interconnect and does not affect requests with a different SrcID.

• A barrier might need to be propagated downstream of the HN-I if write completions from downstream do not
provide the guarantees required by a barrier.

7.5.3 Supported barrier functionality

The barrier functionality supported is:

• The combination of the RN requirements, described in RN requirements on page 7-161, and the functionality
of a barrier at the HN-I, described in HN-I requirements, are sufficient to meet the requirements of a memory
barrier within an RN that is used to establish an order of completion at a single endpoint between Normal
Non-cacheable or Device type memory operations from that RN, that precede the memory barrier, and
Normal Non-cacheable or Device type memory operations from that RN, that follow the memory barrier.

• The combination of the RN requirements described in RN requirements on page 7-161 and the functionality
of a barrier at the HN-I, described in HN-I requirements, are also sufficient to meet the requirements of a
synchronization barrier within an RN that is used to guarantee the following:
— All Device endpoint ordered and non-EWA memory operations from that RN that precede the
synchronization barrier and target an HN-I, have reached their respective endpoints prior to the
completion of the barrier.
— All memory bound requests from that RN that precede a DVMOp(Sync) snoop request have reached,
or appear to have reached, their respective endpoints, have returned a completion response, and have
been applied at the target as required by the DVMOp, prior to responding to the DVMOp(Sync).

7-162 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 7 Ordering
7.5 Barriers

7.5.4 Barrier transaction flow

Figure 7-3 shows the flow for an EOBarrier with the respond and track method. The steps are as follows:

1. RN1 has an EOBarrier to send.

2. RN1 waits for all Normal Non-cacheable, and Device type memory write transactions, prior to the barrier, to
receive completion responses.

3. RN1 sends the EOBarrier request to MN.

4. MN forwards the barrier request to all the HN-I nodes in the system. In this example there are two HN-I
nodes, HN-I0. and HN-I1.

5. HN-Is set markers in the transaction queue, marking all the writes received from the same SrcID as the barrier
and return a completion to the MN.

6. MN waits for Comp responses from all HN-I nodes before sending a consolidated Comp message to RN1

RN1 MN HN-I0 HN-I1

Wait for all Normal

Non-cacheable, and
Device write
transactions, before
the barrier, to
receive completions

EOBarrier

EOBarrier EOBarrier

Guarantees that all

requests received later
from any source will be
ordered to endpoint behind
writes received from the
same SrcID as the barrier

Comp

Comp

Comp

Figure 7-3 Barrier transaction flow

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 7-163
ID061214 Confidential
7 Ordering
7.5 Barriers

7.5.5 Optional barrier support

An implementation can include the following optional configuration interface signals, or bits, to help decide if a
barrier should be issued from an RN:

• An HN-I implementation configuration pin or bit to force write Comp responses to be given only when
barrier guarantees can be provided. If the interconnect downstream of the HNI cannot provide sufficient
ordering guarantees, then this might require early write completions from the HN-I to be disabled.

• An RN configuration pin or bit to force barriers to be handled at source and not be issued into the system.

When an HN-I’s early write acknowledgement is permitted, and the HN-I cannot provide the guarantees required
by a barrier, the RN configuration pin or bit that disables the issue of barriers into the system must not be asserted.

7-164 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 8
DVM Operations

This chapter describes Distributed Virtual Memory (DVM) operations that the protocol uses to manage virtual
memory. It contains the following sections:
• DVM transaction flow on page 8-166.
• DVM Operation types on page 8-174.
• DVM Operations on page 8-177.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-165
ID061214 Confidential
8 DVM Operations
8.1 DVM transaction flow

8.1 DVM transaction flow

All DVM transactions have similar requirements and are mapped to a single flow. The following sections show the
Non-sync and Sync type DVM transaction requirements:
• Non-sync type DVM transaction flow.
• Sync type DVM transaction flow on page 8-168.
• Flow control on page 8-169.
• DVMOp field value restrictions on page 8-170.
• Field value requirements on page 8-173.

8.1.1 Non-sync type DVM transaction flow

Figure 8-1 shows the steps in a Non-sync type DVM transaction.

RN-F0 Core-1 RN-F1 Core-2 RN-F2 MN

DVMOp(Non-sync)

DBIDResp

NCBWrData

SnpDVMOp_P1
SnpDVMOp_P1
Snoop sent SnpDVMOp_P2
to core SnpDVMOp_P2

SnpResp_I

SnpResp_I

DVMOp(Sync) can only

be sent after all prior
DVMOp transactions
receive Comp responses. Comp

NCBWrData = NonCopyBackWrData

Figure 8-1 Non-sync type DVM transaction flow

8-166 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.1 DVM transaction flow

The required steps that Figure 8-1 on page 8-166 shows are:

1. RN-F0 sends a DVMOp(Non-sync) to the MN using the appropriate write semantics for the DVMOp type.

2. The MN accepts the DVMOp(Non-sync) request and provides a DBIDResp response.

3. The RN-F0 sends an 8-byte data packet on the data channel.

4. The MN broadcasts the SnpDVMOp snoop request to all the RN-F and RN-D nodes in the system. The
SnpDVMOp is sent on the snoop channel, and requires two snoop requests. The two parts of the SnpDVMOp
are labeled by the suffix _P1 and _P2 respectively.

Note
• Both parts of the message must carry the same Transaction ID (TxnID).
• RN must have resources available to accept the SnpDVMOp. See Flow control on page 8-169.

5. After forwarding the required operation, each recipient of the SnpDVMOp sends a single SnpResp response
to the MN.

Note
Sending of a SnpResp implies that the target RN has forwarded the SnpDVMOp to the required RN structures
and has freed up the resources needed to accept another DVM operation. It does not imply that the requested
DVM operation has completed. See Sync type DVM transaction flow on page 8-168.

6. After receiving all the SnpResp responses, the MN sends a Comp response to the requesting node.

Note
DBIDResp and Comp responses cannot be opportunistically combined for DVMOps, not even in the case
when an MN might have the opportunity to combine the two responses after receiving DVMOp, it has
determined that SnpDVMOps do not need to be sent, and it is ready to respond with Comp before DBIDResp
has been sent.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-167
ID061214 Confidential
8 DVM Operations
8.1 DVM transaction flow

8.1.2 Sync type DVM transaction flow

Figure 8-2 shows the flow in a Sync type DVM transaction.

RN-F0 Core-1 RN-F1 MN

DVMOp(Sync)

DBIDResp

NCBWrData

SnpDVMOp_P1

SnpDVMOp_P2

SnpResp only sent SnpResp_I

after all DVM related
operations are
complete in the core

Comp

NCBWrData = NonCopyBackWrData

Figure 8-2 Sync type DVM transaction flow

8-168 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.1 DVM transaction flow

The required steps that Figure 8-2 on page 8-168 shows are:

1. RN-F0 sends a DVMOp(Sync) to the MN.

Note
All previous DVMOp requests whose completion needs to be guaranteed by the DVMOp(Sync) must have
received a Comp response before the RN can send a DVMOp(Sync).

2. The MN accepts the DVMOp(Sync) request and sends a DBIDResp response to the Requester.

3. The RN-F0 sends an 8-byte data packet on the data channel.

4. The MN sends the SnpDVMOp to RN-F1. The SnpDVMOp is sent on the snoop channel, and requires two
snoop requests. The two parts of a SnpDVMOp are labeled by the suffix _P1 and _P2 respectively.

5. After completing the DVM Sync operation, RN-F1 sends a SnpResp response to the MN.

Note
Sending of a SnpResp implies that all DVM related operations have completed at the RN structures and the
target RN has freed up the resources needed to accept another SnpDVMOp.

6. After receiving the SnpResp, the MN sends a Comp response to RN-F0.

8.1.3 Flow control

DVMOp request flow control:

• A DVMOp can receive a RetryAck response from an MN.

• A DVMOp that receives a RetryAck response must wait for a PCrdGrant response from the MN that has the
appropriate PCrdType.

• All previous DVMOp requests whose completion needs to be guaranteed by the DVMOp(Sync) must have
received a Comp response before the RN can send the DVMOp(Sync).

• It is permitted to overlap a DVMOp(Non-Sync) and a DVMOp(Sync), from the same RN, if the
DVMOp(Sync) is not required to guarantee completion of the DMVOp(Non-Sync).

SnpDVMOp flow control:

• Each SnpDVMOp transaction requires two SnpDVMOp request packets.

• Both SnpDVMOp request packets corresponding to a single transaction must use the same TxnID.

• The two SnpDVMOp request packets corresponding to a single transaction can be sent or received in any
order.

• Multiple SnpDVMOp(Non-sync) transactions can be outstanding from an MN.

• Only one SnpDVMOp(Sync) transaction can be outstanding from an MN to an RN.

• To prevent deadlocks, due to the two part SnpDVMOp requests that uses the snoop channel, a SnpDVMOp
transaction must only be sent when the receiving RN has pre-allocated resources to accept both parts of the
SnpDVMOp transaction.

• An RN must provide a response to a SnpDVMOp transaction only after it has received both SnpDVMOp
request packets corresponding to that transaction.

• An RN must provide a response to a SnpDVMOp only when it can accept a further SnpDVMOp from an MN.

• Each RN-F and RN-D in the system specifies the number of SnpDVMOp transactions it can accept
concurrently.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-169
ID061214 Confidential
8 DVM Operations
8.1 DVM transaction flow

• Each RN-F and RN-D in the system must be able to accept at least one SnpDVMOp(Non-Sync) transaction
in addition to a SnpDVMOp(Sync) transaction.

• The minimum number of SnpDVMOp transactions that must be accepted concurrently is two. This is the
default number for RNs that do not specify a number.

8.1.4 DVMOp field value restrictions

Table 8-1 shows the Request, Data, Snoop, and Response message field value restrictions during a DVMOp
transaction.

Table 8-1 DVMOp transaction field value restrictions

Message type Field Restriction

Request QoS None. Can be any value.

TgtID Expected to be node ID of MN. Can be remapped to correct TgtID by the

interconnect.

SrcID Source ID of the Requester that initiated the DVM message.

TxnID An ID generated by the Requester. Must follow the same rules as any other
transaction.

Opcode Must be DVMOp.

Size Must be 8-byte.

Addr See DVM Operations on page 8-177.

NS Must be zero.

LikelyShared Must be zero.

AllowRetry Can be any value, because a DVMOp can be given a Retry.

Order Must be zero.

PCrdType Must be zero if AllowRetry is asserted, otherwise the credit type value.

Allocate Must be zero.

Cacheable Must be zero.

Device Must be zero.

EWA Must be zero.

SnpAttr Must be 0b00.

LPID None. Don’t care.

Excl Must be zero.

ExpCompAck Must be zero.

RSVDC None. Don’t care.

8-170 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.1 DVM transaction flow

Table 8-1 DVMOp transaction field value restrictions (continued)

Message type Field Restriction

Data QoS None. Can be any value.

TgtID Must be the same as SrcID returned in the DBIDResp response.

SrcID Must be ID of the original Requester.

TxnID Must be the same as DBID of the DBIDResp response.

Opcode Must be NonCopyBackWriteData.

RespErr Must be 0b00.

Resp Must be 0b000.

DBID None. Don’t care.

CCID Must be 0b00 or Addr[5:4].

DataID Must be 0b00 or Addr[5:4].

BE Only BE[7:0] must be asserted.

Data Unused bits must be zero for Data[63:0] and Data[n:64] = Don’t care.

SnpDVMOp QoS None. Can be any value.

SrcID Must be node ID of MN.

TxnID An ID generated by MN.

Opcode Must be SnpDVMOp.

Addr[43:3] See DVM Operations on page 8-177.

NS Must be zero.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-171
ID061214 Confidential
8 DVM Operations
8.1 DVM transaction flow

Table 8-1 DVMOp transaction field value restrictions (continued)

Message type Field Restriction

Response RetryAck QoS None. Can be any value.

TgtID Must be ID of the original Requester.

SrcID Must be ID of the MN that is handling DVMs.

TxnID Must match TxnID of the original request.

Opcode Must be RetryAck.

RespErr Must be 0b00.

Resp Must be 0b000.

DBID None. Don’t care.

PCrdType None. Can be any value.

DBIDResp QoS None. Can be any value.

TgtID Must be ID of the original Requester.

SrcID Must be ID of the MN that is handling DVMs.

TxnID Must match TxnID of the original request.

Opcode Must be DBIDResp.

RespErr Must be 0b00.

Resp Must be 0b000.

DBID Generated by the MN that is handling DVMOps.

PCrdType Must be 0b00.

SnpResp QoS None. Can be any value.

TgtID Must be ID of the MN that is handling DVMOps.

SrcID Must be ID of the node that is responding to the snoop.

TxnID Must match the TxnID of the SnpDVMOp snoop request.

Opcode Must be SnpResp.

RespErr Must be 0b00 or 0b11.

Resp Must be 0b000.

DBID None. Don’t care.

PCrdType Must be 0b00.

Comp QoS None. Can be any value.

TgtID Must be ID of the original Requester

SrcID Must be ID of the MN that is handling DVMs.

TxnID Must match TxnID of the original request.

Opcode Must be Comp.

8-172 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.1 DVM transaction flow

Table 8-1 DVMOp transaction field value restrictions (continued)

Message type Field Restriction

Response Comp RespErr Must be 0b00 or 0b11.

Resp Must be 0b000.

DBID Generated by the MN that is handling DVMs.

PCrdType Must be 0b00.

8.1.5 Field value requirements

Both SnpDVMOp request packets, corresponding to a single DVMOp, must have the same value in the following
fields:
• TxnID
• Opcode
• SrcID
• TgtID

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-173
ID061214 Confidential
8 DVM Operations
8.2 DVM Operation types

8.2 DVM Operation types

The following DVM Operations are supported:
• TLB Invalidate.
• Branch Predictor Invalidate.
• Instruction Cache Invalidate:
— Physical address invalidate.
— Virtual address invalidate.
• Synchronization.

8.2.1 DVMOp payload

The payload of a DVM operation from the RN to the MN is distributed within:
• The address field in the DVM request from the RN.
• The lower 8 bytes of write data in the NonCopyBackWrData packet.
The payload of a DVM operation from the MN to the RN is distributed over two SnpDVMOp request packets using
the address fields.

The various fields in the payload and their encodings are shown in Table 8-2.

Table 8-2 DVMOp fields and encodings

Field Bits Function

VA Valid 1 0b1 indicates that the specified address is valid

VMID Valid 1 0b1 indicates that the Virtual Machine IDentifier (VMID) or Virtual Index (VI) is valid

ASID Valid 1 0b1 indicates that the Address Space IDentifier (ASID) or VI is valid

Security 2 Indicates that the transaction applies to:

0b00 Secure and Non-secure
0b01 Reserved
0b10 Secure
0b11 Non-secure

Exception Level 2 Indicates that the transaction applies to:

0b00 Hypervisor and all Guest OS
0b01 EL3a
0b10 Guest OS
0b11 Hypervisor

DVMOp type 3 Indicates the DVM operation type as:

0b000 TLB Invalidate
0b001 Branch Predictor Invalidate
0b010 Physical Instruction Cache Invalidate
0b011 Virtual Instruction Cache Invalidate
0b100 Synchronization
0b101-0b111 Reserved

VMID 8 Virtual Machine ID or Virtual Index VA[27:20]

ASID 16 Address Space ID or Virtual Index VA[19:12]b

8-174 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.2 DVM Operation types

Table 8-2 DVMOp fields and encodings (continued)

Field Bits Function

S2-S1 Staged Invalidation 2 Indicates Stage 2 or Stage 1 invalidation:

0b00 Used for all DVMv7 transactions. For DVMv8 transactions, used for both
Stage 1 and stage 2 invalidations.
0b01 Stage 1 invalidation only.
0b10 Stage 2 invalidation only.
0b11 Reserved.

Leaf Entry Invalidation 1 0b1 indicates that only leaf level translation invalidation is required

VA or 43 Virtual address: Addr[48:6]

PA 38 Physical address: Addr[43:6]

a. DVMv8 only.
b. When used as Virtual Index, the upper 8-bits of ASID are Don’t care.

8.2.2 DVMOp and SnpDVMOp packet

Table 8-3 shows the distribution of the payload in the DVMOp request from the RN, using 8-byte write semantics,
and the distribution of the payload in the SnpDVMOp requests from the MN.

In the DVMOp, the combination of the address field in the request and the 8-byte write data transports the complete
payload. Addr[3] is not used in the request and must be set to zero.

In the two SnpDVMOp requests the combination of the two address fields transports the complete payload. Addr[3]
is used in a SnpDVMOp request to indicate which part of the payload is being transported.

Bits [43:3] are used in the DVMOp request address field so that the mapping between the DVMOp request and
SnpDVMOp request are similar.

A 44-bit physical and a 49-bit virtual address are used in the payload mapping.

Table 8-3 DVMOp and SnpDVMOp request payloads using a 49-bit VA and 44-bit PA

Field Bits Request Data Snoop Notes

Addr Data Addr

Part 1 Part 2

Part Num 1 [3] - [3] [3] Must be 0b0 for the Request and Snoop Part 1.
Must be 0b1 for Snoop Part 2.

VA Valid 1 [4] - [4] - -

VMID Valid 1 [5] - [5] - -

ASID Valid 1 [6] - [6] - -

Security 2 [8:7] - [8:7] - -

Exception Level 2 [10:9] - [10:9] - -

DVMOp type 3 [13:11] - [13:11] - -

VMID 8 [21:14] - [21:14] - -

ASID 16 [37:22] - [37:22] - -

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-175
ID061214 Confidential
8 DVM Operations
8.2 DVM Operation types

Table 8-3 DVMOp and SnpDVMOp request payloads using a 49-bit VA and 44-bit PA (continued)

Field Bits Request Data Snoop Notes

Addr Data Addr

Part 1 Part 2

S2-S1 Staged Invalidation 2 [39:38] - [39:38] - -

Leaf Entry Invalidation 1 [40] - [40] - -

VA[48:46] 3 - [46:44] [43:41] - Either VA[48:6] or PA[43:6] is used not both.

VA[45:6] 40 - [43:4] - [43:4]

PA[43:6] 38 - [41:4] - [41:4]

8-176 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.3 DVM Operations

8.3 DVM Operations

This section describes the supported DVM Operations:
• TLB Invalidate.
• Branch Predictor Invalidate on page 8-179.
• Physical Instruction Cache Invalidate on page 8-180.
• Virtual Instruction Cache Invalidate on page 8-181.
• Synchronization on page 8-182.

Table 8-4 shows the values for the Part Num field in all supported DVM Operations.

Table 8-4 Part Num field values

Addr Value Status

Bit Field Request Snoop

Part 1 Part 2

[3] Part Num 0b0 0b0 0b1 Not utilized in the Request, must be
set to zero.

8.3.1 TLB Invalidate

Table 8-5 shows the supported TLB Invalidate operations.

Table 8-5 TLB Invalidate operations

Addr Operation

[13:11] [10:9] [8:7] [6] [5] [40] [39:38] [4]

DVMOp type Exception Secure ASID VMID LEAF S2-S1 VA
Level valid valid valid

0b000 0b10 0b10 0b0 0b0 0b0 0b00a 0b0 Secure TLB Invalidate all
All Guest OS Secure Ignore Ignore Ignore Ignore

0b0 0b0 0b0 0b00a 0b1 Secure TLB Invalidate by VA

Ignore Ignore Ignore Match

0b0 0b0 0b1 0b00a 0b1 Secure TLB Invalidate by VA

Ignore Ignore Leaf Match Leaf Entry only

0b1 0b0 0b0 0b00a 0b0 Secure TLB Invalidate by

Match Ignore Ignore Ignore ASID

0b1 0b0 0b0 0b00a 0b1 Secure TLB Invalidate by

Match Ignore Ignore Match ASID and VA

0b1 0b0 0b1 0b00a 0b1 Secure TLB Invalidate by

Match Ignore Leaf Match ASID and VA Leaf Entry only

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-177
ID061214 Confidential
8 DVM Operations
8.3 DVM Operations

Table 8-5 TLB Invalidate operations (continued)

Addr Operation

[13:11] [10:9] [8:7] [6] [5] [40] [39:38] [4]

DVMOp type Exception Secure ASID VMID LEAF S2-S1 VA
Level valid valid valid

0b000 0b10 0b11 0b0 0b0 0b0 0b00a 0b0 All Guest OS TLB Invalidate
All Guest OS Non-secure Ignore Ignore Ignore Ignore all

0b0 0b1 0b0 0b01 0b0 Guest OS TLB Invalidate all

Ignore Match Ignore S1 Ignore Stage 1 invalidation only

0b0 0b1 0b0 0b00a 0b0 Guest OS TLB Invalidate all

Ignore Match Ignore Ignore ARMv7 must carry out Stage 1
and 2 invalidation

0b0 0b1 0b0 0b00a 0b1 Guest OS TLB Invalidate by

Ignore Match Ignore Match VA

0b0 0b1 0b1 0b00a 0b1 Guest OS TLB Invalidate by

Ignore Match Leaf Match VA Leaf Entry only

0b1 0b1 0b0 0b00a 0b0 Guest OS TLB Invalidate by

Match Match Ignore Ignore ASID

0b1 0b1 0b0 0b00a 0b1 Guest OS TLB Invalidate by

Match Match Ignore Match ASID and VA

0b1 0b1 0b1 0b00a 0b1 Guest OS TLB Invalidate by

Match Match Leaf Match ASID and VA Leaf Entry only

0b0 0b1 0b0 0b10 0b1 Guest OS TLB Invalidate by

Ignore Match Ignore S2 IPAb IPA

0b0 0b1 0b1 0b10 0b1 Guest OS TLB Invalidate by

Ignore Match Leaf S2 IPAb IPA Leaf Entry only

0b000 0b11 0b11 0b0 0b0 0b0 0b00a 0b0 Hypervisor TLB Invalidate all
Hypervisor Non-secure Ignore Ignore Ignore Ignore

0b0 0b0 0b0 0b00a 0b1 Hypervisor TLB Invalidate by

Ignore Ignore Ignore Match VA

0b0 0b0 0b1 0b00a 0b1 Hypervisor TLB Invalidate by

Ignore Ignore Leaf Match VA Leaf Entry only

0b01 0b10 0b0 0b0 0b0 0b00a 0b1 EL3 TLB Invalidate by VA
EL3 Secure Ignore Ignore Ignore Match

0b0 0b0 0b1 0b00a 0b1 EL3 TLB Invalidate by VA

Ignore Ignore Leaf Match Leaf Entry only

0b0 0b0 0b0 0b00a 0b0 EL3 TLB Invalidate All

Ignore Ignore Ignore Ignore
a. All DVMv7 transactions must use 0b00.
b. IPA is the Intermediate Physical Address.

8-178 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.3 DVM Operations

8.3.2 Branch Predictor Invalidate

This section shows the Branch Predictor Invalidate operations.

Table 8-6 shows the fixed value fields in the Branch Predictor Invalidate operation.

Table 8-6 Branch Predictor Invalidate operation fixed values

Addr Value Status

Bits Field

[3] Part Num - See Table 8-4 on page 8-177

[5] VMID Valid 0b0 VMID field not valid

[6] ASID Valid 0b0 ASID field not valid

[8:7] Secure 0b00 Applies to both secure and Non-secure

[10:9] Exception Level 0b00 Applies to all Guest OS and Hypervisor

[21:14] VMID 0xXX VMID not specified

[37:22] ASID 0xXXXX ASID not specified

[39:38] S2, S1 Staged Invalidation 0b00 Reserved, set to Zero

[40] Leaf Entry Invalidation 0b0 Reserved, set to Zero

Note
The use of Branch Predictor Invalidate with a 16-bit ASID is not supported.

Table 8-7 shows the operations supported by Branch Predictor Invalidate.

Table 8-7 Branch Predictor Invalidate operations

Addr Operation

[13:11] [4]
DVMOp type VA valid

0b001 0b0 Branch Predictor Invalidate all

Ignore

0b1 Branch Predictor Invalidate by VA

Match

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-179
ID061214 Confidential
8 DVM Operations
8.3 DVM Operations

8.3.3 Physical Instruction Cache Invalidate

This section shows the Physical Instruction Cache Invalidate operations.

Table 8-8 shows the fixed value fields in the Physical Instruction Cache Invalidate operation.

Table 8-8 Physical Instruction Cache Invalidate operation fixed values

Addr Value Status

Bits Field

[3] Part Num - See Table 8-4 on page 8-177

[10:9] Exception Level 0b00 Applies to all Guest OS and Hypervisor

[39:38] S2, S1 Staged Invalidation 0b00 Reserved, set to zero

[40] Leaf Entry Invalidation 0b0 Reserved, set to zero

Table 8-9 shows the operations supported by Physical Instruction Cache Invalidate.

Note
When Virtual Index is 0b11, then VA[19:12] and VA[27:20], at Addr[29:22] and Addr[21:14] respectively, are used
as part of the Physical Address. Addr[37:30] are not used, and are Don’t care values.

Table 8-9 Physical Instruction Cache Invalidate operations

[13:11] [8:7] [6:5] [4]

Operation
DVMOp type Secure Virtual Index VA

0b010 0b10 0b00 0b0 Secure Physical Address Cache Invalidate all
Secure Ignore

0b00 0b1 Secure Physical Address Cache Invalidate by PA without Virtual Index
Match

0b11 0b1 Secure Physical Address Cache Invalidate by PA with Virtual Index
Match

0b11 0b00 0b0 Non-secure Physical Address Cache Invalidate all

Non-secure Ignore

0b00 0b1 Non-secure Physical Address Cache Invalidate by PA without Virtual

Match Index

0b11 0b1 Non-secure Physical Address Cache Invalidate by PA with Virtual

Match Index

8-180 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 8 DVM Operations
8.3 DVM Operations

8.3.4 Virtual Instruction Cache Invalidate

This section shows the Virtual Instruction Cache Invalidate operations.

Table 8-10 shows the fixed value fields in the Virtual Instruction Cache Invalidate operation.

Table 8-10 Virtual Instruction Cache Invalidate operation fixed values

Addr Value Status

Bits Field

[3] Part Num - See Table 8-4 on page 8-177

[39:38] S2, S1 Staged Invalidation 0b00 Reserved. set to zero

[40] Leaf Entry Invalidation 0b0 Reserved, set to zero

Table 8-11 shows the operations supported by Virtual Instruction Cache Invalidate.

Table 8-11 Virtual Instruction Cache Invalidate operations

Addr Operation

[13:11] [10:9] [8:7] [6] [5] [4]

DVMOp type Exception Secure ASID VMID VA
Level valid valid valid

0b011 0b00 0b00 0b0 0b0 0b0 Invalidate all. Applies to Secure and Non-secure.
Ignore Ignore Ignore Applies to Hypervisor and all Guest OS.

0b11 0b0 0b0 0b0 Invalidate all. Applies to Non-secure. Applies to

Ignore Ignore Ignore Hypervisor and all Guest OS.

0b10 0b10 0b1 0b0 0b1 Secure Invalidate by ASID and VA.
Match Ignore Match

0b11 0b0 0b1 0b0 Guest OS, Invalidate all.

Ignore Match Ignore

0b1 0b1 0b1 Guest OS, Invalidate by ASID and VA.

Match Match Match

0b11 0b11 0b0 0b0 0b1 Hypervisor, Invalidate by VA.

Ignore Ignore Match

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 8-181
ID061214 Confidential
8 DVM Operations
8.3 DVM Operations

8.3.5 Synchronization
This section shows the DVMSync Operation.

Table 8-12 shows the fixed value fields in the Sync operation.

Table 8-12 Sync operation fixed values

Addr Value Status

Bits Field

[3] Part Num - See Table 8-4 on page 8-177

[4] VA Valid 0b0 Not applicable

[5] VMID Valid 0b0 Ignore VMID

[6] ASID Valid 0b0 Ignore ASID

[8:7] Secure 0b00 Applies to both Secure and Non-secure

[10:9] Exception Level 0b00 Applies to all Guest OS and Hypervisor

[13:11] DVMOp type 0b100 Synchronization message

[21:14] VMID 0xXX VMID not specified

[37:22] ASID 0xXXXX ASID not specified

[39:38] S2, S1 Staged Invalidation 0b00 Set to zero

[40] Leaf Entry Invalidation 0b0 Set to zero

8-182 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 9
Error Handling

This chapter describes the error handling requirements. It contains the following sections:
• Error types on page 9-184.
• Error response fields on page 9-185.
• Errors and transaction structure on page 9-186.
• Error response use by transaction type on page 9-187.
• Hardware and software error categories on page 9-191.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 9-183
ID061214 Confidential
9 Error Handling
9.1 Error types

9.1 Error types

This specification supports two types of error reporting:

Data Error Used when the correct address location has been accessed, but an error is detected within
the data. Typically, this is used when data corruption has been detected by ECC or a parity
check.

Non-data Error Used when an error is detected that is not related to data corruption. This specification does
not define all cases when this error type is reported. Typically, this error type is reported for:
• An attempt to access a location that does not exist.
• An illegal access, such as a write to a read only location.
• An attempt to use a transaction type that is not supported.

9-184 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 9 Error Handling
9.2 Error response fields

9.2 Error response fields

The RespErr field is used to indicate error conditions. The RespErr field is included in both response and data
packets.

Table 9-1 shows the encoding of the RespErr field. See Responses to exclusive requests on page 6-146 for more
details on the Exclusive Okay response.

Table 9-1 Error response field encodings

RespErr[1:0] Name Description

0b00 OK Okay. Indicates that a non-exclusive access has been successful.

Also used to indicate an exclusive access failure.

0b01 EXOK Exclusive Okay. Indicates that either the read or write portion of an
exclusive access has been successful.

0b10 DERR Data Error.

0b11 NDERR Non-data Error.

A single transaction is not permitted to mix OK and EXOK responses.

The mixing of OK, DERR, and NDERR responses within a single transaction is permitted.

The mixing of EXOK, DERR and NDERR responses within a single transaction is permitted.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 9-185
ID061214 Confidential
9 Error Handling
9.3 Errors and transaction structure

9.3 Errors and transaction structure

All transactions must complete in a protocol compliant manner, even if they include an error response.

If the transaction contains data packets then the source of the data packets is required to send the correct number of
packets, but the data values are not required to be valid.

The Resp field gives the cache states associated with a transaction and can be influenced by an error condition. See
Response types on page 4-103 for more details on the legal Resp field values. If a response to a transaction does not
have a legal cache state, then the RespErr field must indicate a Data Error or Non-data Error for all data packets.

The Resp field in a response must have the same value for every packet of a data message regardless of whether or
not there is an error condition.

9-186 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 9 Error Handling
9.4 Error response use by transaction type

9.4 Error response use by transaction type

This section defines the permitted use of the error fields for each transaction type.

The tables that follow show the Data and Response packets associated with the following transaction types:
• Read Transactions.
• Dataless transactions on page 9-188.
• Write transactions on page 9-188
• Other transactions on page 9-189
• Snoop transactions on page 9-190

The following keys are used by the tables:

OK The RespErr field must contain the OK RespErr value of 0b00.
Y This value of RespErr is permitted.
N This value of RespErr is not permitted.
- Data or Response packet is not used for this transaction type.

9.4.1 Read Transactions

Read transactions can contain multiple CompData data packets. Each data packet can use a different error type, as
indicated by the table below, with the restriction that a single transaction cannot mix OK and EXOK responses.

Table 9-2 Read transaction packets legal RespErr field values

Read transaction Associated Data and Response packets

Read Receipt CompData CompAck

OK EXOK DERR NDERR

ReadNoSnp OK Y Y Y Y OK

ReadOnce OK Y N Y Y OK

ReadClean - Y Y Y Y OK
ReadShared

ReadUnique - Y N Y Y OK

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 9-187
ID061214 Confidential
9 Error Handling
9.4 Error response use by transaction type

9.4.2 Dataless transactions

A Data Error can be reported for a Dataless transaction when the processing of the transaction by another component
encounters a data corruption error. This data error can be indicated back to the originating component, even though
a transfer of data does not occur.

Table 9-3 Dataless transaction packets legal RespErr field values

Dataless transaction Associated Response packets

Comp CompAck

OK EXOK DERR NDERR

CleanUnique Y Y Y Y OK

CleanShared Y N Y Y OK
CleanInvalid
MakeInvalid
MakeUnique

Evict Y N N Y -

9.4.3 Write transactions

A Write transaction can include either a Non-data Error or a Data Error. Errors can be signalled in both directions,
from the Requester to the Completer, and from the Completer back to the Requester.

For a Write transaction an error can be signalled from the Completer back to the Requester using either the
combined CompDBIDResp or using the Comp response. It is permitted for the Completer to signal an error even
before it has observed the WriteData for the transaction and this can occur when the processing of the transaction,
such as the cache lookup, encounters a data corruption error.

Table 9-4 Write transaction response packets legal RespErr field values

Write transaction Associated Response packets

DBIDResp Comp CompDBIDResp CompAck

OK EXOK DERR NDERR OK EXOK DERR NDERR

WriteNoSnp OK Y Y Y Y Y Y Y Y -

WriteUnique OK Y N Y Y Y N Y Y OK

WriteBack - - - - - Y N Y Y -
WriteClean
WriteEvict

9-188 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 9 Error Handling
9.4 Error response use by transaction type

A Requester that detects an error in the write data to be sent can include an error indication with the write data
packet. This indicates that the data value is known to be corrupt.

Table 9-5 Write transaction data packets legal RespErr field values

Write transaction Associated data packets

WriteData

OK EXOK DERR NDERR

WriteNoSnp Y N Y N

WriteUnique Y N Y N

WriteBack Y N Y N
WriteClean
WriteEvict

9.4.4 Other transactions

A Barrier transaction response must not include an error response.

Table 9-6 Barrier transaction response packet legal RespErr field value

Barrier transaction Associated Response packet

Comp

EOBarrier OK
ECBarrier

A DVMOp transaction can include a Non-data Error in the Comp response. The interconnect must consolidate error
responses from all the snoop responses for a DVMOp and include a single error response in the final Comp message
to the Requester. DBIDResp and WriteData packets must only use the OK response.

Table 9-7 DVM transaction packets legal RespErr field values

DVM transaction Associated response and data packets

DBIDResp NCBWrData Comp

OK EXOK DERR NDERR

DVMOp OK OK Y N N Y

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 9-189
ID061214 Confidential
9 Error Handling
9.4 Error response use by transaction type

9.4.5 Snoop transactions

A snoop transaction response that includes data can indicate a Data Error. A Snoop transaction response that
includes data can mix Okay and Data Error responses for different packets within the transaction. A snoop
transaction response that does not include data can indicate a Non-data Error.

Table 9-8

Snoop Transaction Associated Data and Response packets

SnpResp SnpRespData

OK EXOK DERR NDERR OK EXOK DERR NDERR

SnpOnce Y N N Y Y N Y N
SnpClean
SnpShared
SnpUnique
SnpCleanShared
SnpCleanInvalid

SnpMakeInvalid Y N N Y - - - -
SnpDVMOp

9-190 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 9 Error Handling
9.5 Hardware and software error categories

9.5 Hardware and software error categories

This specification defines two error categories, a software based error and a hardware based error.

9.5.1 Software based error

A software based error occurs when multiple accesses to the same location are made with mismatched Snoopable
or Memory attributes.

A software based error can cause a loss of coherency and the corruption of data values. This specification requires
that the system does not deadlock for a software based error, and that transactions always progress through a system
in a timely manner.

A software based error, for an access within one 4KB memory region, must not cause data corruption within a
different 4KB memory region.

For locations held in Normal memory, the use of appropriate barriers and software cache maintenance can be used
to return memory locations to a defined state.

When accessing a peripheral device the correct operation of the peripheral cannot be guaranteed. The only
requirement is that the peripheral continues to respond to transactions in a protocol compliant manner. The sequence
of events that might be required to return a peripheral device that has been accessed incorrectly to a known working
state is IMPLEMENTATION DEFINED.

9.5.2 Hardware based error

A hardware based error is defined as any protocol error that is not a software based error. This specification does
not support hardware based errors.

Warning
If a hardware based error occurs then recovery from the error is not guaranteed. The system might crash, lock-up,
or suffer some other non-recoverable failure.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 9-191
ID061214 Confidential
9 Error Handling
9.5 Hardware and software error categories

9-192 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 10
Quality of Service

This chapter describes the mechanisms in the CHI protocol to support Quality of Service (QoS). It contains the
following sections:
• Overview on page 10-194.
• QoS priority value on page 10-195.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 10-193
ID061214 Confidential
10 Quality of Service
10.1 Overview

10.1 Overview
A system might utilize a QoS scheme to achieve:
• A guaranteed maximum latency for transactions in a particular stream.
• Minimum bandwidth guarantees for a stream of requests.
• Best effort value of bandwidth and latency provided to requests of a particular stream.

The low latency, or guaranteed throughput requirements, required to meet system QoS demands are primarily the
responsibility of the transaction end points with support from the intermediate interconnect. The protocol supports
this by defining a QoS priority value for packets and controlling request flow using a defined credit mechanism.

10-194 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 10 Quality of Service
10.2 QoS priority value

10.2 QoS priority value

A 4-bit value is used to prioritize the processing of the packets at protocol nodes and within the interconnect. The
QoS Priority Value (PV) for packets is assigned by the source of the transaction. In typical usage models this value
is dependent on the source type and the class of traffic, with ascending values of QoS indicating a higher priority
level. The source might also dynamically vary this value depending on some accumulated latency and required
throughput metric.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 10-195
ID061214 Confidential
10 Quality of Service
10.3 Repeating a transaction with higher QoS value

10.3 Repeating a transaction with higher QoS value

When a transaction has been sent with a particular QoS value, it is permitted to send the same transaction again with
a different, typically higher, QoS value. The Completer is required to handle this situation as multiple different
requests.

In this situation, if one of the transactions receives a RetryAck response, then it is permitted to cancel the transaction
and return the credit. See Credit Return on page 2-79.

10-196 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 11
Link Layer

This chapter describes the Link layer that provides a streamlined mechanism for packet based communication
between nodes and the interconnect across links. It contains the following sections:
• Introduction on page 11-198
• Links on page 11-199.
• Flits on page 11-200.
• Channels on page 11-201.
• Port on page 11-203.
• Node interface definitions on page 11-204.
• Channel interface signals on page 11-207.
• Flit packet definitions on page 11-210.
• Protocol flit fields on page 11-215.
• Link flit on page 11-227.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-197
ID061214 Confidential
11 Link Layer
11.1 Introduction

11.1 Introduction
The Link layer provides a streamlined mechanism for packet based communication between nodes and the
interconnect.

The Link layer defines:

• Packet and flit formats.
• Flow control across a link.

Figure 11-1 shows a typical system using link based communication.

Node 1 Node 2 Node 3

Rx Tx Rx Tx Rx Tx

Tx Rx Tx Rx Tx Rx

Interconnect Links

Tx Rx Tx Rx Tx Rx

Rx Tx Rx Tx Rx Tx
Node 4 Node 5 Node 6

Figure 11-1 System using link based communication

11-198 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.2 Links

11.2 Links
Flit communication occurs between a transmitter and a receiver pair.

The connection between a transmitter and a receiver is referred to as a link.

Two-way communication between a node and the interconnect requires a pair of links. Figure 11-2 shows the link
requirements.

Node Interconnect
Transmitter Receiver
Link 1
(TX) (RX)
Receiver Transmitter
Link 2
(RX) (TX)

Figure 11-2 Two-way link communication

11.2.1 Outbound and inbound links

The link used by a transmitter to send packets is defined as the outbound link.

The link used by a receiver to receive packets is defined as the inbound link.

Figure 11-3 shows the outbound and inbound links at a node. The interface at the interconnect has a complementary
pair of links.

Node
Transmitter
Outbound Link
(TX)
Receiver
Inbound Link
(RX)

Figure 11-3 Outbound and inbound links

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-199
ID061214 Confidential
11 Link Layer
11.3 Flits

11.3 Flits
A flit is the basic unit of transfer in the Link layer.

Packets are formatted into flits and transmitted across a link. There are two types of flits:

Protocol flit A Protocol flit carries a protocol packet in its payload. In this specification, every protocol packet
is mapped into exactly one protocol flit.

Link flit A Link flit carries messages associated with link maintenance. For example, a transmitter uses a
Link flit to return a Link layer Credit, also referred to as an L-Credit, to the receiver during a link
deactivation sequence.
Link flits originate at a link transmitter and terminate at the link receiver connected at the other side
of the link.

11-200 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.4 Channels

11.4 Channels
In this specification, the Link layer provides a set of generic channels for flit communication.

The generic channel is used to determine the flit format that is used and, in some cases, this can be used on both an
inbound and outbound channel.

Table 11-1 shows the generic channels, and the mapping onto channels on the RN and SN components.

Table 11-1 Generic channels mapping onto the RN and SN channels

Channel Description Usage RN Channel SN Channel

REQ The request channel transfers flits associated All Requests TXREQ RXREQ
Request with request messages such as Read and
Write Requests. See REQ channel on
page 11-207.

RSP The response channel transfers flits Responses from the Completer RXRSP TXRSP
Response associated with response messages that do
not have a data payload such as write Snoop Response and Completion TXRSP -
completion messages. See RSP channel on Acknowledge
page 11-207.

SNP The snoop channel transfers flits associated All Snoop requests RXSNP -
Snoop with Snoop and SnpDVMOp Request
messages. See SNP channel on page 11-208.

DAT The data channel transfers flits associated Write data, and snoop data for an RN TXDAT RXDAT
Data with protocol messages that have a data
payload such as read completion and write Read data RXDAT TXDAT
data messages. See DAT channel on
page 11-209.

11.4.1 Channel dependencies

The following dependencies are permitted between the channels in the protocol.

For RN:

• An RN is permitted to wait for forward progress on the outbound REQ channel, before making forward
progress on the inbound SNP channel.

• An RN is permitted to wait for forward progress on the outbound RSP channel before making forward
progress on the inbound SNP channel.

• An RN is permitted to wait for forward progress on the outbound DAT channel before making forward
progress on the inbound SNP channel.

• An RN must make forward progress on the inbound RSP channel without requiring forward progress on any
other channel.

• An RN must make forward progress on the inbound DAT channel without requiring forward progress on any
other channel.

Note
The requirement that an RN must make forward progress on the inbound RSP and DAT channel, without requiring
forward progress on any other channel, means that an RN must be able to accept all Comp and CompData responses
for outstanding transactions without sending any CompAck responses.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-201
ID061214 Confidential
11 Link Layer
11.4 Channels

For SN:

• An SN is permitted to wait for forward progress on the outbound RSP channel before making forward
progress on the inbound REQ channel.

• An SN must make forward progress on the inbound REQ channel without requiring forward progress on the
outbound DAT channel.

• An SN must make forward progress on the inbound DAT channel without requiring forward progress on any
other channel.

11-202 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.5 Port

11.5 Port
A Port is defined as the set of all links at the interface of a node.

Figure 11-4 shows the relationship between links, channels, and port. See Node interface definitions on page 11-204
for the specific node requirements, See Channel interface signals on page 11-207, and Chapter 12 Link Handshake
for signal details.

Port

RN-F
TXSACTIVE
RXSACTIVE
Outbound Link

TXLINKACTIVEREQ
TXLINKACTIVEACK
REQ channel
TXREQFLITPEND
TXREQFLITV
TXREQFLIT
TXREQLCRDV
TX
RSP channel
TXRSPFLITPEND
TXRSPFLITV
TXRSPFLIT
TXRSPLCRDV

DAT channel
TXDATFLITPEND
TXDATFLITV
Inbound Link TXDATFLIT
TXDATLCRDV

RXLINKACTIVEREQ
RXLINKACTIVEACK
RSP channel
RXRSPFLITPEND
RXRSPFLITV
RXRSPFLIT
RXRSPLCRDV
RX
DAT channel
RXDATFLITPEND
RXDATFLITV
RXDATFLIT
RXDATLCRDV

SNP channel
RXSNPFLITPEND
RXSNPFLITV
RXSNPFLIT
RXSNPLCRDV

Figure 11-4 Relationship between links, channels, and port

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-203
ID061214 Confidential
11 Link Layer
11.6 Node interface definitions

11.6 Node interface definitions

Nodes communicate by exchanging Link flits using the node interface. This section describes the node interfaces:
• Request nodes.
• Slave nodes on page 11-205.

Note
The LINKACTIVE interface pins and signals used by each node for link management are described in Chapter 12
Link Handshake.

11.6.1 Request nodes

This section describes the Request Node interfaces:
• RN-F.
• RN-I on page 11-205.
• RN-D on page 11-205.

RN-F
The RN-F interface uses all channels and is used by a fully coherent Requester such as a core or cluster. Figure 11-5
shows the RN-F interface.

ICN
RN-F
TXREQ REQ RXREQ
RXRSP RSP TXRSP
RXDAT DAT TXDAT
RXSNP SNP TXSNP
TXRSP RSP RXRSP
TXDAT DAT RXDAT

Figure 11-5 RN-F interface

11-204 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.6 Node interface definitions

RN-D
The RN-D interface uses all channels and is used by an IO coherent node that processes DVM messages. Use of the
SNP channel is limited to DVM data transfers. See DVM transaction flow on page 8-166 for details. Figure 11-6
shows the RN-D interface.

ICN
RN-D
TXREQ REQ RXREQ
RXRSP RSP TXRSP
RXDAT DAT TXDAT
RXSNP SNP(DVM) TXSNP
TXRSP RSP RXRSP
TXDAT DAT RXDAT

Figure 11-6 RN-D interface

RN-I
The RN-I interface uses all channels, with the exception of the SNP channel, and is used by an IO coherent Request
Node such as a GPU or IO bridge. A SNP channel is not required because an RN-I node does not include a
hardware-coherent cache or TLB. Figure 11-7 shows the RN-I interface.

ICN
RN-I
TXREQ REQ RXREQ
RXRSP RSP TXRSP
RXDAT DAT TXDAT
TXRSP RSP RXRSP
TXDAT DAT RXDAT

Figure 11-7 RN-I interface

11.6.2 Slave nodes

This section describes the slave node interfaces:
• SN-F.
• SN-I.

SN-F and SN-I

The SN-F and SN-I interfaces are identical and use a RX request channel, a TX response channel, a TX data channel,
and an RX data channel. The SN-F and SN-I receive request messages from the interconnect, and return response
messages to the interconnect. However, the SN-F and SN-I receive different types of transactions. Figure 11-8 on
page 11-206 shows the SN-F and SN-I interface.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-205
ID061214 Confidential
11 Link Layer
11.6 Node interface definitions

ICN
SN-F - SN-I

TXREQ REQ RXREQ

RXRSP RSP TXRSP
RXDAT DAT TXDAT
TXDAT DAT RXDAT

Figure 11-8 SN-F and SN-I interface

11-206 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.7 Channel interface signals

11.7 Channel interface signals

This section describes the channel interfaces. It contains the following sections:
• REQ channel.
• RSP channel.
• SNP channel on page 11-208.
• DAT channel on page 11-209.

11.7.1 REQ channel

Figure 11-9 shows the REQ channel interface pins.

Transmitter Receiver
TXREQFLITPEND REQFLITPEND RXREQFLITPEND
TXREQFLITV REQFLITV RXREQFLITV
TXREQFLIT REQFLIT[(r-1):0] RXREQFLIT

TXREQLCRDV REQLCRDV RXREQLCRDV

Figure 11-9 REQ channel interface pins

Table 11-2 shows the REQ channel interface signals.

Table 11-2 REQ channel interface signals

Signal Description

REQFLITPEND Request Flit Pending. Early indication that a request flit might be transmitted in the following
cycle. See Flit level clock gating on page 12-233.

REQFLITV Request Flit Valid. The transmitter sets this signal HIGH to indicate when REQFLIT[(r-1):0] is
valid.

REQFLIT[(r-1):0] Request Flit. See Request flit on page 11-210 for a description of the request flit format.

REQLCRDV Request L-Credit Valid. The receiver sets this signal HIGH to return a request channel L-Credit to
a transmitter. See L-Credit flow control on page 12-231.

11.7.2 RSP channel

Figure 11-10 shows the RSP channel interface pins. The same interface is used for both inbound and outbound RSP
channels.

Transmitter Receiver
TXRSPFLITPEND RSPFLITPEND RXRSPFLITPEND
TXRSPFLITV RSPFLITV RXRSPFLITV
TXRSPFLIT RSPFLIT[44:0] RXRSPFLIT

TXRSPLCRDV RSPLCRDV RXRSPLCRDV

Figure 11-10 RSP channel interface pins

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-207
ID061214 Confidential
11 Link Layer
11.7 Channel interface signals

Table 11-3 shows the RSP channel interface signals.

Table 11-3 RSP channel interface signals

Signal Description

RSPFLITPEND Response Flit Pending. Early indication that a response flit might be transmitted in the following
cycle. See Flit level clock gating on page 12-233.

RSPFLITV Response Flit Valid. The transmitter sets this signal HIGH to indicate when RSPFLIT[44:0] is
valid.

RSPFLIT[44:0] Response Flit. See Response flit on page 11-211 for a description of the response flit format.

RSPLCRDV Response L-Credit Valid. The receiver sets this signal HIGH to return a response channel L-Credit
to a transmitter. See L-Credit flow control on page 12-231.

11.7.3 SNP channel

Figure 11-11 shows the SNP channel interface pins.

Transmitter Receiver
TXSNPFLITPEND SNPFLITPEND RXSNPFLITPEND
TXSNPFLITV SNPFLITV RXSNPFLITV
TXSNPFLIT SNPFLIT[64:0] RXSNPFLIT

TXSNPLCRDV SNPLCRDV RXSNPLCRDV

Figure 11-11 SNP channel interface pins

Table 11-4 shows the SNP channel interface signals.

Table 11-4 SNP channel interface signals

Signal Description

SNPFLITPEND Snoop Flit Pending. Early indication that a snoop flit might be transmitted in the following cycle.
See Flit level clock gating on page 12-233.

SNPFLITV Snoop Flit Valid. The transmitter sets this signal HIGH to indicate when SNPFLIT[64:0] is valid.

SNPFLIT[64:0] Snoop Flit. See Snoop flit on page 11-212 for a description of the snoop flit format.

SNPLCRDV Snoop L-Credit Valid. The receiver sets this signal HIGH to return a snoop channel L-Credit to a
transmitter. See L-Credit flow control on page 12-231.

11-208 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.7 Channel interface signals

11.7.4 DAT channel

Figure 11-12 shows the DAT channel interface pins. The same interface is used for both inbound and outbound DAT
channels.

Transmitter Receiver
TXDATFLITPEND DATFLITPEND RXDATFLITPEND
TXDATFLITV DATFLITV RXDATFLITV
TXDATFLIT DATFLIT[(d-1):0] RXDATFLIT

TXDATLCRDV DATLCRDV RXDATLCRDV

Figure 11-12 DAT channel interface pins

Table 11-5 shows the DAT channel interface signals.

Table 11-5 DAT channel interface signals

Signal Description

DATFLITPEND Data Flit Pending. Early indication that a data flit might be transmitted in the following cycle. See
Flit level clock gating on page 12-233.

DATFLITV Data Flit Valid. The transmitter sets this signal HIGH to indicate when DATFLIT[(d–1):0] is
valid.

DATFLIT[(d-1):0] Data Flit. See Data flit on page 11-213 for a description of the data flit format.

DATLCRDV Data L-Credit Valid. The receiver sets this signal HIGH to return a data channel L-Credit to a
transmitter. See L-Credit flow control on page 12-231.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-209
ID061214 Confidential
11 Link Layer
11.8 Flit packet definitions

11.8 Flit packet definitions

This section defines the flit format. See:
• Request flit.
• Response flit on page 11-211.
• Snoop flit on page 11-212.
• Data flit on page 11-213.

11.8.1 Request flit

Table 11-6 shows the request flit format.

The value of r, the Request flit width, depends on the supported RSVDC bus width y.

Table 11-6 Request flit format

REQFLIT[(r-1):0] format

Field Bit width Bits

QoS 4 [3:0]

TgtID 7 [10:4]

SrcID 7 [17:11]

TxnID 8 [25:18]

Opcode 5 [30:26]

Size 3 [33:31]

Addr 44 [77:34]

NS 1 [78]

LikelyShared 1 [79]

AllowRetry 1 [80]

Order 2 [82:81]

PCrdType 2 [84:83]

MemAttr 4 [88:85]

SnpAttr 2 [90:89]

LPID 3 [93:91]

Excl 1 [94]

ExpCompAck 1 [95]

11-210 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.8 Flit packet definitions

Table 11-6 Request flit format (continued)

REQFLIT[(r-1):0] format

Field Bit width Bits

RSVDC y=0 -

y=4 [99:96]

y=8 [103:96]

y = 12 [107:96]

y = 16 [111:96]

y = 24 [119:96]

y = 32 [127:96]

11.8.2 Response flit

Table 11-7 shows the response flit format.

Table 11-7 Response flit format

RSPFLIT[44:0] format

Field Bit width Bits

QoS 4 [3:0]

TgtID 7 [10:4]

SrcID 7 [17:11]

TxnID 8 [25:18]

Opcode 4 [29:26]

RespErr 2 [31:30]

Resp 3 [34:32]

DBID 8 [42:35]

PCrdType 2 [44:43]

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-211
ID061214 Confidential
11 Link Layer
11.8 Flit packet definitions

11.8.3 Snoop flit

Table 11-8 shows the snoop flit format.

Table 11-8 Snoop flit format

SNPFLIT[64:0] format

Field Bit width Bits

QoS 4 [3:0]

SrcID 7 [10:4]

TxnID 8 [18:11]

Opcode 4 [22:19]

Addr[43:3] 41 [63:23]

NS 1 [64]

11-212 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.8 Flit packet definitions

11.8.4 Data flit

Table 11-9 shows the data flit formats. The number of data flits required is dependent on the number of data bytes,
and the data bus width. See Data packetization on page 2-71.

The data channel interface supports a 128-bit, 256-bit, and 512-bit data bus width. There are three data flit formats
defined, one for each of the three data bus widths supported at the data channel interface.

The value of d, the Data flit width, depends on the supported RSVDC bus width y, plus the supported Data bus
width n.

Table 11-9 Data flit formats

DATFLIT[d-1:0] format

Field Bit width Bits

QoS 4 [3:0]

TgtID 7 [10:4]

SrcID 7 [17:11]

TxnID 8 [25:18]

Opcode 3 [28:26]

RespErr 2 [30:29]

Resp 3 [33:31]

DBID 8 [41:34]

CCID 2 [43:42]

DataID 2 [45:44]

RSVDC y=0 -

y=4 [49:46]

y=8 [53:46]

y = 12 [57:46]

y = 16 [61:46]

y = 24 [69:46]

y = 32 [77:46]

n=128-bit data bus implementation:

BE 16 [(61+y):(46+y)]

Data 128 [(189+y):(62+y)]

n=256-bit data bus implementation:

BE 32 [(71+y):(46+y)]

Data 256 [(333+y):(78+y)]

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-213
ID061214 Confidential
11 Link Layer
11.8 Flit packet definitions

Table 11-9 Data flit formats (continued)

DATFLIT[d-1:0] format

Field Bit width Bits

n=512-bit data bus implementation:

BE 64 [(109+y):(46+y)]

Data 512 [(621+y):(110+y)]

11-214 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

11.9 Protocol flit fields

A Protocol flit is identified by a non-zero value in the opcode field. All the flit fields defined in this section are
applicable for a Protocol flit.

The following sections describe the encoding of the Protocol flit fields:
• QoS
• TgtID
• SrcID
• TxnID on page 11-216
• Opcode on page 11-216
• Size on page 11-219
• Addr on page 11-219
• NS on page 11-219
• LikelyShared on page 11-220
• AllowRetry on page 11-220
• Order on page 11-220
• PCrdType on page 11-221
• MemAttr on page 11-221
• SnpAttr on page 11-222
• LPID on page 11-222
• Excl on page 11-222
• ExpCompAck on page 11-222
• RespErr on page 11-223
• Resp on page 11-224
• DBID on page 11-225
• CCID on page 11-225
• DataID on page 11-225.

11.9.1 QoS
Quality of Service priority level. Ascending values of QoS indicate higher priority levels. See Chapter 10 Quality
of Service for more information.

11.9.2 TgtID
Target Identifier associated with the message. The unique 7-bit physical node ID of the component to which the
message is targeted. This is used by the interconnect to determine the port to which the message is routed. See
Transaction identifier fields on page 2-50.

11.9.3 SrcID
Source Identifier associated with the message. The unique 7-bit physical node ID of the component from which the
message is sent. This is used by the interconnect to determine the port from which the message has been routed. See
Transaction identifier fields on page 2-50.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-215
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

11.9.4 TxnID
Transaction Identifier associated with the message. Every new transaction from a given source node, except a link
flit, has a unique 8-bit transaction ID. See Transaction identifier fields on page 2-50.

Link flits do not have a unique ID. Table 11-10 shows the link flit TxnID field value encodings.

Table 11-10 Link flit TxnID Encodings

TxnID Description

0x00 L-Credit return

0x01 to 0xFF Reserved

11.9.5 Opcode
Specifies the operation to be carried out. The Opcode encodings are specific to each channel. See:
• REQ channel opcodes.
• RSP channel opcodes on page 11-217.
• SNP channel opcodes on page 11-218.
• DAT channel opcodes on page 11-218.

REQ channel opcodes

Table 11-11 shows the opcodes for the request channel.

Table 11-11 REQ channel opcodes

Opcode[4:0] Request command

0x00 ReqLCrdReturn

0x01 ReadShared

0x02 ReadClean

0x03 ReadOnce

0x04 ReadNoSnp

0x05 PCrdReturn

0x06 Reserved

0x07 ReadUnique

0x08 CleanShared

0x09 CleanInvalid

0x0A MakeInvalid

0x0B CleanUnique

0x0C MakeUnique

0x0D Evict

0x0E EOBarrier

0x0F ECBarrier

11-216 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

Table 11-11 REQ channel opcodes (continued)

Opcode[4:0] Request command

0x10 - 0x13 Reserved

0x14 DVMOp

0x15 WriteEvictFull

0x16 WriteCleanPtl

0x17 WriteCleanFull

0x18 WriteUniquePtl

0x19 WriteUniqueFull

0x1A WriteBackPtl

0x1B WriteBackFull

0x1C WriteNoSnpPtl

0x1D WriteNoSnpFull

0x1E - 0x1F Reserved

RSP channel opcodes

Table 11-12 shows the opcodes for the response channel.

Table 11-12 RSP channel opcodes

Opcode[3:0] Response command

0x0 RespLCrdReturn

0x1 SnpResp

0x2 CompAck

0x3 RetryAck

0x4 Comp

0x5 CompDBIDResp

0x6 DBIDResp

0x7 PCrdGrant

0x8 ReadReceipt

0x9 - 0xF Reserved

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-217
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

SNP channel opcodes

Table 11-13 shows the opcodes for the snoop channel.

Table 11-13 SNP channel opcodes

Opcode[3:0] Snoop command

0x0 SnpLCrdReturn

0x1 SnpShared

0x2 SnpClean

0x3 SnpOnce

0x4 - 0x6 Reserved

0x7 SnpUnique

0x8 SnpCleanShared

0x9 SnpCleanInvalid

0xA SnpMakeInvalid

0xB - 0xC Reserved

0xD SnpDVMOp

0xE - 0xF Reserved

DAT channel opcodes

Table 11-14 shows the opcodes for the data channel.

Table 11-14 DAT channel opcodes

Opcode[2:0] Data command

0x0 DataLCrdReturn

0x1 SnpRespData

0x2 CopyBackWrData

0x3 NonCopyBackWrData

0x4 CompData

0x5 SnpRespDataPtl

0x6 - 0x7 Reserved

11-218 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

11.9.6 Size
Size. Specifies the size of the data associated with the transaction. See Data size on page 2-70.

Table 11-15 shows the Size field value encodings.

Table 11-15 Size field value encodings

Size[2:0] Bytes

0b000 1

0b001 2

0b010 4

0b011 8

0b100 16

0b101 32

0b110 64

0b111 Reserved

11.9.7 Addr
Address. Specifies the address associated with the message:
• Request messages support a 44-bit address field, Addr[43:0].
• Snoop messages support a 41-bit address field, Addr[43:3]:
— Addr[43:6] specifies the aligned address of the 64-byte cache line.
— Addr[5:4] indicates the 16-byte critical chunk within the cache line. See Critical Chunk Identifier on
page 2-72.
— Addr[3] is relevant in SnpDVMOp, for all other snoop packets it must be set to zero.

11.9.8 NS
Non Secure. Indicates a Non-secure access or a Secure access.

Table 11-16 shows the NS field value encoding.

Table 11-16 NS value encoding

NS Description

0 Secure access

1 Non-secure access

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-219
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

11.9.9 LikelyShared
Likely Shared. Indicates whether the requested data is likely to be shared with another RN.

Table 11-17 shows the LikelyShared field value encoding.

Table 11-17 LikelyShared value encoding

LikelyShared Description

0 Not likely to be shared by another RN

1 Likely to be shared by another RN

11.9.10 AllowRetry
Allow Retry. Specifies that the request is being sent without a P-Credit and that the target can determine if a retry
response is given. See Transaction Retry mechanism on page 2-80.

Table 11-18 shows the AllowRetry value encoding.

Table 11-18 AllowRetry value encodings

AllowRetry Description

0 RetryAck response not permitted

1 RetryAck response permitted

11.9.11 Order
Specifies the ordering requirements for a transaction. See Chapter 7 Ordering for more information on the ordering
requirements.

Table 11-19 shows the Order field value encodings.

Table 11-19 Order value encodings

Order[1:0] Description

0b00 No ordering required

0b01 Reserved

0b10 Request Order/Ordered Write Observation

0b11 Endpoint Order, which also includes Request Order

11-220 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

11.9.12 PCrdType
Protocol Credit Type. Indicates the type of credit being granted or returned. See Transaction Retry mechanism on
page 2-80.

Table 11-20 shows the PCrdType field encoding.

Table 11-20 PCrdType value encoding

PCrdType Description

0b00 P-Credit type 0

0b01 P-Credit type 1

0b10 P-Credit type 2

0b11 P-Credit type 3

11.9.13 MemAttr
Memory Attribute. Memory attribute associated with the transaction.

Table 11-21 shows the MemAttr value encodings.

Table 11-21 MemAttr value encodings

MemAttr[3:0] Description

[3] Allocate hint bit. Indicates whether or not the cache receiving the transaction is recommended
to allocate the transaction:
0 Recommend that it does not allocate.
1 Recommend that it allocates.

[2] Cacheable bit. Indicates a Cacheable transaction for which the cache, when present, must be
looked up in servicing the transaction:
0 Non-cacheable.
1 Cacheable.

[1] Device bit. Indicates if the memory type associated with the transaction is Device or Normal:
0 Normal memory type.
1 Device memory type.

[0] Early Write Acknowledge bit. Specifies the Early Write Acknowledge status for the
transaction:
0 Early Write Acknowledge not permitted.
1 Early Write Acknowledge permitted.

See Memory Attributes on page 2-62.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-221
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

11.9.14 SnpAttr
Snoop Attribute. Specifies the snoop attributes associated with the transaction.

Table 11-22 shows the SnpAttr value encodings.

Table 11-22 SnpAttr value encodings

SnpAttr[1:0] Snoop attribute

0b00 Non-snoopable

0b01 Inner Snoopable

0b10 Reserved

0b11 Outer Snoopable

See Snoop Attribute on page 2-65.

11.9.15 LPID
Logical Processor Identifier. Used in conjunction with the SrcID to uniquely identify the logical processor that
generated the request. See Logical Processor Identifier on page 2-61.

11.9.16 Excl
Exclusive bit. Indicates that the corresponding transaction is an Exclusive type transaction. The Exclusive bit must
only be used with the following transactions:
• ReadShared.
• ReadClean.
• CleanUnique.
• ReadNoSnp.
• WriteNoSnp.

Table 11-23 shows the Excl value encoding.

Table 11-23 Excl value encoding

Excl Description

0 Normal transaction

1 Exclusive transaction

See Exclusive transactions on page 6-146.

11.9.17 ExpCompAck
Expect CompAck bit. Indicates that the transaction will include a CompAck response.

Table 11-24 shows the ExpCompAck value encoding.

Table 11-24 ExpCompAck value encoding

ExpCompAck Description

0 Transaction does not include a CompAck response

1 Transaction includes a CompAck response

11-222 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

11.9.18 RSVDC
Reserved for customer use. Any value is valid in a Protocol flit. Propagation of this field through the interconnect
is IMPLEMENTATION DEFINED.

This field is applicable to the REQ and DAT channels as follows:

• The presence of this field is optional.
• The permitted field widths are 4-bit, 8-bit, 12-bit, 16-bit, 24-bit and 32-bit.
• The field widths:
— Can be different between REQ and DAT channels.
— Need not be the same across all REQ channels in the system.
— Need not be the same across all DAT channels in the system.

When connecting TX and RX flit interfaces that have mismatched RSVDC widths:

• The corresponding lower-order bits of the RSVDC field must be connected at each side of the interface.

• The higher-order RSVDC bits at the RX interface that do not have corresponding bits at the TX interface
must be tied LOW.

11.9.19 RespErr
Response Error. This field indicates the error status of the response.

Table 11-25 shows the RespErr value encodings.

Table 11-25 RespErr value encodings

RespErr[1:0] Description

0b00 Normal Okay. Indicates that either:

• The Normal access was successful.
• The Exclusive access failed.

0b01 Exclusive Okay. Indicates that either the read or write portion of an exclusive access was successful.

0b10 Data Error.

0b11 Non-data Error.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-223
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

11.9.20 Resp
Response Status. The Resp field must have the same value in all data flits of a multi-flit data transfer.

Table 11-26 shows the Resp value encodings.

Table 11-26 Resp value encodings

Resp[2:0] Description

Resp[2] PassDirty. Indicates that the data included in the response message is Dirty with
respect to memory and that the responsibility of writing back the cache line is being
passed to the recipient of the response message.
0 Returned data is not Dirty.
1 Returned data is Dirty and the responsibility of writing back the
cache line is being passed on.

Resp[1:0] For snoop responses, this field indicates the final state of the snooped target node.
For completion responses, this field indicates the final state in the RN.
For write data responses, this field indicates the current state of the data in the RN.

Table 11-27 shows the valid Resp value encodings.

Table 11-27 Valid Resp value encodings for different message types

Response Type Resp[2:0] State Notes

Snoop responses 0b000 I Final state of the snooped RN-F

0b001 SC

0b010 UC, UD

0b011 SD

0b100 I_PD

0b101 SC_PD

0b110 UC_PD

0b111 - Reserved

Comp responses 0b000 I Final state of the requesting RN-F

0b001 SC

0b010 UC

0b011 - Reserved

0b100 -

0b101 -

0b110 UD_PD Final state of the requesting RN-F

0b111 SD_PD

11-224 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.9 Protocol flit fields

Table 11-27 Valid Resp value encodings for different message types (continued)

Response Type Resp[2:0] State Notes

WriteData responses 0b000 I State of the cache line at the RN-F when data is sent

0b001 SC

0b010 UC

0b011 - Reserved

0b100 -

0b101 -

0b110 UD_PD State of the cache line at the RN-F when data is sent

0b111 SD_PD

11.9.21 DBID
Data Buffer Identifier. The DBID is associated with a Write transaction. In response to Write requests, the DBID is
sent to the requester. See Transaction identifier fields on page 2-50.

11.9.22 CCID
Critical Chunk Identifier. The CCID indicates the critical 128-bit chunk of the data that is being requested.

Table 11-28 shows the CCID value encodings.

Table 11-28 CCID value encodings

CCID[1:0] Critical data chunk

0b00 Data[127:0]

0b01 Data[255:128]

0b10 Data[383:256]

0b11 Data[511:384]

11.9.23 DataID
Data Identifier. The DataID indicates the relative position of the data chunk within the 512-bit cache line that is
being transferred. See Data packetization on page 2-71 for the permitted DataID encodings for all supported data
widths and transaction sizes.

Table 11-29

DataID Data width

128-bit 256-bit 512-bit

0b00 Data[127:0] Data[255:0] Data[511:0]

0b01 Data[255:128] Reserved Reserved

0b10 Data[383:256] Data[511:256] Reserved

0b11 Data[511:384] Reserved Reserved

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-225
ID061214 Confidential
11 Link Layer
11.9 Protocol flit fields

11.9.24 BE
Byte Enable. The BE field is defined for write data, DVM payload, and snoop response data transfers. For read
response data transfers, this field can have any value. It consists of a bit for each data byte in the DAT flit. See Byte
Enables on page 2-71.

11.9.25 Data
Data payload. The following data bus widths are supported:
• 128-bit.
• 256-bit.
• 512-bit.

See Data packetization on page 2-71.

11-226 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 11 Link Layer
11.10 Link flit

11.10 Link flit

A link flit is used to return L-Credits to the receiver during a link deactivation sequence. Link flits originate at a link
transmitter and terminate at the link receiver on the other side of the link.

A link flit is identified by a zero value in the Opcode field. The TxnID field of the link flit is required to be zero.
The remaining fields are not used and can be any value. See TxnID on page 11-216 for the link flit type encoding.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 11-227
ID061214 Confidential
11 Link Layer
11.10 Link flit

11-228 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 12
Link Handshake

This chapter describes the link handshake requirements. It contains the following sections:
• Clock, and initialization on page 12-230.
• Link layer Credit on page 12-231.
• Low power signaling on page 12-232.
• Flit level clock gating on page 12-233.
• Interface activation and deactivation on page 12-234.
• Transmit and receive link Interaction on page 12-240.
• Protocol layer activity indication on page 12-246.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-229
ID061214 Confidential
12 Link Handshake
12.1 Clock, and initialization

12.1 Clock, and initialization

This section specifies the AMBA 5 CHI requirement for global clock and reset signals.

12.1.1 Clock
This architecture specification does not define a specific clocking microarchitecture, but it is expected that all
devices, interconnects, etc. will include one or more clocks that can be relied upon by other Link layer functions
that require synchronous communication. A generic clock signal is referred to as CLK in the following sections,
where applicable.

12.1.2 Reset
This architecture specification does not define a specific reset microarchitecture, but it is expected that all devices,
interconnects, etc will include a specific reset deassertion event that can be relied upon by other Link layer
functions. A generic reset signal is referred to as RESETn in the following sections, where applicable.

12.1.3 Initialization
During reset the following interface signals must be deasserted by the component:
• TX***LCRDV.
• TX***FLITV.
• TXLINKACTIVEREQ and RXLINKACTIVEACK.

The earliest point after reset that it is permitted to begin driving these signals HIGH is at a rising CLK edge after
RESETn is HIGH.

All other signals can be any value.

12-230 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.2 Link layer Credit

12.2 Link layer Credit

This section describes the Link layer Credit (L-Credit) mechanism. Information is transferred across an interface
channel by the use of L-Credits. To transfer one flit from the transmitter to the receiver the transmitter must have
obtained an L-Credit.

12.2.1 L-Credit flow control

An L-Credit is sent from the receiver to the transmitter by asserting the appropriate LCRDV signal for a single clock
cycle. There is one LCRDV signal for each channel. See Channel interface signals on page 11-207 for the LCRDV
signal naming for each channel.

Each transfer of a flit from the transmitter to the receiver consumes one L-Credit.

The minimum number of L-Credits that a receiver can provide is one. The maximum number of L-Credits that a
receiver can provide is 15.

A receiver must guarantee that it can accept all the flits for which it has issued L-Credits.

When the link is active, the receiver must provide L-Credits in a timely manner without requiring any action on the
part of the transmitter.

Note
An L-Credit cannot be used in the cycle it is received.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-231
ID061214 Confidential
12 Link Handshake
12.3 Low power signaling

12.3 Low power signaling

This section describes the signaling used to enhance the low power operation of the interface. There are several
different levels of operation:

Flit Level Clock Gating

This technique is used to provide a cycle by cycle indication of the activity of each of the channels
of the interface. For each channel an additional signal is provided to indicate if a transfer might
occur in the following cycle. This signaling permits local clock gating of certain registers associated
with the interface.

Link Activation
Link activation and deactivation is supported to permit the interface to be taken to a safe state, so
that both-sides of the interface can enter a low power state that permits them to be either clock-gated
or power-gated.

Protocol Activity Indication

The Protocol layer activity indication is used by components to indicate if there are ongoing
transactions in progress. The Protocol layer activity indication can be used to influence the decision
to use other low power techniques.

12-232 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.4 Flit level clock gating

12.4 Flit level clock gating

The FLITPEND signal associated with a channel is used to indicate if a valid flit is going to be sent in the next
clock cycle. There is one FLITPEND signal for each channel. See Channel interface signals on page 11-207 for
the FLITPEND signal naming for each channel.

The requirements for the use of FLITPEND are:

• It is required that the signal is asserted exactly one cycle before a flit is sent from the transmitter.
• When asserted it is permitted, but not required, that the transmitter sends a flit in the next cycle.
• When deasserted, it is required that the transmitter does not send a flit in the next cycle.
• A transmitter is permitted to keep the signal permanently asserted. It might do this, for example, if it is unable
to determine in advance when a flit is to be sent.
• A transmitter is permitted to assert this signal when it does not have an L-Credit.
• A transmitter is permitted to assert and then deassert this signal without sending a flit.

Figure 12-1 shows an example of the use of the FLITPEND signal.

CLK

FLITPEND

FLITV

FLIT
flit flit

Figure 12-1 FLITPEND indicating a valid flit in next cycle

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-233
ID061214 Confidential
12 Link Handshake
12.5 Interface activation and deactivation

12.5 Interface activation and deactivation

A mechanism is provided for an entire interface to move between a full running operational state and a low power
state. When moving between operational states, including when exiting from reset, it is important that the exchange
of L-Credits, and also the exchange of Link flits, is carefully controlled to avoid the loss of flits or credits.

On exit from reset, or when moving to a full running operational state, the interface will start in an idle state and the
transfer of flits can only commence when L-Credits have been exchanged. L-Credits can only be exchanged when
the sender of the credits knows the receiver is ready to receive them.

A two signal, four phase, handshake mechanism is used. This two signal interface is used for all channels traveling
in the same direction, rather than being required for each individual channel. An entire interface uses a total of four
signals, two signals are used for all the transmit channels and two signals are used for all the receive channels.

12.5.1 Request and Acknowledge handshake

For the purposes of description, the two signal Request and Acknowledge signaling is described using the signal
names LINKACTIVEREQ and LINKACTIVEACK.

This section describes the operation of the LINKACTIVEREQ and LINKACTIVEACK handshake pairs for all
channels moving in one direction. Transmit and receive link Interaction on page 12-240 describes the interaction
between the handshake pairs for the transmit channels and those for the receive channels.
For a single channel, or group of channels traveling in the same direction, Figure 12-2 shows the relationship
between the Payload, Credit, LINKACTIVEREQ and LINKACTIVEACK signals.

LINKACTIVEREQ
LINKACTIVEACK

Transmitter Receiver
Payload

Credit

Figure 12-2 Relationship between Payload, Credit and LINKACTIVE signals

As Figure 12-2 shows, during normal operation the transmitter, which sends the payload flits, requires a credit
before it can send a flit. A credit is passed from the receiver when it has resources available to accept a flit:

• On exit from reset, credits are held by the receiver and must be passed to the transmitter before flit transfer
can begin.

• During normal operation there is an ongoing exchange of flits and credits between the two sides of the
interface.

• Before entering a low power state the sending of payload flits must be stopped and all credits must be returned
to the receiver, this effectively returns the interface to the same state that it was at immediately after reset.

12-234 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.5 Interface activation and deactivation

Four states are defined for the interface operation:

RUN There is an ongoing exchange of flits and credits between the two components.

STOP The interface is in a low power state and it is not operational. All credits are held by the
receiver and the transmitter is not permitted to send any flits.

ACTIVATE This state is used when moving from the STOP state to the RUN state.

DEACTIVATE This state is used when moving from the RUN state to the STOP state.

RUN and STOP are stable states and when one of these states is entered a channel can remain in this state for an
indefinite period of time.

DEACTIVATE and ACTIVATE are transient states and it is expected that when one of these states is entered a
channel will move to the next stable state in a relatively short period of time.

Note
The specification does not define a maximum period of time in a transient state, but it is expected that for any given
implementation it is deterministic.

The state is determined by the LINKACTIVEREQ and LINKACTIVEACK signals. Figure 12-3 shows the
relationship between the four states.

STOP
00 10

DEACTIVATE ACTIVATE

01 11
RUN

Figure 12-3 Request and Acknowledge handshake states

Table 12-1 shows the mapping of the states to the LINKACTIVEREQ and LINKACTIVEACK signals.

Table 12-1 Mapping of states to the LINKACTIVE signals

LINKACTIVEREQ LINKACTIVEACK

STOP 0 0

ACTIVATE 1 0

RUN 1 1

DEACTIVATE 0 1

Table 12-2 on page 12-236 describes the behavior of both the transmitter and the receiver of a single link for each
of the four states.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-235
ID061214 Confidential
12 Link Handshake
12.5 Interface activation and deactivation

Table 12-2 Behavior for each Request and Acknowledge state

State Transmitter Behavior Receiver Behavior

STOP The transmitter has no credits and must not send any flits. The receiver is guaranteed not to receive any flits.
The transmitter is guaranteed not to receive any credits. The receiver must not send any credits.
The transmitter must assert LINKACTIVEREQ to
move to the ACTIVATE state if it has flits to send.

ACTIVATE The transmitter must not send any flits. The receiver is guaranteed not to receive any flits.
(ACT) The transmitter must be prepared to receive credits in this The receiver must not send any credits.
state, although it must not use them until in the RUN The ACTIVATE state is a transient state and the
state. receiver controls the move to the RUN state by
The transmitter remains in the ACTIVATE state while it asserting LINKACTIVEACK.
is waiting for the receiver to acknowledge the move to the The receiver must assert LINKACTIVEACK and
RUN state. move to the RUN state before sending credits. It is
Note permitted to assert LINKACTIVEACK and send a
credit in the same cycle.
The transmitter will only receive credits in the
ACTIVATE state when there is a race between the Note
receiver sending credits and asserting It can appear that a receiver has sent credits in the
LINKACTIVEACK to move to the RUN state. ACTIVATE state if there is a race between the receiver
sending credits and asserting LINKACTIVEACK to
move to the RUN state.

RUN The transmitter can receive credits. The receiver can receive flits corresponding to the
The transmitter can send flits when it has credits credits it has sent.
available. The receiver sends credits when it has resources
The transmitter deasserts LINKACTIVEREQ to exit available to accept further flits.
from this state if it wants to move to a low power state. The receiver must remain in the RUN state until it
observers the de-assertion of LINKACTIVEREQ.

DEACTIVATE The transmitter must return credits using Protocol flits or During this state the receiver stops sending credits and
(DEACT) L-Credit return flits. collects all returned credits.
It is recommended that the transmitter enters the The receiver must be prepared to receive flits, other
DEACTIVATE state only when it has no more Protocol than Link flits to return credits, in this state. This is not
flits to send. Therefore, it is expected that the transmitter expected, but can occur.
will return credits using only L-Credit return flits. The receiver is permitted to send credits when first
The transmitter must be prepared to continue receiving entering this state. However, it must have stopped
credits. For each additional credit received it must send sending credits and had all credits returned before
an L-Credit return flit to return the credit. exiting this state.
The transmitter remains in the DEACTIVATE state while The receiver will receive L-Credit return flits until all
it is waiting for the receiver to acknowledge the move to credits are returned.
the STOP state. At this point, it will be guaranteed to The receiver must wait for all credits to be returned
receive no more credits. before deasserting LINKACTIVEACK.
Note
The receiver will only receive flits in the
DEACTIVATE state when there is a race between the
transmitter sending the last remaining flits and
deasserting LINKACTIVEREQ to move to the
DEACTIVATE state.

12-236 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.5 Interface activation and deactivation

Table 12-5 on page 12-244 summarizes the required behavior described in detail in Table 12-2 on page 12-236.

Table 12-3 Summary of behavior for each Request and Acknowledge state

Transmitter Receiver

STOP Must not send flits. Must not send credits.

Will not receive credits. Will not receive flits.

ACT Must not send flits. Must not send credits.

Must accept credits. Will not receive flits.

RUN Can send flits. Must accept flits.

Must accept credits. Can send credits.

DEACT Must not send flits, except for credit return flits. Must accept flits.
Must accept credits. Must stop sending credits.
Must return credit.

Race conditions
There are two situations where one side of the interface performs two actions at or around the same time:
• Changing the LINKACTIVEREQ or LINKACTIVEACK signal to change the state of the interface.
• Sending an associated credit or flit around the time of the state change.

This occurs in the following situations:

• When the receiver is asserting LINKACTIVEACK, to move from ACTIVATE to RUN, it is also permitted
to start sending credits:
— A race can occur between the sending of a credit, which is expected in the new state, and the assertion
of the LINKACTIVEACK signal indicating the state change.
— This is acceptable because the transmitter is required to be able to accept the credit in the previous state
as well as in the new state.
— For the receiver, it is permitted to send a credit in the same cycle that LINKACTIVEACK is asserted.
— For the transmitter, it is required to accept a credit both before and after the assertion of
LINKACTIVEACK.

• When the transmitter is deasserting LINKACTIVEREQ, to move from RUN to DEACTIVATE, it must stop
sending flits, other than L-Credit return flits:
— A race can occur between the last flit sent, which is expected in the previous state, and the deassertion
of the LINKACTIVEREQ signal indicating the state change.
— This is acceptable because the receiver is required to be able to accept the flit in the next state, as well
as in the previous state.
— For the transmitter, it is permitted to send a flit in the last cycle that LINKACTIVEACK is asserted.
— For the receiver, it is required to accept flits both before and after the deassertion of
LINKACTIVEACK.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-237
ID061214 Confidential
12 Link Handshake
12.5 Interface activation and deactivation

Response to new state

When moving to a new state, where the state change has been initiated by the other-side of the interface, a
component might be required to change its behavior.

If the state change requires a component to start sending flits or credits, then there is no defined limit on the time
taken for the component to start the new behavior. This new behavior will only occur in the new state.

If the state change requires a component to stop sending flits or credits, then the component is permitted to take
some time to respond. In this scenario, it is possible to see behavior when first entering a new state which is not
expected within that state.

The state change from RUN to DEACTIVATE is the point at which flits and credits stop being sent.

Flits are sent by the transmitter, which is also the component that determines the state change, and therefore the
transmitter can ensure flits are not sent after the state change. However, a race condition might still occur as
described in Race conditions on page 12-237.

Credits are sent by the receiver, but that component does not determine the state change. The receiver might take
some time to react to the state change and therefore it is possible for credits to be sent when first entering the
DEACTIVATE state.

The protocol requires that the receiver has stopped sending credits and has had all credits returned before it signals
the change from DEACTIVATE to STOP.

Determining when to move to ACTIVATE or DEACTIVATE

For a given channel, or set of channels in the same direction, the transmitter is always responsible for initiating the
state change from RUN to STOP, or from STOP to RUN.

The transmitter itself can determine that a state change is needed. This can happen through a number of mechanisms.
The following examples are not exhaustive:

• The transmitter can determine that it has flits to send, so must move from STOP to RUN.

• The transmitter can determine that it has no activity to perform for a significant period of time, so can move
from RUN to STOP.

• The transmitter can observe an independent sideband signal that indicates it should move either from RUN
to STOP, or from STOP to RUN.

• The transmitter can determine that a transaction is not fully complete and therefore the channels should
remain in RUN state until all activity has completed.

• The transmitter can observe a state change on the channel, or set of channels, that are used in the opposite
direction. See Transmit and receive link Interaction on page 12-240.

12-238 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.5 Interface activation and deactivation

Multiple channels in the same direction

Figure 12-4 shows an example of a multiple channel interface that transfers payload flits in the same direction. A
single pair of LINKACTIVEREQ and LINKACTIVEACK signals are used for all channels.

LINKACTIVEREQ
LINKACTIVEACK

Payload flit
Credit

Transmitter Receiver
Payload flit
Credit

Payload flit
Credit

Figure 12-4 Example of a multiple channel unidirectional interface

The rules regarding the relationship between the LINKACTIVEREQ and LINKACTIVEACK signals must be
applied appropriately across all channels:

• When a state change requires the transmitter to be able to accept credits it must be able to accept credits on
all channels.

• When a state change requires the receiver to be able to accept flits it must be able to accept flits on all
channels.

• When the sending of flits must stop before a state change the sending of flits must stop on all channels.

• When the sending of credits must stop before a state change the sending of flits must stop on all channels.

• A credit can only be associated with a flit on the same channel.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-239
ID061214 Confidential
12 Link Handshake
12.6 Transmit and receive link Interaction

12.6 Transmit and receive link Interaction

This section describes the interaction between a link transmitter and receiver. It contains the following subsections:
• Introduction.
• Tx and Rx state machines on page 12-241.
• Expected transitions on page 12-243.

12.6.1 Introduction
A single component has a number of different channels, some of which are inputs and some of which are outputs.

For a single component:

• All the channels where the Payload is an output are defined to be the Transmit Link (TXLINK).
• All the channels where the Payload is an input are defined to be the Receive Link (RXLINK).

This specification requires that the activation and de-activation of the TXLINK and RXLINK are coordinated.

When the TXLINK and RXLINK are both in the stable STOP state:

• If the RXLINK moves to the ACTIVATE state, which is controlled by the component on the other side of the
interface, then it is required that the TXLINK also moves to the ACTIVATE state, in a timely manner.

• If a component moves the TXLINK to the ACTIVATE state, which it controls, then it can expect the
RXLINK to also move to the ACTIVATE state, in a timely manner.

When the TXLINK and RXLINK are both in the stable RUN state:

• If the RXLINK moves to the DEACTIVATE state, which is controlled by the component on the other side of
the interface, then it is required that the TXLINK also moves to the DEACTIVATE state, in a timely manner.

• If a component moves the TXLINK to the DEACTIVATE state, which it controls, then it can expect the
RXLINK to also move to the DEACTIVATE state, in a timely manner.

When the TXLINK and RXLINK are changing states, the rules about the sending and receiving of credits and flits
can be considered independently for each link.

12-240 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.6 Transmit and receive link Interaction

12.6.2 Tx and Rx state machines

Figure 12-5 shows the permitted relationships between the Tx and Rx state machines. It is formatted so that the
independent nature of the Tx and Rx state machines can be seen.

RXREQ RXACK RXREQ RXACK RXREQ

RxStop RxAct RxRun RxDeact RxStop RxAct

Banned
TxStop Remote TxStop TxStop
TxStop RxStop Initiate RxAct
Output
RxRun+
Race

Local
TXREQ Initiate

Async
TxAct TxAct TxAct TxAct
TxAct RxStop RxAct RxRun
Input
RxDeact+
Race
Async Pe
rm
TXACK Input itt
Race ed

Banned
TxRun+ TxRun TxRun Remote TxRun TxRun
TxRun RxStop RxAct RxRun Initiate RxDeact
Output
RxStop+
Race
Banned Pe Pe
TXREQ rm Local rm
Output itt itt
ed Initiate ed
Race

Async
TxDeact+ TxDeact TxDeact TxDeact TxDeact
TxDeact RxAct RxRun RxDeact RxStop
Input
RxAct+
Race
Async Pe Pe
TXACK rm rm
Input itt itt
Race ed ed

TxStop+ TxStop TxStop TxStop

TxStop RxRun RxDeact RxStop RxAct

Banned Pe
rm
TXREQ Output itt
Race ed

TxAct+ TxAct
TxAct RxDeact RxStop

Figure 12-5 Combined Tx and Rx state machines

Figure 12-5 shows the combined Tx and Rx state machines for a single component:

• For clarity, shortened state names and signal names are used.

• A green arrow represents a transition that the local agent can control.

• A blue arrow represents a transition that is under the control of the remote agent on the other side of the
interface.

• A black arrow represents a transition that is made when both the local and remote agents make a transition
at the same time.

• Around the edge of Figure 12-5 is an indication of the individual Tx and Rx states, the green and blue arrows
show which agent controls the transition. There is also an indication of the signal change that causes the state
transition.

• A vertical or horizontal arrow is a state change caused by just one signal change, that is, only the Rx state
machine or the Tx state machine changes state, not both.

• A diagonal arrow is a state change caused by two signals changing at the same time. If the diagonal arrow is
green or blue then the same agent is changing both signals.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-241
ID061214 Confidential
12 Link Handshake
12.6 Transmit and receive link Interaction

• There are a few cases where, by coincidence, a state change occurs due to two events, one on each side of the
link, occurring at the same time. This is always a diagonal path and is shown by a black arrow.

• The stub-lines show dead-end paths where an exit from a state is not permitted. The color of a stub-line
indicates which agent is responsible for ensuring that the path is not taken.

• The TxStop/RxStop and TxRun/RxRun states are expected to be stable states, and are typically the states
where the state machines stay for long periods of time. These states are highlighted with a bold outline. All
other states are considered transient states that are exited in a timely manner.

• The grey states, on the bottom right of Figure 12-5 on page 12-241, are replications of those on the top left.
They are shown to aid clarity and maintain the symmetry of the diagram.

• The yellow states can only be reached by observing a race between two input signals. The transition into these
states is labeled with Async Input Race. See Asynchronous race condition on page 12-244.

• The red states can only be reached by observing a race between two output signals. A race between two
outputs is not permitted at the edge of a component and therefore the transition into these states is labeled
with Banned Output Race. These states can only be observed at a midpoint between two components. See
Asynchronous race condition on page 12-244.

• The bold arrows are used to indicate the expected transitions around the state machine. These are described
in more detail in Expected transitions on page 12-243.

• The arrows labeled Permitted are state transactions that would not normally be expected, but they are
permitted by the protocol.

State naming
Figure 12-5 on page 12-241 shows the full set of states, including those that can only be reached through race
conditions. A more detailed discussion of race conditions can be found in Asynchronous race condition on
page 12-244.

There are two different TxStop/RxRun states, and two different TxRun/RxStop states. These states differ in how
they are reached and how it is permitted to exit from them. To differentiate between these states, a [+] suffix is used
to indicate which state machine, that is, Tx or Rx, is running ahead. For example:

• TxStop/RxRun+ indicates that the Tx state machine has remained in the previous Stop state, while the Rx
state machine has advanced to the next Run state.

• TxStop+/RxRun indicates that the Tx state machine has advanced to the next Stop state, while the Rx state
machine remains in the previous Run state.

12-242 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.6 Transmit and receive link Interaction

12.6.3 Expected transitions

Figure 12-6 shows the expected state transitions.

RXREQ RXACK RXREQ RXACK RXREQ

RxStop RxAct RxRun RxDeact RxStop RxAct

Banned
TxStop Remote TxStop TxStop
TxStop RxStop Initiate RxAct
Output
RxRun+
Race

Local
TXREQ Initiate

Async
TxAct TxAct TxAct TxAct
TxAct RxStop RxAct RxRun
Input
RxDeact+
Race
Async Pe
rm
TXACK Input itt
Race ed

Banned
TxRun+ TxRun TxRun Remote TxRun TxRun
TxRun RxStop RxAct RxRun Initiate RxDeact
Output
RxStop+
Race
Banned Pe Pe
TXREQ rm Local rm
Output itt itt
ed Initiate ed
Race

Async
TxDeact+ TxDeact TxDeact TxDeact TxDeact
TxDeact RxAct RxRun RxDeact RxStop
Input
RxAct+
Race
Async Pe Pe
TXACK rm rm
Input itt itt
Race ed ed

TxStop+ TxStop TxStop TxStop

TxStop RxRun RxDeact RxStop RxAct

Banned Pe
rm
TXREQ Output itt
Race ed

TxAct+ TxAct
TxAct RxDeact RxStop

Figure 12-6 Expected Tx and Rx state machines transitions

Figure 12-6 shows, using bold arrows, the routes between the stable TxStop/RxStop and TxRun/RxRun states, and
between the stable TxRun/RxRun and the TxStop/RxStop states.

The difference between the two routes moving from TxStop/RxStop to TxRun/RxRun states compared to moving
from TxRun/RxRun to TxStop/RxStop states is due to the requirement to return Link layer Credits (L-Credits) in
the latter case. The differences are detailed in the following sections.

Expected transitions from TxStop/RxStop to TxRun/RxRun

There are two expected routes from a stable Stop/Stop to Run/Run state. Table 12-4 shows, in terms of the state
transitions, the two expected paths.

Table 12-4 Stop/Stop to Run/Run state paths

State 1 State 2 State 3 State 4

Path 1 TxStop/RxStop TxStop/RxAct TxAct/RxRun TxRun/RxRun

Path 2 TxStop/RxStop TxAct/RxStop TxRun/RxAct TxRun/RxRun

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-243
ID061214 Confidential
12 Link Handshake
12.6 Transmit and receive link Interaction

The annotations on the diagram arrows in Figure 12-6 on page 12-243 are:

Local Initiate Indicates that the local agent has initiated the process of leaving one stable state towards the
other stable state.

Remote Initiate Indicates that the remote agent on the other side of the interface has initiated the process of
leaving one stable state towards the other stable state.

Expected transitions from TxRun/RxRun to TxStop/RxStop

A transition from a Run/Run state to a Stop/Stop state requires that L-Credits are returned. A link must remain in
the DEACTIVATE state until all L-Credits are returned.

There are four expected routes from a stable Run/Run to Stop/Stop state. Table 12-5 shows, in terms of the state
transitions, the four expected paths.

Table 12-5 State 5

State 1 State 2 State 3 State 4 State 5

Path 1 TxRun/RxRun TxDeact/RxRun TxDeact/RxDeact TxStop/RxDeact TxStop/RxStop

Path 2 TxRun/RxRun TxDeact/RxRun TxDeact/RxDeact TxDeact/RxStop TxStop/RxStop

Path 3 TxRun/RxRun TxRun/RxDeact TxDeact/RxDeact TxStop/RxDeact TxStop/RxStop

Path 4 TxRun/RxRun TxRun/RxDeact TxDeact/RxDeact TxDeact/RxStop TxStop/RxStop

Transitioning around a stable state

It is permitted, but not expected, to transition around a stable TxRun/RxRun or TxStop/RxStop state.

In the majority of cases, moving to the stable Run/Run or Stop/Stop state would be expected.

The most likely use case for wanting to move quickly out of one of the stable states is when an interface has started
to enter a low power state, but there is still some activity required. It might be that the low power state was entered
prematurely, or it might be that some new activity arose, by coincidence, while the low power state was being
entered. In this use case, it is desirable to be able to move back to the Run/Run state as quickly as possible.

Asynchronous race condition

There are situations where two output signals, X and Y, have a defined relationship such that:

• Output X must change after or at the same time as output Y, but it is not permitted to change before output Y.

This relationship applies specifically as follows:

• The assertion of RXACK must not occur before the assertion of TXREQ.
• The deassertion of RXACK must not occur before the deassertion of TXREQ.
• The assertion of TXREQ must not occur before the deassertion of RXACK.
• The deassertion of TXREQ must not occur before the assertion of RXACK.

In Figure 12-5 on page 12-241, these transitions are labeled as Banned Output Race and the resultant state is shown
in red.

It is possible to observe these states if monitoring the output signals at a point in the system where asynchronous
race conditions can result in two signals, that are asserted within the same cycle, are observed in different clock
cycles.

A component that is on the other side of the interface, and has the two signals as inputs, can see the state transition
if an asynchronous input race occurs. These transitions are labeled on the diagram as Aysnc Input Race and the
resultant state is shown in yellow.

12-244 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.6 Transmit and receive link Interaction

For all input race conditions, a component that observes the input race is required to wait for both signals before
changing any output signals. This is represented in Figure 12-5 on page 12-241 by the fact that the only permitted
output transition from a race state is caused by the arrival of the other signal associated with the race condition.

Combined Tx and Rx state machines without race conditions

In Figure 12-7 all transitions and states that occur as a result of a race condition in the combined Tx and Rx state
machines have been removed.

RXREQ RXACK RXREQ RXACK RXREQ

RxStop RxAct RxRun RxDeact RxStop RxAct

TxStop Remote TxStop

TxStop RxStop Initiate RxAct

Local
TXREQ Initiate

TxAct TxAct TxAct

TxAct RxStop RxAct RxRun

Pe
rm
TXACK itt
ed

TxRun TxRun Remote TxRun

TxRun RxAct RxRun Initiate RxDeact

Pe Pe
TXREQ rm Local rm
itt Initiate itt
ed ed

TxDeact TxDeact TxDeact

TxDeact RxRun RxDeact RxStop

Pe Pe
TXACK rm rm
itt itt
ed ed

TxStop TxStop TxStop

TxStop RxDeact RxStop RxAct

Pe
rm
TXREQ itt
ed

TxAct
TxAct RxStop

Figure 12-7 Combined Tx and Rx state machines without race conditions

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-245
ID061214 Confidential
12 Link Handshake
12.7 Protocol layer activity indication

12.7 Protocol layer activity indication

This section describes the signals that indicate Protocol layer activity. It contains the following subsections:
• Introduction.
• TXSACTIVE signal.
• RXSACTIVE signal on page 12-249.
• Relationship between SACTIVE and LINKACTIVE on page 12-249.

12.7.1 Introduction
SACTIVE signaling indicates that there are transactions in progress.

TXSACTIVE is an output signal that is asserted by an interface where there is a transaction either in progress or
about to start:

• TXSACTIVE must be asserted before or in the same cycle in which the first flit relating to a transaction is
sent.

• TXSACTIVE must remain asserted until after the last flit relating to all transactions is sent or received.

This means that the de-assertion of TXSACTIVE on an interface implies that the component has completed all
transactions in progress and does not need to send or receive any further flits.
A transaction that is given a RetryAck response is considered to be in progress, so TXSACTIVE must remain
asserted until the associated credit has been supplied and used or returned.

RXSACTIVE is an input signal which indicates that the other side of the interface has ongoing Protocol layer
activity. When RXSACTIVE is asserted a component must respond to Protocol layer activity in a timely manner.

12.7.2 TXSACTIVE signal

The following rules apply to the TXSACTIVE signal:

• TXSACTIVE must be asserted when the transmitter has flits to send.

• A component that asserts TXSACTIVE must also, if required, initiate the link activation sequence. It is not
permitted for a component to assert the TXSACTIVE signal and then wait for the other side of the interface
to initiate the link activation sequence.

• TXSACTIVE must remain asserted until after the last flit relating to all transactions is sent or received.

• It is permitted for TXSACTIVE to be deasserted while transmitting link flits as part of the link deactivation
sequence.

12-246 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.7 Protocol layer activity indication

Figure 12-8 shows the requirements for TXSACTIVE assertion during the life of a transaction.

RN-F0 RN-F1 RN-F1 ICN-RN ICN-SN SN-F

I I I

ReadUnique

ReadNoSnp

SnpUnique
SnpUnique

SnpResp_I CompData
SnpResp_I

CompData_UC

I->UC

CompAck

Interconnect
=TXSACTIVE

Figure 12-8 TXSACTIVE assertion during the life of a transaction

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-247
ID061214 Confidential
12 Link Handshake
12.7 Protocol layer activity indication

TXSACTIVE signaling from an RN

When initiating new transactions, an RN must assert TXSACTIVE in the same cycle or before TXREQFLITV is
asserted and must keep it asserted until after the final completing flit of a transaction is sent or received.

The type of flit that completes a transaction initiated by an RN will depend on both the transaction type and the
manner in which the transaction progresses. For example, a ReadNoSnp transaction might typically complete with
the receipt of the last CompData flit, but could equally complete with a ReadReceipt, if this is later than the last
CompData flit.

Table 12-6 shows the flit types that can complete a transaction.

Table 12-6 RN completing flits for RN initiated transactions

Completing flit Channel Transaction type

CompAck TXRSP Read, Dataless

Comp RXRSP Dataless, WriteUnique, WriteNoSnp, Barrier, DVM

CompData RXDAT Read

ReadReceipt RXRSP ReadNoSnp, ReadOnce

PCrdReturn TXREQ All transaction types

NonCopyBackWrData TXDAT WriteUnique, WriteNoSnp

CopyBackWrData TXDAT CopyBack

An RN-F or RN-D component must also assert TXSACTIVE while a Snoop transaction is in progress.
TXSACTIVE must be asserted after receiving an initiating Snoop or SnpDVMOp flit, and no later than when its
first Response flit is sent. It must keep TXSACTIVE asserted until after the final completing flit is sent for all
Snoop transactions. The Response flit will be either SnpResp or SnpRespData.

For an RN-F or RN-D the TXSACTIVE output is the logical OR of the requirements for the Request interface and
the Snoop interface.

TXSACTIVE signaling from an SN

An SN cannot initiate new transactions and is only required to assert TXSACTIVE while it is processing a
transaction that is in progress.

It must assert TXSACTIVE after receiving a transaction initiating flit and it must be asserted before or in the same
cycle in which its first Response flit is sent. It must keep TXSACTIVE asserted until after the final completing flit
is sent or received.

TXSACTIVE signaling from an ICN interface to an RN

The interconnect interface to an RN must assert TXSACTIVE in both the following conditions:

• On receiving a transaction initiating flit, it must be asserted before or in the same cycle in which its first
Response flit is sent. It must keep TXSACTIVE asserted until after the final completing flit is sent or
received.

• Before or in the same cycle in which its initiating Snoop or SnpDVMOp flit is sent. It must keep
TXSACTIVE asserted until after the final completing flit is sent, which will be either SnpResp or
SnpRespData.

12-248 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 12 Link Handshake
12.7 Protocol layer activity indication

TXSACTIVE signaling from an ICN interface to an SN

The interconnect interface to an RN must assert TXSACTIVE before, or in the same cycle in which its initiating
Request flit is sent. It must keep TXSACTIVE asserted until after the final completing flit is sent or received.

12.7.3 RXSACTIVE signal

When RXSACTIVE is asserted, the receiver must respond to a link activation request in a timely manner. It is
permitted for a receiver to delay responding to a link activation request when RXSACTIVE is deasserted.

Note
The deassertion of RXSACTIVE does not indicate that all Protocol layer activity has completed. It is possible for
a receiver to receive a Protocol flit, which corresponds to a transaction that was in progress while RXSACTIVE
was asserted, after RXSACTIVE is deasserted.

RXSACTIVE can be used in combination with a knowledge of the ongoing transactions, which will be indicated
by the components TXSACTIVE output, to indicate that no further transactions are required. This can be used to
control entry to a low power state.

12.7.4 Relationship between SACTIVE and LINKACTIVE

SACTIVE signaling is an indication of Protocol layer activity. A node can be considered inactive when both
TXSACTIVE and RXSACTIVE are deasserted.

LINKACTIVE state is an indication of the Link layer activity. The Link layer at a node, or interconnect, can be
considered inactive when its receiver is in TxStop state and its receiver is in RxStop state.

SACTIVE signaling is orthogonal to the LINKACTIVE states with one constraint as specified in RXSACTIVE
signal.

A node, or interconnect, should only enable higher level clock gating and low power optimizations when both its
Protocol and Link layers are inactive.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 12-249
ID061214 Confidential
12 Link Handshake
12.7 Protocol layer activity indication

12-250 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Chapter 13
Optional Interface Signals

This chapter describes the optional signals that provide flexibility in the mapping of domain and Snoopable
attributes. It contains the following sections:
• Broadcast signals on page 13-252.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. 13-251
ID061214 Confidential
13 Optional Interface Signals
13.1 Broadcast signals

13.1 Broadcast signals

The BROADCASTINNER, BROADCASTOUTER, and BROADCASTCACHEMAINTENANCE interface
signals provide:

• Flexibility in mapping the domain and Snoopable attributes provided by the domain partitioning components.

• Efficient maintenance of downstream caches in the interconnect space.

These signals are optional in CHI systems and are not part of the CHI protocol.

A CHI implementation that includes these signals at the interface must ensure that the signal values are stable when
reset is deasserted.

The broadcast signals are used as follows:

BROADCASTINNER
Asserted if the component at the interface must broadcast Inner Snoopable transactions.

BROADCASTOUTER
Asserted if the component at the interface must broadcast Outer Snoopable transactions.
BROADCASTOUTER must also be asserted when BROADCASTINNER is asserted.

BROADCASTCACHEMAINTENANCE
Asserted when CleanShared, CleanInvalid, or MakeInvalid transactions must be broadcast beyond
the interface for maintenance of downstream caches.
When this signal is deasserted, broadcasting of the Cache Maintenance Operation (CMO) beyond
the interface is determined, as Table 13-1 shows, by both:
• The domain attribute of the CMO.
• Assertion of the BROADCASTINNER and BROADCASTOUTER signals.

Table 13-1 shows the broadcast signal encodings using the following keys:
BI BROADCASTINNER.
BO BROADCASTOUTER.
BCM BROADCASTCACHEMAINTENANCE.

Table 13-1 Broadcast signal encodings

Broadcast signal Transaction to be broadcast

BI BO BCM

0 0 0 None.

0 0 1 All CMO transactions irrespective of domain setting.

0 1 0 All Outer transactions.

0 1 1 All Outer transactions. All CMO transactions irrespective of domain setting.

1 0 X Illegal. BROADCASTINNER = 1 requires that BROADCASTOUTER = 1.

1 1 0 All Inner transactions. All outer transactions.

1 1 1 All Inner, Outer, and CMO transactions.

13-252 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Appendix A
Message Field Mappings

This appendix shows the field mappings for the request, response, data, and snoop request messages. It contains the
following sections:
• Request message field mappings on page A-255.
• Response message field mappings on page A-256.
• Data message field mappings on page A-257.
• Snoop Request message field mappings on page A-258.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. A-253
ID061214 Confidential
Appendix A Message Field Mappings

Table A-1 shows the conventions used in the field mapping tables.

Table A-1 Key to field mapping table conventions

Symbol Description

X Field value is not defined and can be any value.

1 Applicable. Field value is used, must be set to

one.

0 Applicable. Field value is used, must be set to

zero.

0a Inapplicable. Field value must be set to zero.

Y Applicable. Field value is used. See

specification for permitted values and usage.

Yb See Table 8-1 on page 8-170 that describes

CCID and DBID field usage in the Data
message of the DVMOp transaction.

Yc Applicable. Field value is used. See Table 8-3

on page 8-175 that describes DVMOp usage of
the Addr field.

8B Size field must be set to 8-byte encoding.

64B Size field must be set to 64-byte encoding.

A-254 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Appendix A Message Field Mappings
A.1 Request message field mappings

A.1 Request message field mappings

Table A-2 shows the request message field mappings. See Table A-1 on page A-254 for the conventions used in the
field mappings. For further information on field use see Protocol flit fields on page 11-215.
Table A-2 Request message field mappings

MemAttr

ExpCompAck
LikelyShared

AllowRetry

Cacheable
Request

PCrdType

Allocate
Opcode

SnpAttr

RSVDC
message

Device
TxnID

Order
SrcID
TgtID

Addr

EWA

LPID

Excl
Size
Qos

NS
ReqLCrdReturn X X X 0 Y X X X X X X X X X X X X X X X X
ReadShared Y Y Y Y Y 64B Y Y Y Y 0 Y Y 1 0 1 Y Y Y 1 Y
ReadClean Y Y Y Y Y 64B Y Y Y Y 0 Y Y 1 0 1 Y Y Y 1 Y
ReadOnce Y Y Y Y Y 64B Y Y 0 Y Y Y Y 1 0 1 Y Y 0 Y Y
ReadNoSnp Y Y Y Y Y Y Y Y 0 Y Y Y Y Y Y Y 00 Y Y Y Y
ReadUnique Y Y Y Y Y 64B Y Y 0 Y 0 Y Y 1 0 1 Y Y 0 1 Y
CleanShared Y Y Y Y Y 64B Y Y 0 Y 0 Y Y Y 0 1 Y Y 0 Y Y
CleanInvalid Y Y Y Y Y 64B Y Y 0 Y 0 Y Y Y 0 1 Y Y 0 Y Y
MakeInvalid Y Y Y Y Y 64B Y Y 0 Y 0 Y Y Y 0 1 Y Y 0 Y Y
CleanUnique Y Y Y Y Y 64B Y Y 0 Y 0 Y Y 1 0 1 Y Y Y 1 Y
MakeUnique Y Y Y Y Y 64B Y Y 0 Y 0 Y Y 1 0 1 Y Y 0 1 Y
Evict Y Y Y Y Y 64B Y Y 0 Y 0 Y 0 1 0 1 Y Y 0 0 Y
EOBarrier Y Y Y Y Y 0a 0a 0a 0a Y 0a Y 0a 0a 0a 0a 00a Y 0a 0 Y
ECBarrier Y Y Y Y Y 0a 0a 0a 0a Y 0a Y 0a 0a 0a 0a 00a Y 0a 0 Y
DVMOp Y Y Y Y Y 8B Yb 0a 0a Y 0a Y 0a 0a 0a 0a 00a Y 0a 0 Y
PCrdReturn Y Y Y 0a Y 0a 0a 0a 0a 0 0a Y 0a 0a 0a 0a 00a 0a 0a 0 Y
WriteEvictFull Y Y Y Y Y 64B Y Y Y Y 0 Y Y 1 0 1 Y Y 0 0 Y
WriteCleanPtl Y Y Y Y Y 64B Y Y 0 Y 0 Y Y 1 0 1 Y Y 0 0 Y
WriteCleanFull Y Y Y Y Y 64B Y Y Y Y 0 Y Y 1 0 1 Y Y 0 0 Y
WriteUniquePtl Y Y Y Y Y Y Y Y Y Y Y Y Y 1 0 1 Y Y 0 Y Y
WriteUniqueFull Y Y Y Y Y 64B Y Y Y Y Y Y Y 1 0 1 Y Y 0 Y Y
WriteBackPtl Y Y Y Y Y 64B Y Y 0 Y 0 Y Y 1 0 1 Y Y 0 0 Y
WriteBackFull Y Y Y Y Y 64B Y Y Y Y 0 Y Y 1 0 1 Y Y 0 0 Y
WriteNoSnpPtl Y Y Y Y Y Y Y Y 0 Y Y Y Y Y Y Y 00 Y Y 0 Y
WriteNoSnpFull Y Y Y Y Y 64B Y Y 0 Y Y Y Y Y Y Y 00 Y Y 0 Y

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. A-255
ID061214 Confidential
Appendix A Message Field Mappings
A.2 Response message field mappings

A.2 Response message field mappings

Table A-3 shows the response message field mappings. See Table A-1 on page A-254 for the conventions used in
the field mappings. For further information on field use see Protocol flit fields on page 11-215.
Table A-3 Response message field mappings

PCrdType
RespErr
Opcode
Response message

TxnID
SrcID
TgtID

Resp

DBID
QoS
RespLCrdReturn X X X 0 Y X X X X
SnpResp Y Y Y Y Y Y Y X 0a
CompAck Y Y Y Y Y 0 0a X 0a
RetryAck Y Y Y Y Y 0 0a X Y
Comp Y Y Y Y Y Y Y Y 0a
CompDBIDResp Y Y Y Y Y Y 0 Y 0a
DBIDResp Y Y Y Y Y 0 0a Y 0a
PCrdGrant Y Y Y 0a Y 0 0a 0a Y
ReadReceipt Y Y Y Y Y 0 0a X 0a

A-256 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Appendix A Message Field Mappings
A.3 Data message field mappings

A.3 Data message field mappings

Table A-4 shows the data message field mappings. See Table A-1 on page A-254 for the conventions used in the
field mappings. For further information on field use see Protocol flit fields on page 11-215.
Table A-4 Data message field mappings

RespErr
Opcode

RSVDC
DataID
TxnID
SrcID
Data Message

TgtID

Resp

DBID

CCID

Data
QoS

BE
DataLCrdReturn X X X 0 Y X X X X X X X X
SnpRespData Y Y Y Y Y Y Y Ya Y Y Y Y Y

CopyBackWrData Y Y Y Y Y Y Y Ya Y Y Y Y Y

NonCopyBackWrData Y Y Y Y Y Y Y Ya Yb Yb Y Y Y

CompData Y Y Y Y Y Y Y Y Y Y Y X Y
SnpRespDataPtl Y Y Y Y Y Y Y Ya Y Y Y Y Y

a. Must be zero or must be set to the TxnID of the originating request. For SnpRespData and SnpRespDataPtl the originating
request is the snoop request.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. A-257
ID061214 Confidential
Appendix A Message Field Mappings
A.4 Snoop Request message field mappings

A.4 Snoop Request message field mappings

Table A-5 shows the snoop request message field mappings. See Table A-1 on page A-254 for the conventions used
in the field mappings. For further information on field use see Protocol flit fields on page 11-215.
Table A-5 Snoop Request message field mappings

Addr[43:3]
Opcode
Snoop Request Message

TxnID
SrcID
QoS

NS
SnpLCrdReturn X X 0 Y X X
SnpShared Y Y Y Y Y Y
SnpClean Y Y Y Y Y Y
SnpOnce Y Y Y Y Y Y
SnpUnique Y Y Y Y Y Y
SnpCleanShared Y Y Y Y Y Y
SnpCleanInvalid Y Y Y Y Y Y
SnpMakeInvalid Y Y Y Y Y Y
SnpDVMOp Y Y Y Y Yc 0a

A-258 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Appendix B
Communicating Nodes

This appendix specifies, for each packet type, the nodes that communicate using that packet type. It contains the
following sections:
• Request communicating nodes on page B-260.
• Snoop communicating nodes on page B-261.
• Response communicating nodes on page B-262.
• Data communicating nodes on page B-263.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. B-259
ID061214 Confidential
Appendix B Communicating Nodes
B.1 Request communicating nodes

B.1 Request communicating nodes

Table B-1 shows the Request communicating nodes.

For some Requests, both an expected target and a permitted target are given. The use of the permitted target can
occur in the case of an incorrect address decode. The permitted target must complete the transaction in a protocol
compliant manner, this might require the use of an error response.

Table B-1 Request communicating nodes

Request From To

Expected Permitted

ReadNoSnp RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

WriteNoSnpFull
ICN(HN-F) SN-F -
WriteNoSnpPtl
ICN(HN-I) SN-I -

ReadClean RN-F ICN(HN-F) ICN(HN-I)

ReadShared
ReadUnique
CleanUnique
MakeUnique
Evict
WriteBackFull
WriteBackPtl
WriteEvictFull
WriteCleanFull
WriteCleanPtl

ReadOnce RN-F, RN-D, RN-I ICN(HN-F) ICN(HN-I)

CleanShared
CleanInvalid
MakeInvalid
WriteUniqueFull
WriteUniquePtl

EOBarrier RN-F, RN-D, RN-I ICN(MN) -

ECBarrier
ICN(HN-I) SN-I -

DVMOp RN-F, RN-D ICN(MN) -

PCrdReturn RN-F, RN-D, RN-I ICN(HN-F, HN-I, MN)

ICN(HN-F) SN-F

ICN(HN-I) SN-I

B-260 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Appendix B Communicating Nodes
B.2 Snoop communicating nodes

B.2 Snoop communicating nodes

Table B-2 shows the Snoop communicating nodes.

Table B-2 Snoop communicating nodes

Snoop From To

SnpOnce ICN(HN-F) RN-F

SnpClean
SnpShared
SnpUnique
SnpCleanShared
SnpCleanInvalid
SnpMakeInvalid

SnpDVMOp ICN(MN) RN-F, RN-D

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. B-261
ID061214 Confidential
Appendix B Communicating Nodes
B.3 Response communicating nodes

B.3 Response communicating nodes

Table B-3 shows the Response communicating nodes.

Table B-3 Response communicating nodes

Response From To

Upstream RetryAck ICN(HN-F, HN-I, MN) RN-F, RN-D, RN-I

DBIDResp
SN-F ICN(HN-F)
PCrdGrant
Comp SN-I ICN(HN-I)

CompDBIDResp ICN(HN-F, HN-I) RN-F, RN-D, RN-I

SN-F ICN(HN-F)

SN-I ICN(HN-I)

ReadReceipt ICN(HN-F, HN-I) RN-F, RN-D, RN-I

SN-I ICN(HN-I)

Downstream CompAck RN-F, RN-D, RN-I ICN(HN-F, HN-I)

SnpResp RN-F ICN(HN-F)

RN-F, RN-D ICN(MN)

B-262 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Appendix B Communicating Nodes
B.4 Data communicating nodes

B.4 Data communicating nodes

Table B-4 shows the Data communicating nodes.

For some Data, both an expected target and a permitted target are given. The use of the permitted target can occur
in the case of an incorrect address decode. The permitted target must complete the transaction in a protocol
compliant manner.

Table B-4 Data communicating nodes

Data From To

Expected Permitted

Upstream CompData ICN(HN-F, HN-I) RN-F, RN-D, RN-I -

SN-F ICN(HN-F) -

SN-I ICN(HN-I) -

Downstream CopyBackWrData RN-F ICN(HN-F) ICN(HN-I)

NonCopyBackWrData RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

RN-F, RN-D ICN(MN) -

ICN(HN-F) SN-F -

ICN(HN-I) SN-I -

SnpRespData RN-F ICN(HN-F) -

SnpRespDataPtl

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. B-263
ID061214 Confidential
Appendix B Communicating Nodes
B.4 Data communicating nodes

B-264 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Appendix C
Revisions

This appendix describes the technical changes between released issues of this specification.

Table C-1 Issue A

Change Location Affects

No changes, first release − −

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. C-265
ID061214 Confidential
Appendix C Revisions

C-266 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
Glossary

This glossary describes some of the technical terms used in AMBA 5 CHI documentation.

Advanced Microcontroller Bus Architecture (AMBA)

The AMBA family of protocol specifications is the ARM open standard for on-chip buses. AMBA provides
solutions for the interconnection and management of the functional blocks that make up a System-on-Chip (SoC).
Applications include the development of embedded systems with one or more processors or signal processors and
multiple peripherals.

Aligned A data item stored at an address that is divisible by the highest power of 2 that divides into its size in bytes. Aligned
halfwords, words, and doublewords therefore have addresses that are divisible by 2, 4, and 8 respectively.

An aligned access is one where the address of the access is aligned to the size of each element of the access.

AMBA See Advanced Microcontroller Bus Architecture (AMBA).

At approximately the same time

Two events occur at approximately the same time if a remote observer might not be able to determine the order in
which they occurred.

Barrier An operation that forces a defined ordering of other actions.

Blocking Describes an operation that prevents following actions from continuing until the operation completes.

A non-blocking operation can permit following operations to continue before it completes.

Byte An 8-bit data item.

Cache Any cache, buffer, or other storage structure that can hold a copy of the data value for a particular address location.

Cache line The basic unit of storage in a cache. Its size in words is always a power of two. A cache line must be aligned to the
size of the cache line.

The size of the cache line is equivalent to the coherency granule.

See also Coherency granule.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. Glossary-267
ID061214 Confidential
Glossary

Channel A set of signals grouped together to communicate a particular set of messages between a transmitter and receiver
pair. For example Request channel is used to communicate request messages.

A channels consist of a set of information signals and a separate Valid and Credit signal to provide the channel
handshake mechanism.

Coherent Data accesses from a set of observers to a memory location are coherent accesses to that memory location by the
members of the set of observers are consistent with there being a single total order of all writes to that memory
location by all members of the set of observers.

Coherency granule
The minimum size of the block of memory affected by any coherency consideration. For example, an operation to
make two copies of an address coherent makes the two copies of a block of memory coherent, where that block of
memory is:
• At least the size of the coherency granule.
• Aligned to the size of the coherency granule.

See also Cache line.

Completer See Completer on page 1-21.

Component A distinct functional unit that has at least one AMBA interface. Component can be used as a general term for master,
slave, peripheral, and interconnect components.
See also Interconnect component, Master component, Memory slave component, Peripheral slave component,
Slave component.

Deprecated Something that is present in the specification for backwards compatibility. Whenever possible you must avoid using
deprecated features. These features might not be present in future versions of the specification.

Device See Peripheral slave component.

Don’t Care See Don’t Care on page 1-22.

Downstream A transaction operates between a master component and one or more slave components, and can pass through one
or more intermediate components. At any intermediate component, for a given transaction, downstream means
between that component and a destination slave component, and includes the destination slave component.

Downstream and upstream are defined relative to the transaction as a whole, not relative to individual data flows
within the transaction.

See also Master component, Slave component, Upstream.

Downstream Cache
See Downstream cache on page 1-21.

Endpoint See Endpoint on page 1-22.

Flit See Flit on page 1-21.

HN See HN on page 1-22.

ICN See ICN on page 1-22.

In a timely manner
See In a timely manner on page 1-22.
IMPLEMENTATION DEFINED
Behavior that is not defined by the architecture, but is defined and documented by individual implementations.

When IMPLEMENTATION DEFINED appears in body text, it is always in small capitals.

Glossary-268 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Glossary

IMPLEMENTATION SPECIFIC
Behavior that is not architecturally defined, and might not be documented by an individual implementation. Used
when there are a number of implementation options available and the option chosen does not affect software
compatibility.

When IMPLEMENTATION SPECIFIC appears in body text, it is always in small capitals.

Interconnect component
A component with more than one AMBA interface that connects one or more master components to one or more
slave components.

An interconnect component can be used to group together either:

• A set of masters so that they appear as a single master interface.
• A set of slaves so that they appear as a single slave interface.

See also Component, Master component, Slave component.

IO Coherent node
See IO Coherent node on page 1-22.

Line See Cache line.

Link A Link is the connection used for communicating between a transmitter and receiver pair.

Link layer Credit

See Link layer Credit on page 1-22.

Load The action of a master component reading the value held at a particular address location. For a processor, a load
occurs as the result of executing a particular instruction. Whether the load results in the master issuing a read
transaction depends on whether the accessed cache line is held in the local cache.

See also Speculative read, Store.

Main memory The memory that holds the data value of an address location when no cached copies of that location exist. For any
location, main memory can be out of date with respect to the cached copies of the location, but main memory is
updated with the most recent data value when no cached copies exist neither in the RNs nor in the Interconnect.

Main memory can be referred to as memory when the context makes the intended meaning clear.

Master See Master on page 1-21.

Master component
A component that initiates transactions.

It is possible that a single component can act as both a master component and as a slave component. For example,
a Direct Memory Access (DMA) component can be a master component when it is initiating transactions to move
data, and a slave component when it is being programmed.

See also Component, Interconnect component, Slave component.

Memory Management Unit (MMU)

Provides detailed control of the part of a memory system that provides address translation. Most of the control is
provided using translation tables that are held in memory, and define the attributes of different regions of the
physical memory map.

See also System Memory Management Unit (SMMU).

Memory slave component

A memory slave component, or memory slave, is a slave component with the following properties:
• A read of a byte from a memory slave returns the last value written to that byte location.
• A write to a byte location in a memory slave updates the value at that location to a new value that is obtained
by subsequent reads.
• Reading a location multiple times has no side-effects on any other byte location.
• Reading or writing one byte location has no side-effects on any other byte location.

See also Component, Master component, Peripheral slave component.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. Glossary-269
ID061214 Confidential
Glossary

Message See Message on page 1-21.

Observer A processor or other master component, such as a peripheral device, that can generate reads from or writes to
memory.

Outstanding Request
A transaction is outstanding from the cycle that the Request is first issued until either:

• The transaction is fully completed, as determined by the return of all ReadReceipt, CompData, DBIDResp,
Comp, CompDBIDResp responses that are expected for the transaction.

• It receives RetryAck and PCrdGrant and is either:

— Retried using a credit of the appropriate PCrdType, and then is fully completed as determined above.
— Cancelled, and returns the received credit using the PCrdReturn message.

Peer node A protocol node of the same type with reference to itself. For example, the peer node for a Request Node is another
Request Node.

Peripheral slave component

A peripheral slave component is also described as a peripheral slave. This specification recommends that a
peripheral slave has an IMPLEMENTATION DEFINED method of access that is typically described in the data sheet for
the component. Any access that is not defined as permitted might cause the peripheral slave to fail, but must
complete in a protocol-compliant manner to prevent system deadlock. The protocol does not require continued
correct operation of the peripheral.

See also Memory slave component, Slave component.

Permission to store
A component has permission to store if it can perform a store to the associated cache line without informing any
other components or the interconnect.

Packet See Packet on page 1-21.

Phit See Phit on page 1-21.

PoC See PoC on page 1-21.

PoS See PoS on page 1-21.

Prefetching Prefetching refers to speculatively fetching instructions or data from the memory system. In particular, instruction
prefetching is the process of fetching instructions from memory before the instructions that precede them, in simple
sequential execution of the program, have finished executing. Prefetching an instruction does not mean that the
instruction has to be executed.

In this specification, references to instruction or data fetching apply also to prefetching, unless the context explicitly
indicates otherwise.
Protocol Credit See Protocol Credit on page 1-22.

Requester See Requester on page 1-21.

RN See RN on page 1-22.

Slave See Slave on page 1-21.

Slave component
A component that receives transactions and responds to them.

It is possible that a single component can act as both a slave component and as a master component. For example,
a Direct Memory Access (DMA) component can be a slave component when it is being programmed and a master
component when it is initiating transactions to move data.

See also Master component, Memory slave component, Peripheral slave component.

SN See SN on page 1-22.

Snooped cache A hardware-coherent cache that receives Snoop transactions.

Glossary-270 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214
 Glossary

Snoop filter A snoop filter is able to track the cache lines that might be allocated within a master.

Speculative read
A transaction that a component issues when it might not need the transaction to be performed because it already has
a copy of the accessed cache line in its local cache. Typically, a speculative read is performed in parallel with a local
cache lookup. This gives lower latency than looking in the local cache first, and then issuing a read transaction only
if the required cache line is not found in the local cache.

See also Load.

Store The action of a master component changing the value held at a particular address location. For a processor, a store
occurs as the result of executing a particular instruction. Whether the store results in the master issuing a read or
write transaction depends on whether the accessed cache line is held in the local cache, and if it is in the local cache,
the state it is in.

See also Load, Permission to store.

Synchronization barrier
See Barrier.

System Memory Management Unit (SMMU)

A system-level MMU. That is, a system component that provides address translation from one address space to
another. An SMMU provides one or more of:
• Virtual Address (VA) to Physical Address (PA) translation.
• VA to Intermediate Physical Address (IPA) translation.
• IPA to PA translation.

See also Memory Management Unit (MMU).

TLB See Translation Lookaside Buffer (TLB).

Transaction See Transaction on page 1-21.

Translation Lookaside Buffer (TLB)

A memory structure containing the results of translation table walks. TLBs help to reduce the average cost of a
memory access.

See also System Memory Management Unit (SMMU), Translation table, Translation table walk.

Translation table
A table held in memory that defines the properties of memory areas of various sizes from 1KB.

See also Translation Lookaside Buffer (TLB), Translation table walk.

Translation table walk

The process of doing a full translation table lookup.

See also Translation Lookaside Buffer (TLB), Translation table.

Unaligned An unaligned access is an access where the address of the access is not aligned to the size of an element of the access.

Unaligned memory accesses

Are memory accesses that are not, or might not be, appropriately halfword-aligned, word-aligned, or
doubleword-aligned.

See also Aligned.

UNPREDICTABLE In the AMBA Architecture means that the behavior cannot be relied upon.

UNPREDICTABLE behavior must not be documented or promoted as having a defined effect.

When UNPREDICTABLE appears in body text, it is always in small capitals.

ARM IHI 0050A Copyright © 2014 ARM. All rights reserved. Glossary-271
ID061214 Confidential
Glossary

Upstream A transaction operates between a master component and one or more slave components, and can pass through one
or more intermediate components. At any intermediate component, for a given transaction, upstream means
between that component and the originating master component, and includes the originating master component.

Downstream and upstream are defined relative to the transaction as a whole, not relative to individual data flows
within the transaction.

See also Downstream, Master component, Slave component.

Write-Back cache
A cache in which, when a store is permitted to store, the data is only written to the cache. Data in the cache can
therefore be more up-to-date than data in main memory. Any such data is written back to next level cache or main
memory when the cache line is cleaned or re-allocated. Another common term for a Write-Back cache is a
Copy-Back cache.

Write-Invalidate protocol
See Write-Invalidate protocol on page 1-22.

Glossary-272 Copyright © 2014 ARM. All rights reserved. ARM IHI 0050A
Confidential ID061214