Synthesis warnings and how to fix them in Verilog - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Verilog simulation snippet?

Consider this Verilog code snippet that causes a synthesis warning about inferred latches:

module latch_example(input wire clk, input wire d, output reg q);
  always @(clk or d) begin
    if (clk) q = d;
  end
endmodule

What is the main issue causing the synthesis warning?

Verilog

module latch_example(input wire clk, input wire d, output reg q);
  always @(clk or d) begin
    if (clk) q = d;
  end
endmodule

A The input d is not used inside the always block.

B The sensitivity list should only include posedge clk to avoid warnings.

C The output q is declared as reg but should be wire.

D The always block is missing an else branch, causing inferred latch.

💡 Hint

Think about what happens to q when clk is low.

The always block does not assign q when clk is low, so the synthesis tool infers a latch to hold the previous value. Adding an else branch fixes this.

❓ Predict Output

intermediate

What warning does this Verilog code generate during synthesis?

Look at this Verilog code snippet:

module unused_signal(input wire a, output wire b);
  wire temp;
  assign b = a;
endmodule

What synthesis warning will most likely appear?

Verilog

module unused_signal(input wire a, output wire b);
  wire temp;
  assign b = a;
endmodule

A Warning about 'temp' declared but never used.

B No warnings, code is clean.

C Warning about input 'a' not connected.

D Warning about output 'b' not driven.

💡 Hint

Check if all declared signals are connected or used.

The wire 'temp' is declared but never used or connected, so synthesis tools warn about unused signals.

🔧 Debug

advanced

Identify the cause of multiple drivers warning in this Verilog code

Given this Verilog snippet:

module multi_driver(input wire a, input wire b, output reg y);
  always @(*) begin
    y = a;
  end
  always @(*) begin
    y = b;
  end
endmodule

What synthesis warning will this code generate?

Verilog

module multi_driver(input wire a, input wire b, output reg y);
  always @(*) begin
    y = a;
  end
  always @(*) begin
    y = b;
  end
endmodule

A No warnings, code synthesizes cleanly.

B Signal 'y' is not assigned in all branches, causing latch.

C Multiple drivers detected on signal 'y', causing conflict.

D Signal 'a' is not used in the design.

💡 Hint

Think about how many places assign to 'y'.

Two always blocks assign to the same reg 'y', causing multiple drivers warning because hardware cannot drive one signal from two sources simultaneously.

📝 Syntax

advanced

Which option fixes the synthesis warning about incomplete case statement?

Consider this Verilog code:

module case_example(input wire [1:0] sel, output reg out);
  always @(*) begin
    case(sel)
      2'b00: out = 0;
      2'b01: out = 1;
      2'b10: out = 0;
    endcase
  end
endmodule

Which option fixes the synthesis warning about incomplete case statement?

Verilog

module case_example(input wire [1:0] sel, output reg out);
  always @(*) begin
    case(sel)
      2'b00: out = 0;
      2'b01: out = 1;
      2'b10: out = 0;
    endcase
  end
endmodule

A Add a default case: default: out = 0;

B Change output reg to wire.

C Remove the case statement and use if-else.

D Add a sensitivity list with posedge clk.

💡 Hint

Think about what happens when sel is 2'b11.

Without a default case, the synthesis tool warns that some inputs are not covered, possibly inferring latches. Adding a default case assigns 'out' for all inputs.

🚀 Application

expert

How to fix a synthesis warning about combinational loop in this code?

Analyze this Verilog code snippet:

module comb_loop(input wire a, output reg y);
  always @(*) begin
    y = ~y & a;
  end
endmodule

This code causes a synthesis warning about a combinational loop. What is the best way to fix it?

Verilog

module comb_loop(input wire a, output reg y);
  always @(*) begin
    y = ~y & a;
  end
endmodule

A Change '~y' to 'y' to remove inversion.

B Make 'y' a registered output updated on clock edge to break the loop.

C Remove 'a' from the expression to avoid feedback.

D Declare 'y' as wire instead of reg.

💡 Hint

Think about how to avoid feedback loops in combinational logic.

The code feeds back 'y' into its own combinational assignment, causing a loop. Using a clocked process to update 'y' breaks the loop and removes the warning.

Practice

1. What is the main reason synthesis tools generate warnings about incomplete case statements in Verilog?

easy

A. Because the case statement is inside an always block.

B. Because the syntax of the case statement is incorrect.

C. Because the tool does not support case statements.

D. Because not all possible input cases are covered, which may cause unintended hardware behavior.

Solution

1. Step 1: Understand synthesis warnings for case statements

   Synthesis tools warn when a case statement does not cover all possible input values, which can cause unintended latches or hardware behavior.

2. Step 2: Reason why incomplete coverage is problematic

   If some input values are not handled, the hardware may hold previous values or behave unpredictably, which is why the tool warns.

3. Final Answer:

   Because not all possible input cases are covered, which may cause unintended hardware behavior. -> Option D

4. Quick Check:

   Incomplete case coverage = synthesis warning [OK]

Hint: Always cover all input cases in case to avoid warnings [OK]

Common Mistakes:

• Thinking syntax errors cause incomplete case warnings
• Ignoring default cases in case statements
• Assuming tools don't check for all input values

