AMBA AXI 协议规范

IHI0022K_amba_axi_protocol_spec.pdf

AHB 协议规范

引言

本前言描述了本规范中使用的内容组织和文档约定。

目标受众

该规范是为希望熟悉AMBA协议的硬件和软件工程师编写的，旨在设计与AXI协议兼容的系统和模块

使用本规范

本规范中的信息分为几个部分，如本节所述：

Part A 规范

• A第1章 介绍 ：介绍了本规格中使用的AXI协议架构和术语。
• A第2章 信号列表 ：介绍了本规格中使用的AXI协议架构和术语。
• A第3章 传输 ：提供有关AXI协议的基本操作的信息，例如读写事务、通道信号要求以及通道之间的关系。
• A第4章 事务 ：包含有关AXI协议事务的信息，例如事务请求、事务响应、以及读写数据。
• A第5章 请求属性 ：描述内存属性、内存类型、内存保护和多个区域接口。
• A第6章 事务ID和顺序 ：描述事务ID信号、请求顺序、写数据和响应顺序 以及读数据顺序。
• A第7章 原子访问 ：包含关于原子访问、单一和多副本原子性及独占访问的信息。
• A第8章 请求操作码 ：提供有关操作码字段的信息，该字段描述请求的功能并指示如何由从机处理。
• A第9章 缓存 ：描述了AXI协议中的缓存，包括I/O一致性、缓存可共享行以及使用特定事务管理缓存分配。
• A第10章 缓存维护 ：提供有关使用缓存维护操作来控制缓存内容的信息，以确保数据的可见性。
• A第11章 额外请求限定 ：描述AXI协议中的额外请求限定符，例如非安全访问ID(NSAID)基于Page的硬件属性(PBHA)和子系统ID。
• A第12章 其他写事务 ：包含有关AXI协议中其他写事务的信息，例如WriteDeferrable和WriteZero。
• A第13章 系统监控、调试和用户扩展 ：描述了AXI协议的系统调试、跟踪和监控功能，例如内存系统资源分区和监控（MPAM）、内存标记扩展（MTE）以及用户回环和用户定义信号。
• A第14章 未转换事务 ：描述了AXI如何支持在系统内存管理单元（SMMU）上游组件中使用虚拟地址和转换缓存提示
• A第15章 分布式虚拟内存消息 ：描述AXI如何支持分布式系统MMU使用分布式虚拟内存DVM消息来维护虚拟内存系统中的所有MMU。
• A第16章 唤醒信号 ：描述可用于接口时钟或电源控制的唤醒信号。
• A第17章 接口和数据保护 ：解释如何使用中毒信号和奇偶校验信号来保护数据或接口。

Part B 附录

• 第1章 接口类 ：对所有AMBA 5 AXI接口类的描述，包括信号和属性表。
• 第2章 id约束清单 ：AXI协议中ID约束的总结。
• 第3章 版本 ：本次规格与上一版本之间变化的详细信息。

Part C 术语表

• C第1章 术语表

约定

本节描述了本规格使用的约定：

• 排版
• 时序图
• 信号
• 数字

排版

排版惯例是：

• italic(斜体)：突出重要笔记，介绍特殊术语，并指示内部交叉引用和引用。
• bold(粗体)：表示信号名称，并用于描述性列表中的术语(如果适用)。
• monospace(等宽)：该字体用于汇编程序语法描述、伪代码和源代码示例。
  同时用于主要文本中的指令助记符，以及对出现在汇编程序语法描述、伪代码和源代码示例中的其他项目的引用。
• SMALL CAPITALS(小写大写字母)：用于几个具有特定技术含义的术语。

时序图

在时序图中使用的组件在 图 1 中进行了说明。当变化发生时，会有明确的标签。请不要假设图中没有明确的时序信息

图 1

时序图有时将单比特信号同时显示为高和低，它们看起来与 图 1 显示的总线变化类似。 如果时序图以这种方式显示单比特信号，则其值不会影响附带的描述。

信号

下面是关于信号方面的约定：

• 信号电平：
  断言信号的水平取决于信号是高有效还是低有效，断言意味着
  • HIGH：表示高电平有效。
  • LOW：表示低电平有效。
• 小写n：出现在信号名的开始或结束都表示低电平有效。
• 小写x：信号名称的第二个字母表示读取和写入的统称。例如AxCACHE既指ARCACHE信号也指AWCACHE信号。

数字

数字通常以十进制书写。二进制数字以0b开头，十六进制数字以0x开头。 在这两种情况下，前缀和相关的值都以monospace字体书写。例如0xFFFF0000。 为了提高可读性，较长的数字可以在每四个字符之间加下划线分隔。 例如0xFFFF_0000_0000_0000，在解释数字的值时忽略任何下划线。

伪代码描述

本规范使用一种伪代码形式来提供对指定功能的精确描述。 该伪代码以等宽字体书写。伪代码语言在Arm®架构参考手册中描述，适用于A型架构。

额外阅读

本节列出了Arm和第三方的出版物。

查看Arm开发者网站http://developer.arm.com 以获取Arm文档的访问权限。

[1] AMBA® AXI and ACE Protocol Specification. (ARM IHI 0022 H.c).
[2] AMBA® AXI Protocol Specification. (ARM IHI 0022 J).
[3] Arm® Architecture Reference Manual for A-profile architecture. (ARM DDI 0487).
[4] Arm® Realm Management Extension (RME) System Architecture. (ARM DEN 0129).
[5] AMBA® 5 CHI Architecture Specification. (ARM IHI 0050).
[6] Arm® Architecture Reference Manual Supplement, Memory System Resource Partitioning and Monitoring (MPAM), for A-profile architecture. (ARM DDI 0598).
[7] Arm® System Memory Management Unit Architecture Specification, SMMU architecture version 3. (ARM IHI0070)

反馈

• 请通过填写 https://developer.arm.com/feedback/survey 上的表单，提交关于Arm产品文档的反馈意见。
• 有关Arm产品、架构和规格的技术反馈、问题或咨询，请在 https://support.developer.arm.com/my-cases/open-case/ 上提交支持请求。

Part A 规范

A第1章 介绍

本章介绍了AXI协议的架构和本规范中使用的术语。

它包含以下部分：

• 1.1 关于AXI协议
• 1.2 AXI架构
• 1.3 术语

A1.1 关于AXI协议

AXI协议支持高性能、高频率的系统设计，用于主机与从机之间的通信。

AXI协议的特点包括：

• 适用于高带宽和低延迟的设计。
• 无需使用复杂的桥接器，提供高频率操作。
• 该协议满足广泛组件的接口要求。
• 适用于具有高首次访问延迟的内存控制器。
• 提供互联架构实施的灵活性。
• 向后兼容AHB和APB接口。

AXI协议的关键特性包括：

• 独立的地址/控制和数据阶段。
• 支持使用字节strobe的非对齐数据传输。
• 仅发出起始地址的基于突发的事务。
• 分开的写和读数据通道，可以提供低成本的直接内存访问（DMA）。
• 支持发出多个未完成的地址。
• 支持无序事务完成。
• 允许轻松添加寄存器阶段以提供时序闭合。

有关本规范的前期版本，请参见 ^[1] 和 ^[2] 。

A1.2 AXI架构

AXI协议是基于事务的，定义了五个独立的通道：

• 写请求，其信号名称以AW开头。
• 写数据，其信号名称以W开头。
• 写响应，其信号名称以B开头。
• 读请求，其信号名称以AR开头。
• 读数据，其信号名称以R开头。

请求通道携带控制信息，描述要传输数据的性质。这个称为请求。

数据在主机和从机之间使用以下方式传输：

• 写数据通道将数据从主机传输到从机。在写事务中，从机使用写响应通道向主机发出表示完成传输的信号。
• 读数据通道将数据从从机传输到主机。

AXI协议：

• 允许在实际数据传输之前发出地址信息。
• 支持多个未决事务。
• 支持事务的乱序完成。

图 A1.1 展示了写事务如何使用写请求、写数据和写响应通道。

图 A1.1

图 A1.2 展示了读取事务如何使用读取请求和读取数据通道。

图 A1.2

A1.2.1 通道定义

每个独立的五个通道由一组信息信号以及VALID和READY信号组成， 提供双向握手机制。信息源使用VALID信号来表示通道上何时有有效的地址、数据或控制信息可用。 目的地使用READY信号来表示何时可以接受这些信息。 读数据通道和写数据通道还包括LAST信号，以指示在事务中最后一个数据项的传输。

A1.2.1.1 读写请求通道

存在单独的写请求和读请求通道。适当的请求通道携带一个事务所需的所有地址和控制信息。

A1.2.1.2 写数据通道

写数据通道将写数据从主机传输到从机，包括：

• 数据信号WDATA，可以为8、16、32、64、128、256、512或1024位宽。宽度使用DATA_WIDTH属性表示。
• 每8个数据位都有一个字节通道时钟信号，指示有效的数据字节。

写数据通道信息始终被视为缓存，这样主机可以在没有从机确认先前写操作的情况下执行写事务。

A1.2.1.3 写响应通道

从机使用写响应通道来响应写事务。 所有写事务都需要在写响应通道上进行完成信号传输。 如 图 A1.1所示，只有在完整事务中才会发出完成信号，而不是在事务中的每个数据传输中发出。

A1.2.1.4 读数据通道

读取数据通道携带从从机到主机的读取数据和读取响应信息，包括：

• 数据信号RDATA，其宽度可以是8、16、32、64、128、256、512或1024位。宽度通过DATA_WIDTH属性表示。
• 表示读取事务完成状态的读取响应信号。

A1.2.2 接口与互联

一个典型的系统由多个主机和从机组成，这些设备通过某种形式的连接相互连接，如 图 A1.3 所示

图 A1.3

AXI协议为以下接口之间提供了单一的接口定义：

• 主机与互连之间
• 从机与互连之间
• 主机与从机之间

此接口定义支持许多不同的互连实现。

设备之间的互连相当于另一个具有对称的主机和从机端口的设备，实际的主机和从机通过这一互联可以连接在一起。

A1.2.2.1 典型系统拓扑

大多数系统使用三种互连拓扑之一：

• 共享请求和数据通道。
• 共享请求通道和多个数据通道。
• 多层次，具有多个请求和数据通道。

在大多数系统中，请求通道的带宽需求显著低于数据通道的带宽需求。 这种系统可以通过使用一个共享请求通道和多个数据通道来实现系统性能和互连复杂性之间的良好平衡，从而启用并行数据传输。

A1.2.3 寄存器切片

每个AXI通道仅以单一方向传输信息，并且架构不要求通道之间有任何固定关系。 这些特性意味着可以在任意通道的几乎任何位置插入寄存器切片，代价是增加一个周期的延迟。 这些特性使以下情况成为可能：

• 在延迟周期和最大操作频率之间进行权衡。
• 处理器与高性能内存之间的直接快速连接，同时使用简单的寄存器切片来隔离到性能要求较低外设的较长路径。

A1.3 术语

本节总结了本规范中使用的术语，这些术语在 C第1章 术语表 中或其他地方有定义。 在适当的情况下，本节中列出的术语链接到相应的术语表定义。

A1.3.1 AXI组件和拓扑

以下术语描述了AXI组件：

• 组件
• 主机组件
• 从机组件 ，包括内存从机组件和外设从机组件
• 互连组件

对于特定的AXI事务，上游 和 下游 指的是AXI拓扑中AXI组件的相对位置。

A1.3.2 AXI事务与传输

AXI传输是在AXI通道上一个周期内的通信。

AXI事务是AXI主机与AXI从机进行通信所需的传输集合。

例如，读事务由请求传输和一个或多个读数据传输组成。

A1.3.3 缓存与缓存操作

本规范没有定义任何缓存参考书中定义的标准缓存术语。

然而，缓存 和 缓存行 的词汇条目澄清了这些术语在本文档中的使用方式。

A1.3.4 时间描述

AXI规范使用了 及时 的解释。

A第2章 信号列表

本章列出了本规范中描述的所有信号。 有些通道和信号是可选的，因此并不包含在每个接口中。 每个信号名称包含一个超链接，指向定义该信号的章节。 奇偶校验信号不包含在本章中，但在 A17.2.3 校验检查信号 中列出。

信号根据通道和类别分组，如以下各节所述。

• A2.1 写通道 。
• A2.2 读通道 。
• A2.3 侦听通道 。
• A2.4 接口信号 。

A2.1 写通道

写通道用于传输请求、数据和响应以进行写事务以及一些其他无数据事务。

A2.1.1 写请求通道

写请求通道传输使用写通道的事务所需的所有地址和控制信息。该通道上的信号前缀为AW。

表 A2.1 写请求通道信号

A2.1.2 写数据通道

写数据通道携带来自主机到从机的写数据和控制信息。该通道上的信号以W为前缀。

表 A2.2 写数据通道信号

A写响应通道

写响应通道用于传递从从机到主机的响应，适用于使用写数据通道的事务。该通道上的信号以字母B为前缀。

表 A2.3 写响应通道信号

A2.2 读通道

读通道用于传输读取事务、缓存维护操作和DVM完成消息的请求、数据和响应。

A2.2.1 读请求通道

读请求通道携带所有使用读取通道的事务所需的地址和控制信息。该通道上的信号以前缀AR开头。

表 A2.4 读请求信号

A2.2.2 读数据通道

读数据通道传输来自从机设备到管理器的读数据和响应。该通道上的信号以R为前缀。

A2.3 侦听通道

在本规范中，旁路通道仅用于传输DVM消息。

A2.3.1 侦听请求通道

侦听请求通道携带DVM消息请求的地址和控制信息。该通道上的信号具有前缀AC。

表 A2.6 侦听请求通道

A2.3.2 侦听响应通道

侦听响应通道承载对DVM消息的响应。该通道上的信号具有前缀CR.

表 A2.7 侦听响应通道信号

A2.4 接口信号

接口级信号是非信道信号。每个接口最多可以有一组信号。

A2.4.1 时钟和复位信号

接口上的所有信号与全局时钟同步，并通过全局复位信号进行复位。

表 A2.8 时钟和复位信号

A2.4.2 唤醒信号

表 A2.9 唤醒信号

A2.4.3 Qos接收信号

QoS接受信号可以被从机接口用于指示它接受的请求的最小QoS值。

表 A2.10 Qos接收信号

A2.4.4 连贯性连接信号

连贯性连接信号由主机使用，以控制其是否接收AC通道上的DVM消息。

表 A2.11 连贯性连接信号

A2.4.5 接口控制信号

接口控制信号是主机接口的静态输入，可用于配置接口行为。

表 A2.12 接口控制信号

A第3章 传输

本章描述了AXI中使用的通道传输 它包含以下部分：

• A3.1 时钟和复位
• A3.2 通道握手
• A3.3 读写通道
• A3.4 通道关系
• A3.5 通道握手依赖
• A3.6 侦听通道

A3.1 时钟和复位

本节描述了实现AXI全局时钟和复位信号ACLK和ARESETn的要求。

A3.1.1 时钟

每个AXI接口都有一个单一的时钟信号ACLK。 所有输入信号在ACLK的上升沿被采样。 所有输出信号的变化只能在ACLK的上升沿之后发生。

在主机和从机之间，输入和输出信号之间必须没有组合路径。

A3.1.2 复位

AXI协议使用一个单一的低电平有效复位信号ARESETn。 复位信号可以异步地被断言，但去断言只能在ACLK上升沿同步进行。 在复位期间，以下接口要求适用：

• 主机必须将AWVALID、WVALID和ARVALID驱动为低。
• 从机必须将BVALID和RVALID驱动为低。
• 所有其他信号可以被驱动为任何值。

复位后，主机被允许开始将AWVALID、WVALID和ARVALID 驱动为高的最早时刻是在ARESETn高后的ACLK上升沿。

图 A3.1 显示了复位后AWVALID、WVALID和ARVALID 可以被驱动为高的最早时间点 b。

图 A3.1

A3.2 通道握手

所有AXI通道使用相同的VALID/READY握手过程来传输地址、数据和控制信息。 这种双向流控制机制意味着主机和从机都可以控制信息在主机和从机之间移动的速率。 源生成VALID信号以指示地址、数据或控制信息可用。 目标生成READY信号以指示它可以接受信息。 仅当VALID和READY信号均为高电平时，传输才会发生。

在主机和从机之间，输入信号和输出信号之间必须没有组合路径。 图 A3.2 到 图 A3.4 展示了握手过程的示例。

源可以在READY被断言之前就断言VALID。

源在边缘1之后呈现信息，并如 图 A3.2 所示声明VALID信号。 目标在边缘2之后声明READY信号。 源必须保持其信息稳定，直到在边缘3时发生传输，此时该声明被识别。

图 A3.2

源不能在断言VALID之前去等待READY被断言。

Note：
也就是说源不能依靠等待READY被断言之后才断言VALID。

当VALID被断言时，它必须保持断言状态直到握手发生， 握手发生在VALID和READY同时被断言的上升时钟边缘。

在 图 A3.3 中，目标在边缘1之后断言READY，在地址、数据或控制信息有效之前。 这一确认表明它可以接受信息。源在边缘2之后提供信息并断言VALID，然后在边缘3时被识别时进行传输。 在这种情况下，传输发生在一个周期内。

图 A3.3

允许目的在相应的READY断言之前等待VALID被断言。

如果READY被断言，它被允许VALID断言之前解除断言READY。 在 图 A3.4 中，源和目的地恰好都表示它们在边缘1之后可以传送地址、数据或控制信息。 在这种情况下，传输发生在VALID和READY同时被断言的上升时钟边缘。这意味着传输发生在边缘2。

图 A3.4

个别AXI通道握手机制在 A3.4 通道关系 中描述。

Note：

• VALID不能等待READY，
  
• READY可以等待VALID。

A3.3 读写通道

这一部分描述了AXI写通道和读通道。通道如下：

• A3.3.1 写请求通道（AW）
• A3.3.2 写数据通道(W)
• A3.3.3 写响应通道（B）
• A3.3.4 读请求通道（AR）
• A3.3.5 读数据通道（R）

对于使用 A15.3 dvm 消息 的接口，额外有两个通道：

• A3.6.1 侦听请求通道（AC）
• A3.6.2 侦听响应通道（CR）

A3.3.1 写请求通道（AW）

写请求通道的控制信号如 表 A3.1 所示。

表 A3.1 写请求通道控制信号

当主机驱动有效请求时，可以断言AWVALID信号。 当被断言时，AWVALID必须保持断言状态，直到从机在上升时钟边缘断言AWREADY。

AWREADY的默认状态可以是高或低。 建议将AWREADY的默认状态设置为高。 当AWREADY为高时，从机必须能够接受呈现给它的任何有效请求。

不建议将AWREADY默认设置为低，因为这会强制传输至少需要两个周期， 一个周期用于断言AWVALID，另一个周期用于断言AWREADY。

A3.3.2 写数据通道（W）

写数据通道的控制信号如 表 A3.2 所示。

表 A3.2 写数据通道控制信号

在写事务期间，主机只能在其驱动有效写数据时断言WVALID信号。 当断言时，WVALID必须保持断言状态， 直到从机断言WREADY之后的上升时钟边缘。

WREADY的默认状态可以是高，但前提是从机始终能够在单个周期内接受写数据。

主机在驱动事务中的最后写传输时必须断言WLAST信号。

建议对于非活跃的字节通道，将WDATA驱动为零。

未使用WLAST的从机可以省略其接口中的输入。 属性WLAST_Present用于确定WLAST信号是否存在。

