Coding for synthesis best practices in Verilog - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Verilog simulation snippet?

Consider the following Verilog code snippet. What value will the register count hold after 5 clock cycles?

module counter(input clk, input rst, output reg [3:0] count);
  always @(posedge clk or posedge rst) begin
    if (rst)
      count <= 0;
    else
      count <= count + 1;
  end
endmodule

Verilog

module testbench();
  reg clk = 0;
  reg rst = 1;
  wire [3:0] count;
  counter uut(clk, rst, count);

  always #5 clk = ~clk;

  initial begin
    #10 rst = 0;
    #50 $display("Count = %d", count);
    $finish;
  end
endmodule

A Count = 6

B Count = 0

C Count = 5

D Count = 4

💡 Hint

Remember that the counter increments on the rising edge of clk after reset is deasserted.

The reset is active for the first 10 time units, so the counter starts counting from 0 after that. The clock period is 10 time units, so after 5 clock cycles (50 time units), the count will be 5 because the first increment happens at the first rising edge after reset is released.

🧠 Conceptual

intermediate

Which coding style is best for synthesizable combinational logic?

You want to write combinational logic in Verilog that is synthesizable and avoids unintended latches. Which of the following coding styles is best practice?

A Use <code>always @(negedge clk)</code> blocks with blocking assignments.

B Use <code>always @(posedge clk)</code> blocks with non-blocking assignments.

C Use <code>initial</code> blocks to set output values.

D Use <code>always @(*)</code> blocks with blocking assignments and assign all outputs in every branch.

💡 Hint

Combinational logic should react to any input change and avoid memory elements.

Using always @(*) with blocking assignments and assigning all outputs in every possible branch ensures combinational logic without latches. Using clocked blocks or initial blocks is for sequential or simulation-only code.

🔧 Debug

advanced

Identify the synthesis issue in this Verilog code

This Verilog code is intended to implement a 2-to-1 multiplexer. However, synthesis tools infer unintended latches. What is the 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 The missing else branch causes y to hold its previous value, inferring a latch.

B Using <code>output reg</code> causes synthesis to infer a latch.

C The sensitivity list <code>always @(*)</code> is incorrect for combinational logic.

D The input signals a and b are not declared as reg types.

💡 Hint

Think about what happens when sel is 0.

Because y is not assigned a value when sel is 0, the synthesis tool infers a latch to hold the previous value. To avoid this, assign y in all branches.

📝 Syntax

advanced

Which Verilog code snippet correctly implements a synchronous reset flip-flop?

Select the code snippet that correctly implements a positive-edge triggered flip-flop with synchronous reset.

A

always @(posedge clk) begin
  if (rst)
    q <= 0;
  else
    q <= d;
end

B

always @(posedge clk or posedge rst) begin
  if (rst)
    q <= 0;
  else
    q <= d;
end

C

always @(negedge clk) begin
  if (rst)
    q <= 0;
  else
    q <= d;
end

D

always @(posedge clk) begin
  if (!rst)
    q <= 0;
  else
    q <= d;
end

💡 Hint

Synchronous reset means reset is checked only on clock edge.

Option A uses only posedge clk in sensitivity list and checks reset inside the block, making reset synchronous. Option A uses asynchronous reset. Option A uses negedge clk which is uncommon. Option A has inverted reset logic.

🚀 Application

expert

How many flip-flops are inferred by this Verilog code?

Given the following Verilog code, how many flip-flops will the synthesis tool infer?

Verilog

module regfile(input clk, input rst, input [1:0] addr, input d, output reg q);
  reg [3:0] mem;
  always @(posedge clk or posedge rst) begin
    if (rst)
      mem <= 4'b0000;
    else
      mem[addr] <= d;
  end
  always @(*) begin
    q = mem[addr];
  end
endmodule

A 2 flip-flops

B 4 flip-flops

C 1 flip-flop

D No flip-flops, only combinational logic

💡 Hint

Each bit of mem is a register element updated on clock edge.

The 4-bit register mem is updated on clock edge, so 4 flip-flops are inferred. The output q is combinationally assigned from mem.

Practice

1. Which of the following is a best practice for writing combinational logic in Verilog for synthesis?

easy

A. Leave some outputs unassigned to infer latches.

B. Use non-blocking assignments (<=) inside an always @(*) block.

C. Use delays like #5 to model timing.

D. Use blocking assignments (=) inside an always @(*) block.

Solution

1. Step 1: Understand combinational logic coding

   Combinational logic should be written using blocking assignments (=) to ensure correct immediate updates within the always @(*) block.

2. Step 2: Identify synthesis best practices

   Using non-blocking assignments or delays in combinational blocks can cause unintended behavior or non-synthesizable code.

