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响应。

————————————————

版权声明：本文为CSDN博主「谷公子」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/W1Z1Q/article/details/104240820

CHI系列篇

更多AMBA CHI的知识请关注Arm AMBA 协议集专栏。