用UVM做IC验证中DUT和reference model的一致性和代码覆盖率之间的冲突问题

guolehaohao

在用UVM做验证的过程中，发现验证DUT和reference model是否一致需要花费很长时间。同时做代码覆盖率的验证也需要花费很长时间。因此有以下困惑：
1.在做代码覆盖率统计的时候是否要求DUT和reference model要一致？
2.如果第一条有要求的话，在验证的过程中，DUT和Cmodel是实时更新的，在做代码覆盖率检查时并不能保证两者始终保持一致，如果中间出现错误了，是否就意味着此次验证的代码覆盖率没有意义。
3.一个IC验证人员是否是从testbench的搭建、测试例的编写、覆盖率的统计等这些工作都是一个人完成，如果由好多人完成的话，大致如何分工...?


谢谢

eemms20

........

guolehaohao

回复 2# eemms20

????????????????

seabeam

灌水的人真多啊，楼上两位。。。

在工作中也遇到过类似的问题。说一致性吧，应该是功能的一致，但是DUT按照123的步骤来实现，那么golden  model是否也要这样呢，还是按照自己的理解用别的方法实现，更好验证DUT，这两种方法其实有争议，希望有大牛能给说说大公司里都是怎么做的

guolehaohao

求个答案

xd_hg

个人浅薄理解：
1、DUT和reference model的一致性主要集中在功能方面，不太理解收集model代码覆盖率的意义。
2、如果DUT出错，RTL代码被修改，覆盖率应该需要重新收集。
3、验证对象的规模或者级别决定人数吧，所在公司比较土，模块级验证工作的一般单人全包，子系统这类的要分工完成。

guolehaohao

回复 6# xd_hg


   谢谢!看看楼下还有没有更详细的答案

ggggdddd

1.首先说明一点，RM和DUT都是由设计规格来的，RM属于testbench，调试验证环境本身就是不断优化RM功能正确性的过程，需要很长的一段时间，代码覆盖率分为行覆盖，条件覆盖，fsm覆盖，toggle覆盖，这些都比较容易达到，现在一般都推功能覆盖率，功能覆盖率的收集一般是在RM，monitor这些组件进行的。
2.一般海思的脚本处理时tc pass以后才会收集覆盖率，tc fail是不会收集覆盖率的，没任何意义。
3.看模块复杂度，一般的模块一个人搞定，这个取决于项目开始的验证策略是如何制定的，但是有一点非常重要，就是验证环境的重用性，这个由UT向IT，ST集成都是非常重要的。

guolehaohao

回复 8# ggggdddd


   谢谢回答...非常感谢

mooh2028

gooooooooooooooooooooooooooooooooooooooooooooooooooooooood