主模式RTL设计全解析：状态机与三态驱动的工程实践

干数字IC和FPGA这行的，迟早都会碰上一类活儿：写主模式。不管是SPI主控制器、I2C主机，还是AHB/AXI总线上的Master接口，"主模式RTL设计"指的其实是同一件事——设计一个主动发起操作、主动产生时钟和片选信号的模块。它和被动响应的从模式模块是两套完全不同的设计思路，这也是为什么面试题里状态机、三态驱动总是打包出现：主模式模块的骨架是状态机，血肉是数据通路，对外说话靠的往往是带三态控制的引脚。

这一讲把主模式RTL设计的完整套路拆开讲：从状态机一段式、二段式、三段式怎么选，到三段式FSM的代码模板，再到inout双向端口的三态驱动细节，最后用一个带单线双向数据口的主模式控制器实例，把"控制+驱动"完整串起来。重点不是我贴一段能仿真的代码，而是让大家明白每一步为什么这么写，以及实际项目中踩过的坑在哪里。适合正准备写主模式接口的FPGA工程师、准备数字IC校招面试的学生，以及想把自己模块从"能跑"做到"可靠"的开发者。

1. 主模式RTL设计到底在解决什么问题

1.1 "主模式"是主动发起，不是"主流写法"

这里要先澄清一个容易搞混的点：标题里的"主模式"，指的是模块在协议或总线体系中的Master身份，而不是代码风格上的"主流模式"。谁主动发起操作、谁产生时钟、谁决定什么时候开始什么时候结束，谁就是主。比如I2C总线上的主机要产生SCL时钟、发起START和STOP；SPI总线上的主设备要产生SCK并控制片选信号；AHB/AXI总线上的Master要主动发起读写事务。这些都是典型的主模式模块。

从模式就完全相反。它不产生全局时钟，不决定事务何时开始，只是在主设备选中它的时候被动响应。主模式的RTL设计所以难，是因为你要在一个模块里同时想清楚三件事：协议怎么玩、数据怎么走、引脚怎么控。而从模式通常只需要老老实实等命令，复杂度低一个量级。很多新手上来就写SPI Slave写得挺顺，一换到SPI Master就卡住，卡就卡在这三件事没有在脑子里理清。

这个概念可以用一个生活类比理解：主模式像是正在主持一场会议的人，他要决定什么时候开始、什么时候点谁发言、什么时候散会；从模式则是在座听课的人，主持人点到你你才说话。如果所有人都抢着发言，会就开不下去了——这在RTL世界里就是多驱动冲突，也是后面讲三态驱动的根源。

1.2 主模式设计的三个核心模块

一个合格的主模式RTL设计，无论挂在什么协议上，内部都可以拆成三个部分。

一张表就能说清为什么状态机和三态驱动总是成对出现：状态机负责"什么时候做什么"，三态驱动负责"什么时候开口说话、什么时候闭嘴"。开会的人如果只管流程不管话筒开关，底下人肯定乱套。对应到硬件上，就是状态机把使能信号给错一拍，双向引脚上两个设备同时驱动，轻则数据错误，重则烧片子。

初学的人最容易漏掉的是数据通路。状态机写得漂亮、三态也控制了，但收发数据的移位寄存器方向搞反，或者并行写进来的数据在错误的时钟边沿被采走了，整个模块就废了。主模式设计的真正功力，不在于某个单独部分有多精巧，而在于这三个模块的配合节奏。

2. 状态机：主模式的"指挥中枢"

2.1 一段、二段、三段式状态机，到底差在哪

状态机是主模式RTL设计的核心控制器。面试十有八九会问你一段式、二段式、三段式的区别，很多人能背出结论"推荐三段式"，但说不上来为什么。这里把三种写法一次讲透。

• 一段式：状态转移和输出写在一个always块里，状态寄存器同时当输出用。代码最短，但组合逻辑和时序逻辑混在一起，输出容易产生毛刺，后期加逻辑很难维护，基本只适合写非常小的控制逻辑。
• 二段式：第一段写时序逻辑做状态转移，第二段写组合逻辑做输出判断。结构比一段清晰，但输出仍然是组合逻辑，容易毛刺，且跨模块复用时别人拿到的是未寄存的输出。
• 三段式：第一段状态转移，第二段次态组合逻辑，第三段输出寄存器。三条always各干各的，输出全部打一拍，干净、可综合、利于时序收敛。

