FSM with output logic in Verilog - Deep Dive

Overview - FSM with output logic

What is it?

A Finite State Machine (FSM) with output logic is a digital circuit design pattern that changes its output based on its current state and inputs. It uses a set of defined states and rules to decide what output to produce and how to move between states. This helps control complex behaviors in hardware like communication protocols or control units. The output logic can be either dependent only on the current state or on both the state and inputs.

Why it matters

Without FSMs with output logic, designing hardware that reacts correctly to sequences of inputs would be chaotic and error-prone. They provide a clear, organized way to handle complex timing and control tasks in electronics. This makes devices reliable and predictable, which is crucial for everything from simple gadgets to advanced computers. Without this concept, hardware design would be much slower and more prone to bugs.

Where it fits

Before learning FSM with output logic, you should understand basic digital logic, combinational and sequential circuits, and simple FSM concepts. After mastering this, you can explore advanced FSM types like Mealy and Moore machines, timing analysis, and hardware description language optimizations.

Mental Model

Core Idea

An FSM with output logic produces outputs based on its current state and inputs, guiding hardware behavior step-by-step.

Think of it like...

It's like a vending machine that changes its display and actions depending on what buttons you press and what stage of the transaction you're in.

┌─────────────┐       input       ┌─────────────┐
│   Current   │ ───────────────▶ │   Next      │
│   State     │                  │   State     │
└─────┬───────┘                  └─────┬───────┘
      │                               │
      │ output logic depends on       │
      │ current state and inputs      │
      ▼                               ▼
┌─────────────┐                  ┌─────────────┐
│   Output    │                  │   FSM       │
│   Signals   │                  │   Logic     │
└─────────────┘                  └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding FSM Basics

Concept: Introduce what a finite state machine is and how states and transitions work.

An FSM is a system that can be in one of a limited number of states at any time. It changes states based on inputs. For example, a traffic light cycles through states like Green, Yellow, and Red. Each state lasts some time, then moves to the next based on rules.

Result

You understand that FSMs model systems with clear states and rules for moving between them.

Understanding states and transitions is the foundation for controlling hardware behavior step-by-step.

2

Foundation

Combinational vs Sequential Logic

Concept: Explain the difference between combinational logic (outputs depend only on inputs) and sequential logic (outputs depend on inputs and past states).

Combinational logic produces outputs instantly from current inputs, like a calculator adding numbers. Sequential logic remembers past inputs using memory elements like flip-flops, so outputs depend on history. FSMs use sequential logic to remember their current state.

Result

You see why FSMs need memory to track states, unlike simple logic gates.

Knowing this difference helps you grasp why FSMs use flip-flops and clocks to manage state.

3

Intermediate

Moore vs Mealy Output Logic

🤔Before reading on: do you think FSM outputs depend only on states or also on inputs? Commit to your answer.

Concept: Introduce two common FSM output types: Moore (outputs depend only on state) and Mealy (outputs depend on state and inputs).

In a Moore machine, outputs change only when the FSM enters a new state. This makes outputs stable but sometimes slower to react. In a Mealy machine, outputs can change immediately when inputs change, even within the same state, making it faster but more complex.

Result

You can distinguish when to use Moore or Mealy output logic based on design needs.

Understanding output dependencies helps you design FSMs that balance speed and stability.

4

Intermediate

Implementing FSM with Output Logic in Verilog

🤔Before reading on: do you think output logic should be inside the state transition block or separate? Commit to your answer.

Concept: Show how to write Verilog code for FSMs with output logic, separating state transitions and output assignments.

In Verilog, FSMs are often coded with three parts: state register (holds current state), next state logic (decides next state), and output logic (decides outputs). Output logic can be inside a separate always block or combined with next state logic depending on Moore or Mealy style.

Result

You can write clean, modular Verilog FSM code with output logic.

Separating output logic clarifies design and prevents bugs in hardware synthesis.

5

Intermediate

Example: Simple FSM with Output Logic

Concept: Walk through a complete Verilog example of an FSM that outputs signals based on states and inputs.

