AMBA 5 CHI

Architecture Specification

Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved.
ARM IHI 0050E.c (ID092622)
 AMBA 5 CHI
Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved.
Release Information

Change history lists the changes made to this specification.

Change history

Date Issue Confidentiality Change

12 June 2014 A Confidential First limited release

04 August 2017 B Non-Confidential First public release

08 May 2018 C Non-Confidential Second public release

28 August 2019 D Non-Confidential Third public release

19 August 2020 E.a Non-Confidential Fourth public release

16 August 2021 E.b Non-Confidential Fifth public release

26 September 2022 E.c Non-Confidential Sixth public release

Proprietary Notice

This document is NON-CONFIDENTIAL and any use by you is subject to the terms of this notice and the Arm AMBA
Specification Licence set about below.

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 for the purposes of determining whether implementations infringe any third party patents.

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, 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.

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.

The Arm corporate logo and words marked with ® or ™ are registered trademarks or trademarks of Arm Limited (or its
subsidiaries) in the US 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
http://www.arm.com/company/policies/trademarks.

Copyright © 2014, 2017-2022 Arm Limited (or its affiliates). All rights reserved.

ii Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Arm Limited. Company 02557590 registered in England.
110 Fulbourn Road, Cambridge, England CB1 9NJ.
LES-PRE-21451 version 2.2

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. iii
ID092622 Non-Confidential
 AMBA SPECIFICATION LICENCE

THIS END USER LICENCE AGREEMENT ("LICENCE") IS A LEGAL AGREEMENT BETWEEN YOU (EITHER A
SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED ("ARM") FOR THE USE OF ARM'S
INTELLECTUAL PROPERTY (INCLUDING, WITHOUT LIMITATION, ANY COPYRIGHT) IN THE RELEVANT AMBA
SPECIFICATION ACCOMPANYING THIS LICENCE. ARM LICENSES THE RELEVANT AMBA SPECIFICATION TO
YOU ON CONDITION THAT YOU ACCEPT ALL OF THE TERMS IN THIS LICENCE. BY CLICKING "I AGREE" OR
OTHERWISE USING OR COPYING THE RELEVANT AMBA SPECIFICATION YOU INDICATE THAT YOU AGREE TO
BE BOUND BY ALL THE TERMS OF THIS LICENCE.

"LICENSEE" means You and your Subsidiaries.

"Subsidiary" means, if You are a single entity, any company the majority of whose voting shares is now or hereafter owned or
controlled, directly or indirectly, by You. A company shall be a Subsidiary only for the period during which such control exists.

1. Subject to the provisions of Clauses 2, 3 and 4, Arm hereby grants to LICENSEE a perpetual, non-exclusive,
non-transferable, royalty free, worldwide licence to:
(i) use and copy the relevant AMBA Specification for the purpose of developing and having developed products
that comply with the relevant AMBA Specification;
(ii) manufacture and have manufactured products which either: (a) have been created by or for LICENSEE under
the licence granted in Clause 1(i); or (b) incorporate a product(s) which has been created by a third party(s)
under a licence granted by Arm in Clause 1(i) of such third party's AMBA Specification Licence; and
(iii) offer to sell, sell, supply or otherwise distribute products which have either been (a) created by or for
LICENSEE under the licence granted in Clause 1(i); or (b) manufactured by or for LICENSEE under the
licence granted in Clause 1(ii).

2. LICENSEE hereby agrees that the licence granted in Clause 1 is subject to the following restrictions:
(i) where a product created under Clause 1(i) is an integrated circuit which includes a CPU then either: (a) such
CPU shall only be manufactured under licence from Arm; or (b) such CPU is neither substantially compliant
with nor marketed as being compliant with the Arm instruction sets licensed by Arm from time to time;
(ii) the licences granted in Clause 1(iii) shall not extend to any portion or function of a product that is not itself
compliant with part of the relevant AMBA Specification; and
(iii) no right is granted to LICENSEE to sublicense the rights granted to LICENSEE under this Agreement.

3. Except as specifically licensed in accordance with Clause 1, LICENSEE acquires no right, title or interest in any Arm
technology or any intellectual property embodied therein. In no event shall the licences granted in accordance with Clause
1 be construed as granting LICENSEE, expressly or by implication, estoppel or otherwise, a licence to use any Arm
technology except the relevant AMBA Specification.

4. THE RELEVANT AMBA SPECIFICATION IS PROVIDED "AS IS" WITH NO REPRESENTATION OR

WARRANTIES EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
OF SATISFACTORY QUALITY, MERCHANTABILITY, NON-INFRINGEMENT OR FITNESS FOR A
PARTICULAR PURPOSE, OR THAT ANY USE OR IMPLEMENTATION OF SUCH ARM TECHNOLOGY WILL
NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE SECRETS OR OTHER INTELLECTUAL
PROPERTY RIGHTS.

5. NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED IN THIS AGREEMENT, TO THE

FULLEST EXTENT PETMITTED BY LAW, THE MAXIMUM LIABILITY OF ARM IN AGGREGATE FOR ALL
CLAIMS MADE AGAINST ARM, IN CONTRACT, TORT OR OTHERWISE, IN CONNECTION WITH THE
SUBJECT MATTER OF THIS AGREEMENT (INCLUDING WITHOUT LIMITATION (I) LICENSEE'S USE OF THE
ARM TECHNOLOGY; AND (II) THE IMPLEMENTATION OF THE ARM TECHNOLOGY IN ANY PRODUCT
CREATED BY LICENSEE UNDER THIS AGREEMENT) SHALL NOT EXCEED THE FEES PAID (IF ANY) BY
LICENSEE TO ARM UNDER THIS AGREEMENT. THE EXISTENCE OF MORE THAN ONE CLAIM OR SUIT
WILL NOT ENLARGE OR EXTEND THE LIMIT. LICENSEE RELEASES ARM FROM ALL OBLIGATIONS,
LIABILITY, CLAIMS OR DEMANDS IN EXCESS OF THIS LIMITATION.

6. No licence, express, implied or otherwise, is granted to LICENSEE, under the provisions of Clause 1, to use the Arm
tradename, or AMBA trademark in connection with the relevant AMBA Specification or any products based thereon.
Nothing in Clause 1 shall be construed as authority for LICENSEE to make any representations on behalf of Arm in respect
of the relevant AMBA Specification.

7. This Licence shall remain in force until terminated by you or by Arm. Without prejudice to any of its other rights if
LICENSEE is in breach of any of the terms and conditions of this Licence then Arm may terminate this Licence
immediately upon giving written notice to You. You may terminate this Licence at any time. Upon expiry or termination

iv Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 of this Licence by You or by Arm LICENSEE shall stop using the relevant AMBA Specification and destroy all copies of
the relevant AMBA Specification in your possession together with all documentation and related materials. Upon expiry
or termination of this Licence, the provisions of clauses 6 and 7 shall survive.

8. The validity, construction and performance of this Agreement shall be governed by English Law.

Confidentiality Status

This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions in
accordance with the terms of the agreement entered into by Arm and the party that Arm delivered this document to.

Product Status

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

Web Address

http://www.arm.com

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. v
ID092622 Non-Confidential
vi Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Contents
AMBA 5 CHI Architecture Specification

Preface
About this specification .............................................................................................. xii
Feedback ................................................................................................................. xvii

Chapter 1 Introduction
1.1 Architecture overview ............................................................................................. 1-20
1.2 Topology ................................................................................................................ 1-23
1.3 Terminology ........................................................................................................... 1-24
1.4 Transaction classification ....................................................................................... 1-27
1.5 Coherence overview .............................................................................................. 1-31
1.6 Component naming ................................................................................................ 1-33
1.7 Read data source ................................................................................................... 1-35

Chapter 2 Transactions
2.1 Channels overview ................................................................................................. 2-38
2.2 Channel fields ........................................................................................................ 2-39
2.3 Transaction structure ............................................................................................. 2-46
2.4 Transaction identifier fields .................................................................................... 2-93
2.5 Transaction identifier field flows ........................................................................... 2-100
2.6 Ordering ............................................................................................................... 2-121
2.7 Address, Control, and Data .................................................................................. 2-133
2.8 Data transfer ........................................................................................................ 2-142
2.9 Request Retry ...................................................................................................... 2-154

Chapter 3 Network Layer

3.1 System Address Map, SAM ................................................................................. 3-160
3.2 Node ID ................................................................................................................ 3-161
3.3 Target ID determination ....................................................................................... 3-162
3.4 Network layer flow examples ............................................................................... 3-165

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. vii
ID092622 Non-Confidential
 Chapter 4 Coherence Protocol
4.1 Cache line states .................................................................................................. 4-170
4.2 Request types ...................................................................................................... 4-172
4.3 Snoop request types ............................................................................................ 4-201
4.4 Request transactions and corresponding Snoop requests ................................... 4-204
4.5 Response types .................................................................................................... 4-208
4.6 Silent cache state transitions ................................................................................ 4-220
4.7 Cache state transitions at a Requester ................................................................ 4-221
4.8 Cache state transitions at a Snoopee .................................................................. 4-232
4.9 Returning Data with Snoop response ................................................................... 4-251
4.10 Do not transition to SD ......................................................................................... 4-252
4.11 Hazard conditions ................................................................................................. 4-253

Chapter 5 Interconnect Protocol Flows

5.1 Read transaction flows ......................................................................................... 5-256
5.2 Dataless transaction flows .................................................................................... 5-266
5.3 Write transaction flows ......................................................................................... 5-270
5.4 Atomic transaction flows ....................................................................................... 5-273
5.5 Stash transaction flows ........................................................................................ 5-280
5.6 Hazard handling examples ................................................................................... 5-283

Chapter 6 Exclusive accesses

6.1 Overview .............................................................................................................. 6-292
6.2 Exclusive monitors ............................................................................................... 6-293
6.3 Exclusive transactions .......................................................................................... 6-296

Chapter 7 Cache Stashing

7.1 Overview .............................................................................................................. 7-304
7.2 Write with Stash hint ............................................................................................. 7-306
7.3 Independent Stash request .................................................................................. 7-307
7.4 Stash target identifiers .......................................................................................... 7-309
7.5 Stash messages ................................................................................................... 7-310

Chapter 8 DVM Operations

8.1 DVM transaction flow ........................................................................................... 8-314
8.2 DVM Operation types ........................................................................................... 8-323
8.3 DVM Operations ................................................................................................... 8-330

Chapter 9 Error Handling

9.1 Error types ............................................................................................................ 9-342
9.2 Error response fields ............................................................................................ 9-343
9.3 Errors and transaction structure ........................................................................... 9-344
9.4 Error response use by transaction type ................................................................ 9-345
9.5 Poison .................................................................................................................. 9-355
9.6 Data Check ........................................................................................................... 9-356
9.7 Use of interface parity .......................................................................................... 9-357
9.8 Interoperability of Poison and DataCheck ............................................................ 9-360
9.9 Hardware and software error categories .............................................................. 9-361

Chapter 10 Quality of Service

10.1 Overview ............................................................................................................ 10-364
10.2 QoS priority value ............................................................................................... 10-365
10.3 Repeating a transaction with higher QoS value ................................................. 10-366

Chapter 11 System Debug, Trace, and Monitoring

11.1 Data Source indication ....................................................................................... 11-368
11.2 SLC replacement hint ......................................................................................... 11-371

viii Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 11.3 MPAM ................................................................................................................ 11-373
11.4 Completer Busy ................................................................................................. 11-375
11.5 Trace Tag ........................................................................................................... 11-376

Chapter 12 Memory Tagging

12.1 Introduction ........................................................................................................ 12-380
12.2 Message extensions .......................................................................................... 12-381
12.3 Tag coherency ................................................................................................... 12-382
12.4 Read transaction rules ....................................................................................... 12-383
12.5 Write transactions .............................................................................................. 12-386
12.6 Dataless transactions ......................................................................................... 12-388
12.7 Atomic transactions ............................................................................................ 12-389
12.8 Stash transactions ............................................................................................. 12-390
12.9 Snoop requests .................................................................................................. 12-391
12.10 Home to Subordinate transactions ..................................................................... 12-393
12.11 Error response ................................................................................................... 12-394
12.12 Requests and permitted tag operations ............................................................. 12-396
12.13 TagOp field use summary .................................................................................. 12-398

Chapter 13 Link Layer

13.1 Introduction ........................................................................................................ 13-402
13.2 Link .................................................................................................................... 13-403
13.3 Flit ...................................................................................................................... 13-404
13.4 Channel .............................................................................................................. 13-405
13.5 Port .................................................................................................................... 13-407
13.6 Node interface definitions .................................................................................. 13-408
13.7 Increasing inter-port bandwidth .......................................................................... 13-410
13.8 Channel interface signals ................................................................................... 13-414
13.9 Flit packet definitions ......................................................................................... 13-418
13.10 Protocol flit fields ................................................................................................ 13-424
13.11 Link flit ................................................................................................................ 13-450

Chapter 14 Link Handshake

14.1 Clock, and initialization ...................................................................................... 14-452
14.2 Link layer Credit ................................................................................................. 14-453
14.3 Low power signaling .......................................................................................... 14-454
14.4 Flit level clock gating .......................................................................................... 14-455
14.5 Interface activation and deactivation .................................................................. 14-456
14.6 Transmit and receive link Interaction ................................................................. 14-462
14.7 Protocol layer activity indication ......................................................................... 14-468

Chapter 15 System Coherency Interface

15.1 Overview ............................................................................................................ 15-474
15.2 Handshake ......................................................................................................... 15-475

Chapter 16 Properties, Parameters, and Broadcast Signals

16.1 Interface properties and parameters .................................................................. 16-478
16.2 Optional interface broadcast signals .................................................................. 16-482
16.3 Atomic transaction support ................................................................................ 16-486

Appendix A Message Field Mappings

A.1 Request message field mappings ........................................................................ A-491
A.2 Response message field mappings ..................................................................... A-496
A.3 Data message field mappings .............................................................................. A-497
A.4 Snoop Request message field mappings ............................................................ A-498

Appendix B Communicating Nodes

B.1 Request communicating nodes ............................................................................ B-500

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ix
ID092622 Non-Confidential
 B.2 Snoop communicating nodes .............................................................................. B-502
B.3 Response communicating nodes ........................................................................ B-503
B.4 Data communicating nodes ................................................................................. B-504

Appendix C Revisions

Glossary

x Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Preface

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

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. xi
ID092622 Non-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, transaction structures, transaction ID flows, and the supported transaction ordering.

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 Cache Stashing

Read this for a description of the cache stashing mechanism whereby data can be installed in a
cache.

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 System Debug, Trace, and Monitoring

Read this for a description of the mechanisms that provide additional support for the debugging,
tracing, and performance measurement of systems.

Chapter 12 Memory Tagging

Read this for a description of the Memory Tagging Extension (MTE) that provides a mechanism to
check the correct usage of data held in memory.

xii Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Preface
About this specification

Chapter 13 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 14 Link Handshake

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

Chapter 15 System Coherency Interface

Read this for a description of the interface signals that support connecting and disconnecting
components from both the Coherency and DVM domains.

Chapter 16 Properties, Parameters, and Broadcast Signals

Read this for a description of the optional signals that provide flexibility in configuring optional
interface properties.

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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. xiii
ID092622 Non-Confidential
Preface
About this specification

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

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 components used in timing diagrams are explained in the figure, Key to timing diagram conventions. Variations
have clear labels, when they occur. Do 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.

xiv Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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
Allocation
I

Initial cache
state

REQ

Direction of
message flow

RESP

Lifetime of a
transaction

Allocated but forward

progress is blocked

Forward progress
is unblocked Time
I->UC

Cache state Deallocation

change

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 a protocol node is shown by an elongated shaded rectangle along the time axis
from allocation to the deallocation 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. xv
ID092622 Non-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 Arm Developer https://developer.arm.com/documentation, for access to Arm documentation.

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

xvi Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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 [email protected]. Give:
• The title, AMBA 5 CHI Architecture Specification.
• The number, ARM IHI 0050E.c.
• The page numbers to which your comments apply.
• A concise explanation of your comments.

Arm also welcomes general suggestions for additions and improvements.

Progressive terminology commitment

Arm values inclusive communities. Arm recognizes that we and our industry have used terms that can be offensive.

Arm strives to lead the industry and create change.

Previous issues of this document included terms that can be offensive. We have replaced these terms. If you find
offensive terms in this document, please contact [email protected].

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. xvii
ID092622 Non-Confidential
Preface
Feedback

xviii Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-20
• Topology on page 1-23
• Terminology on page 1-24
• Transaction classification on page 1-27
• Coherence overview on page 1-31
• Component naming on page 1-33
• Read data source on page 1-35

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-19
ID092622 Non-Confidential
Introduction
1.1 Architecture overview

1.1 Architecture overview

The CHI architecture is a scalable, coherent hub interface and on-chip interconnect used by multiple
components.The CHI architecture allows for flexible topologies of component connections, driven by performance,
power, and area system requirements.

1.1.1 Components
The components of CHI-based systems can comprise of:
• Standalone processors
• Processor clusters
• Graphic processors
• Memory controllers
• I/O bridges
• PCIe subsystems
• Interconnects

1.1.2 Key features

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 with forwarding of data from any cache state.
— Additional partial and empty cache line states.

• The CHI transaction set includes:

— Enriched transaction types that permit performance, area, and power efficient system cache
implementation.
— Support for atomic operations and synchronization within the interconnect.
— Support for the efficient execution of Exclusive accesses.
— Transactions for the efficient movement and placement of data, to move data in a timely manner closer
to the point of anticipated use.
— Virtual memory management through Distributed Virtual Memory (DVM) operations.

• Request retry to manage protocol resources.

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

• Support for the Arm Memory Tagging Extension (MTE).

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

• ARM TrustZone™ support on a transaction-by-transaction basis.

• Optimized transaction flow for coherent writes with a producer-consumer ordering model.

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

1-20 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.1 Architecture overview

• Handling sub cache line data errors using Data Poisoning and per byte error indication.

• 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-21
ID092622 Non-Confidential
Introduction
1.1 Architecture overview

1.1.3 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 topmost 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 the source and target Node IDs required to route the packet
over the interconnect to the required destination and add to the packet.

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.

1-22 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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
12 13 14 15 2

3
4×4 Mesh

4 5 6 7

Protocol node such as processor complex, Memory Controller, 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 trade-off between interconnect wiring efficiency and latency. The latency
increases linearly 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-23
ID092622 Non-Confidential
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 message is 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
A packet is 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 can
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
FLow control unIT (Flit) is the smallest flow control unit. A packet can 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
PHysical layer transfer unIT (Phit) is defined as one transfer between two adjacent network
devices. A flit can be made up of one or more phits.

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

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

PoC
Point of Coherence (PoC) is 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.

PoP
Point of Persistence (PoP) is the point in a memory system, if it exists, at or beyond the Point
of Coherency, where a write to memory is maintained when system power is removed, and
reliably recovered when power is restored to the affected locations in memory.

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 send a Request with data to allocate data into a downstream cache.

1-24 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.3 Terminology

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. The term Requester can
also be used for an interconnect component that issues a downstream Request message
independently or 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, such as Home Node or a Misc Node,
or a component, such as a Subordinate, that is outside of the interconnect.

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

Endpoint
Another name for a Subordinate 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) is a credit for a single hop at the Link layer.

ICN
Interconnect (ICN) 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.

IPA
Intermediate Physical Address (IPA). In two stage address translation:
• Stage one results in an Intermediate Physical Address.
• Stage two provides the Physical Address.

RN
Request Node (RN) generates protocol transactions, including reads and writes, to the
interconnect.

HN
Home Node (HN) is a node located within the interconnect that receives protocol
transactions from Request Nodes, completes the required Coherency action, and returns a
Response.

SN
Subordinate Node (SN) is a node that receives a Request from a Home Node, completes the
required action, and returns a Response.

MN
Misc or Miscellaneous Node (MN) is a node located within the interconnect that receives
DVM messages from Request Nodes, completes the required action, and returns a
Response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-25
ID092622 Non-Confidential
Introduction
1.3 Terminology

IO Coherent node
A Request Node that generates a subset of 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.

Snoopee
A Request Node that is receiving a snoop.

Write-Invalidate protocol
A protocol in which a Request Node 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.

Inapplicable
A field value that indicates that the field is not used in the processing of the message.

1-26 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.4 Transaction classification

1.4 Transaction classification

The protocol transactions that this specification supports, and their major classification, are listed in Table 1-2.

Table 1-2 Transaction classification

Classification Supporting transactions

Read ReadNoSnp, ReadNoSnpSep

ReadOnce

ReadOnceCleanInvalid

ReadOnceMakeInvalid

ReadClean

ReadNotSharedDirty

ReadShared

ReadUnique

ReadPreferUnqiue

MakeReadUnique

Dataless CleanUnique

MakeUnique

Evict

StashOnceUnique, StashOnceSepUnique

StashOnceShared, StashOnceSepShared

CleanShared

CleanSharedPersist, CleanSharedPersistSep

CleanInvalid

MakeInvalid

Write WriteNoSnpPtl, WriteNoSnpFull, WriteNoSnpZero

WriteUniquePtl, WriteUniqueFull, WriteUniqueZero

WriteUniquePtlStash, WriteUniqueFullStash

WriteBackPtl, WriteBackFull

WriteCleanFull

WriteEvictFull, WriteEvictOrEvict

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-27
ID092622 Non-Confidential
Introduction
1.4 Transaction classification

Table 1-2 Transaction classification (continued)

Classification Supporting transactions

Combined Write WriteNoSnpPtlCleanInv, WriteNoSnpPtlCleanSh, WriteNoSnpPtlCleanShPerSep

WriteNoSnpFullCleanInv, WriteNoSnpFullCleanSh,
WriteNoSnpFullCleanShPerSep

WriteUniquePtlCleanSh, WriteUniquePtlCleanShPerSep

WriteUniqueFullCleanSh, WriteUniqueFullCleanShPerSep

WriteBackFullCleanInv, WriteBackFullCleanSh, WriteBackFullCleanShPerSep

WriteCleanFullCleanSh, WriteCleanFullCleanShPerSep

Atomic AtomicStore

AtomicLoad

AtomicSwap

AtomicCompare

Other DVMOp

PrefetchTgt

PCrdReturn

1-28 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.4 Transaction classification

Table 1-2 Transaction classification (continued)

Classification Supporting transactions

Snoop SnpOnceFwd

SnpOnce

SnpStashUnique

SnpStashShared

SnpCleanFwd

SnpClean

SnpNotSharedDirtyFwd

SnpNotSharedDirty

SnpSharedFwd

SnpShared

SnpUniqueFwd

SnpUnique

SnpPreferUniqueFwd

SnpPreferUnique

SnpUniqueStash

SnpCleanShared

SnpCleanInvalid

SnpMakeInvalid

SnpMakeInvalidStash

SnpQuery

SnpDVMOp

Table 1-3 shows the representations of transactions.

Table 1-3 Representation of transactions

Specification use Represents collectively

ReadOnce* ReadOnce, ReadOnceCleanInvalid, and ReadOnceMakeInvalid

WriteNoSnp WriteNoSnpPtl and WriteNoSnpFull

WriteUnique WriteUniquePtl, WriteUniqueFull, WriteUniquePtlStash, and

WriteUniqueFullStash

WriteBack WriteBackPtl and WriteBackFull

StashOnce StashOnceUnique and StashOnceShared

StashOnceSep StashOnceSepUnique and StashOnceSepShared

StashOnce* StashOnce and StashOnceSep

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-29
ID092622 Non-Confidential
Introduction
1.4 Transaction classification

Table 1-3 Representation of transactions (continued)

Specification use Represents collectively

StashOnce*Shared StashOnceShared and StashOnceSepShared

StashOnce*Unique StashOnceUnique and StashOnceSepUnique

CleanSharedPersist* CleanSharedPersist and CleanSharedPersistSep

SnpStash* SnpStashUnique and SnpStashShared

DBIDResp* DBIDResp and DBIDRespOrd

1-30 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.5 Coherence overview

1.5 Coherence overview

Hardware coherency enables system components to share memory without the requirement of software cache
maintenance to maintain coherency.

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 Requester 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 Requester components.

Requester 1 Requester 2 Requester 3

RN-F RN-F RN-F

Optional
Cache Cache Cache
cache

ICN
Coherent interconnect (ICN) Cache

Main
SN-F
memory

Subordinate 1

Figure 1-2 Example coherency model

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

A cache line is defined as a 64-byte aligned memory region that is 64 bytes in size. All coherency is maintained at
cache line granularity.

Main memory is only required to be updated before a copy of the memory location is no longer held in any cache.
The protocol does not require main memory to be up to date at all times.

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

The protocol enables Requester 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. This ensures:

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

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

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-31
ID092622 Non-Confidential
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, where
some include none or all bytes. An Empty cache line has no bytes valid.

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

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

1-32 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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.
A Request Node 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:
• Does not include a hardware-coherent cache.
• Receives DVM transactions.
• Generates a subset of transactions defined by the protocol.
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 Request
Nodes.
A Home Node is further categorized as:
HN-F Fully Coherent Home Node:
• Expected to receive all request types, except DVMOp.
• 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 Request Node.
• 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 Non-coherent Home Node:

• Processes a limited subset of request types defined by the protocol.
• Does not include a PoC and is not capable of processing a Snoopable request. On
receipt of a Snoopable request, it must respond with a protocol compliant
message.
• Expected to be the PoS that manages order between IO requests targeting the IO
subsystem.
MN Miscellaneous Node. Receives a DVM transaction from a Request Node, completes the
required action, and returns a response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-33
ID092622 Non-Confidential
Introduction
1.6 Component naming

SN Subordinate Node. A Subordinate Node receives a request from a Home Node, completes the
required action, and returns a response.
A Subordinate Node is further categorized as:
SN-F A Subordinate Node type used for Normal memory. It can process Non-snoopable Read,
Write, and Atomic requests, including exclusive variants of them, and Cache
Maintenance Operation (CMO) requests.
SN-I A Subordinate Node type used for peripherals or Normal memory. It can process
Non-snoopable Read, Write, and Atomic requests, including exclusive variants of them,
and CMO requests.

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

Requesters
(Fully coherent)

RN-F0 RN-F1 RN-F2

Requester
(IO coherent)
Interconnect (ICN)
MN

RN-I

HN-I HN-F HN-F

SN-I SN-F

Subordinate Subordinate
(Peripheral and/or Normal Memory) Subordinates (Normal Memory)

Figure 1-4 Protocol node examples

1-34 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Introduction
1.7 Read data source

1.7 Read data source

In a CHI-based system, a Read request can obtain data from different sources. Figure 1-5 shows that these sources
are:
• Cache within the interconnect
• Subordinate Node
• Peer RN-F

Requester RN-F RN-F

Data
Req

Snoop
Data
Home ICN

Req

Data
Data providers Subordinate

Figure 1-5 Possible Data providers for a Read request

One option for Home is to request that the RN-F or Subordinate Node returns data only to Home. The Home in turn
forwards a copy of the received data to the Requester. A hop in obtaining Data in this Read transaction flow can be
removed if the Data provider is enabled to forward the Data response directly to the Requester instead of via the
Home.

This specification uses several techniques to reduce the number of hops to complete a transaction. This reduction
in the number of hops results in Read and Write latency savings as well as reduction in interconnect bandwidth
utilization. The techniques can be categorized as:

Direct Memory Transfer (DMT)

Defines the feature that permits the Subordinate Node to send data directly to the Requester.

Direct Cache Transfer (DCT)

Defines the feature which permits a peer RN-F to send data directly to the Requester.
The Data provider in the DCT Read transaction flows has to inform the Home that it has sent Data
to the Requester and, in some cases, it also has to send a copy of data to the Home.

Direct Write-data Transfer (DWT)

Defines the feature which permits the requesting Request Node to send write data directly to the
Subordinate Node.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 1-35
ID092622 Non-Confidential
Introduction
1.7 Read data source

1-36 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-38
• Channel fields on page 2-39
• Transaction structure on page 2-46
• Transaction identifier fields on page 2-93
• Transaction identifier field flows on page 2-100
• Ordering on page 2-121
• Address, Control, and Data on page 2-133
• Data transfer on page 2-142
• Request Retry on page 2-154

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-37
ID092622 Non-Confidential
Transactions
2.1 Channels overview

2.1 Channels overview

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

Communication between nodes is channel-based. Table 2-1 shows the channel naming and the channel designations
at the Request Nodes and Subordinate Nodes.

See Channel on page 13-405 for the mapping of physical channels on the Request Node and Subordinate Node
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, atomic data, snoop data, forward data. Used for write data, atomic 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, atomic data. Used for read data, atomic data.

SNP RXSNP. Inbound Snoop request. -

2-38 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.2 Channel fields

2.2 Channel fields

This section gives a brief overview of the channel fields and indicates which fields 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-43
• Data fields on page 2-44
• Response fields on page 2-42

The term ‘transaction structure’ is used to describe the different packets that form a transaction. The transaction
structure can vary depending on several factors.

2.2.1 Transaction request fields

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

More information on the different transaction structures can be found in Transaction structure on page 2-46 and Flit
packet definitions on page 13-418.

Table 2-2 Request channel fields

Affects
Field Description
structure

QoS No Quality of Service priority. Specifies one 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 node ID of the port on the component to which the packet is
targeted. See Target Identifier, TgtID, and Source Identifier, SrcID on
page 2-93 and System Address Map, SAM on page 3-160.

SrcID No Source ID. The node ID of the port on the component from which the packet
was sent. See Target Identifier, TgtID, and Source Identifier, SrcID on
page 2-93.

TxnID No Transaction ID. A transaction has a unique transaction ID per source node. See
Transaction Identifier, TxnID on page 2-93.

ReturnNID No Return Node ID. The recipient node ID for the Data response, Persist
response, or TagMatch response See Return Node Identifier, ReturnNID on
page 2-96.

StashNID No Stash Node ID. The node ID of the Stash target. See Stash Node Identifier,
StashNID on page 2-96.

SLCRepHint No System Level Cache Replacement Hint. Forwards cache replacement hints
from the Requesters to the caches in the interconnect. See SLC replacement
hint on page 11-371.

StashNIDValid Yes Stash Node ID Valid. Indicates that the StashNID field has a valid Stash target
value. See Stash Node Identifier Valid, StashNIDValid on page 13-427.

Endian No Endianness. Indicates the endianness of data in the data packet for Atomic
transactions. See Endianness on page 2-147.

Deep No Deep persistence. Indicates that the Persist response must not be sent until all
earlier writes are written to the final destination. See Deep Persistent CMO on
page 4-183.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-39
ID092622 Non-Confidential
Transactions
2.2 Channel fields

Table 2-2 Request channel fields (continued)

Affects
Field Description
structure

ReturnTxnID No Return Transaction ID. The unique transaction ID that conveys the value of
TxnID in the data response from the Subordinate. See Return Transaction
Identifier, ReturnTxnID on page 2-95.

StashLPIDValid No Stash Logical Processor ID Valid. Indicates that the StashLPID field value
must be considered as the Stash target. See Stash Logical Processor Identifier
Valid, StashLPIDValid on page 13-427.

StashLPID No Stash Logical Processor ID. The ID of the logical processor at the Stash target.
See Stash Logical Processor Identifier, StashLPID on page 13-427.

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

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-142.

Addr No Address. The address of the memory location being accessed for Read and
Write requests. See Address on page 2-133 and Address, Addr on page 13-435.

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

Non-secure bit on page 2-133 and Non-secure, NS on page 13-435.

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

AllowRetry Yes Allow Retry. Determines if the target is permitted to give a Retry response. See
Request Retry on page 2-154.

Order Yes Order requirement. Determines the ordering requirement for this request with
respect to other requests from the same agent. See Ordering on page 2-121.

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-154.

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

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

DoDWT Yes Do Direct Write Transfer. Supports Direct Write-data Transfer and the
handling of Combined Writes. See Do Direct Write Transfer, DoDWT on
page 13-438.

LPID No Logical Processor ID. Used with the SrcID field to uniquely identify the
logical processor that generated the request. See Logical Processor Identifier,
LPID on page 13-426.

PGroupID No Persistence Group ID. Indicates the set of CleanSharedPersistSep transactions

to which the request applies. See Persistence Group Identifier, PGroupID on
page 13-426.

StashGroupID No Stash Group ID. Indicates the set of StashOnceSep transactions to which the
request applies. See Stash Group Identifier, StashGroupID on page 13-427.

2-40 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.2 Channel fields

Table 2-2 Request channel fields (continued)

Affects
Field Description
structure

TagGroupID No TagGroupID. Precise contents are IMPLEMENTATION DEFINED. Typically

expected to contain Exception level, TTBR value, and CPU identifier. See Tag
Group Identifier, TagGroupID on page 13-443

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

access transaction. See Chapter 6 Exclusive accesses.

SnoopMe No Snoop Me. Indicates that Home must determine whether to send a snoop to the
Requester during an Atomic transaction. See Atomic transactions on
page 2-74.

ExpCompAck Yes Expect CompAck. Indicates that the transaction will include a completion
acknowledge message. See Transaction structure on page 2-46 and Ordering
on page 2-121.

TagOp Yes Tag Operation. Indicates the operation to be performed on the tags present in
the corresponding DAT channel. See Tag Operation, TagOp on page 13-443.

TraceTag No Trace Tag. Provides extra support for the debugging, tracing, and performance
measurement of systems. See Chapter 11 System Debug, Trace, and
Monitoring.

MPAM No Memory System Performance Resource Partitioning and Monitoring.

Efficiently utilizes the memory resources among users and monitors their use.
See MPAM on page 11-373.

RSVDC No User-defined. See Reserved for Customer Use, RSVDC on page 13-449.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-41
ID092622 Non-Confidential
Transactions
2.2 Channel fields

2.2.2 Response fields

Table 2-3 describes the fields associated with a Response packet.

Table 2-3 Response packet fields

Field Description

QoS Quality of Service priority. As defined in Request channel fields on

page 2-39. See Chapter 10 Quality of Service.

TgtID Target ID. As defined in Request channel fields on page 2-39. See Target
Identifier, TgtID, and Source Identifier, SrcID on page 2-93.

SrcID Source ID. As defined in Request channel fields on page 2-39. See Target
Identifier, TgtID, and Source Identifier, SrcID on page 2-93.

TxnID Transaction ID. As defined in Request channel fields on page 2-39. See
Transaction Identifier, TxnID on page 2-93.

Opcode Response opcode. Specifies the response type. See RSP channel opcodes on
page 13-432.

RespErr Response Error status. As defined in Data packet fields on page 2-44. See
Chapter 6 Exclusive accesses and Error response fields on page 9-343.

Resp Response status. As defined in Data packet fields on page 2-44. See
Response types on page 4-208.

FwdState Forward State. As defined in Data packet fields on page 2-44. See Forward
State, FwdState on page 13-446.

DataPull Data Pull. As defined in Data packet fields on page 2-44. See Snoop requests
and Data Pull on page 7-304.

CBusy Completer Busy. As defined in Data fields on page 2-44. See Completer
Busy on page 11-375.

DBID Data Buffer ID. As defined in Data packet fields on page 2-44. See Data
Buffer Identifier, DBID on page 2-94 and Ordering on page 2-121.

PGroupID Persistence Group ID. As defined in Request channel fields on page 2-39.
See Persistence Group Identifier, PGroupID on page 13-426.

StashGroupID Stash Group ID. As defined in Request channel fields on page 2-39. See
Stash Group Identifier, StashGroupID on page 13-427.

TagGroupID TagGroupID. As defined in Request channel fields on page 2-39. See Tag
Group Identifier, TagGroupID on page 13-443.

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

TagOp Tag Operation. As defined in Request channel fields on page 2-39. See Tag
Operation, TagOp on page 13-443.

TraceTag Trace Tag. As defined in Request channel fields on page 2-39. See
Chapter 11 System Debug, Trace, and Monitoring.

2-42 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.2 Channel fields

2.2.3 Snoop request fields

Table 2-4 shows the Snoop request fields. Many of the Snoop request fields are the same as fields defined for the
Request channel.

Table 2-4 Snoop request fields

Affects
Field Description
structure

QoS No Quality of Service priority. As defined in Request channel fields on page 2-39. See
Chapter 10 Quality of Service.

SrcID No Source ID. As defined in Request channel fields on page 2-39. See Target Identifier,
TgtID, and Source Identifier, SrcID on page 2-93.

TxnID No Transaction ID. As defined in Request channel fields on page 2-39. See
Transaction Identifier, TxnID on page 2-93.

FwdNID No Forward Node ID. The node ID of the original Requester. See Forward Node
Identifier, FwdNID on page 2-98.

FwdTxnID No Forward Transaction ID. The transaction ID used in the Request by the original
Requester. See Forward Transaction Identifier, FwdTxnID on page 2-95.

StashLPIDValid No Stash Logical Processor ID Valid. As defined in Request channel fields on

page 2-39. See Stash Logical Processor Identifier Valid, StashLPIDValid on
page 13-427.

StashLPID No Stash Logical Processor ID. As defined in Request channel fields on page 2-39. See
Stash Logical Processor Identifier, StashLPID on page 13-427.

VMIDExt No Virtual Machine ID Extension. See DVM Operation types on page 8-323.

Opcode Yes Snoop opcode. See Snoop request fields on page 2-43 and SNP channel opcodes on
page 13-433.

Addr No Address. The address of the memory location being accessed for Snoop requests.
See Address on page 2-133 and Address, Addr on page 13-435.

NS No Non-secure or Secure access. As defined in Request channel fields on page 2-39.

See Non-secure bit on page 2-133 and Non-secure, NS on page 13-435.

DoNotGoToSD No Do Not Go To SD state. Controls Snoopee use of SD state. See Do not transition to
SD on page 4-252.

RetToSrc Yes Return to Source. Instructs the receiver of the snoop to return data with the Snoop
response. See Returning Data with Snoop response on page 4-251.

TraceTag No Trace Tag. As defined in Request channel fields on page 2-39. See Chapter 11
System Debug, Trace, and Monitoring.

MPAM No Memory System Performance Resource Partitioning and Monitoring. As defined in

Request channel fields on page 2-39. See MPAM on page 11-373.

Note
This specification does not define a TgtID field for the Snoop request. See Target ID determination for snoop
request messages on page 3-164.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-43
ID092622 Non-Confidential
Transactions
2.2 Channel fields

2.2.4 Data fields

Table 2-5 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-5 Data packet fields

Field Description

QoS Quality of Service priority. As defined in Request channel fields on

page 2-39. See Chapter 10 Quality of Service.

TgtID Target ID. As defined in Request channel fields on page 2-39. See Target
Identifier, TgtID, and Source Identifier, SrcID on page 2-93.

SrcID Source ID. As defined in Request channel fields on page 2-39. See Target
Identifier, TgtID, and Source Identifier, SrcID on page 2-93.

TxnID Transaction ID. As defined in Request channel fields on page 2-39. See
Transaction Identifier, TxnID on page 2-93.

HomeNID Home Node ID. The node ID of the target of the CompAck response to be
sent from the Requester. See Home Node Identifier, HomeNID on page 2-97.

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 13-434.

RespErr Response Error status. Indicates the error status associated with a data
transfer. See Chapter 6 Exclusive accesses and Error response fields on
page 9-343.

Resp Response status. Indicates the cache line state associated with a data transfer.
See Response types on page 4-208.

FwdState Forward State. Indicates the cache line state associated with a data transfer
to the Requester from the receiver of the snoop. See Forward State, FwdState
on page 13-446.

DataPull Data Pull. Indicates the inclusion of an implied Read request in the Data
response. See Snoop requests and Data Pull on page 7-304.

DataSource Data Source. The value indicates the source of the data in a read Data
response. See Data Source indication on page 11-368.

CBusy Completer Busy. Indicates the current level of activity at the Completer. See
Completer Busy on page 11-375.

DBID Data Buffer ID. The ID provided to be used as the TxnID in the response to
this message. See Data Buffer Identifier, DBID on page 2-94 and Ordering
on page 2-121.

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

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

TagOp Tag Operation. As defined in Request channel fields on page 2-39. See Tag
Operation, TagOp on page 13-443.

Tag Memory Tag. Provides sets of 4-bit tags, each associated with an aligned
16-byte of data. See Tag on page 13-443.

2-44 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.2 Channel fields

Table 2-5 Data packet fields (continued)

Field Description

TU Tag Update. Indicates which of the Allocation Tags must be updated. See
Tag Update, TU on page 13-443.

TraceTag Trace Tag. As defined in Request channel fields on page 2-39. See
Chapter 11 System Debug, Trace, and Monitoring.

RSVDC User-defined. See Reserved for Customer Use, RSVDC on page 13-449.

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-142.

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

DataCheck Data Check. Detects data errors in the DAT packet. See Data Check on
page 9-356.

Poison Poison. Indicates that a set of data bytes has previously been corrupted. See
Poison on page 9-355.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-45
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

2.3 Transaction structure

This section describes the ways that a transaction can complete. It shows all the permitted options that can be used
by the various components that participate in a transaction.

All transaction types, except PCrdReturn and PrefetchTgt, can have a Retry sequence at the start of the transaction.
For ease of presentation, the Retry sequence is described separately, see Retry on page 2-83.

Other independent transactions may need to be performed to complete certain transactions, such as a snoop or
memory transaction. These transactions are described separately in the later section, Home Initiated transactions on
page 2-84.

Some transactions from Home to Subordinate support the use of a separate ReturnNID and ReturnTxnID field,
which allow certain responses to be returned to the original Requester rather than the Home. It is permitted, but not
required, for the Home to set the ReturnNID and ReturnTxnID fields, such that they are equal to the SrcID and
TxnID. This means all responses are returned to the Home. In this instance, the transaction from Home to
Subordinate is considered as if it were an independent transaction. See Home Initiated transactions on page 2-84
for more details.

Some messages in this section are described as Optional. This means that whether or not the particular message is
included in the transaction flow is determined by a characteristic of the transaction, typically a field or opcode in
the request. This does not mean that the sender of the message can choose whether or not it wishes to send the
message.

The term Requester is always used to refer to the original Requester of a transaction in this section. This does not
mean an intermediate agent that issues a secondary request to complete the original transaction. The term Requester
always refers to a Request Node, RN-F or RN-I.

In this section, an arrow containing multiple message labels within a diagram indicates any one of the messages can
be sent in a flow. Requirements of when a particular message can be used in the transaction flow can be derived
from elsewhere in the specification.

The flows described in this section are intended to include a complete description of the messages that can be
included in a transaction flow. It does not include the following:

• The channel that is used for a particular transaction. This information can be derived from elsewhere in the
specification.

• A description of when a transaction can be issued or what the reason is for using a particular transaction.

• A description of which combinations of fields can be used in a request. Request fields are only highlighted
when they affect the options for completing a transaction.

Dependencies described in this section use the following approach:

• An implicit dependency exists for each component when it first participates in a transaction sequence. With
the exception of the original Requester, any other component must receive a first message associated with a
transaction before it can send any subsequent messages for that transaction.

• Where a component sends multiple messages associated with the same transaction, it is assumed that
component can send the messages in any order and they can be received in any order, unless an explicit
dependency is described.

• Data transfers are shown in the diagrams as a single message. This message can consist of multiple data
transfers, see Data transfer on page 2-142 for more details. Where a dependency is described, the
dependency is from the first data transfer received, except when it is explicitly stated to be different.

• Where a required or permitted dependency exists in one direction between two components, a dependency
in the opposite direction is not permitted. The text in this section only describes the dependency in one
direction.

• The amount of detail in a dependency rule is context dependent. In some instances where the source of the
dependency and what is dependent is obvious, then the agents are not included.

2-46 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

• For any agent that has one or more outputs:

— If the agent is the original Requester of the transaction, dependencies are described for each input to
that agent.
— If the agent is not the original Requester of the transaction, dependencies are described for each input
to that agent after the first input that agent received. Every output is considered dependent on the first
input.

• This section does not describe all dependencies across different transactions, even when they are both to the
same address. See Ordering on page 2-121 and Hazard conditions on page 4-253.

The conventions used to describe actions in this section are:

Issues
Used only for the first message in a transaction, for example “The Requester issues a WriteNoSnp
request...”.

Sends
A message sent by an agent in a direction away from the Requester.

Sends a downstream
A message relayed by an intermediate agent in a direction away from the Requester, for example
“The Home sends a downstream Read request to the Subordinate”.

Returns
A message sent by an agent in a direction towards the Requester.

Provides
A message sent by an agent in response to a snoop, for example “...provides a snoop response”.

Permitted, but not required

The action is neither encouraged nor discouraged, and is compliant in either case.

Not permitted
The action described would cause non-compliance to the specification. For example, “it is not
permitted to wait for...before sending...”.

2.3.1 Read transactions

Read transactions are grouped into the following types:
• Allocating Read
• Non-allocating Read on page 2-50

Allocating Read
Figure 2-1 on page 2-48 shows the possible transaction flows for an Allocating Read transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-47
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Requester Home Subordinate Snoopee

ReadClean, ReadNotSharedDirty, ReadShared,

ReadUnique, ReadPreferUnique, MakeReadUnique

alt [1. Combined response from Home]

CompData

[2. Separate Data and Response from Home]

RespSepData

DataSepResp

[3. Combined response from Subordinate]

ReadNoSnp

opt [Order != 00]

ReadReceipt

CompData

[4. Response from Home, Data from Subordinate]

RespSepData

ReadNoSnpSep

ReadReceipt

DataSepResp

[5. Forwarding snoop]

Snp*Fwd

alt [5a. With response to Home]

CompData

SnpRespFwded

[5b. With data to Home]

CompData

SnpRespDataFwded

[5c. Failed, must use alternative]

SnpResp

Use alternative

[5d. Failed, must use alternative]

SnpRespData, SnpRespDataPtl

Use alternative

[6. MakeReadUnique only]

Comp

CompAck

Requester Home Subordinate Snoopee

Figure 2-1 Allocating Read

The sequence for the Allocating Read transaction is:

• The transaction starts with the Requester issuing an Allocating Read request to the Home.
The initial request is one of the following:
— ReadClean
— ReadNotSharedDirty
— ReadShared
— ReadUnique
— ReadPreferUnique
— MakeReadUnique

2-48 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

• Alternatives 1-6 show different ways that the Home can process the transaction:
1. Combined response from Home
The Home returns a combined response and read data, CompData, to the Requester.
Typically, this option is used by the Home when it can return data and response at the same time. An
example is when the data is cached locally.
2. Separate data and response from Home
The Home returns a separate response, RespSepData, and read data, DataSepResp, to the Requester.
Typically, this option is used by the Home when it can return a response quicker than it can provide
the data.
3. Combined response from Subordinate
• The Home sends a downstream read request, ReadNoSnp, to the Subordinate.
• Optionally, when the Home requests a ReadReceipt response, the Subordinate returns a read
receipt, ReadReceipt, to the Home.
• The Subordinate returns a combined response and read data, CompData, to the Requester.
Typically, this option is used by the Home either to reduce the message count or reduce design
complexity.
4. Response from Home, Data from Subordinate
• The Home returns a separate response, RespSepData, to the Requester.
• The Home sends a downstream read data only request, ReadNoSnpSep, to the Subordinate.
• The Subordinate returns a read receipt, ReadReceipt, to the Home.
It is permitted, but not required, for the Home to wait for ReadReceipt from the Subordinate
before sending RespSepData to the Requester.
• The Subordinate returns read data, DataSepResp, to the Requester.
Typically, this option is used by the Home when it can return a response quickly, but it does not have
the data available and requires the Subordinate to return the data.
Note
In many circumstances, the Requester receives RespSepData far in advance to DataSepResp. The
Requester is permitted, but not required, to send the CompAck response after receiving RespSepData
without waiting for DataSepResp. The prompt response from the Requester, and potentially receiving
ReadReceipt around the same time, permits the Home to complete the transaction faster than when
using combined completion and data responses from the Subordinate.

5. Forwarding snoop
• The Home requests a Snoopee to forward read data, Snp*Fwd, to the Requester. See Request
transactions and corresponding Snoop requests on page 4-204 to determine which Snp*Fwd
transactions can be used.
Typically, this option is used by the Home when the data is not cached locally and it determines
that a Snoopee is likely to have a copy.
• Alternatives 5a-5d show how the Snoopee can process the transaction:
Alt 5a. With response to Home
• The Snoopee returns a combined response and read data, CompData, to the
Requester.
• The Snoopee provides a snoop response, SnpRespFwded, to the Home.
Typically, this option is used by the Snoopee when it can forward data to the
Requester and is not required to provide a copy of data to the Home.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-49
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Alt 5b. With data to Home

• The Snoopee returns a combined response and read data, CompData, to the
Requester.
• The Snoopee provides a snoop response with data, SnpRespDataFwded, to
the Home.
Note
Typically, this option is used by the Snoopee when it can forward data to the
Requester but it also has to provide a copy of data to the Home. For example, this
can happen when the Snoopee holds a Dirty copy of the cache line, but the data
returned to the Requester must be Clean. This can also happen when the Home has
requested a copy of the data.

Alt 5c. Failed, must use alternative

The Snoopee provides a snoop response, SnpResp, to the Home.
The Home must use another alternative described in this section to complete the
transaction to the Requester.
Alt 5d. Failed, must use alternative
The Snoopee provides a snoop response with data, SnpRespData or
SnpRespDataPtl, to the Home.
The Home must use another alternative described in this section to complete the
transaction to the Requester.
6. MakeReadUnique only
The Home returns a completion response, Comp, to the Requester.
This option is only applicable for a MakeReadUnique transaction when a read data message is not
required.

• The transaction ends when the Requester sends a completion acknowledge, CompAck, to the Home.
The CompAck must only be sent after a CompData or RespSepData is received.
It is permitted, but not required, to wait for DataSepResp before sending CompAck.

Non-allocating Read
Figure 2-2 on page 2-51 shows the possible transaction flows for a Non-allocating Read transaction.

2-50 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Requester Home Subordinate Snoopee

ReadNoSnp, ReadOnce,
ReadOnceCleanInvalid, ReadOnceMakeInvalid

alt [1. Combined response from Home]

opt [Order != 00]

ReadReceipt

CompData

[2. Separate Data and Response from Home]

RespSepData

DataSepResp

[3. Combined response from Subordinate]

opt [Order != 00]

ReadReceipt

ReadNoSnp

opt [Order != 00]

ReadReceipt

CompData

[4. Response from Home, Data from Subordinate]

RespSepData

ReadNoSnpSep

opt [Order != 00]

ReadReceipt

DataSepResp

[5. Forwarding snoop]

opt [Order != 00]

ReadReceipt

Snp*Fwd

alt [5a. with response to Home]

CompData

SnpRespFwded

[5b. with data to Home]

CompData

SnpRespDataFwded

[5c. Failed, must use alternative]

SnpResp

Use alternative

[5d. Failed, must use alternative]

SnpRespData, SnpRespDataPtl

Use alternative

opt [ExpCompAck == 1]
CompAck

Requester Home Subordinate Snoopee

Figure 2-2 Non-allocating Read

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-51
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

The sequence for the Non-allocating Read transactions is:

• The transaction starts with the Requester issuing a Read request to the Home.
The Non-allocating Read transactions are:
— ReadNoSnp
— ReadOnce
— ReadOnceCleanInvalid
— ReadOnceMakeInvalid
The request contains the following fields which affect the transaction flow:
— Order
— ExpCompAck

• Alternatives, 1-6 show how the Home can process the transaction. For a description of the typical use of the
different alternatives, see Allocating Read on page 2-47.
1. Combined response from Home
• Optionally, when the original request has an ordering requirement, the Home returns a read
receipt, ReadReceipt, to the Requester.
• The Home returns a combined response and read data, CompData, to the Requester.
2. Separate data and response from Home
The Home returns a separate response, RespSepData, and read data, DataSepResp, to the Requester.
This alternative cannot be used if the request has an ordering requirement and a completion
acknowledge is not required.
3. Combined response from Subordinate
• Optionally, when the original request has an ordering requirement, the Home returns a read
receipt, ReadReceipt, to the Requester.
• The Home sends a downstream read request, ReadNoSnp, to the Subordinate.
• Optionally, when the Home requests a ReadReceipt response, the Subordinate returns
ReadReceipt to the Home.
The Home must do this when a completion acknowledge is not required.
It is permitted, but not required, for the Home to wait for ReadReceipt from the Subordinate
before returning ReadReceipt to the Requester.
• The Subordinate returns a combined response and read data, CompData, to the Requester.
This alternative cannot be used if the request has an ordering requirement and a completion
acknowledge is not required.
4. Response from Home, data from Subordinate
• The Home returns a separate response, RespSepData, to the Requester and sends a downstream
read data only request, ReadNoSnpSep, to the Subordinate.
• Optionally, when the Home requests a ReadReceipt response, the Subordinate returns a read
receipt, ReadReceipt, to the Home. The Home must request a ReadReceipt unless the original
request indicates a requirement for both ordering and a completion acknowledge.
It is permitted, but not required, for the Home to wait for ReadReceipt from the Subordinate
before returning RespSepData to the Requester.
• The Subordinate returns read data, DataSepResp, to the Requester.
This alternative cannot be used if the request has an ordering requirement and a completion
acknowledge is not required.
5. Forwarding snoop
• Optionally, when the original request has an ordering requirement, the Home returns a read
receipt, ReadReceipt, to the Requester.
• The Home requests a Snoopee to forward read data, Snp*Fwd, to the Requester.
See Request transactions and corresponding Snoop requests on page 4-204 to determine which
Snp*Fwd transactions can be used.

2-52 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

• The alternatives, 5a-5d, show how the Snoopee can process the transaction:
Alt 5a. With response to Home
• The Snoopee provides a combined response and read data, CompData, to the
Requester.
• The Snoopee provides a snoop response, SnpRespFwded, to the Home.
Alt 5b. With data to Home
• The Snoopee provides a combined response and read data, CompData, to the
Requester.
• The Snoopee provides a Snoop response with data, SnpRespDataFwded, to
the Home.
Alt 5c. Failed, must use alternative
• The Snoopee provides a snoop response, SnpResp, to the Home.
• The Home must use another alternative described in this section to complete
the transaction to the Requester.
Alt 5d. Failed, must use alternative
• The Snoopee provides a snoop response with data, SnpRespData or
SnpRespDataPtl, to the Home.
• The Home must use another alternative described in this section to complete
the transaction to the Requester.

• If the original request has ExpCompAck asserted, the Requester must only provide a CompAck response
after the following:
— At least one CompData packet is received.
— RespSepData, if the request does not have an ordering requirement. In this case, it is permitted but not
required to wait for DataSepResp.
— RespSepData and at least one DataSepResp packet, if the request has an ordering requirement.

If the original request has an ordering requirement, it is permitted, but not required, for the Requester to wait for
ReadReceipt before sending CompAck.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-53
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Table 2-6 lists the permitted DMT and DCT transactions for ReadNoSnp and ReadOnce* from a Request Node. The
following key is used:
Y Yes, permitted
N No, not permitted
- The flow is not used in this transaction

Table 2-6 Permitted DMT and DCT for ReadNoSnp and ReadOnce* from an RN

Order
ExpCompAck DMT DCT Notes
[1:0]

00 0 Y Y Home does not need to be notified of transaction

completion.
For DMT, Home must obtain a ReadReceipt from
Subordinate Node to ensure the request to
Subordinate Node is not given a RetryAck
response.

1 Y Y When not using DMT, Home does not need to be

notified of transaction completion.
For DMT, to ensure that the request from the Home
to the Subordinate Node is not given a RetryAck
response:
• When using ReadNoSnp to the Subordinate
Node, Home must either obtain a
ReadReceipt from the Subordinate Node or
wait for the CompAck response from the
Request Node.
• When using ReadNoSnpSep to the
Subordinate Node, Home must obtain a
ReadReceipt from the Subordinate Node.

01 - - - Not permitted.

10 0 N Y For DCT, Home uses the SnpRespFwded or

11 SnpRespDataFwded snoop response to determine
transaction completion.

1 Y Y For DMT, Home uses the CompAck response to

determine transaction completion.
For DCT, Home uses the SnpRespFwd or
SnpRespDataFwded snoop response to determine
transaction completion.

2-54 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

2.3.2 Write Transactions

Write transactions are grouped into the following types:
• Immediate write
• Write Zero on page 2-60
• CopyBack Write on page 2-61
• Combined Immediate Write and CMO on page 2-62
• Combined Immediate Write and Persist CMO on page 2-66
• Combined CopyBack Write and CMO on page 2-72

Immediate write
Figure 2-3 on page 2-56 shows the possible transaction flows for an Immediate Write transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-55
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Requester Home Subordinate

WriteNoSnpPtl, WriteNoSnpFull, WriteUniquePtl, WriteUniqueFull,

WriteUniquePtlStash, WriteUniqueFullStash

alt [1. DWT]

WriteNoSnpPtl, WriteNoSnpFull
(DoDWT=1)

DBIDResp

NCBWrData, WriteDataCancel

Comp

Comp

opt [TagOp == Match]

TagMatch

[2. No DWT, no CompAck]

alt [2a1. Separate responses from the Home]

DBIDResp, DBIDRespOrd

Comp

[2a2. Combined response from the Home]

CompDBIDResp

NCBWrData, WriteDataCancel

opt [TagOp == Match]

alt [2b1. TagMatch from Home]

TagMatch

[2b2. TagMatch from Subordinate]

WriteNoSnpPtl, WriteNoSnpFull
(DoDWT=0)

alt [2b2a. Separate responses from the Subordinate]

DBIDResp

Comp

[2b2b. Combined response from the Subordinate]

CompDBIDResp

NCBWrData, WriteDataCancel

TagMatch

[3. No DWT, with CompAck]

alt [3a1. Separate responses from the Home]

DBIDResp, DBIDRespOrd

Comp

[3a2. Combined response from the Home]

CompDBIDResp

alt [3b1. Separate response from the Requester]

NCBWrData, WriteDataCancel

CompAck

[3b2. Combined response from the Requester]

NCBWrDataCompAck

opt [TagOp == Match]

alt [3c1. TagMatch from Home]

TagMatch

[3c2. TagMatch from Subordinate]

WriteNoSnpPtl, WriteNoSnpFull
(DoDWT=0)

alt [3c2a. Separate responses from the Subordinate]

DBIDResp

Comp

[3c2b. Combined response from the Subordinate]

CompDBIDResp

NCBWrData, WriteDataCancel

TagMatch

Requester Home Subordinate

Figure 2-3 Immediate Write

2-56 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

The sequence for Immediate Write transactions is:

• The transaction starts with the Requester issuing an Immediate Write request to the Home.
The Immediate Write transactions are:
— WriteNoSnpPtl
— WriteNoSnpFull
— WriteUniquePtl
— WriteUniqueFull
— WriteUniquePtlStash
— WriteUniqueFullStash
Snoop requests that are generated to complete these transactions are considered as independent transactions
from the Home and are not shown in this flow. Write requests that are generated to downstream Subordinates,
which are not part of the DWT flow, are considered as independent transactions and are not shown in this
flow. See Home Initiated transactions on page 2-84 for more details of independent transactions from the
Home. Stash snoops that are generated to complete the WriteUniquePtlStash or WriteUniqueFullStash
transactions are described in the later section on Stash transactions, see Stash transactions on page 2-76.
The request contains the following fields which affect the transaction flow:
— ExpCompAck
— TagOp

• The Home can choose to complete the transaction using DWT or without DWT. The remainder of the
transaction flow will also depend on whether the original request requires a completion acknowledge
response, as determined by the ExpCompAck field. The combinations are described in alternatives 1-3:
1. DWT
The Home uses DWT.
• The Home sends a downstream write request, WriteNoSnpPtl or WriteNoSnpFull, with
DoDWT = 1 to the Subordinate.
• The Subordinate returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the
Subordinate.
The Requester must only send this after it has received DBIDResp.
• The Subordinate returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester
before returning Comp to the Home.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before
returning Comp to the Requester.
• Optionally, when the request requires a TagMatch response, the Subordinate returns a tag match
response, TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning TagMatch.
2. No DWT, no CompAck
The Home does not use DWT for a request that does not require a completion acknowledge,
CompAck.
• The Home has two alternatives to send the completion response and the data request response
to the Requester.
Alt 2a1. Separate responses from the Home
The Home does both the following:
• Returns a data request, DBIDResp or DBIDRespOrd, to the Requester.
• Returns a completion response, Comp, to the Requester.
It is permitted, but not required, to wait for write data before returning Comp.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-57
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Alt 2a2. Combined responses from the Home

The Home returns a combined data request and completion response,
CompDBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the Home.
The Requester must only send this after it has received DBIDResp, DBIDRespOrd, or
CompDBIDResp.
• Optionally, when the request requires a TagMatch response, the Home has two alternatives.
Alt 2b1. TagMatch from Home
The Home returns a tag match response, TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning TagMatch.
Alt 2b2. TagMatch from Subordinate
• The Home sends a downstream write request, WriteNoSnpPtl or
WriteNoSnpFull, with DoDWT = 0 to the Subordinate. The Subordinate has
two alternatives to send return data request and completion response to the
Home.
Alt 2b2a. Separate responses from the Subordinate
The Subordinate does both the following:
• Returns data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to
wait for write data from the Home before returning Comp
to the Home.
Alt 2b2b. Combined response from the Subordinate
The Subordinate returns a combined data request and completion
response, CompDBIDResp, to the Home.
• The Home sends write data, NCBWrData, or a cancellation,
WriteDataCancel, to the Subordinate.
The Home must only send this after it has received DBIDResp or
CompDBIDResp.
• The Subordinate returns a tag match response, TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning
TagMatch.
3. No DWT, with CompAck
The Home does not use DWT for a request that does require a completion acknowledge, CompAck.
• The Home has two alternatives to return the completion response and the data request response
to the Requester.
Alt 3a1. Separate response from the Home
The Home does both the following:
• Returns a data request, DBIDResp or DBIDRespOrd, to the Requester.
• Returns a completion response, Comp, to the Requester.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 3a2. Combined response from the Home
The Home returns a combined data request and completion response,
CompDBIDResp, to the Requester.
• The Requester has two alternatives to send write data and completion acknowledge to the
Home.

2-58 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Alt 3b1. Separate response from the Requester

The Requester does both the following:
• Sends write data, NCBWrData, or a write cancellation, WriteDataCancel, to
the Home.
The Requester must only send this after it has received DBIDResp,
DBIDRespOrd or CompDBIDResp.
• Sends a completion acknowledge, CompAck, to the Home.
The Requester must only send this after it has received Comp or
CompDBIDResp.
It is permitted, but not required, to wait for DBIDResp or DBIDRespOrd
before sending CompAck.
It is permitted, but not expected, to wait for TagMatch before returning
CompAck.
Alt 3b2. Combined response from the Requester
The Requester sends a combined write data and completion acknowledge,
NCBWrDataCompAck, to the Home.
The Requester must only send this after it has received CompDBIDResp or both
DBIDResp/DBIDRespOrd and Comp.
• Optionally, when the request requires a TagMatch response, the Home has two alternatives to
return the response.
Alt 3c1. TagMatch from Home
The Home returns a tag match response, TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning TagMatch.
Alt 3c2. TagMatch from Subordinate
• The Home sends a downstream write request, WriteNoSnpPtl or
WriteNoSnpFull, with DoDWT = 0 to the Subordinate. The Subordinate has
two alternatives to return data request and completion response to the Home.
Alt 3c2a. Separate responses from Subordinate
The Subordinate does both the following:
• Returns a data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to
wait for write data before sending Comp to the Home.
Alt 3c2b. Combined response from Subordinate
The Subordinate returns a combined data request and completion
response, CompDBIDResp, to the Home.
• The Home sends write data, NCBWrData, or a cancellation,
WriteDataCancel, to the Subordinate.
The Home must only send this after it has received DBIDResp or
CompDBIDResp.
• The Subordinate returns a tag match response, TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning
TagMatch.

The Completer of a Write transaction is permitted to return a Comp response as soon as it receives a
WriteDataCancel response without dependency on either the processing of the write request or the completion of
any snoops sent due to the write.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-59
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Write Zero
Figure 2-4 shows the possible transaction flows for a Write Zero transaction.

Requester Home

WriteNoSnpZero, WriteUniqueZero

alt [1. Separate response from Home]

DBIDResp, DBIDRespOrd

Comp

[2. Combined response from Home]

CompDBIDResp

Requester Home

Figure 2-4 Write Zero

• The transaction starts with the Requester issuing a Write Zero request to the Home.
The Write Zero transactions are:
— WriteUniqueZero
— WriteNoSnpZero

• The Home has two alternatives to send the completion response and the data request response to the
Requester.
1. Separate response from Home
• The Home returns a data request response, DBIDResp or DBIDRespOrd, to the Requester.
• The Home returns a completion response, Comp, to the Requester
2. Combined response from Home
The Home returns a combined data request and completion response, CompDBIDResp, to the
Requester.

2-60 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

CopyBack Write
Figure 2-5 shows the possible transaction flows for a CopyBack Write transaction.

Requester Home

WriteBackPtl, WriteBackFull, WriteCleanFull

WriteEvictFull, WriteEvictOrEvict

alt [1. Combined response from Home]

CompDBIDResp

CopyBackWrData

[2. For WriteEvictOrEvict Only]

Comp

CompAck

Requester Home

Figure 2-5 CopyBack Write

The sequence for CopyBack Write is:

• The transaction starts with the Requester issuing a CopyBack Write request to the Home.
The CopyBack Write transactions are:
— WriteBackPtl
— WriteBackFull
— WriteCleanFull
— WriteEvictFull
— WriteEvictOrEvict
The request contains the following field which affects the transaction flow:
— Opcode

• The Home can complete any transaction using one of the following alternatives:
1. Combined response from Home
This alternative must be used for:
• WriteBackPtl
• WriteBackFull
• WriteCleanFull
• WriteEvictFull
This alternative can be used for WriteEvictOrEvict transactions.
Typically, it is used for a WriteEvictOrEvict transaction when the Home wants to cache a copy of the
cache line.
• The Home returns a combined data request and completion response, CompDBIDResp, to the
Requester.
• The Requester sends write data, CopyBackWrData, to the Home.
The Requester must only send this after it has received CompDBIDResp.
2. For WriteEvictOrEvict Only
The Home can complete a WriteEvictOrEvict transaction using the second alternative.
Typically, it is used for a WriteEvictOrEvict transaction when the Home does not want to cache a copy
of the cache line.
• The Home returns a completion response, Comp, to the Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-61
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

• The Requester sends a completion acknowledge, CompAck, to the Home.

The Requester must only send this after it has received Comp.

Combined Immediate Write and CMO

Figure 2-6 on page 2-63 shows the possible transaction flows for a Combined Write and CMO transaction. This only
covers Non-persist Cache Maintenance Operations, see Combined Immediate Write and Persist CMO on page 2-66
for transaction flows for a Combined Immediate Write and Persist CMO transaction.

2-62 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Requester Home Subordinate

WriteNoSnpPtlCleanInv, WriteNoSnpFullCleanInv,
WriteNoSnpPtlCleanSh, WriteNoSnpFullCleanSh,
WriteUniquePtlCleanSh, WriteUniqueFullCleanSh

alt [1. Combined Write with DWT to Subordinate]

WriteNoSnpPtlCleanInv, WriteNoSnpFullCleanInv,
WriteNoSnpPtlCleanSh, WriteNoSnpFullCleanSh
(DoDWT = 1)

DBIDResp

NCBWrData, WriteDataCancel

Comp

Comp

CompCMO

CompCMO

[2. Non-combined write with DWT to Subordinate]

WriteNoSnpPtl, WriteNoSnpFull
(DoDWT=1)

DBIDResp

NCBWrData, WriteDataCancel

Comp

Comp

CompCMO

[3. No DWT]

alt [3a1. Separate responses from Home]

DBIDResp, DBIDRespOrd

Comp

[3a2. Combined response from Home]

CompDBIDResp

alt [3b1. No CompAck required]

NCBWrData, WriteDataCancel

[3b2. CompAck required]

alt [3b2a. Separate response from Requester]

NCBWrData, WriteDataCancel

CompAck

[3b2b. Combined response from Requester]

NCBWrDataCompAck

CompCMO

Requester Home Subordinate

Figure 2-6 Combined Immediate Write and CMO

The sequence for the Combined Immediate Write with CMO transactions is:

• The transaction starts with the Requester issuing a Combined Write and CMO request to the Home.
The Combined Immediate Write and CMO transactions are:
— WriteNoSnpPtlCleanInv

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-63
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

— WriteNoSnpPtlCleanSh
— WriteNoSnpFullCleanInv
— WriteNoSnpFullCleanSh
— WriteUniquePtlCleanSh
— WriteUniqueFullCleanSh
Snoop requests that are generated to complete these transactions are considered as independent transactions
from the Home and are not shown in this flow. Write requests that are generated to downstream Subordinates,
which are not part of the DWT flow, are considered as independent transactions and are not shown in this
flow. Also, CMO requests that only return responses to the Home and are generated to downstream
Subordinates are considered independent transactions. See Home Initiated transactions on page 2-84 for
more details on independent transactions from the Home. See Home to Subordinate Write transactions on
page 2-85 for more details on independent Combined Write and CMO transactions from the Home.
The request contains the following fields which affect the transaction flow:
— Opcode
— ExpCompAck

Note
A TagOp value of Match is not permitted in a Combined Immediate Write and CMO transaction, therefore
no TagMatch responses are permitted and the TagOp field does not affect the transaction flow.

The Home has three alternatives to choose from in order to complete the transaction:

• Combined Write with DWT to Subordinate.

• Non-combined Write with DWT to Subordinate.

• Without DWT.

The three approaches are described in the alternatives 1-3.

The remainder of the transaction flow will also depend on whether the original request required a completion
acknowledge, as determined by the ExpCompAck.

1. Combined Write with DWT to Subordinate

The Home uses a Combined Write with DWT.
• The Home sends a downstream combined write request with DoDWT = 1 to the Subordinate.
• The Subordinate returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the Subordinate.
The Requester must only send this after it has received DBIDResp.
• The Subordinate returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester before
returning Comp to the Home.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before returning
Comp to the Requester.
• The Subordinate returns a CMO completion response, CompCMO, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester before
returning CompCMO to the Home.
• The Home returns a CMO completion response, CompCMO, to the Requester.
It is permitted, but not required, for the Home to wait for Comp or CompCMO from the Subordinate
before returning CompCMO to the Requester. If there is an observer downstream of the Home, then
the Home must wait for the CompCMO response from the Subordinate before returning CompCMO
to the Requester.

2. Non-combined Write with DWT to Subordinate

2-64 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

The Home uses a Non-combined Write with DWT.

• The Home sends a downstream WriteNoSnpPtl or WriteNoSnpFull, with DoDWT = 1 to the
Subordinate.
• The Subordinate returns a data Request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the Subordinate.
The Requester must only send this after it has received DBIDResp.
• The Subordinate returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester before
returning Comp to the Home.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before returning
Comp to the Requester.
• The Home returns a CMO completion response, CompCMO, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before returning
CompCMO to the Requester.

3. No DWT
The Home does not use DWT.
• The Home has two alternatives to request write data.
Alt 3a1. Separate responses from Home
The Home does both the following:
• Returns a data request, DBIDResp or DBIDRespOrd, to the Requester.
• Returns a completion response, Comp, to the Requester.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 3a2. Combined response from Home
The Home returns a combined data request and completion response, CompDBIDResp, to
the Requester.
• The Requester has several alternatives to send write data depending on whether the transaction
requires a completion acknowledge.
Alt 3b1. No CompAck required
A completion acknowledge, CompAck, is not required and the Requester sends write data,
NCBWrData, or a write cancellation, WriteDataCancel, to the Home.
The Requester must only send this after it has received DBIDResp, DBIDRespOrd or
CompDBIDResp.
Alt 3b2. Separate response from Requester
A completion acknowledge is required. The Requester has two alternatives to send write
data and completion acknowledge to the Home.
Alt 3b2a. Separate response from Requester
The Requester does both the following:
• Sends write data, NCBWrData, or a write cancellation,
WriteDataCancel, to the Home.
The Requester must only send this after it has received DBIDResp,
DBIDRespOrd, or CompDBIDResp.
• Sends CompAck to the Home.
The Requester must only send this after it has received Comp or
CompDBIDResp.
It is not permitted to wait for CompCMO before sending CompAck.
Alt 3b2b. Combined response from Requester
The Requester sends a combined write data and completion acknowledge,
NCBWrDataCompAck, to the Home.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-65
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

The Requester must only send this after it has received CompDBIDResp or
both DBIDResp/DBIDRespOrd and Comp.
• The Home returns a CMO completion response, CompCMO, to the Requester.
It is permitted, but not required, for the Home to wait for write data from the Requester before
returning CompCMO.

Combined Immediate Write and Persist CMO

Figure 2-7 on page 2-67 shows the possible transaction flows for Combined Immediate Write and Persist CMO
transaction.

2-66 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Requester Home Subordinate

WriteNoSnpPtlCleanShPerSep, WriteNoSnpFullCleanShPerSep,
WriteUniquePtlCleanShPerSep, WriteUniqueFullCleanShPerSep

alt [1. Combined Write with DWT to Subordinate]

WriteNoSnpPtlCleanShPerSep, WriteNoSnpFullCleanShPerSep
(DoDWT = 1)

DBIDResp

NCBWrData, WriteDataCancel

Comp

Comp

CompCMO

CompCMO

Persist

[2. Non-combined write with DWT to Subordinate]

WriteNoSnpPtl, WriteNoSnpFull
(DoDWT=1)

DBIDResp

NCBWrData, WriteDataCancel

Comp

Comp

alt [2a. Persist CMO to Subordinate]

CleanSharedPersistSep

Comp

CompCMO

Persist

[2b. No CMO to Subordinate as part of transaction]

alt [2b1. Separate response from Home]

CompCMO

Persist

[2b2. Combined response from Home]

CompPersist

[3. No DWT]

alt [3a1. Separate responses from Home]

DBIDResp, DBIDRespOrd

Comp

[3a2. Combined response from Home]

CompDBIDResp

alt [3b1. No CompAck required]

NCBWrData, WriteDataCancel

[3b2. CompAck required]

alt [3b2a. Separate response from Requester]

NCBWrData, WriteDataCancel

CompAck

[3b2b. Combined response from Requester]

NCBWrDataCompAck

alt [3c1. Combined write without DWT to Subordinate]

WriteNoSnpPtlCleanShPerSep, WriteNoSnpFullCleanShPerSep
(DoDWT = 0)

alt [3c1a. Separate responses from Subordinate]

DBIDResp

Comp

[3c1b. Combined response from Subordinate]

CompDBIDResp

NCBWrData, WriteDataCancel

CompCMO

CompCMO

Persist

[3c2. All CMO responses from Home]

alt [3c2a. Separate response from Home]

CompCMO

Persist

[3c2b. Combined response from Home]

CompPersist

[3c3. Only CMO transaction to Subordinate]

CleanSharedPersistSep

Comp

CompCMO

Persist

Requester Home Subordinate

Figure 2-7 Combined Immediate Write and Persist CMO

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-67
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

The sequence for Combined Immediate Write and Persist CMO is:

• The transaction starts with the Requester issuing a Combined Immediate Write and Persist CMO request to
the Home.
The Combined Immediate Write and Persist CMO transactions are:
— WriteNoSnpPtlCleanShPerSep
— WriteNoSnpFullCleanShPerSep
— WriteUniquePtlCleanShPerSep
— WriteUniqueFullCleanShPerSep
Snoop requests that are generated to complete these transactions are considered as independent transactions
from the Home and are not shown in this flow. Write requests that are generated to downstream Subordinates,
which are not part of the DWT flow, are considered as independent transactions and are not shown in this
flow. Also, CMO requests that only return responses to the Home and are generated to downstream
Subordinates are considered independent transactions. See Home Initiated transactions on page 2-84 for
more details on independent transactions from the Home. See Home to Subordinate Write transactions on
page 2-85 for more details on independent Combined Write and CMO transactions from the Home.
The request contains the following fields which affect the transaction flow:
— Opcode
— ExpCompAck
Note
A TagOp value of Match is not permitted in a Combined Immediate Write and Persist CMO
transaction, therefore no TagMatch responses are permitted and the TagOp field does not affect the
transaction flow.

• The Home can choose to complete the transaction using a:

— Combined Write with DWT to the Subordinate.
— Non-combined Write with DWT to the Subordinate.
— Without DWT.
The three approaches are described in alternatives 1-3.
The remainder of the transaction flow will depend on whether the original request required a completion
acknowledge, as determined by the ExpCompAck field.
1. Combined Write with DWT to Subordinate
• The Home sends a downstream combined write request with DoDWT = 1 to the Subordinate.
• The Subordinate returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the
Subordinate.
The Requester must only send this after it has received DBIDResp.
• The Subordinate returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester
before returning Comp to the Home.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before
returning Comp to the Requester.
• The Subordinate returns a CMO completion response, CompCMO, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester
before returning CompCMO to the Home.

2-68 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

• The Home returns a CMO completion response, CompCMO, to the Requester.

It is permitted, but not required, for the Home to wait for Comp or CompCMO from the
Subordinate before returning CompCMO to the Requester. If there is an observer downstream
of the Home, the Home must wait for the CompCMO response from the Subordinate before
returning CompCMO to the Requester.
• The Subordinate returns a persist response, Persist, to the Requester.
It is permitted, but not required, to wait for write data before returning Persist.
2. Non-combined write with DWT to Subordinate
• The Home sends a downstream non-combined write request, WriteNoSnpPtl or
WriteNoSnpFull, with DoDWT = 1 to the Subordinate.
• The Subordinate returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the
Subordinate.
The Requester must only send this after it has received DBIDResp.
• The Subordinate returns a completion response, Comp, to the Home.
It is permitted, but not required, for the Subordinate to wait for write data from the Requester
before returning Comp to the Home.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, for the Home to wait for Comp from the Subordinate before
returning Comp to the Requester.
• The Home has two alternatives to send the CMO responses to the Requester.
Alt 2a. Persist CMO to Subordinate
• The Home sends a downstream request, CleanSharedPersistSep, to the
Subordinate.
• The Subordinate returns a completion response, Comp, to the Home.
• The Home returns a CMO completion response, CompCMO, to the
Requester.
If there is an observer downstream of the Home, then Home must wait for
the Comp response from the Subordinate before returning CompCMO to the
Requester.
• The Subordinate returns a persist response, Persist, to the Requester.
Alt 2b. No CMO to Subordinate as part of transaction
The Home sends all the CMO responses to the Requester. The Home has two
alternatives to do this.
Alt 2b1. Separate responses from Home
The Home does both the following:
• Returns a CMO completion response, CompCMO, to the
Requester.
• Returns a persist response, Persist, to the Requester.
Alt 2b2. Combined response from Home
The Home returns a combined completion and persist response,
CompPersist, to the Requester.
3. No DWT
The Home does not use DWT.
• The Home has two alternatives to request write data.
Alt 3a1. Separate responses from Home
The Home does both of the following:
• Returns a data request, DBIDResp or DBIDRespOrd, to the Requester.
• Returns a completion response, Comp, to the Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-69
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

It is permitted, but not required, to wait for write data before returning Comp.
Alt 3a2. Combined response from Home
The Home returns a combined data request and completion response,
CompDBIDResp, to the Requester.
• The Requester has several alternatives to send write data depending on whether the transaction
requires a completion acknowledge.
Alt 3b1. No CompAck required
The Requester sends write data, NCBWrData, or a write cancellation,
WriteDataCancel, to the Home.
The Requester must only send this after it has received DBIDResp, DBIDRespOrd,
or CompDBIDResp.
Alt 3b2. CompAck required
A completion acknowledge response, CompAck, is required. The Requester has
two alternatives to send write data and CompAck to the Home.
Alt 3b2a. Separate response from Requester
The Requester does both the following:
• Sends write data, NCBWrData, or a write cancellation,
WriteDataCancel, to the Home.
The Requester must only send this after it has received
DBIDResp, DBIDRespOrd, or CompDBIDResp.
• Sends a completion acknowledge, CompAck, to the Home.
The Requester must only send this after it has received Comp or
CompDBIDResp.
It is not permitted to wait for CompCMO or Persist before sending
CompAck.
Alt 3b2b. Combined response from Requester
The Requester sends a combined write data and completion
acknowledge, NCBWrDataCompAck, to the Home.
The Requester must only send this after it has received
CompDBIDResp, or both DBIDResp/DBIDRespOrd and Comp.
It is not permitted to wait for CompCMO or Persist before sending
NCBWrDataCompAck.
• The Home has several alternatives to complete the remainder of the transaction.
Alt 3c1. Combined Write without DWT to Subordinate
• The Home sends a Combined Write without DWT to the Subordinate.
• The Subordinate has two alternatives to request write data.
Alt 3c1a. Separate responses from Subordinate
The Subordinate does both the following:
• Returns a data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, to wait for write data
before returning Comp.
Alt 3c1b. Combined response from Subordinate
The Subordinate returns a combined data request and completion
response, CompDBIDResp, to the Home.
• The Home sends write data, NCBWrData, or a cancellation,
WriteDataCancel, to the Subordinate.
The Home must only send this after it has received DBIDResp or
CompDBIDResp.

2-70 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

• The Subordinate returns a CMO completion response, CompCMO, to the

Home.
It is permitted, but not required, to wait for write data before returning
CompCMO.
• The Home returns a CMO completion response, CompCMO, to the
Requester.
It is permitted, but not required, for the Home to wait for CompCMO from
the Subordinate before returning CompCMO to the Requester.
• The Subordinate returns a persist response, Persist, to the Requester.
It is permitted, but not required, to wait for write data before returning
Persist.
Alt 3c2. All CMO transactions from Home
The Home has two alternatives to send all CMO responses to the Requester.
Alt 3c2a. Separate responses from Home
The Home does both the following:
• Returns a CMO completion response, CompCMO, to the
Requester.
• Returns a persist response, Persist, to the Requester.
Alt 3c2b. Combined response from Home
The Home returns a combined completion and persist response,
CompPersist, to the Requester.
Alt 3c3. Only CMO transactions to Subordinate
• The Home sends a downstream request, CleanSharedPersistSep, to the
Subordinate.
Typically, this alternative would only be used where a write to the
Subordinate has been previously sent as an independent transaction.
• The Subordinate returns a completion response, Comp, to the Home.
• The Home returns a CMO completion response, CompCMO, to the
Requester.
If there is an observer downstream of the Home, then Home must wait for
the Comp response from the Subordinate before returning CompCMO to the
Requester.
• The Subordinate returns a persist response, Persist, to the Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-71
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Combined CopyBack Write and CMO

Figure 2-8 shows the possible transaction flows for a Combined CopyBack Write and CMO transaction.

Requester Home Subordinate

alt [1. Without Persist]

WriteBackFullCleanInv,
WriteBackFullCleanSh,
WriteCleanFullCleanSh

CompDBIDResp

CopyBackWrData

CompCMO

[2. With Persist]

WriteBackFullCleanShPerSep,
WriteCleanFullCleanShPerSep

CompDBIDResp

CopyBackWrData

alt [2a. Persist from Home]

alt [2a1 Separate response from Home]

CompCMO

Persist

[2a2. Combined response from Home]

CompPersist

[2b. Persist from Subordinate]

WriteNoSnpPtlCleanShPerSep,
WriteNoSnpFullCleanShPerSep

alt [2b1. Separate response]

DBIDResp

Comp

[2b2. Combined response]

CompDBIDResp

NCBWrData, WriteDataCancel

CompCMO

CompCMO

Persist

[2c. Only CMO transaction to Subordinate]

CleanSharedPersistSep

Comp

CompCMO

Persist

Requester Home Subordinate

Figure 2-8 Combined CopyBack Write and CMO

There are two possible sequences for Combined CopyBack and CMO transactions.

2-72 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Write requests that are generated to downstream Subordinates and not part of the DWT or persist flow. These write
requests are considered as independent transactions and are not shown in this flow. CMO requests that are generated
to downstream Subordinates, which only return responses to the Home, are considered as independent transactions
and are not shown in this flow. See Home Initiated transactions on page 2-84 for more details on independent
transactions from the Home. See Home to Subordinate Combined Write and CMO transactions on page 2-87 for
more details on independent Combined Write and CMO transactions from the Home.

The request contains the following field which affects the transaction flow:

• Opcode

1. Without Persist
The Combined CopyBack Write and CMO transactions without persist are:
• WriteBackFullCleanInv
• WriteBackFullCleanSh
• WriteCleanFullCleanSh
The Requester issues a Combined CopyBack Write and CMO request without Persist response.
• The Requester issues a request to the Home.
• The Home returns a combined data request and completion response, CompDBIDResp, to the
Requester.
• The Requester sends write data, CopyBackWrData, to the Home.
The Requester must only send this after it has received CompDBIDResp.
• The Home returns a CMO completion response, CompCMO, to the Requester.
It is permitted, but not required, to wait for write data before returning CompCMO.

2. With Persist
The Combined CopyBack write and CMO transactions are:
• WriteBackFullCleanShPerSep
• WriteCleanFullCleanShPerSep
The Requester issues a Combined CopyBack Write and CMO request with Persist response.
• The Requester issues a request to the Home.
• The Home returns a combined data request and completion response, CompDBIDResp, to the
Requester.
• The Requester sends write data, CopyBackWrData, to the Home.
The Requester must only send this after it has received CompDBIDResp.
The Home has three alternatives to complete the transaction, with the persist response either coming from the
Home or from the Subordinate.
Alt 2a. Persist from Home
The Home has two alternatives to send the CMO completion response and persist response.
It is permitted, but not required, for the Home to wait for write data before returning CompCMO,
Persist, or CompPersist.
Alt 2a1 Separate response from Home
• Returns a CMO completion response, CompCMO, to the Requester.
• Returns a persist response, Persist, to the Requester.
Alt 2a2 Combined response from Home
The Home returns a combined CMO completion response and persist response,
CompPersist, to the Requester.
Alt 2b. Persist from Subordinate
When a Combined Write is sent to the Subordinate and the Persist response is returned to the
Requester, the following happens:
• The Home sends a downstream write request, WriteNoSnpPtlCleanShPerSep or
WriteNoSnpFullCleanShPerSep, to the Subordinate.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-73
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

It is permitted, but not required, for the Home to wait for write data before sending the
downstream write request.
• The Subordinate has two alternatives to return the completion response and the data
request response to the Home.
Alt 2b1. Separate response
The Subordinate does both the following:
• Returns a data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 2b2. Combined response
The Subordinate returns a combined data request and completion response,
CompDBIDResp, to the Home.
• The Home sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the
Subordinate.
The Home must only send this after it has received DBIDResp or CompDBIDResp.
• The Subordinate returns a CMO completion response, CompCMO, to the Home.
It is permitted, but not required, to wait for write data before returning CompCMO.
• The Home returns a CMO completion response, CompCMO, to the Requester.
It is permitted, but not required, for the Home to wait for CompCMO from the Subordinate
before returning CompCMO to the Requester.
• The Subordinate returns a persist response, Persist, to the Requester.
It is permitted, but not required, to wait for write data before returning Persist.
Alt 2c. Only CMO transaction to Subordinate
When a persist CMO is sent to the Subordinate and the Persist response is returned to the
Requester, the following happens:
• The Home sends a downstream request, CleanSharedPersistSep, to the Subordinate.
Typically, this alternative would only be used where a write to the Subordinate has been
previously sent as an independent transaction or the write has been canceled.
• The Subordinate returns a completion response, Comp, to the Home.
• The Home returns a completion response, CompCMO, to the Requester.
If there is an observer downstream of the Home, then Home must wait for the Comp
response from the Subordinate before returning CompCMO to the Requester.
• The Subordinate returns a persist response, Persist, to the Requester

2.3.3 Atomic transactions

Figure 2-9 on page 2-75 shows the possible transaction flows for an Atomic transaction.

2-74 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Requester Home

alt [1. AtomicStore]

AtomicStore

alt [1a. Separate responses]

DBIDResp, DBIDRespOrd

Comp

[1b. Combined response]

CompDBIDResp

NCBWrData

opt [Optional TagMatch response]

TagMatch

[2. Other Atomic Transactions]

AtomicLoad/Swap/Compare

DBIDResp, DBIDRespOrd

NCBWrData

CompData

opt [Optional TagMatch response]

TagMatch

Requester Home

Figure 2-9 Atomic transactions

There are two possible sequences for Atomic transactions.

The Requester alternatives are:

1. AtomicStore
For an AtomicStore transaction:
• The Requester sends an AtomicStore request to the Home.
• The Home has two alternatives to send the completion response and the data request response to the
Requester.
Alt 1a. Separate responses
The Home does both the following:
• Returns a data request, DBIDResp or DBIDRespOrd, to the Requester.
• Returns a completion response, Comp, to the Requester.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 1b. Combined response
The Home returns a combined data request and completion response, CompDBIDResp, to
the Requester.
• The Requester sends write data, NCBWrData, to the Home.
The Requester must only send this after it has received DBIDResp, DBIDRespOrd, or
CompDBIDResp.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-75
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

• Optionally, when the request requires a TagMatch response, the Home returns a tag match response,
TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning TagMatch.

2. Other Atomic transactions

For an AtomicLoad, AtomicSwap, or AtomicCompare transaction:
• The Requester sends an AtomicLoad, AtomicSwap, or AtomicCompare request to the Home.
• The Home sends a data request response, DBIDResp or DBIDRespOrd, to the Requester.
• The Requester sends write data, NCBWrData, to the Home.
The Requester must only send this after it has received DBIDResp or DBIDRespOrd. The Requester
must not wait to receive CompData before write data is sent.
• The Home returns a combined data and completion response, CompData, to the Requester.
It is permitted, but not required, to wait for write data before returning CompData.
• Optionally, when the request requires a TagMatch response, the Home returns a tag match response,
TagMatch, to the Requester.
It is permitted, but not required, to wait for write data before returning TagMatch.

2.3.4 Stash transactions

Figure 2-10 on page 2-77 shows the possible transaction flows for stash transactions.

2-76 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Requester Home Stashee

alt [1. Write with Stash Hint]

WriteUniquePtlStash, WriteUniqueFullStash

See Immediate Write for details of WriteUnique completion.

opt
alt [1a. SnpUniqueStash]
SnpUniqueStash

alt [1a1. No DataPull]

SnpResp, SnpRespData, SnpRespDataPtl
(No DataPull)

[1a2. DataPull]
SnpResp, SnpRespData, SnpRespDataPtl
(DataPull)

See Allocating Read for details of read completion.

[1b. Other stashing snoops]

SnpMakeInvalidStash, SnpStashUnique, SnpStashShared

alt [1b1. No DataPull]

SnpResp (No DataPull)

[1b2. DataPull]
SnpResp (DataPull)

See Allocating Read for details of read completion.

[2. Independent Stash without StashDone response]

StashOnceUnique, StashOnceShared

opt
SnpStashUnique, SnpStashShared

alt [2a. No DataPull]

SnpResp (no DataPull)

[2b. DataPull]
SnpResp (DataPull)

See Allocating Read for details of read completion.

Comp

[3. Independent Stash with StashDone response]

StashOnceSepUnique, StashOnceSepShared

opt
SnpStashUnique, SnpStashShared

alt [3a1. No DataPull]

SnpResp (no DataPull)

[3a2. DataPull]
SnpResp (DataPull)

See Allocating Read for details of read completion.

alt [3b1. Separate response from Home]

Comp

StashDone

[3b2. Combined response from Home]

CompStashDone

Requester Home Stashee

Figure 2-10 Stash transactions

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-77
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

There are three possible sequences for Stash transactions.

The following can affect transaction flow:

• It is permitted for the Home to ignore the Stash request and not perform any stash snoops.
• The Stashee is permitted to ignore the Stash request and not request a data pull to complete the transaction.
• StashOnceSepUnique and StashOnceSepShared can have a separate StashDone response or combined
CompStashDone response.

1. Write with Stash Hint

A write with Stash hint starts the transaction. The write with Stash hint requests are:
• WriteUniquePtlStash
• WriteUniqueFullStash
The WriteUnique uses the same transaction flows as an Immediate Write, see Immediate write on page 2-55
for details.
The Home can optionally send a stash snoop request.
Alt 1a. SnpUniqueStash
• The Home sends SnpUniqueStash to the Stashee.
Typically the Home sends SnpUniqueStash for a partial line write. Other snoops, including
other stash snoops, are permitted.
• The Stashee has two alternatives to respond to the stash snoop request.
Alt 1a1. No DataPull
Not request a data pull
Alt 1a2 DataPull
Request a data pull.
The completion of a request with data pull is identical to the completion of an
Allocating Read transaction, see Allocating Read on page 2-47 for details.
Alt 1b. Other stashing snoops
• Send SnpMakeInvalidStash, SnpStashShared, or SnpStashUnique, to the Stashee.
Typically, the Home sends SnpMakeInvalidStash for a full line write. Other snoops,
including other stash snoops, are permitted.
• The Stashee has two alternatives to respond to the stash snoop request.
Alt 1b1. No DataPull
Not request a data pull.
Alt 1b2. DataPull
Request a data pull.
The completion of a request with data pull is identical to the completion of an
Allocating Read transaction, see Allocating Read on page 2-47 for details.

2. Independent Stash without StashDone response

An independent Stash without a StashDone response starts the transaction. The independent Stash requests
without a StashDone response are:
• StashOnceUnique
• StashOnceShared
The Home can optionally send a stash snoop request, SnpStashUnique or SnpStashShared, to the Stashee.
Typically the Home sends SnpStashUnique when the original request is StashOnceUnique and
SnpStashShared when the original request is StashOnceShared.
The Stashee has two alternatives to respond to the stash snoop request.
Alt 2a. No DataPull
Not request a data pull.
Alt 2b. DataPull

2-78 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Request a data pull.

The completion of a request with data pull is identical to the completion of an Allocating Read
transaction, see Allocating Read on page 2-47 for details.
The transaction completes with the Home returning a completion response, Comp, to the original Requester.
It is permitted, but not required, to wait for the stash transaction to complete before the Comp response is
returned.

3. Independent Stash with StashDone response

An independent Stash with a StashDone response starts the transaction. The independent Stash requests with
a StashDone response are:
• StashOnceSepUnique
• StashOnceSepShared
The Home can optionally send a stash snoop request, SnpStashUnique or SnpStashShared, to the Stashee.
Typically the Home sends SnpStashUnique when the original request is StashOnceSepUnique and
SnpStashShared when the original request is StashOnceSepShared.
The Stashee has two alternatives to respond to the stash snoop request.
Alt3a1. No DataPull
Not request a data pull.
Alt 3a2. DataPull
Request a data pull.
The completion of a request with data pull is identical to the completion of an Allocating Read
transaction, see Allocating Read on page 2-47 for further details.
The Home has two alternatives to complete the transaction.
Alt 3b1. Separate response from Home
The Home does both the following:
• Returns a completion response, Comp, to the Requester.
• Returns a stash done response, StashDone, to the Requester.
Alt 3b2. Combined response from Home
The Home returns a combined completion and stash done response, CompStashDone, to the
Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-79
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

2.3.5 Dataless transactions

Figure 2-11 shows the transaction flow for a Dataless transaction.

Requester Home Subordinate

alt [1. Transactions without CompAck or Persist]

CleanInvalid, MakeInvalid, CleanShared,
CleanSharedPersist, Evict

Comp

[2. Transactions with CompAck]

CleanUnique, MakeUnique

Comp

CompAck

[3. Transactions with Persist]

CleanSharedPersistSep

alt [3a. Separate response from Home]

Comp

Persist

[3b.Combined response from Home]

CompPersist

[3c. Response from Home and Subordinate]

CleanSharedPersistSep

Comp

Comp

Persist

Requester Home Subordinate

Figure 2-11 Dataless Transactions

There are three possible sequences for Dataless transactions.

1. Transactions without CompAck or Persist

The Dataless transactions without CompAck or Persist are:
• CleanInvalid
• MakeInvalid
• CleanShared
• CleanSharedPersist
• Evict
The Requester sends the request to the Home.
The Home returns a completion response, Comp, to the Requester.

2. Transactions with CompAck

The Dataless transactions with CompAck are:
• CleanUnique
• MakeUnique
The Requester sends the request to the Home.
The Home returns a completion response, Comp, to the Requester.
The Requester sends a completion acknowledge, CompAck, to the Home.
The Requester must only send this after it has received Comp.

2-80 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

3. CleanSharedPersistSep transaction
The Dataless transaction with Persist is:
• CleanSharedPersistSep
The Requester sends the request to the Home.
The Home has three alternatives to complete the transaction.
Alt 3a. Separate responses from the Home
The Home does both the following:
• Returns a completion response, Comp, to the Requester.
• Returns a persist response, Persist, to the Requester.
Alt 3b. Combined response from Home
The Home returns a combined completion and persist response, CompPersist, to the Requester.
Alt 3c. Response from Home and Subordinate
With the Persist response from the Subordinate, the following happens:
• The Home sends a downstream request, CleanSharedPersistSep, to the Subordinate.
• The Subordinate returns a completion response, Comp, to the Home.
• The Home returns a completion response, Comp, to the Requester.
If there is an observer downstream of the Home, the Home must wait for the Comp
response from the Subordinate before returning the Comp response to the Requester.
• The Subordinate returns a persist response, Persist, to the Requester

2.3.6 Prefetch transactions

Figure 2-12 shows the transaction flow for a Prefetch transaction.

Requester Subordinate

PrefetchTgt

Requester Subordinate

Figure 2-12 Prefetch Transactions

The sequence for the Prefetch transaction is:

• The Requester sends a PrefetchTgt request directly to the Subordinate.

Note
No response is given.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-81
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

2.3.7 DVM transactions

Figure 2-13 shows the transaction flows for a DVM transaction.

Requester Home

DVMOp

alt [1. Non-sync DVMOp with separate response]

DBIDResp

NCBWrData

Comp

[2. Non-sync DVMOp with combined response]

CompDBIDResp

NCBWrData

[3. Sync DVMOp]

DBIDResp

NCBWrData

Comp

Requester Home

Figure 2-13 DVM Transactions

Snoop requests that are generated to complete a DVM transaction are considered as independent transactions from
the Home and are not shown in this flow. See Home to Snoopee DVM transactions on page 2-92 for more details.

The sequence for the DVM transaction is:

• The transaction starts with the Requester issuing a DVMOp request to the Home.

• The Home has three alternatives to send the completion response and the data request response to the
Requester.
1. Non-sync DVMOp with separate response
If the DVMOp is a Non-sync DVMOp, the Home can return separate responses.
• The Home returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, to the Home.
The Requester must only send this after it has received DBIDResp.
• The Home returns a completion response, Comp, to the Requester.
It is permitted, but not required, to wait for write data before returning Comp.
2. Non-sync DVMOp with combined response
If the DVMOp is a Non-sync DVMOp, the Home can return combined responses.
• The Home returns a combined data request and completion response, CompDBIDResp, to the
Requester.
• The Requester sends write data, NCBWrData, to the Home.
The Requester must only send this after it has received CompDBIDResp.

2-82 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

3. Sync DVMOp
If the DVMOp is a Sync DVMOp, the Home must return separate responses.
• The Home returns a data request, DBIDResp, to the Requester.
• The Requester sends write data, NCBWrData, to the Home.
The Requester must only send this after it has received DBIDResp.
• The Home returns a completion response, Comp, to the Requester.
The Home must only return this after it has received write data.

2.3.8 Retry
Figure 2-14 shows the possible transaction flows for a Retry sequence.

Requester Completer

Request without Credit

RetryAck

PCrdGrant

alt [1. Request resent]

Request with Credit

[2. Request cancelled]

PCrdReturn

Requester Completer

Figure 2-14 Retry Transactions

A request transaction is first sent without a Protocol Credit (P-Credit). If the transaction cannot be accepted at the
Completer, a RetryAck response is given indicating that the transaction is not accepted and can be sent again when
an appropriate credit is provided. When the transaction is sent a second time, with a credit, it is guaranteed to be
accepted.

The sequence for the Retry transaction is:

• The Requester issues a request without credit.

• The Completer returns a retry response, RetryAck, to the Requester.

• The Completer returns a protocol credit grant, PCrdGrant, to the Requester.

Typically the protocol credit grant is returned a significant time after the Retry response. However, in an
atypical case, the PCrdGrant response can be returned before the Retry response..

• The Requester has two alternatives to conclude the Retry sequence. This step must only occur after the
Requester has received both RetryAck and PCrdGrant.
1. Resend the original request
The Requester issues a request with credit.
2. Cancel the request and return the credit
The Requester sends a protocol credit return, PCrdReturn, to the Completer.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-83
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

2.3.9 Home Initiated transactions

The Home Initiated transactions are:
• Home to Subordinate Read transactions
• Home to Subordinate Write transactions on page 2-85
• Home to Subordinate Write Zero transactions on page 2-86
• Home to Subordinate Combined Write and CMO transactions on page 2-87
• Home to Subordinate Dataless transactions on page 2-88
• Home to Subordinate Atomic transactions on page 2-89
• Home to Snoopee transactions on page 2-91
• Home to Snoopee DVM transactions on page 2-92

Home to Subordinate Read transactions

Figure 2-15 shows the possible transaction flows for a Home to Subordinate Read transaction.

Home Subordinate

alt [1. Combined response from Subordinate]

ReadNoSnp

opt [Order != 00]

ReadReceipt

CompData

[2. Separate response from Subordinate]

ReadNoSnpSep

opt [Order != 00]

ReadReceipt

DataSepResp

Home Subordinate

Figure 2-15 Home Read Transactions

The supported transactions are ReadNoSnp and ReadNoSnpSep.

The transaction flow depends on the transaction type.

1. Combined response from Subordinate

• For a ReadNoSnp transaction, the Home issues the request to the Subordinate.
• Optionally, when the request has Order set to non-zero the Subordinate returns a ReadReceipt
response.
• The Subordinate returns a combined completion response and read data, CompData, to the Home.

2. Separate responses from Subordinate

• For a ReadNoSnpSep transaction, the Home issues the request to the Subordinate.
• Optionally, when the request has Order set to non-zero, the Subordinate returns a ReadReceipt
response.
• The Subordinate returns read data, DataSepResp, to the Home.

2-84 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Home to Subordinate Write transactions

Figure 2-16 shows the possible transaction flows for a Home to Subordinate Write transaction.

Home Subordinate

WriteNoSnpPtl, WriteNoSnpFull

alt [1. Separate response]

DBIDResp

Comp

[2. Combined response]

CompDBIDResp

NCBWrData, WriteDataCancel

opt [Optional TagMatch response]

TagMatch

Home Subordinate

Figure 2-16 Home Write Transactions

The sequence for the Home to Subordinate Write transaction is:

• The transaction starts with the Home issuing a WriteNoSnpPtl or WriteNoSnpFull request to the Subordinate.

• The Subordinate has two alternatives to return the completion response and the data request response to the
Home.
1. Separate response
The Subordinate does both the following:
• Returns a Data request response, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, to wait for write data before returning Comp.
2. Combined response
The Subordinate returns a combined data request and completion response, CompDBIDResp, to the
Home.

• The Home sends write data, NCBWrData, or a cancellation, WriteDataCancel to the Subordinate.
The Home must only send this after it has received DBIDResp or CompDBIDResp.

• Optionally, when the request requires a TagMatch response, the Subordinate returns a Tag match response,
TagMatch, to the Home.
It is permitted, but not required, to wait for write data before returning TagMatch.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-85
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Home to Subordinate Write Zero transactions

Figure 2-17 shows the possible transaction flows for a Home to Subordinate Write Zero transaction.

Home Subordinate

WriteNoSnpZero

alt [1. Seperate response from Home]

DBIDResp

Comp

[2. Combined response from Home]

CompDBIDResp

Home Subordinate

Figure 2-17 Home to Subordinate Write Zero

The sequence for Write Zero is:

• The transaction starts with the Home issuing a Write Zero request to the Subordinate.
The Write Zero transaction is:
— WriteNoSnpZero

• The Subordinate has two alternatives to return the completion response and data request response to the
Home.
1. Separate response from Home
The Subordinate does both the following:
• Returns a data request response, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
2. Combined response from Home
The Subordinate returns a combined data request and completion response, CompDBIDResp, to the
Home.

2-86 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Home to Subordinate Combined Write and CMO transactions

Figure 2-18 shows the possible transaction flows for a Home to Subordinate Combined Write and CMO transaction.

Home Subordinate

WriteNoSnpPtlCleanInv, WriteNoSnpFullCleanInv,
WriteNoSnpPtlCleanSh, WriteNoSnpFullCleanSh,
WriteNoSnpPtlCleanShPerSep, WriteNoSnpFullCleanShPerSep

alt [1a. Separate responses from Subordinate]

DBIDResp

Comp

[1b. Combined response from Subordinate]

CompDBIDResp

NCBWrData, WriteDataCancel

alt [2a. Non-persist CMO]

CompCMO

[2b. Persist CMO]

alt [2b1. Separate response from Subordinate]

CompCMO

Persist

[2b2. Combined response from Subordinate]

CompPersist

Home Subordinate

Figure 2-18 Home Combined Write and CMO Transactions

The sequence for the Home to Subordinate Combined Write with CMO transaction is:

• The transaction starts with the Home issuing a Combined Write and CMO request to the Subordinate.
The Home Combined Write and CMO transactions are:
— WriteNoSnpPtlCleanInv
— WriteNoSnpFullCleanInv
— WriteNoSnpPtlCleanSh
— WriteNoSnpFullCleanSh
— WriteNoSnpPtlCleanShPerSep
— WriteNoSnpFullCleanShPerSep

• The Subordinate has two alternatives to send the completion response and the data request response to the
Home.
Alt 1a. Separate responses from Subordinate
The Subordinate does both the following:
• Returns a data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 1b. Combined response from Subordinate
The Subordinate returns a combined data request and completion response, CompDBIDResp, to
the Home.

• The Home sends write data, NCBWrData, or a cancellation, WriteDataCancel, to the Subordinate.
The Home must only send this after it has received DBIDResp or CompDBIDResp.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-87
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

• There are two alternatives for the Subordinate to return the CMO response depending on whether or not a
persist response, Persist, is required.
It is permitted, but not required, for the Subordinate to wait for write data before returning CompCMO,
Persist, or CompPersist.
Alt 2a. Non-persist CMO
When a persist response is not required, the Subordinate returns a CMO completion response,
CompCMO, to the Home.
Alt 2b. Persist CMO
When a persist response is required, the Subordinate has two alternatives to send the CMO
completion response and persist response.
Alt 2b1. Separate response from Subordinate
The Subordinate does both the following:
• Returns a CMO completion response, CompCMO, to the Home.
• Returns a persist response, Persist, to the Home.
Alt 2b2. Combined response from Subordinate
The Subordinate returns a combined CMO completion response and persist response,
CompPersist, to the Home.

Home to Subordinate Dataless transactions

Figure 2-19 shows the transaction flows for a Home to Subordinate Dataless transaction.

Home Subordinate

alt [1. Transactions without separate Persist]

CleanInvalid, MakeInvalid,
CleanShared, CleanSharedPersist

Comp

[2. Transactions with separate Persist]

CleanSharedPersistSep

alt [2a. Separate response from Subordinate]

Comp

Persist

[2b.Combined response from Subordinate]

CompPersist

Home Subordinate

Figure 2-19 Home to Subordinate Dataless Transactions

The transaction flow depends on the request type.

The Home Dataless transactions are:

• CleanInvalid
• MakeInvalid
• CleanShared
• CleanSharedPersist
• CleanSharedPersistSep

The sequence for the Home to Subordinate Dataless transaction is:

1. Transactions without separate Persist:

2-88 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

CleanInvalid, MakeInvalid, CleanShared, or CleanSharedPersist transaction

• The Home sends the request to the Subordinate.
• The Subordinate returns a completion response, Comp, to the Requester.

2. Transactions with separate Persist:

CleanSharedPersistSep transaction
• The Home sends the request to the Subordinate.
• The Subordinate has two alternatives to complete the transaction.
Alt 2a. Separate response from Subordinate
The Subordinate does both the following:
• Returns a completion response, Comp, to the Home.
• Returns a persist response, Persist, to the Home.
Use of separate completion response, Comp, and persist response, Persist, allows a
Completer to send an early Comp without waiting for Persist. Typically, Persist
takes much longer.
Alt 2b. Combined response from Subordinate
The Subordinate returns a combined completion and persist response, CompPersist, to the
Home.

Home to Subordinate Atomic transactions

Figure 2-20 shows the possible transaction flows for a Home to Subordinate Atomic transactions.

Home Subordinate

alt [1. AtomicStore]

AtomicStore

alt [1a. Separate responses]

DBIDResp

Comp

[1b. Combined response]

CompDBIDResp

NCBWrData

opt [TagOp == Match]

TagMatch

[2. Not Atomic Store]

AtomicLoad/Swap/Compare

DBIDResp

NCBWrData

CompData

opt [TagOp == Match]

TagMatch

Home Subordinate

Figure 2-20 Home Atomic transactions

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-89
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

The Atomic transactions the Home can issue are:

• AtomicStore
• AtomicLoad
• AtomicSwap
• AtomicCompare

When the Subordinate supports the execution of atomic operations, the Home is permitted, but not required, to
forward Atomic transactions to the Subordinate.

There are two alternatives for the Home to complete the transaction, depending on the request type.

1. AtomicStore
• The Home sends an AtomicStore request to the Subordinate.
• The Subordinate has two alternatives to send the completion response and data request response to the
Home.
Alt 1a. Separate responses
The Subordinate does both the following:
• Returns a data request, DBIDResp, to the Home.
• Returns a completion response, Comp, to the Home.
It is permitted, but not required, to wait for write data before returning Comp.
Alt 1b. Combined response
The Subordinate returns a combined data request and completion response,
CompDBIDResp, to the Home.
• The Home sends write data, NCBWrData, to the Subordinate.
The Home must only send this after it has received DBIDResp or CompDBIDResp. The Home must
not wait for Comp before sending write data.
• Optionally, when the request requires a tag match response, the Subordinate returns a TagMatch
response to the Home.
It is permitted, but not required, to wait for write data before returning TagMatch.

2. Not AtomicStore
• The Home sends an AtomicLoad, AtomicSwap, or AtomicCompare request to the Subordinate.
• The Subordinate sends a data request response, DBIDResp, to the Home.
• The Home sends write data, NCBWrData, to the Subordinate.
The Home must only send this after it has received DBIDResp. The Home must not wait to receive
CompData before write data is sent.
• The Subordinate returns a combined data and completion response, CompData, to the Home.
It is permitted, but not required, to wait for write data before returning CompData.
• Optionally, when the request requires a TagMatch response, the Subordinate returns a tag match
response, TagMatch, to the Home.
It is permitted, but not required, to wait for write data before returning TagMatch.

2-90 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.3 Transaction structure

Home to Snoopee transactions

Figure 2-21 shows the possible transaction flows for a Home to Snoopee transaction.

Home Snoopee

Snp*, Snp*Fwd

alt [1. Response to home]

SnpResp

[2. Data to home]

SnpRespData, SnpRespDataPtl

Home Snoopee

Figure 2-21 Home Snoop Transactions

The following transactions must use this transaction flow.

• SnpOnce
• SnpClean
• SnpNotSharedDirty
• SnpShared
• SnpUnique
• SnpPreferUnique
• SnpCleanShared
• SnpCleanInvalid
• SnpMakeInvalid

The following transactions are also permitted, but not required, to use this transaction flow.
• SnpOnceFwd
• SnpCleanFwd
• SnpNotSharedDirtyFwd
• SnpSharedFwd
• SnpUniqueFwd
• SnpPreferUniqueFwd

The sequence the Home to Snoopee transaction is:

• The transaction starts with the Home issuing a Snoop request to the Snoopee.

• The Snoopee has two alternatives to complete the transaction.

1. The Snoopee provides a snoop response, SnpResp, to the Home.
This is the only permitted alternative for a SnpMakeInvalid transaction.
2. The Snoopee provides a snoop response with data, SnpRespData or SnpRespDataPtl.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-91
ID092622 Non-Confidential
Transactions
2.3 Transaction structure

Home to Snoopee DVM transactions

Figure 2-22 shows the transaction flow for a Home to Snoopee DVM transaction, SnpDVMOp.

Home Snoopee

SnpDVMOp

SnpDVMOp

SnpResp

Home Snoopee

Figure 2-22 Home DVM Snoop

The sequence for the Home to Snoopee DVM transaction is:

• The Home issues two Snoop DVM requests, SnpDVMOp, to the Snoopee.
• The Snoopee provides a single Snoop response, SnpResp.
The Snoopee must only provide the Snoop response after it has received both Snoop DVM requests.

2-92 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.4 Transaction identifier fields

2.4 Transaction 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 fields that route packets across the interconnect:

• Target Identifier, TgtID, and Source Identifier, SrcID

The fields that relate all the packets associated with a single transaction are:
• Transaction Identifier, TxnID
• Data Buffer Identifier, DBID on page 2-94
• Return Transaction Identifier, ReturnTxnID on page 2-95
• Forward Transaction Identifier, FwdTxnID on page 2-95

The field that identifies the individual data packets within a transaction:
• Data Identifier, DataID, and Critical Chunk Identifier, CCID on page 2-96

The fields that identify individual processing agents within a single Requester:
• Logical Processor Identifier, LPID on page 2-96
• Stash Logical Processor Identifier, StashLPID on page 2-96

The field that identifies the target node for a Stash transaction:
• Stash Node Identifier, StashNID on page 2-96

The field that identifies the recipient node for the Data response, Persist response, or TagMatch response:

• Return Node Identifier, ReturnNID on page 2-96

The field that identifies the recipient node for the Data response:

• Forward Node Identifier, FwdNID on page 2-98

The field that is used to identify the recipient node for the CompAck response:

• Home Node Identifier, HomeNID on page 2-97

The field that is used to identify different sets of transactions:

• Persistence Group Identifier, PGroupID on page 2-98
• Stash Group Identifier, StashGroupID on page 2-98
• Tag Group Identifier, TagGroupID on page 2-99

2.4.1 Target Identifier, TgtID, and Source Identifier, SrcID

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.

2.4.2 Transaction Identifier, TxnID

A transaction request includes a TxnID that is used to identify the transaction from a given Requester. It is required
that the TxnID, except for PrefetchTgt, 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.

A 12-bit field is defined for the TxnID with the number of outstanding transactions being limited to 1024. A
Requester is permitted to reuse a TxnID value after it has received either:
• All responses associated with a previous transaction that have used the same value.
• A RetryAck response for a previous transaction that used the same value.

Transaction identifier field flows on page 2-100 gives more detailed rules for the different transaction types. The
TxnID field is not applicable in a PrefetchTgt request and can take any value.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-93
ID092622 Non-Confidential
Transactions
2.4 Transaction identifier fields

A value used in the TxnID field of a Request from Home to Subordinate can be reused by Home once all responses
that are required to deallocate the request are received or a RetryAck response is received.

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

2.4.3 Data Buffer Identifier, DBID

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. The DBID value is used as the TxnID field value in the:
• WriteData response of Immediate Write, CopyBack Write, Combined Write, Atomic, and DVMOp
transactions.
• CompData response of Stash transactions for Data Pull purposes.
• CompAck response of Read, Dataless, WriteNoSnp, WriteUnique and Immediate Combined Write
transactions that include a CompAck response.

The DBID value used by a Completer in responses of a given transaction must be unique for a given Requester in
the following cases:
• DBIDResp or DBIDRespOrd or CompDBIDResp for all Write transactions, except in WriteNoSnpZero and
WriteUniqueZero.
• DBIDResp or DBIDRespOrd or CompDBIDResp for all Combined Write transactions.
• DBIDResp or DBIDRespOrd or CompDBIDResp for Atomic transactions.
• DBIDResp or DBIDRespOrd or CompDBIDResp for DVMOp transactions.
• CompData or RespSepData for Read transactions that include CompAck, except in the case when
ReadOnce* and ReadNoSnp do not use the resultant CompAck for deallocation of the request at Home.
• Comp for Dataless transactions that include CompAck.

The DBID value is applicable in the DataSepResp response to Read requests that include CompAck and it must be
the same as the DBID value in the associated RespSepData response.

A Comp response message sent separate from a DBIDResp or DBIDRespOrd message for a Write or Combined
Write transaction must include the same DBID field value in the Comp and DBIDResp or DBIDRespOrd message
when the two messages originate from the same source.
A Comp response message sent separate from a DBIDResp or DBIDRespOrd message for a Atomic transaction is
permitted, but is not required, to include the same DBID field value in the Comp and DBIDResp or DBIDRespOrd
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 required to deallocate
a previous transaction that has used the same value. Transaction identifier field flows on page 2-100 gives more
detailed rules for the different transaction types.

The DBID value used by a Snoop Completer in response to a Stash snoop that includes a Data Pull must be unique
with respect to:
• The DBID values in other Snoop responses to Stash snoops that use Data Pull.
• The TxnID of any outstanding request from that Snoop Completer.

The Completer is not required to utilize the DBID field, and is permitted to set it to any value in:
• WriteNoSnpZero and WriteUniqueZero transactions.
• Read transactions without CompAck.
• Dataless transactions without CompAck.
• Snoop response to a Stash snoop that does not include a Data Pull.
• Snoop response to a Non-stash snoop.

Note
The advantage of using the DBID assigned by the Completer, instead of the TxnID assigned by the Requester, is
that the Completer can use the DBID to index into its request structure instead of performing a lookup using TxnID
and SrcID to determine which transaction write data or completion acknowledge is associated with which request.

2-94 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.4 Transaction identifier fields

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

The DBIDResp response is also used to provide certain ordering guarantees relating to the transaction. See
Transaction ordering on page 2-125.

2.4.4 Return Transaction Identifier, ReturnTxnID

A transaction request from Home to Subordinate also includes a ReturnTxnID field to convey the value of TxnID
in the data response and the DBIDResp response from the Subordinate. Its value, when applicable, must be either:
• The TxnID generated by Home, when the ReturnNID is the node ID of the Home.
• The TxnID of the original Requester, when the ReturnNID is the node ID of the original Requester.

ReturnTxnID is only applicable in a ReadNoSnp, ReadNoSnpSep, WriteNoSnp, Combined Write, and Atomic
requests from Home to Subordinate. The field is inapplicable and must be set to zero in all other requests from Home
to Subordinate.

ReturnTxnID is inapplicable and must be set to zero in all requests from Requester to Home and Requester to
Subordinate.

The following are the expected and permitted values for ReturnTxnID in requests from the Home Node to the
Subordinate Node.

In ReadNoSnp and ReadNoSnpSep:

• Expected value is the original Requester TxnID but permitted to be the Home TxnID.
• Used as the TxnID in the CompData and DataSepResp responses.

In Atomic with TagOp Invalid or Match:

• For AtomicStore, the ReturnTxnID can take any value, and the value is not used in any response.

• For Non-store Atomics, the ReturnTxnID must be the Home TxnID. The value is used as the TxnID in the
CompData response.

In WriteNoSnp with any TagOp value:

• When DoDWT = 0, ReturnTxnID can take any value, and the value is not used in any response.
• When DoDWT = 1, ReturnTxnID value is expected to be the original Requester TxnID but is permitted to
be the Home TxnID. Used as the TxnID in the DBIDResp response.

In Combined Write:
• When DoDWT = 0, ReturnTxnID can take any value, and the value is not used in any response.
• When DoDWT = 1, ReturnTxnID value is expected to be the original Requester TxnID but is permitted to
be the Home TxnID. Used as the TxnID in the DBIDResp response.

2.4.5 Forward Transaction Identifier, FwdTxnID

A Snoop request from Home to RN-F also includes a FwdTxnID field to convey the value of TxnID in the Data
response from the Snoopee. Its value must be the TxnID of the original Request.

The FwdTxnID field is only applicable in:

• SnpSharedFwd
• SnpCleanFwd
• SnpOnceFwd
• SnpNotSharedDirtyFwd
• SnpUniqueFwd
• SnpPreferUniqueFwd

It is inapplicable and must be set to zero in all other snoops.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-95
ID092622 Non-Confidential
Transactions
2.4 Transaction identifier fields

2.4.6 Data Identifier, DataID, and Critical Chunk Identifier, CCID

These fields identify the individual data packets within a transaction.

See Data packetization on page 2-144 and Critical Chunk Identifier on page 2-148.

2.4.7 Logical Processor Identifier, LPID

This field is used when a single Requester contains more than one logically separate processing agent. The SrcID
is used with LPID to uniquely identify the logical processor that generated the request.

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
— ReadNotSharedDirty
— ReadPreferUnique
— MakeReadUnique
— CleanUnique
— ReadNoSnp
— WriteNoSnp
See Chapter 6 Exclusive accesses for further details.

For other transactions, the LPID value is permitted, but not required, to indicate the original logical processor that
caused a transaction to be issued.

In requests, when applicable, the same bits in the packet are used for TagGroupID, PGroupID, and StashGroupID.

2.4.8 Stash Logical Processor Identifier, StashLPID

The StashLPID field can be used to specify a particular LP within the Request Node specified by StashNID, when
the corresponding StashLPIDValid bit is asserted. See Stash Logical Processor Identifier, StashLPID on
page 13-427.

See Supporting REQ packet fields on page 7-310 for the permitted combinations of StashLPIDValid and
StashNIDValid.

2.4.9 Stash Node Identifier, StashNID

The StashNID field provides Request Node that is the target of the Stash transaction when the corresponding
StashNIDValid bit is asserted. See Stash Node Identifier, StashNID on page 13-426.

2.4.10 Return Node Identifier, ReturnNID

A transaction request from Home to Subordinate includes a ReturnNID that is used to determine the TgtID for the
following responses from the Subordinate Node:
• Data response
• DBIDResp response
• Persist response
• TagMatch response

Its value must be either the node ID of Home or the node ID of the original Requester.

2-96 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.4 Transaction identifier fields

ReturnNID is only applicable in a ReadNoSnp, ReadNoSnpSep, CleanSharedPersistSep, WriteNoSnp, Combined

Write, and Atomic requests from Home to Subordinate. The field is inapplicable and must be set to zero in all other
requests from Home to Subordinate.

ReturnNID is inapplicable and must be set to zero in all requests from Requester to Home and Requester to
Subordinate.

The following are the expected and permitted values for the ReturnNID in requests from the Home Node to the
Subordinate Node.

In ReadNoSnp, ReadNoSnpSep, and CleanSharedPersistSep:

• Expected value is the original Requester Node ID but is permitted to be the Home Node ID.
• Used as the TgtID in CompData, DataSepResp and Persist responses.

In Atomic with TagOp Invalid:

• For AtomicStore, ReturnNID can take any value and the value is not used in any responses.
• For Non-store Atomics, the ReturnNID must be the Home Node ID. The value is used as the TgtID in
CompData.

In Atomic with TagOp Match:

• ReturnNID must be the Home Node ID.
• The value is used as the TgtID in CompData and TagMatch responses.

In WriteNoSnp with TagOp not Match:

• When DoDWT = 0, the ReturnNID can take any value, and the value is not used in any responses.
• When DoDWT = 1, the ReturnNID value is expected to be the original Requester Node ID but is permitted
to be the Home Node ID. Used as the TgtID in the DBIDResp response.

In WriteNoSnp with TagOp Match:

• Irrespective of the value of DoDWT, the ReturnNID value is expected to be the original Requester Node ID
but is permitted to be the Home Node ID.
• When DoDWT = 0, the value is used as the TgtID in the TagMatch response only.
• When DoDWT = 1, the value is used as the TgtID in the DBIDResp and TagMatch responses.

In Non-PCMO Combined Write:

• When DoDWT = 0, the ReturnNID can take any value, and the value is not used in any responses.

• When DoDWT = 1, the ReturnNID value is expected to be the original Requester Node ID but is permitted
to be the Home Node ID. Used as the TgtID in the DBIDResp response.

In WriteNoSnpFullClnShPer and WriteNoSnpPtlClnShPer:

• Irrespective of the value of DoDWT, the ReturnNID value is expected to be the original Requester Node ID
but is permitted to be the Home Node ID.
• When DoDWT = 0, the value is used as the TgtID in the Persist response only.
• When DoDWT = 1, the value is used as the TgtID in the DBIDResp and Persist responses.

2.4.11 Home Node Identifier, HomeNID

CompData includes the HomeNID field that is used by the Requester to identify the target of the CompAck that it
might need to send in response to CompData. HomeNID is applicable in CompData and DataSepResp and is
inapplicable and must be set to zero for all other Data messages.

Note
There is no functional requirement for the HomeNID and DBID fields in the DataSepResp response because the
values that are provided in the RespSepData response are identical and can always be used. However, it is required
that these values are included to help with debugging and protocol checking.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-97
ID092622 Non-Confidential
Transactions
2.4 Transaction identifier fields

2.4.12 Forward Node Identifier, FwdNID

A Snoop request from Home to RN-F includes a FwdNID that is used to determine the TgtID for the Data response
from the Snoopee. Its value must be the Node ID of the original Requester.

The FwdNID field is only applicable in:

• SnpSharedFwd
• SnpCleanFwd
• SnpOnceFwd
• SnpNotSharedDirtyFwd
• SnpUniqueFwd
• SnpPreferUniqueFwd

It is inapplicable and must be set to zero in all other snoops, except range-based TLBI DVM operations. For
range-based TLBI operations, the bits in the field are used for DVM payload.

2.4.13 Persistence Group Identifier, PGroupID

A CleanSharedPersistSep and Combined Write with Persistent CMO (PCMO) request includes a PGroupID to
identify the Persistence Group that the request belongs to. If a Requester has persistent CMO requests from different
functional agents that it would like to identify for performant persistent CMO handling, it can assign a different
PGroupID value to each group of Persist requests. Use of this 8-bit field is applicable in CleanSharedPersistSep and
Combined Write with PCMO transactions. It is also applicable in Persist and CompPersist responses. It is
inapplicable and must be set to zero in all other requests and responses. See Persistence Group Identifier, PGroupID
on page 13-426:

• PGroupID must be sent in the CleanSharedPersistSep request and a Combined Write request that includes a
PCMO.

• The PGroupID value returned in the Persist response can be used by a Requester to separately track
completions of Persist responses from each group.

• It is expected that a Requester that does not support multiple persistence groups sets the PGroupID value to
zero.

• A Requester that is making use of PGroupID for passing a barrier typically will not reuse a PGroupID value
until all the earlier sent CleanSharedPersistSep requests from that group have received Persist responses.

• The Completer is required to reflect back PGroupID in the Persist and CompPersist responses, and the
responses of Combined Write requests that include a PCMO.

• The PGroupID field in the Comp and CompCMO response from both the Home and Subordinate is
inapplicable and must be set to zero.

2.4.14 Stash Group Identifier, StashGroupID

To identify the Stash group that the request belongs to, a StashOnceSep request includes a StashGroupID. The same
StashGroupID value from the request is then used by a StashDone response later on in the transaction flow. If a
Requester has StashOnceSep requests from different functional agents that it would like to identify for performant
stash handling, it can assign a different StashGroupID value to each group of Stash requests.

Use of this 8-bit field is applicable in the StashOnceSep request and StashDone response. It is inapplicable and must
be set to zero in all other requests and responses.

• StashGroupID must be sent in the StashOnceSep request.

• The StashGroupID value returned in the StashDone response can be used by a Requester to separately track
completions of Stash transactions from each group.

• It is expected that a Requester that does not support multiple stash groups sets the StashGroupID value to
zero.

2-98 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.4 Transaction identifier fields

• The Completer is required to reflect back StashGroupID in the StashDone response.

See Stash Group Identifier, StashGroupID on page 13-427.

2.4.15 Tag Group Identifier, TagGroupID

To identify the Tag group that the request belongs to, a Write request where TagOp is set to Match includes a
TagGroupID. The same TagGroupID value from the request is then used by a TagMatch response later on in the
transaction flow to notify the Requester if the TagMatch operation passed or failed.

Use of this 8-bit field is applicable in Write requests where TagOp is set to Match, and in a TagMatch response. It
is inapplicable and must be set to zero in all other requests and responses.

• TagGroupID must be sent in a Write request where TagOp is set to Match.

• The precise contents of TagGroupID are implementation defined. Typically, TagGroupID is expected to
contain an Exception Level, TTBR value, and PE identifier.

See Tag Group Identifier, TagGroupID on page 13-443.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-99
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

2.5 Transaction identifier field flows

This section shows the transaction identifier field flows for the different transaction types:
• Read transactions on page 2-101
• Dataless transactions on page 2-109
• Write transactions on page 2-111
• DVMOp transaction on page 2-119
• Transaction requests with Retry on page 2-119
• Protocol Credit Return transaction on page 2-120

In the associated figures:

• The fields included in each packet are:

— For a Request packet: TgtID, SrcID, TxnID, StashNID, StashLPID, ReturnNID, ReturnTxnID,
PGroupID, StashGroupID, and TagGroupID.
— For a Response packet: TgtID, SrcID, TxnID, DBID, PGroupID, StashGroupID, and TagGroupID.
— For a Data packet: TgtID, SrcID, TxnID, HomeNID, and DBID.
— For a Snoop packet: SrcNID, TxnID, FwdNID, FwdTxnID, and StashLPID.

• 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 parentheses 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.

• It is permitted for the TgtID of the original transaction to be remapped 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 asterisk 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.

In the following examples, any transaction identifiers that are not relevant for the example are sometimes omitted
for clarity.

2-100 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

2.5.1 Read transactions

This section shows identifier field flows in Read transactions with and without Direct Data Transfer:
• ID value transfer with DMT
• ID value transfer with DMT and separate Comp and Data on page 2-103
• ID value transfer with DCT on page 2-105
• ID value transfer without Direct Data Transfer on page 2-107

ID value transfer with DMT

Figure 2-23 shows how the Target and Transaction ID values in the DMT transaction messages are derived. For
example, the value of SrcID in the ReadNoSnp request from the interconnect is assigned by the interconnect.
Whereas the ReturnNID, used as TgtID in the Data response, is set to the value of SrcID of the received Read
request.

RN ICN SN

* TgtID (TgtID)
* TgtID R (TgtID) * (SrcID) SrcID
* (SrcID) SrcID * TxnID TxnID
Read ReadNoSnp
* TxnID TxnID ReturnNID ReturnNID
ReturnTxnID ReturnTxnID

TgtID
ReadReceipt (SrcID)
(Optional) TxnID
DBID

(TgtID) TgtID
SrcID (SrcID)
To RN
TxnID CompData CompData TxnID
HomeNID HomeNID
DBID DBID

TgtID
(SrcID)
CompAck
TxnID
DBID

Figure 2-23 ID value transfer in a DMT transaction

The required steps in the flow that Figure 2-23 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 TxnID field that is unique for that Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-101
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

2. The recipient Home Node in the interconnect generates a Request to the Subordinate Node.
The identifier fields of the request are generated as follows:
• The TgtID is set to the value required for the Subordinate.
• The SrcID is a fixed value for the Home.
• The TxnID is a unique value generated by the Home.
• The ReturnNID is set to the same value as the SrcID of the original request.
• The ReturnTxnID is set to the same value as the TxnID of the original request.

3. If the request to the Subordinate requires a ReadReceipt, the Subordinate 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 Subordinate. 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.

4. The Subordinate 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 ReturnNID of the request.
• The SrcID is a fixed value for the Subordinate. This also matches the TgtID received.
• The TxnID is set to the same value as the ReturnTxnID of the request.
• The HomeNID is set to the same value as the SrcID of the request.
• The DBID is set to the same value as the TxnID of the request.

5. The Requester receives the read data and sends a completion acknowledge, CompAck, response.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the HomeNID of the read data.
• The SrcID is a fixed value for the Requester. This also matches the TgtID that was received.
• The TxnID is set to the same value as the DBID of the read data.
• The DBID field is not valid.

The CompAck response from Requester to Home is not required for all requests.

If the original request requires a ReadReceipt, the following additional step is included:

• The Home 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.

Transaction identifier fields on page 2-93 details when the TxnID value and DBID value can be reused.

2-102 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

ID value transfer with DMT and separate Comp and Data

Figure 2-24 shows how the identifier field values are derived in DMT transaction messages that use separate Comp
and Data.

RN ICN SN
* TgtID
* (SrcID)
(TgtID)
* TxnID
SrcID
ReturnNID
* TgtID R (TgtID) ReadNoSnpSep TxnID
ReturnTxnID
* (SrcID) Read SrcID ReturnNID
* TxnID TxnID ReturnTxnID

(TgtID) TgtID
SrcID (SrcID)
RespSepData
TxnID TxnID
TgtID
DBID * DBID
(SrcID)
ReadReceipt
TxnID
TgtID
DBID
(SrcID)
CompAck
TxnID
DBID

(TgtID) TgtID
SrcID (SrcID)
To RN
TxnID DataSepResp DataSepResp TxnID
HomeNID HomeNID
DBID DBID

Figure 2-24 ID value transfer in a DMT transaction with separate Comp and Data

The required steps in the flow that Figure 2-24 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 TxnID field that is unique for that Requester.

2. The recipient Home Node in the interconnect generates a request to the Subordinate Node.
The identifier fields of the request are generated as follows:
• The TgtID is set to the value required for the Subordinate.
• The SrcID is a fixed value for the Home.
• The TxnID is a unique value generated by the Home.
• The ReturnNID is set to the same value as the SrcID of the original request.
• The ReturnTxnID is set to the same value as the TxnID of the original request.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-103
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

3. The recipient Home Node in the interconnect provides the separate Read response.
The identifier fields of the read 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 Home.
• The TxnID is set to the same value as the TxnID of the original request.
• The DBID value is a unique value generated by the Home and is the same value as the TxnID in the
request to the Subordinate.

4. The Requester receives the Read response and sends a completion acknowledge, CompAck, response.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the SrcID of the read response.
• The SrcID is a fixed value for the Requester.
• The TxnID is set to the unique DBID value generated by the Home.
• The DBID value is not valid.

5. The request to the Subordinate requires a ReadReceipt. The Subordinate 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 Subordinate. This also matches the TgtID received.
• The TxnID is set to the same value as the TxnID of the request.

6. The Subordinate provides the separate read data.

The identifier fields of the read data are generated as follows:
• The TgtID is set to the same value as the ReturnNID of the request.
• The SrcID is a fixed value for the Subordinate. This also matches the TgtID received.
• The TxnID is set to the same value as the ReturnTxnID of the request.
• The HomeNID is set to the same value as the SrcID of the request.
• The DBID is set to the same value as the TxnID of the request.

2-104 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

ID value transfer with DCT

Figure 2-25 shows how the identifier field values are derived in DCT transaction messages. In this example, the data
is forwarded to a Request Node and a Snoop response is sent to HN-F with or without data.

RN ICN RN-F

* TgtID R (TgtID) * (SrcID) SrcID

* (SrcID) SrcID * TxnID TxnID
Read Snp[*]Fwd
* TxnID TxnID FwdNID FwdNID
FwdTxnID FwdTxnID

(TgtID) TgtID
SrcID * (SrcID)
TxnID TxnID
To RN
HomeNID CompData CompData HomeNID
DBID DBID

TgtID TgtID
(SrcID) * (SrcID)
CompAck To HN-F To HN-F SnpRespFwded
TxnID or TxnID
DBID SnpRespDataFwded DBID

Figure 2-25 ID value transfer in a DCT transaction

The required steps in the flow that Figure 2-25 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 TxnID field that is unique for that Requester.

2. The recipient Home Node in the interconnect generates a Forwarding snoop to the RN-F node.
The identifier fields of the snoop are generated as follows:
• The SrcID is a fixed value for the Home.
• The TxnID is a unique value generated by the Home.
• The FwdNID is set to the same value as the SrcID of the original request.
• The FwdTxnID is set to the same value as the TxnID of the original request.

3. The RN-F 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 FwdNID of the snoop.
• The SrcID is a fixed value for the RN-F.
• The TxnID is set to the same value as the FwdTxnID of the snoop.
• The HomeNID is set to the same value as the SrcID of the snoop.
• The DBID is set to the same value as the TxnID of the snoop.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-105
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

4. The RN-F also provides a response to Home, either with or without read data.
The identifier fields of the response are generated as follows:
• The TgtID is set to the same value as the SrcID of the snoop.
• The SrcID is a fixed value for the RN-F.
• The TxnID is set to the same value as the TxnID of the snoop.
• The DBID field is not valid.

5. The Requester receives the read data and sends a completion acknowledge, CompAck, response.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the HomeNID of the read data.
• The SrcID is a fixed value for the Requester. This also matches the TgtID that was received.
• The TxnID is set to the same value as the DBID of the read data.
• The DBID field is not valid.

Note
An optional ReadReceipt from the interconnect to Requester can also be included.

2-106 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

ID value transfer without Direct Data Transfer

This section gives an example of a Read identifier field flow without DMT or DCT and describes the use of the
TxnID and DBID fields for Read transactions.

The Requester and Completer in this example are a Request Node and an HN-F respectively.

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-26 shows the ID value transfer.

Requester Completer

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

Optional

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

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

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

Figure 2-26 ID value transfer in a Read request with ReadReceipt and CompAck

The required steps in the flow that Figure 2-26 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-107
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

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 HomeNID is a fixed value for the Completer. This also matches the TgtID received.
• The Completer generates a unique DBID value if ExpCompAck in the request is asserted.

4. The Requester receives the read data and sends a completion acknowledge, CompAck, respone.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the HomeNID of the read data.
• The SrcID is a fixed value for the Requester. This also matches the TgtID that was received.
• The TxnID is set to the same value as the DBID of the read data.
• The DBID field is not valid.

2-108 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

2.5.2 Dataless transactions

For Dataless transactions, with the exception of CleanSharedPersistSep and StashOnceSep, the use of identifier
fields is similar to ID value transfer without Direct Data Transfer on page 2-107. 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.

For StashOnceSep transactions, the StashGroupID value is sent in the request from the Request Node to the
interconnect and the value is returned in the StashDone and CompStashDone responses. The TxnID value in the
StashDone response is inapplicable and must be set to zero.

The description of ID value transfer in a CleanSharedPersistSep transaction follows.

ID value transfer in a CleanSharedPersistSep transaction

Figure 2-27 shows how the identifier field values are derived in CleanSharedPersistSep transaction messages that
use separate Comp and Persist responses. In Figure 2-27, PCMOSep represents CleanSharedPersistSep.

RN ICN SN

* TgtID (TgtID)
* (SrcID) SrcID
* TgtID R (TgtID) * TxnID TxnID
PCMOSep
* (SrcID) SrcID ReturnNID ReturnNID
PCMOSep
* TxnID TxnID ReturnTxnID ReturnTxnID
* PGroupID PGroupID PGroupID PGroupID

TgtID TgtID
(SrcID) Comp (SrcID)
TxnID TxnID (TgtID) TgtID
SrcID Comp (SrcID)
TxnID TxnID

(TgtID) TgtID
SrcID (SrcID)
Persist To RN Persist
TxnID TxnID
PGroupID PGroupID

Figure 2-27 ID value transfer in a CleanSharedPersistSep transaction

The required steps in the flow that Figure 2-27 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 TxnID value that is unique for that Requester.
The TxnID value can be reused by the Requester after receiving the Comp response.
• The Requester generates a new PGroupID value, or reuses a PGroupID value currently in use.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-109
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

2. The recipient Home Node in the interconnect generates a request to the Subordinate.
The identifier fields of the request to the Subordinate Node are generated as follows:
• The TgtID is set to the value required for the Subordinate.
• The SrcID is a fixed value for the Home.
• The TxnID is a unique value generated by the Home.
The TxnID value can be reused by the Home after receiving the Comp response.
• The ReturnNID is set to the same value as the SrcID of the original request.
• The ReturnTxnID is inapplicable and must be set to zero.
• The PGroupID is set to the same value as the PGroupID of the original request.

3. The recipient Home Node in the interconnect sends a Comp response to the Requester.
The identifier fields of the Comp response to the Requester are generated as follows:
• The TgtID is set to the same value as the SrcID of the original request.
• The SrcID is a fixed value for the Home.
• The TxnID is set to the same value as the TxnID of the original request.

4. The recipient Home Node can optionally send a Persist response to the Requester.
The identifier fields of the optional Persist response from the Home Node to the Requester, not shown in
Figure 2-27 on page 2-109, 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 Home Node.
• The TxnID is inapplicable and must be set to zero.
• The PGroupID is set to the same value as the PGroupID of the request.
The recipient Home Node can optionally send a combined CompPersist response to the Requester, instead of
separate Comp and Persist responses.
The identifier fields in the CompPersist response are generated as follows:
• The TgtID is set to the same value as the SrcID of the original request.
• The SrcID is a fixed value for the Home.
• The TxnID is set to the same value as the TxnID of the original request.
• The PGroupID is set to the same value as the PGroupID of the original request.

5. The Subordinate Node generates a Comp to the Home Node.

The identifier fields of the Comp response from the Subordinate Node 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 Subordinate.
• The TxnID is set to the same value as the TxnID of the request.

6. The Subordinate Node also generates a Persist response to either to the Requester or the Home.
The identifier fields of the Persist response from the Subordinate Node are generated as follows:
• The TgtID is set to the same value as the ReturnNID of the request.
• The SrcID is a fixed value for the Subordinate.
• The TxnID is inapplicable and must be set to zero.
• The PGroupID is set to the same value as the PGroupID of the request.

7. The Subordinate Node can optionally send a combined CompPersist response to the Home Node, instead of
separate Comp and Persist responses if the ReturnNID and SrcID of the request are the same value.
The identifier fields of the CompPersist response from the Subordinate 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 Subordinate.
• The TxnID is set to the same value as the TxnID of the request.
• The PGroupID is set to the same value as the PGroupID of the request.

2-110 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

2.5.3 Write transactions

This section describes the use of the TxnID and DBID fields for Write transactions:
• CopyBack transaction
• WriteNoSnp transaction on page 2-113
• WriteUnique transaction on page 2-115
• StashOnce or StashOnceSep transaction on page 2-117

CopyBack transaction
This section describes the use of the identifier fields for a CopyBack transaction.

Figure 2-28 shows the identifier value transfer.

Requester Completer

* TgtID R (TgtID)
* (SrcID) SrcID
CopyBack
* TxnID TxnID

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

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

Figure 2-28 ID value transfer in a CopyBack

The required steps in the flow that Figure 2-28 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-111
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

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. This helps to determine which transaction to associate the write data.
After receiving all write data packets, the Completer can reuse the same DBID value for another transaction.

2-112 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

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

Figure 2-29 does not show the Memory Tagging supported TagGroupID flow. For TagGroupID transfer details see
Write transactions on page 12-386 in Chapter 12 Memory Tagging.

Figure 2-29 shows the identifier value transfer for separate Comp and DBIDResp. The Completer can
opportunistically combine the Comp and DBIDResp into a single CompDBIDResp response. The Requester can
opportunistically combine NCBWrData with CompAck.

Requester Completer

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

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

(TgtID)
TgtID
SrcID
(SrcID)
TxnID
TxnID NCBWrData
DBID
DBID

(TgtID) TgtID
SrcID (SrcID)
Comp
TxnID TxnID
DBID DBID
Optional

TgtID (TgtID)
(SrcID) SrcID
CompAck
TxnID TxnID
DBID DBID
Optional

TgtID (TgtID)
(SrcID) SrcID
NCBWrDataCompAck
TxnID TxnID
DBID DBID

Figure 2-29 ID value transfer in a WriteNoSnp

The uses 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-113
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

The required steps in the flow that Figure 2-29 on page 2-113 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.

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 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.

6. The Requester sends a CompAck message, if the transaction requires it, after receiving DBIDResp or Comp.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the SrcID of the DBIDResp or Comp response.
• The SrcID is a fixed value for the Requester. This also matches the TgtID that was received.
• The TxnID is set to the same value as the DBID of the DBIDResp or Comp response.
• The DBID field is not valid.

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

After receiving all the 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. It is required that the values
used are identical when the two messages originate from the same source.

2-114 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

WriteUnique transaction
This section describes the use of the identifier fields for a WriteUnique transaction.

Figure 2-30 does not show the Memory Tagging supported TagGroupID flow, For TagGroupID transfer details see
Write transactions on page 12-386 in Chapter 12 Memory Tagging.

Under certain circumstances, the WriteUnique transaction can also 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.
— If a combined WriteData and CompAck response is sent, then the TgtID is set to the same value as the
SrcID in the Comp, DBIDResp, or CompDBIDResp, and the TxnID in the combined response is set
to the same value as the DBID in Comp, DBIDResp, or CompDBIDResp.

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

Figure 2-30 shows the identifier value transfer with a combined CompDBIDResp response.

Requester Completer

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

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

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

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

Figure 2-30 ID value transfer with a combined CompDBIDResp response

Figure 2-31 on page 2-116 shows the identifier value transfer with a combined WriteData and CompAck response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-115
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

Requester Completer

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

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

Alternative combined WriteData and CompAck

TgtID (TgtID)
(SrcID) SrcID
TxnID TxnID
NCBWrDataCompAck
DBID DBID

Figure 2-31 ID value transfer with a combined WriteData and CompAck response

2-116 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

StashOnce or StashOnceSep transaction

This section describes the use of the identifier fields for a StashOnce or StashOnceSep transaction with DataPull.

Figure 2-32 shows the identifier value transfer.

RN RN-F
ICN

* (SrcID) SrcID
* TgtID R (TgtID) * TxnID TxnID
Snp[*]Stash
* (SrcID) SrcID StashLPID StashLPID
* TxnID StashOnce or TxnID
* StashNID StashOnceSep StashNID
* StashLPID StashLPID
* StashGroupID StashGroupID RN-F NID
same as
StashNID

TgtID
Comp
TxnID SrcID (SrcID)
(TgtID) TgtID
SnpResp_I_Read
For StashOnceSep TxnID TxnID
DBID DBID *
TgtID
StashDone TxnID (SrcID) SrcID
StashGroupID TgtID (TgtID)
TxnID TxnID
CompData
Alternative combined * DBID DBID
Comp and StashDone * (HomeNID) HomeNID

TgtID TgtID
CompStashDone TxnID CompAck (SrcID)
StashGroupID TxnID
DBID

Figure 2-32 ID value transfer in a Stash transaction

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

1. The Requester starts the transaction by sending a Stash 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 TxnID field that is unique for that Requester.
• The Requester includes the StashNID field to indicate to which RN-F to send the Stash.
• The Requester includes the StashLPID field to indicate the logical processor within the RN-F.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-117
ID092622 Non-Confidential
Transactions
2.5 Transaction identifier field flows

2. The Home Node in the interconnect receives the Stash request packet and sends the Comp response to the
Request Node.
The identifier fields of the Comp response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The TxnID is set to the same value as the TxnID of the request.

3. The Home Node in the interconnect, for the StashOnceSep request, sends the StashDone response to the
Request Node.
The identifier fields of the StashDone response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The TxnID is not valid.
• StashGroupID is set to the same value as the StashGroupID of the request.
Alternatively for the StashOnceSep request, the Home Node in the interconnect sends the combined
CompStashDone response instead of separate Comp and StashDone responses to the Request Node.
The identifier fields of the CompStashDone response are generated as follows:
• The TgtID is set to the same value as the SrcID of the request.
• The TxnID is set to the same value as the TxnID of the request.
• The StashGroupID is set to the same value as the StashGroupID of the request.

4. The Home Node in the interconnect generates a snoop with Stash to the appropriate RN-F.
The identifier fields of the request are generated as follows:
• The SrcID is a fixed value for the Home.
• The TxnID is a unique value generated by the Home.
• The StashLPID is set to the same value as the StashLPID of the original request.
Note
A Snoop request does not include a TgtID field.

5. The snooped RN-F generates a Snoop response. In this example, it includes a Data Pull indication.
The identifier fields of the Snoop 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 RN-F.
• The TxnID is set to the same value as the TxnID of the request.
• The DBID field is a unique value generated by the RN-F.

6. The Home 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 Snoop response.
• The SrcID is a fixed value for the Home.
Note
In this example, the read data is being provided by the Home.

• The TxnID is set to the same value as the DBID of the Snoop response.
• The DBID field is a unique value generated by Home.
• The HomeNID is a fixed value for the Home.

7. The RN-F receives the read data and sends a completion acknowledge, CompAck, response.
The identifier fields of the CompAck are generated as follows:
• The TgtID is set to the same value as the HomeNID of the read data.
• The SrcID is a fixed value for the RN-F. This also matches the TgtID received.
• The TxnID is set to the same value as the DBID of the read data.
• The DBID field is not valid.

2-118 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.5 Transaction identifier field flows

2.5.4 DVMOp transaction

The use of the TgtID, SrcID, TxnID, and DBID identifier fields for a DVMOp transaction is identical to that for the
WriteNoSnp transaction.

2.5.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-154, for more details on the Retry mechanism, and Protocol Credit Return transaction, for
rules about the return of unused credits.

Figure 2-33 shows the identifier value transfer.

Requester Completer

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

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

(TgtID) TgtID
SrcID (SrcID)
PCrdGrant
TxnID TxnID
DBID DBID
PCrdType PCrdType

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

Figure 2-33 ID value transfer in a transaction request with retry

The required steps in the flow that Figure 2-33 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-119
ID092622 Non-Confidential
Transactions
2.5 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, but not required, 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.5.6 Protocol Credit Return transaction

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-120 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

2.6 Ordering
This section describes the mechanisms that the protocol includes to support system ordering requirements. It
contains the following subsections:
• Multi-copy atomicity
• Completion response and ordering
• Completion acknowledgment on page 2-123
• Transaction ordering on page 2-125

For the meaning of the terms EWA, Device, and Cacheable see Memory Attributes on page 2-134.

2.6.1 Multi-copy atomicity

The memory model used in this specification requires multi-copy atomicity. 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.

2.6.2 Completion response and ordering

Table 2-7 shows the Comp, RespSepData, CompData, or Persist response, which guarantees the ordering of a
transaction with respect to later transactions, either from the same agent or from another agent.

Table 2-7 Completion response and ordering

Transaction Location Response Outcome

Read Cacheable CompData or The transaction is observable to a later

DataSepResp transaction from any agent to the same
location.

Cacheable RespSepData No earlier transaction will send a snoop to this

Requester. All later transactions will send a
snoop only if required after the Home receives
the CompAck response for this transaction.

Non-cacheable or RespSepData or The transaction is observable to a later

Device CompData transaction from any agent to the same
endpoint address range.

Write or Atomic Cacheable Comp or The transaction is observable to a later

CompData transaction from any agent to the same
location.

Non-cacheable or Comp or The transaction is observable to a later

Device CompData transaction from any agent to the same
endpoint range.

Dataless except for Comp The transaction is observable to a later

StashOnceSep transaction from any agent to the same
memory location.

CleanSharedPersist Comp Any data written earlier to the same memory

location is made persistent.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-121
ID092622 Non-Confidential
Transactions
2.6 Ordering

Table 2-7 Completion response and ordering (continued)

Transaction Location Response Outcome

Combined Write CompCMO CMO, PCMO, and write operations are

observable to a later transaction from any
agent to the same memory location.

Comp The write operation is observable to a later

transaction from any agent to the same
endpoint address range.

CleanSharedPersistSep Persist The data written earlier to the same memory

location is made persistent.

Combined Write with Persist The data write in the Combined Write is made
Persistent CMO persistent. All earlier writes on the same line
will also be made persistent.

StashOnceSep Comp The Completer accepts the request and will

not send a RetryAck response.

StashDone The transaction is observable to a later

transaction from any agent to the same
memory location.

Note
The size of the endpoint address range is IMPLEMENTATION DEFINED.

In a combined Ordered Write Observation (OWO) Write request, if the write is canceled, that is, the Requester sends
a WriteDataCancel, then the required cache maintenance on the write data is not carried out. The Requester must
resend both the Write request and the CMO:

• If the combined request that had its write canceled is a Write with PCMO:
— The Persist response for the combined request does not indicate that the write data is made persistent.
— The Requester must resend the PCMO either combined with the resent Write request or after the resent
Write request succeeds.

• If the combined request that had its write canceled is a Write with CMO:
— The Requester must resend the CMO, either combined with the re-sent Write request or after the resent
Write request succeeds.

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 deassertion of the MemAttr[2] Cacheable bit in the
request.

A component must only give a Comp or CompDBIDResp response when it is guaranteed that all observers will see
the result of the atomic operation.

A Comp response in a canceled write only implies that the transaction loop is completed and makes no statement
regarding the completion of coherency action initiated by the write. Therefore, the Completer is permitted to send
a Comp as soon as it receives a WriteDataCancel response without dependency on either the processing of the write
request or the completion of any snoops sent due to the write.

2-122 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

2.6.3 Completion acknowledgment

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 acknowledge, CompAck, 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 Read transaction and the sending of CompAck is as follows:
1. An RN-F sends a CompAck after receiving Comp, RespSepData, or CompData, or both RespSepData and
DataSepResp.
2. An HN-F, except in the case of ReadOnce*, waits for CompAck before sending a subsequent snoop to the
same address. For CopyBack transactions, WriteData acts as an implicit CompAck and an HN-F must wait
for WriteData before sending a 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.

When an RN-F has a transaction in progress that uses CompAck, except for ReadNoSnp and ReadOnce*, it is
guaranteed not to receive a Snoop request to the same address between the point that it receives Comp and the point
that it sends CompAck.

For WriteNoSnp and WriteUnique transactions that require a CompAck message, a Request Node sends the
CompAck after receiving the Comp, DBIDResp, or CompDBIDResp response.

The use of CompAck for a transaction is determined by the Requester setting the ExpCompAck field in the original
request. The rules for a Request Node setting the ExpCompAck field and generating a CompAck response are as
follows:

• An RN-F must include a CompAck response in all Read transactions except ReadNoSnp and ReadOnce*.

• An RN-F is permitted, but not required, to include a CompAck response in ReadNoSnp and ReadOnce*
transactions.

• An RN-F must not include a CompAck response in StashOnce, CMO, Atomic, or Evict transactions.

• An RN-I or RN-D is permitted, but not required, to include a CompAck response in Read transactions.

• An RN-I or RN-D must not include a CompAck response in Dataless or Atomic transactions.

• A Request Node that wants to make use of DMT must include a CompAck response in ordered ReadNoSnp
and ReadOnce* transactions.

• For Write transactions, CompAck can only be used for WriteUnique and WriteNoSnp transactions when they
require Ordered Write Observation guarantees. See Streaming Ordered Write transactions on page 2-129.

• For WriteEvictOrEvict, ExpCompAck must be set to one indicating the transaction will include a CompAck
when the Completer sends a Comp instead of a CompDBIDResp.

For transactions between a Request Node and a Home Node, where the Home Node is the Completer, the Home
Node must support the use of CompAck for all transactions that are required or permitted to use CompAck.

A Subordinate Node 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 2-8 on page 2-124 shows the Request types that require a CompAck response and the corresponding
Requester types that are required to provide that response. The following key is used:
Y Yes, required
N No, not required
O Optional

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-123
ID092622 Non-Confidential
Transactions
2.6 Ordering

- Not applicable

Table 2-8 Requester CompAck requirement

Request type CompAck Required

RN-F RN-D, RN-I

ReadNoSnp O O

ReadOnce* O O

ReadClean Y -

ReadNotSharedDirty Y -

ReadShared Y -

ReadUnique Y -

ReadPreferUnique Y -

MakeReadUnique Y -

CleanUnique Y -

MakeUnique Y -

CleanShared N N

CleanSharedPersist* N N

CleanInvalid N N

MakeInvalid N N

WriteBack N -

WriteClean N -

WriteUnique O O

WriteUniqueZero N N

Evict N -

WriteEvictFull N -

WriteEvictOrEvict Y -

WriteNoSnp O O

WriteNoSnpZero N N

Atomics N N

StashOnce N N

In a Combined Write transaction, the CompAck requirement is the same as the CompAck requirement for the type
of Write in the Combined Write transaction.

2-124 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

2.6.4 Ordering semantics of RespSepData and DataSepResp

When a Requester receives the first DataSepResp, it can consider the Read transaction to be globally observed. This
is because there is no action which can modify the read data received.

When a Requester receives a RespSepData response from Home, the request that it applies to has been ordered at
Home and the Requester will not receive any snoops for transactions that are scheduled before it. Before sending
RespSepData response to the Requester, the Home must ensure that no Snoop transactions are outstanding to that
Requester to the same address. Receiving of RespSepData does not guarantee that Home has completed snooping
of other agents in the system.

When the Requester gives a completion acknowledge, CompAck, response, this Requester is indicating that it will
accept responsibility to hazard snoops for any transaction that is scheduled after it. The following rules apply:

• For all transactions, except as described immediately below, the CompAck must be sent after the
RespSepData response is received. It is permitted, but not required, to wait for the DataSepResp response
before the CompAck is given.

• For ReadOnce and ReadNoSnp transactions with an ordering requirement, that is, Order field is set to 0b10
or 0b11 and ExpCompAck field is asserted, it is required that the CompAck is given only after both
DataSepResp and RespSepData responses are received.

• The Requester must wait to receive both RespSepData and DataSepResp before issuing another request to
the same address.

Note
It is required that CompAck must not be given when only DataSepResp is received.

2.6.5 Transaction ordering

In addition to using a Comp response to order a sequence of requests from a Requester, this specification also
defines mechanisms for ordering of requests between a Request Node, Home Node pair and an HN-I, SN-I pair.
Between an HN-F, SN-F pair and HN-I, SN-I pair, the order field is used to obtain a Request Accepted
acknowledgment.

Requester Order between an RN, HN pair and an 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.

Endpoint Order
This guarantees the order of multiple transactions, from the same agent, to the same
endpoint address range.

Ordered Write Observation, OWO

This guarantees the observation order by other agents in the system, for a sequence of Write
transactions from a single agent.

Request Accepted
This guarantees that the Completer will send a positive acknowledgment only when it has
accepted the Read request.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-125
ID092622 Non-Confidential
Transactions
2.6 Ordering

Table 2-9 shows the Order field encodings.

Table 2-9 Order value encodings

Order[1:0] Description Permitted between

0b00 No ordering required All

0b01 Request accepted HN-F to SN-F and HN-I to SN-I

Reserved RN to HN

0b10 Request Order/Ordered Write Observation RN to HNa

Request Order HN-I to SN-I

Reserved HN-F to SN-F

0b11 Endpoint Order RN to HN and HN-I to SN-I

Reserved HN-F to SN-F

a. Request Order when ExpCompAck = 0.

Ordered Write Observation when ExpCompAck = 1.

Ordering requirements
A Requester that changes the ordering requirements of a transaction to a stronger ordering requirement is required
to be consistent in changing the ordering requirement of Request Order to Endpoint Order on all its transactions.

The Order field must only be set to a non-zero value for the following transactions:
• ReadNoSnp
• ReadNoSnpSep
• ReadOnce*
• WriteNoSnp
• WriteNoSnpCMO
• WriteNoSnpZero
• WriteUnique
• WriteUniqueCMO
• WriteUniqueZero
• Atomic

When a ReadNoSnp or ReadOnce* transaction requires Request Order or Endpoint Order:

• The Requester 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.

• A Completer that is capable of sending separate Non-data and Data-only responses can send RespSepData
response instead of ReadReceipt and achieve the same functional behavior.

When a WriteNoSnp, WriteNoSnpZero, or a Non-snoopable Atomic transaction requires Request Order or

Endpoint Order:

• The Requester requires a DBIDResp or DBIDRespOrd to determine when it can send the next ordered
request.

2-126 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

• The Completer sending a DBIDResp or DBIDRespOrd response means that a data buffer is available and 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.
— For requests that require Endpoint Order, it will maintain order between requests to the same endpoint
address range from the same source.

When a WriteUnique transaction without ExpCompAck asserted, or a WriteUniqueZero or a Snoopable Atomic

transaction require Request Order:
• The Requester requires a DBIDResp or DBIDRespOrd to determine when it can send the next ordered
request.
• The Completer sending a DBIDResp or DBIDRespOrd response means that it will maintain order between
requests to the same address from the same source.

Additionally, when a Completer sends DBIDRespOrd for a request with a no order or Request Order requirement,
the Completer guarantees to order all subsequent no order or Request Order received requests to the same address
from the same source against this request, where these later received requests are of any transaction type, not
necessarily Write transactions. When the write includes a CMO, the order is guaranteed against both the write and
the CMO.

When a WriteUnique or WriteNoSnp transaction requires Ordered Write Observation:

• CompAck is required. The Request Node must assert ExpCompAck.

• The Request Node requires a DBIDResp or DBIDRespOrd.

• The Completer is a PoS. A PoS sending DBIDResp or DBIDRespOrd 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.

All architectural mechanisms applicable to increasing streaming efficiency and corresponding constraints are
defined in Streaming Ordered Write transactions on page 2-129.

When a ReadNoSnp or ReadNoSnpSep has the Order field set to 0b01, a ReadReceipt response from the Completer
guarantees that the Completer has accepted the request and will not send a RetryAck response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-127
ID092622 Non-Confidential
Transactions
2.6 Ordering

Read Request Order example

Figure 2-34 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
ReadNoSnp-2 waits
for a CreditGrant Request gets
a Retry
response
RetryAck-2

PCrdGrant
ReadNoSnp-3
continues waiting for
ReadNoSnp-2 to
make progress
ReadNoSnp-2
ReadNoSnp-3 is sent
after Read Receipt-2
ReadReceipt-2
is received
ReadNoSnp-3

ReadReceipt-3

Figure 2-34 Series of ordered Read requests

Three ordered requests are sent from Request Node to Home Node in Figure 2-34 as follows:

1. The Request Node sends the ReadNoSnp-1 request to the Home Node.

2. The Home Node accepts the request and returns the ReadReceipt-1 response to the Request Node.

3. After the ReadReceipt-1 response is received, the Request Node sends the ReadNoSnp-2 request to the Home
Node.

4. The Home Node cannot immediately accept the ReadNoSnp-2 request and returns the RetryAck-2 response
to the Request Node.

5. The Request Node must now wait for a PCrdGrant to be sent from the Home Node before resending the
ReadNoSnp-2 request. The Request Node 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 the
Home Node before ReadNoSnp-3 is sent to the Home Node.

6. After receipt of an appropriate PCrdGrant, the Request Node resends the ReadNoSnp-2 request.

7. The Home Node accepts the request and returns a ReadReceipt-2 response to the Request Node.

2-128 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

8. After receipt of the ReadReceipt-2 response, the Request Node sends the ReadNoSnp-3 request to the Home
Node.

9. The Home Node accepts the request and returns the ReadReceipt-3 response to the Request Node.

10. Each of the read transactions is completed with Requester receiving a completion and data. This is not shown
in Figure 2-34 on page 2-128.

Note
Figure 2-34 on page 2-128 shows a single ordered stream of three reads from the Request Node. However, a Request
Node can have multiple streams of reads, so requests must be ordered within a stream. However, ordering
dependency does not exist between streams. One example of this is when the streams are from different threads
within the Request Node. In this case, the Request Node waits for the ReadReceipt of the previous request from the
same thread only before sending out the next ordered request from that stream.

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. It is permitted, but not required, for an Atomic transaction
with SnoopMe asserted to be issued before the CompDBIDResp response is received for an outstanding CopyBack
to the same cache line.

Streaming Ordered Write transactions

The architectural mechanisms applicable to increasing Ordered Write Observation (OWO) Write streaming
efficiency, and the corresponding constraints, are applicable to WriteUnique and WriteNoSnp transactions only. If
a Requester requires a sequence of Write transactions to be observed in the same order as they are issued, the
Requester can wait for completion before issuing the next write in the sequence. Such an observation ordering is
typically termed OWO.

This specification provides a mechanism termed Streaming Ordered Writes to more efficiently stream such ordered
Write transactions.

The Streaming Ordered Write mechanism relies on the use of the OWO ordering requirement and CompAck.
Responsibilities of Requesters and HN-F when utilizing the Streaming Ordered Write solution are:

• The Requester must set the Order field to 0b10 and set ExpCompAck on the Write request.

• The OWO requirement in a Write 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, DBIDRespOrd, CompDBIDResp, or Comp for a Write transaction
before sending the next Write request.

• The Requester must send a CompAck response after receiving DBIDResp, DBIDRespOrd,
CompDBIDResp, or Comp responses for the corresponding writes and Comp or CompDBIDResp responses
for all earlier related ordered writes. If write data is to be sent, the Requester is permitted, but not required,
to combine the CompAck response with the WriteData response into a NCBWrDataCompAck response.
When the Requester uses the combined CompAck and WriteData response for a transaction, it must send a
combined response for all WriteData transfers in that transaction. The method by which a Requester
determines if a group of ordered writes are related is IMPLEMENTATION DEFINED.

Note
Waiting to send CompAck response until all prior writes have received their Comp responses ensures the
operations at the respective HN-Fs have completed. Any Requester observing the write associated with the
CompAck response will also observe all prior ordered writes.

• The Requester that receives DBIDResp and is ready to send CompAck must not wait for Comp to send
CompAck.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-129
ID092622 Non-Confidential
Transactions
2.6 Ordering

• HN-F must wait for a CompAck response from the Request Node before deallocating a Write transaction and
making the write visible to other observers.

Optimized Streaming Ordered Write transactions

The writes in this section refer to WriteUnique or WriteNoSnp only. The Streaming Ordered Writes mechanism can
be further optimized. If a previously sent write is to a different target, the Requester does not need to wait for the
DBIDResp for the request before sending the next ordered write. However, if the interconnect can remap the
TgtID, the Requester must presume that all Write transactions are targeting the same HN-F and must not use the
optimized version of the Streaming Ordered Writes flow.

An implementation using an optimized or non-optimized Streaming Ordered Writes solution must avoid deadlock
and livelock situations.

Note
A technique for avoiding resource-related deadlock or livelock issues is to limit Streaming Ordered Writes
optimization to one Requester in the system. All other Requesters in the system can use the Streaming Ordered
Writes solution without the optimization.

In a typical system, the optimized Streaming Ordered Writes 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.

OWO Writes can be used by more than one Requester by making use of WriteDataCancel messages to avoid
resource related deadlocks and livelocks.

2-130 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.6 Ordering

Figure 2-35 shows a typical transaction flow in which an RN-I uses Streaming Ordered WriteUnique transactions.
This flow prevents a read acquiring the new value of Write-B before Write-A has completed.

Note
For clarity, the Write-B DBIDResp and the NCBWrData flow is omitted from Figure 2-35.

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 2-35 Streaming Ordered WriteUnique transactions flow

The Streaming Ordered WriteUnique transaction flow is as follows:

1. RN-I issues WriteUnique-A to the Home.

2. The Home responds with DBIDResp and issues SnpCleanInvalid-A to RN-F1 and RN-F2.

3. RN-I sends the write data associated with WriteUnique-A and issues the next ordered WriteUnique request
to the Home, shown in Figure 2-35 as WriteUnique-B.

4. WriteUnique-A and WriteUnique-B are to different addresses. The Home sends out SnpCleanInvalid-B
snoops to RN-F1 and RN-F2 for WriteUnique-B without waiting for responses for WriteUnique-A
transaction snoops.

5. The Snoop responses for the WriteUnique-B transaction are received by the Home before the Snoop
responses for the WriteUnique-A transaction are received. Home sends Comp to RN-I for the WriteUnique-B
transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-131
ID092622 Non-Confidential
Transactions
2.6 Ordering

6. The Home waits for Snoop responses for the WriteUnique-A transaction to be received. Once received, the
Home can send Comp to RN-I for the WriteUnique-A transaction.

7. The Requester, RN-I, receives Comp-B and waits to receive Comp-A before proceeding with the next
response.

8. Once the RN-I receives Comp-A, it sends the corresponding CompAck response for the WriteUnique-A
transaction, followed by a CompAck response for the WriteUnique-B transaction.

2-132 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.7 Address, Control, and Data

2.7 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.

In this section, unless explicitly stated otherwise, a reference to a Write transaction includes both the individual
Write transaction and the corresponding Combined Write transaction.

2.7.1 Address
This specification supports:
• Physical Address (PA) of 44 to 52 bits, in one bit increments.
• Virtual Address (VA) of 49 to 53 bits.

The REQ and SNP packet Addr fields are specified as follows:
• REQ channel: Address[(MPA-1):0]
• SNP channel: Address[(MPA-1):3]

MPA is the Maximum PA supported.

Table 2-10 shows the relationship between the physical address field width and the supported virtual address.

Table 2-10 Addr field width and supported PA and VA size

Maximum address
REQ Addr field supported in bits
width in bits
PA VA

44 44 49

45 45 51

46 to 52 46 to 52 53

See DVMOp and SnpDVMOp packet on page 8-325 for DVM payload mapping in the REQ and SNP fields with
different Addr field widths.

The Req_Addr_Width parameter is used to specify the maximum physical address in bits that is supported by a
component. Valid values for this parameter are 44 to 52, when not specified, the parameter takes the default value
of 44.

2.7.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.

The Non-secure assertion requirements are:

• Can be asserted in any Read, Dataless, Write, and Atomic transaction.
• Can be asserted in PrefetchTgt transaction.
• Is not applicable in the DVMOp or PCrdReturn transaction, and must be set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-133
ID092622 Non-Confidential
Transactions
2.7 Address, Control, and Data

2.7.3 Memory Attributes

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

EWA
EWA indicates whether the Write completion response for a transaction:
• Can come from an intermediate point in the interconnect, such as a Home Node.
• Must come from the final endpoint at the target destination.

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 2-121.

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

Note
It is permitted, but not required, for an implementation not to use the EWA attribute. In this instance, completion
must be given from the endpoint.

The EWA assertion requirements:

• Can take any value in:
— A ReadNoSnp and ReadNoSnpSep transaction
— A WriteNoSnp transaction.
— CMO transactions.
— Atomic transactions.
• Must be asserted in any:
— Read transaction that is not a ReadNoSnp or ReadNoSnpSep transaction.
— Dataless transaction that is not a CMO transaction.
— Write transaction that is not a WriteNoSnp transaction.
• Is inapplicable and:
— Must be set to zero in the DVMOp or PCrdReturn transactions.
— Can take any value in the PrefetchTgt transaction.

2-134 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.7 Address, Control, and Data

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.

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.
• CMO transactions are permitted to Device memory locations.
• Atomic transactions are permitted to Device memory locations.
• The PrefetchTgt transaction is not permitted to Device memory locations. The MemAttr field is inapplicable
and can take any value in the PrefetchTgt transaction.

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, Write, PrefetchTgt, or Atomic 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-135
ID092622 Non-Confidential
Transactions
2.7 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:

• Must be asserted for any:
— Read transaction except ReadNoSnp and ReadNoSnpSep.
— Dataless transaction except CleanShared, CleanSharedPersist*, CleanInvalid, and MakeInvalid.
— Write transaction, except WriteNoSnpFull and WriteNoSnpPtl.
• Must not be asserted for any device memory transaction.
• Can take any value for:
— ReadNoSnp or ReadNoSnpSep transaction to a Normal memory location.
— WriteNoSnpFull and WriteNoSnpPtl transactions to a Normal memory location.
— CleanShared, CleanSharedPersist*, CleanInvalid, and MakeInvalid.
— An Atomic transaction.
• Is inapplicable and:
— Must be set to zero in DVMOp and PCrdReturn.
— Can take any value in the PrefetchTgt.

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 an allocation hint and 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:

• Can be asserted for transactions that have the Cacheable attribute asserted, except for
ReadOnceMakeInvalid,.
• Must be asserted for the WriteEvictFull transaction.
Note
A Requester can convert a WriteEvictFull with the Allocate bit not asserted to an Evict transaction.

• Must not be asserted for:

— Device memory transactions.
— Normal Non-cacheable memory transactions.
• Is inapplicable and:
— Must be set to zero in DVMOp, PCrdReturn, and Evict transactions.
— Can take any value in the PrefetchTgt transaction.

Propagation of Attr
A request from the Home Node to Subordinate Node sent in response to a request to the Home Node must preserve
the MemAttr bits EWA, Device, Cacheable, and Allocate. The only exception to this rule is when the downstream
memory is known to be Normal, then the Device field value can be set to 0b0 to indicate Normal.

2-136 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.7 Address, Control, and Data

In a Combined Write transaction, when the write and CMO transactions are separated, the Write transaction inherits
the MemAttr and SnpAttr values of the original combined request. The separated CMO transaction SnpAttr and
Cacheable bits must be set to the most pervasive to affect all caches at RN-F nodes and caches downstream.

For a ReadNoSnp or WriteNoSnp generated within the interconnect due to a Prefetch from Home or an eviction
from the System cache:
• MemAttr bits EWA, Cacheable, and Allocate must all be set to 0b1.
• Device field value must be set to 0b0 to indicate Normal.
• SnpAttr field value must be set to 0b0 to indicate Non-snoopable.

2.7.4 Transaction attribute combinations

Table 2-11 lists the legal combinations of MemAttr, SnpAttr, and Order field values and the equivalent ARM
memory type. The Order field is described in Ordering on page 2-121.

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

MemAttr[3:0] Order[1:0]

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

ARM Memory Type

LikelyShared
Cacheable
Allocate

SnpAttr
Device

EWA

1 0 0 0 0 0 1 1 Device nRnE

0 0 1 0 0 1 1 Device nRE

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

All other valuesb Not valid

0 0 0 0 0 0 0/1a 0 Non-cacheable Non-bufferablec

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

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

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

0 1 1 1 0/1d 0/1a 0 Snoopable WriteBack No-allocate

1 1 1 1 0/1d 0/1a 0 Snoopable WriteBack Allocate

All other valuesb Not valid

a. Order = 0b10 is permitted, but not required, in ReadOnce*, WriteUnique, ReadNoSnp, WriteNoSnp and
Atomic transactions only.
b. Order = 0b01 is not used for transactions’ ordering. See Transaction ordering on page 2-125.
c. Non-cacheable Non-bufferable is an AXI memory type, not an ARM memory type.
d. See Likely Shared on page 2-139.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-137
ID092622 Non-Confidential
Transactions
2.7 Address, Control, and Data

Memory type
This section specifies the required behavior for each of the memory types shown in Table 2-11 on page 2-137.

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:
• 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.

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.

2-138 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.7 Address, Control, and Data

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 Write-Back Allocate memory type is the same as for Write-Back 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.7.5 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.

The LikelyShared assertion requirements:

• Can be asserted in:
— ReadClean
— ReadNotSharedDirty
— ReadShared
— StashOnceUnique, StashOnceSepUnique
— StashOnceShared, StashOnceSepShared
— WriteUniquePtl
— WriteUniqueFull
— WriteUniqueZero
— WriteUniquePtlStash
— WriteUniqueFullStash
— WriteBackFull
— WriteCleanFull
— WriteEvictFull
— WriteEvictOrEvict
• Must not be asserted in any:
— Combined Write transactions.
— Dataless or Atomic transactions.
— Other Read or Write transactions.
• Is not applicable in:
— DVMOp or PCrdReturn transaction, and must be set to zero.
— PrefetchTgt transaction and can take any value.

2.7.6 Snoop Attribute, SnpAttr

The SnpAttr field indicates if a transaction might require snooping.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-139
ID092622 Non-Confidential
Transactions
2.7 Address, Control, and Data

Table 2-12 shows the SnpAttr field encodings.

Table 2-12 SnpAttr field encodings

SnpAttr Snoop attribute

0 Non-snoopable

1 Snoopable

Table 2-13 shows the snoop attributes for the different transaction types. The following key is used:
Y Yes, permitted
- Not permitted
n/a Not applicable

Table 2-13 Snoop attributes for the different transaction types

Transaction Non-snoopable Snoopable

ReadNoSnp, ReadNoSnpSep Y -

ReadOnce*, ReadClean, ReadShared, ReadNotSharedDirty, ReadUnique, - Y

ReadPreferUnique, MakeReadUnique

CleanUnique, MakeUnique, StashOnce - Y

CleanShared, CleanSharedPersist*, CleanInvalid, MakeInvalid Y Y

Evict - Y

WriteNoSnp Y -

WriteBack, WriteClean, WriteEvictFull, WriteEvictOrEvict - Y

WriteUnique - Y

Atomic transactions Y Y

DVMOp n/aa n/aa

PrefetchTgt n/ab n/ab

a. Not applicable, SnpAttr bit is used as a Domain Identifier in DVM transactions, see DVM domain on page 8-329.
b. Not applicable, can take any value.

The SnpAttr field value in a CMO, in an Atomic, and in ReadNoSnp and ReadNoSnpSep from Home to
Subordinate, must be set to zero, irrespective of the field value in the Request from the original Requester to Home.
In Write and Combined Write transactions from Home to Subordinate, the bit position for the SnpAttr field is used
for the DoDWT field. See Home to Subordinate Write transactions on page 2-85 and Home to Subordinate
Combined Write and CMO transactions on page 2-87.

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

2.7.7 Mismatched Memory attributes

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

2-140 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.7 Address, Control, and Data

Memory accesses from the different agents made with mismatched snoopability or cacheability attributes are
considered software protocol errors. A software protocol error can cause loss of coherency and result in the
corruption of data values. It is required that the system does not deadlock on a software protocol error, and that
transactions always make forward progress. See Software-based error on page 9-361.

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 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
where the RN-F would use, or previously have used, Non-snoopable transactions to access. If an RN-F receives a
Snoop to a location that it believes is Non-snoopable, it must not respond with data and instead send SnpResp_I.
When mismatched attributes are used, there is no defined relationship between the Snoop transaction and the
transaction that the RN-F has issued.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-141
ID092622 Non-Confidential
Transactions
2.8 Data transfer

2.8 Data transfer

A data payload is included in Read transactions, Write transactions, Combined Write transactions, Atomic
transactions, and Snoop responses with data. This section defines the data alignment rules and the data bytes that
are accessed for different combinations of address, transaction size, and memory type.

In this section, unless explicitly stated otherwise, a reference to a Write transaction includes both the individual
Write transaction and the corresponding Combined Write transaction.

2.8.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-14 shows the Size field value encodings. Snoop transactions do not include a Size field. All snoop data
transfers are 64-byte.

Table 2-14 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.8.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-134. 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 memory
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-143.

2-142 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 Data transfer

2.8.3 Byte Enables

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

In the following sections, unless explicitly stated otherwise, a reference to a Write transaction includes both the
individual Write transaction and the corresponding Combined Write transaction.

In WriteData and Snoop responses, a data byte enable value of zero must set the associated data byte value to zero.

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

An asserted byte enable in Write transactions 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.

A Requester must deassert all BE values in CopyBackWrData_I and WriteDataCancel packets.

During data transfers in the following write transactions:

• All byte enables must be asserted, except when write data is a CopyBackWrData_I or WriteDataCancel
packet:
— WriteNoSnpFull
— WriteBackFull
— WriteCleanFull
— WriteEvictFull
— WriteUniqueFull
— WriteUniqueFullStash

• Any combination of byte enables are permitted, including asserting all and asserting none:
— WriteBackPtl
— WriteUniquePtl
— WriteUniquePtlStash

For a 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.

Atomic transactions
For Atomic transactions, all byte enables within the data window must be asserted.

For Atomic transactions, byte enables that are not within the data window, as specified below by Addr and Size,
must be deasserted:
• If Addr is aligned to Size, the Data window is [Addr:(Addr+Size-1)].
• If Addr is not aligned to Size, the Data window is [(Addr-Size/2):(Addr+Size/2-1)].

Snoop transactions
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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-143
ID092622 Non-Confidential
Transactions
2.8 Data transfer

2.8.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 (DataID) and Critical Chunk Identifier (CCID) 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 can be calculated for each
packet based on the data bus width:

• 128-bit: bits [5:4] of the effective memory address of any byte in the packet

• 256-bit: bit [5] of the effective memory address of any byte in the packet, concatenated with 0b0

• 512-bit: always 0b00

For different data bus widths, Table 2-15 shows the relationship between the DataID field and the bytes that are
contained within the packet.

Table 2-15 DataID and the bytes within a packet for different data widths

Data Width
DataID
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

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, it is required that these data packets are
transferred.

When a DAT message is split into multiple packets:

• The fields that must be consistent are:

— TgtID
— SrcID

2-144 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 Data transfer

— TxnID
— HomeNID
— Opcode
— Resp
— FwdState
— DataPull
— DataSource
— CBusy
— DBID
— CCID
— TagOp

• The field tags that are expected to be consistent, but can vary, are:
— QoS
— RespErr
— TraceTag

• The fields that are expected to vary are:

— Data
— DataID
— Tag
— RSVDC
— BE
— DataCheck
— Poison

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-145
ID092622 Non-Confidential
Transactions
2.8 Data transfer

2.8.5 Size, Address and Data alignment in Atomic transactions

This section describes the data size and alignment requirements for Atomic transactions. It contains the following
sub-sections:
• Size
• Address and Data alignment
• Endianness on page 2-147

Size
The Size field of the packet specifies the total data size of the Atomic transaction.

For the AtomicCompare transaction, the data size is the sum of the Compare and Swap data values.

Table 2-16 shows the permitted data sizes, and the relationship between inbound and outbound valid data size for
each Atomic transaction type. The size of the data value returned in response to an AtomicCompare transaction is
half the number of bytes specified in the Size field in the associated Request packet.

Table 2-16 Atomic transaction outbound and inbound data sizes

Atomic transaction Outbound (bytes) Inbound

AtomicStore 1, 2, 4, or 8 -

AtomicLoad 1, 2, 4, or 8 Same as outbound

AtomicSwap 1, 2, 4, or 8 Same as outbound

AtomicCompare 2, 4, 8, 16, or 32 Half size of outbound

Address and Data alignment

In the AtomicStore, AtomicLoad, and AtomicSwap transactions:

• The byte address is aligned to the outbound data size.

• The position of data bytes in the Data packet matches the endianness of the operation, as specified in the
Endian field of the request.

• The big-endian data is byte invariant.

The write data associated with an AtomicCompare transaction is provided as if it were for a transaction that is
aligned to the outbound data size.

In the AtomicCompare transaction:

• The byte address must be aligned in the Data packet to the inbound data size, which is equivalent to half the
outbound data size.

The two data values in an AtomicCompare transaction are placed in the data field in the following manner:

• The Compare and Swap data values are concatenated and the resulting data payload is aligned in the Data
packet to the outbound data size.
• The Compare data is always at the addressed byte location.

• The Swap data is always in the remaining half of the valid data.

For any given Compare data address, the Swap data address can be determined by inverting bit[n] in the Compare
data address where:

• n = log2(Compare data size in bytes)

2-146 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 Data transfer

Alignment example

Figure 2-36 shows examples of data placement with different addresses and different Data size.

Comp and Data

Value size
7 6 5 4 3 2 1 0
Example 1: Addr = 0x2 S C
1 Byte each
7 6 5 4 3 2 1 0
Example 2: Addr = 0x5 C S

7 6 5 4 3 2 1 0
Example 3: Addr = 0x2 C C S S
2 Byte each
7 6 5 4 3 2 1 0
Example 4: Addr = 0x4 S S C C

Only 8 bytes of the 16 byte data packet are shown

Figure 2-36 Data value packing for AtomicCompare transaction

In Figure 2-36, Example 1 shows the addressed byte location is 0x2 and the total size of data is two bytes. In this
case, the Compare and Swap data must be placed in an address location aligned to a 2-byte boundary that includes
the addressed location, that is, addresses 0x2 to 0x3. Compare data is placed in location 0x2 and Swap data is placed
in location 0x3.

Note
The address of the Swap data can be determined by inverting bit[0] of the Compare data address. Bit[0] is inverted
because the size of the Compare data and the size of the Swap data is 1 byte.

In Figure 2-36, Example 3 shows the addressed location is 0x2 and the total size of data is four bytes. In this case,
the Compare and Swap data must be placed in an address location aligned to a 4 byte boundary that includes the
addressed location, that is, addresses 0x0 to 0x3. Compare data is placed in location 0x2 and Swap data is placed in
location 0x0.

Note
The address of the Swap data can be determined by inverting bit[1] of the Compare data address. Bit[1] is inverted
because the size of the Compare data and the size of the Swap data is two bytes.

Endianness
The data on which an atomic operation executes can be in either little-endian or big-endian format. For arithmetic
operations, such as ADD, MAX, and MIN, the component performing the operation needs to know the format of
the data.

The endian format of the data is defined by the Endian bit in the Atomic transaction Request packet. See Endian on
page 13-440.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-147
ID092622 Non-Confidential
Transactions
2.8 Data transfer

2.8.6 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.
The bits to match is dependent on the data bus width:
• For a data bus width of 128 bits, the CCID and DataID bits must match for the critical chunk.
• For a data bus width of 256 bits, only the most significant CCID and DataID bits must match for the critical
chunk.

2.8.7 Critical chunk first wrap order

The Sender of Data is permitted, but not required, to send individual Data packets of a transaction in critical chunk
first wrap order.

The interface property, CCF_Wrap_Order, defines the capabilities of a Sender, and the guarantees provided by the
Receiver:

• CCF_Wrap_Order at the Sender:

True The Sender signals that it is capable of sending Data packets in critical chunk first wrap order.
False The Sender signals that it is not capable of sending Data packets in critical chunk first wrap order.

• CCF_Wrap_Order at the interconnect:

True The interconnect guarantees that it will maintain the Data packets of a transaction in the order
they are received.
False The interconnect signals that it does not guarantee it can maintain the Data packets of a
transaction in the order they are received.

• CCF_Wrap_Order at the Receiver that is not an interconnect:

True The Receiver requires the Data packets to be received in critical chunk first wrap order.
False The Receiver does not require the Data packets to be received in critical chunk first wrap order.

If some components in the system do not support sending Data packets in critical chunk first wrap order, the receiver
of Data must not rely on Data being received in critical chunk first wrap order.

Note
At design time, the CCF_Wrap_Order parameter can help a component to identify if Data packets need to be sent
in critical chunk first wrap order. For example, if the component knows that it is connected to an out-of-order
interconnect, then it might be able to simplify its Data packet path by not returning the Data packets in critical chunk
first wrap order.

If the interconnect has CCF_Wrap_Order set to True, a component interfacing to that interconnect can send data
packets in critical chunk first wrap order, if capable. The Receiver can then make use of possible latency
optimization, due to receiving the critical chunk first.

2-148 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 Data transfer

2.8.8 Data Beat ordering

The reordering of data packets within a transaction is permitted when passing across an interconnect. However, the
original source of data packets is permitted, but not required, to provide the packets in a critical chunk first, wrap
order. See Critical chunk first wrap order on page 2-148.

Note
Critical chunk first wrap order 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-149
ID092622 Non-Confidential
Transactions
2.8 Data transfer

2.8.9 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 bytes and the data bus width is 128 bits. 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-150 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-151
ID092622 Non-Confidential
Transactions
2.8 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-143.

2-152 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.8 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 = 0x2 DataID = 0x1 DataID = 0x0

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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-153
ID092622 Non-Confidential
Transactions
2.9 Request Retry

2.9 Request Retry

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

Request Retry is not applicable to the PrefetchTgt transaction. The PrefetchTgt transaction cannot be retried because
there is no response associated with this request.

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, except for
PrefetchTgt, 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 (P-Credit) required to process the request. The PCrdType field in the RetryAck encodes the type
of P-Credit that will be granted by the Completer. When required resources become available, at a later point in time,
the Completer must then send a P-Credit 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 responses can be reordered so 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
The delay between a RetryAck and PCrdGrant response will typically be much longer than any delay caused by
interconnect reordering. PCrdGrant is expected to rarely be reordered with respect to RetryAck.

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 deasserting 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 when the field is
inapplicable or is one of the following:
• QoS
• TgtID, see Target ID determination for Request messages on page 3-162
• TxnID
• ReturnTxnID for ReadNoSnp and ReadNoSnpSep from the Home Node to the Subordinate Node
• SLCRepHint
• AllowRetry, which must be deasserted
• PCrdType, which must be set to the value in the Retry response for the original transaction
• TraceTag
• RSVDC

When the Requester receives a RetryAck response for a CopyBack Write request whose data is invalidated by a
snoop, the Requester can either:

• Drop the Write request and return the received credit.

• Send the Write request with AllowRetry set to zero, knowing that the subsequent data response will be
CopyBackWrData_I.

2-154 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.9 Request Retry

There is no fixed relationship between credits and particular transactions. If a Requester has received multiple
RetryAck responses for different transactions and then receives a credit, there is no fixed credit allocation. The
Requester is free to choose the most appropriate transaction from the list of transactions that receives a RetryAck
response with that particular Protocol Credit Type.

The Retry mechanism supports up to 16 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, it is recommended that the PCrdType value of 0b0000 is used. See
PCrdType on page 2-156.

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, 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 1024
transactions that require a PCrdGrant response. This is achieved by limiting the maximum number of outstanding
transactions to 1024 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
— RespSepData
— DataSepResp
— DBIDResp
— Comp, CompCMO, CompPersist, and CompStashDone
— 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.
— Canceled and returns the received credit using the PCrdReturn message.

A Requester can reuse the TxnID value used by a request either:

• As soon as it receives a RetryAck response for that request.
• As soon as it receives all the required responses for that request if the received responses are Non-RetryAck
responses.

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.9.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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-155
ID092622 Non-Confidential
Transactions
2.9 Request Retry

Note
If a Requester makes a second request before the first request has been given a RetryAck response, 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 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.

2.9.2 Transaction Retry mechanism

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

The transaction retry mechanism is not applicable to the PrefetchTgt transaction.

AllowRetry
The AllowRetry field indicates if the Request transaction can be given a RetryAck response. See Table 13-26 on
page 13-440 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 either:

• The transaction is using a pre-allocated P-Credit.
• The transaction is PrefetchTgt.

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 0b0000.
— 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 Protocol Credit Type, PCrdType on page 13-442 for the PCrdType value encodings.

• For destinations that have a single credit class, or do not implement credit type classification, it is
recommended that the PCrdType field is set to 0b0000.

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-156 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Transactions
2.9 Request Retry

2.9.3 Transaction Retry flow

Figure 2-37 shows a typical Transaction Retry flow.

RN-F HN-F

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

(Log credit request)

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

n = 0x0 to 0xF

Figure 2-37 Transaction Retry flow

The steps in Figure 2-37 include:

1. The RN-F sends a ReadOnce request to the HN-F

• This is done without a credit, so AllowRetry is asserted. This means PCrdType must be set to 0b0000.

2. The HN-F receives the request and sends a RetryAck response because the request is not able to gain buffer
entry at the HN-F.
• The request is logged and a PCrdType is determined at the HN-F.

3. The HN-F 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 RN-F re-sends the ReadOnce transaction with AllowRetry deasserted.

• The request uses the P-Credit and sets the PCrdType field to the value allocated for the original
request.

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

Note
The Requester might receive PCrdGrant before RetryAck.

The transaction must not be resent until both a RetryAck response and an appropriate P-Credit is received for the
transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 2-157
ID092622 Non-Confidential
Transactions
2.9 Request Retry

2-158 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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, SAM on page 3-160
• Node ID on page 3-161
• Target ID determination on page 3-162
• Network layer flow examples on page 3-165

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 3-159
ID092622 Non-Confidential
Network Layer
3.1 System Address Map, SAM

3.1 System Address Map, SAM

Requesters must have a System Address Map (SAM) to determine the target ID of a request. Requesters might be
Request Nodes or Home Nodes. 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. It is recommended that any address that does
not correspond to a physical component is sent to an agent that can provide an appropriate error response.

3-160 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Network Layer
3.2 Node ID

3.2 Node ID
Each component connected to a 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.

This specification supports a variable NodeID field width of 7 bits to 11 bits.

The width can be configured to any fixed value within this range for a given implementation and this value must be
consistent across all NodeID fields.
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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 3-161
ID092622 Non-Confidential
Network Layer
3.3 Target ID determination

3.3 Target ID determination

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-163
• Target ID determination for snoop request messages on page 3-164

3.3.1 Target ID determination for Request messages

For mapping of target ID in requests from the Request Node, it is required that the SAM logic to be present in the
Request Node or in the interconnect. In the case of the interconnect, it might remap the target ID in the Request
packet provided by the Request Node.

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

Except for PCrdReturn:

• If the request does not use a pre-allocated credit, the target ID is determined by:
— Opcode for DVMOp.
— Address to node ID mapping for all other requests.
PrefetchTgt uses a different Address to node ID mapper than other requests. Two requests from a
Request Node to the same Address, where one is a PrefetchTgt, target different nodes. PrefetchTgt
always targets a Subordinate Node. All other requests from a Request Node that use an Address to
node ID mapper target a Home Node.

• 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 Request Node must match the source ID included in the prior PCrdGrant which
provided the credit being returned.

A Request Node must expect the interconnect to remap the target ID of a request.

For transactions from a Request Node, except for PrefetchTgt which is targeted to an SN-F, it is expected a
Snoopable transaction to be targeted to HN-F and a 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.

A Home Node might also use address map logic to determine the target Subordinate Node ID for each request.

3-162 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Network Layer
3.3 Target ID determination

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 either
the SrcID, HomeNID, ReturnNID, or FwdNID in 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 and the field in the
received message that determines the target ID.

Table 3-1 Source of response packet target ID

Target ID obtained from

Response message
At the HN At the SN At the RN

RetryAck Request.SrcID Request.SrcID -

PCrdGrant Request.SrcID Request.SrcID -

ReadReceipt Request.SrcID Request.SrcID -

RespSepData Request.SrcID or - -
SnpResp*.SrcIDa

Comp Request.SrcID Request.SrcID -

CompCMO Request.SrcID Request.SrcID -

DataSepResp Request.SrcID or Request.ReturnNID -

SnpResp*.SrcIDa

CompData Request.SrcID or Request.ReturnNID Snoop.FwdNID

SnpResp.SrcIDa

CompAck (reads) - - Comp.SrcID or RespSepData.SrcID or

CompData.HomeNID

CompAck (writes) - - Comp.SrcID or DBIDResp.SrcID or

CompDBIDResp.SrcID

CompDBIDResp Request.SrcID Request.SrcIDb

DBIDResp Request.SrcID If Request.DoDWT == 0 then: -

Request.SrcID
or
If Request DoDWT == 1 then:
Request.ReturnNID

DBIDRespOrd Request.SrcID - -

WriteData - - DBIDResp.SrcID or CompDBIDResp.SrcID

NCBWrDataCompAck - - Comp.SrcID or DBIDResp*.SrcID or

CompDBIDResp.SrcID

Persist Request.SrcID Request.ReturnNID -

CompPersist Request.SrcID Request.SrcIDb -

StashDone Request.SrcID - -

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 3-163
ID092622 Non-Confidential
Network Layer
3.3 Target ID determination

Table 3-1 Source of response packet target ID (continued)

Target ID obtained from

Response message
At the HN At the SN At the RN

CompStashDone Request.SrcID - -

TagMatch Request.SrcID Request.ReturnNID -

SnpRespc - - Snoop.SrcID

a. For Data Pull requests where Snoop response can be SnpResp or SnpRespData or SnpRespDataPtl.
b. This response is only permitted when Request.SrcID = Request.ReturnNID, including when Request.DoDWT = 1.
c. SnpResp, SnpRespData, SnpRespDataPtl, SnpRespFwded, and SnpRespDataFwded.

3.3.3 Target ID determination for snoop request messages

A snoop request does not include a target ID. The protocol does not define 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.

3-164 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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-166
• Flow with interconnect-based SAM and Retry request on page 3-167

The following figures contain the term ‘Dec’ that represents the Decode.

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.

TgtID=SN0
RN0 TgtID=HN0 HN0 SrcID=HN0 SN0
SrcID=RN0 ReturnNID=RN0
Dec Req Dec Req

Addr

TgtID=RN0
SrcID=SN0
HomeNID=HN0
RDATA

TgtID=HN0
SrcID=RN0
Resp

Figure 3-1 TgtID assignment without remapping

The steps for TgtID assignment without remapping in Figure 3-1 are:

1. RN0 sends a request with TgtID 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 Subordinate Node.

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

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

4. RN0 receives the data response from SN0.

5. RN0 sends, if necessary, a CompAck response with TgtID of HN0 derived from the HomeNID in the data
response packet to complete the transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 3-165
ID092622 Non-Confidential
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 TgtID occurs in the interconnect.

Note
Only the TgtID of the request from the Request Node is remapped. The TgtID in all other packets in the transaction
flow is determined in a similar manner to Simple flow on page 3-165.

Initial target Remapped TgtID

RN0 HN1 TgtID=SN0 SN0

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

TgtID=RN0
SrcID=SN0
HomeNID=HN1
RDATA

TgtID=HN1
SrcID=RN0
Resp

Figure 3-2 TgtID assignment with remapping logic

The steps for TgtID assignment with remapping logic in Figure 3-2 are as follows:

1. RN0 sends a Request with TgtID of HN0 using the SAM internal to RN0.

2. The interconnect remaps the request TgtID from HN0 to HN1. The SrcID remains set to the original
requester, RN0.

3. HN1 looks up an internal SAM to determine the target Subordinate Node. The ReturnNID is set to match the
original Requester, RN0.

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

• The data response packet has the TgtID derived from the requests ReturnNID, with HomeNID set to
match the remapped Home Node.

5. RN0 receives the data response from SN0.

6. If necessary, the RN0 sends a CompAck response with TgtID of HN1 derived from the HomeNID in the data
response packet to complete the transaction.

3-166 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Network Layer
3.4 Network layer flow examples

3.4.3 Flow with interconnect-based SAM and Retry request

Figure 3-3 shows a case of a request getting retried.

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=SN0
TgtID=HN1 TgtID=HN1 SrcID=HN1
SrcID=RN0 SrcID=RN0 ReturnNID=RN0
Remap
Dec Req Req Dec Req
Dec
Addr

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

Figure 3-3 Remapping of TgtID and retried request

The steps to remap TgtID and retry the request in Figure 3-3 are as follows:

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 on page 3-166.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 3-167
ID092622 Non-Confidential
Network Layer
3.4 Network layer flow examples

3-168 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 4
Coherence Protocol

This chapter describes the coherence protocol and contains the following sections:
• Cache line states on page 4-170
• Request types on page 4-172
• Snoop request types on page 4-201
• Request transactions and corresponding Snoop requests on page 4-204
• Response types on page 4-208
• Silent cache state transitions on page 4-220
• Cache state transitions at a Requester on page 4-221
• Cache state transitions at a Snoopee on page 4-232
• Returning Data with Snoop response on page 4-251
• Do not transition to SD on page 4-252
• Hazard conditions on page 4-253

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-169
ID092622 Non-Confidential
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.
• In response to a snoop that requests data, the cache line is permitted, but not required, to be:
— Returned to Home when requested.
— Forwarded directly to the Requester when instructed by the snoop.

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.
• In response to a snoop that requests data, the cache line must not be:
— Returned to Home even when requested.
— Forwarded directly to the Requester even when instructed by the snoop.

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.
• In response to a snoop that requests data, the cache line:
— Must be returned to Home when requested.
— Is expected to be forwarded directly to the Requester when instructed by the snoop.

UDP Unique Dirty Partial:

• The cache line is present only in this cache.
• The cache line is unique. The cache line might have some bytes valid, where some includes
none or all bytes.
• 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.
• In response to a snoop that requests data, the cache line must:
— Be returned to Home.
— Not be forwarded directly to the Requester even when instructed by the snoop.

4-170 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.1 Cache line states

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.
• In response to a snoop that requests data, the cache line:
— Is required to not return data if RetToSrc bit is not set.
— Is expected to return data if RetToSrc bit is set.
— Is expected to be forwarded directly to the Requester when instructed by the snoop.

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.
• In response to a snoop that requests data, the cache line:
— Must be returned to Home when requested.
— Is expected to be forwarded directly to the Requester when instructed by the snoop.

A cache is permitted to implement a subset of these states.

4.1.1 Empty cache line ownership

An empty cache line is a cache line that is held in a Unique state to prevent other copies of the cache line existing.
None of the data bytes are valid in an empty cache line. This cache line state is UCE or UDP.

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. That copy of the cache line is invalidated before the Requester obtains permission to
store. At the completion of the request, this results in the Requester having an empty cache line with
permission to store.

4.1.2 Ownership of cache line with partial Dirty data

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

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-171
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

4.2 Request types

Protocol requests are categorized as follows:

• For Read request transactions, a data response is provided to the Requester.

• For Dataless request transactions, no data response is provided to the Requester.

• For Write request transactions, data is moved from the Requester.

• For Combined Write request transactions, data is moved from the Requester and a cache maintenance
operation is performed.

• For Atomic request transactions, data is moved from the Requester and a data response is provided to the
Requester in some request types.

• For Stash request transactions, data can be moved within a system to improve performance.

• Other request transactions:

— Do not involve any data movement in the system.
— Can be used to assist with DVM maintenance.
— Can be used to warm the memory controller for a following read request.

The following subsections enumerate the resulting transactions and their characteristics. See Chapter 12 Memory
Tagging for a description of the Memory Tagging mechanism. See Table 12-3 on page 12-396 for information on
the permitted MTE TagOp values for each request. See Request communicating nodes on page B-500 for
information on Request communicating nodes.

Note
It is 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
for 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.

4-172 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

4.2.1 Read transactions

Read transactions have the following common characteristics:

• Data must be included in the completion response to the Requester, except for MakeReadUnique request. For
MakeReadUnique, a data response is optional.

• When Data response is provided, the transferred data can be from the Home Node, another Request Node, or
a Subordinate Node.

• In Allocating Read transactions, received data, if cached, must be cached in a system coherent manner.

• In Non-allocating Read transactions, that is, ReadNoSnp and ReadOnce*, received data is not expected to be
cached. If cached, data is not cached in a system coherent manner.

• The request can result in a cache state change at the Requester. See Table 4-4 on page 4-178 for expected and
permitted initial cache and Table 4-5 on page 4-178 for final cache state at the Requester for each of the Read
transactions.

• The request can result in a cache state change at other Request Nodes in the system. See Table 4-6 on
page 4-179 for expected and permitted cache states at the peer Request Nodes for each of the Read
transactions.

See Chapter 6 Exclusive accesses for details on Exclusive attribute in read transactions.

ReadNoSnp
Read request by a Request Node to a Non-snoopable address region. Alternatively, from a
Home Node to any address region to obtain a copy of the addressed data. See Table 2-6 on
page 2-54 for use DMT, Order field, and ExpCompAck values.

ReadNoSnpSep
Read request from a Home Node to Subordinate Node, requesting the Completer to send
only a data response. Used when separate completion and data responses are used to
complete the read transaction.

ReadOnce
Read request to a Snoopable address region to obtain a snapshot of the coherent data.

ReadOnceCleanInvalid
Read request to a Snoopable address region to obtain a snapshot of the coherent data. It is
recommended, but not required, that other cached copies of the cache line are invalidated.
If a Dirty copy is invalidated, it must be written back to memory.

Note
ReadOnceCleanInvalid is used instead of ReadOnce or ReadOnceMakeInvalid where the
application determines that the data is still Valid, but will not be used in the near future.
Use of ReadOnceCleanInvalid by an application improves cache efficiency by reducing
cache pollution.

The following should be considered when using ReadOnceCleanInvalid:

• The invalidation in the ReadOnceCleanInvalid transaction is a hint. Completion of
the transaction does not guarantee removal of all cached copies, therefore it cannot
be used as a replacement for a CMO.
• Use of the transaction can cause the deallocation of a cache line and therefore caution
is needed if the transaction could target the same cache line that other agents in the
system are using for Exclusive accesses.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-173
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

ReadOnceMakeInvalid
Read request to a Snoopable address region to obtain a snapshot of the coherent data. It is
recommended, but not required, that other cached copies of the cache line are invalidated.
If a Dirty copy is invalidated, it does not need to be written back to memory. All cached
copies must be invalidated if the invalidation hint is accepted and a Dirty copy is not written
back to memory.

Note
ReadOnceMakeInvalid is used in preference to ReadOnce or ReadOnceCleanInvalid to
obtain a snapshot of a data value when the application determines that the cached data is not
going to be used again.
The application can free up the caches and also, by discarding Dirty data, avoid an
unnecessary WriteBack to memory.

The following should be considered when using ReadOnceMakeInvalid:

• The invalidation in the ReadOnceMakeInvalid transaction is a hint. Completion of
the transaction does not guarantee removal of all cached copies, therefore it cannot
be used as a replacement for a CMO.
• Use of the transaction can cause the deallocation of a cache line and therefore caution
is needed if the transactions could target the same cache line that other agents in the
system are using for Exclusive accesses.
• The use of the ReadOnceMakeInvalid transaction can cause the loss of a Dirty cache
line. Use of this transaction must be strictly limited to scenarios where it is known
that the loss of a Dirty cache line is harmless.
• For a ReadOnceMakeInvalid transaction, it is required that the invalidation of the
cache line is committed before the read data response for the transaction. The
invalidation of the cache line is not required to have completed at this point, but it
must be ensured that any later Write transaction from any agent, which starts after
this point, is guaranteed not to be invalidated by this transaction.

ReadClean Read request to a Snoopable address region to obtain a clean copy of a cache line. This can
be used if the Requester is allocating the line to a cache that does not support dirty cache
lines, such as an Instruction cache. Data must be provided to the Requester in either UC or
SC only.

ReadNotSharedDirty
Read request to a Snoopable address region to carry out a load from the cache line. Data
must be provided to the Requester in UC, UD, or SC states only. SD is not permitted.

Note
ReadNotSharedDirty is used instead of ReadShared when the Requester cannot accept data
in SD state.

ReadShared Read request to a Snoopable address region to carry out a load from the cache line. Data
must be provided to the Requester in UC, UD, SC, or SD states.

Note
ReadShared is used instead of ReadNotSharedDirty when the Requester is willing to accept
data in the SD state.

ReadUnique Read request to a Snoopable address region to carry out a store to the cache line. Data must
be provided to the Requester in UC or UD state only.

4-174 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

ReadPreferUnique Read request to a Snoopable address region requesting a unique copy of a cache line.
ReadPreferUnique is used when the Requester prefers, but does not require, the data to be
returned in Unique state:
• Data is provided in Unique state unless another Request Node is currently performing
an exclusive sequence using the same address. In which case the data is provided in
Shared state.
• It is permitted to always provide the data in Shared state to the Requester.

Note
This request is included in this specification to improve the execution efficiency of an
exclusive sequence.

MakeReadUnique Read request to a Snoopable address region requesting a unique copy of a 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.

Note
Because data return is guaranteed if the Requester receives an Invalidating snoop and
retention of data is required otherwise, resending a request to obtain a Unique copy of the
cache line is never required.

Read request attribute values

This section discusses the attribute values for Read requests across node interfaces.

See Appendix A Message Field Mappings for complete list.

Table 4-1 lists permitted values for the key attributes in Read requests for Request Node to Home Node.

Table 4-1 RN to HN Read request permitted attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

ReadNoSnp <=64 0,1 0 0010 11 0 0,1

0011 00,10,11 0 0,1

0000 00,10 0 0,1

0001
0101
1101

ReadOnce 64 0 1 0101 00,10 0 0,1

ReadOnceCleanInvalid 1101

ReadOnceMakeInvalid 64 0 1 0101 00,10 0 0,1

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-175
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Table 4-1 RN to HN Read request permitted attribute values (continued)

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

ReadClean 64 0,1 1 0101 00 0,1 1

ReadNotSharedDirty 1101
ReadShared

ReadUnique 64 0 1 0101 00 0 1
1101

ReadPreferUnique 64 0,1 1 0101 00 0 1

MakeReadUnique 1101

Table 4-2 lists the permitted values for the key attributes in Read requests for HN-F to SN-F.

Table 4-2 HN-F to SN-F Read request permitted attribute values

ExpCompAck
LikelyShared
Size MemAttr
Request Excl SnpAttr Order
(bytes) ACDE

ReadNoSnp <=64 0,1 0 0000 00,01 0 0

0001
0101
1101

ReadNoSnpSep <=64 0 0 0000 00,01 0 0

0001
0101
1101

4-176 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-3 lists the permitted values for the key attributes in Read requests for HN-I to SN-I.

Table 4-3 HN-I to SN-I Read request permitted attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

ReadNoSnp <=64 0,1 0 0010 11 0 0

0011 00,01,10,11 0 0

0000 00,01,10 0 0
0001
0101
1101

ReadNoSnpSep <=64 0 0 0010 11 0 0

0011 00,01,10,11 0 0

0000 00,01,10 0 0
0001
0101
1101

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-177
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Initial cache state at the Requester

Table 4-4 lists the permitted Requester cache states when a Request is sent. The following key is used for Table 4-4
and Table 4-5:
Y Yes, permitted
- Not permitted
n/a Not applicable

Table 4-4 Permitted Requester cache state at the sending of Read request

Initial state
Request
UD UC SD SC I UDP UCE

ReadNoSnp - - - - Y - -

ReadOnce - - - - Y - Y

ReadOnceCleanInvalid, - - - - Y - Y
ReadOnceMakeInvalid

ReadClean Y Y Y Y Y Y Y

ReadNotSharedDirty - - - - Y - Y

ReadShared - - - - Y - Y

ReadUnique Y Y Y Y Y Y Y

ReadPreferUnique - - Y Y Y - Y

MakeReadUnique - - Y Y - - -

Final cache state at the Requester

Table 4-5 lists the permitted cache state at the Requester at the completion of the transaction.

Table 4-5 Permitted final Requester cache state

Final state
Request
UD UC SD SC I UDP UCE

ReadNoSnp - - - - Y - -

ReadOnce - - - - Y - -

ReadOnceCleanInvalid, - - - - Y - -
ReadOnceMakeInvalid

ReadClean - Y - Y - - -

ReadNotSharedDirty Y Y - Y - - -

ReadShared Y Y Y Y - - -

ReadUnique Y Y - - - - -

4-178 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-5 Permitted final Requester cache state (continued)

Final state
Request
UD UC SD SC I UDP UCE

ReadPreferUnique Y Y Y Y - - -

MakeReadUnique(non-Excl) Y Y - - - - -

MakeReadUnique(Excl) Y Y Y Y - - -

Peer cache state

Table 4-6 lists the permitted cache state at the peer Request Nodes at the completion of the transaction.

In response to a request, the Home must send the appropriate Snoops to ensure cached lines at the peer caches are
either an expected or permitted final state.

Table 4-6 Permitted peer cache state at the completion of a request

Peer final state

Request
UD UC SD SC I UDP UCE NoChange

ReadNoSnp n/a n/a n/a n/a n/a n/a n/a n/a

ReadOnce Y Y Y Y Y Y Y Y

ReadOnceCleanInvalid, Y Y Y Y Y Y Y Y
ReadOnceMakeInvalid

ReadClean - - Y Y Y - - -

ReadNotSharedDirty - - Y Y Y - - -

ReadShared - - Y Y Y - - -

ReadUnique - - - - Y - - -

ReadPreferUnique - - Y Y Y - - -

MakeReadUniquea - - - - Y - - -

a. For MakeReadUnique(Excl), it is possible that peer caches are not required to change state.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-179
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

4.2.2 Dataless transactions

Request Nodes use Dataless transactions to perform coherent actions without the transfer of data from or to the
Requester. The Dataless transactions, grouped for their common functionality, are:
• CleanUnique, MakeUnique
• Evict
• Independent Stash transactions
— StashOnceUnique, StashOnceSepUnique, StashOnceShared, StashOnceSepShared
• Cache Maintenance transactions
— CleanShared, CleanSharedPersist, CleanSharedPersistSep, CleanInvalid, MakeInvalid

Dataless transactions have the following common characteristics:

• Data must not be included in the completion response.

• The Request can result in data movement among other agents in the system.

• The Request can result in a cache state change at the Requester.

See Table 4-10 on page 4-185 for expected and permitted initial cache and Table 4-11 on page 4-185 for final
cache state at the Requester for each of the Dataless transactions.

• The Request can result in a cache state change at the other Request Nodes in the system.
See Table 4-12 on page 4-186 for expected and permitted cache states at the peer Request Nodes for each of
the Dataless transactions.

See Chapter 6 Exclusive accesses for details on Exclusive attribute in Dataless transactions.

CleanUnique
Request to a Snoopable address region to change the cache state at the Requester 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. Any dirty copy
of the cache line at a snooped cache must be written back to the memory.

MakeUnique
Request to a Snoopable address region to obtain ownership of the cache 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. Any dirty copy of the cache line at a snooped cache must
be invalidated without carrying out a data transfer.

Evict
Used to indicate that a Clean cache line is no longer cached by the Request Node.

StashOnceUnique, StashOnceSepUnique
Request to a Snoopable address region to attempt to move the addressed cache line to a
targeted cache to enable the target to store that line. The request includes:
• A valid node ID of another Request Node as the Stash target, along with an optional
ID of a Logical Processor within that node. When a valid target is not specified, the
addressed cache line can be fetched to be cached at the request Completer.
• It is recommended, but not required, that the other agent is snooped to indicate that
it obtains the addressed cache line and ensures that it is in a cache state suitable for
writing to the cache line.
• The DataPull request from the target Request Node is treated as a ReadUnique
Request.
See Chapter 7 Cache Stashing.

4-180 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

StashOnceShared, StashOnceSepShared
Request to a Snoopable address region to attempt to move the addressed cache line to a
targeted cache. The request includes:
• The node ID of another Request Node. Optionally, the request can include the ID of
a Logical Processor within that node. When a valid target is not specified, the
addressed cache line can be fetched to be cached at the request Completer.
• It is recommended, but not required, that the other agent is snooped to indicate that
it obtains the addressed cache line.
• The DataPull request from the target Request Node is treated as
ReadNotSharedDirty.
See Chapter 7 Cache Stashing.

Cache Maintenance transactions

A Cache Maintenance Operation (CMO) assists with software cache management. The protocol includes the
following five transactions to support a Cache Maintenance Operation:

CleanShared
The completion response to a CleanShared request ensures that all cached copies are
changed to a Non-dirty state and any Dirty copy is written back to memory.

CleanSharedPersist
The completion response to a CleanSharedPersist request ensures that all cached copies are
changed to a Non-dirty state and any Dirty cached copy is written back to the Point of
Persistence (PoP).

CleanSharedPersistSep
The Persist or combined CompPersist completion response to a CleanSharedPersistSep
request ensures that all cached copies are changed to a Non-dirty state and any Dirty cached
copy is written back to the PoP.
Functionality of CleanSharedPersistSep is similar to CleanSharedPersist but allows two
separate responses to the Requester.
When sending a persistent CMO, it is expected, but not required, that a Requester uses a
CleanSharedPersistSep transaction instead of CleanSharedPersist.
Such a Requester must support receiving both separate Comp and Persist responses and a
combined CompPersist response.

CleanInvalid
The completion response to a CleanInvalid request ensures that all cached copies are
invalidated. The request requires that any cached Dirty copies must be written to memory.

MakeInvalid
The completion response to a MakeInvalid request ensures that all cached copies are
invalidated. The request permits that any cached Dirty copies are discarded.

The following characteristics are common to all five CMO transactions:

• The Resp field value in the Comp, indicating cache state, must be ignored by both the Requester and the
Home.

• Sending of a CMO transaction to the interconnect from an RN and from the interconnect to an SN is
controlled by the BROADCASTPERSIST (BP) and BROADCASTCACHEMAINTENANCE (BCM)
interface signals. See Optional interface broadcast signals on page 16-482.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-181
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Note
Permitting Cache Maintenance Operations to be forwarded downstream of the Home Node incorporates system
topologies where some observers might directly access locations downstream of the Home Node and software cache
maintenance is required to make cached data visible to such observers.

• Cacheable and SnpAttr bit values must be observed.

• MemAttr values on a request received at Home must be preserved when the request is propagated to the
Subordinate, except when it is known that the Subordinate has only Normal memory, in which case the
MemAttr bit Device can be set to Normal.
• Order field must not be asserted:
— A CMO intended for a particular address must not be sent to the interconnect before all previous
transactions sent to the same address that can allocate the data in the Requester caches have completed.
— A transaction intended for a particular address that can allocate data in Requester caches must not be
sent to the interconnect before a previous CMO sent to the same address has completed.
— A Completer is permitted, but not required, to wait for WriteData to send a Persist response. Examples
of when a Completer can send an early Persist is when the Completer does not support Persistence on
that memory location or the request encounters a Non-data Error.
• A CMO is permitted, but not required, to be combined with a Write transaction to the same address when the
write is ahead of the CMO. See Combined Write requests on page 4-192.

Persistent CMO handling at Home

This section discusses the PoP at the Home and downstream of the Home. This section also introduces Deep
attribute in Persistent CMO.

Point of Persistence at Home

If the Home is the PoP, then for CleanSharedPersistSep:

• The Home is permitted to not forward the CleanSharedPersistSep request to the Subordinate. When the Home
decides not to forward the CleanSharedPersistSep request, it must return a Persist response to the Requester.

• When the Home sends a Persist response, it is permitted, but not required, to combine it with Comp and return
a single CompPersist response to the Requester.

Point of Persistence downstream of Home

If the PoP is downstream of the Home, then for CleanSharedPersistSep:

• The Home must send the request downstream.

• The Subordinate Node must return a Comp response only after it guarantees that it has accepted the request
and will not return a RetryAck response.

• When a Subordinate Node can guarantee all previous writes to the same address in non-volatile memory are
persistent, it must also return Persist response to the Requester or Home. The address location will also
contain the updated value even after the removal of power.

• The Home receives a Persist response from downstream, it must forward the Persist response to the
Requester:
— The Subordinate is permitted, but not required, to return a combined CompPersist response to the
Home.
— The Home is permitted, but not required, to wait for the Persist response from the Subordinate.
Permitting a Home to wait for a Persist response enables the Home to send a combined CompPersist
response to the Requester instead of returning separate Comp and Persist responses.

• If the target is volatile memory, the Persist response can be given immediately. Such a situation must not
return an error.

4-182 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Deep Persistent CMO

For high availability expectations, systems with non-volatile memory require guarantees that operation-critical data
is persevered, even when the power and the back up battery fail simultaneously. The guarantee can be provided by
a system by adding a mechanism to push previous writes to the Point of Deep Persistence. This specification
supports this feature using an attribute, called Deep, on Persistent CMO transactions.

If the Completer of the request with Deep asserted does not support the Deep attribute, the Completer can ignore
the attribute value and treat the request as having the Deep attribute deasserted. An error response must not be given
to indicate that Deep persistence is not supported. See Deep persistence, Deep on page 13-434.

Dataless request attribute values

This section discusses the attribute values for Dataless requests across node interfaces.

See Appendix A Message Field Mappings for complete list.

Table 4-7 lists the values permitted for key attributes in Dataless requests from Request Node to Home Node.

Table 4-7 RN to HN Dataless request permitted attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

CleanUnique 64 0,1 1 0101 00 0 1

1101

MakeUnique 64 0 1 0101 00 0 1
1101

Evict 64 0 1 0101 00 0 0

StashOnceUnique 64 0 1 0101 00 0,1 0

StashOnceSepUnique 1101
StashOnceShared
StashOnceSepShared

CleanShared 64 0 1 0101 00a 0 0

CleanSharedPersist 1101
CleanSharedPersistSep
0 0 0010 00a 0 0
CleanInvalid
0011
MakeInvalid
0000
0001
0101
1101

a. The field is inapplicable and must be set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-183
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Table 4-8 lists the values permitted for key attributes in Dataless requests from HN-F to SN-F.

Table 4-8 HN-F to SN-F Dataless request permitted attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

CleanShared 64 0 0 0000 00a 0 0

CleanSharedPersist 0001
CleanSharedPersistSep 0101
CleanInvalid 1101
MakeInvalid
a. The field is inapplicable and must be set to zero.

Table 4-9 lists the values permitted for key attributes in Dataless requests from HN-I to SN-I.

Table 4-9 HN-I to SN-I Dataless request permitted attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

CleanShared 64 0 0 0010 00a 0 0

CleanSharedPersist 0011
CleanSharedPersistSep 0000
CleanInvalid 0001
MakeInvalid 0101
1101

a. The field is inapplicable and must be set to zero.

4-184 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Initial cache state at the Requester

Table 4-10 lists the permitted Requester cache states when a request is sent. The following key is used for
Table 4-10, Table 4-11, and Table 4-12 on page 4-186:
Y Yes, permitted
- Not permitted

Table 4-10 Permitted Requester cache state at the sending of Dataless request

Initial state
Request
UD UC SD SC I UDP UCE

CleanUnique Y Y Y Y Y - Y

MakeUnique - Y Y Y Y - Y

Evict - - - - Y - -

StashOnceUnique - - - - Y - -
StashOnceSepUnique

StashOnceShared - - - - Y - -
StashOnceSepShared

CleanShared - Y - Y Y - -
CleanSharedPersist
CleanSharedPersistSep

CleanInvalid - - - - Y - -

MakeInvalid - - - - Y - -

Cache states for Dataless transactions

This section describes Final cache state at the Requester and Peer cache state on page 4-186 at the completion of
a Dataless transaction.

Final cache state at the Requester

Table 4-11 lists the permitted cache state at the Requester at the completion of the transaction.

Table 4-11 Permitted final Requester cache state

Final state
Request
UD UC SD SC I UDP UCE

CleanUnique Y Y - - - - Y

MakeUnique Y - - - - - -

Evict - - - - Y - -

StashOnceUnique - - - - Y -
StashOnceSepUnique

StashOnceShared - - - - Y -
StashOnceSepShared

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-185
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Table 4-11 Permitted final Requester cache state (continued)

Final state
Request
UD UC SD SC I UDP UCE

CleanShared - Y - Y Y - -
CleanSharedPersist
CleanSharedPersistSep

CleanInvalid - - - - Y - -

MakeInvalid - - - - Y - -

Peer cache state

Table 4-12 lists the expected and permitted cache state at the peer Request Node at the completion of the Dataless
transaction. In response to a request, the Home must send appropriate snoop to transition cached line at the peer
caches to either expected or permitted final states.

Table 4-12 Permitted peer cache state at the completion of a request

Peer final state

Request
UD UC SD SC I UDP UCE NoChange

CleanUnique - - - - Y - - -

MakeUnique - - - - Y - - -

CleanShared - Y - Y Y - - -
CleanSharedPersist
CleanSharedPersistSep

CleanInvalid - - - - Y - - -

MakeInvalid - - - - Y - - -

The Peer Request Node cache state at the completion of Evict, StashOnceUnique, StashOnceSepUnique,
StashOnceShared, and StashOnceSepShared is not applicable.

4-186 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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.

Immediate Write transactions

Immediate Write transactions, also known as Non-CopyBack transactions, are a subclass of Write transactions.
Immediate Write transactions transfer data from Request Nodes to Home Nodes without initially obtaining coherent
ownership of the data. Immediate Write transactions are also used to transfer data from Home Nodes to Subordinate
Nodes.

Each Immediate Write transaction must assert the appropriate byte enables with the data. Immediate Write
transactions can require snooping of other agents in the system.

In Immediate Write requests, except WriteNoSnpZero and WriteUniqueZero, DWT flow between the Request Node
and the Subordinate Node is permitted only when the original request from the Request Node does not use OWO.

DWT flow between a Request Node and a Subordinate Node in WriteNoSnpZero and WriteUniqueZero is never
permitted.

WriteNoSnpFull
Write a full cache line of data from a Request Node to a Non-snoopable address region, or
write for a full cache line of data to any address region from the Home to Subordinate. All
byte enables must be asserted.

WriteNoSnpPtl
Write up to a cache line of data from a Request Node to a Non-snoopable address region, or
write up to a cache line of data to any address region from the Home to Subordinate. Byte
enables must be asserted for the appropriate byte lanes, including none or all, within the
specified data size and deasserted in the rest of the data transfer.

WriteNoSnpZero
Write data value of zero without transferring data bytes from a Request Node to a
Non-snoopable address region, or write data value of zero without transferring data bytes to
any address region from Home to Subordinate.

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. All byte enables must be
asserted.

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. Byte enables must be asserted
for the appropriate byte lanes within the specified data size and deasserted in the rest of the
data transfer.

WriteUniqueZero
Write to a Snoopable address region. Write without data bytes when the data value is zero.

WriteUniqueFullStash
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. Also includes a request to the
Stash target node to obtain the addressed cache line. All byte enables must be asserted.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-187
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

WriteUniquePtlStash
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. Also includes a request to the
Stash target node to obtain the addressed cache line. Byte enables must be asserted for the
appropriate byte lanes within the specified data size and deasserted in the remainder of the
data transfer.

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
WriteBack a full cache line of Dirty data to the next level cache or memory. All byte enables
must be asserted except when the write data is CopyBackWrData_I.

WriteBackPtl
WriteBack up to a cache line of Dirty data to the next level cache or memory. All appropriate
byte enables, up to all 64, including none or all, must be asserted.

WriteCleanFull
WriteBack a full cache line of Dirty data to the next level cache or memory and retain a
Clean copy in the cache. All byte enables must be asserted except when the write data is
CopyBackWrData_I.

WriteEvictFull
WriteBack of UniqueClean data to the next-level cache.
• All byte enables must be asserted except when the write data is CopyBackWrData_I.
• The cache line must not propagate beyond its Snoop domain.

WriteEvictOrEvict
WriteBack of Clean data to the next-level cache. This request type is merging of
WriteEvictFull and Evict into one request. This allows the Home Node to determine if it is
sent data.
• Data might not be sent if the Completer does not accept data.
• If data is sent, then the Data size is a cache line length.
• Table 4-13 indicates the initial state of the cache line when the request is sent:
Table 4-13 LikelyShared value states

LikelyShared Initial state

0 UC
1 SC

• The cache line must not propagate beyond its Snoop domain.

Write request attribute values

This section discusses the attribute values for Write requests across node interfaces.

4-188 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-14 lists the values permitted for key attributes in Write requests from Request Node to Home Node.

Table 4-14 RN to HN Write request attribute values

ExpCompAck
LikelyShared
Request Size Excl SnpAttr MemAttr Order
(bytes) ACDE

WriteNoSnpFull 64 0,1 0 0010 11 0 0

0011 00,11 0 0

10 0 0,1

0000 00 0 0
0001
10 0 0,1
0101
1101

WriteNoSnpPtl <=64 0,1 0 0010 11 0 0

0011 00,11 0 0

10 0 0,1

0000 00 0 0
0001
10 0 0,1
0101
1101

WriteNoSnpZero 64 0 0 0010 11 0 0

0011 00,10,11 0 0

0000 00,10 0 0
0001
0101
1101

WriteUniqueFull 64 0 1 0101 00 0,1 0

WriteUniqueFullStash 1101
10 0,1 0,1

WriteUniquePtl <=64 0 1 0101 00 0,1 0

WriteUniquePtlStash 1101
10 0,1 0,1

WriteUniqueZero 64 0 1 0101 00,10 0,1 0

1101

WriteBackFull 64 0 1 0101 00 0,1 0

WriteCleanFull 1101

WriteBackPtl 64 0 1 0101 00 0 0
1101

WriteEvictFull 64 0 1 1101 00 0,1 0

WriteEvictOrEvict 64 0 1 1101 00 0,1 1

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-189
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Table 4-15 lists the values permitted for key attributes in Write requests from HN-F to SN-F.

Table 4-15 HN-F to SN-F Write request attribute values

ExpCompAck
LikelyShared
MemAttr
Request Size Excl DoDWT Order
ACDE
(bytes)

WriteNoSnpFull 64 0,1 0,1 0000 00 0a 0a

0001
0101
1101

WriteNoSnpPtl <=64 0,1 0,1 0000 00 0a 0a

0001
0101
1101

WriteNoSnpZero 64 0 0a 0000 00 0a 0a
0001
0101
1101

a. The field is inapplicable and must be set to zero.

Table 4-16 lists the values permitted for key attributes in Write requests from HN-I to SN-I.

Table 4-16 HN-I to SN-I Write request attribute values

ExpCompAck
LikelyShared
MemAttr
Request Size Excl DoDWT Order
ACDE
(bytes)

WriteNoSnpFull 64 0,1 0,1 0010 11 0a 0a

0011 00,10,11 0a 0a

0000 00,10 0a 0a
0001
0101
1101

WriteNoSnpPtl <=64 0,1 0,1 0010 11 0a 0a

0011 00,10,11 0a 0a

0000 00,10 0a 0a
0001
0101
1101

4-190 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-16 HN-I to SN-I Write request attribute values (continued)

ExpCompAck
LikelyShared
MemAttr
Request Size Excl DoDWT Order
ACDE
(bytes)

WriteNoSnpZero 64 0 0a 0010 11 0a 0a

0011 00,10,11 0a 0a

0000 00,10 0a 0a
0001
0101
1101

a. The field is inapplicable and must be set to zero.

Initial cache state at the Requester

Table 4-17 lists the permitted Requester cache states when a request is sent. The following key is used:
Y Yes, permitted
- Not permitted

Table 4-17 Permitted Requester cache state at the sending of a Write request

Initial state
Request
UD UC SD SC I UDP UCE

WriteNoSnpFull - - - - Y - -
WriteNoSnpPtl

WriteNoSnpZero - - - - Y - -

WriteUniqueFull - - - - Y - -
WriteUniquePtl
WriteUniqueZero

WriteUniqueFullStash - - - - Y - -
WriteUniquePtlStash

WriteBackFull Y - Y - - - -

WriteBackPtl - - - - - Y -

WriteCleanFull Y - Y - - - -

WriteEvictFull - Y - - - - -

WriteEvictOrEvict - Y - Y - - -

Final cache state at the Requester

The permitted Requester cache state at the completion of a Write transaction, except for WriteCleanFull, is Invalid.

The permitted Requester cache state at the completion of a WriteCleanFull transaction is UC or SC.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-191
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Peer cache state

The Peer Request Node cache state at the completion of WriteNoSnpPtl, WriteNoSnpFull, and WriteNoSnpZero is
not applicable.

The Peer Request Node cache state at the completion of WriteUniquePtl, WriteUniqueFull, WriteUniqueZero,
WriteUniquePtlStash, and WriteUniqueFullStash must be Invalid.

The Peer Request Node cache state at the completion of CopyBack requests is not changed. The Home Node is not
required to snoop the Peer Request Nodes to change their cache state.

4.2.4 Combined Write requests

This specification supports the combining of Write transactions with Cache Maintenance transactions when both
are to the same address. The ability to combine the two requests to the same address is useful when a CMO or PCMO
transaction reaches a point in the system where a Write operation must be completed before the CMO or PCMO
transaction can be initiated. The use of a single Combined Write transaction avoids the need to serialize the Write
and CMO or PCMO transactions. The point where the two requests are combined can be a Request Node or a Home
Node.

Table 4-18 and Table 4-19 on page 4-193 show the Write, CMO, and PCMO combinations for which combining is
permitted. Empty table cells indicate a combination that is not permitted or not applicable.

Note
Deep is an attribute on persistent CMO requests. Deep has not been listed explicitly as a CMO type in Table 4-18
and Table 4-19 on page 4-193.

When a Persistent CMO is combined with a write, the Persistent CMO is treated as a CleanSharedPersistSep, that
is, in addition to a completion response, a separate Persist response is required for the CMO part of the request.

Table 4-18 and Table 4-19 on page 4-193 show the permitted combinations of Write and CMO requests. Table 4-18
and Table 4-19 on page 4-193 use the following key:
Y Yes, permitted
- Not permitted

Table 4-18 Permitted combinations of Write and CMO for RN to HN requests

Persistent CMO Non-persistent CMO

Write type
(With separate Persist
CleanShared CleanInvalid MakeInvalid
response)

WriteNoSnpFull Y Y Y -
WriteNoSnpPtl

WriteUniqueFull Y Y - -
WriteUniquePtl

WriteUniqueStashFull - - - -
WriteUniqueStashPtl

WriteBackFull Y Y Y -

WriteBackPtl - - - -

WriteCleanFull Y Y - -

WriteEvictFull - - - -

4-192 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-19 Permitted combinations of Write and CMO for HN to SN requests

Persistent CMO Non-persistent CMO

Write type
(With separate
CleanShared CleanInvalid MakeInvalid
Persist response)

WriteNoSnpFull Y Y Y -
WriteNoSnpPtl

Examples of how combining of a Write request with Cache Maintenance is useful are:

• Combining WriteBack with CleanShared and CleanSharedPersist, supports Request Nodes that transition the
cache line to Invalid when cleaned by a CMO irrespective of the type of CMO.

• Combining WriteUnique with CleanShared supports the case when the CleanSharedPersist target is known
to not support Persistent transactions. Therefore, the CleanSharedPersist request needs to be converted to
CleanShared by the Requester.

For each Write request the Combined Write requests are:

• WriteNoSnpFull:
— WriteNoSnpFullCleanInv
— WriteNoSnpFullCleanSh
— WriteNoSnpFullCleanShPerSep
• WriteNoSnpPtl:
— WriteNoSnpPtlCleanInv
— WriteNoSnpPtlCleanSh
— WriteNoSnpPtlCleanShPerSep
• WriteUniqueFull:
— WriteUniqueFullCleanSh
— WriteUniqueFullCleanShPerSep
• WriteUniquePtl:
— WriteUniquePtlCleanSh
— WriteUniquePtlCleanShPerSep
• WriteBackFull:
— WriteBackFullCleanInv
— WriteBackFullCleanSh
— WriteBackFullCleanShPerSep
• WriteCleanFull:
— WriteCleanFullCleanSh
— WriteCleanFullCleanShPerSep

Characteristics
A Combined Write request is permitted for both CopyBack and Immediate writes.

All permitted behaviors of the Combined Write request are the same as if the write and CMO are sent separately,
except that:
• WriteNoSnp(Excl) is not permitted to be combined with a CMO.
• TagOp setting of Match is not permitted in WriteCMO.

A Home receiving a Combined Write request from a Request Node is permitted to forward the Combined Write to
the Subordinate Node if both the write and the CMO or PCMO in the request need to be sent downstream. The Home
is also permitted to use DWT for such a Write request if the write from the Request Node is an Immediate write and
ExpCompAck is set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-193
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Where an uncombined CMO from a Request Node results in the cache line being evicted from a cache at the Home
or a Dirty copy is passed in a Snoop response, the CMO propagated to the Subordinate can be combined with the
write back to the Subordinate.

The receiver of a Combined Write request is permitted, but not required, to separate the write and the CMO request
and process them separately. In such a case, the CMO request must be ordered behind the write. Once the requests
are separated, the Completer is permitted to interleave requests to the same address between the write and the CMO
transaction.

The Size field value in a combined request corresponds to the size of Data in the Write request. The CMO is always
on a 64-byte granularity.

The MemAttr and SnpAttr field values in a Combined Write request correspond to the memory attributes of the
Write request. When the write and the CMO transactions are separated, the Write transaction inherits the MemAttr
and SnpAttr values of the original combined request. The SnpAttr and Cacheable bit values of the separated CMO
transaction must be set to the most pervasive.

4.2.5 Atomic transactions

An Atomic transaction permits a Requester to issue a transaction with a memory address and an operation to be
performed on the memory address to the interconnect. This transaction type moves the operation closer to where
the data resides and is useful for atomically executing an operation and updating the memory location in a
performance efficient manner.

Without an Atomic transaction, an atomic operation has to be executed using a sequence of memory accesses. These
accesses might rely on Exclusive reads and writes.

By using an Atomic transaction:

• A more deterministic latency can be estimated for atomic operations.

• The blocking period of access to the memory location being modified is reduced, which then reduces the
impact on the forward progress of memory accesses by other agents.

• Providing fairness among different Requesters accessing a memory location becomes simpler, because
accessing of that memory location by an atomic operation is arbitrated at the Point of Serialization (PoS) or
Point of Coherence (PoC).

This specification defines the following terms relating to atomic operations and Atomic transactions:

Atomic operation The execution of a function involving multiple data values such that, the loading of the
original value, the execution of the function, and the storing of the updated value, occurs in
an atomic manner. This means that no other agent has access to the location during the entire
operation.

Atomic transaction A transaction that is used to pass an atomic operation, along with the data values required
for the execution of the atomic operation, from one agent in a system to another, so that the
atomic operation can be carried out by a different component in the system than the
component that requires the operation to be performed.

Atomic transaction types

This specification defines four Atomic transaction types:
• AtomicStore
• AtomicLoad
• AtomicSwap
• AtomicCompare

See Chapter 12 Memory Tagging for a description of the Memory Tagging mechanism.

For information on the permitted MTE TagOp values for each Atomic request see Table 12-3 on page 12-396.

4-194 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

The following terminology is used to refer to the different data elements in the execution of an atomic operation:

TxnData The write data in the AtomicLoad, and AtomicStore transactions.

CompareData The compare value in the AtomicCompare transaction.

SwapData The swap value in the AtomicCompare, and AtomicSwap transactions.

InitialData The content of the addressed location before the atomic operation.

Enumeration of the four Atomic transaction types is as follows:

AtomicStore • Sends a single data value with an address and the atomic operation to be performed.
• The target, a Home Node or a Subordinate Node, performs the required operation on
the address location specified with the data supplied in the Atomic transaction.
• The target returns a completion response without data.
• Unlike in AtomicLoad transactions, the original value of AtomicStore transactions at
the addressed location is not returned to the Requester.
• Number of operations supported is 8.
Table 4-20 shows the eight operations supported by the AtomicStore transaction.
Each of the AtomicStore operations apply to 1 byte, 2 byte, 4 byte, or 8 byte data sizes.

Table 4-20 AtomicStore operations

Operation Action

STADD Update location with:

(TxnData + InitialData)

STCLR Update location with bitwise:

(InitialData AND (NOT TxnData))

STEOR Update location with bitwise:

(InitialData XOR TxnData)

STSET Update location with bitwise:

(InitialData OR TxnData)

STSMAX Update location with TxnData if:

(((Signed INT) TxnData – (Signed INT) InitialData) > 0)

STSMIN Update location with TxnData if:

(((Signed INT) TxnData - (Signed INT) InitialData) < 0)

STUMAX Update location with TxnData if:

(((Unsigned INT) TxnData - (Unsigned INT) InitialData > 0)

STUMIN Update location with TxnData if:

(((Unsigned INT) TxnData - (Unsigned INT) InitialData < 0)

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-195
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

AtomicLoad • Sends a single data value with an address and the atomic operation to be performed.
• The target, a Home Node or a Subordinate Node, performs the required operation on
the address location specified with the data value supplied in the Atomic transaction.
• The target returns the completion response with data. The data value is the original
value at the addressed location.
• Number of operations supported is 8.
Table 4-21 shows the eight operations supported by the AtomicLoad transaction.
Each of the AtomicLoad operations applies to 1 byte, 2 byte, 4 byte, or 8 byte data sizes.

Table 4-21 AtomicLoad operations

Operation Action

LDADD Update location with:

(TxnData + InitialData)

LDCLR Update location with bitwise:

(InitialData AND (NOT TxnData))

LDEOR Update location with bitwise:

(InitialData XOR TxnData)

LDSET Update location with bitwise:

(InitialData OR TxnData)

LDSMAX Update location with TxnData if:

(((Signed INT) TxnData – (Signed INT) InitialData) > 0)

LDSMIN Update location with TxnData if:

(((Signed INT) TxnData – (Signed INT) InitialData) < 0)

LDUMAX Update location with TxnData if:

(((Unsigned INT) TxnData – (Unsigned INT) InitialData) > 0)

LDUMIN Update location with TxnData if:

(((Unsigned INT) TxnData – (Unsigned INT) InitialData) < 0)

AtomicSwap
• Sends a single data value, the swap value, together with the address of the location to
be operated on.
• The target, a Home Node or a Subordinate Node, swaps the value at the address
location with the data value supplied in the transaction.
• The target returns the completion response with data. The data value is the original
value at the addressed location.
• Number of operations supported is 1.

AtomicCompare
• Sends two data values, the compare value and the swap value, with the address of the
location to be operated on.
• The target, a Home Node or a Subordinate Node, compares the value at the addressed
location with the compare value:
— If the values match, the target writes the swap value to the addressed location.
— If the values do not match, the target does not write the swap value to the
addressed location.

4-196 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

• The target returns the completion response with data. The data value is the original
value at the addressed location.
• Number of operations supported is 1.
Other common characteristics of Atomic transactions are:

• Data must be included in the completion response to the Requester, except for AtomicStore transaction. For
AtomicStore, the completion response does not include the data response.
— When data is returned, inbound data size must be the same as the outbound data size, except for an
AtomicCompare transaction. In AtomicCompare, inbound data size must be half of the outbound data
size.
— The data value in the response data must be the original value at the addressed location.
— The received data must not be cached at the Requester.

• Byte enables must be asserted for all valid data in the inbound and outbound data messages.

• The request can result in a cache state change at other Request Nodes in the system. The peer Request Node
cache state must be Invalid at the completion of the request.

• Atomic transactions cannot use DMT nor DWT flows.

A Requester that has a cached copy of the line on which it must perform an atomic operation can do the following:

• If the cache line is Unique, it can perform the atomic operation locally without generating an Atomic
transaction.

• If the cache line is Shared but not Dirty, it can either:

— Generate a ReadUnique, CleanUnique, or MakeReadUnique to gain ownership of the cache line and
perform the atomic operation locally.
— Invalidate the local copy and send the Atomic transaction to the interconnect.

• If the cache line is Shared Dirty, it can either:

— Generate a ReadUnique, CleanUnique, or MakeReadUnique, gain ownership of the cache line, and
perform the operation locally.
— WriteBack and Invalidate the local copy and then send the Atomic transaction to the interconnect.

• Optionally, in all the above cases, the Requester is permitted, but not required, to send the Atomic transaction
with the SnoopMe bit set to direct the interconnect to send a Snoop request to the Requester to invalidate,
and if necessary, extract the cached copy. See SnoopMe on page 13-441.

Atomic request attribute values

This section discusses the attribute values for Atomic requests across node interfaces.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-197
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

Table 4-22 lists the permitted values for attributes for Atomic requests from Request Node to Home Node.

Table 4-22 RN to HN Atomic request attribute values

ExpCompAck
LikelyShared
Size
Request SnoopMe SnpAttr MemAttr Order
(bytes)
ACDE

AtomicStore 1, 2, 4, 8 0 0 0010 11 0 0
AtomicLoad
0011 00,10,11 0 0
AtomicSwap
0000 00,10 0 0
0001
0101
1101

0,1 1 0101 00,10 0 0

1101

AtomicCompare 2, 4, 8, 0 0 0010 11 0 0
16, 32
0011 00,10,11 0 0

0000 00,10 0 0
0001
0101
1101

0,1 1 0101 00,10 0 0

1101

Table 4-23 lists the permitted values for attributes for Atomic requests from HN-F to SN-F.

Table 4-23 HN-F to SN-F Atomic request attribute values

ExpCompAck
LikelyShared
Request Size SnoopMe DoDWT MemAttr Order
(bytes) ACDE

AtomicStore 1, 2, 4, 8 0a 0 0000 00 0a 0a
AtomicLoad 0001
AtomicSwap 0101
1101

AtomicCompare 2, 4, 8, 16, 32 0a 0 0000 00 0a 0a

0001
0101
1101

a. The field is inapplicable and must be set to zero.

4-198 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.2 Request types

Table 4-24 lists the permitted values for attributes for Atomic requests from HN-I to SN-I.

Table 4-24 HN-I to SN-I Atomic request attribute values

ExpCompAck
LikelyShared
Request SnoopMe DoDWT MemAttr Order
Size (bytes)
ACDE

AtomicStore 1, 2, 4, 8 0a 0 0010 11 0a 0a
AtomicLoad
0011 00,10,11 0a 0a
AtomicSwap
0000 00,10 0a 0a
0001
0101
1101

AtomicCompare 2, 4, 8, 16, 32 0a 0 0010 11 0a 0a

0011 00,10,11 0a 0a

0000 00,10 0a 0a
0001
0101
1101

a. The field is inapplicable and must be set to zero.

Communicating node pair

See Table B-1 on page B-500 for expected and permitted node pairs for each Atomic transaction.

Initial cache state at the Requester

The Requester cache state permitted at the issue of the Atomic transaction is any state.

If the Requester at the time of issuing an Atomic transaction determines the cache state to not be Invalid, or cannot
determine that the cache state is Invalid, then it must set the value of SnoopMe in the Atomic request to 1.

Final cache state at the Requester

The Requester cache state permitted at the completion of an Atomic transaction is Invalid.

Peer cache state

The peer Request Node cache state at the completion of Atomic transactions is Invalid.

4.2.6 Other transactions

This section describes the protocol transactions that carry out miscellaneous actions.

See Chapter 12 Memory Tagging for a description of the Memory Tagging mechanism.

For information on the permitted MTE TagOp values for each miscellaneous request see Table 12-3 on page 12-396.

See Table B-1 on page B-500 for expected and permitted node pairs for other transactions.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-199
ID092622 Non-Confidential
Coherence Protocol
4.2 Request types

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.

Prefetch transaction
The Prefetch target transaction is used to speculatively fetch data from main memory.

PrefetchTgt Prefetch Target. A Request to a Snoopable memory address, sent from a Request Node directly to a
Subordinate Node:
• The PrefetchTgt transaction does not include a response.
• The request can be used by the Subordinate Node to fetch the data from off-chip memory and
buffer it in anticipation of a subsequent Read request to the same location.
• The request does not include a response nor RetryAck. The Requester can deallocate the
request as soon as the request is sent.
• The Receiver must accept the request without dependency on receiving of a subsequent Read
request to the same address.
• The Receiver is permitted to initiate an internal action or discard the request without any
further action.
• Data read from off-chip memory using PrefetchTgt must not hold Subordinate Node
resources waiting indefinitely for a future Read request to the same address.
• The following fields are inapplicable and can take any value:
— TxnID
— Order
— Endian
— Size
— MemAttr
— SnpAttr
— Excl
— LikelyShared

4-200 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.3 Snoop request types

4.3 Snoop request types

The interconnect generates a Snoop request either in response to a request from a Request Node or due to an internal
trigger such as a 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.

The Home selection of a Snoop to send is based on several criteria:

• Expected or permitted final cache states, required by the request causing the snoop, at the Requester and the
snooped nodes.

• Avoid losing any Dirty tags present in the caches being snooped.

• Replacing a Non-forwarding with an equivalent Forwarding snoop, if one exists.

• A Forwarding snoop is permitted to be sent to one RN-F only.

• A stash snoop is permitted to be sent to one RN-F only.

• Snoops are permitted, but not required, to Non-snoopable address locations.

See Request transactions and corresponding Snoop requests on page 4-204.

See Cache state transitions at a Snoopee on page 4-232 for the permitted responses for specific snoop types.

For details of Snoop transaction interaction with the Memory Tagging Extension (MTE) see Chapter 12 Memory
Tagging.

SnpOnceFwd, SnpOnce
Snoop request to obtain the latest copy of the cache line, preferably without changing the
cache line state at the Snoopee:

SnpStashUnique
Snoop request recommending that the Snoopee obtains a copy of the cache line in a Unique
state:
• It is expected that the snoop for a StashOnceUnique request is not sent if the cache
line is cached in Unique state at the Stash target.
• Permitted, but not required, to send the snoop to the Stash target for
WriteUniqueFullStash and WriteUniquePtlStash only if the Snoopee does not have a
cached copy of the cache line.
• The Snoopee must not return data with the Snoop response.
• Permits the Snoop response to include a Data Pull.
• Data Pull request in the Snoop response is treated as a ReadUnique.
• Must not change the cache line state at the Snoopee.

SnpStashShared
Snoop request recommending that the Snoopee obtains a copy of the cache line in a Shared
state:
• It is expected to not send the snoop if the cache line is cached at the target.
• The Snoopee must not return data with the Snoop response.
• Permits the Snoop response to include a Data Pull.
• Data Pull request in the Snoop response is treated as a ReadNotSharedDirty.
• Must not change the cache line state at the Snoopee.

SnpCleanFwd, SnpClean
Snoop request to obtain a copy of the cache line in Clean state while leaving any cached
copy in Shared state. Must not leave the cache line in Unique state.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-201
ID092622 Non-Confidential
Coherence Protocol
4.3 Snoop request types

SnpNotSharedDirtyFwd, SnpNotSharedDirty
Snoop request to obtain a copy of the cache line in SharedClean state while leaving any
cached copy in a Shared state. Must not leave the cache line in Unique state.

SnpSharedFwd, SnpShared
Snoop request to obtain a copy of the cache line in Shared state while leaving any cached
copy in Shared state. Must not leave the cache line in Unique state.

SnpUniqueFwd, SnpUnique
Snoop request to obtain a copy of the cache line in Unique state while invalidating any
cached copies. Must change the cache line to Invalid state.

SnpPreferUniqueFwd, SnpPreferUnique
Snoop request to obtain a copy of the cache line in Unique state while invalidating any
cached copies:
• Home is expected to use SnpPreferUniqueFwd or SnpPreferUnique in response to
ReadPreferUnique.
• The behavior of the Snoopee is dependent on whether it is executing an exclusive
sequence.

SnpUniqueStash
Snoop request to invalidate the cached copy at the Snoopee and recommends that the
Snoopee obtains a copy of the cache line in Unique state:
• Permits the Snoop response to include a DataPull.
• Data Pull request in the Snoop response is treated as a ReadUnique.

SnpCleanShared
Snoop request to remove any Dirty copy of the cache line at the Snoopee. Must not leave
the cache line in a Dirty state.

SnpCleanInvalid
Snoop request to Invalidate the cache line at the Snoopee and obtain any Dirty copy. Might
also be generated by the interconnect without a corresponding request.Must change the
cache line to Invalid state.

SnpMakeInvalid
Snoop request to Invalidate the cache line at the Snoopee and discard any Dirty copy:
• Does not return data with the Snoop response, Dirty data is discarded.
• Must change the cache line to Invalid state.

SnpMakeInvalidStash
Snoop request to invalidate the copy of the cache line and recommends that the Snoopee
obtains a copy of the cache line in Unique state:
• Snoopee must not return data with the Snoop response, Dirty data must be discarded.
• Permits the Snoop response to include a DataPull.
• Data Pull request in the Snoop response is treated as a ReadUnique.

SnpQuery
SnpQuery probes the state of a cache line at a Request Node:
• Home can send a SnpQuery snoop without any corresponding request from a
Requester.
• The Snoop response must include the precise state of the cache line at the targeted
Snoopee.

4-202 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.3 Snoop request types

• Snoopee must not return data with the Snoop response.

• The SnpQuery snoop must not change the state of the cache line at the Snoopee.
See MakeReadUnique transaction on page 4-224 and MakeReadUnique(Excl) on
page 6-298 to see how SnpQuery can be used in the efficient handling of exclusive request
flows.

SnpDVMOp
Generated at the interconnect, 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-314.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-203
ID092622 Non-Confidential
Coherence Protocol
4.4 Request transactions and corresponding Snoop requests

4.4 Request transactions and corresponding Snoop requests

For a required coherency action, a Home has a choice of multiple snoop types that it is permitted to select from. This
section describes examples of how a Home selects the snoop to send and the number of snoops it sends.

While responding to a Request, the selection of which snoop to use is determined from the intended outcome, that
is the desired final state of the cache line at the Requester and the required or desired cache state at the Snoopee.

See Request types on page 4-172 for required cache state at peer Request Nodes. See Cache state transitions at a
Snoopee on page 4-232 for details of Snoopee cache state transitions.

4.4.1 Number of snoops to send

The Home Node can send snoops to more than one Request Node, including to all. In the case of an invalidation,
the invalidating snoop must be sent at least to all the cached copies. Whereas for a Non-invalidating snoop, the
Home Node is:

• Permitted, but not required, to send the snoop to all Request Nodes with the cached copies.

• Must be able to obtain a copy of the Dirty line. In the case of a cache line in Unique Dirty state, it must send
a snoop to the Request Node with the Unique Dirty cached copy.
For Write transactions with stash hint, the Home Node must also send invalidating snoops to all Non-stash target
Request Nodes that have a copy of the cache line:
• For WriteUniqueFullStash, the expected snoop to Non-stash target nodes is SnpMakeInvalid.
• For WriteUniquePtlStash, the expected snoop to Non-stash target nodes is SnpCleanInvalid.

A snoop filter or directory can be included within the interconnect to support filtering of snoops.

4.4.2 Selection of snoop to send

A Home Node, based on internal preferences and implementation constraints, might prefer one of the expected
snoops or substitute an expected snoop with others. See Table 4-25 on page 4-205 for the expected snoop per
Request type.

4-204 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.4 Request transactions and corresponding Snoop requests

Table 4-25 shows the snoops expected to be used by the Home Node for a given Request. A Home is permitted to
substitute the expected snoop with another snoop that accomplishes the required Snoopee state transition.

Table 4-25 Expected snoop requests per Request from an RN

Request Category Request Expected Snoop

Read ReadNoSnp None or SnpOnceFwda

ReadNoSnpSep n/a

ReadOnce SnpOnceFwda

ReadOnceCleanInvalid SnpUnique or SnpOnceFwda

ReadOnceMakeInvalid SnpUnique or SnpOnceFwda

ReadClean SnpCleanFwd

ReadNotSharedDirty SnpNotSharedDirtyFwd

ReadShared SnpSharedFwd

ReadUnique SnpUniqueFwd

ReadPreferUnique SnpPreferUniqueFwd

MakeReadUnique SnpCleanInvalid or
SnpUniqueFwdb

Dataless CleanUnique SnpCleanInvalid

MakeUnique SnpMakeInvalid

Evict None

CleanShared SnpCleanShared

CleanSharedPersist SnpCleanShared
CleanSharedPersistSep

CleanInvalid SnpCleanInvalid

MakeInvalid SnpMakeInvalid

Dataless-stash StashOnceUnique SnpStashUnique

StashOnceSepUnique

StashOnceShared SnpStashShared
StashOnceSepShared

Write WriteNoSnp None

WriteNoSnpSep n/a

WriteUniqueFull SnpMakeInvalid

WriteUniquePtl SnpCleanInvalid or SnpUnique

WriteUniqueZero SnpMakeInvalid

Write-stash WriteUniqueFullStash SnpMakeInvalidStash

WriteUniquePtlStash SnpUniqueStash

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-205
ID092622 Non-Confidential
Coherence Protocol
4.4 Request transactions and corresponding Snoop requests

Table 4-25 Expected snoop requests per Request from an RN (continued)

Request Category Request Expected Snoop

Write-CopyBack WriteBack None

WriteClean

WriteEvictFull

WriteEvictOrEvict

Atomic AtomicStore SnpUnique

AtomicLoad SnpUnique

AtomicSwap SnpUnique

AtomicCompare SnpUnique

Others DVMOp SnpDVMOp

PCrdReturn n/a

PrefetchTgt
a. Forwarding snoops cannot be used for requests of less than 64B.
b. Home is expected to use SnpUniqueFwd if it determines that the Requester has lost its
copy of the cache line.

The interconnect has the following behavior when generating a snoop request on receipt of a request from a Request
Node:

• 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 interconnect 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, 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 SC state, the interconnect does not send a
snoop request.

• The interconnect in response to a WriteUniqueFull, WriteUniqueFullStash, MakeUnique, and MakeInvalid

must not use the SnpMakeInvalid snoop request unless either:
— The transaction TagOp value is Update.
— The interconnect can determine that the Snoopee does not hold Dirty tags.

• The interconnect in response to a MakeReadUnique must not use the SnpMakeInvalid Snoop request unless
the interconnect can determine either that:
— The Requester still has a cached copy of the cache line and the Snoopee does not have Dirty tags.
— The Requester has lost its cached copy and the Snoopee does not have a Dirty copy of the cache line.

• It is permitted for the interconnect to generate a snoop request spontaneously without a corresponding request
from a Request Node. 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.

4-206 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.4 Request transactions and corresponding Snoop requests

• It is permitted for 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 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.

• The interconnect is permitted to:

— For ReadNotSharedDirty, ReadShared, and ReadClean transactions, use SnpNotSharedDirty or
SnpShared or SnpClean.
— For ReadShared transactions, use SnpNotSharedDirtyFwd or SnpSharedFwd or SnpCleanFwd.
— For ReadNotSharedDirty and ReadClean transactions, use SnpNotSharedDirtyFwd or SnpCleanFwd.
— For the ReadOnce transactions, use any Non-forwarding, Non-invalidating snoop types.
— For the ReadOnceCleanInvalid and ReadOnceMakeInvalid transactions, use any Non-forwarding
snoop types except SnpMakeInvalid.
— For the ReadOnce, ReadOnceCleanInvalid, and ReadOnceMakeInvalid transactions, use Forwarding
snoop type SnpOnceFwd.
— For WriteUniqueFullStash and WriteUniquePtlStash transactions, send SnpStashUnique or
SnpMakeInvalidStash to the target Request Node if the target Request Node does not have the cache
line.
— Replace any Invalidating snoop request by the SnpUnique or SnpCleanInvalid request.
— Replace any Forwarding snoop with a corresponding non-Forwarding type. The receiver is permitted
to treat the forward indication as a hint and respond to the snoop with a corresponding non-Forwarding
version in a protocol-compliant manner. This is permitted irrespective of the use of MTE.
— Use of SnpMakeInvalid for MakeInvalid and WriteUniqueZero is permitted only when the Home
knows that the Snoopee does not have Dirty tags.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-207
ID092622 Non-Confidential
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-210
• Snoop response on page 4-212
• Miscellaneous response on page 4-218

4.5.1 Completion response

A completion response is required for all transactions except PCrdReturn and PrefetchTgt. It is typically the last
message sent from the Completer to conclude a request transaction. However, the Requester might still 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
Ordering on page 2-121 for details on the Ordering guarantees.

Read and Atomic transaction completion

A Read completion is either in the form of a single response on the RDAT channel using the CompData opcode, or
two separate responses, one on the RSP channel using the RespSepData opcode and a second one on the RDAT
channel using the DataSepResp opcode. See Dataless transaction completion on page 4-209 for completion without
data for the MakeReadUnique transaction.

AtomicLoad, AtomicSwap, and AtomicCompare completion is sent on the RDAT channel and uses the CompData
opcode.

The CompData and DataSepResp completion responses include the Resp field that indicates the following:

Cache state The final permitted state of the cache line at the Requester for all reads except ReadNoSnp and
ReadOnce*.

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.

When using separate Comp and Data responses, RespSepData also includes the Resp field with Cache state and Pass
Dirty indications. The Resp field value in RespSepData must be either inapplicable and set to zero or the same as
in the corresponding DataSepResp.

Table 4-26 shows the permitted Read transaction completion, the encoding of the Resp field, and the meaning of
the response. A Subordinate Node can send DataSepResp only in response to ReadNoSnpSep, and only CompData
in response to ReadNoSnp.

Table 4-26 Permitted Read transaction completion and Resp field encodings

Response Resp[2:0] Description

CompData_I 0b000 Indicates that a coherent copy of the cache line cannot be kept.
DataSepResp_I

RespSepData_I 0b000 Cache state in this response is not applicable. Cache state must be
determined from DataSepResp response.

CompData_UC 0b010 The final state of the cache line can be UC, UCE, SC or I, when the
DataSepResp_UC cache state in the response is applicable.
RespSepData_UC This response is also permitted for ReadNoSnp and ReadOnce*
transactions but the cache line will not be coherent.
Responsibility for a Dirty cache line is not being passed.

4-208 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

Table 4-26 Permitted Read transaction completion and Resp field encodings (continued)

Response Resp[2:0] Description

CompData_SC 0b001 The final state of the cache line can be SC or I.

DataSepResp_SC Responsibility for a Dirty cache line is not being passed.
RespSepData_SC

CompData_UD_PD 0b110 The final state of the cache line can be UD or SD.
DataSepResp_UD_PD Responsibility for a Dirty cache line is being passed.
RespSepData_UD_PD

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-344.

Dataless transaction completion

A completion for Dataless transactions and the MakeReadUnique transaction without data is sent on the CRSP
channel and uses the Comp, CompPersist, CompCMO, or CompStashDone opcode.

CompCMO is the completion message for the CMO and PCMO in a Combined Write transaction. It must be used
only in Combined Write transactions. CompCMO can be combined with Persist response as CompPersist opcode.

The Comp 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, except for CMO transactions.
For CMO transactions, the cache state field value in the completion, specifically in Comp,
CompCMO and CompPersist transactions, is ignored and the cache state remains unchanged.

Table 4-27 shows the permitted Dataless transaction completion, the encoding of the Resp field, and the meaning
of the response.

Table 4-27 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 UD, UC, UCE, SC, or I.

Comp_SC 0b001 The final state of the cache line can be SC or I.

Comp_UD_PD 0b110 The final state of the cache line must be UD or 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-344. See Combined Immediate Write and CMO on page 2-62 for
CompCMO and CompPersist. See Independent Stash request on page 7-307 for CompStashDone.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-209
ID092622 Non-Confidential
Coherence Protocol
4.5 Response types

Write and Atomic transaction completion

A Write and AtomicStore completion is sent on the CRSP channel and uses the Comp or CompDBIDResp 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.

The permitted Write transaction completion responses are:

Comp Used when the completion response is separate from the DBIDResp or DBIDRespOrd
response.

CompDBIDResp Used when the completion response is combined with the DBIDResp or DBIDRespOrd
response.
All CopyBack requests must use the CompDBIDResp completion response.
Immediate writes and AtomicStore, can either send Comp and DBIDResp or DBIDRespOrd
responses separately or can opportunistically combine the two responses and send
CompDBIDResp 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 DVM transaction completion.

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 or DBIDRespOrd response sent from the Completer.

The WriteData response is sent on the WDAT channel and uses the following opcodes.

CopyBackWriteData, CBWrData
Used for WriteBack, WriteClean, WriteEvictFull, and WriteEvictOrEvict, and CopyBack
Combined Write 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.

NonCopyBackWriteData, NCBWrData
Used for WriteUnique and WriteNoSnp, and Combined Immediate Write transactions. Also
used for a DVMOp transaction. The cache state in the response must be I.

NonCopyBackWriteDataCompAck, NCBWrDataCompAck
Used for Immediate Write and Combined Write transactions. Combined
NonCopyBackWrData and CompAck. The cache state in the response must be I.

WriteDataCancel
Used to inform the Completer that a Write request is canceled before write data is sent.
• A Request Node can send WriteDataCancel instead of NonCopyBackWrData in
WriteNoSnpPtl, WriteUniquePtl, WriteUniquePtlStash, and corresponding
Combined Write transactions.
• A Home Node can send WriteDataCancel instead of NonCopyBackWrData in
WriteNoSnpFull, WriteNoSnpPtl, and corresponding Combined Write transactions
to the Subordinate Node.
• Must not be used in Write requests to Device memory.
• All data packets originally intended to be transferred must be sent.
BE field value in the WriteDataCancel message must be set to all zeroes.

4-210 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

• 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-28 shows the permitted WriteData responses, the Opcode and Resp field encodings, and the meaning of the
response.

Table 4-28 Permitted WriteData responses and Opcode and Resp field encodings

Response DAT Opcode Resp[2:0] Description

CopyBackWrData_I 0x2 0b000 Indicates a CopyBack request has been

canceled.
The data in the response must be zero and all
BE must be deasserted.
The cache state in the response is imprecise
and must be ignored.

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 an Immediate Write

request.

NCBWrDataCompAck 0xC 0b000 Data corresponding to an Immediate Write

request and combined CompAck to indicate
that the transaction has completed.

WriteDataCancel 0x7 0b000 Indicates an Immediate Write request has been

canceled.
The data in the response must be zero and all
BE must be deasserted.

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 WriteEvictFull transaction must be in I state.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-211
ID092622 Non-Confidential
Coherence Protocol
4.5 Response types

• A WriteClean transaction can remain allocated and be in a Clean state.

4.5.3 Snoop response

A Snoop transaction includes a Snoop response. A Snoop response can be with or without data. The 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 can include a DataPull request for stash snoops.
• Snoop response without data is always used for the response to a SnpDVMOp transaction.
Snoop response without data to Home and DCT
• This Snoop response is used when the Snoopee sends Data to the Requester and a data
transfer to the Home is not required.
• It is sent on the SRSP channel and uses the SnpRespFwded opcode.
Snoop response with data
• This Snoop response is used when a full cache line of data is transferred to Home.
• It is sent on the WDAT channel and uses the SnpRespData opcode.
• It can include a DataPull request for stash snoops.
Snoop response with partial data
• This Snoop response is used when a partial cache line of data is transferred to the Home.
• It is sent on the WDAT channel and uses the SnpRespDataPtl opcode.
• It can include a DataPull request for stash snoops.
• 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.
Snoop response with data to Home and DCT
• This Snoop response is used when the Snoopee sends Data to the Requester and a data
transfer to the Home is also required.
• It is sent on the DAT channel and uses the SnpRespDataFwded opcode.

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.

The Snoop response also includes the FwdState field that is applicable in Snoop responses with DCT and indicates
the cache state and pass dirty value in the CompData response sent to the Requester.

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.

See Snoop requests on page 12-391 for details on Snoop responses and MTE interaction.

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 WriteData response, where the cache state information provides the state of the cache line at the point the
write data is sent.

4-212 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

• A read data response, where the cache state information indicates the permitted state of the cache line after
the transaction completes.

Table 4-29 shows the permitted Non-forward type snoop responses without data, the RSP Opcode and Resp field
encodings, and the meaning of the response.

Table 4-29 Permitted Non-forward type snoop responses without data

Response RSP Opcode Resp[2:0] Description

SnpResp_I 0x1 0b000 Snoop response without data.

Cache line state is I.

SnpResp_SC 0x1 0b001 Snoop response without data.

Cache line state is SC, or I.

SnpResp_UC 0x1 0b010 Snoop response without data.

Cache line state is UC, UCE, SC, or I.

SnpResp_UD 0x1 0b010 Snoop response without data.

Cache line state is UD.

SnpResp_SD 0x1 0b011 Snoop response without data.

Cache line state is SD.

Table 4-30 shows the permitted Forward type snoop responses without data, the RSP Opcode, Resp, and FwdState
field encodings, and the meaning of the response.

Table 4-30 Permitted Forward type snoop responses without data

Response RSP Opcode Resp[2:0] FwdState[2:0] Description

SnpResp_I_Fwded_I 0x9 0b000 0b000 Snoop response without data.

Cache line state is I.
Copy of data forwarded to the Requester.
Forward State is I.

SnpResp_I_Fwded_SC 0x9 0b000 0b001 Snoop response without data.

Cache line state is I.
Copy of data forwarded to the Requester.
Forward State is SC.

SnpResp_I_Fwded_UC 0x9 0b000 0b010 Snoop response without data.

Cache line state is I.
Copy of data forwarded to the Requester.
Forward State is UC.

SnpResp_I_Fwded_UD_PD 0x9 0b000 0b110 Snoop response without data.

Cache line state is I.
Copy of data forwarded to the Requester.
Forward State is UD.
Responsibility for updating the memory is
passed.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-213
ID092622 Non-Confidential
Coherence Protocol
4.5 Response types

Table 4-30 Permitted Forward type snoop responses without data (continued)

Response RSP Opcode Resp[2:0] FwdState[2:0] Description

SnpResp_I_Fwded_SD_PD 0x9 0b000 0b111 Snoop response without data.

Cache line state is I.
Copy of data forwarded to the Requester.
Forward State is SD.
Responsibility for updating the memory is
passed.

SnpResp_SC_Fwded_I 0x9 0b001 0b000 Snoop response without data.

Cache line state is SC.
Copy of data forwarded to the Requester.
Forward State is I.

SnpResp_SC_Fwded_SC 0x9 0b001 0b001 Snoop response without data.

Cache line state is SC.
Copy of data forwarded to the Requester.
Forward State is SC.

SnpResp_SC_Fwded_SD_PD 0x9 0b001 0b111 Snoop response without data.

Cache line state is SC.
Copy of data forwarded to the Requester.
Forward State is SD.
Responsibility for updating the memory is
passed.

SnpResp_UC_Fwded_I 0x9 0b010 0b000 Snoop response without data.

SnpResp_UD_Fwded_I Cache line state is UC or UD.
Copy of data forwarded to the Requester.
Forward State is I.

Note
A single encoding is used to indicate that
the cache line is unique.
This encoding is used for UC and UD.

SnpResp_SD_Fwded_I 0x9 0b011 0b000 Snoop response without data.

Cache line state is SD.
Copy of data forwarded to the Requester.
Forward State is I.

SnpResp_SD_Fwded_SC 0x9 0b011 0b001 Snoop response without data.

Cache line state is SD.
Copy of data forwarded to the Requester.
Forward State is SC.

4-214 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

Table 4-31 shows the permitted Non-forward type snoop responses with data, the DAT Opcode and Resp field
encodings, and the meaning of the response.

Table 4-31 Permitted Non-forward type snoop responses with data

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 to the Home.

SnpRespData_UC_PD 0x1 0b110 Snoop response with data.

Cache line state is UC.
Responsibility for updating the memory is passed to the Home.

SnpRespData_SC_PD 0x1 0b101 Snoop response with data.

Cache line state is SC.
Responsibility for updating the memory is passed to the Home.

SnpRespDataPtl_I_PD 0x5 0b100 Snoop response with partial data.

Cache line state is I.
Responsibility for updating the memory is passed to the Home.

SnpRespDataPtl_UD 0x5 0b010 Snoop response with partial data.

Cache line state is UDP.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-215
ID092622 Non-Confidential
Coherence Protocol
4.5 Response types

Table 4-32 shows the permitted Forward type snoop responses with data, the DAT Opcode, Resp, and FwdState
field encodings, and the meaning of the response.

Table 4-32 Permitted Forward type snoop responses with data

Response DAT Opcode Resp[2:0] FwdState[2:0] Description

SnpRespData_I_Fwded_SC 0x6 0b000 0b001 Snoop response with data.

Cache line state is I.
Copy of data forwarded to the
Requester.
Forward State is SC.

SnpRespData_I_Fwded_SD_PD 0x6 0b000 0b111 Snoop response with data.

Cache line state is I.
Copy of data forwarded to the
Requester.
Forward State is SD.
Responsibility of updating the memory
is passed to the Requester.

SnpRespData_SC_Fwded_SC 0x6 0b001 0b001 Snoop response with data.

Cache line state is SC.
Copy of data forwarded to the
Requester.
Forward State is SC.

SnpRespData_SC_Fwded_SD_PD 0x6 0b001 0b111 Snoop response with data.

Cache line state is SC.
Copy of data forwarded to the
Requester.
Forward State is SD.
Responsibility for updating the memory
is passed to the Requester.

SnpRespData_SD_Fwded_SC 0x6 0b011 0b001 Snoop response with data.

Cache line state is SD.
Copy of data forwarded to the
Requester.
Forward State is SC.

SnpRespData_I_PD_Fwded_I 0x6 0b100 0b000 Snoop response with data.

Cache line state is I.
Responsibility for updating the memory
is passed to the Home.
Copy of data forwarded to the
Requester.
Forward State is I.

4-216 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

Table 4-32 Permitted Forward type snoop responses with data (continued)

Response DAT Opcode Resp[2:0] FwdState[2:0] Description

SnpRespData_I_PD_Fwded_SC 0x6 0b100 0b001 Snoop response with data.

Cache line state is I.
Responsibility for updating the memory
is passed to the Home.
Copy of data forwarded to the
Requester.
Forward State is SC.

SnpRespData_SC_PD_Fwded_I 0x6 0b101 0b000 Snoop response with data.

Cache line state is SC.
Responsibility for updating the memory
is passed to the Home.
Copy of data forwarded to the
Requester.
Forward State is I.

SnpRespData_SC_PD_Fwded_SC 0x6 0b101 0b001 Snoop response with data.

Cache line state is SC.
Responsibility for updating the memory
is passed to the Home.
Copy of data forwarded to the
Requester.
Forward State is SC.

The cache line state associated with a Snoop response with data must be a legal value, even if the RespErr field
indicates there is a Data Error. A Snoop response with data is not permitted to have a Non-data Error. See Snoop
transactions on page 9-353.

In responses to stash snoops, the Snoopee can send a Read request combined with the Snoop response
(SnpResp_X_Read), by setting the DataPull bit. The permitted Snoop responses with Data Pull are:

• For SnpUniqueStash:
— SnpResp_I_Read
— SnpRespData_I_Read
— SnpRespData_I_PD_Read
— SnpRespDataPtl_I_PD_Read

• For SnpMakeInvalidStash:
— SnpResp_I_Read

• For SnpStashUnique:
— SnpResp_I_Read
— SnpResp_UC_Read
— SnpResp_SC_Read
— SnpResp_SD_Read

• For SnpStashShared:
— SnpResp_I_Read
— SnpResp_UC_Read

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-217
ID092622 Non-Confidential
Coherence Protocol
4.5 Response types

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, WriteNoSnp,
WriteEvictOrEvict, and WriteUnique transactions.
See Transaction structure on page 2-46.

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 permitted for any request transaction except PCrdReturn or
PrefetchTgt.
See Retry on page 2-83.

PCrdGrant
Grants a Protocol Credit. A subsequent request, sent using the Protocol Credit, is guaranteed to be
accepted by the target.
See Retry on page 2-83.

ReadReceipt
• Sent for a request that has an ordering requirement with respect to other ordered requests
from the same Requester.
• Sent by a Subordinate Node to indicate it has accepted a Read request and will not send a
RetryAck response.
• See Ordering requirements on page 2-126 for how ReadReceipt is used in an ordered request.
• Applies to ReadNoSnp, ReadNoSnpSep, and ReadOnce* request transactions.
See Read transactions on page 2-47.

DBIDResp
• Response sent to signal to the Requester that resources are available to accept the WriteData
response.
• DBIDResp response also indicates that the Completer provides certain transaction ordering
guarantees. See Transaction ordering on page 2-125.
• Applies to Write, Combined Write, DVMOp, and Atomic request transactions.
• The response is permitted from Home Node to Request Node and Subordinate Node to both
a Home Node and Request Node.
See Transaction structure on page 2-46.

4-218 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.5 Response types

DBIDRespOrd
• Response sent to signal to the Requester that resources are available to accept the WriteData
response.
• DBIDRespOrd response also indicates that the Completer provides certain transaction
ordering guarantees. See Transaction ordering on page 2-125.
• Applies to Write, Combined Write, and Atomic request transactions.
• DBIDRespOrd is not permitted in DVM transactions.
• The response is permitted from Home Node to Request Node only.
See Transaction ordering on page 2-125.

Persist
Sent by a Completer for CleanSharedPersistSep transaction to indicate that any data written earlier
to the same memory location is made persistent.
See Combined Immediate Write and Persist CMO on page 2-66 and Combined CopyBack Write and
CMO on page 2-72.

StashDone
Sent by a Completer for StashOnceSep to signal the ordering of the request at the Completer.
See Independent Stash request on page 7-307.

TagMatch
Sent by the Completer for a Write transaction with TagOp of Match to signal the completion of the
Tag Match operation.
See Tag Match on page 12-394.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-219
ID092622 Non-Confidential
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-33. 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-33 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.

The Notes column in Table 4-33 indicates how a silent cache transition can be made non-silent or visible at the
interface.

Table 4-33 Legal silent cache state transitions

RN-F action RN-F Cache state Notes

Present Next

Cache eviction UC I Can use Evict, WriteEvictFull, or WriteEvictOrEvict 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 cache line store

UCE UDP Partial cache line store

UCE UD Full cache 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.

4-220 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

4.7 Cache state transitions at a Requester

This section specifies the cache state transitions and completion responses for the following request transactions:
• Read request transactions
• Dataless request transactions on page 4-229
• Write request transactions on page 4-230
• Atomic transactions on page 4-231
• Other request transactions on page 4-231

4.7.1 Read request transactions

Table 4-34 shows the cache state transitions at the Requester, and the completion responses, for Read request
transactions except for the MakeReadUnique transaction.

For details of the permitted completion responses and cache state transitions at the Requester for the
MakeReadUnique transaction, both Non-exclusive and Exclusive, see MakeReadUnique transaction on
page 4-224.

The cache state in the Data response to the Requester from the Subordinate Node is UC, that is, CompData_UC
irrespective of the original request type. The Requester must ignore the cache state in the CompData response to
ReadNoSnp, ReadOnce, ReadOnceCleanInvalid, and ReadOnceMakeInvalid and implicitly assume the cache state
value to be I.

Note
In a non-DMT data transfer, where the CompData response is sent from the Subordinate to Home, the cache state
in the response can be either I or UC. It is expected that typically the design of a Subordinate can be simplified by
always using UC. Home then sends CompData to the Requester with the appropriate cache state value.

Table 4-34 Cache state transitions at the Requester for Read request transactions

Cache state

Request type Initial

Final Comp response Separate responses
Expected Others permitted

ReadNoSnp I - I CompData_UC, RespSepData +

CompData_I DataSepResp_UC

ReadOnce I, UCEa - I CompData_UC, RespSepData +

CompData_I DataSepResp_UC

ReadOnceCleanInvalid I, UCEa - I CompData_UC, RespSepData +

CompData_I DataSepResp_UC

ReadOnceMakeInvalid I, UCEa - I CompData_UC, RespSepData +

CompData_I DataSepResp_UC

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-221
ID092622 Non-Confidential
Coherence Protocol
4.7 Cache state transitions at a Requester

Table 4-34 Cache state transitions at the Requester for Read request transactions (continued)

Cache state

Request type Initial

Final Comp response Separate responses
Expected Others permitted

ReadClean I - SC CompData_SC RespSepData +

TagOp = Transfer DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

UC, UCE UC CompData_SC RespSepData +

DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

UD, UDP - UD CompData_SC RespSepData +

DataSepResp_SC

UD CompData_UC RespSepData +
DataSepResp_UC

SC - SC CompData_SC RespSepData +
DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

SDb - SD CompData_SC RespSepData +

DataSepResp_SC

UD CompData_UC RespSepData +
DataSepResp_UC

ReadClean I - SC CompData_SC RespSepData +

TagOp != Transfer DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

UCE - UC CompData_SC RespSepData +

DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

ReadNotSharedDirty I, UCEa - SC CompData_SC RespSepData +

DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

UD CompData_UD_PD RespSepData +
DataSepResp_UD_PD

4-222 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

Table 4-34 Cache state transitions at the Requester for Read request transactions (continued)

Cache state

Request type Initial

Final Comp response Separate responses
Expected Others permitted

ReadShared I, UCEa - SC CompData_SC RespSepData +

DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

SD CompData_SD_PD -

UD CompData_UD_PD RespSepData +
DataSepResp_UD_PD

ReadUnique I, SC UC, UCE UC CompData_UC RespSepData +

DataSepResp_UC

UD CompData_UD_PD RespSepData +
DataSepResp_UD_PD

SD UD, UDPc UD CompData_UC RespSepData +

DataSepResp_UC,
CompData_UD_PD RespSepData +
DataSepResp_UD_PD

ReadPreferUnique I, SC - SC CompData_SC RespSepData +

DataSepResp_SC

UC CompData_UC RespSepData +
DataSepResp_UC

UD CompData_UD_PD RespSepData +
DataSepResp_UD_PD

SDb - SD CompData_SC RespSepData +

DataSepResp_SC

UD CompData_UC RespSepData +
DataSepResp_UC,
CompData_UD_PD RespSepData +
DataSepResp_UD_PD

MakeReadUnique See Table 4-37 on page 4-227 and Table 4-38 on page 4-228.

a. For ReadOnce, ReadNotSharedDirty and ReadShared transactions the Requester with an initial state of UCE must not upgrade the cache
line to UDP nor UD while the request is outstanding.
b. A Requester in initial state of SD that receives a CompData_SC or DataSepResp_SC response must stay in SD state. Similarly, a Home
that uses a Snoop filter to track the cached state at the Requester, must not downgrade the state of the cache line in the snoop filter based
on the state in the response to the Requester.
c. Data received from memory must be dropped if the cache state is UD or SD, or merged if the cache state is UDP. Data received from
memory must be the same as the cached data when the cache state is SC or UC.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-223
ID092622 Non-Confidential
Coherence Protocol
4.7 Cache state transitions at a Requester

MakeReadUnique transaction
This section describes the permitted responses and the cache state transitions at the Requester, for the
MakeReadUnique and MakeReadUnique(Excl) transactions. The additional MakeReadUnique(Excl) behavioral
requirements are described in MakeReadUnique(Excl) on page 6-298.

Permitted responses

Table 4-35 shows the permitted responses in a MakeReadUnique transaction. Table 4-36 on page 4-225 shows the
additional responses that are permitted only when the Exclusive bit in the request is set to one. This attribute is
indicated by adding the suffix (Excl) to the request.

Some key features of the permitted responses are:

• A response without data, Comp_UD_PD, indicates that the Requester is being passed responsibility for a
Dirty cache line.
This can occur when the Requester holds a SharedClean copy of the cache line and another agent holds a
SharedDirty copy. The Home invalidates the SharedDirty copy, for example using a SnpMakeInvalid
transaction, and then passes the responsibility for the Dirty cache line to the Requester that issued the
MakeReadUnique transaction.

• A response with a cache state of SC is only permitted in response to an Exclusive version of

MakeReadUnique.
Comp_SC, an example of a response with a cache state of SC, is sent when the Home determines that the
Exclusive Store has failed but the snoop filter, or response to a SnpQuery snoop to the Requester, indicates
that the Requester still holds a copy of the cache line while there is another shared copy in the system.

Note
The above situation can occur with a non-full address PoC exclusive monitor. The monitor bit for an LP can
be reset by another LP performing an Exclusive store to a different address location. This store to a different
address does not invalidate the cached copy of the address location being used for Exclusive access by the
first Requester.

Table 4-35 shows the permitted responses in both the non-Exclusive and Exclusive MakeReadUnique transaction.

Table 4-35 Permitted responses in the MakeReadUnique transaction

Response Received Description

Comp_UC Requester retains its copy of the cache line.

All other cached copies have been invalidated.
Cache line might be Clean or Dirty at the Requester.

Comp_UD_PD Requester retains its copy of the cache line.

Dirty copy of the cache line held elsewhere has been invalidated.
Cache line must become Dirty at the Requester.

CompData_UC Requester lost the cache line while the transaction was in progress.
Clean copy of the cache line is given to the Requester.
Combined data and completion responses are given.

4-224 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

Table 4-35 Permitted responses in the MakeReadUnique transaction (continued)

Response Received Description

CompData_UD_PD Requester lost the cache line while the transaction was in progress.
Dirty copy of the cache line is given to the Requester.
Combined data and completion responses are given.

RespSepData, Requester lost the cache line while the transaction was in progress.
DataSepResp_UC Clean copy of the cache line is given to the Requester.
Separate data and completion responses are given.

RespSepData, Requester lost the cache line while the transaction was in progress.
DataSepResp_UD_PD Dirty copy of the cache line is given to the Requester.
Separate data and completion responses given by Home.

Table 4-36 shows the additional permitted responses in the Exclusive MakeReadUnique transaction.

Table 4-36 Additional permitted responses in the MakeReadUnique (Excl) transaction

Response received Description

Comp_SC Global Exclusive check fails.

Shared cached copy exists in another cache.
Requester retains its copy of the cache line.

CompData_SC Global Exclusive check fails.

Shared cached copy exists in another cache.
Requester might have lost its copy of the cache line.

RespSepData Global Exclusive check fails.

DataSepResp_SC Shared cached copy exists in another cache.
Requester might have lost its copy of the cache line.

Expected snoops

The use of snoops by the Home to invalidate a cache line at the Snoopee in response to a non-Exclusive
MakeReadUnique, or an Exclusive MakeReadUnique that passes an Exclusive check, are as follows:
• The Home is expected to use a SnpCleanInvalid snoop:
— The Home is permitted to use SnpUnique instead of SnpCleanInvalid.
— The Home is permitted to use SnpUniqueFwd if it determines that the Requester has lost the cached
copy of the cache line.
— The Home is also permitted to use SnpMakeInvalid instead of SnpCleanInvalid if it determines that
the Snoopee does not have a Dirty copy of the cache line.

See Home behavior on page 6-298 for the types of snoops the Home is expected and permitted to use when an
Exclusive MakeReadUnique request fails the Exclusive check.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-225
ID092622 Non-Confidential
Coherence Protocol
4.7 Cache state transitions at a Requester

Cache line state transitions

The final state of the cache line after a MakeReadUnique transaction depends on the state of the cache line
immediately before the transaction response is received. This can be different from the state of the cache line at the
point the transaction is issued.

For MakeReadUnique, the Requester must keep a copy of the cache line unless it receives an invalidating snoop.

• Invalidating snoops are SnpUnique, SnpUniqueFwd, SnpCleanInvalid, SnpMakeInvalid, SnpUniqueStash,

and SnpMakeInvalidStash.

• The Requester is permitted to treat SnpPreferUnique and SnpPreferUniqueFwd as either invalidating or

non-invalidating. The Home can determine how these snoops are treated by the Snoopee by inspecting the
Snoop response.

• All other snoops are non-invalidating and the Requester is required to keep a copy of the cache line.

If the Home does not have an SF, or the SF is imprecise, and the Home cannot determine if the Requester still has
a copy of the cache line at the point that the transaction completes, then the Home must assume the cache line is lost
at the Requester and provide data with the response.

A Requester that receives a response with data, while still holding the line in SD state, must use its own copy of the
cache line, rather than the copy returned with the response.

Note
A Requester that receives a response with data, while still holding the line in SD state implies there is no snoop filter
present or that the snoop filter is imprecise. In this case, it is possible that the data returned with the response is Stale.

If the Requester is aware that there is no snoop filter, then it can use a CleanUnique transaction instead of
MakeReadUnique to avoid an unnecessary memory read when the cache line is not cached at any other agent.

Note
Use of the CleanUnique transaction can avoid an unnecessary memory read in the absence of a snoop filter. The
unnecessary memory read occurs when the cache line remains cached at the Requester, but a snoop filter is not
present in the system or a SnpQuery snoop is not used and a cached copy is not available from another agent in the
system. However, using a CleanUnique transaction will result in the Requester needing to issue another transaction
in the case where the cache line is lost due to a snoop while the transaction is in progress.

Table 4-35 on page 4-224 shows the state transitions and responses that are applicable to both non-Exclusive and
Exclusive versions of MakeReadUnique. Table 4-36 on page 4-225 shows the additional state transitions and
responses that apply only to the Exclusive version of the request.

The response rules are:

• The cache state in the response to a non-Exclusive MakeReadUnique must be Unique.

• The cache state in the response to an Exclusive MakeReadUnique is permitted to be Unique or Shared.

• The cache state in the response to an Exclusive and to a Non-exclusive MakeReadUnique must not include
Shared Dirty.

• For each permitted combined completion and data response, a corresponding response with separate
completion and data is permitted.

Table 4-37 on page 4-227 and Table 4-38 on page 4-228 include columns for:
• The initial cache state.
• The cache state immediately before the transaction response is received.
• The final state for each of the possible response combinations.

4-226 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

The handling of a MakeReadUnique transaction at the Home depends on the availability or not of a precise Snoop
Filter. Table 4-37 and Table 4-38 on page 4-228 also include the responses that are permitted with and without a
precise Snoop Filter:

• The table column labeled: Snoop Filter - Precise, covers the cases when the precise state of the cache line at
the Requester, at the response time, is known. The Home obtains the knowledge of precise state from a snoop
filter, or by sending a SnpQuery snoop, or in some other IMPLEMENTATION DEFINED manner.

• The column labeled: Snoop Filter - Imprecise or Absent, covers the cases when the precise state of the cache
line at the Requester, at the response time, is not known. This also includes the case when there is no snoop
filter, or the Home might decide to ignore the available precise information, or not attempt to obtain the
information.

Table 4-37 and Table 4-38 on page 4-228 use the following key:
Y Yes, permitted
- Not permitted

Table 4-37 Cache state transitions at the Requester for the

MakeReadUnique request (non-Excl and Excl)

Cache State Snoop Filter

Home sent Comp Resp Imprecise Notes

At time of
Initial invalidating Final Precise or
Response snoop Absent

SD SD No UD Comp_UC Y -

CompData_UC - Y Returned data

might be stale
RespSepData, - Y
DataSepResp_UC

SC, SC No UC Comp_UC Y -
SD
CompData_UC - Y

RespSepData, - Y
DataSepResp_UC

UD Comp_UD_PD Y -

CompData_UD_PD - Y Data in
response is
RespSepData, - Y identical to the
DataSepResp_UD_PD Requester copy

I Yes UC CompData_UC Y Y Line lost to an

invalidating
RespSepData, Y Y snoop
DataSepResp_UC

UD CompData_UD_PD Y Y

RespSepData, Y Y
DataSepResp_UD_PD

I, UC, Not permitted

UD

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-227
ID092622 Non-Confidential
Coherence Protocol
4.7 Cache state transitions at a Requester

Table 4-38 Additional Cache state transitions at the Requester for the
MakeReadUnique(Excl) request

Cache State Snoop Filter

Home sent Comp Resp Imprecise

At time of
Initial invalidating Final Precise or
Response snoop Absent

SC, SD SC No SC Comp_SC Y -

I Yes SC CompData_SC Y Y

RespSepData Y Y
DataSepResp_SC

SD SD No SD Comp_SC Y -

CompData_SC - Y

RespSepData - Y
DataSepResp_SC

See MakeReadUnique(Excl) on page 6-298 for the additional MakeReadUnique(Excl) behavioral requirements.

4-228 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

4.7.2 Dataless request transactions

Table 4-39 shows the cache state transitions at the Requester, and the completion responses, for Dataless request
transactions.

Table 4-39 Cache state transitions at the Requester for Dataless request transactions

Cache state

Request type Initial Final Comp Response

Expected Others 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

Evict I - I Comp_I

StashOnceUnique I - I Comp

StashOnceSepUnique I - I Comp + StashDone

or CompStashDone

StashOnceShared I - I Comp

StashOnceSepShared I - I Comp + StashDone

or CompStashDone

CleanShared I, SC, UC - No Change Comp_UC

CleanSharedPersist
Comp_SC

Comp_I

CleanSharedPersistSep I, SC,UC - No Change Comp_UC + Persist

or CompPersist_UC

Comp_SC + Persist
or CompPersist_SC

Comp_I + Persist
or CompPersist_I

CleanInvalid I - I Comp_I

MakeInvalid 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-39 shows I state as the only initial state.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-229
ID092622 Non-Confidential
Coherence Protocol
4.7 Cache state transitions at a Requester

4.7.3 Write request transactions

Table 4-40 shows the cache state transitions at the Requester, the WriteData response, and the combined or separate
completion and DBIDResp response for Write and corresponding Combined Write request transactions. Combined
Write request transactions are not listed in Table 4-40. See Combined Write requests on page 4-192.

Table 4-40 Requester cache state transitions for Write request transactions

Cache state at Requester

Request Type Comp response WriteData response
Before WriteData
Initial Final
responsea

WriteNoSnpPtl I - I DBIDResp + Comp NCBWrData or

or CompDBIDResp NCBWrDataCompAck or
WriteDataCancel

WriteNoSnpFull I - I DBIDResp + Comp NCBWrData or

or CompDBIDResp NCBWrDataCompAck

WriteNoSnpZero I - I DBIDResp + Comp None

or CompDBIDResp

WriteUniquePtl I I I DBIDResp + Comp NCBWrData or

WriteUniquePtlStash or CompDBIDResp WriteDataCancel or
NCBWrDataCompAck

WriteUniqueZero I I I DBIDResp + Comp None

or CompDBIDResp

WriteUniqueFull I I I DBIDResp + Comp NCBWrData or

WriteUniqueFullStash or CompDBIDResp NCBWrDataCompAck

WriteBackFull UD UD I CompDBIDResp CBWrData_UD_PD

UC I CompDBIDResp CBWrData_UC

UD, SD SD I CompDBIDResp CBWrData_SD_PD

SC I CompDBIDResp CBWrData_SC

I I CompDBIDResp CBWrData_I

WriteBackPtl UDP UDP I CompDBIDResp CBWrData_UD_PD

I I CompDBIDResp CBWrData_I

WriteCleanFull UD UD UCb CompDBIDResp CBWrData_UD_PD

UC UCb CompDBIDResp CBWrData_UC

CompDBIDResp CBWrData_I

UD, SD SD SC CompDBIDResp CBWrData_SD_PD

SC SC CompDBIDResp CBWrData_SC

CompDBIDResp CBWrData_I

I I CompDBIDResp CBWrData_I

4-230 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.7 Cache state transitions at a Requester

Table 4-40 Requester cache state transitions for Write request transactions (continued)

Cache state at Requester

Request Type Comp response WriteData response
Before WriteData
Initial Final
responsea

WriteEvictFull UC UC I CompDBIDResp CBWrData_UC

SC I CompDBIDResp CBWrData_SC

I I CompDBIDResp CBWrData_I

WriteEvictOrEvict UC UCc I CompDBIDResp CBWrData_UC

I Compd None

UC, SC SC I CompDBIDResp CBWrData_SC

I Compd None

I I CompDBIDResp CBWrData_I

I Compd None

a. A snoop might be received while a write is pending and results in a cache line state change before the WriteData response.
b. After completion of a WriteClean transaction, it is possible for the cache line in a Unique state to immediately transition to a Dirty state.
c. Once the request is sent the Requester is permitted to keep the cache state in UC but must not modify the cache line.
d. Comp is sent if the Home decides not to request data.

4.7.4 Atomic transactions

Table 4-41 shows the cache state transitions at the Requester, and the completion and response for Atomic
transactions.

Table 4-41 Requester cache state transitions for Atomic request transactions

Cache state

Initial Final WriteData

Atomic request Comp response
response
Others
Expected
permitted

AtomicStore I, SC UC, UD, UDP I DBIDResp + Comp_I NCBWrData

UCE, SD or CompDBIDResp

AtomicLoad I, SC UC, UD, UDP I DBIDResp + CompData_I NCBWrData

UCE, SD

AtomicSwap I, SC UC, UD, UDP I DBIDResp + CompData_I NCBWrData

UCE, SD

AtomicCompare I, SC UC, UD, UDP I DBIDResp + CompData_I NCBWrData

UCE, SD

4.7.5 Other request transactions

DVMOp and PrefetchTgt requests do not have any cache state transitions associated with them.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-231
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

4.8 Cache state transitions at a Snoopee

This section specifies the cache state transitions and completion responses for the following Snoop transactions:
• Non-Forwarding and Non-stash Snoop transactions
• Stash snoop transactions on page 4-238
• Forwarding Snoop transactions on page 4-240

A Snoopee, an RN-F that receives a snoop, performs two actions. One action is a state change of the cached line
and the second action is sending a response message either to the Home, or to both the Home and the Requester.

The cache state change depends on the snoop type, the initial state of the cache line and the value of DoNotGoToSD
in the snoop. See Do not transition to SD on page 4-252.

The Snoopee must send a response to Home either with Data or without Data. If for Forwarding snoops, the Snoopee
can also forward a Data response to the Requester.

The type of response sent is determined by the snoop type, initial cache state, cache state change, and the value of
RetToSrc. See Returning Data with Snoop response on page 4-251.

4.8.1 Non-Forwarding and Non-stash Snoop transactions

The Non-forwarding and Non-stash Snoop transactions are:
• SnpOnce
• SnpClean, SnpShared, SnpNotSharedDirty, and SnpPreferUnique on page 4-234
• SnpUnique and SnpPreferUnique on page 4-235
• SnpCleanShared, SnpCleanInvalid, and SnpMakeInvalid on page 4-236
• SnpQuery on page 4-237

SnpOnce
Table 4-42 on page 4-233 shows for SnpOnce, the initial, expected final, and other permitted final cache states at
the snooped Requester, the RetToSrc field value, and the valid completion response from a snooped RN-F.

4-232 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-42 Cache state transitions, RetToSrc value, and valid completion responses

Final cache state

Snoop request Initial
RetToSrca Snoop response
type cache state Others
Expected
permitted

SnpOnce I I - X SnpResp_I

UC UC I, SC X SnpResp_UC

SnpRespData_UC

SC I X SnpResp_SC

SnpRespData_SC

I - X SnpResp_I

SnpRespData_I

UCE UCE I X SnpResp_UC

I - X SnpResp_I

UD UD SD X SnpRespData_UD

SD - X SnpRespData_SD

SC I X SnpRespData_SC_PD

I - X SnpRespData_I_PD

UDP I - X SnpRespDataPtl_I_PD

UDP - X SnpRespDataPtl_UD

SC SC I 0 SnpResp_SC

1 SnpRespData_SC

I - 0 SnpResp_I

1 SnpRespData_I

SD SD - X SnpRespData_SD

SC I X SnpRespData_SC_PD

I - X SnpRespData_I_PD

a. X indicates that the protocol requirements apply for both states of RetToSrc.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-233
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpClean, SnpShared, SnpNotSharedDirty, and SnpPreferUnique

Table 4-43 shows for SnpClean, SnpShared, SnpNotSharedDirty and SnpPreferUnique the initial, expected final,
and other permitted final cache states at the snooped Requester, the RetToSrc field value, and the valid completion
response from a snooped RN-F. Table 4-43 must be used to determine SnpPreferUnique cache state transitions when
the Snoopee is in the middle of executing an Exclusive access sequence. A Snoopee that is not in the middle of
executing an Exclusive access is permitted, but not expected, to use Table 4-43 to determine SnpPreferUnique cache
state transitions.

See SnpPreferUnique and SnpPreferUniqueFwd on page 4-247 for constraints on determining when a Requester is
in the middle of executing an exclusive sequence.

Table 4-43 Cache state transitions, RetToSrc value, and valid completion responses

Final cache state

Initial
Snoop request type cache RetToSrca Snoop response
Others
state Expected
permitted

SnpClean, I I - X SnpResp_I
SnpShared,
UC SC I X SnpResp_SC
SnpNotSharedDirty,
SnpPreferUniqueb SnpRespData_SC

I - X SnpResp_I

SnpRespData_I

UCE I - X SnpResp_I

UD SDc - X SnpRespData_SD

SC I X SnpRespData_SC_PD

I - X SnpRespData_I_PD

UDP I - X SnpRespDataPtl_I_PD

SC SC I 0 SnpResp_SC

1 SnpRespData_SC

I - 0 SnpResp_I

1 SnpRespData_I

SD SDc - X SnpRespData_SD

SC I X SnpRespData_SC_PD

I - X SnpRespData_I_PD

a. X indicates that the protocol requirements apply for both states of RetToSrc.
b. Applicable when the Snoopee is in the middle of executing an Exclusive sequence. Protocol compliant at any time. See
also Table 4-44 on page 4-235.
c. This state transition is not permitted if DoNotGoToSD is set.

4-234 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpUnique and SnpPreferUnique

Table 4-44 shows for SnpUnique and SnpPreferUnique the initial, expected final, and other permitted final cache
states at the snooped Requester, the RetToSrc field value, and the valid completion response from a snooped RN-F
for SnpUnique. Table 4-44 is expected to be used to determine SnpPreferUnique cache state transitions when the
Snoopee is not in the middle of executing an Exclusive access sequence.

Table 4-44 Cache state transitions, RetToSrc value, and valid completion responses

Final cache state

Snoop request type Initial cache state RetToSrca Snoop response

Others
Expected
permitted

SnpUnique, I I - X SnpResp_I
SnpPreferUniqueb
UC I - X SnpResp_I

SnpRespData_I

UCE I - X SnpResp_I

UD I - X SnpRespData_I_PD

UDP I - X SnpRespDataPtl_I_PD

SC I - 0 SnpResp_I

1 SnpRespData_I

SD I - X SnpRespData_I_PD

a. X indicates that the protocol requirements apply for both states of RetToSrc.
b. Only applicable when the Snoopee is not in the middle of executing an Exclusive sequence.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-235
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpCleanShared, SnpCleanInvalid, and SnpMakeInvalid

Table 4-45 shows for SnpCleanShared, SnpCleanInvalid, and SnpMakeInvalid the initial, expected final, and other
permitted final cache states at the snooped Requester, the RetToSrc field value, and the valid completion response
from a snooped RN-F.

Table 4-45 Cache state transitions, RetToSrc value, and valid completion responses

Final cache state

Initial cache
Snoop request type RetToSrc Snoop response
state Others
Expected
permitted

SnpCleanShared I I - 0 SnpResp_I

UC UC I, SC 0 SnpResp_UC

SC I 0 SnpResp_SC

I - 0 SnpResp_I

UCE I - 0 SnpResp_I

UD UC I, SC 0 SnpRespData_UC_PD

SC I 0 SnpRespData_SC_PD

I - 0 SnpRespData_I_PD

UDP I - 0 SnpRespDataPtl_I_PD

SC SC I 0 SnpResp_SC

I - 0 SnpResp_I

SD SC I 0 SnpRespData_SC_PD

I - 0 SnpRespData_I_PD

SnpCleanInvalid I I - 0 SnpResp_I

UC I - 0 SnpResp_I

UCE I - 0 SnpResp_I

UD I - 0 SnpRespData_I_PD

UDP I - 0 SnpRespDataPtl_I_PD

SC I - 0 SnpResp_I

SD I - 0 SnpRespData_I_PD

SnpMakeInvalid I I - 0 SnpResp_I

UC I - 0 SnpResp_I

UCE I - 0 SnpResp_I

UD I - 0 SnpResp_I

UDP I - 0 SnpResp_I

SC I - 0 SnpResp_I

SD I - 0 SnpResp_I

4-236 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpQuery
Table 4-46 shows for SnpQuery the initial, expected final, and other permitted final cache states at the snooped
Requester, the RetToSrc field value, and the valid completion response from a snooped RN-F.

Table 4-46 Cache state transitions, RetToSrc value, and valid completion responses

Final cache state

Initial cache Snoop
Snoop request type RetToSrc
state Others response
Expected
permitted

SnpQuery I I - 0 SnpResp_I

UC UC - 0 SnpResp_UC

UCE UCE - 0 SnpResp_UC

UD UD - 0 SnpResp_UD

UDP UDP - 0 SnpResp_UD

SC SC - 0 SnpResp_SC

SD SD - 0 SnpResp_SD

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-237
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

4.8.2 Stash snoop transactions

The following sub-sections show the permitted responses for the Stash type snoops:
• SnpUniqueStash and SnpMakeInvalidStash
• SnpStashUnique and SnpStashShared on page 4-239

SnpUniqueStash and SnpMakeInvalidStash

The permitted responses to SnpUniqueStash and SnpMakeInvalidStash are the same as the responses to SnpUnique
and SnpMakeInvalid respectively.

The RetToSrc bit value must not be set to 1 in SnpUniqueStash and SnpMakeInvalidStash.

Any Snoop response to SnpUniqueStash and SnpMakeInvalidStash can include a DataPull request. A DataPull
request in a Snoop response to SnpUniqueStash and SnpMakeInvalidStash must be treated as a ReadUnique request.

Table 4-47 shows the Snoopee cache state transitions and required Snoop responses. The Snoop responses do not
include the DataPull options. DataPull is permitted with any Snoop response.

Table 4-47 Snoop response to SnpUniqueStash and SnpMakeInvalidStash

Cache state

Initial Final
Snoop request type RetToSrc Snoop response
Others
Expected
permitted

SnpUniqueStash I I - 0 SnpResp_I

UC I - 0 SnpRespData_I

SnpResp_I

UCE I - 0 SnpResp_I

UD I - 0 SnpRespData_I_PD

UDP I - 0 SnpRespDataPtl_I_PD

SC I - 0 SnpResp_I

SnpRespData_I

SD I - 0 SnpRespData_I_PD

SnpMakeInvalidStash Any I - 0 SnpResp_I

4-238 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpStashUnique and SnpStashShared

For SnpStashUnique and SnpStashShared, the Snoopee must not change cache state.

The Snoopee is permitted to not perform a cache lookup before responding, in which case the Snoop response must
be SnpResp_I.

The Snoopee is permitted to include the precise cache state in the response.

A Snoop response can include DataPull only if the cache state in the response is precise.

The Snoopee can include a DataPull in response to a SnpStashUnique only if the cache-data is not present, or present
in a Shared state. The Snoopee can include DataPull in response to SnpStashShared only if the cache cache-data is
not present.

A DataPull request in a Snoop response to SnpStashUnique must be treated as a ReadUnique request. A DataPull
request in a Snoop response to SnpStashShared must be treated as a ReadNotSharedDirty request.

The inclusion of DataPull in the Snoop response must ensure that the initial state must not violate the initial state
conditions permitted for the corresponding independent Read requests. See Read transactions on page 4-173.

Table 4-48 shows the Snoopee cache state transitions, the required Snoop responses, and DataPull options for
SnpStashUnique.

Table 4-48 Snoop response to SnpStashUnique

Cache state

Initial Final
Snoop request type RetToSrc Snoop response
Others
Expected
permitted

SnpStashUnique I I - 0 SnpResp_I

SnpResp_I_Read

UC UC - 0 SnpResp_UC

SnpResp_I

UCE UCE - 0 SnpResp_UC

SnpResp_UC_Read

SnpResp_I

UD UD - 0 SnpResp_UD

SnpResp_I

UDP UDP - 0 SnpResp_UD

SnpResp_I

SC SC - 0 SnpResp_SC

SnpResp_SC_Read

SnpResp_I

SD SD - 0 SnpResp_SD

SnpResp_SD_Read

SnpResp_I

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-239
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-49 shows the Snoopee cache state transitions, the required Snoop responses, and Data Pull options for
SnpStashShared.

Table 4-49 Snoop response to SnpStashShared

Cache state

Initial Final
Snoop request type RetToSrc Snoop response
Others
Expected
permitted

SnpStashShared I I - 0 SnpResp_I_Read

SnpResp_I

UC UC - 0 SnpResp_UC

SnpResp_I

UCE UCE - 0 SnpResp_UC

SnpResp_UC_Read

SnpResp_I

UD UD - 0 SnpResp_UD

SnpResp_I

UDP UDP - 0 SnpResp_UD

SnpResp_I

SC SC - 0 SnpResp_SC

SnpResp_I

SD SD - 0 SnpResp_SD

SnpResp_I

4.8.3 Forwarding Snoop transactions

Forwarding (Fwd) type snoops are used by Home to support DCT. The Forwarding Snoop transactions are:
• SnpOnceFwd on page 4-242
• SnpCleanFwd, SnpNotSharedDirtyFwd on page 4-244
• SnpSharedFwd on page 4-245
• SnpUniqueFwd on page 4-246
• SnpPreferUnique and SnpPreferUniqueFwd on page 4-247

The rules, common to all Forwarding snoops at the Snoopee are:

• Expected, but not required, to forward a copy of the cache line to the Requester if the cache line is in one of
the following states:
— UD
— UC
— SD
— SC

• The Snoopee is permitted, but not expected, to convert the Snoop to its corresponding Non-forwarding type.

4-240 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

• Must not forward data in Unique state in response to a Non-invalidating type snoop.

• Snoopee receiving a Snoop request with the DoNotGoToSD bit set, except when the Snoop is SnpOnceFwd,
must not transition to SD, even if the coherency conditions permit it.

• In certain cases, based on the Snoop type, the state of the cache line at the Snoopee, and the RetToSrc value
in the Snoop request, the Snoopee forwards a copy to Home along with a copy to the Requester. Forwarding
snoops must not be used if the original request requests tags.
If tags are available, Clean tags are permitted to be forwarded to the Requester along with the data.

• Home is not permitted to send a Forwarding type snoop for:

— Atomic transactions
— Passing Exclusive read transactions
Note
Exclusive read transactions that fail due to Non-exclusive support for the address range being accessed
are treated as corresponding Non-exclusive reads, Home can therefore use Forwarding type snoops in
these cases.

For the rules that are specific to a particular Forwarding snoop see the individual sub-sections in Forwarding Snoop
transactions on page 4-240.

The tables in the following individual sub-sections show the Snoopee state transitions and the corresponding
responses to the Requester and the Home.

The first column in the tables shows the initial cache state, and is the combined data and tag state. Table 4-50 shows
the combined state used and the corresponding data and possible tag state combinations.

Table 4-50 Combined state and the corresponding data and tag states

Combined state Data state Tag state

I I I

UC UC I
Clean

UCE UCE I

UD UD I
Clean
Dirty

UDP UDP I

SC SC I
Clean

SD SD I
Clean
Dirty

The last three columns in the tables correspond to the TagOp value in the Data responses to Home. They are
organized, based on the initial state of the tags:

Dirty Two columns:

• First column: Indicates if the transition itself is permitted or not. This column is only relevant
when the tag initial state is Dirty.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-241
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-51 shows the conventions used, P and NP are only relevant when the data initial state
is UD or SD and the tag initial state is Dirty.

Table 4-51 Key to table conventions

Symbol Description

P The transition is permitted

NP The transition is not permitted

- TagOp is not applicable

• Second column: The response TagOp value when the transition is permitted. The TagOp
value in the response:
— Must be Update if the response state includes Pass Dirty.
— Must be Transfer if the response does not include Pass Dirty.

Invalid, Clean
One column:
• TagOp in the response can be:
— Invalid if the initial tag state is Invalid or Clean.
— Transfer when the initial tag state is Clean.

In Snoop responses to Home without data, TagOp is inapplicable.

SnpOnceFwd
The rules, in addition to the common rules, to be followed by a Snoopee that receives a SnpOnceFwd are:
• Snoopee must forward the cache line in I state.
— As a consequence, the Snoopee must not forward Pass Dirty to the Requester.
• Snoopee must return data to Home only when Dirty state is changed to Clean or Invalid.
• RetToSrc bit in the snoop must be set to zero.
• Snoopee can ignore the DoNotGoToSD value in the snoop.

Table 4-52 shows the Snoopee cache state transitions and the required Snoop responses.

See Table 4-51 for the symbol key.

Table 4-52 SnpOnceFwd Snoopee state transitions with Clean and Dirty tags

TagOp value in
Snoopee cache state Response to
response to Home

Initial Final Initial tag state

RetToSrc

Requester Home
Other
Expected Dirty I. Clean
permitted

I I - 0 No Fwd SnpResp_I - - -

UC UC - 0 CompData_I SnpResp_UC_Fwded_I - - -

SC I 0 CompData_I SnpResp_SC_Fwded_I - - -

I - 0 CompData_I SnpResp_I_Fwded_I - - -

4-242 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-52 SnpOnceFwd Snoopee state transitions with Clean and Dirty tags (continued)

TagOp value in
Snoopee cache state Response to
response to Home

Initial Final Initial tag state

RetToSrc
Requester Home
Other
Expected Dirty I. Clean
permitted

UCE UCE - 0 No Fwd SnpResp_UC - - -

I - 0 No Fwd SnpResp_I - - -

UD UD - 0 CompData_I SnpResp_UD_Fwded_I Pa - -

SD - 0 CompData_I SnpResp_SD_Fwded_I Pa - -

SC I 0 CompData_I SnpRespData_SC_PD_Fwded_I P Updateb I,

Transferc

I - 0 CompData_I SnpRespData_I_PD_Fwded_I P Update I,

Transfer

UDP UDP - 0 No Fwd SnpRespDataPtl_UD - - I

I - 0 No Fwd SnpRespDataPtl_I_PD - - I

SC SC I 0 No Fwd SnpResp_SC - - -

CompData_I SnpResp_SC_Fwded_I - - -

I - 0 No Fwd SnpResp_I - - -

CompData_I SnpResp_I_Fwded_I - - -

SD SD - 0 CompData_I SnpResp_SD_Fwded_I Pa - -

SC I 0 CompData_I SnpRespData_SC_PD_Fwded_I P Update I.

Transfer

I - 0 CompData_I SnpRespData_I_PD_Fwded_I P Update I.

Transfer
a. This transition is permitted, even though the Snoop response does not include data and the tag state is Dirty, because Dirty tags are retained
by the Snoopee.
b. This transition from tag state of Dirty is permitted because a Dirty copy of tags and data are passed to the Home.
c. This transaction from an initial state of Dirty data, and Invalid or Clean tags, includes the Snoop response of data with Clean tags when
available.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-243
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpCleanFwd, SnpNotSharedDirtyFwd
The rules, in addition to the common rules, to be followed by a Snoopee that receives a SnpCleanFwd or a
SnpNotSharedDirtyFwd are:
• Snoopee must forward the cache line in SC state.
• Snoopee must transition to either SD, SC, or I state.
• For behavior related to the RetToSrc bit see Returning Data with Snoop response on page 4-251.

Table 4-53 shows the Snoopee cache state transitions and the required Snoop responses.

See Table 4-51 on page 4-242 for the symbol key.

Table 4-53 SnpCleanFwd and SnpNotSharedDirtyFwd Snoopee state transitions with Clean and Dirty tags

Snoopee cache (data+tag) TagOp value in

Response to
state response to Home

Initial Final Initial tag state

RetToSrc

Requester Home
Other
Expected Dirty I, Clean
permitted

I I - Xa No Fwd SnpResp_I - - -

UC SC I 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

I - 0 CompData_SC SnpResp_I_Fwded_SC - - -

1 CompData_SC SnpRespData_I_Fwded_SC - - I, Transfer

UCE I - Xa No Fwd SnpResp_I - - -

UD SDb - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I, Transfer

SC I Xa CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

I - Xa CompData_SC SnpRespData_I_PD_Fwded_SC P Update I, Transfer

UDP I - Xa No Fwd SnpRespDataPtl_I_PD - - I

SC SC I 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

I - 0 CompData_SC SnpResp_I_Fwded_SC - - -

1 CompData_SC SnpRespData_I_Fwded_SC - - I, Transfer

SD SDb - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I, Transfer

SC I Xa CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

I - Xa CompData_SC SnpRespData_I_PD_Fwded_SC P Update I, Transfer

a. The protocol requirements apply for both states of RetToSrc.

b. This state transition is not permitted if DoNotGoToSD is asserted.

4-244 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

SnpSharedFwd
The rules, in addition to the common rules, to be followed by a Snoopee that receives a SnpSharedFwd are:
• Snoopee is permitted to forward the cache line in either SD or SC state.
• Snoopee must transition to either SD, SC, or I state.
• For behavior related to the RetToSrc bit see Returning Data with Snoop response on page 4-251.

Table 4-54 shows the Snoopee cache state transition and the required Snoop responses.

See Table 4-51 on page 4-242 for the symbol key.

Table 4-54 SnpSharedFwd Snoopee state transitions with Clean and Dirty tags

TagOp value in
Snoopee cache state Response to
response to Home

Initial Final Initial tag state

RetToSrc

Requester Home
Other
Expected Dirty I, Clean
permitted

I I - Xa No Fwd SnpResp_I - - -

UC SC I 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

I - 0 CompData_SC SnpResp_I_Fwded_SC - - -

1 CompData_SC SnpRespData_I_Fwded_SC - - I, Transfer

UCE I - Xa No Fwd SnpResp_I - - -

UD SDb - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I, Transfer

SC I 0 CompData_SD_PD SnpResp_SC_Fwded_SD_PD NP - -

1 CompData_SD_PD SnpRespData_SC_Fwded_SD_PD NP - I, Transfer

Xa CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

I - 0 CompData_SD_PD SnpResp_I_Fwded_SD_PD NP - -

1 CompData_SD_PD SnpRespData_I_Fwded_SD_PD NP - I, Transfer

Xa CompData_SC SnpRespData_I_PD_Fwded_SC P Update I, Transfer

UDP I - Xa No Fwd SnpRespDataPtl_I_PD - - I

SC SC I 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

I - 0 CompData_SC SnpResp_I_Fwded_SC - - -

1 CompData_SC SnpRespData_I_Fwded_SC - - I, Transfer

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-245
ID092622 Non-Confidential
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-54 SnpSharedFwd Snoopee state transitions with Clean and Dirty tags (continued)

TagOp value in
Snoopee cache state Response to
response to Home

Initial Final Initial tag state

RetToSrc
Requester Home
Other
Expected Dirty I, Clean
permitted

SD SDb - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I. Transfer

SC I 0 CompData_SD_PD SnpResp_SC_Fwded_SD_PD NP - -

1 CompData_SD_PD SnpRespData_SC_Fwded_SD_PD NP - I, Transfer

Xa CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

I - 0 CompData_SD_PD SnpResp_I_Fwded_SD_PD NP - -

1 CompData_SD_PD SnpRespData_I_Fwded_SD_PD NP - I, Transfer

Xa CompData_SC SnpRespData_I_PD_Fwded_SC P Update I, Transfer

a. The protocol requirements apply for both states of RetToSrc.

b. This state transition is not permitted if DoNotGoToSD is asserted.

SnpUniqueFwd
Use of the SnpUniqueFwd snoop is only permitted if the cache line is cached at a single RN-F:

• Home is permitted to send the SnpUniqueFwd snoop to an RN-F in Shared state if Home determines that the
Invalidating snoop needs to be sent to only one cache.

The rules, in addition to the common rules, to be followed by a Snoopee that receives a SnpUniqueFwd are:
• Snoopee must forward the cache line in Unique state.
• Snoopee that has the cache line in Dirty state must Pass Dirty to the Requester not to Home.
• Snoopee must transition to I state.
• Snoopee must not return data to Home.

RetToSrc bit in the snoop must be set to zero.

Table 4-55 on page 4-247 shows the Snoopee cache state transitions and the required Snoop responses.

See Table 4-51 on page 4-242 for the symbol key.

4-246 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-55 SnpUniqueFwd Snoopee state transitions with Clean and Dirty tags

Snoopee cache (data+tags} TagOp value in

Response to
state response to Home

Initial Final Initial tag state

RetToSrc
Requester Home
Other
Expected Dirty I, Clean
permitted

I I - 0 No Fwd SnpResp_I - - -

UC I - 0 CompData_UC SnpResp_I_Fwded_UC - - -

UCE I - 0 No Fwd SnpResp_I - - -

UD I - 0 CompData_UD_PD SnpResp_I_Fwded_UD_PD NPa - -

No Fwd SnpRespData_I_PD P Update I, Transfer

UDP I - 0 No Fwd SnpRespDataPtl_I_PD - - I

SC I - 0 CompData_UC SnpResp_I_Fwded_UC - - -

SD I - 0 CompData_UD_PD SnpResp_I_Fwded_UD_PD NPa - -

No Fwd SnpRespData_I_PD P Update I, Transfer

a. This transition is not permitted because Dirty tags are lost. The Dirty tags are lost because the Snoop response to the Home does not include data
with which to pass the Dirty tags to the Home.

SnpPreferUnique and SnpPreferUniqueFwd

Use of the SnpPreferUniqueFwd snoop is only permitted if the cache line is cached at a single RN-F.

The rules, in addition to the common rules, to be followed by a Snoopee that receives a SnpPreferUniqueFwd and
does not treat it as the Non-forwarding snoop are:

• When the Snoopee is in the process of executing an Exclusive access sequence, using the same address:
— Snoopee must forward the cache line in SC state.
— Snoopee must transition to either SD or SC state.
— Snoopee must not transition to I state, except when in UCE or UDP state.
— For behavior related to the RetToSrc bit see Returning Data with Snoop response on page 4-251
related to SnpNotSharedDirtyFwd.
— A Snoopee that is not in the middle of executing an Exclusive access sequence is permitted, but not
expected, to treat the snoop as a Non-invalidating snoop.

• When the Snoopee is not in the process of executing an Exclusive access sequence, using the same address,
and treats the snoop as an Invalidating snoop:
— Snoopee must forward the cache line in Unique state.
— Snoopee that has the cache line in Dirty state must Pass Dirty to the Requester not to Home.
— Snoopee must transition to I state.
— Snoopee must not return data to Home.
— RetToSrc bit value in the snoop is ignored and treated as zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-247
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

For SnpPreferUnique and SnpPreferUniqueFwd, it is IMPLEMENTATION DEFINED when an agent is in the process of
executing an exclusive sequence. This specification cannot determine whether a Snoopee will treat
SnpPreferUnique as an invalidating snoop or a non-invalidating snoop. To determine this, the Snoop response must
be inspected. It is protocol compliant for a Snoopee to always treat the snoop as non-invalidating.

4-248 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-56 and Table 4-57 on page 4-250 show the Snoopee cache state transitions and the required Snoop
responses.

See Table 4-51 on page 4-242 for the symbol key.

Table 4-56 State transitions for SnpPreferUniqueFwd when Snoopee is executing an exclusive sequence

Snoopee cache (Data+tag) TagOp value in

Response to
state response to Home

Initial Final Initial tag state

RetToSrc
Requester Home
Other
Expected Dirty I, Clean
Permitted

I I - X No Fwd SnpResp_I - - -

UC SC - 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

UCE I - X No Fwd SnpResp_I - - -

UD SD - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I, Transfer

SC - X CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

UDP I - X No Fwd SnpRespDataPtl_I_PD - - I

SC SC - 0 CompData_SC SnpResp_SC_Fwded_SC - - -

1 CompData_SC SnpRespData_SC_Fwded_SC - - I, Transfer

SD SD - 0 CompData_SC SnpResp_SD_Fwded_SC P - -

1 CompData_SC SnpRespData_SD_Fwded_SC P Transfer I, Transfer

SC - X CompData_SC SnpRespData_SC_PD_Fwded_SC P Update I, Transfer

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-249
ID092622 Non-Confidential
Coherence Protocol
4.8 Cache state transitions at a Snoopee

Table 4-57 shows the expected and permitted Snoopee cache state transitions and responses to the
SnpPreferUniqueFwd Snoop request when the Snoopee is not executing an Exclusive sequence.

See Table 4-51 on page 4-242 for the symbol key.

Table 4-57 State transitions for SnpPreferUniqueFwd when Snoopee is not executing an exclusive sequence

Snoopee cache (data+tag) TagOp value in

Response to
state response to Home

Initial Final Initial tag state

Other RetToSrc Requester Home

Expected Dirty I, Clean
Permitted

I I - X No Fwd SnpResp_I - - -

UC I - X CompData_UC SnpResp_I_Fwded_UC - - -

UCE I - X No Fwd SnpResp_I - - -

UD I - X CompData_UD_PD SnpResp_I_Fwded_UD_PD NP - -

X No Fwd SnpRespData_I_PD P Update I, Transfer

UDP I - X No Fwd SnpRespDataPtl_I_PD - - I

SC I - X CompData_UC SnpResp_I_Fwded_UC - - -

SD I - X CompData_UD_PD SnpResp_I_Fwded_UD_PD NP

X No Fwd SnpRespData_I_PD P Update I, Transfer

4-250 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.9 Returning Data with Snoop response

4.9 Returning Data with Snoop response

The rules for returning a copy of the cache line with the Snoop response are detailed below.

For Non-forwarding snoops, except SnpMakeInvalid, the rules for returning a copy of the cache line to the Home
are:

• Irrespective of the value of RetToSrc, must return a copy if the cache line is Dirty.

• Irrespective of the value of RetToSrc, optionally can return a copy if the cache line is Unique Clean.

• If the RetToSrc value is 1, must return a copy if the cache line is Shared Clean and the Snoopee retains a copy
of the cache line.

• If the RetToSrc value is 0, must not return a copy if the cache line is Shared Clean.
For Forwarding snoops where data is being forwarded, the rules for returning a copy of the cache line to the Home
are:
• Irrespective of the value of RetToSrc, must return a copy if a Dirty cache line cannot be forwarded or kept.
• If the RetToSrc value is 1, must return a copy if the cache line is Dirty or Clean.
• If the RetToSrc value is 0, must not return a copy if the cache line is Clean.

RetToSrc is inapplicable and must be set to zero in:

• SnpQuery and Stash snoops
• SnpCleanShared, SnpCleanInvalid, and SnpMakeInvalid
• SnpOnceFwd and SnpUniqueFwd

RetToSrc is applicable and can take any value in all other snoops except SnpDVMOp.

RetToSrc is inapplicable and must be set to zero in SnpDVMOp.

Home must only set RetToSrc on the Snoop request to a single Request Node.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-251
ID092622 Non-Confidential
Coherence Protocol
4.10 Do not transition to SD

4.10 Do not transition to SD

Do not transition to SD is a modifier on Non-invalidating snoops.

It specifies when a Snoopee must not transition to SD state as a result of the Snoop request.

The field name is DoNotGotoSD.

Note
• A non-forced change or silent change from UD to SD is permitted irrespective of the value of
DoNotGoToSD.
• Any forced change from Unique to Shared must obey DoNotGoToSD.

See Do not transition to SD state, DoNotGoToSD on page 13-442 for the field applicability and field value
encoding.

4-252 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Coherence Protocol
4.11 Hazard conditions

4.11 Hazard conditions

This section lists the responsibilities of the RN-F and HN-F to handle address hazards and race conditions among
Snoopable transactions. Ordering among Non-snoopable transactions and among Snoopable transactions is
described in Ordering on page 2-121.

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.11.1 At the RN-F node

An RN-F node must respond to received Snoop requests, except for SnpDVMOp(Sync), 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 and the pending request has not received any Data
response packets:

• 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, or forwarded to the
Requester, if required by the Snoop request type, Snoop request attributes, and cache state.

If a pending request to the same cache line is present at the RN-F and the pending request has received at least one
Data response packet:

• The RN-F must wait to receive all Data response packets before responding to the Snoop request.

• Once all the Data response packets are received by RN-F:

— The Snoop request must be processed normally.
— The cache state must transition as applicable for each Snoop request type.
— The cached data must be returned with the Snoop response, or forwarded to the Requester, if required
by the Snoop request type, Snoop request attributes, 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 CopyBackWrData 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.

• If the cache line state is I after the Snoop response is sent, the cache state in CopyBackWrData response must
be I, all byte enables must be deasserted, and the corresponding data must be set to zero.

• If the cache line state is UC or SC after the Snoop response is sent, a Request Node is permitted to not send
valid CopyBack Data. If the Request Node decides not to send valid CopyBack data, the cache state in the
CopyBackWrData response must be I, all byte enables must be deasserted, and the corresponding data must
be set to zero.

• If data is included with CopyBackWrData, it can be:

— The same data that has been sent with the Snoop response
— More up to date data than sent with the snoop response.
This is only possible when the snoop is SnpOnce, SnpOnceFwd, or SnpCleanShared, and the snoop
response indicates the cache line can be further modified.
— Older data than was sent with the snoop response.
This is only possible when the CopyBack write is a WriteClean, the snoop request is SnpOnce*, and
the response indicates that the cache line can be further modified.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 4-253
ID092622 Non-Confidential
Coherence Protocol
4.11 Hazard conditions

For non-ordered transactions, the Request Node can send CompAck without waiting for DataSepResp. For ordered
transactions, the Request Node can send CompAck as soon as the first packet of DataSepResp is received. In both
cases, a Request Node must not respond to a Snoop request before receiving all data packets.

The RN-F might receive multiple snoop requests before it receives a response for a pending CopyBack request for
the same cache line. In this instance, the data response carries the cache line state after the 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.

4.11.2 At the ICN(HN-F) node

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.

If a Response message that includes data requires multiple packets or beats of transfers over the interconnect,
receiving or sending the message by Home implies sending or receiving all the packets corresponding to that
message. That is, when a Home starts sending the message, it must send all packets of the message without
dependence on completion of any other request or response message.

Similarly, when a Home accepts part of the Data message, it must accept the remaining packets of that message
without any dependence on forward progress of any other request or response message.

When a subsequent forwarding of data depends upon receiving a Data message, the forwarding of data action can
occur after receiving the first Data packet. A subsequent Non-data forwarding action that is processing of a
subsequent request at Home as a consequence of sending or receiving of data by Home, must wait until all data is
sent or received.

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 and Atomics
• 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.
• A WriteData response for CopyBack and Atomic requests.
• For WriteUnique, a WriteData response, and, if applicable, CompAck.

4-254 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-256
• Dataless transaction flows on page 5-266
• Write transaction flows on page 5-270
• Atomic transaction flows on page 5-273
• Stash transaction flows on page 5-280
• Hazard handling examples on page 5-283
See Time-Space diagrams on page xv for details of the conventions used to illustrate protocol flow in this
specification.

In the transaction flow diagrams that follow:

• There are multiple coherent Request Nodes, an HN-F, and an SN-F.

• If the HN-F receives multiple data responses, that is, one response from a snooped RN-F and another from
an SN-F, then the data being forwarded to the Requester is highlighted in bold.

• There is no interconnect cache at the HN-F. This results in all requests to the HN-F initiating a request to the
SN-F.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-255
ID092622 Non-Confidential
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 transactions with DMT and without snoops

For Read transactions without snoops, it is recommended to use DMT.

Figure 5-1 shows an example DMT transaction flow using the ReadShared transaction.

In Figure 5-1, a response from SN-F to HN-F is not required because CompAck from the Requester is used to
deallocate the request at Home.

RN-F HN-F SN-F

I

ReadShared

ReadNoSnp

CompData_UC

UC

CompAck

Figure 5-1 DMT Read transaction example without snoops

The steps in the ReadShared transaction flow in Figure 5-1 are:

1. RN-F sends a ReadShared request to HN-F.

2. HN-F sends a ReadNoSnp request to SN-F.

3. SN-F sends a data response directly to RN-F, using CompData_UC.

4. RN-F sends CompAck to HN-F as the request is ReadShared and requires CompAck to complete the
transaction.

5-256 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.2 Read transaction with DMT and with snoops

For Read transactions with snoops and data from memory, DMT is recommended.

Figure 5-2 shows an example DMT transaction flow using the ReadShared transaction.

From SN-F to HN-F, a response is not required because CompAck from the Requester is used to deallocate the
request at Home.

RN-F0 RN-F1 HN-F SN-F

I I

ReadShared

SnpShared

SnpResp_I

ReadNoSnp

CompData_UC

UC

CompAck

Figure 5-2 DMT Read transaction example with snoops and data from memory

The steps in the ReadShared transaction flow in Figure 5-2 are:

1. RN-F0 sends a ReadShared request to HN-F.

2. HN-F sends a SnpShared request to RN-F1. RN-F1 returns SnpResp_I response to HN-F.

3. HN-F sends a ReadNoSnp request to SN-F after receiving the Snoop response from RN-F1. This guarantees
that RN-F1 has not responded with data.

4. SN-F sends a data response directly to RN-F0, using CompData_UC.

5. RN-F0 sends CompAck to HN-F as the request is ReadShared and requires CompAck to complete the
transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-257
ID092622 Non-Confidential
Interconnect Protocol Flows
5.1 Read transaction flows

5.1.3 Read transaction with DCT

For Read transactions with snoops and data from other Request Node caches, Direct Cache Transfer (DCT) is
recommended.

DCT from cache line in UC state

Figure 5-3 shows an example flow for a DCT transaction. The Requester is RN-F0 and the forwarding cache is at
RN-F1.

RN-F0 RN-F1 HN-F SN-F

I UC

ReadShared
(TxnID = A)

SnpSharedFwd
(FwdNID = RN-F0)
(FwdTxnID = A)
(TxnID = B)

UC->SC
CompData_SC
(HomeNID = HN-F) SnpResp_SC_Fwded_SC
(TxnID = A) (TxnID = B)
(DBID = B)

I->SC
CompAck
(TgtID = HN-F)
(TxnID = B)

Figure 5-3 Direct Cache Transfer from cache line in UD state

The steps in the DCT transaction flow in Figure 5-3 are:

1. RN-F0 sends a ReadShared request to HN-F.

2. HN-F sends a SnpSharedFwd, a Forwarding snoop request to RN-F1.

3. RN-F1 forwards CompData_SC response to RN-F0. The TxnID is the same as the original ReadShared
request.

4. RN-F1 also sends a SnpResp_SC_Fwded_SC snoop response to HN-F. RN-F1 cache line state transitions
from UC to SC.

5. After receiving the CompData_SC response, RN-F0 cache line state transitions from I to SC and RN-F0
sends a CompAck response to HN-F.

5-258 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.1 Read transaction flows

Note
Steps 3 and 4 in the DCT transaction flow can occur in any order as CompData and SnpResp are sent on different
channels.

Double data return in a DCT transaction

Figure 5-4 shows an example DCT transaction flow that sends the data to HN-F and forwards the data to the RN-F0.

RN-F0 RN-F1 HN-F SN-F

I UD

ReadShared
(TxnID = A)

SnpSharedFwd
(FwdNID = RN-F0)
(FwdTxnID = A)
(TxnID = B)

UD->SC

CompData_SC
(HomeNID = HN-F) SnpRespData_SC_PD_Fwded_SC
(TxnID = A) (TxnID = B)
(DBID = B)

I->SC WriteNoSnp
CompAck
(TgtID = HN-F)
(TxnID = B)
CompDBIDResp

NCBWriteData

Figure 5-4 Double data return in DCT transaction

The steps in the DCT transaction flow in Figure 5-4 are:

1. RN-F0 sends a ReadShared request to HN-F.

2. HN-F sends a SnpSharedFwd Snoop request to RN-F1.

3. RN-F1 sends CompData_SC response to RN-F0. The TxnID is the same as the original ReadShared request.
RN-F0 cache line state transitions from I to SC.

4. RN-F1 also sends a SnpRespData_SC_PD_Fwded_SC Snoop response to HN-F that includes a copy of the
cache line and passes responsibility for the Dirty cache line to HN-F. RN-F1 cache line state transitions from
UD to SC.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-259
ID092622 Non-Confidential
Interconnect Protocol Flows
5.1 Read transaction flows

5. HN-F sends a WriteNoSnp request to the SN-F.

6. SN-F responds to the HN-F with CompDBIDResp to request the data.

7. HN-F sends NCBWrData to the SN-F.

8. RN-F0 sends CompAck after it receives the Data response.

5.1.4 Read transaction without DMT or DCT

Figure 5-5 shows an example of the flow without DMT using the ReadNoSnp transaction. In Figure 5-5 the
ReadNoSnp has the ExpCompAck set in the original request.

The request does not generate any snoops and receives the data from a response to a memory read by the HN-F.

RN-F0 RN-F1 HN-F SN-F

I

ReadNoSnp
(ExpCompAck==1)

ReadNoSnp

CompData_I

CompData_I

I->I

CompAck

Figure 5-5 ReadNoSnp transaction flow

The steps in the ReadNoSnp transaction flow in Figure 5-5 are:

1. RN-F0 issues a ReadNoSnp transaction, with ExpCompAck set to 1.
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 CompData_I response to HN-F.
5. HN-F returns the data to RN-F0.
Note
If ExpCompAck had not been asserted in the original ReadNoSnp request, the HN-F could have deallocated
the request at this point.

5-260 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.1 Read transaction flows

6. RN-F0 deallocates the request and sends CompAck towards the HN-F.
7. HN-F receives the CompAck response and deallocates the request.

The copy of data being transferred is marked in bold in Figure 5-5 on page 5-260.

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.

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

ReadUnique

ReadNoSnp

SnpUnique

SnpUnique

UDP->I
SnpRespDataPtl_I_PD SnpResp_I
CompData_I

Merge
data
CompData_UD_PD

I->UD

CompAck

Figure 5-6 ReadUnique with partial data snoop response

The steps in the ReadUnique with partial data snoop response transaction flow in Figure 5-6 are:

1. RN-F0 sends ReadUnique request to HN-F.

2. HN-F sends ReadNoSnp request to SN-F and SnpUnique requests to RN-F1 and RN-F2.

3. RN-F1 transitions the cache line from UDP to I and returns SnpRespDataPtl_I_PD to HN-F. RN-F2 returns
SnpResp_I to the HN-F. Meanwhile, the SN-F returns CompData response to HN-F. HN-F merges the data
returned from the SN-F with the partial data received from the RN-F1.

4. HN-F sends CompData_UD_PD to RN-F0. RN-F0 cache line state transitions from I to UD.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-261
ID092622 Non-Confidential
Interconnect Protocol Flows
5.1 Read transaction flows

5. RN-F0 issues CompAck response to the HN-F to indicate transaction completion.

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.

Figure 5-7 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-7 ReadClean with partial data snoop response

The steps in the ReadClean with partial data snoop response transaction flow in Figure 5-7 are:

1. RN-F0 sends ReadClean request to HN-F.

2. HN-F sends ReadNoSnp request to SN-F and SnpClean requests to RN-F1 and RN-F2. RN-F1 cache line
state transitions from UDP to I.

3. RN-F1 returns SnpRespDataPtl_I_PD and RN-F2 returns SnpResp_I to the HN-F. Meanwhile, the SN-F
returns CompData_I response to HN-F. This merges the data.

4. HN-F sends CompData_UC to RN-F0 and WriteNoSnp to SN-F. RN-F0 cache line state transitions from I to
UC.

5. RN-F0 issues CompAck response to the HN-F to indicate transaction completion.

5-262 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.1 Read transaction flows

6. SN-F issues CompDBIDResp to HN-F.

7. HN-F sends NCBWrData to SN-F.

5.1.7 ReadOnce* and ReadNoSnp with early Home deallocation

Figure 5-8 shows the optimized flow for an unordered ReadOnce request.

RN-F0 RN-F1 HN-F SN-F

I

ReadOnce
(ExpCompAck = 0)
(Order[1:0] = 0b00)

ReadNoSnp
(Order[1:0] = 0b01)

ReadReceipt

CompData_UC

Figure 5-8 DMT optimization for unordered ReadOnce

The steps in the optimized ReadOnce transaction flow in Figure 5-8 are:
1. RN-F0 sends an unordered ReadOnce request to HN-F with Order[1:0] set to 0b00.
2. HN-F sends a DMT ReadNoSnp request to SN-F with the Order[1:0] set to 0b01.
3. SN-F sends ReadReceipt to Home.
4. HN-F deallocates the request after receiving the ReadReceipt response.
5. SN-F sends CompData_UC directly to RN-F0.

Note
Use of a ReadNoSnp transaction from Home to Subordinate, in the case where CompAck is not required, avoids the
need to send a RespSepData response from Home to Requester.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-263
ID092622 Non-Confidential
Interconnect Protocol Flows
5.1 Read transaction flows

5.1.8 ReadNoSnp transaction with DMT and separate Non-data and Data-only response
Figure 5-9 shows an example DMT transaction flow with separate Non-data and Data-only response.

In this example, there is no ordering requirement and RN-F can send CompAck to HN-F to deallocate the request
at Home without waiting for DataSepResp.

RN-F HN-F SN-F

ReadNoSnp
(ExpCompAck = 1)
(Order[1:0] = 0b00)

ReadNoSnpSep

RespSepData

ReadReceipt

CompAck

DataSepResp

Figure 5-9 DMT Read transaction example with separate Non-data and Data-only

The steps in the ReadNoSnp transaction in Figure 5-9 are:

1. RN-F sends an unordered ReadNoSnp request to HN-F.

2. HN-F sends a ReadNoSnpSep request to SN-F.

3. HN-F sends a RespSepData response to RN-F.

4. SN-F sends a ReadReceipt to HN-F.

5. RN-F sends CompAck after receiving RespSepData.

6. SN-F sends DataSepResp to RN-F returning the read data.

5-264 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.1 Read transaction flows

5.1.9 ReadNoSnp transaction with DMT with ordering and separate Non-data and Data-only
Figure 5-10 shows an example DMT transaction flow with ordering and separate Non-data and Data-only.

ReadNoSnp with non-zero Order field in Figure 5-10 requires that:

• Next ordered request can be sent only after receiving of RespSepData.
• RN-F must wait for RespSepData and at least one packet of DataSepResp before sending CompAck.
• HN-F must not send next ordered request to SN-F until it receives CompAck.

RN-F HN-F SN-F

ReadNoSnp
(ExpCompAck = 1)
(Order[1:0] = 0b10)

ReadNoSnpSep
(Order[1:0] = 0b01)
RespSepData

ReadReceipt

DataSepResp

CompAck

Figure 5-10 DMT Read transaction example with ordering and separate Non-data and Data-only
The steps in the Read transaction with ordering and separate Non-data and Data-only in Figure 5-10 are as follows:

1. RN-F sends ReadNoSnp to HN-F, with ExpCompAck set to 1. Order[1:0] is set to 0b10.

2. HN-F sends ReadNoSnpSep to SN-F with Order[1:0] set to 0b01.

3. HN-F returns RespSepData to RN-F.

4. SN-F returns ReadReceipt to HN-F.

5. SN-F sends DataSepResp to RN-F directly.

6. RN-F issues CompAck to HN-F.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-265
ID092622 Non-Confidential
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.

Figure 5-11 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->UD

CompAck

Figure 5-11 MakeUnique without memory update

The steps in the MakeUnique without memory update transaction flow in Figure 5-11 are:

1. RN-F0 sends MakeUnique request to HN-F.

2. HN-F sends SnpMakeInvalid requests to RN-F1 and RN-F2. RN-F1 cache line state transitions from UC to I.

3. RN-F1 and RN-F2 return SnpResp_I to the HN-F.

4. HN-F sends Comp_UC to RN-F0. RN-F0 cache line state transitions from I to UD.

5. RN-F0 issues CompAck response to the HN-F to indicate transaction completion.

5-266 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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.

Figure 5-12 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-12 CleanUnique with memory update

The steps in the CleanUnique with memory update transaction flow in Figure 5-12 are:

1. RN-F0 sends CleanUnique request to HN-F.

2. HN-F sends SnpCleanInvalid requests to RN-F1 and RN-F2. RN-F1 cache line state transitions from SD to I.

3. RN-F1 returns SnpRespData_I_PD to HN-F. HN-F sends WriteNoSnp to SN-F.

4. RN-F2 returns SnpResp_I to the HN-F. HN-F can now send Comp_UC to RN-F0. RN-F0 cache line state
transitions from SC to UC. Meanwhile, SN-F returns CompDBIDResp to HN-F. HN-F then sends
NCBWrData to SN-F.

5. RN-F0 issues CompAck response to the HN-F to indicate transaction completion.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-267
ID092622 Non-Confidential
Interconnect Protocol Flows
5.2 Dataless transaction flows

5.2.3 Persistent CMO with snoop and separate Comp and Persist
In this example of CleanSharedPersistSep transaction flow, the PoP is at the SN-F.

Figure 5-13 shows the transaction flow.

RN-F0 RN-F1 HN-F SN-F

SC SC

CleanSharedPersistSep

SnpCleanShared

SnpResp_SC

CleanSharedPersistSep

Comp_SC

Comp

Persist

Figure 5-13 CleanSharedPersistSep transaction flow

The steps in the CleanSharedPersistSep transaction flow in Figure 5-13 are:

1. RN-F0 sends CleanSharedPersistSep request to HN-F.

2. HN-F sends SnpCleanShared request to RN-F1.

3. RN-F1 sends SnpResp_SC to HN-F.

4. HN-F sends Comp_SC to RN-F0.

5-268 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.2 Dataless transaction flows

5. HN-F sends CleanSharedPersistSep to SN-F after completing the writing back of all snooped Dirty data, if
any.

Note
If any Dirty data had been returned to the HN-F following the snoops, the HN-F would need to complete the
write back of this data to the SN-F first. Only then could the HN-F issue the CleanSharedPersistSep request
to the SN-F.

6. SN-F returns Comp response to HN-F. SN-F directly sends Persist response to RN-F0 to indicate the request
has reached PoP and data from any prior writes to the same location is pushed to PoP.

5.2.4 Evict transaction

Figure 5-14 shows the Evict transaction flow.

Note
The Evict request is a hint. A Comp response can be given by HN-F without updating the Snoop Filter or Snoop
Directory.

RN-F HN-F SN-F

UC

UC->I
Evict

Update
Snoop Filter or
Snoop Directory

Comp_I

Figure 5-14 Evict transaction flow

The steps in the Evict transaction flow in Figure 5-14 are:

1. RN-F0 cache line state transitions from UC to I and sends Evict request to HN-F. HN-F receives and allocates
the request.

2. HN-F returns Comp_I response and deallocates the request. RN-F0 deallocates the request.

Note
The cache state at the Requester must change to Invalid before the Evict message is sent.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-269
ID092622 Non-Confidential
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

Figure 5-15 shows a WriteNoSnp transaction flow.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I I

WriteNoSnp

DBIDResp

WriteNoSnp
NCBWrData

CompDBIDResp

NCBWrData
Comp

NCBWrData = NonCopyBackWrData

Figure 5-15 WriteNoSnp with separate responses from HN to RN

The steps in the WriteNoSnp transaction flow in Figure 5-15 are:

1. RN-F0 issues a WriteNoSnp transaction to HN-F. HN-F receives and allocates the request.
2. HN-F sends DBIDResp without Comp. Meanwhile, HN-F sends WriteNoSnp to SN-F.
3. RN-F0 responds with data, NCWrData. SN-F returns CompDBIDResp to HN-F.
4. HN-F sends a Comp after it receives CompDBIDResp from SN-F. HN-F sends NCBWrData to the 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.

5. RN-F0 waits for Comp from HN-F and deallocates its request.

Figure 5-15 shows the flow, the copy of data being transferred is marked in bold.

5-270 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.3 Write transaction flows

5.3.2 Write transaction with snoop and separate responses

An example of this type of flow is a WriteUniquePtl transaction.

Figure 5-16 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

CompDBIDResp

NCBWrData

NCBWrData = NonCopyBackWriteData

Figure 5-16 WriteUniquePtl with snoop

The steps in the WriteUniquePtl with snoop transaction flow in Figure 5-16 are:

1. RN-F0 sends WriteUniquePtl request to HN-F.

2. HN-F sends SnpCleanInvalid requests to RN-F1 and RN-F2. HN-F also returns DBIDResp to RN-F0. RN-F2
cache line state transitions from UD to I.

3. RN-F1 sends SnpResp_I and RN-F2 sends SnpRespData_I_PD to HN-F.

4. RN-F0 issues NCBWrData to HN-F. HN-F merges the write data with the dirty line and sends WriteNoSnp
to SN-F.

5. HN-F sends Comp response to RN-F0.

6. SN-F returns CompDBIDResp to HN-F.

7. HN-F sends NCBWrData to SN-F.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-271
ID092622 Non-Confidential
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.

Figure 5-17 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-17 WriteBackFull transaction flow

The steps in the WriteBackFull transaction flow in Figure 5-17 are:

1. RN-F0 sends WriteBackFull request to HN-F.

2. HN-F returns CompDBIDResp to RN-F0. RN-F0 cache line state transitions from UD to I.

3. RN-F0 sends CBWrData_UD_PD to HN-F. HN-F sends WriteNoSnp to SN-F.

4. SN-F returns CompDBIDResp to HN-F.

5. HN-F sends NCBWrData to SN-F.

5-272 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.4 Atomic transaction flows

5.4 Atomic transaction flows

This section shows flows for different Atomic transaction types. It contains the following subsections:
• Atomic transactions with data return
• Atomic transaction without data return on page 5-276
• Atomic operation executed at the SN on page 5-278

5.4.1 Atomic transactions with data return

This flow is applicable to:
• AtomicLoad
• AtomicCompare
• AtomicSwap

Atomic transaction with snoops and data return

Figure 5-18 shows the atomic operation executed at HN-F.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I UD

AtomicLoad
AtomicSwap
AtomicCompare
Speculative
Read

SnpUnique
ReadNoSnp
SnpUnique UD->I
DBIDResp
RespData_I
SnpResp_I SnpRespData_I_PD
(InitialData)
NCBWrData
(TxnData)
Executes
Atomic operation

CompData_I WriteNoSnp
(InitialData)

CompDBIDResp

NCBWrData
(NewData)

NCBWrData = NonCopyBackWrData

Figure 5-18 AtomicLoad, AtomicSwap, or AtomicCompare executed at HN-F

The steps in Figure 5-18 are:

1. RN-F0 sends an Atomic transaction to HN-F.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-273
ID092622 Non-Confidential
Interconnect Protocol Flows
5.4 Atomic transaction flows

2. After receiving the Atomic request, HN-F:

• Sends DBIDResp to RN-F0 to obtain the Atomic transaction data.
• Sends SnpUnique Snoop request to other RN-Fs after determining that snoops are required.
• HN-F is permitted, but not required, to send a speculative ReadNoSnp to SN-F.

3. RN-F2 has the cache line in UD state and responds by sending data and invalidating its own cached copy.
• The response is SnpRespData_I_PD.
• This data is marked as (InitialData) in Figure 5-18 on page 5-273 to distinguish it from both the data
sent by the Requester and the data written to SN-F after the atomic operation is executed.
• HN-F also receives a second Snoop response, SnpResp_I, from RN-F1.

4. After receiving all Snoop responses, HN-F sends CompData_I to the Requester.
• The data sent with Comp is the initial copy of the data.
• This data must not be cached in a coherent state at RN-F0.

5. In response to the DBIDResp sent previously, HN-F receives the NonCopyBackWrData_I response from the
Requester.
• This data is marked as (TxnData) in Figure 5-18 on page 5-273 to distinguish it from the data sent by
RN-F2 in response to the Snoop request from HN-F,

6. Once HN-F receives the NonCopyBackWrData_I response from the Requester, and the Snoop response with
data from RN-F2, it executes the atomic operation.
• The resulting value after atomic operation execution, marked as (NewData) in Figure 5-18 on
page 5-273, is written to SN-F.

7. In this example, the read data received due to the speculative read is discarded by HN-F.

Note
In Figure 5-18 on page 5-273, the CompData_I response from HN-F can be sent when all Snoop responses are
received.

Alternatively, to aid error reporting, CompData_I can be delayed until NCBWrData is received from the Requester
and the atomic operation is executed.

5-274 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.4 Atomic transaction flows

Atomic transaction without snoops and with data return

Figure 5-19 shows the atomic operation executed at the Home Node.

RN-F0 RN-F1 RN-F2 HN SN

I I I

AtomicLoad
AtomicSwap
AtomicCompare

ReadNoSnp

RespData_
DBIDResp (InitialData)

NCBWrData
(TxnData)

Executes
Atomic operation

CompData_I
(InitialData) WriteNoSnp

CompDBIDResp

NCBWrData
(NewData)

NCBWrData = NonCopyBackWrData

Figure 5-19 AtomicLoad, AtomicSwap, or AtomicCompare executed at HN

The steps in the Atomic transaction executed at the Home Node transaction flow in Figure 5-19 are:

1. RN-F0 sends Atomic transaction request to HN.

2. HN returns DBIDResp to RN-F0.

3. HN sends ReadNoSnp request to SN. Meanwhile, RN sends NCBWrData (TxnData) to HN.

4. SN returns RespData_I (InitialData) to HN.

5. HN returns CompData_I (InitialData).

6. HN executes the Atomic operation and sends WriteNoSnp request to SN.

7. SN returns CompDBIDResp to HN.

8. HN sends the result of the atomic operation to SN, marked as (NewData).

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-275
ID092622 Non-Confidential
Interconnect Protocol Flows
5.4 Atomic transaction flows

5.4.2 Atomic transaction without data return

This flow is applicable to AtomicStore transactions.

Atomic transaction with snoops and without data return

Figure 5-20 shows the atomic operation executed at HN-F. The flow is similar to the Atomic transaction with snoop
and with data return, except that the Comp response to RN-F0 does not include data.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I UD

AtomicStore

SnpUnique
SnpUnique
DBIDResp
UD->I
SnpRespData_I_PD
SnpResp_I (InitialData)

NCBWrData
(TxnData)
Executes
Atomic operation

WriteNoSnp

Comp

CompDBIDResp

NCBWrData
(NewData)

NCBWrData = NonCopyBackWrData

Figure 5-20 AtomicStore executed at HN-F

The steps in the AtomicStore transaction executed at HN in Figure 5-20 are:

1. RN-F0 sends AtomicStore request to the HN-F.

2. HN-F issues DBIDResp to the Requester, RN-F0, and SnpUnique requests to RN-F1 and RN-F2.

3. RN-F1 returns SnpResp_I response to the HN-F. RN-F2 has the cache line in UD state and returns a
SnpRespData_I_PD (InitialData) response. This invalidates the cached copy in RN-F2.

4. RN-F0 sends the write data (TxnData) to the HN-F. The HN-F executes the AtomicStore operation locally.

5. HN-F issues a WriteNoSnp request to the SN-F.

6. SN-F returns CompDBIDResp to the Home.

7. HN-F sends the result of the atomic operation to the SN-F, marked as (NewData).

5-276 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.4 Atomic transaction flows

Atomic transaction without snoops and without data return

Figure 5-21 shows the atomic operation executed at the Home Node. The flow is similar to the Atomic transaction
without snoop and with data return except that the Comp response to the Request Node does not include data.

RN RN-F1 RN-F2 HN SN
I I UD

AtomicStore

ReadNoSnp
DBIDResp

Comp RespData_I
(InitialData)
NCBWrData
(TxnData)

Executes
Atomic operation

WriteNoSnp

CompDBIDResp

NCBWrData
(NewData)

NCBWrData = NonCopyBackWrData

Figure 5-21 AtomicStore executed at HN

Note
In Figure 5-21, the read from the Subordinate Node is required to obtain the InitialData and is not speculative.

The Comp response from the Home Node can be combined with the DBIDResp response.

The steps in the AtomicStore transaction executed at the HN in Figure 5-21 are:

1. RN sends AtomicStore request to the HN.

2. HN returns DBIDResp response to RN, indicating the RN can send the write data to the HN.

3. HN sends Comp response to RN and sends ReadNoSnp request to the SN.

4. SN returns RespData_I to the HN.

5. Once the HN has the write data from the RN, it can execute the atomic operation and send WriteNoSnp to SN.

6. SN returns CompDBIDResp to the HN.

7. HN sends the result of the atomic operation to the SN, marked as NewData.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-277
ID092622 Non-Confidential
Interconnect Protocol Flows
5.4 Atomic transaction flows

5.4.3 Atomic operation executed at the SN

Figure 5-22 shows an example Atomic transaction flow where the SN-F is executing the atomic operation.

RN-F0 RN-F1 RN-F2 HN-F SN-F

I I UD

AtomicStore
(Normal, Snoopable)

DBIDResp
SnpUnique
SnpUnique
UD->I
SnpRespData_I_PD
(InitialData)

NCBWrData
SnpResp_I
(TxnData)

WriteNoSnp

Comp CompDBIDResp

NCBWrData
(InitialData)

AtomicStore

DBIDResp
NCBWrData
(TxnData)

Comp

NCBWrData = NonCopyBackWrData

Figure 5-22 AtomicStore executed at SN-F

The steps in the AtomicStore transaction executed at SN-F in Figure 5-22 are:

1. RN-F0 sends an AtomicStore transaction to HN-F.

• The Atomic request is to a Snoopable address location.

2. After receiving the Atomic request, HN-F:

• Sends DBIDResp to RN-F0 to obtain the Atomic transaction data.
• Sends a SnpUnique to other RN-Fs after determining that snoops are required.

3. RN-F2 has the cache line in UD state and responds by sending data and invalidating its own cached copy.
• The response is SnpRespData_I_PD.
• This data is marked as (InitialData) in Figure 5-22 to distinguish it from both the data sent by the
Requester and the data written to SN-F to execute the atomic operation.

5-278 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.4 Atomic transaction flows

• HN-F also receives a second Snoop response, SnpResp_I, from the other snooped RN-F.

4. HN-F writes the received data to SN-F using a WriteNoSnp transaction.

5. In response to the DBIDResp sent previously, HN-F receives the NonCopyBackWrData response from the
Requester.

6. HN-F after sending the Snoop response data to SN-F, sends an AtomicStore transaction request to SN-F, and
executes the sequence of messages required to complete the Atomic transaction.

7. The HN-F deallocates the request once the Comp response is sent to the Requester and the Comp response
for the Atomic transaction is received from SN-F.
• The Comp response from HN-F can be sent when all the Snoop responses are received.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-279
ID092622 Non-Confidential
Interconnect Protocol Flows
5.5 Stash transaction flows

5.5 Stash transaction flows

This section shows example interconnect protocol flows for the two Stash transaction types:
• Write with Stash hint
• Independent Stash request on page 5-282

5.5.1 Write with Stash hint

Figure 5-23 shows an example WriteUniqueStash with Data Pull transaction flow.

RN RN-F1 RN-F2 HN-F SN-F

I SC I

WriteUniqueFullStash
(StashNID = RN-F1)

DBIDResp

SnpMakeInvalidStash SnpUnique

SC->I
SnpResp_I

SnpResp_I_Read
NCBWrData

Comp_I

CompData_UD_PD

I -> UD

CompAck

NCBWrData = NonCopyBackWriteData

Figure 5-23 WriteUniqueStash with Data Pull

The steps in Figure 5-23 are:

1. The Request Node sends a WriteUniqueFullStash request to HN-F with the Stash target identified as RN-F1.
Typically, the requesting Request Node is an RN-I.

2. HN-F sends SnpMakeInvalidStash to RN-F1 and SnpUnique to RN-F2.

3. RN-F1 and RN-F2 send SnpResp response to HN-F. The Snoop response from RN-F1 also includes a Read
request, that is, the Data Pull.

5-280 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.5 Stash transaction flows

4. HN-F treats the Read request from RN-F1 as a ReadUnique, and sends a combined CompData to RN-F1.
CompData response includes the data written by the Request Node.

5. RN-F1 sends CompAck to HN-F to complete the Read transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-281
ID092622 Non-Confidential
Interconnect Protocol Flows
5.5 Stash transaction flows

5.5.2 Independent Stash request

Figure 5-24 shows an example StashOnce with Data Pull transaction flow.

RN RN-F1 HN-F SN-F

I

StashOnceShared
(StashNID = RN-F1)

ReadNoSnp
SnpStashShared

SnpResp_I_Read
Comp
CompData_I

CompData_UC

I->UC

CompAck

Figure 5-24 StashOnceShared with Data Pull

The steps in Figure 5-24 are:

1. The Request Node sends a StashOnceShared request to HN-F with the Stash target identified as RN-F1.

2. HN-F sends a Comp response after establishing processing order for the received request that is guaranteeing
the request is processed before a request to the same address received later from any Requester.

3. HN-F sends a SnpStashShared snoop to RN-F1, and a ReadNoSnp request to SN-F to fetch data.

4. RN-F1 sends SnpResp_I_Read response to HN-F.

5. HN-F treats the Read request from RN-F1 as a ReadNotSharedDirty, and sends a combined CompData to
RN-F1.

6. RN-F1 sends CompAck to HN-F to complete the Read transaction.

5-282 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.6 Hazard handling examples

5.6 Hazard handling examples

This section shows how CopyBack-Snoop request hazard conditions are handled at the Requester, and how various
requests to request and request to snoop request hazard conditions are handled at the HN-F. It contains the following
subsections:
• CopyBack-Snoop hazard at RN-F
• Request hazard at HN-F on page 5-286
• Read - CopyBack or Dataless - CopyBack hazard at HN-F on page 5-288
• HN-F race hazard: Request and CompAck on page 5-289

5.6.1 CopyBack-Snoop hazard at RN-F

Figure 5-25 shows a Snoop request to an RN-F hazarding a pending CopyBack request at Time C.

RN-F0 RN-F1 HN-F

UD I
Req1: ReadShared
Req2: WriteBack

SnpShared
UD->SC Hazard detected
C Req2 progress
blocked

SnpRespData_SC_PD
Hazard with
CopyBack detected
but ignored

CompData_SC
I->SC

CompAck

B
SC->I
CompDBIDResp
D
CopyBackWrData_SC Req2 progress
(PS = SC, NS(implied) = I) un-blocked
CopyBack
Completed with a
WriteData response

PS = PresentState
NS = NextState

Figure 5-25 CopyBack-Snoop hazard at RN-F example

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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-283
ID092622 Non-Confidential
Interconnect Protocol Flows
5.6 Hazard handling examples

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.

Note
• The response to a Snoop request that hazards with an outstanding Evict must be SnpResp_I.

• The only response that can be received for a CopyBack request, while a Snoop response to a Snoop request
to the same address is pending, is a RetryAck. This includes data, if applicable.

Figure 5-26 on page 5-285 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.

5-284 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.6 Hazard handling examples

RN-F0 RN-F1 HN-F SN-F

UD 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_PD
(PS=UD,
NS(implied)=I)
CopyBack WrNoSnp
Completed with a
WriteData response

PS = PresentState
NS = NextState

Figure 5-26 CopyBack-Snoop hazard with no cache state change example

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-285
ID092622 Non-Confidential
Interconnect Protocol Flows
5.6 Hazard handling examples

5.6.2 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. The exception for this is when the two requests have an ordering requirement and are from
the same source, then the order of processing must match the order of arrival.

Figure 5-27 shows an example where a ReadShared and a ReadUnique, for the same cache line, arrive at the HN-F
at approximately the same time.

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-27 Read-Read request hazard example

The steps required to resolve this hazard in Figure 5-27 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.

5-286 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.6 Hazard handling examples

• The ReadShared transaction is considered to be complete and the HN-F unblocks the ReadUnique
transaction request from RN-F0.

Except for ReadNoSnp, the flows are similar if the two transactions, that Figure 5-27 on page 5-286 shows, are
replaced by any Read request type, or Dataless request type:

• A Read transaction request without DMT or DCT or separate Comp and data response 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-287
ID092622 Non-Confidential
Interconnect Protocol Flows
5.6 Hazard handling examples

5.6.3 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-286. See also CopyBack-Snoop hazard at RN-F
on page 5-283.

Figure 5-28 shows the case where a ReadShared and a WriteBack, for the same cache line, arrive at the HN-F at
approximately the same time.

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-28 Read - CopyBack or Dataless - CopyBack hazard example

The steps required to resolve this hazard in Figure 5-28 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 must 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.

5-288 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Interconnect Protocol Flows
5.6 Hazard handling examples

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 necessary.

5.6.4 HN-F race hazard: Request and CompAck

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, on arrival at HN-F, the CompAck response deallocates the previous request from the HN-F and
unblocks the processing of the new request.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 5-289
ID092622 Non-Confidential
Interconnect Protocol Flows
5.6 Hazard handling examples

5-290 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-292
• Exclusive monitors on page 6-293
• Exclusive transactions on page 6-296

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-291
ID092622 Non-Confidential
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.

Exclusive accesses are supported to Snoopable and Non-snoopable memory locations.

If the location is updated by a different LP since the Exclusive Load, 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.

Table 6-1 shows the descriptions for Exclusive terms.

Table 6-1 Description of Exclusive terms

Term Description of Exclusive terms

Exclusive Load The action of an LP executing an appropriate program instruction, such as

LDREX, requires:
• Obtaining the data from the location to which it wants to perform an
exclusive sequence.
• Indicating that it is starting an exclusive sequence.

Exclusive Load transaction 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.

Exclusive Store The action of an LP executing an appropriate program instruction, such as

STREX, requires:
• Determining if the exclusive sequence has passed or failed.
• If appropriate, updating the data at the location.
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.

Exclusive Store transaction 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-292 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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 depends on the memory attributes of the address.

The attributes of Exclusive accesses must be such that they are guaranteed to be observed by an exclusive monitor.
For example, if there is a cache between the Requester and monitor, then the Exclusive accesses should be
Non-cacheable.

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, indicated by an Invalidating snoop request to the same
address.
• There is a store to the location by the same LP. If the store from the same LP is Non-exclusive,
resetting the monitor is IMPLEMENTATION DEFINED.

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 the Exclusive Store cannot pass.
The monitor is used to ensure an Exclusive Store transaction from an LP is only successful if the 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 Logical Processors 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, the Exclusive Store
transaction is successful and is permitted to proceed. In such a case, registered attempts of all
other LPs must be reset. It is recommended, but not required, 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, the Exclusive Store transaction is
failed and is not permitted to proceed. The monitor must register that the LP is attempting an
Exclusive sequence.
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. For store transactions in which the LP is not identifiable, the
store must be handled as from a different LP than the one which set the monitor.
From initial system reset, the first LP to perform an Exclusive Store transaction can be
successful. At that point, all other LPs must then register the start of their exclusive sequence
for their Exclusive Store transaction to be successful.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-293
ID092622 Non-Confidential
Exclusive accesses
6.2 Exclusive monitors

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.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 an Exclusive Store transaction from another Logical Processor 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 an 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, address monitors can be used on a first-come first-served basis, or by
allocation to particular Logical Processors. 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 many Exclusive access transactions. It is recommended that Secure Exclusive
accesses are permitted to make forward progress independently of the progress of Non-secure accesses.

6.2.3 Alternatives to a PoC monitor

An HN-F is permitted to use the following mechanisms instead of a PoC monitor to determine the results of an
Exclusive access:

• A precise Snoop Filter, to track if the Requester at the time of Exclusive Store processing retains a copy of
the cache line.

• Snooping by the Home Node, to determine if the Requester still holds a copy of the cache line.

Note
Prior to CHI Issue E, a Home Node that supports Exclusive accesses was required to implement a PoC monitor.

6-294 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Exclusive accesses
6.2 Exclusive monitors

6.2.4 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-295
ID092622 Non-Confidential
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
— ReadNotSharedDirty
— ReadShared
— ReadPreferUnique
• Exclusive Store transaction to a Snoopable location:
— CleanUnique
— MakeReadUnique
• 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, LPID on page 13-426.

6.3.1 Responses to exclusive requests

Transaction responses to exclusive requests are similar to the normal responses to reads and writes with the
following exceptions:

• ReadClean, ReadNotSharedDirty, and ReadShared Exclusive transactions:

— Must not use separate Comp and data response.
— Requests that do not fail must not use either DMT or DCT.

• ReadNoSnp Exclusive transactions that do not fail, must not use DMT.

• WriteNoSnpFull and WriteNoSnpPtl transactions, must not use DWT if the Exclusive monitor is located at
the Home and the Exclusive check passes.

However, the response for the following Exclusive transactions must also indicate if the exclusive request has
passed or failed:
• ReadClean
• ReadNotSharedDirty
• ReadShared
• ReadNoSnp
• CleanUnique
• WriteNoSnpFull
• WriteNoSnpPtl

The RespErr field in the response is used for this purpose. See Response Error, RespErr on page 13-447. 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.

6-296 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Exclusive accesses
6.3 Exclusive transactions

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.

It is IMPLEMENTATION DEFINED whether or not Exclusive Store transaction to a location that does not support
Exclusive accesses will update the location.

It is recommended that an Exclusive Store transaction is not performed to a location that does not support Exclusive
accesses.

ReadPreferUnique and MakeReadUnique do not use RespErr to determine the pass or fail of an Exclusive operation.
An Exclusive MakeReadUnique response with Shared cache state indicates the failure of an Exclusive access. When
the response cache state is Unique, the Requester must use its Local Monitor state to determine if the Exclusive
access is a pass.

Table 6-2 shows the Snoopable attributes of the request, the relevant monitor type and possible reasons for fail
conditions and response requirements.

Table 6-2 Responses to an Exclusive access request

Request type Snoopable Monitor type Fail condition Response

ReadNoSnp(Excl) No System Target does not Target must return

support Exclusive a data response
accesses

WriteNoSnp(Excl) No System Address content The Requester

modified must still complete
the write flow by
Address not sending the Data
present due to message
monitor overflow

Target does not

support Exclusive
accesses

ReadClean(Excl) Yes LP, PoC Target does not Target must return
ReadNotSharedDirty(Excl) support Exclusive a data response
ReadShared(Excl) accesses

ReadPreferUnique Yes LP, Optional PoC None If a PoC monitor is

available, the
appropriate
monitor bit must
be set

CleanUnique(Excl) Yes LP, PoC Address content Target must return

modified a Comp response

Address not
present due to
monitor overflow

Target does not

support Exclusive
accesses

MakeReadUnique(Excl) Yes LP, Optional PoC Address content Target uses PoC
modified monitor, Precise
snoop filter, or
SnpQuery to
determine
response

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-297
ID092622 Non-Confidential
Exclusive accesses
6.3 Exclusive transactions

MakeReadUnique(Excl)
When performing an Exclusive Store operation, MakeReadUnique(Excl) is the preferred alternative over the
CleanUnique(Excl) request.

The permitted responses to the MakeReadUnique(Excl) request are included in Table 4-37 on page 4-227 and
Table 4-38 on page 4-228.

Result of an Exclusive access

The result of an Exclusive access is determined in the following manner:

• RespErr value of Exclusive Okay is not permitted in response to a MakeReadUnique(Excl).

• The Requester must use its local exclusive monitor along with the cache state in the response to determine
the success of an Exclusive Store.
— When the cache state in the response is Shared, the Requester must assume that the Exclusive access
has failed.
— When the cache state in the response is Unique, the Requester must use its own local monitor to
determine the result of the Exclusive access.

Home behavior

If the Home, after checking the PoC monitor, determines the Exclusive Store passes, it must invalidate all other
cached copies of the cache line and then send a Comp response with the cache state of Unique to the Requester. The
cache state can include [_PD] if a cached copy in SD state was invalidated and the responsibility of writing back of
the Dirty data is being passed to the Requester.
To avoid an Exclusive access livelock, the monitor must be capable of simultaneously tracking each individual LP
Exclusive thread in the system.

A Home is permitted to use a precise Snoop Filter to determine the success or failure of an Exclusive access. If the
Snoop Filter indicates that the Requester has lost the cache line, it must be assumed that the Exclusive access has
failed.

In the absence of precise caching information from the Snoop Filter, the Home can use the SnpQuery snoop to
determine the presence and state of the cache line at the Requester.

When a Home determines that an Exclusive Store transaction has failed, the following rules must be followed:

• If the Requester has lost the cache line, the Home is expected to send SnpPreferUniqueFwd or
SnpPreferUnique to get a copy of the cache line. The Home is permitted to send SnpNotSharedDirty(Fwd),
or SnpClean(Fwd), or SnpShared instead. The snoop must not be SnpSharedFwd nor any Invalidating snoop.

• The sender of the data is permitted to return, as appropriate, a UC or UD state in the response to the Requester
if no other cached copies exist.
The Completer must return data with SC state, if other copies exist.
SD state is not permitted in the response to the Requester. This is because the Home cannot determine from
the MakeReadUnique(Excl) request whether the Requester will accept data in SD state.

Data is provided in response to a MakeReadUnique(Excl) transaction when a cache line is lost to a snoop between
the issuing of the MakeReadUnique(Excl) transaction and the point at which the Home actions the transaction or
the Home cannot determine that the data has been retained.

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.

6-298 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Exclusive accesses
6.3 Exclusive transactions

• It is recommended that progress on Secure exclusive requests is independent of progress on Non-secure

Exclusive requests.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-299
ID092622 Non-Confidential
Exclusive accesses
6.3 Exclusive transactions

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, it is permitted, but not recommended, that it performs an
Exclusive Load transaction.

• If the LP holds the cache line in a Shared state, it is permitted, but not required, that it performs an Exclusive
Load transaction.

• If the LP does not hold a copy of the cache line, it is recommended that the LP uses an Exclusive Load
transaction to obtain the cache line. It is permitted to use ReadClean, ReadShared, ReadNotSharedDirty, or
ReadPreferUnique 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.

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.

6-300 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Exclusive accesses
6.3 Exclusive transactions

• If the cache line is held in a Shared state and the LP exclusive monitor is set, the LP must issue an Exclusive
Store transaction. A CleanUnique or MakeReadUnique 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 or MakeReadUnique transaction is in progress.
An Exclusive CleanUnique transaction response is handled in the following way.
The transaction will receive a Normal Okay or an Exclusive Okay response.
If the transaction receives an Exclusive Okay response, 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, 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, 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 Logical Processors 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, 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, the LP can repeat
the Exclusive Store transaction.

For handling of an Exclusive MakeReadUnique at the Home Node see Home behavior on page 6-298.

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. This is 1 byte,
2 bytes, 4 bytes, 8 bytes, 16 bytes, 32 bytes, or 64 bytes.

Failure to observe these restrictions results in behavior that is UNPREDICTABLE.

For Exclusive read and Exclusive 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 bytes, 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 6-301
ID092622 Non-Confidential
Exclusive accesses
6.3 Exclusive transactions

If the Subordinate Node does not support Exclusive accesses, as indicated by an Exclusive Fail on the Exclusive
ReadNoSnp, the write will update the location if the write is given an Exclusive Fail response.

If the Subordinate Node does support Exclusive accesses, as indicated by an Exclusive Pass on the Exclusive
ReadNoSnp, the write will not update the location if the write is given an Exclusive Fail response.

6-302 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 7
Cache Stashing

This chapter describes the cache stashing mechanism whereby data that is written from a Request Node can be
installed in a peer cache. It contains the following sections:
• Overview on page 7-304
• Write with Stash hint on page 7-306
• Independent Stash request on page 7-307
• Stash target identifiers on page 7-309
• Stash messages on page 7-310

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 7-303
ID092622 Non-Confidential
Cache Stashing
7.1 Overview

7.1 Overview
Cache stashing is a mechanism to install data within particular caches in a system. Cache stashing ensures that data
is located close to its point of use, improving the system performance.

Cache stashing is permitted to Snoopable memory only.

This specification supports two main forms of cache stashing transaction:

WriteUniqueStash
Write with stash hint. This is used when the cache in which the data should be allocated is known
at the point in time that the data is written. A write with stash hint can be a [Full] or [Ptl] cache line
write, and this will affect the Snoop transactions that are used. See Write with Stash hint on
page 7-306.

StashOnce
Independent stash request. This is used when the request to stash data into a particular cache is
separated from the writing of the data. An independent Stash transaction can indicate if the cache
line should be held in a Unique or Shared state by using a StashOnceUnique or
StashOnceSepUnique, or a StashOnceShared or StashOnceSepShared transaction respectively,
which corresponds to whether the next expected use of the cache line is for storing or for reading.
See Independent Stash request on page 7-307.

Both forms of cache stashing can target installation of data at different cache levels. The Stash target cache can be
a peer cache, specified by using the peer cache target NodeID, or an LP cache within the peer node, if the peer node
has multiple logical processors. The LP is identified by the LPID in the target cache field. See Stash target identifiers
on page 7-309.
The Cache stashing requests can also target the cache below the peer cache in the cache hierarchy, which can be an
interconnect cache or a system cache. This is done by not specifying the peer cache NodeID. See Stash target not
specified on page 7-309.

In all cases of cache stashing, the Stashing is only a performance hint and it is permitted for the Stash request
receiver to not perform the stashing behavior.

7.1.1 Snoop requests and Data Pull

The following Snoop requests are used to notify a peer cache that it is the target of a Stash request:
• SnpUniqueStash
• SnpMakeInvalidStash
• SnpStashUnique
• SnpStashShared

Table 7-1 shows the Snoop requests associated with each of the Stash requests.

Table 7-1 Stash request and the corresponding Snoop request

Stash request Snoop request

WriteUniquePtlStash SnpUniqueStash

WriteUniqueFullStash SnpMakeInvalidStash

StashOnceUnique SnpStashUnique
StashOnceSepUnique

StashOnceShared SnpStashShared
StashOnceSepShared

7-304 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Cache Stashing
7.1 Overview

A Snoopee that receives a Stash Snoop request does one of the following:

• Provides a Snoop response that also acts as a Read request for the associated cache line. Including a Read
request with Snoop response is referred to as a Data Pull. Table 7-2 shows the type of Read request that is
implied by a Data Pull in the response to each Stash Snoop request.

Table 7-2 Snoop response with Data Pull and implied Read request

Snoop request Implied Read request

SnpUniqueStash ReadUnique

SnpMakeInvalidStash ReadUnique

SnpStashUnique ReadUnique

SnpStashShared ReadNotSharedDirty

• Provides a Snoop response without a Data Pull response so ignoring the cache stash hint.

The value of the DataPull field in the SnpResp and SnpRespData responses indicates if DataPull is requested. See
Data Pull, DataPull on page 13-441 for legal values for DataPull.

The use of DataPull to complete a Snoop request with Stash is optional.

If the Snoopee is not able to support the DataPull transaction flow, it is permitted to ignore the stash operation.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 7-305
ID092622 Non-Confidential
Cache Stashing
7.2 Write with Stash hint

7.2 Write with Stash hint

The rules for sending and processing a WriteUniqueFullStash and WriteUniquePtlStash request at the Stash
requester, the Home, and the Stash target node are as follows:

Requester responsibilities:

• Sends a WriteUniqueFullStash or WriteUniquePtlStash request depending on whether a full cache line or a

partial cache line is to be written.

• The request is expected to include a Stash target.

Home responsibilities:

• Permitted to send a RetryAck response to a WriteUniqueStash request and follow the Retry transaction flow.

• Sends SnpUniqueStash to the identified Stash target.

• Sends SnpUnique to all other Requesters that share the cache line.

• Permitted to send SnpMakeInvalidStash and SnpMakeInvalid instead of SnpUniqueStash and SnpUnique

respectively for WriteUniqueFullStash.

• Send Comp to the Requester after the coherency action is completed.

• Permitted to ignore the stash hint in the Write request and process the request as a regular WriteUnique.

• Handles a request without a Stash target in the manner described in Stash target not specified on page 7-309.

• Permitted to use DMT to get data from SN-F to the Stash target in response to a Data Pull request, when the
data is neither available at Home nor obtained from any caches.

• Permitted to use separate Non-data and Data-only response to the Stash target in response to a Data Pull
request.

The Stash target responsibilities:

• The responses that include Data Pull are:

— SnpResp_I_Read
— SnpRespData_I_Read
— SnpRespData_I_PD_Read
— SnpRespDataPtl_I_PD_Read

• Must not request Data Pull if:

— Snoop has an address hazard with an outstanding request.
— The Stash target has an outstanding request to the same address that has received a DBIDRespOrd but
has not completed.

• When requesting Data Pull:

— The Stash target must guarantee the Read data is accepted without any structural or protocol
dependencies that might result in deadlock.
— The Read request is treated by Home as ReadUnique.
— The Stash target must populate the DBID field in the response with the TxnID that is to be used by
Home for the Read transaction. If the Snoop response with DataPull includes data, the DBID field
value in all data packets must be the same.

• Permitted to ignore the Stash hint and handle the snoop as SnpUnique.

7-306 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Cache Stashing
7.3 Independent Stash request

7.3 Independent Stash request

The second mechanism for implementing cache stashing is to permit the Stash request to be sent separated in time
from the writing of Stash data. Examples of when such a mechanism is useful are:

• When the data that is being written is not required by the target immediately. This delayed Stash avoids
polluting the cache with data that is not used immediately.

• When the data is already in the system and the data has to be prefetched into caches.

• When the process using the data being written is not scheduled when the data is written, and therefore the
precise target of the Stash data is not known until later.

In these cases, a Requester can use StashOnce or StashOnceSep requests to request Home or a peer node to fetch a
cache line.

The rules for sending and processing an independent Stash request at the Stash requester, Home, and the Stash target
are as follows:

Requester Node responsibilities:

• Sends StashOnceUnique or StashOnceSepUnique to Home if the stashed cache line is to be modified.

• Sends StashOnceShared or StashOnceSepShared to Home if the stashed cache line is not to be modified.

• Sends StashOnceSep only if the Requester is capable of handling the StashDone response.

• The StashOnce and StashOnceSep requests provide a Stash target when the data is to be stashed in a peer
cache.

• The StashOnce and StashOnceSep requests do not provide a Stash target when the data is to be allocated in
the next level cache.

• The Requester, upon receiving the Comp response, is permitted to release some request resources, while
keeping track of the number of outstanding StashDone responses. This count of the number of outstanding
StashDone responses can be done per Stash group, using the Requester defined Stash Group ID, specified by
the StashGroupID field value.

Home Node responsibilities:

• Permitted to send a RetryAck response to a Stash request and follow the Retry transaction flow.

• Send a SnpStashUnique to the target RN-F for StashOnceUnique and StashOnceSepUnique.

• Send a SnpStashShared to the target RN-F for StashOnceShared and StashOnceSepShared.

• Permitted to not send a Snoop request in response to a Stash request.

• Must send a Comp response, even if it abandons the Stash request.

• For the StashOnce, the Home must send a Comp only after establishing processing order for the received
request that is guaranteeing that any request to the same address received later from any Requester is ordered
behind this request. The Comp response must come from the PoC.

• For the StashOnceSep request, the Home must send a Comp only after establishing the guarantee that it will
not send a RetryAck response. The StashDone response must only be sent after establishing the guarantee
that the request is ordered at the Home.

• Fetches the addressed cache line from memory into the shared system cache when a Stash request without a
Stash target is received.

• Permitted to send Comp after receiving the Stash request, and before sending any SnpStash* or receiving the
Snoop response.

• Send Comp with a Non-Invalid state, if the cache line is cached in the cache at the next level.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 7-307
ID092622 Non-Confidential
Cache Stashing
7.3 Independent Stash request

Send Comp_I if the cache line is not cached, or it is not known if the cache line is cached, in the cache at the
next level.

• Send a Comp_I response if either the cache look up at Home is a miss or Home did not look up the cache
before responding.

• Permitted to use DMT to get data from SN-F to the Stash target in response to a Data Pull request.

• Permitted to use separate Non-data and Data-only response to the Stash target in response to a Data Pull
request.

Stash target responsibilities:

• The snoop must not change the state of the cache line at the Stash target.

• The snoop is treated as a hint at the Stash target to obtain a copy of the cache line.

• Must not request DataPull if:

— Snoop has an address hazard with an outstanding request.
— Response is sent before performing a local cache lookup.
— The snoop is SnpStashShared and the cache has a copy of the cache line.
— The Stash target has an outstanding request to the same address that has received a DBIDRespOrd but
not yet completed.

• When requesting DataPull:

— The Stash target must guarantee the Read data is accepted without any structural or protocol
dependencies that might result in deadlock.
— The DataPull request is treated by Home as ReadNotSharedDirty for SnpOnceShared.
— The DataPull request is treated by Home as ReadUnique for SnpOnceUnique.
— The Home must treat the Stash request and the DataPull request atomically as a single request. That
is, the Home must not order any other request to the same address between the Stash request and the
corresponding DataPull request.
— The Stash target must populate the DBID field in the response with the TxnID that is to be used by
Home for the Read transaction.

• A DataPull request can be sent, but is not required to be sent, when the snoop is SnpStashUnique and a shared
copy is present.

• The Stash target is permitted, but not required, to wait until it completes the local cache lookup before sending
the Snoop response.

• The cache state in the Snoop response is not required to be precise:

— An imprecise response must be SnpResp_I.
— Any state other than I in the response must be precise.

Note
• For StashOnce, care is needed to avoid any action that could result in the deallocation of the cache line from
the cache where it is expected to be used.

• A StashOnceUnique transaction can cause the invalidation of a copy of the cache line and care must be taken
to ensure such transactions do not interfere with Exclusive access sequences.

The requirements regarding the sending of Stash type snoops from a Home, and the permitted responses by the
target, are the same as the request/response rules for StashOnceSep transactions. See Stash transactions on
page 2-76.

7-308 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Cache Stashing
7.4 Stash target identifiers

7.4 Stash target identifiers

For all Stash requests, both options of specified and non-specified Stash target are supported.

7.4.1 Stash target specified

If the Stash target is available in the Stash request then Home sends the snoop with a stash hint to the specified target.
The specified target can be a Request Node or an LP within a Request Node.

7.4.2 Stash target not specified

The Home Node that receives a WriteUniquePtlStash or WriteUniqueFullStash request without a Stash target does
the following:

• If the cache line is cached in a Unique state at a Request Node, the Home can treat that Request Node as the
Stash target.

• If the cache line is not cached in a Unique state, the Home must only send SnpUnique as required, and must
not send SnpUniqueStash to any Request Node.

• For WriteUniquePtlStash, if the cache line is not in any cache, it is recommended that he Home prefetches
and allocates the cache line in the system cache. It is permitted, but not recommended, to perform a partial
write to main memory.

• For WriteUniqueFullStash, if the cache line is not in any cache then Home is permitted to allocate the cache
line in the shared system cache.

The Home Node that receives a StashOnce or StashOnceSep request without a Stash target does the following:

• If the cache line is not cached in any peer cache, it is recommended that the cache line is allocated in the
shared system cache.

• If the cache line is cached in a peer cache, it is IMPLEMENTATION DEFINED if a snoop is sent to transfer a copy
of the cache line and allocate it in the shared system cache. For StashOnceUnique and StashOnceSepUnique,
it is also IMPLEMENTATION DEFINED if all cached copies are invalidated before allocating the cache line in the
shared system cache.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 7-309
ID092622 Non-Confidential
Cache Stashing
7.5 Stash messages

7.5 Stash messages

Stash messages are classified as:
• Write requests:
— WriteUniqueFullStash
— WriteUniquePtlStash
See Write transactions on page 4-187.
• Dataless requests:
— StashOnceUnique
— StashOnceSepUnique
— StashOnceShared
— StashOnceSepShared
See Dataless transactions on page 4-180.
• Snoop requests:
— SnpUniqueStash
— SnpMakeInvalidStash
— SnpStashUnique
— SnpStashShared
See Snoop request types on page 4-201.
• Stash responses:
— Comp
— StashDone
— CompStashDone
See Stash transactions on page 2-76.

7.5.1 Supporting REQ packet fields

The fields defined in the REQ packet to support Stash requests are:
• StashNID, StashLPID
• StashNIDValid, StashLPIDValid

Table 7-3 shows the valid StashNIDValid and StashLPIDValid encodings.

Table 7-3 Valid StashNIDValid and StashLPIDValid encodings

StashNIDValid StashLPIDValid Comments

0 0 Stash target is not specified

0 1 Reserved

1 0 Only a target RN is specified

1 1 Both target RN and LPID are specified

See Protocol flit fields on page 13-424.

7.5.2 Supporting SNP packet fields

The fields defined in the SNP packet to support Stash requests are:
• StashLPID
• StashLPIDValid

See Protocol flit fields on page 13-424.

7-310 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Cache Stashing
7.5 Stash messages

7.5.3 Supporting RSP packet field

The field defined in the RSP packet to support Stash requests is DataPull.

See Protocol flit fields on page 13-424.

7.5.4 Supporting DAT packet fields

The field defined in the DAT packet to support Stash requests is DataPull.

See Protocol flit fields on page 13-424.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 7-311
ID092622 Non-Confidential
Cache Stashing
7.5 Stash messages

7-312 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-314
• DVM Operation types on page 8-323
• DVM Operations on page 8-330

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-313
ID092622 Non-Confidential
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 DVM transaction requirements:
• Non-sync type DVM transaction flow
• Sync type DVM transaction flow on page 8-315
• Flow control on page 8-317
• DVMOp field value restrictions on page 8-318
• Field value requirements on page 8-322

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-314 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.1 DVM transaction flow

The required steps that Figure 8-1 on page 8-314 shows are:

1. RN-F0 sends a DVMOp(Non-sync) to the Miscellaneous Node using the appropriate write semantics for the
DVMOp type.

2. The Miscellaneous Node 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.

Note
• Both parts of the message must carry the same Transaction ID (TxnID).
• The Request Node must have resources available to accept the SnpDVMOp. See Flow control on
page 8-317.

5. After completing the required actions, each recipient of the SnpDVMOp sends a single SnpResp response to
the Miscellaneous Node.

Note
Sending of a SnpResp implies that the target Request Node has forwarded the SnpDVMOp to the required
Request Node 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.

6. After receiving all the SnpResp responses, the Miscellaneous Node sends a Comp response to the requesting
node.

DVM early Comp for Non-sync DVMOps

The Miscellaneous Node in the interconnect is permitted to send Comp for a Non-sync DVMOp without waiting to
complete the required snooping of Request Nodes. Such a Miscellaneous Node must take the responsibility of
ordering this Non-sync DVMOp against any Sync DVMOp received later from the same source. If a Miscellaneous
Node cannot provide such an ordering guarantee, then it must wait for the snooping to be completed before sending
a Comp response for a Non-sync DVMOp.

A Miscellaneous Node that is enabled to send early Comp for a Non-sync DVMOp is permitted to opportunistically
combine Comp and DBIDResp responses into a single CompDBIDResp response.

Note
• Sending of a Comp response early for Non-sync DVMOp reduces round-trip latency for DVMOp
completion. This enables a greater number of DVMOp transactions to be pipelined from a single source.

• Such an early completion also enables a Sync DVMOp, which is waiting for completions of all related
DVMOp transactions sent earlier from the same Request Node.

The Miscellaneous Node must still wait for the Snoop response for a Sync DVMOp to be received before sending
a Comp to the Requester for that Sync DVMOp.

8.1.2 Sync type DVM transaction flow

Figure 8-2 on page 8-316 shows the flow in a Sync DVM transaction.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-315
ID092622 Non-Confidential
DVM Operations
8.1 DVM transaction flow

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 DVM transaction flow

8-316 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.1 DVM transaction flow

The required steps that Figure 8-2 on page 8-316 shows are:

1. RN-F0 sends a DVMOp(Sync) to the Miscellaneous Node.

Note
All previous DVMOp requests whose completion needs to be guaranteed by the DVMOp(Sync) must have
received a Comp response before the Request Node can send a DVMOp(Sync).

2. The Miscellaneous Node accepts the DVMOp(Sync) request and sends a DBIDResp response to the
Requester.

3. The RN-F0 sends a data packet on the data channel with a data size of 8 bytes.

4. The Miscellaneous Node 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.

5. After completing the DVM Sync operation, RN-F1 sends a SnpResp response to the Miscellaneous Node.

Note
Sending of a SnpResp implies that all DVM-related operations have completed at the Request Node
structures and the target Request Node has freed up the resources needed to accept another SnpDVMOp.

6. After receiving the SnpResp, the Miscellaneous Node sends a Comp response to RN-F0.

8.1.3 Flow control

DVMOp request flow control:

• A DVMOp can receive a RetryAck response from a Miscellaneous Node.

• A DVMOp that receives a RetryAck response must wait for a PCrdGrant response from the Miscellaneous
Node 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 Request Node can send the DVMOp(Sync).

• The interconnect must guarantee forward progress on DVMOp(Non-Sync), which requires that there should
be at least one tracker entry in the Miscellaneous Node reserved for DVMOp(Non-Sync).

• It is permitted to overlap a DVMOp(Non-sync) and a DVMOp(Sync), from the same Request Node, 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 a Miscellaneous Node.

• Only one SnpDVMOp(Sync) transaction can be outstanding from a Miscellaneous Node to a Request Node.

• To prevent deadlocks, due to the two part SnpDVMOp requests that use the Snoop channel, a SnpDVMOp
transaction must only be sent when the receiving Request Node has pre-allocated resources to accept both
parts of the SnpDVMOp transaction.

• A Sync DVM operation at a Request Node that has issued a StashOnceSep request must wait until all
outstanding StashDone responses are received for StashOnceSep requests that use invalidated page entries.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-317
ID092622 Non-Confidential
DVM Operations
8.1 DVM transaction flow

• A Request Node must provide a response to a SnpDVMOp transaction only after it has received both
SnpDVMOp request packets corresponding to that transaction.

• A Request Node must provide a response to a SnpDVMOp only when it can accept a further SnpDVMOp
from a Miscellaneous Node.

• When responding to a SnpDVMOp(Sync), a Request Node can depend on the forward progress of any
transaction, except for the completion of an outstanding DVMOp(Sync) request.

• Each RN-F and RN-D in the system specifies the number of SnpDVMOp transactions it can accept
concurrently.

• 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 Request Nodes that do not specify a number.

8.1.4 DVMOp field value restrictions

Field value restrictions during a DVMOp transaction are shown:
• Request messages in Table 8-1
• Data messages in Table 8-2 on page 8-319
• Snoop messages in Table 8-3 on page 8-320
• Response messages:
— DBIDResp, Comp, and SnpResp in Table 8-4 on page 8-322

Table 8-1 shows the Request message field value restrictions for a DVMOp transaction.

Table 8-1 Request message field value restrictions for DVMOp

Field Name Restriction

QoS None. Can take any value.

TgtID Expected to be node ID of Miscellaneous Node. 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.

ReturnNID Must be all zeros.

StashNID
SLCRepHint

StashNIDValid Must be zero.

Endian
Deep

ReturnTxnID Must be all zeros.

StashLPIDValid
StashLPID

Opcode Must be DVMOp.

Size Must be 8-byte.

8-318 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.1 DVM transaction flow

Table 8-1 Request message field value restrictions for DVMOp (continued)

Field Name Restriction

Addr Req_Addr_Width.
See DVM Operations on page 8-330

NS Must be zero.

LikelyShared Must be zero.

AllowRetry Can take any value, because a DVMOp can be given a

Retry.

Order Must be all zeros

PCrdType Must be all zeros if AllowRetry is asserted, otherwise the

Credit type value.

MemAttr Must be all zeros.

SnpAttr None. Can take any value. See DVM domain on

page 8-329.

LPID None. Can take any value.

Excl Must be zero.

SnoopMe

ExpCompAck Must be zero.

TagOp Must be zero.

TraceTag None.

MPAM Must be all zeros.

RSVDC None. Can take any value.

Table 8-2 shows the Data message field value restrictions for a DVMOp transaction.

Table 8-2 Data message field value restrictions for DVMOp

Field Name Restriction

QoS None. Can take 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.

HomeNID Must be all zeros.

Opcode Must be NonCopyBackWriteData.

RespErr Must be 0b00 or 0b10.

Resp Must be all zeros.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-319
ID092622 Non-Confidential
DVM Operations
8.1 DVM transaction flow

Table 8-2 Data message field value restrictions for DVMOp (continued)

Field Name Restriction

FwdState Must be all zeros.

DataPull
DataSource

CBusy Must be all zeros.

DBID None. Can take any value.

CCID Must be all zeros.

DataID Must be all zeros.

TagOp Must be all zeros.

Tag Must be zero.

TU Must be zero.

TraceTag None.

RSVDC None.

BE Only BE[7:0] must be asserted.

Data Unused bits must be zero for Data[63:0] and

Data[n:64] = Can take any value.

DataCheck Must be the appropriate value for the Data field.

Poison None. Can take any value.

Table 8-3 shows the Snoop message field (SnpDVMOp) value restrictions during a DVMOp transaction.

Table 8-3 Snoop message field value restrictions for DVMOp

Field Name Restriction

QoS None. Can take any value.

SrcID Must be node ID of MN.

TxnID An ID generated by MN.

FwdNID None. Used as Range and Num[4:0] fields. See Table 8-7
on page 8-328

VMIDExt Must be used for VMID[15:8] in Part 1 of the SnpDVMOp

request.
None, can take any value in Part 2 of the SnpDVMOp
request.

Opcode Must be SnpDVMOp.

Addr (Req_Addr_Width - 3).

See DVM Operations on page 8-330.

NS Must be zero.

DoNotGoToSD Must be zero.

8-320 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.1 DVM transaction flow

Table 8-3 Snoop message field value restrictions for DVMOp (continued)

Field Name Restriction

RetToSrc Must be zero.

TraceTag None.

MPAM Must be all zeros.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-321
ID092622 Non-Confidential
DVM Operations
8.1 DVM transaction flow

Table 8-4 shows the Response DBIDResp, SnpResp, and Comp and CompDBIDResp message field value
restrictions during a DVMOp transaction.

Table 8-4 Restrictions for response message field values during DVMOp

Response messages

Comp and
Field DBIDResp SnpResp
CompDBIDResp

QoS None. Can take any None. Can take any None. Can take any
value value value

TgtID Must be ID of the Must be ID of the Must be the ID of the

original Requester original Requester MN that is handling
DVMOps

SrcID Must be ID of the MN Must be ID of the MN Must be the node ID

that is handling that is handling that is responding to
DVMOps DVMOps snoops

TxnID Must match TxnID of Must match TxnID of Must match the TxnID
the original request the original request of the SnpDVMOp
snoop request

Opcode Must be DBIDResp Must be Comp or Must be SnpResp

CompDBIDResp

RespErr Must be all zeros Must be 0b00, 0b10, or Must be all zeros
0b11

Resp Must be all zeros Must be all zeros Must be all zeros

FwdState Must be all zeros Must be all zeros Must be all zeros
DataPull

CBusy Expected to be Expected to be Expected to be

populated by the populated by the populated by the
Completer Completer Completer

DBID Generated by the MN Generated by the MN None. Can take any

TagGroupID that is handling that is handling value
StashGroupID DVMOps DVMOps
PGroupID

PCrdType Must be all zeros Must be all zeros Must be all zeros

TagOp Must be all zeros Must be all zeros Must be all zeros

TraceTag None None None

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

8-322 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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 Request Node to the Miscellaneous Node is distributed within:
• The address field in the DVM request from the Request Node.
• The lower 8 bytes of write data in the NonCopyBackWrData packet.

The payload of a DVM operation from the Miscellaneous Node to the Request Node 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-5.

Table 8-5 DVMOp fields and encodings

Field Bits Function

VA Valid 1 0b1 indicates that the specified address is valid.

VI Valid 2 Virtual Index (VI) Valid. Used as part of PICI operations.

0b00 VI not valid.
0b01 Reserved.
0b10 Reserved.
0b11 VI is valid.

VMID Valid 1 0b1 indicates that the Virtual Machine IDentifier (VMID) is valid.

ASID Valid 1 0b1 indicates that the Address Space IDentifier (ASID) is valid.

Security 2 Indicates that the transaction applies to:

0b00 Secure and Non-secure
0b01 Non-secure address from a Secure context
0b10 Secure and Non-secure if DVMOp type is PICI and invalidation is all.
Secure in all other cases.
Note
This update applies retrospectively to all prior issues of this specification.

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

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-323
ID092622 Non-Confidential
DVM Operations
8.2 DVM Operation types

Table 8-5 DVMOp fields and encodings (continued)

Field Bits Function

DVMOp type 3 Indicates the DVM operation type as:

0b000 TLB Invalidate (TLBI)
0b001 Branch Predictor Invalidate (BPI)
0b010 Physical Instruction Cache Invalidate (PICI)
0b011 Virtual Instruction Cache Invalidate (VICI)
0b100 Synchronization
0b101-0b111 Reserved

VMID 8 Virtual Machine ID VMID[7:0]

ASID 16 Address Space ID

Staged Invalidation 2 Indicates Stage 2 or Stage 1 invalidation:

0b00 • DVMv7: Any transaction.
• DVMv8: Both Stage 1 and Stage 2 invalidation.
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.

Rangeb 1 Range can take any value. When:

Range = 1 The transaction is a range-based TLBI operation.
Range = 0 The transaction is a non-range based TLBI operation.
Range is inapplicable and must be zero for non-TLBI DVM transactions.

Numb 5 Used as a constant multiplication factor in the range calculation. All binary values are valid.

Scaleb 2 Used as a constant in address range exponent calculation. All binary values are valid.

TTLb 2 Hint of Translation Table Level (TTL) which includes the addresses to be invalidated:
0b00 The leaf level for the entries to invalidate can be any level of the walk.
0b01 The leaf level for the entries to invalidate is level 1.
0b10 The leaf level for the entries to invalidate is level 2.
0b11 The leaf level for the entries to invalidate is level 3.

TGb 2 Translation Granule (TG) size takes the following values:

0b00 When Range = 0: No level hint is provided. TTL is Reserved.
When Range = 1: Reserved.
0b01 4K
0b10 16K
0b11 64K

BaseAddr or 37 Range base address

VA or 49-53 Virtual address
PA 44-52 Physical address

VI 16 Virtual index

VMIDExt 8 Virtual Machine ID VMID[15:8]

a. DVMv8 only.
b. Inapplicable and must be set to zero in non-TLBI DVM Operations. See Range-based TLBI payload on page 8-326 and Level Hint in TLBI
Operations on page 8-328 for details of how these fields are used in TLBI operations.

8-324 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.2 DVM Operation types

8.2.2 DVMOp and SnpDVMOp packet

Table 8-6 shows the distribution of the payload in the DVMOp request from the Request Node, using 8-byte write
semantics, and the distribution of the payload in the SnpDVMOp requests from the Miscellaneous Node.

In the DVMOp, the combination of the address field in the request and the 8-byte write data transports the complete
payload. REQ.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.
SNP.Addr[0] is used in a SnpDVMOp request to indicate which part of the payload is being transported.
The valid combinations of Maximum PA (MPA) and Maximum VA (MVA) address bits are:
• MPA = 44 : MVA = 49
• MPA = 45 : MVA = 51
• MPA = 46 to 52 : MVA = 53

See Range-based TLBI payload on page 8-326 and Level Hint in TLBI Operations on page 8-328.

Table 8-6 DVMOp and SnpDVMOp request payloads

X in DVMOp Request X in SnpDVMOp Request

Num bits

Num bits
REQ.Addr[x]
Request Data SNP.Addr[x] Part 1 Part 2
DAT.Data[x]

2:0 3 - Num[2:0]a 0 1 0 1

3 1 0 Num[3]a

4 1 VA Valid Scale[0] 1 1 VA Valid Scale[0]

PA[6] PA[6]
VA[6] VA[6]

5 1 VMID Valid Scale[1] 2 1 VMID Valid Scale[1]

VI Valid[0] PA[7] VI Valid[0] PA[7]
VA[7] VA[7]

6 1 ASID Valid TTL[0] 3 1 ASID Valid TTL[0]

VI Valid[1] PA[8] VI Valid[1] PA[8]
VA[8] VA[8]

7 1 Security[0] TTL[1] 4 1 Security[0] TTL[1]

PA[9] PA[9]
VA[9] VA[9]

8 1 Security [1] TG[0] 5 1 Security [1] TG[0]

PA[10] PA[10]
VA[10] VA[10]

9 1 Exception Level [0] TG[1] 6 1 Exception Level [0] TG[1]

PA[11] PA[11]
VA[11] VA[11]

10 1 Exception Level [1] VA[12] 7 1 Exception Level [1] VA[12]

PA[12] PA[12]

13:11 3 DVMOp type[2:0] VA[15:13] 10:8 3 DVMOp type[2:0] VA[15:13]

PA[15:13] PA[15:13]

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-325
ID092622 Non-Confidential
DVM Operations
8.2 DVM Operation types

Table 8-6 DVMOp and SnpDVMOp request payloads (continued)

X in DVMOp Request X in SnpDVMOp Request

Num bits

Num bits
REQ.Addr[x]
Request Data SNP.Addr[x] Part 1 Part 2
DAT.Data[x]

21:14 8 VMID[7:0] VA[23:16] 18:11 8 VMID[7:0] VA[23:16]

VI[27:20] PA[23:16] VI[27:20] PA[23:16]

37:22 16 ASID[15:0] VA[39:24] 34:19 16 ASID[15:0] VA[39:24]

VI[19:12]b PA[39:24] VI[19:12]b PA[39:24]

39:38 2 Staged Invalidation VA[41:40] 36:35 2 Staged Invalidation VA[41:40]

PA[41:40] PA[41:40]

40 1 Leaf Entry Invalidation VA[42] 37 1 Leaf Entry VA[42]

PA[42] Invalidation PA[42]

41 1 Rangec VA[43] 38 1 VA[46] VA[43]

PA[43] PA[43]

42 1 Num[4]a VA[44] 39 1 VA[47] VA[44]

PA[44] PA[44]

43 1 - VA[45] 40 1 VA[48] VA[45]

PA[45] PA[45]

44 1 - VA[46] 41 1 VA[50] VA[49]

PA[46] PA[46]

45 1 - VA[47] 42 1 VA[52] VA[51]

PA[47] PA[47]

48:46 3 - VA[50:48] 45:43 3 - PA[50:48]

PA[50:48]

49 1 - VA[51] 46 1 - PA[51]
PA[51]

50 1 - VA[52] 47 1 - -

55:51 5 - - 48 1 - -

63:56 8 - VMID[15:8]d

a. For part two of a SnpDVMOp request, Num[4:0] from the corresponding DVMOp request is carried on the FwdNID field of the Snoop flit
alongside the Addr field. See Table 8-7 on page 8-328.
b. When used as Virtual Index (VI), REQ.Addr[37:30], DAT.Data[37:30], and SNP.Addr[34:27] can take any value.
c. For part one of a SnpDVMOp request, Range from the corresponding DVMOp request is carried on the FwdNID field of the Snoop flit
alongside the Addr field. See Table 8-7 on page 8-328.
d. For part one of a SnpDVMOp request, VMID[15:8] from the corresponding DVMOp request is carried on the VMIDExt field of the Snoop
flit alongside the Addr field. See Table 13-8 on page 13-421.

Range-based TLBI payload

Range-based TLBI operations include range-specific payload in addition to the payload fields in non-range-based
TLBI operation. These additional range-based payload fields are applicable in both TLBI operation by VA and IPA.

8-326 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.2 DVM Operation types

Note
Prior to CHI Issue E, range-based TLBI operations are not defined.

The range-based fields are Range, BaseAddr, TG, TTL, Scale, and Num. These definitions of the fields and how
they are used to compute the address range to invalidate is given below.

Range payload packing

Address range to invalidate is calculated using the following formula:

Base Addr <= Addr to invalidate < Base Addr + ((Num+1) * 2^(5*Scale+1) * TG)

Where:

BaseAddr Shifted Base address of the range - 37 bits.

The base address in the message is shifted based on the Transaction granule.
The lowest address bit carried in the message is Address[12], Address[14], and Address[16] for
Transaction Granule size of 4K, 16K, and 64K, respectively.

TG Translation Granule Size - 2 bits, takes the following values:

0b00 Reserved
0b01 4K
0b10 16K
0b11 64K

TTL Translation Table Level - 2-bits.

Scale 2 bits, constant used in the address range exponent calculation. All binary values are valid.

Num 5 bits, constant used as multiplication factor in the range calculation. All binary values are valid.

The total number of bits in the Address range calculation is 48.

The range parameters are placed in the request packets as shown in Table 8-6 on page 8-325. The Range and Num
values are carried on the FwdNID field in the Snoop flit alongside the Addr field for the corresponding Snoop
transaction. Unused bits of FwdNID in SnpDVMOp must be set to zero.

Base address of the range operation is placed in VA[MaxVA:12], with significant address bits adjusted TG value in
the following manner.
TG = 4K VA[MaxVA:12].
TG = 16K VA[MaxVA:14]; VA[13:12] must be set to zero.
TG = 64K VA[MaxVA:16]; VA[15:12] must be set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-327
ID092622 Non-Confidential
DVM Operations
8.2 DVM Operation types

Table 8-7 shows the placement of the Range and Num values in the SnpDVMOp payload.

Table 8-7 Num value placement in SnpDVMOp payload

FwdNID SnpDVMOp request

Bit Part 1 Part 2

0 Range Num[0]

1 0 Num[1]

2 0 Num[2]

3 0 Num[3]

4 0 Num[4]

5 0 0

6 0 0

Level Hint in TLBI Operations

Non-range based TLBI operations by VA or IPA are permitted to use TG and TTL. These operations use TG and
TTL as an indication of the level of the page table walk that holds the leaf entry for the address that is being
invalidated. For such operations:
• Range field must be set to zero.
• Num and Scale fields are inapplicable and must be set to zero.
• When TG[1:0] = 00, TTL information is not provided.

TG and TTL fields are inapplicable and must be set to zero in non-range based TLBI operations which are not by
VA or IPA.

Range, Num, Scale, TG, and TTL fields are inapplicable and must be set to zero in all non-TLBI DVM operations.

8-328 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.2 DVM Operation types

8.2.3 DVM domain

The SnpAttr bit in a DVM request is used to differentiate between Inner and Outer domain. Table 8-8 shows the
SnpAttr value encoding in DVM transactions.

Table 8-8 SnpAttr value encoding in DVM transactions

SnpAttr Domain value

0 Inner domain

1 Outer domain

Two additional optional interface broadcast pins BROADCASTTLBIINNER (BTI) and

BROARDCASTTLBIOUTER (BTO) are defined that determine broadcasting of TLBI operations in the
interconnect. See Optional interface broadcast signals on page 16-482.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-329
ID092622 Non-Confidential
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-336
• Instruction cache invalidations on page 8-337
• Synchronization on page 8-339

8.3.1 TLB Invalidate

This section shows the supported TLB Invalidate operations.
• TLB Invalidate, All Guest OS, Secure operations
• TLB Invalidate, All Guest OS, Non-secure IPA, Secure operations on page 8-331.
• TLB Invalidate, All Guest OS, Non-secure operations on page 8-332
• TLB Invalidate, Hypervisor, Secure operations on page 8-332
• TLB Invalidate, Hypervisor, Non-secure operations on page 8-334
• TLB Invalidate EL3, Secure operations on page 8-334

TLB Invalidate, All Guest OS, Secure operations

Table 8-9 shows the fixed value fields for TLB Invalidate, All Guest OS, Secure operations.

Table 8-9 TLB Invalidate, All Guest OS, Secure operations fixed values

Field Value Status

DVMOp Type 0b000 TLBI

Exception Level 0b10 All Guest OS

Security 0b10 Secure

Table 8-10 shows the TLB Invalidate values for All Guest OS, Secure operations. In Table 8-10, the VA field holds
the IPA or PA as required.

Table 8-10 TLB Invalidate, All Guest OS, Secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b0 0b0 0b00a 0b0 Secure TLB Invalidate all

0b0 0b0 0b0 0b00a 0b1 Secure TLB Invalidate by VA

0b0 0b0 0b1 0b00a 0b1 Secure TLB Invalidate by VA Leaf Entry only

0b1 0b0 0b0 0b00a 0b0 Secure TLB Invalidate by ASID

0b1 0b0 0b0 0b00a 0b1 Secure TLB Invalidate by ASID and VA

0b1 0b0 0b1 0b00a 0b1 Secure TLB Invalidate by ASID and VA Leaf Entry only

0b0 0b1 0b0 0b01 0b0 Secure Guest OS, TLBI all, S1 invalidation only

0b1 0b1 0b0 0b00 0b0 Secure Guest OS, TLBI by ASID

0b0 0b1 0b0 0b00 0b1 Secure Guest OS, TLBI by VA

8-330 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.3 DVM Operations

Table 8-10 TLB Invalidate, All Guest OS, Secure operations (continued)

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b1 0b1 0b00 0b1 Secure Guest OS, TLBI by VA, Leaf only

0b1 0b1 0b0 0b00 0b1 Secure Guest OS, TLBI by ASID and VA

0b1 0b1 0b1 0b00 0b1 Secure Guest OS, TLBI by ASID and VA, Leaf only

0b0 0b1 0b0 0b10 0b1 Secure Guest OS, TLBI by Secure IPA

0b0 0b1 0b1 0b10 0b1 Secure Guest OS, TLBI by Secure IPA, Leaf only

0b0 0b1 0b0 0b00 0b0 Secure Guest OS TLBI all

a. All DVMv7 transactions must use 0b00.

TLB Invalidate, All Guest OS, Non-secure IPA, Secure operations

Table 8-11 shows the fixed value fields for TLB Invalidate, All Guest OS, Non-secure IPA, Secure operations.

Table 8-11 TLB Invalidate, All Guest OS, Non-secure IPA, Secure operations fixed values

Field Value Status

DVMOp 0b000 TLBI

Exception Level 0b10 All Guest OS

Security 0b01 Non-secure address from a Secure context

Table 8-12 shows the values for TLB Invalidate, All Guest OS, Non-Secure IPA, Secure operations.

In Table 8-12, the VA field holds the IPA.

Table 8-12 TLB Invalidate, All Guest OS, Non-secure IPA, Secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b1 0b0 0b10 0b1 Secure Guest OS, TLBI by Non-secure IPA

0b0 0b1 0b1 0b10 0b1 Secure Guest OS, TLBI by Non-secure IPA Leaf only

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-331
ID092622 Non-Confidential
DVM Operations
8.3 DVM Operations

TLB Invalidate, All Guest OS, Non-secure operations

Table 8-13 shows the fixed value fields for TLB Invalidate, All Guest OS, Non-secure operations.

Table 8-13 TLB Invalidate, All Guest OS, Non-secure operations fixed values

Field Value Status

DVMOp 0b000 TLBI

Exception Level 0b10 All Guest OS

Security 0b11 Non-Secure

Table 8-14 shows the values for TLB Invalidate, Guest OS, Non-Secure operations.

Table 8-14 TLB Invalidate Guest OS, Non-secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b0 0b0 0b00a 0b0 All Guest OS TLB Invalidate all

0b0 0b1 0b0 0b01 0b0 Guest OS TLB Invalidate all

Stage 1 invalidation only

0b0 0b1 0b0 0b00a 0b0 Guest OS TLB Invalidate all

ARMv7 must carry out Stage 1 and Stage 2 invalidation.

0b0 0b1 0b0 0b00a 0b1 Guest OS TLB Invalidate by VA

0b0 0b1 0b1 0b00a 0b1 Guest OS TLB Invalidate by VA Leaf Entry only

0b1 0b1 0b0 0b00a 0b0 Guest OS TLB Invalidate by ASID

0b1 0b1 0b0 0b00a 0b1 Guest OS TLB Invalidate by ASID and VA

0b1 0b1 0b1 0b00a 0b1 Guest OS TLB Invalidate by ASID and VA Leaf Entry only

0b0 0b1 0b0 0b10 0b1b Guest OS TLB Invalidate by IPA

0b0 0b1 0b1 0b10 0b1b Guest OS TLB Invalidate by IPA Leaf Entry only

a. All DVMv7 transactions must use 0b00.

b. IPA is the Intermediate Physical Address. The IPA is sent using the same format as the Virtual Address (VA).

TLB Invalidate, Hypervisor, Secure operations

Table 8-15 shows the fixed value fields for TLB Invalidate Hypervisor, Secure operations.

Table 8-15 TLB Invalidate, Hypervisor, Secure operations fixed values

Field Value Status

DVMOp 0b000 TLBI

Exception Level 0b11 Hypervisor

Security 0b10 Secure

8-332 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.3 DVM Operations

Table 8-16 shows the values for TLB Invalidate, Hypervisor with Secure operations.

Table 8-16 TLB Invalidate, Hypervisor, Secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b0 0b0 0b00 0b0 Secure Hypervisor, TLBI all

0b1 0b0 0b0 0b00 0b1 Secure Hypervisor, TLBI by ASID and VA

0b1 0b0 0b1 0b00 0b1 Secure Hypervisor, TLBI by ASID and VA Leaf only

0b0 0b0 0b0 0b00 0b1 Secure Hypervisor, TLBI by VA

0b0 0b0 0b1 0b00 0b1 Secure Hypervisor, TLBI by VA, Leaf only

0b1 0b0 0b0 0b00 0b0 Secure Hypervisor, TLBI by ASID

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-333
ID092622 Non-Confidential
DVM Operations
8.3 DVM Operations

TLB Invalidate, Hypervisor, Non-secure operations

Table 8-17 shows the fixed value fields for TLB Invalidate, Hypervisor, Non-secure operations.

Table 8-17 TLB Invalidate, Hypervisor, Non-secure operations fixed values

Field Value Status

DVMOp 0b000 TLBI

Exception Level 0b11 Hypervisor

Security 0b11 Non-secure

Table 8-18 shows the values for TLB Invalidate, Hypervisor, Non-secure operations.

Table 8-18 TLB Invalidate Hypervisor, Non-secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b0 0b0 0b00 0b0 Hypervisor TLB Invalidate all

0b0 0b0 0b0 0b00 0b1 Hypervisor TLB Invalidate by VA

0b0 0b0 0b1 0b00 0b1 Hypervisor TLB Invalidate by VA Leaf Entry only

0b1 0b0 0b0 0b00 0b0 Hypervisor TLB Invalidate by ASID

0b1 0b0 0b0 0b00 0b1 Hypervisor TLB Invalidate by ASID and VA

0b1 0b0 0b1 0b00 0b1 Hypervisor TLB Invalidate by ASID and VA Leaf Entry
only

TLB Invalidate EL3, Secure operations

Table 8-19 shows the fixed value fields for TLB Invalidate, EL3, Secure operations.

Table 8-19 TLB Invalidate, EL3, Secure operations fixed values

Field Value Status

DVMOp 0b000 TLBI

Exception Level 0b01 EL3

Security 0b10 Secure

Table 8-20 on page 8-335 shows values for TLB Invalidate EL3 with Secure operations.

8-334 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.3 DVM Operations

Table 8-20 TLB Invalidate EL3, Secure operations

Addr

Operation
ASID VMID Leaf Entry Staged VA
valid valid Invalidation Invalidation valid

0b0 0b0 0b0 0b00 0b1 EL3 TLB Invalidate by VA

0b0 0b0 0b1 0b00 0b1 EL3 TLB Invalidate by VA Leaf Entry only

0b0 0b0 0b0 0b00 0b0 EL3 TLB Invalidate All

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-335
ID092622 Non-Confidential
DVM Operations
8.3 DVM Operations

8.3.2 Branch Predictor Invalidate

This section shows the Branch Predictor Invalidate operations.

Table 8-21 shows the fixed value fields in the Branch Predictor Invalidate operation.

Table 8-21 Branch Predictor Invalidate operation fixed values

Field Value Status

Part Num - See Table 8-6 on page 8-325

VMID Valid 0b0 VMID field not valid

ASID Valid 0b0 ASID field not valid

Security 0b00 Applies to both secure and Non-secure

Exception Level 0b00 Applies to all Guest OS and Hypervisor

VMID 0xXX VMID not specified

VMIDExt

ASID 0xXXXX ASID not specified

Staged Invalidation 0b00 Reserved, set to Zero

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-22 shows the operations supported by Branch Predictor Invalidate.

Table 8-22 Branch Predictor Invalidate operations

Addr
Operation
DVMOp type VA valid

0b001 0b0 Branch Predictor Invalidate all

0b1 Branch Predictor Invalidate by VA

8-336 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.3 DVM Operations

8.3.3 Instruction cache invalidations

Instruction caches can use either a PA or a VA to tag the data they contain. A system might contain a mixture of both
forms of cache.

The DVM protocol includes instruction cache invalidation operations that use physical addresses and operations
that use virtual addresses. A component that receives DVM messages must support both forms of message,
independent of the style of instruction cache implemented. It might be necessary to over-invalidate in the case where
a message is received in a format that is not native to the cache type.

Physical Instruction Cache Invalidate

This section lists the Physical Instruction Cache Invalidate (PICI) operations that the DVM message supports. This
message type is also used for Instruction Caches which are Virtually Indexed Physically Tagged (VIPT).

Table 8-23 shows the fixed value fields in the PICI operations.

Table 8-23 Physical Instruction Cache Invalidate operation fixed values

Field Value Status

Part Num - See Table 8-6 on page 8-325

Exception Level 0b00 Applies to all Guest OS and Hypervisor

Staged Invalidation 0b00 Reserved, set to zero

Leaf Entry Invalidation 0b0 Reserved, set to zero

Table 8-24 shows the operations supported by PICI.

Note
When VI Valid is 0b11, VI[19:12] is used as part of Physical Address (PA).

Table 8-24 Physical Instruction Cache Invalidate operations

VA
DVMOp type Security VI Valid Operation
Valid

0b010 0b10 0b00 0b0 Secure and Non-secure PICI all

0b00 0b1 Secure PICI by PA without VI

0b11 0b1 Secure PICI by PA with VI

0b11 0b00 0b0 Non-secure PICI all

0b00 0b1 Non-secure PICI by PA without VI

0b11 0b1 Non-secure PICI by PA with VI

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-337
ID092622 Non-Confidential
DVM Operations
8.3 DVM Operations

Virtual Instruction Cache Invalidate

This section shows the Virtual Instruction Cache Invalidate (VICI) operations.

Table 8-25 shows the fixed value fields in the VICI operation.

Table 8-25 Virtual Instruction Cache Invalidate operation fixed values

Field Value Status

Part Num - See Table 8-6 on page 8-325

Staged 0b00 Reserved. set to zero

Invalidation

Leaf Entry 0b0 Reserved, set to zero

Invalidation

Table 8-26 shows the operations supported by VICI.

Table 8-26 Virtual Instruction Cache Invalidate operations

Addr

Operation
Exception ASID VMID VA
DVMOp type Security
Level valid valid valid

0b011 0b00 0b00 0b0 0b0 0b0 Invalidate all. Applies to Secure and Non-secure.
Applies to Hypervisor and all Guest OS.

0b11 0b0 0b0 0b0 Invalidate all. Applies to Non-secure. Applies to

Hypervisor and all Guest OS.

0b10 0b10 0b1 0b0 0b1 Secure Invalidate by ASID and VA.

0b0 0b1 0b0 Secure Invalidate all per VMID.

0b1 0b1 0b1 Secure Invalidate by ASID and VA per VMID.

0b11 0b0 0b1 0b0 Non-secure Guest OS, Invalidate all per VMID.

0b1 0b1 0b1 Non-secure Guest OS, Invalidate by ASID and

VA per VMID.

0b11 0b11 0b0 0b0 0b1 Hypervisor, Invalidate by VA.

0b1 0b0 0b1 Hypervisor, Invalidate by ASID and VA

8-338 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 DVM Operations
8.3 DVM Operations

8.3.4 Synchronization
This section shows the DVMSync Synchronization operation.

Table 8-27 shows the fixed value fields in the Sync operation.

Table 8-27 Sync operation fixed values

Field Value Status

Part Num - See Table 8-6 on page 8-325

VA Valid 0b0 Not applicable

VMID Valid 0b0 Ignore VMID

ASID Valid 0b0 Ignore ASID

Security 0b00 Applies to both Secure and Non-secure

Exception Level 0b00 Applies to all Guest OS and Hypervisor

DVMOp type 0b100 Synchronization message

VMID 0xXX VMID not specified

VMIDExt

ASID 0xXXXX ASID not specified

Staged Invalidation 0b00 Set to zero

Leaf Entry Invalidation 0b0 Set to zero

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 8-339
ID092622 Non-Confidential
DVM Operations
8.3 DVM Operations

8-340 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 9
Error Handling

This chapter describes the error handling requirements. It contains the following sections:
• Error types on page 9-342
• Error response fields on page 9-343
• Errors and transaction structure on page 9-344
• Error response use by transaction type on page 9-345
• Poison on page 9-355
• Data Check on page 9-356
• Use of interface parity on page 9-357
• Interoperability of Poison and DataCheck on page 9-360
• Hardware and software error categories on page 9-361

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-341
ID092622 Non-Confidential
Error Handling
9.1 Error types

9.1 Error types

This specification supports two types of error reporting at sub packet level. There are two types of error reporting
at packet level.

The packet level error reporting types are:

Data Error, DERR

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 Error Correction
Code (ECC) or a parity check.
Data Error reporting is supported by the RespErr, Poison, and DataCheck fields in the DAT
packet.
When processing of a request received by Home that is required to be propagated to the
Subordinate results in a DERR, the Home must not stop propagating the request to the
Subordinate.

Note
An error in data being evicted from Home, or received in a Snoop response as a result of the
request, are examples of the request resulting in a DERR.

Non-data Error, NDERR

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.
Non-data Error reporting is supported by the RespErr field in the RSP and DAT packets.
When processing of a request received by Home results in an NDERR, it is permitted, but
not required, to propagate the request to the Subordinate. The Home is required to pass-back
the NDERR in the response to the Requester.

9-342 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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-296 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.

A transaction with a Data response is required to include NDERR either in none or in all Data packets.

The mixing of OK and DERR responses within a single transaction is permitted.

The mixing of EXOK and DERR responses within a single transaction is permitted.

The mixing of OK and NDERR responses within a single transaction is permitted, which can occur only in
transactions with both Data and Non-data responses.

The mixing of EXOK and NDERR is not permitted.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-343
ID092622 Non-Confidential
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.

Error handling for a transaction that utilizes DMT is the same as the error handling for the same request without
DMT.

Because there is no mechanism to propagate errors on requests or snoops, a request must not use DMT or DCT if
an error is detected at the interconnect.

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-208 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 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.

A Requester that receives a response with a Non-data Error for a Snoopable request must:

• For an Allocating transaction:

— When the start state is I, the Requester must not allocate the received data.
— If the request was sent from a Non-Invalid state, the Requester must leave the cached copy unchanged.
In both cases, the cache state must not be changed.
— The Allocating transactions are:
— ReadClean
— ReadNotSharedDirty
— ReadShared
— ReadUnique
— ReadPreferUnique
— MakeReadUnique
— CleanUnique
— MakeUnique

• For a deallocating transaction:

— The Requester must continue as normal, in a protocol-compliant manner.
— The deallocating transactions are:
— WriteBack
— WriteEvictFull
— Evict
— WriteEvictOrEvict

• For Other transactions that do not change allocation:

— The Requester must not upgrade the cache state but is permitted to downgrade it.

The cache state in a SnpResp message with a Non-data Error must be I. The Completer must invalidate local cached
copies of the cache line. In addition, when the response to a Forwarding snoop results in a Non-data Error, the
Snoopee must not forward data to the Requester. As a consequence, if the CompData message has already been sent
to the Requester then the Snoop response to the Home must not include the Non-data Error.

9-344 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.4 Error response use by transaction type

9.4 Error response use by transaction type

This section defines the permitted, but not required, 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-347
• Write transactions on page 9-348
• Atomic transactions on page 9-350
• Other transactions on page 9-352
• Cache Stashing transactions on page 9-352
• Snoop transactions on page 9-353

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.

Read data which is known to be corrupt must have an appropriate Error indication where the error can be Poison,
DERR, or NDERR.

When RespSepData includes a NDERR, all corresponding DataSepResp packets must be marked with NDERR.

In a Data response to a Read request, an NDERR response is only permitted either in none or in all data response
packets.

Note
Prior to CHI Issue E, a Read transaction was permitted to include a NDERR response in some of the data responses.

Table 9-2 shows the legal RespErr field values associated with Data and Response packets for Read transactions.

Table 9-2 Legal RespErr field values associated with Data and Response packets for Read
transactions

Associated Data and Response packets

Read transaction Read Receipt CompData CompAck

OK EXOK DERR NDERR

ReadNoSnp OK Y Y Y Y OK

ReadNoSnpSep OK - - - - -

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-345
ID092622 Non-Confidential
Error Handling
9.4 Error response use by transaction type

Table 9-2 Legal RespErr field values associated with Data and Response packets for Read
transactions (continued)

Associated Data and Response packets

Read transaction Read Receipt CompData CompAck

OK EXOK DERR NDERR

ReadOnce OK Y N Y Y OK
ReadOnceCleanInvalid
ReadOnceMakeInvalid

ReadClean - Y Y Y Y OK
ReadNotSharedDirty
ReadShared

ReadUnique - Y N Y Y OK
ReadPreferUniquea
MakeReadUniqueb

a. EXOK response is not permitted even when Excl bit in the request is set to 1.
A response of OK in the returned data response is not to be taken as a failure of ReadPreferUnique.
Failure of the exclusive sequence is only determined from the corresponding MakeReadUnique
(Excl) or CleanUnique (Excl) transaction completion.
b. Applicable only when data is returned to the Requester. See Table 9-4 on page 9-347 for permitted
errors when data is not returned to the Requester.

Table 9-3 shows the legal RespErr field values associated with Data-only and Non-data packets for Read
transactions.

Table 9-3 Legal RespErr field values associated with Data-only and Non-data packets for Read
transactions

Associated Data-only and Non-data packets

Read transaction DataSepResp RespSepData

OK EXOK DERR NDERR OK EXOK DERR NDERR

ReadNoSnp Y N Y Y Y N N Y

ReadNoSnpSep Y N Y Y - - - -

ReadOnce Y N Y Y Y N N Y
ReadOnceCleanInvalid
ReadOnceMakeInvalid

ReadClean Y N Y Y Y N N Y
ReadNotSharedDirty
ReadShared

ReadUnique Y N Y Y Y N N Y
ReadPreferUniquea
MakeReadUniqueb

a. A response of OK in the returned data response is not be taken as a failure of ReadPreferUnique. Failure of
the exclusive sequence is only determined from the corresponding MakeReadUnique (Excl) or CleanUnique
(Excl) transaction completion.

9-346 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.4 Error response use by transaction type

b. Applicable only when data is returned to the Requester. See Table 9-4 on page 9-347 for permitted errors
when data is not returned to the Requester.

9.4.2 Dataless transactions

A DERR 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-4 shows the Dataless transaction packets legal RespErr field values.

Table 9-4 Dataless transaction packets legal RespErr field values

Associated Response packets

Comp Persist CompPersist

Dataless transaction
CompAck

NDERR

NDERR

NDERR
EXOK

DERR

EXOK

DERR

EXOK

DERR
OK

OK

OK
CleanUnique Y Y Y Y - - - - - - - - OK

MakeReadUniquea Y N Y Y - - - - - - - - OK

MakeUnique Y N Y Y - - - - - - - - OK

CleanShared Y N Y Y - - - - - - - - -

CleanSharedPersist Y N Y Y - - - - - - - - -

CleanSharedPersistSep Y N Y Y Y N Y Y Y N Y Y -

CleanInvalid Y N Y Y - - - - - - - - -
MakeInvalid

Evict Y N N Y - - - - - - - - -

a. Applicable only when data is not returned to the Requester. See Table 9-2 on page 9-345 and Table 9-3 on page 9-346
for permitted errors when data is returned to the Requester.

Table 9-5 shows the permitted RespErr values in responses to StashOnce transactions.

Table 9-5 Dataless Stash transaction packets legal RespErr field values

Associated Response packets

Comp StashDone CompStashDone

Dataless Stash transaction
NDERR

NDERR

NDERR
EXOK

DERR

EXOK

DERR

EXOK

DERR
OK

OK

OK

StashOnceUnique Y N Y Y - - - - - - - -
StashOnceShared

StashOnceSepUnique Y N Y Y Y N Y Y Y N Y Y
StashOnceSepShared

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-347
ID092622 Non-Confidential
 Error Handling
9.4 Error response use by transaction type

9.4.3 Write transactions

A Write transaction can include either a NDERR or a DERR. Errors can be signaled in both directions, from the
Requester to the Completer, and from the Completer back to the Requester.

Write data which is known to be corrupt must have an appropriate Error indication where the error can be Poison
or DERR.

For a Write transaction an error can be signaled from the Completer back to the Requester using either the combined
CompDBIDResp or using the Comp response. It is permitted, but not required, 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-6 shows the Write transaction response packets legal RespErr field values.

Table 9-6 Write transaction Response packets legal RespErr field values

Associated Response packets

Write
Comp CompDBIDResp
transaction
DBIDResp CompAck
OK EXOK DERR NDERR OK EXOK DERR NDERR

WriteNoSnp OK Y Y Y Y Y Y Y Y OK

WriteUnique OK Y N Y Y Y N Y Y OK

WriteNoSnpZero OK Y N Y Y Y N Y Y -
WriteUniqueZero

WriteBack - - - - - Y N Y Y -
WriteClean
WriteEvictFull

WriteEvictOrEvict - Y N N Y Y N Y Y OK

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-7 shows the Write transaction Data packets legal RespErr field values.

Table 9-7 Write transaction Data packets legal RespErr field values

Associated Data packets

Write
WriteData WriteDataCancel NCBWrDataCompAck
transaction
OK EXOK DERR NDERR OK EXOK DERR NDERR OK EXOK DERR NDERR

WriteNoSnp Y N Y N Y N Y N Y N Y N

WriteUnique Y N Y N Y N Y N Y N Y N

WriteBack Y N Y N - - - - - - - -
WriteClean
WriteEvictFull
WriteEvictOrEvict

9-348 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.4 Error response use by transaction type

Table 9-8 shows the Write transaction TagMatch packet legal RespErr field values when MTE is supported on the
interface of the Requester.

Table 9-8 Write transaction TagMatch packet legal RespErr field values

Associated response packets

Write transaction TagMatch

OK EXOK DERR NDERR

WriteNoSnp Y N Y Y
WriteUnique

WriteBack - - - -
WriteClean
WriteEvictFull
WriteEvictOrEvict

For permitted RespErr field values in a Combined Write transaction response:

• See Table 9-6 on page 9-348 for the corresponding responses for the Write request.
• See Table 9-4 on page 9-347 for the corresponding responses for the CMO request.
The permitted error responses in the CompCMO are the same as those in the Comp in Table 9-4 on
page 9-347.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-349
ID092622 Non-Confidential
Error Handling
9.4 Error response use by transaction type

9.4.4 Atomic transactions

It is permitted, but not required, for a Completer to give a Comp response before it has received all the write data
associated with a transaction and has performed the required operation. This behavior is not compatible with a
component that wants to signal a data error associated with the write data, and such components must use a delayed
form of Comp or CompData response.

In Atomic transactions, Read data or Write data which is known to be corrupt must have an appropriate Error
indication. When the error is on Read data, it can be Poison, DERR, or NDERR. When the error is on Write data, it
can be Poison or DERR.

A DERR or NDERR can be signaled at the following points within a transaction:

• With the CompDBIDResp response.
• For an AtomicStore transaction, with the Comp response.
• For an AtomicLoad, AtomicSwap, and AtomicCompare transaction, with the CompData response.

Note
If a read data at Home due to a non-store Atomic request results in a DERR or NDERR, such an error can be
propagated onto the DBIDResp or CompDBIDResp response for that request.

For Atomic transactions that are not able to complete, a NDERR must be used. The transaction structure, including
all write data transfers, read data transfers, and other responses must still take place.

There is no need to specify an error associated with the execution of an atomic operation, such as overflow. All
atomic operations are fully specified for all input combinations.

A transaction includes both outbound and inbound data, but only has a single Error field. For Atomic transactions,
it is permitted for the Error field to indicate an error on either write data or read data. There is no mechanism
supported within the transaction to differentiate between the potential different causes of an error. A fault log, or a
similar structure, might be able to provide such information, but this is not a requirement of this specification.

The permitted RespErr values in Atomic transactions are an amalgamation of those permitted in Read and Write
transactions.

A DERR can vary between data packets.

Table 9-9 shows the Atomic transaction Response packets legal RespErr field values

Table 9-9 Atomic transaction Response packets legal RespErr field values

Associated Response packets

Atomic transaction Comp CompDBIDResp

DBIDResp
OK EXOK DERR NDERR OK EXOK DERR NDERR

AtomicStore OK Y N Y Y Y N Y Y

AtomicLoad OK Y N Y Y - - - -
AtomicSwap
AtomicCompare

9-350 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.4 Error response use by transaction type

Table 9-10 shows the Atomic transaction Data packets legal RespErr field values.

Table 9-10 Atomic transaction Data packets legal RespErr field values

Associated response packets

Atomic transaction WriteData CompData

OK EXOK DERR NDERR OK EXOK DERR NDERR

AtomicStore Y N Y N - - - -

AtomicLoad Y N Y N Y N Y Y
AtomicSwap
AtomicCompare

Table 9-11 shows the Atomic transaction TagMatch packet legal RespErr field values when MTE is supported.

Table 9-11 Atomic transaction TagMatch packet legal RespErr field values

Associated response packets

Atomic transaction TagMatch

OK EXOK DERR NDERR

AtomicStore Y N Y Y
AtomicLoad
AtomicSwap
AtomicCompare

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-351
ID092622 Non-Confidential
Error Handling
9.4 Error response use by transaction type

9.4.5 Other transactions

This section describes the error handling requirements for the DVMOp and PrefetchTgt transactions.

DVMOp
A DVMOp transaction can include a NDERR in the Comp response. The interconnect can 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. The DBIDResp packet must only use the OK response. Even though the Sender of a WriteData
response might not use DERR, the packet can be marked as DERR if it encounters errors during transmission. See
Interoperability of Poison and DataCheck on page 9-360.

Table 9-12 shows the DVM transaction Response packets legal RespErr field values.

Table 9-12 DVM transaction Response packets legal RespErr field values

Associated Response packets

DVM transaction Comp CompDBIDResp

DBIDResp
OK EXOK DERR NDERR OK EXOK DERR NDERR

DVMOp OK Y N Y Y Y N Y Y

Table 9-13 shows the DVM transaction Data packets legal RespErr field values.

Table 9-13 DVM transaction Data packets legal RespErr field values

Associated Data packets

DVM transaction NCBWrData

OK EXOK DERR NDERR

DVMOp Y N Y N

PrefetchTgt
A PrefetchTgt transaction request to a non-supporting address must be discarded.

Note
A component is permitted, but not required, to record and report such an error.

9.4.6 Cache Stashing transactions

If the specified Stash target does not support receiving Stash snoops, the Home must disregard the Stash hint and
complete the transaction without Stashing. Examples of such Stash targets are RN-I, RN-D, legacy RN-F, or a
Non-request node. In these circumstances, Home must not signal an error to the Requester. Such a wrongly specified
Stash target can be attributed to a software-based error.

If the Home does not support Stash requests, it must complete the transaction in a protocol-compliant manner
without signaling an error.

9-352 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.4 Error response use by transaction type

9.4.7 Snoop transactions

A Snoop transaction response that includes data can indicate a DERR. A Snoop transaction response that includes
data can mix OK and DERR responses for different packets within the transaction.

Data, in response to a Snoop request that is known to be corrupt, must have an appropriate Error indication where
the error can be Poison or DERR.

A Snoop transaction response that does not include data can indicate an NDERR.

A Snoopee that responds with an NDERR:

• Must not include data with the response.
• Must invalidate any locally cached copies.
• Must set the cache state in the response to Invalid.
• Must not forward a CompData response to the Requester in response to a Forwarding snoop. As a
consequence, if the CompData message is already sent to the Requester then the Snoop response to the Home
must not include a Non-data Error.

Table 9-14 shows the Snoop request Response packets legal RespErr field values.

Table 9-14 Snoop request Response packets legal RespErr field values

Associated Data and Response packets

Snoop Transaction SnpResp SnpRespData

OK EXOK DERR NDERR OK EXOK DERR NDERR

SnpOnce Y N N Y Y N Y N
SnpClean
SnpNotSharedDirty
SnpShared
SnpUnique
SnpPreferUnique
SnpUniqueStash
SnpCleanShared
SnpCleanInvalid

SnpStashUnique Y N N Y - - - -
SnpStashShared
SnpMakeInvalid
SnpMakeInvalidStash
SnpQuery
SnpDVMOp

It is recommended, but not required, that a DERR on a Clean cache line is dropped and the error is not propagated
to the memory, nor included in the response to the Requester.

A DERR on a Dirty cache line must be propagated to the memory, and in the response to the Requester.

A DERR in response to the DataPull request is not expected to be transferred to the Comp response to the Stash
request.

For a Forwarding snoop transaction, when simultaneously forwarding data to the Requester and returning Data to
Home, it is permitted, but not required, for only one response to include an indication of a DERR if the other
response does not encounter the error.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-353
ID092622 Non-Confidential
Error Handling
9.4 Error response use by transaction type

Table 9-15 shows the Forwarding Snoop response packets legal RespErr field values.

Table 9-15 Forwarding Snoop response packets legal RespErr field values

Associated Response packets

Snoop transaction SnpResp SnpRespFwded

OK EXOK DERR NDERR OK EXOK DERR NDERR

SnpOnceFwd Y N N Y Y N Y N
SnpCleanFwd
SnpNotSharedDirtyFwd
SnpSharedFwd
SnpUniqueFwd
SnpPreferUniqueFwd

Table 9-16 shows the Forwarding Snoop Data response packets legal RespErr field values.

Table 9-16 Forwarding Snoop Data response packets legal RespErr field values

Associated Data packets

SnpRespData
Snoop transaction CompData
SnpRespDataFwded

OK EXOK DERR NDERR OK EXOK DERR NDERR

SnpOnceFwd Y N Y N Y N Y N
SnpCleanFwd
SnpNotSharedDirtyFwd
SnpSharedFwd
SnpUniqueFwd
SnpPreferUniqueFwd

9-354 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.5 Poison

9.5 Poison
The Poison bit is used to indicate that a set of data bytes have previously been corrupted. Passing the Poison bit
alongside the data in the DAT packet permits any future user of the data to be notified that the data is corrupt.

When Poison is supported:

• The DAT packet includes one Poison bit per 64 bits of data.
• Data marked as poisoned:
— Must not be utilized by any Requester.
— Is permitted, but not required, to be stored in caches and memory if marked as poisoned.
• The Poison value, once set, must be propagated along with the data.
• When a Poison error is detected, it is permitted, but not required, to over poison the data.
• Poison on MTE tags is not supported.

Poison must be accurate if there are any valid bytes in the 64-bit chunk. This is the Poison granularity. When all 8
bytes in the 64-bit chunk are invalid, the Poison bit can take any value.

A Data_Poison property is used to indicate if a component supports Poison.

Note
Although Poison on tags is not supported, implementations might choose to do one of the following:

• Poison associated with the data results in the tag being poisoned. Depending on the granularity of the poison
associated with the tag, it might not be possible to clear the poison using the same techniques that would be
used to clear poison associated with data.

• Poison associated with the data does not result in the tag being poisoned. This means that a corrupted tag
might subsequently be used in an MTE Match operation, which could incorrectly fail. The rate at which this
occurs should be significantly lower than the rate at which data corruption occurs.

• A mixture of approaches can be used, depending on the caching or storage structures that are used.

Other implementations are possible.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-355
ID092622 Non-Confidential
Error Handling
9.6 Data Check

9.6 Data Check

The DataCheck field is used to detect data errors in the DAT packet.

When Data Check is supported:

• The DAT packet carries 8 DataCheck bits per 64 bits of data.
• The Data Check bit is a parity bit that generates Odd Byte parity.

Note
Interface parity optionally extends the error detection provided on the DAT channel by the DataCheck field.

The Data_Check and Check_Type properties are used to indicate if DataCheck is supported in the DAT packet. See
Check_Type on page 16-479 and Data_Check on page 16-479.

9-356 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.7 Use of interface parity

9.7 Use of interface parity

For safety-critical applications it is necessary to detect and possibly correct, transient and functional errors on
individual wires within an SoC.

An error in a system component can propagate and cause multiple errors within connected components. Error
Detection and Correction (EDC) is required to operate end-to-end, covering all logic and wires from source to
destination.

One way to implement end-to-end protection, is to employ customized EDC schemes in components and implement
a simple error detection scheme between components. Between these components there is no logic and connections
are relatively short. This section describes a parity scheme for detecting single-bit errors on the interface between
components. Multi-bit errors may be detected if they occur in different parity signal groups. Figure 9-1 shows
locations where parity can be used.

Long distance wiring

and routing logic Short distance wiring

Interconnect
AMBA AMBA
Source Destination

Parity EDC code Parity

Parity check
Parity generation Parity check and EDC EDC check and Parity
generation generation

Figure 9-1 Parity use in AMBA

AMBA parity optionally extends the error detection provided on the DAT channel by the DataCheck field to cover
the complete flit and control signals on all channels.

The protection scheme employed on an interface is defined by the property Check_Type. See Interface properties
and parameters on page 16-478.

9.7.1 Byte parity check signals

The following attributes are common to all the check signals added for byte parity interface protection:

• Odd parity is used.

Odd parity means that check signals are added to groups of signals on the interface and driven such that there
is always an odd number of asserted bits in that group.

• Parity signals covering data and payload are defined such that there are no more than 8 bits per group.
This limitation assumes that there is a maximum of 3 logic levels available in the timing budget for generating
each parity bit.

• Parity signals covering critical control signals, which are likely to have a smaller timing budget available, are
defined with a single odd parity bit.

• The least significant check bit of the check signal covers the least significant byte of payload.

• If the bits in a payload do not fill the most significant byte, the most significant bit of the check signal covers
fewer than 8 bits.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-357
ID092622 Non-Confidential
Error Handling
9.7 Use of interface parity

• Check signals must be driven correctly in every cycle that the Check Enable term is True, see Table 9-17 on
page 9-359.

• Parity signals must be driven appropriate to all the bits in the associated payload, irrespective of whether
those bits are applicable.

9.7.2 Error detection behavior

This specification is not prescriptive regarding component or system behavior when a parity error is detected.
Depending on the system and affected signals, a flipped bit can have a wide range of effects. It might be harmless,
cause performance issues, cause data corruption, cause security violations or deadlock. Also, an error on one signal
can also cause parity failure on other signals.

When an error is detected, the receiver has options to:

• Terminate or propagate the transaction. It is permitted, but not required, to be protocol-compliant when the
transaction is terminated.

• Correct the parity check signal or propagate the error.

• Update its memory or leave untouched. It is permitted, but not required, to mark the location as poisoned.

• Signal an error response through other means, for example, with an interrupt.

9-358 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.7 Use of interface parity

9.7.3 Interface parity check signals

Table 9-17 shows the parity check signals and their properties on each of the channels.

Table 9-17 Interface parity check signals

Check signal Check

Channel Check signal Signals covered Check enable
width granularity

Common SYSCOREQCHK SYSCOREQ 1 1 RESETn == 1

SYSCOACKCHK SYSCOACK 1 1 RESETn == 1

Common TXSACTIVECHK TXSACTIVE 1 1 RESETn == 1

RXSACTIVECHK RXSACTIVE 1 1 RESETn == 1

Common TXLINKACTIVEREQCHK TXLINKACTIVEREQ 1 1 RESETn == 1

TXLINKACTIVEACKCHK TXLINKACTIVEACK 1 1 RESETn == 1

RXLINKACTIVEREQCHK RXLINKACTIVEREQ 1 1 RESETn == 1

RXLINKACTIVEACKCHK RXLINKACTIVEACK 1 1 RESETn == 1

REQ REQFLITPENDCHK REQFLITPEND 1 1 RESETn == 1

REQFLITVCHK REQFLITV 1 1 RESETn == 1

REQFLITCHK REQFLIT ceil(R/8)a 1 to 8 REQFLITV == 1

REQLCRDVCHK REQLCRDV 1 1 RESETn == 1

RSP RSPFLITPENDCHK RSPFLITPEND 1 1 RESETn == 1

RSPFLITVCHK RSPFLITV 1 1 RESETn == 1

RSPFLITCHK RSPFLIT ceil(T/8)b 1 to 8 RSPFLITV == 1

RSPLCRDVCHK RSPLCRDV 1 1 RESETn == 1

SNP SNPFLITPENDCHK SNPFLITPEND 1 1 RESETn == 1

SNPFLITVCHK SNPFLITV 1 1 RESETn == 1

SNPFLITCHK SNPFLIT ceil(S/8)c 1 to 8 SNPFLITV == 1

SNPLCRDVCHK SNPLCRDV 1 1 RESETn == 1

DAT DATFLITPENDCHK DATFLITPEND 1 1 RESETn == 1

DATFLITVCHK DATFLITV 1 1 RESETn == 1

DATFLITCHK DATFLIT ceil(D/8)d 1 to 8 DATFLITV == 1

DATLCRDVCHK DATLCRDV 1 1 RESETn == 1

a. R = Request flit width See Request flit on page 13-418.

b. T = Response flit width. See Response flit on page 13-420.
c. S = Snoop flit width. See Snoop flit on page 13-421.
d. D = Data flit width. See Data flit on page 13-422.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-359
ID092622 Non-Confidential
Error Handling
9.8 Interoperability of Poison and DataCheck

9.8 Interoperability of Poison and DataCheck

If the recipient of a Data packet does not support the Poison and DataCheck features then the interconnect must
enumerate and convert, as necessary, the Poison and DataCheck error responses to a DERR in the DAT packet.

If support for the Poison and DataCheck features is not similar across an interface, then the following rules apply:
• Poison must be mapped to DataCheck or DERR if Poison is not supported across the interface. At such an
interface, Poison is expected but not required to be mapped to DataCheck instead of DERR, if DataCheck is
supported.
When converting from Poison to DataCheck, when an 8-byte chunk is marked as Poisoned, all 8 bits of
DataCheck corresponding to that chunk must be manipulated to generate a parity error.
• DataCheck must be mapped to Poison or DERR if DataCheck is not supported across the interface. At such
an interface, DataCheck is expected but not required to be mapped to Poison instead of DERR, if Poison is
supported.
When converting from DataCheck to Poison, if one or more DataCheck bits in a given 8-byte chunk generates
a parity error, then the Poison bit corresponding to that chunk must be set.

Note
The difference between the handling of Poison and DERR is that a Poison error in a received data packet is typically
deferred by the receiver, but a DERR error is typically not deferred by the receiver.

It is sufficient for the Sender of a data packet that detects a Poison error to indicate this in the Poison bits. It is not
a requirement that the Sender sets the RespErr field value to DERR.

It is sufficient for the Sender of a data packet that detects a DataCheck error to indicate this in the DataCheck field
and is not required to set RespErr field value to DERR.

As Poison and DataCheck fields are independently set, one type of error does not require setting of the other.

In a Data packet that has the RespErr field value set to DERR or NDERR, the value of the Poison and DataCheck
fields are inapplicable and can take any value.

9-360 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Error Handling
9.9 Hardware and software error categories

9.9 Hardware and software error categories

This specification defines two error categories: a software-based error and a hardware-based error.

9.9.1 Software-based error

A software-based error occurs when multiple accesses to the same location are made with incorrect or mismatched
Snoopable or Memory attributes. See Mismatched Memory attributes on page 2-140.

A software-based error can cause a loss of coherency and the corruption of data values. It is required 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 stores 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.9.2 Hardware-based error

A hardware-based error is defined as any protocol error that is not a software-based error.

Caution
If a hardware-based error occurs, recovery from the error is not guaranteed. The system might crash, lock-up, or
suffer some other non-recoverable failure.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 9-361
ID092622 Non-Confidential
Error Handling
9.9 Hardware and software error categories

9-362 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-364
• QoS priority value on page 10-365
• Repeating a transaction with higher QoS value on page 10-366

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 10-363
ID092622 Non-Confidential
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-364 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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
depends 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 10-365
ID092622 Non-Confidential
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, but not required, to send the same
transaction again with a different QoS value, typically higher. The Completer is required to handle this situation as
multiple different requests.

In this instance, if one of the transactions receives a RetryAck response, it is permitted, but not required, to cancel
the transaction and return the credit. See Credit Return on page 2-155.

10-366 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 11
System Debug, Trace, and Monitoring

This chapter describes mechanisms that provide extra support for the debugging and tracing of systems, and the
monitoring of systems to enhance performance. It contains the following sections:
• Data Source indication on page 11-368
• SLC replacement hint on page 11-371
• MPAM on page 11-373
• Completer Busy on page 11-375
• Trace Tag on page 11-376

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-367
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.1 Data Source indication

11.1 Data Source indication

It is permitted, but not required, that the Completer of a Read request to specify the source of the data. The source
is specified in the DataSource field of the CompData, DataSepResp, SnpRespData, and SnpRespDataPtl responses.
DataSource field value is valid even in data responses with error.

The DataSource field can also be used to transport information to bias SLC replacement policy. See SLC
replacement hint on page 11-371.

11.1.1 DataSource value assignment

The DataSource values must be assigned as follows:

• Fixed values are used for DataSource when data comes from memory and are used to indicate the following:
— 0b0110 PrefetchTgt memory prefetch was useful.
Read data was obtained from the Subordinate with lower latency as the PrefetchTgt
request already read or initiated a read of data from memory.
— 0b0111 PrefetchTgt memory prefetch was not useful.
Read request went through a complete memory access and therefore did not have any
latency reduction due to the PrefetchTgt request sent earlier.
The precise reason for signaling that a prefetch was not useful is IMPLEMENTATION
DEFINED.

Note
There are several reasons why the PrefetchTgt request might not be useful. Examples are that the
prefetch was dropped by the Subordinate, the data obtained by the prefetch was replaced in the buffer,
or the Read request arrived at the Subordinate before the prefetch.

• For a response from a cache, not memory, the DataSource value is IMPLEMENTATION DEFINED.
It is recommended, but not required, to have settings for DataSource in these cases.
A component is permitted, but not required, to have software programmability to override the DataSource
value to:
— Change the groupings to more suitable specific configuration settings.
— Change the values where the values are not correct.

• A Completer is permitted to not support sending a useful DataSource value:

— The Completer, except for a memory SN-F, must return a 0b0000 value.
— A memory SN-F component must return 0b0111 as a default value.
Such exceptions must be understood by the system.

11.1.2 Crossing a chip-to-chip interface

It is the responsibility of the chip interface module, if one exists, to map DataSource values in the incoming data
packets to different values to identify that the response came from the remote chip caches.

Example approaches that the chip interface module might take are:

• Group the remote caches into a single encoding, as Figure 11-1 on page 11-369 shows.

• Have a maximum size of an eight entry table, to remap the implementation values of the DataSource field in
the incoming data packet to new values.

11-368 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Debug, Trace, and Monitoring
11.1 Data Source indication

Suggested DataSource values

Figure 11-1 shows an example multichip configuration and the suggested mapping of DataSource values to different
components in the system:

• Each chip in the system has two processors per cluster, with a three-level cache hierarchy.

• The cache in the chip-to-chip interface module is identified as part of the interconnect caches.

• All the caches in the remote peer chip are grouped.

• A non-memory component that is not programmed to identify itself as the source of data can return the
default value of 0b0000.
Table 11-1 lists the suggested DataSource encodings.

Table 11-1 Suggested DataSource value encodings

DataSource Suggested mapping

0b0000 Non-memory default. Source does not support sending a useful DataSource value.

0b0001 Peer processor cache within local cluster

0b0010 Local cluster cache

0b0011 Interconnect cache

0b0100 Peer cluster caches

0b0101 Remote chip caches

0b1010 Local cluster cache, unused prefetcha

0b1011 Interconnect cache, unused prefetcha

a. New in CHI Issue E. See SLC replacement hint on page 11-371.

Chip Peer chip

Cluster Peer Cluster Cluster Peer Cluster

Processor Processor Processor Processor Processor Processor Processor Processor
Cache Cache Cache Cache Cache Cache Cache Cache
Cache Cache Cache Cache
Cache

Cache

Cache

Cache

Interconnect Interconnect
Cache Cache Cache Cache Cache Cache Cache Cache

Prefetch useful = 0110 Prefetch useful = 0110

= 0001
Memory Memory = 0010 Memory Memory
= 0011
= 0100
Prefetch not useful = 0111 = 0101 Prefetch not useful = 0111

Figure 11-1 Suggested DataSource values

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-369
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.1 Data Source indication

11.1.3 Example use cases

Two examples of how DataSource information can be used by a Requester are:

• To determine the usefulness of a PrefetchTgt transaction in initiating a memory controller prefetch.

— By monitoring the DataSource value in the data returned from the memory SN-F, the Requester can
determine the usefulness of sending PrefetchTgt requests and can modulate the rate, and the sending,
of PrefetchTgt requests.

• Can be used by performance profiling and debug software to evaluate and optimize the data sharing pattern.

11-370 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Debug, Trace, and Monitoring
11.2 SLC replacement hint

11.2 SLC replacement hint

The purpose of this feature is to forward cache replacement hints from the Requesters to the caches in the
interconnect, the System Level Caches (SLC). Typically, a Request Node has the best knowledge of the utility of a
cache line. An SLC that is informed of this knowledge can use it to bias its own replacement algorithms and manage
cache line replacement in a more efficient manner.

11.2.1 Characteristics
Although the replacement information is most useful in CopyBack requests, this feature is not restricted to
CopyBack transactions alone. It is extended to all requests from the Request Node to HN-F, except for the following:
• Atomics
• Stash transactions when StashNIDValid is 1
• PrefetchTgt
• PCrdReturn
• DVMOp

This feature is supported by a 7-bit field called SLCRepHint that is included in the REQ channel. SLCRepHint
includes two subfields, a 3-bit Replacement field and a 1-bit UnusedPrefetch field.

Figure 11-2 shows the placement of the SLCRepHint subfields.

SLCRepHint

6 5 4 3 2 1 0

0 0 0

Replacement[2:0] UnusedPrefetch

Figure 11-2 SLCRepHint subfield placement

The SLCRepHint field shares the same REQ packet location as ReturnNID and StashNID. When the node ID widths
are greater than 7-bit and the field is used as SLCRepHint then the unused bits of the shared field must be set to zero.

Table 11-2 shows the encoding of the UnusedPrefetch subfield.

Table 11-2 UnusedPrefetch subfield encoding

UnusedPrefetch Description

0 The cache line might have been used since being fetched.

1 The cache line was not used since being fetched.

Note
A Request Node that does not track the usage of the cache line can set the UnusedPrefetch bit value to zero.

The SLCRepHint field is only applicable in requests from a Request Node to HN-F.

The field is inapplicable in requests from the Request Node to HN-I and the Home Node to the Subordinate Node.
The field can take any value.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-371
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.2 SLC replacement hint

Table 11-3 shows the suggested Replacement subfield encodings and their meaning.

Table 11-3 Suggested Replacement subfield encodings

Replacement[2:0] Description

0b000 No recommendation (default)

0b100 Most likely to be used again

0b101 More likely to be used again

0b110 Somewhat likely to be used again

0b111 Least likely to be used again

0b011 - 0b001 Unused

11-372 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Debug, Trace, and Monitoring
11.3 MPAM

11.3 MPAM
Memory system Performance Resource Partitioning and Monitoring (MPAM) is a mechanism to efficiently utilize
the memory resources among users and to monitor the utilization of those resources. The resources are partitioned
among users by Partition ID (PartID) and Performance Monitoring Group (PerfMonGroup). A Requester that
supports MPAM includes in each request it sends a label, identifying the partition to which it belongs, together with
the performance monitoring group within that partition. The Home or the Subordinate use this information to
allocate their resources to this request. Support for MPAM on an interface is defined by the MPAM_Support
property, See MPAM_Support on page 16-479.

The MPAM field is applicable only in the REQ and SNP channels:

• On the REQ channel, when a sender does not want to use MPAM for a request, the MPAM values must be
set to default settings. See Default values for MPAM subfields on page 11-374.

• On the SNP channel, MPAM values are only applicable in Stash snoops.
In Non-stash type snoops, MPAM values are inapplicable and must be set to default values.

Field width is either 0 bits or 11 bits:

• The width is zero on interfaces that do not support MPAM.

• The width is 11 bits on interfaces that support MPAM. The field is further divided into the subfields:
— PartID = 9 bits
— PerfMonGroup = 1 bit
— MPAMNS = 1 bit
Figure 11-3 shows the allocation of the MPAM field bits.

10 9 1 0
PartID
PerfMonGroup MPAMNS
MPAM field

Figure 11-3 MPAM subfields bit allocation

It is IMPLEMENTATION DEFINED how the Receiver uses the MPAM field values.

11.3.1 MPAMNS
A Non-secure bit in the MPAM field, this is in addition to and different from the NS bit of the request.

The polarity of the MPAMNS bit encoding is the same as that of the NS bit.

Table 11-4 shows the MPAMNS encodings.

Table 11-4 MPAMNS encodings

MPAMNS Description

0 Secure partition

1 Non-secure partition

All four combinations of values of MPAMNS and NS are permitted.

Note
This change is applied retrospectively to the CHI Issue D and Issue E.a specification.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-373
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.3 MPAM

11.3.2 MPAM value propagation

The Receiver is permitted, but not required, to support the full range of partitions and performance monitor groups
received in the request. It is expected that during the system discovery and configuration process the capabilities of
the system are discovered and the range of partitions and performance monitor groups that are used will match the
capabilities of the system.

MPAM field values must be propagated onto an interface that supports MPAM.

It is permitted, but not required, to propagate MPAM field values onto an interface that does not support MPAM.
Table 11-5 shows the default values for MPAM fields when not supported or not propagated.

Table 11-5 Default values for MPAM subfields

MPAM field Value

PerfMonGroup 0

PartID 0

MPAMNS • Same as NS value in the request message

• Same as NS value in the snoop message

11.3.3 Stash transaction rules

MPAM values in Stash snoops must be the same as in the request that generated the snoops.

For responses to Stash snoops, when the response includes a DataPull request, the Home must assume the MPAM
values in the DataPull request are the same as in the original Stash request.

11.3.4 Request to Subordinate rules

MPAM values in a request to the Subordinate, where the request is generated by a request to the Home, must be the
same as the MPAM values in that request to the Home.

11-374 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Debug, Trace, and Monitoring
11.4 Completer Busy

11.4 Completer Busy

The Completer Busy indication is a mechanism for the Completer of a transaction to indicate its current level of
activity. This signaling provides additional information to a Requester on how aggressive it can be in generating
speculative activity to improve performance.

CBusy Completer Busy. A 3-bit field that is applicable in the appropriate DAT and RSP packets.
When separate Data and Comp responses are used for a single Read request, the Busy indication in
each response can be independently set.

The CBusy field is not applicable in:

• NCBWrData
• NCBWrDataCompAck
• CBWrData
• WriteDataCancel
• CompAck

Note
DataSource can be used as a qualifier to the Completer Busy indication such that some data sources, for example a
Forwarding snoop, do not influence the busy indication.

11.4.1 Use case

It is IMPLEMENTATION DEFINED how a CBusy indication is set by the Completer nor how it should be interpreted by
a Requester. However, it is recommended that implementations consider mechanisms to avoid a few busy
Completers among many skewing the results.

Example use case

The following is an example encoding of the CBusy field.

CBusy[2] When asserted, this indicates multiple cores are actively making requests.

CBusy[1:0] Indicates the degree of fullness of the tracker at the Completer as:
• 00 = Less than 50% full
• 01 = Greater than 50% full
• 10 - Greater than 75% full
• 11 = Greater than 90% full
The prefetcher at the Requester can use the CBusy field values and fine-tune the prefetcher.

Table 11-6 shows the prefetcher mode that is determined by the value of CBusy.

Table 11-6 Prefetcher mode that is determined by CBusy

CBusy[2] CBusy[1:0] Prefetcher mode

1 11 Disable inaccurate prefetchers.

Can take any value 10 Very conservative mode on inaccurate prefetchers.

1 01 Moderately aggressive mode on inaccurate prefetchers.

Can take any value 00 Fully aggressive mode on inaccurate prefetchers.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-375
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.5 Trace Tag

11.5 Trace Tag

This specification includes a TraceTag bit per channel that provides enhanced support for debugging, tracing, and
performance measurement of systems.

11.5.1 TraceTag usage and rules

The rules for when to set and how to propagate TraceTag bit values are:

• The TraceTag bit can be set by the transaction initiator or an interconnect component.

• A component that receives a packet with TraceTag bit set in every received packet must preserve and reflect
the value back in any response packet or spawned packet generated in response to the received packet.
Otherwise, the TraceTag bit in response and spawned packet can take any value. This requirement is true only
when the TraceTag bit in the response packet is applicable. Examples of pairs of such response and received
packets are CompAck in response to multiple CompData packets and Snoop response to the pair of two
DVMOp packets.

• If a received packet spawns multiple responses, such as a Write request resulting in separate Comp and
DBIDResp responses or a Read request generating separate DataSepResp and RespSepData responses, all
such spawned responses are required to have the TraceTag bit set if the spawning packet has the TraceTag bit
set. If the spawning packet does not have the TraceTag bit set, the value of the TraceTag bit in a spawned
packet is independent of the value of the bit in other related spawned packets.

• If a component can receive multiple packets that are associated with a single transaction, then for each packet
that it, in turn, generates, the TraceTag value is only required to be set if it is set in the associated received
packet. For example:
— A Write transaction flow at the Request Node might have write data and CompAck as two responses
for received packets DBIDResp and Comp respectively. As CompAck is in response to the received
Comp only, its TraceTag bit value is only required to depend on the TraceTag bit value in the Comp
packet and similarly for the write data and DBIDResp Response-Received Packet pair.
A request that receives separate DataSepResp and RespSepData responses and generates a CompAck,
is only required to have the TraceTag bit set in CompAck if RespSepData has the TraceTag bit set.
— The TraceTag bit in the NCBWrDataCompAck response from the Request Node must be set if either
one of Comp or DBIDResp that caused the WriteData response have the TraceTag bit set.

• When an interconnect receives a packet with the TraceTag bit set, it must preserve the value and not reset the
value.

Note
• Propagating the value of the TraceTag bit on a resulting cache eviction is IMPLEMENTATION DEFINED.
• The precise mechanism to trigger and utilize the TraceTag bit is IMPLEMENTATION DEFINED.
• It is expected that the TraceTag bit will be limited to single system-wide use at any time.
Some of the ways the trace tag mechanism can be used are:
— Debug, by tracing transaction flows through the system.
— Performance counting
— Latency measurement

Examples, not an exhaustive list, of Request-Response pairs are:

• A Snoop response, with or without data, in response to a Snoop request.
• A Snoop response in response to a SnpDVMOp request.
• Data response from the Subordinate Node in response to a Read request.
• Spawned requests from HN-F:
— Snoops generated in response to a request from the Request Node.
— Request to SN-F generated in response to a request from the Request Node.
• Spawned request from HN-I:
— Read or Write request to SN-I generated in response to a request from the Request Node.
• A CompAck from the Request Node in response to CompData, Comp, or RespSepData.

11-376 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Debug, Trace, and Monitoring
11.5 Trace Tag

• A RetryAck response from the Home Node or the Subordinate Node to any request.
• A ReadReceipt response from the Home Node or the Subordinate Node to a Read request or from the
Subordinate Node to a ReadNoSnpSep request.
• A DBIDResp response to a Write request.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 11-377
ID092622 Non-Confidential
System Debug, Trace, and Monitoring
11.5 Trace Tag

11-378 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 12
Memory Tagging

This chapter describes the Memory Tagging mechanism and contains the following sections:
• Introduction on page 12-380
• Message extensions on page 12-381
• Tag coherency on page 12-382
• Read transaction rules on page 12-383
• Write transactions on page 12-386
• Dataless transactions on page 12-388
• Atomic transactions on page 12-389
• Stash transactions on page 12-390
• Snoop requests on page 12-391
• Home to Subordinate transactions on page 12-393
• Error response on page 12-394
• Requests and permitted tag operations on page 12-396
• TagOp field use summary on page 12-398

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-379
ID092622 Non-Confidential
Memory Tagging
12.1 Introduction

12.1 Introduction
The Memory Tagging Extension (MTE) is a mechanism that is used to check the correct usage of data held in
memory. When a memory location is allocated for a particular use, it can be also assigned a memory tag. This
memory tag is held alongside that data in memory and is referred to as the Allocation Tag. When the memory
location is later accessed, the Requester uses both the address of the location and the tag value that it believes is
associated with the location. This tag is referred to as the Physical Address Tag or Physical Tag.

For any access where tag checking is enabled, the Physical Tag is checked against the Allocation Tag. The access
always progresses as normal, and the result of the tag check determines whether or not an error condition is signaled.

This mechanism ensures that a memory access is for its expected purpose, rather than an erroneous or malicious
access. It can be used at runtime to identify many common programming memory errors, such as buffer-overflow
and use-after-free.

The memory tag consists of a 4-bit tag associated with each aligned 16 bytes of data in memory.

The following behavior is supported:

• Memory tagging is permitted only in requests to Normal WriteBack memory.

• Read transactions have an indication in the transaction request that determines whether the Allocation Tag
value must be returned alongside the data.
Checking of the returned Physical Tag against the Allocation Tag is performed by the Requester.
In the case where a cache holds the data value, but does not hold the Allocation Tag value, then a Read
transaction that returns both data and tag must be performed. The data returned is not required to be valid.

• Read requests that require tags to be fetched must not use Forwarding snoops.

• StashOnce transactions that request Allocation Tags.

The Allocation Tags are expected to be stashed along with the stashing of data.

• Write transactions that have a Physical Tag supplied alongside the write data that must be checked against
the Allocation Tag.
Checking of the Physical Tag against the Allocation Tag is performed by the Completer. In the case of a
mismatch a notification of the failure is required.

• Write transactions that update the Allocation Tag to a new value.

These Write transactions typically update the data at the same time. However, it is permitted to have no BE
asserted so that only the tag is updated.

• Write transactions which pass a Dirty or Clean cache line to a downstream cache or memory controller
without either updating or checking the tags.
These Write transactions always include data and provide an indication whether the Allocation Tag value is
also being passed with the data.

• Snoop transactions that return data can also return the associated Allocation Tag.
If the tags are Dirty, they must be returned. If the tags are Clean, then returning them is optional.

• Cache Maintenance Operations must operate on both the data and the corresponding memory tags.

12-380 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.2 Message extensions

12.2 Message extensions

The following extensions to the CHI message definitions are used to support Memory Tagging:

Tag Provides sets of 4-bit tags, each associated with an aligned 16 bytes of data.
• Applicable on the DAT channel only.
• Size is Data_Width/32 bits.
See Tag on page 13-443.

TU Tag Update. Indicates which of the Allocation Tags must be updated.

• Applicable on the DAT channel only.
• Size is Data_Width/128 bits.
See Tag Update, TU on page 13-443.

TagOp Tag Operation. Indicates the operation to be performed on the tags present in the corresponding
DAT channel.
• Applicable on the REQ, DAT, and RSP channels.
• Size is 2 bits.
• Table 12-1 shows the value encodings.

Table 12-1 TagOp encoding and Tag operations

TagOp[1:0] Tag operation

0b00 Invalid

0b01 Transfer

0b10 Update

0b11 Match or Fetch

See Tag Operation, TagOp on page 13-443.

Note
For clarity, in the following sections TagOp values are italicized to differentiate them from data and
cache line values.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-381
ID092622 Non-Confidential
Memory Tagging
12.3 Tag coherency

12.3 Tag coherency

This section summarizes the tag coherency features.

Allocation Tags that are cached are kept hardware coherent. The coherence mechanism is the same as data
coherence.

Applicable tag cached states are: Invalid, Clean, and Dirty. A cache line that is either Clean or Dirty is Valid.

Constraints on the combination of data cache state and tag cache state are:

• Tags can be Valid only when data is Valid.

• Tags can be Invalid when data is Valid.

• When a cache line is in a Unique state, it applies to both data and tags.

• When a cache line is in a Shared state, it applies to both data and tags.

• When a cache line with Dirty tags is evicted then:

— Both data and tags must be treated as Dirty.
— The tags must be either written back to memory or passed Dirty [_PD] by Home to another cache.

• When Clean tags are evicted from a cache, they can be sent to other caches or dropped silently.

• When Clean tags are evicted with Dirty data, Clean tags can be transferred downstream of PoC along with
Dirty data.

12-382 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.4 Read transaction rules

12.4 Read transaction rules

A read can optionally fetch tags along with the data. The need to return tags along with read data is determined from
the value of TagOp in the request.

12.4.1 TagOp values

When TagOp value in the request is Transfer:

• Tags are required to be returned along with the data.

• The state of the returned tags must be the appropriate permitted cache state for the request being used.

• The number of tags to be returned is determined by the size of Data that is returned. For all Snoopable
requests four tags per access must be returned.

• When required by the access, matching of Physical Tags against the Allocation Tags that are received along
with read data is done at the Requester.

When TagOp value in the Request is Fetch:

• Tags are required to be returned along with data.

• Returned data is not required to be valid. The Requester must ignore the received data irrespective of the tag
match result.

• All tags corresponding to a cache line must be returned.

• The state of the returned tags must be Clean or Dirty.

• If Dirty tags are returned, they must be preserved, unless updated, and written back to memory.

When TagOp value in the request is Invalid:

• It is permitted, but not required, that tags are returned along with the data.
• If tags are returned along with the data, then they must be Clean.

Converting tags from Shared to Unique

To update either the data or the tags or both, when both the data and the tags are present at the Requester in Shared
state and the Requester requires to move the cache line to a Unique state the MakeReadUnique transaction with a
TagOp value of Transfer is expected to be used. The Requester is permitted to use ReadUnique with a TagOp value
of Transfer.

Fetching tags when Data is present

If a Requester has a cached copy of a cache line, with data Valid but Allocation tags are not Valid and the Requester
requires a Tag Match to be performed then the Requester must use a Read request to fetch the required tags. The
type of the Read request and TagOp value in the request depends on:
• The operation being performed by the Requester, that is, a Load or a Store operation.
• The size of the Store operation.
• The target memory location.

A Requester in the above scenario must use:

• ReadClean with Transfer if the operation is a Load operation. The request can be sent from any initial data
state. The initial MTE tag state is expected to be invalid but is permitted to be any state. See Table 4-34 on
page 4-221 for Requester cache state transitions.

• ReadUnique with Transfer if the operation is a Store operation. The request can be sent from any initial data
state. The initial MTE tag state is expected to be invalid but is permitted to be any state. ReadUnique,
irrespective of the existence of MTE can be sent from any initial data state.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-383
ID092622 Non-Confidential
Memory Tagging
12.4 Read transaction rules

• ReadNoSnp with Fetch if the target memory location is Non-snoopable and the Requester guarantees to write
a full cache line irrespective of the Tag Match result. The returned data must be dropped. The returned data
is not required to be valid. Clean tags must be returned. All tags within the cache line must be Valid.

• ReadUnique with Fetch, if the target memory location is Snoopable and the Requester guarantees to write a
full cache line irrespective of result of the Tag Match result. The returned data must be dropped. The returned
data is not required to be valid. Clean or Dirty tags must be returned. All tags within the cache line must be
Valid.

When responding to a ReadClean, a Home that uses a Snoop Filter to track the cached state at the Requester, must
not downgrade the state of the cache line in the Snoop Filter based on the state in the response to the Requester.

Note
In prior issues of this specification, I and UCE were the only permitted initial cache line states for the ReadClean
transaction. The Home that uses a Snoop Filter to track the cached states was permitted to set the state of the cached
line based on the state in the response.

Permitted responses and tag state

The data and state of the cache line received with the Allocation Tags must be appropriately handled to not break
coherency.

When the request TagOp value is Transfer, the permitted response field values are:
• Transfer. Indicates the returned tags are Clean.
• Update. Indicates the returned tags are Dirty. Data response must pass Dirty [_PD].

When the request TagOp value is Fetch, the permitted response field values are:
• Transfer. Indicates the returned tags are Clean.
• Update. Indicates the returned tags are Dirty. Data response must pass Dirty [_PD].

When the request TagOp value is Invalid, the permitted response field values are:
• Invalid. Indicates the returned tags are Invalid.
• Transfer. Indicates the returned tags are Clean.

When the TagOp value in Read data is invalid, TU must be all zeros. Tag is inapplicable and can take any value.

When data and response are separately sent in a Read transaction, the TagOp field is only applicable in the Data-only
message. It is inapplicable in the Non-data response message and must be set to zero.

The cache state that the tags must be held in is consistent with the type of the Read request:

• For all Read requests with a TagOp value of Invalid, Invalid or Clean tags must be returned.

• For ReadNoSnp with a TagOp value of Transfer or Fetch, Clean tags must be returned.

• For ReadOnce and ReadClean with a TagOp value of Transfer, Clean tags must be returned.

• For ReadNotSharedDirty with a TagOp value of Transfer, Clean or Dirty tags must be returned. Dirty tags
are permitted to be returned only if the cache line state is Unique.

• For ReadShared with a TagOp value of Transfer, Clean or Dirty tags must be returned.

• For ReadUnique with a TagOp value of Transfer or Fetch, Clean or Dirty tags must be returned. The returned
cache line state must be Unique.

• For MakeReadUnique with a TagOp value of Invalid, Invalid or Clean tags must be returned. Clean tags are
only permitted in responses with data.

• For MakeReadUnique with a TagOp value of Transfer, if data is included in the response then Clean or Dirty
tags must be returned. To issue a MakeReadUnique with a TagOp value of Transfer, it is required that the
Requester has copies of both the data and the tags.
— Clean tags are only permitted if data is included in the response.

12-384 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.4 Read transaction rules

— Dirty tags are only permitted when the response is transferring the responsibility of updating Dirty
data, that is the response includes [UD_PD].

• In the case where Dirty tags are returned, the cache line returned must include pass Dirty [_PD].

When MTE is not supported for the targeted address, the response must use TagOp of Invalid.

For an Exclusive access sequence, it is important that the fetching of tags must avoid any form of request that will
Invalidate other copies of the cache line before the Exclusive Store transaction is performed. This is typically
achieved by fetching tags at the same time the Exclusive Load transaction is performed.

12.4.2 Permitted initial MTE tag states

Table 12-2 shows the permitted initial data state along with tag state for different Read transactions and permitted
TagOp value in the corresponding request. The combination of tag and data states must obey the coherency rules
described in Tag coherency on page 12-382.

Table 12-2 Permitted initial Tag states and request TagOp values in Read transactions

Request TagOp Data state Tag state

ReadNoSnp Invalid, Transfer, Fetch I Invalid

ReadOnce Invalid, Transfer I, UCE Invalid

ReadNotSharedDirty
ReadShared

ReadClean Invalid I, UCE Invalid

Transfer I, UCE Invalid

SC, UC Invalid, Clean

SD, UD Invalid, Clean, Dirty

ReadPreferUnique Invalid, Transfer I, UCE Invalid

SC Invalid, Clean

SD Invalid, Clean, Dirty

ReadUnique Invalid, Transfer, Fetch I, UCE Invalid

SC, UC Invalid, Clean

SD, UD Invalid, Clean, Dirty

MakeReadUnique Invalid SC Invalid, Clean

SD Invalid, Clean, Dirty

Transfera SC Clean

SD Clean, Dirty

a. The requester has copies of both the data and the tags.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-385
ID092622 Non-Confidential
Memory Tagging
12.5 Write transactions

12.5 Write transactions

Different fields to support MTE are distributed between the Request and Data message of a Write transaction. The
TagOp field, which indicates the operation to be performed on the tags in the WriteData message, is included in both
the Request and WriteData message. The Request also includes the TagGroupID field to provide an identifier for
the pass/fail response for a request that requires a Tag Match operation.

Note
The use of the TagGroupID field is IMPLEMENTATION DEFINED, typically it can be used to identify the Exception
level and TTBR which a response relates to.

The TagOp value in the WriteData message is typically the same as the value in the Request message, except when
either the write data is snooped out or the write is canceled. Whether or not to perform a Tag Match must be decided
based on the TagOp value in the WriteData, when the TagOp values in the WriteData and Write request are different.

The WriteData message also includes a Tag Update (TU) bit per tag, which is applicable when TagOp is Update.

12.5.1 Permitted TagOp values

This section describes the permitted WriteData TagOp values for each of the permitted TagOp values in the Write
request message.

When the TagOp field in the Request is Invalid, the Memory Tagging fields in the WriteData must be set to zero
and ignored by the Completer.

When the TagOp field in the Request is Transfer, the TagOp field in the WriteData can be:
• Transfer: The Tags are Clean and must be handled appropriately by the Completer.
• Invalid: This is possible only if either the cached copy is invalidated, or the Write transaction is canceled.

In a WriteClean transaction where the Request TagOp is Transfer, the TagOp in the Write data is not permitted to
be changed to Update.

When the TagOp field in the request is Update, the TagOp field in the WriteData can be:
• Update: The Dirty tags must be cached or written to memory.
• Transfer: The Tags are Clean. This is possible if the Dirty tags have been snooped out.
• Invalid: This is possible only if either the cached copy is invalidated or the Write transaction is canceled.

When the TagOp field in the Request is Match the TagOp field in the WriteData can be:
• Match: The appropriate Tag Match must be performed at the Completer.
• Invalid: This is possible only if the Write transaction is canceled.

12.5.2 TagOp, TU, and tags relationship

This section describes the relationship between TagOp, TU, and tags in different Write transactions:

• For all Write requests with TagOp Invalid, the Memory Tagging fields must be set to zero and ignored by the
Completer.

• For WriteBackFull and WriteCleanFull with TagOp:

— Transfer: Clean tags must be returned. TU bits are inapplicable and must be set to zero.
— Update: All TU bits must be asserted.
— Match: Not permitted.

• For WriteBackPtl with TagOp:

— Transfer: Not permitted.
— Update: Not permitted.
— Match: Not permitted.

12-386 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.5 Write transactions

• For WriteNoSnpFull with TagOp:

— Transfer: TU bits are inapplicable and must be set to zero. Clean tag transfer is permitted from the
Request Node to the Home Node as well as the Home Node to the Subordinate Node.
— Update: All TU bits must be asserted.
— Match: TU bits are inapplicable and must be set to zero.

• For WriteUniqueFull and WriteUniqueFullStash with TagOp:

— Transfer: Not permitted.
— Update: All TU bits must be asserted.
— Match: TU bits are inapplicable and must be set to zero.

• For WriteNoSnpPtl, WriteUniquePtl and WriteUniquePtlStash with TagOp:

— Transfer: Not permitted.
— Update: Any combination of TU and BE bits, including none or all, can be asserted.
— Match: TU bits are inapplicable and must be set to zero. Tag Match must be performed for only those
tags that have at least one corresponding BE bit asserted.
A Tag Match must not be performed when all BE bits are set to zero.

• For WriteEvictFull, WriteEvictOrEvict and with TagOp:

— Transfer: Clean tags must be returned. TU bits are inapplicable and must be set to zero.
— Update: Not permitted.
— Match: Not permitted.

• For WriteNoSnpZero and WriteUniqueZero, only TagOp Invalid is permitted.

For a Write request with a TagOp of Match the tags within the size wrap boundary can take any value, and the tags
outside of size are inapplicable and can also take any value.

In the WriteDataCancel Write data response, irrespective of the TagOp value in the Write request, the MTE fields
are inapplicable and must be set to zero.

In Write data, with TagOp Invalid, all the TU bits and all the Tag bits must be set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-387
ID092622 Non-Confidential
Memory Tagging
12.6 Dataless transactions

12.6 Dataless transactions

MakeUnique is the only Dataless transaction that supports the use of the TagOp field. In all other Dataless
transactions, the TagOp field is inapplicable and must be set to all zeros.

The TagOp value in MakeUnique request can be Invalid or Update only. A Request TagOp value of Update is an
indication that the Requester will update the tags along with data. Home, in response to MakeUnique, is permitted
to use SnpMakeInvalid only when either the Request TagOp value is Update or the Home knows that the Snoopee
does not have Dirty tags.

The only permitted TagOp value in response to MakeUnique is Invalid.

Cache Maintenance Operations must operate on both the data and the corresponding memory tags. A MakeInvalid
that permits dropping of Dirty data without writing to memory must write Dirty tags to memory.

12-388 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.7 Atomic transactions

12.7 Atomic transactions

TagOp is applicable in Atomic transactions. The permitted values for the field are Invalid and Match.

The Physical Tags to be matched are provided in the write data and correspond to the valid data bytes in
AtomicLoad, AtomicStore, and AtomicSwap. Only one set of tag bits are applicable in these Atomic transactions
because the maximum data size is 8-byte. The remaining tag bits in the set are not applicable and must be set to zero.

In AtomicCompare with a data size of up to 16 byte the valid data still corresponds to only one set of tag bits.

In AtomicCompare with data size of 32-byte the individual compare and swap data is only 16-byte. Only one set of
Physical Tag bits is required to be matched when TagOp is set to Match. Physical Tags must be duplicated to cover
both Compare and Swap data. The Completer is permitted to use either set of Physical Tags to perform Tag Match.

The permitted TagOp values in the CompData response to Non-store Atomic transactions are Invalid and Transfer.

The Write data for Atomic transactions where TagOp is Invalid must have all TU bits and all the Tag bits set to zero.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-389
ID092622 Non-Confidential
Memory Tagging
12.8 Stash transactions

12.8 Stash transactions

In StashOnce and StashOnceSep transactions, TagOp values of Invalid and Transfer are permitted.

For Stash snoop interaction with Memory Tagging see Stash snoops on page 12-392.

12-390 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.9 Snoop requests

12.9 Snoop requests

This section describes the permitted use by Home of the following snoop types:
• Non-forwarding snoops
• Forwarding snoops
• Stash snoops on page 12-392

12.9.1 Non-forwarding snoops

Home can use any applicable Non-forwarding snoop when tags are needed by the request. If the Snoop response
returns data to Home but not tags, the Home is responsible for obtaining tags before returning the Data response to
the Requester.

A Home in response to WriteUniqueFull, WriteUniqueFullStash, MakeUnique, and MakeInvalid must not use the
SnpMakeInvalid snoop request unless either:
• The transaction is WriteUniqueFull, WriteUniqueFullStash, or MakeUnique with a TagOp value of Update.
• The Home can determine that the Snoopee does not hold Dirty tags.

Note
By sending a ReadUnique with TagOp Fetch, a Requester is indicating its willingness to update the full cache line
but not the tags. Home must not use SnpMakeInvalid in response to such a request, to avoid losing modified tags at
the Snoopee.

12.9.2 Forwarding snoops

The use by Home of the Forwarding snoop is permitted only if the request does not need to fetch tags. A Forwarding
snoop is permitted to be sent even when the Snoopee has Valid tags. If the Snoopee has Dirty tags, when responding
to a Forwarding snoop, it must not forward Dirty tags to the Requester nor split dirtiness or uniqueness of tags and
data.

A Snoopee is always permitted to forward Clean tags to the Requester.

When tags are Clean, the Snoopee must follow the same data transfer rules as in the Non-MTE case.

When tags are Dirty the Snoopee must follow the rules:

• For the invalidating Forwarding snoop SnpUniqueFwd and SnpPreferUniqueFwd handled as an invalidating
snoop:
— Must not forward data to the Requester.
— Must return data and tags to the Home.

• For the Non-invalidating Forwarding snoops SnpCleanFwd, SnpSharedFwd, SnpNotSharedDirtyFwd

SnpPreferUniqueFwd handled as a non-invalidating snoop:
— Must treat the snoop as SnpCleanFwd.
Note
Same as SnpNotSharedDirtyFwd.

• For SnpOnceFwd:
— Permitted to return Dirty tags to the Home.
— Dirty tags must be kept at the Snoopee if the data transfer to Home is not performed.
— Dirty tags must be written back to Home if the cache line is being invalidated or Dirty data is being
written back to Home.

A Snoopee is permitted, but not required, to convert any Forwarding snoop to its corresponding Non-forwarding
snoop.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-391
ID092622 Non-Confidential
Memory Tagging
12.9 Snoop requests

Note
This property is similar to that in the Non-MTE case.

See Permitted TagOp values in Snoop responses for more details.

12.9.3 Stash snoops

Because the SNP channel does not include a TagOp field, the Home cannot forward the Requester’s TagOp
intentions to the Stash target.

The permitted TagOp values in Snoop responses are:

• Invalid in response to SnpStash*.
• Invalid, Transfer, and Update in response to SnpUniqueStash.
• Invalid in response to SnpMakeInvalidStash.

See Permitted TagOp values in Snoop responses for more details.

The requirements for determining the TagOp value in the Read request implied from the Data Pull request in the
Snoop response are as follows:

For a Data Pull request in response to SnpStash*:

• If the TagOp value in the original request is Transfer, then it is recommended that Clean tags are returned in
response to the Data Pull request.

• If the TagOp value in the original request is Invalid, then it is recommended that Clean tags are returned in
response to the Data Pull request if tags are available.

For a Data Pull request in response to SnpUniqueStash:

• Irrespective of the presence or absence of data in the Snoop response and for any cache state, it is
recommended that, if tags are available when data is returned, Clean tags are returned in response to a Data
Pull request.

12.9.4 Permitted TagOp values in Snoop responses

The permitted tag field values in Snoop responses are:

• For SnpResp, the TagOp field is inapplicable and must be set to zero.

• For SnpRespDataPtl, the permitted TagOp value is Invalid. Both the TU and the Tag field must be set to zero
and ignored by the receiver.

• For SnpRespData:
— Invalid. All Tag fields must be set to zero.
— Transfer. Clean tags must be returned. TU bits are inapplicable and must be set to zero.
— Update. All TU bits must be asserted. The data state must include Pass Dirty.
— Match. Not permitted.

12-392 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.10 Home to Subordinate transactions

12.10 Home to Subordinate transactions

For a Read request to the Subordinate:
• The permitted TagOp values are Invalid, Transfer, and Fetch.

For a Write request to the Subordinate:

• The permitted TagOp values are Invalid, Transfer, Update, and Match.

For an Atomic request to the Subordinate:

• The permitted TagOp values are Invalid, and Match.

A ReadNoSnp or ReadNoSnpSep with TagOp Transfer or Fetch can be used to fetch tags from the Subordinate.
Tags can be returned from a Subordinate to the Home directly or sent to the Requester using DMT. When TagOp
Fetch is used then the Subordinate is not required to return valid data. TagOp Fetch is permitted only with a data
size of 64 bytes.

When memory needs to be updated with tags, WriteNoSnp with TagOp Update must be used. When only tags need
to be updated, the data byte enables can be set to all zero.

When TagOp is Match, the TagGroupID in WriteNoSnp and Atomic transactions to the Subordinate are applicable,
and these values must be returned in the TagMatch response.

When Atomic operations are performed at the Subordinate Node, the Home is permitted to include TagOp Match
in Atomic requests to the Subordinate. Where the tag match is performed at the Subordinate, in both non-Store
Atomic and Store Atomic transactions, the TagMatch response TgtID must be obtained from the ReturnNID value
in the request. To support this feature, it is required that the ReturnNID in the Atomic Store from a Home Node to
a Subordinate Node is applicable and must be set to the same value as the SrcID in the request.

Note
Applicability of the ReturnNID in non-Store Atomic transactions is already a requirement in the previous version
of this specification.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-393
ID092622 Non-Confidential
Memory Tagging
12.11 Error response

12.11 Error response

The following sub-sections describe Error response handling for:
• Tag Match
• Non-Tag Match errors
• MTE not supported on page 12-395

12.11.1 Tag Match

Write and Atomic transactions that have TagOp value of Match must return the results of the Tag Match operation.
The results are returned using the TagMatch message. The transaction must proceed as normal irrespective of the
Tag Match result. The TagMatch response must be sent even if the WriteData is canceled or a Tag Match is not
performed.

Note
Using a separate TagMatch message adds complexity and extra messages to the Write and Atomic transactions but
has the advantage that it provides a sufficiently accurate response mechanism. Using a separate response does not
delay the sending of the Comp response.

The TagMatch message characteristics are:

• It is sent by the Completer performing the Tag Match operation. This can be a Home Node or a Subordinate
Node.

• The TgtID value in the message is copied from:

— SrcID in the request if the Completer is a Home Node.
— ReturnNID in the request if the Completer is a Subordinate Node. The ReturnNID can point to the
Requester or the Home. When the Subordinate returns the TagMatch response to the Home, if required
by the transaction, the Home is responsible for forwarding the response to the Requester.

• The response must return the TagGroupID value from the request.

• The TraceTag field is inapplicable and can take any value.

• The Resp field value in the response indicates the Tag Match state as either pass or fail. See Response status,
Resp on page 13-444.

• The TagMatch response can be sent as soon as the Completer can determine the result. TagMatch is permitted
to be sent without waiting for data. This can occur when the Completer does not support MTE.

• The Resp value in the TagMatch response must be:

— A Fail when MTE is not supported.
— A Pass when MTE is supported but the Tag Match is not performed. For example, when an Exclusive
write fails and the Tag Match is not performed.
— Accurate, if the match is performed.

12.11.2 Non-Tag Match errors

Permitted Data and Non-data error responses to requests are independent of the presence or absence of Memory
Tagging.

Permitted RespErr field values in the TagMatch response are OK, DERR, and NDERR. See Error response use by
transaction type on page 9-345.

When the RespErr field in a response is NDERR then:

• The TagOp in the response to the Requester is inapplicable and can take any value.
• The Snoop response must be Invalid.

Poison on tags is not supported. See Poison on page 9-355.

12-394 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.11 Error response

12.11.3 MTE not supported

When a Completer does not support MTE for the address in the request, the Completer must send a TagOp value of
Invalid in response to a Read transaction with a TagOp value of Transfer or Fetch. The returned tags must be set to
zero. The returned tags can be cached as Clean by the Requester.

A Completer in response to a Read request to a Non-cacheable or Device memory location must set the TagOp value
in the response to Invalid. A Completer is expected to give an OK response on RespErr to an MTE operation, unless
it would have given a different response to an equivalent non-MTE operation.

When a Write request with TagOp Match is received and a Completer does not support MTE for the address in the
request, the Completer is still required to send a TagMatch response. The Resp field value must indicate that the Tag
Match failed. The Completer is permitted, but not required, to wait for the write data before sending the TagMatch
response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-395
ID092622 Non-Confidential
Memory Tagging
12.12 Requests and permitted tag operations

12.12 Requests and permitted tag operations

Table 12-3 shows a summary of the permitted TagOp field values in the different requests. The following key is
used:
Y Yes, permitted
N No, not permitted

Table 12-3 Permitted TagOp values for each request type

Tag operation
Requests
Invalid Transfer Update Match Fetch

ReadOnce Y Y N N N
ReadClean
ReadShared
ReadNotSharedDirty
ReadPreferUnique

ReadUnique Y Y N N Y

ReadNoSnp Y Y N N Y
ReadNoSnpSep

ReadOnceInvalid Y N N N N

MakeReadUnique Y Y N N N

CleanShared Y N N N N
CleanSharedPersist
CleanSharedPersistSep

CleanUnique Y N N N N
CleanInvalid
MakeInvalid

MakeUnique Y N Y N N

Evict Y N N N N

StashOnceUnique Y Y N N N
StashOnceSepUnique
StashOnceShared
StashOnceSepShared

WriteNoSnpFull Y Y Y Y N

WriteUniqueFull Y N Y Y N
WriteUniqueFullStash

WriteNoSnpPtl Y N Y Y N
WriteUniquePtl
WriteUniquePtlStash

WriteBackFull Y Y Y N N
WriteCleanFull

WriteBackPtl Y N N N N

12-396 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.12 Requests and permitted tag operations

Table 12-3 Permitted TagOp values for each request type (continued)

Tag operation
Requests
Invalid Transfer Update Match Fetch

WriteEvictFull Y Y N N N
WriteEvictOrEvict

WriteNoSnpFull+(P)CMO Y Y Y N N

WriteNoSnpPtl+(P)CMO Y N Y N N

WriteUniqueFull+(P)CMO Y N N N N

WriteUniquePtl+(P)CMO Y N N N N

WriteBackFull+(P)CMO Y Y Y N N

WriteCleanFull+(P)CMO Y Y Y N N

WriteNoSnpZero Y N N N N

WriteUniqueZero Y N N N N

Atomic* Y N N Y N

PrefetchTgt Y Y N N N

PCrdReturn Y N N N N
DVMOp

The TagOp field in ReqLCrdReturn, DatLCrdReturn, and RspLCrdReturn is inapplicable and can take any value.

The Tag and TU fields in DatLCrdReturn are inapplicable and can take any value.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-397
ID092622 Non-Confidential
Memory Tagging
12.13 TagOp field use summary

12.13 TagOp field use summary

The following sections give a summary of the use of the TagOp field in messages in different channels:

REQ channel message:

• Read* and MakeReadUnique transaction:

— TagOp field can be Invalid, Transfer, or Fetch.
— TagOp Fetch is permitted only in ReadUnique, ReadNoSnp, and ReadNoSnpSep transactions.
— TagOp field Transfer indicates whether Allocation Tags must be returned alongside read data.
— TagOp field Fetch indicates only valid tags are required to be returned. Returned data is not required
to be valid.

• Write transaction:
— TagOp field can be Invalid, Transfer, Match or Update.
— TagOp field Transfer indicates Clean tags are being transferred and tags can be cached alongside the
data.
— TagOp field Match indicates a Match check is required between the Physical Tags in the message and
the Allocation Tags at the memory location.
— TagOp field Update indicates Dirty tags are being passed, which must update the Allocation Tag
values.

• MakeUnique transaction:
— TagOp field can be Invalid or Update.
— TagOp field Update indicates all tags will be written to.

• Atomic transaction:
— TagOp field can be Invalid or Match.
— TagOp field Match indicates whether a Tag Match is required.

• StashOnce transaction:
— TagOp field can be: Invalid or Transfer.
— TagOp field Transfer indicates whether Allocation Tags should be stashed alongside Stash data.

• PrefetchTgt transaction:
— TagOp value can be Invalid or Transfer.

• For all the other REQ channel messages, the TagOp field is inapplicable and must be zero.

DAT channel message:

• For Read data, the TagOp field indicates whether the Allocation Tags sent along with the data are Invalid,
Clean, or Dirty.

• For Snoop data, the TagOp field indicates whether the Allocation Tags sent in the Snoop response are Invalid,
Clean, or Dirty.

• For write data, the TagOp field indicates whether the Allocation Tags sent in the write data are Invalid, Clean,
Dirty, or a Match check is required. The TagOp value must be the same as in the Request message except
when a snoop has downgraded the state of the tags or the write has been canceled.

RSP channel message:

• For a Comp response, the TagOp field is only used in response to a MakeReadUnique transaction and is used
to indicate if responsibility for Dirty tags is being passed to the Requester.

• For all other RSP channel messages, the TagOp field is inapplicable and must be zero.

12-398 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Memory Tagging
12.13 TagOp field use summary

SNP message:

• The TagOp field is not present in the SNP channel.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 12-399
ID092622 Non-Confidential
Memory Tagging
12.13 TagOp field use summary

12-400 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 13
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 13-402
• Link on page 13-403
• Flit on page 13-404
• Channel on page 13-405
• Port on page 13-407
• Node interface definitions on page 13-408
• Increasing inter-port bandwidth on page 13-410
• Channel interface signals on page 13-414
• Flit packet definitions on page 13-418
• Protocol flit fields on page 13-424
• Link flit on page 13-450

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-401
ID092622 Non-Confidential
Link Layer
13.1 Introduction

13.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 and flow control across a link.

Figure 13-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 13-1 System using link based communication

Interface parity signals, which are discussed in Use of interface parity on page 9-357, are not included in this
chapter.

13-402 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.2 Link

13.2 Link
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 13-2 shows the link
requirements.

Node Interconnect
Transmitter Receiver
Link 1
(TX) (RX)
Receiver Transmitter
Link 2
(RX) (TX)

Figure 13-2 Two-way link communication

13.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 13-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 13-3 Outbound and inbound links

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-403
ID092622 Non-Confidential
Link Layer
13.3 Flit

13.3 Flit
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.

13-404 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.4 Channel

13.4 Channel
In this specification, the Link layer provides a set of channels for flit communication.

Each channel has a defined flit format that has multiple fields and some of the field widths have multiple possible
values. In some cases, the defined flit format can be used on both an inbound and an outbound channel.

Table 13-1 shows the channels, and the mapping onto the Request Node and Subordinate Node component
channels.

Table 13-1 Channels’ mapping onto the RN and SN component 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 requests
and Write requests. See Request, REQ,
channel on page 13-414.

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 Response, RSP, Acknowledge
channel on page 13-415.

SNP The snoop channel transfers flits associated All Snoop requests RXSNP -
Snoop with Snoop and SnpDVMOp Request
messages. See Snoop, SNP, channel on
page 13-416.

DAT The data channel transfers flits associated WriteData, and Snoop response data TXDAT RXDAT
Data with protocol messages that have a data from an RN
payload such as read completion and
WriteData messages. See Data, DAT, Read data RXDAT TXDAT
channel on page 13-417.

13.4.1 Channel dependencies

The following dependencies are permitted between the channels in the protocol.

For a Request Node:

• Must make forward progress on the inbound SNP channel without requiring forward progress on outbound
REQ channel.

• Permitted, but not required, to wait for forward progress on the outbound RSP channel before making
forward progress on the inbound SNP channel.

• Permitted, but not required, to wait for forward progress on the outbound DAT channel before making
forward progress on the inbound SNP channel.

• Must make forward progress on the inbound RSP channel without requiring forward progress on any other
channel.

• Must make forward progress on the inbound DAT channel without requiring forward progress on any other
channel.

Note
The requirement that a Request Node must make forward progress on the inbound RSP and DAT channel, without
requiring forward progress on any other channel, means that a Request Node must be able to accept all Comp and
CompData responses for outstanding transactions without sending any CompAck responses.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-405
ID092622 Non-Confidential
Link Layer
13.4 Channel

For a Subordinate Node:

• Permitted, but not required, to wait for forward progress on the outbound RSP channel before making
forward progress on the inbound REQ channel.

• Must make forward progress on the inbound REQ channel without requiring forward progress on the
outbound DAT channel.

• Must make forward progress on the inbound DAT channel without requiring forward progress on any other
channel.

13-406 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.5 Port

13.5 Port
A Port is defined as the set of all links at the interface of a node.

Figure 13-4 shows the relationship between links, channels, and port. See Node interface definitions on page 13-408
for the specific node requirements, See Channel interface signals on page 13-414, and Chapter 14 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 13-4 Relationship between links, channels, and port

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-407
ID092622 Non-Confidential
Link Layer
13.6 Node interface definitions

13.6 Node interface definitions

The nodes exchange messages by sending flits across the node interface. This section describes two node types of
node interfaces supported in this specification:
• Request Nodes
• Subordinate Nodes on page 13-409

Note
The LINKACTIVE interface pins and signals used by each node for link management are described in Chapter 14
Link Handshake.

13.6.1 Request Nodes

This section describes the Request Node interfaces:
• RN-F
• RN-D
• RN-I on page 13-409

RN-F
The RN-F interface uses all channels and is used by a fully coherent Requester such as a core or cluster. Figure 13-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 13-5 RN-F interface

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 transactions. See DVM transaction flow on page 8-314 for details. Figure 13-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 13-6 RN-D interface

13-408 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.6 Node interface definitions

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 13-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 13-7 RN-I interface

13.6.2 Subordinate Nodes

This section describes the Subordinate Node interfaces, SN-F and 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 13-8
shows the SN-F and SN-I interface.

ICN
SN-F - SN-I

TXREQ REQ RXREQ

RXRSP RSP TXRSP
RXDAT DAT TXDAT
TXDAT DAT RXDAT

Figure 13-8 SN-F and SN-I interface

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-409
ID092622 Non-Confidential
Link Layer
13.7 Increasing inter-port bandwidth

13.7 Increasing inter-port bandwidth

The available bandwidth at a node interface can be increased in several ways. Two architectural methods permitted
are detailed in the following sections:
• Multiple interfaces
• Replicated channels on a single interface on page 13-412

13.7.1 Multiple interfaces

The simplest method for a component to increase the available bandwidth is to have multiple interfaces. A complete
interface can be duplicated. The number of times an interface on a node is duplicated is IMPLEMENTATION DEFINED.

Figure 13-9 shows an example of duplicated interfaces.

RN-F
TXREQ REQ
RXRSP RSP

Interface 1
RXDAT DAT
RXSNP SNP
TXRSP RSP
TXDAT DAT

TXREQ REQ
RXRSP RSP

Interface 2
RXDAT DAT
RXSNP SNP
TXRSP RSP
TXDAT DAT

Figure 13-9 Multiple interface example

The main features of this method of increasing bandwidth across two interfaces are:
• Each interface has its own:
— NodeID
— TxnID pool
— Set of SACTIVE signals
— Set of LINKACTIVE signals
— Set of SYSCOREQ/SYSCOACK signals
— Set of optional broadcast control pins
• Each duplicate interface must be treated as an independent interface:
— If one interface allocates the cache line, another duplicate interface cannot deallocate that cache line.
— When responding to a request, the Completer must send the response on the same interface as the one
used by the request.
— A snoop must be sent to the same interface that was used for the transaction that caused the allocation
of a cache line.
— A transaction from one interface must make forward progress without requiring forward progress of a
transaction on a duplicate interface.
• All channels must be replicated even when only a subset of the channels needs increased bandwidth.

13-410 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.7 Increasing inter-port bandwidth

Address striping
This specification permits an optional optimization where a Request Node can specify the address striping that it
will use to select between multiple interfaces. This can be specified for any number of interfaces.

A Request Node is permitted to use address striping to guide its requests to the appropriate interface without
declaring the striping algorithm being used.

A Home Node typically can filter snoops based on a snoop filter. If the snoop filter is precise, it can track the Node
ID of the Requester that cached the cache line and send a snoop for a subsequent request to the same cache line on
a single interface. A snoop filter that does not track precisely or is sized to the number of components in the system
instead of the number of Request Node interfaces will not be able to isolate the single interface it needs to send the
snoop on, unless the snoop filter knows and uses the same address striping algorithm as the Requester.

When a Request Node does not declare the striping algorithm it is using, the snoop filters either need to be larger or
the Home will have to send redundant snoops. It is recommended that a Request Node that uses address striping
advertises the striping algorithm so that the Home Nodes can make use of it.

The address striping used by a Request Node can be specified by a hash function.

Hash function example

This section describes a suggested hash function to be used to distribute requests across multiple REQ interfaces.
The same hash function can be used to distribute snoops across multiple available SNP interfaces. The steps in
generating the interface number are:

1. The cache line aligned input address is first filtered through a predefined Hash Mask. The most significant
address bits that are not used must be set to all zero before filtering the address. In this example, the result of
the filtering is Mask_Result.

2. The individual bits of Mask_Result are XORed to obtain the target interface.

Where the number of interfaces is a power-of-two:

• For 2 interfaces:
Interfaces[0] = Mask_Result[n-1] ^ Mask_Result[n-2] ... Mask_Result[7] ^ Mask_Result[6]

• For 4 interfaces:
Interfaces[1:0] = Mask_Result[n-1:n-2] ^ Mask_Result[n-3:n-4] ... Mask_Result[9:8] ^ Mask_Result[7:6]

• For 8 interfaces:
Interfaces[2:0] = Mask_Result[n-1:n-3] ^ Mask_Result[n-4:n-6] ... Mask_Result[11:9] ^ Mask_Result[8:6]

This example does not cover the situation where the number of interfaces is not a power-of-two.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-411
ID092622 Non-Confidential
Link Layer
13.7 Increasing inter-port bandwidth

13.7.2 Replicated channels on a single interface

Rather than replicating a complete interface through more complex methods, a more efficient method to increase
the available interface bandwidth is to selectively replicate the channels that require greater bandwidth.

Figure 13-10 shows an example of replicated channels.

RN-F
TXREQ0 REQ0
TXREQ1 REQ1
RXRSP0 RSP0

Single interface
RXRSP1 RSP1
RXDAT0 DAT0
RXDAT1 DAT1
RXSNP0 SNP0
TXRSP0 RSP0
TXDAT0 DAT0
TXDAT1 DAT1

Figure 13-10 Replicated channels example

Features
The main features of this method of increasing available bandwidth are described in this section.

Each channel can be selectively replicated. There are no restrictions on which channels are replicated. Typically,
replication of a channel is based on the expected bandwidth required on that channel. For example, in Figure 13-10,
TXREQ is duplicated as TXREQ0, TXREQ1, whereas RXSNP is not duplicated and has only RXSNP0. The
characteristics of the replicated channel interface are:

• All replicated DAT subchannels corresponding to a single DAT channel must be of the same width.

• The complete interface must use:

— The same NodeID
— A single TxnID pool

• Messages within a transaction can use any subchannel:

— A response message does not need to use the same subchannel as the request. For example, Request
on TXREQ0 can give a response on either RXRSP0 or RXRSP1.
— Multiple response messages for a single request can come on any subchannel. For example,
DBIDResp for a write transaction is received on RXRSP0 whereas the corresponding Comp can be
received on RXRSP1.

• Like non-replicated channels, replicated channels do not provide any in-channel ordering guarantees.

• All link crediting is done on a subchannel basis.

— Cannot use the credit for TXREQ0 to send the flit on TXREQ1.
— Credits are required to be provided by the Receiver on all subchannels.

• Protocol credits are for the combined TXREQ channel.

• There is no support for powering down a subchannel individually.

• The two parts of a DVM snoop can come on either subchannel. Each part can be on a different subchannels.

• The number of subchannels on two connected interfaces must match.

13-412 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.7 Increasing inter-port bandwidth

• There must be only one set of SACTIVE, LINKACTIVE, and SYSCOREQ/SYSCOACK signals, and
optional broadcast control pins.

• Interface property CCF_Wrap_Order is not permitted to be set to True when the interface includes replicated
DAT channels.

Note
When a channel has been replicated on an interface, it is IMPLEMENTATION DEFINED which of the subchannels is
used for a transfer.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-413
ID092622 Non-Confidential
Link Layer
13.8 Channel interface signals

13.8 Channel interface signals

This section describes the channel interfaces. It contains the following sections:
• Request, REQ, channel
• Response, RSP, channel on page 13-415
• Snoop, SNP, channel on page 13-416
• Data, DAT, channel on page 13-417

13.8.1 Request, REQ, channel

Figure 13-11 shows the REQ channel interface pins, where R is the width of REQFLIT.

Transmitter Receiver
TXREQFLITPEND REQFLITPEND RXREQFLITPEND
TXREQFLITV REQFLITV RXREQFLITV
TXREQFLIT REQFLIT[(R-1):0] RXREQFLIT

TXREQLCRDV REQLCRDV RXREQLCRDV

Figure 13-11 REQ channel interface pins

Table 13-2 shows the REQ channel interface signals.

Table 13-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 14-455.

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 13-418 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 14-453.

13-414 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.8 Channel interface signals

13.8.2 Response, RSP, channel

Figure 13-12 shows the RSP channel interface pins, where T is the width of RSPFLIT. The same interface is used
for both inbound and outbound RSP channels.

Transmitter Receiver
TXRSPFLITPEND RSPFLITPEND RXRSPFLITPEND
TXRSPFLITV RSPFLITV RXRSPFLITV
TXRSPFLIT RSPFLIT[(T-1):0] RXRSPFLIT

TXRSPLCRDV RSPLCRDV RXRSPLCRDV

Figure 13-12 RSP channel interface pins

Table 13-3 shows the RSP channel interface signals.

Table 13-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 14-455.

RSPFLITV Response Flit Valid. The transmitter sets this signal HIGH to indicate when RSPFLIT[(T-1):0] is
valid.

RSPFLIT[(T-1):0] Response Flit. See Response flit on page 13-420 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 14-453.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-415
ID092622 Non-Confidential
Link Layer
13.8 Channel interface signals

13.8.3 Snoop, SNP, channel

Figure 13-13 shows the SNP channel interface pins, where S is the width of SNPFLIT.

Transmitter Receiver
TXSNPFLITPEND SNPFLITPEND RXSNPFLITPEND
TXSNPFLITV SNPFLITV RXSNPFLITV
TXSNPFLIT SNPFLIT[(S-1):0] RXSNPFLIT

TXSNPLCRDV SNPLCRDV RXSNPLCRDV

Figure 13-13 SNP channel interface pins

Table 13-4 shows the SNP channel interface signals.

Table 13-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 14-455.

SNPFLITV Snoop Flit Valid. The transmitter sets this signal HIGH to indicate when SNPFLIT[(S-1):0] is
valid.

SNPFLIT[(S-1):0] Snoop Flit. See Snoop flit on page 13-421 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 14-453.

13-416 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.8 Channel interface signals

13.8.4 Data, DAT, channel

Figure 13-14 shows the DAT channel interface pins, where D is the width of DATFLIT. 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 13-14 DAT channel interface pins

Table 13-5 shows the DAT channel interface signals.

Table 13-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 14-455.

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 13-422 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 14-453.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-417
ID092622 Non-Confidential
Link Layer
13.9 Flit packet definitions

13.9 Flit packet definitions

This section defines the flit format. See:
• Request flit
• Response flit on page 13-420
• Snoop flit on page 13-421
• Data flit on page 13-422

13.9.1 Request flit

Table 13-6 shows the Request flit format in a REQ channel packet starting at bit zero. The following key is used:

SBZ Should Be Zero

Table 13-6 Request flit format

REQFLIT[(R-1):0] format

Field Field width Comments

QoS 4 -

TgtID 7 to 11 Width determined by NodeID_Width

SrcID 7 to 11 Width determined by NodeID_Width

TxnID 12 -

ReturnNID 7 to 11 Used for DMT

StashNID Used in Stash transactions
{(NodeID_Width - 7)’b0, SBZ
SLCRepHint[6:0]} Used in cache line replacement algorithms

StashNIDValid 1 Used in Stash transactions

Endian Used in Atomic transactions
Deep Used in CleanSharedPersist* transactions

ReturnTxnID[11:0] 12 Used for DMT

{6’b0, SBZ
StashLPIDValid, Used in Stash transactions
StashLPID[4:0]} Used in Stash transactions

Opcode 7 -

Size 3 -

Addr RAW = 44 to 52 Width determined by Req_Addr_Width (RAW)

NS 1 -

LikelyShared 1 -

AllowRetry 1 -

Order 2 -

PCrdType 4 -

MemAttr 4 -

13-418 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.9 Flit packet definitions

Table 13-6 Request flit format (continued)

REQFLIT[(R-1):0] format

Field Field width Comments

SnpAttr 1 -
DoDWT Used for DWT

{3’b0, 8 SBZ
LPID[4:0]} -
PGroupID[7:0] Used in Persistent CMO transactions
StashGroupID[7:0] Used in the StashOnceSep transaction
TagGroupID[7:0] Used for Memory Tagging

Excl 1 Used in Exclusive transactions

SnoopMe Used in Atomic transactions

ExpCompAck 1 -

TagOp 2 -

TraceTag 1 -

MPAM M=0 No MPAM bus

M = 11 -

RSVDC Y=0 No RSVDC bus

Y = 4, 8, 12, 16, -
24, 32

Total R= (87 + RAW +

M + Y) to
(99 + RAW + M +
Y)

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-419
ID092622 Non-Confidential
Link Layer
13.9 Flit packet definitions

13.9.2 Response flit

Table 13-7 shows the Response flit format in a RSP channel packet starting at bit zero,

Table 13-7 Response flit format

RSPFLIT[(T-1):0] format

Field Field width Comments

QoS 4 -

TgtID 7 to 11 Width determined by NodeID_Width

SrcID 7 to 11 Width determined by NodeID_Width

TxnID 12 -

Opcode 5 -

RespErr 2 -

Resp 3 -

FwdState[2:0] 3 Used for DCT

DataPull[2:0] Used in Stash transactions

CBusy 3 -

DBID[11:0] 12 -
{4’b0, SBZ
PGroupID[7:0]} Used in Persistent CMO transactions
{4’b0, SBZ
StashGroupID[7:0]} Used in Stash transactions
{4’b0, SBZ
TagGroupID[7:0]} Used for Memory Tagging

PCrdType 4 -

TagOp 2 -

TraceTag 1 -

Total T = 65 to 73 -

13-420 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.9 Flit packet definitions

13.9.3 Snoop flit

Table 13-8 shows the Snoop flit format in a SNP channel packet starting at bit zero.

Table 13-8 Snoop flit format

SNPFLIT[(S-1):0] format

Field Field width Comments

QoS 4 -

SrcID 7 to 11 Width determined by NodeID_Width

TxnID 12 -

FwdNID 7 to 11 Width determined by NodeID_Width

FwdTxnID[11:0] 12 Used for DCT

{6’b0, SBZ
StashLPIDValid, Used in Stash transactions
StashLPID[4:0]} Used in Stash transactions
{4’b0, SBZ
VMIDExt[7:0]} Used in DVM transactions

Opcode 5 -

Addr SAW = 41 to 49 Req_Addr_Width - 3

NS 1 -

DoNotGoToSD 1 -

RetToSrc 1 -

TraceTag 1 -

MPAM M=0 No MPAM bus

M = 11 -

Total S = 51 + SAW + M to -
59 + SAW+ M

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-421
ID092622 Non-Confidential
Link Layer
13.9 Flit packet definitions

13.9.4 Data flit

Table 13-9 shows the Data flit format in a DAT channel packet starting at bit zero.

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-144.

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.

DataCheck (DC) field width is either zero or equal to the width of the Data field divided by 8.

Poison (P) field width is either zero or equal to the width of the Data field divided by 64.

Table 13-9 Data flit fields

DATFLIT[D-1:0] format

Field Field Width Comments

QoS 4 -

TgtID 7 to 11 Width determined by NodeID_Width

SrcID 7 to 11 Width determined by NodeID_Width

TxnID 12 -

HomeNID 7 to 11 Width determined by NodeID_Width

Opcode 4 -

RespErr 2 -

Resp 3 -

{1’b0, 4 SBZ
FwdState[2:0]} Used for DCT
{1’b0, SBZ
DataPull[2:0]} Used in Stash transactions
DataSource[3:0] Indicates Data source in a response

CBusy 3 -

DBID[11:0] 12 -

CCID 2 -

DataID 2 -

TagOp 2 -

Tag DW/32 = 4, 8, 16 -

TU DW/128 = 1, 2, 4 -

TraceTag 1 -

RSVDC Y=0 No RSVDC bus

Y = 4, 8, 12, 16, 24, 32 -

BE DW/8 = 16, 32, 64 -

Data DW = 128, 256, 512 DW = Data bus width

13-422 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.9 Flit packet definitions

Table 13-9 Data flit fields (continued)

DATFLIT[D-1:0] format

Field Field Width Comments

DataCheck (DC) 0 or DW/8 = 16, 32, 64 -

Poison (P) 0 or DW/64 = 2, 4, 8 -

Total D = (221 to 233) + Y + DC + P DW = 128 bit Data

D = (370 to 382) + Y + DC + P DW = 256 bit Data

D = (668 to 680) + Y + DC + P DW = 512 bit Data

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-423
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10 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:
• Quality of Service, QoS on page 13-425
• Target Identifier, TgtID on page 13-425
• Source Identifier, SrcID on page 13-425
• Home Node Identifier, HomeNID on page 13-425
• Return Node Identifier, ReturnNID on page 13-425
• Forward Node Identifier, FwdNID on page 13-425
• Logical Processor Identifier, LPID on page 13-426
• Persistence Group Identifier, PGroupID on page 13-426
• Stash Node Identifier, StashNID on page 13-426
• Stash Node Identifier Valid, StashNIDValid on page 13-427
• Stash Logical Processor Identifier, StashLPID on page 13-427
• Stash Logical Processor Identifier Valid, StashLPIDValid on page 13-427
• Stash Group Identifier, StashGroupID on page 13-427
• Transaction Identifier, TxnID on page 13-428
• Return Transaction Identifier, ReturnTxnID on page 13-428
• Forwarding Transaction Identifier, FwdTxnID on page 13-428
• Data Buffer Identifier, DBID on page 13-428
• Channel opcodes, Opcode on page 13-429
• Deep persistence, Deep on page 13-434
• Address, Addr on page 13-435
• Non-secure, NS on page 13-435
• Size of transaction data, Size on page 13-435
• Memory Attribute, MemAttr on page 13-437
• Snoop Attribute, SnpAttr on page 13-437
• Do Direct Write Transfer, DoDWT on page 13-438
• Likely Shared, LikelyShared on page 13-438
• Ordering requirements, Order on page 13-438
• Exclusive, Excl on page 13-440
• Endian on page 13-440
• Allow Retry, AllowRetry on page 13-440
• Expect Completion Acknowledge, ExpCompAck on page 13-441
• SnoopMe on page 13-441
• Return to Source, RetToSrc on page 13-441
• Data Pull, DataPull on page 13-441
• Do not transition to SD state, DoNotGoToSD on page 13-442
• Protocol Credit Type, PCrdType on page 13-442
• Tag Operation, TagOp on page 13-443
• Tag on page 13-443
• Tag Update, TU on page 13-443
• Tag Group Identifier, TagGroupID on page 13-443
• Trace Tag, TraceTag on page 13-444
• Memory System Performance Resource Partitioning and Monitoring, MPAM on page 13-444
• Virtual Machine Identifier Extension, VMIDExt on page 13-444
• Response status, Resp on page 13-444
• Forward State, FwdState on page 13-446
• Completer Busy, CBusy on page 13-446
• Response Error, RespErr on page 13-447

13-424 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

• Data payload, Data on page 13-447

• Critical Chunk Identifier, CCID on page 13-447
• Data Identifier, DataID on page 13-448
• Byte Enable, BE on page 13-448
• Data check, DataCheck on page 13-448
• Poison on page 13-448
• Data source, DataSource on page 13-449
• System Level Caches Replacement Hint, SLCRepHint on page 13-449
• Reserved for Customer Use, RSVDC on page 13-449

13.10.1 Quality of Service, QoS

This field is used to assign a Quality of Service (QoS) value to a transaction. Ascending values of QoS indicate
higher priority levels. See Chapter 10 Quality of Service.

13.10.2 Target Identifier, TgtID

This field is the NodeID of the component to which the message is targeted. This is used by the interconnect to
determine the port to which the message is sent. See Target Identifier, TgtID, and Source Identifier, SrcID on
page 2-93.

13.10.3 Source Identifier, SrcID

This field is the NodeID 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 sent. See Target Identifier, TgtID, and Source Identifier, SrcID
on page 2-93.

13.10.4 Home Node Identifier, HomeNID

This field is associated with the original request. The Requester uses the value in this field to determine the TgtID
of the CompAck to be sent in response to CompData. See Home Node Identifier, HomeNID on page 2-97.

Applicable in CompData and DataSepResp.

Inapplicable and must be zero in all other Data messages.

13.10.5 Return Node Identifier, ReturnNID

This field identifies the node to which the Subordinate sends a CompData, DataSepResp, or Persist response. This
field also indicates the node to which the Subordinate sends DBIDResp when DoDWT = 1. The value can be either
the Node ID of Home or the Requester that originated the transaction. See Return Node Identifier, ReturnNID on
page 2-96.

Applicable from Home to Subordinate in ReadNoSnp, ReadNoSnpSep, CleanSharedPersistSep, WriteNoSnp,

Combined Write, and Atomic requests.

Inapplicable and must be zero for all other requests. For Stash requests, the same bits in the packet are used for
StashNID.

13.10.6 Forward Node Identifier, FwdNID

This field identifies the Requester to which the CompData response can be forwarded. The value must be the
NodeID of the Requester that initiated the transaction. See Forward Node Identifier, FwdNID on page 2-98.

Applicable in Forward-type snoops.

Inapplicable and must be zero in all other Snoop requests, except range-based TLBI DVM operations.

In range-based TLBI DVM operations, the bits in the field are used for DVM payload.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-425
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.7 Logical Processor Identifier, LPID

This field is used when a single Requester contains more than one logically separate processing agent. The SrcID
is used with LPID to uniquely identify the logical processor that generated the request.

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
— ReadNotSharedDirty
— ReadPreferUnique
— MakeReadUnique
— CleanUnique
— ReadNoSnp
— WriteNoSnp
See Chapter 6 Exclusive accesses for further details.

In requests, when applicable, the same bits in the packet are used for TagGroupID, PGroupID, and StashGroupID.

For other transactions, the LPID value is permitted, but not required, to indicate the original logical processor that
caused a transaction to be issued.

13.10.8 Persistence Group Identifier, PGroupID

This field is used by a Requester to process different sets of CleanSharedPersistSep transactions by grouping them
together and identifying each using PGroupID.

Applicable in the CleanSharedPersistSep and WriteCleanShPerSep requests and the Persist and CompPersist
responses.

Inapplicable and must be set to zero in all other requests and responses.
In requests, when applicable, the same bits in the packet are used for LPID, TagGroupID, and StashGroupID.

In responses, when applicable, the same bits in the packet are used for DBID, TagGroupID, and StashGroupID.

13.10.9 Stash Node Identifier, StashNID

This field identifies the target of the Stash request. Provides a valid stash target value when the corresponding
StashNIDValid bit is asserted. See Stash target identifiers on page 7-309.

Applicable in Stash requests.

Inapplicable and must be zero for all other requests. For ReadNoSnp and ReadNoSnpSep requests, the same bits in
the packet are used for ReturnNID.

13-426 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.10 Stash Node Identifier Valid, StashNIDValid

This field indicates if StashNID field has a valid value. See Stash target identifiers on page 7-309.

Applicable in Stash requests, inapplicable and must be set to zero in all other requests.

Table 13-10 shows the StashNIDValid value encoding.

Table 13-10 StashNIDValid value encoding

StashNIDValid Description

0 StashNID field value is inapplicable and must be set to zero.

1 The StashNID field in the Request has a valid Stash target.

For permitted combinations of StashNIDValid and StashLPIDValid, see Table 7-3 on page 7-310.

13.10.11 Stash Logical Processor Identifier, StashLPID

This field provides a valid LP target value within the Request Node specified by StashNID. See Stash target
identifiers on page 7-309.

Applicable in Stash requests and Stash type Snoop requests.

Inapplicable and must be zero for all other requests. For ReadNoSnp requests, the same bits in the packet are used
for ReturnTxnID.
Inapplicable and must be zero for all other snoop requests. For Forwarding snoops, the same bits in the packet are
used for FwdTxnID and for SnpDVMOp snoops the same bits in the packet are used for VMIDExt.

13.10.12 Stash Logical Processor Identifier Valid, StashLPIDValid

This field indicates if the StashLPID field has a valid value. See Stash target identifiers on page 7-309.

Applicable in Stash requests and Stash snoop requests, inapplicable and must be set to zero in all other requests.

Table 13-11 shows the StashLPIDValid value encoding.

Table 13-11 StashLPIDValid value encoding

StashLPIDValid Description

0 StashLPID field value is inapplicable and must be set to zero.

1 The StashLPID field in the Request has a valid Stash target.

For permitted combinations of StashLPIDValid and StashNIDValid, see Table 7-3 on page 7-310.

13.10.13 Stash Group Identifier, StashGroupID

This field is used by a Requester to process different sets of StashOnceSep transactions by grouping them together
and identifying each using StashGroupID.

Applicable only in the StashOnceSep request and StashDone response.

Inapplicable and must be set to zero in all other requests and responses.

In requests, when applicable, the same bits in the packet are used for LPID, TagGroupID, and PGroupID.

In responses, when applicable, the same bits in the packet are used for DBID, TagGroupID, and PGroupID.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-427
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.14 Transaction Identifier, TxnID

This field provides the transaction identifier of the message. When there are multiple outstanding transactions from
a given source node they will each use a unique transaction ID. See Transaction Identifier, TxnID on page 2-93.

The TxnID in a link flit must be zero.

13.10.15 Return Transaction Identifier, ReturnTxnID

This field identifies the value the Subordinate must use in the TxnID field of the CompData, and DataSepResp
response. It can be either the TxnID generated by Home for this transaction or the TxnID in the Request packet from
the Requester that originated the transaction. See Return Node Identifier, ReturnNID on page 2-96.

Applicable only in ReadNoSnp, ReadNoSnpSep, WriteNoSnp, Combined Write, and Atomic requests from Home
to Subordinate.

Inapplicable and must be set to zero for all other requests. For Stash requests, the same bits in the packet are used
for StashLPID.

13.10.16 Forwarding Transaction Identifier, FwdTxnID

This field identifies the TxnID field of the original Request associated with the Snoop transaction. See Forward
Transaction Identifier, FwdTxnID on page 2-95.

Applicable in Forward-type snoops.

Inapplicable and must be set to zero in all other Snoop requests. For Stash snoops, the same bits in the packet are
used for StashLPID and for SnpDVMOp snoops the same bits in the packet are used for VMIDExt.

13.10.17 Data Buffer Identifier, DBID

The value in this field in the response packet from a Completer is used in the TxnID field for CompAck or WriteData
sent from the Requester.

In Snoop responses with Data Pull, the DBID value indicates the value to be used in the TxnID field of Data Pull
response messages. See Data Buffer Identifier, DBID on page 2-94.

In responses, when applicable, the same bits in the packet are used for PGroupID, StashGroupID, and TagGroupID.

13-428 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.18 Channel opcodes, Opcode

This field specifies the operation to be carried out. The Opcode encodings are specific to each channel. See:
• REQ channel opcodes
• RSP channel opcodes on page 13-432
• SNP channel opcodes on page 13-433
• DAT channel opcodes on page 13-434

REQ channel opcodes

Table 13-12 shows the opcodes for the Request channel.

Table 13-12 REQ channel opcodes

Request command

Opcode[5:0] Opcode[6] = 0 Opcode[6] = 1

0x00 ReqLCrdReturn Reserved

0x01 ReadShared MakeReadUnique

0x02 ReadClean WriteEvictOrEvict

0x03 ReadOnce WriteUniqueZero

0x04 ReadNoSnp WriteNoSnpZero

0x05 PCrdReturn Reserved

0x06 Reserved Reserved

0x07 ReadUnique StashOnceSepShared

0x08 CleanShared StashOnceSepUnique

0x09 CleanInvalid Reserved

0x0A MakeInvalid Reserved

0x0B CleanUnique Reserved

0x0C MakeUnique ReadPreferUnique

0x0D Evict Reserved

0x0E Reserved Reserved

0x0F Reserved Reserved

0x10 Reserved WriteNoSnpFullCleanSh

0x11 ReadNoSnpSep WriteNoSnpFullCleanInv

0x12 Reserved WriteNoSnpFullCleanShPerSep

0x13 CleanSharedPersistSep Reserved

0x14 DVMOp WriteUniqueFullCleanSh

0x15 WriteEvictFull Reserved

0x16 Reserved WriteUniqueFullCleanShPerSep

0x17 WriteCleanFull Reserved

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-429
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

Table 13-12 REQ channel opcodes (continued)

Request command

Opcode[5:0] Opcode[6] = 0 Opcode[6] = 1

0x18 WriteUniquePtl WriteBackFullCleanSh

0x19 WriteUniqueFull WriteBackFullCleanInv

0x1A WriteBackPtl WriteBackFullCleanShPerSep

0x1B WriteBackFull Reserved

0x1C WriteNoSnpPtl WriteCleanFullCleanSh

0x1D WriteNoSnpFull Reserved

0x1E Reserved WriteCleanFullCleanShPerSep

0x1F Reserved Reserved

0x20 WriteUniqueFullStash WriteNoSnpPtlCleanSh

0x21 WriteUniquePtlStash WriteNoSnpPtlCleanInv

0x22 StashOnceShared WriteNoSnpPtlCleanShPerSep

0x23 StashOnceUnique Reserved

0x24 ReadOnceCleanInvalid WriteUniquePtlCleanSh

0x25 ReadOnceMakeInvalid Reserved

0x26 ReadNotSharedDirty WriteUniquePtlCleanShPerSep

0x27 CleanSharedPersist Reserved

0x28 - 0x2F AtomicStore Reserved

0x30 - 0x37 AtomicLoad Reserved

0x38 AtomicSwap Reserved

0x39 AtomicCompare Reserved

0x3A PrefetchTgt Reserved

0x3B - 0x3F Reserved Reserved

Note
Prior to CHI Issue E, the following requests were not supported:
• ReadPreferUnique
• MakeReadUnique
• StashOnceSep
• WriteEvictOrEvict
• WriteNoSnpZero
• WriteUniqueZero
• Combined Write

13-430 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

Table 13-13 shows the sub-opcodes for AtomicStore and AtomicLoad.

Table 13-13 Sub-codes for AtomicStore and AtomicLoad

Opcode[5:3]
Opcode[2:0] Operation
AtomicStore AtomicLoad

101 110 000 ADD

001 CLR

010 EOR

011 SET

100 SMAX

101 SMIN

110 UMAX

111 UMIN

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-431
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

RSP channel opcodes

Table 13-14 shows the opcodes for the Response channel.

Table 13-14 RSP channel opcodes encoding

Opcode[4:0] Response

0x0 RespLCrdReturn

0x1 SnpResp

0x2 CompAck

0x3 RetryAck

0x4 Comp

0x5 CompDBIDResp

0x6 DBIDResp

0x7 PCrdGrant

0x8 ReadReceipt

0x9 SnpRespFwded

0xA TagMatch

0xB RespSepData

0xC Persist

0xD CompPersist

0xE DBIDRespOrd

0xF Reserved

0x10 StashDone

0x11 CompStashDone

0x12-0x13 Reserved

0x14 CompCMO

0x15-0x1F Reserved

Note
Prior to CHI Issue E, the following responses were not supported:
• DBIDRespOrd
• TagMatch
• StashDone
• CompStashDone
• CompCMO

13-432 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

SNP channel opcodes

Table 13-15 shows the opcodes for the Snoop channel.

Table 13-15 SNP channel opcodes encoding

Opcode[4:0] Snoop command

0x00 SnpLCrdReturn

0x01 SnpShared

0x02 SnpClean

0x03 SnpOnce

0x04 SnpNotSharedDirty

0x05 SnpUniqueStash

0x06 SnpMakeInvalidStash

0x07 SnpUnique

0x08 SnpCleanShared

0x09 SnpCleanInvalid

0x0A SnpMakeInvalid

0x0B SnpStashUnique

0x0C SnpStashShared

0x0D SnpDVMOp

0x0E - 0x0F Reserved

0x10 SnpQuery

0x11 SnpSharedFwd

0x12 SnpCleanFwd

0x13 SnpOnceFwd

0x14 SnpNotSharedDirtyFwd

0x15 SnpPreferUnique

0x16 SnpPreferUniqueFwd

0x17 SnpUniqueFwd

0x18 - 0x1F Reserved

Note
Prior to CHI Issue E, the following Snoop requests were not supported:
• SnpPreferUnique
• SnpPreferUniqueFwd
• SnpQuery

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-433
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

DAT channel opcodes

Table 13-16 shows the opcodes for the Data channel.

Table 13-16 DAT channel opcodes encoding

Opcode[3:0] Data command

0x0 DataLCrdReturn

0x1 SnpRespData

0x2 CopyBackWrData

0x3 NonCopyBackWrData

0x4 CompData

0x5 SnpRespDataPtl

0x6 SnpRespDataFwded

0x7 WriteDataCancel

0x8 - 0xA Reserved

0xB DataSepResp

0xC NCBWrDataCompAck

0xD-0xF Reserved

13.10.19 Deep persistence, Deep

This field is used by the Requester to indicate that the Persist response must not be sent until all earlier writes are
written to the final destination.

Applicable in the CleanSharedPersist* request and Combined Write request with CleanSharedPersistSep.

Inapplicable and must be set to zero in all other requests.

When Deep is deasserted:

• The Completer must send Persist response after all the earlier writes have reached the PoP.
— The PoP is the point at which it is guaranteed that sufficient time is available to make the data
persistent after loss of power.

When Deep is asserted:

• The Completer must send the Persist response only after all earlier writes are written to the final destination,
not just the PoP.
— The final destination is the point at which no time is required to make the data persistent after the loss
of power, thus preserving data even when battery failure occurs.

13-434 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.20 Address, Addr

This field specifies the address associated with the message.

This specification supports a PA of 44 to 52 bits. The address is carried in Addr field in the REQ and SNP channel.

The width of the field is defined by the Req_Addr_Width parameter. The field width is the same value of the
parameter in REQ channel, Addr[(43-51):0], and is three less than the parameter value in the SNP channel,
Addr[(43-51):3].

The Addr field is utilized in the REQ and SNP channels in the following manner.

• For Read, PrefetchTgt, Dataless, Write, and Atomic transactions, the Addr field includes the address of the
memory location being accessed. This starts with Addr[0] mapped to bit zero of Addr.

• For a snoop request, except SnpDVMOp, the Addr field includes the address of the location being snooped.
This starts with Addr[3] mapped to bit zero of Addr.
— Addr[(43-51):6] is the cache line address. It 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-148. It is recommended that the snooped cache returns the data in wrap order with the
critical chunk returned first.
Note
Addr[3] in the REQ channel, that is Addr[0] in SNP channel, is supplied but is not used by a snoop
request.

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

• The Addr value is not used for PCrdReturn transaction and must be set to zero.

13.10.21 Non-secure, NS
This field indicates a Non-secure access or a Secure access. See Non-secure bit on page 2-133.

Table 13-17 shows the NS field value encoding.

Table 13-17 NS value encoding

NS Description

0 Secure access

1 Non-secure access

13.10.22 Size of transaction data, Size

This field specifies the size of the data associated with the transaction. See Data size on page 2-142.

Table 13-18 shows the Size field value encodings.

Table 13-18 Size field value encodings

Size[2:0] Bytes

0b000 1

0b001 2

0b010 4

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-435
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

Table 13-18 Size field value encodings (continued)

Size[2:0] Bytes

0b011 8

0b100 16

0b101 32

0b110 64

0b111 Reserved

13-436 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.23 Memory Attribute, MemAttr

This field is associated with the transaction.

Table 13-19 shows the MemAttr value encodings.

Table 13-19 MemAttr value encodings

MemAttr[3:0] Description 0 1

[3] Allocate hint bit. Indicates whether or not the Recommend that it Recommend that it
cache receiving the transaction is recommended does not allocate allocates
to allocate the transaction:

[2] Cacheable bit. Indicates a Cacheable transaction Non-cacheable. Cacheable.

for which the cache, when present, must be Looking up a cache Looking up a
looked up in servicing the transaction: is not required cache is required.

[1] Device bit. Indicates if the memory type Normal memory Device memory
associated with the transaction is Device or type type
Normal:

[0] Early Write Acknowledge (EWA) bit. Specifies EWA not permitted EWA permitted
the EWA status for the transaction:

See Memory Attributes on page 2-134.

13.10.24 Snoop Attribute, SnpAttr

This field specifies the snoop attribute associated with the transaction.

Table 13-20 shows the SnpAttr value encoding.

Table 13-20 SnpAttr value encoding

SnpAttr Description

0 Non-snoopable

1 Snoopable

See Snoop Attribute, SnpAttr on page 2-139.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-437
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.25 Do Direct Write Transfer, DoDWT

The characteristics of this field are:
• Only applicable in WriteNoSnpFull, WriteNoSnpPtl, and Combined Write requests from Home to
Subordinate.
• It is inapplicable and must be set to zero in all other requests.
• The bit shares the same field as SnpAttr.

Table 13-21 shows the DoDWT value encoding.

Table 13-21 DoDWT value encoding

DoDWT DBIDResp.TgtID value DBIDResp.TxnID value

0 Set to the SrcID value of the request Set to TxnID value in the request

1 Set to the ReturnNID value in the request Set to the ReturnTxnID value in the request

See Immediate write on page 2-55 and Combined Immediate Write and CMO on page 2-62.

13.10.26 Likely Shared, LikelyShared

This field indicates whether the requested data is likely to be shared with another Request Node. See Likely Shared
on page 2-139.

Table 13-22 shows the LikelyShared field value encoding.

Table 13-22 LikelyShared value encoding

LikelyShared Description

0 Not likely to be shared by another RN

1 Likely to be shared by another RN

13.10.27 Ordering requirements, Order

This field specifies the ordering requirements for a transaction. See Ordering on page 2-121 for more information
on the ordering requirements.
Table 13-23 on page 13-439 shows the Order field value encodings.

13-438 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

Table 13-23 Order value encodings

Order[1:0] Description Permitted between

0b00 No ordering required All

0b01 Request accepted HN-F to SN-F and HN-I to SN-I

Reserved RN to HN

0b10 Request Order/Ordered Write Observation RN to HNa

Request Order HN-I to SN-I

Reserved HN-F to SN-F

0b11 Endpoint Order RN to HN and HN-I to SN-I

Reserved HN-F to SN-F

a. Request Order when ExpCompAck = 0.

Ordered Write Observation when ExpCompAck = 1.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-439
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.28 Exclusive, Excl

This field indicates that the corresponding transaction is an Exclusive-type transaction. The Exclusive bit must only
be used with the following transactions:
• ReadNotSharedDirty
• ReadShared
• ReadClean
• ReadPreferUnique
• CleanUnique
• MakeReadUnique
• ReadNoSnp
• WriteNoSnp

Table 13-24 shows the Excl value encoding.

Table 13-24 Excl value encoding

Excl Description

0 Normal transaction

1 Exclusive transaction

See Exclusive transactions on page 6-296.

13.10.29 Endian
This field indicates the endianness of Data in an Atomic transaction. See Endianness on page 2-147.

Applicable in Atomic requests, inapplicable in all other requests and must be set to zero.

Table 13-25 shows the Endian value encoding.

Table 13-25 Endian value encoding

Endian Description

0 Little Endian

1 Big Endian

13.10.30 Allow Retry, AllowRetry

This field 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-156.

Table 13-26 shows the AllowRetry value encoding.

Table 13-26 AllowRetry value encodings

AllowRetry Description

0 RetryAck response not permitted

1 RetryAck response permitted

13-440 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.31 Expect Completion Acknowledge, ExpCompAck

This field indicates that the transaction will include a CompAck response.

Table 13-27 shows the ExpCompAck value encoding.

Table 13-27 ExpCompAck value encoding

ExpCompAck Description

0 Transaction does not include a CompAck response

1 Transaction includes a CompAck response

13.10.32 SnoopMe
This field indicates that the Home must determine whether to send a snoop to the Requester. See Atomic transactions
on page 2-74.

Only applicable in Atomic requests.

Table 13-28 shows the SnoopMe value encoding.

Table 13-28 SnoopMe value encoding

SnoopMe Description

0 Home is permitted, but not required, to send a snoop to the Requester.

1 Home must send a Snoop to the Requester if it determines the cache line might be present at the
Requester.

13.10.33 Return to Source, RetToSrc

This field requests the Snoopee to return a copy of the cache line to the Home.

Applicable in all snoops except SnpDVMOp.

For RetToSrc bit semantics see Returning Data with Snoop response on page 4-251.

13.10.34 Data Pull, DataPull

This field indicates the inclusion of a Read request, also referred to as a Data Pull, in the Snoop response. See Snoop
requests and Data Pull on page 7-304.

Applicable in SnpResp and SnpRespData response to a Stash request, not applicable in all other Snoop responses.

When the DataPull bit is set in a SnpRespData message, it must be set in all packets of that response message.

Table 13-29 shows the DataPull field value encodings.

Table 13-29 DataPull value encodings

DataPull[2:0] Description Comment

0b000 No Read Inclusion of Data Pull in the Snoop response

0b001 Read

0b010- 0b111 - Reserved

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-441
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.35 Do not transition to SD state, DoNotGoToSD

This field is an attribute in a Snoop request indicating if a Snoopee is required to not transition to SD state. See Do
not transition to SD on page 4-252.

Applicable, and can take any value in:

• SnpOnce, SnpOnceFwd
• SnpClean, SnpCleanFwd
• SnpNotSharedDirty, SnpNotSharedDirtyFwd
• SnpShared, SnpSharedFwd
• SnpPreferUnique, SnpPreferUniqueFwd

Applicable, and must be set to 1 in:

• SnpStashShared, SnpStashUnique
• SnpUnique, SnpUniqueFwd. SnpUniqueStash
• SnpCleanShared
• SnpCleanInvalid
• SnpMakeInvalid, SnpMakeInvalidStash

Inapplicable, and must be set to zero in:

• SnpQuery
• SnpDVMOp

Table 13-30 shows the DoNotGoToSD value encoding.

Table 13-30 DoNotGoToSD value encoding

DoNotGoToSD Description

0 Permitted to transition to SD state.

1 Transitioning to SD state is not permitted.

If already in SD state, SD state must be exited in response to the snoop.
The bit value can be ignored by the Snoopee if the Snoop request is SnpOnce or SnpOnceFwd.

13.10.36 Protocol Credit Type, PCrdType

This field indicates the type of credit being granted or returned. See Transaction Retry mechanism on page 2-156.
Table 13-31 shows the PCrdType value encodings.

Table 13-31 PCrdType value encodings

PCrdType Description

0x0 - 0xF P-Credit type 0 to 15 respectively.

13-442 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.37 Tag Operation, TagOp

This field indicates the operation to be performed on the tags present in the corresponding DAT channel.

Table 13-32 shows the TagOp value encodings.

Table 13-32 TagOp value encodings

TagOp[1:0] Tag Operation Description

0b00 Invalid The tags are not valid.

0b01 Transfer • The tags are Clean.

• Tag Match does not need to be performed.
• All tags corresponding to data in the packet must be transferred. For Snoopable
transactions, partial tag transfer is not supported.
• TU field is not applicable and must be set to zero.

0b10 Update • The Allocation Tag values have been updated and are Dirty.
• The Tags in memory should be updated. Only the Tags that have TU asserted must be
updated.

0b11 Match • Match:

Fetch — The Physical Tags in the write must be checked against the Allocation Tag values
obtained from memory.
— The Match Tag operation must be enabled for only those tags that have BE asserted.
— TU field is not applicable and must be set to zero.
• Fetch:
— Tags must be fetched.
— All tags must be fetched.
— Permitted, but not required, to fetch valid data.

TagOp value in a Retry request must be the same as in the original request.

13.10.38 Tag
Tag[4*n-1:0]. This field provides n sets of 4-bit tags, each associated with a 16-byte, aligned address location.

[Tag[((4*n)-1) : 4*(n-1)] corresponds to Data[((128*n)-1) : 128*(n-1)]

13.10.39 Tag Update, TU

TU[n-1:0]. This field indicates which of the Allocation Tags must be updated. There is one TU bit for each tag. Only
valid in Snoop responses and Write transactions which update the Allocation Tags. Must be set to zero in all other
transactions.
TU[n-1] corresponds to Tag[(4*n)-1 : 4*(n-1)]

13.10.40 Tag Group Identifier, TagGroupID

This field is used by a Requester to process different sets of TagMatch responses by grouping the corresponding
requests together and identifying each group using TagGroupID. The precise contents of TagGroupID are
IMPLEMENTATION DEFINED. Typically, TagGroupID is expected to contain an Exception Level, TTBR value, and
CPU identifier.

TagGroupID is applicable in requests where TagOp is set to Match and in a TagMatch response.

In requests, when applicable, the same bits in the packet are used for LPID, PGroupID, or StashGroupID.

In responses, when applicable, the same bits in the packet are used for DBID, PGroupID, or StashGroupID.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-443
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.41 Trace Tag, TraceTag

This field is a bit in a packet used to tag the packets associated with a transaction for tracing purposes.

Table 13-33 shows the TraceTag field value encoding.

Table 13-33 TraceTag value encoding

TraceTag Description

0 Packet is not tagged.

1 Packet is tagged.

See Chapter 11 System Debug, Trace, and Monitoring.

13.10.42 Memory System Performance Resource Partitioning and Monitoring, MPAM

This field is used to efficiently utilize the memory resources among users and to monitor their use. See MPAM on
page 11-373.

13.10.43 Virtual Machine Identifier Extension, VMIDExt

This field is used to extend VMID value from 8-bits to 16-bits. See DVMOp payload on page 8-323.

13.10.44 Response status, Resp

This field must have the same value in all data flits of a multi-flit data transfer.

Table 13-34 shows the Resp value encodings.

Table 13-34 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 RN-F.
For completion responses, this field indicates the final state in the RN.
For WriteData responses, this field indicates the state of the data in the RN when
the data is sent.
For TagMatch responses, Resp[0] alone indicates a Tag Match pass or fail.

13-444 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

Table 13-35 shows the valid Resp value encodings.

Table 13-35 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 Final state of the snooped RN-F. Responsibility for

updating memory is passed to Home.
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. Responsibility for

updating memory is passed to the Requester.
0b111 SD_PD

WriteData responses 0b000 I The cache state in the response is imprecise and must
be ignored.

0b001 SC State of the cache line at the RN-F when data is sent.

0b010 UC

0b011 - Reserved.

0b100 -

0b101 -

0b110 UD_PD State of the cache line at the RN-F when data is sent.
Responsibility for updating memory is passed to
0b111 SD_PD Home.

TagMatch responses 0b000 Fail Part of the Tag Match operation.

0b001 Pass

0b010 - 0b111 - Reserved.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-445
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.45 Forward State, FwdState

This field indicates the state in the CompData sent from the Snoopee to the Requester. Applicable in SnpRespFwded
and SnpRespDataFwded, inapplicable in all other Snoop responses and must be set to zero.

Table 13-36 shows the FwdState value encodings.

Table 13-36 FwdState value encodings

FwdState[2:0] Description

FwdState[2] PassDirty.
0 Forwarded data is not Dirty.
1 Forwarded data is Dirty and the responsibility of writing back the cache line
is passed on to the Requester.

FwdState[1:0] Indicates the final state at the Requester. See Table 13-37.

Table 13-37 enumerates the FwdState value encodings.

Table 13-37 Valid FwdState value encodings

FwdState[2:0] State Comment

0b000 I Final state at the Requester.

0b001 SC

0b010 UC

0b011 - Reserved.

0b100 -

0b101 -

0b110 UD_PD Final state at the Requester.

Responsibility for updating
0b111 SD_PD memory is passed to the
Requester.

13.10.46 Completer Busy, CBusy

This field is a mechanism for the Completer of a transaction to indicate its current level of activity. The CBusy value
encodings are IMPLEMENTATION DEFINED. See Completer Busy on page 11-375.

13-446 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.47 Response Error, RespErr

This field indicates the error status of the response. See Chapter 9 Error Handling.

Table 13-38 shows the RespErr value encodings.

Table 13-38 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.

13.10.48 Data payload, Data

This field is the data payload that is being transported in a Data packet.

The following data bus widths are supported:

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

See Data packetization on page 2-144.

13.10.49 Critical Chunk Identifier, CCID

This field indicates the critical 128-bit chunk of the data that is being requested. See Critical Chunk Identifier on
page 2-148.

Table 13-39 shows the CCID value encodings.

Table 13-39 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]

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-447
ID092622 Non-Confidential
Link Layer
13.10 Protocol flit fields

13.10.50 Data Identifier, DataID

This field indicates the relative position of the data chunk within the 512-bit cache line that is being transferred. See
Data packetization on page 2-144.

Table 13-40 shows the DataID value encodings.

Table 13-40 DataID and the bytes within a packet for different data widths

Data Width
DataID
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

13.10.51 Byte Enable, BE

This field indicates if the byte of data corresponding to this byte enable bit is valid. The BE field is defined for write
data, DVM payload, and Snoop response data transfers. For Read response data transfers, this field is inapplicable
and can take any value. It consists of a bit for each data byte in the DAT flit. See Byte Enables on page 2-143.

Table 13-41 shows the BE value encodings.

Table 13-41 BE value encodings

BE Byte enable
0 Corresponding byte of data is not valid.
1 Corresponding byte of data is valid.

13.10.52 Data check, DataCheck

This field is used to supply the DataCheck bit for the corresponding byte of Data. See Data Check on page 9-356.

13.10.53 Poison
This field indicates if the 64-bit chunk of data corresponding to a Poison bit is poisoned, that is, has an error, and
must not be consumed. See Poison on page 9-355.

Table 13-42 shows the Poison value encodings.

Table 13-42 Poison value encodings

Poison Description
0 Corresponding 64-bit chunk is not poisoned.
1 Corresponding 64-bit chunk is poisoned.

13-448 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Layer
13.10 Protocol flit fields

13.10.54 Data source, DataSource

This field identifies the Sender of the data response. See DataSource value assignment on page 11-368.

Applicable in CompData and DataSepResp responses in Read and Atomic transactions, and SnpRespData and
SnpRespDataPtl responses in Non-stash type Snoop transactions. DataSource is not applicable and must be set to
zero in all other responses.

Table 13-43 shows the DataSource value encodings.

Table 13-43 DataSource value encodings

DataSource Description Comment

0b0000 DataSource is not supported Applicable only to a non-memory component

0b0001 - 0b0101 IMPLEMENTATION DEFINED See Suggested DataSource values on page 11-369

0b0110 PrefetchTgt was useful Indication from memory that the earlier sent prefetch was useful or
memory received a prefetch.

0b0111 PrefetchTgt was not useful Indication from memory that the earlier sent prefetch was not useful
or memory did not receive a prefetch.

0b1000 - 0b1111 IMPLEMENTATION DEFINED -

13.10.55 System Level Caches Replacement Hint, SLCRepHint

This field forwards cache replacement hints from the Requesters to the SLC in the interconnect, See SLC
replacement hint on page 11-371.

13.10.56 Reserved for Customer Use, RSVDC

This field in a Protocol flit can take any value. Propagation of this field through the interconnect is IMPLEMENTATION
DEFINED. There is no defined relationship between RSDVC field values in different packets of a transaction.

This field is applicable in 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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 13-449
ID092622 Non-Confidential
Link Layer
13.11 Link flit

13.11 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 take any value. See Channel opcodes, Opcode on page 13-429 for the
link flit type encoding.

13-450 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 14
Link Handshake

This chapter describes the link handshake requirements. It contains the following sections:
• Clock, and initialization on page 14-452
• Link layer Credit on page 14-453
• Low power signaling on page 14-454
• Flit level clock gating on page 14-455
• Interface activation and deactivation on page 14-456
• Transmit and receive link Interaction on page 14-462
• Protocol layer activity indication on page 14-468

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-451
ID092622 Non-Confidential
Link Handshake
14.1 Clock, and initialization

14.1 Clock, and initialization

This section specifies the AMBA 5 CHI requirement for global clock and reset signals.

14.1.1 Clock
This specification does not define a specific clocking microarchitecture. It is expected that all devices,
interconnects, and so on, includes 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.

14.1.2 Reset
This specification does not define a specific reset microarchitecture. It is expected that all devices, interconnects,
and so on, 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.

14.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 take any value.

14-452 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.2 Link layer Credit

14.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.

14.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 13-414 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 1. 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-453
ID092622 Non-Confidential
Link Handshake
14.3 Low power signaling

14.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 are 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.

14-454 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.4 Flit level clock gating

14.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 13-414 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, but not required, to keep the signal permanently asserted. A Transmitter might do
this, for example, if it is unable to determine in advance when a flit is to be sent.
• A Transmitter is permitted, but not required, to assert this signal when it does not have an L-Credit.
• A Transmitter is permitted, but not required, to assert and then deassert this signal without sending a flit.

Figure 14-1 shows an example of the use of the FLITPEND signal.

CLK

FLITPEND

FLITV

FLIT
flit flit

Figure 14-1 FLITPEND indicating a valid flit in next cycle

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-455
ID092622 Non-Confidential
Link Handshake
14.5 Interface activation and deactivation

14.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. 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 starts 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.

14.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 14-462 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 14-2 shows the relationship
between the Payload, Credit, LINKACTIVEREQ, and LINKACTIVEACK signals.

LINKACTIVEREQ
LINKACTIVEACK

Transmitter Receiver
Payload

Credit

Figure 14-2 Relationship between Payload, Credit, and LINKACTIVE signals

As Figure 14-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.

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.

14-456 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.5 Interface activation and deactivation

RUN and STOP are stable states. When one of these states is entered, a channel can remain in this state for an
indefinite period.

DEACTIVATE and ACTIVATE are transient states. It is expected that when one of these states is entered, a channel
moves to the next stable state in a relatively short period.

Note
The specification does not define a maximum period 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 14-3 shows the
relationship between the four states.

STOP
00 10

DEACTIVATE ACTIVATE

01 11
RUN

Figure 14-3 Request and Acknowledge handshake states

Table 14-1 shows the mapping of the states to the LINKACTIVEREQ and LINKACTIVEACK signals.

Table 14-1 Mapping of states to the LINKACTIVE signals

State LINKACTIVEREQ LINKACTIVEACK

STOP 0 0

ACTIVATE 1 0

RUN 1 1

DEACTIVATE 0 1

Table 14-2 on page 14-458 describes the behavior of both the Transmitter and the Receiver of a single link for each
of the four states.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-457
ID092622 Non-Confidential
Link Handshake
14.5 Interface activation and deactivation

Table 14-2 Behavior for each Request and Acknowledge state

State Transmitter behavior Receiver behavior

STOP The Transmitter has no credits and must not send any The Receiver is guaranteed not to receive any flits.
flits. The Receiver must not send any credits.
The Transmitter is guaranteed not to receive 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 The Receiver must not send any credits.
this 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 Receiver must assert LINKACTIVEACK and
the RUN state. move to the RUN state before sending credits. It is
permitted, but not required, to assert
Note
The Transmitter will only receive credits in the LINKACTIVEACK and send a credit in the same
ACTIVATE state when there is a race between the cycle.
Receiver sending credits and asserting Note
LINKACTIVEACK to move to the RUN state. It can appear that a Receiver has sent credits in the
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
observes the deassertion of LINKACTIVEREQ.

DEACTIVATE The Transmitter must return credits using Protocol flits or During this state, the Receiver stops sending credits
(DEACT) L-Credit return flits. and 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.
returns credits using only L-Credit return flits. The Receiver is permitted, but not required, to send
The Transmitter must be prepared to continue receiving credits when first entering this state. However, it must
credits. For each additional credit received it must send have stopped sending credits and had all credits
an L-Credit return flit to return the credit. returned before exiting this state.
The Transmitter remains in the DEACTIVATE state The Receiver receives L-Credit return flits until all
while it is waiting for the Receiver to acknowledge the credits are returned.
move to the STOP state. At this point, it is 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.

14-458 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.5 Interface activation and deactivation

Table 14-5 on page 14-466 summarizes the required behavior described in detail in Table 14-2 on page 14-458.

Table 14-3 Summary of behavior for each Request and Acknowledge state

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 Expected to send L-Credit return flits. Must accept flits.

Can send any flits. Must stop sending credits.
Must accept credits.
Must return credits.

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, 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, 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.

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.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-459
ID092622 Non-Confidential
Link Handshake
14.5 Interface activation and deactivation

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 various 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, 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 14-462.

14-460 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.5 Interface activation and deactivation

Multiple channels in the same direction

Figure 14-4 shows an example of a multiple channel interface, also referred to as a Link, 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 14-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 credits must stop on all channels.

• A credit can only be associated with a flit on the same channel.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-461
ID092622 Non-Confidential
Link Handshake
14.6 Transmit and receive link Interaction

14.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 14-463
• Expected transitions on page 14-465

14.6.1 Introduction
A single component has various 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).

It is required that the activation and deactivation 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, 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, 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, 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, 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.

14-462 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.6 Transmit and receive link Interaction

14.6.2 Tx and Rx state machines

Figure 14-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
Input

rm
TXACK

itt
Race

ed
Banned
TxRun+ TxRun TxRun Remote TxRun TxRun
TxRun RxStop RxAct RxRun Initiate RxDeact
Output
RxStop+
Race
Banned
Pe

Pe
TXREQ Local
Output
rm

rm
Initiate
itt

itt
Race
ed

ed
Async
TxDeact+ TxDeact TxDeact TxDeact TxDeact
TxDeact RxAct RxRun RxDeact RxStop
Input
RxAct+
Race
Async
Pe

Pe
TXACK Input
rm

rm
itt

itt
Race
ed

ed
TxStop+ TxStop TxStop TxStop
TxStop RxRun RxDeact RxStop RxAct

Banned
Pe

Output
rm

TXREQ
itt

Race
ed

TxAct+ TxAct
TxAct RxDeact RxStop

Figure 14-5 Combined Tx and Rx state machines

Figure 14-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 14-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, the same agent is changing both signals.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-463
ID092622 Non-Confidential
Link Handshake
14.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 gray states, on the bottom right of Figure 14-5 on page 14-463, 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 14-466.

• 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 14-466.

• 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 14-465.

• The arrows labeled Permitted are state transactions that would not normally be expected, but they are
permitted by the protocol.

State naming
Figure 14-5 on page 14-463 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 14-466.

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, 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.

14-464 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.6 Transmit and receive link Interaction

14.6.3 Expected transitions

Figure 14-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
Input

rm
TXACK

itt
Race

ed
Banned
TxRun+ TxRun TxRun Remote TxRun TxRun
TxRun RxStop RxAct RxRun Initiate RxDeact
Output
RxStop+
Race
Banned
Pe

Pe
TXREQ Local
Output
rm

rm
Initiate
itt

itt
Race
ed

ed
Async
TxDeact+ TxDeact TxDeact TxDeact TxDeact
TxDeact RxAct RxRun RxDeact RxStop
Input
RxAct+
Race
Async
Pe

Pe
TXACK Input
rm

rm
itt

itt
Race
ed

ed
TxStop+ TxStop TxStop TxStop
TxStop RxRun RxDeact RxStop RxAct

Banned
Pe

Output
rm
TXREQ
itt
Race
ed

TxAct+ TxAct
TxAct RxDeact RxStop

Figure 14-6 Expected Tx and Rx state machines transitions

Figure 14-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 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 14-4 shows, in terms of the state
transitions, the two expected paths.

Table 14-4 Stop/Stop to Run/Run state paths

Route 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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-465
ID092622 Non-Confidential
Link Handshake
14.6 Transmit and receive link Interaction

The annotations on the diagram arrows in Figure 14-6 on page 14-465 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 14-5 shows, in terms of the state
transitions, the four expected paths.

Table 14-5 State 5

Route 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 14-5 on page 14-463, 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.

14-466 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.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 14-5 on page 14-463 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 14-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 Local
rm

rm
Initiate
itt

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 14-7 Combined Tx and Rx state machines without race conditions

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-467
ID092622 Non-Confidential
Link Handshake
14.7 Protocol layer activity indication

14.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 14-470
• Relationship between SACTIVE and LINKACTIVE on page 14-471

14.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 deassertion 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, 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.

SACTIVE signals must be synchronous to CLK and therefore are not required to be synchronized. If they cross a
clock domain, the clock domain crossing bridge is required to synchronize the signals.

14.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, but not required, for TXSACTIVE to be deasserted while transmitting link flits as part of the
link deactivation sequence.

Note
To ensure an efficient power down sequence, it is recommended not to assert a deasserted TXSACTIVE signal
during a link deactivation sequence.

It is permitted, but not required, for the interface on an interconnect component to use the RXSACTIVE input
signal to directly generate the TXSACTIVE output signal. This behavior is only permitted on the interconnect
interface and it is not permitted on any attached component.

Except for an interconnect interface of a Link, no other interface of a Link is permitted to loop-back the incoming
RXSACTIVE onto the outgoing TXSACTIVE.

Figure 14-8 on page 14-469 shows the requirements for TXSACTIVE assertion during the life of a transaction.

14-468 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.7 Protocol layer activity indication

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 14-8 TXSACTIVE assertion during the life of a transaction

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-469
ID092622 Non-Confidential
Link Handshake
14.7 Protocol layer activity indication

TXSACTIVE signaling from a Request Node

When initiating new transactions, a Request Node 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 a Request Node depends 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.

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 lifetime of a PrefetchTgt is a single flit. For the PrefetchTgt, the initiating flit is also the
completing flit and the transaction can be considered complete in the following cycle after it is sent from the
perspective of TXSACTIVE.

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 a Subordinate Node

A Subordinate Node 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 interconnect interface to a Request Node

The interconnect interface to a Request Node 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.

TXSACTIVE signaling from an interconnect interface to a Subordinate Node

The interconnect interface to a Subordinate Node 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.

14.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.

14-470 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Link Handshake
14.7 Protocol layer activity indication

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.

14.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 Transmitter 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 on page 14-470.
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 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 14-471
ID092622 Non-Confidential
Link Handshake
14.7 Protocol layer activity indication

14-472 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 15
System Coherency Interface

This chapter describes the interface signals that support connecting and disconnecting an RN-F from both the
Coherency and DVM domains and an RN-D from the DVM domain. It contains the following sections:
• Overview on page 15-474
• Handshake on page 15-475

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 15-473
ID092622 Non-Confidential
System Coherency Interface
15.1 Overview

15.1 Overview
The system coherency interface signals are:
SYSCOREQ Requester coherency request.
SYSCOACK Interconnect coherency acknowledge.

Both SYSCOREQ and SYSCOACK signals must be synchronous to CLK and therefore are not required to be
synchronized. If they cross a clock domain, the clock domain crossing bridge is required to synchronize the signals.

Figure 15-1 shows the system coherency interface signals connections.

RN-F or RN-D

SYSCOREQ SYSCOACK

Interconnect

Figure 15-1 System coherency interface signals

Note
In this chapter:
• Coherency when stated, includes the DVM domain, unless explicitly stated otherwise.
• Snoop when stated, includes SnpDVMOp, unless explicitly stated otherwise.

15-474 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 System Coherency Interface
15.2 Handshake

15.2 Handshake
A Request Node, an RN-F or an RN-D, requests connection to system coherency by setting SYSCOREQ HIGH.
The interconnect indicates that coherency is enabled by setting SYSCOACK HIGH.

The Request Node requests disconnection from system coherency by setting SYSCOREQ LOW. The interconnect
indicates that coherency is disabled by setting SYSCOACK LOW.

Requests to enter and exit coherency are always initiated by the Request Node.

Figure 15-2 shows the system coherency interface handshake timing.

t0 t1 t2 t3 t4

SYSCOREQ

SYSCOACK

Coherency Disabled Coherency Connect Coherency Enabled Coherency Disconnect Coherency Disabled

Figure 15-2 System coherency interface handshake timing

As Figure 15-2 shows, the interface signaling obeys four-phase handshake rules:
• SYSCOREQ can only change when SYSCOACK is at the same logic state.
• SYSCOACK can only change when SYSCOREQ is at the opposite logic state.

15.2.1 RN rules
Referring to Figure 15-2, a Request Node must:
• Be able to service Snoop requests when it sets SYSCOREQ HIGH at t1.
• Not issue a transaction that permits it to cache a coherent location until SYSCOACK goes HIGH at t2.
• Ensure all transactions that permit it to cache a coherent location are complete before it sets SYSCOREQ
LOW at t3.
SYSCOREQ can only be deasserted on the cycle after all of the following:
— All data packets are received for Reads.
— All data packets are sent for CopyBack.
— All data packets are sent for snoops and Forwarding snoops.
— Comp is received for Dataless transactions.
• Keep servicing Snoop requests until SYSCOACK is sampled LOW at t4.

SACTIVE must be asserted during coherency connect transition periods to guarantee the SYSCOACK transition
occurs. See Protocol layer activity indication on page 14-468.

Note
The transactions that permit a coherent location to be cached are:
• ReadUnique
• ReadPreferUnique
• MakeReadUnique
• ReadClean
• ReadNotSharedDirty
• ReadShared
• CleanUnique
• MakeUnique

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 15-475
ID092622 Non-Confidential
System Coherency Interface
15.2 Handshake

15.2.2 Interconnect rules

Referring to Figure 15-2 on page 15-475:

When the interconnect samples SYSCOREQ HIGH it must:

• Set SYSCOACK HIGH without waiting for responses to any Snoop requests that it has sent after
SYSCOREQ goes HIGH.

• Be able to service coherent data accesses from the interface when it sets SYSCOACK HIGH at t2.

When the interconnect samples SYSCOREQ LOW it must:

• Complete all snoop accesses to the interface before it sets SYSCOACK LOW at t4.

15.2.3 Protocol states

Table 15-1 shows the interface states and the rules that the Requester must follow in relation to the interface state.

Table 15-1 System coherency interface states

State name SYSCOREQ SYSCOACK Description

Coherency Disabled 0 0 • RN caches must not contain coherent data.

• RN must not issue transactions that permit it to cache a coherent
location or send DVM transactions.
• RN not required to respond to Snoop requests.
• Interconnect must not send Snoop requests.

Coherency Connect 1 0 • RN caches must not contain coherent data.

• RN must not issue transactions that permit it to cache a coherent
location or send DVM transactions.
• RN must respond to Snoop requests.
• Interconnect can send Snoop requests.

Coherency Enabled 1 1 • RN caches can contain coherent data.

• RN can issue transactions that cache a coherent location and send
DVM transactions.
• RN must respond to Snoop requests.

Coherency Disconnect 0 1 • RN caches must not contain coherent data.

• RN must not issue transactions that permit it to cache a coherent
location or send DVM transactions.
• RN must respond to Snoop requests.
• Interconnect must complete outstanding Snoop requests but must
not generate new Snoop requests.

15-476 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Chapter 16
Properties, Parameters, and Broadcast Signals

This chapter describes the properties, parameters, and optional broadcast signals that specify the behavior supported
by an interface. It contains the following sections:
• Interface properties and parameters on page 16-478
• Optional interface broadcast signals on page 16-482
• Atomic transaction support on page 16-486

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-477
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.1 Interface properties and parameters

16.1 Interface properties and parameters

A property is used to declare a capability. If a property is not declared, it is considered False.

The properties and parameters that specify the interface behavior are described in the following sections:
• Atomic_Transactions
• Cache_Stash_Transactions
• Direct_Memory_Transfer
• Data_Poison
• Direct_Cache_Transfer on page 16-479
• Data_Check on page 16-479
• Check_Type on page 16-479
• CleanSharedPersistSep_Request on page 16-479
• MPAM_Support on page 16-479
• CCF_Wrap_Order on page 16-480
• Req_Addr_Width on page 16-480
• NodeID_Width on page 16-480
• Data_Width on page 16-480
• Enhanced_Features on page 16-480
• DVM_Support on page 16-480

16.1.1 Atomic_Transactions
An Atomic_Transactions property is used to indicate if a component supports Atomic transactions:
• When not specified, or set to False, Atomic transactions are not supported.
• When set to True, Atomic transactions are supported.

A component that supports Atomic transactions must support all Atomic transactions. However, it is not required
that a component that supports Atomic transactions supports the targeting of all memory types.

16.1.2 Cache_Stash_Transactions
A Cache_Stash_Transactions property is used to indicate if a component supports Cache Stashing transactions:
• When not specified, or set to False, Cache Stashing transactions are not supported.
• When set to True, Cache Stashing Transactions are supported.

16.1.3 Direct_Memory_Transfer
A Direct_Memory_Transfer property is used to indicate if a component supports Direct Memory Transfer
transactions:
• When not specified, or set to False, Direct Memory Transfer transactions are not supported.
• When set to True, Direct Memory Transfer transactions are supported.
• The Direct_Memory_Transfer property is defined at each HN for each SN.

16.1.4 Data_Poison
A Data_Poison property is used to indicate if a component supports Poison:

• When not specified, or set to False, Poison is not supported and the Poison field is not present in the DAT
packet.

• When set to True, Poison is supported and the Poison field is present in the DAT packet.

See Poison on page 9-355.

16-478 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Properties, Parameters, and Broadcast Signals
16.1 Interface properties and parameters

16.1.5 Direct_Cache_Transfer
A Direct_Cache_Transfer property is used to indicate if a component supports Direct Cache Transfer transactions:

• When not specified, or set to False, Direct Cache Transfer transactions are not supported.

• When set to True, Direct Cache Transfer transactions are supported.

• It is the responsibility of the HN-F to determine the correct snoop type to use.

16.1.6 Data_Check
The Data_Check property is used to indicate the DataCheck field is present in the DAT packet:

• When not specified, or set to False, the DataCheck field is not in the DAT packet unless specified by the
Check_Type property.

• When set to Odd_Parity, Data Check is supported and the DataCheck field is present in the DAT packet. If
Check_Type is defined and set to Odd_Partity_Byte_All, no DataCheck field is present in the DAT packet.

See Data Check on page 9-356.

16.1.7 Check_Type
The Check_Type property is used to indicate the protection scheme employed on an interface:

• When not specified, or set to False, no checking signals are present on the interface, unless specified by the
Data_Check property.

• When set to Odd_Parity_Byte_Data, the DataCheck field is present in the DAT packet.

• When set to Odd_Parity_Byte_All, parity check signals are added to every channel. The signals added are
detailed in Interface parity check signals on page 9-359.

16.1.8 CleanSharedPersistSep_Request
The CleanSharedPersistSep_Request property is used to indicate if a component supports CleanSharedPersistSep:

• When not specified, or set to False, the component does not support CleanSharedPersistSep and the
component must not be sent a CleanSharedPersistSep request.

• When set to True, the component supports CleanSharedPersistSep.

• A Home that receives a CleanSharedPersistSep request must support such a request.

• A Home can track if a connected Subordinate supports CleanSharedPersistSep.

• If a Subordinate does not support CleanSharedPersistSep:

— The Home must send a CleanSharedPersist instead of a CleanSharedPersistSep request to that
Subordinate.
— Home must take the responsibility of sending the Persist response to the Requester. This Persist
response must only be sent after receiving the Comp response from the Subordinate.

• A Requester that does not support CleanSharedPersistSep will generate CleanSharedPersist instead.

16.1.9 MPAM_Support
The MPAM_Support property is used to indicate whether an interface supports MPAM.

• When not specified, or set to False, MPAM is not supported:

— The interface is not MPAM enabled.
— No MPAM fields are present on the interface.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-479
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.1 Interface properties and parameters

• When set to MPAM_9_1, the interface is enabled for partitioning and monitoring:
— It must include the MPAM field on the REQ, DAT, and SNP channels.
— The width of PartID is 9 bits and the width of PerfMonGroup is 1bit.

How the MPAM field values are used by a receiver is IMPLEMENTATION DEFINED.

16.1.10 CCF_Wrap_Order
See Critical chunk first wrap order on page 2-148.

16.1.11 Req_Addr_Width
This parameter specifies the maximum physical address supported by a component:
• Legal values for this parameter are 44 to 52.
• When Req_Addr_Width is not specified, the default value is 44.

16.1.12 NodeID_Width
This parameter specifies the width of NodeID fields supported by a component, which determines the maximum
permitted NodeID value in the system:
• The width specified is uniformly applied to all NodeID related fields.
• Legal values of NodeID_Width are 7 to 11.
• When NodeID_Width is not specified, the default value is 7.

16.1.13 Data_Width
This parameter specifies the data width in the DAT channel packet supported by a component:
• Legal values for Data_Width are 128, 256, and 512.
• When Data_Width is not specified, the default value is 128.

16.1.14 Enhanced_Features
The Enhanced_Features property describes the combined support for some of the miscellaneous features in the CHI
specification that do not have an explicit property or parameter defined.

When the Enhanced_Features property is True, the component supports all the following enhanced features:
• Data return from SC state.
• I/O Deallocation transactions.
• ReadNotSharedDirty transaction.
• CleanSharedPersist transaction.
• Receiving of Forwarding snoops.

When not specified, or set to False, the component does not support the enhanced features that do not have an
explicitly defined property or parameter.

16.1.15 DVM_Support
A DVM_Support property is used to indicate Arm ARM specification supported by a given component. When set
to:
False The component does not support any DVM transactions.
DVM_v8 The component supports DVM transactions required to support Armv8.
DVM_v8.1 The component supports DVM transactions required to support Armv8.1.
DVM_v8.4 The component supports DVM transactions required to support Armv8.4.

16-480 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Properties, Parameters, and Broadcast Signals
16.1 Interface properties and parameters

In a system with heterogeneous components, it is the responsibility of the system configuration to determine the
lowest common DVM specification supported in the system. The interconnect must have the knowledge of this
lowest common denominator value by means of configuration, straps, parameterization, or some other
IMPLEMENTATION DEFINED method.

To avoid deadlocks and denial of service, the interconnect must detect unsupported DVM operations. The
interconnect must suppress unsupported DVM operation propagation and respond in a protocol-compliant manner.
Error indication in such a response is optional.

Note
The following expression can be used by the interconnect to determine if a DVM operation is a new one added in
Armv8.4 and not supported by older specifications.

If the following expression is true, then the transaction is a DVM operation supported by Armv8.4 only.

[TLBI and (
(Hypervisor and Secure) or
(Guest OS and Secure and VMID) or
(Non-secure only) or
(Range))] OR
[VICI and (
(Guest OS and Secure and VMID))]

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-481
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.2 Optional interface broadcast signals

16.2 Optional interface broadcast signals

This specification includes six sets of optional pins to determine broadcasting of certain groups of transactions in
the interconnect. These pins are optional at the Request Node to the interconnect, and the interconnect to the
Subordinate Node interfaces. The optional broadcast pins are:
• BROADCASTINNER and BROADCASTOUTER
• BROADCASTCACHEMAINTENANCE
• BROADCASTPERSIST
• BROADCASTATOMIC on page 16-484
• BROADCASTICINVAL on page 16-484
• BROADCASTMTE on page 16-484
• BROADCASTERTLBIINNER and BROADCASTTLBIOUTER on page 16-484

An implementation that includes these signals at the interface must ensure that the signal values are stable when
Reset is deasserted.

16.2.1 BROADCASTINNER and BROADCASTOUTER

The BROADCASTINNER and BROADCASTOUTER signals are used to control the issuing of Non-snoopable
transactions from an interface. It is required that these two pins must be set to the same value.

When the signals are present and deasserted, all transactions are converted to Non-snoopable equivalents before
they are sent. The transaction conversion from Snoopable to Non-snoopable, using the BROADCASTINNER and
BROADCASTOUTER signals, the following conversions apply:
• All Read transactions must be converted to ReadNoSnp.
• All Snoopable CMO transactions must be converted to Non-snoopable CMO.
• The following Dataless transactions must be dropped:
— CleanUnique
— MakeUnique
— Evict
— StashOnce
— StashOnceUnique
— StashOnceShared
• All Combined Writes must be converted to Combined WriteNoSnp.
• All Write transactions, except WriteEvictFull and WriteEvictOrEvict, must be converted to WriteNoSnp.
• WriteEvictFull and WriteEvictOrEvict transactions must be dropped.
• All Snoopable Atomic transactions must be converted to Non-snoopable.
• PrefetchTgt transaction conversion is not required.

16.2.2 BROADCASTCACHEMAINTENANCE
The BROADCASTCACHEMAINTENANCE signal is used to control the issuing of cache maintenance
operations when there are no software-managed caches downstream of the interface.

When the BROADCASTCACHEMAINTENANCE, BROADCASTINNER, and BROADCASTOUTER

signals are all present and deasserted:
• CleanShared, CleanInvalid, and MakeInvalid transactions are not issued.
• All Combined Write transactions must be converted to standalone Write transactions.

16.2.3 BROADCASTPERSIST
The BROADCASTPERSIST signal is used to control the issuing of CleanSharedPersist and
CleanSharedPersistSep Cache Maintenance Operations.

16-482 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Properties, Parameters, and Broadcast Signals
16.2 Optional interface broadcast signals

When the BROADCASTPERSIST signal is present and deasserted, CleanSharedPersist and

CleanSharedPersistSep transactions are converted to CleanShared.The conversion applies to both standalone CMO
and Combined Write transactions.

Note
The issuing of the CleanShared is controlled by the BROADCASTINNER, BROADCASTOUTER, and
BROADCASTCACHEMAINTENANCE signals.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-483
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.2 Optional interface broadcast signals

16.2.4 BROADCASTATOMIC
The BROADCASTATOMIC signal is used to control the generation of Atomic transactions:
• When asserted, the interface is permitted, but not required, to generate Atomic transactions.
• When deasserted, the interface must not generate Atomic transactions.

A Request Node is not required to make use of Atomic transactions. A Request Node that does not make use of
Atomic transactions itself, needs no added functionality to be compatible with an interconnect that supports Atomic
transactions.

A Request Node that supports atomic operations but does not include support for the execution of atomic operations
must be able to send Atomic transactions.

See Atomic transaction support on page 16-486.

16.2.5 BROADCASTICINVAL
The BROADCASTICINVAL signal at each Request Node is used to inform the Request Node that broadcasting
of Instruction Cache (ICache) invalidations using the DVM mechanism is required:
• When asserted, DVMOp for ICache Invalidations must be sent to the interconnect.
• When deasserted, DVMOp for ICache invalidations are not required to be sent to the interconnect.

In a system where all Instruction Caches are fully coherent the hardware coherency mechanism automatically
invalidates all ICache copies on a cache line update, In such systems, it is not necessary to broadcast ICache
invalidation operations.

If a system contains one or more Instruction Caches that are not updated by the hardware coherency mechanism,
then it is necessary for ICache invalidation operations to be broadcast using DVM transactions.

16.2.6 BROADCASTMTE
The BROADCASTMTE signal is used to control the issuing of requests with MTE beyond the interface:
• When asserted, requests with MTE can be sent beyond the interface.
• When deasserted, requests with MTE must not be sent beyond the interface.

The BROADCASTMTE signal is typically deasserted when the interface does not support MTE functionality.

When the BROADCASTMTE signal is deasserted, all other MTE-related interface pins must be tied to zero. The
interconnect is permitted, but not required, to remove the related MTE transport wires.

The interface fields that can be fixed to a value of zero are:

• On DAT channels:
— TagOp, Tag, and TU

• On REQ and RSP channels:

— TagOp

16.2.7 BROADCASTERTLBIINNER and BROADCASTTLBIOUTER

The BROADCASTTLBIINNER (BTI) and BROADCASTTLBIOUTER (BTO) signals are used to control the
issuing of TLBI operations in the interconnect.

16-484 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Properties, Parameters, and Broadcast Signals
16.2 Optional interface broadcast signals

Table 16-1 shows the permitted BTI and BTO signal encodings.

Table 16-1 BTI and BTO signal encodings

BTI BTO Permitted

0 0 Yes

0 1 Yes

1 0 Reserved

1 1 Yes

Note
The decision to broadcast a DVM(Sync) does not only depend on the values of BTI and BTO but must also consider
if any DVM operations other than TLBI must be pushed to their completion by the DVM(Sync).

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-485
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.3 Atomic transaction support

16.3 Atomic transaction support

The CHI component support requirements for Atomic transactions are described in the following sections:
• Request Node support
• Interconnect support on page 16-487
• Subordinate Node support on page 16-487

16.3.1 Request Node support

A Requester component is required to support a mechanism to suppress the generation of Atomic transactions to
ensure compatibility in systems where Atomic transactions are not supported. A Requester can use the optional
interface pin BROADCASTATOMIC to determine whether Atomic transactions are transmitted.

A Request Node is not required to make use of Atomic transactions. A Request Node that does not use Atomic
transactions itself needs no added functionality to be compatible with an interconnect that supports Atomic
transactions.

A Request Node that supports atomic operations but does not include support for the execution of atomic operations
must be able to send Atomic transactions.
For a Request Node that supports both the execution of atomic operations as well as the sending of Atomic
transactions, the following applies:

For cacheable locations, both Snoopable and Non-snoopable, a Request Node is able to perform an atomic operation
locally without generating an Atomic transaction at its interface. To achieve this, the Requester obtains a copy of
the location in its local cache, in the same manner that it would for a store operation, and then performs the atomic
operation within its local cache. For cacheable locations that are Snoopable, if the contents of the cache line are
updated and the cache line was not previously Dirty, then the cache line must be marked as Dirty.

16-486 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Properties, Parameters, and Broadcast Signals
16.3 Atomic transaction support

16.3.2 Interconnect support

Interconnect support for Atomic transactions is optional.

The Atomic_Transactions property is used to indicate that an interconnect supports Atomic transactions.

If Atomic transactions are not supported by the interconnect, all attached Request Nodes must be configured to not
generate Atomic transactions. The BROADCASTATOMIC pin can be used for this purpose, when implemented.
See Request Node support on page 16-486.

For interconnects that support Atomic transactions, atomic operation execution can be supported at any point within
an interconnect, including passing an Atomic transaction downstream to a Subordinate Node.

Atomic transactions are not required to be supported for every address location.

If Atomic transactions are supported for a given Snoopable address location, then they must be supported for the
complete Snoopable address range.

If Atomic transactions are not supported for a given address location, then an appropriate Error response can be
given for the Atomic transaction. See Atomic transactions on page 9-350.

For transactions to a Device, the Atomic transaction must be passed to the appropriate endpoint Subordinate. If the
Subordinate is configured to indicate that it does not support Atomic transactions, the interconnect must return an
Error response for the transaction.

For Non-snoopable transactions, the Atomic transaction must be performed either:

• At a point, or past a point, where the transaction is visible to all other agents.
• At the endpoint.

For Snoopable transactions, the interconnect can either:

• Perform the atomic operation required by an Atomic transaction within the interconnect. This requires that
the interconnect performs the appropriate Read, Write, and Snoop transactions to complete the Atomic
transaction.

• If the appropriate endpoint Subordinate is configured to indicate that it supports Atomic transactions, the
interconnect can pass the Atomic transaction to the Subordinate. The interconnect is still required to perform
the appropriate Snoop and Write transactions before issuing the Atomic transaction to the Subordinate.

16.3.3 Subordinate Node support

Subordinate Node support for Atomic transactions is optional.

The Atomic_Transaction property is used to indicate that a Subordinate Node supports Atomic transactions.

If a Subordinate Node supports Atomic transactions for particular memory types, or for particular address regions,
then on receiving an Atomic transaction that it does not support, the Subordinate Node must give an appropriate
Error response.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. 16-487
ID092622 Non-Confidential
Properties, Parameters, and Broadcast Signals
16.3 Atomic transaction support

16-488 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-491
• Response message field mappings on page A-496
• Data message field mappings on page A-497
• Snoop Request message field mappings on page A-498

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. A-489
ID092622 Non-Confidential
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

CF Common Field. Two or more protocol message fields

share the same set of bits in this packet field.

X Inapplicable. Field value can take 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.

D Inapplicable. Field value must be default setting for

MPAM fields.

8B Size field must be set to 8-byte encoding.

64B Size field must be set to 64-byte encoding.

M Field position reused for DVM operations. See

Chapter 8 DVM Operations.

- Assigned to another protocol message field that

shares the same set of bits in this packet field.

A-490 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Message Field Mappings
A.1 Request message field mappings

A.1 Request message field mappings

Table A-2 and Table A-3 on page A-492 show the Read, Dataless and Miscellaneous Request message field
mappings. See Table A-1 on page A-490 for the conventions used in the field mappings. For further information on
field use see Protocol flit fields on page 13-424.

Table A-2 Read, Dataless and Miscellaneous Request message field mappings Part 1

AllowRetry
PCrdType

TraceTag
Opcode

RSVDC
Request message

TagOp

MPAM
TxnID
SrcID
TgtID
Qos
ReqLCrdReturn X X X 0 Y X X X X X X
PCrdReturn Y Y Y 0a Y 0a Y Y 0a Y 0a
DVMOp Y Y Y Y Y Y Y Y 0a Y 0a
PrefetchTgt Y Y Y X Y 0 X Y Y Y Y
ReadNoSnp Y Y Y Y Y Y Y Y Y Y Y
ReadNoSnpSep Y Y Y Y Y Y Y Y Y Y Y
ReadOnce Y Y Y Y Y Y Y Y Y Y Y
ReadOnceCleanInvalid Y Y Y Y Y Y Y Y Y Y Y
ReadOnceMakeInvalid Y Y Y Y Y Y Y Y Y Y Y
ReadClean Y Y Y Y Y Y Y Y Y Y Y
ReadNotSharedDirty Y Y Y Y Y Y Y Y Y Y Y
ReadShared Y Y Y Y Y Y Y Y Y Y Y
ReadUnique Y Y Y Y Y Y Y Y Y Y Y
ReadPreferUnique Y Y Y Y Y Y Y Y Y Y Y
MakeReadUnique Y Y Y Y Y Y Y Y Y Y Y
CleanShared Y Y Y Y Y Y Y Y Y Y Y
CleanSharedPersist Y Y Y Y Y Y Y Y Y Y Y
CleanSharedPersistSep Y Y Y Y Y Y Y Y Y Y Y
CleanInvalid Y Y Y Y Y Y Y Y Y Y Y
MakeInvalid Y Y Y Y Y Y Y Y Y Y Y
CleanUnique Y Y Y Y Y Y Y Y Y Y Y
MakeUnique Y Y Y Y Y Y Y Y Y Y Y
Evict Y Y Y Y Y Y Y Y Y Y Y

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. A-491
ID092622 Non-Confidential
Message Field Mappings
A.1 Request message field mappings

Table A-3 Read, Dataless and Miscellaneous Request message field mappings Part 2

MemAttr CF CF CF CF CF CF

StashLPIDValid
StashNIDValid
StashGroupID
ExpCompAck
LikelyShared

ReturnTxnID
SLCRepHint
TagGroupID
Cacheable

StashLPID
ReturnNID
PGroupID
SnoopMe

StashNID
Request message

Allocate

SnpAttr
DoDWT

Endian
Device
Order

Deep
Addr

EWA

LPID
Excl
Size
ReqLCrdReturn NS X X X X X X X X X X X X X X X X
PCrdReturn 0a 0a 0a 0a 0a 0 0a 0a 0a 0a 0a - 0a 0a 0a 0a 0a
DVMOp M 0a 8B 0a 0a 0 0a 0a 0a 0a M - 0a Y - - - 0a 0a 0a
PrefetchTgt Y Y X X X 0a X X X X X X - Y - - - 0a X 0a
ReadNoSnp Y Y Y Y 0 Y Y Y Y Y 0 - Y - Y - - - Y - Y 0a Y - -
ReadNoSnpSep Y Y Y Y 0 0 Y Y Y Y 0 - 0 - Y - - - Y - Y 0a Y - -
ReadOnce Y Y 64B Y 0 Y Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
ReadOnceCleanInvalid Y Y 64B Y 0 Y Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
ReadOnceMakeInvalid Y Y 64B Y 0 Y 0 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
ReadClean Y Y 64B 0 Y 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
ReadNotSharedDirty Y Y 64B 0 Y 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
ReadShared Y Y 64B 0 Y 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
ReadUnique Y Y 64B 0 0 1 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
ReadPreferUnique Y Y 64B 0 0 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
MakeReadUnique Y Y 64B 0 0 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
CleanShared Y Y 64B 0a 0 0 Y Y Y Y Y - 0 - Y - - - - - Y 0a 0a
CleanSharedPersist Y Y 64B 0a 0 0 Y Y Y Y Y - 0 - 0a - - Y - - Y 0a
CleanSharedPersistSep Y Y 64B 0a 0 0 Y Y Y Y Y - 0 - - - - Y Y - Y - - Y 0a
CleanInvalid Y Y 64B 0a 0 0 Y Y Y Y Y - 0 - Y - - - - - Y 0a 0a
MakeInvalid Y Y 64B 0a 0 0 Y Y Y Y Y - 0 - Y - - - - - Y 0a 0a
CleanUnique Y Y 64B 0 0 1 Y 1 0 1 1 - Y - Y - - - - - Y 0a 0a
MakeUnique Y Y 64B 0 0 1 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
Evict Y Y 64B 0 0 0 0 1 0 1 1 - 0 - Y - - - - - Y 0a 0a

A-492 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Message Field Mappings
A.1 Request message field mappings

Table A-4 and Table A-5 on page A-494 show the Write and Combined Write Request message field mappings. See
Table A-1 on page A-490 for the conventions used in the field mappings. For further information on field use see
Protocol flit fields on page 13-424.
Table A-4 Write and Combined Write Request message field mappings Part 1

AllowRetry
PCrdType

TraceTag
Opcode

RSVDC
Request message

TagOp

MPAM
TxnID
SrcID
TgtID
Qos
WriteNoSnpPtl Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpPtlCleanInv Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpPtlCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpPtlCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpFull Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpFullCleanInv Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpFullCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpFullCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteNoSnpZero Y Y Y Y Y Y Y Y Y Y Y
WriteUniquePtlStash Y Y Y Y Y Y Y Y Y Y Y
WriteUniqueFullStash Y Y Y Y Y Y Y Y Y Y Y
WriteUniquePtl Y Y Y Y Y Y Y Y Y Y Y
WriteUniquePtlCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteUniquePtlCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteUniqueFull Y Y Y Y Y Y Y Y Y Y Y
WriteUniqueFullCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteUniqueFullCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteUniqueZero Y Y Y Y Y Y Y Y Y Y Y
WriteBackPtl Y Y Y Y Y Y Y Y Y Y Y
WriteBackFull Y Y Y Y Y Y Y Y Y Y Y
WriteBackFullCleanInv Y Y Y Y Y Y Y Y Y Y Y
WriteBackFullCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteBackFullCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteCleanFull Y Y Y Y Y Y Y Y Y Y Y
WriteCleanFullCleanSh Y Y Y Y Y Y Y Y Y Y Y
WriteCleanFullCleanShPerSep Y Y Y Y Y Y Y Y Y Y Y
WriteEvictFull Y Y Y Y Y Y Y Y Y Y Y
WriteEvictOrEvict Y Y Y Y Y Y Y Y Y Y Y

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. A-493
ID092622 Non-Confidential
Message Field Mappings
A.1 Request message field mappings

Table A-5 Write and Combined Write Request message field mappings Part 2

MemAttr CF CF CF CF CF CF

StashLPIDValid
StashNIDValid
StashGroupID
ExpCompAck
LikelyShared

ReturnTxnID
SLCRepHint
TagGroupID
Cacheable

StashLPID
ReturnNID
PGroupID
SnoopMe

StashNID
Request message

Allocate

SnpAttr
DoDWT

Endian
Device
Order

Deep
Addr

EWA

LPID
Excl
Size
WriteNoSnpPtl NS
Y Y Y Y 0 Y Y Y Y Y 0 Y Y - Y - - Y - Y 0a Y - -
WriteNoSnpPtlCleanInv Y Y Y Y 0 Y Y Y Y Y 0 Y 0 - Y - - Y - Y 0a Y - -
WriteNoSnpPtlCleanSh Y Y Y Y 0 Y Y Y Y Y 0 Y 0 - Y - - Y - Y 0a Y - -
WriteNoSnpPtlCleanShPerSep Y Y Y Y 0 Y Y Y Y Y 0 Y 0 - - - - Y Y - Y - - Y Y - -
WriteNoSnpFull Y Y 64B Y 0 Y Y Y Y Y 0 Y Y - Y - - Y - Y 0a Y - -
WriteNoSnpFullCleanInv Y Y 64B Y 0 Y Y Y Y Y 0 Y 0 - Y - - Y - Y 0a Y - -
WriteNoSnpFullCleanSh Y Y 64B Y 0 Y Y Y Y Y 0 Y 0 - Y - - Y - Y 0a Y - -
WriteNoSnpFullCleanShPerSep Y Y 64B Y 0 Y Y Y Y Y 0 Y 0 - - - - Y Y - Y - - Y Y - -
WriteNoSnpZero Y Y 64B Y 0 0 Y Y Y Y 0 0a 0 - Y - - - - - Y 0a 0a
WriteUniquePtlStash Y Y Y Y Y Y Y 1 0 1 1 - 0 - Y - - - Y Y - - - Y
WriteUniqueFullStash Y Y 64B Y Y Y Y 1 0 1 1 - 0 - Y - - - Y Y - - - Y
WriteUniquePtl Y Y Y Y Y Y Y 1 0 1 1 - 0 - Y - - - - Y 0a 0a
WriteUniquePtlCleanSh Y Y Y Y Y Y Y 1 0 1 1 - 0 - Y - - - - Y 0a 0a
WriteUniquePtlCleanShPerSep Y Y Y Y Y Y Y 1 0 1 1 - 0 - - - - Y - - Y - - Y 0a
WriteUniqueFull Y Y 64B Y Y Y Y 1 0 1 1 - 0 - Y - - - - Y 0a 0a
WriteUniqueFullCleanSh Y Y 64B Y Y Y Y 1 0 1 1 - 0 - Y - - - - Y 0a 0a
WriteUniqueFullCleanShPerSep Y Y 64B Y Y Y Y 1 0 1 1 - 0 - - - - Y - - Y - - Y 0a
WriteUniqueZero Y Y 64B Y Y 0 Y 1 0 1 1 - 0 - Y - - - - Y 0a 0a
WriteBackPtl Y Y 64B 0 0 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteBackFull Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteBackFullCleanInv Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteBackFullCleanSh Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteBackFullCleanShPerSep Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - - - - Y - - Y - - Y 0a
WriteCleanFull Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteCleanFullCleanSh Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteCleanFullCleanShPerSep Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - - - - Y - - Y - - Y 0a
WriteEvictFull Y Y 64B 0 Y 0 1 1 0 1 1 - 0 - Y - - - - - Y 0a 0a
WriteEvictOrEvict Y Y 64B 0 Y 1 1 1 0 1 1 - 0 - Y - - - - - Y 0a 0a

A-494 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Message Field Mappings
A.1 Request message field mappings

Table A-6 and Table A-7 on page A-495 show the Stash and Atomic Request message field mappings. See
Table A-1 on page A-490 for the conventions used in the field mappings. For further information on field use see
Protocol flit fields on page 13-424.
Table A-6 Stash and Atomic Request message field mappings part 1

AllowRetry
PCrdType

TraceTag
Opcode

RSVDC
Request message

TagOp

MPAM
TxnID
SrcID
TgtID
Qos
StashOnceUnique Y Y Y Y Y Y Y Y Y Y Y
StashOnceSepUnique Y Y Y Y Y Y Y Y Y Y Y
StashOnceShared Y Y Y Y Y Y Y Y Y Y Y
StashOnceSepShared Y Y Y Y Y Y Y Y Y Y Y
AtomicLoad Y Y Y Y Y Y Y Y Y Y Y
AtomicStore Y Y Y Y Y Y Y Y Y Y Y
AtomicCompare Y Y Y Y Y Y Y Y Y Y Y
AtomicSwap Y Y Y Y Y Y Y Y Y Y Y

Table A-7 Stash and Atomic Request message field mappings part 2

MemAttr CF CF CF CF CF CF

StashLPIDValid
StashNIDValid
StashGroupID
ExpCompAck
LikelyShared

ReturnTxnID
SLCRepHint
TagGroupID
Cacheable

StashLPID
ReturnNID
PGroupID
SnoopMe

StashNID
Request message
Allocate

SnpAttr
DoDWT

Endian
Device
Order

Deep
Addr

EWA

LPID
Excl
Size
NS

StashOnceUnique Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - Y Y - - - Y
StashOnceSepUnique Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - - - Y - - Y Y - - - Y
StashOnceShared Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - Y - - - - Y Y - - - Y
StashOnceSepShared Y Y 64B 0 Y 0 Y 1 0 1 1 - 0 - - - Y - - Y Y - - - Y
AtomicLoad Y Y Y Y 0 0 Y Y Y Y Y - - Y Y - - Y - - - Y - Y - -
AtomicStore Y Y Y Y 0 0 Y Y Y Y Y - - Y Y - - Y - - - Y - X - -
AtomicCompare Y Y Y Y 0 0 Y Y Y Y Y - - Y Y - - Y - - - Y - Y - -
AtomicSwap Y Y Y Y 0 0 Y Y Y Y Y - - Y Y - - Y - - - Y - Y - -

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. A-495
ID092622 Non-Confidential
Message Field Mappings
A.2 Response message field mappings

A.2 Response message field mappings

Table A-8 shows the Response message field mappings. See Table A-1 on page A-490 for the conventions used in
the field mappings. For further information on field use see Protocol flit fields on page 13-424.
Table A-8 Response message field mappings

CF CF

StashGroupID
TagGroupID
Response message

PGroupID
PCrdType

FwdState
TraceTag

DataPull
RespErr
Opcode

CBusy

TagOp
TxnID
SrcID
TgtID

DBID
Resp
QoS
RspLCrdReturn X X X 0 Y X X X X X X X X
SnpResp Y Y Y Y Y Y Y Y 0a Y 0a Y - - - - Y
SnpRespFwded Y Y Y Y Y Y Y Y 0a Y 0a X - - - Y -
CompAck Y Y Y Y Y 0 0a 0a 0a Y 0a X - - - 0a
RetryAck Y Y Y Y Y 0 0a Y 0a Y Y X - - - 0a
Comp Y Y Y Y Y Y Y Y Y Y 0a Y - - - 0a
CompCMO Y Y Y Y Y Y Y Y 0a Y 0a X - - - 0a
Persist Y Y Y 0a Y Y 0a Y 0a X 0a - - - Y 0a
CompPersist Y Y Y Y Y Y Y Y 0a Y 0a - - - Y 0a
StashDone Y Y Y 0a Y Y 0a Y 0a X 0a - - Y - 0a
CompStashDone Y Y Y Y Y Y Y Y 0a Y 0a - - Y - 0a
RespSepData Y Y Y Y Y Y Y Y 0a Y 0a Y - - - 0a
CompDBIDResp Y Y Y Y Y Y 0 Y 0a Y 0a Y - - - 0a
DBIDResp Y Y Y Y Y 0 0a Y 0a Y 0a Y - - - 0a
DBIDRespOrd Y Y Y Y Y 0 0a Y 0a Y 0a Y - - - 0a
TagMatch Y Y Y 0a Y Y Y Y 0a X 0a - Y - - 0a
PCrdGrant Y Y Y 0a Y 0 0a Y 0a Y Y 0a 0a
ReadReceipt Y Y Y Y Y 0 0a Y 0a Y 0a X - - - 0a

A-496 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Message Field Mappings
A.3 Data message field mappings

A.3 Data message field mappings

Table A-9 shows the Data message field mappings. See Table A-1 on page A-490 for the conventions used in the
field mappings. For further information on field use see Protocol flit fields on page 13-424.
Table A-9 Data message field mappings

CF

DataSource
DataCheck
HomeNID

FwdState
TraceTag

DataPull
RespErr
Opcode

RSVDC
Data message

Poison
CBusy

DataID

TagOp
TxnID
SrcID
TgtID

Resp

DBID
CCID

Data
Qos

Tag
BE

TU
DatLCrdReturn X X X 0 Y X X X X X X X X X X X X X X X X X
SnpRespData Y Y Y Y Y Y Y Y Y Y Y Y Y Y 0a Y Y Y Y Y Y - Y
SnpRespDataFwded Y Y Y Y Y Y Y Y X Y Y Y Y Y 0a Y Y Y Y Y Y Y - -
CopyBackWrData Y Y Y Y Y Y Y 0a X Y Y Y Y Y 0a Y Y Y Y Y Y 0a
NonCopyBackWrData Y Y Y Y Y Y Y 0a X Y Y Y Y Y 0a Y Y Y Y Y Y 0a
NCBWrDataCompAck Y Y Y Y Y Y Y 0a X Y Y Y Y Y 0a Y Y Y Y Y Y 0a
CompData Y Y Y Y Y Y Y Y Y Y Y Y X Y Y Y Y Y Y Y Y - - Y
DataSepResp Y Y Y Y Y Y Y Y Y Y Y Y X Y Y Y Y Y Y Y Y - - Y
SnpRespDataPtl Y Y Y Y Y Y Y Y Y Y Y Y Y Y 0a Y Y Y Y Y Y - Y
WriteDataCancel Y Y Y Y Y Y Y 0a X Y Y Y 0 0 0a Y Y Y Y Y Y 0a

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. A-497
ID092622 Non-Confidential
Message Field Mappings
A.4 Snoop Request message field mappings

A.4 Snoop Request message field mappings

Table A-10 shows the snoop request message field mappings. See Table A-1 on page A-490 for the conventions
used in the field mappings. For further information on field use see Protocol flit fields on page 13-424.
Table A-10 Snoop Request message field mappings

CF

StashLPIDValid
Addr[(43-51):3]

DoNotGoToSD
Snoop Request message

StashLPID
FwdTxnID
RetToSrc

TraceTag

VMIDExt
Opcode

FwdNID

MPAM
TxnID
SrcID
QoS

NS
SnpLCrdReturn X X 0 Y X X X X X X X X
SnpShared Y Y Y Y Y Y 0a Y Y Y D 0a
SnpClean Y Y Y Y Y Y 0a Y Y Y D 0a
SnpOnce Y Y Y Y Y Y 0a Y Y Y D 0a
SnpNotSharedDirty Y Y Y Y Y Y 0a Y Y Y D 0a
SnpUnique Y Y Y Y Y Y 0a 1 Y Y D 0a
SnpPreferUnique Y Y Y Y Y Y 0a Y Y Y D 0a
SnpCleanShared Y Y Y Y Y Y 0a 1 0a Y D 0a
SnpCleanInvalid Y Y Y Y Y Y 0a 1 0a Y D 0a
SnpMakeInvalid Y Y Y Y Y Y 0a 1 0a Y D 0a
SnpSharedFwd Y Y Y Y Y Y Y Y 0a Y D Y - - -
SnpCleanFwd Y Y Y Y Y Y Y Y 0a Y D Y - - -
SnpOnceFwd Y Y Y Y Y Y Y Y 0a Y D Y - - -
SnpNotSharedDirtyFwd Y Y Y Y Y Y Y Y 0a Y D Y - - -
SnpUniqueFwd Y Y Y Y Y Y Y 1 0a Y D Y - - -
SnpPreferUniqueFwd Y Y Y Y Y Y Y Y 0a Y D Y - - -
SnpUniqueStash Y Y Y Y Y Y 0a 1 0a Y Y - Y -
SnpMakeInvalidStash Y Y Y Y Y Y 0a 1 0a Y Y - Y -
SnpStashUnique Y Y Y Y Y Y 0a 1 0a Y Y - Y -
SnpStashShared Y Y Y Y Y Y 0a 1 0a Y Y - Y -
SnpQuery Y Y Y Y Y Y 0a 0a 0a Y D 0a
SnpDVMOp Y Y Y Y M 0a M 0a 0a Y 0a - - - Y

A-498 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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-500.
• Snoop communicating nodes on page B-502.
• Response communicating nodes on page B-503.
• Data communicating nodes on page B-504.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. B-499
ID092622 Non-Confidential
Communicating Nodes
B.1 Request communicating nodes

B.1 Request communicating nodes

Table B-1 shows the Request communicating nodes. In Table B-1, unless explicitly stated otherwise, a reference to
a Write transaction includes both the individual Write transaction and the corresponding Combined Write
transaction.

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 a software based error. 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) -

WriteNoSnpPtl
ICN(HN-F) SN-F -
WriteNoSnpFull
WriteNoSnpZero ICN(HN-I) SN-I -

ReadNoSnpSep ICN(HN-F) SN-F -

ICN(HN-I) SN-I -

ReadClean RN-F ICN(HN-F) ICN(HN-I)

ReadShared
ReadNotSharedDirty
ReadUnique
ReadPreferUnique
MakeReadUnique
CleanUnique
MakeUnique
Evict
WriteBackPtl
WriteBackFull
WriteCleanFull
WriteEvictFull
WriteEvictOrEvict

ReadOnce RN-F, RN-D, RN-I ICN(HN-F) ICN(HN-I)

ReadOnceCleanInvalid
ReadOnceMakeInvalid
StashOnceUnique
StashOnceShared
StashOnceSepUnique
StashOnceSepShared
WriteUniqueFull
WriteUniqueFullStash
WriteUniquePtl
WriteUniquePtlStash
WriteUniqueZero

B-500 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Communicating Nodes
B.1 Request communicating nodes

Table B-1 Request communicating nodes (continued)

Request From To

Expected Permitted

CleanShared RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

CleanSharedPersist
ICN(HN-F) SN-F -
CleanSharedPersistSep
CleanInvalid ICN(HN-I) SN-I -
MakeInvalid

WriteUniquePtlCleanSh RN-F ICN(HN-F) ICN(HN-I)

WriteUniquePtlCleanShPerSep
WriteUniqueFullCleanSh
WriteUniqueFullCleanShPerSep
WriteBackFullCleanInv
WriteBackFullCleanSh
WriteBackFullCleanShPerSep
WriteCleanFullCleanSh
WriteCleanFullCleanShPerSep

WriteNoSnpPtlCleanInv RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

WriteNoSnpPtlCleanSh
ICN(HN-F) SN-F -
WriteNoSnpPtlCleanShPerSep
WriteNoSnpFullCleanInv ICN(HN-I) SN-I -
WriteNoSnpFullCleanSh
WriteNoSnpFullCleanShPerSep

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 -

AtomicStore RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

AtomicLoad
ICN(HN-F) SN-F -
AtomicSwap
AtomicCompare ICN(HN-I) SN-I -

PrefetchTgt RN-F, RN-D, RN-I SN-F -

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. B-501
ID092622 Non-Confidential
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

SnpShared ICN(HN-F) RN-F

SnpClean
SnpOnce
SnpNotSharedDirty
SnpUnique
SnpPreferUnique
SnpCleanShared
SnpCleanInvalid
SnpMakeInvalid
SnpSharedFwd
SnpCleanFwd
SnpOnceFwd
SnpNotSharedDirtyFwd
SnpUniqueFwd
SnpPreferUniqueFwd
SnpUniqueStash
SnpMakeInvalidStash
SnpStashUnique
SnpStashShared
SnpQuery

SnpDVMOp ICN(MN) RN-F, RN-D

B-502 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 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

PCrdGrant
SN-F ICN(HN-F)
Comp
CompDBIDResp SN-I ICN(HN-I)

CompCMO ICN(HN-F, HN-I) RN-F, RN-D, RN-I

ReadReceipt
SN-F ICN(HN-F)

SN-I ICN(HN-I)

RespSepData ICN(HN-F, HN-I) RN-F, RN-D, RN-I

DBIDResp ICN(HN-F, HN-I, MN) RN-F, RN-D, RN-I

SN-F ICN(HN-F), RN-F, RN-D, RN-I

SN-I ICN(HN-I), RN-F, RN-D, RN-I

DBIDRespOrd ICN(HN-F, HN-I) RN-F, RN-D, RN-I

StashDone ICN(HN-F) RN-F, RN-D, RN-I

CompStashDone

TagMatch ICN(HN-F) RN-F, RN-D, RN-I

SN-F ICN(HN-F), RN-F, RN-D, RN-I

Persist ICN(HN-F, HN-I) RN-F, RN-D, RN-I

SN-F ICN(HN-F), RN-F, RN-D, RN-I

SN-I ICN(HN-I), RN-F, RN-D, RN-I

CompPersist ICN(HN-F, HN-I) RN-F, RN-D, RN-I

SN-F ICN(HN-F)

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)

SnpRespFwded RN-F ICN(HN-F)

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. B-503
ID092622 Non-Confidential
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. In Table B-4, unless explicitly stated otherwise, a reference to a Write transaction includes both
the individual Write transaction and the corresponding Combined Write transaction.

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 RN-F, RN-D, RN-I, ICN(HN-F) -

SN-I RN-F, RN-D, RN-I, ICN(HN-I) -

DataSepResp ICN(HN-F, HN-I) RN-F, RN-D, RN-I -

SN-F RN-F, RN-D, RN-I ICN(HN-F)

SN-I RN-F, RN-D, RN-I ICN(HN-I)

Downstream CopyBackWrData RN-F ICN(HN-F) ICN(HN-I)

WriteDataCancel RN-F, RN-D, RN-I ICN(HN-F, HN-I), SN-F, SN-I -

ICN(HN-F) SN-F -

ICN(HN-I) SN-I -

NonCopyBackWrData RN-F, RN-D, RN-I ICN(HN-F, HN-I), SN-F, SN-I -

RN-F, RN-D ICN(MN) -

ICN(HN-F) SN-F -

ICN(HN-I) SN-I -

NCBWrDataCompAck RN-F, RN-D, RN-I ICN(HN-F, HN-I) -

SnpRespData RN-F ICN(HN-F) -

SnpRespDataFwded
SnpRespDataPtl

Peer-to-Peer CompData RN-F RN-F, RN-D, RN-I -

B-504 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
Appendix C
Revisions

This appendix describes the technical changes between released issues of this specification.

Table C-1 Issue B

Change Location

No changes, first public release −

Table C-2 Issue C

Change Location

New feature: Response after receiving first Data packet. Allocating Read on page 2-47.
Non-allocating Read on page 2-50.

New feature: Separate Non-data and Data-only response. Read transactions on page 2-47 and multiple related
locations.

New feature: Combined CompAck with WriteData. WriteUnique transaction on page 2-115 and multiple
related locations.

Clarification: Regarding byte enables for Write transactions. Byte Enables on page 2-143.

Update: Concerning the list of fields that can change value from Request Retry on page 2-154.
the original request in the retried request.

Clarification: Concerning the transaction responses permitted to At the RN-F node on page 4-253.
be sent to the same address when a Snoop transaction response
is pending.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. C-505
ID092622 Non-Confidential
Revisions

Table C-2 Issue C (continued)

Change Location

Additional information: Concerning Legal RespErr field values Table 9-7 on page 9-348.
for WriteDataCancel.

Clarification: Regarding TraceTag field value propagation. TraceTag usage and rules on page 11-376.

Corrections and additions: Concerning message field mappings. Table A-3 on page A-492, Table A-8 on page A-496,
and Table A-9 on page A-497.

Table C-3 Issue D

Change Location

New feature: Persistent CMO with two part response. Dataless transactions on page 2-80.
Dataless transactions on page 2-109.
Cache Maintenance transactions on page 4-181.
Transaction identifier fields on page 2-93.
Persistent CMO with snoop and separate Comp and
Persist on page 5-268.
Interface properties and parameters on page 16-478.
Dataless transactions on page 9-347.

New feature: Deep Persistent cache maintenance. Cache Maintenance transactions on page 4-181.
Deep persistence, Deep on page 13-434.

New feature: Interface Parity. Use of interface parity on page 9-357.

Interface properties and parameters on page 16-478.

New feature: Memory System Performance Resource Partitioning and MPAM on page 11-373.
Monitoring (MPAM). Interface properties and parameters on page 16-478.

New feature: Completer Busy indication. Completer Busy on page 11-375.

New feature: ICache Invalidation broadcast signal. Optional interface broadcast signals on page 16-482.

Additional requirement: Concerning SACTIVE synchronization to CLK. Protocol layer activity indication on page 14-468.

Additional requirement: Concerning SYSCOREQ and SYSCOACK Chapter 15 System Coherency Interface.
synchronization to CLK.

Correction: Concerning the use of RXSACTIVE to directly generate the TXSACTIVE signal on page 14-468.
TXSACTIVE signal.

Update: Concerning Ordered Write Observation flow enhancements. Streaming Ordered Write transactions on page 2-129.

Update: Concerning the relaxation of the order requirement between Cache Cache Maintenance transactions on page 4-181.
Maintenance transactions and any other transaction to the same address.

Update: Concerning UD_PD state is permitted on a DataSepResp Read and Atomic transaction completion on
response. page 4-208.

Update: Concerning DVM early Comp. DVM early Comp for Non-sync DVMOps on
page 8-315.

C-506 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Revisions

Table C-3 Issue D (continued)

Change Location

Update: Concerning increased TxnID width. Flit packet definitions on page 13-418.

Clarification: Regarding when a RespSepData response includes a Read transactions on page 9-345.
Non-data Error.

Clarification: Regarding when the DataPull bit is set in a SnpRespData Data Pull, DataPull on page 13-441.
message.

Table C-4 Issue E.a

Change Location

New feature: Writes with optional Data: CopyBack Write on page 2-61.
• WriteEvictOrEvict. CopyBack transactions on page 4-188.
Chapter 9 Error Handling.
Chapter 12 Memory Tagging.

New feature: Write Zero with no Data: Immediate write on page 2-55.
• WriteNoSnpZero. Transaction ordering on page 2-125.
• WriteUniqueZero. Write transactions on page 4-187.
Chapter 9 Error Handling.
Chapter 12 Memory Tagging.

New feature: SnpQuery Snoop request. Snoop request types on page 4-201.
Chapter 9 Error Handling.

New feature: DBIDRespOrd response. Immediate write on page 2-55.

Miscellaneous response on page 4-218.

New feature: New transactions to support Exclusive reads: Read transactions on page 2-47.
• ReadPreferUnique. Stash transactions on page 2-76.
• SnpPreferUnique. Read transactions on page 4-173.
• SnpPreferUniqueFwd. Snoop request types on page 4-201.
• MakeReadUnique. MakeReadUnique transaction on page 4-224.
• MakeReadUnique(Excl). Exclusive transactions on page 6-296.
MakeReadUnique(Excl) on page 6-298.
Chapter 9 Error Handling.
Chapter 12 Memory Tagging.

New feature: Direct Write-data Transfer. Write Transactions on page 2-55.

Do Direct Write Transfer, DoDWT on page 13-438.

New feature: Combined Write transactions: Transaction classification on page 1-27.

• CompCMO. Combined Immediate Write and CMO on page 2-62.
Combined Write requests on page 4-192.

New feature: Two-part StashOnce transaction including: Stash transactions on page 2-76
• StashOnceSep requests. StashOnce or StashOnceSep transaction on page 2-117.
• StashDone response. Dataless transactions on page 4-180.
• CompStashDone response. Independent Stash request on page 7-307.
Chapter 9 Error Handling.
Chapter 12 Memory Tagging.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. C-507
ID092622 Non-Confidential
Revisions

Table C-4 Issue E.a (continued)

Change Location

New feature: Forward indication on Snoop forward treated as a hint. Request transactions and corresponding Snoop requests
on page 4-204.

New feature: Increasing inter-port bandwidth: Increasing inter-port bandwidth on page 13-410.
• Multiple interfaces.
• Replicated channels.

New feature: Memory tagging. Chapter 12 Memory Tagging.

New feature: Extending DVM operations: Chapter 8 DVM Operations.

• Range based TLBI.
• Level hint in TLBI operations,
• DVM Domain.

New feature: SLC replacement hint. SLC replacement hint on page 11-371.

Additional requirement: Concerning Transaction Ordering guarantees. Transaction ordering on page 2-125.

Additional requirement: Concerning change in WriteNoSnpFull behavior. Write Transactions on page 2-55.

Correction: Concerning Size field value in ReadNoSnpSep. Read transactions on page 4-173.

Correction: Concerning the Ordering guarantees provided by the Comp and Completion response and ordering on page 2-121.
CompData response.

Update: Concerning removal of the DoNotDataPull attribute on snoops. -

Update: Concerning extending the GroupID field width. See Table C-5 on page C-509 for further information.

Update: Concerning extending the TxnID field width. Flit packet definitions on page 13-418.

Update: Concerning ICache invalidation operations. Virtual Instruction Cache Invalidate on page 8-338.

Update: Concerning Secure EL2 TLBI operations. TLB Invalidate on page 8-330.

Update: Concerning the Order requirements between transactions with Transaction ordering on page 2-125.
different Order field values.a

Clarification: Regarding Comp and cancelled Write. Write Transactions on page 2-55.

Clarification: Regarding CopyBack Write transaction and RetryAck Request Retry on page 2-154.
response.

Clarification: Regarding the SnpAttr and Cacheable field value in a Cache Maintenance transactions on page 4-181.
standalone CMO transaction.

Clarification: Regarding the attributes of Exclusive accesses. Exclusive monitors on page 6-293.

Clarification: Regarding the receiving of WriteData and the sending of the Cache Maintenance transactions on page 4-181.
Persist response.

a. This Update applies retroactively to CHI Issue D.

C-508 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Revisions

Table C-5 Issue E.b

Change Location

Update: All offensive terminology has been replaced per Arm’s Throughout the specification.
commitment to progressive terminology.

Update: Restructured and reformatted Transaction structures section. Transaction structure on page 2-46

Clarification: SnpAttr bit reuse in DVMOp and inapplicability in Table 2-13 on page 2-140
PrefetchTgt.

Update: SLCRepHint value is permitted to be different in the resent Request Retry on page 2-154
request.

Clarification: Simultaneous pending of CMO and allocating requests to the Cache Maintenance transactions on page 4-181
same address.

Correction: Request Order permitted in WriteNoSnpZero from HN-I to Immediate Write transactions on page 4-187
SN-I.

Update: Re-write of transactions, grouping common characteristics. Request types on page 4-172

Clarification: Permitted attribute values for requests, initial cache state at Request types on page 4-172
the Requester, and final cache state at the Requester outlined.

Correction: Order field value 0b00 and 0b01 permitted in ReadNoSnpa. Read transactions on page 4-173

Correction: Security field 0b10 in PCI DVM operation expanded to include Table 8-5 on page 8-323
both Secure and Non-secure.

Clarification: Corrupt data must be marked with Poison, DERR, or Error response use by transaction type on page 9-345
NDERR.

Clarification: Poison on MTE is not supported. Poison on page 9-355

Non-Tag Match errors on page 12-394

Correction: Legal RespErr field tables corrected. Table 9-6 on page 9-348

Correction: Transaction error cannot be indicated in DBIDResp response. Table 9-6 on page 9-348

Update: All four combinations of Request NS and MPAMNS field values MPAMNS on page 11-373
are legalb.

Clarification: MTE fields are inapplicable and must be set to zero in TagOp, TU, and tags relationship on page 12-386
WriteDataCancel write data response.

Update: Redundant GroupIDExt field definition is removed from the Protocol flit fields on page 13-424
specification

Clarification: Re-write of protocol flit fields. Protocol flit fields on page 13-424

Correction: Requirements for DoNotGoToSD in SnpQuery updated. Do not transition to SD state, DoNotGoToSD on
page 13-442

Correction: Link deactivation and sending of protocol flits updated. Race Table 14-3 on page 14-459
conditions section deleted.

Clarification: Restructured and reformatted Broadcast signals. Optional interface broadcast signals on page 16-482

Correction: TagGroupID field is applicable in WriteNoSnpPtl, Table A-5 on page A-494

WriteNoSnpFull, WriteUniquePtlStash, WriteUniqueFullStash,
WriteUniquePtl, and WriteUniqueFull.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. C-509
ID092622 Non-Confidential
Revisions

Table C-5 Issue E.b (continued)

Change Location

Correction: PGroupID field applicable in WriteNoSnpPtl, Table A-5 on page A-494

WriteNoSnpFull, WriteUniquePtl, WriteUniqueFull, WriteCleanFull, and
WriteBackFull.

Correction: Deep field in all CleanSharedPersist* and Table A-5 on page A-494
Write*CleanShPerSep requests applicable.

Correction: SLCRepHint not applicable for Atomic transactions Table A-7 on page A-495

Clarification: UniqueDirtyPartial cache line can have none, some, or all Cache state model on page 1-32 and Cache line states on
bytes valid. page 4-170

a. This correction is applied retrospectively to CHI Issue C, Issue D, and Issue E.a.
b. This update is applied retrospectively to CHI Issue D and Issue E.a.

Table C-6 Issue E.c

Change Location

Editorial edits Throughout the specification

Clarification: Cancellation of CopyBack requests following overlapping At the RN-F node on page 4-253,
snoop Table 4-28 on page 4-211, and Table 4-40 on page 4-230

Defect: ReadReceipt not optional in certain transaction flows Figure 2-1 on page 2-48 and Table 2-6 on page 2-54

Clarification: DVM payload encoding for Instruction cache invalidations Table 8-6 on page 8-325

Clarification: Typographical error in example WriteUniqueStash with Figure 5-23 on page 5-280
Data Pull transaction flow

Clarification: Requirements for ReadOnceMakeInvalid when invalidating Read transactions on page 4-173
a Dirty copy

Clarification: Requirements for Completer read response when MTE is not MTE not supported on page 12-395
supported

Clarification: Data_Check and Check_Type property descriptions Data Check on page 9-356, Data_Check on page 16-479,
and Check_Type on page 16-479

Clarification: Typographical error in Request Node to Home node request RN to HN Write request attribute values on page 4-189
attribute values table

Clarification: DBID value in Comp and DBIDResp messages that Data Buffer Identifier, DBID on page 2-94
originate from different sources in DWT flow have no relationship

Clarification: Field consistency requirements for data messages split into Data packetization on page 2-144
multiple packets

C-510 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
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 hierarchy
The organization of different size caches in a hierarchy, typically with the cache with faster access and smaller size
closer to the core and larger and slower access ones farther away from the core. The last level of this hierarchy might
be connected to the memory. In this specification, in relation to a referenced cache, above refers to caches closer to
the core, and below refers to caches farther from the core.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. Glossary-511
ID092622 Non-Confidential
Glossary

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.

Cache state State of a block of data in a cache, of 64-byte size in this specification. The state determines if the block is cached
in any other caches in the system and also if it is different from the copy of the block in memory. See Cache state
model on page 1-32 for a description of the cache states supported in this specification.

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-25.

Component A distinct functional unit that has at least one AMBA interface. Component can be used as a general term for
Requester, Subordinate, peripheral, and interconnect components.

See also Interconnect component, Requester component, Memory Subordinate component, Peripheral Subordinate
component, Subordinate 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 Subordinate component.

Direct Data Transfer

Sending Read data directly from a Snoopee or Subordinate to the Requester bypassing the Home Node.

Downstream A transaction operates between a Requester component and one or more Subordinate 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 Subordinate component, and includes the destination Subordinate
component.

Downstream and upstream are defined relative to the transaction as a whole, not relative to individual data flows
within the transaction.

See also Requester component, Peer to Peer, Subordinate component, Upstream.

Downstream Cache
See Downstream cache on page 1-24.

Endpoint See Endpoint on page 1-25.

Final Destination
Final destination for a Memory transaction is a peripheral or physical memory, also called an Endpoint.

Flit See Flit on page 1-24.

HN See HN on page 1-25.

Glossary-512 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Glossary

ICN See ICN on page 1-25.

In a timely manner
See In a timely manner on page 1-26.

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.

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 Requester components to one or more
Subordinate components.

An interconnect component can be used to group together either:

• A set of Requesters so that they appear as a single Requester interface.
• A set of Subordinates so that they appear as a single Subordinate interface.

See also Component, Requester component, Subordinate component.

IO Coherent node
See IO Coherent node on page 1-26.

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-25.

Load The action of a Requester 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 Requester 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.

Requester See Requester on page 1-25.

Requester component
A component that initiates transactions.

It is possible that a single component can act as both a Requester component and as a Subordinate component. For
example, a Direct Memory Access (DMA) component can be a Requester component when it is initiating
transactions to move data, and a Subordinate component when it is being programmed.

See also Component, Interconnect component, Subordinate 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).

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. Glossary-513
ID092622 Non-Confidential
Glossary

Memory Subordinate component

A Memory Subordinate component, or Memory Subordinate, is a Subordinate component with the following
properties:
• A read of a byte from a Memory Subordinate returns the last value written to that byte location.
• A write to a byte location in a Memory Subordinate 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, Requester component, Peripheral Subordinate component.

Message See Message on page 1-24.

Observer A processor or other Requester 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 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.
— Canceled, 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.

Peer to Peer Communication between the same type of nodes. For example, from one RN to another RN.

See also Downstream, Upstream.

Peripheral Subordinate component

A Peripheral Subordinate component is also described as a Peripheral Subordinate. This specification recommends
that a Peripheral Subordinate 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 Subordinate 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 Subordinate component, Subordinate 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-24.

Phit See Phit on page 1-24.

PoC See PoC on page 1-24.

PoS See PoS on page 1-24.

PoP See PoP on page 1-24.

Glossary-514 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622
 Glossary

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-25.

Requester See Requester on page 1-25.

RN See RN on page 1-25.

Subordinate See Subordinate on page 1-25.

Subordinate component
A component that receives transactions and responds to them.

It is possible that a single component can act as both a Subordinate component and as a Requester component. For
example, a Direct Memory Access (DMA) component can be a Subordinate component when it is being
programmed and a Requester component when it is initiating transactions to move data.

See also Requester component, Memory Subordinate component, Peripheral Subordinate component.

SN See SN on page 1-25.

Snooped cache A hardware-coherent cache that receives Snoop transactions.

Snoop filter A snoop filter is able to track the cache lines that might be allocated within a Requester.

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.

Stash The action of placing data in a cache closer to the agent that is expected to be the next user of the data.

Store The action of a Requester 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 Requester 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-24.

ARM IHI 0050E.c Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. Glossary-515
ID092622 Non-Confidential
Glossary

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.

Upstream A transaction operates between a Requester component and one or more Subordinate 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 Requester component, and includes the originating Requester
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, Requester component, Peer to Peer, Subordinate 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-26.

Glossary-516 Copyright © 2014, 2017-2022 Arm Limited or its affiliates. All rights reserved. ARM IHI 0050E.c
Non-Confidential ID092622