State diagram to Verilog translation - Mini Project: Build & Apply

State diagram to Verilog translation

📖 Scenario: You are designing a simple traffic light controller using a state diagram. The traffic light has three states: Green, Yellow, and Red. Each state lasts for a fixed number of clock cycles. You want to translate this state diagram into Verilog code to control the traffic lights.

🎯 Goal: Build a Verilog module that implements the traffic light controller using a state machine. You will create the states, a counter for timing, and output signals for the lights.

📋 What You'll Learn

Create a Verilog module named traffic_light with inputs clk and reset.

Define three states: GREEN, YELLOW, and RED using localparam.

Use a register state to hold the current state.

Use a register counter to count clock cycles for timing each state.

Implement state transitions based on the counter reaching specific values.

Output signals green_light, yellow_light, and red_light that are high when the corresponding state is active.

💡 Why This Matters

🌍 Real World

Traffic light controllers are common examples of state machines used in embedded systems and digital design.

💼 Career

Understanding how to convert state diagrams into hardware description languages like Verilog is essential for FPGA and ASIC design engineers.

1

Create the module and define states

Write a Verilog module named traffic_light with inputs clk and reset. Inside the module, define three states using localparam: GREEN = 2'd0, YELLOW = 2'd1, and RED = 2'd2. Also declare a reg [1:0] state to hold the current state.

Verilog

module traffic_light(input clk, input reset);

// Define states
// Your code here

endmodule

Hint

Remember to declare the module with inputs and use localparam to define states as 2-bit values.

2

Add a counter register for timing

Inside the traffic_light module, declare a 4-bit register named counter to count clock cycles for timing the states.

Verilog

module traffic_light(input clk, input reset);

    // Define states
    localparam GREEN = 2'd0;
    localparam YELLOW = 2'd1;
    localparam RED = 2'd2;

    reg [1:0] state;
    // Declare a 4-bit counter register
    // Your code here

endmodule

Hint

Use reg [3:0] counter; to declare a 4-bit register for counting.

3

Implement state transitions and counter logic

Add an always @(posedge clk or posedge reset) block inside the module. On reset, set state to GREEN and counter to 0. Otherwise, increment counter. When counter reaches 4 for GREEN, move to YELLOW and reset counter. When counter reaches 2 for YELLOW, move to RED and reset counter. When counter reaches 4 for RED, move back to GREEN and reset counter.

Verilog

module traffic_light(input clk, input reset);

    // Define states
    localparam GREEN = 2'd0;
    localparam YELLOW = 2'd1;
    localparam RED = 2'd2;

    reg [1:0] state;
    reg [3:0] counter;

    always @(posedge clk or posedge reset) begin
        // Your code here
    end

endmodule

Hint

Use a synchronous reset and a case statement to handle state transitions and counter resets.

4

Add output signals for the traffic lights

Declare output registers green_light, yellow_light, and red_light. Inside an always @(*) block, set these outputs to 1 when the state matches their color, otherwise 0. Finally, add these outputs to the module's port list.

Verilog

module traffic_light(input clk, input reset, output reg green_light, output reg yellow_light, output reg red_light);

    // Define states
    localparam GREEN = 2'd0;
    localparam YELLOW = 2'd1;
    localparam RED = 2'd2;

    reg [1:0] state;
    reg [3:0] counter;

    always @(posedge clk or posedge reset) begin
        if (reset) begin
            state <= GREEN;
            counter <= 0;
        end else begin
            counter <= counter + 1;
            case (state)
                GREEN: if (counter == 4) begin
                    state <= YELLOW;
                    counter <= 0;
                end
                YELLOW: if (counter == 2) begin
                    state <= RED;
                    counter <= 0;
                end
                RED: if (counter == 4) begin
                    state <= GREEN;
                    counter <= 0;
                end
            endcase
        end
    end

    always @(*) begin
        // Your code here
    end

endmodule

Hint

Use a combinational always @(*) block to set the output signals based on the current state.

Practice

1. What is the main purpose of using a state diagram when designing a Verilog state machine?

easy

A. To visually represent states and transitions for easier coding

B. To write the exact Verilog code automatically

C. To test the hardware after synthesis

D. To replace the need for a clock signal

Solution

1. Step 1: Understand the role of state diagrams

   State diagrams show states and how the system moves between them, making design clearer.

2. Step 2: Connect to Verilog design

   They help plan the Verilog code but do not generate code or replace hardware elements.

3. Final Answer:

   To visually represent states and transitions for easier coding -> Option A

4. Quick Check:

   State diagram = Visual design aid [OK]

Hint: State diagrams show steps and moves clearly [OK]

Common Mistakes:

• Thinking state diagrams generate code automatically
• Confusing state diagrams with testing tools
• Believing state diagrams replace clock signals

2. Which of the following is the correct way to declare states in Verilog using an enum for a state machine with states IDLE, READ, and WRITE?

easy

A. enum {IDLE, READ, WRITE} state_t; state_t current_state, next_state;

B. state_t enum {IDLE, READ, WRITE}; current_state, next_state;

C. typedef enum {IDLE, READ, WRITE} state_t; state_t current_state, next_state;

