AI能写Verilog吗？FPGA开发者的真实测试

当所有人都在讨论AI写JavaScript、Python和Rust时，一个被忽视的问题浮出水面：大语言模型能理解硬件描述语言吗？Verilog中的并行执行、时序约束、FPGA厂商特有的原语——这些对LLM来说是否过于陌生？

一位同时从事全栈Web开发和FPGA/Verilog编程的开发者，在过去一个月里用Claude、GPT-4和Cursor在真实FPGA项目中进行了系统性测试。他的结论既令人振奋，也让人清醒。

为什么硬件描述语言对AI格外困难

作者坦言自己最初持怀疑态度。硬件描述语言与软件有着本质区别：

• 并行执行：所有逻辑同时发生，而非逐步执行
• 时序至关重要：一个在仿真中不可见的bug可能在100MHz下暴露
• 资源约束：FPGA的LUT、触发器和DSP块数量固定
• 工具链差异：Xilinx、Intel、Lattice各有各的怪癖

这些特性使得Verilog代码的正确性验证远比软件复杂——仿真通过不代表硬件能工作。

阻塞赋值与非阻塞赋值是Verilog中最容易出错的语法细节。阻塞赋值（=）在顺序块中按书写顺序立即执行，类似于软件中的变量赋值；非阻塞赋值（<=）则在时间步结束时统一更新，用于描述时序逻辑中的触发器行为。在always @(posedge clk)块中误用阻塞赋值，会导致仿真结果与综合后的硬件行为不一致——仿真可能通过，但综合工具会发出警告甚至产生错误的电路。这一区别源于Verilog同时承担仿真建模和硬件综合两种职责，是硬件描述语言区别于软件语言的典型特征。

建立时间违例是数字电路时序分析中的核心概念。建立时间（setup time）指触发器时钟边沿到来前，数据必须保持稳定的最短时间。当信号在组合逻辑中经过的路径延迟过长，数据到达触发器时晚于时钟边沿的建立窗口，就会产生建立时间违例。在100MHz时钟下，每个周期仅10纳秒，留给组合逻辑的延迟预算极为紧张。修复手段包括插入流水线寄存器（将长组合路径切分为多级）、逻辑重定时、使用专用硬件资源（如DSP块或块RAM）替代通用逻辑。这正是AI仅能给出通用建议、却无法替代工程师查看时序报告进行精确路径分析的原因。

亚稳态是跨时钟域设计中最危险的隐患之一。当异步信号进入当前时钟域时，若其跳变恰好发生在触发器的建立/保持窗口内，触发器输出可能在一段时间内处于既非0也非1的不确定状态，即亚稳态。这种状态会随机传播到下游逻辑，导致间歇性、难以复现的功能故障。标准解决方案是使用双触发器同步器（对异步输入连续打两拍），对于多比特信号则需采用握手协议或异步FIFO。亚稳态问题在仿真中通常不可见，因为仿真器不会模拟真实的时序违规，只有在硬件上以特定频率运行时才会暴露。

厂商特定原语是FPGA开发中不可回避的底层资源。Xilinx的DSP48E2、Intel的DSP Block、Lattice的sysDSP等均为各家特有的硬核计算单元，其原语名称、端口命名、参数配置和级联方式各不相同。例如DSP48E2具有预加法器、乘法器和累加器三段式结构，可通过INMODE、OPMODE、ALUMODE等参数精细控制。这些原语信息在公开代码库中相对稀少，且不同器件代际间差异显著，因此LLM往往生成看似合理但实际不存在的原语名称或错误的端口连接。

五项测试：从简单模块到厂商原语

测试一：基础模块——UART发送器

作者要求Claude编写一个115200波特率、8N1格式、50MHz时钟的UART发送器。结果令人满意：波特率生成器、移位寄存器、起始/停止位逻辑一应俱全，甚至额外添加了奇偶校验选项。波特率分频计算（50MHz/115200≈434）正确。

结论：UART、SPI、I2C、PWM等标准接口模块表现良好。

测试二：状态机——SPI主控制器