2. Which of the following Verilog code snippets will NOT cause a synthesis warning about unassigned signals?

easy

A. module example(input clk, input a, output reg q); always @(posedge clk) q <= a; endmodule

B. module example(input clk, input a, output reg q); always @(posedge clk) ; endmodule

C. module example(input clk, input a, output reg q); reg temp; always @(posedge clk) temp <= a; endmodule

D. module example(input clk, input a, output reg q); reg temp; always @(posedge clk) q <= temp; endmodule

Solution

1. Step 1: Identify unassigned signals in each snippet

   module example(input clk, input a, output reg q); always @(posedge clk) q <= a; endmodule assigns q on clock edge, so no unassigned output. module example(input clk, input a, output reg q); always @(posedge clk) ; endmodule has an empty always block, so q is never assigned. module example(input clk, input a, output reg q); reg temp; always @(posedge clk) temp <= a; endmodule assigns temp but q is unassigned output. module example(input clk, input a, output reg q); reg temp; always @(posedge clk) q <= temp; endmodule assigns q from temp, but temp is never assigned.

2. Step 2: Determine which code avoids unassigned signals

   Only module example(input clk, input a, output reg q); always @(posedge clk) q <= a; endmodule properly assigns the output q and has no unassigned signals, so no synthesis warning.

3. Final Answer:

   module example(input clk, input a, output reg q); always @(posedge clk) q <= a; endmodule -> Option A

4. Quick Check:

   All outputs assigned = no warnings [OK]

Hint: Check if all outputs get assigned in every clock cycle [OK]

Common Mistakes:

• Ignoring that outputs must be assigned to avoid warnings
• Assuming internal regs cause warnings if unassigned
• Confusing blocking and non-blocking assignments

3. Given the following Verilog code, what synthesis warning will most likely appear?

module test(input wire [1:0] sel, output reg out);
  always @(*) begin
    case(sel)
      2'b00: out = 1'b0;
      2'b01: out = 1'b1;
      // Missing cases for 2'b10 and 2'b11
    endcase
  end
endmodule

medium

A. Warning about incomplete case statement causing inferred latch.

B. Warning about unused input sel.

C. Warning about multiple drivers for out.

D. No warnings; code is synthesizable as is.

Solution

1. Step 1: Analyze the case statement coverage

   The case covers only 2 of 4 possible values of sel. Missing 2'b10 and 2'b11 cases.

2. Step 2: Understand synthesis implications of missing cases

   Because not all cases are covered and no default is provided, synthesis infers a latch to hold out value for missing cases, causing a warning.

3. Final Answer:

   Warning about incomplete case statement causing inferred latch. -> Option A

4. Quick Check:

   Incomplete case = inferred latch warning [OK]

Hint: Add default case to avoid inferred latch warnings [OK]

Common Mistakes:

• Assuming no warning if some cases are missing
• Confusing unused input warnings with case coverage
• Ignoring latch inference from incomplete cases

4. Identify the synthesis warning and fix in the following Verilog snippet:

module fixme(input clk, input a, output reg q);
  reg temp;
  always @(posedge clk) begin
    temp <= a;
  end
  always @(posedge clk) begin
    q <= temp;
  end
endmodule

medium

A. Warning: Unused signal temp. Fix: Remove temp and assign q directly.

B. No synthesis warnings; code is correct.

C. Warning: temp is assigned but never used. Fix: Connect temp to output.

D. Warning: Multiple drivers for q. Fix: Use only one always block for q.

Solution

1. Step 1: Check signal usage and assignments

   temp is assigned from a on clock edge, then q is assigned from temp on next clock edge. Both signals are used properly.

2. Step 2: Verify if multiple drivers or unused signals exist

   Only one always block drives temp, and one drives q. No multiple drivers or unused signals.

3. Final Answer:

   No synthesis warnings; code is correct. -> Option B

4. Quick Check:

   All signals assigned and used properly = no warnings [OK]

Hint: Check if every assigned signal is used and driven once [OK]

Common Mistakes:

• Assuming temp is unused because it is intermediate
• Thinking multiple always blocks cause multiple drivers if signals differ
• Ignoring proper signal flow over clock cycles

5. You have a combinational always block with multiple outputs, but synthesis warns about inferred latches. How can you fix this warning effectively?

hard

A. Add more inputs to the sensitivity list of the always block.

B. Remove the always block and use continuous assignments instead.

C. Add a default assignment to all outputs at the start of the always block.

D. Declare all outputs as wires instead of regs.

Solution

1. Step 1: Understand why inferred latches occur in combinational blocks

   If outputs are not assigned in all possible paths, synthesis infers latches to hold previous values, causing warnings.

2. Step 2: Fix by adding default assignments

   Assign default values to all outputs at the start of the always block to ensure they are always driven, preventing latch inference.

3. Final Answer:

   Add a default assignment to all outputs at the start of the always block. -> Option C

4. Quick Check:

   Default assignments prevent inferred latches [OK]

Hint: Initialize outputs at block start to avoid latches [OK]

Common Mistakes:

• Thinking sensitivity list affects latch warnings
• Assuming changing output type fixes latch inference
• Removing always block without replacing logic