驗證計畫(十二)

测量进度

解决方法是根据功能覆盖点来测量进度，这些功能覆盖点可以确定一个功能是否被验证
过。这样，验证的目标变为填满设计的功能覆盖模型而不是编写一系列的测试集。你可以用很
大的直接的测试平台来填满这个覆盖模型，或者可以让一个随机的测试平台生成测试集替你验
证功能。

用带有随机测试平台的覆盖驱动方法进行测量的进度和传统的直接方法
测量的进度。前者的测试平台的初始开发时间较长，但长时间运行时的功能覆盖率更高。

直接的测试用例只能发现你想要查找的错误，而随机仿真可以生成一些在写验证计划时
未曾想过的条件。它们可以生成意想不到的条件。它们也可以减少验证工程师在编写直接的测
试平台时引入的偏差。代替生成很容易编码的输入序列，它们生成更符合实际的激励。由于设
计会在相当多的条件下进行验证（在同样的时间里相对于直接的方法来说），设计整体的质量
会更高。

使用约束驱动的方法需要约定。在进度压力下，很容易回去写直接的测试集。这种方法的
一个关键部分是需要对测试平台和设计进行仿真，以弄清楚已经完成了多少功能覆盖。如果
RTL 模型没有准时完成（它往往不能准时完成），要怎样调试自检验的随机测试平台呢？怎样
知道验证团队正在向它的功能覆盖目标前进呢？最简单的解决方法是开始把测试用例编写成直
接的伪随机的测试平台，毫无疑问它可以填充功能覆盖点。那会使你又回到楼梯曲线。更好的
方法是尽可能早地交付RTL、开始仿真并使用行为级模型。

 在覆盖驱动的方法中，功能覆盖测量用于确认哪些测试用例被执行了，而不是直接编写那
些测试用例。因此，实现功能覆盖模型并从一开始就收集功能覆盖率是很重要的。
功能覆盖从项目的一开始就用来记录哪些测试用例和条件被随机发生器自动生成
了。如果没有把功能覆盖和随机环境联合使用，那恐怕仅是在用随机激励做直接的测试用例。

每种功能都会在输入数据流、设计的配置或必定要经过的设计内部状态中体现出一种特性
或征兆。功能覆盖必须确认并记录那些特性和征兆。

只有明确地定义了目标，功能覆盖工具才能测量进度。它也会使功能覆盖分析更容易。进
度会以一个不变的目标进行测量。如果每次分析功能覆盖报告时目标被智能地定义，那么这些
目标属于人为的错误。因为你会下意识地把进度与迫近的截止日期进行比较，因此在项目快结
束时有一种要减小验证缺口的重要性的趋向。

理解目标的复杂性
不要让你的目标比需要的更准确。如果为了实现目标需要设定的值越多，你的工作就越
多。由于交叉覆盖，要设定的值的数目会成指数地增长。

收集大量的功能覆盖数据是很容易的。但是掌握的功能覆盖数据越多，分析结果就越困
难。总是需要询问适当的功能覆盖点。如果打算忽略一些覆盖报告或不再关注以后的报告，就
不该收集它。数据和信息之间有本质的区别。任意的功能覆盖点仅仅提供要分析的数据，而仔
细选择的功能覆盖点和精心定义的目标可以马上提供有意义的信息。

功能覆盖的定义是一种还在发展的艺术
为验证计划开发好的功能覆盖模型是不容易的。本节概要讨论了必要的步骤。功能覆盖模
型是一个可以并且应该被发展的明确定义的科学话题，需要一整本书来讨论它。