Avoiding unintended latch inference in VHDL - Step-by-Step Execution

Concept Flow - Avoiding unintended latch inference

Start process

↓

Check if all outputs assigned in all branches?

No↓

Latch inferred (holds previous value)

↓

END

↓

Start process

↓

All outputs assigned in all branches?

Yes↓

No latch inferred, output updated

↓

END

This flow shows that if outputs are not assigned in every branch of a process, VHDL infers a latch to hold the previous value. Assigning outputs in all branches avoids unintended latches.

Execution Sample

VHDL

process(sel, a, b)
begin
  if sel = '1' then
    y <= a;
  end if;
end process;

This code shows a process where output y is assigned only when sel='1', causing a latch inference because y is not assigned otherwise.

Execution Table

Step	Condition (sel='1'?)	y assigned?	Latch inferred?	Explanation
1	sel = '1'	y <= a	No	Output y assigned, no latch needed here
2	sel = '0'	y not assigned	Yes	No assignment means latch inferred to hold previous y
3	Process ends	-	-	Latch inferred due to missing assignment in else branch

💡 Latch inferred because y is not assigned when sel='0'

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
sel	unknown	'1'	'0'	varies
y	unknown	a (assigned)	previous y (held by latch)	varies

Key Moments - 2 Insights

Why does VHDL infer a latch if output is not assigned in all branches?

Because in the execution_table at Step 2, y is not assigned when sel='0', so VHDL infers a latch to remember the last value.

How can we avoid unintended latch inference in this example?

By assigning y in all branches, for example adding an else branch that assigns y a default value, as shown by the missing assignment causing latch in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the latch inferred?

A Step 1

B Step 2

C Step 3

D No latch inferred

💡 Hint

Check the 'Latch inferred?' column in the execution_table rows

According to variable_tracker, what happens to y when sel='0'?

A y is assigned a new value

B y is reset to zero

C y holds its previous value via latch

D y becomes undefined

💡 Hint

Look at y's value after Step 2 in variable_tracker

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

A Latch inference disappears

B Latch inference remains

C Process stops early

D y is never assigned

💡 Hint

Refer to the explanation in key_moments about assigning outputs in all branches

Concept Snapshot

Avoiding unintended latch inference in VHDL:
- Always assign outputs in every branch of a process
- Missing assignments cause VHDL to infer latches
- Use else or default assignments to prevent latches
- Latches hold previous values, often unwanted
- Check all conditions to ensure full output coverage

Full Transcript

In VHDL, if you do not assign a signal in every possible branch of a process, the compiler infers a latch to hold the previous value. This happens because the hardware needs to remember the last output when no new value is given. For example, if you assign output y only when sel='1' but not otherwise, a latch is created. To avoid this, assign y in all branches, such as adding an else branch with a default value. This prevents unintended latches and makes your design behave as expected.

Practice

1. What causes unintended latch inference in a VHDL process?

easy

A. Not assigning a signal in all possible branches inside a process

B. Using only combinational logic without clocks

C. Assigning signals only in the clocked part of a process

D. Using variables instead of signals

Solution

1. Step 1: Understand latch inference

   In VHDL, if a signal is not assigned in every possible condition inside a process, the synthesizer infers a latch to hold the previous value.

2. Step 2: Identify cause of unintended latches

   Missing assignments in some branches cause the tool to create latches to remember old values, which is usually unintended.

3. Final Answer:

   Not assigning a signal in all possible branches inside a process -> Option A

4. Quick Check:

   Missing assignments = unintended latch [OK]

Hint: Always assign signals in every branch to avoid latches [OK]

Common Mistakes:

• Thinking latches come from clocked processes only
• Assuming variables cause latches
• Believing combinational logic never infers latches

2. Which VHDL code snippet correctly avoids unintended latch inference?

easy

A. process(a, b) begin if a = '1' then y <= '1'; else null; end if; end process;

B. process(a, b) begin if a = '1' then y <= '1'; end if; end process;

C. process(a, b) begin y <= '0'; if a = '1' then y <= '1'; end if; end process;

D. process(a, b) begin if a = '1' then y <= '1'; elsif b = '1' then y <= '0'; end if; end process;

Solution

1. Step 1: Check assignments in all branches

   process(a, b) begin y <= '0'; if a = '1' then y <= '1'; end if; end process; assigns y <= '0' before the if, so y is always assigned regardless of conditions.

