日志

验证的计划篇之四：计划的进程评估

已有 2749 次阅读| 2016-10-16 22:19 |个人分类:验证系统思想|系统分类:芯片设计

在验证过程中，我们需要不断地更新验证的进度，从各项参数综合评估验证的完备性。在不同的验证层次过程中，我们通过收集以下信息来评估验证计划的实施进程：

递归测试通过率（regressioin pass rate）
代码覆盖率（code coverage）
断言覆盖率（assertion coverage）
功能覆盖率（function coverage）
缺陷曲线（bug rcurve）

接下来我们分别介绍上述信息的具体收集和分析过程。

递归测试通过率

一份递归测试表是将测试设计所有功能点的用例合并为一个测试集。递归测试表的主要功能就是用来在设计经过缺陷修复或者性能提高后测试原有的所有功能点，确保设计仍然可以正常工作。这种往复的测试方式不仅在于确保新的设计变化不会影响之前的功能，也可以用来避免新的对话对于别的模块造成的功能失效，所以，设计的维护不仅在于按照设计需求提供新的功能，而且也需要保证新功能不会影响原有的功能。

不同的公司和团队之间，往往有着不同的递归测试工具和方法，在这里需要注意的是工具和脚本的版本可能会对递归测试造成影响。例如，如果我们切换了仿真器的版本，那么可能会出现新的问题需要我们调试，所以在项目后期阶段设计区域稳定时，我们不建议切换工具或者脚本的版本。

另外一个重要的地方时，递归测试表中的测试用例需要确保是可以重现激励场景的。这一点对于直接测试方法（例如C/C++）是容易实现的，而对于随机约束测试而言，我们需要在测试中打印出每次测试用例使用到随机种子（random seed），只有通过这个特定的钟子号，我们才可以重新产生之前的激励，并且跟踪调试失败的用例。

我们将递归测试的流程归纳为下图，值得注意的是，如果在某一个层次的递归测试通过，我们接下来可以向上迁移到新的验证层次，展开新的递归测试流程，或者在设计需求发生变化时，重新从模块级开始递交测试表。

不同层次的递归测试表，每个测试用例的仿真时间消耗也不一样，一般而言，模块级是最快的，到了芯片级，一个递归测试表如果是数千级别的测试用例，往往需要若干天时间才能最终运行完毕得出结果。所以，不同层次，不同设计规模大小，不同测试场景复杂度，都会影响测试用例的仿真时间。递交测试表的重要因素就是仿真速度，由于考虑到递交测试表主要是计算资源的消耗和验证结构的性能表现，我们对验证平台的优化和运算资源都会在此时提出更高的要求，因为只有更快速地往复递交和得出结果，才能更快得知新的设计变动是否是可靠的。


代码覆盖率
代码覆盖率是用来衡量RTL代码是否被充分运行的指标，目前的仿真器也都提供方法来收集代码覆盖率，并且进行合并和分析。通过递归测试表，我们可以产生基于测试用例的代码覆盖数据，并且在递归测试完成后，通过合并数据，生成总的数据来分析各个模块的覆盖率情况。常见的代码覆盖率包括：
语句覆盖率（statement coverage）：指的是程序的每一行代码是否被执行过。
条件覆盖率（condition coverage）：指的是每个条件中的逻辑操作数被覆盖的情况。
决策覆盖率（branch coverage）：指的是在if, case, while, repeat, forever, for和loop语句中各个分支执行的情况。 
事件覆盖率（event coverage）：该覆盖率用来记录某一个事件被触发的次数。
跳转覆盖率（toggle coverage）：用来记录某个设计边界信号数据位的0/1跳转情况，例如从0到1，或者从1到0的跳转。
状态机覆盖率（finite stage machine coverage）：仿真器的覆盖率功能可以识别出设计中的状态机部分，记录各种状态被进入的次数，以及状态之间的跳转情况。

