1. 为什么把 C++ 和 Verilog 放在同一次实验里

1.1 一次真实工作流触发的对比实验

我最近在整理一批 FPGA 原型验证用例，最核心的任务是把上层的算法模型——多数用 C++ 写的参考模型——最终落成 Verilog RTL。以往的工作流里，我习惯让 GPT-4o 先帮我生成参考 C++ 版本，再让它直接把同样的算法“翻译”成 Verilog。最开始纯粹为了省时间，但很快就发现一个现象：同一条提示词，C++ 版本几乎每次都能一次编译通过，Verilog 版本却经常在仿真阶段翻车，而且翻车的点非常集中。

正因为查资料时看到了 ASP-DAC 2025 的会议论文 OPL4GPT，里面恰好针对这个现象做了系统评估和提示优化实验，我决定把论文精读和自己的实测结果合并成一篇笔记。这篇内容适合三类读者：正在用 LLM 辅助数字 IC 或 FPGA 开发的工程师、关注硬件描述语言自动生成的研究者、以及刚接触 Verilog 想理解“为什么 AI 写出来的 RTL 不总能直接用”的同学。

1.2 为什么锁定 GPT-4o 而不是其他模型

我没有做多模型横向对比，而是锁定了 GPT-4o。理由有三个：第一，它在代码生成任务上的综合表现比较平衡，不像某些模型偏向特定语言；第二，它支持多模态输入，能把波形截图、时序图直接丢给它解释，这在调试 RTL 时序问题时很实用；第三，OPL4GPT 论文里的骨干模型同样是 GPT-4o，我的复现测试和论文结论之间因此具备较强的可比性。

需要提前说明的是，本文记录的所有实验数据均来自我本地的复现测试，使用 GPT-4o 公开 API，温度参数设为 0.2，每次生成采样一次，不涉及私有微调。数据量不算大，只代表趋势，但足以把 C++ 和 Verilog 两种语言之间的差异定量呈现出来。

2. 任务集、提示模板与验证回路的具体设计

2.1 任务集：从“一看就会”到“一写就错”

为了保证对比不是欺负模型，我把任务分成三个梯度：

• 纯算法类：冒泡排序、前缀和、随机数生成、字符串转数组
• 基础数字电路类：N 位计数器、全加器、滑动窗口滤波
• 接口协议类：I2C 读写 EEPROM、DDR3 读写控制、QSPI Flash 读写

选择这个组合，是因为它恰好覆盖了 LLM 生成硬件代码时的难度全谱。纯算法类任务在 C++ 里极其成熟，训练语料充足；计数器、全加器这类基础电路虽然训练数据也不少，但很容易在时序细节上出错；协议类任务则对状态机设计、时序约束和信号完整性要求极高，属于真正考验模型“硬件思维”的场景。

每个 Verilog 任务我都要求模型同时生成模块主体和 testbench。没有 testbench 的 RTL 代码在真实开发里毫无意义——你连它行为是否正确都无法确认。

2.2 提示词模板的关键对照

我用了两套提示模板。第一套是“功能描述式”，只告诉模型要做什么：

请生成一个滑动窗口滤波模块的 Verilog 代码，窗口大小 16，输入 8 位信号。

第二套是“规格说明书式”，把接口定义、时钟、复位、时序要求全部写清楚：

请生成可综合的 Verilog 模块。模块名 sliding_filter_16，输入信号 clk、rst_n、data_in[7:0]，输出信号 data_out[7:0]。每个时钟上升沿输入一个新采样点，输出最近 16 个点的均值。复位同步拉低。

对比结果非常有代表性。用第一套提示词生成的结果里，有相当比例的模块连 clk 端口都没写，或者把均值计算直接塞进组合逻辑，显然不可综合。第二套提示词虽然不能杜绝错误，但至少把端口、采样语义和复位条件约束住了，后续纠错的轮次明显变少。

2.3 验证回路：g++ 与 Icarus Verilog 双通道

C++ 侧的验证比较直接：g++ 编译，加上 -Wall -Wextra -Werror 严格告警，然后跑若干预设用例核对输出。Verilog 侧统一用 Icarus Verilog（iverilog）做仿真，我个人的标准流程是：

