AI 补模型，EDA 的新成本账|eda|上下文|方法学|神经网络

AI + EDA 这几年有一个特别诱人的说法：什么时候能从 specification 一路做到 tape-out？

这句话很适合做标题，也很适合做演示。但真放到芯片研发现场，它反而会遮住一个更现实的问题。

SemiEngineering 最近写了一篇文章，问的是另一件事：AI 能不能把 EDA flow 里那些缺失的、昂贵的、没人愿意长期维护的模型补起来？

我觉得这个问题更值得聊。

因为 EDA 的很多变化，过去不是没人想过，而是被模型成本卡住了。模型要写，要校准，要验证，要维护，还要跟着工艺、工具版本和设计上下文一起变。账算不过来，方法学再漂亮也只能停在论文、原型工具或少数大厂内部。

所以这不是“AI 又会生成一个文件”的故事。它更像是在问：AI 会不会重新改写 EDA 的成本结构？

EDA 本来就是模型驱动的行业

EDA 里的“模型”不是新东西。

RTL 是模型，testbench 是模型，架构性能模型是模型，AMS 里的 behavioral model 也是模型。再往后看，PPA 预测、工具参数探索、verification plan、coverage model、PSS 模型，本质上也都是对复杂设计问题的抽象。

模型的工作很朴素：留下当前任务需要的信息，把暂时不需要的细节藏起来。

没有抽象，仿真和分析跑不动；抽象太狠，结论又可能不可信。芯片设计很多麻烦就夹在这中间。

一个模型越接近真实物理世界，通常越慢、越贵、越难维护。一个模型越抽象，跑得越快，但拿它做决策时心里也越没底。真正的问题从来不是“模型越准越好”，而是“在这个阶段，用什么成本拿到足够可信的模型”。

过去电子系统级抽象、早期架构探索、性能模型、顶层 AMS behavioral simulation 都有过很强的吸引力。但项目团队最后会算一笔很冷的账：如果建模本身要占掉大量专家时间，那我为什么不等更低层级结果出来？

AI 的机会就在这里。

如果它能把模型创建成本降下来，很多原来因为不划算而被放弃的 flow，就可能重新变得可用。

缺的不是文件，是可相信的抽象

把 AI 用来生成模型，听起来像内容生成问题。但在 EDA 里，它首先是可信度问题。

SemiEngineering 文章里有个例子很典型：用神经网络拟合滤波器模型，曲线可能看上去不错，但如果没有电子系统知识约束，模型可能违反 passivity 等基本物理准则。它看起来像，不代表它真的对。

这就是 AI 进入 EDA 后最容易被低估的地方。

软件里的 AI 生成，很多时候可以靠运行、测试和上线反馈慢慢修。芯片设计不一样。一个模型如果被用来做架构判断、约束选择或验证覆盖决策，它的错误不会停在模型里，而会一路传到后面的工程动作。

所以 AI 生成模型的前提不是“生成得快”，而是“知道它在什么条件下可靠，什么条件下必须停下来”。

这会把 EDA flow 里的模型分成几层：

• 早期探索模型可以粗一点，但必须说明误差范围。

• 优化加速模型可以替代一部分昂贵仿真，但最终要回到更细粒度仿真确认。

• 影响 sign-off 前判断的模型，必须有确定性检查和人工 review。

• 用于数据分析或流程调度的模型，要求可以低一些，但不能混进关键决策链路。

AI 真正带来的不是一个万能模型生成器，而是一套更细的模型分层策略。

Analog 可能最先受益，也最容易踩坑

文章特别提到 analog/mixed-signal 场景。这个方向确实很有代表性。

模拟电路和混合信号设计经常依赖高精度仿真。晶体管级仿真、物理仿真、电磁和热分析，在复杂设计里可能非常耗时。顶层仿真如果每个模块都跑全细节，工程上很快就不可承受。

behavioral model 的价值就在这里：它不模拟所有内部细节，而是复制一个模块的输入输出行为，让顶层验证、系统级分析和设计优化更快往前走。

如果 AI 能帮工程师更快生成高质量 behavioral model，AMS flow 的门槛确实会下降。很多团队不是不知道应该建模，而是缺少足够多会写好模型的人。AI 让模型生成更便宜，就可能让更多问题在更高层级、更早暴露出来。

但 analog 也是最能证明“AI 不能裸奔”的地方。

PLL、ADC、DAC、LDO 这类模块，有大量非线性行为、工艺敏感性和上下文依赖。不是拿几组输入输出数据拟合一下，就能放心替代真实仿真。模型是否满足稳定性、passivity、边界条件、工艺角、温度和电压变化，往往比拟合分数更重要。

这意味着 analog 里的 AI 建模不会把专家拿掉，反而会把专家前移。专家不一定每次手写完整模型，但要定义建模路线、评价指标、采样策略和可用边界。

