Why FSMs control complex sequential behavior in VHDL - See It in Action

Why FSMs Control Complex Sequential Behavior

📖 Scenario: Imagine you are designing a simple traffic light controller for an intersection. The traffic lights must change colors in a specific order and timing to control the flow of cars safely. This is a real-world example where a Finite State Machine (FSM) helps manage complex sequential behavior.

🎯 Goal: Build a basic FSM in VHDL that controls a traffic light sequence: Green → Yellow → Red → Green, repeating continuously.

📋 What You'll Learn

Create a VHDL type for the traffic light states

Create a signal to hold the current state

Write a process that changes the state in the correct order

Output the current state as a string or code

Print the current state to show the sequence

💡 Why This Matters

🌍 Real World

Traffic lights, vending machines, elevators, and many devices use FSMs to control sequences of actions safely and predictably.

💼 Career

Understanding FSMs is essential for hardware design engineers, embedded systems developers, and anyone working with digital logic and control systems.

1

DATA SETUP: Define the traffic light states

Create a VHDL type called state_type with these states: Green, Yellow, and Red. Then create a signal called current_state of type state_type and initialize it to Green.

VHDL

type state_type is (Green, Yellow, Red);
signal current_state : state_type := Green;  -- Your code here

Hint

Use type to define states and signal to hold the current state.

2

CONFIGURATION: Add a clock signal for state changes

Add a signal called clk of type std_logic to simulate a clock that triggers state changes.

VHDL

library ieee;
use ieee.std_logic_1164.all;

entity TrafficLightFSM is
end TrafficLightFSM;

architecture Behavioral of TrafficLightFSM is
    type state_type is (Green, Yellow, Red);
    signal current_state : state_type := Green;
    signal clk : std_logic := '0';  -- Your code here
begin
end Behavioral;

Hint

Use signal clk : std_logic := '0'; to create a clock signal.

3

CORE LOGIC: Write a process to change states on clock rising edge

Write a process triggered on the rising edge of clk that updates current_state to the next state in this order: Green → Yellow → Red → Green.

VHDL

library ieee;
use ieee.std_logic_1164.all;

entity TrafficLightFSM is
end TrafficLightFSM;

architecture Behavioral of TrafficLightFSM is
    type state_type is (Green, Yellow, Red);
    signal current_state : state_type := Green;
    signal clk : std_logic := '0';
begin
    process(clk)
    begin
        if rising_edge(clk) then
            -- Your code here
        end if;
    end process;
end Behavioral;

Hint

Use a process with if rising_edge(clk) and a case statement to update current_state.

4

OUTPUT: Print the current state to show the sequence

Add a process that prints the current state name as text whenever current_state changes.

VHDL

library ieee;
use ieee.std_logic_1164.all;
use std.textio.all;
use ieee.std_logic_textio.all;

entity TrafficLightFSM is
end TrafficLightFSM;

architecture Behavioral of TrafficLightFSM is
    type state_type is (Green, Yellow, Red);
    signal current_state : state_type := Green;
    signal clk : std_logic := '0';
    file output_file : text open write_mode is "output.txt";
begin
    process(clk)
    begin
        if rising_edge(clk) then
            case current_state is
                when Green =>
                    current_state 
                    current_state 
                    current_state <= Green;
            end case;
        end if;
    end process;

    -- Your code here to print current_state
end Behavioral;

Hint

Use a process sensitive to current_state and write and writeline to print the state.

Practice

1. Why are FSMs (Finite State Machines) used to control complex sequential behavior in VHDL designs?

easy

A. Because they organize behavior into clear, manageable states.

B. Because they make the circuit run faster than combinational logic.

C. Because they eliminate the need for clocks in the design.

D. Because they reduce the number of input signals required.

Solution

1. Step 1: Understand FSM purpose

   FSMs break down complex sequences into smaller states, making behavior easier to manage.

2. Step 2: Compare to other options

   FSMs do not inherently speed circuits, remove clocks, or reduce inputs; their main role is organizing states.

3. Final Answer:

   Because they organize behavior into clear, manageable states. -> Option A

4. Quick Check:

   FSMs = clear state management [OK]

Hint: FSMs split tasks into states for easy control [OK]

Common Mistakes:

• Thinking FSMs make circuits faster
• Believing FSMs remove clock signals
• Assuming FSMs reduce input count

2. Which VHDL code snippet correctly declares a simple FSM state type?

easy

A. type state_type is (IDLE, PROCESS, DONE);\nsignal state : state_type;

B. signal state : integer range 0 to 2;\ntype state_type is (IDLE, PROCESS, DONE);

C. type state_type is array (0 to 2) of std_logic;\nsignal state : state_type;

