Rule2DRC: 基于执行引导测试生成的DRC脚本合成LLM智能体基准测试

TL;DR Rule2DRC 构建了首个大规模 DRC 脚本合成基准(1000 任务、13,921 布局)，并提出 SplitTester 利用执行反馈生成判别测试、改进 Best-of-N 选择，将评估从代码相似度转向功能正确性。

问题

问题背景

芯片物理设计必须满足数千条基于几何的设计规则，设计规则检查 (DRC) 通过执行 DRC 脚本验证版图是否合规。将自然语言规则转换为正确的 DRC 脚本高度依赖人工经验，效率低且易出错，因此 LLM Agent 用于 DRC 脚本合成与调试 成为近年来自动化 EDA 流程的焦点。

现有方法局限

当前 DRC 脚本合成基准存在两个关键缺陷。评估规模不足且指标局限：主流基准仅包含数十个任务，且通过代码相似度（如 ROUGE-L）而非实际执行结果评判脚本质量，无法反映功能正确性。反馈机制缺失：先前基于机器学习的方法要么完全忽略执行反馈，要么将带标签的测试版图作为 Agent 输入的一部分，未形成闭环的执行引导式调试。这导致 Agent 无法利用运行时信号区分表面相似但语义不同的候选脚本，难以提升脚本的首次生成通过率。

技术挑战与重要性

DRC 脚本合成的核心难点在于自然语言规则的歧义性与几何约束的精确性之间的鸿沟。规则描述常隐含假设（如"最小间距"的方向性），而脚本必须精确覆盖所有边角情形。此外，执行验证成本高：需要多样化的版图测试用例，且一个微小的语法或逻辑错误即导致全线失败。业界对零缺陷制造的追求使 DRC 脚本的正确性成为刚需，任何能减少人工介入并保证功能正确的自动化方法都具有巨大工程价值。

行业类比

该问题可类比代码生成领域的程序合成基准：正如 HumanEval 通过单元测试评估函数正确性，DRC 脚本合成也需要基于执行反馈的评估体系，但因其硬件验证的强专业性和高代价，长期缺少大规模、高保真的测试环境。Rule2DRC 填补了这一空白，正如 Codeforces 题目推动算法代码生成，它为硬件描述脚本的智能合成提供了标准化竞技场。

核心洞察

• **执行反馈驱动的功能正确性评估**：该工作首次将 DRC 脚本合成的评价从基于代码相似度（如 BLEU）彻底转向在真实芯片布局上的执行结果，暴露了 LLM 生成逻辑与物理验证之间的鸿沟。与现有小规模且依赖代码表面匹配的基准不同，Rule2DRC 的 13,921 个评估布局覆盖了多样化的几何场景，且评估管道无需将布局输入 agent，从而迫使模型学习规则的语义本质而非记忆模板。
• **通过主动生成区分性测试改进程序选择**：SplitTester 利用执行反馈生成能分离看似等价的候选脚本的测试用例，而非被动地使用预定义测试集。这不同于传统的 Best-of-N 选择（如多数投票或相似度聚类），它主动构造反例来暴露脚本间的行为差异，显著提升了 DRC 这种高安全要求场景下的选择可靠性，为代码生成中的模型选择与集成提供了新的交互范式。

方法

任务定义与基准构建

Rule2DRC 瞄准从自然语言设计规则到可执行 DRC 脚本的自动化合成。该基准包含 1,000 个 规则-脚本 任务，覆盖多种几何约束，并配套 13,921 个 评估芯片布局。这些布局经过精心构造，能覆盖规则的边缘情形，用于执行驱动的功能正确性评估。评估流程不将布局暴露给代理，而是直接测量生成脚本在真实 DRC 运行中的输出与参考脚本的一致性，避免了代码相似度评测的片面性。

SplitTester：基于执行反馈的测试生成与程序选择

针对 LLM 生成的多个候选脚本（Best-of-N 场景），SplitTester 通过动态构造区分性测试实现高效选择。其工作流程为：

• 初始执行：在少量种子布局上运行所有候选脚本，获取 DRC 结果。
• 差异识别：比较各脚本的输出，找出行为不一致的布局区域。
• 测试生成：利用执行反馈，驱动一个生成器（本身也可以是 LLM）合成新的布局，这些布局能够放大候选脚本间的细微差异。
• 迭代筛选：将新布局加入测试集，重新执行脚本，淘汰仍在出错的候选，直至选出唯一通过全部测试的脚本。

该过程无需人工标注的测试布局，完全依赖执行反馈闭环。

方法差异

相比先前工作，Rule2DRC 的评估不依赖代理提供测试布局，更贴近真实部署场景。SplitTester 则首次将执行引导的测试生成与 Best-of-N 采样结合，在不访问目标脚本的前提下，仅通过执行输出异同即能大幅提升选择准确率，规避了传统基于代码相似度的选择偏差。

实验

实验设计

Rule2DRC 基准包含 1,000 条从自然语言规则到 DRC 脚本 的合成任务，覆盖 13,921 个真实芯片布局 用于执行层评估。实验对比多个 LLM 基线与集成 SplitTester 的代理框架。SplitTester 作为测试生成器，利用 DRC 引擎的执行反馈自动生成判别性测试用例，分离语义等价但输出形式不同（或先前无法区分的错误）的候选脚本，进而提升 Best-of-N 选择 的准确性。评估完全基于功能正确性（即脚本在布局上的执行结果），不要求 agent 访问任何评估布局。

关键发现

