设计工程师学一点验证，不是跨界

芯片项目里有一种很常见的内耗——设计和验证在扯皮。这种沟通摩擦本质上是知识盲区造成的。设计工程师如果从没写过 testbench就很难理解验证工程师面对的是什么处境。举个具体的例子。设计写了一个这样的状态跳转always (posedge clk) begin if (pkt_cnt cfg_threshold - 1 arb_grant !flush_pending) state DRAIN; end逻辑上完全正确。但验证工程师拿到这段代码要覆盖这个跳转需要同时让pkt_cnt精确打到阈值减一、仲裁恰好授权、flush 没有挂起。这三个条件来自不同的模块要在同一个时钟沿对齐激励构造难度很高。设计工程师如果懂这些当初可能就会加一个 assertion或者只是一条注释都能省掉验证很多时间。沟通摩擦背后还有一个原因很多设计 bug其实是设计工程师在写 RTL 时没有想清楚边界。断言、边界条件——这些是验证的工具但背后的思维是把所有可能出错的情况列出来一个个去确认。这种思维方式用在设计阶段其实就是在逼自己把 spec 想透。一个信号在复位时是什么值溢出怎么处理两个请求同时到来优先级怎么定这些问题如果设计工程师在写代码前就想清楚了验证阶段发现的 bug 数量会直接减少不是因为验证变弱了而是设计本身变严谨了。有人会觉得这是验证的职责设计不用操心。但现实是bug 发现得越晚修复成本越高。仿真阶段发现的问题比门级之后发现要便宜得多更不用说流片之后。设计工程师自己能提前堵住的漏洞就没必要等验证来发现。而且坦率说很多设计工程师在 review 别人代码或者写完自己模块后自己很难发现边界问题——因为思维惯性会让人默认正常路径。学过验证的思维方式之后会开始主动想异常路径这是一种真实的设计能力提升。学验证不是要去精通 UVM也不是要去抢验证工程师的活。需要的只是框架认知覆盖率在衡量什么断言在保护什么边界条件为什么重要。有了这一层和验证工程师开会时能听懂对方在说什么写 RTL 时脑子里会多一个维度review 代码时会多问几个问题。这些改变很细微但积累下来设计质量和协作效率都会不一样。