AXI（Advanced eXtensible Interface） 学习笔记

1. 概述

AXI 协议支持高性能、高频系统设计，用于主设备（Manager）和从设备（Subordinate）之间的通信。

1.1 AXI 协议的特点

• 适用于高带宽、低延迟设计。
• 无需使用复杂的桥接电路即可实现高频运行。
• 该协议满足各类组件的接口需求。
• 适用于初始访问延迟较高的内存控制器。
• 为互连架构的实现提供灵活性。
• 与 AHB 和 APB 接口向后兼容。

1.2 AXI 协议的核心特性

• 地址 / 控制阶段与数据阶段分离。
• 支持通过字节选通信号实现非对齐数据传输。
• 采用基于突发的事务处理方式，仅需发送起始地址。
• 读写数据通道分离，可提供低成本的直接内存访问（DMA）。
• 支持发送多个未完成的地址。
• 支持乱序事务完成。
• 便于添加寄存器级以实现时序收敛。

1.3 专业术语

• Manager and Subordinate：在 AXI 协议中，Manager 通常指发起事务的主设备（如 CPU、DMA 控制器），Subordinate 指响应事务的从设备（如内存、外设）。
• Burst-based transactions：突发传输，指一次性传输连续地址的多个数据，只需指定起始地址和传输长度，可显著提升传输效率。
• Outstanding addresses：未完成地址，指主设备在收到前一个事务的响应前，可继续发送新的地址，支持并行处理以提高带宽利用率。
• Out-of-order transaction completion：乱序事务完成，允许从设备按非请求顺序返回结果，适用于多通道并行处理场景。
• Timing closure：时序收敛，指设计满足所有时序要求（如建立时间、保持时间），是芯片设计中确保电路在目标频率下稳定工作的关键步骤。

2. AXI架构

AXI协议基于事务（transactions），并定义了5个独立的通道（channels）：

• 写请求（Write request），其信号名称以AW开头。
• 写数据（Write data），其信号名称以W开头。
• 写响应（Write response），其信号名称以B开头。
• 读请求（Read request），其信号名称以AR开头。
• 读数据（Read data），其信号名称以R开头。

请求通道（request channel）承载描述待传输数据性质的控制信息。这一过程被称为请求（request）。

数据在主设备（Manager）和从设备（Subordinate）之间通过以下方式传输：

• 写数据通道（write data channel），用于将数据从主设备传输到从设备。在写事务（write transaction）中，从设备使用写响应通道（write response channel）向主设备发信号（signal）表明传输完成 。
• 读数据通道（read data channel），用于将数据从从设备传输到主设备。

AXI协议具备以下特点：

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

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

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

2.1 通道定义

五个独立通道中的每个通道都包含一组信息信号，以及提供双向握手机制的VALID信号和READY信号。

信息源通过VALID信号表明通道上何时有有效的地址、数据或控制信息。目标端通过READY信号表明何时可以接收信息。

读数据通道和写数据通道均包含LAST信号，用于指示事务中最后一个数据项的传输。

2.1.1 写请求和读请求通道

写请求通道和读请求通道是分离的。相应的请求通道承载事务所需的所有地址和控制信息。

2.1.2 写数据通道

写数据通道承载从主设备（Manager）到从设备（Subordinate）的写数据，包括：

• 数据信号WDATA，其位宽可为8、16、32、64、128、256、512或1024位。位宽通过DATA_WIDTH属性指定。
• 每8位数据对应一个字节通道选通信号，用于指示数据中哪些字节是有效的。

写数据通道的信息始终被视为缓冲式的，因此主设备无需等待从设备对先前写事务的确认，即可执行写事务。

1
2
3
4
5
6
7
8
9
10

在 WVALID/WREADY 握手成功的那个时钟周期里，并不要求从设备（Subordinate）已经把数据真正写进目标存储体；
• 协议只要求：数据已经被某处“接住”──可能是从设备内部的 FIFO，也可能是总线互联里的缓冲区；
• 因而握手的语义是 “数据已被缓存接受 (buffered-accept)”，而不是 “写操作已完成 (write-commit)”。
AXI 把写传输拆成三个独立通道：AW(地址)-W(数据)-B(响应)。
• 如果必须等 B 响应返回以后才能发下一笔写，就失去了流水线优势。
• 将 W 通道定义为“缓冲型”后，只要 WVALID 与 WREADY 握手成功，Manager就可以立即继续发下一笔 AW/W，而不用等待上一笔写的 B 响应；B 响应可以在之后任意时刻回来。
• 这样可以同时悬挂多笔写事务（outstanding writes），显著提高带宽利用率。
Subordinate 或互联系统必须具备足够的缓冲能力。既然向 Manager 声明自己 “READY”，就要能暂存对应的写数据，直到真正写入目标。
• Manager 只能以 B 响应来判定这笔写是否最终完成；不能以 WREADY 来做此判断。
• 协议允许同一 ID 具有多达 AWLEN+1 个写突发 (burst) 在飞，但在实现里往往还会再加一个“最大 outstanding 数量”的硬件/软件限制。

2.1.3 写响应通道

从设备（Subordinate）通过写响应通道对写事务做出响应。所有写事务都要求在写响应通道上发送完成信号。

如图A1.1所示，完成信号仅针对完整事务发出，而非事务中的每个数据传输。

2.1.4 读数据通道

读数据通道承载从从设备（Subordinate）到主设备（Manager）的读数据和读响应信息，包括：

• 数据信号RDATA，其位宽可为8、16、32、64、128、256、512或1024位。位宽通过DATA_WIDTH属性指定。
• 读响应信号，用于指示读事务的完成状态。

关键术语说明（结合ASIC语境）：

• VALID/READY handshake：AXI协议中核心的握手机制，确保数据传输的可靠性——只有当VALID和READY信号同时有效时，数据才被视为成功传输。
• LAST signal：在突发传输（burst transfer）中标记最后一个数据项，帮助接收端判断事务是否结束，常见于连续多数据块传输场景。
• Byte lane strobe：字节选通信号（如WSTRB），在非对齐数据传输中指定有效字节，避免无效数据覆盖，是AXI支持灵活数据传输的重要机制。
• DATA_WIDTH：决定数据通道的位宽，需根据系统带宽需求配置，不同位宽（如32bit、64bit）直接影响传输效率。

2.2 接口与互连

经典系统由若干主设备（Manager）和从设备（Subordinate）构成，这些设备通过某种形式的互连（interconnect）连接在一起，如图 A1.3 所示 。

AXI 协议针对以下各类接口，提供统一的接口定义：

• 主设备与互连（interconnect）之间的接口
• 从设备与互连（interconnect）之间的接口
• 主设备与从设备之间的接口
  该接口定义支持多种不同的互连实现方式 。
  设备之间的互连，等效于具备对称主设备端口（Manager ports）和从设备端口（Subordinate ports）的另一设备，实际的主设备和从设备可与之连接 。

2.2.1 典型系统拓扑结构

多数系统采用以下三种互连拓扑结构之一：

• 共享请求通道和数据通道（Shared request and data channels ）
• 共享请求通道及多个数据通道（Shared request channel and multiple data channels ）
• 多层结构，含多个请求通道和数据通道（Multilayer, with multiple request and data channels ）

在多数系统中，请求通道（request channel）的带宽需求显著低于数据通道（data channel）的带宽需求。这类系统可通过采用共享请求通道搭配多个数据通道的方式，在实现并行数据传输（parallel data transfers）的同时，在系统性能（system performance）与互连复杂度（interconnect complexity）之间达成良好平衡 。

2.3 寄存器分段（Register slices）

AXI 协议的每个通道仅支持单向信息传输，且架构不强制通道间存在固定时序关联。这一特性让开发者几乎能在任意通道的任意位置插入寄存器分段，代价是增加一个时钟周期的延迟。
这种设计灵活性可实现：