Consider a FSM with two states: IDLE and ACTIVE. When input 'start' is high, FSM moves to ACTIVE and output 'busy' goes high. When 'done' input is high, FSM returns to IDLE and 'busy' goes low. The output depends on the current state (Moore style).

Result

You see how state and input control outputs in a real Verilog FSM.

Seeing a full example connects theory to practical hardware design.

6

Advanced

Handling Output Glitches and Timing

🤔Before reading on: do you think outputs in Mealy FSMs can glitch when inputs change? Commit to your answer.

Concept: Explain how output logic timing can cause glitches and how to avoid them in FSM design.

Mealy outputs depend on inputs and can change asynchronously with state changes, causing glitches. To avoid this, designers often register outputs or use Moore outputs for stable signals. Understanding clock domains and timing constraints is key to reliable FSM output.

Result

You know how to design FSM outputs that avoid glitches and timing errors.

Knowing output timing issues prevents subtle bugs in hardware circuits.

7

Expert

Optimizing FSM Output Logic for Synthesis

🤔Before reading on: do you think combining output logic with next state logic always reduces hardware? Commit to your answer.

Concept: Discuss advanced techniques to optimize FSM output logic for area, speed, and power during synthesis.

Synthesis tools can optimize FSMs differently based on coding style. Combining output logic with next state logic can reduce hardware but may increase complexity. Using one-hot encoding or encoding states to minimize transitions can improve speed. Balancing readability and optimization is a key skill.

Result

You understand trade-offs in FSM output logic coding for real hardware.

Knowing synthesis impacts helps you write FSM code that is both efficient and maintainable.

Under the Hood

Internally, an FSM uses flip-flops to store the current state. On each clock cycle, the next state logic computes the next state based on current state and inputs. The output logic then produces signals based on this state and possibly inputs. The hardware synthesizer converts this logic into gates and registers, ensuring timing and signal integrity.

Why designed this way?

FSMs were designed to simplify complex control logic by breaking behavior into discrete states. Separating state storage, next state logic, and output logic allows modular design and easier debugging. Moore and Mealy models offer trade-offs between output stability and responsiveness, giving designers flexibility.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Inputs      │──────▶│ Next State    │──────▶│ State Register│
│ (external)    │       │ Logic         │       │ (flip-flops)  │
└───────────────┘       └──────┬────────┘       └──────┬────────┘
                                   │                       │
                                   ▼                       │
                           ┌───────────────┐              │
                           │ Output Logic  │◀─────────────┘
                           │ (Moore/Mealy) │
                           └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do Mealy FSM outputs change only on state changes? Commit yes or no.

Common Belief: Mealy FSM outputs change only when the state changes, just like Moore FSMs.

Reality: Mealy FSM outputs can change immediately when inputs change, even if the state stays the same.

Why it matters: Assuming Mealy outputs change only on state changes can cause missed glitches or timing errors in hardware.

Quick: Is it always better to put output logic inside the state register block? Commit yes or no.

Common Belief: Output logic should always be inside the state register block for simplicity.

Reality: Separating output logic from state registers improves clarity and synthesis results, especially for Mealy machines.

Why it matters: Mixing output and state logic can cause confusing code and synthesis inefficiencies.

Quick: Do Moore FSM outputs always react slower than Mealy outputs? Commit yes or no.

Common Belief: Moore FSM outputs are always slower than Mealy outputs because they depend only on states.

Reality: While Moore outputs update on state changes, careful design can minimize delay; Mealy outputs are faster but can glitch.

Why it matters: Misunderstanding this can lead to choosing the wrong FSM type for timing-critical designs.

Quick: Can FSM outputs be asynchronous signals? Commit yes or no.

Common Belief: FSM outputs can be asynchronous and change anytime inputs change.

Reality: FSM outputs should be synchronous to the clock to avoid glitches and timing issues.

Why it matters: Asynchronous outputs can cause unpredictable hardware behavior and bugs.

Expert Zone

1

Output logic placement affects not only timing but also power consumption in hardware.

2

State encoding choices (binary, one-hot, gray) influence output logic complexity and speed.

3

Synthesis tools may optimize FSM output logic differently based on coding style, so code clarity can impact final hardware.