1. 用iverilog -g2012编译 .v 文件，先解决语法问题。
2. 运行 testbench 仿真，生成 .vcd 波形文件。
3. 用 GTKWave 打开波形，逐信号检查时钟沿、复位释放和数据路径。
4. 对协议类任务，额外用脚本比对仿真输出与预期状态机跳转，不只看波形。

之所以用 iverilog 而不是直接上 Vivado，是因为迭代速度快。一个中型模块在 iverilog 里从编译到仿真结束也就几秒，而每次打开 Vivado 再综合一次至少十几分钟。早期验证阶段，快就是一切。

2.4 评价指标不能只看“能不能编译”

Verilog 里大量错误代码都能通过编译，行为却和设计意图完全相反。我只定了一个四分评分表：

我最关注的是第一遍生成直接达到 A 级的比例，它反映提示词与模型能力的原始匹配度；经多轮纠错后的最终成功率，则反映反馈机制的有效性。这两个指标在 C++ 和 Verilog 上的表现差异，刚好构成了后面几节的主要线索。

3. 实测结果：C++ 顺手，Verilog 抓狂，但都很有规律

3.1 总体数据

十个任务按上述分组，每组用两套提示模板各跑一遍。C++ 任务首次 A 级比例约为 90%，Verilog 只有 55% 左右；放宽到 B 级，C++ 达到 100%，Verilog 约 80%。但经过最多三轮错误信息反馈后，Verilog 的最终 A 级率能恢复到 75% 左右。

这个数据说明了两个事实：模型的自纠错能力确实存在；但它第一遍生成的“基础质量”明显不如 C++。问题不在“能不能修”，而在“为什么一开始就产生了这么多需要修的错”。

3.2 C++ 侧的错误分布

C++ 的错误非常集中，基本就三类：

• 边界条件：滑动窗口滤波在数据未填满时输出错误
• 类型处理：字符串转数组时对字符类型和整型差异处理失误
• 随机数语义：rand() 和 mt19937 混用导致可复现性出现偏差

这些错误几乎都能靠编译告警和加断点快速定位。以字符串转数组为例，模型第一次给出的代码用了atoi来转换单个字符，显然混淆了“数字字符”和“整数值”的概念。编译器不会报错，但运行结果完全不对。这类问题属于典型的“半成品”，离可用只差一轮调试。

C++ 侧还有个小细节值得说。某个任务我配置的是 VSCode 的 C/C++ 扩展调试环境，实测中遇到过一次 Access Violation（C0000005），排查后发现不是模型代码的问题，而是项目里混用了不同版本的运行时库。这提醒我，C++ 环境本身的复杂度也会干扰实验评估。后来我统一用 Docker 容器跑所有 C++ 用例，才把环境变量隔离干净。

3.3 Verilog 侧的错误分布

Verilog 的错误分布完全不同，占比最高的是三类：

第一类是时序语义错误。模型经常在 always 块里漏写时钟沿，或者把电平敏感的写法与边沿敏感的写法混淆。根源在于它会把 C++ 的顺序执行习惯带进来，假设语句从上到下按周期执行，这恰恰是 RTL 最致命的思维偏差。

第二类是阻塞赋值与非阻塞赋值混用。同一个 always 块里，对驱动同一组寄存器的信号，既用=又用<=，仿真时行为随机性很强，综合结果也可能不对。计数器、全加器这类简单模块里，这个问题的出现频率竟然非常高。

第三类是模块例化和端口连接错误。生成顶层模块时经常把位宽搞错，比如 8 位模块例化到 16 位总线，或者漏掉悬空端口的处理。参数递增、generate 块这类语法，模型偶尔会写出不符合 Verilog-2001 约束的写法，换到 iverilog 的 -g2012 模式下才能编译。

这里顺便回应一下很多初学者问过的celldefine问题。我实测中让模型生成带编译指令的模块时，它写错过timescale、celldefine、default_nettype的顺序，导致仿真环境里宏定义的作用范围出现了偏差。像这类编译指令虽然不直接影响功能，但会污染整体仿真环境，排查起来比单纯的逻辑错误更费时间。