值得注意的一点是，仿真器在收集覆盖率数据的时候会牺牲一些运行效率，这是因为它需要对代码保持“更多的关注”，所以资源消耗要更多一些。所以，我们建议只有在需要收集覆盖率的时候，需要传入一些仿真命令触发覆盖率收集，而在更多情况下，不需要传入这些命令，也不需要编译带有支持覆盖率收集的仿真目标。

在项目执行中，我们一般会在模块级验证节点结束后开始收集模块级的代码覆盖率，而在芯片级验证节点结束后，收集芯片级的代码覆盖率。在两部分的数据都收集结束后，我们会进行这两个级别的覆盖率数据融合，生成总的数据库。一般项目中会有专人来负责收集和分析覆盖率，各个模块的覆盖率数据会分发给相应的验证人员，等待他们的分析、过滤或者添加新的测试用例，再次递交测试收集新的数据，以此往复，来提高总体的覆盖率。

通常，我们会比较关注语句覆盖率、决策覆盖率和跳转覆盖率，对于总体指标和各个模块在这三项覆盖率上也有相应的指标，只有至少达到了90%以上的覆盖率，才会有足够的信心进行分析下面的两类覆盖率。


断言覆盖率
断言描述本身也支持覆盖率收集，一般可以通过仿真或者硬件加速的方式来收集，也可以通过形式验证的工具来收集。在常见的仿真中，仿真器会记录断言的先决条件是否被触发，以及判断语句成功或者失败。

根据选择的验证方法不同，我们可以将断言覆盖率分为：
基于动态仿真或者硬件加速的断言覆盖率
基于形式验证的静态断言覆盖率

功能覆盖率
功能覆盖率是为了衡量设计的各项功能要求是否都实现了，并且按照预想的行为执行。功能覆盖率会关注设计的输入、输出和内部状态，通常它会通过如下组合的方式来描述功能覆盖率要求：
对于输入而言，它会检测数据端的输入和命令组合类型，以及各种控制信号与数据传输的组合情况。
对于输出而言，它会检测是否有完整的数据传输类别，和各种情况的反馈时序。
对于设计内部而言，需要检查的点会跟验证计划中需要覆盖的功能点相对应，通过组合或者时序的功能覆盖率来检查目标功能是否被触发、以及执行是否正确。

缺陷曲线
在验证过程中，我们会不断地发现新的设计缺陷，通过缺陷记录表或者已有的商业工具记录下来，进而提交给设计人员。设计人员在分析了缺陷，构思并修复了设计缺陷以后，也会修改该缺陷的记录，并且通知验证人员。验证人员会递交原有的递归测试，在有必要的情况下添加新的测试用例，直到所有的测试通过以后，才能宣布新修复的缺陷是成功的。

在缺陷被记录的过程中，我们通过时间坐标和特定时段的缺陷数量绘制出缺陷率曲线。在之前《验证的任务》一文中，我们就指出了缺陷曲线对于验证计划的影响，从下图中我们看到，如果我们可以尽早地将缺陷曲线增长状态收敛，这意味着我们后期发现缺陷数量和可能性也就越小。可有些时候，我们需要当心的是，如果到了验证后期，我们发现了一个基本功能存在重大缺陷，这就是一个危险信号，代表我们很可能在之前验证当中遗漏一些重要的激励部分。
至此，我们将用来评估验证进度的几种标准概括介绍完了。对于验证计划的制定，不仅仅是验证人员会参与其中，其它角色也会被邀请到会议当中。而到后来验证进度的更新和评估过程，则主要是验证人员和验证经理的在执行。实际项目的经在重复告诉我们，一份详尽准确、不断更新维护的验证计划是迈向成功验证的基石。在结束了本篇《验证的计划篇》后，我们会在下一篇章《验证的管理篇》中为你们更详细的带来验证管理和执行过程中需要注意的那些事儿，感谢你们对路科验证的持续关注。