随着设计复杂性的跃升，以覆盖为导向的验证已经从高端解决方案转变成主力军。虽然整个EDA产业正倾向于覆盖为导向的验证，追求通用性覆盖数据库，并享用这种“新”技术带来的好处，但有个问题也应运而生：你能充分利用当前已有的所有衡量标准吗？

予以正确实现并以覆盖为导向的验证是一种用于自动创建测试代码和客观地跟踪过程的理想工具。它是以衡量标准为导向的一个验证例子。以衡量标准为导向的验证可以被宽泛地定义为任何验证过程，该过程可通过客观、自动采集的过程数据跟踪和实现自动化。下面是以衡量标准为导向的其它策略性和战术性验证方法，目前已有可用的过程数据支持这些方法，它们是：代码覆盖、功能覆盖和版本控制信息。

让代码覆盖重现生机。代码覆盖数据是多年来设计和验证中一直可用的过程衡量标准—几乎在设计师使用RTL之时就开始了。然而，这是一个利用率的衡量标准。通过代码覆盖数据可以告诉设计工程师所有代码是否都被检查过。这对完美验证来说当然是一个必要条件，但还不够。每行代码都得到了执行并不意味着器件的所有功能都得到了验证。

功能覆盖有着同样的充分性问题。由于功能覆盖取决于覆盖模型的构造，不完整的模型将错误地指示完整的覆盖。

使用衡量标准组合

通过同时分析代码和功能覆盖，可以获得更完整的验证过程图像。附表粗略给出了三种情况。如果我们有高的功能覆盖率和高的代码覆盖率，验证可能如期望的那样执行。当然，一个遗漏的维度仍会产生问题。假如设计中增加了一个新功能，但还没有实现或验证？基于性能的可执行验证计划可解决这个问题。随着每个新功能的加入，在覆盖被全部实现和跟踪之前验证计划始终会产生不完整的。

如果代码覆盖率高而功能覆盖率低会如何？它会指出器件的测试套件相对器件的定义功能是不完整的，同时也会指示对应于遗漏功能覆盖的设计部分还没有得到实现。

如果代码覆盖率低、而功能覆盖率低会如何？它会指出功能覆盖部分还没有实现，同时也会指示存在着不提供实际功能的设计结构。也许是一个性能及其相应测试代码被删除了，但针对这一性能的实际设计代码还没有被删除。通过分析这两种可用覆盖衡量标准的组合，设计和验证团队可以获得更完整的过程图像。

另外一种经常被忽视的衡量标准可以帮助验证：版本控制数据。版本控制数据可以是调试过程中的一个关键指示器。通过自动绘制近故障相对近RTL版本的曲线图，验证工程师可能快速了解潜伏性问题所在。

调试中的功能覆盖

功能覆盖可以用作战术性过程衡量标准和策略性衡量标准。工程师可以查询故障测试的功能覆盖数据库，从而确定被验证的器件是怎样配置的。

随后工程师就可查询集合递归级覆盖数据库，以发现其中器件用相同方式配置的其它通过性测试。对这些通过和失败测试之间差异的分析可以突出引起器件故障的原因。