【IC每日一题：SVA和覆盖率知识点】

【博客首发与微信公众号《漫谈芯片与编程》，欢迎专注一下】

3 SVA和覆盖率知识点

断言：是对设计违例的一种严查，能够在违例时立刻报出错误；
覆盖率：是定量衡量IC验证质量的指标和指导提高验证质量；

3.1 代码覆盖率、功能覆盖率和断言覆盖率的区别

这三个覆盖率是在验证过程中用于定量衡量验证的具体指标；
代码覆盖率：衡量的是设计代码中哪些部分已经被测试到了。
行覆盖率（line）：多少行代码被执行。
分支覆盖率（path）：代码中的分支被执行到；
翻转覆盖率（toggle）：哪些单bit的值为0或1
有限状态机覆盖率（FSM）：状态机中哪些状态和状态转换已经被访问过了

功能覆盖率：设计的功能特性是否被充分验证–通过定义一组覆盖点（cover points）来衡量设计的功能特性是否被测试到。
事务覆盖率 (Transaction Coverage): 检查特定类型的事务（如读写操作）是否被执行。
状态覆盖率 (State Coverage): 检查设计的状态机是否遍历了所有可能的状态。
交叉覆盖率 (Cross Coverage): 检查多个功能点之间的组合是否被测试到。
边界覆盖率 (Boundary Coverage): 检查设计在边界条件下的行为是否被测试到。

断言覆盖率：设计中的断言语句被触发的比例。
断言语句用于检查设计的内部状态或信号是否符合预期。

【总结】
代码覆盖率关注的是代码的执行情况，确保每一行代码都被执行过。
功能覆盖率关注的是设计的功能特性是否被充分验证。
断言覆盖率关注的是设计中的断言语句是否被触发，以检查设计的内部状态是否符合预期。

3.2 coverage一般不会直接达到100%，当发现condition未cover到的时候，该怎么做？

查看覆盖率报告去定位哪些条件没有被覆盖到,是因为没有满足该条件的前提条件还是因为根本就遗漏了这些情况，根据这个我们去编写相应的case，进而将其覆盖到。还要找设计人员一块review看一下，看看哪些未覆盖到的点需要怎样构造激励； 当然最暴力的一种方式是：加大种子随机轮数回归；
具体步骤来说：

1. 分析未覆盖的条件
   确定未覆盖的具体条件:使用覆盖率报告工具提供的详细报告，找出哪些条件未被覆盖。确定这些条件的具体位置和上下文。
   理解未覆盖的原因:分析未覆盖条件的原因，可能是由于某些特定的输入组合、状态转换或其他条件难以触发。
2. 修改或增强测试用例
   增加新的测试用例:根据未覆盖的条件，编写新的测试用例来专门覆盖这些条件。例如，如果某个分支条件未被覆盖，可以编写一个测试用例来触发该条件。
   修改现有测试用例:检查现有的测试用例，看看是否可以通过修改输入数据或配置来触发未覆盖的条件。例如，调整随机化约束或增加特定的激励模式。
3. 使用约束和定向测试
   约束随机化:使用约束来指导随机化生成器，使其更有可能生成能够覆盖未覆盖条件的测试用例。例如，在 UVM 中，可以使用 constraint 来限制随机化生成的值范围，以提高特定条件被覆盖的概率。
   定向测试:编写定向测试用例，专门针对未覆盖的条件。例如，手动构造特定的输入序列来触发未覆盖的条件；

3.3 function coverage和code coverage的区别，以及他们分别对项目的含义？

代码覆盖率：关注的是代码的执行情况，确保每一行代码都被执行过。
功能覆盖率：关注的是设计的功能特性是否被充分验证。

功能覆盖率coverpoint和covergroup的代码示例：

// 定义covergroup
covergroup my_covergroup @(posedge clk);
    // 定义coverpoint
    coverpoint my_module.a {
        bins a_values[] = {[0:255]}; // 覆盖a的所有可能值
    }
    // 定义另一个coverpoint
    coverpoint my_module.b {
        bins b_values[] = {[0:255]}; // 覆盖b的所有可能值
    }
    // 定义交叉覆盖率
    cross a_values, b_values; // 覆盖a和b所有可能的组合
endgroup