• 延迟与工作频率的权衡

  • 若系统追求高频运行，可通过寄存器分段拆分长时序路径，减少单周期内的逻辑延迟，提升时钟频率；若更看重低延迟，可减少分段数量。需根据需求在二者间平衡。

• 差异化路径优化

  • 处理器与高性能内存（如 L1 缓存）这类对延迟敏感的路径，可直接连接不加分段，保障数据传输极速响应；
  • 外设（如 UART、GPIO 等）这类对延迟不敏感的路径，用寄存器分段隔离长路径，避免拖慢系统整体频率，同时简化时序约束。

1
2
3
4
5
6
7
8
9
10
11
12

AW、AR、W、R、B 这五条通道都是单向传输：有效信号从发起端到接收端只走一个方向，READY 信号则走回头路。
• 因为是单向的，所以一条通道上只有一组 VALID/READY 握手，不会出现两组信息互相冲突的情况。
• 结果：把通道打断、在中间插一个寄存器并不会改变握手关系和时序语义——寄存器照搬 VALID/READY 即可
AXI 把地址、数据、响应拆成独立通道，并且它们之间没有“必须同时到达”或“必须按某相对时序对齐”之类的硬性约束。
• 因此，你可以只给某一条通道加寄存器，而不必同步修改其它通道。握手会自动把通道内部的延迟吸收掉。
只要你觉得线路太长、时序吃紧，就能在那段连线处插入一个寄存器切片。
• 唯一代价是：从这一级开始，后面的数据/地址/响应都比原来慢一个时钟周期（latency +1）。
• 典型做法：把一根很长或跨时钟区域的网线砍成两段，各自加寄存器后，时钟到达时间 (Tclk-q + Tpd + Tsetup) 变短，允许设计跑到更高频率。
• 换句话说，用“多一个 pipeline stage”换取“更高的 Fmax”。
• 性能最敏感的路径（如 CPU ↔ DDR 控制器）可以保持直连，少插或不插寄存器，保证最低延迟。
• 对延迟不敏感、布线又长的路径（如 GPIO、UART、SPI 等外围）就在距离较远的互联上多插几级寄存器，让这部分走线不拖累整体时钟。
• 这样既兼顾了高性能部件的响应时间，又让整个芯片的物理布局、时序收敛更容易。

2.4 术语

以下术语描述AXI组件：

• 组件（Component）
• 主设备组件（Manager Component）
• 从设备组件（Subordinate Component），包括内存从设备组件（Memory Subordinate component）和外设从设备组件（Peripheral Subordinate component）
• 互连组件（Interconnect Component）

对于特定的AXI事务，“上游（Upstream）”和“下游（Downstream）”指AXI拓扑中AXI组件的相对位置。

AXI传输（AXI transfer）是在AXI通道上一个周期内的通信。
AXI事务（AXI transaction）是AXI主设备与AXI从设备进行通信所需的一系列传输操作。例如，读事务包含一个请求传输和一个或多个读数据传输。

AXI规范中使用“适时（in a timely manner ）”这一表述 。

3 信号列表

本章列出本规范中描述的所有信号。部分通道和信号为可选，因此并非在每个接口中都存在。

奇偶校验信号未包含在本章。

信号根据以下章节所述的通道和类别进行分组：

• 写通道（Write channels）
• 读通道（Read channels）
• 监听通道（Snoop channels）
• 接口级信号（Interface level signals）

3.1 写通道（Write channels）

写通道用于传输写事务（write transactions）及某些无数据事务（data-less transactions）的请求、数据和响应。

3.1.1 写请求通道（Write request channel）

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

3.1.2 写数据通道（Write data channel）

写数据通道承载从Manager到Subordinate的写数据及控制信息。该通道上的信号均以W为前缀。

3.1.3 写响应通道（Write response channel）

写响应通道承载Subordinate针对使用写数据通道的事务向Manager发送的响应。该通道上的信号均以B为前缀。

3.2 读通道（Read channels）

读通道用于传输读事务、缓存维护操作（cache maintenance operations）以及DVM完成消息（DVM Complete messages）的请求、数据和响应。

3.2.1 读请求通道（Read request channel）

读请求通道承载使用读通道的事务所需的所有地址和控制信息。该通道上的信号均以AR为前缀。

3.2.2 读数据通道（Read data channel）

读数据通道承载从Subordinate到Manager的读数据及响应。该通道上的信号均以R为前缀。

3.3 监听通道（Snoop channels）

在本规范中，监听通道仅用于传输DVM（Distributed Virtual Memory, 分布式虚拟内存）消息。

3.3.1 监听请求通道（Snoop request channel）

监听请求通道承载DVM消息请求的地址和控制信息。该通道上的信号均以AC为前缀。

3.3.2 监听响应通道（Snoop response channel）

监听响应通道承载对DVM消息的响应。该通道上的信号均以CR为前缀。

3.4 接口级信号（Interface level signals）

接口级信号为非通道信号。每个接口最多可包含一组此类信号。

3.4.1 时钟和复位信号（Clock and reset signals）

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

3.4.2 唤醒信号（Wakeup signals）

唤醒信号用于指示接口存在相关活动。

3.4.3 QoS 接受信号（QoS Accept signals）

QoS 接受信号可由从设备接口用于指示其可接受的请求的最低 QoS（服务质量）值。

3.4.4 一致性连接信号（Coherency Connection signals）

一致性连接信号由Manager用于控制是否在AC通道上接收DVM消息。

3.4.5 接口控制信号（Interface control signals）

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

4 AXI传输（AXI Transport）

本章描述AXI中使用的通道传输机制，包含以下小节：

• 时钟和复位（Clock and reset）
• 通道握手（Channel handshake）
• 写通道和读通道（Write and read channels）
• 通道间的关系（Relationships between the channels）
• 通道握手信号间的依赖关系（Dependencies between channel handshake signals）
• 监听通道（Snoop channels）

本章是AXI协议中关于数据传输机制的核心内容，涵盖了协议的基础时序规则、通道交互逻辑及事务处理流程，是理解AXI接口如何实现高效数据传输的关键。后续小节将详细解析各部分的具体规范，包括信号同步方式、握手协议、读写事务的执行流程等。

4.1 时钟和复位（Clock and reset）

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

4.1.1 时钟（Clock）

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

在主设备（Manager）和从设备（Subordinate）接口上，输入信号和输出信号之间不允许存在组合逻辑路径（需通过寄存器隔离，避免时序违规）。

4.1.2 复位（Reset）

AXI协议使用单路低电平有效复位信号ARESETn。复位信号可以异步断言（assert，即拉低），但解除断言（deassert，即拉高）必须与ACLK的上升沿同步。 (异步复位，同步释放)

复位期间，接口需满足以下要求：

• 主设备接口必须将AWVALID、WVALID、ARVALID驱动为低电平（无效状态）；
• 从设备接口必须将BVALID、RVALID驱动为低电平（无效状态）；
• 所有其他信号可驱动为任意值。

复位后，主设备最早可驱动AWVALID、WVALID或ARVALID为高电平的时刻，是在ARESETn变为高电平后的第一个ACLK上升沿。图A3.1展示了复位后AWVALID、WVALID或ARVALID可被驱动为高电平的最早时刻（点b）。

1
2
3
4
5
6
7
8
9
10

1. 时钟同步机制：  
   - 上升沿采样是AXI协议的核心时序规则，所有信号的有效性均以ACLK上升沿为准，确保主从设备间的时序一致性。  
   - 禁止组合逻辑路径可避免信号在时钟周期内的不稳定传播（如“毛刺”），简化时序分析。  

2. 复位特性：  
   - 异步复位，同步释放：允许复位信号快速响应系统异常（异步复位），同时避免解除复位时的时序冲突（同步释放）。  
   - 复位期间的信号约束明确了关键控制信号的状态，确保系统上电或复位后从已知状态启动，减少不确定性。  

3. 复位后启动时机：  
   - 主设备需等待ARESETn稳定为高电平后，才能发起新事务，这一规则避免了复位未完全解除时的错误操作。  

