十亿级 DRC violation，被压缩成数百个 Signal。Siemens EDA 在 8 月 5 日发布的 Calibre Vision AI 官方博客用这个数字概括新一代 DRC debug 的变化。
这个数字只回答了第一层问题：工程师眼前的列表能缩短多少。判断一套 AI 分诊工具是否真有工程价值，还要再算两本账：相似 violation 是否被正确分组，以及这种分组最终有没有缩短 DRC 收敛周期。
压缩倍数、分组质量、收敛收益，三项缺一不可。压缩得多，不代表分得准；分得准，也不代表项目一定更快。Calibre Vision AI 最值得讨论的地方，是它把这三层问题放进了同一条物理验证工作流。
先分清三层对象：violation、Signal、Signature
DRC 规则引擎面对的是几何条件。线宽、间距、包围、密度、边界或复杂图形条件不满足时，Calibre nmDRC 会在具体位置、层级或实例上报告一条 violation。
大型 SoC 层级深、复用实例多。一处单元边界、路由约束或集成配置问题，可能在全芯片重复制造成千上万条 violation。因此，十亿条 violation 并不等于十亿个独立根因，更不等于十亿次独立修改。
Siemens 把结果组织成三层：violation 是规则命中的原始标记；Signal 是按空间和语义相似性聚合出的调查入口；Signature 再归纳重复出现的 Signal 行为，用来提示系统性设计或集成问题。
三层对象承担不同责任。规则引擎决定哪里命中规则，AI 帮工程师组织调查入口，工程师确认根因、选择修复并复查。Signal 可以指向潜在共同根因，却不是根因结论，也不保证对应一个 ECO 或一次修复。
一个 violation 怎样走完分诊链路
Siemens 在博客中给了两个示意场景。一个深层 SRAM macro（SRAM 宏单元）因路由约束触发 violation；另一个发生在设计早期，十亿级错误最后关联到少数几类 cell boundary（单元边界）条件。这些是厂商用来解释机制的场景，不是披露了客户、节点和周期的生产案例。
沿着这两个场景，可以把 Vision AI 的链路走一遍。
第一步，nmDRC 仍按确定性规则执行检查。OASIS 结果数据库在运行期间增量写入 Vision AI，工程师不用等完整 run 结束才看到首批结果。
第二步，instance-complete 保留全芯片层级及各 block instance 中已经报告的 violation。过去如果每条检查受报告上限约束，深层实例中的重复问题可能要到后续迭代才逐渐暴露；现在团队可以更早看到它在全芯片的分布。
第三步，相似 violation 被聚成 Signal，重复的 Signal 再形成 Signature。工程师由此判断：这是一个局部 SRAM 约束问题，还是跨多个实例反复出现的单元边界问题？如果 Signature 的假设成立，团队可以先处理少数系统性条件，再观察大量下游 marker 是否随重跑消失。
第四步，chip owner 把带有筛选条件、版图上下文和选定 Signal 的工作区交给 partition owner。相关结果还能导出为 ASCII 数据库，在 Calibre RVE 中继续查看。接手者看到的不再只有坐标和规则名，还包括前一位工程师为什么把这些结果归为一组。
第五步仍然回到传统工程责任：确认根因、修改版图或约束、评估对 LVS、时序、功耗和可靠性的连带影响，再重跑检查。只有复查通过，Signal 才有关闭依据。
这条链路解释了 Vision AI 改变了什么：它提前了结果可见时间，压缩了调查入口，并保存了交接上下文。规则判断、修复决策和 sign-off 责任没有转移给 AI。
第一本账：压缩倍数
Siemens 的公开口径是把十亿级 violation 组织成数百个 Signal。2025 年另一篇 Calibre Vision AI 博客还给出一个厂商案例：1.4GB 的 OASIS 文件包含 35 亿条错误，45 秒加载；对应 ASCII 结果被描述为 71GB、加载超过 15 分钟。
这些数字说明 OASIS、高容量加载与分组可以把原始结果转成更小的人工调查空间，但公开材料没有披露客户、工艺节点、硬件、rule deck、软件版本或第三方复现条件。
评估压缩倍数时，分母和分子必须说清楚。团队应固定输入的规则、层级和设计阶段，说明 Signal 的生成粒度，再比较更换 rule deck、完成一次 ECO 或进入更干净的 run 后，压缩比是否稳定。只展示一个最拥挤的初始 run，很难代表整个项目。
第二本账：分组质量
压缩比回答“列表短了多少”，分组质量回答“短列表还能不能相信”。
误合并会把成因不同的 violation 塞进一个 Signal，工程师可能过早接受共同根因假设；过度拆分会把同一问题切成许多组，噪声只是换了一种形式；跨 run 的 Signal 身份若频繁变化，负责人、状态和修复证据也难以延续。
公开产品材料没有提供分组精确率、召回率、误合并率或跨迭代稳定性。用户导入时需要建立自己的对照集：让熟悉设计的工程师抽样标注哪些 marker 应该同组，记录 AI 分组被拆分、合并、否决或重标的比例，并观察同一问题在相邻 run 中能否保持可追踪身份。
还要问一个更实际的问题：工程师能否接管分组？严肃的 sign-off 流程不能只给出“AI 认为相似”，还要允许用户查看依据、回到原始 marker、拆组或保留例外，并记录谁做了哪次判断。
第三本账：收敛收益
增量加载最直接改善的是首次形成可用判断的时间，也就是 time-to-first-insight。它让 DRC 检查和 debug 部分并行，使灾难性配置错误或系统性问题有机会在完整 run 结束前暴露。
这个时间不能与 nmDRC 核心检查运行时间混为一谈，更不能直接替代项目总周期。即使首个 Signal 提前出现，根因分析、版图修改、跨团队往返、重跑、问题重开和最终 closure 仍可能占据大部分时间。
因此，收敛收益至少要同时记录六项：首个可操作 Signal 出现时间、完整结果加载时间、人工分诊工时、DRC 迭代次数、Signal 重开数量，以及从首次检查到最终 closure 的总耗时。界面快、列表短，只有在这些结果指标上继续传导，才会变成项目收益。
不同角色，验收的不是同一件事
同一个 Signal 落到不同角色手里，代表的工作并不相同：有人判断分组是否可信，有人负责跨层级交接，有人验证流程稳定性，也有人核算项目收益。
一线物理验证工程师最在意分组是否准确、原始 marker 是否随时可回看、错误分组能否人工接管。他们承受的是日常审阅成本。
chip owner 和 partition owner更关心上下文能否跨层级交接：筛选条件、Signal 状态、负责人、修复提交和复查结论能否连成证据链。列表再短，如果每次下放都要重新解释，协作成本并没有真正下降。
CAD / methodology 团队要验证流程稳定性。不同 rule deck、工具版本、设计阶段和数据规模下，Signal 身份与过滤逻辑是否稳定？与 RVE、版图查看器、布局布线工具、waiver 和回归流程如何衔接？
研发管理者与采购负责人最后看项目账：人工分诊工时、迭代次数、重开率和 closure 时间有没有可重复改善，迁移、培训、运维与退出成本是多少。厂商演示里的压缩倍数，只是这张验收表的第一行。
AI 在 EDA 里更像一层结果控制面
Vision AI 展示了一条不同于 RTL 生成、脚本编写或参数搜索的 AI 路线。底层 nmDRC 继续产出确定性的规则命中；AI 把海量结果变成人能审阅的工作单元；协作功能再把工作单元送给对应角色，并保留处理上下文。
它更像结果控制面：不替代规则引擎，却决定信息怎样被聚合、导航、交接和追踪。这条路线降低了模型直接进入签核决策的风险，也提出了新的治理要求。分组一旦成为多人协作的共同语义单位，其命名、边界、状态和关闭条件就必须可解释、可修改、可回溯。
同样的门槛也适用于企业内部的 AI+EDA 落地。IC 智能知识库可以承接规则解释和历史处置，Flow Builder 串起任务、权限与人工 review；模型输出只有回到可追溯的研发流程，才不会在下一轮迭代里失去依据。
公开证据支持到哪一步
现有公开资料可以支持三项判断：Calibre Vision AI 能接入增量 OASIS 结果；Siemens 公开描述了 instance-complete、Signal / Signature 分组、全局筛选和工作区交接；厂商称十亿级 violation 可以压成数百个 Signal。
公开资料还不能证明另外三件事：分组在不同客户和设计上的普遍准确性，项目周期的可重复缩短比例，以及具体客户、节点或量产项目中的生产收益。产品机制已经成形，普遍收益仍需更多客户许可数据或第三方复现。
采购与试点不应只问“能压成多少组”，还要追问：分组错了多少、工程师改了多少、跨 run 保留了多少、最终少跑了几轮、总周期缩短了多少。只有三本账能同时对上，数百个 Signal 才真正从产品演示变成可验收的工程能力。
Calibre Vision AI 把物理验证中的一个隐性瓶颈摆到了台前：先进节点不只制造更多 violation，也制造更高的注意力、交接和判断成本。
十亿级 violation 压成数百个 Signal，是一次很有价值的认知压缩。它还不是最终答案。压缩倍数衡量工具能否缩小问题空间，分组质量决定工程师是否敢用，收敛收益才决定项目是否值得为它改变流程。
下一次再看到“海量结果被 AI 压成少数问题”的产品故事，可以直接拿这三本账去核对。它们比一个漂亮的压缩数字更接近真实工程价值。
作者：麒芯
声明：本文基于公开信息整理分析，涉及的产品能力与案例数据以 Siemens 官方材料为准，不构成采购或投资建议。
参考资料：
1. Siemens Calibre Blog：《DRC at scale: How Calibre Vision AI turns billions of errors into actionable insights》
2. Siemens Calibre Blog：《Calibre Vision AI: a new era of fast, scalable chip-level DRC debug》
热门跟贴