State diagram to Verilog translation - Step-by-Step Execution

Concept Flow - State diagram to Verilog translation

Start

↓

Define States

↓

Create State Encoding

↓

Write State Register

↓

Write Next State Logic

↓

Write Output Logic

↓

Simulate & Verify

↓

End

This flow shows how to translate a state diagram into Verilog code step-by-step, from defining states to writing logic and verifying.

Execution Sample

Verilog

typedef enum logic [1:0] {
  IDLE = 2'b00,
  WAIT = 2'b01,
  DONE = 2'b10
} state_t;

state_t state, next_state;

always_ff @(posedge clk or posedge rst) begin
  if (rst) state <= IDLE;
  else state <= next_state;
end

This code defines states and a state register that updates on clock or reset.

Execution Table

Step	Action	State Variable	Next State Logic	Output Logic	Notes
1	Define states IDLE, WAIT, DONE	state_t enum created	-	-	States encoded as 2-bit values
2	Initialize state register	state = IDLE	-	-	On reset, state set to IDLE
3	Evaluate inputs to decide next_state	state = IDLE	if start=1 then next_state=WAIT else IDLE	-	Transition from IDLE to WAIT on start signal
4	Update state on clock edge	state <= next_state	-	-	State changes at clock rising edge
5	Set outputs based on state	-	-	done=1 if state==DONE else 0	Output depends on current state
6	Check if state == DONE	state = DONE	next_state = IDLE	-	Return to IDLE after DONE
7	End simulation	-	-	-	All transitions covered

💡 Simulation ends after all states and transitions are verified.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
state	undefined	IDLE	WAIT (if start=1)	DONE	IDLE (after DONE)
next_state	undefined	undefined	WAIT	IDLE	IDLE
done	0	0	0	1	0

Key Moments - 3 Insights

Why do we use a separate 'next_state' variable instead of updating 'state' directly?

Because 'state' updates only on the clock edge (step 4), 'next_state' holds the computed next state based on inputs (step 3). This separation avoids combinational loops and models synchronous behavior correctly.

How does the reset signal affect the state register?

At step 2, when reset is high, the state is forced to IDLE immediately, ensuring the FSM starts in a known state.

Why do outputs depend on the current state and not the next state?

Outputs are usually based on the current state (step 5) to reflect the FSM's present condition, ensuring stable and predictable output signals.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'state' after step 4 if 'start' is 1?

A WAIT

B IDLE

C DONE

D Undefined

💡 Hint

Refer to row 4 and variable_tracker for 'state' after step 4.

At which step does the FSM return to the IDLE state after completing the DONE state?

A Step 3

B Step 4

C Step 6

D Step 7

💡 Hint

Check the execution_table row describing transition from DONE to IDLE.

If the reset signal is asserted, what happens to the 'state' variable according to the execution table?

A It remains unchanged

B It becomes IDLE

C It becomes DONE

D It becomes WAIT

💡 Hint

Look at step 2 where reset sets the state.

Concept Snapshot

State Diagram to Verilog Translation:
- Define states as enums or parameters
- Use a state register updated on clock edge
- Compute next_state combinationally from current state and inputs
- Outputs depend on current state
- Reset initializes state
- Simulate to verify transitions

Full Transcript

This visual execution shows how to translate a state diagram into Verilog code. First, states are defined and encoded. Then a state register is created that updates on the clock or reset. Next, combinational logic decides the next state based on inputs and current state. Outputs are set based on the current state. The execution table traces each step, showing state changes and logic decisions. Key moments clarify why next_state is separate, how reset works, and output timing. The quiz tests understanding of state changes and reset behavior.

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