Three-process FSM coding style in VHDL - Deep Dive

Overview - Three-process FSM coding style

What is it?

The three-process FSM coding style is a way to design finite state machines in VHDL using three separate processes. Each process has a clear job: one for state transitions, one for output logic, and one for updating the current state. This separation helps organize the design and makes it easier to understand and maintain.

Why it matters

Without a clear structure like the three-process style, FSM designs can become messy and hard to debug. This style prevents mixing different logic types, reducing errors and making the design more reliable. It also helps teams work together by clearly defining where each part of the FSM lives.

Where it fits

Before learning this, you should understand basic VHDL syntax, signals, and simple FSM concepts like states and transitions. After mastering this style, you can explore more complex FSM designs, optimization techniques, and hardware synthesis considerations.

Mental Model

Core Idea

Separate the FSM into three clear parts: deciding the next state, producing outputs, and updating the current state to keep the design clean and easy to follow.

Think of it like...

It's like a traffic light system where one person decides when to change lights (next state logic), another person controls the lights themselves (output logic), and a third person keeps track of the current light color (state register). Each has a clear role to avoid confusion.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Next State    │─────▶│ Output Logic  │      │ State Update  │
│ Logic Process │      │ Process       │      │ Process       │
└───────────────┘      └───────────────┘      └───────────────┘
         │                    │                      ▲
         │                    │                      │
         └────────────────────┴──────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding FSM basics in VHDL

Concept: Learn what a finite state machine is and how states and transitions work in VHDL.

A finite state machine (FSM) is a system that can be in one of many states and changes states based on inputs. In VHDL, states are often represented by an enumerated type. Transitions happen when certain conditions are met, moving the FSM from one state to another.

Result

You can describe simple FSMs with states and transitions in VHDL code.

Understanding the basic FSM concept is essential because all FSM coding styles, including the three-process style, build on this foundation.

2

Foundation

Signals and processes in VHDL

Concept: Learn how signals and processes work in VHDL to model hardware behavior.

Signals represent wires or storage elements in hardware. Processes are blocks of code that run when signals change or on clock edges. They help describe sequential and combinational logic.

Result

You can write simple processes that react to signals and clocks.

Knowing how processes and signals work lets you split FSM logic into separate parts cleanly.

3

Intermediate

Next state logic process

🤔Before reading on: do you think next state logic should be synchronous or combinational? Commit to your answer.

Concept: Create a combinational process that decides the next state based on current state and inputs.

The next state logic process uses the current state and inputs to decide what the next state will be. It is written as a combinational process without clock sensitivity, so it updates immediately when inputs change.

Result

The FSM knows which state to go to next without waiting for a clock.

Separating next state logic as combinational prevents unintended delays and makes the FSM responsive.

4

Intermediate

Output logic process

🤔Before reading on: should output logic depend only on current state or also on inputs? Commit to your answer.

Concept: Write a combinational process that sets outputs based on the current state (Moore) or current state and inputs (Mealy).

The output logic process generates the FSM outputs. For Moore machines, outputs depend only on the current state. For Mealy machines, outputs can also depend on inputs. This process is combinational and updates outputs immediately.

Result

Outputs reflect the FSM's current condition clearly and separately from state changes.

Separating output logic clarifies how outputs relate to states and inputs, improving readability and correctness.

5

Intermediate

State update process

Concept: Implement a synchronous process that updates the current state on the clock edge.

The state update process runs on the clock's rising edge. It assigns the next state value to the current state signal, effectively moving the FSM forward in time. It may also handle reset signals to initialize the FSM.

Result

The FSM moves through states in sync with the clock, ensuring predictable timing.

Having a dedicated state update process ensures timing control and clean separation from combinational logic.

6

Advanced

Handling asynchronous reset and initialization

🤔Before reading on: do you think reset should be handled in the state update process or elsewhere? Commit to your answer.

Concept: Add asynchronous reset logic to the state update process to initialize the FSM safely.

In the state update process, check for an asynchronous reset signal. When active, set the current state to a known initial state immediately, regardless of the clock. This ensures the FSM starts correctly after power-up or reset.

Result

The FSM reliably starts in a defined state, preventing unpredictable behavior.

Proper reset handling is critical for robust hardware design and prevents startup errors.

7

Expert

Avoiding common synthesis pitfalls

🤔Before reading on: do you think mixing combinational and sequential logic in one process is good practice? Commit to your answer.

Concept: Understand why mixing logic types in one process can cause synthesis issues and how the three-process style prevents this.

Mixing combinational and sequential logic in one process can cause unintended latches or glitches. The three-process style keeps combinational next state and output logic separate from the sequential state update, making synthesis tools generate clean hardware without hidden bugs.

Result

Your FSM synthesizes into reliable hardware without unexpected latches or timing problems.

Knowing how synthesis tools interpret your code helps you write safer, more predictable FSMs.

Under the Hood

