AMBA5 AXI和ACE协议技术规范中文版-第A4章 事务属性

第A4章 事务属性

本章描述了决定一个事务应该如何被系统组件，如缓存、缓冲区和内存控制器处理的属性。它包括以下部分：

• 在A4-62页的事务类型和属性
• 在A4-63页的AXI3内存属性信号
• 在A4-64页的对AXI4内存属性信号的更改
• 在A4-69页的内存类型
• 在A4-73页的内存不匹配属性
• 在A4-74页的事务缓冲区
• 在A4-75页的访问权限
• 在A4-76页的遗留问题
• 在A4-77页的用例

A4.1 事务类型和属性

分为以下两种：
内存slave
内存slave需要正确的处理所有的事务类型。
外设slave
外设slave有一个实现定义IMPLEMENTATION DEFINED的访问方法。通常，访问方法是在组件数据表中定义的，该数据表描述了slave正确处理的事务类型。
根据协议，任何对不属于实现定义IMPLEMENTATION DEFINED访问方法的外设slave访问都必须完成。但是，当进行这样的访问时，并不要求外设slave继续正确地操作。它只需要以符合协议的方式继续完成进一步的事务。
注意

• 为了防止系统死锁，需要兼容所有事务类型的完成，但是，不需要外设slave继续正确操作。
• 因为外设slave只需要为定义的访问方法正确工作，它可以有一个简化的接口信号集。
  AXI协议定义了一组支持内存和外围设备slave的事务属性。ARCACHE和AWCACHE信号指定事务属性。他们控制:
• 事务在系统中如何处理
• 任何系统级缓存如何处理事务
  在此规范中，术语AxCACHE统指ARCHCHE和AWCHACHE。
  以下部分描述了事务属性：
• 在A4-63页的AXI3内存属性信号
• 在A4-64页的对AXI4内存属性信号的更改

A4.2 AXI3 内存属性信号

在AXI3中，AxCACHE[3:0]信号指定了事务的缓冲，缓存和分配属性。
AxCACHE编码如表A4-1所示。

AxCACHE[0], Bufferable (B) bit
当此bit生效时，互联或任何组件可以延迟任意个周期数到达它最终的目的地。
注意
通常，缓冲属性只与写有关。
AxCACHE[1], Cacheable © bit
当此bit无效时，禁止事务的分配。
当此bit生效时：

• 允许事务的分配。RA和WA提供额外的提示信息。
• 在最终目的地事务的特征不必与源头事务特征相匹配。
  对写，这意味着几个不同的写可以被合并在一起。
  对于读取，这意味着可以预取某个位置的内容，或者可以将单个读取的值用于多个读取事务。
  AxCACHE[2], Read-Allocate (RA) bit
  当此bit生效时，推荐但是不强制事务的读分配。如果C bit无效，RA bit必须不能生效。
  AxCACHE[3], Write-Allocate (WA) bit
  当此bit生效时，推荐但是不强制事务的写分配。如果C bit 无效，WA bit必须不能生效。

A4.3 AXI4对内存属性信号的更改

AXI4对AXI3内存属性信号做了以下更改:

• AxCACHE[1]bit被重新命名为可修改的bit。
• 排序需求是为不可修改事务定义的。
• 读分配和写分配的含义被更新。

A4.3.1 AxCACHE[1],可修改的

在AXI中，AxCACHE[1] bit是可修改位。当为高时，可修改表明事务的特征是可修改的。当可修改位为低时，事务时不可修改的。
注意
AxCACHE[1]位从Cacheable位重命名为Modifiable位，以便更好地描述所需的功能。实际功能没有改变。
以下部分描述了可修改事务和不可修改事务的属性。
不可修改的事务
通过设定AxCACHE[1]为低，表示不可修改的事务。
不可修改事务必须不能被拆分为多个事务或与其他事务合并。
在不可修改事务中，如表A4-2所示参数不能修改。

AxCACHE属性只能被修改，将事务从可缓冲的转换为不可缓冲的。不允许对AxCACHE进行其他更改。
事务ID和QoS的值可以被修改。
突发长度大于16的不可修改事务可以拆分为多个事务。每个生成的事务必须符合本节规定的要求，但以下情况除外:

• 减少突发长度。
• 成的突发地址被适当的调整。
  如果访问的字节数保持不变，有AxLOCK生效表明独占访问的非修改事务被允许事务大小，AxSIZE，事务长度，AxLEN被修改。
  注意
  在某些情况下，不可能满足不可修改事务的要求。例如，当总线宽度缩小到比事务大小(AxSIZE)要求的更窄时，必须修改事务。
  执行此类操作的组件可以有选择地包含一个执行定义IMPLEMENTATION DEFINED机制，以指示已经发生了修改。这种机制可以帮助软件调试。
  可修改事务
  可修改事务通过AxCACHE[1]生效来表明。
  可修改事务通过以下方式修改：
• 一个事务可以被分解成多个事务。
• 多个事务可以合并成一个事务。
• 读事务可以获取比请求更多的数据。
• 写事务可以访问比请求更大的地址空间，使用WSTRB信号来确保只更新适当的位置。
• 在每个生成的事务中，以下信号可以被修改：
  — 传输地址, AxADDR
  — 突发大小, AxSIZE
  — 突发长度, AxLEN
  — 突发类型, AxBURST
  以下必须不能被改变：
• 锁定类型, AxLOCK
• 保护类型, AxPROT
  内存属性AxCACHE可以被修改，但是任何修改都必须确保不会降低其他组件对事务的可见性，这可以防止事务传播到所需的点，也可以改变在缓存中查找事务的需要。对于相同地址范围的所有事务，对内存属性的任何修改必须是一致的。
  事务ID和QoS值可能被修改。
  以下情况不允许修改事务:
• 引起与原始事务不同的4KByte地址空间访问。
• 使对单副本原子性大小区域的一次访问作为多次访问执行。参见A7-94页中的单副本原子性大小。

A4.3.2 更新读分配和写分配的含义

在AXI4中，读分配和写分配位的含义被更新，因此，一个位表示为事务进行了分配，另一个位表示由于另一个事务可能进行了分配。
对读事务，重新定义的写事务bit表明：

• 由于写事务(作为在AXI3中定义的)，此位置可能之前在缓存中已经被分配。
• 由于另一个主机的操作(额外AXI4定义)，此位置可能之前在缓存中已经被分配。
  对写事务，重新定义的读分配bit表明：
• 由于读事务(作为AXI3定义中的)，此位置可能之前在缓存中已经被分配。
• 由于另一个主机的操作(额外AXI4定义)，此位置可能之前在缓存中已经被分配。
  这些变化意味着:
• 如果AxCACHE[3:2]的值不是0b00，事务必须在缓存中查找。
• 如果AxCACHE[3:2]的值是0b00, 事务不需要在缓存中查找。
  注意
  对AxCACHE定义的更改意味着对于同一个位置的读和写事务，这些信号可能不同。
  表A4-3显示对AWCACHE信号的AXI4 bit分配。
  表A4-3 AWCACHE bit分配

信号	AXI4定义	描述
AWCACHE[3]	Allocate	当生效时，事务必须在缓存中查找，因为它可能之前被分配过。如果AWCACHE[2] 生效，事务必须在缓存中查找。当无效时，如果AWCACHE[2] 也无效，然后事务不需要在缓存中查找，事务必须传播到最终的目的地中。当无效时，因为性能原因此规范推荐这个事务被分配在缓存中。
AWCACHE[2]	Other Allocate	当生效时，事务必须在缓存中被查找，因为它可能已经被其它事务在缓存中分配，或者是读事务或是来自其它master的事务。如果AWCACHE[3]生效，事务必须在缓存中查找。当失效时，如果AWCACHE[3]也失效，那么事务不需要在缓存中被查找，并且事务必须传播到最终目的地。
AWCACHE[1]	Modifiable	当生效时，事务的特征可以被修改，写可以被合并。当失效时，事务的特征必须不可以被修改。
AWCACHE[0]	Bufferable	如果AWCACHE[3:2]是无效的，当此bit无效时，写响应必须从最终目的地给出。当失效时，如果AWCACHE[3:2]任何一个生效，写事务响应可以从中间点给出，但是写事务需要在最终目的地及时的可见。当生效时，如果AWCACHE[3:2] 任何一个生效，写响应可以从中间点给出。写事务需要在最终目的地可见。

表A4-4 ARCACHE bit分配

