【CHI】Ordering保序

本节介绍CHI协议所包含的支持系统保序需求的机制，包括：

• Multi-copy atomicity

• Completion response and ordering

• Completion acknowledgment

• Transaction ordering

一、 Multi-copy atomicity

CHI协议中所使用的memory model要求为multi-copy atomic，所有相关组件必须确保所有的write-type必须是multi-copy atomic。一个写操作被定义为multi-copy atomic必须满足以下两个条件：

1. 所有对相同位置的写入都是序列化串行的，也就是说，所有的请求者都以相同的顺序观察到它们，尽管一些请求者可能不会观察到所有的写操作。
2. 一笔写操作只有被所有Requester观察到后，才能被同地址的Read操作读出该值；

注意：在本规范中，如果两个地址的cacheline地址和物理地址空间（PAS）属性相同，则认为它们在一致性、可观察性和冲突性方面是相同的。

二、 Completion Response and Ordering

不管是同一个agent还是不同agents，为了保证当前transaction和后续的transactions之间的顺序，CHI采用Comp，RespSepData，CompData响应来保证。如下表所示：

1. 对于Requester访问Non-cacheable或Device区间的Read transaction，RespSepData或CompData响应可以保证当前的传输访问的endpoint范围 可以被后续的transactions观察到；
2. 对于Requester访问Cacheable地址的Read transaction，CompData或DataSeqResp响应可以保证当前的传输被后续任何agent发送的transactions观察到；
3. 对于Requester访问Cacheable地址的Read transaction，RespSepData响应可以保证没有更早之前的transactions将会发送snoop请求给这个Requester，之后的transactions需要发送snoop请求只有等到HN收到该笔read transaction的CompAck之后才可以；
4. 对于Dataless transaction，只能访问Cacheable memory空间，Comp响应就可以保证同地址的当前transaction可以被任何agent的后续transactions观察到；另外CleanSharePersist transaction，HN必须收到下游Persist节点的响应之后，才能往RN返回Comp；
5. 对于访问Non-cacheable或Device nRnE或Device nRE的Write or Atomic transactions，Comp或CompData响应可以保证同endpoint范围的当前传输可以被任何agent的后续transactions观察到；
6. 对于访问Cacheable或Device RE的Write or Atomic transactions，Comp或CompData响应可以保证同地址的当前传输可以被任何agent的后续transactions观察到；

注意：

endpoint address range取决于具体实现，通常的定义如下：对于外设，则是整个peripheral device区域；对于memory空间，则是整个cacheline大小；

对于EWA的Write transaction去访问Non-cacheable或Device空间，Comp不能保证同endpoint地址范围的该transaction被后续的transactions所观察到，如果需要确保保序，可以使用Endpoint Order来访问同一个endpoint address range；

三、Completion acknowledgement

对于Requester发送的transactions和其它Requester transactions产生的snoop transactions之间的相对保序关系是通过Completion Acknowledgment响应来确保的。这个可以保证在Requester的transaction之后的保序的snoop transaction是在Requester完成响应之后才被接收；

一笔transaction完成和发送CompAck之间的顺序如下：

1. RN-F在收到Comp、RespSepData或CompData、RespSepData和DataSepResp两者之后，才发送CompAck；
2. 除了ReadOnce*，HNF只有在收到CompAck之后，才会发送下一笔同地址的snoop transaction；对于CopyBack transactions，WriteData蕴涵着CompAck，因此HNF必须等到WriteData之后再发送同地址的snoop transaction；

这个序列保证了RNF按照相同的顺序  HNF发出到同一cacheline的 a transaction 和 a snoop的相同顺序接收到。这可以确保以正确的顺序观察到相同cacheline的事务。

除了ReadOnce*，以上这个机制保证了Requester收到Comp和发送CompAck之间，不能收到任何的同地址的snoop请求。

对于一笔transaction中CompAck是否使用是取决于ExpCompAck域，RN在合适需要将ExpCompAck置位且产生CompAck响应有如下规定：

1. 除了ReadNoSnp和ReadOnce*操作，RN-F其它所有读操作都需要发送CompAck；
2. RN-F允许但不要求ReadNoSnp和ReadOnce*命令发送CompAck响应；
3. 在StashOnce*、CMO、Atomic、Evict操作中，不能发送CompAck响应；
4. RN-I和RN-D允许但不要求在读操作中要包含CompAck响应；
5. RN-I和RN-D的Dataless和Atomic传输不能包含CompAck响应；
6. 保序的ReadNoSnp和ReadOnce*如果要使用DMT，那么必须使用CompAck响应；
7. 对于写操作，CompAck只能用于：

——WriteUnique和WriteNoSnp在要求OWO时；

——在HNF提供了Comp响应的CopyBack write事务，表明请求者不能发送CBWrData。当HNF提供了一个Comp响应时，请求者必须发送一个CompAck，而不管原始的ExpCompAck值如何。

HNF必须支持所有允许或需要使用CompAck的transactions。

SN不需要支持CompAck的使用。

请求者，如HNF或HNI与SNF或SNI通信时，不能发送CompAck响应。

下表展示了需要CompAck响应的请求程序类型，以及提供该响应所需的相应请求者类型：

Y ：Yes, required

N ：No, not required

H ：Dependent on transaction flow chosen by Home in response to the CopyBack Write request.

O ：Optional

- ：Not applicable

四、Transaction ordering

 未完待续。。