Skip to content
VLSIMentor

VHDL · Chapter 19.7 · Interview and Industry Readiness

Debugging and Sim/Synth Interview Questions

The last technical round is often diagnostic: the interviewer hands you broken code or a bug report, classically the testbench passes but the chip fails, and watches how fast you classify the symptom and name the root cause. The culprits are a knowable catalogue, mostly simulation and synthesis mismatches. Common cases include an incomplete sensitivity list, an inferred latch from a missing default, an initial value wrongly used as a reset, a simulation-only construct treated as logic, multiple drivers producing an unknown value, an accidental extra pipeline stage, and metastability from an unsynchronized clock crossing. The winning move is to classify quickly, deciding whether it is a value bug, a storage bug, or a sim-synth bug, then state the root cause and the fix. This lesson is that debugging catalogue and the fast-classification method.

Foundation15 min readVHDLInterviewDebuggingSim/Synth MismatchRTLVerification

1. Engineering intuition — classify first, then locate

A debugging question feels open-ended, but experienced engineers don't read every line hoping to spot the error — they classify the symptom to shrink the search to a handful of known causes. The most informative split is by where the bug lives: is the value wrong/unknown (X, U, multiple drivers)? does the design have storage it should not (an inferred latch) or miss storage it should have (no reset, wrong pipeline depth)? or does it simulate fine but fail in hardware (a sim/synth mismatch)? Each class points at a small set of root causes you already know. So the interview skill is pattern-matching the symptom to its class first, then naming the specific cause and the fix — fast, confident classification beats a slow line-by-line read every time.

2. Formal explanation — the debugging catalogue

debug_catalogue.txt
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
-- CLASSIFY the symptom, then name the ROOT CAUSE and FIX:
--
-- A) SIM PASSES, CHIP/GLS FAILS  (the classic 'why does TB pass but silicon fail?')  -> sim/synth mismatch:
--    * INCOMPLETE SENSITIVITY LIST : sim misses an input; synthesis builds full logic.   FIX: process(all).
--    * INFERRED LATCH              : combinational output unassigned on a path.           FIX: default/cover.
--    * INITIAL VALUE AS RESET      : sim honours init; real FFs power up unknown.         FIX: explicit reset.
--    * SIM-ONLY CONSTRUCT AS LOGIC : 'after' delay / wait-for as 'logic' is ignored.      FIX: remove from RTL.
--
-- B) WRONG / UNKNOWN VALUE -> X or U:
--    * MULTIPLE DRIVERS            : two drivers conflict on a resolved net -> 'X'.        FIX: single driver.
--    * UNASSIGNED / NO RESET       : read before written -> 'U' spreads.                  FIX: reset/init.
--    (trace the X/U BACKWARD to the first node that is X with defined inputs.)
--
-- C) WRONG TIMING / DEPTH:
--    * SIGNAL WHERE VARIABLE MEANT : deferred signal adds an unintended register stage.   FIX: variable.
--    * METASTABILITY / CDC         : async signal into logic without a synchronizer.       FIX: 2-FF sync.
--
-- METHOD: classify (A/B/C) -> root cause -> rule->hardware->failure FIX.

The catalogue groups bugs into three classes — sim/synth mismatch (passes sim, fails hardware), wrong/unknown value (X/U), and wrong timing/depth (extra stage, metastability). Classifying into one of these immediately narrows the cause, and each cause has a one-line, well-rehearsed fix.

3. Production usage — reading broken code under interview pressure

reading_the_bug.vhd
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
-- Q: "This passes the testbench but fails on the FPGA. Why?" (class A: sim/synth mismatch)
process (a)                        -- INCOMPLETE sensitivity: b is read but not listed
begin
    y <= a and b;
end process;
-- ANSWER: sim only re-evaluates on 'a', so changes on 'b' are missed in simulation; synthesis builds the
--   real AND(a,b). Mismatch. FIX: process(all) (or list b). -- rule -> hardware -> failure, in one breath.
 
-- Q: "Synthesis warns 'inferred latch' on y." (class A / storage)
process (all) begin
    if en = '1' then y <= d; end if;   -- y unassigned when en='0' -> latch
end process;
-- ANSWER: y holds when en='0', so a level-sensitive latch is inferred. FIX: default 'y <= '0';' first.
 
-- Q: "q is one cycle later than expected." (class C: timing/depth)
-- s <= a + b; q <= s * c;            -- signal intermediate defers -> extra register stage
-- ANSWER: the signal 's' is deferred, inserting a pipeline stage. FIX: use a variable for the intermediate.

