目录
一、概述
二、覆盖率的种类
1、概述
2、分类
三、代码覆盖率
四、功能覆盖率
五、从功能描述到覆盖率
一、概述
“验证如果没有量化，那么就意味着没有尽头。” 伴随着复杂SoC系统的验证难度系数成倍增加，无论是定向测试还是随机测试，我们在验证的过程中终究需要回答两个问题：
- 是否所有设计的功能在验证计划中都已经验证？
- 代码中的某些部分是否从未执行过。
覆盖率就是用来帮助我们在仿真中回答以上问题的指标。如今，覆盖率已经被广泛采用，作为衡量验证过程中的重要数据。
只有满足以下三个条件，才可以在仿真中实现高质量的验证：
- 测试平台必须产生合适的激励来触发一个设计错误；
- 测试平台仍然需要产生合适的激励使得被触发的错误可以进一步传导到输出端口；
- 测试平台需要包含一个监测器（monitor）用来监测被激活的设计错误，以及在它传播的某个节点（内部或者外部）可以捕捉到它。
二、覆盖率的种类
1、概述
没有任何一种单一的覆盖率可以完备地去衡量验证过程。
即使我们可以达到100%的代码覆盖率，但这并不意味着100% 的功能覆盖率。原因在于代码覆盖率并不是用来衡量设计内部的功能运转，或者模块之间的互动，或者功能时序的触发等。
类似地，我们即便达到了100%功能覆盖率，也可能只达到了 90%的代码覆盖率。原因可能在于我们疏漏了去测试某些功能，或者一些实现的功能并没有被描述。
从上述关于代码覆盖率和功能覆盖率简单的论述就可以证明，如果想要得到全面的验证精度，我们就需要多个覆盖率种类的指标。
2、分类
最常见的划分覆盖率的两种方法
- 按照覆盖率生成的方法，即隐性生成还是显性生成。
- 按照覆盖率溯源，即它们从功能描述而来还是从设计实现而来。
例如功能覆盖率是显性的需要人为定义的覆盖率，而代码覆盖率则是隐性覆盖率这是因为仿真工具可以自动从RTL代码来生成。
如果将上述两个分类的方式进行组合，那么可以将代码覆盖率、 断言覆盖率以及功能覆盖率分别置入到不同的象限。但是需要注意，目前有一个象限仍然处于研究阶段，没有隐性的可以从功能描述生成某种覆盖率的方法，这也是为 什么功能覆盖率依然需要人为定义的原因。
接下来我们将认识主要的两种覆盖率
- 代码覆盖率（隐性覆盖率）
- 功能覆盖率（显性覆盖率）
三、代码覆盖率
衡量验证进展的最简易的方式是使用代码覆盖率。这种方式衡量的是多少行代码已经被执行过(行覆盖率)，在穿过代码和表达式的路径中有哪些已经被执行过(路径覆盖率)。哪些单比特变量的值为0或1(翻转覆盖率),以及状态机中哪些状态和状态转换已经被访问过(有限状态机覆盖率)。不用添加任何额外的 HDL代码，工具会通过分析源代码和增加隐藏代码来自动帮你完成代码覆盖率的统计。当运行完所有测试代码覆盖率工具便会创建相应的数据库。
许多仿真器都带有代码覆盖率工具。后续处理工具会把数据库转换成可读格式。最终的结果用于衡量你执行了设计中的多少代码。注意,你的主要关注点应该放在对设计代码的分析上，而不是测试平台。未经测试的设计代码里可能会隐藏硬件漏洞，也可能仅仅就是冗余的代码。
代码覆盖率衡量的是测试对于设计规范的“实现”究竟测试得多彻底，而非针对验证计划。原因很简单.你的测试达到了100%的覆盖率，并不意味着你的工作已经完成。如果你的代码有漏洞但是测试没找到怎么办?或者情况更差一些,如果你的代码实现中遗漏了某个必要的特性怎么办?所以单有代码覆盖率还远远不够。
四、功能覆盖率
验证的目的就是确保设计在实际环境中的行为正确，实际环境可以是MP3播放器、路由器或移动电话。设计规范里详细说明了设备应该如何运行，而验证计划里则列出了相应的功能应该如何激励、验证和测量。当你收集测量数据希望找出哪些功能已被覆盖时，你其实就是在计算"设计”的覆盖率。例如，对D触发器的验证计划除了涉及触发器的数据存储外，还应该检查触发器如何被复位到某个已知状态。在你的测试对这两种设计特性全部进行验证之前、你就不能达到100%的功能覆盖率。
功能覆盖率是和设计意图紧密相连的，有时也被称为“规范覆盖率”，而代码覆盖率则是衡量设计的实现情况。设想某个代码块在设计中被漏掉的情况。代码覆盖率不能发现这个错误,但功能覆盖率可以。
五、从功能描述到覆盖率
要实现功能覆盖率的收敛，就需要按照以下步骤考虑：
- 哪些功能需要测试
- 明白在什么条件下需要测试对应的功能
- 为了测试这些功能，需要提供什么样的测试平台组件以便提供激励和监测
- 测试平台如何检查这些功能正常工作
由于功能覆盖率不是自动的过程，因此它需要将功能描述同设计实现对应起来。
