用UVM做IC验证中DUT和reference model的一致性和代码覆盖率之间的冲突问题
1.在做代码覆盖率统计的时候是否要求DUT和reference model要一致?
2.如果第一条有要求的话，在验证的过程中，DUT和Cmodel是实时更新的，在做代码覆盖率检查时并不能保证两者始终保持一致，如果中间出现错误了，是否就意味着此次验证的代码覆盖率没有意义。
3.一个IC验证人员是否是从testbench的搭建、测试例的编写、覆盖率的统计等这些工作都是一个人完成，如果由好多人完成的话，大致如何分工...?
谢谢
........
?
灌水的人真多啊，楼上两位。
在工作中也遇到过类似的问题。说一致性吧，应该是功能的一致，但是DUT按照123的步骤来实现，那么goldenmodel是否也要这样呢，还是按照自己的理解用别的方法实现，更好验证DUT，这两种方法其实有争议，希望有大牛能给说说大公司里都是怎么做的
求个答案
个人浅薄理解：
1、DUT和reference model的一致性主要集中在功能方面，不太理解收集model代码覆盖率的意义。
2、如果DUT出错，RTL代码被修改，覆盖率应该需要重新收集。
3、验证对象的规模或者级别决定人数吧，所在公司比较土，模块级验证工作的一般单人全包，子系统这类的要分工完成。
谢谢！看看楼下还有没有更详细的答案
1.首先说明一点，RM和DUT都是由设计规格来的，RM属于testbench，调试验证环境本身就是不断优化RM功能正确性的过程，需要很长的一段时间，代码覆盖率分为行覆盖，条件覆盖，fsm覆盖，toggle覆盖，这些都比较容易达到，现在一般都推功能覆盖率，功能覆盖率的收集一般是在RM，monitor这些组件进行的。
2.一般海思的脚本处理时tc pass以后才会收集覆盖率，tc fail是不会收集覆盖率的，没任何意义。
3.看模块复杂度，一般的模块一个人搞定，这个取决于项目开始的验证策略是如何制定的，但是有一点非常重要，就是验证环境的重用性，这个由UT向IT，ST集成都是非常重要的。
谢谢回答...非常感谢
gooooooooooooooooooooooooooooooooooooooooooooooooooooooood
2.一般海思的脚本处理时tc pass以后才会收集覆盖率，tc fail是不会收集覆盖率的，没任何意义。
这点不认同，海思脚本处理的是兼容两种情况的，由验证人员设置一种是TC pass收集覆盖率，一种是所有TC都收集覆盖率；要思考的一点是当我们验证人员收集覆盖率的时候，今天用例一条没有PASS，那就意味着覆盖率为0，那我验证人员的工作从哪里去体现，我写的覆盖率这么多代码就白写了吗?老大看到这情况不骂死验证人员，所以说最好是要有两种覆盖率的统计，一种是TC pass的覆盖率统计，一种是所有TC的覆盖率统计，只有这样我们才能保证功能覆盖率确实是收敛了，我们验证人员的工作确实是得到了体现。
有道理啊...这个注意不错...
跟着大牛学习下！
请问下reference model 或者C model 怎么放入scoreboard中比较
怎么实现 根据脚本处理TC的结果去决定覆盖率的收集? 覆盖率收集不是仿真中实时进行的吗?仿真的结果也是实时判断并决定是否收集覆盖率? 脚本不是只在仿真之后才进行处理的吗，这个时候怎么进行覆盖率收集?迷惑中，求解...
验证人员的绩效并不是但一看说你覆盖率达到就ok了，错误的case错误的触发了某些条件，使覆盖点被cover，这样的覆盖率没有任何意义。case的passing rate是首要保证对象，你的功能验证尚且没有完全PASS，谈何覆盖率。
这是自然，那么 根据脚本处理TC的结果怎么去决定覆盖率的收集呢?
每个CASE有他自己的覆盖率，又不是在一起的，等你的regression结束之后，把PASS的case的覆盖率merge在一起生成覆盖率报告啊。
所以说要有两个维度的呀，一个是前期DUT还不稳定的时候，这个时候可以通过总的功能覆盖率observe验证人员的工作状态，一个是后期DUT稳定了，可以通过PASSTC的覆盖率保证功能确实覆盖啦。
总TC的覆盖率有一个好处就是在于能够得知当前验证人员开发TC对覆盖率的贡献，如果没有这部分TC 覆盖率的统计，你怎么能知道今天验证人员开发的TC能覆盖多少点呢，你只知道tc fail了，如果有统计，那么可以一边定位一边开发其他的tc去覆盖其他的覆盖点了
最近学习了小编的《如何做UVM验证》，感激之至。
如果DUT没有错误，只是修改了极小一部分的实现方式，新的覆盖率文件vdb和之前的vdb怎么合并呢，还是两者不能合并
不能合并的
学习了
看看额
1. 模型不会去综合实现，所以模型的覆盖率意义不大
2. 一般覆盖率最后回归收集，难道最后不跑完整回归了?
3. 按接口功能分uvc