The three-process FSM style works by splitting the FSM into distinct hardware parts: combinational logic for next state and outputs, and a register for the current state. The next state process computes the next state signals immediately from inputs and current state. The output process generates outputs based on the current state (and inputs for Mealy). The state update process is a clocked register that stores the current state, updating it on clock edges or resets. This separation matches hardware components: combinational logic blocks and flip-flops.

Why designed this way?

This style was designed to improve clarity and synthesis reliability. Early FSM designs mixed logic types in one process, causing synthesis tools to infer unintended latches or glitches. Separating logic into three processes aligns with hardware structure and makes debugging easier. It also supports clear reset handling and output timing. Alternatives like one-process FSMs are simpler but risk errors and harder maintenance.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Combinational │      │ Combinational │      │ Sequential    │
│ Next State    │      │ Output Logic  │      │ State Register│
│ Logic         │      │ Logic         │      │ (Flip-Flops)  │
└───────┬───────┘      └───────┬───────┘      └───────┬───────┘
        │                      │                      │
        │                      │                      │
        └──────────────┬───────┴──────────────┬───────┘
                       │                      │
                 Next State Signals       Output Signals
                       │                      │
                       ▼                      ▼

Myth Busters - 4 Common Misconceptions

Quick: Is it okay to combine next state and output logic in one process? Commit to yes or no.

Common Belief: Many believe combining next state and output logic in one process is simpler and just as good.

Reality: Combining them can cause unintended latches and makes the design harder to debug and maintain.

Why it matters: This leads to hardware that behaves unpredictably and is difficult to fix, causing project delays.

Quick: Does the output logic always depend only on the current state? Commit to yes or no.

Common Belief: Some think outputs depend only on the current state in all FSMs.

Reality: In Mealy machines, outputs depend on both current state and inputs, not just the state.

Why it matters: Ignoring input-dependent outputs can cause incorrect behavior and missed timing requirements.

Quick: Should the state update process be combinational or synchronous? Commit to your answer.

Common Belief: Some believe the state update can be combinational for faster response.

Reality: State updates must be synchronous to the clock to ensure stable and predictable state changes.

Why it matters: Using combinational state updates causes glitches and unstable FSM behavior.

Quick: Can you safely omit reset logic in the state update process? Commit to yes or no.

Common Belief: Some think reset logic is optional and can be left out for simplicity.

Reality: Reset logic is essential to initialize the FSM to a known state after power-up or errors.

Why it matters: Without reset, the FSM may start in an unknown state, causing unpredictable system behavior.

Expert Zone

1

The order of processes in the code does not affect hardware but can improve readability and debugging.

2

Using enumerated types for states improves synthesis results and simulation clarity compared to integers.

3

Careful handling of 'others' clauses in case statements prevents unintended latches and synthesis warnings.

When NOT to use

The three-process style is less suitable for very simple FSMs where a single process is clearer and synthesis tools are trusted to handle mixed logic correctly. For ultra-high-speed designs, custom FSM implementations with optimized logic might be preferred.

Production Patterns

In real-world FPGA and ASIC projects, the three-process FSM style is standard for complex control logic. It is combined with coding guidelines enforcing reset usage, state encoding strategies, and thorough simulation to ensure robust designs.

Connections

Modular programming

Both separate concerns into distinct parts to improve clarity and maintainability.

Understanding how breaking code into modules helps software design clarifies why splitting FSM logic into processes improves hardware design.

Digital circuit design

The three-process FSM style directly maps to hardware components like combinational logic and flip-flops.

Knowing digital circuits helps understand why separating combinational and sequential logic in FSMs is critical for correct hardware behavior.

Project management workflows

Clear separation of responsibilities in FSM design mirrors task division in team projects.

Recognizing this parallel helps appreciate how structured FSM coding supports teamwork and reduces errors.

Common Pitfalls

#1 Mixing next state and output logic in one process causing unintended latches.

Wrong approach:

process(current_state, inputs)
begin
case current_state is
when IDLE =>
if start = '1' then
next_state <= RUN;
output_signal <= '1';
else
next_state <= IDLE;
output_signal <= '0';
end if;
when others =>
next_state <= IDLE;
output_signal <= '0';
end case;
end process;

Correct approach:

process(current_state, inputs)
begin
case current_state is
when IDLE =>
if start = '1' then
next_state <= RUN;
else
next_state <= IDLE;
end if;
when others =>
next_state <= IDLE;
end case;
end process;

process(current_state)
begin
case current_state is
when IDLE =>
output_signal <= '0';
when RUN =>
output_signal <= '1';
when others =>
output_signal <= '0';
end case;
end process;

Root cause:

Confusing combinational next state logic with output logic leads to mixing signals and unintended memory elements.

#2 Omitting reset in state update process causing unknown startup state.

Wrong approach:

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

Correct approach:

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

Root cause:

Not including reset means the FSM state is undefined after power-up, causing unpredictable behavior.

#3 Using combinational logic for state update causing glitches.

Wrong approach:

