SV学习笔记（十四）-覆盖率

覆盖率

概述

• 验证没有量化，那么就意味着没有尽头
• 伴随着复杂的SoC系统的验证难度系数成倍增加，无论是定向测试还是随机测试，我们在验证的过程中终究要回答两个问题
  • 是否所有设计的功能在验证计划中都已经验证？
  • 代码中的某些部分是否从未执行过？
• 覆盖率就是用来帮助我们在仿真中回答以上问题的指标
• 覆盖率已经被广泛采用，作为衡量验证过程中的重要数据
• 一旦通过覆盖率来量化验证，我们可以在更复杂的情况下捕捉一些功能特性是否被覆盖
  • 当我们在测试X特性时，Y特性是否也在同一时刻被使能和测试
  • 是否可以精简我们已有的测试来加速仿真，并且取得同样的覆盖率
  • 覆盖率在达到一定的数值时，是否停滞，不再继续上升
• 简单而言，覆盖率就是用来衡量验证精度和完备性的数据指标
• 覆盖率可以告诉我们在仿真时设计的哪些结构被触发，当然，它也可以高数我们设计在仿真时哪些结构从未被触发过
• 只有满足以下三个条件，才可以在仿真中实现高质量的验证
  • 测试平台必须产生合适的激励来触发一个设计错误
  • 测试平台仍然需要产生合适的激励使得被触发的错误可以进一步传导到输出端口
  • 测试平台需要包含一个检测器（monitor）用来监测被激活的设计错误，以及在它传播的某个节点（内部或者外部）可以捕捉到它

覆盖率的种类

• 没有任何一种单一的覆盖率可以完备的去衡量验证过程

• 即使我们达到100%的代码覆盖率，并不意味着100%的功能覆盖率。原因在于代码覆盖率并不是用来衡量设计内部的功能运转，或者模块间的互动，或者功能时序的触发等

• 类似地，我们既便达到了100%功能覆盖率，也可能只达到了90%的代码覆盖率。原因可能在于我们疏漏了去测试某些功能或者一些实现的功能并没有被描述

• 从上述关于代码覆盖率和功能覆盖率的论述可以证明，如果想要得到全面的验证精度，我们就需要多个覆盖率种类的指标

• 最常见的划分覆盖率的两种方法

  • 按照覆盖率生成的方法，即隐形生成还是显性生成

  • 按炸藕改了溯源，即它们从功能描述而来还是从设计实现而来

  • 例如功能覆盖率时显性的需要认为定义的覆盖率，而代码覆盖率则是隐形覆盖率，因为仿真工具可以自动从RTL代码来生成

    

• 如果将上述两个分类的方式进行组合，那么可以将代码覆盖率、断言覆盖率、功能覆盖率分别置入不同的象限

• 但是需要注意，目前有一个象限仍然处于研究阶段，没有隐形的可以从功能描述生成某种覆盖率的方法，这也是为什么功能覆盖率依然需要人为定义的原因

• 接下来我们将主要认识两种覆盖率

  • 代码覆盖率（隐形覆盖率）
  • 功能覆盖率（显性覆盖率）

代码覆盖率

• 代码覆盖率并不是SV独有的，在软件测试领域很早之前就有了这一项测试指标
• 代码覆盖率的一个优势在于它可以由仿真工具自动收集，继而用来指出在测试程序中设计源代码哪些被激活触发，而哪些则一直处于非激活的状态
• 由于代码覆盖率自动的特性，在仿真过程中使能它变得很简单，不需要修改设计或者验证环境

局限

• 代码覆盖率100%并不意味着足够的功能覆盖率
• 研究发现，在回归测试实现了90%的代码覆盖率时，平均只有54%的代码会被监测，这意味着即便代码覆盖率的完备性满足，但依然可能在这些代码中存在漏洞
• 上述的推断是因为并不是多有被覆盖的代码都会得到足够的监测，也