编写测试平台-HDL模型的功能验证 第一章

第一章 什么是验证？

验证不是一个测试平台，也不是一堆测试平台。验证是一个证明设计[1]的功能是否正确的过程。验证贯穿于我们的日常生活中：对账，品尝炖菜，在地图上寻找标志物。这些都是验证的过程。

注[1]：设计就是可综合的HDL。

在这一章，我会介绍验证的基本概念，叙述验证的重要性、代价以及方法。我们会看到不同的测试方法之间的差异，以及测试和验证的差异。我会指出为什么验证是设计复用的关键。

1.1 什么是测试平台（testbench简称tb）？

在VHDL和Verilog中，测试平台通常被用于创建一些已知的输入信号到设计中，然后选择性地观察输出信号。测试平台一般用VHDL或Verilog编写，但是，它也包含外部的数据文件或C程序。

图1-1指出测试平台如何跟待验证设计（DUV）交互。测试平台提供输入信号到设计中，以及观察输出信号。请注意，这是一个完整的闭环系统：没有输入或输出信号[2]。测试平台作用于整个设计。验证的难点就是使用什么样的输入信号作用于设计，以及如何观察输出信号。

注[2]：在测试平台和DUV以外没有输入或输出。

                                图1-1

1.2 验证的重要性。

如果你看了一些Verilog或VHDL的教材，你会发现里面用很多章节介绍该语言的语法和语义，还有两到三章介绍可综合的代码风格或寄存器传输级（RTL）的子集。

很多时候，只有一章介绍测试平台，而且是一笔带过的。几乎所有的教材把测试平台局限于运用同步的方式产生简单的输入信号，然后用波形观察工具[3]观察输出信号。大量的篇幅介绍集成开发环境IDE[4]，以及语法和语义。

注[3]：常用的工具有Modelsim。

注[4]：常用的IDE有Quartus、ISE、Vivado。

你会觉得学习可综合的VHDL或Verilog代码，比测试平台更重要。事实上，并不是这样的。

在这个百万门级别的ASIC、可复用知识产权（IP），和SoC的时代，验证占了整个项目的70%工作量。一个开发团队，应该由架构师，验证工程师和设计工程师组成。其中，验证工程师的数量通常是设计工程师的两倍。每当完成项目后，验证的代码占了整个项目代码的80%。

由于验证的工作量巨大，又缺乏优秀的工程师，而且我们经常在完成设计之后，才开始验证的工作。这也是为什么现在的新工具和新的方法学把验证作为研究的热点。这些工具和方法学通过并行化、高层次抽象和自动化的手段，来缩短验证的时间。

如果验证可以并行化，那么增加资源可以缩短整个验证的时间。这就好比，很多个工人同时挖一个坑。要让验证并行化，就需要编写可综合HDL代码和测试平台可以同时进行。

使用高层次抽象可以提高你的工作效率，因为不需要关注底层的细节。正如上面的例子中，使用挖土机来挖坑。

高层次抽象往往难以控制底层细节，所以要精心选择抽象的层次。高层次抽象常常需要额外的训练来理解抽象机制及其作用。

使用挖土机挖坑同样会遇到失控的问题：工人不再直接接触泥土，而是使用操控扞和踏板。挖掘的效率大大提高，但是精度降低了，而且只有培训过的工人才能工作。事务、总线周期[5]甚至更高层次，可以使用高层次抽象的方法来验证，而不是和0、1打交道。

      注[5]：总线上的读写操作等。

      自动化可以让电脑自主、快速地完成任务并得到结果，同时你又能处理其它事情。自动化是一个已知输入和输出的标准流程。并非所有的流程都能实现自动化。通用的挖土机是不可能挖出形状、大小、深度、位置和土质条件各不相同的坑。

      验证面临着相同的难题。因为有各种不同的功能、接口、协议和变换要验证，以当今的技术是不可能给出一种通用的、自动的验证方案。但是，我们可以把一部分验证流程自动化，尤其是一些狭窄的应用领域。这就好像挖沟机可以自动挖出放置管道和电缆的线沟。我会介绍各种验证的自动化工具。我希望这本书会帮你在不久的将来认识到全新的、标准的、自动化的验证流程。

1.3 收敛模型。