4.2 通道握手（Channel handshake）

所有AXI通道均采用相同的VALID/READY握手机制来传输地址、数据和控制信息。这种双向流控机制意味着主设备（Manager）和从设备（Subordinate）都能控制两者之间信息的传输速率。源端生成VALID信号，以指示地址、数据或控制信息何时可用。目的端生成READY信号，以指示其可以接收信息。仅当VALID和READY信号均为高电平时，才会发生传输。

在主设备和从设备接口上，输入信号与输出信号之间不得存在组合逻辑路径。

图A3.2至图A3.4展示了握手机制的示例。

如A3.2所示，源端在边沿1之后呈现信息并断言VALID信号。目的端在边沿2之后断言READY信号。源端必须保持其信息稳定，直到传输在边沿3发生（此时该断言被识别）。

源端不得等待READY后再断言VALID 。

当VALID被断言后，它必须保持断言状态，直到握手发生——即VALID和READY均被断言的时钟上升沿。

在图A3.3中，目的端在边沿1之后、地址、数据或控制信息有效之前就断言READY。这一断言表明它可以接收信息。源端在边沿2之后呈现信息并断言VALID，随后在边沿3（此时该断言被识别）发生传输。在这种情况下，传输在单个周期内完成。

目的端允许在断言相应的READY之前等待VALID被断言。 （ 目的端可以等待 VALID 后再断言READY）

如果READY已被断言，允许在VALID被断言之前撤销READY。

在图A3.4中，源端和目的端恰好在边沿1之后都表明可以传输地址、数据或控制信息。在这种情况下，传输发生在VALID和READY的断言均被识别的时钟上升沿。这些断言意味着传输在边沿2发生。

4.3 写通道和读通道

本节描述AXI的写通道和读通道。这些通道包括：

• 写请求通道（AW）
• 写数据通道（W）
• 写响应通道（B）
• 读请求通道（AR）
• 读数据通道（R）

对于使用DVM消息的接口，还有两个额外通道：

• 监听请求通道（AC）
• 监听响应通道（CR）

4.3.1 写请求通道（Write request channel，AW）

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

• AWVALID的断言与保持
  主设备（Manager）仅当驱动有效请求时，才可断言AWVALID。一旦断言，AWVALID必须保持高电平，直到从设备（Subordinate）断言AWREADY后的时钟上升沿（即握手完成）。

• AWREADY的默认状态
  AWREADY的默认状态可以是高电平或低电平，但推荐将高电平作为默认状态。当AWREADY为高电平时，从设备必须能够接收任何有效的写请求。

• 不推荐的默认状态
  不建议将AWREADY的默认状态设为低电平，因为这会强制传输至少需要两个周期：一个周期用于断言AWVALID，另一个周期用于断言AWREADY，增加了传输延迟。

4.3.2 写数据通道（Write data channel，W）

写数据通道的控制信号如下表所示。

• WVALID的断言与保持
  主设备仅当驱动有效写数据时，才可断言WVALID。一旦断言，WVALID必须保持高电平，直到从设备断言WREADY后的时钟上升沿（即握手完成）。

• WREADY的默认状态
  WREADY的默认状态可以设为高电平，但仅当从设备能始终在单周期内接收写数据时方可如此配置。若从设备需要多周期处理数据（如缓冲满），则应将WREADY默认设为低电平。

• WLAST的断言时机
  主设备在驱动事务中的最后一笔写数据时，必须断言WLAST信号，以标识该事务的结束。

• 无效字节通道的处理
  推荐对未激活的字节通道（byte lanes）将WDATA驱动为零，避免传输无效数据。

• WLAST信号的可选性
  若从设备无需使用WLAST功能，可从其接口中省略该输入。通过WLAST_Present属性可判断WLAST信号是否存在。

4.3.3 写响应通道（Write response channel，B）

写响应通道的控制信号如下表所示。

• BVALID的断言与保持
  从设备仅当驱动有效写响应时，才可断言BVALID。一旦断言，BVALID必须保持高电平，直到主设备断言BREADY后的时钟上升沿（即握手完成）。

• BREADY的默认状态
  BREADY的默认状态可以设为高电平，但仅当主设备能始终在单周期内接收写响应时方可如此配置。若主设备需要多周期处理响应（如内部缓冲已满），则应将BREADY默认设为低电平。

4.3.4 读请求通道（Read request channel，AR）

读请求通道的控制信号如下表所示。

• ARVALID的断言与保持
  主设备仅当驱动有效读请求时，才可断言ARVALID。一旦断言，ARVALID必须保持高电平，直到从设备断言ARREADY后的时钟上升沿（即握手完成）。

• ARREADY的默认状态
  ARREADY的默认状态可以是高电平或低电平，但推荐将高电平作为默认状态。当ARREADY为高电平时，从设备必须能够接收任何有效的读请求。

• 不推荐的默认状态
  不建议将ARREADY的默认状态设为低电平，因为这会强制传输至少需要两个周期：一个周期用于断言ARVALID，另一个周期用于断言ARREADY，增加了传输延迟。

4.3.5 读数据通道（Read data channel，R）

读数据通道的控制信号如下表所示。

• RVALID的核心约束

  • 从设备仅当读数据通道上的信号（如数据、状态等）有效时，才能断言RVALID（置为高电平）。
  • 一旦RVALID被断言，必须保持高电平，直到主设备断言RREADY后的时钟上升沿（即握手完成）。
  • 特殊限制：即使从设备只有一个读数据源，也只能响应主设备的读请求才能断言RVALID，不允许主动发送未请求的数据（避免无意义的数据传输）。

• RREADY的默认状态与条件

  • 主设备通过RREADY信号表示可接收读数据。
  • RREADY的默认状态可为高电平，但仅当主设备启动读事务后能立即接收数据时才允许（例如主设备内部缓冲空闲，无需额外准备时间）。若主设备需要时间准备（如缓冲占用），则默认应设为低电平。

• RLAST的断言规则

  • 从设备在传输事务中的最后一笔读数据时，必须断言RLAST信号，用于标记突发读操作的结束（如多批次读取的最后一块数据）。

• 无效字节通道的处理建议

  • 推荐将未激活的字节通道（byte lanes）对应的RDATA驱动为零，减少无效信号干扰，提升数据传输的稳定性。

• RLAST信号的可选性与标识

  • 若主设备无需使用RLAST（如不支持突发读），可从接口中省略该信号。
  • 通过RLAST_Present属性判断RLAST是否存在，具体定义如表A3.7：

4.4 通道间的关系（Relationships between the channels）

AXI协议要求维持以下通道间的关系：

4.4.1 事务流程的基本依赖关系

• 写响应（B通道）必须始终跟随写事务中的最后一次数据传输（W通道的最后一笔数据，由WLAST标记）。
  • 含义：写事务的完整流程为“写请求（AW）→ 写数据（W）→ 写响应（B）”，响应是事务完成的标志，必须在所有数据传输结束后产生，确保主设备能确认事务结果。
• 读数据和响应（R通道）必须始终跟随读请求（AR通道）。
  • 含义：读事务的流程为“读请求（AR）→ 读数据（R）”，从设备不能在未收到读请求的情况下主动发送读数据，避免无意义的数据传输。

4.4.2 握手与依赖的约束

• 通道握手必须符合“通道握手信号间的依赖关系”中定义的规则（如VALID/READY的交互逻辑）。

4.4.3 主设备（Manager）的能力要求

• 当主设备发起写请求（AW）时，必须能够提供该事务的所有写数据（W通道），且不依赖该主设备的其他事务。
  • 目的：避免死锁。若主设备因其他事务阻塞而无法提供当前写请求的数据，会导致从设备等待数据，进而阻塞整个通道。
• 当主设备已发起写请求和所有写数据后，必须能够接收该事务的所有响应（B通道），且不依赖该主设备的其他事务。
  • 目的：确保写响应能被及时处理，防止从设备因响应无法发送而阻塞后续操作。
