AI 时代，一个人能不能做出 EDA 工具？

这个问题放在两年前，答案几乎是肯定的：不能。EDA 工具的门槛被描述得像是某种不可逾越的天堑——算法复杂、格式晦涩、需要跟晶圆厂签 NDA 才能拿到库数据、需要庞大的工程团队写几百万行 C++。但这两年有两样东西在变：AI 写代码的能力，和开源 EDA 生态的成熟度。于是这个问题值得重新问一遍。

先说我的判断：一个人做 EDA 工具，从来没有像现在这么接近"可能"。但这个"可能"的边界在哪，得拆开来看。

传统观点认为个人做不了 EDA，理由无非几条：格式复杂（Liberty、LEF/DEF、Verilog 每个都是几千页的 spec），算法太难（布局布线是 NP-hard），没有 PDK 数据没法验证，商业工具已经垄断了几十年。这些理由放在今天还成立吗？

格式解析这件事，已经被开源社区解决了。OpenDB 能读 LEF、DEF、Liberty，Yosys 能读 Verilog，KLayout 能读写 GDSII。你不用从零写 parser，直接站在这些库上面，省掉的工程量以人年计。算法方面，主流 EDA 算法的论文都是公开的——ePlace/RePlAce 的布局算法、PathFinder 的布线协商、STA 的图遍历和迟滞传播，每一篇都写得清清楚楚。把论文变成代码这件事，恰好是当前 AI 最擅长的。

那 PDK 呢？没有 PDK 数据，工具做出来怎么知道算得对不对？这也是过去几年变化最大的地方。SkyWater 的 SKY130、IHP 的 SG13G2、GlobalFoundries 的 GF180MCU，这些都是真正可以流片的开源 PDK，Liberty、LEF、techfile 全套齐全，Apache 或 CC 协议发布，个人可以随便用、可以商用。它们不是玩具，上面已经跑过大量真实芯片。

验证方法也有了现成的答案。开源 EDA 生态里有一套完整的参考工具链：OpenSTA 做时序分析，Yosys 做综合，OpenROAD 做布局布线。你的工具算出来的结果，可以和 OpenSTA 逐 endpoint 对比，做差分验证。这跟商业 EDA 公司内部的验证方法论本质上是一样的——只不过你的"golden"从商业工具换成了开源工具。

写到这你会发现，传统认为的那些"个人做不了"的理由，每一条都在被瓦解。那是不是说一个人加一个 AI 就能做出一个完整的 EDA 工具链了？别急。

不是所有的 EDA 模块生而平等。如果你把 EDA 工具拆成几个核心引擎，它们的难度差距很大。

时序分析引擎是最现实的切入点——但产品方向不是卖 STA，而是以 STA 为核心的 ECO 工具。ECO（Engineering Change Order）工具做的是增量优化：找到时序违例、建议换 VT 类型、调整 buffer 尺寸、插入 buffer。它的核心引擎就是 STA，但精度要求比 signoff 低得多——你不需要算到小数点后精确，只需要把违例路径排对序。这个精度区间，个人开发是够得着的。

这个定位的巧妙之处在于，技术难度和商业门槛同时降了一档。技术上，ECO 工具只需要 STA 做到"相对排序准确"而非"绝对数值精确"——前者比后者容易一个数量级，因为很多系统误差会在排序中被抵消。商业上，ECO 工具不碰 signoff，不需要晶圆厂认证，卖的是"帮工程师省时间"而不是"替工程师做决策"，客户的信任成本完全不同。

布局引擎也处于"可行"的区间。算法论文公开，DREAMPlace 甚至有开源的 GPU 实现可以参考。难点在于调参——density 和 wirelength 的权重怎么设、timing-driven 的 net weighting 怎么做，这些需要跟真实设计反复碰撞才能收敛。验证也比 STA 模糊：你不能直接比坐标，得比下游的 QoR，验证环路更长。

寄生提取也处在一个有趣的位置。pattern matching 加 2.5D 场求解的方法论是公开的，原型不难。但要达到 signoff 精度，需要和晶圆厂提供的 techfile 对标——那些 techfile 里凝结了工艺 know-how，不是开源能解决的。

布线器则是另一个故事。global routing 的协商拥塞算法是公开的，个人可以实现。但先进节点的 detail routing 面对的是几百条设计规则、多图案分解、pin access 的几何复杂性。OpenROAD 的 TritonRoute 是一个团队做了好几年才到现在这个水平，离商业工具仍有差距。这个模块目前仍然是"团队级工程"，不适合个人挑战。

所以如果你问我"个人+AI"做 EDA 的可行性边界在哪，我的回答是：STA 引擎、布局引擎、提取引擎的单点实现，可行；完整工具链、先进节点 detail router，不可行。但算法可行只是第一步。真正的分水岭是规模工程——一个 naive 的数据结构在十万 instance 上跑得不错，到了千万 instance 就内存爆炸、cache miss 飙升。数据结构和内存布局的设计，是个人项目和工业级工具之间最隐形也最硬的鸿沟。

还有一个经常被低估的技术风险，我称之为"论文-实现鸿沟"。一篇 EDA 论文只描述核心思想，从论文到工业级实现之间，隔着几十处没有写出来的启发式策略、参数调度方案、数值稳定性技巧。这些"暗知识"只有通过反复实验才能找回来。AI 能帮你写论文描述的 80%，但剩下的 20%——那些只有试过才知道的东西——仍然需要你亲自去碰。好消息是，差分验证给了你一个"逼近"的手段：你的输出和 golden 的差距，就是你需要填补的暗知识。

这引出一个有趣的问题：一个人做出来的 EDA 工具，有人敢用吗？

这个问题分两层。第一层是技术信任：你的工具算得准不准？如果你能展示一套完整的差分验证体系——在开源 PDK 上、跟开源 golden 逐 endpoint 对比、误差分布公开可查——那技术信任是可以建立的。开源 EDA 社区已经在走这条路，OpenROAD 的 QoR 报告就是公开的。

第二层是业务信任。如果你做的是 signoff 工具，确实需要晶圆厂认证——那这条路个人走不通。但如果你做的是 ECO 工具、设计辅助工具、流程自动化工具，这条线是不用跨的。这些工具不替代 signoff 流程，只是帮工程师在 signoff 之前做更快的迭代。客户买的是效率，不需要你提供签核背书。

这里还有一个很多人没意识到的技术事实：EDA 引擎是工艺无关的。你的 STA 引擎读的是 Liberty 格式，不管这个 Liberty 来自 130nm 还是更先进的节点，查表插值的数学没有区别。在开源 PDK 上开发验证的引擎，到了任何合法获取的工艺数据上都能直接跑。工具的能力边界不取决于你在什么工艺上开发它。

这个市场其实比 signoff 工具市场大得多。每家设计公司都在用各种自制的脚本和工具来填补流程缝隙——ECO、floorplan 评估、power plan 迭代、congestion 预测、CTS 调试、数模混合的 placement……它们不好用、难维护、但不得不做。一个更好用的替代品，不需要 certification，只需要"比他们自己写的强"。这是个人开发者最现实的生态位。

写到这，我其实没有标准答案。这篇文章本身就是抛砖引玉。我的判断基于我对开源生态和 AI 能力的观察，但我很可能是错的——要么低估了 AI 的进步速度，要么低估了 EDA 的隐性复杂度。

所以我真正想问的是：你在实际工作中，最希望有一个更好的工具的环节是什么？是 ECO 的反复迭代、floorplan 的方案评估、power plan 的快速探索，还是别的什么？来评论区聊聊你的痛点，也许下一篇文章就聊你提的方向。