表 A3.3 WLAST_Present 属性

A3.3.3 写响应通道（B）

写响应通道的控制信号如 表 A3.4 所示。

表 A3.4 写响应通道控制信号

从机只能在驱动有效写响应时断言BVALID信号。 当断言时，BVALID必须保持断言状态， 直到主机断言BREADY后的上升时钟边缘。

BREADYBREADY的默认状态可以是高电平，但是前提是主机必须始终能在一个周期内接受写响应。

A3.3.4 读请求通道（AR）

读取请求通道的控制信号如 表 A3.5 所示。

表 A3.5 读请求控制信号

主机只能在发出有效读请求时断言ARVALID信号。 一旦断言，ARVALID必须保持断言状态，直到从机在上升时钟边缘断言ARREADY信号。

ARREADY的默认状态可以是高或低。 建议将ARREADY的默认状态设置为高。 如果ARREADY为高，则从机必须能够接受任何呈现给它的有效读请求。

不建议将ARREADY设为低，因为这会使传输至少需要两个周期，一个用于将ARVALID置为有效， 另一个用于将ARREADY置为有效

A2.3.5 读数据通道（R）

读取数据通道的控制信号如 表 A3.6 所示

表 A3.6 读数据通道控制信号

从机仅在驱动读取数据通道上的有效信号时才能断言RVALID信号。 当RVALID被断言时，它必须保持断言状态，直到主机断言ARREADY后的上升时钟边缘。 即使从机只有一个读取数据源，它也必须仅在响应请求时断言RVALID信号。

主机使用信号RREADY指示它接受数据。 RREADY的默认状态可以是高，但只有在主机能够在开始读取事务且立即接受读取数据时。

每当从机驱动事务中的最终读取传输时，必须断言RLAST信号。 建议对不活动的字节通道将RDATA驱动为零。

不使用RLAST的主机可以从其接口中省略该输入。属性RLAST_Present用于确定RLAST信号是否存在。

表 A3.7 RLAST_Present 属性

A3.4 通道关系

AXI协议要求保持以下关系：

• 写响应必须始终跟随写事务中的最后一次写传输。
• 读数据和读响应必须始终跟随读请求。
• 通道握手必须符合 A3.5 通道握手依赖关系 定义。
• 当主机发出写请求时，必须能够提供该事务的所有写数据，而不依赖于该主机的其他事务。
• 当主机已发出写请求并提供所有写数据时，必须能够接受该事务的所有响应，而不依赖于该主机的其他事务。
• 当主机已发出读请求时，必须能够接受该事务的所有读数据，而不依赖于该主机的其他事务。

Note：
主机可以依赖于使用相同ID的事务按顺序返回读数据，因此主机只需要足够的存储空间来存储具有不同ID的事务的读数据。

• 主机被允许在发出另一个事务请求之前等待一个事务完成。
• 从机被允许在接受或发出另一个事务的传输之前等待一个事务完成。
• 从机不能因带有前导写数据的事务而阻止接受无数据的写请求。

该协议未定义通道之间的其他关系。

缺乏关系意味着写数据可以在写请求之前出现在接口处。 如果写请求通道包含比写数据通道更多的寄存器级别，就会发生这种情况。 同样，写数据可能在与写请求相同的周期内出现。

当互连需要确定目标地址空间或从机空间时，必须重新对齐请求和写数据。 此重新对齐是为了确保写数据仅向被标记为有效的从机发送。

A3.5 通道握手依赖关系

通道之间存在写、读和侦听事务的依赖关系。这些在下面的章节中进行了描述，并包含依赖图，其中：

• 单箭头指向可以在箭头起始信号之前或之后被断言的信号。
• 双箭头指向必须在箭头起始信号断言之后才能被断言的信号。

A3.5.1 写事务依赖

对于写通道上的事务， 图 A3.5 显示了握手信号的依赖关系。规则如下：

• A3.5.1.1 主机在断言AWVALID或WVALID 之前不得等待从机断言AWREADY或WREADY。这适用于事务中的每个写数据传输。
• A3.5.1.2 从机可以在断言AWREADY之前等待AWVALID或WVALID， 或两者。
• A3.5.1.3 从机可以在AWVALID或WVALID， 或两者被断言之前断言AWREADY。
• A3.5.1.4 从机可以在断言WREADY之前等待AWVALID或WVALID， 或两者。
• A3.5.1.5 从机可以在AWVALID或WVALID， 或两者被断言之前断言WREADY。
• A3.5.1.6 从机必须在断言BVALID之前等待 AWVALID、AWREADY、WVALID和WREADY被断言。
• A3.5.1.7 从机还必须在断言BVALID之前等待WLAST被断言。 这是因为写响应BRESP必须在写事务的最后一次数据传输之后发送信号。
• A3.5.1.8 从机不得在断言BVALID之前等待主机断言BREADY。
• A3.5.1.9 主机可以在断言BREADY之前等待BVALID。
• A3.5.1.10 主机可以在BVALID被断言之前断言BREADY。

图 A3.5

A3.5.2 读事务依赖

对于读取通道上的事务，图 A3.6 显示了握手信号的依赖关系。规则如下：

• A3.5.2.1 主机在断言ARVALID之前不得等待从机断言ARREADY。
• A3.5.2.2 从机可以在断言ARREADY之前等待ARVALID被断言。
• A3.5.2.3 从机可以在ARVALID被断言之前断言ARREADY。
• A3.5.2.4 从机必须等到ARVALID和ARREADY都被断言后， 才能断言RVALID以指示有效数据可用。
• A3.5.2.5 从机不得等待主机断言RREADY后再断言RVALID。
• A3.5.2.6 主机可以在断言RREADY之前等待RVALID被断言。
• A3.5.2.7 主机可以在RVALID被断言之前断言RREADY。

图 A3.6

总结：

• 断言VALID不等断言READY：
  A3.5.1.1 写请求和写
  A3.5.1.8 写响应
  A3.5.2.1 读请求
  A3.2.2.5 读
  A3.6.3.1 侦听请求
  A3.6.3.5 侦听响应
• 断言READY可等断言VALID：
  A3.5.1.2 写请求和写
  A3.5.1.9 写响应
  A3.5.1.4 写请求和写
  A3.5.2.2 读请求
  A3.5.2.6 读
  A3.6.3.2 侦听请求
  A3.6.3.6 侦听响应
• 断言VALID和断言READY没有先后关系：
  A3.5.1.3 写请求和写
  A3.5.1.5 写请求和写
  A3.5.1.10 写响应
  A3.5.2.3 读请求
  A3.5.2.7 读
  A3.6.3.3 侦听请求
  A3.6.3.7 侦听响应
• 断言BVALID必须在写传输完成之后：
  A3.5.1.6 写响应在写请求和写之前
  A3.5.1.7 写响应在最后一笔写传输之前
  
• 断言RVALID必须在ARVALID和ARREADY断言之后：
  A3.5.2.4 读有效在读请求有效和就绪之前
• 断言CRVALID必须在ACVALID和ACREADY断言之后：
  A3.6.3.4 侦听响应有效在侦听请求有效和就绪之前

A3.6 侦听通道

DVM消息在互连和管理组件之间通过侦听通道传输。 当支持DVM消息时，会有一个侦听请求通道（AC）和一个侦听响应通道（CR）。

A3.6.1 侦听请求通道（AC）

侦听请求通道的控制信号如 表 A3.8 所示。

表 A3.8 侦听请求通道控制

从机只能在驱动有效地址和控制信息时断言ACVALID信号。 当ACVALID被断言时，它必须保持断言状态，直到主机断言ACREADY信号的上升时钟边缘。

ACREADY的默认状态可以是高或低。 建议将ACREADY的默认状态设置为高。 如果ACREADY为高，则主机必须能够接受任何呈现给它的有效请求。

不推荐将ACREADY的默认状态设置为低，因为这会迫使传输至少需要两个时钟周期， 一个用于断言ACVALID，另一个用于断言ACREADY。

A3.6.2 侦听响应信号（CR）

侦听响应通道的控制信号如 表 A3.9 所示。

表 A3.9 侦听响应信号

主机只有在它在侦听响应通道上驱动有效信号时才能断言CRVALIDCRVALID信号。 当CRVALID被断言时，必须保持断言状态，直到从机断言CRREADY后的时钟上升沿。

从机使用CRREADY信号表示它接受响应。 CRREADY的默认状态可以为高，但前提是从机能够在开始侦听事务时立即接受侦听响应。

A3.6.3 侦听事务依赖

对于侦听通道上的事务，图 A3.7 显示了握手信号依赖关系。规则如下：

• A3.6.3.1 从机在断言ACVALID之前不得等待主机断言ACREADY。
• A3.6.3.2 主机可以在断言ACREADY之前等待ACVALID被断言。
• A3.6.3.3 主机可以在ACVALID被断言之前断言ACREADY。
• A3.6.3.4 主机必须等待ACVALID和ACREADY都被断言后才能断言CRVALID，以表示有效响应可用。
• A3.6.3.5 主机不得等待从机断言CRREADY后再断言CRVALID。
• A3.6.3.6 从机可以在断言CRREADY之前等待CRVALID被断言。
• A3.6.3.7 从机可以在CRVALID被断言之前断言CRREADY。

图 A3.7

A第4章 事务

AXI协议使用事务在主机和从机之间进行通信。 所有事务包括请求和响应。

写和读事务也包括一个或多个数据传输。

本章描述了事务请求、响应和数据传输。它包含以下几个部分

• A4.1 事务请求
• A4.2 读写数据
• A4.3 事务响应

A4.1 事务请求

AXI主机通过向从机发出请求来启动事务。 请求包括事务属性和第一次数据传输的地址。 如果事务包含多个数据传输，从机必须计算后续传输的地址。

事务不得跨越4KB地址边界，这防止了事务跨越两个从机之间的边界。 这也限制了从机必须支持的地址增量数量。

A4.1.1 大小属性

size表示每次数据传输中的最大字节数.

对于读取事务，size表示每次读取数据传输中必须有效的数据字节数.

对于写入事务，size表示允许活动的数据字节通道数，WSTRB 指示在每次传输中哪些字节是有效的。

size不得超过接口的数据宽度，这由DATA_WIDTH属性确定。

如果size小于DATA_WIDTH，则在每次传输中使用字节通道的一个子集。

size通过写请求和读请求通道上的AWSIZE和ARSIZE信号进行传达， 在本规范中，AxSIZE表示AWSIZE和ARSIZE。

表 A4.1 AxSIZE信号

size通过AxSIZE信号进行编码，如 表 A4.2 所示。

如 表 A4.3 所示，属性 SIZE_Present 用于确定 AxSIZE 信号是否存在。

表 A4.3 SIZE_Present 属性

一个只发出全数据宽度请求的主机可以从其接口中省略AxSIZE输出。 相应的从机必须根据数据宽度将其AxSIZE输入连接起来。

A4.1.2 长度属性

Length属性定义了事务中的数据传输次数。

Size x Length是一个事务中可以传输的最大字节数。如果地址未对齐或存在未使能的WSTRB，实际传输的字节数可能低于Size x Length。

主机必须根据Length发出写数据传输的数量。

从机必须根据Length发出读数据传输的数量。

Length通过写请求和读请求通道上的AWLEN和ARLEN信号进行通信。

在本规范中AxLEN表示AWLEN和ARLEN，如 表 A4.4 所示。

表 A4.4 AxLEN信号

属性 LEN_Present 用于确定信号是否存在，表 A4.5 显示了 LEN_Present 的合法值。

表 A4.5 LEN_Present属性

一个只发出长度为1请求的主机可以从其接口中省略AxLEN输出。 相应的从机必须将其AxLEN输入连接到0x00。以下规则适用于事务长度：

• 对于wrap突发，长度可以是2、4、8或16。
• 对于固定突发，长度可以达到16。
• 事务不得跨越4KB地址边界。
• 不支持事务的提前终止。

没有组件可以提前终止事务。 然而，为了减少写事务中的数据传输次数，主机可以通过取消所有WSTRB的有效状态来禁用进一步的写入。 在这种情况下，主机必须完成事务中的其余传输。 在读取事务中，主机可以丢弃读取数据，但必须完成事务中的所有传输。

A4.1.3 事务的最大传输byte

一个事务的最大字节数为4KB，事务不允许跨越4KB边界。 然而，许多主机生成的事务可能始终小于此值。

一个从机或互连可能会从这些信息中受益。例如，一个从机可借此优化一些解码逻辑。 一个在小于4KB粒度下进行条带化的互连如果知道事务不会跨越条带边界，可能能够避免突发拆分。

属性Max_Transaction_Bytes定义了一个事务的最大字节数，如 表 A4.6 所示。

表 A4.6 Max_Transaction_Bytes 属性

在连接主机和从机时，表 A4.7 指示了兼容的 Max_Transaction_Bytes 组合。

表 A4.7 Max_Transaction_Bytes 互联

A4.1.4 突发属性

Burst属性描述了在事务中传输之间地址的递增方式。有三种不同的Burst类型：

• 固定（FIXED）
  此Burst类型用于对同一位置的重复访问，例如在加载或清空FIFO时。

  • 在Burst中的每次传输的地址都相同。
  • 有效的字节通道对于所有传输都是恒定的。然而，在这些字节通道内，实际的WSTRB有效的字节在每次传输中可能不同。
  • Burst的长度可以达到16次传输。
  • 固定Burst类型仅可与WriteNoSnoop或ReadNoSnoop操作码一起使用。 有关更多信息，请参见 A第8章 请求操作码 。

• 增量（INCR）
  对于此Burst类型，每次传输的地址是前一次传输地址的递增。 递增值取决于事务的大小。例如，对于对齐的起始地址，事务中每次传输的地址是前一个地址加4。此Burst类型用于对正常顺序内存的访问。

• 回环（WRAP）
  

  • 此Burst类型类似于增量，除了在达到上限地址时地址会回环到较低的地址。适用以下限制：
    • 起始地址必须与每次传输的大小对齐。
    • Burst的长度必须为2、4、8或16次传输。
      
  • 回环事务的行为是：
    • 事务访问的最低地址是与要传输的数据总大小对齐的起始地址，即Size x Length。此地址被定义为回环边界。
    • 每次传输后，地址的递增方式与增量Burst相同。然而，如果这个递增的地址是((回环边界) + (Size x Length))，则地址会回环到回环边界。
    • 事务中的第一次传输可以使用高于回环边界的地址，前提是遵守适用于回环事务的限制。 当第一次地址高于回环边界时，地址会回环。此Burst类型用于缓存行访问。

通过AWBURST和ARBURST信号分别在写请求和读请求通道上传达Burst。 在本规范中，AxBURST指示AWBURST和ARBURST。

表 A4.8 AxBURST信号

Burst在AxBURST信号上进行编码如 表 A4.9 所示。

表 A4.9 AxBURST编码

属性BURST_Present用于确定AxBURST信号是否存在。 只发出类型为INCR的Burst请求的主机可以从其接口中省略AxBURST输出。 相应的从机必须将其AxBURST输入连接到0b01。

表 A4.10 BURST_Present属性

一种突发类型的固定不常用属性，并在 表 A4.11 中定义了属性Fixed_Burst_Disable以指示组件是否支持它。

表 A4.11 Fixed_Burst_Disable属性

根据 Fixed_Burst_Disable 属性的值，表 A4.12 显示了主机和从机之间的兼容性。

表 A4.12 Fixed_Burst_Disable 兼容性

A4.1.5 传输地址

本节提供了在事务中确定传输的地址和字节通道的方法。事务的起始地址通过AxADDR信号指示。

表 A4.13 AxADDR信号

属性ADDR_WIDTH用于定义地址宽度。

表 A4.14 ADDR_WIDTH属性

该协议支持具有不同物理地址空间大小的组件之间的通信。

具有不同物理地址空间大小的组件必须按如下方式进行通信

• 物理地址空间较小的组件必须位于较大物理地址空间中的对齐窗口内。 通常，窗口位于较大物理地址空间的底部。 但是，物理地址空间较小的组件可以位于较大物理地址空间中的偏移窗口内。
• 外部事务必须将所需的额外高位添加到事务地址中。
• 内部事务必须做以下检查：
  • 在地址窗口内的事务去掉高位地址位并被传递。
  • 不具有所需高位地址位的事务被抑制。

Note：
高位地址位通常携带了用于选择存储器或I/O设备特定区域的信息。
在计算机系统中，地址被分为高位和低位，高位地址线用于选择更大的地址范围或特定的存储区域，而低位地址线用于具体单元或设备的寻址.

提供所需功能是互联的责任

A4.1.6 事务方程

该文中列出的方程用于确定事务中每次传输的地址和活动数据字节通道。方程使用以下变量：

• Start_Addr：由主机发出的起始地址。
• Data_Bytes：数据通道的宽度（以字节为单位）（DATA_WIDTH/8）。
• Aligned_Addr：起始地址的对齐地址。
• Address_N：事务中传输N的地址。事务中第一次传输N的值为1。
• Wrap_Boundary：wrap突发事务中的回环边界地址。
• Lower_Byte_Lane：传输中最低寻址字节的字节通道。
• Upper_Byte_Lane：传输中最高寻址字节的字节通道。
• INT(x)：对x向下取整的整数值。

这些方程确定突发内传输的地址：
Start_Addr = AxADDR
Aligned_Addr = INT(Start_Addr / Size)* Size

该方程确定突发中第一次传输的地址：
Address_1 = Start_Addr

对于INCR突发和地址未回环的WRAP突发，该方程确定突发中首次传输后的任何传输地址：
Address_N = Aligned_Addr + (N - 1)* Size

对于WRAP突发，Wrap_Boundary变量定义回环边界：
Wrap_Boundary = INT(Start_Addr / (Size x Length))* Size x Length

对于WRAP突发，如果Address_N = Wrap_Boundary + Size x Length，则：

• 对于当前传输使用该方程：
  Address_N = Wrap_Boundary
• 对于任何后续传输使用该方程：
  Address_N = Start_Addr + ((N - 1)* Size)- (Size x Length)

这些方程确定突发中第一次传输使用的字节通道：
Lower_Byte_Lane = Start_Addr - (INT(Start_Addr/Data_Bytes)* Data_Bytes)
Upper_Byte_Lane = Aligned_Addr + (Size-1)- (INT(Start_Addr/Data_Bytes)* Data_Bytes)

这些方程确定突发中第一次传输之后所有传输使用的字节通道：
Lower_Byte_Lane = Address_N - (INT(Address_N / Data_Bytes)* Data_Bytes)
Upper_Byte_Lane = Lower_Byte_Lane + Size - 1

数据传输在：
DATA((8 x Upper_Byte_Lane)+ 7: (8 x Lower_Byte_Lane))

事务容器描述在该事务中可以访问的所有字节，如果地址对齐且触发信号得到确认：
Container_Size = Size x Length

对于INCR突发：
Container_Lower = Aligned_Addr
Container_Upper = Aligned_Addr + Container_Size

对于WRAP突发：
Container_Lower = Wrap_Boundary
Container_Upper = Wrap_Boundary + Container_Size

A4.1.7 传输描述的伪代码

