企业官网建设流程全解析

1. 项目概述：用FPGA实现“过河”逻辑游戏，状态机是灵魂

你有没有试过在一块FPGA开发板上，不接任何外部传感器、不跑Linux、不连串口调试器，只靠几个按键和LED，就能把“狼、羊、菜、人”四者安全运过河？这不是教学演示，而是EDA课程里最经典、最硬核的入门实战——“过河”数字游戏。它表面是个逻辑谜题，内核却是一套完整、可验证、可扩展的状态驱动系统。我带过六届数字电路设计实训，每年都有学生卡在“为什么仿真波形对不上”“为什么按键一按就乱跳状态”“为什么LED显示和预期完全相反”这些细节上。其实问题从来不在Verilog语法，而在于对状态机本质的理解偏差：状态不是代码里的枚举值，而是硬件中真实存在的寄存器组；转移不是if-else的顺序执行，而是时钟边沿触发的同步跃迁；输出不是组合逻辑的即时响应，而是受控于当前状态与输入的确定映射。这个项目用Quartus II完成综合与下载，目标芯片是Cyclone IV系列（比如AC620或EGO1），所有逻辑全部用Verilog HDL手写，不调用IP核，不依赖任何第三方库。它适合刚学完组合/时序逻辑、正准备接触FPGA开发的新手，也适合想夯实状态机设计功底的中级工程师——因为“过河”规则清晰、边界明确、状态有限，但恰恰在这种“简单”里，藏着数字系统设计最底层的严谨性。你不需要懂无线通信、图像处理或PCIe高速接口，只需要理解“人必须在场才能划船”“狼不能单独和羊在一起”“羊不能单独和菜在一起”这三条铁律，就能构建出一个真正能跑在硅片上的决策引擎。

2. 整体架构设计与状态机选型逻辑

2.1 为什么必须用状态机，而不是纯组合逻辑？

先说结论：纯组合逻辑根本无法实现“过河”游戏。有人会问，不就是四个变量的真值表吗？列出来不就行了？错。这里存在两个致命陷阱：一是隐含时序依赖，二是状态持久性缺失。举个例子：假设当前状态是“人在左岸，狼羊菜全在左岸”，你按下“人带羊过河”按键，系统必须记住“人已到右岸，羊已到右岸，狼菜仍在左岸”这个中间结果，并等待下一次有效输入。如果用纯组合逻辑，每次按键都会重新计算输出，但没有寄存器保存“当前两岸分布”，下一次按键时，系统根本不知道上一步发生了什么——它就像一个失忆的裁判，永远在初始状态打分。而状态机的核心价值，正在于用一组时序寄存器（state register）显式地、稳定地存储系统当前所处的唯一状态。这个状态在每个时钟上升沿被更新，不受按键抖动、信号传播延迟等瞬态干扰影响，保证了系统行为的可预测性和可重现性。

2.2 三段式状态机：为什么它是工业级首选？

网络上关于状态机的讨论很多，有两段式、一段式、Moore型、Mealy型……但在FPGA工程实践中，三段式状态机是绝对主流，原因非常实际：它把“状态转移逻辑”“状态寄存器更新”“输出逻辑”彻底解耦，让综合工具能生成最干净、最易时序收敛的电路。我们来拆解它的三层结构：

• 第一段（同步时序逻辑）：只做一件事——在时钟上升沿，把next_state的值锁存进current_state寄存器。这是整个系统的“记忆中枢”，所有状态变迁都发生在这里。
• 第二段（组合逻辑）：根据current_state和所有输入（按键、复位），计算出next_state。这部分纯粹是逻辑运算，不涉及时序，综合后就是一堆查找表（LUT）和多路选择器（MUX）。
• 第三段（输出逻辑）：根据current_state（有时也结合输入），生成所有对外输出（LED显示、蜂鸣器、数码管段码）。这部分决定了用户看到什么，是人机交互的最终出口。

