指示器有助于管理以覆盖为主导的验证项目

以覆盖为主导的验证项目如何能取得成功的和可预测的结论？本文将讨论有关此问题的一些基本要素。

首先，本文将描述什么是简单、清晰的指示器，接着介绍功能覆盖的定义、审查和编码，以便高效地使用指示器。文章的第三部分将讨论在运行以覆盖为主导的项目时验证管理解决方案的使用及好处。

图1:全局指示器图表示例

验证指示器

常言道，一幅图胜过千言万语，这也是本段要说明的内容。为了让验证和项目管理人员集中精力实现目标，有必要将验证项目定义成一幅图给他们看。我们所要呈现的图是对验证过程客观的和量化的描述。这幅基于全局和局部指示器图表的图将逐步反映项目进行的状态，以确保过程中的问题被尽早发现和纠正。

我们使用的全局指示器(图1)反映了整个验证进程。它可以告诉管理者目前我们所处的位置、应该达到的位置以及我们计划要前进到的位置。这个图表上表示的进程是每周运行故障率测试所达到的功能覆盖。

全局指示器的数据是基于在对所有功能一起仿真时所观察到的功能覆盖结果。在跟踪进程并提交想要的进程图之前，主要的一些负责人应对功能在总体指示器中的相关权重达成一致的认识。

每项功能的权重是根据功能的复杂度和优先级决定的。项目负责人可以使用这种方法开发可接受的指示器可靠性，并融入验证过程中。

一旦期望的图表发布后，每周测量就会提供可靠的指示器以及满足期望值的强烈动机。因为总体数量是在多种功能上收集的覆盖的函数，因此单个功能的延迟可以通驱动另外功能的前进得到补偿。这样即使某些个别功能出现频繁挫折，验证管理者和他们的团队也能保持整体过程的稳定性和可控性。

局部指示器图表设计用于指示每个性能的进度。规范一共分成20到40个小类，每个类都可单独跟踪。

图2：每个性能的进程图表示例

如图2所示，这幅图所要表达的是对每个性能进程的客观度量。由于这是由硬件验证语言(HVL)工具产生的客观性度量，数量无法把握，但问题很容易发现。

在提交局部指示器图表时，每个不满足期望值的性能都会被点亮，并必须配有相应的解释。因此项目管理人员可以很容易理解引起延迟的具体问题。在问题得到理解后，一些浅显的问题通常能够很快得到解决。

局部/全局图表有着深远的影响。那些为了提高覆盖率在一起工作的验证和设计人员都有一个切实的、可实现的小组奋斗目标。因为这是基本的项目指示器，因此可以集中精力确保问题的快速解决。随着各个性能同时向各自目标的稳定发展，会有大量积极的能量和问题解决方案相继涌现出来。

如何才能实现目标？

为了在客观度量基础上有效地跟踪项目，需要定义以覆盖为主导的验证计划。该计划应该在“功能覆盖点”方面提前定义好所有的验证目标。同时，必须从事件、数值和其它方面对设计中要求测试的每个功能作详细描述。

这一过程需要通过系统地审查被测器件(DUT)规范和相关文档才能完成，并可根据微架构功能覆盖设计小组的定义进行扩展。然后再仔细地检查前面生成的覆盖计划，确保它包含了所有要求的功能。达到计划中要求的覆盖率也就意味所有出带所需的功能测试要求都已得到满足。

当功能覆盖点定义好后，它们就能编码进HVL环境，以便随后测量它们完成的覆盖率。每个功能覆盖章节都是由一组功能覆盖点所定义的。这些章节再如前文所述的那样赋于权重，跟踪从此开始。

一旦完成覆盖计划并开始跟踪，重点就转移到覆盖率的完成。之所以称为“覆盖驱动的测试”，原因是从这点开始，覆盖结果将左右今后的所有活动。经过仔细分析覆盖和回归测试结果就可确定或重新确定验证努力的重点。

修复缺陷、减少约束条件和改善测试环境全都是达成覆盖率所要做的活动。同样，RTL缺陷、脚本问题、许可不足和计算资源等问题的解决也都要以突破减缓覆盖进程的障碍为中心。

