关于整个虚拟项目，请参考：
【IC萌新虚拟项目】Package Process Unit项目全流程目录_尼德兰的喵的博客-CSDN博客
前言
实际参与过项目的同学一定对质量活动这四个字深恶痛绝，项目进入质量活动阶段时，意味着RTL的时序和面积功耗等主要指标已经基本通过验收，debug阶段也已经进行了很长事件已经覆盖了大部分的功能场景。那么这个时候就进入到前端的收尾阶段了。
此时验证的同学更多的是在补充定向用例，收功能覆盖率的corner场景，而验证同学就会收集代码覆盖率，这个过程一般会持续1~2个月（当然了，领导是不会让你只收覆盖率的）。
代码覆盖率
代码覆盖率包括5个：
- line是行覆盖率，只要某一行被仿真到了就会收集覆盖；
- toggle是翻转覆盖率，它会收集信号0->1和1->0的翻转情况；
- FSM是状态机覆盖率，收集状态机的跳转情况，注意并不是显示声明为状态机的才会被FSM收集；
- condition是条件覆盖率，最难收的覆盖率就是它了，他会把语句中各种条件的组合情况放到一起来收集；
- branch是分支覆盖率，它收集的是各种分支是否都走到过，可以认为是condition的简化情况；
对于代码覆盖率，不需要在环境或者RTL中进行操作，只需要在vcs编译时加入选项就可以了。对于本环境，和收集功能覆盖率一样在make run时加上ccov=on的编译选项就可以。
那么这五种覆盖率以什么标准进行收集呢？一般而言，我们只需要收集line、toggle和condition覆盖率，严格一点来说三项覆盖率必须都达到100%才能算是完成。当然了，对于确认无法覆盖的情况，可以通过wavie的方式进行剔除，之后需要组织会议对wavie掉覆盖率进行评审，以防有需要覆盖的场景被遗漏。
代码覆盖率收集
跑完用例之后，打开覆盖率文件：
verdi -cov -covdir sim_base/cov/simv.vdb/ &可以看到代码覆盖率的覆盖情况：
因为我们还是只跑了一个用例，所以覆盖率低是很正常的。
如果跑了多个用例的话，可以对覆盖率文件进行merge，这样可以体现真实的覆盖率情况。当然目前的环境里，由于覆盖率文件并没有根据case和seed进行命名，所以跑多个用例时会发生覆盖。有兴趣的话，可以自行修改Makefile来适配。