这种分离带来的好处是立竿见影的：当你修改输出逻辑（比如想让LED闪烁频率变慢），只会影响第三段，前两段的时序路径完全不受影响；当你优化状态转移条件（比如增加一个防误触的使能信号），只改第二段，寄存器部分纹丝不动。我在嘉立创EDA画PCB时，曾为一个FPGA项目反复迭代状态机，三段式结构让我能在三天内完成五次重大逻辑变更，而时序报告始终稳定在-0.8ns裕量。反观两段式，把状态更新和输出混在一起，一次小修改可能引发全局时序重跑，耽误整整一天。

2.3 状态编码策略：独热码 vs 二进制码，怎么选？

状态编码不是随便写个localparam S0=2'b00, S1=2'b01...就完事。它直接关系到资源占用和关键路径延迟。我们以“过河”为例，总共需要多少个状态？不是简单的4! = 24种排列，因为“人必须在船边”“两岸不能出现非法组合”这些约束会大幅削减合法状态数。经过穷举验证，合法状态共16个（例如：S0=人左狼左羊左菜左，S1=人右狼左羊左菜左，S2=人右狼右羊左菜左……直到S15=人右狼右羊右菜右）。面对16个状态，两种主流编码方式对比鲜明：

• 二进制编码（Binary Encoding）：用4位二进制数表示16个状态（0000~1111）。优势是节省触发器资源——16个状态只需4个FF。劣势是状态跳转时，多位可能同时翻转（如从7=0111跳到8=1000），产生毛刺，且关键路径上异或门数量多，时序压力大。
• 独热码（One-Hot Encoding）：每个状态用一个独立的触发器表示，16个状态就需要16个FF。看起来很“奢侈”，但在现代FPGA（如Cyclone IV）上，触发器资源极其丰富，而LUT资源相对紧张。独热码的最大优势是：状态转移时，永远只有1位从0变1、另1位从1变0，其余位保持不变。这意味着：
  • 关键路径上只需2个2选1MUX（选哪个位变高、哪个位变低），延迟极小；
  • 组合逻辑简单，几乎全是与门和或门，综合后面积小；
  • 调试时，用SignalTap抓取16根线，哪根高电平亮，当前状态一目了然，比看4位二进制码直观十倍。

我实测过：在AC620开发板上，用独热码实现16状态机，最大工作频率可达128MHz；而用二进制码，同样逻辑，最高只能跑到92MHz。对于“过河”这种对实时性要求不高的游戏，二进制码省下的12个FF意义不大，但独热码带来的时序余量和调试便利性，却是实实在在的生产力。所以我的建议很明确：只要FPGA资源允许（现代入门级芯片都允许），无脑选独热码。

2.4 系统顶层模块划分：解耦是可靠性的基石

一个健壮的FPGA设计，绝不能把所有逻辑塞进一个大模块里。我习惯将“过河”系统拆成四个核心子模块，通过清晰的端口互联：

• top_level.v（顶层）：只负责引脚约束、时钟分频、模块实例化。它像一张总线图，定义了谁连谁、数据怎么走，但不参与任何业务逻辑。
• key_debounce.v（按键消抖）：物理按键按下时会产生数十毫秒的机械抖动，直接采样会导致状态机误触发。这个模块用计数器实现硬件消抖，输出干净的key_valid脉冲信号，确保每次按键只被状态机响应一次。
• game_fsm.v（主状态机）：承载全部游戏规则的核心。它接收消抖后的按键信号，根据当前状态和规则，计算下一状态，并生成LED显示编码。
• led_display.v（LED驱动）：将状态机输出的4位编码，转换成8个LED的点亮模式（例如：用不同颜色LED代表人、狼、羊、菜的位置）。它还集成了简单的呼吸灯效果，让界面更友好。

这种划分的好处是：你可以单独仿真game_fsm.v，用Testbench给它喂任意状态和按键，验证规则是否100%正确；也可以单独测试key_debounce.v，用ModelSim看波形确认消抖时间是否足够；甚至可以先不接FPGA，用面包板搭个LED电路，只验证led_display.v的输出是否符合预期。模块化不是为了炫技，而是为了把“哪里错了”这个问题，从“整个系统崩了”缩小到“是消抖没做好，还是状态转移写错了”。

