SV学习笔记—覆盖率类型

0.前言

覆盖率是用来衡量设计验证完备性,随着测试逐步覆盖各种合理的组合,覆盖率用来衡量测试进行的程度,覆盖率工具会在仿真过程中收集信息,然后进行后续处理并且得到覆盖率报告,通过报告找出覆盖盲区,然后修改现有test或者创建新的test来填补这些盲区,这个过程可以一直迭代进行,直到覆盖率达到100%。

一个覆盖率反馈环路如下:

可见通过随机和定向测试得到功能覆盖率,将RTL代码漏洞修复后再跑,如此往复最后得到100%的覆盖率。

1.覆盖率类型

1.1代码覆盖率

代码覆盖率是放在工具在仿真完成后自动收集的,不需要人工收集。

1.1.1line coverage

检查RTL代码的所以行是否都被覆盖到。

1.1.2branch coverage

检查RTL代码中所有条件分支是否都被运行到,如:

if(!rst_n)
    d<=0;
else
    d<=q;

分支覆盖率会检测这个if else语句是否每个分支都被运行

1.1.3toggle coverage

检查所有变量是否都经过了0到1,1到0的翻转

1.1.4FSM coverage

若RTL代码中存在状态机,则检查状态机的所有状态是否都被执行过,不同状态之间的跳转是否都跳转过。

1.1.5condition coverage

指的是每个条件中的逻辑操作数被覆盖的情况。

Δ这里要区分condition coverage和branch coverage的区别:

if(a>0 || b>0)
  c=1;
else
  c=0;

设置2组测试用例,第一组a=5,b=0;第二组a=0,b=0;这两组测试可以把这个if else每种情况都遍历到,这时 branch coverage为100%,但condition coverage不是100%,因为并没有把b>0的情况测试到。

在VCS中,上述5个代码覆盖率类型如下所示:

但代码覆盖率达到100%是否意味着验证完备了呢?

代码覆盖率最终的结果用于衡量所有testcase覆盖了设计中的多少代码,关注点在设计代码的分析上,而不是测试平台,未经测试的设计代码里可能隐藏硬件漏洞,也可能是冗余代码,代码覆盖率衡量的是测试对于硬件设计描述的“实现”究竟测试得有多彻底,而非针对验证 计划,所以代码覆盖率达到了100%,并不意味着验证的工作已经完成,但代码覆盖率100%是验证工作完 备性的必要条件。

2.功能覆盖率

功能覆盖率是为了衡量设计的各项功能是否都实现了并按照预期行为执行

功能覆盖率需要自己在验证平台中设计采样点

对于代码覆盖率和功能覆盖率之间的关系如下:

在验证初始阶段,往往处于代码/功能覆盖率都低的情况,当代码/功能覆盖率都达到100%时验证完成;但有时会出现代码覆盖率高功能覆盖率低的情况或者是相反,这往往反映了一些问题

代码覆盖率高功能覆盖率低:这意味着验证遍历了RTL大部分代码,但这大部分代码并没有实现Spec中的某些功能,说明RTL代码不完善

代码覆盖率低功能覆盖率高:这意味着你所定位的功能点都被覆盖了,而RTL代码并没有被全部执行完,这往往说明验证计划不完善,并没有把所有该验的点都采样到。

3.断言覆盖率

 用于一次性地或在一段时间内核对两个设计信号之间关系的声明性代码,断言最常用于查找错误,例如两个信号间的相位关系,是否应该互斥或者请求与许可 信号之间的时序等,一旦检测到问题,仿真就可以立即停止。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值