重点厘清覆盖率相关的概念以及在芯片开发流程中跟覆盖率相关的事项

验证覆盖率（Verification Coverage）的存在是为了试图回答这样一个问题：“你怎么知道验证已经完成？”

实际上，就算验证覆盖率达到了100%，从逻辑上也不能保证当前的验证是完备的。只不过，100%的验证覆盖率，可以让工程团队对即将tape out的芯片增添不少信心。

01 覆盖率概述

要完成一项工程，需要从市场需求、产品计划、工程流程、威廉希尔官方网站手段、监管机制、资源调配、评审体系等多个维度做全盘考量。而覆盖率，就是芯片工程中，评审体系需要重点参考的一项威廉希尔官方网站指标，但也只是验证相关的其中一项。

目前被业界广泛采用的覆盖率指标有功能覆盖率（Function Coverage）和代码覆盖率（Code Coverage）。这两项指标需要配合起来看，比如100%的代码覆盖率以及低于100%的功能覆盖率，可以看出验证不完整；100%的功能覆盖率以及低于100%的代码覆盖率，可以看出代码冗余或验证计划有误；更多的分析可以得出更详细的结论。

下面会对这两种覆盖率分别展开阐述，最后再补充一下用例通过率（Pass rate）和计划覆盖率（Plan Coverage）的内容。

02 功能覆盖率

功能覆盖率，被用来度量DUT中哪些功能/特性被测试用例测试到了。这项指标在随机验证中非常有用，通过它可以明确地知道在“大范围的扫射”之后，哪些功能被命中了，也就对当前DUT的状态有了大致的把握。

但要获得这项指标也会比较麻烦，工程师们需要针对各种各样的功能和应用场景，使用SV等验证语言去实现覆盖率模型（Coverage Model）或断言（Assertion），并且从大量的回归测试（Regression）中采集（Sample）覆盖数据，然后进行统计数据的合并（Merge），最后做覆盖率分析（Analysis）。

这里提到的功能和应用场景，在不同层级的验证中（模块验证/子系统验证/系统验证）有不同抽象的表达，比如模块验证会更关心模块电路是否所有的功能都被触发到了，而系统验证会更关心是否耦合了各类工作场景。

这里提到的实现覆盖率模型，是容易引入人为错误的地方。覆盖率模型的定义决定了计算覆盖率时的全集，比如设计文档中提到了100个功能特性，验证工程师在开发覆盖率模型的时候由于理解不到位或者遗漏，导致只针对其中90个特性编写了覆盖点，那么最后就算达成100%的功能覆盖率，也还是有10个功能特性没有被测试到。

SV功能覆盖率模型的实现，需要用到覆盖组covergroup和覆盖点coverpoint这些语法特性。覆盖组可以定义在package包、module模块、program程序、interface接口或者class类中。覆盖组通过包含多个覆盖点或覆盖点交叉场景来完成对覆盖率模型的描述，覆盖组还需要指定采样条件和其他配置选项。而覆盖点，通常是需要被覆盖的信号的逻辑或算术表达式，并且对具体覆盖仓（bin）做划分。

提个小建议，即使对SV相关语法很熟悉，实现覆盖率模型的时候还是使用最直接和最简单的方式。这样可以提高可读性，便于维护和评审。

03 代码覆盖率

代码覆盖率，被用来度量RTL中哪些代码被仿真验证执行到了。代码覆盖率是一种软件和硬件开发都通用的手段，通过在仿真程序运行的过程中记录统计数据，来说明代码中哪些语句被分别执行了多少次。

通过对代码覆盖率的分析，我们很容易发现RTL中冗余的代码块（没有被执行），这种“冗余”可能来自于RTL实现逻辑的错误，或者用例和环境没有正确完成期望的测试序列，又或者验证计划不够完备。总之，对于验证质量的把控是非常有益的。

代码覆盖率的收集相比于功能覆盖率要方便得多。收集代码覆盖率通常是由EDA工具在启用相应功能的选项（option）之后自动化完成，不需要工程师再开发额外的代码。同时，代码覆盖率是按照所有代码作为全集来计算，不会像功能覆盖率那样存在人为引入的局限性。

但是，代码覆盖率有个本质上的问题，那就是代码行本身不能代表功能特性，也就是说，某一些代码被覆盖到了，并不能说明RTL实现了某项功能，也不能说明功能实现的正确性和逻辑完备性。反过来，完整的代码覆盖率，不能识别出来哪些功能特性没有被实现，不能识别出来实现了的功能特性所有可能的场景，也不能识别代码行在执行顺序上的正确性。

代码覆盖率的统计一般会再进一步做分类，即翻转覆盖率（Toggle Coverage）、行覆盖率（Line Coverage）、语句覆盖率（Statement Coverage）、分支覆盖率（Branch Coverage）和状态覆盖率（FSM Coverage）。这些分类很好理解，都是字面意思，比如toggle cov就是看某个信号的翻转情况，FSM cov就是有限状态机的遍历情况，这里不再一一展开赘述。