AMBA-CHI协议详解（十四）

AMBA-CHI协议详解（一）- Introduction
AMBA-CHI协议详解（二）- Channel fields / Read transactions
AMBA-CHI协议详解（三）- Write transactions
AMBA-CHI协议详解（四）- Other transactions
AMBA-CHI协议详解（五）- Transaction identifier fields
AMBA-CHI协议详解（六）- Transaction identifier field flows
AMBA-CHI协议详解（七）- Ordering
AMBA-CHI协议详解（八）- Address, Control, and Data
AMBA-CHI协议详解（九）- Data transfer
AMBA-CHI协议详解（十）- Retry
AMBA-CHI协议详解（十一）- Network Layer
AMBA-CHI协议详解（十二）- Cache line states
AMBA-CHI协议详解（十三）- Read transactions and Cache line states
AMBA-CHI协议详解（十四）- Dataless transactions
AMBA-CHI协议详解（十五）- Write transactions

---

4.4.2 Dataless transactions

  请求节点使用无数据事务执行一致性操作，而无需从Requester处传输数据。无数据事务根据其共同功能进行分组，具体如下：

• CleanUnique, MakeUnique

• Evict

• Independent Stash transactions
  — StashOnceUnique, StashOnceSepUnique, StashOnceShared, StashOnceSepShared
• Cache Maintenance transactions

  — CleanShared, CleanSharedPersist, CleanSharedPersistSep, CleanInvalid, CleanInvalidPoPA, MakeInvalid

无数据事务具有以下共同特征：

• 完成响应中不得包含数据。
• 请求可能导致系统中其他代理之间的数据移动。
• 请求可能导致Requester的Cacheline状态更改。

CleanUnique
  请求对可Snoop地址区域的访问，将Requester的缓存状态更改为Unique，以便对缓存行进行store。 典型用法是当Requester拥有缓存行的共享副本并希望获得存储到缓存行的权限时。 在被Snoop的缓存中，任何dirty副本的缓存行必须写回内存。

MakeUnique
  请求对可Snoop地址区域的访问，在没有数据响应的情况下获得缓存行的所有权。
此请求仅在Requester保证将对缓存行的所有字节进行存储时使用。 在被Snoop的缓存中，任何dirty副本的缓存行必须在不进行数据传输的情况下失效。

Evict
  用于指示清除的缓存行不再被请求节点缓存。

StashOnceUnique, StashOnceSepUnique
  向可Snoop的地址区域请求，尝试将指定的缓存行移动到目标缓存，以使目标能够存储该行。请求包括：

• 另一个请求节点（RN1）的有效节点ID作为存储目标，以及该节点内逻辑处理器的可选ID（比如Cluster中又多个核就会有具体的LPID）。 当未指定有效目标时，指定的缓存行可以被提取以缓存到请求完成者处（HN）。
  -

• 建议但不要求对其他代理进行Snoop，以指示其获取指定的缓存行并确保其处于适合写入缓存行的缓存状态。

• 来自目标请求节点的DataPull请求被视为ReadUnique请求。
  

StashOnceShared, StashOnceSepShared
  向可Snoop的地址区域请求，尝试将指定的缓存行移动到目标缓存。请求包括：

• 另一个请求节点的节点ID。可选地，请求可以包含该节点内逻辑处理器的ID（LPID）。 当未指定有效目标时，指定的缓存行可以被提取以缓存到请求完成者处（例如HN）。
• 建议但不强制其他代理被监视，以指示它获取了所寻址的缓存行。
• 来自目标请求节点的DataPull请求被视为ReadNotSharedDirty。

Cache Maintenance transactions
  缓存维护操作(CMO，Cache Maintenance Operation) 协助软件缓存管理。 该协议包括以下五个事务，以支持缓存维护操作：

CleanShared
  CleanShared请求的完成响应确保所有缓存副本都被更改为非Dirty状态，并且任何Dirty副本都被写回内存。

CleanSharedPersist
  CleanSharedPersist请求的完成响应确保所有缓存副本都被更改为非Dirty状态，并且任何Dirty缓存副本都被写回Persistence点（PoP，例如断电可恢复内存）。

CleanSharedPersistSep
  对CleanSharedPersistSep请求的Persist或组合完成响应确保所有缓存副本都被更改为
非Dirty状态，并且任何Dirty缓存副本都被写回PoP。（CleanSharedPersistSep请求可以返回Comp和Persist的分离响应，也可以返回CompPersist组合响应）

