Coding for synthesis best practices in Verilog - Step-by-Step Execution

Concept Flow - Coding for synthesis best practices

Write RTL code

↓

Follow synthesis rules

↓

Avoid latches

↓

Use synchronous resets

↓

Use inferred flip-flops

↓

Check for combinational loops

↓

Run synthesis tool

↓

Review synthesis report

↓

Optimize and fix issues

↓

Final synthesized design

This flow shows the steps to write Verilog code that synthesizes well, avoiding common pitfalls and ensuring good hardware implementation.

Execution Sample

Verilog

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

A simple 4-bit synchronous counter with synchronous reset, following synthesis best practices.

Execution Table

Step	Signal	Condition	Action	Value After
1	reset	reset=1	count <= 0	count=0
2	reset	reset=0	count <= count + 1	count=1
3	reset	reset=0	count <= count + 1	count=2
4	reset	reset=0	count <= count + 1	count=3
5	reset	reset=1	count <= 0	count=0
6	reset	reset=0	count <= count + 1	count=1
7	reset	reset=0	count <= count + 1	count=2
Exit	-	Simulation ends	-	-

💡 Simulation ends after several clock cycles demonstrating synchronous reset and counting.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7	Final
count	x (unknown)	0	1	2	3	0	1	2	2

Key Moments - 3 Insights

Why do we use synchronous reset instead of asynchronous reset?

Synchronous reset ensures the reset signal is sampled on the clock edge, avoiding timing issues and glitches during synthesis, as shown in steps 1 and 5 where reset is checked only at clock edges.

What happens if we forget to assign 'count' in all branches of the always block?

If 'count' is not assigned in all branches, synthesis tools may infer latches, which are usually unwanted. Our example always assigns 'count' either to 0 or count+1, preventing latches (see all steps in execution_table).

Why is it important to avoid combinational loops in synthesis?

Combinational loops cause unstable hardware and synthesis errors. Our example uses only sequential logic with clocked always block, avoiding such loops.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'count' after step 3?

A 1

B 3

C 2

D 0

💡 Hint

Check the 'Value After' column in row with Step 3.

At which step does the synchronous reset set 'count' back to zero?

A Step 5

B Step 2

C Step 4

D Step 7

💡 Hint

Look for the step where 'reset=1' and action is 'count <= 0' in the execution table.

If we remove the 'else' branch in the always block, what synthesis issue might occur?

A No change

B Inferred latch

C Combinational loop

D Synchronous reset failure

💡 Hint

Refer to key moment about assigning 'count' in all branches to avoid latches.

Concept Snapshot

Verilog synthesis best practices:
- Use synchronous resets inside clocked always blocks
- Assign all outputs in all branches to avoid latches
- Avoid combinational loops
- Use non-blocking assignments (<=) for sequential logic
- Check synthesis reports to catch issues early

Full Transcript

This visual execution shows how to write Verilog code that synthesizes well. We start by writing RTL code with a synchronous reset inside a clocked always block. The execution table traces the 'count' variable through clock cycles, showing reset and counting behavior. Key moments explain why synchronous reset is preferred, why assigning outputs in all branches avoids latches, and why combinational loops must be avoided. The quiz tests understanding of these steps and common pitfalls. The snapshot summarizes the main rules for synthesis-friendly Verilog coding.

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