CHI DFX方法

本文描述CHI error handling、Data Source和Trace Tag。

一、Error Handling

本节描述CHI error handling需求，包含如下部分。

1.1 Error types

CHI协议支持在sub packet级的两种error reporting类型，和packet级的两种error reporting类型。
packet级的error reporting类型有：

• Data Error：用于正确的地址已经正确访问到，但是检测到里面的data有error。通常情况用于数据损坏被ECC或parity check检测到；DAT packet的RespErr、Posion和DataCheck域支持Data Error reporting；
• Non-data Error：用于检测到一个错误，但不是数据损坏相关的。CHI协议没有定义这种错误类型的所有情况。典型的，在以下情况会报该类型的错误：1. 访问的地址不存在；2. 错误的访问，例如对只读区域发起写操作；3. 企图使用不存在的transaction type。RSP和DAT packets的RespErr域支持Non-data Error reporting。

1.2 Error response fields

RespErr域用于指示error conditions。在response和data packets中都包含该域段。表1为RespErr域段的编码。
表1 Error response field encodings

一笔transaction不允许混合返回OK和EXOK响应；
一笔transaction允许混合返回OK、DERR和NDERR响应；
一笔transaction允许混合返回EXOK、DERR和NDERR响应。

1.3 Errors and transaction structure

不管transaction是否包含error response，都必须按照与协议一致的行为完成。
使用DMT的transaction的error handling和没有使用DMT相同请求的error handing处理流程一样。
requests或snoops没有机制传输errors，如果在ICN上检测错误，那么该request不能使用DMT或DCT。
如果transaction包含data packets，则需要data packets的源发送正确数量的数据包，但不要求数据值有效。
transaction中resp域的cache state可以被error handling影响。如果transaction的响应没有包含合法的cache state，那么RespErr域必须把所有data packets指示为Non-data Error。带没有合法cache state error信息的snoop response必须不能在response中携带数据。
不管是否存在error情况，data message的每个packet的Resp域在响应中必须有相同的值；
在Non-data error响应的Read data packets中，DataSource域段的值不用，且可以为任意值。

1.4 Error response use by transaction type

本小节描述用于每种transaction类型允许的error field。在下表中将会使用的一些关键字意思如下：

• OK：RespErr域必须包含OK RespErr的值0b00；
• Y：允许RespErr的值；
• N：不允许RespErr的值；
• -：该类型的Data或Response不需要；

1、Read Transactions
读传输包含多个CompData data packets，每个data packet可以使用不同的error类型，如表2和表3所示，有一个限制是一笔transaction不能混合有OK和EXOK两种responses。
表2 Read transaction’s Data and Response packets legal RespErr field values

表3 Read transac’s Data-only and Non-data packets legal RespErr field values

2、Dataless transactions
当其它component遇到data corruption error时，Dataless transactions可以用Data Error来反馈。data error将传递给原始component，尽管没有数据传输发生。表4为Dataless transaction packets合法的RespErr域段值。
表4 Dataless transaction packets legal RespErr field values

3、Write transactions
写传输可以包含要么Non-data Error，要么Data Error。Errors可以在两个方向传输，从Requester到Completer，或从Completer到Requester。
对于一笔写传输，Error可以通过CompDBIDResp或Comp响应从Completer传输到Requester。在处理transaction时，允许Completer在还没有收到WriteData之前就返回Error错误，例如在查找cache时遇到一个data corruption error。表5为Write传输响应合法的RespErr域段。
表5 Write transaction response packets legal RespErr field values

Requester可以检测到写数据error，并将其包含在write data packet中一块往下发，用于指示data value是否被损坏。表6为Write transaction data packets的合法RespErr域段值。

4、Atomic transactions
这里暂不描述。

5、Other transactions
本小段用于DVMOp和PrefetchTgt transaction的error handling需求。
DVMOp
DVMOp transaction可以在Comp响应中包含Non-data Error。对于DVMOp的所有snoop responses响应，ICN必须将它们合并成一个最终Comp，然后返回给Requester。DBIDResp packet必须只使用OK response。尽管WriteData响应的发送者可能没有使用DERR，但是如果在转换过程中遇到errors，data packet可以用于携带DERR。表7 DVM transaction packets合法的RespErr域值。
表7 DVM transaction packets legal RespErr field values

PrefetchTgt
发往不支持地址的PrefetchTgt transaction应该被丢弃掉。

6、Cache Stashing transactions
如果指定的stash target不支持接收Stash type snoops，那么HN必须忽视Stash hint，且按没有Stashing来完成transaction，例如：如果Stash targets是RN-I，RN-D，legacy RN-F，or Non-request node。在这些环境中，HN不能给Requester返回error信号。这样错误的指定Stash target可以归为软件错误。

