但覆盖的量度有很多，它们来自各种工具，表示不同的事情。对设计经理来说，重要的是理解某个量度的真正含义。同等重要的是，经理必须能够将各种量度混合成为一幅图像，它将能够解答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（统一覆盖数据库），概念上可以将其看作有全部覆盖数据的单一存储库。