验证的效率如何提升？

xuri2009

很多验证的同事都抱怨自己比设计人员苦逼，没有设计人员有地位。
如果单从工作量评估上看貌似是这样的，验证的工作量一般是设计的两倍。从整个ic流程上看验证在设计的后面，所以从项目结点倒退时间的话，验证压力也是要跟大一些（如果设计人员有delay，项目结点不变，那只能辛苦验证的兄弟了）
      验证的效率如何提升？这个话题很大，但是又很重要，各位坛友可以多发表些观点。
1:cdv的诞生，相对于以前的定向激励应该是个进步，可以一定程度上的缩短验证周期；
     之前验证一个比较小的模块用例也少者100多条，多者400、500条，但随机用例就很快，10几条用例写好后就可以大规模随机。好吧，随机和定型下次专门搞个专题讨论下，这里就不展开讲了；
2:如果是非写定向激励，如何在达到测试目的的前提下，减少用例个数这个很重要；我们曾帮一个同事检视过他的用例有效性，帮他从150条缩减至100条，这里不涉及用例合并，只是去砍掉那些本质上重复的用例。  （用例规划的复杂度，怎样算合适，太简单了，覆盖的测试点少，用例数明显增多，规划的复杂出了问题不容易定位，这里面的取舍折衷，下次再展开讲吧。）
     如何保证每条用例都是价值满满，重复用例、无效用例少，这个值得大家去思考？
3:据我所知耗费验证人员时间比较多的，应该是实现自动比对；尤其是算法模块里面涉及到何种延时的调整，这个相当耗时。这里不展开讲了，下次再做个专题，不然明天上不了班了。对，这个比对的问题我之前也发起过讨论。
4:定位设计问题花费的时间，这个其实应该还好，因为一般都会要求设计人员协助验证人员定位，小问题自己稍微一下其实也能发现，耗时不是很多。
5:环境的搭建，除了checker外，其它环境组件都是一次投入终身受益，即前期写好后后期改动相对比较小，不会像checker改动始终与用例的执行相伴随；
6:很多同事在制定计划时，规格的熟悉，feature的提取，用例的编写，验证方案的制定，这几块花费的时间和精力不够。我认为前面这些事情才是你最需要花费精力和时间去好好思考和琢磨的。其实“二八原理”也非常适用于验证，前面20%的事情决定着后面80%事情的快慢和效果，决定着整个验证的成败；
  前面20%才是技术活，后面80%就是执行力，。。。
7:各位你觉得在你的验证过程中哪些阶段耗时比较多呢？

写的有点乱，大家先讨论着，明天继续跟大家交流。。。。。

hfyfpga

楼主很牛！！！

nativeda

回复 1# xuri2009


   你们流程比较奇怪啊，debug全甩给设计工程师了？网上给的统计是验证50%的时间都花在debug上了

seabeam

回复 3# nativeda
每个公司不同工程师的分工不一样，不同场景下也不一样，系统级也许debug到一级子模块接口就扔给设计了，模块级验证就不太一样，但是模块级别验证工程师常常不如设计工程师那么熟悉设计，也需要控制好粒度然后设计协助完成debug.这个时候到底要到什么样的深度？是不是要定位到行？是不是设计工程师只需要等验证工程师给结论然后自己去确认就完事，抑或反过来验证工程师发现比对不上不找原因马上丢给设计工程师？
想必每个公司人员比例不一样，DUT熟悉程度不一样，设计VS验证主导不一样，实际操作起来也不一样。

xuri2009

回复 4# seabeam

＂每个公司人员比例不一样，DUT熟悉程度不一样，设计VS验证主导不一样，实际操作起来也不一样＂ 这句话含金量很高！

heyitsyou

回复 1# xuri2009


   LZV5

maxstone

回复 1# xuri2009


   感觉其中两个比较重要，3 和 6
   自动化程度对工作效率的影响很大

   从feature上来说，验证人员确实应该在前期投入更多的时间去理解和计划