Bird
Raised Fist0
Verilogprogramming~5 mins

Latch inference and how to avoid it in Verilog - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is latch inference in Verilog?
Latch inference happens when the synthesis tool creates a latch because some outputs are not assigned in all possible conditions inside a combinational always block.
Click to reveal answer
beginner
Why is latch inference usually undesirable in digital design?
Latches can cause timing problems and unpredictable behavior because they hold their previous value without a clock, making circuits harder to debug and slower to operate.
Click to reveal answer
beginner
How can you avoid latch inference in a combinational always block?
Make sure every output signal is assigned a value in every possible path of the always block, including the else parts of if statements or default assignments at the start.
Click to reveal answer
intermediate
What is a common coding pattern to prevent latch inference?
Assign default values to all outputs at the beginning of the always block, then override them conditionally. This ensures outputs always have a value.
Click to reveal answer
intermediate
Show an example of a latch inferred due to missing else branch.
always @(*) begin if (enable) out = in1; // Missing else: out keeps old value, latch inferred end
Click to reveal answer
What causes latch inference in a combinational always block?
ANot assigning outputs in all possible conditions
BUsing a clock signal
CAssigning outputs only once
DUsing blocking assignments
How can you prevent latch inference?
AUse only non-blocking assignments
BAssign default values to outputs at the start of the always block
CAvoid using if statements
DUse only clocked always blocks
Which of these is a sign that a latch might be inferred?
AUsing non-blocking assignments
BAll outputs are assigned in every branch
CUsing always @(posedge clk)
DAn output is assigned only inside an if without an else
Why are latches generally avoided in synchronous designs?
AThey cause timing uncertainty and glitches
BThey use too much power
CThey are slower than combinational logic
DThey require more code
What is a good practice when writing combinational always blocks?
AAvoid using else statements
BUse only blocking assignments
CAssign default values to outputs at the start
DUse only asynchronous resets
Explain what latch inference is and why it happens in Verilog.
Think about what happens when outputs are not assigned in all cases.
You got /3 concepts.
    Describe how to write Verilog code to avoid latch inference.
    Consider how to make sure outputs always get a value.
    You got /4 concepts.

      Practice

      (1/5)
      1. What causes latch inference in Verilog combinational blocks?
      easy
      A. Assigning default values to outputs
      B. Using clocked always blocks
      C. Using non-blocking assignments
      D. Not assigning output signals in all possible conditions

      Solution

      1. Step 1: Understand latch inference context

        Latch inference occurs when outputs inside combinational blocks are not assigned in every possible condition.
      2. Step 2: Identify cause of latch inference

        If an output is missing assignment in some branches, Verilog infers a latch to hold the previous value.
      3. Final Answer:

        Not assigning output signals in all possible conditions -> Option D
      4. Quick Check:

        Missing assignments cause latch inference [OK]
      Hint: Always assign outputs in every condition to avoid latches [OK]
      Common Mistakes:
      • Thinking clocked blocks cause latch inference
      • Believing non-blocking assignments cause latches
      • Ignoring missing else branches
      2. Which Verilog code snippet correctly avoids latch inference in a combinational block?
      easy
      A. always @(*) begin out = 0; if (sel) out = 1; end
      B. always @(*) begin if (sel) out = 1; end
      C. always @(posedge clk) begin if (sel) out <= 1; end
      D. always @(*) begin if (sel) out = 1; else if (sel) out = 0; end

      Solution

      1. Step 1: Check for default assignment

        always @(*) begin out = 0; if (sel) out = 1; end assigns a default value to 'out' before conditional checks, preventing latch inference.
      2. Step 2: Compare other options

        always @(*) begin if (sel) out = 1; end misses assignment when 'sel' is false, causing latch. always @(posedge clk) begin if (sel) out <= 1; end is clocked, not combinational. always @(*) begin if (sel) out = 1; else if (sel) out = 0; end misses assignment when 'sel' is false since both conditions require sel true, causing latch.
      3. Final Answer:

        Assigning default value before conditions to avoid latches -> Option A
      4. Quick Check:

        Default assignment prevents latch [OK]
      Hint: Assign default output values at start of combinational blocks [OK]
      Common Mistakes:
      • Omitting default assignments
      • Confusing clocked and combinational blocks
      • Using incomplete else branches
      3. Given the following Verilog code, what is the inferred hardware behavior?
      always @(*) begin
        if (a) out = 1;
        else if (b) out = 0;
        // no assignment if neither a nor b
      end
      medium
      A. Latch inferred to hold previous value when neither a nor b is true
      B. Combinational logic with no latch
      C. Synthesis error due to missing assignments
      D. Flip-flop inferred with clock input

      Solution

      1. Step 1: Analyze assignment coverage

        The code assigns 'out' only when 'a' or 'b' is true; no assignment otherwise.
      2. Step 2: Understand latch inference

        Missing assignment in some conditions causes Verilog to infer a latch to hold the last value.
      3. Final Answer:

        Latch inferred to hold previous value when neither a nor b is true -> Option A
      4. Quick Check:

        Missing else branch causes latch [OK]
      Hint: Check if all conditions assign outputs; else latch inferred [OK]
      Common Mistakes:
      • Assuming no latch because of if-else
      • Confusing latch with flip-flop
      • Thinking synthesis error occurs
      4. Identify the error in this Verilog code that causes latch inference:
      always @(*) begin
        if (enable) out = data;
        // no else branch
      end
      How can it be fixed?
      medium
      A. Use non-blocking assignments instead of blocking
      B. Change always @(*) to always @(posedge clk)
      C. Add an else branch assigning a default value to 'out'
      D. Remove the if condition entirely

      Solution

      1. Step 1: Identify missing assignment

        The code assigns 'out' only when 'enable' is true; no assignment otherwise causes latch.
      2. Step 2: Fix by adding else branch

        Adding an else branch with a default assignment ensures 'out' is assigned in all cases, avoiding latch.
      3. Final Answer:

        Add an else branch assigning a default value to 'out' -> Option C
      4. Quick Check:

        Complete assignments prevent latch [OK]
      Hint: Always include else branch or default assignment [OK]
      Common Mistakes:
      • Thinking clocked block fixes latch in combinational logic
      • Ignoring missing else branch
      • Confusing blocking and non-blocking assignments
      5. You want to design a combinational logic block in Verilog that outputs 'result' based on inputs 'x' and 'y'. To avoid latch inference, which of the following coding styles is best?
      always @(*) begin
        case ({x,y})
          2'b00: result = 0;
          2'b01: result = 1;
          2'b10: result = 1;
          // missing 2'b11 case
        endcase
      end
      hard
      A. Use an always @(posedge clk) block instead
      B. Add a default case assigning 'result' a value
      C. Remove the case statement and use if-else only
      D. Leave as is; synthesis tools will optimize automatically

      Solution

      1. Step 1: Identify incomplete case coverage

        The case statement misses the 2'b11 input combination, so 'result' is not assigned in that case.
      2. Step 2: Add default case to assign 'result'

        Adding a default case ensures 'result' is assigned for all inputs, preventing latch inference.
      3. Final Answer:

        Add a default case assigning 'result' a value -> Option B
      4. Quick Check:

        Complete case coverage avoids latch [OK]
      Hint: Always cover all cases or use default in case statements [OK]
      Common Mistakes:
      • Assuming missing case won't cause latch
      • Switching to clocked block unnecessarily
      • Ignoring default case importance
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard