Rocket - tilelink - ErrorEvaluator

https://mp.weixin.qq.com/s/NkbW465NAmhDsETksd2M0g

 

介绍ErrorEvaluator的实现。

 

​​

 

1. 基本介绍

 

ErrorEvaluator用于判断请求（Request）是否符合某种模式（Pattern）。

若符合，则下游节点针对这个请求的响应消息中应该报告错误。

 

2. RequestPattern

 

​​

 

1) 测试方法：test: TLBundleA => Bool

 

a. 输入参数：TLBundleA，可以看出这个方法只能测试channel a的请求；

b. 返回值：Bool，返回测试结果，即是否满足模式；

 

2) 调用测试方法

 

根据RequestPattern的定义可以看出：测试方法是固定的，待测试的对象是变化的。需要测试某个请求时，直接把该请求传入RequestPattern对象的apply方法即可:

​​

 

3) 测试方法实例：overlaps

 

判断请求中的地址是否与指定的AddressSet序列中的某一个重叠：

​​

 

包含两个参数列表：

a. pattern: Seq[AddressSet]：预先指定的一组AddressSet；

b. a: TLBundleA：channel a输入的请求；

 

这里第一个参数列表命名为pattern并不合适，为了不与RequestPattern中的Pattern混淆，直接使用sets或者addressSets比较合适：

​​

 

使用的地方在AtomicAutomata中：

​​

 

4) 隐式类型转换：Seq[AddressSet] => RequestPattern

 

把一组AddressSet隐式转换为一个RequestPattern，意在简化RequestPattern的创建。如上面的overlaps的使用实例可以转换为如下写法：

​​

 

Desugar一下：

​​

 

3. TLErrorEvaluator

 

用于检测错误请求的LazyModule节点：

​​

 

1) 类参数

 

a. test: RequestPattern：用于匹配的请求模式；这里建议把test重命名为pattern，毕竟测试方法（test）已经封装在RequestPattern里面了，这里看到的是请求模式，而非测试方法。两者属于不同层次的概念，外层封装要对外屏蔽内部实现细节。

 

b. testOn: Boolean：If testOn is true, it will assert fail if these transactions do not already error.

c. testOff: Boolean：If testOff is true, it will assert fail if these transactions otherwise error.

d. deny: Boolean：deny的意义难以理解，使用的地方都使用默认值false，相当于不起作用，这里先不考虑；

 

2) d_error

 

​​

 

规范中channel d的d_error信号被拆分成d_corrupt和d_denied两个：

​​

 

两者的意义如下：

a. d_corrupt表示带数据的响应消息有错；

b. d_denied表示请求被拒绝；

 

d_denied有两重意义：

a. 如果有数据，意思与corrupt相同，即数据有问题；

b. 如果没数据，意思是拒绝请求（主观上）或者无法完成请求（客观上）；

 

3) diplomacy node

 

用于与上下游节点相连，这里对manager参数向上传递的函数managerFn进行了适配：

​​

 

A. mayDenyPut = true

 

表示Put消息的响应消息中的d_denied信号是否可能为真。

 

Put请求的响应是AccessAck，不包含Data，所以不能使用d_corrupt信号表示消息是否有错，而只能使用d_denied信号来表示。

 

因此模式匹配的结果只能注入到d_denied信号中，mayDenyPut可能为真。

 

B. mayDenyGet = m.mayDenyGet（deny = false）

 

表示Get消息的响应消息中的d_denied信号是否可能为真。

 

Get请求的响应是AccessAckData，包含Data，所以可以使用corrupt信号表示是否有错，而不使用d_denied这个信号。

 

因此模式匹配结果可以注入d_corrupt信号，mayDenyGet取决于下游节点的能力；

 

4) lazy module

 

实现请求模式匹配及其匹配结果使用的逻辑。

 

A. 成对的输入边和输出边

 

​​

 

B. 默认直连

 

ErrorEvaluator只在模式匹配时时才介入：

​​

 

C. 记录是否注入匹配状态信息的内存

 

​​

 

D. 当前匹配状态

 

​​

 

E. 记录匹配状态

 

​​

 

F. 是否注入匹配状态：d_inject

 

a. bypass：请求是否可以在同一个时钟周期内返回：

 

​​

 

b. d_inject

 

如果在同一个时钟周期内返回响应消息，inject_map中的信息还没来得及更新，需要使用inject_now的值：