在以覆盖为主导的项目中，每个验证工程师的工作重点都是想让他负责的性能达到满意的结果。由于功能覆盖是客观的、量化了的，因此工程师都受结果的驱动。当某个性能停止不前时，工程师就转移到下一个性能上工作。影响进程的问题被高亮显示，并被快速解决。

验证管理工具

管理以覆盖为主导的验证项目对质量、可预测性和资金回笼时间有着很重要的正面影响。然而，它将远远扩大传统的脚本和分析工具范围，留下大量手工作业要做。

应该使用验证管理自动化工具来提高这一过程的整体产能。这种类型的解决方案有以下一些性能：

• 运行和跟踪回归测试

• 分析覆盖率

• 优化回归测试

在以覆盖为主导的验证程序中，每天运行的仿真量通常增加10倍以上。仿真量增加一般是对已有资源的优化以便它们能够更好地得到利用。这样，通常在晚上和周末关机的工具和计算机必须不停地运转。这种量的增加虽然可以提供对设计和高质量缺陷的更深层覆盖，但需要管理的信息也随之大量增加。为了跟踪测试套件的完成、解析和分配故障以及验证故障的修复，管理平台必须提供必要的工具套件来处理大量的测试，从而减少个人的手工处理量。

采用管理自动化工具的验证小组中的每个工程师都有直接分配给他的故障类型列表。这意味着不管是根据错误类型还是测试名称，测试故障都是由工具自动分配给个人。

在整夜的回归测试后，所有故障都会根据故障类型分类，根据故障周期数排序，并分配给工程师调试和修复这些测试平台问题，或将故障再分配给RTL设计人员。当修复完成后，工程师会向工具明示修复已经完成。自动化工具将在随后的回归测试中通过重新运行仿真来验证所报告的每个故障修复。

分析覆盖率

随着项目的进展，重点将转向覆盖率的分析，为的是重点关注覆盖空白区和产生每周的指示器。为了提高精度，节省这类分析对管理人员和工程师的时间和资源要求，管理工具应该提供以下几方面的功能：

• 根据每个性能定义优先级和权重

• 为中间里程碑和对特殊性能感兴趣的用户确定远景规划

• 确定造成功能无法被覆盖的约束条件

这类分析工具将在管理阶段性项目中开启全新的可能性。例如，第一轮设计只是为了演示，那么只需验证少部分设计功能就能发布RTL。在这种情况下，只选择所需的覆盖点就能确定100%的覆盖率。

如果后续设计对时间而不是性能更敏感，那么覆盖设置定义可以只包括第一优先级的性能，把其它性能留给下一轮设计。总之，不同的负责人可以根据他们的优先级和观点监视覆盖率，同时验证人员可以把重点放在手头的目标上，无需设计多个分开的计划。

优化回归测试

到达以覆盖为主导的项目终点的瓶颈之一是产生覆盖所需的计算机时间和许可资源数量。管理自动化工具应该提供一种方法来确定达到覆盖率的最优测试。集中以这种方式运行的循环过程将有助于更快更高效地达成目标。

功能覆盖是随机测试效率的最好指示器。因此，运行成千上百次对覆盖率没有贡献的测试可能不是对资源的最佳利用。为了找到最佳的测试套件，应依据提供覆盖的效率对关键测试进行分级。

冗余测试可以取消，某些测试可以被标记为只运行一次或运行多次。这样将有助于找到以随机方式运行的最优回归测试，并且能用最少的测试覆盖最广的性能。随机运行这种回归测试可以显著节省资源。

在前文所述的覆盖前景基础上能够识别最优化测试套件的工具还能用来创建多个用于多种目的的小型回归测试。一个性能回归测试是所有测试的子集，它能以最少的运行次数覆盖完整的性能。

这种回归测试是在修改性能代码文件检查之前运行的。最小回归测试是确定每个性能仍然活动的高稳定测试的一个子集，一般在所有顶层或建模改变前使用。另外，如同前文例子那样，在小组决定后面重新发布RTL并想保持一致的质量等级情况下，第一次回归测试可以定义为保持100%的第一次输出覆盖率。

总之，管理自动化工具应该可以用来完成许多原本由验证团队和管理者手工完成的任务，同时在高效管理验证项目中寻找新的可能性。

作者：Akiva Michelson

首席技术官

Ace Verification公司