1. 覆盖率类型

• 随机约束往往伴随覆盖率
  
  
  
  
  
  
• AB。回归测试达到上限后一般是修改约束

1.1 代码覆盖率

• 一般只收集设计代码的代码覆盖率
• 路径覆盖率看if else if的分支是否被执行
  
  
  
  
• C。有一部分代码是dead code永远没法执行到，需要告诉仿真器这部分没法执行，排除掉。一般会设定一个阈值95%。

1.2 断言覆盖率

• 断言表达更方便，便于收集覆盖率。比我自己写function、task等效实现更好。
  
  

1.3 漏洞率曲线

• 漏洞率下降也有可能是约束范围内的约束已经基本发现了，但是没有考虑到的测试场景的漏洞还没有被发现。
• 将要流片时候出现一个漏洞，那么就要考虑之前有些功能是否没有考虑到，功能点没有测。若是基本功能那就需要重新回顾验证计划。

1.4 功能覆盖率

• 形式验证、硬件加速也可以收集覆盖率。
• 若收集到一些覆盖率，但是功能没有通过，那覆盖率要放弃掉。
• 只有测试通过，才会收集功能覆盖率。
  
  
  
  
• BCD。

2. 功能覆盖策略

• 覆盖率只有在设计稳定的时候才开始收集，回归测试稳定时候开始。
• 没有必要收集的覆盖率就不收集。

• 代码覆盖率往往比功能覆盖率更容易提高。
  
  
• 代码覆盖高，功能低，是因为测试功能点不充分，随机化不完备导致某些状态没有被触发，也可能是设计没有实现某些功能。
  
  
• CD

3. 覆盖组

• covergroup可以包含多个coverpoint，因此可以采样多个变量，需要明确在何时采样，声明采样事件。
  
  
  
  
• 若不列举采样变量tr.port的关心值，那么所有值都会被采样。
• 还有一种例化形式（推荐，因为一个Covergroup可以例化多次，上面只能一次）： CovPort cg1 = new()；CovPort cg2 = new()
• 采样方式：
  • @（）
  • CovPort.sample();
    
    
    
    
• 可以借助已有的信号，如clk。
  
  
• ABC.可以定义在类中，也可在module和interface中。

4. 数据采样

• coverpoint也可以有自己的options，默认情况没有进一步的option，那么covergroup的option起作用。
  
  
  
  
• hit表示命中多少次，最后一列表示最少需要hit几次。上面的bin覆盖率是10/11.
  
  
• 在哪些条件下进行收集。
• iff表示只有当interface中的reset==0才可以进行覆盖率收集。
  
  
  
  
• ABD。关闭采样功能用stop()方法。iff是添加一个独立的采样条件。
  
  
  
  
  
  
  
  
• 不推荐将变量直接放在cross后面，会有很多不便。
  
  
  
  
• 没有交叉排除，那应该有8*11=88个bin
• ignore会排除交叉得到的bin
  
  
  
  
• cross将三种关系的情况交叉了：bina0b0就是一个当a=0且b=0的特殊bin
• 一般不用排除法，而是使用指定特殊情况的办法
  
  
• 这两种方式都可以列出感兴趣组合的方式

• ABC。不一定会分配24个bin，只有coverpoint中将所有可能的值都涵盖了，才会是容量相乘个BIN
• 比如没有bins misc = defaut，那就会自动添加4567这4个bin，那bin数就不是原先的8
  
  11=11，而是8
  
  （10+4）。可见自动分配bin不可靠，因此还是自己选择感兴趣的bin。

5. 覆盖选项

• 推荐：可以添加上面红色的一行，会在例化多次时，单独计算每一个实例的覆盖率（不去合并）。
  
  
  
  
  
  
  
  

6. 数据分析