​​

 

这里使用的是Mem，而非Reg。但是Mem也具有相同的特性，即写入的值需要等待下来一个时钟周期才更新：

​​

 

G. d_first/d_last/d_hasData

 

​​

 

H. corrupt

 

根据d_corrupt的定义，只有包含数据时，才注入模式匹配结果：

​​

 

I. denied（deny = false）

 

​​

a. 如果不包含数据，则注入模式匹配结果，因为不能使用d_corrupt信号注入模式匹配结果；

b. 如果包含数据，则不注入模式匹配结果，因为可以使用d_corrupt信号注入模式匹配结果；

 

J. detect：下游节点是否报错

 

A. d_detect（deny = false）

 

标识下游节点返回的错误，包括corrupt和denied两种错误：

​​

 

B. r_detect

 

r_detect是一个寄存器，存放d_detect的值：

​​

其中：

a. 当d_first为真即第一个beat时，r_detect中还没有存值（需要下一个时钟周期才能存入d_detect并生效），所以不能使用r_detect的值；

b. 当d_first为假即后续的beat时，r_detect也参与产生d_detect；因为规范规定，错误信号要一直拉高；

 

K. 错误的来源

 

总结下来，错误的来源有两个：

a. 下游报上来的错误；

b. 模式匹配产生的结果，因为注入到corrupt或denied信号中，所以也可以称为错误；

 

L. assert testOn

 

​​

assert的触发条件：

a. testOn = true；

b. out.d.fire();

c. d_last；

d. d_inject为真，即模式匹配成功；

e. d_detect为假，即下游节点未报错；

f. d_hint为假，即不是HintAck消息；

 

总结：模式匹配报错，下游节点未报错，则触发；

 

M. assert testOff

 

​​

assert的触发条件：

a. testOff = true；

b. out.d.fire();

c. d_last；

d. d_inject为假，即模式匹配失败；

e. d_detect为真，即下游节点报错；

 

总结：模式匹配未报错，下游节点报错，则触发；

 

N. testOn/testOff

 

两个assert综合在一起，即是要求模式匹配和下游节点同时报错。也就是可以检测到下游节点是否按照预定的模式报告错误，用以验证下游节点的实现是否正确。

 

4. deny

 

前面都使用deny的默认值false，相当于不存在的情况下进行分析。

这里考虑一下deny的意义，以及其值为true的情况。

 

1) 意义

 

结论：是否把模式匹配结果注入到所有响应消息的d_denied信号。

 

2) managerFn

 

​​

 

如果deny = false，即不把模式匹配结果注入到带数据响应消息的d_denied信号中，前面已经分析了。

 

如果deny = true，即把模式匹配结果注入到所有消息的d_denied信号中，那么Get消息的响应消息即AccessAckData消息中的d_denied信号也可能为真，即mayDenyGet = true。

 

3) d_inject

 

​​

a. 如果deny = false，是否注入取决于响应消息是否包含数据；

b. 如果deny = true，则无论响应消息是否包含数据，一定会注入；

 

4) d_detect

 

​​

 

如果deny = true，则模式匹配信息会注入到所有消息的d_denied信号中，此时只需要检测下游节点报告的d_denied信号，以与d_inject比对即可。

 

如果deny = false，则模式匹配信息不会注入到带数据响应消息的d_denied信号中，此时需要检测下游节点报告的d_corrupt信号。

 

5) 受deny约束的节点

 

ErrorEvaluator节点用于对下游节点返回的错误信息进行验证，那么两者的行为需要保持一致。具体而言，主是ErrorEvaluator节点，从是下游节点。也就是下游节点的行为需要符合ErrorEvaluator节点的要求。

 

所以deny首先约束的是ErrorEvaluator节点，然后间接约束下游节点。

 

当deny = false时，部分情况下d_denied信号中未注入模式匹配信息，那么下游节点返回的d_denied信号也不包含全部信息，所以需要检查下游节点返回的d_corrupt信号。

 

当deny = true时，d_denied包含所有情况下的模式匹配信息，那么下游节点返回的d_denied中应该包含全部信息，所以不需要检查下游节点返回的d_corrupt信号。

 

6) ErrorEvaluator对下游节点的要求

 

ErrorEvaluator对下游节点的要求从何而来呢？

只有一个，就是模式匹配。

 

所以模式匹配信息在哪里，就检查哪里。