• 当主设备已发起读请求（AR）时，必须能够接收该事务的所有读数据（R通道），且不依赖该主设备的其他事务。
  • 补充说明：主设备可依赖“使用相同ID的事务的读数据按序返回”，因此只需为不同ID的事务准备足够的读数据存储（无需为同一ID的多个事务预留额外空间）。
    • （背景：AXI通过ID信号区分不同事务，同一ID的事务需按序响应，不同ID可乱序，此规则减少主设备的存储压力。）

4.4.4 事务处理的灵活性

• 主设备允许等待一个事务完成后，再发起另一个事务请求（如先完成写事务，再发起读请求）。
  • 场景：适用于资源有限的主设备（如小型MCU），通过串行处理避免资源冲突。
• 从设备允许等待一个事务完成后，再接收或发起另一个事务的传输（如先处理完读事务，再接收写请求）。
  • 场景：适用于处理能力有限的从设备（如低速外设），通过串行处理保证数据正确性。

4.4.5 特殊事务的处理约束

• 从设备不得因存在“领先写数据的事务”（即先传输数据、后传输请求的事务），而阻塞对“无数据写请求”（如仅含地址、无实际数据的写事务）的接收。
  • 目的：避免“无数据请求”被无限延迟。例如，某些特殊命令（仅需地址，无需数据）需优先处理，不能因其他事务的未完成数据而被阻塞。

4.4.6 协议未定义的其他关系

协议未定义通道间的其他依赖关系，这意味着：

• 例如，写数据（W通道）可能在写请求（AW通道）之前出现在接口上（如写请求通道因寄存器级联更多而延迟，导致数据先到达）。
• 此时，若互连（interconnect）需要确定目标地址空间或从设备，必须对请求和数据进行重新对齐，确保写数据仅向其目标从设备标识为有效。

4.5 通道握手信号间的依赖关系（Dependencies between channel handshake signals）

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

• 单箭头指向的信号，可以在箭头起点信号断言之前或之后被断言（无强制先后）；
• 双箭头指向的信号，必须仅在箭头起点信号断言之后才能被断言（有强制先后）。

4.5.1 写事务的依赖关系（Write transaction dependencies）

写通道事务的握手信号依赖关系如图A3.5所示，具体规则如下：

4.5.1.1 主设备（Manager）对写请求/数据信号的约束

• 规则1：主设备不得等待从设备（Subordinate）断言AWREADY或WREADY后，才断言AWVALID或WVALID。这一规则适用于事务中的每一次写数据传输。
  • 核心逻辑：避免死锁。若主设备等待从设备的“就绪信号”（AWREADY/WREADY）才发送“有效信号”（AWVALID/WVALID），而从设备可能等待主设备的“有效信号”才发送“就绪信号”，会导致双方无限等待。因此，主设备必须主动发起有效信号，不依赖从设备的就绪状态。

4.5.1.2 从设备对写请求就绪信号（AWREADY）的约束

• 规则2：从设备可以等待AWVALID、WVALID（或两者）断言后，再断言AWREADY；
• 规则3：从设备也可以在AWVALID、WVALID（或两者）断言之前，就断言AWREADY。
  • 核心逻辑：赋予从设备灵活的流控能力。例如：从设备空闲时可提前断言AWREADY（规则3），直接接收请求；忙碌时可等待主设备的请求/数据有效后（规则2），再准备接收，避免资源冲突。

4.5.1.3 从设备对写数据就绪信号（WREADY）的约束

• 规则4：从设备可以等待AWVALID、WVALID（或两者）断言后，再断言WREADY；
• 规则5：从设备也可以在AWVALID、WVALID（或两者）断言之前，就断言WREADY。
  • 核心逻辑：与AWREADY类似，允许从设备根据自身数据缓冲状态（如是否有空余空间）动态调整对写数据的接收时机，平衡效率与可靠性。

4.5.1.4 从设备对写响应信号（BVALID）的约束

• 规则6：从设备必须等待AWVALID、AWREADY、WVALID、WREADY均被断言（即写请求和写数据的握手均完成）后，才能断言BVALID；
• 规则7：从设备还必须等待WLAST被断言后，才能断言BVALID。这是因为写响应（BRESP）必须在写事务的最后一次数据传输完成后才能发出。
  • 核心逻辑：确保写响应的“完整性”。写响应是对整个写事务的结果反馈，必须在请求被接收、所有数据（包括最后一笔，由WLAST标记）传输完成后才能生成，避免响应过早发送导致主设备误解事务状态。

4.5.1.5 写响应通道（B）的交互约束

• 规则8：从设备不得等待主设备断言BREADY后，才断言BVALID；
• 规则9：主设备可以等待BVALID断言后，再断言BREADY；
• 规则10：主设备也可以在BVALID断言之前，就断言BREADY。
  • 核心逻辑：
    • 规则8避免B通道死锁（从设备必须主动提供响应，不依赖主设备的就绪）；
    • 规则9和10赋予主设备灵活接收响应的能力（如主设备空闲时提前就绪，忙碌时延迟就绪）。

4.5.2 读事务的依赖关系（Read transaction dependencies）

读通道事务的握手信号依赖关系如图A3.6所示，具体规则如下：

4.5.2.1 主设备（Manager）对读请求信号（ARVALID）的约束

• 规则1：主设备不得等待从设备（Subordinate）断言ARREADY后，才断言ARVALID。
  • 核心逻辑：与写事务的AWVALID规则一致，避免死锁。主设备必须主动发起读请求（断言ARVALID），不能依赖从设备的“就绪信号”（ARREADY），否则可能因双方相互等待导致事务阻塞。

4.5.2.2 从设备对读请求就绪信号（ARREADY）的约束

• 规则2：从设备可以等待ARVALID被断言后，再断言ARREADY；
• 规则3：从设备也可以在ARVALID被断言之前，就断言ARREADY。
  • 核心逻辑：赋予从设备灵活控制读请求接收时机的能力。例如：从设备空闲时可提前就绪（规则3），直接接收请求；忙碌时可等待主设备的请求有效后（规则2），再准备处理，避免资源冲突。

4.5.2.3 从设备对读数据有效信号（RVALID）的约束

• 规则4：从设备必须等待ARVALID和ARREADY均被断言（即读请求的握手已完成）后，才能断言RVALID（表示有效读数据可用）。
  • 核心逻辑：确保读数据的“响应性”。读数据是对读请求的响应，必须在从设备确认接收请求后才能生成，避免无请求的数据传输，保证事务的有序性。

4.5.2.4 读数据通道（R）的交互约束

• 规则5：从设备不得等待主设备断言RREADY后，才断言RVALID；
• 规则6：主设备可以等待RVALID被断言后，再断言RREADY；
• 规则7：主设备也可以在RVALID被断言之前，就断言RREADY。
  • 核心逻辑：
    • 规则5避免R通道死锁（从设备必须主动提供数据，不依赖主设备的就绪状态）；
    • 规则6和7赋予主设备灵活接收数据的能力（如主设备空闲时提前就绪，忙碌时延迟就绪）。

4.6 监听通道（Snoop channels）

DVM消息通过监听通道在互连（interconnect）和主设备（Manager）组件之间传输。当支持DVM消息时，存在两个通道：监听请求通道（AC）和监听响应通道（CR）。

4.6.1 监听请求通道（Snoop request channel，AC）

监听请求通道的控制信号如下表所示。

• ACVALID的断言与保持
  从设备（Subordinate）仅当驱动有效地址和控制信息时，才可断言ACVALID。一旦断言，ACVALID必须保持高电平，直到主设备（Manager）断言ACREADY后的时钟上升沿（即握手完成）。

• ACREADY的默认状态
  ACREADY的默认状态可以是高电平或低电平，但推荐将高电平作为默认状态。当ACREADY为高电平时，主设备必须能够接收任何有效的监听请求。

• 不推荐的默认状态
  不建议将ACREADY的默认状态设为低电平，因为这会强制传输至少需要两个周期：一个周期用于断言ACVALID，另一个周期用于断言ACREADY，增加传输延迟。

