Building a Sequence Detector: State Table to Working Circuit

Turning a completed state table into a working sequence detector: the clocked state register, the combinational next-state block, and a Mealy-style output line.

Updated 2026-07-21

Once a state table is complete, building the circuit is mechanical: the dual-block FSM pattern turns each row directly into either a case item or a comparison.

reg [1:0] cur_state, nxt_state;

// Block 1: state register — the only clocked piece
always @(posedge clk) begin
  if (reset) cur_state <= A0;
  else       cur_state <= nxt_state;
end

// Block 2: next-state logic — one case item per state, reading straight off the table
always @(*) begin
  nxt_state = cur_state;              // safe default: stay unless a condition below fires
  case (cur_state)
    A0: if (bit_in) nxt_state = A1;
    A1: if (bit_in) nxt_state = A1; else nxt_state = A2;
    A2: if (bit_in) nxt_state = A1; else nxt_state = A3;
    A3: if (bit_in) nxt_state = A1; else nxt_state = A0;
  endcase
end

The state register never changes across a whole family of detectors — it is the same clocked pattern from Module 3, applied to a multi-bit state value. The next-state block is where the state table actually lives: each case item's condition and target come straight from that state's row (or rows) in the table, including the "reset all the way back" rows that trip learners up.

The output line is the one piece that depends on WHEN a detector needs to react, and it depends on how the states themselves were defined. With this four-state, partial-match encoding — where A3 means "matched one bit short of the full pattern," not "fully matched" — a state-only expression, cur_state == A3, is true one bit too early, before the final bit has actually arrived. Reading the current input directly inside the output expression fixes that:

assign hit = (cur_state == A3) && bit_in;

This is a Mealy-style output: it depends on state AND the current input, and it asserts the instant the deciding bit shows up, without waiting for the next clock edge. That one-cycle-earlier reaction is exactly the tradeoff the Moore-versus-Mealy comparison introduced — reading an input directly costs the state-only stability a Moore output keeps by default, and a detector that needs to flag a match the moment it completes is a case where that tradeoff is worth making. A Moore-style detector is not impossible here — it would add one more state meaning "fully matched," and assert from that state alone, one cycle later than the Mealy version. The encoding this guide uses (one state per partial match, capped one bit short of the full pattern) is exactly the case where Mealy needs one fewer state than the Moore equivalent.