3. 核心细节解析与实操要点

3.1 “过河”状态空间的数学建模与合法性验证

很多人以为状态机设计就是拍脑袋列状态，这是最大的误区。“过河”的16个合法状态，是严格数学推导的结果，不是凭感觉写的。我们建立一个四元组模型：(P, W, G, C)，其中P=人位置（0=左，1=右），W=狼位置，G=羊位置，C=菜位置。初始状态是(0,0,0,0)，目标状态是(1,1,1,1)。但并非所有16种组合都合法，必须满足两条生存法则：

1. 人不在场时，狼与羊不能同侧：即当P≠W且P≠G时，W必须等于G（否则狼吃羊）；
2. 人不在场时，羊与菜不能同侧：即当P≠G且P≠C时，G必须等于C（否则羊吃菜）。

用布尔代数表达，非法状态需同时满足：

(P != W) && (P != G) && (W != G) // 狼吃羊 || (P != G) && (P != C) && (G != C) // 羊吃菜

我写了一个Python脚本，遍历所有16种(P,W,G,C)组合，代入上述公式，筛出非法状态。结果发现，(0,0,1,1)（人左，狼左，羊右，菜右）是合法的——因为人和羊、菜都不在同一侧，但羊和菜在右岸无人看管，按规则应非法。等等，这里有个常见误解！规则原文是“羊和菜不能单独在一起”，关键在“单独”二字。当人、狼都在左岸，羊、菜在右岸，右岸确实只有羊和菜，构成非法组合。所以(0,0,1,1)必须排除。同理，(1,1,0,0)（人右，狼右，羊左，菜左）也是非法的。最终，16种组合中，有6种被判定为非法，剩下10个合法状态？不对。我重新检查，发现漏掉了人和船的关系——船默认总在人所在的一侧，所以“人带某物过河”本质上是改变两个变量（人+某物）的位置。因此，状态转移不是任意翻转，而是受限于“人必须参与搬运”。这意味着，合法状态不仅要看静态分布，还要看能否从初始状态通过一系列合法搬运到达。用广度优先搜索（BFS）从(0,0,0,0)出发，每次尝试四种搬运（空船、带狼、带羊、带菜），并过滤掉搬运后产生的非法状态，最终得到全部16个可达且合法的状态。这个过程我做了三次，第一次手算漏掉一个，第二次用Excel表格推演，第三次用Python BFS验证，才敢把状态列表写进Verilog。经验之谈：状态机设计的第一步，永远是用纸笔或脚本穷举并验证所有状态，而不是急着写代码。

3.2 按键消抖的硬件实现：为什么20ms是黄金阈值？

