对验证的量度：何时算充分？

Mentor Graphics公司首席验证科学家Harry Foster认为，今天的大多数设计经理要依赖于某种验证覆盖的量度来回答三个重要问题：我在哪里？去哪里？何时到？

　　但覆盖的量度有很多，它们来自各种工具，表示不同的事情。对设计经理来说，重要的是理解某个量度的真正含义。同等重要的是，经理必须能够将各种量度混合成为一幅图像，它将能够解答Foster的三个问题。最重要的是，经理必须正确回答第三个问题的另一版本：何时该停止？作决策不仅需要不同量度的结合，而且有赖于一个详尽的验证计划，这种计划在架构设计的早期就已存在，并伴随设计而成熟发展。

　　代码覆盖的概念（设计者从软件验证世界中借用的同一工具）很简单：当运行RTL（寄存器传输级）仿真时，只是维护一个1 bit宽的表，其表项是RTL源码中的各个代码行。一个仿真运行开始时，将表中的各位清零。第一次执行某行时，表中的相应位设为1。仿真结束后，就获得一个映像，它表示执行了哪些代码行，哪些行没有执行。如果某行没有执行，就能可靠地说你没有验证它。

　　专家把代码覆盖的概念推广到基于设计RTL视图的很多其它覆盖的隐式量度。你可以设计出有关RTL公式、分支或寄存器切换等覆盖的报告工具。并且，多数这类报告都可从商用仿真工具中获得，而无需设计专用的监控器。

　　代码覆盖量度的早期表现和易于使用的特点，使它们受到了大众的欢迎。Foster称Mentor公司的调查数据表明，大约一半设计团队在自己验证流中的某个地方有代码覆盖量度。但代码覆盖也有严重的问题。Synopsys公司研究员Janick Bergeron认为，主要问题是“结构的覆盖量度是必要的，但不足以决定验证覆盖”。Bergeron指出，代码覆盖中多数显而易见的问题是一种逻辑问题。你执行了一行RTL，并不意味着它做了你期望的事。

　　更精确地说，问题在于可观察性与完备性。当你执行这行代码时，它的结果是否传送到了一个你在这个仿真中实际观察的结点？如果不是这样，那么你就不知道代码是否做了你希望的事。Foster说：“我们见过有100%代码行覆盖的设计，但事实上，在仿真中只观察到70%代码行的运行。”

　　完备性是一个独立的问题。你执行了代码行。但你是否在所有可能激活的情况下都执行了它？如果在它不工作的情况下会怎样？

　　功能量度

　　这些缺点使很多团队采用功能验证。人们会问功能覆盖，有多少设计中的功能做了你预期要做的事。由于这种直观形式是经理们用于量度验证的最早方式，它也是很多团队的支柱。

　　Alcatel-Lucent公司光学部硬件研发技术经理Hans Sahm描述了这种基本方案的一个现代版。Sahm说：“我们从一个需求文档开始，采用内部开发的脚本，从需求生成一个验证计划电子表。这个表列出了功能需求，以英语表述，还有验证团队选来验证每个需求的测试案例。”这个电子表为验证团队提供了单一的文档，他们可以在运行仿真时用该表检查各种测试案例，因此就有了一个有关验证过程的逐项功能检查表。

　　这个概念构成了各种形式功能覆盖量度的支架，但它也受到严重的挑战。如Sahm指出的那样，“在一个功能需求和需要验证它的测试案例之间没有自动的链接。”要理解一种需求，并将其转化为充分覆盖该需求的测试，取决于验证工程师的技能和经验。

　　Mentor公司的Foster称：“思想不存在自动化。 ”

　　Altera公司首席验证架构师Jeff Fox表示：“在解译需求文档时总会存在一个问题。不同工程师在阅读相同文档时，对于功能的表现方式会有完全不同的想法。这就是为什么我们试图使自己的需求文档尽可能贴近可执行代码。它们必须是精确的。”

　　Synopsys公司的Bergeron也表示同意。他评论说：“当你建立验证一个功能的定向测试时，它是一个开环过程。你永远不能从结果去保证测试中不存在错误。”

