Mealy vs Moore: two ways to build a state machine (and a note on feedback)

Every finite state machine is a small loop: a register holds the current state, some logic decides the next state, and some logic decides the outputs. The only real choice is where the outputs come from, and that single decision is the whole difference between a Moore machine and a Mealy machine.

• Moore: the output is a function of the state alone.
• Mealy: the output is a function of the state and the current input.

Structurally they're almost identical. The one extra wire, the red one that carries the input straight into the output logic, is the entire distinction. It sounds tiny. It changes the state count, the timing, and the glitch behavior.

Same job, two machines

Let's detect the pattern 11 in a serial bit stream (overlapping, so 111 counts twice). In Moore, the output has to be a state, so you need a state that means "I have just seen two 1s." In Mealy, the output rides on a transition, so you can fold that into the arrows and save a state:

Notice the state counts: Moore needs three states, Mealy needs two. That is the classic tradeoff. A Moore machine often needs an extra state for each distinct output condition, because the output has nowhere to live except in the state.

In Verilog the two are a few lines apart:

// MEALY: output = f(state, input). One flip-flop.
module detect11_mealy (input clk, input rst, input din, output y);
    reg state;                    // 1 = the previous bit was a 1
    always @(posedge clk) state <= rst ? 1'b0 : din;
    assign y = state & din;       // saw a 1, and here comes another one
endmodule

// MOORE: output = f(state). Two flip-flops (an extra "detected" state).
module detect11_moore (input clk, input rst, input din, output y);
    reg [1:0] state, nxt;         // S0=0, S1=1 (one 1), S2=2 (two 1s)
    always @(posedge clk) state <= rst ? 2'd0 : nxt;
    always @* case (state)
        2'd0: nxt = din ? 2'd1 : 2'd0;
        2'd1: nxt = din ? 2'd2 : 2'd0;
        2'd2: nxt = din ? 2'd2 : 2'd0;
        default: nxt = 2'd0;
    endcase
    assign y = (state == 2'd2);   // the output is just a decode of the state
endmodule

Run them side by side

Here are both, fed the same bit stream. Press Run and watch y_mealy and y_moore: the Mealy output pulses the same cycle the second 1 arrives, while the Moore output pulses one cycle later (it has to wait for the state register to update). Same detections, shifted by a clock.

That one-cycle shift is the practical heart of it. Mealy is faster to react but its output is combinational, so it can glitch and it changes mid-cycle with the input. Moore is a clean decode of a registered state, so it's glitch-free and steady, at the cost of a cycle of latency and usually an extra flip-flop or two.

The tradeoff at a glance

Rules of thumb: reach for Moore when the output drives something timing-sensitive (a clock enable, an external pin, another clock domain) and you want it clean and predictable. Reach for Mealy when you want the fewest states or the fastest reaction and you can tolerate a combinational output. And you can always convert one into the other; they're the same computation wearing different clothes. Our FSM generator will build either from a state table.

A deeper thread: feedback, compression, and why neural nets struggle with it

Step back and look at what that little loop is really doing. The state register feeds back into the next-state logic, and that feedback is the entire source of the machine's power. Break the loop and you have a pile of combinational gates that only knows the present. Close the loop and you have something with memory and dynamics: a two-state machine can recognize a pattern in a stream of any length; a 32-bit counter folds four billion distinct time steps into 32 wires. The feedback loop is compressing an unbounded history into a handful of bits of state.

That compression is a property of recurrence, and recurrence is slippery. Feedback loops in the physical world do things that are genuinely hard to simulate: they oscillate, they can wander into chaos, they can sit balanced at a metastable point. A ring oscillator is the clean example: a structural loop of ideal gates settles to an undefined X in a simulator, yet rings happily in silicon, because the real behavior emerges from the loop's physics, not from any closed-form function of its inputs. A loop can interpolate between states and extrapolate a trajectory forward in ways a feedforward circuit simply cannot.

This is exactly where modern neural networks have an awkward relationship with recurrence. A feedforward network, and a transformer-based LLM at its core, computes each output as a fixed-depth function of its input, with no loop. To "remember," a transformer re-reads its entire context window on every token, which is expensive (the cost grows with the square of the context) and hard-bounded by the window size. It carries the raw past around rather than folding it into an evolving state. It has no state register feeding back.

A recurrent system does the opposite. An RNN, a state machine, arguably a brain, folds history into a small state and updates it step by step. That state is a compression of everything that came before, and it lets the system run forever in constant memory and cheaply extrapolate what comes next. Pure feedforward models can't easily get this, because they have no loop to carry and compress state across steps. It's the same reason a Moore machine needs a state to "remember" it saw two 1s: without a loop, memory has nowhere to live.

Tellingly, the field keeps reinventing the feedback loop. State-space models like S4 and Mamba, and linear-attention and RWKV-style designs, deliberately put a recurrent state back into the model so it can squeeze a long history into a fixed-size state and run in linear time, much closer to how a dynamical system, or a humble FSM, behaves. None of this makes transformers wrong; they work astonishingly well. But the tension is real: carry the whole context, or compress it into state that feeds back. The Mealy/Moore loop is the tiniest, most exact version of that same choice, and it has been quietly running in every sequential circuit the whole time.

Keep going

Build one yourself: open the state machines lesson, or generate an FSM from a table with the FSM generator.