Latch inference and how to avoid it in Verilog - Step-by-Step Execution

Concept Flow - Latch inference and how to avoid it

Start always block

↓

Check if-else conditions

↓

Is output assigned in all branches?

No→Latch inferred

Yes↓

Output assigned in all cases

↓

No latch inferred

↓

End always block

The flow shows how missing assignments in some branches cause latch inference, and assigning outputs in all branches avoids it.

Execution Sample

Verilog

always @(*) begin
  if (enable)
    out = in;
  // missing else assignment
end

This code infers a latch because 'out' is not assigned when 'enable' is false.

Execution Table

Step	Condition (enable)	Output assigned?	Action	Latch inferred?
1	enable = 1	Yes (out = in)	Assign out = in	No
2	enable = 0	No	No assignment to out	Yes (latch inferred)
3	End	-	-	Stop: latch inferred due to missing assignment

💡 Latch inferred because output 'out' is not assigned when enable is 0

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
out	undefined	in (when enable=1)	retains previous value (when enable=0)	retains previous value (latch)

Key Moments - 2 Insights

Why does missing an else branch cause a latch?

Because in step 2 of the execution_table, when enable=0, 'out' is not assigned, so the hardware remembers the previous value, creating a latch.

How to avoid latch inference in combinational always blocks?

Assign the output variable in every possible branch, including else, so no value is left unassigned as shown in step 1 and 2.

Visual Quiz - 3 Questions

Look at the execution_table, what happens to 'out' when enable is 0?

A 'out' keeps its previous value (latch behavior)

B 'out' is assigned to zero

C 'out' is assigned to 'in'

D 'out' becomes undefined

💡 Hint

Check step 2 in execution_table where enable=0 and output is not assigned

At which step does the latch get inferred according to the execution_table?

A Step 1

B Step 3

C Step 2

D No latch inferred

💡 Hint

Look at the 'Latch inferred?' column in execution_table

If we add an else branch assigning 'out = 0', how does the execution_table change?

A Latch inference still occurs at step 2

B Latch inference is avoided; 'out' assigned in all steps

C 'out' becomes undefined at step 1

D No change in latch inference

💡 Hint

Think about assigning 'out' in all branches to avoid latch as explained in key_moments

Concept Snapshot

Latch inference happens when outputs are not assigned in all branches of combinational always blocks.
To avoid latches, always assign outputs in every if-else branch.
Missing assignments cause hardware to remember previous values (latch).
Use default assignments or else branches to cover all cases.
This ensures combinational logic without unintended memory.

Full Transcript

Latch inference in Verilog occurs when an output variable inside a combinational always block is not assigned in all possible branches of the code. For example, if an if statement assigns a value to an output when a condition is true but there is no else branch assigning the output when the condition is false, the hardware infers a latch to remember the previous value. This is because the output must hold its value when not explicitly assigned. The execution table shows that when enable is 1, the output is assigned, but when enable is 0, the output is not assigned, causing latch inference. To avoid this, always assign the output in every branch, including else, or provide a default assignment at the start of the always block. This practice ensures the output is always driven and no latch is created. Understanding this helps write correct combinational logic without unintended memory elements.