【SV验证】常见模块的验证模型--前言

做验证的时候经常会被老板这样问道：

老板：小黄呀，这个模块你知道怎么验吗？

或者是被隔壁组的designer问道：

Designer：黄同学，你知道一个模块怎么算验全了呢？怎样可以投片呢？

上面两个问题都是对验证工程师的灵魂拷问了，我们一般怎么回答呢。

验证小黄：啊啊。。别着急，你把你这个模块的spec给我，我看看，然后写一个testplan。然后我们找几个大佬review一下，大家都来补充（找茬）一下，然后大家没有问题了，我们就可以投片了。

       Designer：如果流片回来有问题呢？

验证小黄：啊，那就大家一起背锅呗，你也在review的list里面呢，哈哈哈哈。。。。。

开玩笑了，不过做simulation验证的验证完备性确定根据验证工程师的能力素质息息相关，当然review团队的把关也很重要，收code coverage的时候可能还能得到一些补充。

那么我们有没有办法降低这种人为的不确定性呢？很难！但是或许我们可以总结一下我们验证中会遇到哪些模块，对应的模块又会遇到些什么问题。积累得多了，或许我们就是高手了呢。哈哈哈哈。。。。

好了，下面我会持续分享一些常见模块的验证方案。

验证讲究的就是完备性（不要漏bug），怎样才算完备呢？假如我们输入数据是一个2bit的信号signal[1:0], 我们的激励怎样做才算完备呢？

	signal[1]	signal[0]
1	0	0
2	0	1
3	1	0
4	1	1

我们很自然的想到用真值表来表示输入信号的所有可能的组合，那么这样的输入激励就是完备的了。我们在后面的验证思路里也会尽量抽象到这种真值表的层次，让我们能清楚的看到那些可能性是覆盖的，哪些是需要补充的。