FPGA开发板上运行时序逻辑电路设计实验完整示例-程序员充电站

FPGA交通灯控制器实战：从状态机建模到板级稳定运行的全链路拆解

你有没有遇到过这样的情况：仿真波形完美，综合报告无误，烧录进Basys 3开发板后——灯乱闪、状态跳变、按键失灵？不是代码写错了，也不是板子坏了，而是数字电路设计里最隐蔽也最关键的敌人悄然上线：时序。

在Xilinx Artix-7这类中端FPGA上做教学实验，我们常误以为“能综合、能仿真、能点亮LED”就等于成功。但真实硬件不讲情面：它只认建立时间（Setup Time）、保持时间（Hold Time）、时钟偏斜（Clock Skew）和亚稳态窗口（Metastability Window）。一个没约束的rst_n信号，可能让整个状态机在上电瞬间进入不可预测的中间态；一个没同步的按键输入，会在某次按下时让红灯突然变绿；一段没加unique case的FSM逻辑，可能被综合器悄悄推断出锁存器——而你在波形里根本看不到。

这不是玄学，是物理世界的铁律。下面，我们就以一个看似简单的交通灯控制器为切口，带你走完一条真正“能落地、可复现、经得起量产拷问”的FPGA时序逻辑设计路径。

状态机不是画个图就完事：Moore型三段式为何是工业级起点？

很多初学者一上来就用一段式或两段式写FSM，理由很实在：“代码短、好理解”。但当你把设计规模扩大到10+状态、多输入条件、带优先级响应时，问题立刻浮现：仿真和实测不一致、资源占用异常高、时序收敛困难——根源往往藏在编码风格里。

Moore型三段式不是教条，而是对硬件本质的尊重：

输出只依赖当前状态→ 消除输入毛刺对输出的直接影响；
状态更新、次态计算、输出译码严格分离→ 综合工具能清晰识别reg-to-reg、combo-to-reg路径，STA才能给出可信报告；
每个always块职责单一→ 调试时你能一眼锁定：是状态没更新？还是次态算错了？或是输出译码漏了分支？

再看这段交通灯FSM的核心代码：

