单段式状态机：一段式写法、混搭陷阱与避坑指南
各位同学，今天我们来聊聊状态机里最基础、也最容易踩坑的一种写法——单段式状态机。说白了，就是把所有逻辑都塞进一个 always 块里。嗯，我刚入行时也这么干过，觉得简单粗暴，后来吃了不少苦头。
一段式状态机的写法
一段式状态机，也叫单进程状态机。它的核心特征就是：状态跳转逻辑、状态寄存器、输出逻辑，全部写在一个 always 块里。我刚开始学 Verilog 时，觉得这样写最直观，代码量也最少。
来看一个简单的例子：一个两状态的状态机，控制一个 LED 灯闪烁。
module fsm_one_shot(
input clk,
input rst_n,
output reg led
);
reg state;
parameter IDLE = 1'b0;
parameter BLINK = 1'b1;
always @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
state <= IDLE;
led <= 1'b0;
end else begin
case (state)
IDLE: begin
led <= 1'b0;
state <= BLINK;
end
BLINK: begin
led <= 1'b1;
state <= IDLE;
end
default: begin
state <= IDLE;
led <= 1'b0;
end
endcase
end
end
endmodule你看，状态寄存器 state 和输出 led 都在同一个 always 块里赋值。代码确实短，但问题也出在这里。
组合逻辑与时序逻辑混搭
一段式状态机最大的问题，就是组合逻辑和时序逻辑混在一起。你想想看，always 块是时序逻辑（posedge clk），但里面的 case 分支其实是在描述组合逻辑的行为。
为什么会这样？因为我们在同一个 always 块里，既做了状态寄存器的更新（时序），又做了输出信号的赋值（组合）。这在功能上没错，但综合工具会怎么理解呢？
我遇到过这样一个案例：一个同事用一段式写了个复杂的状态机，仿真没问题，但综合后时序总是不满足。查了半天，发现输出信号被综合成了寄存器输出，而不是组合逻辑输出。这就导致多了一级寄存器延迟，关键路径变长了。
⚠️ 重要警告： 一段式状态机中，所有输出都会被综合成寄存器输出。如果你需要组合逻辑输出（比如地址译码、使能信号），一段式写法会强制增加一个时钟周期的延迟。
常见错误与陷阱
我总结了几个最常见的坑，都是我在项目里亲眼见过的：
- 陷阱一：输出信号被锁存 —— 一段式里，如果 case 分支没有覆盖所有输出赋值，综合工具会推断出锁存器。我曾经在代码 review 时发现一个同事的代码，default 分支只写了 state 没写输出，结果生成了 latch。
- 陷阱二：状态跳转和输出耦合太紧 —— 你想修改输出逻辑时，不得不动整个状态机结构。维护起来很痛苦。
- 陷阱三：可读性差 —— 状态机一复杂，几十个状态挤在一个 always 块里，你想想看，调试时眼睛都看花了。
- 陷阱四：仿真与综合不一致 —— 有些仿真器对一段式的处理方式不同，可能导致仿真通过但综合后功能异常。
💡 我的建议： 一段式状态机只适合极其简单的场景，比如 2-3 个状态、输出逻辑也很简单的情况。但凡状态超过 4 个，或者输出需要组合逻辑，我强烈建议改用两段式或三段式。
知识体系结构图
下面这张图，是我自己总结的一段式状态机的核心要点。你可以把它当作一个快速检查清单：
什么时候可以用一段式？
说实话，我现在很少用一段式了。但也不是完全不用。我个人习惯在以下场景使用：
- 极简的控制逻辑：比如上电复位后的初始化序列，只有 2-3 个状态
- 快速原型验证：写个简单的测试模块，不需要考虑综合优化
- 教学演示：给学生讲状态机概念时，一段式最直观
📌 核心总结： 一段式状态机不是不能用，但要清楚它的代价。输出被寄存、组合时序混搭、维护困难——这三个问题你心里有数就行。我在项目中吃过亏后，现在基本只用两段式或三段式。你想想看，多写几行代码，换来的是更清晰的逻辑和更可控的综合结果，这笔账怎么算都划算。
好了，关于单段式状态机就聊到这里。记住：简单场景可以用，复杂场景别碰。下一节我们聊聊两段式状态机，那才是工程实践中的主力选手。
可可精品资料库