Rule2DRC：面向 DRC 脚本合成的 LLM 智能体基准与执行引导的测试生成 Rule2DRC: Benchmarking LLM Agents for DRC Script Synthesis with Execution-Guided Test Generation
构建执行式 DRC 脚本合成基准 Rule2DRC 与测试生成选择智能体 SplitTester。
前置知识
DRC（设计规则检查）
DRC 即设计规则检查，是芯片流片前用专用引擎（如 KLayout）在候选版图上执行一段 DSL 脚本、报告是否违反工艺几何约束的过程，脚本对某版图输出 1 表示违规、0 表示合规。
理解 DRC 才能明白脚本“正确”指的是执行结果与真值一致，而非代码长得像。
KLayout DRC DSL 与 GDSII
KLayout 是开源版图查看与检查工具，其内置领域专用语言用 separation、sized、interacting 等几何算子描述规则；GDSII 是描述版图层与多边形的工业二进制格式。
脚本、版图与评测引擎全部基于 KLayout 与 GDSII，读懂这一层才能看懂任务的输入输出。
Best-of-N 选择与 tester agent
Best-of-N 指采样 N 个候选代码再用选择器挑最优；tester agent 在普通选择器之上额外生成测试用例、用执行反馈给候选打分，是测试时扩展的常见范式。
SplitTester 本质就是一个 tester agent，理解该范式才能定位它相对 CodeMonkey、S* 的创新。
执行式评测 vs 代码相似度
执行式评测把生成脚本真跑在版图上比对违规输出判断对错；代码相似度只比较与参考脚本字面或 AST 相似度。同一条规则可用多种语法等价实现，后者会误判正确脚本。
这是本文基准区别于旧基准的核心动机，也是图 3 要说明的关键点。
pass@N / Oracle@N
pass@N 是 N 个采样中至少存在一个正确解的任务比例，是 Best-of-N 选择性能上界；本文用无偏估计量计算并记为 Oracle@N，用来衡量选择器离理论上界还有多远。
表 2 用 Oracle@N 作为选择器上界，SplitTester 的价值正在于逼近它。
研究动机
在芯片制造前，晶圆厂会发布成百上千条用自然语言描述的几何设计规则（如“pad 必须位于 M4 内且被 M4 包围至少 0.850 µm”），工程师需把它们逐条翻译成可在 DRC 引擎上执行的领域专用语言脚本并反复验证，这套工作极其依赖专家经验且每代工艺都要重做；7nm 及以下节点规则数量与复杂度激增，进一步拉长工艺迁移的周转时间。已有机器学习方法各有短板：BERT 词级分类、LLM 智能体加 RAG 这类一次性翻译几乎不用执行反馈，留下宝贵信号；DRC-Coder 虽引入执行反馈，却要求评测版图及其真值违规标注作为输入，这在现实中要先有可信参考脚本或人工标注，既不现实又会过拟合到固定版图集。更基础的问题是评测：现有基准多在 200 条以下，且用代码相似度打分，而同一条规则可用 separation、sized、sep 别名等多种语法等价实现（见图 3），字面相似会误判正确脚本，又因涉密往往不公开，难以支撑公平研究。
本文的目标是本文要同时补齐数据与方法两块短板。数据上，构建一个公开、规模量级更大、且以执行结果为打分依据的基准：覆盖 1000 个自然语言规则到 DRC 脚本的翻译任务和 13921 个评测版图，规模比已有基准高一个数量级，并把评测版图作为内部私有信号而非喂给智能体的输入。方法上，提出一个选择阶段的 tester agent，在 Best-of-N 框架下用 DRC 引擎的执行反馈自动生成判别性测试版图，把原本不可区分的候选脚本逐步分离开，从而更可靠地挑出与自然语言规则一致的脚本。目标是用可量化的成功率与错误率，证明该 agent 能逼近 Oracle@N 上界、并优于 CodeMonkey、S* 等近期方法。
与已有工作不同的是，独特切入角度在于“主动制造差异”。CodeMonkey 与 S* 虽也生成额外测试，但 CodeMonkey 先把候选裁到 top-3 再决定要不要改测试，容易在候选尚未被区分前就丢掉正解；S* 则只对已经被测试区分开的簇做采样，对“当前测试下行为完全相同”的高质量大簇束手无策，而这些大簇恰恰最可能藏着正解。本文抓住这一被忽视的点：把测试生成火力集中到分数高、规模大的不可区分簇上，用簇内代表样本提示模型造出新版图来劈开它，并持续重聚类，从而避免过早剪枝、把额外算力真正换成选择准确率。
核心方法
直觉上，SplitTester 像一个会“反诘”的考官：它先把若干候选脚本在同一批版图上跑一遍，按输出模式把它们分进若干“同温层”簇——同一簇里的脚本在现有测试下表现一模一样、分不出高下；接着它专门挑那个分数又高、人又多的簇，针对性出几道能把簇内脚本区分开的新题，再重新分簇，如此循环直到题量预算耗尽；最后请一位评委综合所有“能区分 top-3”的题目来定夺。技术路线是三段式：初始测试生成与聚类、迭代分裂目标簇、终审判断。整个流程只用同一个底层 LLM，靠切换提示词分别扮演测试生成器与评委，初始化都用 8 个测试、最多再加 8 个，并在连续 $P=1$ 次分裂失败后提前停止。
核心创新是把“测试生成”的优化目标从“区分已被区分的簇”改成“分裂尚未被区分的大簇”。形式上，SplitTester 每轮选使 $s_i |C_i|$ 最大的簇 $C_i$ 作为分裂目标——$s_i$ 是该簇在当前测试上的得分、$|C_i|$ 是其规模——理由是大而高分的簇最可能同时含正解与错解，对它们区分的边际收益最高。为避免把整个大簇塞进提示反而干扰生成器，它从目标簇均匀采样 $K=3$ 个代表，让模型据此生成新测试，若新测试能把簇一分为二则失败计数清零、否则累加，到连续 $P$ 次失败即早停。终审阶段取 top-3 候选，仅把“它们之间输出不同”的那些测试交给评委 LLM 选最优，这样既利用了生成标签的打分信号又用评委纠正噪声标签。这套“主动分裂大簇 + 全程保留候选池 + 终审纠偏”的组合，是与 CodeMonkey（早裁 top-3）和 S*（只挑已区分簇）最本质的区别。
方法步骤详情
步骤对应 Algorithm 1 三段。第一段初始化：用提示 $p_{test}$ 让 LLM 生成 $B_0$ 个测试 $(x^{(m)}, \phi^{(m)})$，$x^{(m)}$ 是版图、$\phi^{(m)}$ 是期望标签；对每个候选 $c$ 跑引擎，按 $s(c)=\frac{1}{|T|}\sum 1\{\phi(x,c)=\phi^{(m)}\}$ 打分，再按输出向量相同聚成簇 $\{C_i\}$。第二段迭代分裂：在 $|T|1$ 时循环——选 $i^*=\arg\max_i s_i|C_i|$，采 $K=3$ 代表生成新测试 $(\hat x,\hat\phi)$，能分裂目标簇则 $q\leftarrow 0$ 否则 $q\leftarrow q+1$，并入 $T$ 重算 $s(c)$ 并重聚类。第三段终审：取 top-3 候选，收集它们输出不一致的测试 $X_\Delta=\{x:\exists c_a,c_b\in C_3,\phi(x,c_a)\ne\phi(x,c_b)\}$，交评委选 $c^*$。
技术新颖性
新颖性有三层。一是问题与数据：把 DRC 脚本合成从“一次性翻译 + 代码相似评测”重定义为“执行式评测下的选择问题”，并放出比 DRC-SG（200 条）、AST-Guided SVRF（74 条）、DRC-Coder（7 条）大一个数量级且完全开源的 1000 任务基准。二是选择机制：首次显式把测试生成目标对准“当前测试下不可区分的大簇”并用 $s_i|C_i|$ 加权选目标，配合代表采样与早停，规避了 CodeMonkey 早裁与 S* 只顾已区分簇的盲点。三是工程闭环：用同一 LLM 兼任测试生成器与终审评委，并用消融证明生成标签打分与终审判断互补、二者缺一不可。
实验结果
核心发现分四组。上下文工程（图 5）：在 GPT-OSS-120B 上把约 60K token 的 KLayout API 文档塞进上下文，pass@1 提升逾 20 个百分点、pass@20 提升逾 40 个百分点，后续实验因此默认带文档。主对比（表 2，BoN-20、GPT-OSS-20B）：SplitTester 成功率 44.4%、错误率 12.6%，优于 CodeMonkey 41.1%/14.1%、S* 38.2%/14.9% 与 Generated Tests 38.7%；GPT-OSS-120B 达 63.8%/4.1%，逼近 Oracle@20 的 72.1%/3.7% 上界。Pareto（图 6）：以 2×H100 + Xeon Gold 5218R 实测运行时间，SplitTester 在三模型上均位于 Pareto 前沿，同成本下成功率最高。消融（表 3，120B、BoN-10）：完整版 58.0%，去终审降到 55.5%、去标签降到 57.1%、只用初始 top-3 降到 57.4%，证明打分与终审互补、过早裁剪会丢正解。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Rule2DRC 脚本合成（BoN-20，GPT-OSS-20B） | 成功率 | SplitTester 44.4% | CodeMonkey 41.1%；S* 38.2%；Generated Tests 38.7% | 较最强基线 CodeMonkey +3.3 个百分点 |
| Rule2DRC 脚本合成（BoN-20，GPT-OSS-20B） | 错误率 | SplitTester 12.6% | CodeMonkey 14.1%；S* 14.9% | 较 CodeMonkey 降低 1.5 个百分点 |
| Rule2DRC 脚本合成（BoN-20，GPT-OSS-120B） | 成功率 | SplitTester 63.8%（Oracle@20 上界 72.1%） | CodeMonkey 62.7% | +1.1 个百分点，距上界仍有约 8 个百分点空间 |
| 上下文工程（GPT-OSS-120B，pass@N） | 成功率 | 带约 60K token KLayout API 文档 | 不带 API 文档 | pass@1 提升逾 20 个百分点、pass@20 提升逾 40 个百分点 |
局限与改进
作者在 Impact Statement 中承认让 LLM 与可执行环境交互有副作用风险，过度依赖自动生成可能在脚本不准、漏规则或错实现约束时带来隐患。结合实验我自己观察到几点：第一绝对成功率仍不算高——最强的 GPT-OSS-120B 也只到 63.8%，离 Oracle@20 的 72.1% 还有 8 个百分点，说明选择器远未榨干候选池；第二规则来源偏窄，310 条来自开源 SkyWater130，而先进节点的 690 条规则靠 GPT-5.2-high 草拟后人工修订，与真实 7nm/5nm 商用 PDK 的规则密度与复杂度可能有差距；第三 60K token 文档是性能的关键杠杆，一旦换到不熟悉的 DRC 引擎或文档不全，增益可能不复存在；第四成功定义是“在评测版图上与真值输出完全一致”，若评测版图对某些边界条件覆盖不足，通过率可能虚高。
独立分析的弱点
第一选择目标用乘积 $s_i|C_i|$ 偏粗：当多数簇分数接近时，它过度奖励大簇，可能反复去分一个其实全对的簇而浪费预算，可改用簇内候选“两两不一致”的概率估计或信息增益来更精准选目标。第二测试生成依赖同一 LLM 既出题又当评委，存在系统性同源偏差，模型若对某类几何边界理解错误，会同时造错题与给错判，建议引入差异化模型或对版图执行结果做几何校验作为客观锚点。第三代表采样是均匀随机，对长尾正确解不友好，可结合语义嵌入做分层采样。第四任务规模虽大但仍集中在几何规则，未覆盖电气规则、与原理图一致性检查等更宽 DRC deck，推广性待验证。第五成本不低，BoN-20 要对每个任务跑 20 个脚本加多轮测试，工业 7nm deck 规则动辄数千条，端到端开销需进一步优化。
未来方向
作者明确希望降低人工 DRC 编写与验证成本、缩短工艺迁移周转、降低 EDA 执行式 agent 的研究门槛。基于成果可延伸：把 SplitTester 的“主动分裂大簇”思想从纯选择扩展到迭代改写，把每次分裂得到的反例喂回生成器做自调试，形成生成-测试-改写闭环；将基准扩展到更激进的合成节点规则、电气 DRC 与 LVS 一致性检查；研究把选择器与轻量可微生成器联合训练，让测试用例与脚本共同进化；探索跨引擎迁移，把 KLayout 文档换成 SVRF/Calibre 以验证 60K token 文档杠杆的泛化性。
复现评估
复现条件较好。代码与基准已在 github.com/snu-mllab/Rule2DRC 开源，使用开源 KLayout 引擎与 GDSII 格式，无商业闭源依赖；评测指标（成功率、错误率）定义清晰，Oracle@N 用无偏估计量；实验用 Qwen3-30B-A3B、GPT-OSS-20B/120B 均为可获取的权重或 API，附 Section A 实现细节与 Section B 成本/早停/预算等附加实验。主要门槛在算力：BoN-20 端到端评测要 2×H100 跑 LLM 加 CPU 跑 DRC，1000 任务并行也要数小时；合成 690 条规则的种子依赖 GPT-5.2-high API，外部研究者需自行承担调用成本。整体对有 GPU 集群的中等以上团队可复现，对个人研究者偏重。
论文图表
左侧给出一条 NL 规则与真值脚本（用 separation 语法），右侧给出三种等价写法：(a) 用 sized 放大 hv_ndiff 层、(b) 把放大逻辑用到 N-well 层、(c) 用 sep 别名代替 separation。
它直观说明为什么代码相似度评测不可靠——同一规则有多种语法等价实现，从而论证本文必须改用执行式评测，是动机章节的核心证据。