AMBA-CHI协议详解（八）

本文主要是介绍AMBA-CHI协议详解（八），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

AMBA-CHI协议详解（一）
AMBA-CHI协议详解（二）
AMBA-CHI协议详解（三）
AMBA-CHI协议详解（四）
AMBA-CHI协议详解（五）
AMBA-CHI协议详解（六）
AMBA-CHI协议详解（七）
AMBA-CHI协议详解（八）

---

2.7 Address, Control, and Data

  事务包括定义互连处理事务的方式的属性。其中包括地址、内存属性、snoop属性和数据格式。每个属性都在本节中定义。

  在本节中，除非另有明确说明，否则对写事务的引用既包括单个写事务，也包括相应的组合写事务。

2.7.1 Address

该规范支持:
  ●Physical Address (PA，物理地址) 为44~52bits，以1bit递增。
  ●Virtual Address (VA，虚拟地址) 为49~53 bits.

REQ和SNP报文Addr字段的说明如下：
  ●REQ channel: Address[(MPA-1):0]
  ●SNP channel: Address[(MPA-1):3]

“MPA”为支持的最大PA。

下表显示物理地址字段宽度与支持的虚拟地址之间的关系。

DVM的地址域段在下面章节会有描述。

Req_Addr_Width参数用于指定组件支持的最大物理地址(以bit为单位)。取值范围为44 ~ 52，不指定时采用默认值44。

2.7.2 Physical Address Space, PAS

  通过NSE和NS字段的组合来确定访问的PAS值。PAS编码如表2-11所示

  对于Snoopable事务，可以将PAS视为定义了四个地址空间的附加地址信息。必须正确处理不同物理地址空间之间的任何混叠。（Hardware coherency硬件一致性不管理四个地址空间之间的一致性。）

PAS编码要求如下：
  ●可以在任何Read、Dataless、Write and Atomic中取任何值。
  ●可以在PrefetchTgt事务中取任意值。
  ●不适用于DVMOp或PCrdReturn事务，必须设置为零。

2.7.3 Memory Attributes

  内存属性(MemAttr)由EWA (Early Write Acknowledgment)、Device、Cacheable和Allocate四部分组成。

EWA
EWA表示事务的写完成响应：
  ●可以来自互连中的中间点，例如Home节点。
  ●必须来自目标目的地的最终端点。

如果断言了EWA，则事务的Write完成响应可以来自中间点或端点。

如果EWA被取消断言，则事务的写完成响应必须来自端点。

允许实现不使用EWA属性，但不是必需的。在这种情况下，必须从端点完成。

EWA断言要求是：
  ●可以取任意值：
  —ReadNoSnp和ReadNoSnpSep
  —WriteNoSnp和WriteNoSnpDef
对于WriteNoSnpDef事务，期望响应来自最终目标端点，而不管EWA值如何。
来自中间组件的早期响应可能会阻止原始RN观察到来自最终端点的有效Defer响应，从而降低可延迟写事务的有效性。
  —CMO事务
  —Atomic原子事务

  ●必须断言：
  —非ReadNoSnp、ReadNoSnp的读事务或CMO事务。
  —非CMO事务的Dataless事务
  —非WriteNoSnp或WriteNoSnpDef 事务的写事务

  ●不适用：
  —在DVMOp或pcrreturn事务中必须设置为零。
  —可以在PrefetchTgt事务中取任何值。

Device
Device属性表示内存类型是Device还是Normal。

Device memory type
  Device memory type必须用于exhibit side-effects的位置（一个地址的变动可能会影响一段地址）。允许在没有exhibit side-effects使用Device内存类型。

Device memory type位置的事务的要求如下：
  ●读取事务读取的数据不得超过请求的数量。
  ●不允许从Device memory位置预取。
  ●读取操作必须从端点获取数据。Read不得将数据从写入转发到在中间点完成的同一地址位置。
  ●不允许将对不同位置的请求合并为一个请求，或将对同一位置的不同请求合并为一个请求。
  ●写操作不能合并。
  ●从中间点获得完成的对Device memory的写入必须使写入数据及时地对端点可见。

