Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
    • Controller and Datapath
    • Moore vs Mealy
      • Behavioral Difference
      • Side-by-Side: A Sequence Detector
      • Registered Mealy Outputs
      • Choosing and Verifying
    • State Encoding
    • Multi-Cycle Sequencers
    • UART Transmitter
    • Memory Controller
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Moore vs Mealy
  1. Topics
  2. RTL Design
  3. FSM & Control
  4. Moore vs Mealy
  5. Choosing and Verifying

Part 4 · FSM & Control · Intermediate

Choosing and Verifying

A practical decision rule for Moore versus Mealy, and the checks that catch the usual mistakes.

On this page

    Why this matters

    Output style is a timing decision made at the destination. Pick it, then prove it by reaching every state through legal inputs, because forcing the state register hides reset and encoding bugs.

    After this lesson you can: choose Moore, Mealy or registered outputs for a destination, and write a checklist that verifies the FSM.

    A decision rule

    Match the output style to its destination. Boundaries want registered outputs, and local fast paths want Mealy.

    Situation

    Pick

    Output crosses a block or chip boundary

    Specify receiver timing/latency; register where the interface requires it

    Output crosses a clock-domain boundary

    Use the appropriate synchronization or handshake protocol; source registration alone is insufficient

    Output must not glitch

    Registered output, or an explicitly justified hazard-free decode; Moore alone is insufficient

    Local control signal that must react this very cycle (e.g. a handshake that cannot add latency)

    Mealy

    State count must be tiny (very small block)

    Mealy

    You are unsure

    Moore: simpler timing, easier to verify

    Verification checklist

    1. Reset state is legal and outputs are known after reset.

    2. Intended states are reachable through legal inputs. Progress holds under the specified environment assumptions: e.g. a WAIT_ACK state progresses only if an acknowledgement arrives. Terminal/error states may intentionally absorb inputs until reset; reject prohibited lock-up, not every non-returning path.

    3. Outputs are assigned a default at the top of the combinational block, so no latch is inferred.

    4. For Mealy outputs: inputs are stable before the clock edge in the testbench, and the check happens after settling.

    5. Compare against a reference or a cycle-accurate model; for FSMs with small input alphabets, test every state × input combination.

    6. Check illegal states (see state encoding): what happens after a bit-flip?

    Common mistakes

    The check below reaches every state through legal inputs rather than forcing the state register. Forcing is quicker, but it can hide reset and encoding bugs, because it visits states the real machine might never enter.

    Interview

    Explain which paths the receiver must time: Moore removes a direct input-to-output path but can still have decode hazards. Mealy uses fewer states in this detector. Registration creates a flop-driven output boundary; a clock-domain crossing additionally needs the appropriate transfer protocol.

    Check yourself Name two properties you would check on any FSM, regardless of style.

    Outputs are fully defined at the specified observation points, and intended states are reachable. Also check the specified progress/terminal behavior under explicit environment assumptions and the illegal-state policy; unconditional return to reset is not a universal requirement.

    Testbench

    The listing reaches all three states through legal prefixes and checks all six state/input combinations: Moore y before the edge must reflect the current state, then state and y after the edge must reflect the transition table. Coverage records the actually observed pre-edge state/input pair.

    det_probe.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    // Exhaustive state x input check for the two-ones detector.
    // Reach each state through legal inputs, apply each input, and compare with the transition table.
    module det_probe (input logic clk, rst_n, x, output logic y, output logic [1:0] st);
      typedef enum logic [1:0] {S0, S1, S11} state_t;
      state_t state, next;
      always_comb begin
        next = state;
        unique case (state)
          S0:      if (x)  next = S1;
          S1:      if (x)  next = S11; else next = S0;
          S11:     if (!x) next = S0;
          default: next = S0;
        endcase
      end
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) state <= S0; else state <= next;
      assign y  = (state == S11);
      assign st = state;
    endmodule
    

    Remember

    • Boundaries want registered outputs, and local fast paths want Mealy.

    • Reach every state through legal inputs rather than forcing the state register.

    • Check reset state, defaults, reachability, progress under the environment and illegal-state behaviour.

    Keep going

    • Practice: FSM verification strategy: coverage and assertions

    • Interview: run a mock interview on this topic

    Related topics

    • State encoding

    Previous

    98 / 350

    Next: State Encoding

    Up next

    Up nextState Encoding

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Behavioral Difference
    • Side-by-Side: A Sequence Detector