A traffic light controller FSM helps manage traffic lights automatically. It changes lights in a safe order to control cars and pedestrians.
Traffic light controller FSM in Verilog
module traffic_light_fsm(
input clk,
input reset,
output reg [2:0] light
);
typedef enum reg [1:0] {
RED = 2'b00,
GREEN = 2'b01,
YELLOW = 2'b10
} state_t;
state_t state, next_state;
// State transition logic
always @(posedge clk or posedge reset) begin
if (reset) state <= RED;
else state <= next_state;
end
// Next state logic
always @(*) begin
case(state)
RED: next_state = GREEN;
GREEN: next_state = YELLOW;
YELLOW: next_state = RED;
default: next_state = RED;
endcase
end
// Output logic
always @(*) begin
case(state)
RED: light = 3'b100; // Red light on
GREEN: light = 3'b010; // Green light on
YELLOW: light = 3'b001; // Yellow light on
default: light = 3'b100;
endcase
end
endmoduleThis example uses a simple 3-state FSM: RED, GREEN, YELLOW.
The always @(posedge clk or posedge reset) block updates the current state.
typedef enum reg [1:0] {RED=2'b00, GREEN=2'b01, YELLOW=2'b10} state_t;
always @(posedge clk or posedge reset) begin if (reset) state <= RED; else state <= next_state; end
always @(*) begin
case(state)
RED: next_state = GREEN;
GREEN: next_state = YELLOW;
YELLOW: next_state = RED;
default: next_state = RED;
endcase
endThis program defines a traffic light FSM with three states. The testbench simulates clock and reset signals. The monitor prints the light output every time it changes.
module traffic_light_fsm(
input clk,
input reset,
output reg [2:0] light
);
typedef enum reg [1:0] {
RED = 2'b00,
GREEN = 2'b01,
YELLOW = 2'b10
} state_t;
state_t state, next_state;
always @(posedge clk or posedge reset) begin
if (reset) state <= RED;
else state <= next_state;
end
always @(*) begin
case(state)
RED: next_state = GREEN;
GREEN: next_state = YELLOW;
YELLOW: next_state = RED;
default: next_state = RED;
endcase
end
always @(*) begin
case(state)
RED: light = 3'b100;
GREEN: light = 3'b010;
YELLOW: light = 3'b001;
default: light = 3'b100;
endcase
end
endmodule
// Testbench to simulate the FSM
module testbench();
reg clk = 0;
reg reset = 1;
wire [2:0] light;
traffic_light_fsm fsm(.clk(clk), .reset(reset), .light(light));
// Clock generation
always #5 clk = ~clk;
initial begin
$monitor($time, " ns - Light: %b", light);
#10 reset = 0; // Release reset after 10ns
#100 $finish;
end
endmoduleUse a testbench to simulate and verify your FSM behavior.
Each light is represented by a 3-bit code: red=100, green=010, yellow=001.
Resetting the FSM sets it to the RED state to start safely.
A traffic light FSM controls lights in a safe repeating order.
States and transitions are defined clearly using enums and case statements.
Testbenches help check the FSM works as expected before real use.
Practice
Solution
Step 1: Understand FSM role in traffic lights
A traffic light controller FSM manages the sequence of lights (red, yellow, green) safely and in timed order.Step 2: Compare options to FSM purpose
Only To change traffic lights in a safe and timed sequence describes changing lights in a safe and timed sequence, which is the FSM's job.Final Answer:
To change traffic lights in a safe and timed sequence -> Option CQuick Check:
FSM controls light sequence = A [OK]
- Confusing FSM with sensor or speed control
- Thinking FSM counts cars
- Assuming FSM controls vehicle speed
Solution
Step 1: Identify correct state variable type
FSM states are stored in registers (reg) because they hold values across clock cycles.Step 2: Check bit width for multiple states
Traffic light FSM usually needs multiple bits (e.g., 2 bits) to represent states, so reg [1:0] is correct.Final Answer:
reg [1:0] state; // 2-bit state variable -> Option DQuick Check:
State needs reg and multiple bits = A [OK]
- Using wire instead of reg for state
- Using single bit for multiple states
- Using integer without clocked assignment
always @(posedge clk) begin
case(state)
2'b00: state <= 2'b01;
2'b01: state <= 2'b10;
2'b10: state <= 2'b00;
default: state <= 2'b00;
endcase
endWhat will be the sequence of states after 4 clock cycles starting from 2'b00?
Solution
Step 1: Trace state transitions step-by-step
Start at 00, next is 01, then 10, then back to 00 on each clock.Step 2: List states for 4 cycles
Cycle 1: 00, Cycle 2: 01, Cycle 3: 10, Cycle 4: 00.Final Answer:
00, 01, 10, 00 -> Option AQuick Check:
Follow case transitions = B [OK]
- Mixing up state assignments order
- Forgetting default case resets state
- Assuming states skip steps
always @(posedge clk) begin
if (reset) state <= 2'b00;
else
case(state)
2'b00: state = 2'b01;
2'b01: state = 2'b10;
2'b10: state = 2'b00;
endcase
endSolution
Step 1: Check assignment types in clocked always block
Inside always @(posedge clk), non-blocking assignment (<=) must be used to avoid race conditions.Step 2: Identify incorrect use of blocking assignment
The code uses '=' (blocking) inside sequential logic, which is incorrect.Final Answer:
Using blocking assignment (=) inside sequential always block -> Option AQuick Check:
Use non-blocking (<=) in clocked blocks = C [OK]
- Using = instead of <= in sequential logic
- Ignoring missing default case (less critical)
- Confusing synchronous and asynchronous reset
Solution
Step 1: Understand safe traffic light sequence
Normal sequence is Green -> Yellow -> Red, then pedestrian walk should come after Red for safety.Step 2: Check options for correct order
Green (00) -> Yellow (01) -> Red (10) -> Pedestrian Walk (11) -> Green (00) correctly places Pedestrian Walk after Red, then cycles back to Green.Final Answer:
Green (00) -> Yellow (01) -> Red (10) -> Pedestrian Walk (11) -> Green (00) -> Option BQuick Check:
Pedestrian after Red before Green = D [OK]
- Placing pedestrian walk before Yellow or Green
- Skipping pedestrian state in sequence
- Looping pedestrian state incorrectly
Ready to prove it?
Pass the test and this pattern moves unknown
