关于随机用例的讨论

xuri2009

问题背景：
       项目组有些模块采用的验证策略是通过直接用例覆盖模块的所有规格，然后规划些随机用例不停的跑；
没有采用功能覆盖率模型；
问题，争议：
      1：有些人认为因为没有使用功能覆盖率模型随机就没有闭环，你跑随机的效果就不清楚，也许你跑了10000条其实都是雷动的或说是价值不大的；你这个随机如何去度量？
       2：有些同事认为随机就是锦上添花的事情可有可无。
      
针对第一问题，我的观点是：直接用例+随机用例这种模式中的随机用例的目的是用来冲击那些你没有想到的功能点或时序的，能想到的你通过直接用例已经覆盖了；
      CDV模式即有功能覆盖率模型的验证方式，功能覆盖率模型里面写的也是你能想到的功能点，没想到的你也没写入模型中，所以这与上面那种验证方式是一样的，也可以说成是没有闭环的；
针对第二个问题：
        锦上添花，这个花有多大，如何添花，值得思考？我身边的同事在做继承性模块是通过大量的随机居然发现了好几个上一代芯片的bug！
所以我认为如何制定高效的随机策略更值得大家思考。

抛砖引玉，针对上面的任何一点，任何内容，大家都可以畅所欲言，随意发散，发表你的观点。

A1985

以前没有CDV的时候，大家还不是一条feature一个一个的测试，难道那时候大家不去流片？CDV这种东西只是增强流片的信心，个人觉得。度量这种东西不好说。

seabeam

功能覆盖率和随机是两个概念，不管要不要随机，功能覆盖率都可以做。
功能覆盖率的目的在于确定验证什么时候收敛，验到什么程度算验完了？大点的公司会使用验证计划来写上需要覆盖的feature,哪个case包含了哪些feature,取自spec的什么部分之类，有文本做底，也方便回归。在定覆盖率点的时候需要多个部门相关工程师讨论确定，保证尽量完备。
随机化，我觉得你说的也是一个不错的方面。这里借用一下synopsys的一个老例子，很多人应该见过。两个32位的数相加，输出也是一个32位，假如1ns可以完成一次运算的验证，那么需要超过500年才能验完所有情况。解决的办法：
Verify with sufficient set of vectors to gain a level of confidence that product will ship with a tolerable fieldfailure rate.
最好的方法synopsys认为是随机化

xuri2009

回复 3# seabeam


   说的不错

开不了口8099

我们现在设计测试用例是根据测试点来设计的，这样决定了对于某个用例，配置基本上固定的，不是随机的，主要是激励的随机。但我觉得配置的随机也同样重要。
请问大家在实际项目中，用例的随机主要体现在什么地方，激励吗？还是配置，还是两者都有？

seabeam

回复 5# 开不了口8099

一般都有，确切的说是带约束的随机

omission

这两种方式互相补充的，不是互斥的，相对而言，Random靠谱一点，direct case毕竟是主观意志决定的。

qyxu1979

传统验证流程：大量直接用例+随机用例，芯片功能主要由直接用例保证，随机为辅，随机发现的都是概率低或验证人员本身就理解错误的地方。随机时一般分为全随机或部分随机，随机发现的问题要回溯为什么直接用例没发现，要把出错的随机用例补充到直接用例集里进行回归测试。

cdv流程：现在比较流行，认为可以提高验证效率，减轻验证工作量，可度量的验证流程。一般是少量直接用例冒烟+大量随机用例稳定+提取最小回归用例集+cdv不好覆盖的直接用例。cdv对功能覆盖率模型要求高，功能覆盖率模型需要经过评审，你没想到的别人可能想到并提醒，大大减少了验证遗漏点。至于tc也会评审，但没人会看的仔细，而且从文档到tc的映射也可能出现偏差，没有cdv直观，哪些覆盖哪些没覆盖一目了然。

个人认为两者各有利弊，cdv对工具对技能要求稍高，不是说cdv就不用跑直接用例了。两者有机的结合比较好。总之，除了穷举以外，bug不可能全部被发现，只是在质量与时间之间找了一个平衡点。

maxstone

回复 8# qyxu1979


   有道理， 一般提取最小回归用例集合用什么工具做 ?

qyxu1979

emanager,cadence公司的，根据随机用例的贡献率自动提取最小用例集