【讨论】随机能增加验证的可信度么？

eddsos

昨晚在msn上碰上以前公司的头头，聊了一会。
他说对我们上半年设计的一个芯片很担心，虽然流片后没有发现任何bug。
我问为什么，他说因为以前的验证环境中随机用的太少。我说随机只能减少工作量，并不能帮你发现更多的bug。我们争论了半天，没有结果。
我觉的很困惑，有什么理由认为机选的彩票比你自己选号的彩票更容易获奖？或许是我错了？

brooks

看情况，随机测试可以提高一些代码覆盖率（如果原来不高的话），可能可以测出一些边界情况

TommyGG

3#说得很正确。另外还有一个很重要的原因，如下：

假如复杂的设计的某个测试点，有100种可能，其中有效求解空间是80种，无效求解空间是20种。

而验证在制定验证计划时，有可能不能正确把握求解空间（如果是100万种可能就很明显了），比如验证工程师认为只有70种是有效求解空间，10种是无效求解空间。

如果采用directed test，一般的做法是遍历测试验证工程师认为的70种是有效求解空间，必然造成验证的不全面性。而ramdom test往往采用的是把激励限制为无效求解空间的补集，这样，就遍历了90种。当然，在验证中会发现异常输出，再去分析，就能确定是因为输入为无效的激励还是设计的BUG。

一般来说，我们的一个复杂的设计都是由验证工程师进行ramdom test，由设计工程师进行directed test。发现的BUG数量比例大概为9：1。

zhouchang2001cn

一般来说，我们的一个复杂的设计都是由验证工程师进行ramdom test，由设计工程师进行directed test。发现的BUG数量比例大概为9：1。

这个数据有点意思

smilesly

1# eddsos

为了覆盖功能，最好是随机定向都做测试。
而且一般随机也不是乱随机，也是有一定约束的随机。

全部随机怎么也没法保证覆盖率。除非无穷尽的时间测下去

neptune1983

我们一般都是自己的小模块使用直接测试，这个一般用于设计人员
然后合成系统以后使用random test，测试功能
因为系统大了以后没办法直接测试了，呵呵

jery_cn

desigh release出来给验证工程师之前,desiger一般都会自己先跑跑direct case.验证工程师一般都是用random test 方法.但衡量random的程度,一般就靠code & function coverage.还有就是发现bug的频率.如果coverage很高的同时,bug 的频率很低.基本上就可以考虑测试模块ok了.

gongxiao

一般是采用边界情况和伪随机测试生成相互结合的方法来验证！

littledot66

楼主说节省了时间也没错.关键是节省了手工不可能实现的时间.因此达到了手工不可能达到的覆盖率.所以有了手工不可能有的可信度

sjjg

一般来说，我们的一个复杂的设计都是由验证工程师进行ramdom test，由设计工程师进行directed test。发现的BUG数量比例大概为9：1。

这个数据有点意思
zhouchang2001cn 发表于 2009-10-29 15:18

                               
登录/注册后可看大图

感兴趣的是什么设计，多大的规模和怎样的复杂度下得出的数据