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对下游节点的要求从何而来呢？
只有一个，就是模式匹配。
所以模式匹配信息在哪里，就检查哪里。