Digital Logic interview questions

10 questions, easiest first

1. 1You build a 4-to-1 multiplexer out of three 2-to-1 muxes (two feeding a third), and you use it to select between four sensor signals based on a 2-bit select code. When you scope the output while the select lines are changing between certain codes, you occasionally see a very brief unwanted pulse (a glitch) on the output even though the correct value settles a few nanoseconds later. Explain why this glitch appears and whether it matters for your application.intro

   This is a first-pass check on whether a candidate understands combinational logic as delay-laden circuitry rather than an instantaneous truth table.

   Answer this one, graded

   Or just show what a strong answer covers

   Every mux and gate has propagation delay, and those delays aren't identical across all paths from input to output. When the 2-bit select code changes, the two internal 2:1 muxes and the final 2:1 mux don't necessarily switch at exactly the same instant, so for a brief window the output can reflect an intermediate, incorrect selection before settling to the right value a few nanoseconds later. This is a classic combinational glitch, most likely to appear when multiple select bits toggle at once. Whether it matters depends on how the output is consumed: if it feeds a flip-flop that only samples well after the settling time, the glitch is invisible to the rest of the system. If it feeds another asynchronous combinational block, or something edge-sensitive like a clock or reset line, that glitch could propagate as a real logic error.

   • Identifies unequal propagation delay as the cause — States that internal muxes/gates have different delays so select transitions don't propagate uniformly, causing a momentary wrong combination at the output.
   • Connects glitch to select-line transitions specifically — Explains that the glitch is worst when multiple select bits change at once, since intermediate states can briefly select the wrong input.
   • Discusses whether it matters given how output is used — Notes that if output is registered on a clock edge after settling time, glitch is harmless; if used asynchronously (e.g., feeding another combinational stage or an async reset), it can cause real errors.

   Where answers go wrong: Saying combinational logic is 'instantaneous' and glitches shouldn't happen. · Blaming it entirely on noise/EMI instead of internal timing. · Not addressing whether the glitch actually causes a functional problem.

2. 2You built a 4-bit one-hot to 2-bit binary priority encoder using basic AND/OR/NOT gates. Steady-state testing shows the output is correct for every valid one-hot input. But when you switch quickly from one active request line to another, a logic analyzer captures the output briefly flickering to an invalid code for a few nanoseconds before settling to the correct new value. Walk me through why this happens and how you would confirm it's this specific issue rather than a wiring or logic error.intro

   The encoder has no registers -- it's pure combinational logic feeding directly from the input switches to the output pins.

   Answer this one, graded

   Or just show what a strong answer covers

   This looks like a static hazard, not a logic bug. When you switch from one active input to another, different signal paths through the AND/OR network have slightly different numbers of gates and thus different propagation delays. During the brief window while some paths have updated and others haven't, the output can pass through a code that doesn't correspond to any valid steady-state input. I'd confirm this by checking that the glitch only appears right at input transitions, never in steady state, and that its duration is on the order of a few gate delays -- which matches nanosecond timescale, not a persistent error. I'd use a scope or logic analyzer fast enough to actually capture something that short; if my sample rate is too slow I might miss it entirely and think the circuit works. Since the logic settles to the correct value, the truth table implementation itself isn't wrong. If this feeds combinational logic downstream I'd worry about it propagating; if it only feeds a flip-flop that samples well after the transition, the glitch is harmless.

   • Identifies unequal path delays as the root cause — States that different combinational paths through the gates have different propagation delays, causing a temporary invalid output during a transition.
   • Correctly names this a hazard/glitch, not a design flaw — Explicitly distinguishes this transient behavior from a persistent logic error, noting it self-corrects once signals settle.
   • Proposes a way to verify it's a hazard — Describes checking that the glitch duration is on the order of gate delay (ns), occurs only at transitions, and using an instrument with sufficient bandwidth/sample rate to catch it.
   • Mentions a mitigation, even briefly — Suggests something like registering the output, adding redundant terms to cover the hazard, or simply noting downstream logic should be clocked so the glitch is masked.

   Where answers go wrong: Assuming the encoder logic itself is wrong and trying to re-derive the truth table instead of considering timing. · Not distinguishing between a static hazard and a genuine race condition in sequential logic. · Suggesting a fix (like adding a flip-flop) without first explaining why the glitch occurs.

