谈谈我对stimulus和checker的理解
结合我所认为的“错误观点”来谈吧。
1）认为stimulus就是testcase。
testcase是stimulus里最重要的部分（没有之一），但不是全部。Driver-model也是stimulus里非常非常重要的部分。好的、完整的、容易控制的driver-model才能构造出完善的stimulus。假设dut是一个amba-master，那么amba-slave就是driver-model；如果dut是一个amba-slave，那么amba-master就是driver-model；如果dut是一个amba-arbiter，那么amba-master和amba-slave都是driver-model。另外，stimulus包括控制、时序和数据，完善的testcase应该要包括这三方面。
2）认为checker就是reference-model
一般来说reference-model是dut的行为级描述（有时候就是一个c模型），而checker还应该包括数据的收集、分析、判断等工作。有的算法实现的模块的reference-model就是cmodel，这样的cmodel的核心部分通常是算法组提供，但是模块的接口时序不是算法cmodel能描述的。
3）认为checker比stimulus重要
我觉得这个观点很错误、很要命。100%的checker+50%的stimulus 与 100%的stimulus+50%的checker 你会选哪个?我想还是会选后者吧，因为后者能覆盖全dut。虽然后者检查起来会很辛苦，但是遗漏bug的可能性要小于前者。
我觉得一个做验证的人如果能把stimulus和checker都做好，那么从技术上说他就具备了带验证团队的一些基本素质；如果只能把stimulus做好，那么从技术上说他就是合格的leader，可以带一两个人；如果只能把checker做好，那么从技术上说他只是个比较合格的programmer，得有人配合他一起做才可以。
最后举个我经历过的实际的例子。我曾经做过一个人手和时间都非常紧张的项目（图像类芯片），从资源上来看是不可能做完善的checker的，我们只好把有限的时间尽量投在stimulus上。我们想办法在验证环境里做了一些简单的数据收集和处理，然后把dut输出的数据转换成图片，再把很多很多testcase输出的这些图片自动处理成网页的格式，每天早上来公司检查regression结果的时候就打开这个生成的网页浏览一下这些输出。虽然投片的时候心里有些惴惴的，但是最终的效果很好，几乎没有遗漏什么bug。----举这个例子也是想说明：“checker总是有办法的，无论是多么土的方法；但是stimulus是没法取代的，无论如何都要去实现和覆盖到的”。
一点拙见，供大家看看。
很好的经验，受益匪浅～～谢谢分享！
stimulus和checker一样作用吧
没有好的checker，就算用更好的stimulus，bug出现了难被发现；
而没有好的stimulus，就算有完美的checker，bug不能出现又有什么用呢。
个人感觉stimulus需要更丰富的经验才能做好。
stimulus和checker都重要，
不过stimulus需要更多的关注整体设计的结构、spec...以及如何更加简单易用的部分，
从重点上看应该需要stimulus比checker走的更早一步，这需要工程师能更加深入的去理解设计，
checker来说是要想办法把自己人为判断的一些东西尽量自动化以减少误判以及加快进度
学习了
真想见识一下成熟的验证方案
好的testbench应该能够模拟所有可能出现的场景，而且应该让stimulus构造场景的时候容易，这样有利于问题的复现。随即验证的话，要确保随机范围全面，并要有确保验证快速收敛的机制。checker也是非常重要的，要保证检查的全面性，漏查的话很容易埋bug。
对第三点不是特别同意， 说checker比stimulus重要当然不对，但是反过来一样有问题。stimulus全了，checker不正确，没发现错误有又什么用呢?应该是都重要才对
只不过，一般来说，checker要好设计一些，而想出完备的stimulus要难的多，从工作投入的角度来说，小编说的也有一定道理吧。
3）认为checker比stimulus重要
我觉得这个观点很错误、很要命。100%的checker+50%的stimulus 与 100%的stimulus+50%的checker 你会选哪个?我想还是会选后者吧，因为后者能覆盖全dut。虽然后者检查起来会很辛苦，但是遗漏bug的可能性要小于前者。
谈一下对LZ和8楼关于verification架构讨论的意见。
先把概念理一下，stimulus好像都没有异议，而我理解的checker和LZ的描述似乎有差异，checker应该只是一个完全的被动部件，感觉中，LZ似乎想说的是monitor和RM以及scoreboard的部分或者组合的一个概念。
实际上，我理解UVM/VMM/OVM等中的checker是针对断言和覆盖率而存在的一个独立的验证部件。
下面我还是依据LZ的思路，把“checker”作为“RM/monitor/scoreboard”等部件的一个混合或者部分混合体来看待。
我主要讨论的内容不是参与stimulus和checker谁重要的讨论，而是希望其它方面来说说我的意见，
如果说我们验证没有足够的资源去做一个完整的验证过程，那么去单纯地裁剪验证架构中的组件的做法是不太恰当的。
有一个做法可能会好一些：裁剪spec，当然现实中可能性比较小，所以spec区分优先级是个很不错的选择。之后的做法有不同的路径，比如有些spec可以少做一些用例等等。
当然还有一些细节的做法可以考虑，比如stimulus尽量做到正交化等等，这些是验证功力的问题，超出了本话题的范畴。
另外，再说一些题外话。
从LZ在芯片验证举例中，我理解LZ的芯片可能在checker的开发力度上的需求可能不是太高，但这种情况不具普适性，也许LZ认为的百分比比实际需要的百分比要低一些，这些情况都有可能，总之，不希望存在一个误导，就是最后验证实践过程成了拼RP了，这就违背了验证的本意了。
LS shuo de tai hao le
关于simulus和checker的问题，LZ想表达的意思应该是要重点关注simulus的完备性，checker当然也很重要，在时间和人力紧张的情况下，可以暂时用“经济实惠”的“偏方”来代替正规严谨开发出来的checker。LZ在进度要求紧张时，采用的看图形其实也是checker的一种。
也许LZ的这种重simulus轻checker的想法是由于其项目环境造成的。因为LZ在项目前期开发simulus时很重视且时间较充裕，因此功夫下得很到位。在项目中后期启动checker开发时往往由于时间紧、任务重而不得不草草收尾。其实，个人认为在simulus启动开发时就应该并行启动checker的开发了。
以上纯属个人观点！
stimulus完备性十分重要。不完备的stimulus不能覆盖所有的功能点。
而checker如果没有充分完成，就无法保证dut功能的正确性。
对于最后所举的例子，我觉得之所以那个项目可以在checker没有充分完成的情况下
没有出现不得了的bug，是因为这个是一个图像处理的设计。
dut的output在无法用checker充分检验的情况下，转化为图片，用看图的方式进行检查。
而项目设计的最终应用本来就是为了产生图像给人看，恰巧和你们所用的方式有一致性。
换个其他方向的项目，八成就不行了。
感觉小编对stimulus更为看重。是不是您的项目都是图像处理方面的呀?
有没有兴趣开个新贴，讲讲图像芯片的验证心得?
我很是赞同你的看法，chenshi同学。
经验之谈，鼓励一下！
我主要是做SoC的项目，图像是其中一部分，算是比较重要的部分。 我个人觉得验证的基本思想是比较一致的，倒是不怎么用区分多媒体、通信、cpu等。 我想一想我做图像方面有什么比较特殊一点的验证方法或者技术吧。
we will be right here waiting for you~
初来乍到
严格来讲，现在Verification的规模是越来越大了
学习了。
大的验证项目的话，还有一些和它们同样重要的东西，比如参考模块等
你好，请教一下“stimulus正交化”是个什么概念?能推荐一些相关的资料吗?