Avoiding unintended latch inference in VHDL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output behavior of this VHDL process?

Consider the following VHDL process. What will be the inferred hardware behavior when this code is synthesized?

VHDL

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

A A combinational logic block with no memory elements.

B A latch is inferred because q is not assigned when enable = '0'.

C A flip-flop with enable control, no latch inferred.

D A flip-flop without enable, q updates every clock cycle.

💡 Hint

Think about whether q is assigned in all clock cycles.

Since q is assigned only inside the rising_edge(clk) and only when enable = '1', but q retains its previous value otherwise, this is a flip-flop with enable control. No latch is inferred because the assignment happens only on clock edges.

❓ Predict Output

intermediate

What error does this VHDL code cause during synthesis?

Analyze this VHDL process and determine what kind of hardware or synthesis issue it will cause.

VHDL

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

A A latch is inferred because y is not assigned when a = '0'.

B A flip-flop is inferred with asynchronous reset.

C Combinational logic with y always '1'.

D Synthesis error due to missing sensitivity list signals.

💡 Hint

Check if y is assigned in all possible conditions.

Because y is assigned only when a = '1' and not assigned otherwise, the synthesizer infers a latch to hold the previous value of y when a = '0'.

🔧 Debug

advanced

Identify the cause of unintended latch inference in this code

This VHDL process unintentionally infers a latch. Which line or condition causes this?

VHDL

process(sel, in1, in2)
begin
  if sel = '0' then
    outp <= in1;
  elsif sel = '1' then
    outp <= in2;
  end if;
end process;

A Using elsif instead of else causes latch inference.

B Sensitivity list missing clk signal causes latch.

C Assigning outp inside process causes latch.

D Missing else clause to assign outp when sel is neither '0' nor '1'.

💡 Hint

Think about what happens if sel has an unexpected value.

If sel is neither '0' nor '1', outp is not assigned any new value, so the synthesizer infers a latch to hold the previous value. Adding an else clause assigning outp fixes this.

📝 Syntax

advanced

Which option correctly avoids unintended latch inference?

Choose the VHDL process code that avoids unintended latch inference by ensuring all outputs are assigned in all conditions.

A

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

B

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

C

process(a, b)
begin
  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';
  else
    y <= 'Z';
  end if;
end process;

💡 Hint

Make sure y is assigned in every possible condition.

Option B assigns y in both if and else branches, so no latch is inferred. Other options miss assignments in some conditions, causing latch inference.

🚀 Application

expert

How many latches are inferred by this VHDL code?

Analyze the following VHDL process and determine how many latches will be inferred during synthesis.

VHDL

process(sel, a, b, c)
begin
  if sel = "00" then
    outp <= a;
  elsif sel = "01" then
    outp <= b;
  elsif sel = "10" then
    outp <= c;
  end if;
end process;

A One latch is inferred because outp is not assigned when sel = "11".

B No latch is inferred because all cases are covered.

C Two latches are inferred due to incomplete assignments.

D Synthesis error due to missing else clause.

💡 Hint

Check if outp is assigned for all possible sel values.

Since sel can be "11" and outp is not assigned in that case, a latch is inferred to hold the previous value of outp.

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