D. signal state : std_logic_vector(1 downto 0);\ntype state_type is (IDLE, PROCESS, DONE);

Solution

1. Step 1: Identify correct state type declaration

   type state_type is (IDLE, PROCESS, DONE);\nsignal state : state_type; correctly defines an enumerated type with states and a signal of that type.

2. Step 2: Check other options

   signal state : integer range 0 to 2;\ntype state_type is (IDLE, PROCESS, DONE); declares signal before type, which is invalid. type state_type is array (0 to 2) of std_logic;\nsignal state : state_type; uses array instead of enumeration. signal state : std_logic_vector(1 downto 0);\ntype state_type is (IDLE, PROCESS, DONE); mixes vector with enumeration incorrectly.

3. Final Answer:

   type state_type is (IDLE, PROCESS, DONE);\nsignal state : state_type; -> Option A

4. Quick Check:

   Correct enum type declaration = type state_type is (IDLE, PROCESS, DONE);\nsignal state : state_type; [OK]

Hint: Declare enum type before signal using it [OK]

Common Mistakes:

• Declaring signal before type
• Using arrays instead of enums for states
• Mixing std_logic_vector with enum states

3. Given the following VHDL FSM snippet, what is the next state when current state is PROCESS and input start = '0'?

type state_type is (IDLE, PROCESS, DONE);
signal state : state_type;

process(clk)
begin
  if rising_edge(clk) then
    case state is
      when IDLE =>
        if start = '1' then
          state <= PROCESS;
        else
          state <= IDLE;
        end if;
      when PROCESS =>
        if start = '0' then
          state <= DONE;
        else
          state <= PROCESS;
        end if;
      when DONE =>
        state <= IDLE;
    end case;
  end if;
end process;

medium

A. IDLE

B. PROCESS

C. DONE

D. ERROR

Solution

1. Step 1: Analyze current state and input

   Current state is PROCESS and input start = '0'. According to code, PROCESS state moves to DONE if start = '0'.

2. Step 2: Determine next state

   Since start = '0', next state is DONE.

3. Final Answer:

   DONE -> Option C

4. Quick Check:

   PROCESS + start='0' = DONE [OK]

Hint: Follow case conditions for current state and input [OK]

Common Mistakes:

• Ignoring input value in state transition
• Confusing PROCESS and DONE states
• Assuming default next state is IDLE

4. Identify the error in this FSM process code snippet:

process(clk)
begin
  if clk'event and clk = '1' then
    case state is
      when IDLE =>
        if start = '1' then
          state <= PROCESS;
        end if;
      when PROCESS =>
        state <= DONE;
      when DONE =>
        state <= IDLE;
    end case;
  end if;
end process;

medium

A. Missing else branch in IDLE state causes latch inference.

B. Using clk'event instead of rising_edge(clk) is incorrect.

C. State transitions are not inside a clocked process.

D. No reset condition to initialize the state signal.

Solution

1. Step 1: Check clock event usage

   Using clk'event and clk = '1' is valid but less recommended than rising_edge(clk), so not an error.

2. Step 2: Look for reset signal

   The code lacks any reset condition to initialize the state signal, which can cause undefined behavior.

3. Final Answer:

   No reset condition to initialize the state signal. -> Option D

4. Quick Check:

   Missing reset = No reset condition to initialize the state signal. [OK]

Hint: Always include reset to set initial FSM state [OK]

Common Mistakes:

• Confusing clk'event with rising_edge(clk)
• Assuming else needed in every if
• Ignoring reset importance

5. You want to design an FSM in VHDL that controls a traffic light sequence: RED -> GREEN -> YELLOW -> RED. Which approach best uses FSMs to handle this complex sequential behavior?

hard

A. Use combinational logic only to switch lights based on input sensors.

B. Define states RED, GREEN, YELLOW and transition on a timer signal in a clocked process.

C. Use multiple independent signals toggling asynchronously for each light.

D. Write separate processes for each light color without state tracking.

Solution

1. Step 1: Identify FSM role in traffic light control

   FSMs manage sequences by defining states and transitions, perfect for timed traffic light changes.

2. Step 2: Evaluate options

   Define states RED, GREEN, YELLOW and transition on a timer signal in a clocked process. uses states and timer in a clocked process, matching FSM design principles. Others lack clear state control or timing.

3. Final Answer:

   Define states RED, GREEN, YELLOW and transition on a timer signal in a clocked process. -> Option B

4. Quick Check:

   FSM + timer = controlled traffic light sequence [OK]

Hint: Use states and timer in clocked process for sequences [OK]

Common Mistakes:

• Using only combinational logic for sequence
• Toggling signals asynchronously causing glitches
• Not tracking state leads to unpredictable behavior