AI 助我 FPGA 邪修之 PLL 篇

从语法、复位到示波器带宽：一次真实的 FPGA 入门排障记录

导语

一场借助 AI“邪修”FPGA 的 PLL 实验：从语法、复位到下载排查，最后才发现真正的瓶颈竟是示波器带宽。

开头摘要

在 AI 编程快速发展的今天，一些重复性强、边界清晰的初级研发工作正在被自动化工具逐步替代。那工程师是否还有必要学习新知识？我的答案是肯定的：越是在 AI 时代，越需要具备快速进入新领域、理解问题本质，并将新技能应用到实际项目中的能力。

我是一名从业多年的嵌入式软件工程师，长期从事 MCU/MPU 软件开发。此前也断续接触过 FPGA，但始终没有系统学习。最近公司的项目的核心算法逐渐转换为FPGA，为避免在AI时代被优化，增加自己的复合竞争力，我计划利用两个月时间完成 FPGA 基础知识和开发环境的搭建，掌握常用开发流程，达到能支持公司FPGA项目进行开发与调试水平。

这篇文章记录我的第一次 PLL 实验。它不是一篇完美的教程，而是一次真实的初学者排障过程：从基础语法、复位极性，到“程序下载后示波器测不到时钟”，最后才发现是测试仪器的带宽限制。

一、实验硬件与目标

本次使用的是从闲鱼购入的二手正点原子达芬奇 A7 开发板，核心器件为 Xilinx XC7A35T。虽然是二手板，但对于入门学习、熟悉 Vivado 和验证常用的功能已经足够。

实验目标很简单：使用 Vivado 的 Clocking Wizard（PLL/MMCM）IP，对开发板输入时钟进行处理，并从 FPGA 的两个引脚输出一对频率相同、相位相差 180° 的互补时钟信号。

听起来只是一个基础实验，实际调试下来却碰到了三个典型问题：

1. Verilog 基础语法问题；
2. 复位信号电平有效性问题；
3. 程序下载后，示波器测不到输出时钟。

二、第一关：基础语法问题，交给 AI 快速扫清

考虑到是在学习 FPGA，我没有让 AI 直接帮我生成代码，而是先参考正点原子的示例，再自己手动输入代码。每位有编程经验的人应该都知道：学习一门新语言时，手动输入代码难免出现各种错误，例如漏输或误输括号（如输入中文括号)，最终导致综合编译无法通过。当然，这类语法问题交给 AI，往往可以很快解决。

这正是 AI 时代赋予我们每个人的能力：不必在低级错误上耗费大量时间，而是把精力放在快速积累相关知识、将其应用到项目实战上。

这里我也想说说，为什么还要“古法编程”。在学习阶段，我认为手动输入代码有助于加深理解和记忆；但在实际项目开发中，纯手工输入代码效率较低，已经逐渐被更高效的开发方式取代。

三、第二关：复位电平不一致，仿真帮我定位问题

第二个问题来自复位信号。

我的顶层逻辑使用的是低电平有效复位，写法类似：

always @(posedge sys_clk or negedge sys_rst)begin    if (!sys_rst)        // 复位处理end

但 Clocking Wizard IP 的复位端配置为高电平有效。最初我直接把 sys_rst 接到了 PLL 的 reset 端，这就造成了一个隐藏矛盾：系统逻辑已经退出复位时，PLL 可能仍处在复位状态。

经过仿真检查后，问题被定位到复位极性。最终在 PLL IP 接口处进行取反：

.reset(~sys_rst)

这其实是一个低级问题。正点原子的示例代码本身是正确的，只是我手动输入时没有注意到它对复位信号做了取反处理（即低电平有效），从而写错并导致逻辑异常。通过这个问题，我也加深了对 Vivado 仿真功能的使用和理解。

四、第三关：程序下载成功，为什么示波器还是没有波形？

修正代码并生成 bitstream 后，我把程序下载到开发板，满怀期待地把示波器探头接到输出引脚。

结果是：没有波形。

第一次遇到这种情况，我首先怀疑下载是否有问题，于是重新下载了两次；依然没有。接着又怀疑代码逻辑有错误，便将自己的实现与正点原子的示例工程进行对照，同时让 AI 检查时钟连接、PLL 配置和输出逻辑。结果显示，从代码逻辑看没有明显问题。

这时我明显感受到 FPGA 与 MCU 调试方式的差异。