信号	AXI4	定义描述
ARCACHE[3]	Other Allocate	当生效时，事务必须在缓存中被查找，因为它可能在缓存中被另一个事务分配，或写事务或来自另外一个master的事务。如果ARCACHE[2]生效，事务也必须在缓冲中被查找。当无效时，如果ARCACHE[2]也是无效，则事务不需要在缓存中被查找。
ARCACHE[2]	Allocate	当生效时，事务必须从缓存中查找，因为它可以被分配。如果ARCACHE[3]生效，事务必须也可以被在缓存中查找。当无效时，如果ARCACHE[3]也是无效，那么事务不需要在缓存中被查找。当生效时，因性能原因，此规范推荐此事务被分配在缓存中。
ARCACHE[1]	Modifiable	当生效时，事务的特征可以被修改且可以获取比需要更大的数据量。当无效时，事务的特征必须不能修改。
ARCACHE[0]	Bufferable	当ARCACHE[3:1]无效时，此bit没有影响。当ARCACHE[3:2]无效且ARCACHE[1]生效时：- 如果此bit无效，读数据从最终目的地获取。- 如果此bit有效，读数据可以从最终目的地获取或从正在目的地前进的写数据。当ARCACHE[3]或ARCACHE[2]生效时，此bit可以用来区分write-through和write-back内存类型。

A4.4 内存类型

AXI4协议引入新的通过AxCACHE编码识别的内存类型名字。表A4-5显示AXI4 AxCACHE编码和相关的内存类型。在AXI3中一些内存类型有不同的编码，这些编码显示在括号中。
注意
相同的内存类型可能在读通道和写通道上有不同的编码。这些编码提供与AXI3 AxCACHE定义的向后兼容。在AXI4中，对特定的内存类型使用多个AxCACHE值是合法的。表A4-5显示了首选的AXI4值，括号中是AXI3的合法值。

表A4-5中未标注的值为预留值。

A4.4.1 内存类型要求

这部分指定每种内存类型所需的行为。
设备Non-bufferable
设备不可缓冲内存所需的行为是：

• 写响应必须从最终目的地获取。
• 读数据必须从最终目的地获取。
• 事务是不可修改的，参看A4-64页的不可修改事务。
• 读必须不能预取。写必须不能合并。
  设备Bufferable
  设备缓冲内存类型所需的行为是：
• 写响应可以从中间点获取。
• 写事务必须在最终目的地及时可见，正如在第A4-74页的事务缓冲中定义的那样。
• 读数据必须从最终目的地获取。
• 事务是不可修改的，参看A4-64页的不可修改事务。
• 读必须不能预取。写必须不能合并。
  注意
  两种设备内存类型都是不可修改的。在本协议规范中，术语“设备内存”和“不可修改内存”是可互换的。
  对于读事务，设备不可缓冲和设备可缓冲内存类型所需的行为没有区别。
  常规Non-cacheable Non-bufferable
  常规不可缓存不可缓冲内存类型所需的行为是：
• 写响应必须从最终目的地获取。
• 读数据必须从最终目的地获取。
• 事务是可修改的，参看A4-65页的可修改事务。
• 写可以被合并。
  常规 Non-cacheable Bufferable
  常规不可缓存可缓冲内存类型所需的行为是：
• 写响应可以从中间点获取。
• 写事务必须在最终目的地及时可见，正如在第A4-74页的事务缓冲中定义的那样。没有机制来决定写事务在其最终目的地处何时可见。
• 读数据必须从以下其中一个获取：
  — 最终目的地
  — 正在向最终目的地前进的写事务
  如果读数据从写事务获取：
  — 它必须从写的最新版本中获取。
  — 数据必须不能被缓存供以后读取。
• 事务是可修改的，请参见A4-65页的可修改事务。
• 写可以被合并。
  注意
  对于常规非缓存可缓冲读，数据可以从仍在向最终目的地前进的写事务中获得。该数据与同时传播到最终目的地的读写事务是不可区分的。以这种方式返回的读数据并不表示写事务在最终目的地是可见的。
  Write-Through No-Allocate
  Write-Through No-Allocate内存类型所需的行为是：