process(current_state, inputs)
begin
if reset = '1' then
current_state <= IDLE;
else
current_state <= next_state;
end if;
end process;

Correct approach:

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

Root cause:

State must update synchronously on clock edges to avoid unstable transitions and glitches.

Key Takeaways

The three-process FSM style separates next state logic, output logic, and state update into distinct processes for clarity and reliability.

Next state and output logic are combinational processes, while state update is a synchronous process triggered by the clock.

Proper reset handling in the state update process ensures the FSM starts in a known state, preventing unpredictable behavior.

Mixing combinational and sequential logic in one process can cause synthesis issues and should be avoided.

Understanding this style aligns your VHDL code with hardware structure, making designs easier to debug, maintain, and synthesize correctly.

Practice

1. In the three-process FSM coding style in VHDL, which process is responsible for storing the current state?

easy

A. The next state logic process

B. The state register process

C. The output logic process

D. The clock generation process

Solution

1. Step 1: Understand the role of each process

   The three-process FSM style divides the FSM into state register, next state logic, and output logic processes.

2. Step 2: Identify which process stores the current state

   The state register process updates and stores the current state on clock edges.

3. Final Answer:

   The state register process -> Option B

4. Quick Check:

   State storage = state register process [OK]

Hint: State storage always happens in the state register process [OK]

Common Mistakes:

• Confusing next state logic with state storage
• Thinking output logic stores the state
• Assuming clock generation is part of FSM

2. Which of the following is the correct sensitivity list for the next state logic process in a three-process FSM?

easy

A. clk, reset

B. clk

C. outputs

D. current_state, inputs

Solution

1. Step 1: Recall what next state logic depends on

   The next state logic calculates the next state based on the current state and inputs.

2. Step 2: Determine the sensitivity list

   It must react to changes in current_state and inputs, so these go in the sensitivity list.

3. Final Answer:

   current_state, inputs -> Option D

4. Quick Check:

   Next state logic sensitivity = current_state, inputs [OK]

Hint: Next state logic sensitive to current state and inputs only [OK]

Common Mistakes:

• Including clk in next state logic sensitivity list
• Using outputs in sensitivity list
• Leaving sensitivity list empty

3. Given the following partial FSM code snippet, what will be the output value of output_signal when current_state is S1 and input_signal is '1'?

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

medium

A. Undefined

B. '0'

C. '1'

D. Signal retains previous value

Solution

1. Step 1: Analyze the output logic for state S1

   When current_state is S1, output_signal is '1' if input_signal is '1', else '0'.

2. Step 2: Apply given inputs

   current_state = S1 and input_signal = '1' means output_signal <= '1'.

3. Final Answer:

   '1' -> Option C

4. Quick Check:

   Output for S1 with input '1' = '1' [OK]

Hint: Check state and input conditions carefully for output logic [OK]

Common Mistakes:

• Ignoring input condition inside S1
• Assuming output is always '0' in S1
• Confusing output logic with next state logic

4. Identify the error in this state register process code snippet for a three-process FSM:

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

medium

A. Using next_state instead of current_state on clock edge

B. Missing sensitivity to next_state signal

C. Reset condition should be inside rising_edge(clk)

D. No error, code is correct

Solution

1. Step 1: Understand state register role

   The state register updates current_state with next_state on clock edge.

2. Step 2: Check assignment inside clock edge

   The code assigns next_state <= current_state, which is reversed and wrong.

3. Final Answer:

   Using next_state instead of current_state on clock edge -> Option A

4. Quick Check:

   State register updates current_state, not next_state [OK]

Hint: State register updates current_state from next_state [OK]

Common Mistakes:

• Assigning next_state inside state register process
• Placing reset inside clock edge condition
• Confusing current_state and next_state signals

5. You want to design a three-process FSM with states IDLE, BUSY, and DONE. Which of the following correctly describes the responsibilities of the three processes?

hard

A. Process 1: Store current state; Process 2: Compute next state from current state and inputs; Process 3: Generate outputs based on current state

B. Process 1: Generate outputs; Process 2: Store current state; Process 3: Compute next state

C. Process 1: Compute next state; Process 2: Generate outputs; Process 3: Store current state

D. Process 1: Store current state and outputs; Process 2: Compute next state; Process 3: Reset FSM

Solution

1. Step 1: Recall three-process FSM roles

   The three processes are: state register (store current state), next state logic (compute next state), output logic (generate outputs).

2. Step 2: Match roles to options

   Process 1: Store current state; Process 2: Compute next state from current state and inputs; Process 3: Generate outputs based on current state correctly assigns these roles in order.

3. Final Answer:

   Process 1: Store current state; Process 2: Compute next state from current state and inputs; Process 3: Generate outputs based on current state -> Option A

4. Quick Check:

   Three-process FSM roles = B [OK]

Hint: Remember: register stores state, logic computes next, output drives signals [OK]

Common Mistakes:

• Mixing output generation with state storage
• Assigning reset to a separate process
• Combining multiple roles in one process