验证计划工作正迈向自动化

如果象某些研究报告指出的那样，功能验证已经占了IC逻辑设计流程的很大部分，那么当芯片规模达到1千万门甚至1亿门时会发生什么情况呢？

答案非常混乱，但有一点是明确的：功能验证过程必须变得更可管理化。一些专家们认为，以覆盖为驱动的验证(CDV)对今天的设计会有所帮助，但长期的答案需要在重新考虑验证和设计的基础上才能得到。

随着芯片复杂性的不断提高，可能会出错的事件的数量将呈指数式增长，因此验证非常有必要。能否在不雇用大量验证工程师去做指导性测试的情况下完成验证呢？

形式验证可以提供有目的的详尽测试，但它并不能覆盖全部范围。加速和仿真能加快验证过程，但工程师仍需要创建和监视测试过程。面对为数众多的设计类型、工具和验证技术，有一点是肯定的，即设计师必须要有计划。

验证计划要做的首先是确定哪些设计部分要测试以及如何做测试。计划中要确定被测设计需要使用的输入条件，并尽可能找出可能无法被仿真覆盖到的偏僻案例。另外，还必须在CDV基础上制定出测试进度的计划。

现在的工程师都很熟悉代码覆盖技术，它能通过检查发现是否存在未被执行到的代码。难度更大的新技术则是功能覆盖，它可用于检查各种偏僻案例，例如确定FIFO是空还是满。

由于功能覆盖可以提供反馈信息，因此随机测试生成更具实用性，能发现隐藏更深的缺陷。另外，基于断言的验证的崛起还可以提高断言覆盖率，配合其它技术，核查断言是否确实在起作用。

更高层次的抽象

但这仅仅是开始。一些观察人士认为，为了真正管理验证过程，有必要转向更高层的抽象，并应起始于系统级而非模块级。还有些人认为必须改善设计过程本身，使得首次输出存在更少的缺陷。

正如Janick Bergeron的“编写测试平台：HDL模型的功能验证”一书所述的那样，验证计划是概括验证工作的书面性规范。它的主要内容是分割设计、为验证定义粒度水平、设定策略和工具，并回答也许是最难回答的问题：怎样知道验证何时完成？

“验证计划应该包括所有被怀疑会对设计构成风险的对象，”新思公司科学家、在线验证指导论坛主席Bergeron表示。这样才有可能确定验证这些对象所需的偏僻案例和覆盖点。Bergeron指出，目前拟制验证计划的工作绝大部分还是“手工作业”。

“这种计划一般以文字形式提供，”Cadence设计系统公司首席架构师Jay Lawrence表示 ，“目前拟制计划过程的自动化程度极低，因此我认为这对辅助工具来说是个很好的机会。”

正处于Cadence收购进程中的Verisity设计公司已经凭借VManager产品朝这个方向迈出了脚步。据Verisity公司负责验证过程自动化的高级副总裁Ziv Binyamini透露，VManager支持可执行验证计划格式。这使得它能够读写机器可识别的计划。

“VManager可以汇聚和控制包括仿真、形式验证和加速在内的许多不同验证任务的运行，然后收集来自功能、代码和断言等不同资源的覆盖数据。”Binyamini说。

光有验证计划、没有以覆盖为驱动的方法来对计划实施监视是毫无意义的，专家们指出。

Binyamini直接了当地说：“没有覆盖指导的验证就象盲人开汽车一样。如果你不知道怎样才能到达目的地，那么你就只能在原地打圈圈。”

确保设计质量是验证团队所面临的主要挑战，CDV正是解决这个挑战的答案，Bergeron表示。“用户运行上千个测试，但质量却得不到保证。”他说，“他们无法测试到偏僻案例。唯一可行的方法是用功能覆盖收敛环路，并验证要做的每个性能和偏僻案例是否都得到了执行。”

目前大多数设计人员正在使用代码覆盖工具，Bergeron指出。这些工具在代码中插入检查点以便判断结构句是否得到了执行。这些工具通常提供语句、路径、分支和表达式覆盖。

但代码覆盖不能识别丢失的代码或功能。这也是一些验证团队转而采用功能覆盖的原因。功能覆盖通过插入“覆盖点”来确保各种事件发生或不发生(如FIFO是空还是满)，确保特殊指令集通过管线，确保数据包经过设计的所有信道发送等。