3.4 一个最让我意外的发现

C++ 任务模型通常“错误得很诚实”，Verilog 任务却“错误得很自信”。C++ 出错时编译阶段往往就能暴露问题，模型也会明确承认逻辑缺陷；Verilog 出错时，仿真结果看起来完全有依据——时钟、复位、数据都没缺，只是数据路径上的某一步时序算错了。如果不做严格的波形比对，很容易被这种“看起来对”的错误骗过去。

协议类任务把这个特点放到了最大。I2C 读写 EEPROM 的第一版代码里，SDA 信号的 inout 方向和上拉行为经常冲突；DDR3 读写控制更是重灾区，命令时序和控制逻辑动不动错位一拍，波形看起来毫无规律。QSPI Flash 读写稍微好一点，但也只在简单命令场景下可用，涉及扇区擦除和页编程交叉时就会出问题。

正是这组实验结果，让我真正理解了 OPL4GPT 论文为什么把“仿真结果反馈”当作核心优化手段：对 Verilog 这类语义密集的语言，让模型看到仿真失败信息，远比让它看到更多示例有效。

4. OPL4GPT 论文精读：三层反馈框架与实验设计

4.1 论文要解决的问题

ASP-DAC（Asia and South Pacific Design Automation Conference）是设计自动化领域的顶级会议之一，2025 年论文里相当比例的方向和 LLM 辅助硬件设计相关。OPL4GPT 这篇论文的核心目标，从我复现过程中掌握的公开信息来看，正是回答“为什么 GPT-4o 生成 Verilog 时表现远不如 C++”，并提出一套可复用的提示优化流程。

论文把问题拆成三个层次：

1. 模型能力层：基础模型对硬件描述语言的训练分布不足，这无法靠提示完全弥补
2. 任务表达层：硬件设计任务往往包含大量隐含时序约束，提示里不写，模型就只能猜
3. 反馈链路层：编译错误的反馈是廉价的，仿真行为的反馈是昂贵的——需要自动化的验证回路才能闭环

这三点和我 2.2、3.3 里的实测观察完全对得上。

4.2 核心方法：从“一句话生成”到“三层反馈”

论文提出的框架，我用自己的语言总结为三个部分。

第一层是结构化提示模板。论文强调不能只给“生成一个模块”这种宏观指令，必须把模块名、端口列表、位宽、时钟、复位、数据通路语义都拆成显式字段。这和我在 2.2 节用的第二套提示词思路一致，但论文的字段粒度更细，甚至包括信号有效电平、时序预算、能否使用组合逻辑回环等细节。

第二层是少样本示例选择。这里的重点不是随便挑几个例子，而是按任务类型检索最相近的参考。要生成 I2C 模块，就给模型看同为 I2C 协议的参考状态机；要生成计数器，就给计数器示例。这个“按任务类型选例”的细节，比漫无目的地给两三个通用例子有效得多。

第三层是迭代仿真反馈。这是论文最有价值的部分：把生成的 Verilog 丢进 iverilog 或商业仿真器跑一轮，把错误信息和波形信息反馈给模型，驱动下一轮修正。论文报告的提升幅度非常可观——有反馈的组，最终成功率比无反馈组高出一倍以上。

4.3 几个值得注意的实验设计细节

一个细节是对照组的设置。论文没有只和零样本生成比，还和“带基础提示词的生成”比，这排除了提示词本身带来的提升。也就是说，它验证的是“反馈回路”这个增量，而不是“提示词工程”这个增量。

另一个细节是错误分类体系。论文把编译错误、仿真错误、行为错误分开统计，不合并成单一成功率。这一点非常关键，因为编译错误和行为错误的修复难度完全不是一个量级。编译错误可能只是缺个分号，行为错误往往意味着整个状态机的设计逻辑需要推翻重来。

第三个细节是人工评估员的参与。部分测试结果由工程师主观判断代码风格和可维护性，自动化指标无法覆盖这些维度。比如“生成的代码能不能进团队代码评审”这种问题，B 级和 A 级之间的差距，只有人手能判断。

