状态机设计方法：状态转移图、状态表、状态分配

各位同学，咱们直接进入正题。状态机设计说白了就是三步：先画图、再列表、最后分配编码。这三步走对了，后面调试能省一半的功夫。我个人习惯把这三步叫做“状态机设计三件套”，少了哪一个都容易出幺蛾子。

状态转移图——先把逻辑画出来

状态转移图（State Transition Diagram）是整个状态机设计的起点。它用圆圈表示状态，用箭头表示转移条件。你想想看，连自己要实现什么逻辑都没想清楚，就直接上手写代码，那不是等着返工嘛？

画图的时候有几个要点：

• 每个状态只画一个圆圈，圆圈里写上状态名（比如 IDLE、WAIT、DONE）。
• 箭头从当前状态指向下一个状态，箭头上标注转移条件（比如 start=1、cnt==10）。
• 自环转移也要画出来，就是箭头绕回自己，条件不满足时保持当前状态。
• 初始状态用双圈或特殊标记标出来，通常是复位后的状态。

我在项目中遇到过一位同事，画图的时候漏了一个自环，结果仿真时状态机跑到某个状态就卡住了——因为没有画自环，他以为没条件变化时会自动回到IDLE，实际上综合工具会生成一个让你摸不着头脑的“隐式状态”。嗯，这里要注意：所有状态都必须有明确的后继状态定义，哪怕条件不变也得画自环。

一个小技巧：先画主干，再补细节

别一上来就想把所有条件画全。先把主流程串起来：上电复位 → 等待条件 → 执行操作 → 结束判断。主干通了，再往里加分支。相当于先搭骨架，再填肉。

状态转移表——把图翻译成表格

画完了图，下一步就是把图里的信息塞进表格。状态转移表（State Transition Table）是一张二维表：行是当前状态，列是输入条件组合，表格里填下一状态和输出。你想想看，表格比图更容易做形式化检查——有没有漏掉某个输入组合？一眼就能看出来。

状态转移表的标准结构：

看到没？每个状态下的所有输入条件都列全了，没有遗漏。我一般在画完表之后会逐行对照状态转移图检查一遍，看看有没有箭头没对应上。说白了，表就是图的数据化版本，二者必须严格一致。

状态分配——给状态起个“二进制名字”

状态分配（State Assignment）就是给每个状态分配一个二进制编码。这一步最容易被忽视，但恰恰是很多时序问题的根源。常用的分配方式有：

• 二进制编码（Binary Encoding）：按顺序分配 00、01、10、11……触发器数量最少，但可能出现多条状态线同时翻转，造成毛刺。
• 一位热码（One-Hot Encoding）：每个状态对应一个触发器，只有一个为1，其余为0。比如4个状态就用4个触发器。时序好，无竞争条件，但触发器多。
• 格雷码（Gray Encoding）：相邻状态只变1位，适合连续状态转移的场合（比如计数器）。
• 自定义编码：有时为了适配输出逻辑，会把状态编码直接映射到输出上，省掉输出译码器。

我个人的习惯是：小型状态机（少于8个状态）用一位热码，调试方便，看波形一眼就能知道当前是哪个状态。大型状态机（超过16个状态）用二进制编码，节省面积。至于格雷码，我只在状态机用作FSM计数器时用，其他场景比较少用。

三者的关系——一张图看懂

为了帮你理清这三步是怎么串起来的，我画了一张汇总图。你照着这个流程走，基本不会走偏。

实战中的一些经验

• 画图工具怎么选？ 我个人习惯用Graphviz或draw.io，直接在代码里定义节点和边，自动生成矢量图，不容易漏箭头。你如果喜欢手画也行，但务必保证最终归档的文档和代码里的一致。
• 状态表一定要包含“非法状态”处理吗？ 要。哪怕你的状态机只有3个状态，如果用二进制编码，4种编码中会有一种非法状态。我建议在状态表里加一行“others → IDLE”的default转移，这样就算邪门歪道也不怕。
• 状态分配谁说了算？ 资源约束和时序约束说了算。当触发器数量富裕时，一位热码的调试体验好很多；当面积吃紧时，二进制编码更友好。你如果拿不定主意，可以先写RTL，让综合工具帮你选择——但一定要阅读综合报告，确认它用了你期望的编码方式。

小结一下核心步骤

刚才说了不少，其实总结起来就是三步走：
① 用状态转移图把逻辑画清楚（圈+箭头）
② 用状态转移表把图翻译成完整覆盖的表格（行×列）
③ 用状态分配给每个状态赋予二进制名字（编码策略）
弄完这三步，基础就打牢了。后面的代码实现和仿真验证都能有条不紊地推进。