4.6.2 监听响应通道（Snoop response channel，CR）

监听响应通道的控制信号如下表所示。

• CRVALID的断言与保持
  主设备仅当监听响应通道上的信号有效时，才可断言CRVALID。一旦断言，CRVALID必须保持高电平，直到从设备断言CRREADY后的时钟上升沿（即握手完成）。

• CRREADY的默认状态
  从设备通过CRREADY信号指示其可接收监听响应。CRREADY的默认状态可以是高电平，但仅当从设备在启动监听事务时能立即接收响应时方可如此配置。

4.6.3 监听事务的依赖关系（Snoop transaction dependencies）

监听通道事务的握手信号依赖关系如图A3.7所示，具体规则如下：

4.6.3.1 从设备（Subordinate）对监听请求信号（ACVALID）的约束

• 规则1：从设备不得等待主设备（Manager）断言ACREADY后，才断言ACVALID。
  • 核心逻辑：与读写事务中主设备主动发起请求的逻辑一致，避免死锁。监听请求由从设备（如一致性控制器）主动发起，必须主动断言ACVALID，不能依赖主设备的“就绪信号”（ACREADY），否则可能因双方相互等待导致事务阻塞。

4.6.3.2 主设备对监听请求就绪信号（ACREADY）的约束

• 规则2：主设备可以等待ACVALID被断言后，再断言ACREADY；
• 规则3：主设备也可以在ACVALID被断言之前，就断言ACREADY。
  • 核心逻辑：赋予主设备灵活控制监听请求接收时机的能力。例如：主设备空闲时可提前就绪（规则3），直接接收请求；忙碌时可等待从设备的请求有效后（规则2），再准备处理，避免干扰正在进行的核心事务。

4.6.3.3 主设备对监听响应信号（CRVALID）的约束

• 规则4：主设备必须等待ACVALID和ACREADY均被断言（即监听请求的握手已完成）后，才能断言CRVALID（表示有效响应可用）。
  • 核心逻辑：确保监听响应的“响应性”。监听响应是对监听请求的反馈，必须在主设备确认接收请求后才能生成，避免无请求的响应传输，保证事务的有序性。

4.6.3.4 监听响应通道（CR）的交互约束

• 规则5：主设备不得等待从设备断言CRREADY后，才断言CRVALID；
• 规则6：从设备可以等待CRVALID被断言后，再断言CRREADY；
• 规则7：从设备也可以在CRVALID被断言之前，就断言CRREADY。
  • 核心逻辑：
    • 规则5避免CR通道死锁（主设备必须主动提供响应，不依赖从设备的就绪状态）；
    • 规则6和7赋予从设备灵活接收响应的能力（如从设备空闲时提前就绪，忙碌时延迟就绪）。

这些规则保障了监听事务（用于缓存一致性维护）的可靠传输，使多主设备环境下的共享数据同步得以高效实现。

5. AXI事务（AXI Transactions）

AXI协议使用事务实现主设备（Managers）与从设备（Subordinates）之间的通信。所有事务均包含请求（request）和响应（response）；写事务和读事务还包含一次或多次数据传输（data transfers）。

本章描述事务的请求、响应及数据传输，包括以下小节：

• 事务请求（Transaction request）
• 写数据与读数据（Write and read data）
• 事务响应（Transaction response）

5.1 事务请求（Transaction request）

AXI主设备（Manager）通过向从设备（Subordinate）发起请求来启动事务。一个请求包含事务属性和首次数据传输的地址。如果事务包含多次数据传输，从设备必须计算后续传输的地址。

事务不得跨越4KB地址边界。这一限制可防止事务跨越两个从设备的边界，同时也限制了从设备必须支持的地址增量数量。

5.1.1 大小属性（Size attribute）

“大小（Size）”表示每次数据传输中的最大字节数。

• 对于读事务，Size指示每次读数据传输中必须有效的数据字节数；
• 对于写事务，Size指示允许激活的字节通道（byte lanes）数量，而写选通信号（write strobes）则指示每次传输中哪些字节是有效的。

Size不得超过接口的数据宽度（由DATA_WIDTH属性决定）。如果Size小于DATA_WIDTH，则每次传输仅使用字节通道的一个子集。

Size通过写请求通道的AWSIZE信号和读请求通道的ARSIZE信号传递。本规范中，AxSIZE泛指AWSIZE和ARSIZE。

AxSIZE信号的编码方式如下表所示：

“SIZE_Present”属性用于判断AxSIZE信号是否存在：

仅发起全数据宽度请求的主设备，可从其接口中省略AxSIZE输出。与之连接的从设备必须根据数据宽度将其AxSIZE输入引脚固定（如硬连线到对应值）。

这些规则确保了事务请求的规范性和灵活性，适配不同数据宽度和传输粒度的场景。

5.1.2 长度属性（Length attribute）

长度属性定义了一个事务中的数据传输次数。

• Size × Length 是一个事务中可传输的最大字节数。若地址未对齐或存在未激活的写选通信号，则实际传输的字节数可能小于该值。
• 主设备（Manager）必须根据Length发送相应次数的写数据传输。
• 从设备（Subordinate）必须根据Length发送相应次数的读数据传输。

长度通过写请求通道的AWLEN信号和读请求通道的ARLEN信号传递。本规范中，AxLEN泛指AWLEN和ARLEN。

5.1.2.1 信号定义与编码

AxLEN信号定义与编码如下表所示：

5.1.2.2 可选性与默认配置

LEN_Present属性用于判断AxLEN信号是否存在：

• 仅发起单传输（Length=1）请求的主设备，可省略AxLEN输出。
• 此时，相连从设备的AxLEN输入必须固定为0x00（对应Length=1）。

5.1.2.3 事务长度的约束规则

1. 突发类型与长度的关系

   • 回环突发（Wrapping bursts）：Length只能为2、4、8或16。
     （回环突发要求地址在固定范围内循环，特定长度值可确保地址计算的规律性。）
   • 固定突发（Fixed bursts）：Length最大为16。
     （固定突发的地址始终不变，允许较多的重复传输。）

2. 地址边界限制

   • 事务不得跨越4KB地址边界。
     （确保事务数据的连续性，避免跨设备边界导致的复杂处理。）

3. 不支持提前终止

   • 任何组件均不得提前终止事务。
   • 写事务优化：主设备可通过禁用所有写选通信号（deassert all write strobes）停止后续数据写入，但仍需完成Length规定的所有传输次数。
   • 读事务处理：主设备可丢弃读数据，但必须完成所有传输。

5.1.3 事务中的最大字节数（Max_Transaction_Bytes）

在AXI协议中，事务的数据传输受“最大字节数”限制，这一机制通过Max_Transaction_Bytes属性定义，旨在规范事务大小、避免跨边界传输，并确保Master（Manager）与从设备（Subordinate）之间的兼容性。以下是具体说明：

5.1.3.1 核心限制：4KB边界与最大字节数

• 默认最大字节数：所有事务的最大字节数默认不超过4KB（4096字节），且绝对不允许跨越4KB地址边界。这一限制的目的是：
  • 避免单个事务同时涉及多个从设备（因不同从设备可能在4KB边界划分）；
  • 简化从设备对地址增量的处理逻辑。
• 灵活配置：实际应用中，Master或从设备可通过Max_Transaction_Bytes属性指定更小的最大字节数（如64、128、256等），以适应自身需求（如优化解码逻辑、避免事务拆分等）。

5.1.3.2 Max_Transaction_Bytes属性定义

该属性明确了事务允许的最大总字节数，具体规则如下：

• 取值范围：支持64、128、256、512、1024、2048、4096字节（默认值为4096）。
• 对Master的要求：发起的事务中，Size × Length（单次传输字节数 × 传输次数）必须小于等于其Max_Transaction_Bytes，且事务不能跨越该值对应的地址边界（如Max_Transaction_Bytes=2048时，事务不可跨越2048字节边界）。
• 对从设备的要求：只能接受Size × Length小于等于其Max_Transaction_Bytes的事务。