用环岛交通来类比：一段式就像没有交警也没有红绿灯的路口，谁抢到谁走，混乱且不可预测；二段式像是有了红绿灯但没有黄灯缓冲，切换瞬间容易出问题；三段式则是带清空时间的规范信号灯，每一拍都知道自己该亮哪个灯。主模式控制器要驱动外部引脚、和外部设备打交道，任何毛刺都可能被对方错误采样，所以输出寄存几乎是必须的。

另外还要注意，题主提到的"JTAG状态机""MCU状态机""C语言状态机"，本质和RTL状态机是同一个思维模型，都是"当前状态+输入条件=下一个状态"。区别在于C语言状态机是串行执行，同一时刻只能有一个状态机在跑；RTL状态机是并行硬件，你可以同时例化几十个状态机，每个都在自己的时钟域里独立跳动。这是从软件思维切到RTL思维最容易拧巴的地方。

2.2 三段式状态机的标准模板与代码示例

直接给一个能综合的标准三段式模板，注释按实际工程习惯写。

// 三段式状态机标准模板 module fsm_template #( parameter IDLE = 2'd0, parameter WORK = 2'd1, parameter DONE = 2'd2 )( input wire clk, input wire rst_n, input wire req, output reg done ); reg [1:0] state_c; // 当前态 reg [1:0] state_n; // 次态 // 第一段：状态寄存器，时序逻辑 always @(posedge clk or negedge rst_n) begin if (!rst_n) state_c <= IDLE; else state_c <= state_n; end // 第二段：次态组合逻辑 always @(*) begin state_n = state_c; // 默认保持，防止产生latch case (state_c) IDLE: if (req) state_n = WORK; WORK: if (done) state_n = DONE; DONE: state_n = IDLE; default: state_n = IDLE; // 必须收敛，防死锁 endcase end // 第三段：输出寄存器，按次态判断 always @(posedge clk or negedge rst_n) begin if (!rst_n) done <= 1'b0; else begin case (state_n) DONE: done <= 1'b1; default: done <= 1'b0; endcase end end endmodule

这里三个要点值得展开。第一，第二段里state_n默认赋state_c，是FSM编码里防latch的关键手法，不写这一句综合器会给你推断出锁存器。第二，default分支必须收到一个确定状态，不能悬空，否则状态机一旦走到未定义态就拉不回来了。第三，第三段输出用state_n而不是state_c判断，这样done信号在进入DONE态的那个时钟沿就有效，输出和状态同步跳变，不会晚一个周期。

2.3 状态编码、摩尔米利与复位设计

状态机的编码方式直接影响面积和时序。主模式控制器一般有四个选择：二进制码、格雷码、独热码，以及-onehot和二进制混用。

项目里选编码的建议是：状态少于8个用二进制，状态多且时序紧用独热码，相邻跳变敏感、低功耗场景用格雷码。独热码在一堆状态里找"当前在哪"只需要比较一个bit，组合路径短，FPGA里触发器资源多所以特别常用；ASIC里如果状态很多，独热码占的面积会比较大。JTAG TAP那个16态的状态机，很多实现就是用独热码或二进制，因为它跳变路径复杂，而格雷码只适合线性跳转。

摩尔机和米利机的选择也要说清楚。摩尔机输出只取决于当前状态，稳定但响应慢一拍；米利机输出还看输入条件，响应快但组合逻辑输出容易毛刺。对主模式接口来说，凡是直接驱动外部引脚的控制信号，我都建议做成"寄存器输出的准摩尔机"——判断逻辑按米利写，但输出全都打一拍寄存。这样既拿到米利机的响应速度，又避免了组合毛刺直接对外。

复位设计更不能马虎。状态机必须有确定的复位状态，异步复位要保证rst_n释放时远离时钟沿，否则可能亚稳态。我见过一个产品bug就是异步复位释放瞬间刚好撞上CLK上升沿，状态机随机落到非IDLE状态，系统整个启动流程全乱。工程上的做法是：内部先用同步器把外部复位打两拍，再用异步复位、同步释放的方式产生全局复位信号，顶层所有状态机共用这一个复位。

3. 三态驱动：主模式怎么把引脚"让"出去

3.1 高阻态到底是个什么东西

三态驱动是主模式RTL设计里绕不开的坎，因为主模式模块经常需要驱动双向引脚。所谓三态，就是除了输出0和输出1之外，还有第三种状态：高阻Z。高阻的意思是引脚和内部电路完全断开，既不输出高也不输出低，对外呈现高阻抗。这时候引脚的电平完全由外部设备决定，可以把它理解成"你把手从方向盘上拿开了"。

为什么需要高阻态？一根线上挂了多个设备，同一时刻只能有一个设备主动驱动这条线，其他设备必须"松手"。最典型的就是I2C的SDA线和一些传感器用的单线数据接口。主设备要读数据的时候，必须先把自己的输出驱动关掉，让从设备来拉这根线；如果主设备一直霸占着总线输出，从设备怎么拉都拉不动。

用多人共用一个话筒的场景来解释最贴切：话筒就是那根总线，一个人讲话的时候，其他人都得闭嘴。如果有人不管别人在讲也硬要发声，出来的就是谁也听不懂的混音。硬件上比混音更严重，两个输出驱动同一根线，一个想拉高一个想拉低，轻则逻辑错误，重则芯片过热甚至烧毁。所以三态驱动设计的第一原则就是：同一时刻有且只有一个驱动源。

3.2 三态IO的标准RTL写法

inout端口的RTL写法和普通输入输出完全不同，它不能直接在always块里被赋值，必须用连续赋值assign语句。标准写法如下：

// 标准三态IO模板 module tristate_io ( inout wire data_io, // 双向数据线 input wire oe, // 输出使能，高有效 input wire tx_data, // 要发送的数据 output wire rx_data // 接收到的数据 ); // 输出路径：oe为1时驱动总线，oe为0时释放总线 assign data_io = oe ? tx_data : 1'bz; // 输入路径：始终采样总线，不受oe影响 assign rx_data = data_io; endmodule

这个模板看起来简单，但有几个容易被忽略的细节。第一，rx_data是连续采样的，也就是说即使你正在输出数据，也同时能"听到"总线上的电平。在总线回环测试、多主仲裁时非常有用。第二，oe信号一定要来自寄存器输出，不能是组合逻辑直接产生，否则三态的切换时机不可控。第三，inout端口在Verilog仿真里默认是Z，如果外层testbench不接驱动，你读进来的就是X，仿真根本跑不对。

设计真正的主模式模块时，我通常会把三态控制单独拆成一个IO单元，而不是散写在各个always块里。好处是方便后仿真定位问题，在DFT、IO约束时也能单独处理。FPGA上综合后这个逻辑会被映射成IOBUF原语，如果是ASIC，则对应pad ring里的三态IO单元。RTL层面看是两行assign，物理层面其实把控着芯片的对外引脚。

3.3 三态驱动的三条铁律

写三态驱动这几年，总结下来有三条必须刻在脑子里的铁律。

第一条，方向切换必须留死区。从输出切到输入、或从输入切到输出时，中间至少留一拍高阻。因为总线电平切换不是瞬间完成的，有上升下降时间，如果前一个设备刚松手、后一个设备立刻驱动，总线上会出现短暂的驱动重叠期，这段时间的电平是不确定的。实际项目里，这个"死区"拍数由总线速度和线长决定，宁可多等一拍也不要省。

第二条，三态输出控制信号必须能复位。芯片上电瞬间、系统复位后，所有对外三态引脚都应该处于高阻态或安全的默认态，不能处于驱动状态。否则芯片还没初始化完，引脚就已经在和外部设备打架了。这也是很多人犯的错误：oe信号没有复位值，上电是一堆X，对外表现就是引脚乱驱动。

第三条，不要把inout端口直接接进功能逻辑。要过一层缓冲再使用。比如从data_io采进来的信号，先打一拍寄存器，再去参与状态判断。因为总线上的信号相对内部时钟是异步的，直接接进组合逻辑很容易采到亚稳态。主模式自己是时钟的发起方，通常可以协调好采样点，但该打的拍一定要打，不能因为"时序看起来差不多"就偷懒。

4. 完整实战：一个带单线双向数据口的主模式控制器

4.1 需求定义与引脚规划

