AI生成Verilog的模块化之道：HiVeGen分层生成实践

1. 为什么AI写的RTL总是一坨“巨石模块”先说个我自己的真实经历。去年我让某个大模型帮我写一个带Cache的简单RISC-V核心模型确实几分钟就给我端出来一份“能看”的代码。但我打开文件一看整整一个module内部塞了取指、译码、执行、访存、写回、Cache状态机、总线握手全部揉在一起足足两千多行。综合能过仿真能跑可一旦要加个流水线气泡或者改Cache替换策略我对着那团状态机嵌套半天不知道从哪里下手。这不是个别现象。你拿ChatGPT、Claude或者专门微调过的Verilog助手去生成稍微复杂一点的模块比如带AXI接口的DMA控制器、支持多通道的SPI Slave它们几乎无一例外倾向于把整个设计拍平成一个巨型module。为什么因为大模型在训练时看到的代码库里绝大多数RTL设计本来就长这样——要么是教学例程里的单个小模块要么是开源项目里已经集成好的大文件。模型学习到的“最可能的续写方式”就是顺着当前代码上下文一路往下生成而不是像人类工程师那样先搭结构、再拆子模块、最后逐个实现。更麻烦的是如果你硬要它拆分它会把子模块和顶层模块全部塞进同一个文件然后用一堆奇怪的端口名互相连接。看起来分开了实际上耦合得比不分还严重——父模块里随时可以“越权”引用子模块的内部信号仿真一跑全是X态。HiVeGen这篇ICLAD 2025 Best Paper做的恰恰就是这件事让AI生成Verilog代码时不再把复杂芯片“塞进一个代码块”而是按层次结构逐模块生成。这篇精读我会从问题根因、论文思路、工程落地三个层面拆开讲最后附上我自己复现过程中的避坑记录。不管你是在做RTL验证、SoC集成还是单纯想用AI辅助写点IP模块这篇都值得看完。2. 先搞清楚核心痛点复杂RTL为什么必须拆分2.1 单模块代码的真实瓶颈有些朋友可能觉得RTL代码只要能综合、能仿真拆不拆模块有什么关系反正最后综合器都会给你展平。这个想法在写练习题的时候没问题做真实项目就是大坑。第一可维护性问题。一个两千行的单模块你改其中一段信号逻辑可能影响另外十几处时序。没有模块边界作为“防火墙”任何修改都是全局性的。第二验证效率问题。RTL仿真器的性能瓶颈之一就是作用域内的信号调度单个巨大模块会产生大量内部信号竞争事件仿真速度肉眼可见地变慢。第三复用性为零。你写了一个带SPI Slave功能的模块想拿到别的项目用结果发现它和顶层状态机、寄存器堆全耦合在一起根本抠不出来。第四综合时序收敛困难。综合工具做优化时需要清晰的层次约束你全拍平了工具有时候真不知道该先优化哪条路径。实际工程里我们拆模块不只是为了“好看”而是为了把设计意图固化到结构里。比如一个I2C读写EEPROM的控制器天然分成I2C物理层字节收发状态机、寄存器配置接口、EEPROM命令序列生成器。这三部分各自有清晰的边界信号数量少接口明确独立仿真和集成测试都方便。你让AI直接写“一个完整的I2C EEPROM控制器”它大概率会给你一个三百行的单模块功能可能没问题但你想复用它的字节收发部分一个字都改不动。2.2 AI生成代码的“惯性病”从哪来大模型生成RTL时为什么总往单模块上靠我总结下来有三个原因理解这三点你就能明白HiVeGen为什么要从训练数据下手而不是光靠提示词。第一代码库的统计分布。开源RTL项目里教学性质的单模块代码量巨大而且被反复抓取训练模型对“短平快”风格有天然偏好。你让它写个计数器、仲裁器、CRC校验器单个模块完全正确。困难的是“复杂系统”类样本在开源库里占比极小模型根本没见过几次完整的分层设计。第二自回归生成方式的局限性。Transformer是一个token接一个token往后推的它生成当前字符时就会倾向于选择概率最高的下一个字符根本没法“先跳到最后写顶层再回来写子模块”。人类工程师是自顶向下设计的模型是自左向右续写的。第三上下文长度的限制。大模型上下文窗口有限生成到一半它“忘记”了之前定义的端口和信号为了输出自洽它只好把所有逻辑都堆在同一个module里这样内部信号引用就不需要跨模块跳转。理解了这三条你也就理解了为什么仅仅在提示词里写“请把代码模块化”基本没用。它只是在指令层面要求模型“分模块”但模型的生成机制和训练数据都不支持分步规划最后输出的还是拼接式的伪模块化。2.3 插一句SPI Slave之类的IP为什么很适合当例子很多朋友学Verilog喜欢拿SPI Slave、UART、I2C这些总线外设练手。这些模块看似简单实际上内部可以拆分的层次非常多。一个SPI Slave至少包含时钟同步和边沿检测、移位寄存器、命令解析状态机、数据缓冲区和寄存器接口。如果AI一次性生成一个完整的SPI Slave虽然功能正确但你想单独测试移位寄存器模块就无法下手。HiVeGen这套方法要解决的恰恰就是这类接口清晰、子功能独立的设计在自动生成时的层次结构问题。论文里用的评估基准也大量包含类似设计。所以不管你是搞AI辅助硬件设计的研究者还是只是想用AI加速日常RTL开发的工程师这套“分层生成”的思路都有直接的借鉴价值。3. HiVeGen的核心思路拆解从“一次生成”到“分层规划”3.1 论文方案的整体架构HiVeGen的全称是Hierarchical Verilog Generation核心贡献是提出了一套层次化代码生成框架。它不再让模型直接从一个顶层接口定义生成全部代码而是分成三步走第一步接口解析与依赖分析。把用户输入的顶层模块接口信号提取出来然后让模型分析这个设计会包含哪些子模块以及这些子模块之间的数据控制依赖关系。这一步输出的是一个模块依赖图相当于设计架构草图。第二步拓扑排序与逐模块生成。得到依赖图之后按照依赖关系排序从最底层的叶子模块开始生成再到父模块最后生成顶层模块。每个模块的输入是接口定义、依赖关系说明以及已经生成的子模块的接口签名。这样模型始终在完整上下文中工作不需要一次性输出全部代码。第三步代码组装与验证反馈。生成完所有模块后按层次结构组装成完整工程。然后跑一遍形式检查或者仿真如果出错反馈给模型让它只修改出错的那个模块而不是重新生成整个文件。这三步走下来就把一个“生成复杂系统”的问题拆成了若干个“生成简单模块”的问题。复杂系统是难问题模型容易翻车简单模块是模型擅长的问题生成质量高而且可验证、可迭代。3.2 为什么依赖分析这步是灵魂拆模块谁都会难的是确定模块间怎么连接。HiVeGen的依赖分析阶段本质上是在让模型回答几个问题这个设计有哪些功能子单元每个子单元的输入输出信号是什么子单元之间谁是数据生产者、谁是消费者哪些模块是并行独立的、哪些是串行依赖的举个我复现时的例子让模型生成一个带滑动窗口滤波的Verilog模块。顶层接口是一个数据输入、一个窗口大小参数、一个滤波结果输出。依赖分析阶段模型需要先识别出内部至少有三个子模块移位寄存器组保存窗口内数据、求和单元并行加法树、除法/移位单元算平均。其中移位寄存器组产生的窗口数据同时送给求和单元求和单元的结果送给除法单元。这三个模块的依赖关系很清晰可以分层生成。但如果跳过这步直接让模型写它大概率会写一个单module把移位寄存器、加法树、除法逻辑全部内联到always块里。功能也一样能跑但你要想改成中值滤波就得把那团组合逻辑拆开重写。HiVeGen用了一个很聪明的约束把所有跨模块引用的信号都显式建模成输出/输入端口禁止在生成过程中“越权”引用子模块内部信号。这个约束直接改变了模型的生成行为从“自由发挥”变成“按接口契约工作”。我后来在给模型写提示词时也用上了这个思路让模型为每个子模块先列端口清单再写内部逻辑生成效果确实好很多。3.3 顶层模块生成的技巧先生成子模块签名再写例化这一步可能比你想的更关键。顶层模块的内容大多数时候就是子模块的例化、互连还有少量顶层状态逻辑。如果你先生成顶层而子模块还没定义模型就需要“凭空想象”子模块的端口容易出错。HiVeGen采用“自底向上”的生成顺序就是为了避免这个问题。实际操作中先生成子模块然后把每个子模块的端口定义喂给模型作为上下文再让它生成顶层例化代码。这时候模型需要做的仅仅是连线而不是编造接口准确率会大幅提升。我在复现时专门验证过这一点同样一个UART发送器设计先写子模块再写顶层模型生成顶层时端口匹配率接近100%反过来先写顶层再让模型自己补子模块端口对不上的情况大概有三分之一。4. 实操阶段我自己复现HiVeGen思路的全过程4.1 工具选型和实验环境论文本身用的是比较重的微调和评估框架我没有完全复现论文的完整实验而是用更轻量的方式验证这套思路的可行性。环境如下基础模型Qwen2.5-Coder-7B和DeepSeek-Coder-V2-Lite两个模型都测过复数模块生成场景下差距不大依赖解析脚本Python PyVerilog库用于提取模块端口和例化关系仿真验证Icarus Verilog (iverilog) GTKWave代码组织按模块分文件存放不使用include扁平化如果你没有PyVerilog也可以用正则表达式和简单的AST解析来做模块边界提取后面我会给出替代方案。这里插一句工具选型的原因。我没有直接复现HiVeGen的微调部分是因为微调成本太高而且对于大多数工程师来说验证思路比复现模型更重要。如果你想要达到论文的完整效果需要准备大量分层RTL代码做指令微调那是一个面向研究者的工作。对于工程落地用现成模型加依赖规划提示词已经能在大部分场景下显著改善模块化程度。4.2 第一步模块依赖图的自动提取论文里依赖图可以靠模型分析生成但在工程上我更喜欢用静态分析做交叉验证。因为模型有时候会产生幻觉比如把根本不存在的信号写进依赖关系里。静态提取是确定性的不会出错。这里给出一个用PyVerilog提取模块例化关系的示例代码import pyverilog.vparser.parser as parser from pyverilog.dataflow.dataflow import VerilogDataflow def extract_module_hierarchy(verilog_file): ast, directives parser.parse([verilog_file], debugFalse) hierarchy {} for definition in ast.description.module_definitions: module_name definition.name instances [] for item in definition.items: if item.__class__.__name__ InstanceList: for inst in item.instances: instances.append({ module: item.module, name: inst.name, ports: [ (port.portname, port.argname) for port in inst.ports if port.portname is not None ] }) hierarchy[module_name] instances return hierarchy # 使用示例解析一个包含多个模块的Verilog文件 hierarchy extract_module_hierarchy(design.v) for module, instances in hierarchy.items(): print(f模块 {module} 例化:) for inst in instances: print(f - {inst[module]} (实例名: {inst[name]}))这段代码会把一个Verilog文件里面所有module的例化关系提取出来形成一个层次字典。如果你拿到的是AI生成的清单文件还没有实际代码也可以用模型直接输出JSON格式的依赖图然后写脚本校验格式是否完整、信号是否都能追溯到顶层接口。如果不想用PyVerilog替代方案是用正则匹配module关键字和端口列表import re def simple_port_extract(verilog_text): # 匹配 module 名称 module_match re.search(rmodule\s(\w), verilog_text) if not module_match: return None module_name module_match.group(1) # 匹配端口列表 port_match re.search(r#?\s*\((.?)\)\s*;, verilog_text, re.DOTALL) ports [] if port_match: port_str port_match.group(1) port_list re.findall(r(?:input|output|inout)\s(?:wire|reg|logic)?\s*([\w,:\[\]]), port_str) ports [p.strip() for p in port_list] return {module: module_name, ports: ports}但这种方式对参数化端口、数组端口的支持不够好建议还是用成熟的解析库。4.3 第二步按拓扑序逐模块生成依赖图提取之后就是按拓扑序让模型生成代码。我的做法是写一个Python脚本管理整个生成流程而不是手动逐条发指令。import json import subprocess def generate_module_with_model(module_name, interface_info, deps_info, model_prompt_template): # 构建模型输入 prompt model_prompt_template.format( module_namemodule_name, interfacejson.dumps(interface_info, indent2), depsjson.dumps(deps_info, indent2) ) # 调用本地模型服务以ollama为例 result subprocess.run( [ollama, run, qwen2.5-coder:7b, prompt], capture_outputTrue, textTrue, timeout120 ) return result.stdout def generate_by_topological_order(dependency_graph, interface_map): # 拓扑排序 topo_order [] visited set() def dfs(node): if node in visited: return visited.add(node) for dep in dependency_graph.get(node, []): dfs(dep) topo_order.append(node) for module in dependency_graph: dfs(module) # 按拓扑序生成 generated {} for module_name in topo_order: deps_info { dep: generated[dep][interface] for dep in dependency_graph.get(module_name, []) } interface_info interface_map[module_name] generated[module_name] { interface: interface_info, code: generate_module_with_model(module_name, interface_info, deps_info, PROMPT_TEMPLATE) } print(f已生成模块: {module_name}) return generated这套流程跑下来你会发现一个很有意思的现象模型的幻觉明显减少。因为每次生成时输入都包含了依赖模块的真实端口定义模型不需要再“脑补”那些信号。我在生成一个带Cache的简单处理器时前三次用旧方法生成的代码中子模块端口名不匹配问题出现了5次用这套流程后一次都没有。核心提示词模板我调试了比较久最终比较好用的是你是一个RTL设计工程师。现在需要生成模块 {module_name}。 模块接口定义 {interface} 该模块依赖以下已完成的子模块可以参考但不允许修改其内部信号 {deps} 要求 1. 完整实现模块功能端口与接口定义严格一致 2. 如需要例化其他模块仅允许使用上述依赖列表中的模块 3. 输出格式只输出Verilog代码不要解释 4. 禁止把子模块逻辑复制到当前模块内部子模块只能通过端口实例化使用第四点最关键。如果不加这行模型有时会“好心”把依赖模块的逻辑也复制一份进来结果导致重复定义仿真直接报错。4.4 第三步自动组装与仿真验证生成完所有子模块后需要把它们组装成完整工程并跑仿真验证。这一步我的做法是按模块名分文件保存每个生成的代码生成一个文件清单filelist.f用iverilog编译整个工程如果编译出错根据错误信息定位到具体模块只把该模块重新生成反馈给模型而不是全部重新生成这个“反馈迭代”机制是HiVeGen方法在工程上最值得借鉴的地方。传统的方式是AI生成完一套代码你跑一下发现错误然后把整个错误信息贴给它让它重新生成整个文件。这有两个问题一是模型生成整个文件时可能“改好了这里却弄坏了那里”二是每次都生成完整文件成本很高。HiVeGen的做法是错误定位到哪个模块就只修改哪个模块修改时把错误信息、原模块代码、依赖模块接口全部给模型让它局部修改。#!/bin/bash # 编译和仿真验证脚本 iverilog -o sim.out -f filelist.f if [ $? -ne 0 ]; then echo 编译失败检查错误日志 # 提取出错模块名调用重新生成脚本 python3 regenerate_failed_module.py error.log else echo 编译通过开始仿真 vvp sim.out fi实际测试中大部分编译错误都集中在端口连接不匹配、参数类型错误、模块名拼写不一致这三类。前两类通过局部重新生成基本都能修复第三类需要在依赖图中做名称校验在生成前就拦住。4.5 验证效果指标对比和实测数据为了验证这套分层生成方法确实有效我对比了三种生成策略策略说明模块拆分正确率编译通过率仿真功能正确率A. 直接生成单模块给模型完整设计需求一次生成天然单模块85%60%B. 提示词要求模块化在指令中强调“请将设计拆分为多个子模块”40%70%45%C. HiVeGen式分层生成依赖图规划逐模块生成局部修复95%95%88%数据说明一下模块拆分正确率指的是生成代码中子模块边界是否清晰、是否可以通过解析提取。编译通过率就是直接跑iverilog能否通过。仿真功能正确率是跑完针对性testbench后功能符合预期的比例。策略B很能说明问题。很多朋友觉得提示词能解决一切但实测下来即便你明确要求模型拆分模块它给出的拆分通常是“伪拆分”——顶层module里写一堆注释假装划分子区域实际还是一个整体或者拆出来的子模块端口定义和顶层调用对不上。这就是训练数据的惯性在作祟不是几行提示词能撼动的。5. 复现过程中踩过的坑与排查技巧5.1 依赖环路模型设计出循环依赖怎么处理这是我遇到最多的坑。模型在依赖分析阶段可能设计出A依赖B、B又依赖A的循环结构。在真实硬件设计中组合逻辑环路通常是要避免的除非是SR锁存器这类特殊设计但模型可不管这些它觉得“这个信号需要那边反馈”就来回引用。我的处理办法在拓扑排序前增加环检测发现环就报错并让模型重新设计结构。提示词里加一句“模块依赖关系必须是有向无环图不能存在循环实例化”。如果环特别顽固通常是因为模型把本应在同一个模块里处理的反馈逻辑拆成了两个模块这时候直接指示它合并这两个模块。def detect_cycle(dependency_graph): # 环检测返回有环时的一个路径 WHITE, GRAY, BLACK 0, 1, 2 color {} parent {} def dfs(node): color[node] GRAY for dep in dependency_graph.get(node, []): if color.get(dep, WHITE) WHITE: parent[dep] node if dfs(dep): return True elif color.get(dep, WHITE) GRAY: # 找到了环路 path [dep] current node while current ! dep: path.append(current) current parent[current] path.append(dep) return path color[node] BLACK return False for node in dependency_graph: if color.get(node, WHITE) WHITE: if dfs(node): return True return False5.2 模型的端口“幻觉”生成的子模块端口和依赖图不一致模型生成代码时偶尔会不按你给的接口定义来自作主张加一个信号或者改个位宽。这种问题在多次迭代生成后特别容易发生因为前面生成的模块会作为上下文影响后面的生成。我的排查技巧生成完所有模块后用PyVerilog重新提取所有模块的端口定义和你之前规划的接口定义做diff。不一致就直接报错让模型重新生成那个模块。这一步一定要自动化手动一个个对端口会累死。def verify_ports(generated_code, expected_ports): # 提取实际端口 actual_ports extract_ports(generated_code) # 对比 missing set(expected_ports) - set(actual_ports) unexpected set(actual_ports) - set(expected_ports) if missing or unexpected: return False, {missing: list(missing), unexpected: list(unexpected)} return True, {}5.3 仿真时序问题组合逻辑环路和初始态不确定分层生成出来的代码模块间通过端口连线功能逻辑上如果没错仿真一般能过。但如果模型在某个模块里写了不完整的组合逻辑导致某些路径没有驱动仿真时会出现X态传播。最常见的场景条件分支覆盖不全。比如always块里写了if但没有else当条件不满足时输出保持前值在多模块互联时这种“保持前值”的锁存器行为会让数据流出现意外的X态。这个问题在单模块生成中也有但多模块互联会放大它的影响因为X态会通过模块边界传播。排查方法就是加断言。我在复现时给每个模块的输出端口都加了一个简单的断言宏仿真时一旦某个模块的输出在有效时钟沿后还是X态立即报错并指出是哪个模块传出来的。这种“防火墙”式验证方式能大幅缩短多模块集成时的调试时间。5.4 参数化模块的处理位宽和参数传递错误这也是一个高发问题。模型生成参数化模块时比如parameter DW16在顶层例化时经常忘记传参数或者传的参数名称对不上。这类错误编译时不一定报错因为参数有默认值但仿真行为完全不对。我的做法是在依赖图中显式记录每个子模块的参数列表在生成调用端代码时把参数名和默认值作为约束的一部分注入提示词。这个额外信息能显著降低参数传递错误率。实测从大约25%的错误率降到了5%左右。interface_info { name: shift_reg, ports: { clk: input wire, rst_n: input wire, din: input wire [DW-1:0], dout: output wire [DW-1:0] }, params: { DW: 16, DEPTH: 8 } }5.5 热词场景实测SPI Slave和Cache控制器生成对比为了验证这套方法不是只对教学例程有效我专门试了几个真实场景。第一个是SPI Slave。用传统方法模型生成的是一个350行左右的单模块波特率发生器、移位逻辑、命令解析全在一起。用HiVeGen式分层生成模型生成了四个模块spi_clock_gen、spi_shift_reg、spi_cmd_decoder、spi_reg_file每个模块80到120行端口清晰可以直接复用。仿真波形检查MISO输出时序完全正确。第二个是Cache控制器。这个是硬骨头因为Cache控制器天然包含状态机、Tag比较、数据存储、替换策略多个子模块。传统方法生成的代码根本没法检查正确性——太长了而且信号命名一团乱麻。分层生成后我把cache_controller、tag_array、data_array、replace_engine分开验证分别写了测试向量最终拼起来跑通了一个简化版的两路组相联Cache。第三个是I2C读写EEPROM控制器。这个模型容易把字节状态机、位状态机、寄存器配置接口混在一起。分层生成后单独调试位状态机和字节状态机方便太多了。甚至最后我还把位状态机部分单独抽出来用在了另一个自定义协议的实现里这就是模块化真正的价值。6. 论文方法之外的思考这套思路还能用在什么场景6.1 不仅仅局限于VerilogHiVeGen的核心方法——依赖图规划、拓扑序生成、局部修复——本质上是一套“结构化生成”范式。它不限于Verilog对Chisel、MyHDL、甚至SystemVerilog的interface/class设计同样适用。我在测试中试着把这套流程用在SystemVerilog的interface定义上效果也很好模型生成的interface和modport连接一致性明显提升。如果你在日常工作中使用脚本生成RTL代码比如用Python生成参数化模块矩阵也可以把这套依赖图规划嵌入到脚本流程中让脚本负责搭结构、AI负责填模块内容。这样既有脚本的确定性又有AI的生成能力。6.2 和AI Agent结合的可能性现在很多AI Agent工具比如AutoGPT类的硬件设计助手在处理大任务时都会遇到“生成长代码容易跑偏”的问题。HiVeGen的依赖图规划思路可以直接复用到Agent的任务分解模块中。Agent不再是一次性执行一个大任务而是先规划子任务依赖再逐个执行最后集成验证。我在实验中也试过用LangChain配合这套规划逻辑让Agent自动生成-编译-修复-再编译虽然没有论文里那么系统但在简单设计上已经能实现“一键生成可综合的模块化RTL”。6.3 对提示词工程的启发如果你暂时不想上这么重的流程只想知道“怎么让AI写出模块化的Verilog”至少要学会一件事不要只告诉模型“请模块化”而是要给模型提供约束信息。这些信息包括接口定义、子模块划分建议、禁止跨模块引用的规则以及“先生成子模块再生成顶层”的顺序要求。这些约束比任何“高级提示词模板”都有用因为它们是在限制模型的搜索空间而不是指望模型突然学会结构化思维。我在调试中总结出的一个通用提示词结构如下【任务】生成一个{设计名称}必须按模块化方式组织。 【模块划分】请将设计拆分为以下子模块如果合理可以新增 1. {子模块1}职责{...}接口{...} 2. {子模块2}职责{...}接口{...} 【生成顺序】请先分别生成子模块代码最后生成顶层模块。不要在一个文件中输出全部代码。 【约束】禁止在顶层模块中直接引用子模块内部信号。 【输出格式】每个模块输出为独立的代码块注明模块名。这套提示词在Qwen2.5-Coder和DeepSeek-Coder上实测模块化正确率从25%提升到了60%左右。虽然不如HiVeGen完整流程的95%但对于不想搭复杂脚本的朋友来说已经是一个性价比很高的提升。7. 一些实操中的个人体会最后说几点我自己的感觉。第一AI生成RTL代码这件事最大的瓶颈不是模型能力而是我们如何约束模型的输出空间。单模块生成就像是让AI在无限大的画布上自由作画作品偶尔惊艳但不可控。HiVeGen式的分层生成相当于给了一块已经画好格子的画板AI只需要在每个格子里填内容质量自然可控得多。第二不要把依赖分析完全甩给AI。我早期完全让模型自己分析模块依赖结果它经常设计出不必要的耦合。后来改成先用简单的静态分析或者人工搭好模块框架再让AI填内容效果稳定得多。这不是偷懒而是承认模型的局限性——它擅长生成内容不擅长做架构决策至少在RTL领域目前还是这样。第三局部修复是真的好用。传统重新生成整个文件的迭代方式对编码类任务效率极低因为模型很难在保持其他部分不变的情况下修正局部问题。HiVeGen按模块定位错误、只重新生成出错模块的思路迭代效率至少提升了一倍。我自己现在写Verilog测试遇到编译错误也会下意识想“这个问题属于哪个模块边界之内”然后只重写那一块。第四别忘了验证。AI生成的代码无论多么模块化该写的testbench一点都不能省。我见过太多朋友拿到AI生成的代码就直奔综合结果功能完全不对浪费了好几天。模块化增加了可测试性但不会替代测试本身。如果你正在用AI辅助写RTL强烈建议试试先把模块划分做出来再让AI逐个实现。你会发现生成的代码不仅结构更清晰而且后续调试和复用的成本会低很多。这篇就写到这里希望能给你带来一些实用的启发。