Traffic light controller FSM in Verilog - Deep Dive

Overview - Traffic light controller FSM

What is it?

A traffic light controller FSM is a digital system that manages traffic lights at an intersection. It uses a finite state machine (FSM) to switch lights between red, yellow, and green in a timed sequence. This ensures safe and orderly traffic flow by controlling when cars can stop or go.

Why it matters

Without a traffic light controller FSM, traffic lights would not change in a predictable or safe way, causing confusion and accidents. This system automates traffic control, reducing human error and improving road safety. It also helps manage traffic efficiently, reducing congestion and wait times.

Where it fits

Before learning this, you should understand basic digital logic and Verilog syntax. After this, you can explore more complex FSM designs, timing control, and integration with sensors or pedestrian signals.

Mental Model

Core Idea

A traffic light controller FSM cycles through a fixed set of states, each representing a light color, to control traffic flow safely and predictably.

Think of it like...

It's like a music playlist that plays songs in order, one after another, repeating the cycle to keep the rhythm going smoothly.

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│   Green Light │ ──▶ │  Yellow Light │ ──▶ │    Red Light  │
└───────────────┘     └───────────────┘     └───────────────┘
       ▲                                         │
       └─────────────────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Finite State Machines

Concept: Introduce the idea of FSMs as systems with a limited number of states that change based on inputs or time.

A finite state machine has states and rules to move between them. For example, a traffic light has states like green, yellow, and red. The FSM moves from one state to the next in a cycle to control the lights.

Result

You understand that FSMs model systems with clear, limited states and transitions.

Understanding FSMs is key because they model many real-world control systems, including traffic lights.

2

Foundation

Basics of Verilog for FSM Design

Concept: Learn how to write simple Verilog code to represent states and transitions.

In Verilog, states can be represented using parameters or enums. You use always blocks triggered by clock signals to change states. For example, you can define states as numbers and use a case statement to decide the next state.

Result

You can write basic Verilog code that changes states on clock edges.

Knowing how to represent states and transitions in Verilog is essential to implement any FSM.

3

Intermediate

Designing Traffic Light States and Timing

🤔Before reading on: do you think the yellow light duration should be longer, shorter, or equal to the green light? Commit to your answer.

Concept: Define the specific states for the traffic light and assign timing durations for each light color.

The traffic light FSM has three main states: GREEN, YELLOW, and RED. Each state lasts a certain number of clock cycles to control how long the light stays on. For example, green might last 10 seconds, yellow 3 seconds, and red 10 seconds. We use counters to track time in each state.

Result

You can control how long each light stays on by counting clock cycles in each state.

Understanding timing control within states lets you create smooth and safe traffic light sequences.

4

Intermediate

Implementing State Transitions in Verilog

🤔Before reading on: do you think state transitions happen immediately or only on clock edges? Commit to your answer.

Concept: Use synchronous logic to change states only on clock edges, ensuring predictable behavior.

In Verilog, state changes happen inside an always block triggered by the clock's rising edge. We check if the timer for the current state has expired, then move to the next state. This keeps transitions clean and synchronized with the clock.

Result

The FSM changes states predictably on clock ticks, avoiding glitches.

Synchronous state transitions prevent timing errors and make the FSM reliable.

5

Advanced

Adding Reset and Output Logic

🤔Before reading on: do you think outputs should change immediately or only after state updates? Commit to your answer.

Concept: Add a reset input to initialize the FSM and define outputs based on the current state.

A reset input sets the FSM to a known state (usually RED) when the system starts. Outputs for the traffic lights are assigned based on the current state, turning on the correct light. Outputs update synchronously with state changes to avoid flickering.

Result

The FSM starts safely and controls lights correctly based on state.

Reset and output logic ensure the FSM starts correctly and communicates its state clearly.

6

Expert

Optimizing FSM for Real-World Traffic Control

🤔Before reading on: do you think a simple cycle FSM can handle pedestrian buttons or emergency vehicles? Commit to your answer.

Concept: Extend the FSM to handle inputs like pedestrian requests or emergency vehicle priority, adding complexity and flexibility.

Real traffic controllers often have inputs for pedestrian crossing buttons or emergency vehicle sensors. The FSM can add states or transitions to handle these inputs, like extending green light or skipping certain states. This requires careful design to avoid unsafe conditions.

Result

The FSM can adapt to real-world events, improving traffic flow and safety.

Knowing how to extend FSMs for real inputs prepares you for practical, complex control systems.

Under the Hood

The FSM uses a clock signal to synchronize state changes. Internally, a register holds the current state. On each clock tick, the FSM checks timers or inputs to decide the next state. Outputs are combinational logic derived from the current state. The timer counts clock cycles to control how long each state lasts.

Why designed this way?