3. Final Answer:

   Use blocking assignments (=) inside an always @(*) block. -> Option D

4. Quick Check:

   Combinational logic = blocking assignments [OK]

Hint: Use blocking (=) for combinational, non-blocking (<=) for sequential [OK]

Common Mistakes:

• Using non-blocking assignments in combinational blocks
• Adding delays (#) which are not synthesizable
• Leaving outputs unassigned causing inferred latches

2. Which of the following is the correct sensitivity list for a combinational always block in Verilog?

easy

A. always @(*)

B. always @(negedge reset)

C. always @(posedge clk)

D. always @(clk or reset)

Solution

1. Step 1: Identify combinational block sensitivity

   Combinational logic should react to all input changes, so always @(*) automatically includes all signals read inside the block.

2. Step 2: Compare other options

   Options with clock edges or specific signals are used for sequential logic, not combinational.

3. Final Answer:

   always @(*) -> Option A

4. Quick Check:

   Combinational sensitivity = always @(*) [OK]

Hint: Use always @(*) for combinational blocks to cover all inputs [OK]

Common Mistakes:

• Using clock edges in combinational blocks
• Listing incomplete sensitivity signals manually
• Forgetting to include all inputs causing latches

3. What is the output of the following Verilog code snippet when clk rises?

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

medium

A. q updates but may cause simulation vs synthesis mismatch

B. Syntax error due to blocking assignment in sequential block

C. q updates correctly on clock edge

D. q never updates

Solution

1. Step 1: Analyze assignment type in sequential block

   The code uses blocking assignment (=) inside a clocked always block, which is not recommended for registers.

2. Step 2: Understand synthesis vs simulation behavior

   While synthesis tools may infer the register correctly, simulation can show unexpected behavior due to immediate assignment instead of scheduled update.

3. Final Answer:

   q updates but may cause simulation vs synthesis mismatch -> Option A

4. Quick Check:

   Sequential block + blocking assignment = mismatch risk [OK]

Hint: Use non-blocking (<=) in sequential blocks to avoid mismatches [OK]

Common Mistakes:

• Using blocking (=) in clocked always blocks
• Expecting immediate update in sequential logic
• Confusing simulation behavior with synthesis

4. Identify the error in the following Verilog code snippet intended for synthesis:

always @(posedge clk) begin
  if (enable)
    q <= d;
  else
    ; // missing else assignment
end

medium

A. Sensitivity list is incomplete

B. Using non-blocking assignment in sequential block is wrong

C. Missing non-blocking assignment in else branch causes inferred latch

D. Syntax error due to empty else statement

Solution

1. Step 1: Check assignments in all branches

   The else branch has no assignment to q, so q retains its previous value, causing a latch to be inferred.

2. Step 2: Understand synthesis best practice

   To avoid latches, all outputs must be assigned in every branch of a sequential block.

3. Final Answer:

   Missing non-blocking assignment in else branch causes inferred latch -> Option C

4. Quick Check:

   All branches assign outputs to avoid latches [OK]

Hint: Assign outputs in all if-else branches to prevent latches [OK]

Common Mistakes:

• Leaving else branch empty causing inferred latch
• Confusing blocking and non-blocking assignments
• Ignoring sensitivity list completeness in sequential blocks

5. You want to design a 4-bit counter with synchronous reset using best synthesis practices. Which code snippet correctly implements this?

hard

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

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

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

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

Solution

1. Step 1: Identify synchronous reset and non-blocking assignments

   Synchronous reset means reset is checked only on clock edge, so sensitivity list should only have posedge clk. Non-blocking assignments (<=) must be used for registers.

2. Step 2: Evaluate each option

   always @(posedge clk or posedge reset) begin if (reset) count <= 0; else count = count + 1; end uses asynchronous reset (posedge reset) and blocking assignment in else branch, which is not best practice. always @(posedge clk) begin if (reset == 1'b1) count = 0; else count <= count + 1; end mixes blocking and non-blocking assignments. always @(posedge clk) begin if (reset) count <= 0; else count = count + 1; end uses blocking assignment in else branch. Only always @(posedge clk) begin if (reset) count <= 0; else count <= count + 1; end uses synchronous reset and non-blocking assignments consistently.

3. Final Answer:

   Option B correctly implements a 4-bit counter with synchronous reset and proper assignments. -> Option B

4. Quick Check:

   Synchronous reset + non-blocking assignments = always @(posedge clk) begin if (reset) count <= 0; else count <= count + 1; end [OK]

Hint: Use only posedge clk and non-blocking (<=) for synchronous reset counters [OK]

Common Mistakes:

• Mixing blocking and non-blocking assignments in sequential logic
• Using asynchronous reset when synchronous is required
• Including reset in sensitivity list for synchronous reset