体系结构论文（九十四）：LOCALV: Exploiting Information Locality for IP-Level Verilog Generation

LOCALV: Exploiting Information Locality for IP-Level Verilog Generation一、这篇论文到底在解决什么问题这篇论文盯上的不是“小模块 RTL 生成”这种相对轻量的问题而是更接近真实工业设计环境的 IP-level Verilog generation。这里先把问题翻译成人话以前很多 RTL 生成论文做的任务往往像“根据一句需求写个小状态机”或者“根据一个简短描述写一个小模块”。这类任务当然有意义但它和真正的工程设计之间还有一大截距离。现实中的 IP 级设计通常有1. 很长的规格文档2. 很多 I/O 信号3. 多个子模块和层次结构4. 很长的 Verilog 代码5. 非常繁琐的调试和验证过程所以作者真正想问的是当任务从“短文档 - 短代码”升级成“长文档 - 长代码”时现有 LLM 和 agent 框架为什么会崩有没有一种更适合 IP 级硬件设计的生成方法作者给出的答案是 LocalV。它的核心判断是IP 级硬件文档其实存在很强的信息局部性。也就是说某一段 RTL 代码真正依赖的通常只是规格文档里的某一个局部片段而不是整份文档的全部内容。基于这个观察作者把原本的“长文档到长代码”问题拆成很多“短文档到短代码”的子问题。这就是整篇论文最核心的思想。二、背景为什么现有 RTL 生成方法到了 IP 级就明显不够用如果你之前看过 VerilogEval 这类 benchmark会发现很多论文在小任务上已经能做出不错结果。但 LocalV 一上来就指出一个很重要的现实学术 benchmark 和真实 IP 设计之间差得很远。论文里给了一个非常直接的对比1. VerilogEval 这类基准里的文档平均长度大约 5.72. REALBENCH 这种 IP 级 benchmark 的文档平均长度是 197.33. VerilogEval 的代码长度平均大约 15.84. REALBENCH 的代码长度平均大约 241.2这四个数字很重要因为它们揭示了问题不只是“难一点”而是任务分布已经变了。作者归纳了三个核心挑战1. 长文档处理问题规格太长时关键信号约束会淹没在一堆局部说明和子模块细节里。2. 长代码生成问题代码一长LLM 的语法错误、接口错误、非综合结构错误都会明显上升。3. 复杂调试问题真实硬件设计不是写完就结束而是要过 testbench、看波形、定位信号、回溯文档、反复改。也就是说这篇论文并不认为“代码生成”本身就是全部问题。它把“调试如何依赖文档”和“长输出为何失稳”也一起算进来了。一 Introduction论文开头先回顾了一条常见发展线1. 最初大家只是拿通用 LLM 测试 RTL 生成能力2. 后来有人做 fine-tuning、做 RTL 领域数据增强3. 再往后就是多智能体方法试图模仿人类工程师的设计、验证、调试流程作者点名提到了 VerilogCoder、MAGE、ChatCPU、Spec2RTL-Agent 这些工作意思很明确不是说以前的方法完全没用而是它们大多还停留在“任务规模可控”的条件下。一旦放到 REALBENCH 这种真实 IP 级任务上性能会明显掉下去甚至连 syntactic correctness 都守不住。这时作者给出了第一组很重要的证据也就是 Figure 1。Figure 1 分成两部分。1. Figure 1(a)Passk 随 I/O signal 数量变化2. Figure 1(b)Passk 随代码行数变化图里的主角是 Claude 3.7 Sonnet 在 REALBENCH 上的表现。作者同时画了 syntax1、func1、syntax5、func5、syntax10、func10。这张图要表达的核心不是“Claude 不够强”而是随着接口复杂度和代码长度变大不管你是单次采样还是多次采样语法正确率和功能正确率都会持续下降。尤其是 Figure 1(b)当代码超过 750 行以后就算采样 10 次也经常连语法正确的结果都拿不到。这说明问题并不只是“多采样几次就能解决”。模型在长代码生成上存在一个更基础的稳定性问题。对于做调研的人来说这张图的价值在于它把“IP 级 RTL 生成难”从一种模糊印象变成了一个可观测的经验事实。二、核心洞见Information Locality论文最有意思、也最像“真正新 insight”的地方在 3.2 节。作者提出信息局部性假设对于任意一段语义完整的 RTL 代码单元 c_j它所需要的信息主要集中在规格文档 D 的某个子集里而不是均匀分布在整篇文档中。换句话说一个代码片段通常不需要“看完整本说明书”它只需要“看对那几页”。这个假设为什么在硬件里容易成立因为 IP 级硬件设计本身就是模块化的。文档的组织结构也通常是模块化的1. 某一节讲接口2. 某一节讲某个子模块3. 某一节讲状态转换4. 某一节讲实现细节所以代码结构和文档结构之间往往有天然对齐关系。作者这里其实是在说硬件设计不像很多开放式软件任务那样信息耦合得非常散它在很多情况下是“可以按局部切开来做”的。这就是 LocalV 之所以成立的前提。光说“有局部性”还不够作者接着用 Figure 3 来量化这个假设。它做的事情是1. 把规格文档切成 paragraph2. 把 Verilog 切成 code units3. 计算每个 code unit 和所有 paragraph 的语义相似度4. 把这些相似度做 softmax变成一个“这个代码单元的信息来源分布”5. 再用熵来衡量这个分布是否集中如果某个代码单元真的只依赖少数文档片段那它对应的信息分布熵就应该比较低如果它需要东拼西凑整个文档的信息熵就会更高。Figure 3 给了三种情形1. 10 个随机 VerilogEval 模块拼起来作为理想局部性下界2. REALBENCH 里的 e203 CPU Top 模块3. 一个软件任务 Parse Lisp Expression这个对比非常聪明因为它顺便把软件任务拉进来做反例。结果是1. 10 个独立 Verilog 模块的 locality 最强属于理想情况2. E203 CPU Top 这个真实硬件 IP 的 locality 也很强明显接近理想情况3. 软件任务的 locality 更弱作者报告的一个关键数值是E203 CPU Top 的归一化熵大约是 0.8680而 Parse Lisp Expression 是 0.9126。因为这里 lower entropy 表示更强的局部性所以硬件任务的确比软件任务更“局部化”。图 3(d) 又进一步把一个具体代码单元和所有文档段落的 cosine similarity 展开给你看。它的意义是不是所有文档都在同时提供同等强的信息而是真有少数段落对某一段代码的贡献远大于其他段落。这一组图支撑了整篇论文的方法不只是工程直觉有一点点“问题结构分析”的味道。作者进一步换了几种不同的相似度模型1. BM252. DeepRTL23. Qwen3-Embedding-0.6B4. Qwen3-Embedding-8B目的很明确证明“硬件文档存在较强局部性”不是某个 embedding 模型偶然算出来的。虽然不同方法的绝对数值不同但总体排序是稳定的1. 独立 Verilog 模块拼接最局部2. REALBENCH 的硬件任务仍然明显具有局部性3. 软件任务的 locality 更弱这意味着作者的核心观察有一定稳健性。不过也要客观地说这里的证据仍然是“语义相似度代理指标”不是严格证明。它足够支撑方法设计但还谈不上是理论层面的强证明。三、LocalV 的整体流程Figure 2 给的是一个比较概括的 workflowFigure 4 给的是细化版。两张图结合起来看LocalV 的完整流程大概是1. 预处理把原始文档切成段落并给每段建立双层索引语义层总结它在讲什么词法层提取信号名、模块名、参数、宏等低层实体。2. 规划Planner 先生成整体代码骨架再把任务拆成若干 sub-tasks每个 sub-task 对应一个代码片段。3. 生成多个 RTL agent 分别在局部文档上下文里生成各自的代码 fragment。4. 合并Merge agent 把 fragment 拼成完整 Verilog并处理接口一致性问题。5. 调试如果仿真失败就利用错误信息和波形分析提取关键信号再反向去检索“最相关的文档局部片段”然后让 debug agent 做针对性修改。这一整套流程的中心思想其实非常统一无论是生成还是调试都不要重新吞整份规格而要把问题缩回到“与这个代码片段最相关的局部文档”。很多 agent 论文的问题是模块很多但内核思想并不统一LocalV 的优点在于它的预处理、检索、生成、调试全都围绕 locality 这一件事展开。1. Preprocessing预处理阶段并不只是“分段”而是给每个段落建立双层描述1. semantic level高层功能摘要2. lexical level信号、宏、参数、模块等低层硬件实体为什么要同时保留这两层因为硬件文档里既有“这个模块做什么”的功能描述也有“这个信号叫什么、宽度多少、宏怎么定义”的细节约束。只做高层摘要容易丢接口细节只做词法提取又容易失去功能上下文。所以这一步本质上是在做“为后续 retrieval 服务的文档结构化”。2. Planning and Task Decomposition这一节是 LocalV 和很多“按子模块切分”的方法不太一样的地方。作者不是简单把任务按模块名切而是1. 先生成整体 skeleton2. 再把 skeleton 里的占位部分拆成 sub-tasks3. 对每个 sub-task 检索最相关的文档片段这样做的好处是所有 sub-task 都直接服务于最终代码不需要先发明一层新的中间表示也减少了“自己给自己编目标”的漂移问题。作者在文中明确批评了一些方法会出现 objective drift这个批评我觉得是成立的。因为在复杂设计里一旦中间计划和原文档脱节后面的 debug 就会越来越难。3. RTL Generation这里的核心设计是局部上下文生成。每个 RTL agent 只看自己那一小段 task 和相关文档片段这样能减少1. phantom signals2. port list mismatch3. 对无关文档噪声的误吸收这一点和普通长文档问答里的“分块检索再回答”有点像但在这里它不是 retrieval 辅助而是生成流程的主干。4. Code Fragments Merging拆开生成之后一个自然风险就是1. 片段本身各自看着都对2. 合在一起接口不一致3. 某个 fragment 的局部逻辑和整体框架不兼容所以作者专门设计了 Merge Agent再次借助 Retriever 拉回相关文档片段做融合修正。这一点其实很现实。因为“局部最优 fragment”不等于“全局可综合模块”合并阶段在这种框架里是不可省的。5. Locality-aware Debugging这是我觉得这篇论文比很多纯生成论文更成熟的地方。作者没有停留在“生成一遍看看结果”而是把调试也纳入 locality 范式1. 从错误信息和波形里抽取关键线索2. 用这些线索反向检索局部文档3. 让 Debug Agent 做 line-number-aware edit这里的关键是调试不是重新生成整个模块而是把错误重新定位到“相关代码局部 相关文档局部”。这明显比全局重写要经济也更接近人类工程师的行为。四、实验作者主要用的是 REALBENCH。整篇论文本来就是冲着“IP 级长文档长代码”来的如果还拿 VerilogEval 当主战场论证力就会弱很多。REALBENCH 包含三类 IP1. AES encoder/decoder cores2. SD card controller3. CPU core总共 60 个 RTL generation tasks而且平均规格长度接近 10k tokens平均每个目标模块大概 320 行 Verilog。作者还补测了 CVDP 的一个子集 cid003用来说明即便在更短、更简单的任务上LocalV 也不会因为自己的局部化设计而退化。Table 2 是全文最重要的结果表。先看最核心的总体 functional pass rate1. Claude-3.7 直接 prompting19.6%2. MAGE(Claude)21.6%3. LocalV(DeepSeek-V3)35.0%4. LocalV(Claude)45.0%这个结果非常有冲击力因为它说明1. 强底模直接做远远不够2. 现有 agent 框架在 IP 级任务上增益也有限3. LocalV 提升不是一点点而是直接把整体 functional pass1 从二十多拉到了四十五作者还特别强调LocalV(Claude) 的单次生成效果已经超过 Claude 直接 prompting 的 Pass20。这句话很重要因为它说明LocalV 的优势不是靠“多采样多试几次”硬凑出来的而是单次流程本身就更靠谱。这对于成本敏感的场景尤其关键。Figure 5(a) 把 LocalV 的单次 functional pass rate 和 Claude 直接采样的 Passk 放在一起比较。图想表达的是直接采样就算从 k1 一直堆到 k20曲线也会逐渐收敛但最后还是达不到 LocalV 的单次性能。这说明问题不在于“多给模型一点随机性”而在于如果任务组织方式不对采样再多也只是扩大无效搜索。Figure 5(b) 则分析了语法错误类别比如1. erroneous macro references2. non-synthesizable syntax3. implementation error4. invalid code structure作者用这张图说明LocalV 在各类语法错误上都更低。这很能说明它不是只修功能错误而是在更早阶段就通过局部化生成减少了系统性失误。很多方法在长任务上有优势但到短任务上未必占优。作者因此在 cid003 上做了补充比较。结果是1. Claude-3.748.72%2. MAGE(Claude)44.87%3. LocalV(Claude)61.50%这说明 LocalV 不是只在“超长上下文”里才有意义。它更像是一种更稳的 RTL 生成组织方式而不只是一个长文档 hack。消融表是 LocalV 说服力很重要的一部分。完整方法的 overall functional 是 45.0%。然后作者逐步删模块1. 去掉 index掉到 35.0%2. 去掉 index 和 debug掉到 20.0%3. 再去掉 planner还是只有 20.0%这组结果告诉我们1. hierarchical indexing 是核心组件如果没有索引模型又会回到“整篇文档太杂太长”的困境里。2. debugging 也很关键光靠任务拆解不够复杂 RTL 仍然需要定向修错。3. planner 的作用更多体现在结构保持和语法组织它对 functional 的增益没 indexing 和 debug 那么夸张但能让整体过程更稳。作者最后把这三者统一解释成 locality 的不同体现1. index 建立 locality2. planner 维持 locality3. debugger 利用 locality五、附录和 failure case附录里作者给了几个失败案例失败大致分三类1. complex logic比如 AES 顶层这种复杂加密逻辑模型很难真正把状态机和轮函数实现完整。2. syntactic errors比如宏展开、位宽表达、ifdef 条件下的逗号和接口拼接。3. excessive signals像 e203 cpu top 这种信号太多时模型会混淆 directionality 和接口约束。这些失败模式其实和论文开头提出的三大挑战是呼应的说明作者前面的诊断不是乱猜而是和后面的错误现象对得上。个人看法优点。第一它提出的问题非常真。这篇论文明确冲向了更像工程现实的 IP-level 。这个方向选择本身就有价值。第二它的核心 insight 是清楚的。信息局部性不是一句口号而是1. 有定量分析2. 能直接指导方法设计3. 能统一解释预处理、生成、调试三个阶段这是比“多加几个 agent”更扎实的贡献。第三它的实验结果是有说服力的。在 REALBENCH 上从 19.6% 提到 45.0%而且是单次生成意义下的提升。这篇论文的问题和边界第一它的方法高度依赖“硬件文档确实具有较强局部性”。对很多模块化清晰的 IP这个假设成立但如果规格文档组织很差或者跨章节依赖极强、约束散落得很碎LocalV 的优势可能会变弱。第二合并阶段和调试阶段仍然可能成为瓶颈。虽然拆分生成降低了局部难度但 fragment merge 本身并不是一个轻松问题。论文里展示了 Merge Agent但对其失败模式和成本展开得还不够多。第三它当前更多解决“生成出可工作 RTL”的问题而不是“生成高质量可综合可优化 RTL”的全部问题。从论文主结果来看重点仍是 syntax / functional correctness。PPA 方面作者提到和开源 AES 方案相比是 comparable但这部分论证明显没有 correctness 那么完整。提一嘴这篇paper投的26ICLR 得分4466最后被拒有点可惜。但也基本符合我读完这篇文章的印象。问题有很好的现实性但是对特例依赖性太强、对于agent方面的创新较弱更多的集中在workflow。祝作者有好运气。