用一个真实感很强的例子来收束全篇：设计一个"半双工单线SPI Master"，这是很多温湿度传感器、单线存储器使用的接口形态。主设备产生SCK时钟和片选CS，数据通过一根双向线SIO传输，高位在前，每次收发8bit。

功能需求列清楚：支持主机发起写操作（主机在SIO上逐位驱动数据）、支持主机发起读操作（主机释放SIO，从机驱动数据）、片选极性可配、时钟极性可配。

端口规划如下表。

这个设计把主模式RTL设计的核心矛盾全部暴露出来了：既有状态机调度，又有三态驱动，还要处理数据通路里收发方向的切换。注意sio是三态，sclk和cs_n是纯输出。很多人看到inout端口就发怵，实际只要记住一条：inout永远是assign出来的，控制逻辑提供方向信号即可。

4.2 状态机设计：从需求映射到状态转移

按三段式状态机的思路，把一次读写事务拆成几个状态。这里用FSMD（有限状态机+数据通路）的思路：状态机只管跳转，数据移位、计数器、方向切换都放在数据通路部分。

状态定义如下：

• IDLE：空闲，cs_n=1，sclk=默认电平，sio为高阻，等待start。
• START：cs_n拉低，准备SIO方向，等待建立时间。
• SHIFT：按位传输数据，sclk产生8个时钟脉冲，SIO方向由rw决定，写操作时主机驱动SIO，读操作时主机释放SIO由从机驱动。
• STOP：cs_n拉高，SIO回到高阻，事务结束。

次态跳转的逻辑很直白：IDLE在start有效时进START；START一个周期后进SHIFT；SHIFT里用bit_counter数到7且时钟完成，进STOP；STOP一拍回IDLE。要注意的是SHIFT状态里每个bit还需要一个内部节拍计数器来控制sclk的高低电平宽度，这是主模式设计里最容易被忽略的部分——光有状态机的"宏观状态"还不够，每个状态内部的"微观节拍"也需要计数。

时钟极性这里稍微展开。SPI协议里有CPOL和CPHA的配置，决定sclk空闲电平是低还是高、数据在哪个边沿采样。主模式的优势就在于这些都由你说了算，你可以自由配置；劣势也在这里——配置错了从机就完全对不上。我实现时一般把sclk逻辑放在SHIFT状态内部用计数器产生，而不是单独一个状态，这样不会产生额外的状态跳变毛刺。

4.3 RTL实现：状态机加三态IO的完整缝合

直接给出这个设计的关键RTL代码。为了控制篇幅，我摘出最核心的状态机和三态控制部分。

// 半双工单线SPI Master 核心逻辑 module spim_single # (parameter PRESCALE = 25) ( input wire clk, input wire rst_n, input wire start, input wire rw, input wire [7:0] tx_data, output reg [7:0] rx_data, output reg busy, output reg sclk, output reg cs_n, inout wire sio ); localparam IDLE = 3'd0; localparam START = 3'd1; localparam SHIFT = 3'd2; localparam STOP = 3'd3; reg [2:0] state_c, state_n; reg [2:0] bit_cnt; reg [7:0] shift_reg; reg sio_oe; // SIO输出使能 reg sio_out; // SIO输出数据 wire sio_in; // SIO输入数据 // 三态IO：写操作时驱动SIO，读操作或空闲时释放 assign sio = sio_oe ? sio_out : 1'bz; assign sio_in = sio; // 第一段：状态寄存器 always @(posedge clk or negedge rst_n) begin if (!rst_n) state_c <= IDLE; else state_c <= state_n; end // 第二段：次态组合逻辑 always @(*) begin state_n = state_c; case (state_c) IDLE: if (start) state_n = START; START: state_n = SHIFT; SHIFT: if (bit_cnt == 3'd7) state_n = STOP; STOP: state_n = IDLE; default: state_n = IDLE; endcase end // 数据通路：移位寄存器与方向控制 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin shift_reg <= 8'd0; bit_cnt <= 3'd0; rx_data <= 8'd0; end else begin case (state_n) IDLE: begin bit_cnt <= 3'd0; if (start) shift_reg <= tx_data; end SHIFT: begin if (rw) begin // 写：主机驱动SIO sio_oe <= 1'b1; sio_out <= shift_reg[7]; shift_reg <= {shift_reg[6:0], 1'b0}; end else begin // 读：主机释放SIO，采样从机数据 sio_oe <= 1'b0; shift_reg <= {shift_reg[6:0], sio_in}; end bit_cnt <= bit_cnt + 1'b1; end default: begin sio_oe <= 1'b0; bit_cnt <= 3'd0; end endcase end end // 第三段：输出寄存器（busy、cs_n、sclk） always @(posedge clk or negedge rst_n) begin if (!rst_n) begin busy <= 1'b0; cs_n <= 1'b1; sclk <= 1'b0; end else begin case (state_n) IDLE: begin busy <= 1'b0; cs_n <= 1'b1; sclk <= 1'b0; end START: begin busy <= 1'b1; cs_n <= 1'b0; end SHIFT: begin sclk <= toggle_clock(); end STOP: begin busy <= 1'b1; cs_n <= 1'b1; sclk <= 1'b0; end endcase end end endmodule

