今日话题：验证的纠结，比对还是不比对，该如何比对？

话题背景今天听一个同事给我抱怨说：他负责的模块其中有一个很简单的规格，如果通过看代码即代码检视，或者check 波形，就是1、2分钟的事情；但是如果要在环境中添加自动比对，至少要搞1、2个小时才能搞好；
他认为添加自动比对机制收益太小，但是他的领导又要求他添加自动比对机制，于是他很郁闷，。
本人感受：
其实我也遇到过类似纠结的事情；但我一直认为：验证就像打仗一样，DUT的规格、feature就是敌人，怎样在牺牲最小的情况下歼灭敌人?这是你这个元帅需要思考的（每个验证人员，都是这场验证战役里面，正义之师的元帅）；
战役要取得胜利，最重要的是策略-----你的验证策略；
其次你的武器的先进程度---你用的验证工具；
当然还有你对敌人的了解程度---对DUT规格的了解（知己知彼，百战不殆嘛）
所以我认为，验证就像打仗一样，为了胜利你可以多种兵种，多种武器相结合，水陆空一起配合达到最优的效果；自动比对你可以使用sv编写rm、checker，你也可以用断言检测，或者用脚本离线比对，甚至你可以用formal等其它手段验证；即使用sv编写checker，这里又是条条大道通罗马，肯定有那么一条是最近的；
小结：
我的观点是：尽量实现自动比对，这样便于回归，也便于后期他人的接手；但是实现自动比对的手段可以更多样化，更别具一格，从而能达到更好的收益（投入产出比）；不要认为创新、创造那是设计人员的事，在你的战役里你是国王你可以任性！
一点随想，写的比较匆忙，欢迎大家积极交流讨论；

看来跳出苦海了

有时候搭平台确实费时费力，但是科学也好，工程也好，不能主观的说代码我check过，波形我也check过，所以就OK了，需要有客观的指标来确定什么时候算验证收敛，就像你之前的帖子讨论的一样。
就算不说指标，BOSS也会要求有点东西来证明你的验证OK了。
多思路是好事，不同的设计，最佳验证方法不尽相同，往往是多种方法的组合。而且和验证工程师自己对DUT的熟悉程度，工具的熟悉程度，继承环境的debug机制都有关系。究竟是静态分析，还是单步调试，需要自己去选择。

“就算不说指标，BOSS也会要求有点东西来证明你的验证OK了”
你这话说的很好，就说我们验证人员的工作：小到平时日常的技术讨论，大到一个模块的验证报告评审，只要你抛出自己的观点就必须有材料来支撑它；
否则你就会被评审专家或领导一个接一个的追问给击倒，自己会被问的支支吾吾，处境相当尴尬；当然大家会认为你考虑的不够充分，从而觉得你工作做的还很不到位，领导也会表示很不放心。