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

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可以大大加速这一过程，它可以使团队将设计与断言综合起来，并实时或接近实时地运行测试。这种方案可以使约束随机测试的创建者涉及宽得多的网表，不仅能研究已知的案例，也包括未知的角落案例。
(本文由Cogo商城-IC元器件在线采购平台搜集整理，
浏览http://www.cogobuy.com/product/2-3-5-22.html了解更多详细信息)