碗丸聊一篇和我日常做RTL设计关系很密切的论文，题目很直白——利用信息局部性做IP级Verilog生成。最近几年，用大模型自动写代码已经不稀奇了，C、Python随手就是一段，但放到硬件描述语言（HDL）上，效果立刻拉胯。很多人试过让大模型写Verilog，得到的代码要么语法没问题但一综合全是时序违例，要么模块接口乱成一团，甚至端口都能少两根。问题出在哪？我自己的感受是：硬件代码和软件代码的“上下文依赖方式”完全不一样，而通用模型根本不懂这种差异。
这篇论文提出的LOCALV，核心思路就是抓住Verilog代码里的“信息局部性”来做IP级生成。所谓IP级，通俗说就是生成一个完整可复用的小功能模块，比如UART、SPI、FIFO这类常见的总线或存储控制模块，而不是零散的几行表达式。它能解决的问题很实际：当一个模块的结构高度自包含、内部信号强相关、外部接口相对固定时，利用好这种局部性，生成质量能提升一个台阶。适合谁看？如果你是做FPGA开发、数字IC前端、或者对AI辅助EDA工具感兴趣的工程师和研究者，这篇文章的思路值得仔细品一品。它不只是一个模型的创新，更像是在提醒我们：别老想着让大模型盲目模仿软件代码生成，硬件代码本身有它的“脾气”，顺着来才能出活。
1. 论文在解决什么问题：RTL自动生成的“最后一公里”
1.1 通用代码生成和Verilog生成的底层差异
先盘一下背景。通用代码生成任务里，模型要在自然语言描述或部分代码的基础上，补全剩余代码，目标是保证语法正确、语义大致符合需求。对软件代码来说，这种“局部性”往往是成立的：一个函数内部的变量、调用、逻辑段之间依赖很近，跨文件、跨模块的引用虽然在，但大模型可以借助长上下文窗口去抓。
但Verilog很不一样。我自己写RTL时的体验是，一个功能模块的代码经常自包含度极高：几百行代码内部，信号之间你牵我我牵你，但对外只有一组端口。换句话说，一个FIFO控制器里，wr_ptr、rd_ptr、full、empty这些信号几乎只在一个模块内部纠缠，外部根本不会直接碰它们。这种结构特征给生成模型带来的好处是，局部窗口内信息密度远远高于通用代码，但坏处是，任何跨模块的信号配合、跨时钟域的交互、全局参数传递，都会让依赖关系瞬间失控。通用模型并不理解“模块边界是信息依赖的分水岭”，导致它们经常把不该外连的信号拉到端口里，或者把一个模块内部信号错误地当成全局信号处理。
LOCALV这篇论文抓住的正是这个问题。它把生成目标定义为IP级模块，把代码语言建模从“逐行预测”转向“结构感知的局部建模”，简单说，就是让模型更关注模块内部紧密耦合的信号、状态和控制逻辑，而不是盲目依赖遥远位置的token。
1.2 为什么“局部性”是突破口
如果你做过体系结构相关的底层研究，一定眼熟“局部性”这个词。做CPU缓存的人天天讲时间局部性、空间局部性：刚访问过的数据很快还会被访问，邻近地址的数据大概率一起被访问。Verilog代码里其实也有一模一样的规律——同一模块里的信号、寄存器、赋值语句之间，在文本距离上往往非常接近；一旦跨越模块边界，这种关联度断崖式下降。这就是结构上的“空间局部性”。而一个完整的状态机、一组握手协议逻辑，通常会在一段代码里反复出现、多次引用，这又是“时间局部性”在代码层面的体现。
把一个工程问题拆成局部性问题来处理，最大的好处是能大幅降低建模复杂度。如果模型能意识到“模块内部必须自己闭环”，它就不会去外面找依赖，也不会让内部信号乱跑。对生成任务而言，约束越清晰，生成一致性和综合可通过率就越高。这篇论文的价值就在于，它没有简单套用大模型那一套，而是从硬件代码本身的特性出发，设计了一套利用局部性提升生成质量的完整方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 信息局部性在Verilog代码里长什么样
2.1 从体系结构的局部性概念说起
不急着聊模型结构，先看看Verilog代码里到底哪儿藏着局部性。做过RTL的人其实有直觉，但从来没把它当成一种可量化的“信息特征”。我把它拆成几个层次来理解。
第一层是模块边界。一个module就是一堵墙，墙内信号随便连接，墙外只能通过端口沟通。这决定了跨模块的信息依赖极弱，同一个模块内部的信息密度极高。这是Verilog和C语言最大的不同点。你写C函数时，函数可以随心所欲地访问全局变量，但写Verilog模块时，内部信号几乎不可能被另一个模块直接引用。没有全局变量，做不了全局变量，这就是硬件语言的纪律性。
第二层是模板与重复子模式。RTL代码里充满了固定的写法：异步复位同步释放、三段式状态机、握手valid-ready协议、FIFO指针的格雷码转换、跨时钟域的打两拍。这些写法在模块内反复出现，而且形式非常固定。从信息论角度看，这种重复模式意味着代码中存在大量可以压缩的结构化信息，模型一旦捕捉到这些模板，生成时就等于在复读机基础上做局部微调。
第三层是命名与语义的局部共现。硬件的信号命名通常有很强的“语义簇”特征。写时钟相关的代码时，clk、clk_en、rst_n、q、d这些符号几乎必然同时出现；写写通道时，wdata、waddr、wen必然抱团。这种共现不是偶然的，而是硬件设计习惯长期沉淀的结果。模型不需要理解数字电路的物理含义，只需要学习这种共现规律，就能在生成时做出合理的信号推断。
第四层是端口和参数列表的高度结构性。IP级模块的端口定义往往不多，但每个端口的位宽、方向、类型必须准确。一个模块如果在端口上出错，整个集成就崩了。幸运的是，端口列表是模块边界上的“结构化摘要”，信息高度压缩，一个看得懂端口的模型，很大程度上就控制住了模块的整体行为。
2.2 具体到RTL代码的四种局部性表现
把这四个层次落到代码上，就可以看清局部性的“形状”。举个例子，一个典型的FIFO控制器模块，长度可能在200到400行之间。前50行是端口声明和参数定义，中间是内部信号和状态寄存器，后面是写指针、读指针、空满标志的组合逻辑。整个模块里，rd_ptr和wr_ptr这两个信号会在几十行代码中反复出现，而且每次出现都伴随着几乎固定的逻辑语义。任何一段合理的生成结果，都不可能在写指针逻辑时突然冒出一个八竿子打不着的全局宏或外部信号。
反之，如果把模块代码按行切碎，丢给一个没有局部性感知的模型，它很可能会在生成内部逻辑时，错误地把一些原本只在端口列表里出现的信号混入内部处理，或者干脆忽略某个关键的状态位。这种现象我在实际使用通用大模型生成RTL时遇到过太多次，堪称“局部性缺失综合症”。LOCALV把这种直觉形式化了：它在训练和生成过程中显式建模这种“模块内高内聚、模块间低耦合”的信息结构，让模型学会在正确的范围内获取上下文。这个思路听完很朴素，但效果我认为比单纯把模型规模做大更关键。换个角度说，如果算法不尊重硬件代码的先天结构，再大的模型也是在错误的方向上浪费算力。
3. LOCALV方法拆解：如何把局部性变成生成能力
3.1 面向局部性的代码表示与预处理
我对这篇论文方法部分的理解是，它的第一步不是直接卷Transformer，而是对Verilog代码做“局部性感知的表示重构”。常规做法是直接把代码当文本喂给tokenizer，然后用注意力机制去建模依赖。但Verilog代码里，模块边界、端口列表、内部信号声明、always块、assign语句，这些都是有明确结构意义的物理边界。如果不在表示层做文章，模型只能自己隐式学习这些边界，效果不稳定。
一种合理的设计是给代码添加结构化token：在module声明、端口列表、begin/end、always块等位置插入特殊标记。这些标记不参与语义计算，但能帮助模型快速定位“我现在处于模块的哪个区域”，从而调整注意力范围。另一种方式是按模块边界做滑动窗口切分，窗口长度尽量覆盖整个模块，而不是机械地取固定长度截断。固定长度截断最大的问题是，它可能把一个完整的always块劈成两半，让模型在一个支离破碎的局部环境里做预测。正确的做法是让窗口随代码结构走，模块边界就是天然断点。
还有一个值得提的预处理细节是把参数化模块展开。IP级代码里经常有parameter、localparam、宏定义这类参数化写法。如果你不对这些参数做处理，模型会面临两难：不展开，它不知道实例化后的具体数值；全展开，又会让代码变得冗长且破坏原始结构的局部性。合理的折中是保留参数的默认值，并在上下文里注入参数名与具体值的映射关系。这种“参数-值”的局部映射，远比让模型自己从头脑补一个参数化逻辑要稳。
3.2 局部性引导的上下文建模
到了模型层面，核心问题变成了：怎么让注意力机制意识到局部性的存在？这里的关键设计思路是“结构化注意力窗口”。具体来说，如果一个模块已经切分到足够细的粒度，模型在计算某一行token的注意力时，应该优先考虑同模块内的token，然后是相邻模块的端口接口信息，最后才是全局的参数和宏定义。这种分级注意力既保留了全局参数的约束能力，又避免了长距离依赖对局部生成造成干扰。
实践里可以通过给token赋予“模块归属”特征来实现。比如每个token除了本身的embedding，再拼接一个模块ID特征或者区域类型特征。这样注意力计算时，模型能自然而然地降低跨模块token的权重。这比硬掩码更灵活，因为硬掩码会让模型完全看不到外部信息，但某些跨模块调用（比如顶层例化）确实需要外部信息。折中方案是让硬件设计者用“允许跨模块参考”的规则来控制注意力范围，既尊重局部性，又不丢失必要的全局上下文。
还有一个操作层面的大招：生成时采用“骨架优先，细节填充”的策略。先用局部性注意力生成完整module骨架，包含端口、参数、内部信号声明，这一步严格控制接口正确性；然后再逐个填充内部逻辑块。我试用过类似思路，效果确实好于一口气直接生成全文。原因在于，先确定骨架相当于把搜索空间缩小了很多，之后每个逻辑填充任务都是在一个高度确定的局部结构里做决策，难度和错误率都会显著下降。
3.3 训练目标与生成策略的关键设计
训练阶段，LOCALV这类工作的核心也不是让模型做整段代码的无差别预测，而是设计了一系列与局部性相关的辅助任务。一个常见思路是掩码重建：随机遮盖模块内几个关键信号，要求模型根据局部上下文补全。这能促使模型学习模块内部信号的强耦合关系。另一个思路是端口预测：只给模块内部代码，不给端口声明，让模型猜测端口列表与其位宽。这能强制模型理解“内部使用了哪些信号、这些信号必须向外暴露”的边界逻辑。
还有一个容易忽略的训练细节：模块级别去重。同一个功能模块可能出现在多个工程里，但命名、注释、格式有细微差别。如果数据集里充满这类重复，模型会偷懒去记忆固定答案，而不是真正学习局部性结构的生成规律。按模块语义去重后，模型被迫学到更本质的模块结构知识。这点在自建数据集时尤其值得注意，别以为语料越多越好，重复语料在HDL数据里比通用代码严重得多。
生成策略上，还应该结合RTL代码的性质做针对性解码。比如在生成状态机相关代码时，可以施加“状态枚举必须先定义”的约束；在生成寄存器赋值时，可以要求所有always块中被赋值的reg都已在前面声明。这种约束不来自某个复杂算法，就来自RTL代码的语法纪律。把纪律写进解码过程，生成结果的质量提升会很直接。
4. 从论文到实践：想复现这个工作该怎么做
4.1 数据集构建与局部性标注
如果看完论文思路，想在自己的项目里试试，第一步是搞到合适的数据集。公开可用的RTL数据其实不少，常见渠道是各种开源IP仓库和处理器核源码，但直接用肯定不行，得做清洗。
首要工作是模块切分：写一个简单的解析器，把每个module提取成独立样本。这个解析器不需要做完整语义分析，只需正确配对begin/end和module/endmodule，就能可靠切分大部分代码。切分后统计样本长度分布，删掉过大或过小的模块，保留100到1000行之间的中等模块，这类样本生成难度适中，也最能体现“局部性”的增益。
然后是局部性标注。这一步没有现成工具，但可以用一种简单有效的替代方案：计算信号共现矩阵。把模块内所有信号提取出来，统计它们在同一个always块或assign语句中共同出现的次数。共现次数高的信号对，就构成了局部性关系的标注。这个标注可以用于两方面：一是训练数据增强，通过共现关系构造掩码任务；二是作为评估指标，检查生成代码中信号共现结构与原始代码的匹配度。
4.2 工具链选择与评估指标
复现时不需要从零训练一个大模型，我建议在开源代码模型基础上做微调或注入局部性偏置。模型规模可以控制在6B到15B之间，对硬件生成任务来说，太小的模型学不到结构知识，太大的模型在局部性建模上没有额外收益，还会显著增加微调成本。硬件上，单机多卡即可，数据量在10万到20万条模块样本之间，微调便能看到明显效果。
评估方面，我试过一些指标后发现，传统的BLEU和Code-BLEU对RTL生成毫无意义，语法正确率只是一个及格线，真正有用的指标主要有四个。第一是可编译率，用业界通用编译工具跑一遍，代码能否完整编译通过；第二是模块接口匹配率，生成模块的端口名、位宽、方向是否与需求一致；第三是仿真功能通过率，跑几个定向测试用例，检查功能是否准确；第四是综合结果无警告率，用综合工具如开源的综合工具链跑一次，看是否有latch推断、位宽截断、组合环路等警告。论文工作通常会在更大规模上评估，但你自己复现时，这四个指标已经能说明很多问题。
4.3 一个可落地的实验路线
具体路线我建议这样。第一步，搭建数据管道，从开源RTL中提取出模块样本，并随机分成交叉验证集和测试集。第二步，在目标模型上做一个“局部性预训练”，把模块边界token和信号共现掩码任务加入训练目标，这一步并不难实现，难的是设计好掩码概率和训练步数。第三步，设计提示模板，输入尽量包含模块功能描述、端口要求、参数要求等结构化信息，让生成过程有据可依。第四步，迭代评估：先看可编译率，如果不能编译，大概率是语法结构问题；再看接口匹配率，如果接口错了，说明提示信息没被充分利用；最后再纠结仿真功能。
我自己的经验是这个顺序不能乱。很多人拿到模型第一步就追求仿真功能，结果在语法和接口上反复返工。先把“骨架”的问题解决干净，再去填“血肉”，复杂度会低很多。LOCALV这类局部性工作之所以能出效果，本质上就是因为它把RTL生成这个大任务分解成一系列符合结构规律的小任务，每一步都由局部信息驱动，误差被控制在极小的范围内。
5. 局限性与边界条件：不是所有Verilog都适合“局部生成”
被LOCALV的好处讲完，也得泼点冷水。信息局部性是个好抓手，但它不是万能的。有一个很典型的场景：跨时钟域（CDC）和全局异步逻辑。两个模块虽然边界分明，但它们的交互需要全局时钟方案和同步策略的约束，这些约束并不体现在模块内部文本里。如果模型只依赖模块内局部性，它生成出来的跨时钟域握手逻辑很可能是“语法完美但物理完全不可用”的代码。这就需要额外的全局约束或者验证步骤来兜底。
另一个短板是性能与面积的优化。LOCALV生成逻辑的正确率再高，它也不理解时序收敛、面积优化、功耗平衡这些物理目标。它会用最直白的方式实现功能，但可能引入过深的组合逻辑链，或者不使用流水线导致频率上不去。这是所有代码生成模型的老毛病，加上了信息局部性也不能根治。我的建议是，把生成结果当成第一版草稿，而不是最终交付物，用它来加速前期开发，但该做的timing分析一张都不能少。
还有一个工程化痛点：形式化验证。自动生成的RTL必须与设计规格保持一致，但自然语言描述到Verilog之间没有形式化的对应关系。目前只能靠设计者写测试断言或者用仿真用例来覆盖，而覆盖的充分性很难保证。LOCALV这类方法可以在生成阶段减少基础错误，但“生成结果=验证通过”这个等式永远不成立。做实际项目的朋友务必记得，工具生成代码只是把工作量前置了，验证环节一分都省不掉。
6. 我的一些感想和实操提醒
6.1 不要迷信大模型，回归代码结构本身
去年到现在，我持续在尝试各种RTL生成方案，最大的感受是：硬件代码生成的核心瓶颈不是模型capacity，而是如何把硬件设计的结构约束注入到生成过程中。LOCALV提的信息局部性，抓住了Verilog最重要的特征，思路有很强的启发性。相比之下，单纯比拼参数量的路线，在RTL领域效率是很低的。你在软件代码上增加参数量能学到更好的等价语义，但在硬件代码上，模型学到更多的是“表面相似性”，深层结构如果有偏差，代码根本没法用。
有一个反直觉的发现：当我限制了模型的上下文范围，只让它“看”当前模块内部的信息时，生成质量反而提升了。这说明对某些任务，更多信息并不等于更高正确率，结构化筛选比无脑堆信息重要得多。做生成实验时，很值得多试几种上下文窗口策略，不要默认长上下文一定更好。
6.2 四个实操避坑技巧
写到这里，我把自己的几个高频问题快速列一下，给大家做个参考。
生成代码语法全对但仿真一直不通过，大概率是复位逻辑没处理对。很多模块的复位信号是异步低有效，模型在生成时容易搞成同步复位，或者把复位条件写反。解决方法是，在训练提示里显式标明“使用异步低复位”，并在数据集中增加一类专门学习异步复位的样本。
端口位宽错乱是第二常见问题。主要原因是模型分不清输入输出方向。我建议生成时分两步：先把端口声明生成完并锁定，再生成内部逻辑，而不是一次性输出全部。锁定后的端口可以作为局部约束参与后续生成，能明显降低位宽错误率。
状态机生成的next-state逻辑容易多条件覆盖错误。有时会有多个状态条件同时满足，模型却只生成一个分支。这个问题的根源在于局部上下文中的条件互斥信息不够。可以在数据预处理阶段把相邻状态转化条件分组标注，让模型认识到同一个状态下的多个条件通常是互斥优先级。
位宽和符号对齐的坑也很多，有符号数运算时位宽扩展经常莫名失败。一个比较土但有效的办法是，在生成数据集中加入大量有符号运算的模板，让模型反复模仿，加强它在token层面的记忆。这类问题靠“道理”教不会，只能靠大量重复示例来训练。
6.3 后续扩展方向
LOCALV这个思路还有几个很有意思的延展空间。现在它主要面向IP级模块生成，下一步完全可以往系统级探索：多个IP之间的互联逻辑、总线协议栈、甚至NoC路由生成，这些场景里局部性依然存在，但颗粒度更大、层次更复杂。此外，局部性不仅可以用于生成，还可以用于代码总结、模块重构、IP快速移植。特别是“老IP移植到新工艺或新总线协议”这种活儿，本质上就是保持模块内部逻辑局部性不变、只改边界适配层，和LOCALV的理念完美契合。
我个人在实际操作中的体会是，信息局部性这个视角不只是生成模型的利器，它也反向提醒了手工设计师：写RTL时尽量让模块边界清晰、信号局部内聚，不仅代码更好维护，未来还更容易被AI工具理解和复用。你写代码的方式，决定了工具能不能帮你干活。与其等着更好的模型出现，不如先把手上的RTL结构整理得更“局部友好”。
最后再分享一个小技巧：如果你没法复现完整模型，退而求其次，可以手动在本地用局部性思维设计一套提示词规则，把大模型的生成限制在模块边界、端口信息和固定模板内，效果也会比直接自由生成好很多。工具服务于思路，思路通了，工具只是用来落地的桥梁。