MCU 开发中，我们通常可以通过 J-Link、ST-Link 等调试器单步执行、查看变量和寄存器，很快判断程序究竟跑到了哪里。FPGA 下载的是已经综合、布局布线后的硬件电路，不存在像 MCU 那样的“单步运行 RTL”。虽然可以借助仿真、ILA 等工具观察内部信号，但它们与 MCU 单步调试不是同一种体验。

所以，当外部引脚没有波形时，不能只盯着示波器，也不能只在代码里反复猜。需要为“内部 PLL 到底有没有在工作”建立一个新的可观察证据。

五、借鉴 MCU 调试思路：用 LED 给 PLL 做一个心跳指示

在 MCU 开发中，遇到程序跑飞或外设不工作时，最常用的方法之一就是翻转一个 GPIO，或者点亮 LED，确认程序是否运行到指定位置。

我把这个思路迁移到了 FPGA：开发板本身带有 LED，那就让 LED 不再使用系统原始时钟，而是改由 PLL 输出的时钟驱动。

在 AI 的协助下，我修改了计数器和流水灯逻辑，让 LED 的计时基准来自 PLL 输出时钟：

输入时钟 → PLL IP → PLL 输出时钟 → LED 计数器 → 流水灯

如果流水灯能够按照预期节奏移动，至少可以说明 PLL 输出已经在驱动后级逻辑。

重新生成并下载后，LED 正常显示了。

这一步非常关键。它没有直接证明两个外部引脚上的高频时钟一定合格，却把“PLL 完全没有工作”这个猜测大幅排除了。对于初学者来说，这种把大问题拆成一个个可观察现象的方式，比一次性寻找最终答案更可靠；我的嵌入式 MCU 开发经验也算派上了用场。

六、真相出现：不是 FPGA 没输出，而是示波器带宽不够

LED 正常后，我再次测量输出引脚，示波器上依旧没有看到预期的高频波形。

这时 AI 给出的建议是：先把 PLL 输出频率降下来，用低频信号验证引脚、约束和测量链路是否正常。于是我把诊断输出降低到 1 kHz，再次生成并下载。

这一次，示波器终于测到了波形。

看到 1 kHz 波形后，我才反应过来：我手上的正点原子示波器带宽只有 10 MHz，而之前要测的时钟大约是 50 MHz。它并不是 FPGA 没有输出，而是测试仪器本身无法可靠地观察这个频率的信号。

至此，整个问题终于闭环：

代码语法 → AI 协助修正复位极性 → 仿真定位并修复外部无波形 → LED 验证 PLL 内部时钟降低到 1 kHz → 验证输出路径与测量链路回看仪器参数 → 发现 10 MHz 带宽无法测量约 50 MHz 时钟

七、这次实验带给我的几点收获

1. 让 AI 处理语法错误，加速学习进程

当我们学习一门新语言或新技能时，最怕在低级错误中耗费大量时间，导致学习计划失控，最后三天打鱼、两天晒网，消磨掉学习热情，无法达成最初的目标。这恰恰是 AI 现在能给每个人的帮助：它可以随时协助检查错误、解释概念和提供思路。

2. FPGA 调试更依赖“设计可观测性”

所有嵌入式软件开发都一样，建立可检测、可评估、可测试的系统，是解决很多问题的关键。MCU 可以单步和看寄存器；FPGA 更常见的思路是增加状态输出、LED 心跳、分频诊断信号，或者使用 ILA 抓取内部波形。设计时预留可观测点，会让后续调试轻松很多。

八、下一步计划

这次 PLL 实验只是 FPGA 学习的起点。接下来我会继续补齐 Verilog 基础、时钟与复位设计、仿真验证、时序约束和 ILA 在线调试等内容，并尽量把每一次学习都落在一个可运行、可测量的小实验上。

两个月的目标不是把所有 FPGA 知识都学完，而是通过常用 FPGA 示例的测试与验证（如串口、DA/AD 等），建立起从需求理解、RTL 编写、仿真验证、生成 bitstream 到板级调试的完整闭环，为达到项目级能力打好基础。

如果你也正从 MCU 转向 FPGA，不妨从一个小实验开始：先让一个 LED 按预期闪烁，再让一个低频测试信号被示波器稳定测到。正在学习 FPGA 的朋友，也欢迎在评论区沟通。