3. 3You're asked to design a state machine that controls a single LED beacon: press a button once and it blinks slowly, press it again and it blinks fast, press it a third time and it turns off, then repeats. A junior teammate draws a state diagram with three states and, in the 'slow blink' state, has a combinational path that directly asserts the 'turn off' output based on both the current LED phase and the button signal, without going through a clocked register. Why is this implementation likely to be broken, and how would you fix it?easy

   Tests whether a candidate understands the difference between a state machine on paper and one that is actually implementable in real hardware with a clock.

   Answer this one, graded

   Or just show what a strong answer covers

   The problem isn't the three-state diagram itself, it's that the implementation reacts directly to the raw button signal in combinational logic instead of treating it as an unsynchronized, possibly bouncy input. A physical button isn't aligned to the clock and can chatter for milliseconds, so gating output logic straight off it can produce spurious transitions or glitches on the LED output. The fix is to first pass the button through a couple of flip-flops to synchronize it to the clock domain, then run it through simple debounce/edge-detect logic so you get one clean pulse per press. Only then should that clean, registered signal feed the state machine's next-state logic, with the actual state itself stored in flip-flops updated once per clock edge -- never derived live and unregistered from the button.

   • Flags the raw button signal as a hazard — Explains that the button is asynchronous and possibly bouncy, so directly gating output logic with it can cause glitches or missed/extra transitions.
   • Distinguishes stored state from combinational output logic — Clarifies that state (which blink mode we're in) must live in a register clocked by the system clock, not be re-derived live from an unregistered input.
   • Proposes a concrete fix — Suggests synchronizing the button through flip-flops and adding debounce/edge-detection before feeding it into the synchronous state machine's next-state logic.

   Where answers go wrong: Saying the state diagram itself is wrong rather than the implementation choice of using an unregistered signal. · Ignoring button bounce entirely. · Proposing to just 'add more states' without addressing the synchronization problem.

4. 4You have a microcontroller GPIO output running at 5V logic levels driving directly into the input pin of a separate chip that is specified to run at 3.3V. The system powers up and seems to work for a few minutes, then the 3.3V chip starts behaving erratically and eventually stops responding. What's the likely cause, and what would you check or change?easy

   Basic mixed-voltage interfacing is a very common early mistake, and reasoning about it requires understanding logic thresholds and device ratings rather than memorizing a spec sheet.

   Answer this one, graded

   Or just show what a strong answer covers

   The likely culprit is that the 5V output is exceeding the 3.3V part's absolute maximum input voltage rating, not just its recommended logic-high threshold. Many 3.3V devices have clamp diodes or ESD structures on their inputs that can tolerate brief overvoltage, but continuously driving 5V into them stresses those structures and can degrade the part over time rather than killing it instantly -- which matches the 'works for a few minutes then degrades' symptom. I'd pull the datasheet for the 3.3V part and check its absolute max input voltage against what I'm actually applying, and I'd probe the line with a scope to confirm the real voltage swing at the pin. The fix is to not connect 5V directly: use a proper level shifter, or if the signal is simple and slow, a resistor divider or open-drain output with a pull-up to 3.3V, so the receiving pin never sees more than its rated voltage.

   • Identifies over-voltage on the input as the root cause — States that the 5V signal exceeds the 3.3V part's rated input voltage, likely beyond its absolute maximum rating.
   • Explains why failure is delayed rather than instant — Notes that overstress damage can accumulate over time (e.g., protection diode or junction degradation) rather than always causing immediate failure.
   • Proposes a correct fix — Recommends a level shifter, voltage divider, or other proper interface instead of a direct 5V-to-3.3V connection, and mentions checking the datasheet's absolute max ratings.

   Where answers go wrong: Assuming all digital logic is voltage-tolerant as long as it 'reads as high'. · Blaming it on noise or grounding without addressing the voltage mismatch. · Suggesting a fix that only reduces average voltage without limiting peak/transient voltage (e.g. an inadequate divider).

5. 5You wired up what you believe is a D flip-flop clocked by a signal, and you expect the output Q to change only on the rising edge of the clock. During testing, you notice Q actually follows D and changes any time D changes while the clock is high, not just at the edge. What's most likely going on, and how would you prove it on the bench?easy

   You're using a discrete chip from a datasheet and a function generator for the clock, probing D, clock, and Q with a scope.

   Answer this one, graded

   Or just show what a strong answer covers

   That behavior -- Q tracking D any time the clock is high -- is the classic signature of a transparent latch, not an edge-triggered flip-flop. A real D flip-flop only samples D at the instant of the clock edge and holds that value until the next edge, regardless of what D does afterward. To confirm, I'd hold the clock high with the function generator or a static high level and toggle D by hand or with a slow square wave, then watch Q on the scope: if Q follows D continuously while clock stays high, it's transparent, which proves it's a latch. I'd also pull the actual datasheet for the part I placed and check its truth table and part number, since it's easy to grab a latch when you meant to grab a flip-flop, or to mis-wire an enable pin as if it were a clock pin. The fix is either using the correct edge-triggered part or adding a proper edge-detection/second stage if I'm stuck with what's on hand.

   • Identifies latch-vs-flip-flop confusion as the likely cause — States that the observed behavior (Q follows D throughout the clock-high period) is characteristic of a level-sensitive latch, not an edge-triggered flip-flop.
   • Explains the behavioral distinction precisely — Correctly describes that a latch is transparent while enabled and a flip-flop samples only at the clock edge.
   • Describes a concrete bench test to confirm it — Proposes holding clock high and varying D while watching Q, or overlaying traces to show Q changes are not aligned to a single edge.
   • Mentions checking the actual part/datasheet — Notes that the fix/confirmation includes verifying the part number and pinout against its datasheet rather than assuming.

   Where answers go wrong: Assuming it's a wiring error (D and clock swapped) without first checking whether the timing pattern matches level-sensitivity vs edge-sensitivity. · Not proposing a concrete experiment, just restating the symptom. · Confusing this with a metastability issue, which is unrelated to this symptom.

6. 6A synchronous design has a flip-flop with clock-to-Q delay of 0.5 ns feeding a combinational block with worst-case propagation delay of 3.2 ns, which then feeds the data input of a second flip-flop with a setup time requirement of 0.4 ns. Board-level clock skew between the two flip-flops adds 0.3 ns of pessimism to the timing path. Ignoring hold time for this question, what is the maximum clock frequency this path can support?medium

   This is the core timing-closure calculation every digital logic intern should be able to do without a tool, since it underlies why 'it works on the bench but not at full speed' failures happen.

   Answer this one, graded

   Or just show what a strong answer covers

   For a setup check, the clock period has to be long enough for data launched by the first flip-flop to propagate through clock-to-Q delay, then through the combinational logic, and still meet the second flip-flop's setup time before the next active clock edge -- with clock skew added as pessimism since it eats into that margin. So T_min = tCO + tPD + tsu + tskew = 0.5 + 3.2 + 0.4 + 0.3 = 4.4 ns. Max frequency is just the inverse of that: 1 / 4.4ns ≈ 227 MHz. So this path caps the whole design's speed at about 227 MHz unless the combinational delay or skew is reduced.

   • Uses the correct setup timing formula — Sets up T_min = tCO + tPD + tsu + tskew (0.5+3.2+0.4+0.3) rather than omitting a term or using the wrong sign for skew.
   • Computes the correct minimum period — Arrives at T_min = 4.4 ns.
   • Correctly inverts to get frequency — States f_max = 1/4.4ns ≈ 227 MHz, showing the inversion step explicitly.

   Where answers go wrong: Forgetting to include clock skew in the budget. · Subtracting skew instead of adding it (using the wrong-direction skew assumption for a setup check). · Confusing setup analysis with hold analysis and mixing up which delays matter.

7. 7You have a free-running counter in clock domain A whose value is read directly (all bits, no synchronizer) by logic in clock domain B, which runs at an unrelated, asynchronous frequency. Occasionally, domain B reads a counter value that never actually existed in domain A -- not just a value that's one count behind, but a value that's numerically nonsensical given the counter's sequence. Explain what's happening and how you'd fix it.medium

   Multi-bit clock domain crossing failures are one of the most common real bugs interns encounter once they move past single-bit synchronizer theory.

   Answer this one, graded

   Or just show what a strong answer covers

   The root problem is that domain B is sampling an asynchronous signal with no synchronizer at all, so any bit caught changing near the sampling clock edge can resolve metastably to an unpredictable value. But the reason it looks like a 'nonsensical' value rather than just a slightly stale one is bit skew: when the counter increments across a boundary where multiple bits change simultaneously, like 0111 to 1000, domain B might capture some of those bits before the transition and others after, producing a composite value that was never actually a valid state in the counter's sequence. Simply adding a two-flop synchronizer to each bit independently doesn't fix this, because each bit is still synchronized independently and can still land on either side of the transition relative to its neighbors. The real fix is to either Gray-code the counter so only one bit ever changes between adjacent values, eliminating the multi-bit skew hazard, and then synchronize that single-bit-changing signal properly, or to avoid transferring the raw multi-bit value at all and instead use a handshake protocol or asynchronous FIFO that guarantees the full word is stable before it's used in the other domain.

   • Identifies missing synchronization as the root issue — States that reading an asynchronous multi-bit signal directly, without any synchronizer, risks metastability on any bit sampled near its transition.
   • Explains why the failure is 'nonsensical value', not just a stale read — Explains that different bits can resolve on different sides of the transition boundary (bit skew), producing composite values that never existed in the actual counter sequence, which is worse than simply reading an old value.
   • Proposes an appropriate multi-bit-safe fix — Recommends Gray coding the counter (so adjacent values differ by one bit) combined with per-bit synchronizers, or a handshake/FIFO-based transfer, rather than just adding more flip-flops per bit.

   Where answers go wrong: Treating this purely as a single-bit metastability problem and proposing only a two-flop synchronizer per bit without addressing bit skew. · Assuming the read will just be 'one cycle late' rather than potentially any invalid intermediate value. · Suggesting to slow down clock domain A to 'fix' the crossing instead of properly synchronizing.

8. 8A static timing analysis report on a small synchronous design shows a hold violation of 0.15 ns on a path between two flip-flops that share the same clock net -- setup timing on every path looks comfortable with plenty of margin. Explain what a hold violation actually means physically for this path, why raising or lowering the clock frequency won't fix it, and one concrete way you'd fix it.medium

   Both flip-flops are clocked from the same source with negligible skew reported between them; the combinational logic between them is very short (close to zero delay).

   Answer this one, graded

   Or just show what a strong answer covers

   A hold violation means the data at the second flip-flop's D input is changing too soon after the clock edge that just captured the previous value -- the flop needs the input to stay stable for some minimum time after the edge to reliably latch it, and here that requirement isn't met. This is a fast-path problem, not a slow-path problem: it happens because the combinational logic between the two flops is nearly zero delay and both flops share essentially the same clock edge, so the new data from the first flop arrives at the second flop almost immediately, potentially before the second flop has finished sampling the prior value. Changing frequency doesn't help because hold time depends only on the relationship between the clock edge and the fastest path delay, not on the clock period -- you could run this at 1 Hz and still violate hold. The fix is to add deliberate delay, usually in the form of buffer cells, into that short path so the new data doesn't arrive at the second flop until safely after the hold window closes. I'd also double check the skew assumption, since hold margin is tightest when skew works against you.

   • Correctly explains hold violation physically — States that data changes too soon after the capturing clock edge, meaning the flop can't reliably hold the correct value it just captured -- the new data can race in before the sample is stable.
   • Explains why clock frequency is irrelevant to hold — Explicitly states hold violations depend on minimum path delay and clock edge timing/skew, not the clock period, so changing frequency does not resolve it.
   • Proposes a valid concrete fix — Suggests adding delay (buffers) to the short path between the two flops so data arrives later relative to the capturing edge.
   • Connects it to the near-zero combinational delay in this specific scenario — Notes that a very short/fast path with matched clocks is exactly the situation where hold violations occur, since setup is about the slowest path and hold is about the fastest path.

   Where answers go wrong: Suggesting you fix a hold violation by lowering the clock frequency, which is a classic confusion between setup and hold. · Describing hold violation using setup violation language (e.g., 'data arrives too late'). · Not mentioning that hold violations are fundamentally about the fast path, in contrast to setup being about the slow path.

9. 9A design already uses a standard two-flip-flop synchronizer to bring a single-bit asynchronous status signal into a fast clock domain, and it has passed validation at room temperature for weeks. Once units ship and get tested in a thermal chamber at temperature extremes (both hot and cold), a small fraction of units occasionally latch the wrong value of that status signal, causing a downstream state machine to glitch. The synchronizer flip-flops themselves were never touched or modified. Walk through how you'd reason about what's changing with temperature, and what you would actually go measure to confirm your theory.hard

   This tests whether a candidate understands metastability as a probabilistic, physically-grounded phenomenon (MTBF, resolution time) rather than a binary 'synchronizer present or absent' checkbox, and can connect environmental stress to that probability.

   Answer this one, graded

   Or just show what a strong answer covers

   A two-flop synchronizer never eliminates metastability outright, it just reduces the probability that a metastable event escapes the synchronizer within one clock period, characterized by an MTBF that depends on the flip-flop's internal resolution time constant, the clock frequency, and how often the async signal transitions. What likely changed with temperature is that margin: flip-flop metastability resolution time and effective setup/hold times generally get worse at temperature extremes (and often at voltage corners too), which shrinks the time available for the potentially metastable state to resolve before the second flip-flop samples it, lowering the effective MTBF and raising the observed failure rate -- consistent with only seeing failures at the hot and cold extremes, not room temperature. Rather than assuming a design bug elsewhere, I'd pull the flip-flop's datasheet or characterization data for resolution time constant / MTBF versus temperature and voltage, and separately correlate the observed failure rate in the chamber against temperature and against the toggle rate of the async signal, since MTBF theory predicts failure rate should scale with both. If that correlation holds, the fix is either to accept the now-lower MTBF if it's still acceptable for the product's lifetime, add a third synchronizer stage or slow the sampling clock to buy back margin, or select a flip-flop with better metastability characteristics for the operating temperature range.

   • Recognizes the synchronizer as probabilistic rather than a fixed guarantee — States that a two-flop synchronizer only reduces failure probability (per MTBF), it doesn't make metastability impossible, so a nonzero failure rate is expected and can shift with conditions.
   • Connects temperature to resolution time / setup-hold degradation — Explains that at temperature (and voltage) extremes, flip-flop metastability resolution time constant and effective setup/hold margins typically worsen, reducing the safety margin within a clock period and lowering MTBF, which explains more frequent failures at extremes.
   • Proposes concrete measurements/checks to confirm the theory — Suggests checking the flip-flop's characterized MTBF/tau vs. temperature from the datasheet, correlating observed failure rate with temperature and clock frequency/data toggle rate, and considering adding a third synchronizer stage or a slower/more robust flip-flop if margin is confirmed insufficient.

   Where answers go wrong: Assuming the synchronizer 'should' make failures impossible and looking for an unrelated design bug instead. · Ignoring temperature's effect on internal flip-flop timing and only looking at board-level issues like connector or trace problems. · Proposing a fix (like adding a third flip-flop) without first confirming metastability/MTBF is actually the mechanism via measurement.

10. 10A design passes a 4-bit binary counter value from clock domain A to clock domain B by giving each of the 4 bits its own independent 2-flop synchronizer in domain B. On the bench, you occasionally see domain B briefly read counter values that never actually occurred in domain A -- for example, seeing a 4 followed by an 11 when the counter was slowly incrementing by 1 each time. Explain why per-bit synchronization isn't sufficient here even though each individual bit is properly synchronized, and describe a technique that would fix it.hard

    Each bit's 2-flop synchronizer is correctly designed and, in isolation, resolves metastability for that bit reliably.

    Answer this one, graded

    Or just show what a strong answer covers

    The problem is that each 2-flop synchronizer only guarantees that its own bit resolves cleanly to a valid logic level -- it says nothing about whether all four bits get sampled together relative to when they actually changed in domain A. When the counter goes from binary 0011 to 0100, three bits change at once. If domain B's sampling edge lands in the middle of that transition, some bits might already reflect the new value while others still reflect the old one, and each synchronizer will happily resolve to a stable but inconsistent combination -- that's exactly how you'd see something like an 11 appear that never existed in domain A. Each synchronizer being individually correct doesn't fix the fact that bits aren't guaranteed to change in lockstep from domain B's perspective. The standard fix for a counter specifically is to make it Gray-coded before crossing domains, since Gray code guarantees only a single bit toggles between any two consecutive values -- so no matter when domain B samples relative to the transition, it reads either the fully-old or fully-new value, never a hybrid. This only works because it's a counter with sequential increments; for arbitrary multi-bit data you'd instead need a handshake protocol or an asynchronous FIFO to guarantee the whole word is stable before it's read.

    • Identifies the multi-bit sampling skew issue — Explains that independently synchronized bits can be captured at slightly different effective times relative to the source change, so a transition where multiple bits change (e.g., binary 3 to 4) can be sampled as a nonexistent intermediate combination.
    • Explains why each synchronizer being individually correct isn't enough — Clarifies that resolving metastability per bit does not guarantee all bits are captured consistently relative to one another across the bus.
    • Proposes Gray coding as a fix — States that using a Gray-coded counter (only one bit changes per increment) guarantees any sampled value is either the pre- or post-transition value, never a mix.
    • Recognizes generalization/limits — Notes that Gray coding works for counters specifically, and arbitrary multi-bit data would need a handshake or FIFO-based crossing instead.

    Where answers go wrong: Assuming that because each bit's synchronizer resolves metastability, the whole bus transfer is automatically safe. · Proposing to just add more synchronizer stages per bit, which doesn't address inter-bit skew at all. · Not connecting the specific example (4 to 11, i.e., binary 0100 to 1011) to which bits actually change and why that's the worst case.