在产生了有效的激励后，需要判断出不符合功能描述的行为。Checker就是用于查看DUT是否按照功能描述做出期望的行为，识别出所有的设计缺陷。

按照激励的生成方式和检查的功能点分布可以将验证划分为三种方式：

• 黑盒验证：验证环境不关注设计的内部，只需要将激励灌入DUT的外部接口，检查DUT的输出就足够了。测试成功与否只是根据一个输入是否得到一个正确的输出去判断。所以黑盒验证有个明显缺点就是在测试失败时无法更深层次地定位问题。而且无法根据DUT本身给出更合适的激励，可能难以发现一些较深的缺陷。
• 白盒验证：可以对DUT更底层的设计进行测试，通常参考模型逻辑非常简单，只需要植入监视器和断言来检查各个内部逻辑，测试发生失败时可以更快速定位到缺陷。这种验证方式的背后原则是，充分检查各个逻辑驱动和结构以后，就不需要测试它的整体功能了。所以在整体功能测试和数据一致性检查方面，白盒验证很难检查出来。而是DUT更新时，验证环境的维护成本偏高。
• 灰盒验证：结合了上述两种方式。将监视器、断言、参考模型一同用来完善验证。这种方式带来的好处有：1.监视器和断言可以有更好的透明度来着重检查DUT内的一些重要逻辑；2.参考模型已经有了断言检查局部逻辑的帮助，所以可以降低一部分精确度，而主要专注在输入和输出数据的比较上，以及整体的DUT功能。

我所接触的项目中，目前都是灰盒验证，所以本文讲下灰盒验证的checker。总体思维导图如下。

 对于检查DUT来说，需要我们的检查功能大体有：

• DUT的内部设计细节
• DUT的输入和输出
• DUT在架构上的角色

可以用到的检查方法有：

• 参考模型+比较器
• 断言
• 定向测试
• 形式验证

我们可以把checker分为三类：

• 常规检查：DUT在正常工作状态下的行为，一般伴随长时间的稳定工作。通过查看DUT的配置和激励判断DUT的工作状态是否符合预期。

• 异常检查：某一异常事件触发而使DUT做出的响应。主要就事件触发检查设计的响应。

• End of Check：仿真结束时的检查。

 综上所述，在分析checker时，可以按照“常规检查>>异常检查>> End of Check” 方向去分析。在常规检查内，可以按照“基于接口>>时序检查>>协议检查>>信号检查”和"内部结构>>沿着控制/数据路径>>配置情况" 这两方向去分析。在异常检查内，可以按照"时钟复位>>fault>>中断" 方向去分析。在End of Check中，可以按照“TB/DUT状态检查>>仿真日志检查” 方向去分析。34332原则。

参考文献: 芯片验证漫游指南