7、Snoop transactions
Snoop transaction响应可以包含Data error的data响应。对于Snoop transaction的响应，可以在不同packets中混合包含Okay和Data Error响应。不带数据的snoop transaction响应可以用Non-data Error来指示。表8为Snoop request响应合法的RespErr域值。
表8 Snoop request response packets legal RespErr field values

Data Pull request的DERR响应，不期望出现在Stash request的Comp响应中。Snoopee给Request的完成响应带数据和snoop和fowarding snoop transaction一样可以包含error指示。当同时发生Forwarding data给requester和返回data给HN，如果其它response没有遇到错误，只允许一个response携带Data Error指示。
在数据发送给Requester，但还没有发送给HN情况下，SnpRespFwded允许包含Non-data Error错误指示。在Non-data Error的SnpRespFwded响应中，Fwdstate的值必须的发送给Requester中CompData的Resp域值一样。表9为forward snoop response packets的合法RespErr域段值。
表9 Forward Snoop response packets legal RespErr field values

表10为 Forward snoop Data response packets legal RespErr field values

1.5 Poison

Posion bit用于指示一组data bytes是否已经被损坏了。随DAT packet一块传输的Posion，允许告知后续使用data告知该data已经损坏了。
当支持Posion的话：

• DAT packet中，每64bits数据包含一个Posion；
• 在以下情况下Data可以标记为Posion：1. 不能被任何master使用；2. 被标记为Posion的话，其实也允许存到cache和memory中。
• Posion值一旦被设置了，就需要随data一块传输；
• 当检测到Posion error，允许跳过Posion data；

在64bit块中，如果有其他任何有效的数据，Posion必须精确。其它情况下，Posion bit可以不care，例如64bit，8Bytes全部无效，那么Posion的值bucare。
使用Data_Poison属性去指示是否一个组件支持Posion功能。

1.6 Data Check

DataCheck域用于检查DAT packet的data errors。当支持Data Check时：

• 在DAT packet中，每64bit的数据携带8bit Data Check；
• Data Check是通过奇偶校验的奇数字节产生的；

使用Data_check属性去指示是否一个组件支持Data_check。

1.7 Interoperability of Poison and DataCheck

如果Data packet的接受者不支持Posion或DataCheck特性，需要的话，ICN必须将其转换成DAT packet的Data Error。如果支持Posion和DataCheck特性，但接口不是相似的话，需要遵循如下原则：

• 如果Posion不支持的话，Posion必须映射成DataCheck或DERR。在这样的interface下，如果DataCheck支持的话，更期望将Posion映射成DataCheck，而不是DERR；在将Posion转为DataCheck的时候，8bytes块标记为Posion，每个DataCheck的8bits必须控制产生为parity error；
• 如果DataCheck不支持的话，DataCheck必须映射成Posion或DERR。在这样的interface下，如果支持Posion，更期望将DataCheck映射成Posion，而不是DERR；在将DataCheck转换为Posion的时候，在一个8byte chunk中，如果一个或多个DataCheck bits产生parity error，那么chunk的Posion bit必须置位。

注意：Posion和DERR的不同之处在于： 收到带Posion error的Data packet通常会被receiver推迟，但是DERR error通常不会被receiver推迟。
对在检测到Posion error时将其指示到Posion bits，对于Sender来说已经足够了，但是否将其RespErr置成DERR不是需要的。
对在检测到DataCheck error时将其指示到DataCheck bits，对于Sender来说已经足够了，但是否将其RespErr置成DERR不是需要的。
Posion和DataCheck的域段是独立的，一个类型的错误不要求另一个类型的域段置位；
在一个Data packet中，如果RespErr域段设置成DERR或NDERR，那么Posion和DataCheck的域段值不关心。

1.8 Hardware and software error categories

CHI协议定义了两种类型错误：software based error和hardware based error。
Software based error
软件错误通常是发生在多笔访问同一个地址的操作，确采用了mismatch的Snoopable或memory属性；
软件错误可以导致一致性功能失效和数据值的损坏。CHI协议要求在发生软件错误时不能有死锁，所有的transactions仍然可以及时进行；
对于访问一份4KB memory区间，软件错误不能导致其它4KB区间的数据损坏；
对于Normal memory空间的地址，使用恰当的stores和软件CMO操作可以使memory空间返回确定的状态；
在访问peripheral device是，不能保证peripheral的正常工作。唯一一点要求就是外设对于CHI的访问，要返回合乎CHI协议的response。事件序列可能用于将peripheral device返回到不正确的已知工作状态为，是根据具体实现决定的。

Hardware based error
任何不适软件错误的其它protocol error都归为硬件错误。
如果硬件错误发生了，那么不能保证错误能够修复，系统可能会崩溃、死锁，或遭受一些不可恢复的失败。

二、Data Source and Trace Tag

本节描述CHI中Data Source和Trace Tag的机制，用于给debugging和tracing of system和monitoring of performance提供额外的支持。包含如下小节。

2.1 Data Source indication