明导资讯公司首席工程师Richard Ho认为，如果没有功能覆盖，设计师只能做指导性测试和已经想好了要做的测试。功能覆盖则提供了“受限随机驱动的”仿真方法。该方法能够进行随机测试，然后根据来自覆盖测试的反馈信息进行交互修改。

然而代码覆盖和功能覆盖都存在缺点，验证咨询师Brian Bailey表示。“代码覆盖可以让你知道你是否可以控制你的设计，但它不能告诉你你已经正确地获得了某行代码。”他说，“功能覆盖是一种观察性的方法。它能让你发现这个事件，但不会告诉你该事件发生的正确理由。”

有难度的测试

功能覆盖的问题在于它是一个手工过程。它必须靠人采用SystemVerilog、专有规范语言(PSL)或Verisity公司的“e”语言等中的结构句插入覆盖点，然后需要一个仿真器来翻译这些结构句。

“这样做的工作量很大。”新思公司的Bergeron说，“虽然可以使用模板加以简化，但实现非常困难。”

“这通常还存在10%到30%的仿真开销，”明导公司的Ho指出 ，“但从宏观的角度看，仿真开销相对于你不知道该做什么，更节省了时间。”

功能覆盖通常是验证工程师的工作，Ho表示，但他们一般不具备准确插入覆盖点的专业知识。设计师也许不会对此花心思。在最近的DesignCon会议上发表的文章中，Ho推荐了一个好方法。该方法采用一般由设计师插入的断言来确定设计中的功能覆盖点。

“断言与覆盖是事物的两个方面。”Ho表示。断言可以用来检查不良的行为，而功能覆盖点则用来指出想要的行为，他指出。该文讨论了设计师如何使用断言库自动插入覆盖点，获取事务覆盖点，以及使用PSL和SystemVerilog中有关断言和覆盖的属性。

将断言用于覆盖还有一个概念，就是“断言覆盖”，根据陈述对象的不同断言覆盖具有不同的含义。咨询师Bailey认为，理想情况下断言覆盖能够告诉你对象已经从头到尾成功地得到了验证，而实际使用时断言覆盖工具可能只是告诉你断言是否已经触发。

正如Ho指出的那样，从来没有触发的断言是“伪”真。因此我们需要一种方法，能够用来确保断言真正进入检查相关事件的状态。

Lawrence 表示，Cadence的Incisive验证套件能够报告某个断言离开故障状态的次数，还能确定断言是否触发、预置状态是否设置正确。但断言覆盖一般只对“实际的”断言有效，他说，而对描述从未发生的特定行为的断言无效。

形式验证新创企业Jasper设计自动化公司首席方法学家Harry Foster认为：“断言检查‘什么’，而覆盖检查‘怎样’。”断言定义了什么是必须检查的，而覆盖点描述需要什么样的输入激励来激活关键功能。

Foster是基于断言验证的倡导者之一，他表示不能肯定“断言覆盖”是什么意思，但是否有足够的断言用来检查设计是一种可能的意思，有时也被称为“断言密度。”

他指出，因为没有输入激励，形式验证不需要功能验证。尝试所有可能组合的数学模型是形式验证的基础。“人们真正需要的是针对书面断言的覆盖。”他说。

提高抽象层次

一些观察人士认为，从长远观点看，提升抽象层次是促进验证管理的最佳方法。提倡电子系统级(ESL)验证的Bailey坚持认为，基于模块的验证已经使EDA产业发生了倒退。“我们面临先有鸡还是先有蛋的问题。我们正在试图验证我们不知道是否需要验证的事物。”他说。

Dataquest公司首席EDA分析师Gary Smith一直在提倡人们使用“智能测试平台”。这是一种超级工具，它能自动分割设计，并调用最适合具体单元的验证工具。他认为这种先进工具肯定会出现在ESL验证领域，虽然工具的架构至今还没有定义好。

不过真正的解决方案也许涉及设计过程而非验证。在多个DesignCon小组讨论会上，参与者和听众都认为目前首要的是创建出更佳的设计。

“我们面临是发现缺陷还是从一开始就做正确的问题，”Jasper设计公司Foster说，“我们应该问一问我们在设计过程中能够避免多少缺陷，而不是在验证过程中发现多少缺陷。”

在是否能够以及如何改善设计才能减少验证需求的问题上存在不同的观点。Foster相信形式验证把握住了“边设计边验证”方法的精髓。如果他是正确的，那么验证管理问题的最终解决方案也许是与更好的验证工具完全不同的。

作者：葛立伟