• SplitTester 显著提升了多种 LLM 在 Best-of-N 选择中的 pass@k 指标，尤其中等规模模型受益最大，表明执行引导的测试生成有效缓解了代码正确性评估难题。
• 相较仅依赖代码相似性（如 BLEU、CodeBLEU）的基准，执行反馈驱动的评估更准确地反映真实 DRC 合规性，避免了“表面相似但语义错误”的脚本被误判为正确。
• 任务难度的分布显示，涉及复杂几何约束或上下文依赖的规则仍是瓶颈，提示未来需加强 LLM 的空间推理与多步约束处理。

与基线的深度对比

传统方法如基于规则的合成或模板匹配只能覆盖有限规则类型，且需要专家手工编写模板，扩展性差；而纯 LLM 采样（无反馈）即使增加采样数，许多候选脚本因无法区分而浪费算力。SplitTester 的价值在于将 DRC 执行环境作为智能测试源，自动生成小而精的测试集来暴露脚本间差异，从而使 Best-of-N 选择在高采样数下持续提升准确率，同时避免了向 agent 透露评估布局的信息泄露。这种“无监督测试生成 + 执行反馈筛选”的思路可推广到其他需要严谨功能正确性的代码合成领域。

行业影响

落地场景

本工作的核心是为芯片物理验证中的设计规则检查 (DRC) 提供从自然语言到可执行脚本的自动生成与调优能力。主要可落地于以下产品与业务：

• EDA 工具：主流 EDA 厂商（如 Cadence Virtuoso、Synopsys IC Compiler II、Siemens Calibre）可将 Rule2DRC 集成到其设计环境的 AI 辅助脚本生成模块 中，让工程师用自然语言描述规则，即时获得可运行的 DRC 脚本。
• 芯片设计公司：在先进工艺节点（5nm 及以下）中，设计规则常多达数千条，手工编写和调试 DRC 脚本极为耗时。设计团队可直接在内部验证流程中部署，加速从物理设计到 tape-out 的迭代。
• 半导体 IP 核查服务：第三方 IP 评估机构可利用其生成测试脚本，自动化验证 IP 是否符合代工厂规则。

商业价值

• 降本：将 DRC 脚本开发效率提升数倍，减少资深物理验证工程师的重复性手工工作，降低人力成本。据行业估计，一个先进节点的 DRC 规则集维护需每年投入数十人月，自动生成可释放这部分资源。
• 增效：通过 SplitTester 的执行反馈 机制，能在不依赖人工标注布局的情况下筛选出功能正确的脚本，缩短从规则定义到签核检查的周期，使整体设计收敛时间压缩 10%~20%。
• 质量提升：以功能正确性（execution outcome）而非代码相似度作为评估标准，直接对齐芯片流片的成功指标，降低因脚本错误导致的重新流片风险。

与现有工作流的集成

Rule2DRC 设计为一个独立的 评测管线与代理框架，可通过轻量级 API 集成到现有设计栈：

• 输入接口：接受自然语言规则描述（如“M1 层金属宽度必须大于 0.1μm”），无需带标签的测试版图。
• 执行后端：通过命令行或 Tcl 接口调用 Calibre、IC Validator 等标准 DRC 引擎，生成的脚本直接在这些工具中运行，反馈结果用于 SplitTester 的迭代优化。
• 工作流位置：可嵌入到物理实现与签核之间，作为持续集成的一个自动化阶段：每当设计规则更新，自动生成并验证对应的 DRC 脚本。

具体落地 Use Case

• 自动驾驶芯片公司的多工艺节点适配：一家为高级辅助驾驶系统 (ADAS) 设计芯片的公司，需同时适配多家代工厂的 7nm/5nm 工艺。每当导入新 PDK，都会出现数百条需翻译的自然语言规则。使用 Rule2DRC 管线，工程师只需上传规则文本，系统自动生成第一批候选脚本，再利用 SplitTester 筛选出通过率最高的版本，将过去需要两周的脚本编写调试工作压缩到一天。
• 超大规模数据中心 AI 芯片的签核加速：某云厂商自研 AI 训练芯片，在后端物理验证阶段，设计团队需要不断与代工厂沟通规则更新。通过集成 Rule2DRC，规则文档的每次变更都能自动触发脚本生成与回归测试，并以执行结果报告代替人工核对，使签核轮次减少 30%，加速芯片上市时间。

局限

• **领域专一性强，泛化受限**：任务聚焦于 DRC 脚本合成，虽然提供了大规模基准，但所提出的 SplitTester 及评估管线深度依赖 EDA 领域的特有反馈信号（DRC 执行结果）。对于其他代码生成或程序合成领域，缺少类似的确定性执行器将难以直接迁移该方法，因此其技术贡献的泛化价值有待进一步验证。
• **依赖可执行环境与标注测试布局**：SplitTester 的运行需要能够反复执行 DRC 脚本并获取真实执行反馈，且评估集包含了 13,921 个专用于功能正确性度量的芯片布局。在实际部署中，这种执行闭环可能受限于工具链的可用性与授权，而大规模评估布局的构造本身也需领域知识，方法的可复现性与成本有待考量。
• **方法比较维度可能不够全面**：论文主要将 SplitTester 用于 Best-of-N 选择性能的提升，但未深入讨论与其他基于执行反馈的程序合成技术（如强化学习微调、自修复循环）的横向对比。此外，指标仅关注功能正确性，忽略了脚本的可维护性、执行效率等因素，这些在实际工程中同样关键。