// DataTransfer()
// IsWrite is TRUE for a write, and FALSE for a read
DataTransfer(Start_Addr, Size, Length, Data_Bytes, Burst, IsWrite)

	addr = Start_Addr; // Variable for current address
	Aligned_Addr = (INT(addr/Size) x Size);
	aligned = (Aligned_Addr == addr); // Check whether addr aligned to Size
	Container_Size = Size x Length;
	
	if Burst == WRAP then
		Lower_Wrap_Boundary = (INT(addr/Container_Size) x Container_Size);
		// addr must be aligned for a wrapping burst
		Upper_Wrap_Boundary = Lower_Wrap_Boundary + Container_Size;

	for n = 1 to Length
		Lower_Byte_Lane = addr - (INT(addr/Data_Bytes) x Data_Bytes);
		if aligned then
			Upper_Byte_Lane = Lower_Byte_Lane + Size - 1
		else
			Upper_Byte_Lane = Aligned_Addr + Size - 1 - (INT(addr/Data_Bytes) x Data_Bytes);

		// Perform data transfer
		if IsWrite then
			dwrite(addr, Lower_Byte_Lane, Upper_Byte_Lane)
		else
			dread(addr, Lower_Byte_Lane, Upper_Byte_Lane);

		// Increment address if necessary
		if Burst != FIXED then
			if aligned then
				addr = addr + Size;
				if Burst == WRAP then
					if addr >= Upper_Wrap_Boundary then 
						addr = Lower_Wrap_Boundary;
					else
						addr = Aligned_Addr + Size;
						aligned = TRUE; // All transfers after the first are aligned
		return;

A4.1.8 常规事务

事务有许多突发、大小和长度的选项。 然而，一些接口和事务类型可能只使用这些选项的一个子集。 如果一个从机连接到一个仅使用事务选项子集的主机，它可以设计为简化型解码逻辑。

Regular属性被定义为识别符合以下标准的事务：

• 长度为1、2、4、8或16次传输。
• 如果长度大于1，则大小与数据通道宽度相同。
• 突发为INCR或WRAP，而不是FIXED。
  • 对于INCR事务，地址与事务容器对齐。
  • 对于WRAP事务，地址与大小对齐。

Regular_Transactions_Only属性用于定义一个主机是否仅发出常规类型的事务， 以及一个从机是否仅支持常规事务。

表 A4.15 Regular_Transaction_Only属性

常规事务的互操作性规则见 A4.16

表 A4.16 Regular_Transactions_Only互操作性

A4.2 读写数据

本节描述了AXI写入和读取数据通道上不同大小的传输，以及接口如何执行混合字节序和非对齐传输。

A4.2.1 write strobes

WSTRB信号携带写使能信号，指定写数据通道的哪些字节通道包含有效的信息。

表 A4.17 WSTRB信号

每8位写数据通道都对应一位的WSTRB，因此WSTRB[n]对应于WDATA[(8n)+7:(8n)]。
当WVALID为高电平时：

• 要写入的数据字节与WSTRB信号相应的bit被设为高电平。
• 在事务容器内部，可以有任意数量的WSTRB信号bit为高电平。 如果所有WSTRB信号bit都为低电平，则该传输不写入任何数据。
• 在事务容器外部，所有WSTRB信号bit必须为低电平。

当WVALID为低电平时，WSTRB信号可以取任何值， 但建议将其保持在低电平或保持在之前的值上。

建议在WSTRB信号为低电平时，WDATA的字节通道设为零。

属性WSTRB_Present用于指示接口上是否存在WSTRB信号。

表 A4.18 WSTRB_Present属性

一个只在所有WSTRB信号bit都被激活时发出事务的主机可以省略其接口中的WSTRB输出。 相应的从机必须将其WSTRB输入固定为高电平。

A4.2.2 窄传输

当主机生成的传输比其数据通道窄时，地址和控制信息决定了传输使用的字节通道：

• 当突发模式为INCR或WRAP时，事务中的每个数据传输使用不同的字节通道。
• 当突发模式为FIXED时，事务中的每个数据传输使用相同的字节通道。

字节通道使用的两个示例显示在 图 A4.1 和 图 A4.2 中。 阴影单元表示未传输的字节。 在 图 A4.1 中：

• 事务有五个数据传输。
• 起始地址为0。
• 每个传输为8位。
• 传输在32位数据通道上进行。
• 突发类型为INC。

图 A4.1

在 图 A4.2 中

• 该事务有三个数据传输。
• 起始地址是4。
• 每个传输为32位。
• 传输在64位数据通道上。
• 突发类型是INCR。

图 A4.2

A4.2.3 字节不变性

为了在单一内存空间中访问混合字节序的数据结构，AXI协议使用了字节不变的字节序方案。

字节不变的字节序意味着在数据结构中的任何多字节元素：

• 元素使用相同的连续内存字节，与数据的字节序无关。
• 字节序决定了内存中这些字节的顺序，这意味着它决定了内存中的第一个字节是元素的最高有效字节（MSB）还是最低有效字节（LSB）。
• 任何字节传输到一个地址时，会将8位数据通过相同的数据通道线传输到相同的地址位置，无论它所属的较大数据元素的字节序如何。

只有一种传输宽度的组件必须将其字节通道连接到数据通道的适当字节通道。 支持多种传输宽度的组件可能需要更复杂的接口来转换不是自然字节不变的接口。

大多数小端组件可以直接连接到字节不变接口。 仅支持大端传输的组件需要一个转换函数以实现字节不变操作。

图 A4.3 和 图 A4.4 中的示例显示了一个32位数字0x0A0B0C0D， 存储在寄存器和内存中。

在 图 A4.3 中，有一个大端字节不变数据结构的示例，在该结构中：

• 数据的最高有效字节（MSB），即0x0A，存储在寄存器的最高有效字节位置。
• 数据的最高有效字节（MSB），存储在最低地址的内存位置。
• 其他数据字节按重要性递减顺序排列。

图 A4.3

在 图 A4.4 中，有一个小端字节不变数据结构的示例在这个结构中：

• 数据的最低有效位（LSB），即0x0D，存储在寄存器的最低有效位位置。
• 数据的最低有效位（LSM），存储在地址最低的内存位置。
• 其他数据字节按重要性递增的顺序排列。

图 A4.4

图 A4.3 和 图 A4.4 中的示例显示了 字节不变性确保大端和小端结构可以在单一内存空间中共存且不会出现损坏。

图 A4.5 中有一个需要字节不变访问的数据结构示例，在这个示例中标头字段使用小端排序而有效负载使用大端排序。

图 A4.5

在这个示例结构中，Data items是一个两字节的小端元素，这意味着其最低地址是最低有效位。 字节不变量的使用确保了大端对负载的访问不会破坏小端元素。

A4.2.4 不对齐传输

AXI支持非对齐传输。 对于由超过1kB的数据传输组成的任何事务，初始访问的字节可能与自然地址边界不对齐。 例如开始于字节地址0x1002的32位数据包未对齐到自然32位地址边界，

主机可以：

• 使用低位地址线来表示非对齐的起始地址.
• 提供对齐地址并使用字节行strobes来表示非对齐的起始地址。

低位地址线上的信息必须与字节行strobes上的信息一致。

从机不需要基于主机提供的任何对齐信息采取特殊行动。

图 A4.6 显示了32位数据通道上对齐和非对齐32位事务的示例。 图中的每一行表示一次传输并且阴影单元表示未传输的字节。

图 A4.6

在 图 A4.7 中，有一些在64位数据通道上对齐和未对齐的32位事务示例。 图中每一行代表一次传输，阴影单元格表示未传输的字节。

图 A4.7

在 图 A4.8 中有一个在64位数据通道上对齐的32位回环事务的示例。 图中的每一行表示一个传输，阴影的单元格表示未传输的字节。

图 A4.8

A4.3 事务响应

每个AXI事务都包括一个或多个由从机发送的响应传输，以指示事务的结果。

写通道上的事务有一个或多个写响应。

读通道上的事务有一个或多个读响应。

原子事务有写和读响应，请参见 A7.4 原子事务 。

A4.3.1 写响应

写响应通过写响应通道上的BRESP信号进行传输。 写通道上的所有事务都有一个完成响应，它指示事务的结果。 一些事务还有第二个写响应，例如指示持久性。 参见 A10.8.4 B通道上的PCMO响应 。

BRESP和BCOMP信号用于发送写响应。

表 A4.19 BRESP 和 BCOMP信号

BRESP_WIDTH属性在 表 A4.20 中有显示。

表 A4.20 BRESP_WIDTH属性

BRESP是一个可选信号。如果BRESP_WIDTH属性为0，则该信号不存在，并被假定为0b000（OKAY）。

只有在接口使用可以具有两个写响应的特性时，BCOMP才会出现，这些特性包括：

• 持久性的缓存维护，参见 A10.8 持久性CMOs 。
• 内存标签，参见 A13.2 内存标签扩展 。

如果BCOMP存在，则必须在写通道每个事务的响应传输中被断言。

BRESP编码见 表 A4.21 。

表 A4.21 BRESP编码

A4.3.2 读响应

读取响应指示读取是否成功以及该传输中的数据是否有效。

读取响应通过读取数据通道上的RRESP信号传输，在事务中的每次读取数据传输都有一个读取响应。 响应值不要求在事务中的每次读取数据传输中都相同。

需要注意的是所有数据传输都应按长度指示始终完成而不考虑响应。 对于某些响应，该传输中的数据不要求有效。

RRESP信号的定义如表 表 A4.22 所示。

表 A4.22 RRESP信号

RRESP_WIDTH属性在 表 A4.23 中显示。

表 A4.23 RRESP_WIDTH属性

RRESP是一个可选信号。 如果RRESP_WIDTH属性为0，则该信号不存在，并假定为0b000（OKAY）。 RRESP的编码如 表 A4.24 所示。

对于数据不要求有效的响应，主机可能仍会采样RDATA值，因此从机不应依赖响应来隐藏敏感数据。

表 A4.24 RRESP编码

RRESP的值并不限制在每次传输中都相同。 当访问从机出现问题时，通常会使用 DECERR 响应。 且在这种情况下，DECERR 在每次读取数据的传输中都会一致地发出信号。

如果主机可以检查一次读取数据传输以确定是否发生了， DECERR 可能会有效。

Consistent_DECERR 属性用于定义从机在一个事务中是否一致地发出 DECERR 信号，如表 A4.25 所示。

表 A4.25 Consistent_DECERR 属性

从机不使用DECERR响应的可以将Consistent_DECERR属性设置为真。

将Consistent_DECERR设置为真的主机可以检查一次数据传输以确定是否发生了DECERR。

当在AXI和CHI之间桥接时将此属性设置为真可以有用的，因为DECERR会转换为非数据错误。

在连接主机和从机时 表 A4.26 显示了兼容的Consistent_DECERR组合。

表 A4.26 Consistent_DECERR 互操作性

A4.3.3 从机繁忙标志

当提供响应时，从机可以使用繁忙标志来表明其当前的活动水平。 这些信息可以用来控制主机的发出速率或它产生的推测性事务的数量。

繁忙标志对于有共享资源的组件是有用的， 比如内存控制器或系统缓存。例如，繁忙指示可以表示：

• 共享队列的繁忙状态。
• 读取或写入请求队列的繁忙状态，取决于事务的方向。
• 当组件对资源的使用超过或少于其分配值。

如 表 A4.27 所示，Busy_Support属性用于定义接口是否包含繁忙标志信号。

表 A4.27 Busy_Support属性

当 Busy_Support 为 True 时，表 A28 以下信号将包含在接口上。

表 A28 繁忙标志信号

对于具有多个读取数据传输的事务，Busy必须有效，但每次传输可以有不同的值。

对于具有多个写入响应的事务，在BCOMP断言的响应中，Busy必须有效。 对于其他写入响应，Busy不适用时可以取任何值。

对于具有写入和读取响应的原子事务，BBUSY和RBUSY预计但不要求具有相同的值。

Busy标志值的具体使用方式是实现定义的，在 表 A4.29 中有展示了使用它的示例。 在这个示例中，如果从机无法生成动态繁忙标志，则默认值0b01是适当的。

表 A29 繁忙标志的使用例子

A4.30 Busy_Support 互操作性

A第5章 请求属性

本章描述了请求属性以及下游组件如何对其进行处理。它包含以下部分：

• A5.1 从机类型
• A5.2 内存属性
• A5.3 内存类型
• A5.4 协议错误
• A5.5 内存保护和领域管理扩展
• A5.6 内存加密上下文
• A5.7 多区域接口
• A5.8 Qos信号

A5.1 从机类型

从机被分类为内存从机或外设从机：

• 内存从机： 内存从机需要正确处理所有事务类型。

• 外设从机： 外设从机有一个 IMPLEMENTATION DEFINED 的访问方法。 通常访问方法在组件数据表中定义，该表描述了从机正确处理的事务类型。

任何不是 IMPLEMENTATION DEFINED 访问方法一部分的外设从机，其访问必须完成，并遵循协议。 然而，当这样的访问已被进行时，不要求外设从机继续正常操作。 只要求从机在协议合规的方式下继续完成进一步的事务。

A5.2 内存属性

本节描述了决定系统组件如缓存、缓冲区和内存控制器应如何处理请求的属性。 AWCACHE和ARCACHE信号指定了请求的内存属性。 它们控制：

• 事务如何在系统中进行。
• 任意系统级缓冲区和缓存如何处理事务。

在本规范中，术语AxCACHE统称为AWCACHE和ARCACHE信号。 表 A5.1 描述了AWCACHE和ARCACHE信号。

表 A5.1 AxCACHE信号

属性CACHE_Present用于确定接口上是否存在AxCACHE信号。

表 A5.2 CACHE_Present属性

AWCACHE位被编码为：

• [0] 可缓冲
• [1] 可修改
• [2] 其他分配
• [3] 分配

ARCACHE位被编码为：

• [0] 可缓冲
• [1] 可修改
• [2] 分配
• [3] 其他分配

请注意，分配和其他分配位在读请求和写请求中的位置不同。

A5.2.1 可缓冲-AxCACHE[0]

对于写入事务：

• 如果可缓冲位被解除断言，则写入响应表示数据已到达最终目的地。
• 如果可缓冲位被断言，则写入响应可以在满足可观察性要求时从中间点发送。

对于 ARCACHE[3:2] 被解除断言（不可缓存）且 ARCACHE[1] 被断言（可修改）的读取事务：

• 如果可缓冲位被解除断言，则读取的数据必须从最终目的地获取。
• 如果可缓冲位被断言，则读取的数据可以从最终目的地或从正在传输到最终目的地的写入中获取。

对于 ARCACHE[3:1] 的其他组合，可缓冲位无效。

A5.2.2 可修改-AxCACHE[1]

事务可以被修改。当AxCACHE[1]解除断言时，事务是不可修改的。 以下部分描述了不可修改和可修改事务的属性。

不可修改事务

不可将其拆分为多个事务或与其他事务合并。 在不可修改事务中，表 A5.3 中显示的参数不得更改。

表 A5.3 不可修改的参数

AxCACHE属性只能修改以将事务从可缓冲转换为不可缓冲。对AxCACHE的其他更改是不允许的。

事务ID和QoS值可以被修改。

长度大于16的不可修改事务可以分割成多个事务。 每个生成的事务必须满足本小节中给出的要求，但不可避免的带来一些改变，

• 长度减少。
• 地址要做相应的调整。

AxLOCK断言指定的独占访问不可修改事务，可以修改大小AxSIZE和长度AxLEN， 前提是总访问的字节数保持不变。

存在一些情况，无法满足不可修改事务的要求。 例如，当缩小到宽度小于大小要求的数据时，事务必须被修改。

执行该操作的组件可以选择性地包括 IMPLEMENTATION DEFINED 的机制，以指示已发生修改。 这种机制可以帮助软件调试。

可修改事务

可修改事务可以通过以下方式进行修改：

• 事务可以被分解为多个事务。
• 多个事务可以合并为一个事务。
• 读取事务可以获取比所需更多的数据。
• 写入事务可以访问比所需更大的地址范围，使用WSTRB信号确保只有适当的位置被更新。
• 在每个生成的事务中，可以修改以下属性：
  • 地址属性，AxADDR
  • 大小属性，AxSIZE
  • 长度属性，AxLEN
  • 突发属性，AxBURST

以下内容不得更改：

• 独占访问指示符，AxLOCK
• 保护和安全属性，AxPROT和AxNSE。

AxCACHE可以修改，但任何修改必须确保不减少其他组件对事务的可见性， 既不能阻止事务传播到所需位置，也不能更改在缓存中查找事务的需求。 对内存属性的所有修改必须对同一地址范围内的所有事务保持一致。

事务ID和QoS值可以被修改。
不允许的事务修改包括：

• 导致访问与原始事务不同的4KB地址空间。
• 导致对单一拷贝原子性大小区域的单个访问被执行为多个访问。见 A7.1 单副本原子大小

A5.2.3 分配和其他分配-AxCACHE[3:2]

如果分配位被断言：

• 数据可能先前已被分配，因此必须在缓存中查找该行。
• 建议将数据分配到缓存中以供将来使用。

如果其他分配位被断言：

• 数据可能先前已被分配，因此必须在缓存中查找该行。
• 不建议对数据进行分配，因为预计不会再次访问。

如果分配和其他分配都未断言，则请求不需要在任何缓存中查找。

A5.3 内存类型

AxCACHE信号的组合指示了一种内存类型。 A5.4 显示了内存类型编码。 括号中的值是允许的但不是首选的，表中未显示的值是保留的。

表 A5.4 内存类型编码

A5.3.1 内存类型需求

本节规定了各类内存的必要行为。

A设备非缓冲
设备非缓冲内存的必要行为是：

• 写操作的响应必须从最终目的地获得。
• 读取的数据必须从最终目的地获得。
• 事务是不可修改的，请参见 a5.2.2 可修改-AxCACHE[1] 。
• 读取的数据不得预取。
• 写事务不得合并。

A设备可缓冲
设备缓冲内存类型的必要行为是：

• 写操作的响应可以从中间点获得。
• 写事务必须在最终目的地及时可见。
• 读取的数据必须从最终目的地获得。
• 事务是不可修改的，请参见。
• 读取的数据不得预取。
• 写事务不得合并。

这两种设备内存类型都是不可修改的。在本规范中，设备内存和不可修改内存这两个术语是可以互换的。

对于读取事务，设备非缓冲和设备缓冲内存类型的必要行为没有区别。

A正常非缓存非缓冲
正常非缓存非缓冲内存类型的必要行为是：

• 写操作的响应必须从最终目的地获得。
• 读取的数据必须从最终目的地获得。
• 事务是可修改的，请参见 a5.2.2 可修改-AxCACHE[1] 。
• 写事务可以合并。

A正常非缓存可缓冲
正常非缓存缓冲内存类型的必要行为是：

• 写操作的响应可以从中间点获得。
• 写事务必须在最终目的地及时可见，具体定义见 c第1章 术语表 。 没有机制可以确定写事务何时在最终目的地可见。
• 读取的数据必须从以下任一来源获得：
  • 最终目的地。
  • 正在进行的写事务，目标是最终目的地。
• 如果从写事务获得读取数据：
  • 必须从写的最新版本获得。
  • 数据不得被缓存，用于服务于后续的读取。
• 事务是可修改的，请参见 a5.2.2 可修改-AxCACHE[1] 。
• 写事务可以合并。

对于正常非缓存可缓冲读取，数据可以从仍在进行中的写事务中获得，目标是最终目的地。 这些数据与同时传播到最终目的地的读取和写入事务无法区分。 以这种方式返回的读取数据并不表示写事务在最终目的地可见。

A写直通不分配
写直通不分配内存类型的必要行为是：

