概述
“验证如果没有量化，那么就意味着没有尽头。”
伴随着复杂SoC系统的验证难度系数成倍增加，无论是定向测试还是随机测试，我们在验证的过程中终究需要回答两个问题:
- 是否所有设计的功能在验证计划中都已经验证?
- 代码中的某些部分是否从未执行过?
覆盖率就是用来帮助我们在仿真中回答以上问题的指标。
覆盖率已经被广泛采用，作为衡量验证进度的重要数据。
覆盖率是衡量设计验证完备性的一个通用词语。
随着测试逐步覆盖各种合理的组合，仿真过程会慢慢勾画出你的设计情况。
覆盖率工具会在仿真过程中收集信息，然后进行后续处理并且得到覆盖率报告。
通过这个报告找出覆盖率之外的盲区，然后修改现有测试或者创建新的测试来填补这些盲区。
这个过程可以一直迭代进行，直到你对覆盖率满意为止。
覆盖率反馈回路
优化验证效率
一旦通过覆盖率来量化验证，我们可以在更复杂的情况下捕捉一些功能特性是否被覆盖:
- 当我们在测试X特性的时候，Y特性是否也在同一时刻被使能和测试?
- 是否可以精简我们已有的测试来加速仿真，并且取得同样的覆盖率?
- 覆盖率在达到一定的数值的时候，是否停滞，不再继续上升?
简单而言，覆盖率就是用来衡量验证精度和完备性的数据指标。
覆盖率可以告诉我们在仿真时设计的哪些结构被触发，当然，它也可以告诉我们设计的哪些结构在仿真时从未被触发过。
覆盖率分类
最常见的划分覆盖率的两种方法
- 按照覆盖率生成的方法，，即隐性生成还是显性生成。
- 按照覆盖率溯源，即它们从功能描述而来还是从设计实现而来。
功能覆盖率是显性的，并且需要依照功能描述去定义的覆盖率。
代码覆盖率则是隐性覆盖率，仿真工具可以自动分析RTL设计代码的执行结果来提供。
如果将上述两个分类的方式进行组合，那么可以将代码覆盖率、断言盖率以及功能覆盖率分别置入到不同的象限。
但是需要注意，目前有一个象限仍然处于研究阶段，没有隐性的可以从功能描述生成某种覆盖
率的方法，这也是为什么功能覆盖率依然需要人为定义的原因。
接下来我们将认识主要的两种覆盖率
- 代码覆盖率(隐性覆盖率)
- 功能覆盖率(显性覆盖率)
覆盖率辩证
没有任何一种单一的覆盖率可以完备地去衡量验证过程。
即使我们可以达到100%的代码覆盖率，但这并不意味着100%的功能覆盖率。原因在于代码覆盖率并不是用来衡量设计内部的功能运转，或者模块之间的互动，或者功能时序的触发等。
类似地，我们即便达到了100%功能覆盖率，也可能只达到了90%的代码覆盖率。原因可能在于我们疏漏了去测试某些功能，或者一些实现的功能并没有被描述。
从上述关于代码覆盖率和功能覆盖率简单的论述就可以证明，如果想要得到全面的验证精度，我们就需要多个覆盖率种类的指标。