访问 Device memory必须使用以下类型，允许独占variants：
  ●对Device memory位置的读访问必须使用ReadNoSnp。
  ●对Device memory位置的写访问必须使用WriteNoSnpPtl、WriteNoSnpFull或WriteNoSnpDef
  ●允许CMO事务到Device memory位置。
  ●允许Atomic事务进入Device memory位置。
  ●PrefetchTgt事务不允许进入Device memory位置。MemAttr字段不适用，可以在PrefetchTgt事务中取任何值。

Normal memory type

Normal memory类型适用于没有 exhibit side-effects的内存位置。

访问Normal memory在预取或转发方面（prefetching or forwarding）没有与Normal memory内存相同的限制：
  ●一个有EWA断言的读事务可以从一个写事务中获得读数据，这个写事务已经从一个中间点发送了它的Comp，并且是相同的地址位置。
  ●写可以合并

任何Read、Dataless、Write、PrefetchTgt或Atomic事务类型都可以用于访问Normal memory位置。所使用的事务类型由要完成的内存操作和Snoopable属性决定。

Cacheable
Cacheable属性指示事务是否必须执行Cache查找：
  ● 当断言Cacheable时，事务必须执行Cache查找。
  ● 当取消Cacheable时，事务必须访问最终目的地。

Cacheable属性值要求如下：
  ● 必须断言：
  — 除ReadNoSnp和ReadNoSnp外的读事务。
  — 除了 CleanShared、CleanSharedPersist*、CleanInvalid、CleanInvalidPoPA和MakeInvalid的Dataless事务。
  — 除了WriteNoSnpFull、WriteNoSnpPtl、and WriteNoSnpDef的写事务。

  ● 绝对不能断言：
  — Device memory事务
  — WriteNoSnpDef事务

  ● 可以取任何值：
  — ReadNoSnp或ReadNoSnpSep事务到Normal memory位置
  — WriteNoSnpFull或WriteNoSnpPtl到Normal memory位置
  — CleanShared、CleanSharedPersist*、CleanInvalid、CleanInvalidPoPAa、MakeInvalid
  — Atomic事务

  ● 不适用的：
  — 在DVMOp和PCrdReturn中必须设置为零
  — 可以在PrefetchTgt中取任何值

在可以接受任何可Cacheable的事务中，该值通常由页表属性（page table attributes）确定。

Allocate
Allocate属性是一个分配提示，指示事务的推荐分配策略
  ● 如果断言了Allocate，出于性能原因，建议将事务分配到Cache中。但是，允许不分配事务。
  ● 如果取消Allocate，出于性能原因，建议不要将事务分配到缓存中。但是，允许分配事务。

Allocate属性值需求如下：
  ● 可以断言具有Cacheable属性的事务，ReadOnceMakeInvalid除外。（具体看附表）
  ● 必须为WriteEvictFull事务断言。（RN可以将带有未断言的Allocate位的WriteEvictFull转换为Evict事务。）

  ● 下面情况不能断言：
  — Device memory 事务
  — Normal Non-cacheable memory事务
  ● 下面情况不适用：
  — 在DVMOp、PCrdReturn和Evict事务中必须设置为零。
  — 可以在PrefetchTgt事务中取任何值

Propagation of Attr
  从Home节点到SN节点的响应请求必须保留MemAttr位EWA、Device、Cacheable和Allocate。此规则的唯一例外是当下游memory已知为Normal时，则可以将Device字段值设置为0b0以表示Normal。

  在组合写事务中，当写事务和CMO事务分开时，写事务继承原始组合请求的MemAttr和SnpAttr值。

对于由于从Home预取或从系统缓存中evict而在互连中生成的ReadNoSnp或WriteNoSnp：
  ● MemAttr的EWA、Cacheable、 Allocate必须设置为1。
  ● “Device”字段值必须设置为“0b0”，表示“Normal”属性。
  ● SnpAttr字段值必须设置为0，表示不可窥探。