这段代码里sclk的toggle_clock函数省略了内部分频计数器，实际实现时需要维护一个节拍计数器，在计数值一半时翻转sclk。这是主模式产生时钟的标准手法：不用独立PLL，用系统时钟分频产生外设时钟，节省资源且保证相位可控。

关键点在于shift_reg的移位方向：写模式时sio_oe有效，把shift_reg最高位送上SIO，同时左移；读模式时sio_oe无效，把SIO上的输入采样进shift_reg最低位。一个寄存器同时承担发送和接收的功能，收发方向由rw决定，这就是半双工单线接口的本质。

4.4 分频参数的计算方法

上述代码里PRESCALE参数决定了SCK的频率。假设系统时钟50MHz，目标SCK为1MHz，分频公式是：

SCK频率 = 系统时钟 / ((PRESCALE + 1) × 2)

代入计算：50MHz / ((PRESCALE + 1) × 2) = 1MHz，得到PRESCALE = 24。因为每个SCK周期需要计数到PRESCALE再翻转，而一个完整周期需要两次翻转，所以乘以2。如果目标SCK是4MHz，则50MHz / ((PRESCALE+1)×2) = 4MHz，PRESCALE + 1 = 6.25，取整为6，实际SCK变成50/(7×2) ≈ 3.57MHz，误差约10%，很多慢速传感器完全能接受。

这里提醒一点：分频值的计算不要简简单单用除法器，直接用计数器在每个sclk翻转点自增就行。如果要求高精度，比如某些从设备要求SCK不超过规定上限，你需要往上取整而不是四舍五入。我在项目里吃过一次亏，四舍五入取分频值导致实际SCK超了规格，低温环境下从机直接罢工，排查了两天才发现是分频参数的问题。

5. 仿真与调试：状态机和三态的那些坑

5.1 仿真里高阻态Z和X态的纠缠

主模式设计仿真时最让人抓狂的就是Z和X。Z本来是正常的高阻态，但它一旦和不该出现的地方碰到一起，就会变成全仿真的灾难。

最常见的场景：testbench里没有给inout端口接驱动或者上拉，主设备在读模式释放SIO后，SIO就悬空了。此时如果你去赋值shift_reg <= {shift_reg[6:0], sio_in}，采进来的就是X。这个X会一路传播，移位寄存器变成一坨X，后面rx_data全是X，整个仿真波形根本没法看。

解决办法有三个层次。第一，testbench里给SIO加上拉或下拉电阻模型，Verilog里可以用pullup(sio)语句；第二，从设备模型在地址匹配时要主动驱动SIO，模拟真实从机的行为；第三，如果只是做模块级仿真，可以在读模式下直接force SIO为预期的值，验证时序逻辑。

