Two-process FSM coding style in VHDL - Deep Dive

Overview - Two-process FSM coding style

What is it?

Two-process FSM coding style is a way to design finite state machines in VHDL using two separate processes. One process handles the state transitions based on inputs and current state, while the other process updates the outputs based on the current state. This separation helps organize the design clearly and makes it easier to understand and maintain. It is a common and recommended approach for designing synchronous digital circuits.

Why it matters

Without a clear coding style like the two-process FSM, designs can become confusing and error-prone, mixing state changes and output logic in one place. This can lead to bugs that are hard to find and fix, especially in complex circuits. Using two processes improves readability, reduces mistakes, and helps tools optimize the hardware better, making designs more reliable and easier to debug.

Where it fits

Before learning this, you should understand basic VHDL syntax, signals, and how processes work. You should also know what a finite state machine (FSM) is conceptually. After mastering two-process FSM style, you can learn more advanced FSM styles, like one-process FSMs, or explore asynchronous FSMs and timing optimization techniques.

Mental Model

Core Idea

Separate the FSM's state updates and output logic into two distinct processes to keep control flow and output behavior clear and manageable.

Think of it like...

It's like a traffic light controller where one person decides when to change the light color (state transitions), and another person controls the actual lights turning on or off (outputs), each focusing on their own job.

┌───────────────┐       ┌───────────────┐
│ State Process │──────▶│ Output Process│
│ (State update)│       │ (Output logic)│
└───────────────┘       └───────────────┘
       ▲                       ▲
       │                       │
       │                       │
   Inputs & Clock          Current State

Build-Up - 7 Steps

1

Foundation

Understanding FSM basics in VHDL

Concept: Introduce what a finite state machine is and how states and transitions are represented in VHDL.

A finite state machine (FSM) is a system that can be in one of a limited number of states. In VHDL, states are often represented using an enumerated type. Transitions happen on clock edges, changing the current state based on inputs. For example, you define a type with states like IDLE, RUN, STOP, and use a signal to hold the current state.

Result

You can represent and store the current state in VHDL and understand how it changes over time.

Understanding how states are represented and updated is the foundation for building any FSM in VHDL.

2

Foundation

Writing a synchronous process for state updates

Concept: Learn to write a clocked process that updates the FSM state on the rising edge of the clock.

In VHDL, a process sensitive to the clock signal updates the state variable only on the clock's rising edge. Inside this process, you check the current state and inputs to decide the next state. This ensures the FSM changes state synchronously with the clock, which is essential for predictable hardware behavior.

Result

You have a process that safely updates the FSM state every clock cycle.

Separating state updates into a clocked process ensures timing correctness and predictable state transitions.

3

Intermediate

Creating a combinational process for output logic

Concept: Introduce a second process that sets outputs based on the current state without waiting for the clock.

The output process is combinational, meaning it reacts immediately to changes in the current state or inputs. It uses a case statement on the current state to assign output signals. This separation means outputs reflect the FSM state instantly, improving clarity and avoiding unintended latches.

Result

Outputs change immediately when the state changes, separate from state updates.

Separating output logic into a combinational process prevents mixing timing domains and makes output behavior clearer.

4

Intermediate

Combining state and output processes in a full FSM

Concept: Put together the two processes to form a complete FSM design following the two-process style.

You write one process triggered by the clock to update the state, and another combinational process to set outputs based on the current state. Inputs are used only in the state process to decide transitions. This clear division helps avoid common bugs like unintended latches or glitches.

Result

A clean, readable FSM design with separated state and output logic.

This structure improves maintainability and reduces errors by clearly defining responsibilities.

5

Intermediate

Handling asynchronous reset in two-process FSM

Concept: Learn how to add an asynchronous reset signal to initialize the FSM state safely.

In the state process, check for an asynchronous reset signal before the clock edge. If reset is active, set the state to a known initial state immediately. This ensures the FSM starts predictably after power-up or reset events. The output process will then reflect this initial state automatically.

Result

FSM can be reset asynchronously to a known state, improving reliability.

Proper reset handling is critical for safe startup and predictable behavior in hardware.

6

Advanced

Avoiding common pitfalls with two-process FSMs

🤔Before reading on: Do you think mixing output assignments in the state process causes glitches or not? Commit to your answer.

Concept: Explain why mixing output logic in the state process can cause glitches and how two-process style prevents this.