2.7.4 Transaction attribute combinations

  下表列出了MemAttr、SnpAttr和Order字段值的合法组合以及相应的ARM内存类型。Order字段的详细描述后面会提到。

a. Order = 0b10只允许在ReadOnce*、WriteUnique、ReadNoSnp、WriteNoSnp、WriteNoSnpDef,和Atomic事务中使用
b. Order = 0b01不应用于保序。
c. Non-cacheable Non-bufferable是AXI的Memory类型，不是ARM的Memory类型。

Memory type

Device nRnE：（no Reorder no Early Write Acknowledgment）

Device nRnE内存类型要求的行为：
  ● 写响应必须从最终目的地获得。
  ● 读数据必须从最终目的地获得。
  ● 读取操作不能获取多于所需的数据。
  ● 读操作不能预取。
  ● 写操作不能合并。
  ● 写操作不能写入比原始事务更大的地址范围。
  ● 从同一源到同一端点的所有Read和Write事务必须保持有序。

Device nRE：
  ● 写响应可以从中间点获得。
  ● 读数据必须从最终目的地获得。
  ● 读取操作不能获取多于所需的数据。
  ● 读操作不能预取。
  ● 写操作不能合并。
  ● 写操作不能写入比原始事务更大的地址范围。
  ● 从同一源到同一端点的所有Read和Write事务必须保持有序。

Device RE：
  ● 写响应可以从中间点获得。
  ● 读数据必须从最终目的地获得。
  ● 读取操作不能获取多于所需的数据。
  ● 读操作不能预取。
  ● 写操作不能合并。
  ● 写操作不能写入比原始事务更大的地址范围。
  ● 从同一源到同一端点的读写事务不需要保持顺序。
  ● 从同一源到重叠地址的读写事务必须保持有序。

Normal Non-cacheable Non-bufferable：

Normal Non-cacheable Non-bufferable memory类型行为：
  ● 写响应必须从最终目的地获得
  ● 读数据必须从最终目的地获得。
  ● 写操作可以合并。
  ● 从同一源到重叠地址的读写事务必须保持有序。

Normal Non-cacheable Bufferable：
  ● 写响应可以从一个中间点获得。
  ● 写事务必须及时地在最终目的地显示可观察。（没有机制来确定Write事务何时在其最终目的地可见。）
  ● 读数据必须从以下途径获取：
   — 最终的目的地。
   — 正在向最终目的地执行的写事务。
   如果读数据是从写事务中获得的:
   — 它必须从最新的写入中获得。
   — 不能缓存数据以服务于以后的读取
  ● 写操作可以合并。
  ● 从同一源到重叠地址的读写事务必须保持有序。

对于Normal Non-cacheable Bufferable读取，可以从仍在向最终目的地执行的写入事务中获取数据。这与同时到达最终目的地的读取和写入事务无法区分。以这种方式返回的读取数据并不表示写入事务在最终目的地可见。

Write-Back No-allocate：
  ● Write响应可以从一个中间点获得。
  ● 写事务不需要在最终目的地可见。
  ● 读取数据可以从中间Cache副本中获得
  ● 读可以预取。
  ● 写操作可以合并。
  ● 读和写事务需要Cache查找。
  ● 从同一源到重叠地址的读写事务必须保持有序
  ● No-allocate属性是一个分配提示，也就是说，它是对内存系统的一个建议，即出于性能原因，不分配事务。但是，分配的过程是不被禁止的。

Write-Back Allocate：
  ● Write响应可以从一个中间点获得。
  ● 写事务不需要在最终目的地可见。
  ● 读取数据可以从中间Cache副本中获得
  ● 读可以预取。
  ● 写操作可以合并。
  ● 读和写事务需要Cache查找。
  ● 从同一源到重叠地址的读写事务必须保持有序
  ● 分配提示是对内存系统的建议，出于性能原因，分配事务。

2.7.5 Likely Shared

  LikelyShared属性是一个缓存分配提示。当断言此属性时，表明所请求的数据可能由系统内的其他请求节点共享。这是对共享系统级缓存的一个提示，即出于性能原因，建议分配缓存行。