• 写操作的响应可以从中间点获得。
• 写事务必须在最终目的地及时可见，具体定义见 C第1章 术语表 。 没有机制可以确定写事务何时在最终目的地可见。
• 读取数据可以从中间缓存副本获得。
• 事务是可修改的，请参见 a5.2.2 可修改-AxCACHE[1] 。
• 读取数据可以预取。

A写直通读分配
写透读取分配内存类型的必要行为与写透不分配内存相同。出于性能原因：

• 建议分配读取事务。
• 不建议分配写事务。

A写直通写分配
透写分配内存类型的必要行为与写透不分配内存相同。出于性能原因：

• 不建议分配读取事务。
• 建议分配写事务。

A写直通读写分配
写直通读写分配内存类型的必要行为与写直通不分配内存相同。出于性能原因：

• 建议分配读取事务。
• 建议分配写事务。

A写回不分配
写回不分配内存类型的必要行为是：

• 写操作的响应可以从中间点获得。
• 写事务不要求在最终目的地可见。
• 读取数据可以从中间缓存副本获得。
• 事务是可修改的，请参见 a5.2.2 可修改-AxCACHE[1] 。
• 读取数据可以预取。
• 写事务可以合并。
• 读取和写入事务需要进行缓存查找。
• 不分配属性是一个分配提示，即它是向内存系统推荐的，出于性能原因，这些事务不会被分配。然而，读取和写入事务的分配并不被禁止。

A写回读分配
写回读取分配内存类型的必要行为与写回不分配内存相同。出于性能原因：

• 建议分配读取事务。
• 不建议分配写事务。

A写回写分配
写回写分配内存类型的必要行为与写回不分配内存相同。出于性能原因：

• 不建议分配读取事务。
• 建议分配写事务。

A写回读写分配
写回读写分配内存类型的必要行为与写回不分配内存相同。出于性能原因：

• 建议分配读取事务。
• 建议分配写事务。

A5.3.2 内存属性不匹配

多个访问同一内存区域的主机可以使用不匹配的内存属性。 但是，为了功能正确性，必须遵循以下规则：

• 访问同一区域内存的所有主机在任何层次结构中必须对该区域内存的缓存性有一致的视图。适用的规则是：
  • 如果地址区域是不可缓存的，则所有主机必须使用AxCACHE[3:2]都未断言的事务。
  • 如果地址区域是可缓存的，则所有主机必须使用AxCACHE[3:2]的任何一个断言的事务。
• 不同的主机可以使用不同的分配提示。
• 如果一个地址区域是正常的不可缓存，任何主机都可以使用设备内存事务访问它。
• 如果一个地址区域具有可缓冲属性，任何主机都可以使用不允许缓冲行为的事务访问它。例如，要求从最终目的地响应的事务不允许缓冲行为。

A5.3.3 改变内存属性

特定内存区域的属性可以从一种类型更改为另一种不兼容的类型。 例如，可以将属性从写直通缓存可用更改为普通不可缓存。 这一变化需要适当的过程来执行更改。

通常，执行以下过程：

1. 所有主机停止访问该区域。
2. 一个主机执行任何必要的缓存维护操作。
3. 所有主机重新开始访问内存区域，使用新的属性。

A5.3.4 事务缓冲

写入对以下内存类型的访问不需要最终目的地的事务响应，但确实需要确保写入事务及时在最终目的地可见：

• 设备可缓冲。
• 普通非缓存可缓冲。
• 写直通。

对于写入事务，这三种内存类型要求相同的行为。

对于读取事务，所需行为如下：

• 对于设备可缓冲内存，读取的数据必须从最终目的地获得。
• 对于普通非缓存可缓冲内存，读取的数据必须从最终目的地获得，或者从正在前往其最终目的地的写入事务中获得。
• 对于写直通内存，读取的数据可以从中间缓存副本中获得。

除了确保写入事务及时向其最终目的地产生进展之外，中间缓冲区必须表现如下：

• 一个可以响应事务的中间缓冲区必须确保随着时间的推移，任何对普通非缓存可缓冲内存的读取事务都向其目的地传播。 这种传播意味着在转发读取事务时，尝试的转发不能无限期继续，且用于转发的数据不能无限期存在。 协议未定义任何确定用于转发读取事务的数据能够存在多久的机制。但是，在这样的机制中，读取数据的行为不能重置数据超时期限。
  如果没有这一要求，持续对同一位置的轮询可能会阻止保存在缓冲区中的读取的超时，从而阻止读取向其目的地的进展。
• 一个可以持有和合并写入事务的中间缓冲区必须确保事务不会无限期保留在其缓冲区中。 例如，合并写入事务不得重置确定写入何时向其最终目的地排出的机制。
  如果没有这一要求，持续向同一位置写入可能会阻止保存在缓冲区中的写入的超时，从而阻止写入向其目的地的进展。

有关对这些内存类型的读取访问所需行为的信息，请参见：

• A设备可缓冲
• A正常非缓存可缓冲
• A写直通不分配

A5.3.5 设备内存实例

该规范支持设备非缓冲和设备缓冲内存类型的组合使用，以强制写入事务到达其最终目的地，并确保发起的主机知道事务何时对所有其他主机可见。

标记为设备缓冲的写入事务必须及时地到达其最终目的地。 然而，该事务的写入响应可以由一个中间缓冲区发出信号。 因此，发起的主机无法知道写入何时对所有其他主机可见。

如果主机发起了一个设备缓冲写入事务，或一系列写入事务，随后是一个设备非缓冲写入事务，并且所有事务使用相同的AXI ID， 则AXI排序要求强制所有设备缓冲写入事务在设备非缓冲事务给予响应之前到达最终目的地。 因此，设备非缓冲事务的响应表明所有事务对所有主机可见。

A5.4 协议错误

AXI协议定义了两类协议错误，软件协议错误和硬件协议错误。

A5.4.1 软件协议错误

软件协议错误发生在多个访问同一位置时，访问的共享性或缓存属性不匹配。 软件协议错误可能导致一致性丧失，并导致数据值损坏。 该协议要求系统在出现软件协议错误时不发生死锁，并且事务始终在系统中进行推进。

对一个4KB内存区域的访问导致的软件协议错误不得在另一个4KB内存区域造成数据损坏。 对于保存在正常内存中的位置，可以使用适当的软件屏障和缓存维护将内存位置恢复到定义状态。

在访问外设时，如果使用可修改事务（AxCACHE[1]被断言），则无法保证外设的正常操作。 唯一的要求是外设继续以遵循协议的方式响应事务。 将一个错误访问的外设恢复到已知工作状态所需的事件序列是实现定义的。

A5.4.2 硬件协议错误

硬件协议错误被定义为任何不是软件协议错误的协议错误。 硬件协议错误不需要支持。

如果发生硬件协议错误，则无法保证从错误中恢复。系统可能会崩溃、锁死或遭遇其他不可恢复的故障。

A5.5 内存保护和领域管理扩展

AXI提供可以用来保护内存免受意外事务的信号。

通过领域管理扩展（RME），内存保护也可以被扩展。 它提供基于硬件的隔离，允许执行上下文在不同的安全状态下运行并共享系统中的资源。

当使用RME时，它扩展了物理寻址和未转换事务的地址空间，影响缓存维护操作的运行并扩展了MPAM信号。 保护信号如 表 A5.5 所示

表 A5.5 保护信号

属性PROT_Present用于确定接口上是否存在AxPROT信号。 一个不使用保护属性的从机可以从其接口中省略AxPROT输入。

表 A5.6 PROT_Present属性

当使用RME时，RME_Support属性被设置为True，并且AxNSE信号出现在一个接口上。

表 A5.7 RME_Support属性

保护属性分为三个部分：

非特权与特权

AXI主机可能支持多于一个级别的操作特权，并且可以选择性地将这一特权概念扩展到内存访问。
AxPROT[0]将访问标记为非特权或特权：

• 0b0：非特权
• 0b1：特权

某些主机支持多个特权级别，请参阅所选处理器的文档以确定与AXI特权级别的映射。 AXI提供的唯一区分是特权和非特权访问之间的区分。

安全与非安全

如果AXI主机支持不同的安全操作状态，它可以将其扩展到内存访问中，使用安全属性。 具有不同安全属性的请求可以被视为占用不同的地址空间，因此同一地址可以根据安全属性解码到不同的位置。

• 0b0: 安全
• 0b1：非安全

AxPROT[1]和AxNSE信号用于定义安全属性，如 表 A5.8 所示。

表 A5.8 安全属性

数据与指令

AxPROT[2]表示事务是指令访问或数据访问：

• 0b0: 数据访问
• 0b1: 指令访问

AXI协议将此指示定义为提示。在所有情况下它并不一定准确。 例如，当一个事务包含指令和数据项的混合时。建议在访问被确定为指令访问之前，主机将AxPROT[2]设置为LOW以指示数据访问。

A5.6 内存加密上下文

内存加密上下文（MEC）是对Arm域管理扩展（RME）的扩展，允许每个域拥有其独特的加密上下文。

MEC扩展将内存加密上下文分配给域物理地址空间内的所有内存访问。 所有内存事务都与一个MECID相关，该ID由安全状态、转换方案、转换表和MEC系统寄存器决定。 MECID被内存加密引擎用作加密上下文表（无论是密钥还是变更）的索引，这些上下文有助于外部内存加密。

使用MEC可以通过使每组域数据采用不同的加密方式来帮助保护内存中的域数据。 这意味着，能够访问物理内存设备并能够解密一组域数据的恶意主机，无法使用相同的解密方法来访问其他组域数据。 在加密点（PoE）之前，在组件之间移动的数据是明文形式。

R-EL2上的域管理软件控制MECID的策略和分配给域的信息。

有关MEC的更多信息，请参见 [3] 和 [4] 。

请注意，MEC架构规范 [3] 详细说明了MECID值不匹配时的几种实现选项。 此MEC实现假设主机和缓存不执行任何MECID检查。

例如，如果与一个MECID相关的读取访问目标位置在缓存中有一个副本并且与不同的MECID相关，那么读取访问就会成功，好像MECID值没有不匹配一样。 这里不需要额外的保护，因为R-EL2上的域管理软件确保一个上下文无法访问属于不同上下文的位置，从而确保不会发生明文泄漏。

A5.6.1 MEC信号

MEC_Support属性确定接口是否支持内存加密上下文MEC。

表 A5.9 MEC_Support属性

MEC是RME的扩展，因此如果RME_Support属性为False，则MEC_Support必须为False。
表 A5.10 中信号是支持MEC所必需的。

表 A5.10 MECID信号

参数MECID_WIDTH定义了宽度。

表 A4.11 MECID_WIDTH属性

以下规则适用于MECID_WIDTH属性：

• 如果MECID_WIDTH为0，则AWMECID和ARMECID不在接口上。
• 如果MEC_Support为False，则MECID_WIDTH必须为0。
• 如果MEC_Support为True，则MECID_WIDTH必须不为0。

Note：
注意MECID的宽度并不表示组件使用了多少不同的值。通过使用更窄的内部宽度，可能可以减少MECID的存储需求。

如果两个组件之间的MECID位宽不同，可以进行零扩展或截去高位，具体取决于情况。 此调整仅在将公共MECID宽度设置为系统中任何MEC兼容组件支持的最小MECID宽度时，才能产生正确的MEC操作。

根据MEC_Support属性的值，主机和从机之间的兼容性如 表 A5.12 所示。

表 A5.12 MEC_Support兼容性

A5.6.2 MECID使用

MECID值范围是有界的，依赖于被访问的物理地址空间。

表 A5.13 在每个物理地址空间可能的MECID

MECID 不适用，并且对于以下请求操作码可以取任何值：

• CMO
• CleanInvalid
• MakeInvalid
• CleanShared
• CleanSharedPersist
• InvalidateHint
• StashTranslation
• UnstashTranslation

MECID 不适用，且对于以下请求操作码必须为 0：

• DVM Complete

传播事务并在其从机和主机上支持 MECID 的组件必须在适用请求中保留 MECID。 执行地址转换的组件可能会更改 MECID。

存储与 MECID 关联数据的高速缓存必须也存储 MECID，并在写回时与数据一同提供。

可以使用 CleanInvalidPoPA 操作来确保从加密点上游的所有缓存中清理并使缓存行失效。 有关 CleanInvalidPoPA 的更多信息，请参见 <a href="#a10.9 缓存维护和rme>A10.9 缓存维护和RME 。

A5.7 多区域接口

本节描述了在请求中使用区域ID的方式，以支持单个接口中具有多个地址区域的接口。

A5.7.1 区域ID信号

属性 REGION_Present 决定接口是否支持区域ID信号。

表 A5.14 REGION_Present属性

指示区域的信号如 表 A5.15 所示。

表 A5.15 Region信号

A5.7.2 区域ID

4位区域ID可用于唯一指示最多16个不同的区域。 区域ID可以提供更高位地址位的解码。 区域ID在任何4K字节的地址空间内必须保持不变。

使用区域ID意味着从机上的单个物理接口可以提供多个逻辑接口，每个接口在系统地址映射中具有不同的位置。 使用区域ID意味着从机不必支持不同逻辑接口之间的地址解码。

本规范期望互连在对具有多个逻辑接口的单个从机执行地址解码功能时产生AxREGION信号。 如果从机在系统地址映射中只有一个物理接口，则互连必须使用默认的AxREGION值。

区域ID有几种使用模型，包括但不限于以下内容：

• 外设可以在地址映射中的不同位置具有其主要数据路径和控制寄存器，并通过单个接口访问，无需从机执行地址解码。
• 从机可以在不同的内存区域表现出不同的行为。例如，从机可能在一个区域提供读写访问，但在另一个区域只提供只读访问。

从机必须确保正确的协议信号和事务的正确顺序得到维护。 从机必须确保对两个请求不同区域的相同事务ID的响应按正确顺序提供。

从机还必须确保AxREGION任何值的正确协议信号。 如果从机实现的区域少于十六个，则从机必须确保对任何对不支持区域的访问提供正确的协议信号。

如何实现这一点是实现定义的。例如，从机可能通过以下方式确保此点：

• 对于任何访问不支持区域的事务提供错误响应。
• 在所有不支持区域之间对受支持区域进行别名，以确保对所有访问给出合规的协议响应。

AxREGION信号仅提供现有地址空间的地址解码，可以被从机用来消除地址解码功能的需要。信号不创建新的独立地址空间。

AxREGION必须仅出现在地址解码功能下游的接口上。

A5.8 Qos信号

AXI支持服务质量（Quality of Service）QoS方案通过以下特性：

• A5.8.1 QoS 标志
• A5.8.2 QoS 接受标志

A5.8.1 QoS 标志

AXI请求有一个可选的标志，可以用来区分不同的流量流，如 表 A5.16 所示。

表 A5.16 QoS信号

QOS_Present属性用于定义接口是否包含AxQOS信号。

表 A5.17 QOS_Support属性

该协议未指定QoS标志的具体使用方式。 建议将AxQOS用作关联写或读请求的优先级指示符，其中较高的值表示更高优先级的请求。

使用QoS标志

主机可以生成自己的AxQOS值，如果它可以生成多个流量流，可以为不同的流选择不同的QoS值。

支持QoS需要对正在使用的QoS方案有系统级的理解，以及所有参与组件之间的协作。 因此，建议主机组件包括一些可编程性，以可用于控制任何给定场景下使用的确切QoS值。

如果主机组件不支持可编程QoS方案，则可以使用表示其生成的事务相对优先级的QoS值。 这些值随后可以映射到适当的替代系统级QoS值。

该规范预期许多互连组件实现将支持可编程寄存器，这些寄存器可用于将QoS值分配给连接的主机。 这些值替代主机提供的编程或默认QoS值。

QoS的默认系统级实现是任何具有选择多个要处理的事务的组件首先选择具有更高QoS值的请求进行处理。 当没有其他AXI约束要求按特定顺序处理请求时，才会进行此选择。 这意味着AXI排序规则优先于QoS目的的排序。

A5.8.2 QoS 接受标志

表 A5.18 中显示的QoS接受指标是来自从机的输出信号，指示它接受的最低QoS值而不会产生延迟。 这些信号与ACLK同步，但与其他AXI通道无关。

表 A5.18 QoS接受信号

QoS接受信号旨在用于具有不同资源的从机组件，以满足不同的QoS值，这通常适用于内存控制器。 当较低QoS值所需的资源正在使用时，从机可以表明它仅接受特定QoS值或更高的请求。

QoS接受信号可以作为主机的输入，该接口可能有多个不同的请求可供选择。 这允许主机仅发出有可能被接受的请求，从而避免接口的不必要阻塞。

通过防止可能停滞一段时间的请求被发出，接口仍然可用于发出可能在稍后时间抵达的更高优先级请求。

在本规范中，术语VAxQOSACCEPT统称为VAWQOSACCEPT和VARQOSACCEPT信号。 VAxQOSACCEPT信号的规则和建议如下：

• 任何QoS级别等于或高于VAxQOSACCEPT的请求将被从机接受。
• 任何QoS级别低于VAxQOSACCEPT的请求可能会被显著延迟。
  本规范未定义从机必须在何种时间段内接受等于或高于所指QoS级别的请求。 然而，预计对于给定的从机，接受事务所需的时钟周期数是确定性的最大值，这在考虑到实现方面（如时钟域交叉比率）后得出。
• 允许从机接受低于VAxQOSACCEPT信号所指示的QoS级别的请求，但预计该请求可能会遭受显著延迟。 虽然从机延迟优先级低于QoS接受级别的请求是可以接受的，但建议该事务不应无限期延迟。

优先级低的事务在接口发出的原因有几个，例如：

• QoS接受值的变化与组件适应该变化之间的延迟。
• 需要对此事务进行以避免阻塞较高优先级请求的头部。
• 由于饥饿预防的原因，要求对此事务进行。

表 A5.19 中显示的QoS_Accept属性用于定义接口是否包含QoS接受指示信号。

表 A5.19 QoS_Accept属性

A第6章 事务ID和顺序

本章描述了事务标志及其如何用于控制事务的顺序。 它包含以下部分：

• A6.1 事务ID
• A6.2 唯一ID
• A6.3 请求顺序
• A6.4 互联使用事务ID
• A6.5 写数据和响应顺序
• A6.6 读数据顺序

A6.1 事务ID

AXI协议包含一个事务ID（AXI ID）。 主机可以使用AXI ID来识别必须按顺序返回的事务。

所有具有给定AXI ID值的事务必须保持有序，但对于不同ID值的事务没有排序限制。

单个物理端口可以通过作为多个逻辑端口来支持乱序事务，每个端口按顺序处理其事务。

通过使用AXI ID，主机可以发出事务而无需等待早期事务完成这可以提高系统性能， 因为它使事务的并行处理成为可能。

A6.1.1 事务ID信号

读写请求、读取数据和写入响应通道包括一个事务ID信号。

表 A6.1 ID信号

表 A6.2 中描述了ID宽度属性。

表 A6.2 ID位宽属性

如果宽度属性为零，则相关信号不存在。

一个不支持请求和响应重排序的主机，或者只有一个未完成事务的主机，可以从其接口中省略 ID 信号。 相应的从机必须将其 AxID 输入固定为低电平。

一个不重排序请求或响应的从机不需要使用 ID 值。 如果一个从机不包含 ID 信号，则不能连接到具有 ID 信号的主机。 因为主机要求从AWID和ARID对应BID和RID。

A6.2 唯一ID

唯一ID指示器是一个可选标志，指示在读或写地址通道上的请求是否使用了对于在途事务唯一的AXI ID。 在读和写响应通道上也有一个相应的信号，用于指示某个事务使用了唯一ID。

