AMBA-CHI协议详解（一）
AMBA-CHI协议详解（二）
AMBA-CHI协议详解（三）
AMBA-CHI协议详解（四）
AMBA-CHI协议详解（五）
AMBA-CHI协议详解（六）
AMBA-CHI协议详解（七）
文章目录
2.6 Ordering
本节描述该协议包含的支持系统保序需求的机制。
2.6.1 Multi-copy atomicity
该协议中使用的内存模型需要多副本原子性（multi-copy atomicity）。所有兼容组件必须确保所有写类型请求都是multi-copy atomicity的。如果满足以下两个条件，则写操作被定义为multi-copy atomicity操作:
● 所有对同一位置的写操作都是序列化的，也就是说，所有Requester以相同的顺序观察它们，尽管有些Requester可能不会观察所有的写操作。
● 对一个位置的读操作不会返回写操作的值，直到所有Requester都观察到写操作。
在本规范中，如果两个地址的cache line地址和物理地址空间(PAS)属性相同，则它们在一致性、可观察性和冲突性方面（coherence, observability, and hazarding）被认为是相同的。
2.6.2 Completion response and ordering
下表显示Comp、RespSepData、CompData或Persist响应，它保证事务相对于来自同一agent或来自另一个agent的后续事务的排序。
| Transaction | Location | Response | Outcome |
|---|---|---|---|
| Read | Cacheable | CompData or DataSepResp | 从任何Agent到同一位置的后续事务都可以观察到该事务。 |
| Cacheable | RespSepData | 之前的事务不会向此请求程序发送Snoop。只有在Home接收到此事务的CompAck响应后需要时，所有后续事务才会发送snoop。 | |
| Non-cacheable or Device | RespSepData or CompData | 从任何Agent到相同端点地址范围的后续事务都可以观察到该事务。 | |
| Write or Atomic | Cacheable | Comp or CompData | 从任何Agent到同一位置的后续事务都可以观察到该事务。 |
| Non-cacheable or Device | Comp or CompData | 从任何Agent到同一端点范围的后续事务都可以观察到该事务 | |
| Dataless except for StashOnceSep and CleanInvalidPoPA | Comp | 从任何Agent到同一内存位置的后续事务都可以观察到该事务。 | |
| CleanSharedPersist | Comp | 之前写入同一内存位置的任何数据都是持久化的（persistent）。 | |
| CleanInvalidPoPA | Comp | 从任何Agent到任何PAS中相同内存位置的后续事务都可以观察到该事务。在其他物理地址空间中可能需要额外的Cache维护操作，以确保之前写入的任何数据对这些物理地址空间完全可见。 | |
| Combined Write | CompCMO (non-PoPA CMO) | 从任何Agent到同一内存位置的后续事务都可以观察到CMO、PCMO和写操作。 | |
| CompCMO (PoPA CMO) | 从任何Agent到任何PAS中相同内存位置的后续事务都可以观察到CMO和写操作。在其他物理地址空间中可能需要额外的Cache维护操作，以确保之前写入的任何数据对这些物理地址空间完全可见。 | ||
| Comp | 从任何Agent到同一端点地址范围的后续事务都可以观察到写操作 | ||
| CleanSharedPersistSep | Persist | 之前写入同一内存位置的数据被持久化。 | |
| Combined Write with Persistent CMO | Persist | 合并写中的数据写入将被持久化。在同一cache line上的所有早期写操作也将被持久化。 | |
| StashOnceSep | Comp | Completer接受请求，不会发送RetryAck响应。 | |
| StashDone | 从任何Agent到同一内存位置的后续事务都可以观察到该事务。 |
在组合有序写观察(OWO)写请求中，如果写被取消，即请求方发送WriteDataCancel，则不会对写数据进行所需的缓存维护。请求方必须重新发送写请求和CMO：
● 如果取消写入的合并请求是PCMO的写入，则：
— 合并请求的Persist响应并不表示写入数据是持久化的
— Requester必须与重新发送的写请求一起重新发送PCMO，或者在重新发送的写请求成功之后重新发送PCMO。
● 如果取消写入的合并请求是与CMO的写入，则：
— Requester必须重新发送CMO，要么与重新发送的写请求一起发送，要么在重新发送的写请求成功后发送。
———Note—数字硬鉴——————
● endpoint address range是由实现时具体定义的，典型情况：
— 外围设备的大小，用于外围设备的区域。
— 用于内存的区域的Cache line的大小。
Cacheable位置可以通过请求中的MemAttr[2] Cacheable位的断言来确定。
Non-cacheable或Device位置可以通过请求中MemAttr[2] Cacheable位的取消来确定。
————————————————
组件只有在保证所有观察者都能看到atomic操作的结果时，才必须给出compp或CompDBIDResp响应。
在取消的写操作中，Comp响应仅意味着事务循环已经完成，并且不会对写操作发起的一致性操作的完成做出任何声明。因此，Completer被允许在收到WriteDataCancel响应后立即发送一个Comp，而不依赖于写请求的处理或由于写而发送的任何snoops的完成。
2.6.3 Completion acknowledgment
由Requester发出的事务和由来自不同Requester的事务引起的Snoop事务的相对顺序通过使用CompAck响应来控制。
Read事务的完成和CompAck的发送顺序如下：
1、RN-F接收到Comp、RespSepData、CompData或RespSepData和DataSepResp后发送一个CompAck。
2、HN-F (ReadOnce*除外)在向同一地址发送后续Snoop之前等待CompAck。对于CopyBack事务，WriteData充当隐式的CompAck，HN-F在向同一地址发送Snoop之前必须等待WriteData。
此序列保证RN-F接收到事务的Comp和对同一缓存行的Snoop，其顺序与从HN-F发送的顺序相同。这确保以正确的顺序观察到同一Cache line的事务。
当一个RN-F有一个正在进行的事务使用CompAck时，除了ReadNoSnp和ReadOnce*，那么它可以保证在它接收Comp和发送CompAck的点之间不会收到到相同地址的Snoop请求。
对于需要CompAck消息的WriteNoSnp和WriteUnique事务，Request Node在收到Comp、DBIDResp或CompDBIDResp响应后发送CompAck。
在事务中使用CompAck是由Requester在原始请求中设置ExpCompAck字段决定的。请求节点设置ExpCompAck字段并生成CompAck响应的规则如下：
● 一个RN-F必须在除ReadNoSnp和ReadOnce之外的所有Read事务中包含一个CompAck响应。
● 允许RN-F在ReadNoSnp和ReadOnce事务中包含CompAck响应，但不是必需的。
● RN-F不能在StashOnce、CMO、Atomic或Evict事务中包含CompAck响应。
● 允许(但不是必需)RN-I或RN-D在读事务中包含CompAck响应。
● RN-I或RN-D不能在Dataless或 Atomic事务中包含CompAck响应。
● 想要使用DMT的请求节点必须在有序的ReadNoSnp和ReadOnce*事务中包含一个CompAck响应。
● 对于写事务，CompAck只能用于：
— WriteUnique和WriteNoSnp事务，当它们需要OWO保证时。
— CopyBack写事务，其中Home提供了一个Comp响应，表明请求者不能发送CBWrData。当Home提供一个Comp响应时，请求者必须发送一个CompAck，而不管最初的ExpCompAck值是多少。
对于请求节点和Home节点之间的事务，其中Home节点是完成者，Home节点必须支持对所有需要或允许使用CompAck的事务使用CompAck。
Subordinate节点不需要支持CompAck的使用。
请求者(例如分别与SN-F或SN-I通信的HN-F或HN-I)不能发送CompAck响应。
下图显示了需要CompAck响应的请求类型，以及提供该响应所需的相应RN类型：
在组合写事务中，CompAck要求与组合写事务中写类型的CompAck要求相同。
2.6.4 Ordering semantics of RespSepData and DataSepResp
当Requester接收到第一个DataSepResp时，它可以认为Read事务是全局观察的。这是因为没有任何动作可以修改接收到的读数据。
当一个Requester从Home接收到一个RespSepData响应时，它所应用的请求已经在Home进行了保序，并且RN将不会收到任何在它之前安排的事务的Snoop。在向Requester发送RespSepData响应之前，Home必须确保该Requester到同一地址没有未完成的Snoop事务。接收到RespSepData不能保证Home已经完成了对系统中其他代理的Anoop。
当Requester给出一个完成确认CompAck响应时，该Requester表明它将承担对在它之后安排的任何事务进行hazard snoop的责任。以下规则适用：
● 对于所有事务，除了下面立即描述的情况外，必须在收到RespSepData响应后发送CompAck。允许(但不是必须)在给出CompAck之前等待DataSepResp响应。
● 对于具有保序要求的ReadOnce和ReadNoSnp事务，也就是说，Order字段设置为0b10或0b11，并且断言了ExpCompAck字段，则需要仅在收到DataSepResp和RespSepData响应之后才给出CompAck。
● 在向同一地址发出另一个请求之前，RN必须等待接收到RespSepData和DataSepResp。
当只接收到DataSepResp时，要求不能给出CompAck。
2.6.5 Transaction ordering
除了使用Comp响应来排序来自Requester的请求序列外，该规范还定义了在Request节点、Home节点对和HN-I、SN-I对之间排序请求的机制。
在HN-F, SN-F对和HN-I, SN-I对之间，order字段用于获得请求接受的确认。
请求中的Order字段支持RN、HN对和HN- i、SN-I对之间的顺序。Order字段表明事务需要以下排序形式之一：
Request Order
这保证了从同一Agent到同一地址位置的多个事务的顺序。
Endpoint Order
这保证了从同一Agent到同一端点地址范围的多个事务的顺序。
Ordered Write Observation, OWO
这保证了系统中其他Agent对来自单个代理的写事务序列的观察顺序。
Request Accepted
这保证了Completer 只有在接受读请求后才会发送一个肯定的确认。
Order域段的编码
Ordering requirements
将事务的保序需求更改为更强的保序需求的Requester必须在其所有事务上将排序需求更改为Request Order t或者Endpoint Order。
Order字段必须仅在以下事务中设置为非零值:
● ReadNoSnp
● ReadNoSnpSep
● ReadOnce*
● WriteNoSnp
● WriteNoSnpDef
● WriteNoSnpCMO
● WriteNoSnpZero
● WriteUnique
● WriteUniqueCMO
● WriteUniqueZero
● Atomic
当ReadNoSnp或ReadOnce*事务需要 Request Order或Endpoint Order时：
● Requester需要一个ReadReceipt来确定何时可以发送下一个保序请求。
● 在Completer，ReadReceipt意味着请求已经到达下一个保序点，该点将按照收到的顺序维护请求：
— 对于需要Request Order的请求，它将在来自相同来源的相同地址的请求之间进行保序。
— 对于需要Endpoint Order的请求，它将维护来自相同源的到相同端点地址范围的请求之间的顺序。
● 能够发送单独的非数据和仅数据响应的Completer可以发送RespSepData响应而不是ReadReceipt，并实现相同的功能行为。
当WriteNoSnp, WriteNoSnpDef, WriteNoSnpZero或 Non-snoopable Atomic事务需要Request Order或Endpoint Order时：
● Requester需要一个DBIDResp或DBIDRespOrd来确定何时可以发送下一个保序的请求。
● Completer 发送一个DBIDResp或DBIDRespOrd响应意味着一个数据缓冲区是可用的，并且写请求已经达到了一个PoS（保序点），它将按照它们被接收的顺序维护请求：
— 对于需要Request Order的请求，它将在来自相同来源的相同地址的请求之间保持顺序。
— 对于需要Endpoint Order的请求，它将维护来自相同源的到相同端点地址范围（endpoint address range）的请求之间的顺序。
当没有断言ExpCompAck的WriteUnique事务、WriteUniqueZero或Snoopable Atomic事务需要Request Order时:
● Requester需要一个DBIDResp或DBIDRespOrd来确定何时可以发送下一个保序请求。
● Completer 发送DBIDResp或DBIDRespOrd响应意味着它将在来自相同源的相同地址的请求之间保持顺序。
此外，当Completer为没有order或Request Order的请求发送DBIDRespOrd时，Completer保证根据此请求将所有后续没有order或Request Order的同源同地址的请求进行排序，其中这些后来收到的请求是任何事务类型的，不一定是写入事务。当写入包含CMO时，可以保证顺序不受写入和CMO的影响。
当WriteUnique或WriteNoSnp事务需要 Ordered Write Observation时：
● CompAck是必需的。请求节点必须断言ExpCompAck。
● 请求节点需要一个DBIDResp或DBIDRespOrd
● Completer是Pos（保序点），PoS发送DBIDResp或DBIDRespOrd意味着：
— 数据buffer可用。
— PoS保证这次写入的一致性操作的完成不依赖于需要Ordered Write Observation的后续写入的一致性操作的完成。
— 在收到CompAck之前，写操作是不可见的。
当ReadNoSnp或ReadNoSnp将Order字段设置为0b01时，来自Completer的ReadReceipt响应保证Completer已经接受请求，并且不会发送RetryAck响应。
Read Request Order example
三个有序的ReadNoSnp请求从请求节点发送到Home节点：
1、RN向Home节点发送ReadNoSnp-1请求。
2、Home节点接受请求并向RN返回ReadReceipt -1响应。
3、收到ReadReceipt -1响应后，RN向Home节点发送ReadNoSnp-2请求。
4、Home节点不能立即接受ReadNoSnp-2请求，并向RN返回RetryAck-2响应。
5、在重发ReadNoSnp-2请求之前，RN现在必须等待从Home节点发送PCrdGrant。此时，RN不发送ReadNoSnp-3，因为它希望在ReadNoSnp-3排在ReadNoSnp-2之后。这个顺序要求在ReadNoSnp-3发送到Home节点之前，必须先在Home节点接受ReadNoSnp-2。
6、在收到适当的PCrdGrant后，RN重新发送ReadNoSnp-2请求。
7、Home节点接受请求并向RN返回一个ReadReceipt-2响应。
8、RN收到ReadReceipt-2响应后，向Home节点发送ReadNoSnp-3请求。（也就是通过ReadReceipt响应完成保序）
9、Home节点接受请求并向RN返回ReadReceipt-3响应。
10、每个读取事务都在RN接收到Comp和数据时完成。
上图中显示了一个来自Request Node的三个读的有序流。然而，一个请求节点可以有多个读流，所以请求必须在一个流中排序。然而，流之间不存在排序依赖。这种情况的一个例子是当流来自请求节点内的不同线程时。在这种情况下，请求节点等待来自同一线程的前一个请求的 ReadReceipt，然后才从该流发送下一个有序的请求。
CopyBack Request order
在向同一Cache line发出另一个请求之前，RN-F必须等待接收到未完成的CopyBack事务的CompDBIDResp或Comp响应。对于断言在CompDBIDResp或Comp响应收到到同一Cache line的未完成CopyBack之前发出SnoopMe的原子事务，允许这样做，但不是必需的。
Streaming Ordered Write transactions
用于提高OWO (Ordered Write Observation)写流效率的体系结构机制，以及相应的约束，只适用于WriteUnique和WriteNoSnp事务。
如果Requester要求按照与发出顺序相同的顺序观察一系列写事务，那么Requester可以等待完成一次写操作，然后再发出序列中的下一个写操作。这样的观察顺序通常称为Ordered Write Observation（有序写观察）。该规范提供了一种称为流式有序写(Streaming Ordered Writes)的机制，以更有效地对此类有序写事务进行流处理。
● Requester必须将Order字段设置为0b10，并在写请求上设置ExpCompAck。
● Write请求中的OWO要求向HN-F表明，这次写操作的一致性操作的完成不能依赖于后续写操作的一致性操作的完成。
● 在发送下一个写请求之前，Requester必须等待DBIDResp、DBIDRespOrd、CompDBIDResp或Comp来处理一个写事务。
● Requester必须在接收到对应写操作的DBIDResp、DBIDRespOrd、CompDBIDResp或Comp响应以及所有先前相关的有序写操作的Comp或CompDBIDResp响应后发送CompAck响应。如果要发送写数据，则允许(但不要求)Requester将CompAck响应与WriteData响应合并为NCBWrDataCompAck 响应。当Requester对事务使用组合的CompAck和WriteData响应时，它必须为该事务中的所有WriteData传输发送一个组合的响应。
—Note—————
等待发送CompAck响应，直到所有先前相关的有序写都收到了它们的Comp响应，以确保各自HN-Fs的操作已经完成。观察与CompAck响应相关的写操作的Requester程序也将观察所有先前相关的有序写操作。
————————
● 接收到DBIDResp并准备发送CompAck的Requester不能等待Comp发送CompAck
● HN-F必须等待来自请求节点的CompAck响应，然后才能释放写事务并使写对其他观察者可见。
Optimized Streaming Ordered Write transactions
此处的写操作仅指WriteUnique或WriteNoSnp。流有序写机制可以进一步优化。如果先前发送的写操作是针对不同的目标，则Requester在发送下一个有序写操作之前不需要等待该请求的DBIDResp请求。但是，如果互连可以重新映射TgtID，则Requester必须假定所有写事务都针对相同的HN-F，并且不得使用流式有序写流的优化版本。
使用优化或非优化的流有序写解决方案的实现必须避免死锁和活动锁情况。
—Note—————
避免与资源相关的死锁或活动锁问题的一种技术是将流式有序写优化（Streaming Ordered Writes optimization）限制为系统中的一个Requester。系统中的所有其他Requester都可以使用流有序写（ Streaming Ordered Writes）解决方案而无需优化。
在典型的系统中，优化的流有序写（optimized Streaming Ordered Writes）解决方案最有利于RN-I，它是PCIe风格、non-relaxed order、Snoopable writes。在大多数系统中，一个承载这种类型PCIe通信的RN-I就足够了。
通过使用WriteDataCancel消息来避免与资源相关的死锁和活动锁，OWO写操作可以被多个Requester使用。
————————
下图显示了一个典型的RN-I使用Streaming Ordered WriteUnique事务的事务流。（为清晰起见，在图中省略了Write-B DBIDResp流程和NCBWrData流程。）
这个流程可以防止在Write-A完成之前读取Write-B的新值。
Streaming Ordered WriteUnique事务流程如下：
1、RN-I向Home发出WriteUnique-A。
2、Home返回DBIDResp响应，并向RN-F1和RN-F2发出SnpCleanInvalid- A。
3、RN-I发送与WriteUnique- A相关的写数据，并向Home发出下一个有序的WriteUnique请求，如图WriteUnique- B。
4、WriteUnique-A和WriteUnique-B的地址不同。Home为WriteUnique-B向RN-F1和RN-F2发送SnpCleanInvalid-B侦听，而不等待WriteUnique-A事务Snoop的响应。
5、在接收到WriteUnique-A事务的Snoop响应之前，Home会接收到WriteUnique-B事务的Snoop响应。Home为WriteUnique-B事务向RN-I发送Comp
6、Home等待接收WriteUnique-A事务的Snoop响应。一旦收到，Home就可以将Comp发送给RN-I进行WriteUnique-A事务。
7、Requester RN-I接收到Comp-B，并在继续下一个响应之前等待收到Comp-A
8、一旦RN-I接收到Comp-A，它为WriteUnique-A事务发送相应的CompAck响应，随后为WriteUnique-B事务发送一个CompAck响应。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