　　为了解决这种对人类弱点的依赖性，最常用的技术是采用断言（assertion）和约束随机测试（constrained random test），这是Verisity公司（现在归Cadence公司所有）最初倡议的。据Mentor公司的调查数据，只有大约40%的验证团队在使用约束随机测试。相应地，大约40%团队在使用功能覆盖量度。从早期开始，出现了许多用于书写断言的专门语言，但业界现在似乎趋同于将System Verilog用于该目的。因此，我们正在看到一种新的形式：采用System Verilog的断言，测试断言的约束随机测试，以及表述为断言覆盖的验证量度。

　　对很多设计团队来说，这是个改良过程。Wipro Technologies公司半导体与解决方案业务部总经理Giri Raju描述了他的设计团队采用的路径。他说：“以前，我们只使用代码覆盖量度，跟踪一个手工制作的交叉参考表来管理验证工作。我们的目标只是100%的代码覆盖。我们已经分阶段地转到功能验证工具，并继续用手工表跟踪验证过程。现在，我们正转向System Verilog和Open Verificaton方法。”

  　　“现在仍需要大量工程技巧。验证工程师要判断验证的覆盖点，并与设计工程师一起复审，作为一次检查。我们相信自己可以将这个过程的80% ~ 90%实现自动化，但总会有某些情景下必须手动完成工作。不过断言覆盖验证量度确实对我们有帮助。我们的设计工程师现在已习惯在自己的代码中插入断言。”

　　生成断言覆盖量度过程的一个最大便利之处是能用FPGA（现场可编程门阵列）在System Verilog环境中作逻辑验证。较新的工具都允许验证工程师生成约束的随机激励模式，然后工具会在覆盖点跟踪采样数。Altera公司的Fox 说，FPGA可以大大加速这一过程，它可以使团队将设计与断言综合起来，并实时或接近实时地运行测试。这种方案可以使约束随机测试的创建者涉及宽得多的网表，不仅能研究已知的案例，也包括未知的角落案例。

　　它还实现了事务级覆盖的一种物理分类。例如，通过FPGA手段，验证工程师可以检查一个接口的运行，只需简单地将FPGA连接到一个良好的外部设备上，观察事务的情况。其想法是，如果接口能与其它芯片“良好地工作”，那么它就被100%覆盖。

　　形式工具

　　通过代码、功能和断言覆盖的量度，验证经理就拥有了很多数字，能给出验证完成的程度。当然，所有这些都留下了一些不能解答的问题。一些团队越来越多地采用形式验证工具，作为基于仿真技术的辅助方法。这些工具带来了一些自己独有的量度。

　　Alcatel-Lucent公司的Sahm称：“对那些最重要的模块，我们正在使用特性检查的形式工具。这种方法引入了特性覆盖（property coverage）的概念。实际上，我们使用的工具有自身内部的完备性检查能力，它会对特性覆盖等作出量度，以及在一个给定场景下是否已确定了每个输出状态。”

　　作为一种方法，形式工具给出了终极的保证。在运行结束时，你就拥有了以前违反所规定特性的全部反面实例。通过定义，可100% 地覆盖各种特性。但也存在着特性集如何完全覆盖设计预期的问题。于是就又回到了设计者的技能上，现在也许需求降低了，因为形式验证工具的学习曲线是出了名的困难。

　　融合数据

　　你可以看到，验证覆盖不存在固定的答案。各个工具都可以告诉你如何完整地转换 RTL代码结构，或如何完全地检查设计与验证团队编写的断言，或证实由形式验证专家定义的特性。但一个人工解析和创建的过程会将每个量度与设计预期分离开来。因此，很多设计经理会组合不同来源的覆盖量度，从而构成自己对验证过程的图像。

　　Foster说：“不同的团队有将覆盖数据组合为一个单一图像的不同方式。做CPU的经常只用功能覆盖的量度，但他们有做这种工作的资源。没有资源时，一些设计团队仍然只用代码行覆盖。但你也可以结合不同种类的数据。”

　　Foster建议一个团队可以从功能覆盖量度起步。当功能覆盖接近100%时，团队可以转向代码覆盖作为一种对完备性的检查。Altera公司Fox指出，这种方案可以使团队准确地确定功能覆盖中的漏洞。如果一块代码没有得到执行，那么它或者是死代码（设计团队应能通过检查确定），或者设计中的一些功能未得到覆盖。Fox说：“在这个地方，编写一些针对性测试。”