When NOT to use

FSMs with output logic are not ideal for extremely large state spaces or highly parallel systems; in such cases, consider microprogramming or dataflow architectures.

Production Patterns

In real hardware, FSMs with output logic are used in communication protocols, CPU control units, and device drivers, often combined with pipelining and hazard detection for robust performance.

Connections

Control Systems

FSMs model discrete control logic similar to how control systems manage states in mechanical or electrical systems.

Understanding FSMs helps grasp how machines switch between modes in real-world control applications.

Software State Machines

FSMs in hardware and software share the same principles of states and transitions but differ in implementation details.

Knowing hardware FSMs clarifies how software state machines manage program flow and vice versa.

Human Decision Making

FSMs resemble how humans make decisions step-by-step based on current context and inputs.

Recognizing FSM patterns in human behavior aids in designing intuitive user interfaces and AI models.

Common Pitfalls

#1 Mixing output logic with state register causing timing issues.

Wrong approach:

always @(posedge clk) begin
state <= next_state;
output_signal <= (state == S1) && input_signal;
end

Correct approach:

always @(posedge clk) begin
state <= next_state;
end

always @(*) begin
output_signal = (state == S1) && input_signal;
end

Root cause:

Confusing synchronous state updates with combinational output logic leads to incorrect timing and glitches.

#2 Using Mealy outputs without registering them, causing glitches.

Wrong approach:

assign output_signal = (state == S1) && input_signal; // Mealy output directly from inputs

Correct approach:

reg output_reg;
always @(posedge clk) begin
output_reg <= (state == S1) && input_signal;
end
assign output_signal = output_reg;

Root cause:

Not registering outputs that depend on inputs causes asynchronous changes and glitches.

#3 Forgetting to define default states or outputs in combinational blocks.

Wrong approach:

always @(*) begin
case(state)
S0: next_state = S1;
S1: next_state = S0;
endcase
end

Correct approach:

always @(*) begin
next_state = S0; // default
case(state)
S0: next_state = S1;
S1: next_state = S0;
endcase
end

Root cause:

Missing default assignments causes latches or unintended behavior in hardware.

Key Takeaways

FSMs with output logic control hardware behavior by producing outputs based on current states and inputs.

Moore FSMs produce outputs depending only on states, offering stability, while Mealy FSMs use states and inputs for faster response but risk glitches.

Separating state registers, next state logic, and output logic in Verilog leads to clearer and more reliable designs.

Understanding timing and output glitches is crucial to designing robust FSMs in hardware.

Advanced FSM design balances code clarity, hardware efficiency, and timing requirements for real-world applications.

Practice

1. Which part of an FSM with output logic determines the output signals based only on the current state?

easy

A. Input decoder

B. Next state logic

C. State register

D. Output logic in a Moore machine

Solution

1. Step 1: Understand FSM output types

   In FSMs, Moore outputs depend only on the current state, while Mealy outputs depend on state and input.

2. Step 2: Identify output logic role

   The output logic in a Moore machine produces outputs based solely on the current state stored in the state register.

3. Final Answer:

   Output logic in a Moore machine -> Option D

4. Quick Check:

   Moore output = state only [OK]

Hint: Moore outputs depend only on state, not inputs [OK]

Common Mistakes:

• Confusing next state logic with output logic
• Thinking outputs depend on inputs in Moore FSM
• Mixing state register role with output logic

2. Which of the following is the correct Verilog syntax to declare a state register named state with 2 bits?

easy

A. reg [1:0] state;

B. wire [2:0] state;

C. reg state[1:0];

D. state reg [1:0];

Solution

1. Step 1: Recall Verilog register declaration

   Registers are declared with reg keyword followed by bit width in brackets, e.g., reg [1:0] for 2 bits.

2. Step 2: Check each option

   reg [1:0] state; correctly declares a 2-bit register named state. wire [2:0] state; uses wire and wrong width. reg state[1:0]; uses incorrect syntax for bit width. state reg [1:0]; has wrong keyword order.

3. Final Answer:

   reg [1:0] state; -> Option A