If outputs are assigned inside the clocked state process, they update only on clock edges, which can cause glitches or unintended latches if outputs depend on inputs combinationally. The two-process style avoids this by keeping outputs in a separate combinational process, ensuring outputs change immediately with state changes without glitches.

Result

Outputs are glitch-free and stable, improving circuit reliability.

Knowing how output timing affects hardware behavior helps prevent subtle bugs in FSM design.

7

Expert

Optimizing two-process FSMs for synthesis tools

🤔Before reading on: Do you think synthesis tools treat two-process FSMs differently than one-process FSMs? Commit to your answer.

Concept: Explore how synthesis tools interpret two-process FSMs and how coding style affects optimization and resource usage.

Synthesis tools recognize the two-process FSM pattern and optimize the state register and output logic separately. Writing clear, separated processes helps tools generate efficient hardware with minimal logic and no unintended latches. However, some tools can also optimize one-process FSMs well, but two-process style remains preferred for clarity and debugging.

Result

Efficient hardware with clear, maintainable code that synthesis tools optimize well.

Understanding synthesis behavior guides writing FSM code that is both readable and hardware-efficient.

Under the Hood

The two-process FSM works by having one process triggered on the clock edge that updates the state register synchronously. This process uses the current state and inputs to compute the next state. The second process is combinational and continuously evaluates the current state to assign outputs. This separation ensures that state changes happen only on clock edges, while outputs respond immediately to state changes, avoiding timing hazards.

Why designed this way?

This style was designed to separate concerns: state storage and output logic. Early hardware description languages mixed these, causing complex timing issues and bugs. Separating them simplifies reasoning, debugging, and synthesis. It also aligns well with hardware reality, where flip-flops store state and combinational logic drives outputs.

┌───────────────┐       ┌───────────────┐
│ Clocked Process│──────▶│ State Register│
│ (State update) │       └───────────────┘
└───────────────┘               │
                                ▼
                       ┌─────────────────┐
                       │ Combinational    │
                       │ Output Process   │
                       └─────────────────┘
                                │
                                ▼
                            Outputs

Myth Busters - 4 Common Misconceptions

Quick: Does assigning outputs inside the clocked state process always prevent glitches? Commit yes or no.

Common Belief: Assigning outputs inside the clocked state process is safe and prevents glitches.

Reality: Assigning outputs only in the clocked process can cause outputs to update only on clock edges, potentially causing glitches or unintended latches when outputs depend on inputs combinationally.

Why it matters: This misconception leads to unstable outputs and hardware bugs that are hard to debug.

Quick: Is it necessary to have two separate processes for every FSM? Commit yes or no.

Common Belief: Two-process FSM style is mandatory and the only correct way to code FSMs in VHDL.

Reality: While two-process FSM style is recommended for clarity, one-process FSMs are also valid and sometimes used, especially in simpler designs or with advanced synthesis tools.

Why it matters: Believing this limits flexibility and understanding of alternative FSM coding styles.

Quick: Does the output process depend on the clock signal? Commit yes or no.

Common Belief: The output process must be clocked to synchronize outputs with the state.

Reality: The output process is combinational and does not depend on the clock; it updates outputs immediately based on the current state.

Why it matters: Misunderstanding this can cause unnecessary clocked outputs, increasing latency and resource usage.

Quick: Can synthesis tools always optimize one-process FSMs as well as two-process FSMs? Commit yes or no.

Common Belief: Synthesis tools treat one-process and two-process FSMs equally in optimization.

Reality: Some synthesis tools optimize two-process FSMs better because the separation matches hardware structure more clearly, though modern tools are improving at optimizing one-process FSMs.

Why it matters: Knowing this helps write code that synthesis tools handle efficiently, improving hardware performance.

Expert Zone

1

The output process should cover all states explicitly to avoid inferred latches, a subtlety often missed.

2

Using enumerated types for states improves readability and synthesis results compared to integers or std_logic_vectors.

3

Careful handling of asynchronous resets in the state process avoids metastability and ensures safe startup.

When NOT to use

Two-process FSM style is less suitable for very simple FSMs where outputs directly depend on inputs without state, or for asynchronous FSMs where outputs and state transitions are not clocked. In such cases, combinational logic or one-process FSMs may be better.

Production Patterns

