Why synthesis rules matter in Verilog - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Verilog simulation?

Consider this Verilog code snippet for a simple flip-flop. What will be the value of q after the positive edge of clk?

Verilog

module dff(input clk, input d, output reg q);
  always @(posedge clk) begin
    q <= d;
  end
endmodule

// Testbench snippet
reg clk;
reg d;
initial begin
  clk = 0;
  d = 1;
  #5 clk = 1; // posedge
  #5 clk = 0;
end

A q becomes 1 after the posedge of clk

B q remains 0 after the posedge of clk

C q becomes 0 immediately when d changes

D Simulation will produce a syntax error

💡 Hint

Remember that q updates only on the positive edge of clk.

The flip-flop updates q to the value of d only at the rising edge of clk. Since d is 1 at that time, q becomes 1.

🧠 Conceptual

intermediate

Why must combinational logic avoid latches in synthesis?

In synthesis, why is it important to avoid unintended latches in combinational logic?

A Because latches are easier to synthesize than flip-flops

B Because latches can cause unpredictable timing and glitches in hardware

C Because latches reduce power consumption significantly

D Because latches always improve circuit speed

💡 Hint

Think about how hardware behaves when signals are not fully specified.

Unintended latches hold their previous state when inputs are not fully specified, causing timing uncertainty and glitches. This makes the hardware unreliable.

🔧 Debug

advanced

Identify the synthesis issue in this Verilog code

What synthesis problem does this Verilog code cause?

Verilog

