Máquinas de estados finitos en Verilog: el patrón FSM estándar

Qué es una FSM

Una máquina de estados finitos es un controlador que:

• Mantiene uno de un conjunto fijo de estados con nombre en cualquier momento dado.
• Transita entre estados basándose en entradas (y posiblemente en el estado actual).
• Produce salidas que dependen del estado actual (y quizá de las entradas actuales).

Eso cubre una cantidad sorprendente de diseño digital: controladores de semáforos, transmisores UART, controladores de memoria, manejadores de protocolos de red, decodificadores de instrucciones, cualquier cosa que tenga modos de operación discretos.

Lo que hace que las FSMs se sientan distintas de la lógica de datapath es que son estados, no valores. Un contador avanza por 1, 2, 3, 4. Una FSM avanza por IDLE, FETCHING, BUSY, DONE - misma forma, pero los estados tienen nombre y las transiciones tienen significado.

El patrón de dos procesos

La FSM estándar de Verilog usa dos bloques always:

1. Un bloque sincronizado por reloj que captura el registro de estado en cada flanco de reloj. Usa asignación no bloqueante. Pequeño - normalmente tres líneas.
2. Un bloque combinacional que usa un case sobre el estado actual para calcular el siguiente estado y las salidas. Usa asignación bloqueante. El código "interesante" vive aquí.

Esta separación tiene tres beneficios: te fuerza a pensar en el estado explícitamente, produce hardware que mapea limpiamente a "un registro más un bloque combinacional" y es el estándar - cualquiera que lea tu Verilog lo reconocerá al instante.

Un ejemplo trabajado: detector de secuencia

Una FSM clásica para enseñar: detecta la secuencia de bits 1011 en una entrada serie. Saca un pulso de un ciclo cuando la secuencia se completa.

module seq_detect_1011(
    input  wire clk,
    input  wire reset,
    input  wire in,
    output reg  detected
);
    // State encoding - localparam because it's an implementation detail.
    localparam S0 = 3'd0;   // no progress
    localparam S1 = 3'd1;   // saw "1"
    localparam S2 = 3'd2;   // saw "10"
    localparam S3 = 3'd3;   // saw "101"

    reg [2:0] state, next_state;

    // ---------------------------------------------------------------------
    // Block 1: clocked state register
    // ---------------------------------------------------------------------
    always @(posedge clk) begin
        if (reset) state <= S0;
        else       state <= next_state;
    end

    // ---------------------------------------------------------------------
    // Block 2: combinational next-state + output logic
    // ---------------------------------------------------------------------
    always @(*) begin
        // Defaults - so we never accidentally infer a latch.
        next_state = state;
        detected   = 1'b0;

        case (state)
            S0: if (in)  next_state = S1;
            S1: if (~in) next_state = S2;
                else     next_state = S1;
            S2: if (in)  next_state = S3;
                else     next_state = S0;
            S3: if (in) begin
                    next_state = S1;
                    detected   = 1'b1;     // emit pulse, keep looking
                end else begin
                    next_state = S2;
                    detected   = 1'b1;     // same - pulse, then look from S2
                end
            default: next_state = S0;
        endcase
    end
endmodule

module test;
    reg clk = 0;
    reg reset = 1;
    reg in = 0;
    wire detected;

    seq_detect_1011 dut(.clk(clk), .reset(reset), .in(in), .detected(detected));

    always #5 clk = ~clk;

    initial begin
        #12 reset = 0;
        // Drive the input sequence: 1 0 1 1 (should detect at the second-to-last)
        in = 1; #10;
        in = 0; #10;
        in = 1; #10;
        in = 1; #10;    // <-- detected should pulse here
        in = 0; #10;
        // Try again with an overlapping sequence: 1 0 1 1 0 1 1
        in = 1; #10;
        in = 1; #10;    // another detection
        #20 $finish;
    end

    always @(posedge clk)
        $display("t=%0t in=%b state=%0d detected=%b", $time, in, dut.state, detected);
endmodule

La estructura de dos bloques es el punto de bala de arriba. Los detalles de limpieza valen la pena señalarlos:

• Valores por defecto al inicio del bloque combinacional. next_state = state (quédate donde estás) y detected = 1'b0 (sin pulso) son las asignaciones "no hagas nada". Cada rama del case solo establece lo que difiere. Esto hace imposible inferir un latch.
• localparam para los nombres de estado. Quien lea el módulo piensa en S0, S1, S2, S3, no en 3'd0, 3'd1. El sintetizador hace la sustitución.
• Sin salidas desde el bloque sincronizado. Toda la lógica de "qué hace este estado" vive en el bloque combinacional. El bloque sincronizado no es responsable de nada excepto mantener el estado actual.