typedef enum logic [1:0] { RED = 2'b00, YELLOW= 2'b01, GREEN = 2'b10 } state_t; state_t curr_state, next_state; logic timer_en; // 关键！所有状态跳变必须受此使能控制 // 1. 状态寄存器更新（纯时序） always_ff @(posedge clk or negedge rst_n) begin if (!rst_n) curr_state <= RED; else curr_state <= next_state; end // 2. 次态逻辑（纯组合，无时序依赖） always_comb begin case (curr_state) RED: next_state = ped_req ? YELLOW : GREEN; YELLOW: next_state = GREEN; GREEN: next_state = ped_req ? RED : YELLOW; default: next_state = RED; endcase end // 3. 输出逻辑（纯组合，状态到输出单向映射） always_comb begin unique case (curr_state) RED: begin light_ns = RED; light_ew = GREEN; end YELLOW: begin light_ns = YELLOW; light_ew = YELLOW; end GREEN: begin light_ns = GREEN; light_ew = RED; end default: begin light_ns = RED; light_ew = GREEN; end endcase end

注意三个细节：

unique case不是可选项——它强制编译器检查全状态覆盖与无重叠，防止综合出意外锁存器。Vivado会直接报错：“case item not covered”，逼你补全逻辑，而不是默默给你埋雷。
timer_en不是可有可无的信号。它来自分频模块，本质是状态驻留的计时开关。没有它，FSM会在每个100 MHz时钟沿都尝试跳转，导致状态在RED→GREEN→YELLOW→RED之间疯狂振荡。加上它，状态切换被严格锚定在2 Hz的分频边沿上，物理意义清晰，时序路径可控。
所有状态赋值都用<=而非=，所有组合逻辑都用always_comb而非always @(*)。这是Verilog 2001之后的现代写法，让工具明确知道你的意图：前者是触发器行为，后者是纯组合逻辑，避免隐式锁存器推断。

坦率说，这个FSM本身不复杂，但它的结构决定了你后续能否安全地加入行人请求中断、夜间模式切换、故障自检等扩展功能。好的状态机设计，是给未来留出确定性，而不是给自己挖坑。

分频不是“除个数”那么简单：跨时钟域处理才是生死线

Basys 3的100 MHz主晶振是个“暴力时钟”——它快得足以让任何慢速外设（比如人眼能分辨的LED变化）变成模糊残影。你想让红灯亮30秒？直接用100 MHz计数器数30亿次？先不说32位计数器吃掉多少LUT，单是计数器输出cnt == 30_000_000_000这个比较逻辑，就会因组合延迟过大而无法满足建立时间。

所以必须分频。但分频不是简单地“降速”，而是构建一个可靠的时间基准源，并确保它能被下游模块安全采样。

我们用的是整数分频器，参数化设计：

module clk_divider #( parameter DIV_CNT = 50_000_000 // 100MHz → 2Hz ) ( input logic clk_in, input logic rst_n, output logic clk_out ); logic [31:0] cnt; logic clk_div_tmp; always_ff @(posedge clk_in or negedge rst_n) begin if (!rst_n) begin cnt <= 0; clk_div_tmp <= 0; end else begin if (cnt == DIV_CNT-1) begin cnt <= 0; clk_div_tmp <= ~clk_div_tmp; // 翻转实现分频 end else begin cnt <= cnt + 1; end end end // 双触发器同步链：这才是重点！ logic clk_sync1, clk_sync2; always_ff @(posedge clk_in or negedge rst_n) begin if (!rst_n) begin clk_sync1 <= 0; clk_sync2 <= 0; end else begin clk_sync1 <= clk_div_tmp; clk_sync2 <= clk_sync1; end end assign clk_out = clk_sync2;

关键不在DIV_CNT，而在最后四行。

clk_div_tmp是计数器内部生成的2 Hz信号，但它诞生于100 MHz时钟域。当你要把它送给FSM模块作为timer_en使用时，FSM的clk仍是100 MHz——这意味着clk_div_tmp对你来说是一个异步信号。如果不加处理直接连过去，只要clk_div_tmp翻转时刻恰好落在100 MHz时钟的建立/保持窗口内，第一级触发器就可能进入亚稳态，第二级也可能跟着失效，最终导致FSM在某个周期收到一个既不是0也不是1的“中间态”，状态迁移彻底失控。

双触发器同步链（Synchronizer Chain）就是专治这个病的良方。它不能100%消除亚稳态，但能把平均故障间隔（MTBF）提升到远超系统寿命的程度。这是FPGA设计里唯一被工业界广泛接受的跨时钟域信号传递方案。

顺便提一句：为什么不用PLL？因为教学实验追求的是“原理可见、路径可控”。PLL是黑盒，你调个参数它就给你一个新时钟，但你不知道相位噪声、抖动、锁定时间这些底层指标。而手动分频，每一步延时、每一级寄存器行为都暴露在你眼前——这才是学习的本质。

XDC约束不是“补作业”：它是你和FPGA之间的正式契约

很多人把XDC文件当成“最后补的作业”：仿真过了，综合过了，布局布线快完成了，才想起去查Basys 3引脚文档，随便填几个set_property PACKAGE_PIN ...。结果呢？板子上灯不亮、按键没反应、或者更糟——大部分时候正常，偶尔死机。

XDC不是附加说明，它是你向Vivado发出的法律声明：“我要求这个设计必须满足以下物理条件，否则请拒绝实现。”

一份合格的交通灯XDC至少包含三类约束：

1. 主时钟定义（不可省略）

create_clock -period 10.000 -name sys_clk [get_ports clk] set_property CLOCK_DEDICATED_ROUTE TRUE [get_nets clk]

-period 10.000告诉工具：这条路径上，数据必须在10 ns内从一个触发器到达下一个。CLOCK_DEDICATED_ROUTE TRUE强制使用全局时钟网络（BUFG），保证时钟偏斜最小。如果这里写错成8.000（对应125 MHz），整个STA报告就失去参考价值。

2. 输入延迟约束（针对机械按键）

# Basys 3按键是低电平有效，需消抖，但STA仍要预留余量 set_input_delay -max 8.0 [get_ports btn] -clock [get_clocks sys_clk] set_input_delay -min 0.5 [get_ports btn] -clock [get_clocks sys_clk]

机械按键抖动典型值为5–20 ms，但FPGA看到的是GPIO引脚上的电平跳变。set_input_delay -max 8.0的意思是：“请假设这个信号最晚会在时钟上升沿前8 ns到达”，这样工具会在布局布线时，特意把按键输入路径布得更短，确保即使抖动最严重时，也能满足建立时间。

3. 复位路径处理（最容易被忽视）

# 同步复位，但复位释放时刻仍可能与时钟边沿冲突 set_false_path -from [get_ports rst_n] -to [get_clocks sys_clk] set_false_path -from [get_clocks sys_clk] -to [get_ports rst_n]

set_false_path不是“忽略时序”，而是告诉工具：“这条路径我不需要你分析建立/保持时间，因为它本就不该有时序要求”。因为复位信号是全局异步的，你无法保证它何时释放。与其让它在STA报告里狂报违例，不如明确声明——这是设计意图的一部分。

一个经验法则：如果你的XDC文件少于15行，它大概率不合格；如果你的STA报告里WNS（Worst Negative Slack）是负数，哪怕只有-0.01 ns，这个设计在真实硬件上就存在失败风险。Vivado不会骗你，它只是如实反映物理极限。

板级调试不是“碰运气”：从现象反推时序根因的三步法

当你的交通灯在Basys 3上表现异常时，别急着改代码。先问自己三个问题：

1. 它是“完全不动”，还是“规律性错乱”？

如果所有LED全灭或常亮：检查rst_n是否被正确拉高（用万用表测FPGA引脚电压），确认XDC中rst_n引脚绑定无误；
如果状态按固定节奏乱跳（比如红→绿→红→绿循环）：大概率是timer_en没起作用，检查分频器输出是否真的连到了FSM，用Vivado的ILA核抓取clk_divider.clk_out信号验证；
如果仅在特定按键操作后出错：立即检查按键输入是否经过同步处理，以及XDC中是否添加了set_input_delay。

2. 你能观测到哪些信号？

别只盯着light_ns和light_ew。在顶层模块加一个debug_bus：

output logic [3:0] debug_bus; assign debug_bus = {2'b00, curr_state}; // 高2位空置，低2位送当前状态

然后在XDC里绑定到4个LED上。这样你不用逻辑分析仪，就能肉眼看到状态机是否卡死、是否在两个状态间反复横跳——这是定位FSM问题最快速的方式。

3. 违例路径在哪里？

打开Vivado的“Report Timing Summary”，重点看：
-WNS（Worst Negative Slack）：负值越大，风险越高；
-TNS（Total Negative Slack）：所有违例路径的slack总和，反映整体健康度；
- 点开最差路径（Worst Path），看它经过哪些单元：如果是btn → ff → next_state，那问题就在按键同步；如果是cnt_reg[31] → next_state，那就是分频计数器输出路径太长，需要加流水线或换算法。

真正的工程能力，不在于写出“能跑”的代码，而在于建立一套从现象→信号→时序路径→物理约束的闭环排查思维。这比背一百个Verilog语法重要得多。