Two-process FSM coding style in VHDL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a two-process FSM with synchronous reset

Consider the following VHDL two-process FSM code snippet. What is the value of state after the third rising clock edge if reset is deasserted at the second clock edge?

type state_type is (IDLE, S1, S2);
signal state, next_state : state_type;

-- Clock process
process(clk)
begin
  if rising_edge(clk) then
    if reset = '1' then
      state <= IDLE;
    else
      state <= next_state;
    end if;
  end if;
end process;

-- Next state logic
process(state, input_signal)
begin
  case state is
    when IDLE =>
      if input_signal = '1' then
        next_state <= S1;
      else
        next_state <= IDLE;
      end if;
    when S1 =>
      next_state <= S2;
    when S2 =>
      next_state <= IDLE;
  end case;
end process;

VHDL

type state_type is (IDLE, S1, S2);
signal state, next_state : state_type;

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

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

A IDLE

B S1

C S2

D Undefined (no transition)

💡 Hint

Trace the state transitions step-by-step considering the reset and input_signal values at each clock edge.

Initially, state is IDLE due to reset. At first clock edge after reset deassertion, if input_signal is '1', next_state becomes S1. At second clock edge, state updates to S1, next_state updates to S2. At third clock edge, state updates to S2. Thus, after the third clock edge, state is S2.

🧠 Conceptual

intermediate

Purpose of separating state register and next state logic in two-process FSM

In a two-process FSM coding style in VHDL, why do we separate the state register update and the next state logic into two different processes?

A To clearly separate synchronous state updates from combinational next state logic, improving readability and synthesis results.

B To allow the state register to update asynchronously with the clock.

C To reduce the number of signals needed in the design.

D To enable the FSM to run faster by using two clocks.

💡 Hint

Think about how synchronous and combinational logic are typically coded in VHDL.

The two-process style separates the synchronous state register update (clocked process) from the combinational next state logic (combinational process). This separation improves code clarity and helps synthesis tools generate efficient hardware.

🔧 Debug

advanced

Identify the error in this two-process FSM code

What is the error in the following two-process FSM VHDL code snippet?

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

process(state)
begin
  case state is
    when IDLE =>
      if input_signal = '1' then
        next_state <= S1;
      else
        next_state <= IDLE;
      end if;
    when S1 =>
      next_state <= S2;
    when S2 =>
      next_state <= IDLE;
  end case;
end process;

A The second process is missing input_signal in its sensitivity list, causing simulation mismatches.

B The reset signal should be asynchronous in the second process.

C The state signal should be assigned using '<=' in the second process.

D The clock process should not check for rising_edge(clk).

💡 Hint

Consider what signals the combinational process depends on to update next_state correctly.

The combinational process that calculates next_state depends on both state and input_signal. Missing input_signal in the sensitivity list can cause simulation mismatches or incorrect behavior in simulation, even if synthesis tools may infer it correctly.

📝 Syntax

advanced

Syntax error in two-process FSM next state logic

Which option contains the correct syntax for the next state combinational process in a two-process FSM?

Assume state and next_state are of an enumerated type with states IDLE, S1, S2, and input_signal is a std_logic.

Options:

A

process(state, input_signal) begin
  case state is
    when IDLE =>
      if input_signal = '1' then
        next_state <= "S1";
      else
        next_state <= "IDLE";
      end if;
    when S1 =>
      next_state <= "S2";
    when S2 =>
      next_state <= "IDLE";
  end case;
end process;

B

process(state, input_signal) begin
  case state is
    when IDLE =>
      if input_signal = '1' then
        next_state = S1;
      else
        next_state = IDLE;
      end if;
    when S1 =>
      next_state = S2;
    when S2 =>
      next_state = IDLE;
  end case;
end process;

C

process(state, input_signal) begin
  case state is
    when IDLE =>
      if input_signal = '1' then
        next_state := S1;
      else
        next_state := IDLE;
      end if;
    when S1 =>
      next_state := S2;
    when S2 =>
      next_state := IDLE;
  end case;
end process;

D

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

💡 Hint

Remember that signal assignment in VHDL uses '<=' and enumerated states are not strings.

Option D uses correct signal assignment '<=' and assigns enumerated states directly. Option D uses '=' which is variable assignment and invalid for signals. Option D uses ':=' which is for variables, not signals. Option D uses string literals for states which is invalid.

🚀 Application

expert

Number of states and output values in a Moore FSM two-process design

You design a Moore FSM using the two-process style in VHDL. The FSM has 4 states: IDLE, READ, WRITE, DONE. The output signal done_flag is '1' only in the DONE state and '0' otherwise.

Given the following code snippet for the output logic process:

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

How many clock cycles after reset will it take for done_flag to become '1' if the FSM transitions IDLE -> READ -> WRITE -> DONE on consecutive clock cycles with no stalls?

A 4 clock cycles

B 3 clock cycles

C 1 clock cycle

D 0 clock cycles (immediate after reset)

💡 Hint

Count the clock edges needed to reach DONE state starting from reset state IDLE.

After reset, FSM is in IDLE (done_flag = '0'). On first clock, moves to READ; second clock to WRITE; third clock to DONE. Output done_flag updates immediately with state, so it becomes '1' at the third clock cycle.

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