4. 硬件加速器设计思路：状态机与计数器结合

好，咱们接着聊。前面几章我们把按键消抖的基本原理和纯软件方案都过了一遍。今天要聊的，是真正把消抖做到硬件加速器里的核心思路——状态机 + 计数器。

说实话，我第一次接触这个组合时，觉得有点小题大做。一个按键消抖而已，至于用状态机吗？后来在项目里吃过亏才明白——没有状态机管着，计数器就是个没脑子的傻大个。

4.1 为什么非要用状态机？

你想想看，按键信号在抖动时，电平会反复跳变。如果我们只用计数器，比如检测到低电平就开始数数，数到20ms就认为稳定了——那问题来了：

  • 如果数到一半，信号又跳高了怎么办？
  • 如果按键按下后一直抖动，计数器该不该复位？
  • 如果用户按了一下马上松开，计数器怎么知道该停？

这些问题，说白了就是缺少一个“大脑”来管理计数器的行为。状态机就是那个大脑。

核心思想：状态机负责“判断当前该干什么”，计数器负责“干多久”。两者配合，才能做出一个健壮的硬件消抖模块。

4.2 三状态消抖状态机

我个人习惯把消抖状态机分成三个状态：

状态 含义 计数器行为
IDLE 空闲态，等待按键按下 计数器清零，不计数
DEBOUNCE 消抖态，正在等待稳定 计数器递增，直到超时
CONFIRM 确认态，输出稳定电平 计数器保持，等待释放

嗯，这里要注意——IDLE 和 CONFIRM 虽然看起来都是“等待”，但行为完全不同。IDLE 等待的是按键按下，CONFIRM 等待的是按键释放。我在项目中见过有人把这两个状态合并，结果消抖逻辑乱成一锅粥。

4.3 状态转移图

光说理论太干，咱们直接画个图。下面这个 SVG 是我手绘风格的状态转移图，你看一眼就明白了：

IDLE 输出=上次稳定值 DEBOUNCE 计数器递增 CONFIRM 输出=新稳定值 按键电平变化 计数器超时 抖动返回原电平 按键释放

这个图里，箭头上的文字就是状态转移条件。你看，从 IDLE 到 DEBOUNCE 的条件是“按键电平变化”——注意，不是“按下”，是“变化”。因为我们要同时处理按下和释放两种情况。

小技巧：我曾经在 DEBOUNCE 到 IDLE 的路径上吃过亏。如果抖动导致信号回到原始电平，计数器必须立即清零并回到 IDLE。否则下次再抖动时，计数器是从上次的值继续累加，消抖时间就不对了。

4.4 计数器设计要点

计数器本身不复杂，但有几个细节我特别想强调：

  • 位宽选择：假设时钟是 50MHz（周期 20ns），消抖时间 20ms，那么需要计数值 = 20ms / 20ns = 1,000,000。2^20 = 1,048,576，所以至少 20 位计数器。我一般会留点余量，用 24 位。
  • 使能控制：计数器只在 DEBOUNCE 状态才递增，其他状态保持或清零。这个使能信号由状态机给出。
  • 比较器：不需要每次都用“等于”判断，用“大于等于”更安全。万一计数器多跑了一个周期，也不会出大问题。

4.5 代码实现（Verilog）

光说不练假把式。下面是我写的一个简化版消抖模块，你感受一下状态机和计数器是怎么配合的：

module debounce_fsm (
    input  wire       clk,
    input  wire       rst_n,
    input  wire       key_in,      // 原始按键输入
    output reg        key_out      // 消抖后输出
);

    // 状态定义
    localparam IDLE      = 2'b00;
    localparam DEBOUNCE  = 2'b01;
    localparam CONFIRM   = 2'b10;

    // 计数器参数
    parameter CNT_MAX = 24'd1_000_000;  // 20ms @ 50MHz

    reg [1:0] state, next_state;
    reg [23:0] cnt;
    reg cnt_en;
    reg cnt_rst;

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

    // 状态机第二段：次态逻辑
    always @(*) begin
        next_state = state;
        case (state)
            IDLE: begin
                if (key_in != key_out)      // 电平变化
                    next_state = DEBOUNCE;
            end
            DEBOUNCE: begin
                if (cnt >= CNT_MAX)         // 超时确认
                    next_state = CONFIRM;
                else if (key_in == key_out) // 抖动返回
                    next_state = IDLE;
            end
            CONFIRM: begin
                if (key_in != key_out)      // 按键释放
                    next_state = IDLE;
            end
        endcase
    end

    // 计数器控制
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            cnt <= 24'd0;
        else if (cnt_rst)
            cnt <= 24'd0;
        else if (cnt_en)
            cnt <= cnt + 1'b1;
    end

    // 控制信号组合逻辑
    always @(*) begin
        cnt_en  = (state == DEBOUNCE);
        cnt_rst = (state != DEBOUNCE);
    end

    // 输出更新
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            key_out <= 1'b1;  // 默认高电平（上拉）
        else if (state == CONFIRM)
            key_out <= key_in;
    end

endmodule

注意：这段代码里，我用了 key_out 作为状态转移的参考值。这意味着第一次上电时，key_out 是默认值，按键第一次按下会触发消抖。但如果按键在上电前就已经按下了，这个逻辑会漏掉第一次事件。解决办法是在初始化时先采样一次按键值——这个我们后面章节再细聊。

4.6 避坑指南

做硬件加速器设计，有些坑是绕不开的。我把自己踩过的几个列出来：

  • 计数器溢出：如果消抖时间设得太长，计数器可能溢出。比如 50MHz 时钟下，24 位计数器最大能数 16.7ms，如果你要 20ms 消抖，就得用 25 位以上。别问我怎么知道的——有一次仿真跑了一整天，结果发现计数器一直在溢出复位循环。
  • 状态机死锁：如果状态转移条件写漏了，比如 DEBOUNCE 状态下没有处理“抖动返回”的情况，状态机就会卡在 DEBOUNCE 里出不来。我建议你在每个状态都加上 default 处理，回到 IDLE。
  • 亚稳态问题：按键输入是异步信号，直接送给状态机可能会出问题。一定要先做两级同步，再送给状态机。这个我们后面有专门章节讲。

4.7 小结

状态机加计数器，说白了就是用有限状态来管理无限的时间。状态机告诉你“现在该干什么”，计数器告诉你“干了多久”。两者缺一不可。

我个人觉得，这个设计思路最大的好处是可扩展性强。你想加个长按检测？在 CONFIRM 状态再加一个计数器就行。想加双击检测？再加一个状态。框架搭好了，往上加功能就像搭积木一样简单。

好，这一章就到这里。记住这个三状态模型，后面我们所有的加速器方案都是在这个基础上演变的。

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