4. Quick Check:

   reg [1:0] state; is correct syntax [OK]

Hint: Use reg [width-1:0] name; for registers [OK]

Common Mistakes:

• Using wire instead of reg for state registers
• Incorrect bit width syntax like reg name[1:0]
• Wrong keyword order like state reg

3. Given this Verilog snippet for a Moore FSM output logic:

always @(state) begin
  case(state)
    2'b00: out = 1'b0;
    2'b01: out = 1'b1;
    2'b10: out = 1'b0;
    default: out = 1'b0;
  endcase
end

What is the output out when state is 2'b01?

medium

A. 1'b0

B. Undefined

C. 1'b1

D. 2'b01

Solution

1. Step 1: Check case for state 2'b01

   The case statement sets out = 1'b1 when state is 2'b01.

2. Step 2: Confirm output value

   Since the state matches 2'b01, output out is assigned 1'b1.

3. Final Answer:

   1'b1 -> Option C

4. Quick Check:

   State 01 -> out = 1 [OK]

Hint: Match state in case to find output quickly [OK]

Common Mistakes:

• Confusing output with state value
• Assuming default applies instead of matching case
• Misreading bit values as decimal

4. Identify the error in this FSM output logic code snippet:

always @(posedge clk) begin
  case(state)
    2'b00: out = 1'b0;
    2'b01: out = 1'b1;
    default: out = 1'b0;
  endcase
end

What is the main problem?

medium

A. Output logic should be in a combinational always block, not clocked

B. Missing reset signal for output

C. State values are incorrectly formatted

D. Output out is not declared as reg

Solution

1. Step 1: Understand output logic timing

   Moore FSM output logic is usually combinational and depends only on state, so it should be in an always block sensitive to state changes, not clock edges.

2. Step 2: Analyze given code

   The code uses always @(posedge clk), making output synchronous, which is incorrect for pure output logic in Moore FSM.

3. Final Answer:

   Output logic should be in a combinational always block, not clocked -> Option A

4. Quick Check:

   Output logic = combinational, not clocked [OK]

Hint: Output logic usually uses always @(*) for combinational [OK]

Common Mistakes:

• Using clocked always block for output logic
• Ignoring sensitivity list correctness
• Confusing output and state update blocks

5. You want to design a Mealy FSM with output logic that sets out = 1 only when the current state is 2'b10 and input in is high. Which Verilog code snippet correctly implements this output logic?

hard

A. always @(in) begin\n if (in)\n out = 1'b1;\n else\n out = 1'b0;\nend

B. always @(state or in) begin\n if (state == 2'b10 && in)\n out = 1'b1;\n else\n out = 1'b0;\nend

C. always @(posedge clk) begin\n if (state == 2'b10 && in)\n out <= 1'b1;\n else\n out <= 1'b0;\nend

D. always @(state) begin\n if (state == 2'b10)\n out = 1'b1;\n else\n out = 1'b0;\nend

Solution

1. Step 1: Understand Mealy output logic

   Mealy outputs depend on both current state and inputs, so sensitivity list must include both state and in.

2. Step 2: Check each option

   always @(state or in) begin\n if (state == 2'b10 && in)\n out = 1'b1;\n else\n out = 1'b0;\nend correctly uses always @(state or in) and sets out based on both conditions. always @(state) begin\n if (state == 2'b10)\n out = 1'b1;\n else\n out = 1'b0;\nend ignores input in. always @(posedge clk) begin\n if (state == 2'b10 && in)\n out <= 1'b1;\n else\n out <= 1'b0;\nend uses clocked block which is not typical for Mealy output logic. always @(in) begin\n if (in)\n out = 1'b1;\n else\n out = 1'b0;\nend ignores state.

3. Final Answer:

   always @(state or in) begin if (state == 2'b10 && in) out = 1'b1; else out = 1'b0; end -> Option B

4. Quick Check:

   Mealy output depends on state and input [OK]

Hint: Include both state and input in sensitivity list for Mealy outputs [OK]

Common Mistakes:

• Leaving input out of sensitivity list
• Using clocked always block for Mealy output
• Ignoring state condition in output logic