5.1.3.3 兼容性规则

当Master与从设备连接时，Max_Transaction_Bytes的取值需满足兼容性，否则可能导致事务错误。具体规则：

• 兼容情况：
  • Master的Max_Transaction_Bytes 小于 从设备的取值（Master发起的事务大小在从设备可接受范围内）；
  • 两者取值相等（事务大小完全匹配双方限制）。
• 不兼容情况：
  • Master的Max_Transaction_Bytes 大于 从设备的取值（Master可能发起从设备无法接受的超大事务）。

5.1.4 突发属性（Burst attribute）

突发属性描述了事务中各次数据传输间的地址递增方式。AXI协议定义了三种突发类型，用于支持不同场景下的地址生成逻辑：

5.1.4.1 固定突发（FIXED）

用于对同一地址的重复访问，如操作FIFO（先进先出队列）时的读写操作。

• 地址特性：突发内每次传输的地址保持不变。
• 数据特性：所有传输中有效的字节通道（byte lanes）固定，但每次传输中通过写选通信号（WSTRB）激活的具体字节可不同。
• 长度限制：突发长度（Length）最大为16次传输。
• 操作码限制：仅支持WriteNoSnoop或ReadNoSnoop操作码。

5.1.4.2 递增突发（INCR, Incrementing）

用于访问连续内存区域（如数组、缓冲区），每次传输的地址按前一次地址递增。

• 地址特性：每次传输的地址 = 前一次地址 + Size（如Size=4字节，则每次地址+4）。
• 适用场景：普通顺序内存访问（如加载程序代码、读取连续数据结构）。
• 对齐要求：起始地址不强制对齐，但为提高效率通常建议对齐到Size（如4字节对齐）。

5.1.4.3 回环突发（WRAP, Wrapping）

类似递增突发，但当地址达到上限时会“回环”到起始地址附近，形成闭环访问。

• 对齐要求：
  • 起始地址必须对齐到Size（如Size=8字节，则起始地址必须是8的倍数）。
  • 突发长度（Length）必须为2、4、8或16（确保地址回环的规律性）。
• 回环规则：
  1. 回环边界（wrap boundary）：事务访问的最低地址，等于起始地址按Size × Length对齐（如Size=4、Length=8，则回环边界为起始地址按32字节对齐）。
  2. 地址递增：每次传输后地址按INCR方式递增（+Size），但若递增后的地址达到回环边界 + (Size × Length)，则地址回跳到回环边界。
• 适用场景：高速缓存行（Cache Line）访问（如缓存行填充或回写，需连续访问固定大小的内存块）。

5.1.4.4 信号定义与编码

突发类型通过写请求通道的AWBURST和读请求通道的ARBURST信号传递，编码如下：

5.1.4.5 可选性与默认配置

BURST_Present属性用于判断AxBURST信号是否存在：

• 仅使用INCR突发的主设备 （Manager）可省略AxBURST输出。
• 此时，相连从设备（Subordinate）的AxBURST输入必须固定为0b01（INCR）。

5.1.4.6 Fixed_Burst_Disable

在AXI协议中，Fixed_Burst_Disable是一个用于标识组件是否支持FIXED类型突发传输的属性，其核心作用是规范Manager（请求发起方）和Subordinate（请求接收方）之间的兼容性。以下是详细说明：

5.1.4.6.1 Fixed_Burst_Disable的定义

该属性通过布尔值（True/False）表示组件对FIXED突发的支持情况：

• 默认值为False：表示组件支持FIXED突发（Manager可能生成FIXED请求，Subordinate可以接收FIXED请求）。
• 当为True时：组件不支持FIXED突发（Manager不会生成FIXED请求，Subordinate无法接收FIXED请求）。

5.1.4.6.2 Manager与Subordinate的兼容性规则

兼容性取决于Manager和Subordinate各自的Fixed_Burst_Disable值，具体如下：

5.1.4.6.3 实际意义

• FIXED突发主要用于重复访问同一地址（如FIFO读写），但实际应用中并不常用。因此，部分组件可能选择不支持该类型以简化设计。
• 该属性确保连接的Manager和Subordinate在FIXED突发的处理能力上匹配，避免因一方发送而另一方无法处理导致的通信错误。

例如：若一个Manager的Fixed_Burst_Disable为False（可能发送FIXED请求），则必须连接到Fixed_Burst_Disable为False的Subordinate（可接收），否则会不兼容；若Manager不生成FIXED请求（Fixed_Burst_Disable为True），则可连接任何Subordinate。

5.1.5 传输地址（Transfer address）

本节介绍事务中各次传输的地址及字节通道（byte lanes）的确定方法。

5.1.5.1 起始地址信号（AxADDR）

事务的起始地址通过AWADDR（写请求）和ARADDR（读请求）信号指示，具体定义如下：

AxADDR信号定义与编码如下表所示：

5.1.5.2 地址宽度（Address width）

地址宽度由ADDR_WIDTH属性定义，具体规则：

ADDR_WIDTH属性定义如下表所示：

5.1.5.3 不同物理地址空间大小的组件通信规则

协议支持物理地址空间大小不同的组件之间的通信，此类组件必须按以下规则交互：

• 地址窗口定位：
  物理地址空间较小的组件，必须位于物理地址空间较大的组件的对齐窗口（aligned window）内。通常，该窗口位于较大地址空间的底部（低地址区域），但也允许较小地址空间的组件位于较大空间的偏移窗口（offset window）中（即非底部的对齐区域）。

• Outgoing transaction（输出事务）：
  输出事务必须在地址中添加所需的额外高阶位（higher-order bits）。例如，32位地址组件向64位地址组件发送事务时，需将32位地址扩展为64位（补充高阶位，通常为0）。

• Incoming transaction（输入事务）：
  输入事务必须经过检查，处理规则如下：

  • 若事务地址在地址窗口内，则移除高阶地址位并传递（如64位地址组件向32位组件发送事务时，截断超出32位的高阶位）；
  • 若事务地址不包含所需的高阶位（即不在地址窗口内），则该事务被抑制（suppressed，不传递）。

• 互连（interconnect）的职责：
  提供上述地址处理功能（如地址扩展、截断、窗口检查）是互连的责任，以确保不同地址宽度的组件能正确通信。

5.1.6 事务方程式

这里列出的方程式用于确定事务中每次传输的地址和活动数据字节通道（byte lanes）。方程式使用以下附加变量：

• Start_Addr：主设备 （Manager）发出的起始地址
• Data_Bytes：数据通道的字节宽度（DATA_WIDTH/8）
• Aligned_Addr：起始地址的对齐版本
• Address_N：事务中第N次传输的地址。对于事务中的第一次传输，N为1
• Wrap_Boundary：回环事务（wrapping transaction）内的最低地址
• Lower_Byte_Lane：一次传输中最低地址字节的字节通道
• Upper_Byte_Lane：一次传输中最高地址字节的字节通道
• INT(x)：x的向下舍入整数值

这些方程式确定突发传输（burst）内各次传输的地址：

1
2

Start_Addr = AxADDR
Aligned_Addr = INT(Start_Addr / Size) * Size

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

1

Address_1 = Start_Addr

对于递增突发（INCR burst）和地址尚未回环的回环突发（WRAP burst），该方程式确定突发传输中第一次传输之后任何传输的地址：

1

Address_N = Aligned_Addr + (N - 1) * Size

对于回环突发，Wrap_Boundary变量定义回环边界：

1

Wrap_Boundary = INT(Start_Addr / (Size * Length)) * Size * Length

对于回环突发，如果Address_N = Wrap_Boundary + Size * Length，则：

• 对当前传输使用此方程式：

1

Address_N = Wrap_Boundary

• 对任何后续传输使用此方程式：

1

Address_N = Start_Addr + ((N - 1) * Size) - (Size * Length)