收敛模型从概念上表达了验证的流程。它通常被用来解释验证的对象是什么。

你必须明确知道你在验证什么。验证的目的就是确定一些变换的结果是否跟预期的一致。例如，对账的目的就是确定所有的交易都被准确无误地记录下来，并且余额能反映出可用资金。

图1-2

      图1-2说明了变换的验证必需由一个公共起点，再通过两条收敛路径来完成。只要有输入和输出，都可以称之为变换。在一个项目中，规范的RTL代码，插入边界扫描链，把RTL代码综合成门级网表，以及门级网表的版图都是变换。验证使得结果和起点一致。如果变换和验证之间没有公共起点，则没有验证可言。

  图1-3

图1-3以对账为例描述了收敛模型。在对账中，公共起点就是上个月的结余。变换就是这个月内开出发票，收取发票和还款。验证就是让本月结余和对账单相一致。

1.4 人为因素。

如果从端到端的变换没有自动完成，那么就需要个人或小组对变换的实现进行解释。RTL代码就是这样的例子。开发团队先撰写项目计划书，再实现功能正确的可综合代码。通常，每位工程师都要验证代码是否正确。

图1-4

图1-4展示了上述情况的收敛模型。如果由同一个人完成需求分析、编写RTL代码及其验证，那么公共的起点就是这个人对需求的理解，但是，不一定是真正的需求。在这种情况下，验证的成败取决于这个人的理解，如果理解有偏差，那么验证就没有意义了。

人为干预是不确定、不可复制的。可以通过下列方法来减少人为出错的概率：自动化、防差错技术或冗余。

1.4.1 自动化。

显然，自动化可以减少人为出错，因为不需要人为干预。但是，并非所有情况都可以使用自动化，尤其是没有明确定义的、需要人类发挥的创造性的时候，例如硬件设计。

1.4.2 防差错技术。

把需要人为干预的步骤尽可能地简化、傻瓜化，也是可以减少出错的概率。只需要人类按照特定的步骤去操作，即可得到预期的结果。这种方法在整体品质管理中，叫防差错技术。它离自动化只有一步之遥。然而，它跟自动化一样，需要已知的、标准的变换步骤。时至今日，验证仍然没有固定步骤。

1.4.3 冗余。

最后一种减少人为出错的方法是冗余。它是最简单的，却是代价最高的方法。冗余就是让每种变换都复制多份，然后都由不同的人去完成它，再让另一帮人做验证。或者由两个人分别完成两份变换，再去验证他们的结果是否一致。冗余用在要求高可靠性的场合下，比如：航天器。一些工业级的产品，重新设计并替换缺陷品的代价比使用冗余的代价要高得多，比如：IC设计。

图1-5

图1-5是个冗余法的收敛模型。对一个模棱两可的需求进行两次解释，可以减少出错的概率。在硬件设计的项目中，编写RTL代码就是变换，然后需要由另一个人做验证。

1.5 验证什么？

验证的工具决定了公共起点和收敛点，而起点和收敛点又决定了验证什么。了解这些点的位置有利于理解验证何种变换。形式验证、模型校验、功能验证和测试平台生成器用于验证不同的东西，因为他们的起点和收敛点不同。

1.5.1 形式验证。

形式验证起初容易被误解。不熟悉形式验证的工程师经常把它当作利用数学来验证的工具，从而不需要写测试平台。只要你理解形式验证收敛模型的端点，你就知道需要验证什么了。

形式验证的应用可以分为两大类：等价校验和模型校验。

1.5.2 等价校验。

图1-6

图1-6是等价校验的收敛模型。形式验证利用数学的方法证明了起点和输出在逻辑上是等价的。因此变换保持了它原有的功能。

等价校验最常见的用法，就是于对比两个网表，以确保处理过的网表是否改变了电路的功能，比如：插入扫描链，综合时钟树，或者是手工修改网表。

而另一种用法，则是验证RTL代码是否正确地映射成网表。如果可以完全相信综合工具，那就不需要验证了。然而，综合工具是非常庞大的软件，它依赖于算法的正确性和库的信息。历史告诉我们，这样的软件容易出错。而等价校验可以确保综合工具的正确性。

