-
什么时候可以说，这个设计的可以Tapout了
-
验证什么时候是个头
验证的指标之一：code coverage
1. 什么是Code Coverage
-
RTL代码是否每一行都覆盖到了，每一行是不是都执行了
-
所有的状态，是否遍历了
-
判断分支语句是否执行了
公司对行覆盖率的要求达到100%，冗余产生的多余的面积，成本增加
是不是已经完成了所有的功能，
边沿情况，特殊情况，corner-case， MP3下载的时候边听歌
2. Code Coverage的类型
PPT1
-
Toggle Coverage:是不是信号又0-1的跳变还是一直为固定值
-
Conditional coverage:case是不是有没有输入情况
-
FSM coverage：是不是没有进入某种状态
PPT2
PPT3
2. 行覆盖率
PPT1
PPT2
PPT3
2. 条件覆盖率
PPT1
PPT2
出现了没有覆盖的情况，要给出合理的解释
PPT3
3. 跳变覆盖
PPT1
PPT2
PPT3
4. 状态机覆盖
PPT1
状态都覆盖了，但不一定所有的跳变都覆盖了
PPT2
要告诉验证人员什么情况下，状态机才会跳转
5. 路径覆盖
6. 如何去做覆盖率
PPT1
PPT2
coverage的衡量
toggle coverage的比较花时间
PPT3
一般不会用-cm_pp都是用gui，或者是转化为网页的格式，或者是文本格式
有些不想工具去检测某个模块的覆盖率，比如辅助debug的部分
- 针对代码段
//vcs coverage on和//vcs coverage off
synopssys不去综合//synopssys translate_on
- 针对模块
7. 编译coverage
PPT1
PPT2
PPT3
8. 仿真和报告coverage
PPT1
PPT2
PPT4
把覆盖率糅合在一起，不是简单的加法
产生多个simv文件，并行的跑多个test case，成百上千个testcase
9. 举例说明
最下面的方法不推荐
不同的case对覆盖率的共享不大，统计每一个case对覆盖率的贡献
前面跑的testcase往往覆盖率贡献比较大，代码大部分是满足基本功能需求的
10. 总结
autograding是针对边边角角的测试
11. 实验用例
编译仿真代码
对应的覆盖率的命令如上所示，产生的simv_fsm_moore.vdb文件夹
用DVE查看覆盖率
-
代码覆盖率
绿色的标记
- 打开之后和上面所示，双击进入如下toggle 覆盖率
dout没有跳变
- 状态机的覆盖率
点击shon in list
- path覆盖率
别的形式报告覆盖率
网页的形式，超文本的格式
通过命令行 urg -dir *.vdb
注释不统计覆盖率
编译仿真的显示，代码覆盖率为灰色
还有一种是
模块不统计覆盖率
先创建空文件vcs_cov.cfg
文件里面添加-module fsm_top代表不看top层
编译的脚本改变为，增加了一句话
结果是top层不统计覆盖率
空文件里面添加+module fsm_top代表只看top层
加号看这个模块，减号不看这个模块