This design ensures predictable, glitch-free transitions synchronized to a clock, which is essential in hardware. Using a register for state and counters for timing is efficient and maps well to digital circuits. Alternatives like asynchronous transitions were avoided because they cause unpredictable behavior.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   State Reg   │──────▶│ Next State    │──────▶│ Output Logic  │
│ (holds state) │       │ Logic & Timer │       │ (lights on/off)│
└───────────────┘       └───────────────┘       └───────────────┘
        ▲                      │                       │
        │                      │                       │
        └──────────────────────┴───────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the FSM change states immediately when a timer expires, or only on the next clock edge? Commit to your answer.

Common Belief: The FSM changes states immediately as soon as the timer expires.

Reality: The FSM only changes states on the next clock edge after the timer expires, ensuring synchronization.

Why it matters: Assuming immediate change can lead to design errors causing glitches or unstable outputs in hardware.

Quick: Is it safe to use asynchronous resets in all FSM designs? Commit to your answer.

Common Belief: Asynchronous resets are always safe and preferred for FSMs.

Reality: Asynchronous resets can cause metastability or glitches if not handled carefully; synchronous resets are often safer in FSMs.

Why it matters: Misusing resets can cause unpredictable behavior and hardware faults.

Quick: Can a simple three-state FSM handle pedestrian crossing requests without modification? Commit to your answer.

Common Belief: Yes, the basic three-state FSM can handle all traffic control needs including pedestrians.

Reality: Handling pedestrian requests requires adding states or inputs to the FSM; the basic cycle is not enough.

Why it matters: Ignoring this leads to unsafe or non-functional pedestrian signals.

Quick: Does the FSM output change instantly when the state changes, or can there be delays? Commit to your answer.

Common Belief: Outputs change instantly and independently of the clock.

Reality: Outputs are usually combinational logic based on the current state and update quickly, but the state itself changes only on clock edges.

Why it matters: Misunderstanding output timing can cause design errors or unexpected light behavior.

Expert Zone

1

The choice between Moore and Mealy FSM models affects output timing and complexity; traffic lights usually use Moore for stable outputs.

2

Using parameterized timing constants allows easy adjustment of light durations without changing core logic.

3

Handling asynchronous inputs like emergency vehicle signals requires careful synchronization to avoid metastability.

When NOT to use

Simple FSMs are not suitable for highly dynamic intersections with many sensors and adaptive timing; in such cases, microcontroller-based or software-driven controllers are better.

Production Patterns

Real-world traffic controllers use hierarchical FSMs with multiple layers for different directions, pedestrian signals, and sensor inputs, often implemented on FPGAs or ASICs with safety checks.

Connections

Moore vs Mealy Machines

Builds-on

Understanding the difference helps design FSM outputs that are stable and synchronized, crucial for traffic light safety.

Digital Clock Dividers

Same pattern

Clock dividers generate slower clocks used as timers in FSMs, showing how timing control is built from basic digital blocks.

Project Management Workflows

Analogy in process control

Like FSMs control traffic states, workflows control project phases, showing how state machines model many real-world processes.

Common Pitfalls

#1 Forgetting to reset the FSM leads to undefined starting state.

Wrong approach:

always @(posedge clk) begin
case(state)
GREEN: if(timer_done) state <= YELLOW;
YELLOW: if(timer_done) state <= RED;
RED: if(timer_done) state <= GREEN;
endcase
end

Correct approach:

always @(posedge clk or posedge reset) begin
if(reset) state <= RED;
else begin
case(state)
GREEN: if(timer_done) state <= YELLOW;
YELLOW: if(timer_done) state <= RED;
RED: if(timer_done) state <= GREEN;
endcase
end
end

Root cause:

Not including reset logic means the FSM starts in an unknown state, causing unpredictable light behavior.

#2 Changing state variables outside clock edges causing glitches.

Wrong approach:

always @(*) begin
if(timer_done) state = next_state;
end

Correct approach:

always @(posedge clk) begin
if(timer_done) state <= next_state;
end

Root cause:

Using combinational always blocks for state changes breaks synchronous design rules, causing unstable outputs.

#3 Using blocking assignments for state updates in sequential logic.

Wrong approach:

always @(posedge clk) begin
state = next_state;
end

Correct approach:

always @(posedge clk) begin
state <= next_state;
end

Root cause:

Blocking assignments (=) execute immediately and can cause race conditions; non-blocking (<=) ensure proper sequential updates.

Key Takeaways

A traffic light controller FSM cycles through defined states to manage traffic lights safely and predictably.

Verilog FSMs use synchronous logic with state registers and timers to control state duration and transitions.

Reset logic is essential to start the FSM in a known safe state, preventing unpredictable behavior.

Extending FSMs to handle real-world inputs like pedestrian buttons requires adding states and careful design.

Understanding synchronous design principles prevents common hardware bugs like glitches and metastability.