这些方程式确定突发传输中第一次传输要使用的字节通道：

1
2

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)

这些方程式确定突发传输中第一次传输之后所有传输要使用的字节通道：

1
2

Lower_Byte_Lane = Address_N - (INT(Address_N / Data_Bytes) * Data_Bytes)
Upper_Byte_Lane = Lower_Byte_Lane + Size - 1

数据在以下位置传输：

1

DATA((8 * Upper_Byte_Lane) + 7: (8 * Lower_Byte_Lane))

事务容器（transaction container）描述该事务中可能访问的所有字节，如果地址是对齐的且选通信号（strobes）被断言：

1

Container_Size = Size * Length

对于递增突发（INCR bursts）：

1
2

Container_Lower = Aligned_Addr
Container_Upper = Aligned_Addr + Container_Size

对于回环突发（WRAP bursts）：

1
2

Container_Lower = Wrap_Boundary
Container_Upper = Wrap_Boundary + Container_Size

5.1.7 传输的伪代码描述

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// DataTransfer()
DataTransfer(Start_Addr, Size, Length, Data_Bytes, Burst, IsWrite)
// IsWrite 对于写操作为TRUE，对于读操作为FALSE
addr = Start_Addr; // 当前地址的变量
Aligned_Addr = (INT(addr/Size) * Size);
aligned = (Aligned_Addr == addr); // 检查addr是否按Size对齐
Container_Size = Size * Length;
if Burst == WRAP then
    Lower_Wrap_Boundary = (INT(addr/Container_Size) * Container_Size);
    // 对于回环突发，addr必须对齐
    Upper_Wrap_Boundary = Lower_Wrap_Boundary + Container_Size;
for n = 1 to Length
    Lower_Byte_Lane = addr - (INT(addr/Data_Bytes) * 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) * Data_Bytes);
    // 执行数据传输
    if IsWrite then
        dwrite(addr, Lower_Byte_Lane, Upper_Byte_Lane)
    else
        dread(addr, Lower_Byte_Lane, Upper_Byte_Lane);
    // 必要时递增地址
    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; // 第一次传输之后的所有传输都是对齐的
return;

5.1.8 常规事务（Regular transactions）

在AXI协议中，事务的突发类型、大小和长度存在多种组合。但某些接口或事务类型可能仅使用其中的一部分组合。若从设备（Subordinate）仅连接使用部分事务选项的主设备 （Manager），则可设计简化的解码逻辑。

常规事务（Regular transactions） 被定义为满足以下所有条件的事务：

1. 长度（Length） 为1、2、4、8或16次传输。
2. 大小（Size）：若长度大于1，则必须与数据通道宽度相同。
3. 突发类型（Burst）：仅支持INCR（递增）或WRAP（回环），不支持FIXED。
4. 地址对齐：
   • INCR突发：起始地址必须对齐到事务容器（Container，即Size × Length）。
   • WRAP突发：起始地址必须对齐到Size。

5.1.8.1 Regular_Transactions_Only属性

该属性用于标识主设备 是否仅发出常规事务，以及从设备是否仅支持常规事务：

5.1.8.2 兼容性规则

主设备 与从设备之间的兼容性规则如下：

5.2 写入和读取数据

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

5.2.1 写选通信号（Write strobes）

WSTRB信号携带写选通信息，用于指定写数据通道中哪些字节通道（byte lanes）包含有效数据。

5.2.1.1 写选通信号（WSTRB）的定义

WSTRB信号定义如下表所示：

5.2.1.2 信号映射关系

写选通信号与写数据的字节通道一一对应：每1位WSTRB对应写数据通道中8位（1字节）的数据。具体来说，WSTRB[n]对应WDATA[(8n)+7 : 8n]（即第n个字节）。

5.2.1.3 WSTRB的行为规则

当WVALID为高电平时（写数据有效）：

1. 有效数据标记：需要写入的字节对应的写选通位必须置高（WSTRB[n] = 1）。
2. 事务容器内的灵活性：在事务容器（transaction container）范围内，任意数量的写选通位可置高；若所有写选通位均为低，则该次传输无数据写入。
3. 事务容器外的限制：事务容器范围外的所有写选通位必须置低（防止越界写入）。

当WVALID为低电平时（写数据无效）：

• 写选通位可取任意值，但推荐将其拉低或保持前值（避免无效信号干扰）。

5.2.1.4 推荐设计实践

• 对于写选通位为低（WSTRB[n] = 0）的字节通道，建议将WDATA的对应字节驱动为0（减少无效数据传输的干扰）。

5.2.1.5 WSTRB信号的可选性（WSTRB_Present属性）

该属性用于标识接口是否包含WSTRB信号：

WSTRB_Present属性定义如下表所示：

• 若主设备 （Manager）仅发起“所有写选通位均置高”的事务（即每次传输的所有字节均有效），可省略WSTRB输出。
• 与之连接的从设备（Subordinate）必须将其WSTRB输入引脚固定为高电平（模拟全选通有效）。

5.2.2 窄传输（Narrow transfers）

5.2.2.1 核心定义与规则

当 传输宽度（Size）小于数据通道宽度（Data_Bytes = DATA_WIDTH/8，即数据总线的字节数）时，称为窄传输。此时，地址和突发类型 决定了传输使用的字节通道（byte lanes）：

5.2.2.2 示例解析（结合图A4.1和图A4.2）

5.2.2.2.1 图A4.1：32位总线，8位传输（INCR突发）

• 参数：

  • 数据总线：32位 → Data_Bytes = 4（4字节，通道0~3）。
  • 传输大小：8位 → Size = 1（1字节/次）。
  • 突发：INCR，共5次传输，起始地址 Start_Addr = 0。

• 字节通道计算：
  地址的 低2位（log₂(Data_Bytes) = log₂(4) = 2）决定通道：

5.2.2.2.2 图A4.2：64位总线，32位传输（INCR突发）

• 参数：

  • 数据总线：64位 → Data_Bytes = 8（8字节，通道0~7）。
  • 传输大小：32位 → Size = 4（4字节/次）。
  • 突发：INCR，共3次传输，起始地址 Start_Addr = 4。

• 字节通道计算：
  地址的 低3位（log₂(Data_Bytes) = log₂(8) = 3）决定通道：

（阴影部分为未使用的字节通道，仅标记有效数据的通道。）

5.2.3 字节不变性（Byte invariance）

为在单一内存空间中访问混合大小端（mixed-endian）的数据结构，AXI协议采用字节不变性端序方案（byte-invariant endianness scheme）。

字节不变性端序的定义：对于数据结构中的任意多字节元素：

• 内存连续性：该元素始终使用内存中相同的连续字节，与数据的端序无关。
• 端序决定排列：端序仅决定这些字节在内存中的排列顺序（即内存首字节是元素的最高有效字节（MSB） 还是最低有效字节（LSB））。
• 单字节路径固定：无论该字节属于何种多字节元素，对特定地址的单字节传输始终通过数据通道的相同物理线路，写入内存的相同地址位置。

5.2.3.1 组件实现规则

1. 单宽度组件：仅支持一种传输宽度的组件，需将其字节通道与数据通道的对应字节通道直连。
2. 多宽度组件：支持多种传输宽度的组件，可能需要复杂的接口转换逻辑，以确保非自然字节不变的接口符合规范。
3. 端序适配：
   • 小端组件：通常可直接连接字节不变接口。
   • 大端组件：需内置转换功能，以实现字节不变操作。

5.2.3.2 示例解析（图A4.3）

以32位数值 0x0A0B0C0D 为例，展示大端字节不变结构的存储方式：

• 寄存器存储：数据的MSB（0x0A）存于寄存器的最高有效位位置。
• 内存存储：数据的MSB存储于最低地址的内存位置，其他字节按重要性递减排列（如地址递增方向依次存储 0x0A, 0x0B, 0x0C, 0x0D）。
  