module mux(input sel, input a, input b, output reg y);
  always @(*) begin
    if (sel == 1'b1)
      y = a;
    // Missing else branch
  end
endmodule

A It infers a latch because the else branch is missing

B It causes a syntax error due to missing semicolon

C It synthesizes correctly as a combinational multiplexer

D It causes a runtime error in simulation

💡 Hint

Think about what happens to y when sel is 0.

Because y is not assigned in the else case, synthesis infers a latch to hold the previous value, which is usually unintended in combinational logic.

📝 Syntax

advanced

Which option causes a synthesis syntax error?

Which of the following Verilog code snippets will cause a syntax error during synthesis?

A assign out = (sel) ? a : b;

B always @(posedge clk) begin q <= d; end

C always @* begin if (sel) y = a else y = b; end

D module m(input a, output reg b) begin b = a; endmodule

💡 Hint

Check the module declaration and body syntax carefully.

Option D is missing the endmodule keyword properly and uses begin directly after module declaration without an always or initial block, causing a syntax error.

🚀 Application

expert

How does synthesis handle multiple drivers on a signal?

In Verilog, if a signal is driven by multiple always blocks or continuous assignments, what will synthesis typically do?

A Synthesis ignores all but the first driver it encounters

B Synthesis will produce a single driver by merging all assignments automatically

C Synthesis will generate an error or unpredictable hardware due to multiple drivers

D Synthesis will infer a wired-AND or wired-OR structure depending on the drivers

💡 Hint

Think about hardware rules for signal driving and conflicts.

Multiple drivers on the same signal without explicit resolution cause conflicts. Synthesis tools usually report errors or generate unpredictable hardware, as real hardware cannot have multiple conflicting drivers on a single net.

Practice

1. Why is it important to follow synthesis rules when writing Verilog code?

easy

A. Because synthesis rules ensure the code can be converted into real hardware

B. Because synthesis rules make the code run faster in simulation

C. Because synthesis rules help the code look cleaner

D. Because synthesis rules allow the code to run on any software

Solution

1. Step 1: Understand synthesis purpose

   Synthesis converts Verilog code into hardware circuits.

2. Step 2: Connect rules to hardware creation

   Following synthesis rules ensures the code can be correctly transformed into hardware.

3. Final Answer:

   Because synthesis rules ensure the code can be converted into real hardware -> Option A

4. Quick Check:

   Synthesis rules = hardware conversion [OK]

Hint: Synthesis rules = code to hardware conversion [OK]

Common Mistakes:

• Confusing synthesis rules with simulation speed
• Thinking synthesis rules only affect code style
• Believing synthesis rules affect software compatibility

2. Which of the following Verilog code snippets follows synthesis rules for combinational logic?

easy

A. always @(posedge clk) begin out = in1 & in2; end

B. always @(negedge clk) begin out <= in1 | in2; end

C. initial begin out = 1'b0; end

D. always @(*) begin out = in1 & in2; end

Solution

1. Step 1: Identify combinational logic sensitivity list

   Combinational logic uses always @(*) to react to input changes.

2. Step 2: Check each option

   always @(*) begin out = in1 & in2; end uses always @(*) with blocking assignment, correct for combinational logic.

3. Final Answer:

   always @(*) begin out = in1 & in2; end -> Option D

4. Quick Check:

   Combinational logic uses always @(*) [OK]

Hint: Combinational logic uses always @(*) blocks [OK]

Common Mistakes:

• Using clock edges for combinational logic
• Using non-blocking assignments in combinational always blocks
• Using initial blocks for synthesis

3. What will be the output of this Verilog code after synthesis if clk is a clock and reset is active high?

module test(input clk, reset, input d, output reg q);
  always @(posedge clk or posedge reset) begin
    if (reset) q <= 0;
    else q <= d;
  end
endmodule

medium

A. q follows d asynchronously ignoring reset

B. q resets to 0 when reset is high, else q follows d on clock edge

C. q never resets and holds previous value

D. q resets to 1 when reset is high

Solution

1. Step 1: Analyze sensitivity list

   The always block triggers on rising edge of clk or reset.

2. Step 2: Understand reset behavior

   If reset is high, q is set to 0 immediately (asynchronous reset). Otherwise, q follows d on clock edge.

3. Final Answer:

   q resets to 0 when reset is high, else q follows d on clock edge -> Option B

4. Quick Check:

   Asynchronous reset sets q=0, else q=d [OK]

Hint: Check sensitivity list for async reset behavior [OK]

Common Mistakes:

• Assuming reset is synchronous
• Ignoring reset in output behavior
• Confusing reset value as 1 instead of 0

4. Identify the synthesis error in this Verilog code:

always @(posedge clk) begin
  if (enable)
    count = count + 1;
end

medium

A. Using blocking assignment inside sequential always block

B. Missing sensitivity to reset signal

C. Using non-blocking assignment instead of blocking

D. No error, code is synthesizable

Solution

1. Step 1: Check assignment type in sequential block

   Sequential blocks triggered by clock edges should use non-blocking assignments (<=).

2. Step 2: Identify error in code

   The code uses blocking assignment (=) inside a clocked always block, which can cause incorrect synthesis.

3. Final Answer:

   Using blocking assignment inside sequential always block -> Option A

4. Quick Check:

   Sequential always blocks need non-blocking assignments [OK]

Hint: Use <= in clocked always blocks, not = [OK]

Common Mistakes:

• Confusing blocking and non-blocking assignments
• Ignoring reset signals in counters
• Assuming blocking assignments are always okay

5. You want to design a 4-bit counter that resets asynchronously and counts up on each clock edge only when enable is high. Which of the following code snippets follows synthesis rules correctly?

hard

A. always @(posedge clk or posedge reset) begin
if (reset) count = 0;
else if (enable) count <= count + 1;
end

B. always @(posedge clk) begin
if (reset) count = 0;
else if (enable) count = count + 1;
end

C. always @(posedge clk or posedge reset) begin
if (reset) count <= 0;
else if (enable) count <= count + 1;
end

D. always @(posedge clk) begin
if (reset) count <= 0;
else if (enable) count <= count + 1;
end

Solution

1. Step 1: Check asynchronous reset sensitivity

   Asynchronous reset requires reset in sensitivity list (posedge reset).

2. Step 2: Verify assignment types and conditions

   always @(posedge clk or posedge reset) begin if (reset) count <= 0; else if (enable) count <= count + 1; end uses non-blocking assignments (<=) and includes reset in sensitivity list, correctly implementing async reset and enable control.

3. Final Answer:

   always @(posedge clk or posedge reset) begin if (reset) count <= 0; else if (enable) count <= count + 1; end -> Option C

4. Quick Check:

   Async reset in sensitivity + non-blocking assignments [OK]

Hint: Async reset needs posedge reset in sensitivity list [OK]

Common Mistakes:

• Using blocking assignments in sequential logic
• Omitting reset from sensitivity list for async reset
• Mixing blocking and non-blocking assignments