008 · 过了编译，为何长 RTL 仍几乎全错？

核心问题：当 RTL 从短小独立模块扩展到长代码和多模块层级时，编译通过还能在多大程度上说明模型真正保持了设计行为？

论文卡片

• 原题： ChipVerilog: A Large-Scale OpenCores-Derived Benchmark for LLM-Based Verilog RTL Generation
• 作者： Yan Tan、Jiping Du、Xiangchen Meng、Yangdi Lyu。
• 机构： 香港科技大学（广州）Microelectronics Thrust。
• 版本： 2026-07-12 首次提交；2026-08-17 更新至 arXiv v3；分类为 cs.AR、cs.PL。
• 定位： 面向大规模、层级化 Verilog RTL 生成的实证基准论文。
• 阅读入口： alphaXiv · arXiv · 免费全文 · PDF

论文讲了什么

许多既有 Verilog 生成基准以不足百行、无需依赖其他模块的任务为主。ChipVerilog 质疑的是：这类成绩能否代表模型处理真实 IP 层级的能力。作者从 OpenCores 选取双精度 FPU、OR1200、MIPS-16、I2C 和 CORDIC 五组设计，构造了 64 个生成目标，共约 20,400 行参考 RTL；中位文件长度约 268 行，其中 7 个目标超过 500 行，3 个超过 1,000 行。

任务分为独立模块、多模块目标和完整系统。每个 prompt 不只是简短功能描述，而是作者结合官方规格文档与参考 RTL 整理出的详细自然语言规格，包含端口、位宽、时钟与复位、数据流、控制流、状态转换、时序以及子模块交互，并经过人工复核。模型只接收该规格来生成目标 RTL。

验证分两层。所有输出先经 Icarus Verilog 做语法、编译和 elaboration 检查；独立模块和局部多模块目标再由 Yosys 与参考 RTL 做等价检查，其中只替换待测模块，其余子模块保留参考实现。五个完整系统目标因状态空间过大，改用已有 testbench 仿真。指标采用 VerilogEval 的 pass@k：每项生成 5 个样本，估计随机选取 k 个样本时至少一个通过的概率。

主要结果

论文比较 Claude Opus 4.5、GPT-5.4 与 DeepSeek V4 Pro。GPT-5.4 的语法 pass@1 最高，为 83.13%，功能 pass@1 却只有 23.13%；Claude 对应为 78.75% / 17.50%，DeepSeek 为 45.94% / 13.44%。增加到五次采样后，Claude 和 GPT-5.4 的语法 pass@5 都超过 93%，功能 pass@5 仍只有 35.94% 和 37.50%。更多采样明显更容易救回语法失败，却没有同等程度地救回行为错误。

按参考 RTL 长度分组后，功能 pass@1 从少于 100 行的 58.0%，降至 100–300 行的 17.7%、300–500 行的 3.2%，超过 500 行则为 0%；语法 pass@1 在各长度组仍处于 61.6%–80.7%。按层级分组时，37 个无子模块目标和 10 个单子模块目标的功能 pass@5 分别为 44.14% 与 46.67%，17 个涉及至少两个子模块的目标则为 0%，尽管后一组语法 pass@5 仍有 74.51%。

这些结果支持论文的中心观察：模型已经能频繁产出“像 RTL、能编译”的长代码，但保持控制行为、时序关系、接口约束与跨模块协同仍远未可靠。这里更准确的说法是 ChipVerilog 暴露了规模和层级丰富任务上的失败，而不是仅凭分组结果就证明某一个因素单独造成了失败。

证据边界

第一，长度、层级和设计类型并未被实验独立控制。最长目标往往也更复杂、更层级化；64 个任务又高度集中于 OR1200（38 个）。因此“超过 500 行为 0%”和“两个以上子模块为 0%”是强烈关联证据，但不能分辨失败究竟来自 token 长度、规格密度、控制复杂度、领域差异还是模块交互。

第二，功能通过并非统一强度的判据。59 个局部目标使用等价检查，五个完整系统使用有限 testbench 仿真；后者通过只能说明覆盖到的行为成立。论文的整体 pass@k 把这两类结果放在同一列中，适合描述其分层验证流程，却不应被理解为所有任务都获得了相同程度的正确性保证。

第三，prompt 由官方文档和参考 RTL 共同整理，并以参考实现校正歧义。它测量的是从一份实现感知、信息较完整的描述重建既定行为，而不是从原始、可能矛盾或遗漏的需求中完成设计。另一方面，OpenCores RTL 是公开代码，论文没有报告训练集污染审计；模型可能见过相关实现的可能性没有被排除。这两点都影响“接近真实设计”的概念边界。

最后，论文与既有基准的比较主要是任务规模、层级和验证方式的结构性对照，没有让相同模型在各基准的统一协议下做数值基线实验。因此它能证明这些模型在 ChipVerilog 上表现如何，不能单凭表格给出跨基准难度的精确倍数。

重点读哪里

先读 §3.3，理解规格怎样从文档与参考 RTL 中生成；再读 §3.4 与 §4.1，看三类任务为何采用不同验证 oracle；最后读 §4.2–§4.4，把整体 pass@k、代码长度和模块层级三组结果放在一起比较。附录 A 值得用来判断 prompt 到底包含了多少实现信息。

思考启发

以下是导读者由论文引出的理解角度，不是作者额外验证过的结论。

ChipVerilog 把“会写 Verilog”拆成了两个很不对称的能力：生成满足语言与接口约束的外形，以及保持跨周期、跨状态、跨模块的行为。前者可以随着采样迅速接近饱和，后者却没有同步改善。因而编译器反馈是一道必要的过滤器，却不是功能能力的连续代理指标；当语法通过率已经很高时，它对模型之间语义差距的分辨力反而会下降。

论文也提示，所谓“更真实的基准”并不是单一尺度。代码更长、层级更多确实增加结构现实性，但规格是否来自实现、验证是否穷尽、公开代码是否可能进入训练集，同样决定结果能回答什么。真实性不是一个标签，而是一组彼此可能冲突的选择。

三个思考问题

1. 0% 结果究竟归因于什么？

超过 500 行与至少两个子模块的任务功能通过率都降为零，这足以说明长度或层级是主要原因吗？

2. 从参考 RTL 整理出的规格在测什么能力？

若 prompt 的细节由参考实现补全并人工消歧，这更接近规格到实现，还是对既有实现的语义重建？

3. 不同验证 oracle 的通过能否汇总成同一个 pass@k？

形式等价与有限仿真都记为“功能通过”时，整体分数保留了什么信息，又掩盖了什么差异？