更复杂的测试：带可配置寄存器文件的SPI主控制器。AI正确实现了SPI模式0时序（CPOL=0, CPHA=0）、状态机和片选逻辑。但出现了一个经典错误——在时序块中使用阻塞赋值（=）而非非阻塞赋值（<=）。这种错误仿真可能不报，但综合工具会拒绝。

结论：结构良好，但需警惕微妙的Verilog语法陷阱。

测试三：时序约束——AI的盲区

当作者询问如何修复100MHz时钟下的建立时间违例时，AI给出了标准建议：添加流水线寄存器、重定时逻辑、使用RAM块、检查组合环路。建议本身没错，但过于通用——AI无法读取具体的时序报告来定位问题路径。

结论：理论建议尚可，但无法分析具体时序报告。

测试四：调试能力——简单有效，复杂有限

AI在秒级内发现了MOSI/MISO信号交换的明显bug。但当面对亚稳态问题时——作者忘记对异步输入进行双同步——AI只能给出方向性建议，无法精确定位，因为它看不到完整设计。

结论：擅长发现明显bug，对微妙的时序/亚稳态问题力不从心。

测试五：厂商特定知识——明显的短板

当要求使用Xilinx DSP48E2原语实现FIR滤波器时，AI使用了通用名称而非实际的Xilinx原语名称。这类厂商特定的原语名称、端口和参数，AI经常出错。

结论：通用逻辑尚可，厂商特定原语需要手动修正。

Testbench（测试平台） 是验证Verilog模块功能正确性的专用代码，它不参与综合，仅用于仿真环境。Testbench通过实例化待测模块（DUT），向其施加激励信号，并观察输出是否符合预期。典型结构包括：时钟生成、复位序列、激励向量驱动、输出监视与断言检查。相比RTL设计代码，Testbench更接近软件编程风格——大量使用initial块、task/function、文件读写和随机化约束，且不涉及可综合子集的限制。这恰好落在LLM的舒适区内：语法灵活、模式化强、无需考虑硬件资源。因此AI在生成Testbench时的准确率和实用性远高于生成RTL代码，成为FPGA开发者使用AI最令人惊喜的场景之一。

AI真正节省时间的地方

经过一个月的实践，作者总结了AI在FPGA开发中最有价值的四个场景：

1. 样板代码和常用接口：UART、SPI、I2C、PWM、I2S等标准模块，AI约90%的情况下能正确编写
2. 测试平台（Testbench）：这是AI表现最令人惊喜的领域——编写testbench的繁琐工作可以大幅自动化
3. 解释现有代码：将不熟悉的Verilog粘贴给Claude，它能快速逆向工程出代码功能
4. 调试明显bug：语法错误、端口方向错误、缺失endmodule等瞬间识别

AI仍然搞不定的领域

• 时序收敛：无法读取时序报告并精确定位关键路径
• 资源优化：无法实际运行综合工具查看真实资源占用
• 厂商工具链：Vivado、Quartus、iCEcube2的Tcl脚本和约束格式差异
• 微妙的硬件bug：亚稳态、竞争条件、毛刺——仿真不报但硬件致命

实际工作流：AI是副驾驶，不是飞行员

作者当前的工作流程体现了务实的人机分工：

1. 设计阶段：自己画框图，AI不做架构决策
2. 实现阶段：让AI写样板模块
3. 集成阶段：手动连接各模块
4. 测试平台：AI编写
5. 调试阶段：仿真失败时粘贴代码求助AI
6. 综合阶段：自己运行工具，AI不碰时序约束

这种分工的核心逻辑是：AI处理乏味的部分，人类处理架构和棘手问题。

FPGA开发者应该使用AI吗？

作者的答案是肯定的，但有重要前提。

把AI想象成一位初级工程师——它能针对定义明确的任务输出可运行的代码，但你仍然需要仔细审查。对于时序、资源和架构这些硬骨头，你依然是那个掌舵的人。

硬件设计太过微妙，与特定硬件的绑定太深，对实际测量的依赖太强，AI短期内不会取代FPGA工程师。但它确实能显著提升生产力——过去需要数小时编写的UART和SPI模块，现在几分钟就能完成。节省下来的时间可以投入到真正重要的事情上：架构设计、优化和测试。

如果你还没有在FPGA开发中使用AI，作者的观点很直接：你在从零编写UART和SPI模块上花费了太多时间。