大模型和芯片工程师都会犯错——凭什么用零缺陷标准要求前者?
跨时钟域漏处理、验证约束文件过约束了——这些问题在流片前几乎每个项目都会遇到。没有人会因为工程师犯了这些错误就说"这个人不能用"。
那为什么大模型一旦出错,就有人开始质疑它的价值?
这个双重标准值得认真想一想。
现在很多团队在用大模型辅助芯片开发,比如让它帮忙写UVM testbench、生成初版的SystemVerilog模块、或者解释某段复杂的时序逻辑。用起来顺手的时候没人提,一旦模型输出有问题,马上就有声音说"是吧,还是不靠谱"。
这才是关键——模型的输出需要人来审,就像下游模块需要上游工程师review一样。这不是模型的缺陷,这是工作流程本身就该有的环节。
问题不在于模型犯不犯错,而在于整个开发流程有没有把"纠错机制"设计进去。
芯片开发本来就是一个层层验证的过程:仿真、形式验证、门级仿真、流片后测试……每一层都是在假设前一层可能有问题的前提下设计的。这套体系的底层逻辑就是:没有任何环节是完美的,所以要多层冗余。
把大模型引入这个流程,思路应该完全一样。不要期待它零错误,要把它当作一个需要被验证的环节。
进步比完美更实际,也更有意义。
如果模型能把一个工程师写初版RTL的时间从两天缩短到半天,哪怕它产出的代码有20%需要修改,整体效率还是提升了。
技术的准确性当然重要——芯片领域容不得模糊,一个bit的错误可能导致整片报废。但准确性应该由整个系统来保证,而不是把所有压力压在某个单一节点上。无论这个节点是人还是模型。
工程师自己也会在凌晨改bug时写出有问题的代码,也需要code review,也需要CI检查。要求模型做到工程师都做不到的事,这个逻辑本身就站不住脚。
目标是持续进步,不是等待完美降临。
