设计工程师最崩溃的时刻,大概就是信心满满地提交代码,然后被验证团队甩回来一份长长的bug列表。
“这都什么奇葩场景?谁会这么用?”
“正常情况下根本不可能出现这种输入!”
“你们是不是故意找茬?”
但验证团队的回答往往很简单:我们只是把所有可能性都试了一遍。
设计人员做仿真的时候,脑子里想的是典型应用场景。设计一个UART模块,就测一测正常收发数据,波特率切换,也许再加几个异常情况处理。跑通了,看起来挺完美,交付。
但验证团队拿到手就不一样了。
他们会问:如果同时收发会怎样?如果在传输过程中突然断电重启呢?如果两个模块同时抢总线呢?这些场景设计人员压根没想过,因为”正常情况下不会发生”。
问题就出在这个”正常情况”上。
芯片一旦流片出去,就会被用在各种各样的系统里。有些客户按规矩使用,有些客户会搞出匪夷所思的操作。也许是软件工程师写错了配置,也许是硬件设计有缺陷,也许就是某个极端环境触发了低概率事件。
验证的价值就在于此——把那些设计者想象不到的场景全部暴露出来。
这种全面性是设计自测根本达不到的。设计人员的思维路径已经固化在”我想实现什么功能”上,测试也会沿着这条路径走。而验证团队是带着”这东西怎么可能出错”的心态去折腾,专门找边界条件、异常组合、时序冲突这些刁钻角度。
当然,验证爆出来的bug也不全是真bug。
有些确实是设计问题,逻辑写错了或者边界处理不当。但也有相当一部分是验证自己理解偏了,参考模型建错了,或者测试用例本身有问题。还有一类最麻烦,也最重要，就是需求文档写得模棱两可,设计按一种理解实现了,验证按另一种理解验证了,结果对不上。
这时候就得坐下来掰扯。
设计拿出需求文档:“你看这里明确写了这么处理。”
验证指着另一段:“但这里又说了那样的情况,你的实现覆盖不了。”
两人争半天,发现问题根源在于需求定义本身就有漏洞。
这种争论看似低效,实际上是在完善整个系统的定义。设计和验证从不同角度理解同一份需求,碰撞出来的分歧恰恰暴露了规范中的模糊地带。这些坑如果不在验证阶段填上,流片后遇到客户投诉就晚了。
所以当设计工程师看到那份长长的bug列表时,先别急着生气。
里面有真问题,能救你一命;有假问题,说明需求得澄清;还有模棱两可的问题,正好逼着整个团队把定义理清楚。这些bug不是验证在找茬,而是在帮整个项目排雷。
从某种意义上说,验证就是在模拟真实世界的复杂和残酷。
现实中的系统不会温柔地按照设计意图运行,它会出现各种意外、误操作、极端情况。验证团队提前把这些糟糕场景演练一遍,总好过芯片到了客户手里才暴雷。
那些被验证虐过的设计,往往才是真正robust的设计。
抱怨归抱怨,但每个经历过流片失败的工程师都会承认:宁可在验证阶段多吵几架,也不想在产线上收到召回通知。
