4. 状态机设计误区：三段式与一段式的选择，冗余状态与缺省状态的处理，状态机跑飞的预防

状态机这东西，说简单也简单，说复杂也复杂。我见过不少新手，上来就写一段式状态机，结果代码改了三版还没跑通。也见过老手，明明用三段式就能搞定的事，非要搞个复杂的状态嵌套，最后把自己绕进去了。

今天咱们就聊聊状态机设计里那些容易踩的坑。嗯，我尽量把话说得直白点。

4.1 一段式 vs 三段式：别盲目跟风

先说说最基础的问题：到底用一段式还是三段式？

我个人习惯是：能用三段式就别用一段式。为什么？因为一段式把所有逻辑揉在一起，代码可读性差，后期维护简直是噩梦。

一段式状态机长这样：

always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
        state <= IDLE;
    else begin
        case (state)
            IDLE: begin
                if (start)
                    state <= WORK;
                else
                    state <= IDLE;
                // 输出逻辑也混在这里
                data_out <= 0;
            end
            WORK: begin
                // 状态转移和输出全在一起
                ...
            end
        endcase
    end
end

你看，状态跳转、输出逻辑、时序控制全在一个 always 块里。代码少的时候还行，一旦状态多了，你改一个地方可能影响三个功能。我在项目中遇到过这种情况：同事改了一段式状态机的一个输出条件，结果状态跳转逻辑也跟着变了，查了两天才找到原因。

三段式就清晰多了：

// 第一段：状态寄存器
always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
        state <= IDLE;
    else
        state <= next_state;
end

// 第二段：次态逻辑（组合逻辑）
always @(*) begin
    case (state)
        IDLE: begin
            if (start)
                next_state = WORK;
            else
                next_state = IDLE;
        end
        WORK: begin
            if (done)
                next_state = IDLE;
            else
                next_state = WORK;
        end
        default: next_state = IDLE;
    endcase
end

// 第三段：输出逻辑
always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
        data_out <= 0;
    else begin
        case (state)
            WORK: data_out <= 1;
            default: data_out <= 0;
        endcase
    end
end

我的建议： 除非你的状态机只有两三个状态，而且输出逻辑极其简单，否则老老实实用三段式。你想想看，以后代码要给别人看，或者几个月后你自己回来看，三段式一眼就能看懂，一段式得从头捋一遍。

4.2 冗余状态与缺省状态：别给自己挖坑

状态机设计里，冗余状态和缺省状态是两个容易被忽视的问题。

冗余状态，说白了就是那些永远进不去、或者进去了就出不来的状态。我见过有人设计状态机，画了十几个状态，结果实际用到的只有五六个。剩下的状态要么是设计时脑补的，要么是后来需求变更了但代码没删干净。

冗余状态有什么危害？它会让你的状态机变得臃肿，综合工具会多分配寄存器，而且万一因为某种原因（比如干扰）跳到了冗余状态，你的状态机可能就卡死在那里了。

缺省状态，就是 case 语句里的 default 分支。很多人觉得「我的状态已经覆盖全了，不需要 default」。嗯，这里要注意：永远不要省略 default 分支。

我曾经犯过的错： 有一次设计一个通信协议的状态机，自认为状态覆盖得很完整，就没写 default。结果仿真时一切正常，上板测试时偶尔出现死机。查了三天，发现是某个极端情况下状态跳到了一个未定义的值，因为没有 default，综合工具默认生成了一个锁存器，状态就卡住了。

正确的做法是：

case (state)
    IDLE: ...
    WORK: ...
    DONE: ...
    default: next_state = IDLE;  // 安全兜底
endcase

而且，我建议 default 分支里不要只写个空操作，最好跳到一个安全状态（比如 IDLE 或复位状态）。

4.3 状态机跑飞：预防比补救更重要

状态机跑飞，就是状态跳到了你预期之外的地方。这通常由几个原因引起：

  • 组合逻辑的竞争冒险：次态逻辑是组合逻辑，如果输入信号有毛刺，可能导致状态跳错
  • 异步信号未同步：外部输入直接驱动状态跳转，没有做同步处理
  • 状态编码不合理：相邻状态之间跳转时，多个比特同时变化，容易出错

怎么预防？我总结了几个实用方法：

  1. 使用格雷码或独热码：格雷码相邻状态只有一位变化，独热码每个状态只有一个比特为1，都能降低出错概率
  2. 输入信号做同步处理：所有外部输入先打两拍再进状态机
  3. 加看门狗机制：在状态机里加一个超时计数器，如果某个状态停留时间过长，强制复位

看门狗状态机的简单实现：

always @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        state <= IDLE;
        timeout_cnt <= 0;
    end else begin
        case (state)
            IDLE: begin
                timeout_cnt <= 0;
                if (start) state <= WORK;
            end
            WORK: begin
                if (timeout_cnt > MAX_TIMEOUT) begin
                    state <= IDLE;  // 超时，强制回到安全状态
                    timeout_cnt <= 0;
                end else begin
                    timeout_cnt <= timeout_cnt + 1;
                    if (done) state <= IDLE;
                end
            end
            default: state <= IDLE;
        endcase
    end
end

你看，加个超时计数器，状态机就算跑飞了，也能在超时后自动复位。这招我在实际项目中用过多次，效果很好。

4.4 状态编码的选择：别小看这个细节

状态编码方式直接影响状态机的稳定性和资源消耗。常用的有三种：

编码方式 优点 缺点 适用场景
二进制编码 节省寄存器 多比特同时变化，易出错 状态数较多（>16）
格雷码 相邻状态只有1位变化 译码逻辑复杂 状态连续跳转的场景
独热码 译码简单，速度快 浪费寄存器 状态数较少（<16）

我个人习惯是：状态少于8个用独热码，8到16个用格雷码，超过16个用二进制码。当然，这也不是绝对的，具体还要看你的时序要求和资源限制。

一个小技巧： 如果你不确定用什么编码，可以先写代码，让综合工具自动选择。在 Vivado 或 Quartus 里都有相关的综合选项。但如果你对稳定性要求很高，我建议手动指定编码方式，别完全依赖工具。

4.5 实战避坑清单

最后，我把自己这些年踩过的坑整理成一份清单，你写状态机时对照着检查一遍：

  • ✅ 是否用了三段式？（除非状态极少）
  • ✅ 是否写了 default 分支？
  • ✅ 是否处理了冗余状态？
  • ✅ 外部输入是否做了同步？
  • ✅ 是否加了超时保护？
  • ✅ 状态编码是否合理？
  • ✅ 复位状态是否明确？

嗯，差不多就这些。状态机设计说到底是经验活，写得多了自然就有感觉了。但有些坑，能提前避开就别亲自去踩。

核心一句话： 状态机设计，安全第一。宁可多写几行代码，也别省那点功夫。跑飞一次，够你查一星期的。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →