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数就不是原先的811=11,而是8(10+4)。可见自动分配bin不可靠,因此还是自己选择感兴趣的bin。
5. 覆盖选项
- 推荐:可以添加上面红色的一行,会在例化多次时,单独计算每一个实例的覆盖率(不去合并)。