没有与此事务属性关联的必需行为。

Likely Shared断言需求：
  ● 可以被断言
  — ReadClean
  — ReadNotSharedDirty
  — ReadShared
  — StashOnceUnique, StashOnceSepUnique
  — StashOnceShared, StashOnceSepShared
  — WriteUniquePtl
  — WriteUniqueFull
  — WriteUniqueZero
  — WriteUniquePtlStash
  — WriteUniqueFullStash
  — WriteBackFull
  — WriteCleanFull
  — WriteEvictFull
  — WriteEvictOrEvict

  ● 必须不能断言
  — 组合写事务。
  — Dataless或Atomic事务。
  — 其他的读或写事务。

  ● 不适用的
  — DVMOp或PCrdReturn事务，并且必须设置为零。
  — PrefetchTgt事务可以使用任何值。

2.7.6 Snoop Attribute

SnpAttr字段指示事务是否需要Snoop。

下表展示了SnpAttr 字段编码

显示不同事务类型的snoop属性。

a.不适用，SnpAttr 位在DVM事务中用作域标识符。
b.不适用，可以取任意值。

CMO、Atomic以及从Home到SN的ReadNoSnp和ReadNoSnp中的SnpAttr字段值必须设置为零，与从原始RN到Home的请求中的字段值无关。
在从Home到SN的写和组合写事务中，SnpAttr字段的位位置用于DoDWT字段。

对于可以接受多个SnpAttr值的事务，该值通常由页表属性（page table attributes）确定。

2.7.7 Mismatched Memory attributes

  允许使用不匹配的MemAttr或SnpAttr值对同一位置进行两次不同的访问。不匹配的MemAttr或SnpAttr值可能是预期的，也可能是意外的。它要求系统在任何一个实例中都不会死锁，并且事务总是可以正常进行。

为了帮助处理预期的不匹配的内存属性，互连：
  ● 必须确保一个Clean的Clean line，不管是UC还是SC，在一个一致性Cache中：
  — 如果该位置在被分配到完全一致的缓存后被另一个SnpAttr = 0的事务更新，对于使用SnpAttr = 0的事务访问该位置的请求者不可见。
  — 未写入主存。
  — 不用于覆盖下游Cache中的脏副本。

  ● 允许（但不是必需的）使Requester使用SnpAttr=0的事务写入的缓存行的脏副本对完全一致的请求者可见。
使用SnpAttr=0的事务访问该位置时，不得从Requester中删除脏Cache line的可见性。

  ● 允许（但不是必需的）使用SnpAttr=0的事务访问该位置，使完全一致的缓存中的Cache行（UD或SD）对另一个Requester可见。

  ● 一旦使用SnpAttr=0请求访问该位置的事务使完全一致缓存中的脏Cache line对Requester可见，则不得将其从该Requester的可见性中删除。

  ● 必须确保CMO不会在Unique line上命中而终止。

这是必需的，因为在系统的缓存层次结构中，唯一副本可能是过时的，而相同位置的其他脏副本可能存在于其他位置。

Reasons for mismatched attributes

不匹配的属性可能由于各种原因而发生：

Upgrading of Non-shareable Cacheable accesses

  将Nonshareable_Cache_Maint属性设置为True的完全一致的Requesters将对页表中标记为不可共享缓存的位置的所有访问升级为可共享缓存。

  将Nonshareable_Cache_Maint属性设置为False的完全一致的Requesters将使用SnpAttr=0的事务来访问这些位置。