说白了，AI 能省的是重复劳动，不是工程责任。

数字后端已经给出了一种答案

在数字后端，AI 辅助优化已经有相对清晰的产品形态。

Synopsys DSO.ai 和 Cadence Cerebrus 都把强化学习用于大规模设计空间搜索。Synopsys 官方资料称，DSO.ai 使用 reinforcement learning 在巨大的芯片设计解空间里搜索优化目标，以改善 PPA。Cadence 也把 Cerebrus 定位为 AI-driven 的芯片设计 flow 优化工具，用于自动优化 power、performance、area。

这类工具最有启发的一点是：模型不是凭空生成的。

它们通过跑真实 EDA flow，观察综合、实现、时序、功耗、面积等结果，逐步学习哪些工具设置和 flow 配置更可能带来好结果。

这和“给 LLM 一段 specification，让它一次性吐出设计”完全不同。

后端优化里的 AI 更像一个在真实工具链旁边反复试错的策略搜索器。训练数据来自 flow 执行本身，反馈来自工具结果，目标函数也更清楚。即便这样，工程师仍然要控制目标、看结果、判断 trade-off。

这可能是 AI + EDA 更现实的路线：不是跳过 flow，而是让 AI 在 flow 内部学习；不是替代 sign-off，而是把探索成本降下来；不是用一个大模型吞掉所有环节，而是让不同抽象层级的模型围绕确定性工具形成闭环。

这也是中科麒芯关注的方向：把专业模型、企业知识库、设计流程编排和 Agent 治理连接起来，让 AI 不停留在个人问答助手，而是进入芯片研发可用、可控、可追溯的工程链路。

RTL 生成最大的问题不是语法

聊 AI 生成模型，很快会绕回 RTL。

现在 LLM 写 Verilog 或 SystemVerilog 片段已经不稀奇。真正麻烦的是，能通过仿真的 RTL，不等于能实现、能收敛、能进入生产设计库。

SemiEngineering 引用的观点很直接：functional correctness 和 implementation correctness 不是同一个属性。一个 RTL 在仿真里功能正确，但如果没有 timing closure 意识，没有清楚的 reset strategy，没有 clock domain discipline，后端可能根本收不住。

这句话对 AI + EDA 很关键。

LLM 更容易学到“代码长什么样”，却很难从公开语料里学到某个团队在先进节点、具体 PDK、具体 IP 组合下的物理实现纪律。很多真正决定芯片能不能做出来的知识，不在公开教程里，而在项目历史、内部 checklist、review 记录、失败案例和 CAD flow 里。

因此，AI 生成 RTL 的上限，不只取决于模型参数规模，还取决于它能不能接触到工程上下文，能不能被 LINT、CDC、仿真、形式验证、综合、STA 等工具持续纠偏。

如果没有这些反馈，它很容易生成“看起来对”的代码。对芯片团队来说，这还远远不够。

验证模型会是另一个关键战场

原文还有一个很重要的方向：verification model。

AI 不一定只生成 RTL，也可以生成 verification plan model、testbench、assertion、coverage model，甚至帮助创建 PSS 模型。Accellera 对 PSS 的定义，本来就是把 verification intent 和行为以可复用方式描述出来，让同一份规范可以在多个平台和上下文中自动生成测试。

这类抽象和 AI 很契合。

验证的难点不是简单写更多 test，而是把设计意图、场景组合、约束关系、覆盖目标表达成可执行、可复用、可追踪的模型。过去 PSS 的门槛之一，是工程师要学习新语言和方法学。AI 如果能把自然语言规格、场景描述和已有验证资产转成 PSS 或类似抽象，就可能降低这个门槛。

但验证模型同样不能只看生成。

AI 生成 assertion，要能被形式工具或仿真环境检查。AI 生成 UVM testbench，要能跑，要能覆盖目标场景，还要避免 false-pass。AI 生成 coverage model，要和真实验证计划一致，不能制造虚假的覆盖率安全感。

生产环境里的硬要求应该很明确：任何 AI 生成的设计或验证 artefact，进入设计数据库前，都要经过确定性检查。可以是 simulator，可以是 FPV engine，可以是 lint tool，也可以是多种工具组合。

这不是保守，是芯片行业的基本盘。

模型维护会成为新的隐性成本

AI 降低模型创建成本以后，行业很快会遇到另一个问题：谁来维护这些模型？

模型不是写完就结束。

PDK 会更新，工艺数据会变，设计风格会变，IP 版本会变，EDA 工具也会变。一个去年表现不错的模型，今年未必还适用。尤其是 domain-adapted model，它越贴近某个团队、某类设计、某套 flow，就越需要持续跟踪版本和适用范围。

这会带来一串新问题：

• 模型什么时候需要重训？