唯一ID指示器可以在AXI主机下游使用，以确定何时请求需要相对于该主机的其他请求进行排序。 那些不需要排序的请求可能在下游组件中不需要跟踪。

Unique_ID_Support属性用于指示接口是否支持唯一ID指示。

表 A6.3 Unique_ID_Support 属性

当Unique_ID_Support为真时，以下信号包含在读取请求、读取数据、写入请求和写入响应通道中。

表 A6.4 唯一ID信号

以下规则适用于唯一 ID 指示符：

• 当AWIDUNQ被断言时，该主机不得有同一AWID值的未完成写入事务。
• 当AWIDUNQ被断言时，该主机不得发出与未完成写入事务具有相同AWID的写入请求。
• 如果请求的AWIDUNQ断言被解除， 则对应的BIDUNQ信号必须在单个传输响应中或在多传输响应的完成部分中被解除断言。
• 如果请求的AWIDUNQ被断言， 则对应的BIDUNQ信号必须在单个传输响应中或在多传输响应的完成部分中被断言。
• 当ARIDUNQ被断言时，该主机不得有同一ARID值的未完成读取事务。
• 当ARIDUNQ被断言时，该主机不得发出与未完成读取事务具有相同ARID的读取请求。
• 如果请求的ARIDUNQ被解除断言，则必须为该事务的所有响应传输解除相应的RIDUNQ信号断言。
• 如果请求的ARIDUNQ被断言，则必须为该事务的所有响应传输断言相应的RIDUNQ信号。
• 对于包含读取和写入响应的原子事务，还适用附加规则：
  • 如果原子请求的AWIDUNQ被取消断言，则必须为该事务的所有响应传输解除相应的RIDUNQ信号断言。
  • 如果原子请求的AWIDUNQ被断言，则必须为该事务的所有响应传输断言相应的RIDUNQ信号。

一个事务从AxVALID被断言的周期开始，直到最终响应传输被主机接受的周期结束。 如果接口包含BCOMP，则该事务在收到断言BCOMP的响应之前被视为未完成。

一个原子事务在写入和读取响应都被主机接受之前是未完成的，参见 A7.4 原子事务 。

某些事务类型规定如果存在，则需要断言AxIDUNQ。 如果没有指定，即使没有使用相同 ID 的未完成事务，断言AxIDUNQ是可选的。

A6.3 请求顺序

AXI请求排序模型是基于事务ID的使用，该ID在ARID或AWID上发出信号。

具有相同ID和目标的同一通道上的事务请求保证保持顺序。
具有相同ID的事务响应将以与请求发出相同的顺序返回。

排序模型不对以下情况提供任何排序保证：

• 来自不同主机的事务。
• 读和写事务。
• 具有不同ID的事务。
• 发送到不同外设区域的事务。
• 发送到不同内存位置的事务。

如果主机要求在没有排序保证的事务之间进行排序，则主机必须等到收到第一个事务的响应后再发出第二个事务。

A6.3.1 内存位置和外设区域

AMBA中的地址映射由内存位置和外设区域组成。
内存位置具有以下所有属性:

• 从内存位置读取一个字节返回该字节位置最后写入的值。
• 向内存位置的一个字节写入更新该位置的值为后续读取该位置获得的新值。
• 对内存位置的读取或写入对任何其他内存位置没有副作用。
• 每个位置都有内存观察保证。
• 内存位置的大小等于该组件的单拷贝原子性大小。

外设区域具有以下所有属性：

• 从外设区域中的一个地址读取并不一定返回最后写入该地址的值.
• 向外设区域中的一个字节地址写入并不一定将该地址的值更新为后续读取获得的新值.
• 访问外设区域内的一个地址可能对该区域内的其他地址产生副作用。
• 每个区域都有外设观察保证
• 外设区域的大小由实现定义，但必须包含在一个从机内。
• 一个事务可以针对一个或多个地址位置，这些位置由AxADDR和任何相关限定符如地址空间确定。
• 仅对同一内存位置或外设区域的访问之间提供排序保证。
• 针对外设区域的事务必须完全包含在该区域内。
• 跨越多个内存位置的事务具有多个排序保证。

A3.6.2 设备和正常请求

事务可以是设备类型或普通类型。

设备事务

一个读取或写入请求，其中AxCACHE[1]失效。

设备事务可用于访问外设区域或内存位置。

普通事务

一个读取或写入请求，其中AxCACHE[1]有效。

普通事务用于访问内存位置，且不应预期用于访问外围区域。

对外设区域的普通访问必须以符合协议的方式完成，但结果是IMPLEMENTATION DEFINED。

A3.6.3 观察和完成定义

对于对外设区域的访问，当设备读取或写入访问DRW1在DRW2到达从机之前时，设备读取或写入访问DRW2会观察到DRW1。

对于对内存位置的访问，以下所有条件均适用：

• 如果W2在W1之后生效，则写入W1会被写入W2观察到。
• 如果R1从写入W3返回数据，而W2在W3之后，则读取R1会被写入W2观察到。
• 如果R2从W1或写入W3返回数据，而W3在W1之后，则写入W1会被读取R2观察到。

读取R1或写入W1可以是设备类型或普通类型。

写入和读取完成的定义如下：

写入完成响应

在关联的BRESP握手被发出时的周期， 当BVALID，BREADY和BCOMP（如果存在）被断言。

读取完成响应

在最后一个关联的RDATA握手被发出时的周期，当RVALID，RLAST和RREADY被断言。

A6.3.4 主机顺序保证

有三种类型的排序模型保证：

• 在收到完成响应之前的可观察性保证。
• 完成响应中的可观察性保证。
• 响应排序保证。

在收到完成响应之前的可观察性保证

以下所有保证适用于使用相同 ID 的同一主机的事务：

• 设备写入 DW1 保证在目的地到达之前先于设备写入 DW2 到达，其中 DW2 在 DW1 之后发布，且针对相同的外设区域。
• 设备读取 DR1 保证在目的地到达之前先于设备读取 DR2 到达，其中 DR2 在 DR1 之后发布，且针对相同的外设区域。
• 写入 W1 保证被写入 W2 观察到，其中 W2 在 W1 之后发布，且针对相同的内存位置。
• 一个被读取 R2 观察到的写入 W1 保证被读取 R3 观察到，其中 R3 在 R2 之后发布，且针对相同的内存位置。

从完成响应中的可观察性保证

完成响应的保证如下：

• 对于读取请求，完成响应保证它对来自任何主机的后续读取或写入请求是可观察的。
• 对于不可缓冲的写入请求，完成响应保证它对来自任何主机的后续读取或写入请求是可观察的。
• 对于可缓冲的写入请求，完成响应可以从一个中间点发送。它并不保证写入在端点完成，但保证可观察性，这取决于请求的域：
  • 不可共享：仅对发布主机可观察。
  • 可共享：对共享域中的所有其他主机可观察。
  • 系统：对所有其他主机可观察。

有关域的更多信息，请参阅 A9.3 缓存一致性和域 。

响应排序保证

事务响应具备以下所有排序保证：

• 读取 R1 保证在读取 R2 的响应之前收到响应，其中 R2 是在 R1 之后从同一主机发布且具有相同 ID 的请求。
• 写入 W1 保证在写入 W2 的响应之前收到响应，其中 W2 是在 W1 之后从同一主机发布且具有相同 ID 的请求。

A6.3.5 从机顺序需求

为了满足主机顺序的保障，从机也必须满足以下要求。

外设位置

• 对于外设位置，对外设位置事务的执行顺序是实现定义的。该执行顺序通常预期与到达顺序相匹配，但这并不是要求。

内存位置

• 写入 W1 必须在写入 W2 之前，W1 和 W2 是同一内存位置相同 ID 的访问，W2 的接收时间晚于 W1 的接收时间。
• 写入 W1 必须在写入 W2 之前，W1 和 W2 是同一内存位置的访问，W2 的接收时间晚于 W1 的完成响应。
• 写入 W1 必须在读取 R2 之前，W1 和 R2 是同一内存位置的访问，R2 的接收时间晚于 W1 的完成响应。
• 读取 R1 必须在写入 W2 之前，W1 和 W2 是同一内存位置的访问，W2 的接收时间晚于 R1 的完成响应。

响应排序要求

• 对读取 R1 的响应必须在对读取 R2 的响应之前返回，R2 是在 R1 之后接收的，相同 ID。
• 对写入 W1 的响应必须在对写入 W2 的响应之前返回，W2 是在 W1 之后接收的，相同 ID。

A3.6.6 互联顺序需求

互连组件具有以下属性：

• 在一个端口接收到请求，并在另一个端口发出或响应。
• 在一个端口接收到响应，并在另一个端口发出或处理。

当互连发出请求或响应时，必须遵循以下要求：

• 在发出读取 R2 请求之前，必须发出读取 R1 请求，其中 R2 是在 R1 之后接收的，具有相同的 ID，并且指向相同或重叠的位置。
• 在发出写入 W2 请求之前，必须发出写入 W1 请求，其中 W2 是在 W1 之后接收的，具有相同的 ID，并且指向相同或重叠的位置。
• 在发出设备读取 DR2 请求之前，必须发出设备读取 DR1 请求，其中 DR2 是在 DR1 之后接收的，具有相同的 ID，并且指向相同的外设区域。
• 在发出设备写入 DW2 请求之前，必须发出设备写入 DW1 请求，其中 DW2 是在 DW1 之后接收的，具有相同的 ID，并且指向相同的外设区域。
• 在发出读取 R2 响应之前，必须发出读取 R1 响应，其中 R2 是在 R1 之后接收的，具有相同的 ID。
• 在发出写入 W2 响应之前，必须发出写入 W1 响应，其中 W2 是在 W1 之后接收的，具有相同的 ID。

当互连作为从机工作时，也必须遵循从机要求。

与事务相关 AXI ID 值的任何操作必须确保原始 ID 值的顺序要求得以保持。

A3.6.7 终点之前响应

为了提高系统性能，中间组件可以对某些事务发出响应。这一操作被称为提前响应。 发出提前响应的中间组件必须确保满足可见性和排序保证。

提前读取响应

对于普通读取事务，如果中间组件的本地内存与对相同或重叠地址的所有早期写入保持同步，则可以用读取数据进行响应。 在这种情况下，请求不需要传播到中间组件之外。

中间组件必须遵守 ID 排序规则，这意味着只有在所有早期的相同 ID 读取已经有响应的情况下，才能发送读取响应。

提前写入响应

对于可缓冲写入事务（AWCACHE[0] 被置为有效），中间组件可以为没有下游观察者的事务发送提前写入响应。 如果中间组件发送提前写入响应，则可以存储数据的本地副本，但必须在丢弃该数据之前将事务向下游传播。

中间组件必须遵守 ID 排序规则，这意味着只有在所有早期的相同 ID 写入已经有响应的情况下，才能发送写入响应。

在发送提前写入响应后，该组件必须负责该事务的排序和可观察性，直到写入被传播到下游并收到写入响应。 在发送提前写入响应和收到下游响应的期间，该组件必须确保：

• 如果对普通事务给予了提前写入响应，则所有后续事务对相同或重叠内存位置的写入都是在已经给予提前响应的写入之后排序。
• 如果对设备事务给予了提前写入响应，则所有后续事务对相同外设区域的写入都是在已经给予提前响应的写入之后排序。

在对设备可缓冲事务给予提前写入响应时，预计中间组件将独立于其他事务传播写入事务。 中间组件无法等待另一个读取或写入到达，然后再传播之前的设备写入。

A3.6.8 不同内存类型之间的请求顺序

在可缓存请求与设备请求或非缓存普通请求之间没有排序要求。 设备请求与非缓存普通请求之间的排序要求取决于Device_Normal_Independence属性。

表 A6.5 Device_Normal_Independence属性

连接具有不同Device_Normal_Independence值的主机和从机接口的指导如 表 A6.6 所示。

表 A6.6 Device_Normal_Independence互联指导

A3.6.9 写入可观察顺序

为了提高与支持不同排序模型的接口协议兼容性， 从机可以为写事务提供更强的排序保证，这被称为有序写观察。

Ordered_Write_Observation 属性用于定义一个接口是否具有有序写观察。

表 A6.7 Ordered_Write_Observation 属性

一个展示有序写观察的接口为写事务提供了保证，这些保证与目的地或地址无关：

• 写操作W1保证会被写操作W2观察到，其中W2是在W1之后由同一主机发出的，且具有相同的ID。

使用有序写观察时，主机可以在不等待写响应的情况下发出多个写请求，并且它们会按照发出顺序被观察。 这在使用Producer-Consumer排序模式时可以提高性能。

A6.4 互联使用事务id

当一个主机连接到互连时，互连会将附加bit附加到AWID和ARID， 这些位对于该主机端口是唯一的。这有两个效果：

• 主机不必知道其他主机使用的ID值，因为互连通过将主机编号附加到原始ID使每个主机使用的ID值唯一。
• 从机接口处的ID比主机接口处的ID更宽。

对于写响应，互连使用BID附加bit来确定写响应的目标主机器端口。 互连在将BID值传递给正确的主机端口之前会去掉这些BID的位。

对于读数据，互连使用RID的附加bit来确定读数据的目标主机端口。 互连在将RID值传递给正确的主机端口之前会去掉这些RID的位。

A6.5 写数据和响应顺序

从机必须确保写响应的BID值与其响应请求的AWID值匹配。

主机必须按照发出事务请求的顺序发出写数据。

一个将不同主机的写事务结合在一起的互连必须确保以请求顺序转发写数据。

不同事务的写数据传输不允许交错。

互连必须确保来自具有相同AWID值的事务序列的写响应在请求顺序中被主机接收。

A6.6 读数据顺序

从机必须确保任何返回数据的RID值与其响应请求的ARID值匹配。

互连接口必须确保来自同一ARID值的不同从机的一系列事务的读取数据按请求顺序被主机接收。

读取数据重排序深度是从机可能发送读取数据的最大接受请求数量。 按接收请求的顺序发送读取数据的从机具有一级读取数据重排深度。

读取数据重排序深度是一个静态值，可以由从机的设计者指定。

主机没有机制动态地确定从机的读取数据重排序深度。

A6.6.1 读数据交错

对于读取数据传输允许使用不同的ID值交织进行，这包括所有可以有多个读取数据传输的事务，包括原子事务。

如果确定附加的从机将交织不同事务的读取数据，一些AXI主机和互联组件可以更有效地设计。

Read_Interleaving_Disabled属性用于指示接口是否支持来自不同事务的读取数据传输交织。

表 A6.8 Read_Interleaving_Disabled

对于某些接口，此属性可用作配置控制。对于其他接口，它是一个功能指示器。 所有发出具有不同ID的事务的主机必须被设计为接受交织数据。 作为一种优化，当附加的从机支持禁用交错时，主机可能使用配置选项来禁用交错。

A6.6.2读取数据分块

读取数据分块选项使从机能够使用128bit粒度重新排序事务中的读取数据。 起始地址可能用作决定首先发送哪个块的提示，但从机允许以任何顺序返回数据块。

属性Read_Data_Chunking用于指示接口是否支持以可重新排序的块形式返回读取数据。

表 A6.9 Read_Data_Chunking 属性

A6.6.2.1 读取数据分块信号

表 A6.10 读取数据分块信号

当支持读取数据分块时，在读取请求和数据通道中会添加如 表 A6.10 所示的信号。

表 A6.10 读取数据分块信号

属性RCHUNKNUM_WIDTH定义了RCHUNKNUM信号的宽度。

表 A6.11 RCHUNKNUM_WIDTH属性

RCHUNKSTRB_WIDTH属性定义RCHUNKSTRB信号的宽度.

表 A6.12 RCHUNKSTRB_WIDTH属性

具有较小DATA_WIDTH的接口可以包含RCHUNKNUM和RCHUNKSTRB信号， 宽度为1位，也可以从接口中省略它们。 当使用接口保护时，RCHUNKCHK信号涵盖这两个信号， 因此连接组件的RCHUNKNUM和RCHUNKSTRB必须具有相同的宽度。

建议在接口不需要时省略RCHUNKNUM和RCHUNKSTRB。

A6.2.2 读数据分块协议规则

在读取数据分块协议中，所有以下规则都适用：

• ARCHUNKEN 仅针对具有以下属性的事务：
  • 大小等于数据通道宽度，或长度为一次传输。
  • 大小为 128 位或更大。
  • Addr 对齐到 16 字节。
  • Burst 为 INCR 或 WRAP。
  • 操作码为 ReadNoSnoop、ReadOnce、ReadOnceCleanInvalid 或 ReadOnceMakeInvalid。
• ID 值必须在飞行中是唯一的，这意味着：
  • 只有在没有使用相同ARID值的未完成读取事务的情况下，才能断言ARCHUNKEN。
  • 主机不得在读取通道上发出与具有断言ARCHUNKEN的未完成请求具有相同ARID的请求。
  • 如果在接口上存在，则如果断言ARCHUNKEN，则必须断言ARIDUNQ。
• 如果解除断言ARCHUNKEN，则必须为事务的所有响应传输解除断言RCHUNKV。
• 如果断言ARCHUNKEN，则可以为事务的响应传输断言RCHUNKV。
• RCHUNKV 必须对事务的每个响应传输相同。
• 当断言RVALID和RCHUNKV时，RCHUNKNUM必须介于零和ARLEN之间。
• 当断言RVALID和RCHUNKV时，RCHUNKSTRB必须不为零。
• 当断言RVALID和RCHUNKV时，RLAST仅针对事务的最终响应传输断言， 与RCHUNKNUM和RCHUNKSTRB无关。
• 当断言RVALID且解除断言RCHUNKV时，RCHUNKNUM和RCHUNKSTRB可以取任何值。

传输的数据块数量必须与ARLEN和ARSIZE一致， 因此事务中传输的字节数无论是否启用分块都相同。

请注意，当使用读取数据分块时，事务可能比 ARLEN 指示的具有更多读取数据传输。

对于未对齐的事务，地址低于ARADDR的块不会传输，并且必须解除断言RCHUNKSTRB。

A6.6.2.3 互操作性

如果主机支持读数据分块，从机也支持分块，那么下游互联和从机可以减少其缓冲。 一种连接到具有混合分块支持组件的互联可以根据所附组件的能力驱动ARCHUNKEN和RCHUNKV。

当连接具有不同Read_Data_Chunking属性值的接口时，适用以下规则，如 表 A6.13 所示。

表 A6.13 Read_Data_Chunking互操作性

A6.6.2.4 分块实例

在这些示例中，图中的每一行表示一次传输，阴影单元格表示未传输的字节。

图 A6.1 显示了在256位宽的读数据通道上的一次事务，其中：

• 地址为0x00
• 长度为2次传输
• 尺寸为256位
• 突发为INCR

图 A6.1

图 A6.2 在256位宽读数据通道上的一次事务，其中：

• 地址是0x10
• 长度是2次传输
• 尺寸是256位
• 突发是INCR

图 A6.2

在一个128位宽的读数据通道上的事务，其中：

• 地址是0x10。
• 长度是4个传输。
• 尺寸是128位。
• 突发是WRAP。
• RCHUNKSTRB不存在。

从机使用起始地址作为提示，并首先发送0x10处的块。

图 A6.3

A第7章 原子访问

本章描述了单副本和多副本的原子性以及如何执行独占访问和原子事务。
它包含以下部分：

• A7.1 单副本原子大小
• A7.2 多副本原子写
• A7.3 独占访问
• A7.4 原子事务