With this upgrade：

  ● 当访问不可共享的可缓存位置时，完全一致的Requesters将使用SnpAttr = 1的事务。

  ● 所有被标记为不可共享缓存的位置的snoops都必须以相同的方式执行，就好像该位置最初在页表中被标记为可共享缓存一样。此外，系统中任何Requesters发出的CMO将对由完全一致的Requesters或互连者缓存的副本进行操作。

  ● 它使在页表中标记为不可共享的位置上的缓存维护可以由一个PE执行，而这个PE与导致分配到缓存中的PE不同。

  将这些位置设置为不可共享缓存比高带宽IO一致性Requesters（如GPU）更可取，因为GPU在所有事务上都不会遇到任何 snoop filter查找。

  当IO一致性Requesters使用非监听事务（如WriteNoSnp）对位置进行存储时，RN-F或互连中该行的upgraded版本可能会过时。

  互连的责任是确保cache lines的过时副本不会对不能观察到它们的Agent可见，并确保必须观察它们的Agent的可见性中不会删除缓存行的最新副本。

Software protocol errors

  来自不同Agent的内存访问，如果具有不匹配的snoopability或cacheability属性，则可以被视为软件协议错误。软件协议错误会导致一致性丧失，并导致数据值损坏。

  在一个4KB内存区域中访问的软件协议错误不能导致另一个4KB内存区域中的数据损坏。

  对于保存在Normal memory中的位置，可以使用适当的软件缓存维护来将内存位置返回到定义的状态。

  使用不匹配的内存属性可能会导致RN-F观察到Snoop事务到RN-F将使用或以前使用Non-snoopable事务访问的同一地址。如果RN-F接收到一个它认为不可监听的位置的Snoop，它就不能用数据进行响应，而是发送SnpResp_I。
当使用不匹配的属性时，Snoop事务和RN-F发出的事务之间没有定义的关系。

2.7.8 CopyAtHome attribute

  CopyAtHome (CAH)是一个cache line属性，Home可以使用它来优化冗余数据传输。在system caches既不是完全包容的也不是完全排斥的，但根据系统的行为调整其包含策略的拓扑中，它很有用。

  在对Requesters的CompData和DataSepResp响应中，CAH值指示Home是否保留该行的副本。CAH值与Requesters中的行一起缓存。如果行在本地更新，则必须重置cache的CAH属性。

  当Requesters对该行执行 CopyBack Write或Combined CopyBack Write 时，CAH值将随请求一起发送。Home可以使用CAH值来指示它检查它是否仍然有该行的副本，如果有，它可以请求在没有CBWrData传输的情况下完成CopyBack Write事务。

CAH usage at Home
在CompData或DataSepResp响应来自Home, CAH属性设置为：

1：
  如果Home表示它保留了该Cache line的副本。如果Home为Requesters提供了的Unique copy，则Home中的副本是隐藏副本，系统中的任何代理都无法观察到。如果隐藏副本是Clean的，Home可以在任何时候 remove它，除非在发送了comp并且相关的comppack仍然未完成的窗口期间。如果它是Dirty的，Home是不允许删除隐藏的副本的行。

0：
如果Home不打算保留该行的副本或不支持优化的CopyBack Write流程。

当Home接收到之后的CopyBack Write请求时，它可以检查CAH属性以建立用于完成事务的事务流变化。下表展示了 CopyBack Write事务在Home中的CAH属性使用情况。

Request CAH value	CopyBack Write transaction	Description
1	WriteBack, WriteClean, or WriteEvictFull	Home可采取下列其中一项措施: ● 使用CompDBIDResp响应以请求事务的写数据。 ● 检查它是否仍然有该行的副本: 如果Home有这一行的拷贝   期望Home使用Comp响应，请求在不传输数据的情况下完成事务，但不是必需的。如果Home不发送Comp，它必须发送CompDBIDResp，以请求事务的写数据。 如果Home没有该行的副本  Home必须使用CompDBIDResp响应以请求事务的写数据
	WriteEvictOrEvict	Home允许执行以下操作之一： ● 使用CompDBIDResp响应以请求事务的写数据。 ● 使用Comp响应，请求在没有数据传输的情况下完成事务。 如果Home有这一行的拷贝   期望Home使用Comp响应，请求在不传输数据的情况下完成事务，但不是必需的。如果Home不发送Comp，它必须发送CompDBIDResp，以请求事务的写数据。 如果Home没有该行的副本  Home必须使用CompDBIDResp响应以请求事务的写数据