Moore vs Mealy

Moore: la salida depende solo del estado actual. Mealy: la salida depende del estado actual y de las entradas actuales.

En el ejemplo de arriba, detected se establece dentro de la rama S3 solo cuando in coincide con uno de los patrones esperados que completan la secuencia. Esa es una salida Mealy - depende de in además de state. Una versión Moore tendría un estado separado para "recién detectado" y pondría detected = 1 cuando ese estado estuviese activo; la salida pulsaría un ciclo más tarde pero nunca sería sensible a un glitch en in.

Los dos estilos son válidos. Moore es el por defecto en los libros de texto porque las salidas están garantizadas a no tener glitches cuando las entradas cambian a mitad de ciclo. Mealy es más rápida (sin latencia de registro para salidas dirigidas por entrada) y produce hardware más pequeño en muchos casos. Elige según el protocolo que estés implementando.

Codificación de estados: binaria, one-hot, Gray

El patrón de bits que asignas a cada estado importa para el área y la velocidad:

• Binaria (S0 = 3'd0, S1 = 3'd1, ...): registro de estado más pequeño - $\lceil \log_2 N \rceil$ bits para $N$ estados. Lógica de decodificación máxima.
• One-hot (S0 = 4'b0001, S1 = 4'b0010, ...): N bits para N estados. La lógica de decodificación es trivial (cada estado es un wire); las transiciones son rápidas. Las FPGAs a menudo lo eligen por defecto.
• Código Gray: estados consecutivos difieren en un bit. Útil cuando los bits de estado cruzan dominios de reloj.

La mayoría de las herramientas de síntesis modernas eligen la codificación por ti (Vivado, Quartus, Design Compiler todos tienen un modo automático que prueba cada una y elige la mejor). Rara vez necesitas especificar. Especifica cuando lo hagas: la mayoría de las herramientas aceptan una anotación attribute o un pragma (* fsm_encoding = "one_hot" *).

Una variante de tres bloques

Ocasionalmente verás la FSM dividida en tres: un bloque sincronizado para el estado, un bloque combinacional para el siguiente estado, un bloque combinacional para las salidas. Eso es el patrón de dos bloques con el cálculo de salidas sacado a su propio bloque:

// State register
always @(posedge clk) ...

// Next-state logic
always @(*) ...

// Output logic
always @(*) begin
    case (state)
        ...
    endcase
end

El estilo de salidas separadas es útil cuando las salidas son grandes y la lógica de siguiente estado quedaría desordenada si estuvieran en el mismo bloque. Para FSMs pequeñas es excesivo.

Qué hace default en una FSM

La sentencia case de cada FSM debería tener una rama default. Dos razones:

1. Seguridad: si el registro de estado de alguna manera toma un valor inválido (corrupción, bug, reset parcial), default lo devuelve a un estado conocido.
2. Pista de síntesis: cuando los cases explícitos son exhaustivos (un estado de 2 bits con los 4 valores manejados, por ejemplo), default: next_state = 'x; le dice al sintetizador "prometo que el default es inalcanzable, optimiza libremente". Si el camino inalcanzable se alcanza en simulación, el x resultante se propaga y surge el bug inmediatamente.

default: begin
    next_state = S0;   // safe recovery
    // or
    next_state = 'x;   // unreachable, optimize freely
end

Elige según si has probado que el default es realmente inalcanzable.

Cosas que vigilar

Olvidar los valores por defecto al inicio del bloque combinacional. Sin next_state = state y los valores por defecto de las salidas, una rama que no asigna todo deja escapar un latch.

Poner salidas en el bloque sincronizado. Si detected <= 1 vive en el bloque always @(posedge clk), la salida está registrada - aparece un ciclo tarde. Eso puede ser intencional (una salida "Mealy registrada"), pero es un error de diseño accidental común cuando la especificación pide un pulso instantáneo.

Mezclar blocking y non-blocking. Bloque sincronizado: <=. Bloque combinacional: =. Mezclar los dos dentro de un bloque es una condición de carrera.

Un bloque always combinacional que referencia next_state y asigna state. Eso construye un bucle de realimentación que el simulador no puede resolver. El bloque sincronizado posee state; el combinacional posee next_state; nunca dejes que ninguno toque la variable del otro.

Qué viene a continuación

Ya puedes construir cualquier controlador que puedas describir. El siguiente capítulo da un paso atrás del diseño sintetizable y cubre los testbenches que lo ejercitan - cómo excitar estímulos, observar salidas, volcar formas de onda y validar que tus módulos realmente hacen lo que crees.