第2章 有限状态机基础

做高速接口协议解析，绕不开状态机。我见过不少工程师，协议背得滚瓜烂熟，一画状态图就乱。说白了，状态机就是描述“系统在不同时刻，处于什么状态，遇到什么条件，下一步去哪”的一套规则。它不复杂，但细节多。咱们这一章，就把FSM的底子夯实。

2.1 FSM概念：到底是什么

有限状态机，你想想看，核心就三个东西：

• 状态：系统在某一时刻的稳定模式。比如接口的“空闲”、“发送”、“接收”。
• 事件/条件：触发状态变化的外部输入。比如收到一个“开始位”，或者“数据完成”信号。
• 动作：进入状态或状态跳转时执行的操作。比如“清零计数器”、“输出数据”。

我的习惯是，先画个简陋的状态图，再写代码。别一上来就搞复杂的状态表，容易晕。

2.2 状态图表示法：画图比说话管用

状态图的画法有标准，但日常项目中，大家更关心“能不能一眼看懂”。我通常用Robei或Visio，手绘也行。

核心元素就几样：

• 圆圈/圆角矩形：表示状态。
• 箭头：表示状态跳转方向。
• 标签：写在箭头上，表示跳转条件。
• 初始状态：用一个带箭头的起点指向它。
• 结束状态：如果有终点，用双圈表示。

2.3 状态跳转条件：条件写清楚，硬件不犯错

条件写错，是状态机跑飞的主要原因。记住，每个箭头只能有一个条件组，但可以用“与”、“或”组合。

举个例子，PCIe的Link Training，状态从“Detect”跳到“Polling”，条件必须是(reset_done && refclk_stable)，缺一不可。我曾经看到一个同事，把条件写成(reset_done || refclk_stable)，结果仿真没问题，上板子就崩。为什么？因为条件太宽松，状态乱跳。

2.4 Mealy型与Moore型：输出怎么来的，区别很大

这是面试常考题，也是实际设计的分水岭。直接说区别：

我个人更倾向用Moore型。不是因为Moore更好，而是更安全。在PCIe或DDR这类高速接口中，一旦输出毛刺，整个链路就错了。Moore型输出多等一个时钟，换来的是稳定。但Mealy型也有其价值，比如在做命令解析时，你希望输入一到，输出立刻变，节省一个时钟就是几个纳秒的收益。

2.5 混合型：现实项目的常态

实际项目中，很少用纯Mealy或纯Moore。为什么呢？

• 纯Mealy：组合逻辑直接出，快但易毛刺。需要后端加“输出寄存器”来打一拍，本质上又变成了Moore。
• 纯Moore：所有输出都靠寄存器，状态数多，面积大，延迟也固定。
• 混合型：核心状态跳转用 Moore，数据输出用 Mealy。既保证控制时序稳定，又让数据通道快一拍。

我做过一个SerDes接口控制状态机，就是混合的。复位用Moore，命令解码用Mealy。仿真时没什么，但上板发现接收数据偶尔错位。查了波形才知道，Mealy部分的组合逻辑产生了半个周期的毛刺，被接收寄存器采到了。后来在Mealy输出后加了一个“透明锁存器”，问题解决。

2.6 状态跳转与输出机制对比流程图

下面这张图，把 Mealy 和 Moore 的核心差异、状态跳转逻辑、以及输出依赖关系画清楚了。你盯着看三分钟，应该就能明白为什么实际项目很少用纯粹的一种。

2.7 状态跳转条件写法：你的逻辑能综合吗？

很多初学者喜欢写复杂的嵌套if-else，然后发现综合后面积巨大。我建议：

1. 每个状态独占一个分支（case或if）。不要嵌套超过3层。
2. 条件用wire或logic定义好，不要直接在敏感列表里算。
3. 默认状态（others）一定要有，指向IDLE。否则综合会生成锁存器。

// 错误写法：条件内嵌复杂运算
always @(posedge clk or negedge rst_n) begin
    if(!rst_n) state <= IDLE;
    else begin
        case(state)
            IDLE: if(data_in & (counter > 10) & !lock) state <= SEND;
            SEND: if(data_in & transfer_done) state <= IDLE;
            default: state <= IDLE;
        endcase
    end
end

// 正确写法：条件预计算
wire start_condition = data_in & (counter > 10) & !lock;
wire stop_condition  = data_in & transfer_done;
always @(posedge clk or negedge rst_n) begin
    if(!rst_n) state <= IDLE;
    else begin
        case(state)
            IDLE: if(start_condition) state <= SEND;
            SEND: if(stop_condition)  state <= IDLE;
            default: state <= IDLE;
        endcase
    end
end

2.8 状态编码：别小看这一步

状态跳转流畅与否，编码方式影响很大。常用三种：

我个人的偏好是：状态不超过8个，用独热码。超过8个，用格雷码。二进制编码？嗯，只有在面积实在推不动时才考虑。