2. Step 2: Compare other options

   process(a, b) begin if a = '1' then y <= '1'; end if; end process; misses assignment when a /= '1', causing latch. process(a, b) begin if a = '1' then y <= '1'; else null; end if; end process; uses null which does not assign y. process(a, b) begin if a = '1' then y <= '1'; elsif b = '1' then y <= '0'; end if; end process; misses assignment if neither condition is true.

3. Final Answer:

   process(a, b) begin y <= '0'; if a = '1' then y <= '1'; end if; end process; -> Option C

4. Quick Check:

   Default assignment before conditions = no latch [OK]

Hint: Use default assignments before conditions to prevent latches [OK]

Common Mistakes:

• Using null instead of assigning signals
• Not covering all conditions with assignments
• Assuming else branch is optional

3. What is the output of this VHDL process for input a = '0' and b = '1'?

process(a, b) begin if a = '1' then y <= '1'; elsif b = '1' then y <= '0'; end if; end process;

medium

A. y = '0'

B. y = '1'

C. y retains previous value (latch inferred)

D. y = 'Z' (high impedance)

Solution

1. Step 1: Analyze conditions for a='0', b='1'

   The first if (a='1') is false, so skip to elsif (b='1'), which is true, so y <= '0'.

2. Step 2: Note latch inference overall

   A latch is inferred because the case a='0', b='0' has no assignment. However, for the given inputs a='0', b='1', y is explicitly assigned '0'.

3. Final Answer:

   y = '0' -> Option A

4. Quick Check:

   Taken branch assigns despite inferred latch [OK]

Hint: Check if all input combos assign output to avoid latches [OK]

Common Mistakes:

• Assuming y always updates without default assignment
• Ignoring latch inference on missing else
• Confusing latch with high impedance

4. Identify the error causing unintended latch inference in this code:

process(clk, reset) begin if reset = '1' then q <= '0'; elsif rising_edge(clk) then if enable = '1' then q <= d; end if; end if; end process;

medium

A. Using rising_edge(clk) incorrectly

B. Missing assignment to q when enable /= '1'

C. Incorrect sensitivity list

D. Missing reset condition

Solution

1. Step 1: Check assignments inside clocked process

   When enable = '1', q <= d assigned. But when enable /= '1', q is not assigned any value.

2. Step 2: Understand latch inference in clocked process

   Not assigning q in all branches inside clocked process causes latch inference to hold previous q value.

3. Final Answer:

   Missing assignment to q when enable /= '1' -> Option B

4. Quick Check:

   All branches must assign signals to avoid latches [OK]

Hint: Assign signals in every if-else branch inside clocked processes [OK]

Common Mistakes:

• Assuming reset covers all cases
• Ignoring else branch after enable check
• Thinking sensitivity list causes latch

5. You want to design a combinational process that outputs z based on inputs a and b. Which code snippet best avoids unintended latch inference while implementing:
if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; else z <= 'X'; end if;

hard

A. process(a, b) begin if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; end if; end process;

B. process(a, b) begin if a = '1' then z <= '1'; if b = '1' then z <= '0'; else z <= 'X'; end if; end if; end process;

C. process(a, b) begin if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; else null; end if; end process;

D. process(a, b) begin z <= 'X'; if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; end if; end process;

Solution

1. Step 1: Check for default assignment

   process(a, b) begin z <= 'X'; if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; end if; end process; assigns z <= 'X' before conditions, ensuring z always has a value.

2. Step 2: Verify conditional assignments

   Then it overrides z if a='1' or b='1', covering all cases without missing assignments.

3. Step 3: Analyze other options

   process(a, b) begin if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; end if; end process; misses else assignment causing latch. process(a, b) begin if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; else null; end if; end process; uses null which does not assign z. process(a, b) begin if a = '1' then z <= '1'; if b = '1' then z <= '0'; else z <= 'X'; end if; end if; end process; has nested ifs causing logic errors and possible latch.

4. Final Answer:

   process(a, b) begin z <= 'X'; if a = '1' then z <= '1'; elsif b = '1' then z <= '0'; end if; end process; -> Option D

5. Quick Check:

   Default assignment before conditions prevents latches [OK]

Hint: Set default output before conditions to cover all cases [OK]

Common Mistakes:

• Omitting else branch or default assignment
• Using null instead of assigning signal
• Incorrect nested if causing missed assignments