0 or Not checked	WriteBack, WriteClean, or WriteEvictFull	Home必须使用CompDBIDResp响应以请求事务的写数据。
	WriteEvictOrEvict	Home可采取下列其中一项措施： ● 使用CompDBIDResp响应以请求事务的写数据。 ● 使用Comp响应，请求在没有数据传输的情况下完成事务。

如果Home发出Comp而不是CompDBIDResp，它必须看到来自 Requester 的以下CompAck响应才能完成CopyBack Write事务。
（该表在后面章节会详细描述）

CAH usage at Request Node

Requester 或Snoopee以下方式处理CAH属性：

  ● 如果在CompData或DataSepResp响应中CAH属性的值为1，则允许(但不是必需) Requester 缓存CAH的值为1。
  ● 如果在CompData或DataSepResp响应中CAH属性的值为0，则Requester 不得缓存CAH的值为1
  ● Requester 不需要缓存传入的CAH值。如果没有缓存CAH值，则必须假定该值为0
  ● 当line或MTE tags是updated时，缓存必须将CAH属性清除为0。
  — 可以在任何时候将缓存中的CAH属性清除为0。（但是，如果不必要地清除缓存的CAH属性，则无法减少CopyBack write事务的写数据带宽。）
  — Requester 在发送WriteClean请求时不需要将CAH属性清除为0。
  ● 当Requester 有一条CAH值为0的cache line时，它不能发送将请求中的CAH属性设置为1的CopyBack事务。
  ● 当Requester 具有CAH值为1的cache line时，期望(但不是必需)发送CAH属性为1的CopyBack事务。发送了将CAH属性设置为1的CopyBack请求后，在事务完成之前，Requester不得进一步修改cache line。
  ● 在为 forwarding snoop提供CompData响应时，期望(但不要求)Snoopee将CAH值转发给Requester。如果Snoopee不转发CAH值，则在CompData响应中必须将其设置为0。
  ● 当向Home提供SnpRespData或SnpRespData以响应snoop时，期望Snoopee发送CAH值，但不是必需的。如果Snoopee不发送CAH值，则必须在数据响应中将其设置为0。

  对于CopyBack Write事务，CompAck响应中的Resp字段值是适用的，并且必须指示发送CompAck响应时Cache的状态。如果在CopyBack Write未完成时收到Snoop请求，则cache line状态可能与发送原始事务时的cache line状态不同。

Home必须使用CompAck响应中的cache line状态信息来确定是否可以公开它所拥有的该行的任何隐藏副本。关于Home可以对每个CompAck响应采取什么操作的详细信息，如下表：

Response	Resp[2:0]	Description
CompAck_I	0b000	表示CopyBack请求已被取消。 响应中的cache状态不精确，必须忽略。 不会暴露任何隐藏的本地缓存行副本
CompAck_UC	0b010	发送响应时Cache line状态为UC。 期望，但不是要求，任何隐藏的缓存行的副本都是公开的，除非Unique copy仍然存在于其他地方。
CompAck_SC	0b001	发送响应时Cache line状态为SC。 预期的，但不是必需的，任何隐藏的缓存行的副本都是公开的。
CompAck_UD_PD	0b110	发送响应时Cache line状态为UD。 传递更新内存的责任。 期望，但不是要求，任何隐藏的缓存行的副本都是公开的，除非Unique copy仍然存在于其他地方。
CompAck_SD_PD	0b111	发送响应时Cache line状态为SD。 传递更新内存的责任。 预期的，但不是必需的，任何隐藏的缓存行的副本都是公开的。

a.当CopyBack Write事务是WriteClean时，Requester中仍然可以存在唯一副本。

如果Home保存了一个Cache line的隐藏副本，并且后来确定该行不存在其他副本：
  ● 如果隐藏的副本是Clean的，则期望Home(但不要求Home)公开该副本。
  ● 如果隐藏的副本是Dirty的，则Home需要公开该副本。

这篇关于AMBA-CHI协议详解（八）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---