验证的策略篇之五：检查的方法

本文转自：http://www.eetop.cn/blog/html/28/1561828-438326.html

我们在上一节《激励的原则》里面给出了几点用来评估激励自由度的方法，在这篇文中，我们则需要考虑在各种可能的激励组合下，如何选择适当的检查来完成一项核心要素：检查就是查看设计是否按照功能描述做出理应的行为，并且识别所有错误的输出从而发现设计缺陷。

 

对于激励我们是从接口类型来划分的，那么在检查阶段，我们划分则是基于被检查逻辑的层次，这些层次指的是：

• 模块的内部设计细节

• 模块的输入输出

• 模块与相邻模块的互动信号

• 模块在芯片系统级的应用角色

 

对于这些不同的检查层次，我们会考虑采用不同的方法来应对：

从上面这张方法选择列表里我们可以看出，经常使用的方法有监测器（monitor）、断言（assertion，用于仿真）、参考模型（reference model）、比较器（comparator/scoreboard）、直接测试和形式断言等等。至于常用的验证方法和工具，我们会在下一季的《验证的工具篇》给大家详细介绍，在这一篇中我们就主要的方法来看看我们之所以这样划分的考虑是什么。

一般而言，监测器（monitor）是一项必备的组件，有了它方便我们观察内部信号，所以你在各个层次都可以找到监测器的身影，而要查看设计内部信号，另外一个可行的办法是使用SystemVerilog绑定（bind）的特性。由于监测器可能被置入到各种方法中，我们需要本着复用的角度，在构建监测器的时候考虑如下的地方：

• 监测器一般跟激励发生器的作用域一致。这指的是，如果该激励发生器对应一组总线，那么也应该有一个对应的监视器来负责监视总线的传输。

• 监测器应根据检查的层次将信号检测分为模块内部和模块边界。

• 对于断言（assertion），我们主要依靠它检查模块的内部逻辑细节和时序信息。利用断言，我们可以通过仿真或者形式验证来测试对应的逻辑和时序。这里，是否选用仿真或者形式验证的方式，给的建议是：

• 如果是模块级别，断言通过形式验证完全覆盖设计的多数功能点从效率和完备性来看是可靠的。同时我们建议在子系统或者芯片一级创建基本的测试用例进行仿真，作为形式验证的补充。

• 如果断言验证的功能点较分散，或者主要是关切于模块的核心逻辑、时序的时候，我们倾向于使用仿真验证，采取灰盒模式，用断言来验证重要设计细节。

• 如果断言总体可以覆盖模块的所有设计功能部分，采取形式验证或者白盒仿真验证两种方法都是可取的。

 

参考模型（reference model）的构建除过待测设计本身的尺寸、复杂度以外，也跟验证方法有关。从之前《验证的透明度》来看，白盒验证对于参考模型的要求是最低的，而黑盒验证却会将最多的压力交给参考模型。

 

就比较器（comparator）而言，它的结构相对简单。一般依靠足够稳定的监测器和准确的参考模型，比较器只需要将检测的待测输出和参考模型的输出做比较，给出充分的比较信息。在测试用例结束的时候可以给出自定义的测试报告即可。

 

当模块完成了模块测试、子系统测试，迁入到芯片系统级测试以后，我们会在系统一级复用监测器和断言。这些从低层次复用来的监测器和断言在上层测试中主要覆盖于其它模块互动的功能点。同时由于在系统测试中，我们会采用直接测试从实际系统应用场景出发，写C或者汇编代码由系统中的处理器来执行。直接测试的另外一个好处是可以为硅后测试提供可以复用的测试代码。