State diagram to Verilog translation - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a simple FSM with two states

Given the following Verilog code for a simple FSM with states IDLE and ACTIVE, what is the output out after the first clock cycle if start is 1 at reset?

Verilog

module fsm(input clk, input reset, input start, output reg out);
  typedef enum logic [1:0] {IDLE=2'b00, ACTIVE=2'b01} state_t;
  state_t state, next_state;

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

  always_comb begin
    next_state = state;
    out = 0;
    case(state)
      IDLE: if (start) next_state = ACTIVE;
      ACTIVE: out = 1;
    endcase
  end
endmodule

A out = Z (high impedance)

B out = 1

C out = X (unknown)

D out = 0

💡 Hint

Combinational outputs update immediately based on the new state after the clock edge.

At reset, state is IDLE and out=0. With start=1, next_state=ACTIVE. After the first clock edge, state becomes ACTIVE, and the combinational logic sets out=1 immediately.

🧠 Conceptual

intermediate

State encoding in Verilog FSM

Which of the following is the best way to encode states in a Verilog FSM for clarity and maintainability?

A Use <code>typedef enum logic</code> with named states

B Use <code>parameter</code> constants with binary values for each state

C Use plain integers without naming states

D Use <code>localparam</code> with decimal values for states

💡 Hint

Modern Verilog supports enumerated types for better readability.

Using typedef enum logic allows named states with clear binary encoding, improving code clarity and reducing errors.

🔧 Debug

advanced

Identify the error in this FSM state transition code

What error will this Verilog FSM code produce when synthesized or simulated?

Verilog

always_ff @(posedge clk) begin
  if (reset) state <= IDLE;
  else begin
    case(state)
      IDLE: if (start) state <= ACTIVE;
      ACTIVE: state <= IDLE;
    endcase
  end
end

always_comb begin
  case(state)
    IDLE: out = 0;
    ACTIVE: out = 1;
  endcase
end

A Syntax error due to missing default case

B No error, code works correctly

C Latch inferred for 'out' signal

D Multiple drivers for 'state' signal

💡 Hint

Check if all outputs are assigned in all branches of combinational block.

The combinational block assigning 'out' does not assign 'out' in all cases, so a latch is inferred.

📝 Syntax

advanced

Correct syntax for synchronous reset in Verilog FSM

Which option shows the correct syntax for a synchronous reset in a Verilog FSM?

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

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

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

D always_ff @(negedge clk) begin if (reset) state <= IDLE; else state <= next_state; end

💡 Hint

Synchronous reset triggers only on clock edge.

Synchronous reset is checked inside the clocked block triggered only on clock edge, so reset is not in sensitivity list.

🚀 Application

expert

Number of states and output values in a Mealy FSM

A Mealy FSM has 3 states and 2 inputs. The output depends on the current state and inputs. How many unique output values can this FSM produce at maximum?

A 3

B 6

C 8

D 12

💡 Hint

Consider outputs can differ for each state-input combination.

In a Mealy FSM, output depends on state and inputs. With 3 states and 2 inputs (4 combinations), max unique outputs = 3*4 = 12.

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