等价校验也会用于验证两份RTL代码在逻辑上是否一致，目的是为了避免长时间的仿真，例如，少量非功能性的改动会让代码综合出来的效果更好。

你可以选择等价校验来验证逻辑综合的变换。它只会在功能上对比组合逻辑和时序逻辑，而不关心底层的工艺映射表。

数字设备公司（DEC）的工程师曾使用等价校验发现设计在综合时出错。这个设计在处理超出48位数据时出错。文档中有明确指出不支持48位以上的数据。但是，综合工具不能理解文档，所以生成了错误的逻辑。等价校验可以快速发现这种用门级仿真难以发现的问题。

模型校验

模型校验是形式验证的新应用。它可以从形式上证明断言或设计的特征是否正确。例如，它可以检查出设计中的所有状态机是否存在不可到达的状态。它甚至可以检查出状态机是否死锁。

与接口相关的断言是另一种形式验证的断言。有关接口的断言，可以使用形式描述语言来描述，然后由工具来证明它是否正确。例如，一个断言可能是：假设ALE信号有效，则DTACK或ABORT信号接着有效。

图1-7

图1-7是模型校验的收敛模型。模型校验最大的难点在于如何判断出需要证明哪些断言。在这些断言中，只有一小部分可以被证明的。目前的技术水平还不能证明高层次的断言，即不能确定复杂功能是否被正确地实现。如果能证明以下断言就好了：设置了一组特殊寄存器，异步传输模式（ATM）的单元将会按照某种次序来产生一组输出。可惜，模型校验的技术还没达到这种水平。

图1-8

1.5.4 功能验证。

功能验证目的是确保设计中的功能是否实现。图1-8是功能验证的收敛路径。功能验证检验了设计和规范是否一致。没有功能验证的话，工程师要主观地认为自己完全理解了规范，从规范文档到RTL代码的变换是正确的，

值得注意的是，除非规范是用非常严谨精确的形式描述语言来描述，否则是不可能证明设计是否符合规范的要求。规范文档是用自然语言写的，工程师们的表达能力各不相同。任何文档都需要理解。功能验证可以说明设计和规范是否一致，但不能证明它。人们可以很轻易地证明设计与规范不一致，但是反过来则很困难。没有人能证明没有不同点。正如没人能证明会飞的驯鹿和UFO不存在。（然而，只要找到一只会飞的驯鹿或一个UFO就能证明它存在了）。

Testbench生成器。

日益普及的代码覆盖率和模型验证，有望创造出一种新的验证工具：testbench生成器。

testbench生成器使用代码覆盖率的指标或者一些证明的结论，再分析源码，然后生成testbench，这样不仅提高代码覆盖率还可以实现设计中随时可变的属性。

表面上看，这些工具似乎很有吸引力，但是如图1-9所示。它对验证贡献不大。RTL代码是个公共的起点，这里没有收敛点。验证工程师需要自己去判断testbench是否给设计一个有效的激励。可以肯定地说，他必须判断基于此种激励，期望什么样的输出，再去对比设计产生的输出。

图1-9

生成的testbench是否有用，我们将在下一章从代码覆盖率的指标来讨论。生成的testbench从模型校验的结果来看是有用，仅仅说明了一个属性可以改变以及什么的输入序列会导致异常。它可能是个鉴别异常条件的工具，如：规范中未考虑的条件或者提供修复问题的调试环境。

1.6 功能验证的方法。

功能验证有三种方法：黑盒法，白盒法，灰盒法。

1.6.1 黑盒法。

使用黑盒法是不需要关心设计是如何实现的。所有的验证通过接口完成，无需直接询问设计的内部状态，也不需要了解它的结构和实现细节。显然，这种方法缺乏对设计的可控性和可观性。它很难设置一种状态或隔离某些功能。它同样难以观察到输入对应的输出，也难以定位到问题的根源。尤其是输出到产生问题之间有较长的延时就更加难以定位了。

黑盒法的优点是不需要关心实现的细节。无论设计是用一片ASIC、多片FPGA、一块电路板还是纯软件实现，都是无关重要的。墨盒法是真正的一致性验证，它只检验设计是否实现了规范的要求。

在一些非常庞大复杂的设计，黑盒法需要一些非功能性的模型来提供额外的可观性和可控性。