FPGA开发新手常犯的错误，是用一个简单的if(key_in == 1'b0)来检测按键释放，结果发现LED狂闪、状态乱跳。这是因为机械按键在闭合和断开瞬间，触点会反复弹跳，产生一串宽度几微秒到几毫秒的脉冲。Quartus II综合后，这段代码会被映射成一个敏感于毛刺的组合电路，导致灾难性后果。正确的做法是用同步计数器实现硬件消抖。

核心思想：用系统时钟（假设50MHz）对按键信号进行采样，当连续N个周期采样值都为低电平（按键按下），才认定为有效按键。N的选择至关重要。人手按键的典型抖动时间为5~15ms，所以采样窗口必须大于15ms。50MHz时钟周期是20ns，要达到20ms，需要计数20ms / 20ns = 1,000,000次。这个数太大，会占用大量LUT资源。工程实践中的折中方案是：用一个较低频率的时钟（比如1kHz）作为消抖基准。怎么得到1kHz？对50MHz进行2^16=65536分频，得到约763Hz，再用一个2分频器，得到381Hz，接近但不够。更优解是用参数化计数器：设定DEBOUNCE_CNT = 50_000（对应1ms），然后计数1000次，得到1s，显然太长。标准做法是：DEBOUNCE_CNT = 1_000_000，但用一个10位计数器（0~1023）循环计数，每轮计数满后置位一个标志位，再用另一个计数器统计这个标志位出现的次数。我最终采用的是两级计数器：第一级计数20_000（对应0.4ms），第二级计数50（对应20ms），这样总资源消耗可控，且精度足够。关键代码片段如下：

// 第一级：0.4ms计数器 always @(posedge clk or negedge rst_n) begin if (!rst_n) cnt1 <= 0; else if (cnt1 == DEBOUNCE_CNT1 - 1) cnt1 <= 0; else cnt1 <= cnt1 + 1'b1; end assign cnt1_done = (cnt1 == DEBOUNCE_CNT1 - 1); // 第二级：20ms计数器，只在cnt1_done为高时加1 always @(posedge clk or negedge rst_n) begin if (!rst_n) cnt2 <= 0; else if (cnt1_done && (cnt2 == DEBOUNCE_CNT2 - 1)) cnt2 <= 0; else if (cnt1_done) cnt2 <= cnt2 + 1'b1; else cnt2 <= cnt2; end assign key_valid = (cnt2 == DEBOUNCE_CNT2 - 1) && cnt1_done;

这里DEBOUNCE_CNT1=20_000，DEBOUNCE_CNT2=50，乘积正好是1,000,000。实测下来，这个消抖模块在AC620上占用不到50个LE，却让按键响应变得无比可靠。记住：消抖不是锦上添花，而是状态机稳定的前提。没有它，后面所有逻辑都是空中楼阁。

3.3 LED显示编码设计：用颜色和位置讲好故事

“过河”游戏的用户界面，全靠8个LED传达信息。如何让玩家一眼看懂当前局势？我放弃了简单的二进制显示（比如用LED0-LED3显示状态编号），而是采用语义化编码：用不同LED代表不同角色，用亮灭代表左右岸。

具体分配如下：

• LED0：人（Person）——亮=右岸，灭=左岸
• LED1：狼（Wolf）——亮=右岸，灭=左岸
• LED2：羊（Goat）——亮=右岸，灭=左岸
• LED3：菜（Cabbage）——亮=右岸，灭=左岸
• LED4-LED7：状态指示灯——显示当前处于第几步（0-15），用4位二进制，方便调试时定位

这个设计看似简单，但背后有深意。首先，它符合人类认知直觉：看到LED1亮，就知道狼在右岸，无需查表换算。其次，它天然支持“非法状态报警”：当系统检测到非法组合（如狼羊同侧且无人），可以让LED4-LED7快速闪烁，同时让LED0-LED3全灭，形成强视觉警示。更重要的是，它为后续扩展留了余地——比如想增加音效，可以用LED7作为蜂鸣器使能信号；想加数码管显示步数，LED4-LED7的数据可以直接送过去。我在嘉立创EDA画PCB时，特意把这8个LED排成两行，上行4个（P/W/G/C），下行4个（STEP），物理布局和逻辑编码完全一致，焊接调试时一目了然。经验之谈：硬件接口设计，永远要站在用户（或调试者）的角度思考，而不是编译器的角度。

3.4 Quartus II工程配置与引脚约束：别让工具毁了你的设计

Quartus II是老牌EDA工具，但配置不当，会让你的Verilog代码在下载后完全不工作。最常见的坑有三个：

1. 时钟设置错误：AC620开发板的主时钟是50MHz，但很多教程默认用1MHz。如果你在Assignments -> Device -> Device and Pin Options -> Clocking里没把Global clock设置为CLK_50M，或者没在Pin Planner里把PIN_A12（或对应引脚）正确分配给clk端口，那么你的状态机就会跑得奇慢无比，甚至无法启动。我的做法是：新建工程时，第一步就打开Pin Planner，找到CLK_50M，双击它，在Location栏手动输入A12（AC620的官方引脚），然后勾选Use as input pin。这一步做完，时钟才算真正接入。

2. 未启用“Smart Compilation”：Quartus II默认的编译流程会做全量分析，耗时极长。在Assignments -> Settings -> Compiler里，把Compilation mode改为Smart Compilation，并勾选Incremental compilation。这样，当你只修改了game_fsm.v，Quartus II会智能识别，只重新综合这个模块，其他模块（如key_debounce.v）的网表直接复用，编译时间从8分钟缩短到90秒。

3. 引脚约束文件（.qsf）的手动编辑：自动生成的引脚约束往往不准确。比如，key[0]可能被分配到PIN_R1，但AC620原理图上，这个按键实际连接的是PIN_T10。必须打开.qsf文件，找到set_location_assignment PIN_T10 -to key[0]这一行，确保它存在且正确。我养成的习惯是：拿到新开发板，第一件事就是对照原理图，把所有按键、LED、数码管的引脚在.qsf里手动写死，绝不依赖自动分配。因为自动分配可能把两个LED分配到同一个Bank，导致电压不匹配，烧毁IO。

提示：在Tools -> Tcl Scripts里，可以运行一个Tcl脚本，自动读取原理图PDF，生成标准.qsf模板。我分享过这个脚本，但核心不是脚本，而是对硬件原理图的敬畏心——每一个引脚，都是硅片和现实世界的契约。

4. 实操过程与核心环节实现

4.1 从零开始创建Quartus II工程：避坑指南

创建工程不是点几下鼠标那么简单。我记录下自己在AC620上从零搭建“过河”项目的完整步骤，每一步都标注了容易踩的坑：

1. 新建工程：File -> New Project Wizard，路径不要用中文或空格，比如D:\eda\heguo。项目名填heguo，顶层实体名也填heguo。这一步看似 trivial，但路径含空格会导致ModelSim仿真失败，顶层名和项目名不一致会让SignalTap抓不到信号。

2. 选择器件：在Device family里选Cyclone IV E，Available devices里选EP4CE6F17C8（AC620的型号）。千万别选错成Cyclone V或MAX 10，引脚定义和资源完全不同。

3. 添加源文件：点击Add，依次加入top_level.v,key_debounce.v,game_fsm.v,led_display.v。注意：必须按依赖顺序添加！先加key_debounce.v，再加game_fsm.v，最后加top_level.v。因为Quartus II会按添加顺序解析，如果top_level.v在最前面，它引用的key_debounce还没被解析，会报错undefined module。

4. 配置引脚：Assignments -> Pin Planner。这里要极度耐心。AC620的按键是低电平有效（按下时为0），所以key[0]的I/O Standard必须设为3.3-V LVTTL，Reserved设为As output driving low。LED是高电平点亮，所以led[0]的I/O Standard也是3.3-V LVTTL，但Reserved设为As output driving high。这个细节，决定了你的LED是按下按键后亮，还是灭。

5. 编译前检查：Processing -> Start Compilation之前，务必运行Analysis & Synthesis。它会检查语法和基本连接。如果这里报错，说明Verilog有硬伤，比如always @(posedge clk)里漏写了begin...end，或者case语句没写default。我见过太多人跳过这步，直接全编译，结果等10分钟后报错，才发现是少了个分号。

6. 下载到板子：编译成功后，Tools -> Programmer。确保Hardware setup选的是USB-Blaster，Mode是JTAG，File指向生成的heguo.sof。点击Start，进度条走到100%，LED立刻亮起。如果没反应，先看USB-Blaster是否被识别（设备管理器里有Altera USB-Blaster），再查.sof文件路径是否正确。

这个过程我走了67次，才总结出这份清单。它不是操作手册，而是血泪教训的结晶。

4.2 game_fsm.v核心代码详解：状态转移的每一行都在说话

下面是我最终版game_fsm.v的关键代码，逐行解释其设计意图：

module game_fsm ( input wire clk, input wire rst_n, input wire key_valid, // 消抖后按键有效信号 input wire [1:0] key_sel, // 按键选择：00=空船，01=带狼，10=带羊，11=带菜 output reg [3:0] led_out // LED显示编码 ); // 独热码状态定义，共16个状态 localparam S0 = 4'b0001, S1 = 4'b0010, S2 = 4'b0100, S3 = 4'b1000, S4 = 4'b0001, ... // 此处省略，实际有16个 reg [3:0] current_state, next_state; // 第一段：状态寄存器更新（同步时序） always @(posedge clk or negedge rst_n) begin if (!rst_n) current_state <= S0; // 复位到初始状态 else current_state <= next_state; // 时钟上升沿更新 end // 第二段：状态转移逻辑（组合逻辑） always @(*) begin case (current_state) S0: begin // 初始：全在左岸 if (key_valid && key_sel == 2'b10) next_state = S1; // 带羊过河 else next_state = S0; // 其他操作非法，保持原状 end S1: begin // 人羊在右，狼菜在左 if (key_valid && key_sel == 2'b00) next_state = S2; // 空船返回 else next_state = S1; end S2: begin // 人狼在左，羊菜在右 if (key_valid && key_sel == 2'b01) next_state = S3; // 带狼过河 else next_state = S2; end // ... 后续13个状态，每个都严格按BFS路径编写 default: next_state = S0; // 防止latch，强制回到初始 endcase end // 第三段：输出逻辑（组合逻辑） always @(*) begin case (current_state) S0: led_out = 4'b0000; // 人狼羊菜全左 S1: led_out = 4'b1100; // 人右、狼右、羊左、菜左？不对！这里要根据状态含义赋值 // 正确做法：led_out[0]=P, led_out[1]=W, led_out[2]=G, led_out[3]=C S0: {led_out[0], led_out[1], led_out[2], led_out[3]} = 4'b0000; S1: {led_out[0], led_out[1], led_out[2], led_out[3]} = 4'b1010; // P=1,W=0,G=1,C=0 // ... 为每个状态精确计算P,W,G,C值 endcase end endmodule

关键点解析：

• key_sel是2位信号，由顶层模块的按键矩阵扫描生成。它不是直接连按键，而是经过编码，把4个物理按键（空船、狼、羊、菜）映射成2位选择码。这样，状态机只需关心“选了什么”，不用管“按了哪个键”，解耦更彻底。
• default: next_state = S0是安全网。FPGA上电后，寄存器初值不确定，current_state可能处于非法编码（如4'b1111）。如果没有default分支，next_state会变成x（未知态），导致整个状态机锁死。强制回S0，保证系统可恢复。
• 输出逻辑里，我用了{led_out[0], ...} = 4'b1010这种位拼接写法，而不是led_out = 4'b1010。因为led_out的每一位代表一个角色，这样写，逻辑和物理意义完全对齐，后期维护时，看到4'b1010就知道是“人右、狼左、羊右、菜左”，无需查表。

4.3 ModelSim仿真验证：如何写出有价值的Testbench

仿真不是走过场，而是发现逻辑漏洞的显微镜。一个合格的Testbench，必须覆盖所有边界情况。我的tb_game_fsm.v包含以下关键测试用例：

1. 复位测试：rst_n拉低100ns，再拉高，检查current_state是否在下一个时钟沿变为S0。
2. 单步转移测试：在S0状态下，施加key_valid=1且key_sel=2'b10（带羊），检查next_state是否在下一个周期变为S1。
3. 非法操作测试：在S0状态下，施加key_sel=2'b01（带狼），检查next_state是否保持S0，不发生转移。
4. 毛刺免疫测试：在S0状态下，给key_valid一个宽度为1个时钟周期（20ns）的尖峰脉冲，检查状态是否稳定，不发生误跳。
5. 长按键测试：保持key_valid=1长达10个时钟周期，检查状态是否只转移一次，不会因持续有效而多次跳转。

Testbench的核心技巧是：用$monitor打印关键信号，用$stop在关键点暂停，用force和release精确控制输入。例如：

initial begin $display("Time\tState\tNextState\tKeyValid\tKeySel"); $monitor("%d\t%b\t%b\t%b\t%b", $time, dut.current_state, dut.next_state, key_valid, key_sel); // 复位 rst_n = 0; #100 rst_n = 1; // 等待第一个时钟沿 @(posedge clk); // 测试带羊操作 key_valid = 1; key_sel = 2'b10; @(posedge clk); // 状态应变为S1 $stop; // 暂停，人工检查波形 // 测试非法操作 key_valid = 1; key_sel = 2'b01; @(posedge clk); // 状态应保持S0 end

运行仿真后，打开Wave窗口，把current_state,next_state,key_valid,key_sel拖进去，放大看每个时钟沿的变化。你会发现，真正的bug往往藏在next_state的建立时间（setup time）和保持时间（hold time）上——比如key_valid在时钟沿前1ns才变高，就可能采样失败。这才是仿真价值所在：它让你在烧录前，就看到硅片上将发生什么。

4.4 下载调试与SignalTap实战：在真实硬件上“看见”状态

仿真通过，不等于板子能跑。最后一步，用SignalTap Logic Analyzer抓取真实信号。这是FPGA工程师的“听诊器”。

配置SignalTap的要点：

• 采样时钟：必须用设计中的主时钟clk，不能用SignalTap自带的时钟。否则抓到的波形是错相的。
• 采样深度：AC620的SignalTap内存有限，设为1024samples足够。太多会拖慢下载速度。
• 触发条件：设置current_state == S0且key_valid == 1为触发，这样能精准捕获状态转移瞬间。
• 信号选择：除了current_state,next_state,key_valid,key_sel，一定要加上led_out。因为LED是最终输出，如果led_out不对，说明第三段逻辑有问题；如果led_out对但LED不亮，问题在顶层引脚约束。

我曾经遇到一个诡异问题：仿真波形完美，下载后LED全灭。用SignalTap一抓，发现led_out输出全是4'b0000，但current_state显示是S15（目标状态）。问题出在led_display.v里，我把led_out的位宽写成了[2:0]，漏掉了最高位，导致led_out[3]被截断。SignalTap直接暴露了这个低级错误。所以，SignalTap不是高级功能，而是必选项。它让你从“我以为它在工作”，变成“我亲眼看到它在工作”。

5. 常见问题与排查技巧实录

5.1 按键失灵：90%的问题出在消抖和电平上

现象：按下按键，LED毫无反应，或反应迟钝、多次触发。

排查路径：

1. 测物理电平：用万用表测按键引脚。按下时，电压应从3.3V降到0V（AC620是低电平有效）。如果一直是3.3V，说明硬件没接好或按键坏了。
2. 看SignalTap：抓key_in（原始按键信号）波形。正常应看到一串密集毛刺（抖动），持续几毫秒。如果没有毛刺，说明按键或上拉电阻有问题；如果毛刺太长（>50ms），可能是按键质量差。
3. 查消抖模块：抓key_valid信号。它应该是宽度约20ms的单个脉冲。如果脉冲太窄（<1ms），说明DEBOUNCE_CNT设小了；如果脉冲太宽（>100ms），说明计数器没清零。
4. 验状态机输入：抓game_fsm的key_valid输入。如果这里没信号，问题在顶层模块的连线；如果这里有信号但状态不跳，问题在状态转移逻辑。

注意：AC620的按键是“常开”型，未按下时，引脚通过10kΩ上拉电阻接到3.3V，呈高电平；按下时，引脚接地，呈低电平。很多新手误以为“按下是高电平”，导致key_valid逻辑写反，永远等不到有效信号。

5.2 状态乱跳：时序违规与异步复位的陷阱

现象：LED随机闪烁，状态在几个之间无规律跳变，甚至进入S0以外的非法状态。

根本原因：异步复位释放时的亚稳态（metastability）。当rst_n从0变1时，如果恰好在时钟沿附近，current_state寄存器可能进入亚稳态，输出短暂的x值，被case语句误判为某个非法状态，从而触发错误转移。

解决方案：

• 同步复位：把复位信号也通过两级触发器同步到clk域