We want to make sure our digital circuit works correctly. Unintended latches can cause bugs and unpredictable behavior.
Avoiding unintended latch inference in VHDL
process(signal_list) is begin if condition then output_signal <= value1; else output_signal <= value2; end if; end process;
Always assign a value to output signals in every possible path inside the process.
Missing assignments in some branches cause VHDL to infer latches.
process(a, b) is begin if a = '1' then y <= '0'; else y <= '1'; end if; end process;
process(a, b) is begin if a = '1' then y <= '0'; end if; end process;
process(a, b) is begin if a = '1' then y <= '0'; else y <= y; -- hold previous value explicitly end if; end process;
This example shows a simple process that assigns y in both branches, avoiding unintended latch inference.
library ieee; use ieee.std_logic_1164.all; entity latch_example is port( a : in std_logic; y : out std_logic ); end latch_example; architecture behavioral of latch_example is begin process(a) is begin if a = '1' then y <= '1'; else y <= '0'; end if; end process; end behavioral;
Unintended latches happen when signals are not assigned in all branches of a process.
Always check your conditional statements to cover all cases.
Use default assignments before conditions to avoid missing assignments.
Unintended latches cause bugs and unpredictable hardware behavior.
Assign outputs in every possible path inside a process.
Careful coding helps your design synthesize correctly without hidden memory elements.
Practice
Solution
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.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.Final Answer:
Not assigning a signal in all possible branches inside a process -> Option AQuick Check:
Missing assignments = unintended latch [OK]
- Thinking latches come from clocked processes only
- Assuming variables cause latches
- Believing combinational logic never infers latches
Solution
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.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.Final Answer:
process(a, b) begin y <= '0'; if a = '1' then y <= '1'; end if; end process; -> Option CQuick Check:
Default assignment before conditions = no latch [OK]
- Using null instead of assigning signals
- Not covering all conditions with assignments
- Assuming else branch is optional
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;
Solution
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'.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'.Final Answer:
y = '0' -> Option AQuick Check:
Taken branch assigns despite inferred latch [OK]
- Assuming y always updates without default assignment
- Ignoring latch inference on missing else
- Confusing latch with high impedance
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;
Solution
Step 1: Check assignments inside clocked process
When enable = '1', q <= d assigned. But when enable /= '1', q is not assigned any value.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.Final Answer:
Missing assignment to q when enable /= '1' -> Option BQuick Check:
All branches must assign signals to avoid latches [OK]
- Assuming reset covers all cases
- Ignoring else branch after enable check
- Thinking sensitivity list causes latch
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;Solution
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.Step 2: Verify conditional assignments
Then it overrides z if a='1' or b='1', covering all cases without missing assignments.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.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 DQuick Check:
Default assignment before conditions prevents latches [OK]
- Omitting else branch or default assignment
- Using null instead of assigning signal
- Incorrect nested if causing missed assignments
Ready to prove it?
Pass the test and this pattern moves unknown