D. typedef enum state_t {IDLE, READ, WRITE}; current_state, next_state;

Solution

1. Step 1: Recall Verilog enum syntax

   In SystemVerilog (modern Verilog), enums are declared with 'typedef enum {states} name;'.

2. Step 2: Check variable declarations

   Variables of enum type are declared as 'state_t current_state, next_state;'.

3. Final Answer:

   typedef enum {IDLE, READ, WRITE} state_t; state_t current_state, next_state; -> Option C

4. Quick Check:

   Enum typedef syntax = typedef enum {IDLE, READ, WRITE} state_t; state_t current_state, next_state; [OK]

Hint: Use 'typedef enum { } name;' for states [OK]

Common Mistakes:

• Using 'enum' without typedef
• Incorrect order of keywords
• Missing variable type for state variables

3. Given the following Verilog code snippet for a state machine, what will be the value of current_state after two clock cycles if the reset is deasserted and start is 1?

typedef enum {IDLE, BUSY, DONE} state_t;
state_t current_state, next_state;
always_ff @(posedge clk or posedge reset) begin
  if (reset) current_state <= IDLE;
  else current_state <= next_state;
end

always_comb begin
  case (current_state)
    IDLE: next_state = start ? BUSY : IDLE;
    BUSY: next_state = DONE;
    DONE: next_state = IDLE;
    default: next_state = IDLE;
  endcase
end

medium

A. BUSY

B. DONE

C. IDLE

D. start

Solution

1. Step 1: Analyze state transitions per clock

   At reset, current_state = IDLE. On first clock, start=1, so next_state = BUSY.

2. Step 2: Follow second clock update

   On second clock, current_state = BUSY, so next_state = DONE.

3. Final Answer:

   DONE -> Option B

4. Quick Check:

   Two clocks after start=1: IDLE -> BUSY -> DONE [OK]

Hint: Trace states step-by-step per clock edge [OK]

Common Mistakes:

• Assuming immediate state change without clock
• Confusing next_state with current_state
• Ignoring reset effect

4. Identify the error in the following Verilog code snippet for a state machine and select the correct fix:

typedef enum {S0, S1, S2} state_t;
state_t current_state, next_state;
always_ff @(posedge clk or posedge reset) begin
  if (reset)
    current_state <= S0;
  else
    current_state = next_state;
end

always_comb begin
  case (current_state)
    S0: next_state = S1;
    S1: next_state = S2;
    S2: next_state = S0;
  endcase
end

medium

A. Declare next_state as reg instead of state_t

B. Add default case in always_comb case statement

C. Remove reset from sensitivity list

D. Change 'current_state = next_state;' to 'current_state <= next_state;'

Solution

1. Step 1: Check assignment types in always_ff block

   Inside always_ff, non-blocking assignment '<=' must be used for sequential logic.

2. Step 2: Identify incorrect assignment

   Line 'current_state = next_state;' uses blocking '=', which is incorrect here.

3. Final Answer:

   Change 'current_state = next_state;' to 'current_state <= next_state;' -> Option D

4. Quick Check:

   Sequential logic uses '<=' [OK]

Hint: Use '<=' in always_ff blocks for state updates [OK]

Common Mistakes:

• Using '=' instead of '<=' in sequential blocks
• Forgetting default case (not critical here)
• Misunderstanding sensitivity list for reset

5. You have a state diagram with states A, B, C, and transitions based on input x. State A transitions to B if x=1, else stays in A. State B transitions to C unconditionally. State C transitions back to A if x=0, else stays in C. Which Verilog code snippet correctly implements the next state logic using a case statement?

hard

A. always_comb begin
case (current_state)
A: next_state = (x == 1) ? B : A;
B: next_state = C;
C: next_state = (x == 0) ? A : C;
default: next_state = A;
endcase
end

B. always_comb begin
case (current_state)
A: if (x) next_state = B; else next_state = C;
B: next_state = A;
C: next_state = B;
endcase
end

C. always_comb begin
case (current_state)
A: next_state = (x == 0) ? B : A;
B: next_state = C;
C: next_state = (x == 1) ? A : C;
endcase
end

D. always_comb begin
case (current_state)
A: next_state = B;
B: next_state = C;
C: next_state = A;
endcase
end

Solution

1. Step 1: Translate each transition from the diagram

   State A: if x=1 go to B else stay A; State B: always go to C; State C: if x=0 go to A else stay C.

2. Step 2: Match transitions to code options

   always_comb begin case (current_state) A: next_state = (x == 1) ? B : A; B: next_state = C; C: next_state = (x == 0) ? A : C; default: next_state = A; endcase end matches all conditions exactly with correct ternary expressions and default case.

3. Final Answer:

   Option A code snippet -> Option A

4. Quick Check:

   Transitions match diagram = always_comb begin case (current_state) A: next_state = (x == 1) ? B : A; B: next_state = C; C: next_state = (x == 0) ? A : C; default: next_state = A; endcase end [OK]

Hint: Match each state transition condition exactly [OK]

Common Mistakes:

• Swapping conditions for x in transitions
• Missing default case in case statement
• Incorrect unconditional transitions