A7.1 单副本原子大小

单副本原子性大小是一个事务原子更新的最小字节数。 AXI协议要求大小超过单副本原子性大小的事务以至少单副本原子性大小的块更新内存。

原子性并不定义数据更新的确切时刻。必须确保没有主机能够观察到原子数据的部分更新形式。 例如，在许多系统中，数据结构如链表由32位原子元素组成。 对这些元素之一的原子更新需要在同一时间更新整个32位值。 任何主机都不能观察到一次仅更新16位，然后再更新另外16位的情况。

更复杂的系统需要对更大原子元素的支持，特别是64位原子元素，以便主机能够使用基于这些更大原子元素的数据结构进行通信。

系统中支持的单副本原子性大小很重要，因为涉及某一通信的所有组件必须支持所需的原子元素大小。 如果两个主机通过互连和一个从机进行通信，则所有相关组件必须确保所需大小的事务被视为原子。

AXI协议不要求特定的单副本原子性大小，系统可以设计为支持不同的单副本原子性大小。

在AXI中，单副本原子组一词描述了一组可以在特定原子性下进行通信的组件。例如，图 A7.1 显示了这样一个系统，其中：

• CPU、DSP、DRAM控制器、DMA控制器、外设、SRAM内存和相关互连处于32位单副本原子组中。
• CPU、DSP、DRAM控制器和相关互连也处于64位单副本原子组中。

图 A7.1

一个事务的原子性保证从来没有超过其起始地址的对齐程度。 例如，在一个64位单副本原子组中的事务，如果没有与8字节边界对齐，则没有任何64位单副本原子保证。

与事务相关的字节strobes不会影响单副本原子性大小。

A7.2 多副本原子写

如果满足下列情况，则一个系统被定义为多副本原子性：

• 所有代理观察到对同一位置的写入是按照相同的顺序进行的。
• 对一个代理可观察位置的写入，对于所有代理都是可观察的。

为了说明一个系统提供多副本原子性，定义了一个Multi_Copy_Atomicity属性。

表 A7.1 Multi_Copy_Atomicity 属性

多副本原子性可以通过以下方式确保：

• 对于给定地址使用单一的序列化点（Point of Serialization - PoS），以便对同一位置的所有访问都被排序。 这必须确保在新值对任何代理可见之前，位置的所有一致缓存副本都失效。
• 避免使用在任何代理上游的转发缓冲区。这防止了某些代理在所有代理可见之前看到位置的缓冲写入。

要求该多副本原子性属性在本规范的第G期及之后为真。

A7.3 独占访问

独占访问机制可以提供信号量类型的操作，而无需在操作期间将连接专门分配给特定的主机。

AxLOCK信号用于指示独占访问， 而BRESP和RRESP信号分别指示独占访问写入或读取的成功或失败。

表 A7.2 AxLOCK 信号

Exclusive_Accesses属性用于定义主机是否能够发放独占访问权限或从机是否支持这些权限。

表 A7.3 Exclusive_Accesses 属性

表 A7.4 提供了在连接具有不同属性值的主机和从机组件时适用的指导。

表 A7.4 独占访问的互操作性

A7.3.1 独占访问序列

独占访问序列的机制是：

1. 主机从一个地址发出独占读取请求。
2. 在稍后的时间，主机尝试通过向同一地址发出独占写入请求来完成独占操作， 并且AWID与用于独占读取的ARID相匹配。
3. 该独占写入访问被标记为：
   • 成功，如果自独占读取访问以来没有其他主机写入该位置。在这种情况下，独占写入更新内存。
   • 失败，如果自独占读取访问以来其他主机已向该位置写入。在这种情况下，内存位置不更新。

主机可能没有完成独占操作的写入部分。独占访问监控硬件仅监控每个事务ID的一个地址。 如果主机没有完成独占操作的写入部分，则该主机使用相同的事务ID进行的后续独占读取将改变监控的独占访问地址。

A7.3.2 从主机的角度进行独占访问

一个主机通过执行独占读取开始独占操作。 如果事务成功，从机返回EXOKAY响应，表示从机记录了需要监控的独占访问地址。

如果主机尝试对不支持独占访问的从机进行独占读取，从机返回OKAY响应，而不是EXOKAY响应。 在这种情况下，读取的数据是有效的，但位置并没有被独占性监控。

主机可以将OKAY响应视为错误条件，表示不支持独占访问。 建议主机不要执行此独占操作的写入部分。

在独占读取后，主机尝试对同一位置执行独占写入。 如果所寻址位置的内容自独占读取以来没有被更新，则独占写入操作成功。 从机返回EXOKAY响应，并更新内存位置。

如果所寻址位置的内容自独占读取以来已被更新，则独占写入尝试失败，从机返回OKAY响应，而不是EXOKAY响应。独占写入尝试不会更新内存位置。

主机可能无法完成独占操作的写入部分。 如果发生这种情况，从机继续监控该地址的独占访问，直到另一个独占读取开始新的独占访问序列。 主机在读取部分完成之前，不得开始独占访问序列的写入部分。

A7.3.3 独占访问限制

以下限制适用于独占访问：

• 独占访问的地址必须与事务中的字节总数对齐，即 Size 和 Length 的乘积。
• 在独占访问事务中传输的字节数必须是 2 的幂，即 1、2、4、8、16、32、64 或 128 字节。
• 独占事务中可以传输的最大字节数为 128。
• 独占访问的长度不得超过 16 次传输。
• 域不得是可共享的，请参见 A9.3.3 可共享域 。
• 操作码必须是 ReadNoSnoop 或 WriteNoSnoop。请参见 A第8章 请求操作码 。
• AWTAGOP 必须不匹配，请参见 A13.2 内存标签扩展 。

未遵守这些限制会导致UNPREDICTABLE的行为。

为了使独占序列成功，AxCACHE值必须适当，以确保读写请求到达独占访问监控器。

在独占操作期间需要监控的最小字节数是 Size 和 Length 的乘积。

从机可以监控更多的字节，最多可达 128，这是独占访问中的最大字节数。 然而，这可能导致成功的独占访问被指示为失败，因为相邻的字节被更新。 如果在独占序列中的读请求和写请求之间显示的任何信号在表 A7.5 中不同，则即使该位置未被其他代理更新，独占写入也可能失败。

表 A7.5 独占序列中应该保持不变的信号

A7.3.4 从从机的角度进行独占访问

一个支持独占访问的从机必须具有监视硬件。 建议每个支持独占功能的主机ID都配有一个监视单元， 可以访问该从机。

当从机接收到独占读取请求时，它会记录任何独占读取操作的地址和ARID值。 然后它监视该位置，直到该位置发生写入，或直到另一个具有相同ARID值的独占读取将监视器重置为另一个地址。

如果从机能够成功处理独占读取，它会对每个读取数据传输回应EXOKAY。

如果从机无法处理独占读取，它会以不是EXOKAY的响应作出回应。 一个独占读取可以有多个响应传输。对于单个事务不允许同时出现OKAY和EXOKAY响应。

当从机接收到具有给定AWID值的独占写入时，监视器会检查该地址是否正在监视该AWID的独占访问。 如果是，这表明自独占读取访问以来，该位置没有发生写入，独占写入继续进行，并完成独占访问。 从机向主机返回EXOKAY响应，并更新指定的存储位置。

如果在独占写入时，该地址未使用相同的AWID值进行，这表示以下情况之一：

• 该位置自独占读取访问以来已被更新。
• 监视器已重置到另一个位置。
• 主机没有以与独占写入相同的属性发出独占读取。

在所有独占写入都不得更新指定位置的情况下，从机必须返回OKAY响应，而不是EXOKAY响应。

如果一个不支持独占访问的从机接收到独占写入，它会以OKAY响应作出回应，并更新该位置。

A7.4 原子事务

原子事务不仅仅执行单一访问，还有与事务相关联的操作。 原子事务允许将操作发送到数据上，从而使操作能够在更靠近数据位置的地方执行。 原子事务适用于数据与必须执行操作的代理相距较远的情况。

与使用独占访问相比，该方法减少了在系统中必须使数据对其他代理不可访问的时间。

A7.4.1 概述

在原子事务中，主机发送一个地址、控制信息和出站数据。从机发送入站数据（原子存储除外）和响应。 该规格支持四种形式的原子事务：

原子存储 - AtomicStore

• 主机发送一个带地址的单一数据值和要执行的原子操作。
• 从机使用发送的数据和位于地址位置的值作为操作数执行操作。 •-结果存储在地址位置。
• 提供一个没有数据的单一响应。
• 出站数据大小为1、2、4或8字节。

原子加载 - AtomicLoad

• 主机发送一个带地址的单一数据值和要执行的原子操作。
• 从机返回位于地址位置的原始数据值。
• 从机使用发送的数据和位于地址位置的值作为操作数执行操作。
• 结果存储在地址位置。
• 出站数据大小为1、2、4或8字节。
• 入站数据大小与出站数据大小相同。

原子交换 - AtomicSwap

• 主机发送一个带地址的单一数据值。
• 从机使用事务中提供的数据值交换地址位置的值。
• 从机返回位于地址位置的原始数据值。
• 出站数据大小为1、2、4或8字节。
• 入站数据大小与出站数据大小相同。

原子比较 - AtomicCompare

• 主机发送两个数据值，即比较值和交换值，至地址位置。比较值和交换值大小相等。
• 从机将地址位置的数据值与比较值进行检查：
  • 如果值匹配，则将交换值写入地址位置。
  • 如果值不匹配，则不将交换值写入地址位置。
• 从机返回位于地址位置的原始数据值。
• 出站数据大小为2、4、8、16或32字节。
• 入站数据大小为出站数据大小的一半，因为出站数据包含比较值和交换值，而入站数据仅具有原始数据值。

A7.4.2 原子事务操作

该规范支持八种不同的操作，可将 A7.6 所示的与AtomicStore和AtomicLoad事务一起使用。

A7.4.2 原子事务操作

A7.4.3 原子事务属性

原子事务的规则如下：

• AWLEN 和 AWSIZE 指定事务中写数据的字节数。 对于 AtomicCompare，字节数必须包括比较值和交换值。
• 如果 AWLEN 指示的事务长度大于 1，则 AWSIZE 必须是完整的数据通道宽度。
• 在 AWADDR 和 AWSIZE 指定的数据窗口之外的写 strobe必须被禁止。
• 数据窗口内的写 strobes必须被使能。

对于 AtomicStore、AtomicLoad 和 AtomicSwap

• 写数据为 1、2、4 或 8 字节，读数据分别为 1、2、4 或 8 字节。
• AWADDR 必须与总写数据大小对齐。
• AWBURST 必须为 INCR。

对于 AtomicCompare

• 写数据为 2、4、8、16 或 32 字节，读数据为 1、2、4、8 或 16 字节。
• AWADDR 必须与总写数据大小的一半对齐。
• 如果 AWADDR 指向事务的下半部分：
  • 首先发送比较值。比较值位于单次传输事务的低字节中，或位于多次传输事务的第一次传输中。
  • AWBURST 必须为 INCR。
• 如果 AWADDR 指向事务的上半部分：
  • 首先发送交换值。交换值位于单次传输事务的低字节中，或位于多次传输事务的第一次传输中。
  • AWBURST 必须为 WRAP。
• 对于 WRAP 类型的事务，通常规则有所放宽：
  • 允许长度为 1。
  • AWADDR 不需要与传输大小对齐。

具有 64 位数据通道的 AtomicCompare 事务示例如 图 A7.2 所示。

图 A7.2

A7.4.4 原子事务使用ID

一个单一的AXI ID用于原子事务。 相同的AXI ID用于请求、写响应和读数据。 这个要求意味着主机只能使用可以在AWID和RID信号上进行信号传递的ID值。

原子事务不能使用与同时存在的非原子事务所使用的AXI ID值。 这条规则适用于AR或AW通道上的事务。 这条规则确保了原子事务和非原子事务之间没有排序约束。

如果一个事务在另一个事务发出之前已完全完成，原子事务和非原子事务可以使用相同的AXI ID值。

同时存在的多个原子事务不能使用相同的AXI ID值。

对于使用读数据通道的原子事务，如果接口包括唯一ID信号，则如果AWIDUNQ被确认，则必须确认RIDUNQ。 有关更多细节，请参见 A6.2 唯一ID 。

A7.4.5 原子事务的请求属性限制

对于原子事务，请求属性适用以下限制：

• AWCACHE 和 AWDOMAIN 可以是接口类型有效的任何组合。请参见 表 A9.1 。
• AWSNOOP 必须设置为全零。如果 AWSNOOP 有其他值，则 AWATOP 必须全为零。
• AWLOCK 必须不被声明为独占访问。

A7.4.6 原子事务信号

为了支持原子事务，AWATOP 应该被添加到一个接口中。

表 A7.7 id信号

AWATOP的编码如 表 A7.8 和 表 A7.9 所示

表 A7.8 AWATOP编码

对于原子存储（AtomicStore）和原子加载（AtomicLoad）事务，AWATOP[3]表示原子操作所需的字节序：

• 当未断言时，此位表示操作为小端。
• 当断言时，此位表示操作为大端。

AWATOP[3]的值仅适用于算术操作，对于按位逻辑操作则被忽略。

对于原子存储（AtomicStore）和原子加载（AtomicLoad）事务， 表 A7.9 显示了低位AWATOP[2:0]信号上的操作编码。

表 A7.9 低位AWATOP[2:0]编码

A7.4.7 事务结构

对于AtomicLoad、AtomicSwap和AtomicCompare事务，事务结构如下：

• 请求在AW通道上发出。
• 相关的事务数据在W通道上发送。
• W通道上所需的写数据传输数量由AWLEN信号决定。
• 原子事务请求与原子事务写数据的相对时序未指定。
• 从机通过R通道返回原始数据值。
• 读取数据传输的数量由AWLEN和AWATOP信号决定。 对于AtomicCompare操作，如果AWLEN指示事务长度大于1，则读取数据传输的数量为AWLEN指定数量的一半。
• 允许从机在发送读取数据之前等待所有写数据。主机必须能够在未接收任何读取数据的情况下发送所有写数据。
• 允许从机在接受任何写数据之前发送所有读取数据。主机必须能够在未接受任何写数据的情况下接受所有读取数据。
• 在B通道上返回单个写响应。写响应必须由从机在接收到所有写数据传输并且原子事务的结果可观察后给出。

AtomicLoad、AtomicSwap和AtomicCompare事务涉及的传输如 图 A7.3 所示。

图 A7.3

对于AtomicStore事务，事务结构如下：

• 请求在AW通道上发出。
• 相关的事务数据在W通道上发送。
• W通道上所需的写数据传输次数由AWLEN信号决定。
• Atomic事务请求和Atomic事务写数据的相对时序未指定。
• 在B通道上返回单个写响应。写响应必须由从机在收到所有写数据传输并且观察到原子事务的结果之后给出。

涉及AtomicStore事务的传输如 图 A7.4 所示。

图 A7.4

A7.4.8 响应信号

写响应指示原子事务对所有必需的观察者可见。

包含读取响应的原子事务在接收到第一项读取数据时对所有必需的观察者可见。

主机被允许使用读取或写入响应作为事务对所有必需的观察者可见的指示。

与操作相关的错误概念是不存在的，例如溢出。一个操作对所有输入组合是完全指定的。

对于如原子比较等事务，当事务有多个结果时，不会提供事务结果的指示。 为了确定比较和交换指令是否已更新内存位置，必须检查作为事务一部分返回的原始数据值。

当事务达到不支持原子事务的组件时，可以对原子事务给出错误响应。

对于原子加载（AtomicLoad）、原子交换（AtomicSwap）和原子比较（AtomicCompare）事务：

• 从机必须发送正确数量的读取数据传输，即使写响应是DECERR或SLVERR。
• 主机可能会忽略写响应，仅使用随读取数据一起返回的响应。

A7.4.9 原子事务的依赖

对于AtomicLoad，AtomicSwap和AtomicCompare事务，图 A7.5 显示以下原子事务握手信号依赖关系：

• 主机在断言AWVALID或WVALID之前不应等待从机断言AWREADY或WREADY。
• 从机可以在断言AWREADY之前等待AWVALID或WVALID，或两者。
• 从机可以在AWVALID或WVALID，或者两者被断言之前断言AWREADY。
• 从机可以在断言WREADY之前等待AWVALID或WVALID，或两者。
• 从机可以在AWVALID或WVALID，或者两者被断言之前断言WREADY。
• 从机在断言BVALID之前必须等待AWVALID、AWREADY、WVALID和WREADY被断言。
• 从机还必须在断言BVALID之前等待WLAST被断言，因为写响应BRESP必须在写事务的最后一次数据传输后才发出信号。
• 从机在断言BVALID之前不应等待主机断言BREADY。
• 主机可以在断言BREADY之前等待BVALID。
• 主机可以在BVALID被断言之前断言BREADY。
• 从机必须在AWVALID和AWREADY都被断言之后才能断言RVALID，以指示有效数据可用。
• 从机在断言RVALID之前不应等待主机断言RREADY。
• 主机可以在断言RREADY之前等待RVALID被断言。
• 主机可以在RVALID被断言之前断言RREADY。
• 主机在断言WVALID之前不应等待从机断言RVALID。
• 从机可以在所有写数据传输之前等待WVALID被断言，然后再断言RVALID。
• 主机可以在RVALID被断言之前断言WVALID。

在 图 A7.5 所示的依赖性图中：

• 单头箭头指向可以在箭头起始信号之前或之后被断言的信号。
• 双头箭头指向必须在箭头起始信号被断言之后才能被断言的信号。

图 A7.5

A7.4.10 原子事务的支持

Atomic_Transactions属性用于指示一个组件是否支持原子事务。

表 A7.10 Atomic_Transactions属性

在某些实现中，这将是一个固定的接口属性，而其他实现可能支持在设计时设置该属性。

如果一个从机或互连组件声明它支持原子事务，那么它必须支持所有操作类型、大小和字节顺序。

主机支持

一个支持原子事务的主机组件还可以包括一个机制来抑制原子事务的生成，以确保在不支持原子事务的系统中的兼容性。
指定了一个可选的BROADCASTATOMIC引脚。当该存在并未被断言时，主机不会发出原子事务。

表 A7.11 BROADCASTATOMIC 绑定输入

从机支持

从机支持原子事务是可选的。
如果从机仅支持特定内存类型或特定地址区域的原子事务，则从机必须对其不支持的原子事务给出适当的错误响应。

互连支持

互连支持原子事务是可选的。

如果互连不支持原子事务，则所有连接的主机必须配置为不生成原子事务。

在支持原子事务的互连中的任何点都可以支持原子事务，包括将原子事务向下传递到从机。

并非每个地址位置都要求支持原子事务。如果给定地址位置不支持原子事务，则可以对此事务给出适当的错误响应。详见 A4.3 事务响应 。

对于设备事务，原子事务必须传递给端点从机。如果从机被配置为指示其不支持原子事务，则互连必须对此事务给出错误响应。 不得将原子事务传递给不支持原子事务的组件。

对于可缓存事务，互连可以选择：

• 在互连内执行原子操作。此方法要求互连执行适当的读取、写入和侦听事务以完成操作。
• 如果适当的端点从机被配置为指示其支持原子操作，则互连可以将原子操作传递给从属。

A第8章 请求操作码

请求操作码指示请求的功能以及从机如何处理该请求。 本章总结了所有可用的操作码，并在表中提供了链接，以详细描述它们的工作原理。它包含以下部分：

