EDA 工具选型与采购：在「能用、好用、被认证、买得起」之间权衡（G4）
本篇讲组织级决策：一个环节往往有两三家商业工具（综合 DC vs Genus、P&R Innovus vs ICC2、仿真 VCS vs Xcelium vs Questa、形式 VC Formal vs JasperGold vs Questa Verify），怎么公平评估、怎么算账。各工具的技术纵深见本目录对应分篇，算力与 license 运行机制见 G1 LSF，工具链与数据格式绑定见 F10 版本基线。
一、先认清一个前提：不存在「全局最优工具」
EDA 是高度经验驱动、强耦合的工业软件，工具之间不是「谁全面碾压谁」，而是：
- 各有擅长的设计类型/节点/场景（有的某类高速 SerDes 强、有的大规模数字吞吐高、有的低功耗好）；
- 结果强依赖库质量、foundry 认证版本、工程师经验和设计约束质量——同一个工具，高手和新手结果差距比工具间差距还大；
- 全流程各工具之间有数据与流程耦合（约束、库视图、ECO 反标、签核一致性）。
所以选型不是「跑分越高越好」，而是「在我们的设计、我们的节点、我们的团队、我们的预算下，综合 TCO 与风险最低」。
二、评估维度（不只看 QoR）
| 维度 | 具体看什么 |
|---|---|
| QoR / 签核相关性 | 时序（WNS/TNS）、面积、功耗、能否在黄金签核（PrimeTime/Calibre）下干净收敛——实现工具自评不算数，以独立签核工具的相关性（correlation）为准 |
| 容量与运行时间（capacity/runtime） | 我们最大设计的峰值内存、单 run 墙钟时间、多机扩展（见 G3） |
| 收敛可预测性 | 结果稳不稳、是否靠大量手工魔法脚本/个人经验、版本升级会不会 QoR 漂移 |
| 可用性/学习曲线 | 文档、报错可读性、调试手段、命令一致性、团队上手成本 |
| 生态与集成 | 与我们既有上下游工具/库/IP/流程的衔接、脚本资产复用、厂商 AE 支持响应 |
| foundry/PDK 认证 | 目标工艺节点的 tool version + kit 是否被 foundry 认证（F10）——没认证的工具/版本不能用于量产签核 |
| 路线/风险 | 厂商投入、是否可能停更/收购、长期支持 |
| 成本 | license 与续费、所需硬件/算力、AE 服务、培训 |
签核相关性常比单点 QoR 更重要：A 工具内部报告好 2%，但交黄金 STA 后冒出一堆违例、ECO 反复，工程时间成本远超那 2%。
三、PoC / benchmark 怎么设计才公平
选型要有可复现、双盲、同口径的 PoC（Proof of Concept），否则结论会被厂商 AE 的「精选 demo」带偏：
- 用自己的真实设计，不是玩具也不是厂商自带样例——最好挑 1 个近期量产/在研的代表性模块 + 1 个最难（时序/规模）模块；
- 同一份输入、同一套约束与库版本：相同 RTL、黄金 SDC、同一 PDK/库角、相同 MMMC scenario（E2）；
- 限定相同的工程预算：给两家 AE 相同的人时（如各 2 周、同等专家投入），而不是一家调一个月、一家只跑默认；
- 统一裁判：最终都用同一套独立黄金签核（PrimeTime/Tempus + Calibre/Hercules、同一签核版本）量 QoR/DRC/LVS，而非各工具自报；
- 记全指标：WNS/TNS、面积、漏电/总功耗、runtime、峰值内存、违例清零所需 ECO 轮数、工程师工时；
- 复现性与回归：跑两遍看结果方差，换版本看漂移，要求厂商留下可复现流程与脚本；
- 让未来的实际使用者参与：跑流程的工程师评价易用性、文档、报错、AE 响应——买来难用等于沉没成本。
警惕「benchmark 特调」：厂商可能针对评测设计手工调优。可在评测中途追加一个没见过的设计，看泛化能力与默认流程的真实水平。
四、license 商业模式：报价单背后的账
| 模式 | 含义 | 适合 |
|---|---|---|
| Floating / concurrent（浮动并发） | license server 按并发数发放，团队共享（见 G3 FlexNet） | 大多数公司主流，利用率高 |
| Token / credit | 买通用令牌池，不同工具/特性按费率扣点 | 多工具、用量不均，灵活但费率可被调 |
| Term / subscription（期限订阅） | 按年/三年订阅，含升级与支持 | 现金流友好，持续是支出 |
| Perpetual（永久+年维护） | 一次买断版本 + 每年约 20% 维护费 | 长期稳定工具，老派模式 |
| Site / company-wide（站点/全包） | 不限量企业协议 | 超大厂摊薄单价 |
- 高级特性单独收费：签核模式、某先进引擎、某 foundry 套件、多机分布式额度常是独立 feature/令牌，询价要按完整场景列清单，不能只问基础价；
- 真实 TCO = license/续费 + 算力（多核/分布式机器成本）+ AE 服务 + 培训 + 人员学习成本 + 迁移/返工风险；
- 谈判常以多年期 + 捆绑套件 + 预付款换折扣，季末/财年末厂商更有动力；
- 还要看许可证使用计量：买前用日志统计真实并发峰值，避免买多（浪费）或买少（半夜排队，G3）。
五、为什么大厂常常「全套绑定」而不是逐环节选最优
理论上可在每个环节都选该环节最好的工具（best-of-breed），实践中大厂更常整套采用一家流程，原因是集成成本与风险：
- 同厂工具间约束/库/ECO/签核数据互通更顺，跨厂交接靠标准格式（网表/SDC/SPEF/LEF/DEF，见 F1–F7）总能转，但厂商私有扩展、ECO 反标、增量流程会丢信息或不收敛；
- 签核工具与实现工具的相关性在同厂生态通常被重点打磨（DC→ICC2→PrimeTime、Genus→Innovus→Tempus 各自闭环）；
- 单一 vendor 责任清晰、AE 协同、脚本与人员技能统一；
- 商务上买整套折扣远好于零买，且避免多家「这是对方工具的问题」的扯皮。
折中常见：主线用一家全流程保证收敛与责任，在个别己方强项/痛点环节引入第二家工具做补充或对打（dual-vendor），既保留议价与备份，又不承担全流程混搭的集成风险。小团队/创业公司则更倾向跟随 foundry 参考流程（reference flow）和现成 PDK 认证组合，把工程风险压到最低。
六、决策清单（一页纸）
- 我们的设计类型、规模、目标节点、最大 run 是？该节点谁被 foundry 认证？
- 用自家 2 个真实设计、同约束同库、限同人时跑 PoC；
- 用独立黄金签核量 QoR/相关性，记 runtime/内存/ECO 轮数/工时；
- 中途加盲测设计防特调；让实际工程师评易用性与 AE；
- 按完整 feature 清单询 license（含高级特性/分布式/期限），算 3 年 TCO；
- 评估与既有流程/库/脚本/签核生态的集成与迁移成本；
- 主线全流程降风险，个别环节 dual-vendor 保议价与备份。
相关与延伸
- 运行与许可机制：G3 LSF 作业调度。
- 工具链耦合：F10 PDK/版本基线、X4 数据管理。
- 各家工具分篇：C1 DC/Genus、D1 Innovus、A1 VCS/Xcelium、B3 JasperGold/VC Formal、B5 HLS。
总结
EDA 选型没有全局最优、只有在自家设计、节点、团队和预算下的最低风险方案，因为结果强依赖库质量、foundry 认证版本和工程师经验，工具间差距往往小于高手与新手的差距；评估时实现工具自评的 QoR 不算数，必须以独立黄金签核下的相关性为准，并连同容量/runtime、收敛可预测性、易用性、生态集成、foundry 认证和完整 license 成本一起量；公平的 PoC 要用自家真实且含一个最难的设计、同一份 RTL/黄金 SDC/PDK、限定双方相同人时、统一用一套签核工具裁判并记录 ECO 轮数与工时，中途追加盲测设计防止 AE 特调；商业上分清浮动并发、Token、订阅与永久模式且把高级特性和分布式额度列入完整报价，按三年 TCO 算账；正因跨厂交接会丢私有扩展、ECO 反标与签核相关性，大厂通常主线采用一家全流程锁定收敛与单一责任，只在个别环节引入第二家对打以保留议价和备份，小团队则直接跟随 foundry 认证的参考流程把风险降到最低。