CHI协议允许Read request的Completer指定data的来源，是通过CompData、DataSepResp、SnpRespData和SnpRespDataPtl响应中的DataSource域段传输的，该域段设置在data error时也是有效的。

2.1.1 DataSource value assignment

DataSource的值必须按如下赋值：

• 当数据来源于memory的话，是采用固定值来指示如下信息：
  —— 0b110：PrefetchTgt memory的预取是有用的；读数据以更低latency从Slave获得，是由于PrefetchTgt request已经读取或触发从memory读取数据；
  —— 0b111：PrefetchTgt memory的预取是无用的；Read request仍然经历整个memory访问过程，因此没有因为之前PrefetchTgt的作用而使得有latency的缩小；具体为啥没有效果的精确原因是由具体实现决定的。注意：有几个原因可能导致PrefetchTgt request无效。1. prefet命令被Slave丢掉；2. prefetch数据被buffer替换掉；3. Read request比PrefetchTgt先到达Slave。
• 对于不是来自memory的response，即来自cache，DataSource的值由具体实现决定的。CHI协议推荐但不要求在以下情况使用设置DataSource的值。
  组件允许软件编程来重写DataSource的值：1. 将分组更改为更合适的指定配置设置；2. 将错误的值改变；
• Responder允许不支持发送有效的DataSource值：1. 除了访问memory SN-F，responder必须返回0b000值；2. memory SN-F组件允许返回0b111作为默认值；这种例外情况必须得到系统认定。

2.1.2 Crossing a chip-to-chip interface

如果存在across chip，需要将到来的Data packet的DataSource值映射成不同的值，用于标识响应是来自remote chip cache，这个功能应该是由chip interface module来完成的。chip interface module可能采用的方法示例为：

• 将remote cache打包成单一编码，如图1所示；
• 实现一个最大8个入口的查找表，用于将到来Data packet的DataSource域段的实现值映射成新值。

Suggested DataSource values
图1展示了multichip配置和对于系统中不同组件的DataSource映射建议值的例子：

• 系统中每个chip的每个cluster有两个processors，并带有三级cache；
• chip-to-chip接口module的cache和ICN内cache一致；
• remote peer chip的所有cache分成一组；
• non-memory组件不能编程去标识它自己，由于它可以返回的DataSource默认为0b000；

表11为建议的DataSource编码。


图1 Suggested DataSource values

2.1.3 Examples use cases

对于Requester如何使用DataSource信息有两个例子如下：

• 用于确定PrefetchTgt触发memory controller prefetch上是否有用；
  ——通过监控SN-F memory返回数据的DataSource值，Requester可以确定PrefetchTgt的有效性，然后调整PrefetchTgt的发送速率；
• 可以用于性能分析和调试软件用于优化数据共享模式；

2.2 Trace Tag

CHI协议在每个通道包含了TraceTag bit，用于提供·增强debugging、tracing和系统性能测量。

2.2.1 TraceTag usage and rules

合适设置TraceTag和怎样传输TraceTag域段的值按如下规则：

• TraceTag bit是由transaction的发起者或ICN组件设置的；
• 如果组件收到TraceTag置位的packet，必须将保留和反射该域值给任何响应的packet或衍生的packet；
• 如果接收到的置位的TraceTag packets衍生了许多response，那么每个衍生的response的TraceTag域段都要求置位。如果衍生的packet没有将TraceTag置位，那么该衍生packet和其它相关衍生packets是无关的；
• 如果一个组件可以收到一笔transaction的多个packets，对于每个packet产生的TraceTag值要求置位只和相应收到的packet有关，例如：
  —— 如果Comp和DBIDResp是分开返回的，那么RN的write transaction流程可能有WriteData和CompAck两个响应。由于CompAck是作为接收到Comp的响应，它的值必须和Comp packet的TraceTag的值有依赖关系，同样对于DBIDResp和WriteData的关系；如果Requester收到分离的DataSepResp和RespSepData响应，然后产生CompAck，那么CompAck的TraceTag只和DataSepResp有关。
  —— 如果Comp或DBIDResp的任何一个将TraceTag置位，那么NCBWrDataCompAck响应必须将TraceTag置位。
• 如果ICN收到一笔TraceTag置位的packet，那它必须要保留该值且不能将复位该值。

注意，以下列出一些Request-Response对的例子：

• Snoop request与snoop带或不带数据的响应；
• SnpDVMOp request与snoop响应；
• Read request和来自SN的Data response；
• HN-F产生的requests：1. Snoops generated in response to a request from RN；2. Request to SN-F generated in response to a request from RN；
• HN-I产生的requests：1. Read or Write request to SN-I generated in response to a request from RN；
• RN收到CompData、Comp或RespSepData后发送的CompAck；
• 对于任何请求，来自HN或SN的RetryAck响应；
• 对于Read request或ReadNoSnpSeq request访问SN，来自HN或SN的ReadReceipt；
• 对于Write request，DBIDResp响应。