另外，Z在综合后会变成真实的断开状态，但在RTL仿真里它是特殊的四态值，所有比较运算里Z都不等于0也不等于1。所以写验证代码时不要写if (sio_in === 1'b0)这种死板的判断，有些仿真器对三态处理不一致，跨仿真器移植时容易出诡异结果。

5.2 三态总线多驱动问题的定位方法

实际项目中，三态总线最常见的bug是多驱动。两个模块同时把oe拉高，总线上两个驱动源打架。这种问题在仿真里往往不报错，需要你用$display或波形交叉检查才能发现。

我的定位三板斧：第一，仿真波形里把总线相关所有oe信号全部拉出来，在总线出现异常跳变的时刻检查是否有多个oe同时为高；第二，用$monitor在oe变化时打印当前所有驱动模块的名字和oe值；第三，上板调试时用示波器看总线波形，如果看到明显的中间电平而不是干净的0/1，基本就是多驱动了。

防止多驱动要从设计源头解决。主模式控制器里，oe信号必须来自中央状态机统一管理，任何外围模块都不允许直接驱动总线。如果系统里确实存在多个主设备分时占用总线，那还要加一层仲裁器，保证同一时刻只有一个主设备拿到总线授权。在RTL中，这层仲裁的输出就是所有主设备oe信号的与逻辑——只有拿到授权的设备才能把oe拉高。

5.3 常见问题速查表

把主模式RTL设计里常见问题按现象、原因、对策整理出来，可以直接对照排查。

这个表格基本覆盖了我在实际项目里遇到过的九成问题。每条背后都在强调一个共同点：主模式RTL设计的可靠性，靠的不是某个精巧的技巧，而是每一步都按规范来。状态机收敛、复位可控、三态使能统一、采样点正确——这些基础动作做到位，绝大多数问题都不会出现。

5.4 综合与DFT阶段对RTL的约束

这里专门提一个热搜里大家很关心的问题：DFT插复位怎么改RTL。DFT工具做扫描链插入时，会在每个寄存器前面加MUX和测试时钟控制。如果RTL写得随意，比如状态机里用了多个异步复位源，或者三态oe信号在测试模式下没有强制控制，DFT插入就无法正常进行。

从RTL设计端配合DFT，核心就几条。第一，状态机只用统一的一个复位源，不要在局部另加异步复位，否则扫描链上每个寄存器的复位逻辑都不一样，DFT工具没法统一控制。第二，三态控制信号oe在测试模式下必须能被强制。通常做法是加一个test_mode端口，测试模式下强制oe为0（高阻），或者强制为可控值，避免扫描移位时总线被意外驱动。第三，所有寄存器复位后要有确定值，尤其是状态寄存器和oe。这些不是DFT工程师单方面改脚本能解决的，RTL源头不配合，后段怎么修都别扭。

综合阶段对三态也要提前规划。FPGA里inout会映射到IOBUF原语，通常可以直接用；ASIC里如果内部总线用三态做，综合时要特别注意三态总线的竞争和DFT的可控性。行业内更推荐的做法是：芯片内部总线用MUX替代三态，只有对外引脚才用真三态。内部逻辑一旦用三态，后端的DRC和DFT都会头疼得多。

6. 实操心得与代码评审清单

最后分享几条从实战里沉淀下来的经验。主模式控制器写完之后，我每次做代码评审，手里都捏着一份固定清单，现在可以直接交给大家。

第一遍先看结构：状态机是不是三段式，输出有没有全部寄存，状态转移的default有没有写，复位是不是统一源。这一遍能筛掉一半的问题。第二遍盯三态：所有inout端口的oe是不是都来自状态机可控信号，oe和总线数据方向切换有没有死区，上电复位后所有对外引脚是不是安全状态。第三遍查数据通路：移位方向对不对、采样边沿和时钟极性是否匹配、收发切换时有没有额外周期。

还有一个容易被忽略的心得：主模式模块的对外时序，最好在RTL里就写成参数化、可配置的形式。时钟极性、分频系数、位宽、建立时间，都做成parameter或者寄存器配置，不要写死在代码里。因为同一个主模式控制器，在不同项目里接的外设千差万别，可配置的主模式模块才是复用价值最高的模块。我在实际项目中靠着这个习惯，一个SPI主控制器换过三款FPGA、接过五种不同规格的从设备，每次只需要改参数顶多加点状态，省了非常多时间。

最后再说一个小的调试技巧：上板出问题的时候，先别急着看逻辑，先看时钟和片选波形。主模式是时钟和事务的发起方，只要sclk稳定、cs_n边沿干净，内部数据通路的定位范围就缩小了一大半。反过来，如果连时钟都歪歪扭扭，就别花时间查状态机了，先把时钟树和IO约束理清楚。这个排错顺序，帮我省下了无数个加班夜。