　　Fox强调了拥有不同来源数据的重要性。他说：“比如，我们最近正在做一个接口IP块。我们从三家供应商买进了第三方验证IP，让两个内部团队做验证过程。将他们在每个方案中发现的数据汇集起来做一些检查。”

　　寻找终点

　　即使像Fox这样有经验的经理，何时可以说验证完成了？可能有人会说验证永远没有尽头。但也有人可能回应说，当超过计划日程后，验证就完成了。不过，实用主义者的回答更加有趣。Bergeron说：“你永远不会结束。但可以在功能上达到一个商业成功需要的信心等级。这是一个风险管理问题。”

　　因此，Bergeron和Foster都认为，有经验的验证经理会查看多个来源的覆盖量度。商用工具可用于辅助这个过程，它按照结构块或按功能来组织各种量度，这样验证工程师就可以从一个设计区域看到所有量度。并且现在还有减轻这些融合过程的努力（见附文《UCIS确保互操作性》）。这个水平上的差异通常指出了验证计划中的漏洞，团队应用手工创建的专门测试加以弥补。

　　但经理还应看问题报告的频率。如果当覆盖量度接近100%时，问题报告频率在下滑，则一切正常。如果问题以一种恒定速率（或更差）持续上升，那么就有一些麻烦了。可是何时停止呢？大多数经理都同意下列观点：当你实际上确定了一些关键块时就能停止了。Sahm将“关键”定义为那些包括全新功能的块；不能在软件中简单处理的块；以及设计者缺乏经验的块。

　　Foster说：“尝试用覆盖量度，将设计中的风险限制在某些可修复块内，这是一种非常合理的策略。这些块可能有明显的软件工作区。它们可能有一堆不受约束的门，我们过去叫它们为‘快乐门’，设计者可以只用一些金属层作一些修补。或者这些块是实现新的算法，如果它们不工作，设计者只需简单地把它关掉。”

　　Foster总结说：“覆盖量度不能告诉你哪天完成工作。你可以看覆盖曲线。如果它们在离100%不远处走平，你可以改变自己的策略。如果覆盖中有大的漏洞，可以针对它们做工作。如果有很多小漏洞，就可能需要全面改变自己的策略，并且尝试形式方法，或针对分散区域的专门测试台。但你从量度就能看出要去哪里，以及下一步应达目的地。” 　　附文：UCIS确保互操作性

　　Mentor Graphics公司首席验证科学家Hany Foster说，今天流行的验证流程经常会采用一组各异的验证工具，从各种形式的仿真，到形式验证甚至模拟。每个过程都可能生成多种覆盖的量度，你用它们去测量一个过程的有效性，标记出那些可能需要注意的缺点。

　　今天流程的问题在于，一个过程中的任何工具都可能生成不连贯、重叠的覆盖量度，或者是一个不同工具可能生成一个量度的子集。此外，每个工具都以供应商确定的格式生成它的覆盖数据。即使对最完备的项目团队，要管理分析这些不同的覆盖数据集也会是一场恶梦。

图A来自很多工具的覆盖量度以及消费它们的几种客户

　　Accellera公司建立了UCIS（统一覆盖互操作标准），确保在多工具的异质验证流中收集、合并和解析覆盖结果时的互操作性（图A）。通过使用未来的Accellera UCIS API（应用编程接口）标准，多个验证工具将能够访问一个UCDB（统一覆盖数据库），概念上可以将其看作有全部覆盖数据的单一存储库。



　　附文：UCIS确保互操作性

　　今天流行的验证流程经常会采用一组各异的验证工具，从各种形式的仿真，到形式验证甚至模拟。每个过程都可能生成多种覆盖的量度，你用它们去测量一个过程的有效性，标记出那些可能需要注意的缺点。

　　今天流程的问题在于，一个过程中的任何工具都可能生成不连贯、重叠的覆盖量度，或者是一个不同工具可能生成一个量度的子集。此外，每个工具都以供应商确定的格式生成它的覆盖数据。即使对最完备的项目团队，要管理分析这些不同的覆盖数据集也会是一场恶梦。

　　Accellera公司建立了UCIS（统一覆盖互操作标准），确保在多工具的异质验证流中收集、合并和解析覆盖结果时的互操作性（图A）。通过使用未来的Accellera UCIS API（应用编程接口）标准，多个验证工具将能够访问一个UCDB（统一覆盖数据库），概念上可以将其看作有全部覆盖数据的单一存储库。