What hardware does this become? The point is diagnosis, not building — but each answer names the hardware the bug creates (a missed input in sim vs a real gate, a transparent latch, an extra flip-flop) and the one-line fix. Interviewers grade the speed and confidence of classification: a strong candidate reads the process, says class A, incomplete sensitivity, mismatch, fix with process(all) in seconds, because they recognize the pattern. Practicing the catalogue until each symptom maps instantly to its class, cause, and fix is what turns the find-the-bug round from a hunt into a lookup.

4. Structural interpretation — symptom to cause to fix

classify symptom into sim/synth mismatch, wrong value, or wrong timing, then map to root cause and fixA: sim passes, chipfailssensitivity / latch / init/ sim-onlyB: wrong / unknownvaluemultiple drivers,unassigned -> X/UC: wrong timing /depthextra stage, metastabilityroot cause -> fixrule -> hardware -> failure12
The debugging interview round is best handled by classifying the symptom before locating the line. Three classes cover almost every question: a simulation/synthesis mismatch (the testbench passes but the chip or gate-level sim fails) points to incomplete sensitivity, an inferred latch, an initial-value-as-reset, or a simulation-only construct used as logic; a wrong or unknown value (X or U) points to multiple drivers or an unassigned/unreset signal, found by tracing the metavalue backward; and a wrong timing or depth points to a deferred signal adding a pipeline stage or to metastability from an unsynchronized crossing. Each class maps to a small set of root causes, each with a one-line fix stated as rule, hardware, failure. This is a symptom-to-cause decision map, captured by a diagram rather than a waveform.

5. Why this is structural, not timing

The debugging round is a classification method and catalogue — how to map a symptom to its cause and fix — so the decision-map structure above is the right picture, not a waveform. The individual bugs have their own waveforms in the debugging and combinational/sequential modules; here the substance is the organization that lets you classify fast and answer confidently. That is a preparation-time, structural skill — recognizing patterns — rather than a single signal trace.

6. Debugging example — the 'testbench passes but the chip fails' question

Expected: a fast, confident diagnosis. Observed: the candidate, told a design passes simulation but fails on the FPGA, starts reading line by line for a functional error and misses it, because the bug is not a logic error at all. Root cause: the candidate did not classify — this symptom (passes sim, fails hardware) is the signature of a simulation/synthesis mismatch, which immediately narrows the search to a short list (incomplete sensitivity, inferred latch, init-as-reset, sim-only construct). Fix: recognize the symptom class first, then check that short list: ask is the sensitivity complete (process(all))? is every combinational output assigned on all paths? is a register relying on an initializer instead of a reset? is an after/wait being used as logic? Engineering takeaway: when a design passes simulation but fails in hardware, it is almost always a sim/synth mismatch — classify the symptom and check the short mismatch list, rather than hunting line by line for a functional bug.

classify_then_check.txt
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
-- BUG (method): read line-by-line for a logic error when the symptom is 'passes sim, fails chip'.
-- FIX (method): classify -> sim/synth mismatch -> check the short list:
--   process(all)? all comb outputs assigned? reset (not init)? no 'after'/wait used as logic?

7. Common mistakes & what to watch for

  • Not classifying first. Map the symptom to a class (sim/synth mismatch, X/U value, timing/depth) before reading line by line.
  • Missing the sim/synth signature. 'Passes sim, fails chip/GLS' is almost always a mismatch — check sensitivity, latch, init-as-reset, sim-only constructs.
  • Treating X/U as cosmetic. Trace the metavalue backward to the first node that is X/U with defined inputs — that is the source (often multiple drivers or no reset).
  • Overlooking timing-class bugs. A one-cycle-late output is usually a signal where a variable was meant (extra stage); a flaky cross-domain bug is metastability.
  • Stopping at the symptom. Always finish with root cause and the one-line fix in the rule → hardware → failure structure.

8. Engineering insight & continuity

The find-the-bug round rewards fast classification: sort the symptom into sim/synth mismatch, wrong/unknown value (X/U), or wrong timing/depth, and each class points at a short list of root causes with one-line fixes — the sim/synth catalogue (incomplete sensitivity, latch, init-as-reset, sim-only construct) being the most-tested. Classify, name the cause, give the fix as rule → hardware → failure. This completes the technical interview deep dives. The module closes by zooming out from individual questions to how real design teams actually work — the next lesson, The Industry RTL Workflow — so you can speak credibly about the end-to-end process.