Hazard conditions
□ 此处描述RNF/HNF在处理snoopable trans的竞争冒险时各自承担的角色；
□ 除了有多个RN可以同时发送Trans, 协议也允许一个RN outstanding的发送多个trans;
□ Interconnect要保证对于这些访问相同地址的trans, 有一个固定的处理顺序，并且对于每个component, 这个顺序都是一样的；
At the RN-F node
■ RNF必须及时的响应收到的snoop（除了sync的snpdvm）, 而不应该和之前已经发送的请求之间，有任何依赖；
■ 如果RNF发出了一些命令，这些命令访问的地址和收到的snopp访问的地址相同：
■ 还没有收到data resp:
□ Snoop请求正常处理；
□ Cache的状态根据snoop的命令进行转换；
□ 如果snoop请求，需要数据，那么cached data, 或者copyback请求数据，必须要跟随snoop rsp返回给HN或者forward给RN;
■ 已经收到了至少一个data resp；
□ 必须等到接收完所有的data resp, 才能响应snoop;
□ 一旦所有的dataresp收到了：
□ 可以正常的处理snoop命令；
□ Cache状态根据snoop type进行改变；
□ 如果snoop需要数据，则cache data，要么跟随snp resp返回HN, 要么直接返回RN；
■ 如果之前发送的命令是copy back命令，那么要满足如下的一些额外需求：
□ 在收到compdbidresp之后，整个流程就结束了；
□ Write dataresp中携带的cache state, 应该是snoop处理完之后的状态，而不是发送copy back命令时的状态；
□ 如果snoop之后，状态已经是I or SC, 允许不再发送有效的数据；此时在write data resp中的cache state，必须是I, 并且BE全0；
□ Write data，要么和snoop时返回的数据相同，要么可以是比snoop data返回时更新的数据；但是当snoop为snponce, 且snp resp中状态为UC/UD时，上述规则不适用；也就是说，只有当snp中的状态，指示RN可以更改为新数据时，才满足该规则，当snp resp中的状态为UC/UD时，unique状态已经给别人了，这个时候就不适用了；
□ Non-ordered trans, RN可以不用等datasepresp, 直接发送compack;
□ Ordered trans, RN必须要等到收到第一个dataseprsp之后，再发送compack;
□ 上述两种场景下的读，RN都必须在收到所有的data之后，再响应snp;
□ RNF在发送一个copyback之后，还没有开始执行之前，会有可能收到多个snoop, 此时，data resp中的cacheline, 是最后一个处理的snoop后的状态；
At the ICN(HN-F) node
□ HNF通过按照一定顺序返回resp或者发送snoop request, 对收到的访问同一地址的trans进行排序;
□ 由于总线不保序，因此HNF实际收到的顺序，和实际的发送顺序，可能不一样；
□ HNF一旦开始发送resp, 则必须发送完所有的message, 而不能依赖其他请求或者resp的完成；
□ 同样，HNF在接收到部分数据后，必须无条件的继续接收剩下的数据，而不能依赖于之前的命令处理流程，或者其他的请求trans和resp;
□ 当snoop trans被pending的时候，只允许发送如下的resp:
• RetryAck for a CopyBack.
• RetryAck and DBIDResp for a WriteUnique and Atomics.
• RetryAck and, if applicable, a ReadReceipt for a Read request type.
• RetryAck for a Dataless request type.
□ 一旦某个请求的comp resp发送了，那么此时HNF不能再发送相同地址的snoop请求，直到下面情况发生：
□ 收到了read(except for ReadOnce* and ReadNoSnp)/dataless request的compack;
□ 收到了copyback/atomic request的write data;
□ 收到了writeunique的writedata或者compack;