📖 Scenario: You are designing a simple traffic light controller using VHDL. The traffic light cycles through three states: Green, Yellow, and Red. You will use the two-process FSM coding style to implement this controller.
🎯 Goal: Build a two-process FSM in VHDL that controls a traffic light with three states: Green, Yellow, and Red. The FSM should use one process for state transitions (clocked process) and one process for output logic (combinational process).
📋 What You'll Learn
Create a type called state_type with states Green, Yellow, and Red.
Create a signal called current_state of type state_type.
Create a clocked process that updates current_state on the rising edge of clk.
Create a combinational process that sets the output light based on current_state.
Use the two-process FSM style: one process for state transitions, one for output logic.
💡 Why This Matters
🌍 Real World
Traffic light controllers are common examples of FSMs used in embedded systems for managing signals safely and predictably.
💼 Career
Understanding two-process FSM coding style is essential for hardware engineers and FPGA developers designing reliable digital control systems.
Progress0 / 4 steps
1
Define the state type and signals
Create a VHDL type called state_type with states Green, Yellow, and Red. Then create a signal called current_state of type state_type and initialize it to Green.
VHDL
Hint
Use type state_type is (Green, Yellow, Red); to define the states. Then declare signal current_state : state_type := Green;.
2
Create the clocked process for state transitions
Add a clocked process named state_transition that triggers on the rising edge of clk. Inside, use a case statement on current_state to update current_state to the next state in the sequence: Green → Yellow, Yellow → Red, Red → Green.
VHDL
Hint
Use if rising_edge(clk) then inside the process. Use a case statement on current_state to assign the next state.
3
Create the combinational process for output logic
Add a combinational process named output_logic that sets the output light based on current_state. Use a case statement: Green sets light to "100", Yellow sets light to "010", and Red sets light to "001".
VHDL
Hint
Use a process sensitive to current_state. Use a case statement to assign light values as strings.
4
Print the current state and light output
Add a simple testbench process inside the architecture that prints the current state and light output every clock cycle. Use report statements to display the state name and light vector as a string. This will help verify the FSM behavior.
VHDL
Hint
Use a process triggered by clk. Inside, on rising edge, use report to print the state and light.
Practice
(1/5)
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
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.
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.
Final Answer:
To update the current state on clock and reset signals -> Option A
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
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.
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.
Final Answer:
current_state, inputs -> Option D
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
Step 1: Analyze reset condition
Reset is '0', so the reset block is skipped; no forced reset to S0.
Step 2: Analyze clock rising edge behavior
On rising edge of clk, current_state is assigned next_state, which is S1.
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
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.
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.
Final Answer:
Missing default case in case statement -> Option C
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
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.
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.
Final Answer:
The case statement with IDLE, BUSY, DONE transitions -> Option A
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.