• A8.1 操作码信号
• A8.2 AWSNOOP编码
• A8.3 ARSNOOP编码

A8.1 操作码信号

请求操作码通过AWSNOOP和ARSNOOP信号进行传达。

表 A8.1 AxSNOOP信号

WriteNoSnoop、WriteUniquePtl、ReadNoSnoop 和 ReadOnce 是默认的操作码，用于通用请求AxSNOOP。

宽度属性在 表 A8.2 被定义。

表 A8.2 AxSNOOP位宽属性

如果以下任何属性不为 False，则 AWSNOOP_WIDTH 必须为 5：

• WriteDeferrable_Transaction
• UnstashTranslation_Transaction
• InvalidateHint_Transaction

如果以下任何属性不为 False，则 AWSNOOP_WIDTH 必须为 4 或 5：

• Shareable_Cache_Support
• WriteNoSnoopFull_Transaction
• CMO_On_Write
• WriteZero_Transaction
• Cache_Stash_Transactions
• Untranslated_Transactions
• Prefetch_Transaction

如果以下任何属性不为 False，则 ARSNOOP_WIDTH 必须为 4：

• Shareable_Cache_Support
• DeAllocation_Transactions
• CMO_On_Read
• DVM_Message_Support

任何未由接口驱动的 AxSNOOP 位都假定为 LOW。

仅发出 WriteNoSnoop/WriteUniquePtl/Atomic 请求的主机可以将 AWSNOOP_WIDTH 设置为 0， 从而从其接口中省略 AWSNOOP 输出。连接的从机必须将其 AWSNOOP 输入连接为 LOW。

仅发出 ReadNoSnoop/ReadOnce 请求的主机器可以将 ARSNOOP_WIDTH 设置为 0，从而从其接口中省略 ARSNOOP 输出。 连接的从机必须将其 ARSNOOP 输入连接为 LOW。

A8.2 AWSNOOP编码

AWSNOOP的编码如 表 A8.3 所示。 一些操作码取决于请求的域。Enable列列出了决定主机是否被允许使用操作码以及从机是否支持的属性表达式。

未列出的AWSNOOP和AWDOMAIN组合是非法的。

表 A8.3 AWSNOOP编码

A[8-1] ： NSH是不可共享的（0b00），SH是可共享的（0b01或0b10），SYS是系统（0b11）。

A8.3 ARSNOOP编码

ARSNOOP的编码如 表 A8.4 所示。 一些操作码取决于请求的域。Enable列列出了决定主机是否被允许使用该操作码，以及从机是否支持它的属性表达式。

未列出的ARSNOOP和ARDOMAIN组合是非法的。

表 A8.4 ARSNOOP编码

A[8-2] ： NSH是不可共享的（0b00），SH是可共享的（0b01或0b10），SYS是系统（0b11）。

A第9章 缓存

本章节描述了AXI协议中的缓存。 它包含以下部分：

• A9.1 缓存
• A9.2 缓存行大小
• A9.3 缓存一致性和域
• A9.4 IO一致性
• A9.5 可共享缓存行
• A9.6 预取事务
• A9.7 缓存存储
• A9.8 读取事务撤销分配
• A9.9 无效指示

A9.1 缓存

在本规范中，术语缓存用于任何存储结构，包括缓存、缓冲区或其他中间存储元素。 数据可以在系统的各个点进行缓存。 示例拓扑如 图 A9.1 所示。 在这个例子中，有一个系统缓存，所有代理都可以看到，本地可共享缓存所有一致代理都可以看到，以及本地不可共享缓存仅对单个代理可见。

完全一致的代理使用硬件一致性和数据监听来保持其缓存的一致性。 这些通常使用AMBA CHI接口 ^A[5] 。

I/O一致的代理可以与完全一致的代理共享数据，但任何在它们本地缓存的数据必须手动维护以确保一致性。

非一致性代理必须手动维护与其他代理共享并在本地缓存的任何数据。

图 A9.1

A9.2 缓存行大小

缓存行被定义为顺序字节地址内存位置的缓存副本，第一个地址与缓存行的总大小对齐。 采用缓存共享的系统必须具有相同的缓存行大小。 一些事务仅在整个缓存行上操作，必须是缓存行大小。

缓存行大小在设计时是固定的，并使用Cache_Line_Size属性定义。

表 A9.1 Cache_Line_Size属性

对于任何传输缓存行大小化事务的接口，数据宽度必须足够宽，以便使用16次传输或更少来传送一个缓存行。

为了与AMBA CHI兼容，缓存行大小必须为64字节。

事务必须为缓存行大小化和常规的操作码见 表 A9.2 。 有关常规事务的更多信息，请参见 A4.1.8 常规事务 。

表 A9.2 缓存必须大小化和常规的操作码

缓存行大小化，常规事务具有以下约束：

• Size x Length必须等于缓存行大小。
• Length可以是1、2、4、8或16。
• 如果Length大于1，Size必须等于数据通道宽度。
• 突发不得为FIXED。
• 如果突发为INCR，地址必须与缓存行大小对齐。
• 如果突发为WRAP，地址必须与Size对齐。
• 请求必须可修改，即AxCACHE[1]被断言。
• 请求不得为独占访问，即AxLOCK被取消断言。
• 具有写数据的事务必须在缓存行容器内断言所有字节strobes。

A9.3 缓存一致性和域

当多个主机共享数据时，这些主机的写入操作必须是一致的。 这意味着两个主机对同一地址位置的写入操作在所有参与主机中是可观察到的，并且顺序相同。

如果系统包含缓存，则必须采取措施确保缓存值不会过时。

在AMBA中，可以通过三种方式实现这一点：

• 使用非缓存事务。
• 通过手动缓存维护进行软件一致性。
• 通过侦听和自动缓存维护实现硬件一致性。

AXI通过为每个地址位置分配一个域来支持这些功能，这可以是系统（System）、不可共享（Non-shareable）或可共享（Shareable）。 必须对以下内容有一致的定义：

• 哪些地址位置属于每个域。
• 一个地址位置归属于哪个域。

A9.3.1 系统域

系统域中的地址位置必须对所有能够访问它们的主机者可见。 这是通过确保所有系统域请求都是不可缓存的，因此不会存储在任何本地缓存中来实现的。 使用系统域使一致性变得简单，但通常性能并不高。

对设备类型内存的请求需要使用系统域。

A9.3.2 非共享域

非共享域中的地址位置不需要对其他主机可见。 对非共享位置的事务无需触发硬件一致性机制以确保可见性。

如果非共享数据在主机之间共享，则必须发出称为缓存维护操作（CMO）的事务，以在读取数据之前清除和使数据在任何本地缓存中无效。 有关更多详细信息，请参见 A第10章 缓存维护 。

使用CMO进行数据共享称为软件一致性，如果主机之间的共享行为已知，这可以是一种有效的方法。 例如，如果有可预测的数据集由一个代理写入，然后由另一个代理读取。 这种方法的主要缺点是它依赖于软件的正确性。 软件中的一致性错误很容易出现，且难以调试。

为了避免一致性的丧失，在缓存非共享行时有一些规则：

• 不允许clean非共享数据的逐出和写回。这是为了避免clean行覆盖了由其他主机写入的下游缓存中的dirty行。
• 不允许在从一个缓存读取非共享行时将dirty数据传递到另一个缓存。该行必须作为clean行传递，写回该行的责任仍由下游缓存承担。 这避免了后续的写回操作覆盖来自其他主机的最新更新。

A9.3.3 可共享域

地址位于可共享域的位置必须对所有其他也将这些位置标记为可共享的主机可见。 具有可共享属性的请求必须侦听本地缓存并查询可能包含来自其他主机的可共享数据的缓存。

一个 AXI 组件可能需要支持可共享域的两个原因是：

• 实现 I/O 一致性。
• 支持可共享缓存行在上游和下游缓存之间的移动。

这些情况在 A9.4 IO一致性 和 A9.5 可共享缓存行 中进行了说明。

可共享域中的请求可以使用 INCR 或 WRAP 的突发类型，而不是 FIXED。

A9.3.4 域信号

域信号是可选的，如果接口没有域信号，则非缓存请求被认为在系统域内，而缓存请求被认为在非共享域内。

如果一个组件需要支持共享域，则必须包含域信号。

Shareable_Transactions 属性用于描述一个接口是否支持共享域，从而决定是否具有域信号。

表 A9.3 Shareable_Transactions属性

当Shareable_Transactions为真时，以下信号会包含在接口中。

表 A9.5 AxDOMAIN信号

Shareable_Transactions编码在AxDOMAIN信号中，如下所示

表 A9.5 AxDOMAIN编码

在该规范的早期版本中，AxDOMAIN 值 0b01 和 0b10 分别表示内共享和外共享。 在本版本中，建议使用 0b10 来表示共享域。

连接具有不同 Shareable_Transactions 值的主机和从属接口的指导见表 表 A9.6 。

A9.3.5 域一致性

地址位置可以标记为某一代理可共享而对另一代理不可共享。 为了避免一致性丧失，作为不可共享缓存的数据必须在被标记为可共享的代理访问之前通过CMO使其可见。

A9.3.6 域和内存类型

域和内存类型的组合决定了完成事务必须访问哪些缓存。

合法的内存类型和域的组合如 表 A9.7 所示。该表还指明了在处理请求时必须访问哪些缓存。

• （Peer）对等缓存是通过侦听请求访问的缓存，这需要像AMBA CHI这样的连贯协议。
• （Inline）内联缓存是请求在向内存进行时经过的缓存。

表 A9.7 内存类型和域的合法组合

Note：
正常的非缓存共享是被允许但不被期望的。一些实现可能不会在对非缓存访问时查看对等缓存。

A9.4 IO一致性

一个I/O一致性主机可以通过一致性互连在可共享域中读取和写入数据，但它不能被侦听，因此不能缓存可共享数据。 AXI不支持数据侦听，因此一致性互连通常基于AMBA CHI协议 ^A[5] ，并使用AXI接口连接I/O一致性主机。

图 A9.2

当 I/O 一致性主机发出可共享读请求时，一致性互连会通过观察适当的一致性缓存并检查其缓存中的可共享行来尝试找到数据。 如果找不到数据，则向内存发送请求。当数据返回时，不能由 I/O 一致性主机缓存，因为数据可能会变得过时。

当 I/O 一致性主机发出可共享写请求（WriteUniquePtl 或 WriteUniqueFull）时，一致性互连会向一致性缓存发出清除和失效请求，以确保没有本地副本。 然后将数据写入缓存或内存。对于部分缓存行写入，在一致性缓存中找到的任何dirty数据都可以与写入合并。 对于 I/O 一致性接口，Shareable_Cache_Support 属性必须为 False。

A9.5 可共享缓存行

一个基于AXI的缓存，可以在一个一致性的互连下游，选择存储可共享行以及不可共享缓存行。这具有以下优点：

• 可共享行的clean evictions可以被缓存，但必须不写回内存。
• 可共享行中的dirty数据可以被传递到上游的可共享缓存。

为此，需要额外的操作码和响应。如果缓存还存储不可共享域中的行，则缓存还必须跟踪哪些行是可共享的。 在这种情况下，一个有效的缓存行可以有四种状态：

• Clean
• Dirty
• Shareable-Clean
• Shareable-Dirty

关于哪些操作码可以命中哪些缓存行的规则如 表 A9.8 下所示。

星号（*）表示操作码的所有变体。

A[9-1] ：该行不再标记为可共享。
A[9-2] ：如果请求是 ReadShared，则可以在上游提供dirty数据。
A[9-3] ：如果 RME_Support 为 True，则必须命中。

A9.5.1 支持完整缓存行读写的操作码

以下操作码可以用于读取和写入完整的缓存行数据。使用这些操作码的事务必须是缓存行大小且为常规类型。对于写入事务，所有写入strobes信号必须被激活。

ReadClean

从可共享位置读取完整的缓存行，其中数据很可能分配在上游缓存中，读取的数据必须是clean的。

如果Shareable_Cache_Support和Shareable_Transactions 两个属性都为真，则可以使用此操作码。

ReadShared

从可共享位置读取完整的缓存行，其中数据很可能分配在上游缓存中 读取的数据可以是clean的或dirty。如果数据是dirty的，该行必须在上游分配， 并且所有读取数据的传输响应必须是OKAYDIRTY而不是OKAY。

如果Shareable_Cache_Support和Shareable_Transactions两个属性都为真，则可以使用此操作码。

WriteNoSnoopFull

对完整缓存行的非共享写入，其中数据为dirty并且未在上游分配。

当上游缓存驱逐一个非共享dirty缓存行或流式写入缓存行大小的数据时，可以发出WriteNoSnoopFull事务。 如果下游缓存收到WriteNoSnoopFull请求，它可以分配该行，知道该行未在上游分配。

如果WriteNoSnoopFull事务或Shareable_Cache_Support属性为真，则可以使用此操作码。

表 A9.9 WriteNoSnoopFull_Transaction 属性

WriteUniqueFull

一个可共享的完全缓存行的写入，其中数据是dirty的但未在上游分配。

该事务由I/O一致主机使用，以写入可能存储在一致性域内缓存中的缓存行。系统缓存可以将该行分配为可共享的dirty数据。

如果Shareable_Transactions属性为真，则可以使用此操作码。

WriteBackFull

当可共享的dirty缓存行从一致性缓存中驱逐时，可以使用WriteBackFull事务。 该事务使系统缓存能够将该行分配为可共享的dirty数据。

如果Shareable_Cache_Support和Shareable_Transactions属性均为真，则可以使用此操作码。

WriteEvictFull

当可共享的clean缓存行从一致性缓存中驱逐时，可以使用WriteEvictFull事务。该事务使系统缓存能够将该行分配为可共享的clean数据。

可共享的clean缓存行不得暴露给可共享域外的任何代理，因为该行可能在可共享域内的缓存中变得过时。 出于同样的原因，WriteEvictFull的数据显示不得更新内存。

如果Shareable_Cache_Support和Shareable_Transactions属性均为真，则可以使用此操作码。

A9.5.2 可共享内存支持的配置

Shareable_Cache_Support属性用于指示一个接口是否支持存储一致性缓存行所需的附加事务操作码。

表 A9.10 Shareable_Cache_Support 属性

根据Shareable_Cache_Support属性的值，显示了主机和从机之间的兼容性。

表 A9.11 Shareable_Cache_Support 兼容性

可共享请求也可以在重置时通过可选的主机输入信号BROADCASTSHAREABLE进行控制。

表 A9.13 BROADCASTSHAREABLE 信号

当BROADCASTSHAREABLE存在且未激活时，所有事务在发送之前都转换为非共享等效项，如图所示

表 A9.13 替代操作码

A9.6 预取事务

当一个主机有迹象表明可能需要某个地址的数据，但还不想承诺立即读取时，它可以向系统发送预取请求，以提前准备该位置进行读取。 这个请求可以导致数据分配到下游缓存或从片外内存中提取，随后主机才会发出实际的读取请求。

预取请求不需要与其他请求（如CMO）有顺序关系，因此不应使用预取来指示某一行可以被提取到受管或可见缓存中。

对读取请求的预取响应表明该事务命中了预取的数据。 主机可以将此作为启发式的一部分，以决定是否继续发出预取请求。

在AMBA CHI ^A[5] 中，预取请求的等价物是PrefetchTgt，可以与同一地址的连贯请求同时发出。 PrefetchTgt可以绕过任何连贯性检查，并使内存控制器预取数据，以防连贯请求在任何共享缓存中找不到该数据。 如果内存控制器使用AXI接口，则CHI PrefetchTgt请求可以转换为AXI预取请求。

A9.6.1 预取事务的规则

预取是一个无数据事务，其规则如下：

• 预取事务由AW通道上的请求和B通道上的单个响应传输组成，没有数据传输。
• 预取请求通过0b01111的AWSNOOP操作码进行信号传递。
• 预取请求必须是缓存行大小，并具有以下约束：
  • 该事务是常规的，详见 A4.1.8 常规事务 。
  • AWCACHE[1]被断言，即为正常事务。 – AWDOMAIN为Non-shareable或Shareable。
  • AWLOCK未被断言，不为独占访问。
• ID值必须在事务中唯一，这意味着：
  • 仅当没有使用相同AWID的未决写入事务时，才能发出预取请求。
  • 主机不得对与未决的预取请求具有相同AWID的写通道发出请求。
  • 如果接口上存在，预取事务必须确认AWIDUNQ。
• 主机可以选择是否在预取请求之后对同一地址发出非预取请求。
• 任一级的下级接口可以选择传播或响应预取请求。
• 允许以OKAY、DECERR、SLVERR或TRANSFAULT响应预取请求。无论下级是否对预取请求采取行动，均可发送OKAY响应。

Prefetch_Transaction 属性用于指示组件是否支持预取操作码，如 表 A9.14 所示。

表 A9.14 Prefetch_Transaction属性

A9.6.2 预取数据的响应

如果读取请求命中由于之前的预取请求而准备好的数据，从机可以返回预取响应。 这个响应可以被主机用来确定其预取请求的成功率。

预取响应有以下规则和建议：

• 预取响应使用RRESP编码0b100进行信号传递。
• 当Prefetch_Transaction为真时，RRESP_WIDTH必须为3，以便启用预取响应的信号传递。
• 预取表示读取的数据是有效的，并且来自于预取源。
• 预取可用于以下交易类型的响应：
  • ReadNoSnoop
  • ReadOnce
  • ReadClean
  • ReadShared
  • ReadOnceCleanInvalid
  • ReadOnceMakeInvalid
• 不能为独占读取发送预取响应。
• 建议在一个缓存行内使用预取响应进行所有数据传输或不进行数据传输。如果一个事务跨越多个缓存行，则每个访问的缓存行可以混合使用预取和其他响应。
• 只有在接口的Prefetch_Transaction属性为真时，才能发送预取响应。
• 即使主机没有向该位置发送预取请求，也可以向主机发送预取响应。例如，如果主机恰好读取了被另一个主机预取的数据。

A9.7 缓存存储

缓存存储使一个组件能够指示数据应放置在系统中的另一个缓存中。 这种技术可以确保数据靠近其使用点，从而潜在地提高整体系统的性能。 AXI协议支持带或不带存储目标ID的缓存存储请求。

缓存存储是一个提示。缓存或系统组件可以选择忽略请求的存储部分。

I/O一致的AXI主机可以请求数据存储在具有AMBA CHI接口 ^A[5] 的完全一致的主机中。

A9.7.1 暂存事务操作码

有四个 Opcodes 可用于暂存。

WriteUniquePtlStash

写入可共享位置，指示数据应分配到缓存中。可以写入缓存行中的任意数量的字节，包括所有字节或零字节。

WriteUniqueFullStash

将完整的缓存行数据写入可共享位置，指示数据应分配到缓存中。事务必须是缓存行大小且为常规事务。所有写入信号必须被断言。

StashOnceShared

一种无数据事务，指示应将缓存行提取到特定缓存中。其他行的副本不需要失效。

StashOnceUnique

一种无数据事务，指示应将缓存行提取到特定缓存中。建议失效所有其他副本。

StashOnceUnique 事务可能导致缓存行的缓存副本失效，必须注意确保此类事务不会干扰独占访问序列。

对于支持未转换事务特性的接口，还支持额外的存储事务。 StashTranslation 事务用于向系统内存管理单元（SMMU）指示应为随 StashTranslation 事务提供的地址获取转换。 请参见 A14.7 暂存转换操作码

A9.7.2 暂存信号