例如，增加一些软件可访问的寄存器来控制或观测内部状态，或者修改处理的数据量让验证耗时最短。这些寄存器不会在正常的操作下使用。他们常常用于初次原型系统的集成阶段。

黑盒法是唯一一个能与设计并行实现的功能验证方法。因为它不需要关心实现的细节。

我母亲非常熟悉黑盒法：为了防止我们猜到圣诞节礼物，她从不在礼物盒上写名字。到了圣诞节，她不打开礼物盒，又不得不分辨出每个礼物盒里装的是什么，然后才知道该把礼物给谁。她多次失败后，成为我们的节后笑料。

1.6.2 白盒法。

白盒法可以完全地观测和控制设计内部结构和实现的细节。这种方法的优点是可以快速地设置一个感兴趣的状态和输入，或者隔离一个特殊功能。它可以随着验证的进行，很轻易地观测结果，然后马上报告任何异常的行为。

然而，这种方法要与实现的细节紧密结合。设计一旦修改后，测试平台也要同时修改。

白盒法是黑盒法有力的补充。这种方法可以确保底层功能的正确性。例如，计数器到达临界值后是否翻转，数据路径是否进行适当的调整和排序。

1.6.3 灰盒法。

灰盒法是介于黑盒法和白盒法之间的折中方法。黑盒法不能控制设计，白盒法不可移植。

与黑盒法类似，灰盒法通过顶层接口来控制和观测设计。同时，针对特定的功能进行验证。相同的验证可以用于不同的设计，但是它不会比黑盒法关注更多的细节。

1.7 测试和验证。

测试常常跟验证混淆。测试的目的是检验设计是否正确，验证的目的是确保设计是否实现预期的功能。

图1-10

图1-10是验证和测试的收敛模型。测试阶段中，完成的硅片要与生产时提交的网表一致。

测试是通过测试向量完成的。这些测试向量不是执行函数。它要确保设计中的物理位置能否从0翻转为1以及从1翻转为0。已测的物理位置与总数量之比称为测试覆盖率。测试向量是通过自动测试生成系统（ATPG）自动生成，以达到测试覆盖率最大，同时测试向量最少。

测试和测试覆盖率取决于设置内部物理位置为1或0的能力，然后观察它们是确实设置了。有些设计只有很少的输入和输出，但有大量可能的状态，需要很长的序列来观察和控制所有内部的物理位置。一个很好的例子是电子手表：它有三或四个输入（拨号盘周围的按钮）和一个输出（显示器上的数字和符号）。如果它带有日历功能，它有十亿个可能的状态（把几百年按毫秒计）。需要几百年才遍历完所有可能的状态。

1.8 基于扫描的测试。

有幸的是，基于扫描测试的技术帮助我们去解决这个问题。基于扫描测试将设计中的所有寄存器用一个长长的链串联起来。在正常模式下，操作寄存器仿佛扫描链不存在（如图1-11(a)所示）。在扫描模式下，操作寄存器就像操作一个很长的移位寄存器一样（如图1-11(b)所示）。

图1-11

若要测试一个可以扫描的设计，测试单元先进入扫描模式，然后输入信号通过设计内部所有的寄存器进行移位。设计先进入正常模式，再利用单个时钟周期加载正常操作的结果到扫描状态的寄存器。然后设计再次进入扫描模式。结果被移出寄存器（同一时刻把下一个输入移入），并把结果和异常值进行比较。

这增加了可控性和可观性，同时也增加了测试覆盖率的代价。这限制了设计插入扫描链和自动生成测试用例。这些限制包括但不限于：全同步设计，没有衍生时钟或门控时钟，和使用时钟的单边沿。可测试性设计的主题要大得多而且比这个简单的介绍更复杂。

硬件工程师最初使用基于扫描的测试时，反对强加给他们的限制。他们只看到眼前的禁区及其最喜爱的设计技巧的不足之处。

但是，当设计使用一个或多个的扫描链时，按下按钮时自动生成测试用例和实现高测试覆盖率，其价值很快超过了增加的面积和额外设计的开销。节省出来的时间以及增加工程师对产品上市的信心，已经远远超过了基于扫描设计的额外开销。

1.9 用于验证的设计。