In real-world designs, two-process FSMs are used with parameterized state types, clear reset handling, and often combined with assertion checks for state validity. They are integrated into larger synchronous systems with careful timing constraints and simulation testbenches.

Connections

Moore and Mealy Machines

Two-process FSM style naturally implements Moore machines by separating state and output logic.

Understanding Moore vs Mealy machines clarifies why outputs depend only on state in two-process FSMs, improving design predictability.

Hardware Flip-Flops and Combinational Logic

The two-process FSM mirrors hardware structure: flip-flops store state, combinational logic drives outputs.

Knowing hardware basics helps understand why separating state and output processes leads to efficient, glitch-free designs.

Project Management: Separation of Concerns

Two-process FSM style applies the software engineering principle of separation of concerns to hardware design.

Recognizing this connection helps appreciate how clear division of responsibilities reduces complexity and errors in any system.

Common Pitfalls

#1 Mixing output assignments inside the clocked state process causing glitches.

Wrong approach:

process(clk)
begin
if rising_edge(clk) then
state <= next_state;
output_signal <= some_logic_based_on_inputs;
end if;
end process;

Correct approach:

process(clk)
begin
if rising_edge(clk) then
state <= next_state;
end if;
end process;

process(state, inputs)
begin
case state is
when STATE1 => output_signal <= '0';
when STATE2 => output_signal <= '1';
when others => output_signal <= '0';
end case;
end process;

Root cause:

Confusing state updates with output logic timing causes outputs to update only on clock edges, leading to glitches.

#2 Forgetting to cover all states in the output process causing inferred latches.

Wrong approach:

process(state)
begin
if state = STATE1 then
output_signal <= '1';
end if;
end process;

Correct approach:

process(state)
begin
case state is
when STATE1 => output_signal <= '1';
when others => output_signal <= '0';
end case;
end process;

Root cause:

Incomplete output assignments cause synthesis tools to infer latches to hold previous values.

#3 Not handling asynchronous reset properly causing unknown startup state.

Wrong approach:

process(clk)
begin
if rising_edge(clk) then
state <= next_state;
end if;
end process;

Correct approach:

process(clk, reset)
begin
if reset = '1' then
state <= IDLE;
elsif rising_edge(clk) then
state <= next_state;
end if;
end process;

Root cause:

Ignoring reset means the FSM starts in an unknown state, causing unpredictable behavior.

Key Takeaways

Two-process FSM coding style separates state updates and output logic into distinct processes for clarity and reliability.

The state process is synchronous and updates the FSM state on clock edges, ensuring predictable timing.

The output process is combinational and sets outputs immediately based on the current state, avoiding glitches.

Proper asynchronous reset handling is essential for safe and predictable FSM startup.

Understanding this style helps write clean, maintainable VHDL code that synthesis tools optimize efficiently.

Practice

1. In a two-process FSM coding style in VHDL, what is the main role of the first process?

easy

A. To update the current state on clock and reset signals

B. To decide the next state based on inputs

C. To generate output signals directly

D. To initialize variables outside the FSM

Solution

1. Step 1: Understand the two-process FSM structure

   The first process in a two-process FSM handles synchronous operations like updating the current state on clock edges and reset.

2. Step 2: Identify the role of the first process

   This process updates the current state register based on clock and reset signals, ensuring state changes happen synchronously.

3. Final Answer:

   To update the current state on clock and reset signals -> Option A

4. Quick Check:

   First process updates state [OK]

Hint: First process updates state on clock/reset [OK]

Common Mistakes:

• Confusing output logic with state update
• Thinking next state logic is in first process
• Assuming initialization happens in first process

2. Which of the following is the correct sensitivity list for the second process in a two-process FSM that decides next state and outputs?

easy

A. clk, reset

B. clk only

C. reset only

D. current_state, inputs

Solution

1. Step 1: Identify what triggers next state and output logic

   The second process is combinational and depends on current state and inputs to decide next state and outputs.

2. Step 2: Determine the sensitivity list

   It must include all signals that affect next state and outputs, which are current_state and inputs, not clock or reset.

3. Final Answer:

   current_state, inputs -> Option D

4. Quick Check:

   Second process sensitivity = current_state, inputs [OK]

Hint: Second process sensitive to state and inputs only [OK]

Common Mistakes:

• Including clock in second process sensitivity
• Using reset in sensitivity list incorrectly
• Leaving sensitivity list empty