暂存请求在写请求通道上发送，并在写响应通道上有单一的响应传输。 与暂存事务一起写入的内容也包括写入数据。

暂存请求在域、大小和长度上有约束，如 表 A9.15 所示。缓存暂存事务不允许跨越缓存行边界。

表 A9.15 暂存请求的域、大小、长度约束

以下约束也适用于所有暂存请求操作码：

• AWCACHE[1] 为0b1：可修改
• AWLOCK为0b0：非独占访问
• AWTAGOP为0b00：无效的
• AWATOP0b00000：非原子操作

A9.7.3 暂存请求域

暂存请求的域决定了将检查哪些缓存以获取缓存行以及如何获取和存储该行。

对可共享位置的暂存请求意味着该行可以存储在对等缓存或内联缓存中。 如果暂存请求导致缓存发出下游请求，则如果可能的话应该是可共享的。对存储的写入必须始终指向可共享位置。

对非共享位置的暂存请求意味着该行可以存储在内联缓存中。 如果暂存请求导致缓存发出下游请求，则必须是非共享的。 StashOnceShared 和 StashOnceUnique 操作码可以是可共享或非共享位置。

A9.7.4 暂存目标ID

一个暂存请求可以选择性地包含目标ID，以指示首选用于暂存数据的特定缓存。 该规格未定义该识别机制的具体细节。预计执行暂存操作的任何代理都知道用于特定暂存事务的ID。 该规格定义了两个识别级别：

• 节点 ID 用于识别缓存存储应发送到的物理接口。
• 逻辑处理器 ID 用于识别与该物理接口相关的功能单元。

例如，暂存事务可以指定一个处理器集群接口和该集群内的具体缓存。

用于指示存储目标的信号如 表 A9.16 所示。

表 A9.16 表明暂存目标的信号

节点ID和逻辑处理器ID信号在接口上是可选的，分别通过STASHNID_Present和STASHLPID_Present属性进行控制。

表 A9.17 STASHNID_Present 属性

表 A9.18

每个暂存目标ID都有一个使能信号，因此 NID 和 LPID 可以独立控制：

• 对于暂存事务，允许任何目标使能的组合。
• 对于非暂存事务，AWSTASHLPIDEN 和 AWSTASHNIDEN 必须为低。
• 当 AWSTASHNIDEN 为低时，AWSTASHNID 为无效且必须为零。
• 当 AWSTASHLPIDEN 为低时，AWSTASHLPID 为无效且必须为零。
• 发送一个指示不支持缓存暂存的暂存目标的暂存事务是被允许的，但不推荐。

对于无目标的 WriteUniquePtlStash 和 WriteUniqueFullStash 请求，建议如下：

• 如果互连可以确定在写入发生之前该行被单个缓存持有，则将缓存行暂存到该缓存。
• 如果在写入发生之前，该缓存行不被任何缓存持有，则将在共享系统缓存中暂存该缓存行。

对于无目标的 StashOnceShared 和 StashOnceUnique 请求：

• 如果互连可以确定缓存行不在任何缓存中，则建议在共享系统缓存中暂存该缓存行。
• 组件可以使用此功能将缓存行预取到下游缓存以供其自己使用。

A9.7.5 暂存事务的id

对于WriteUniquePtlStash和WriteUniqueFullStash事务，不存在对AXI ID值的使用限制。

StashOnceShared和StashOnceUnique可以称为StashOnce事务。 StashOnce事务不得使用与同时存在的非StashOnce事务相同的AXI ID值。 这条规则确保了StashOnce事务与其他事务之间不存在排序约束。 因此，丢弃StashOnce请求的组件可以在不检查ID排序要求的情况下立即响应。

允许StashOnce事务和非StashOnce事务使用相同的AXI ID值，前提是同一个ID值不能同时被StashOnce事务和非StashOnce事务使用。

可以有多个具有相同ID的未完成StashOnce事务。

可以有多个具有相同ID的未完成非StashOnce事务。

为StashOnce事务使用唯一的ID值确保在不支持这些事务时可以给出立即响应。

A9.7.6 暂存事务的支持

Cache_Stash_Transactions 属性用于指示接口是否支持缓存暂存，如 表 A9.19 所示。

表 A9.19 Cache_Stash_Transactions 属性

表 A9.20 Cache_Stash_Transactions 兼容性

如果主机向不支持的目标发出暂存请求，则可以在主机或互联上采取行动，如图 表 A9.21 所示。

表 A9.21

A9.8 读取事务撤销分配

读取事务去分配可以用于当某个主机需要的数据不太可能被其他主机再次使用时。 缓存可以将此作为提示以驱逐该行并为其他数据提供资源。

DeAllocation_Transactions属性用于指示组成部分是否支持事务去分配，如 表 A9.22 所示。

发出事务去分配的组件与不支持它们的组件之间的互操作性可以通过将操作码转换为ReadOnce来实现。

表 A9.22 DeAllocation_Transactions属性

A9.8.1 读取事务撤销分配配操作码

本规范定义了读取请求通道上的两种接触事务分配操作码：

ReadOnceCleanInvalid (ROCI)

该请求读取缓存行当前值的快照。建议，但不要求，任何缓存的缓存行副本被去分配。 如果存在缓存行的dirty拷贝，并且缓存行被接触分配，则该dirty拷贝必须写回主内存。

ReadOnceCleanInvalid 的信号使用 ARSNOOP 值为 0b0100。

ReadOnceMakeInvalid (ROMI)

该请求读取缓存行当前值的快照。建议，但不要求，任何缓存的缓存行副本被接触分配。 允许，但不要求，丢弃缓存行的dirty拷贝。缓存行的dirty拷贝不需要写回主内存。

ReadOnceMakeInvalid 的信号使用 ARSNOOP 值为 0b0101。

A9.8.2 读取事务撤销分配的规则和建议

去分配事务只能同时访问一个缓存行，并且不允许跨越缓存行边界。 大小必须是缓存行大小或更小。

对缓存行某部分的ROMI请求可能导致整个缓存行失效。 一些实现可能不支持小于缓存行的事务去分配行为，而是将此类事务转换为ReadOnce。

ROCI和ROMI仅支持共享域，因此如果DeAllocation_Transactions为True，则Shareable_Transactions属性必须为True。

对于ROMI事务，要求在返回事务的第一个读取数据项之前，必须确认缓存行的失效。 在这一点上，不要求缓存行的失效已完成。 然而，必须确保从此时开始的任何后续写事务不会被此事务使其失效。

以下考虑适用于去分配事务的使用：

• 在去分配事务被发往其他代理正用于独占访问的同一缓存行时需要谨慎。这是因为去分配可能导致独占序列失败。
• 除了与独占访问的交互，ROCI事务仅提供去分配缓存行的提示，对系统的正确性没有其他影响。
• 使用ROMI事务可能会导致dirty缓存行的丢失。此事务的使用必须严格限制在已知安全的情况下。
• 去分配事务不保证缓存行将被清除或失效，因此不能用于确保数据对所有观察者可见。

A9.9 无效指示

InvalidateHint事务是一种无数据的去分配提示。 当一个主机完成对一个数据集的处理，并且该数据可能在下游缓存中分配时，可以使用InvalidateHint请求。 InvalidateHint请求通知缓存，该行不再需要，可以被作废。允许但不要求对该行进行写回。

对于功能正确性，InvalidateHint并不是必需的。因此可以在系统中的任何时刻通过响应BRESP的OKAY来终止。

使用InvalidateHint事务时需要小心，以避免暴露先前被覆盖的值。这可以通过以下方式实现：

• 确保在擦洗写入后执行的干净操作可以确保写入已经传播到足够远的地方，以至于不会被Invalidate Hint事务删除。
• 确保InvalidateHint事务的使用限制在不包含敏感信息的地址范围内。

A9.9.1 无效指示信号

InvalidateHint是一种使用AW和B通道的数据无关事务。
以下约束适用于InvalidateHint请求：

• AWSNOOP为0b10010。
  • 如果InvalidateHint_Transaction属性为True，则AWSNOOP必须为5b宽。
• AWDOMAIN可以是非共享的或共享的。
• AWBURST为INCR。
• AWSIZE和AWLEN必须是缓存行大小且为常规。
• AWCACHE为普通可缓存。
• AWID是传输中唯一的，这意味着：
  • 仅在写通道上没有使用相同ID值的未完成事务时，才能发出InvalidateHint请求。
  • 主机不得在写通道上发出与未完成的InvalidateHint事务相同ID的请求。
• 如果存在，AWIDUNQ必须在InvalidateHint请求中被断言。
• AWLOCK被解除断言，这不是独占访问。
• AWTAGOP为无效。
• AWATOP为非原子操作。

A9.9.2 无效指示支持

InvalidateHint_Transaction 属性用于指示接口是否支持 InvalidateHint 事务，如 表 A9.23 所示。

表 A9.23 InvalidateHint_Transaction属性

根据InvalidateHint_Transaction属性的值，主机和从机之间的兼容性如 表 A9.24 所示。

表 A9.24

A第10章 缓存维护

本章描述了软件缓存管理辅助下的缓存维护操作（CMOs）。它包含以下几个部分：

• A10.1 CMO
• A10.2 CMO动作
• A10.3 CMO请求属性
• A10.4 CMO传播
• A10.5 写通道的CMOs
• A10.6 cmo写
• A10.7 读通道的CMOs
• A10.8 CMOs持续
• A10.9 缓存维护和领域管理扩展
• A10.10 处理器缓存维护指令

A10.1 CMO

缓存维护操作是指示缓存清理和使缓存行失效的请求。 与分配和去分配提示不同，缓存必须执行针对其缓存行的缓存维护操作。

缓存维护操作可以通过读取或写入通道传输。

为了支持遗留组件，本规范将缓存维护操作通过读取通道传输纳入规定。 建议新设计通过写入通道传输缓存维护操作。

该规范支持以下缓存维护操作：

CleanShared(CS)

完成后，所有缓存的目标行副本被清理，并且任何相关的写入都可观察。

CleanSharedPersist(CSP)

完成后，所有缓存的目标行副本被清理，并且任何相关的写入都可观察并且已达到持久性点 (PoP)。 参见 A10.8CMOSs持续 。

CleanSharedDeepPersist(CSDP)

完成后，所有缓存的目标行副本被清理，并且任何相关的写入都可观察并且已达到深度持久性点 (PoDP)。 参见 A10.8CMOSs持续 。

CleanInvalid (CI)

完成后，所有缓存的目标行副本被失效，如果它们是dirty的，则已写入内存。任何相关的写入都可观察。

CleanInvalidPoPA (CIPA)

完成后，所有缓存的目标行副本被失效，并且任何dirty的缓存副本在物理别名点 (PoPA) 之前被写入。参见 A10.9 缓存维护和领域扩展 。

MakeInvalid (MI)

完成后，所有缓存的目标行副本被失效，并且任何dirty的缓存副本可能已被丢弃。

A10.2 CMO动作

当一个组件接收到CMO时，它必须执行以下操作：

1. 如果该组件是一个缓存并且CMO是可缓存的，则必须查找该行。
2. 如果该组件是一个一致性互连并且CMO是可共享的，则必须向任何可能拥有该行的缓存发送CMO监视：
   • 对于无效CMO，Allocated。
   • 对于清除CMO，Dirty。
     注意，需要使用像AMBA CHI这样的连贯协议来发送CMO监视请求。
3. 对于清除CMO，写回在缓存或对等缓存中发现的任何dirty数据。
   建议对将跟随到同一行CMO内存的写入使用写穿透无分配。这确保该行将在任何下游缓存中被查找，但不会被分配。
4. 等待所有监视和相关写操作收到响应。
5. 如果CMO不需要传送到下游，组件可以对CMO发出响应。
6. 如果CMO确实需要传送到下游，则必须发送CMO，并且必须在从下游接收到时传播返回的响应。

A10.3 CMO请求属性

以下规则适用于CMO事务：

• 请求必须是缓存行大小且为常规。有关更多细节，请参见 A4.1.8 常规事务
• 域可以是不可共享或可共享。
  • 不允许使用系统域，这意味着CMO事务必须为正常而不是设备。

AxCACHE和AxDOMAIN属性指示哪些缓存必须对CMO进行操作，如表所示。

A10.1 CMO 适用性

为了保持一致性，以下建议适用于CMO和非CMO：

• 如果一个位置对于非CMO事务是可缓存的，它应该对于CMO事务也是可缓存的。
• 如果一个位置在非CMO事务的可共享域内，它应该在CMO事务的可共享域内。
• 如果一个位置在非CMO事务的不可共享域内，它可以在CMO事务的不可共享域或可共享域内。
• 主机不应发出允许其分配行的读取请求，同时该行有未解决的CMO。
• 分配提示，如AxCACHE[3:2]，并不要求在CMO和非CMO事务对同一缓存行时匹配。

A10.4 CMO传播

CMO在组件下游的传播依赖于系统拓扑。如果CMO是可缓存的，并且下游有一个可能已分配该行的缓存，并且该缓存下游还有一个观察者，则必须将CMO向下传播。 为控制CMO是否从主机接口传播定义了两种机制。

• 在设计时，使用属性CMO_On_Write或CMO_On_Read。
• 在运行时，使用可选的BROADCASTCACHEMAINT和BROADCASTSHAREABLE连接输入到主机接口。

表 A10.2 BROADCASTCACHEMAINT信号

当BROADCASTCACHEMAINT和BROADCASTSHAREABLE同时存在且未激活时：

• 不会发出CleanShared、CleanInvalid和MakeInvalid请求。
• WritePtlCMO被转换为WriteNoSnoop。
• WriteFullCMO被转换为WriteNoSnoop或WriteNoSnoopFul。

A10.5 写通道的CMOs

CMO_On_Write 属性用于指示接口是否支持写通道上的 CMO。

表 A10.3 CMO_On_Write 属性

在正确的通道上，CMO可以作为独立操作发送，也可以与数据写入结合。 用于在AW通道上信号CMO请求的AWSNOOP编码如 表 A10.4 所示。 有关CMO操作的组合写入的更多信息，请参见 A10.6 CMO写

表 A10.4 AWSNOOP编码

AWCMO信号指示请求的CMO类型，当CMO_On_Write为真时，它出现在AW通道上。

表 A10.5AWCMO信号

AWCMO的宽度由属性AWCMO_WIDTH决定。

表 A10.6

AWCMO_WIDTH的规则如下：

• 如果CMO_On_Write为False，则必须为0。这意味着AWCMO不在接口上。
• 如果CMO_On_Write为True且RME_Support为False，则必须为2。
• 如果CMO_On_Write为True且RME_Support为True，则必须为3。

AWCMO的编码如 表 A10.7 所示。 如果关联的使能属性为False，则无法使用该编码。

表 A10.7 AWCMO编码

请注意，MakeInvalid 不支持写通道。

当 AWSNOOP 不是 CMO、WritePtlCMO 或 WriteFullCMO 时，AWCMO 必须为 0b000。

写通道上的 CMO 事务由 AW 通道上的请求和 B 通道上的响应组成。在 CMO 事务中，W 通道没有传输。

对 CMOs CleanInvalid 和 CleanShared 的写响应在 B 通道上包含单个响应传输。 这表示在指定域内所有缓存均为 Clean 和/或无效，任何相关写入都是可观察的。

Persist CMOs 描述在 A10.8 CMOs持续 中， POPA CMO 描述在 A10.9 缓存维护和领域管理扩展 中。

A10.6 CMO写

缓存维护操作通常与写入内存一起使用。例如：

• 从I/O代理的写入，必须对下游缓存的观察者可见。
• 写入持久内存，必须确保所有缓存行的副本都被清理到持久性的程度。
• 导致dirty数据写回的CMO，必须跟随CMO。

带有CMO的写入将写入与CMO相结合，以提高此类场景的效率。可以预见一些主机将原生生成带有CMO的写入。 在其他情况下，缓存或互连将在向下游传播之前将CMO与写入结合。

Write_Plus_CMO属性用于指示组件是否支持写入通道上的写入和CMO组合。

表 A10.8 Write_Plus_CMO属性

如果 Write_Plus_CMO 属性为真，则 CMO_On_Write 属性也必须为真。

当 Write_Plus_CMO 为真时，可以使用 WritePtlCMO 和 WriteFullCMO 操作码来指示带有 CMO 的写入。

带有 CMO 的写入可以使用 AWCMO 指示的任何 CMO 类型。

一些带有 CMO 的写入示例用法如 表 A7.10 所示。

表 A10.9 CMO写事务的例子

A10.6.1 CMO写的属性

具有CMO的写操作具有以下属性约束：

• AWSNOOP为0b1010表示WritePtlCMO，0b1011表示WriteFullCMO。
• AWDOMAIN为非共享或共享。
• AWCACHE[1]被断言时，事务必须是可修改的。
• AWLOCK未断言，不是独占访问。

WriteFullCMO必须是缓存行大小且为常规，见 A4.1.8 常规事务

WritePtlCMO必须是缓存行大小或更小，并且不得跨越缓存行边界。相关的CMO适用于所寻址缓存行的整个内容，AWBURST不得为FIXED。

带有CMO的写操作的缓存维护部分始终被视为可缓存和共享，无论AWCACHE和AWDOMAIN如何。

A10.6.2 CMO写的传播

CMO写的传播遵循与CMO传播相同的规则。可以将带有CMO的写入分成单独的写入和CMO事务以进行下游传播。在这种情况下，或者：

• 写入首先发出，随后在与写入相同ID的写请求通道上发出CMO。
• 写入首先发出。当收到写入响应时，可以在写入或读取通道上发出CMO。

在拆分写入和CMO时，如果AWDOMAIN是可共享的，那么：

• WritePtlCMO变为WriteUniquePtl。
• WriteFullCMO变为WriteUniqueFull。

如果AWDOMAIN是非共享的，那么写入变为WriteNoSnoop或WriteNoSnoopFull。

CMO作为可缓存的发送。如果在可共享域中存在下游缓存，则CMO作为可共享的发送。

如果没有需要通过缓存维护管理的下游缓存，则事务的CMO部分可以被丢弃。 如果丢弃的CMO是CleanSharedPersist或CleanSharedDeepPersist， 则在写入响应上必须设置BCOMP和BPERSIST信号。 有关更多详细信息，请参见 A10.8 CMOs持续 。

A10.6.3 CMOs写响应

对带有CMO的写入的响应遵循与写通道上的CMO相同的规则。

带有CI或CS的写入有一个响应传输，表明写入和CMO都是可观察的 。

带有CSP或CSDP的写入有一个响应，表明写入是可观察的，还有一个响应表明写入已到达PoP / PoDP 。

与独立的CSP/CSDP一样，从机可以选择将两个响应合并为一个传输。

带有CMO的写入不允许使用MTE匹配操作码，因此与Persist和Match响应结合的写入响应不是必需的。
有关更多详细信息，请参见 A13.2 内存标签扩展

A10.6.4 cmo加写的实例流程

作为使用CMO写操作的流程示例，图 A10.1 展示了一个I/O一致性主机在AW通道上向CHI互连发出一个可共享的CleanShared请求。

• 由一致性互连生成的侦听表示一致性缓存中的dirty数据。
• 然后，互连发出一个Non-shareable WriteFullCMO和CleanShared。
• 系统缓存查找该行，覆盖任何现有的副本，并将写请求转发给内存。内存不需要接收CMO，因为其数据对所有代理都是可观察的。
• 当数据可观察时，内存控制器返回一个OKAY响应，该响应被传播回主机。

图 A10.1

A10.7 读通道的CMOs