• 写响应可以从中间点获取。
• 写事务必须在最终目的地及时可见，正如在第A4-74页的事务缓冲中定义的那样。没有机制来确定写事务何时在最终目标可见。
• 读数据可以从中间缓存的副本中获取。
• 事务是可修改的，参看A4-65页的可修改事务。
• 读可以被预取。
• 写可以被合并。
• 读和写事务需要进行缓存查找。
• No-Allocate属性是一个分配提示，也就是说，出于性能原因，它建议内存系统不要分配这些事务。但是，不禁止分配读和写事务。
  Write-Through Read-Allocate
  Write-Through Read-Allocate内存类型所需的行为是和Write-Through No-Allocate内存所需行为是一样的。但在本例中，由于性能原因，分配提示如下:
• 建议分配读事务。
• 不建议分配写事务。
  Write-Through Write-Allocate
  Write-Through Write-Allocate内存类型所需的行为是与Write-Through No-Allocate一样的。但在本例中，由于性能原因，分配提示如下:
• 不建议分配读事务。
• 建议分配写事务。
  Write-Through Read and Write-Allocate
  Write-Through Read和Write-Allocate内存类型所需的行为是与Write-Through No-Allocate内存一样的。但在本例中，由于性能原因，分配提示如下:
• 建议分配读事务。
• 建议分配写事务。
  Write-Back No-Allocate
  Write-Back No-Allocate内存类型所需的行为是：
• 写响应可以从中间点获取。
• 写事务不需要在最终目的地可见。
• 读数据可以从中间缓存副本获取。
• 事务是可修改的，参看A4-65可修改事务。
• 读可以被预取。
• 写可以被合并。
• 读和写事务需要进行缓存查找。
• No-Allocate属性是一个分配提示，也就是说，出于性能原因，它建议内存系统不要分配这些事务。但是，不禁止分配读和写事务。
  Write-Back Read-Allocate
  Write-Back Read-Allocate内存类型所需的行为与Write-Back No-Allocate内存相同。但在本例中，由于性能原因，分配提示如下:
• 建议分配读事务。
• 不建议分配写事务。
  Write-Back Write-Allocate
  Write-Back Write-Allocate内存类型所需的行为与Write-Back No-Allocate内存相同。但在本例中，由于性能原因，分配提示如下:
• 不建议分配读事务。
• 建议分配写事务。
  Write-Back Read and Write-Allocate
  Write-Back Read和Write-Allocate内存类型所需的行为与Write-Back No-Allocate内存相同。但在本例中，由于性能原因，分配提示如下:
• 建议分配读事务。
• 建议分配写事务。

A4.5 内存不匹配属性

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

• 所有访问同一内存区域的master必须对该内存区域在任何层次结构上的缓存性有一致的视图。适用的规则是:
  地址域不可缓存
  所有master必须使用AxCACHE[3:2]都失效的事务。
  地址域可缓存
  所有master必须使用AxCACHE[3:2]任意一个生效的事务。
• 不同的master可以使用不同的分配提示。
• 如果一个寻址区域是常规不可缓存的，那么任何master都可以使用设备内存事务访问它。
• 如果一个寻址区域具有可缓冲属性，那么任何master都可以使用不允许可缓冲行为的事务访问它。
  注意
  例如，需要从最终目的地响应的事务不允许可缓冲行为。

A4.5.1 改变内存属性

特定内存区域的属性可以从一种类型更改为另一种不兼容的类型。
例如，属性可以从 Write-Through Cacheable更改为Normal Non-cacheable。此更改需要一个合适的流程来执行更改。通常，执行以下过程:
特定内存区域的属性可以从一种类型更改为另一种不兼容的类型。

1. 所有master停止访问这个区域。
2. 单个master执行任何需要的缓存维护操作。
3. 所有master使用新的属性重新启动访问内存区域。

A4.6 事务缓冲

对以下内存类型的写访问不需要来自最终目的地的事务响应，但需要写事务在最终目的地及时可见:

• Device Bufferable
• Normal Non-cacheable Bufferable
• Write-Through
  对于写事务，所有三种内存类型要求相同的行为。对于读事务，需要的行为如下:
• 对Device Bufferable内存，读数据必须从最终目的地获取。
• 对Normal Non-cacheable Bufferable内存，读数据必须从最终目的地或从正在向最终目的地前进的写事务
• 对Write-Through内存，读数据可以从中间缓存的副本中获取。
  除了确保写事务及时地向最终目的地前进外，中间缓冲区的行为必须如下所示:
• 能够响应事务的中间缓冲区必须确保，随着时间的推移，任何对Normal Non-cacheable buffable的读事务都传播到它的目的地。这种传播意味着，当转发一个读的事务时，试图转发的事务不能无限地继续下去，用于转发的任何数据也不能无限地持久。协议没有定义任何机制来决定用于转发读事务的数据可以持久化多长时间。但是，在这种机制中，读取数据的行为不能重置数据超时时间。
  注意
  如果没有这个要求，对相同位置的连续轮询可以防止缓冲区中保存的读取超时，从而防止读取向目的地前进。
• 一个可以保存和合并写事务的中间缓冲区必须确保事务不会无限期地留在它的缓冲区中。例如，合并写事务必须不能重置决定何时将写操作耗尽到最终目的地的机制。
  注意
  如果没有这个要求，对同一个位置连续写操作可以防止缓冲区中保存的写操作超时，从而防止向目的地进行写操作。
  有关这些内存类型的读访问所需行为的信息，请参见:
• 在A4-70页的Device Bufferable
• 在A4-70页的Normal Non-cacheable Bufferable
• 在A4-71页的Write-Through No-Allocate

A4.7 访问权限

AXI提供了访问权限信号，可用于防止非法事务:

• ARPROT[2:0]对读访问定义了访问权限
• AWPROT[2:0]对写访问定义了访问权限
  术语AxPROT统称为ARPROT和AWPROT信号。
  AxPROT[2:0]编码如表A4-6所示。
  

保护属性是：
无特权或特权
AXI主机可能支持多个级别的操作特权，并将特权的概念扩展到内存访问。AxPROT[0]将访问标识为无特权或有特权。
注意
一些处理器支持多级特权，请参阅所选处理器的文档以确定到AXI特权级别的映射。AXI能够提供的唯一区别是特权访问和非特权访问。
安全或非安全
AXI master可能支持安全和非安全操作状态，并将这种安全性的概念扩展到内存访问。AxPROT[1]将访问标识为安全或不安全。可以认为AxPROT[1]定义了两个地址空间，一个是安全地址空间，一个是非安全地址空间。这个信号可以被视为一个额外的地址位。必须正确处理安全地址空间和非安全地址空间之间的任何别名。
注意
定义这个bit，以便当它生效时，事务被标识为非安全的。此定义与Arm安全扩展实现中的其他信号一致。
指令或数据
该bit表示该事务是指令访问或数据访问。
AXI协议将此指示定义为提示。它并不是在所有情况下都准确，例如，一个事务包含指令和数据项的混合。本规范建议master设置AxPROT[2]为低，以指示数据访问，除非已知该访问是指令访问。

A4.8 遗留问题

AXI4引入了处理一些AxCACHE内存属性的附加要求。
在AXI4中，对同一个slave使用相同ID的所有Device事务必须相互排序。
注意

• 这种排序不是AXI3的显式要求。任何依赖于此行为的AXI4组件都不能连接到不显示此行为的AXI3互连。
• Arm认为，大多数实现的AXI3互连都支持要求的AXI4行为。
  该规范强烈建议任何新的AXI3设计都实现AXI4需求。
  对于AxCACHE bit名称和内存类型名称，AXI4要求使用新的术语。AXI3组件可以使用AXI3或AXI4名称。

A4.9 用例

本节给出内存类型使用的示例。

A4.9.1 设备内存类型的使用

该规范支持Device non-buffable和Device buffable内存类型的联合使用来强制写事务到达它们的最终目的地，并确保发出事务的master知道该事务何时对所有其他master可见。
一个被标记为Device Bufferable的写事务需要及时到达它的最终目的地。但是，事务的写响应可以由中间缓冲区发出信号。因此，发出master无法知道何时写入对所有其他master可见。
如果一个master发出一个Device buffable写事务，或者写事务流，然后是一个Device non buffable写事务，并且所有的事务使用相同的AXI ID，AXI排序要求强制所有的Device buffable写事务在响应给Device non buffable事务之前到达最终目的地。因此，对 Device Non-bufferable事务的响应表明，所有事务对所有master都是可见的。
注意
Device Non-bufferable事务只能保证完成具有相同ID的Device Bufferable事务，并且是相同的salve设备。