我们可以修改设计以适应可测试性的需求。但是，修改相同的设计以满足验证的需求是不可行的吗？

功能验证所付出的努力是设计的两倍，需要额外的设计来简化验证是非常合理的。就像设计使用扫描链以提高可测试性而不增加功能，我们是应该添加非功能的模块和特性以简化验证。这就需要在项目的开始阶段，订制规范阶段就要考虑验证。不仅只有架构师能回答这些问题“这样做的目的是什么？”，还有“如何验证这个东西？”

典型用于验证的设计技术包括提供额外的软件可访问寄存器以控制和观察内部位置，并提供可编程多路复用器隔离或旁路功能单元。

1.10 验证和设计重用。

现在，单芯片可制造的晶体管数量和工程师在合理时间内使用的晶体管数量存在差异。设计重用被认为是克服这种差异的最佳方法。这种差异称为生产率差距。设计重用是一个简单的概念似乎很容易实行。事实证明会产生更多的问题。

1.11 重用就是信任。

设计重用的主要障碍是文化。工程师不太乐意使用未知的设计。他们不相信另一个设计是好的或是像自己设计的一样可靠。设计重用的关键是获得信任。

信任，就像质量一样，是不可以事后添加到设计中的东西。它必须是内置的，并通过尽可能好的设计体现出来。它必须通过可重用设计的后面来获取：提供技术支持和建立客户关系。一旦建立信任，就会更多地重用设计。

信任也可以通过适当的验证来证明。向客户展示已经根据规范彻底并细致地验证了设计，可以建立信任以及让沟通更流畅。功能验证是唯一的方法来证明设计的质量满足甚至超过了工程师可以自己做的类似的设计。

1.12 可重用的验证。

如果你创造了一个设计，你会相信自己的设计能力，并毫无疑问地相信它是正确的。功能验证仅用于确认该意识和加强这些薄弱的意识。如果你要重用一个设计，你只能依靠功能验证来建立同样的信任。因此，可重用设计必须比定制设计更可靠。

因为可重用设计倾向于可配置和可编程以满足各种应用场合，所以它需要验证所有可能的配置和用途。所有关于可重用性设计的声明必须向客户验证和演示。

1.13 验证的代价。

验证是罪恶。它非常耗时，代价很大。验证不会直接产生利润：毕竟，这是经过验证的设计被出售并赚钱，而不是验证。然而验证是必不可少的。要有销路，创造收入，设计必须是功能正确，能满足客户的需求。

验证没有完成的时候。验证的目的是为了确保设计是对的，但不能证明设计是对的。验证只能显示存在错误，而不是没有错误。只要有足够的时间，就能发现错误。这个问题变成了：这个错误严重到要花多少钱去发现它？随着越来越多的时间花在验证上，以相同的代价来发现的错误越来越少。随着验证的进行，收益递减。它越来越贵了，发现的错误却越来越少，越往后越不可能发现错误。

功能验证类似于统计学中的假设检验。测试中的假设是：我的设计功能正确吗？这个答案可以是或不是，但是两种答案都可能是错的。这些错误的答案分别是II型和I型错误。

图1-12

图1-12显示出现不同类型的错误。I型错误或者叫假阴性，很容易识别出来。验证找到一个不存在的错误。一旦确认这个误解，修改验证把答案从“否”改为“是”，这个错误就不复存在了。第二类错误是最严重的错误：验证不能识别出错误。在II型错误或假阳性情况下，一个糟糕的设计在不知不觉中发货，这会带来不可预估的后果。

美国食品药品监督管理局面临第二类错误具有潜在毁灭性的后果：尽管临床试验结果阳性，药物被流出在市场上是否危险？糟糕的设计可能导致召回产品或者像太空探测器着陆另一个星球后全部损坏。

随着公司的未来可能面临潜在的风险，验证中价值64000美元的问题是：验证到什么程度才够？本书所讲述的功能验证和下一章介绍的工具将回答这个问题。

验证中价值6400万美元的问题是：什么时候才能完成验证？尽管不能精确地估算时间，但确定正在验证哪一步比估算验证所需的时间要容易得多。第三章介绍验证规划，让验证工程师可以更好地估算出完成任务的时间和效果。