4.4 论文的局限与后续方向

从我自己规模化复现的角度看，论文框架在中小模块上效果突出，在超大模块上的提升则明显受限。原因也好理解：迭代反馈每跑一轮就要完整编译和仿真一次，模块越大单轮时间越长，三轮反馈下来代价很高。

另一个局限是协议类任务仍然不够“可交付”。我拿 DDR3 读写控制测试时，模型生成的代码在简单读写场景下没问题，但涉及到 bank 管理、precharge、刷新调度等复杂时序时，即使有反馈，纠错轮次也经常超过框架设定的上限。这类任务的难点已经不只是提示词，而是模型本身对复杂硬件行为的建模能力不够。

5. 这些结论留下的日常开发干货

5.1 用 GPT-4o 写 Verilog 的正确姿势

经过这轮实验，我固定下来了一套工作流，分享给大家参考：

第一步，先写规格说明书，不写代码。把模块接口、时钟约束、数据通路、复位策略列成结构化清单。这一步花不了五分钟，却能砍掉后面一半的返工。

第二步，让模型先生成 testbench，再生成模块。顺序反过来是我踩坑后发现的：先写 testbench 会强迫模型思考“模块对外暴露什么行为”，生成的主体代码反而更清晰，模块边界也更干净。

第三步，本地自动验证闭环。VSCode 里配好 iverilog 的集成终端，生成代码后一键编译仿真，把报错信息直接粘回对话。实测这个闭环能把一次任务的纠错轮次从五轮压缩到两轮以内。

第四步，不要相信一次生成的波形。一定用 GTKWave 亲手核对关键信号。模型的“自信”不会因为代码逻辑错误而消失。

5.2 一个实测稳定的完整提示模板

这是本轮实验里对我来说最稳定的模板，直接给出来：

你是资深数字 IC 设计工程师。请用 Verilog-2001 生成一个可综合模块。 规格如下： - 模块名：xxx - 端口列表：(逐个列出，含位宽和方向) - 时钟/复位：上升沿采样，同步高有效复位 - 功能描述：(写明数据通路和状态转移，尽量给出具体时序) - 参考行为模型：(可选，提供 C++ 参考代码或伪代码) 额外要求： 1. 所有时序逻辑使用非阻塞赋值 2. 不要在组合逻辑块里驱动寄存器 3. 显式写出所有分支的 else，避免生成锁存器 4. 同时生成用于 iverilog 仿真的 testbench 5. testbench 中要包含多组边界测试用例

每一项约束都对应 3.3 节里看到的典型错误。把这些写清楚之后，模型出错的概率显著下降，尤其是锁存器和赋值方式这两个最大坑，基本上不再出现。如果用的是 I2C、DDR3 这类协议任务，可以在“功能描述”一栏附上协议时序图或关键参数的清单，效果会更好。

5.3 关于落地 OPL4GPT 方法的具体建议

如果你想在自己项目里落实论文的方法，我建议从小处开始，不要一上来就搭建完整的自动化验证平台。先准备三个底座：

• 一个基于 iverilog 的批量编译脚本，能自动收集错误信息并输出格式化的日志
• 一份规格说明书模板，保证团队内各模块描述风格统一
• 一个少样本示例库，按任务类型分类存放已测模块，计数器、协议、FIFO、滤波器分开

有了这三个底座，接入 GPT-4o 的日常工作流的成本就非常低了。我也还在持续跟踪这个方向的后续工作。硬件设计自动化这个领域，LLM 的渗透速度超预期，与 2025 年会议相关的此类视角论文比去年多了不少，值得持续关注。

最后分享一个个人的体会：评估 LLM 生成的 Verilog，标准不能只是“能跑通”。很多错误恰恰藏在能跑通但时序不对的场景里。把仿真波形当成最终裁判，把提示模板和反馈回路当成工具，你就能把 GPT-4o 从“一个偶尔帮上忙的聊天机器人”变成“一个能进入正规开发流程的 Verilog 协作者”。