3. Given the following VHDL code snippet for a two-process FSM, what will be the value of current_state after the rising edge of clk if reset is '0' and next_state is S1?

process(clk, reset)
begin
  if reset = '1' then
    current_state <= S0;
  elsif rising_edge(clk) then
    current_state <= next_state;
  end if;
end process;

medium

A. S0

B. S1

C. Undefined

D. Remains previous state

Solution

1. Step 1: Analyze reset condition

   Reset is '0', so the reset block is skipped; no forced reset to S0.

2. Step 2: Analyze clock rising edge behavior

   On rising edge of clk, current_state is assigned next_state, which is S1.

3. Final Answer:

   S1 -> Option B

4. Quick Check:

   Reset '0' + rising edge = current_state = next_state [OK]

Hint: Reset '0' means state updates to next_state on clock [OK]

Common Mistakes:

• Assuming reset '0' resets state to S0
• Confusing next_state with current_state immediately
• Ignoring rising_edge condition

4. Identify the error in this two-process FSM snippet where the next state logic is incorrect:

process(current_state, input_signal)
begin
  case current_state is
    when S0 =>
      if input_signal = '1' then
        next_state <= S1;
      else
        next_state <= S0;
      end if;
    when S1 =>
      next_state <= S0;
  end case;
end process;

process(clk, reset)
begin
  if reset = '1' then
    current_state <= S0;
  elsif rising_edge(clk) then
    current_state <= next_state;
  end if;
end process;

medium

A. Sensitivity list missing clk and reset

B. Next state logic should be in clocked process

C. Missing default case in case statement

D. Using '<=' in combinational process instead of ':='

Solution

1. Step 1: Check the case statement coverage

   The case(current_state is) only specifies when S0 and when S1, but omits a catch-all 'when others' clause.

2. Step 2: Understand the consequence

   In a combinational process, incomplete case coverage infers latches on next_state, which is undesirable; it should be fully combinational logic. A default like 'when others => next_state <= current_state;' is needed.

3. Final Answer:

   Missing default case in case statement -> Option C

4. Quick Check:

   Missing when others => latch inferred [OK]

Hint: Case statements in combo processes need 'when others' [OK]

Common Mistakes:

• Omitting 'when others' in case statement
• Ignoring sensitivity list completeness
• Placing next state logic in clocked process

5. You want to design a two-process FSM in VHDL that has three states (IDLE, BUSY, DONE). The FSM should reset to IDLE, move to BUSY when start='1', and then to DONE after one clock cycle. Which of the following next state process code snippets correctly implements this behavior?

hard

A. process(current_state, start)
begin
case current_state is
when IDLE =>
if start = '1' then
next_state <= BUSY;
else
next_state <= IDLE;
end if;
when BUSY =>
next_state <= DONE;
when DONE =>
next_state <= IDLE;
end case;
end process;

B. process(clk, reset)
begin
if reset = '1' then
next_state <= IDLE;
elsif rising_edge(clk) then
if start = '1' then
next_state <= BUSY;
else
next_state <= DONE;
end if;
end if;
end process;

C. process(current_state)
begin
if start = '1' then
next_state <= BUSY;
else
next_state <= IDLE;
end if;
end process;

D. process(current_state, start)
begin
if current_state = IDLE and start = '1' then
next_state <= BUSY;
elsif current_state = BUSY then
next_state <= DONE;
end if;
end process;

Solution

1. Step 1: Check reset and state transitions

   The FSM resets to IDLE (handled in clocked process), so next_state logic must handle transitions from IDLE to BUSY on start='1', BUSY to DONE, and DONE to IDLE.

2. Step 2: Analyze next state logic options

   The correct code uses a combinational process with sensitivity to current_state and start, employing a case statement that fully covers all states with proper transitions: IDLE stays or goes to BUSY based on start, BUSY to DONE, DONE to IDLE. Other codes fail by using clocked process for next_state, missing inputs in sensitivity, incomplete state handling, or unassigned paths in conditional logic leading to latches.

3. Final Answer:

   The case statement with IDLE, BUSY, DONE transitions -> Option A

4. Quick Check:

   Case statement with all states and transitions [OK]

Hint: Use case statement covering all states for next state logic [OK]

Common Mistakes:

• Placing next state logic in clocked process
• Missing transitions for all states
• Ignoring start signal conditions