作者：电子创新网编辑部
图源：AI生图
芯片行业这几年被AI带动得很热，一个反复出现的说法是：未来可以从规格直接生成硬件，甚至不需要懂RTL、不需要懂架构，只要描述需求，AI就能完成设计。
这个叙事听起来很顺滑，但在真正做过SoC或复杂IP验证的人看来，它忽略了一个最硬的现实：芯片设计的问题，从来不在“能不能写出来”，而在“有没有被证明是对的”。
而验证工程师，正是这个现实的第一见证者。
一、设计只是起点，验证才是主战场
如果把芯片开发拆开看，设计只是第一步。
真正占用资源的部分是验证：
• 功能验证
• 时序验证
• 形式验证
• 系统级仿真
• 软件协同验证
在复杂SoC项目里，一个很常见的结构是：设计完成了，但验证还没开始收敛。
甚至在很多团队中，验证周期可以达到设计周期的2到3倍。
原因并不复杂：设计是在“构造一个系统”，验证是在“证明这个系统不会在任何情况下出错”。
这两个问题的难度等级并不对称。
二、验证不是测试，是“寻找所有可能的失败路径”
很多人会把验证理解为测试，但工程上完全不是一回事。
测试回答的是：在给定输入下系统是否工作正常
验证回答的是：是否存在任何输入，使系统失效
这意味着验证不是抽样，而是覆盖：
• 所有状态空间
• 所有时序组合
• 所有异常路径
• 所有边界条件
• 所有跨模块交互
问题在于，这个空间是爆炸的。
一个中等复杂度的设计，其状态空间可能远超人类直觉能处理的范围。
因此验证工程的本质是：用有限资源逼近无限状态空间。
三、AI进入设计，但没有进入“错误空间”
AI在芯片设计中的讨论，通常集中在一个方向：
• 自动生成RTL
• 自动生成架构
• 自动生成模块代码
但验证工程师看到的是另一件事：AI没有改变错误的数量，只是改变了错误的分布方式。
原因在于，AI生成的是“看起来合理的结构”，但芯片问题往往来自：
• 时序边界条件
• 并发竞争
• 跨时钟域交互
• 非典型输入序列
• 软件与硬件交互时序
这些问题的共同特点是：它们不在“正常路径”上，而AI擅长的是正常路径。
四、真正困难的不是设计复杂，而是系统不可完全定义
芯片验证的另一个核心现实是：很多spec本身就不是完整的。
在实际工程中，spec经常存在：
• 模糊描述
• 隐含约束
• 互相冲突的要求
• 未定义的异常行为
这意味着验证不仅是在验证设计，还在反推spec到底想表达什么？
这也是为什么验证工程师在项目中经常扮演“规则解释者”的角色，而不仅是“错误发现者”。
在这种环境下，“AI可以替代验证”的前提几乎无法成立，因为：你无法用不完整的规则自动证明系统正确。
五、AI最容易低估的一点：验证不是生成问题，而是对抗问题
设计是生成问题：给定约束，构造一个满足条件的系统。
验证是对抗问题：尝试找到系统失效的路径。
这两者的思维结构完全不同：
• 生成追求可行解
• 验证追求反例
而AI目前的优势主要集中在“生成侧”。
但在验证侧，问题变成：
• 如何系统性构造极端输入
• 如何探索边界状态
• 如何覆盖低概率但高风险路径
这更接近“对抗搜索”，而不是“模式生成”。
六、为什么验证工程师对“AI写芯片”反应冷淡
如果把AI生成硬件的叙事拿到验证团队，会出现一种很典型的反应：不是否定技术，而是降低预期。
原因有三个现实经验：
1. 错误永远不会按平均分布出现
芯片失败通常来自极少数corner case，而不是平均行为。
2. 系统复杂度越高，验证成本增长越快
不是线性增长，而是组合爆炸。
3. 最难的问题往往在“接口之间”
单模块正确没有意义，系统错误通常发生在交互层。
这些问题都不依赖“代码写得好不好”，而依赖：是否完整覆盖系统行为空间
七、AI可能改变验证，但不会消除验证
更现实的路径不是“AI替代验证”，而是：
• 自动生成测试用例
• 辅助覆盖率分析
• 构造边界场景
• 识别潜在不一致路径
• 优化验证计划
也就是说，AI进入的是：验证工程的“增强层”，而不是“替代层”。
但核心逻辑不会变：验证的目标仍然是找错，而不是证明正确。
八、结语：工程现实不会因为生成速度改变
AI让“生成设计”变得更容易，这是事实。
但芯片行业的核心约束，从来不在生成。
而在另一侧：是否存在任何未被发现的错误。
在这个问题上，验证工程师始终站在第一线。
所以当外界讨论“AI能不能写芯片”时，验证工程师的反应往往很简单：
不是否认进步，而是知道边界在哪里。
AI可以让设计更快，但无法让“正确性”变得便宜。
而在芯片行业，这一点从未改变。
本文为原创文章，转载需注明作者、出处及原文链接，否则，本网站将保留追究其法律责任的权利