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
AMBA-CHI协议详解（十六）- Combined Write/Atomic transactions
AMBA-CHI协议详解（十七）- Snoop request types
AMBA-CHI协议详解（十八）- Response types
AMBA-CHI协议详解（十九）- Cache state transitions at a Requester
AMBA-CHI协议详解（二十）- Cache state transitions at a Snoopee
AMBA-CHI协议详解（二十一）- Hazard conditions
AMBA-CHI协议详解（二十二）- Read transaction flows
AMBA-CHI协议详解（二十三）- Dataless transaction flows
AMBA-CHI协议详解（二十四）- Write transaction flows/Atomic transaction flows
AMBA-CHI协议详解（二十五）- Stash transaction flows/Hazard handling examples

---

5.5 Stash transaction flows

本节展示了Stash transaction的示例互连协议流程：

5.5.1 Write with Stash hint

图中显示了带Data Pull的WriteUniqueStash事务流程的示例。

1. 请求节点向 HN-F 发送一个WriteUniqueFullStash请求，stash目标标识为 RN-F1（由StashNID指示）。
   通常，请求的请求节点是 RN-I。
2. HN-F 向 RN-F1 发送 SnpMakeInvalidStash，并向 RN-F2 发送 SnpUnique。
3. RN-F1 和 RN-F2 向 HN-F 发送 SnpResp 响应。RN-F1 的窥探响应还包括一个读取请求，即Data Pull。
4. HN-F 将 RN-F1 的读取请求视为ReadUnique，并向 RN-F1 发送合并的 CompData。
   CompData 响应包括请求节点写入的数据。
5. RN-F1 向 HN-F 发送 CompAck 以完成读取事务。

5.5.2 Independent Stash request

下图显示了一个带有Data Pull事务流的 StashOnce 示例。

1. 请求节点向 HN-F 发送 StashOnceShared 请求，stash目标标识为 RN-F1。
2. HN-F在为接收到的请求建立处理顺序后发送Comp响应，以确保在向稍后从任何请求者收到的同一地址请求之前处理该请求。
3. HN-F 向 RN-F1 发送 SnpStashShared 侦听请求，并向 SN-F 发送ReadNoSnp以获取数据。
4. RN-F1 向 HN-F 发送 SnpResp_I_Read 响应。
5. HN-F 将来自 RN-F1 的读取请求视为 ReadNotSharedDirty，并向 RN-F1 发送合并的 CompData。
6. RN-F1 向 HN-F 发送 CompAck 以完成读取事务。

5.6 Hazard handling examples

本节展示了如何在请求者处处理 CopyBack-Snoop 请求的Hazard条件（冲突），以及如何在 HN-F 处处理各种请求和Snoop请求的Hazard条件。

5.6.1 CopyBack-Snoop hazard at RN-F

下图显示了一个对RN-F的Snoop请求，该请求在时间C处Hazard了一个待处理的CopyBack请求。

1. 在时间C：
   • SnpShared事务忽略了该Hazard并读取了缓存行数据。
   • 缓存行状态从UD更改为SC。
2. 在时间D：
   • CopyBack的CompDBIDResp被发送到RN-F0。
   • RN-F0返回一个CopyBackWrData_SC响应。
   • 缓存行状态从SC更改为I。
   数据在一致性方面是clean的，不需要发送到互连以确保正确的功能。
   然而，协议要求CopyBack流程在snoop hazard的情况下保持一致。
   WriteData响应中的缓存行状态为SC，因为在发送WriteData响应时缓存行的状态就是SC。

注意：
• 对于与未完成的Evict发生冲突的Snoop请求，可以接收到的响应必须是SnpResp_I。
• 在对同一地址的Snoop请求的Snoop响应待处理时，唯一可以接收到的CopyBack请求的响应是RetryAck。这包括数据（如果适用）。

下图展示了一个Snoop请求与未完成的CopyBack请求发生冲突的进一步示例。 在这个示例中，Snoop请求是由于来自RN-F1的ReadOnce请求生成的SnpOnce请求。SnpOnce请求接收到带有Snoop响应的数据副本，但不改变缓存行状态。

5.6.2 Request hazard at HN-F

如果对同一缓存行的多个请求在 HN-F 处理，则 HN-F 可以以任意顺序选择下一个请求。 例外情况是当两个请求有排序要求并且来自同一来源时，必须要保证顺序。

下图展示了一个示例，其中一个ReadShared和一个ReadUnique针对同一缓存行，几乎同时到达HN-F。

1. 在时间A：
   • 来自RN-F0的ReadUnique到达，并对来自RN-F2的ReadShared请求造成hazard，而HN-F已经发送了嗅探请求。
   • ReadUnique的处理在HN-F处被阻塞。
2. 在时间B：
   • HN-F已完成来自RN-F2的ReadShared事务请求。
   • ReadShared事务被视为完成，HN-F解除对来自RN-F0的ReadUnique事务请求的阻塞。
   除了ReadNoSnp，如果图中显示的两个事务被任何读取请求类型或无数据请求类型替换，则流程类似：
   • 当以下两个条件都为真时，未使用 DMT 或 DCT 或分离的 Comp 和数据响应的读取事务请求在 HN-F 处完成：
   — 所有 CompData 已发送，并且（如适用）已收到 CompAck。 仅对在原始请求消息中断言 ExpCompAck 的事务要求 CompAck。
   — 如果需要，内存更新已完成。

5.6.3 Read - CopyBack or Dataless - CopyBack hazard at HN-F

在 HN-F 处，Read or Dataless请求与 CopyBack 请求之间的hazard 处理方式类似上面描述的Read-Read hazard

下图显示了在大约相同时间到达 HN-F 的ReadShared和WriteBack对同一缓存行的情况。

1. 在时间A：
   • WriteBack在HN-F处遇到hazard条件。hazard的原因是一个已经在进行中的ReadShared事务。
   • hazard检测导致WriteBack被阻塞。
   • ReadShared事务接收到带有Snoop响应的数据，并且必须在将数据发送给请求者的同时更新内存。
2. 在时间B：
   • WriteBack被解除阻塞，因为HN-F已将数据响应发送给请求者，并且为ReadShared事务向内存发送了WriteData响应。
   如果ReadShared请求在HN-F开始处理WriteBack请求后到达HN-F，则ReadShared请求将在WriteBack请求完成之前被阻塞。
   当以下两个条件都为真时，CopyBack请求在HN-F处完成：
   • 收到与CopyBack请求对应的数据消息。
   • 如果必要，内存更新将完成。

5.6.4 HN-F race hazard: Request and CompAck

Completion后，请求可能会静默地将缓存行从缓存中驱逐，并生成另一个对同一地址的请求（即相同的Txnid）。例如：

1. 重新生成的请求（下图Req2）在与早期Req1请求相关联的 CompAck 响应之前到达 HN-F。
2. HN-F 检测到地址Hazard，并在收到 CompAck 响应之前阻止新请求的处理。
   

在这种情况下，当 CompAck 响应到达 HN-F 时，它将从 HN-F 中解除分配先前的请求，并解除对新请求处理的阻塞。