在图A4.4中，展示了一个小端（little-endian）字节不变数据结构的示例。在该结构中：
• 数据的最低有效字节（LSB，即0x0D）存储在寄存器的最低有效位（LSB）位置。
• 数据的LSB存储在地址最低的内存位置。
• 其他数据字节按 重要性递增 的顺序排列（即地址越高，字节的有效位权重越高）。

5.2.3.3 与大端的核心差异（辅助理解）：

无论大小端，单字节的传输路径始终固定（如内存Byte 0对应总线字节通道0）—— 这正是“字节不变性”的核心：单字节的物理映射不变，仅多字节的内部顺序由端序决定。

图A4.3和图A4.4的示例表明，字节不变性确保了大端（BE）和小端（LE）结构可以在同一内存空间中共存而不发生数据损坏。

在图A4.5中，展示了一个需要字节不变访问的数据结构示例：

• 头部字段（Header）采用小端序（如两字节的Data items字段，其最低地址存储LSB）。
• 有效载荷（Payload）采用大端序（如多字节数据按BE规则排列）。
  

这种混合端序结构的正确性依赖于字节不变性：

• 当组件以大端方式访问Payload时，仅操作Payload区域的字节，不会影响相邻的小端头部字段（如Data items）。
• 字节不变性确保每个字节的物理存储位置固定，无论访问端序如何，都不会误写其他区域的数据。

5.2.4 非对齐传输（Unaligned transfers）

AXI协议支持非对齐传输，即当单次传输宽度超过1字节时，首个访问的字节可能未对齐到自然边界（如32位传输未对齐到4字节边界）。例如，起始地址为0x1002的32位数据包未对齐到32位自然边界。

5.2.4.1 非对齐传输的实现方式

主设备 （Manager）可通过以下两种方式指示非对齐起始地址：

1. 使用低阶地址线：直接通过AxADDR信号的低阶位（如AxADDR[1:0]）指示非对齐偏移量。
2. 使用字节通道选通（WSTRB）：提供对齐的地址（如0x1000），但通过WSTRB信号仅激活部分字节通道（如仅激活通道2和3，对应地址0x1002和0x1003）。

约束条件：低阶地址线与字节通道选通的信息必须一致（例如，若地址为0x1002，则WSTRB必须仅激活通道2和3）。

5.2.4.2 从设备（Subordinate）的处理规则

从设备无需根据主设备 提供的对齐信息执行特殊操作。具体来说：

• 从设备可直接忽略地址对齐信息，仅根据WSTRB信号接收有效字节。
• 若从设备内部要求数据对齐（如缓存行对齐），需自行处理非对齐数据的重组。

5.2.4.3 示例解析（图A4.6）

图A4.6展示了32位数据通道上的对齐与非对齐事务示例：

（阴影部分表示未传输的字节通道。）

图 A4.7 展示了 64 位数据通道上 32 位对齐与非对齐事务的示例。图中每一行代表一次传输，阴影部分表示未传输的字节。

图 A4.8 展示了 64 位数据通道上 32 位对齐回环事务（aligned 32-bit wrapping transaction）的示例。图中每一行代表一次传输，阴影部分表示未传输的字节。

5.3.1 写响应（Write response）

写响应通过写响应通道（B通道）的BRESP信号传输。所有写通道上的事务都有一个完成响应（Completion response），用于指示事务的结果。部分事务还会有第二个写响应（例如用于指示“持久性”, B通道上的PCMO响应）。

5.3.1.1 BRESP和BCOMP信号定义

写响应通过BRESP和BCOMP信号发送，具体定义如下：

5.3.1.2 BRESP_WIDTH属性

BRESP_WIDTH属性定义如下：

5.3.1.3 信号的可选性与约束

• BRESP信号：可选信号。若BRESP_WIDTH属性为0，则BRESP信号不存在，默认值为0b000（OKAY）。

• BCOMP信号：仅当接口使用以下支持“双写响应”的特性时存在：
  • 用于持久性的缓存维护操作（持久性相关的PCMO）；
  • 内存标记（内存标记扩展（MTE））。

  若BCOMP信号存在，则写通道上每个事务的其中一次响应传输必须将BCOMP置高（标记为完成响应）。

BRESP的编码方式如下表所示。

• 独占写的特殊处理：

  • EXOKAY（0b001）仅用于独占写成功的场景（如LL/SC机制中的存储条件指令）。
  • 非独占写即使成功也返回OKAY（0b000），而独占写失败则返回OKAY（表示未满足独占条件）。

• 错误分类：

  • SLVERR与DECERR的区别：前者表示请求到达从设备但因内部问题失败（如权限不足），后者表示地址无效（如访问未映射的地址）。
  • DEFER与UNSUPPORTED仅用于可延迟写事务，允许设备在特定条件下拒绝当前写操作。

• 地址转换故障：

  • TRANSFAULT用于指示地址转换过程中出现错误（如TLB缺失），可能通过特权请求（PRI）修复。

• 向后兼容：

  • 当BRESP_WIDTH=2时，仅支持前4种编码（0b000~0b011），其余值需视为保留或错误。

5.3.2 读响应（Read response）

读响应用于指示读取操作是否成功，以及该次传输中的数据是否有效。

读响应通过读数据通道的RRESP信号传输。事务中的每个读数据传输都对应一个读响应，且同一事务中各次读数据传输的响应值不必相同。

强制要求：无论响应结果如何，必须完成所有由Length指示的数据传输（即不能因响应错误而提前终止）。在某些响应中，传输的数据可能无效。

5.3.2.1 RRESP信号定义

RRESP信号的定义如下：

5.3.2.2 RRESP_WIDTH属性

RRESP_WIDTH属性定义如下：

5.3.2.3 信号的可选性

RRESP是可选信号：

• 若RRESP_WIDTH属性为0，则RRESP信号不存在，默认值为0b000（OKAY）。

5.3.2.4 RRESP编码

对于数据无需有效的响应，主设备仍可能采样RDATA的值，因此从设备不应依赖响应来隐藏敏感数据。

读响应值（RRESP）在事务的各次传输中不要求保持一致。DECERR响应通常用于指示访问从设备（Subordinate）时出现问题，这种情况下，所有读数据传输都应一致地发出DECERR——这样主设备（Manager）只需检查一次读数据传输，就能判断是否发生了DECERR。

一致性DECERR（Consistent_DECERR） 属性用于定义从设备在事务内是否一致地发出DECERR响应，具体如下表所示。

• 不使用DECERR响应的从设备接口，可将Consistent_DECERR属性设为True。
• 若主设备的Consistent_DECERR设为True，它只需检查一次数据传输，就能判断是否发生了DECERR。
• 将该属性设为True有助于AXI与CHI协议的桥接（DECERR在CHI中对应“非数据错误（Non-data Error）”）。

当连接主设备与从设备接口时，Consistent_DECERR的兼容组合如下：

5.3.3 从设备繁忙指示（Subordinate Busy indicator）

从设备在提供响应时，可通过繁忙指示（Busy indicator） 信号表明其当前的活动状态。该信息可用于控制主设备（Manager）的事务发出速率，或限制其生成的推测性事务数量。

繁忙指示对共享资源的组件（如内存控制器或系统缓存）尤为有用，可指示以下状态：

• 共享队列的深度；
• 读写请求队列的状态（取决于事务方向）；
• 组件的资源使用率是否超过/低于分配值。

5.3.3.1 Busy_Support属性

5.3.3.2 繁忙指示信号定义

当Busy_Support为True时，接口包含以下信号：

5.3.3.3 信号使用规则

1. 多传输事务：

   • 对于多次读数据传输的事务，每次传输的Busy值必须有效，但可不同。
   • 对于多次写响应的事务，仅在BCOMP置高的响应中Busy必须有效；其他写响应中Busy值无关紧要。

2. 原子事务：

   • 同时包含读写响应时，BBUSY和RBUSY可不同，但需分别有效。

3. 实现定义：
   Busy指示值的具体含义由实现方定义。下表给出一种可能的用法示例：

下表给出了Busy_Support的互操作性