CleanSharedPersistSep的功能类似于CleanSharedPersist，但允许请求者收到两个独立的响应。

在发送persistent CMO时，期望但不要求请求者使用CleanSharedPersistSep事务，而不是CleanSharedPersist。

这样的请求者必须支持接收独立的Comp和Persist响应以及组合的CompPersist响应。

CleanInvalid
  对CleanInvalid请求的完成响应确保所有缓存副本被失效。 该请求要求任何缓
存的Dirty副本必须写入内存。

CleanInvalidPoPA
  对CleanInvalidPoPA请求的完成响应确保在PoPA之前的所有缓存副本被失效。 该
请求要求任何缓存的脏副本必须写入超过PoPA的位置。这使得在一个物理地址空间（PAS）中的写入对其他物理地址空间可见。可能需要在其他物理地址空间中执行额外的缓存维护操作，以确保任何更新可见。

MakeInvalid
  对 MakeInvalid请求的完成响应确保所有缓存副本被失效。 该请求允许丢弃任何缓存的脏副本。

以下特征是所有六个 CMO 事务的共同点：

• Comp中的Resp字段值，表示缓存状态，必须被请求者和主节点忽略。
• 必须观察Cacheable和 SnpAttr 位值。
• 在接收到的请求中，Home上的MemAttr值必须在请求传播到SN时保留，除非已知从属仅具有Normal内存，在这种情况下，MemAttr Device位可以设置为Normal。
• Order字段不得被断言：
• — 针对特定地址的CMO必须在所有先前发送到同一地址且可以在请求者缓存中分配数据的
  事务完成之前，不得发送到互连。
  — 针对特定地址的事务，能够在请求者缓存中分配数据，必须在先前发送到同一地址的CMO
  完成之前，不得发送到互连。
  — 完成者可以等待WriteData以发送Persist响应，但不是必须的。 完成者可以提前发送Persist的
  示例是，当完成者不支持该内存位置的持久性或请求遇到非数据错误时。
• CMO被允许，但不是必须的，可以与同一地址的写入事务结合使用，当写入在CMO之前时。
• 当 Nonshareable_Cache_Maint 属性为真时，CMO 必须对在页表中标记为可缓存的位置进行操作，无论其是否被标记为非共享或共享。CMO 必须传播到任何根据共享性区分其条目的缓存。
• CMO 必须：
  — 传播到所有根据可缓存性区分的缓存。
  — CMO 必须对任何具有相同地址和相同 PAS 的缓存行进行操作。CMO 被允许但不要求对不同
  PAS 中的缓存行进行操作。必须确保在不同 PAS 中无效化脏缓存行是无害的。

Persistent CMO handling at Home
本节讨论主节点及其下游的PoP。

Point of Persistence at Home

• Home节点可以不将CleanSharedPersistSep请求转发给从属节点（SN）。当主节点决定不转发CleanSharedPersistSep请求时，必须向请求者返回Persist响应。
• 当主节点发送Persist响应时，可以但不要求，将其与Comp结合并向请求者返回单个CompPersist
  响应。

Point of Persistence downstream of Home
如果PoP在主节点下游，则对于CleanSharedPersistSep：

• 主节点必须将请求发送到下游。
• 从属节点必须在保证已接受请求并且不会返回RetryAck响应后，仅返回Comp响应。
• 当从属节点能够保证所有先前对同一地址在非易失性存储器中的写入都是持久的时，它还必须向请求者或Home节点返回一个Persist响应。即使在断电后，地址位置也将包含更新的值。
• 主节点从下游接收到Persist响应后，必须将Persist响应转发给请求者。
• 如果目标是易失性存储器，则可以立即给出持久响应。 这种情况必须不返回错误。

Deep Persistent CMO

  具有非易失性存储器的系统需要保证操作关键数据的保存，即使在电源和备用电池同时故障时。 通过向深度持久性点推送先前的写入，可以由系统提供保证。本规范通过在持久CMO事务上添加一个名为Deep的属性来支持此功能。

Dataless request attribute values

RN to HN：

HNF to SNF：

HN-I to SN-I：

Requester的初始缓存状态
发送请求时允许的请求者缓存状态

Requester的最终缓存状态
事务完成时请求者的允许缓存状态。

Peer cache state
在响应请求时，Home必须发送适当的Snoops，以确保对等缓存中的cache line是预期的或允许的最终状态。所以下面是相应事务传输后对等RNF的cache line状态。