Top 10 Real World Logic Design Interview Questions with Model Answers

The hardest logic design interview questions are not about definitions. They describe a failure on a real chip, such as a FIFO that fails at speed, a register that flips on its own or a reset that will not release cleanly, and ask you to reason from symptom to cause to fix. Below are ten such questions, each with a model answer, the points a strong candidate covers and the follow-ups interviewers tend to ask.

Anyone who has sat a semiconductor interview knows there are two kinds of question. Theory questions ("What is setup and hold time?") and real design questions ("Why did your async FIFO fail in silicon when it passed simulation?").

The first kind tests memory. The second tests experience: the problems you have debugged late at night, two weeks before tape-out. That is usually what separates strong candidates from great ones.

In logic design and VLSI interviews today, hiring managers want more than engineers who can write RTL or run STA. They want people who can:

• spot CDC problems before they turn into field failures;
• balance power, performance and timing under hard deadlines;
• cope with scan, ECOs, resets and silicon bring-up.

That is why interviewers increasingly ask scenario questions that no textbook or quick search fully prepares you for. Here are ten of the hardest, the kind senior engineers and chip leads meet on real projects. Each one is a debugging story in disguise.

Key takeaways

• Answer in the order symptom, likely causes ranked, how you would prove which one, then the fix. Interviewers score the method more than the final answer.
• Most of these questions come back to four themes: clock domain crossings, timing exceptions, power intent and reset design.
• Simulation passing is never proof. Know what each tool cannot see: RTL simulation does not model power, metastability or physical delays.
• Say what you would check in the constraints, not only in the RTL. Many silicon failures are wrong exceptions, not wrong logic.
• Quote numbers when you can (MTBF, jitter, slack). It shows you have done it rather than read about it.

How to answer a scenario question

Step	What to say	Why it scores
1. Restate the symptom	When it fails, how often, does it depend on voltage, temperature or frequency	Shows you collect data before guessing
2. Rank causes	Two or three candidates, most likely first	Shows judgement, not a list from memory
3. Prove it	A test, a tool report or an experiment that separates the causes	This is the part juniors skip
4. Fix and prevent	The local fix, then the check or rule that stops it recurring	Shows you think about the next project

The ten questions with model answers

1. Fractional divider for telecom frequencies

You need a 622.08 MHz clock from a 1 GHz reference using only digital logic, with no PLL. How do you design the divider so jitter stays bounded and the duty cycle stays reasonable? (Hints for this one are in this post on fractional dividers.)

Model answer. Start with the ratio: 1000 / 622.08 = 3125 / 1944, about 1.6075. A divider can only produce output periods that are whole numbers of input periods (or half periods if you use both edges), so the output must mix periods of 1 ns and 2 ns. To average 1.6075 ns, 1181 of every 1944 output cycles are 2 ns long and 763 are 1 ns long (763 + 2 x 1181 = 3125 input cycles). An accumulator, the same idea as a fractional-N or flying-adder synthesiser, decides each cycle which period to use, so the average frequency is exact.

The catch is jitter. Period jitter is a full input period, 1 ns, against an average period of about 1.61 ns. Using both edges of the reference halves the step to 0.5 ns and also lets you build a usable duty cycle, but that is still far too much for a 622.08 MHz telecom clock (the SONET OC-12 / SDH STM-4 line rate), whose jitter limits are set by ITU-T and Telcordia specifications. A strong answer says so plainly, then offers the realistic options: sigma-delta control of the period choice to push jitter to high frequencies where a downstream cleaner can filter it, a multi-phase reference (for example from a DLL) with phase selection to get steps far finer than 1 ns, or accepting that a jitter-cleaning PLL is needed after all.

Follow-ups. What is the worst-case phase error of the accumulator? How do you switch between phases without a glitch? How would you measure the jitter?

2. Gated clocks and scan mode

Your RTL uses integrated clock-gating (ICG) cells to save power. After scan insertion, vectors fail on silicon because of clock skew. How would you change the RTL or the constraints to avoid the conflict?

Model answer. Two separate issues are usually tangled here. First, controllability: every ICG must have its test-enable pin driven by scan enable or test mode, so the clock reaches every scan flop during shift. RTL-coded gating with plain AND gates should be replaced with library ICG cells, which contain the latch that keeps the enable glitch-free. Second, skew: the ICG adds insertion delay, and if clock tree synthesis does not balance through it, flops behind the ICG see a later clock than their neighbours. In shift mode that becomes a hold failure between adjacent scan flops.

Fixes: make sure CTS treats ICGs as balance-through points and does not stop at them; add lock-up latches where the scan chain crosses between clock groups or domains with significant skew; order scan chains by clock group; and run STA in shift and capture modes with the right case analysis on test mode, not only in functional mode. For at-speed capture, an on-chip clock controller (OCC) should provide the pulses so the ICGs behave as they will in function.

Follow-ups. Why does the ICG use a latch rather than a flop? What does a lock-up latch do, and on which clock phase is it transparent?

3. CDC failure at speed

A FIFO between two asynchronous domains passes simulation but fails at speed on silicon. How do you find the root cause? Would you suspect metastability, Gray-code errors or a false-path setting in STA?

Model answer. All three are candidates, and a good answer explains how they connect. RTL simulation cannot show metastability or the real skew between pointer bits, so passing it proves little. Check, in order:

• Pointer structure. The Gray pointer must come straight from a flop in the source domain. If there is any logic between that flop and the synchroniser, glitches can be captured. A binary pointer must never cross directly.
• Constraints. If the pointer bus was given set_false_path, the tools are free to route its bits with very different delays. If the skew between bits exceeds one destination clock period, the receiver can see two bits change, and the single-bit-change property of Gray code is lost. The usual fix is a set_max_delay -datapath_only (or a bus skew constraint) of about one destination period instead of a blanket false path.
• Synchroniser depth. At the silicon frequency, two flops may not give enough MTBF. The usual model is MTBF = e^(tr/tau) / (T0 x fclk x fdata), where tr is the resolution time available, and tau and T0 are flop parameters from the library or foundry.
• Full and empty logic and reset. Both sides must reset the pointers together, and the full and empty comparisons must use the synchronised pointer from the other domain.

To prove which one it is, run a structural CDC tool on the netlist, review the exceptions file, and shmoo the part: failures that worsen at high frequency or low voltage point to timing or metastability; failures that appear at a specific clock ratio point to logic.

Follow-ups. Why does Gray code only work for pointers that change by one? How does the FIFO depth need to change for non-power-of-two sizes?

4. A "phantom toggle" after silicon

During post-silicon validation, a configuration register that should be static occasionally changes value. The RTL has no bug. Which physical design or clocking issues could cause it?

Model answer. List physical causes and how to tell them apart:

Cause	Signature	How to confirm
Glitch on the write enable or clock (crosstalk, a combinationally gated clock)	Correlates with nearby switching activity	Signal integrity report on the enable and clock nets; repeat with neighbouring traffic stopped
Hold violation on the register input under on-chip variation	Worse at low temperature or high voltage (fast corner)	Re-run STA with tighter OCV derates; shmoo voltage and temperature
IR drop or ground bounce	Correlates with high current events	Dynamic IR drop analysis on that region; on-die voltage monitors if present
Reset glitch	Register returns to its reset value, not a random one	Check reset tree for combinational decode (see question 9)
Soft error (single event upset)	Random, rare, any bit, not repeatable	Rate vs altitude or a beam test; parity on the register catches it
Write from another clock domain without synchronisation	Bus writes that coincide with clock edges	CDC check on the register file's write path

The value it changes to is a strong clue. A return to the reset value points at reset; a single flipped bit points at a soft error or a glitch; a plausible written value points at a stray write. For safety-relevant configuration, add parity or ECC and periodic read-back.

5. Retiming gone wrong

Synthesis retiming moves registers across logic to fix setup, but after clock tree synthesis hold violations jump sharply. How would you constrain the tools or structure the RTL to avoid this?

Model answer. Retiming balances logic by moving flops, which often leaves some paths very short, sometimes flop to flop with nothing between them. Before CTS, ideal clocks hide the problem; after CTS, real skew turns those short paths into hold violations, and the hold-fix buffers then cost area and power and can damage setup on other paths.

Controls: limit retiming to the pipeline stages that need it and mark interface, CDC, reset and scan-critical flops as do-not-retime; give the synthesis tool a realistic clock uncertainty and hold margin so it does not create near-zero paths; where possible, write the pipeline in RTL with the logic split by hand so retiming has less to do. Also remember the knock-on effects: retimed flops change names and reset behaviour, so formal equivalence checking needs retiming support switched on, and ECO and debug scripts that refer to register names may break.

6. Multi-voltage isolation bug

Your block talks to a domain that can power down. In power-aware simulation the signals go to X when that domain is off, but in plain RTL simulation they do not. How do you design and code the isolation correctly?

Model answer. Plain RTL simulation has no idea that the domain can power off, so it never produces X. Power-aware simulation, driven by UPF (IEEE 1801), corrupts the outputs of the off domain, which is exactly the behaviour you need to see. The X reaching your block means either there is no isolation on those signals or it is enabled at the wrong time.

• Describe isolation in UPF: an isolation strategy on the outputs of the switchable domain, a clamp value chosen so the receiver is safe (for example, valid and request clamp to 0), a location (usually the always-on side) and the isolation enable signal.
• Get the sequence right. Power down: stop traffic, assert isolation, save state if retention is used, then remove power. Power up: restore power, wait for it to be stable, restore state, release reset, then release isolation.
• Do not hand-code isolation cells in RTL unless the UPF describes them too, or the tools will insert a second set or flag a mismatch.
• Run static power-intent checks on the netlist and power-aware simulation on the sequences, including the corner where traffic arrives during the transition.

7. A false path that is not false

A path was set as false in STA, but silicon shows intermittent timing failures. Which design situations make a false-path assumption invalid, and how do you avoid both under- and over-constraining?

Model answer. Common ways a false path turns out to be real:

• A "static" configuration register that software actually changes while the logic is running.
• Mux paths assumed mutually exclusive that are both active in some mode, such as test or a debug configuration.
• A CDC bus where a false path removed the skew limit the design depends on (see question 3).
• A wildcard -through or -from that matches far more paths than intended, often after a rename.

To avoid it: prefer the narrowest exception that is true. Use set_multicycle_path when the path is slow by design, set_max_delay when only a bound is needed, and set_false_path only when there is truly no timing relationship. Review the number of paths each exception covers after every netlist change, and check exceptions with assertions in simulation or a formal timing-exception tool. Over-constraining wastes area and power; under-constraining fails on silicon, so the goal is exceptions that are exactly as wide as the design intent.

8. Handshake deadlock

You built a ready/valid handshake across two clock domains. In some corner cases it stalls for good. How do you debug it, and which RTL practices prevent handshake deadlocks?

Model answer. A ready/valid handshake is a same-clock protocol. Across asynchronous domains it needs either an asynchronous FIFO or a full request/acknowledge handshake in which each signal is synchronised and held until the other side responds. Typical stall causes:

• A pulse shorter than the destination clock period is lost in the synchroniser. Use level or toggle signalling instead of pulses.
• One side was reset while the other was not, so the two toggles disagree and each waits for the other.
• valid depends on ready. The AMBA AXI rule is that a source must not wait for ready before asserting valid; break any loop where each side waits for the other.
• A two-phase protocol mixed with a four-phase one between the two sides.

To debug: add assertions that valid, once raised, stays high until accepted and that every request gets an acknowledge within a bound, then use formal liveness checks to find the corner case. In silicon, a small debug register showing the req and ack state on both sides usually identifies the stuck state at once.

9. Glitch in a reset tree

During bring-up, a block does not come out of reset cleanly. The RTL decodes the reset with combinational logic. Why are resets so sensitive to glitches, and how should resets be designed in a chip with several clocks?

Model answer. An asynchronous reset acts on any pulse, at any time, with no clock to filter it. A glitch of a few hundred picoseconds from a combinational decode, for example two inputs that change at slightly different times, can reset some flops and not others. Release is the other hazard: if reset is removed close to a clock edge, flops can go metastable or leave reset on different cycles, so a state machine starts in an illegal state.

Good practice: drive every reset from a flop output, never from a combinational decode; use one reset synchroniser per clock domain that asserts asynchronously and releases synchronously; sequence the release of domains that depend on each other; and run recovery and removal checks in STA on every reset tree. A minimal synchroniser, checked by simulation:

// Reset synchroniser: asserts asynchronously, releases synchronously
module rst_sync (
  input  wire clk,
  input  wire arst_n,     // raw asynchronous reset, active low
  output wire rst_n       // safe reset for this clock domain
);
  reg [1:0] sync;
  always @(posedge clk or negedge arst_n)
    if (!arst_n) sync <= 2'b00;
    else         sync <= {sync[0], 1'b1};
  assign rst_n = sync[1];
endmodule

The same habit of registering before crossing applies to FIFO pointers in question 3. A Gray pointer generated from a flop in the source domain:

// Binary to Gray, registered in the source domain before crossing
module gray_ptr #(parameter W = 4) (
  input  wire         clk,
  input  wire         rst_n,
  input  wire         inc,
  output reg  [W-1:0] gray
);
  reg  [W-1:0] bin;
  wire [W-1:0] bin_next = bin + {{(W-1){1'b0}}, inc};
  always @(posedge clk or negedge rst_n)
    if (!rst_n) begin bin <= 0; gray <= 0; end
    else begin
      bin  <= bin_next;
      gray <= bin_next ^ (bin_next >> 1);   // one bit changes per step
    end
endmodule

10. ECO on a tight timing path

Two weeks before tape-out, an ECO needs new logic on a path that is close to critical. Which RTL or gate-level techniques let you add the function without breaking timing closure?

Model answer. Start by asking which input of the new logic arrives late. The main technique is to put the new gate on the early-arriving side, so the critical signal still passes through as few levels as before. For example, if a new condition must qualify an enable, combine it with the other early terms first and leave the late signal as the last gate before the flop.

Other tools in the box: use spare cells already in the layout for a metal-only ECO if the base layers are frozen; swap cells on the path to a faster threshold voltage (accepting more leakage) or upsize drivers; move the logic one cycle earlier or later if the protocol tolerates the latency; and use useful skew on the capture flop if hold margin allows. Make the change in RTL as well, generate the gate-level patch with an ECO tool, prove RTL against the patched netlist with formal equivalence, then re-run full STA, including hold and all modes, not only the path you touched.

How interviewers probe these answers

• "How would you prove it?" Expect this after every cause you list. Have a test or report ready for each.
• "What would you do differently next time?" They want a rule, a check or a lint rule, not "be more careful".
• "Draw it." Be ready to sketch a synchroniser, an ICG with its latch, an isolation cell and a reset synchroniser.
• "Give me a number." MTBF, jitter, slack, insertion delay. A rough, reasoned number beats none.

Common mistakes in answers

• Jumping to "add another synchroniser flop" for every CDC problem without checking structure and constraints.
• Treating set_false_path as a fix rather than a statement about the design that must be true.
• Forgetting test mode and power states when listing scenarios.
• Describing only the fix, not how you found the cause.

FAQ

Are these questions only for senior roles?

Mostly they are asked of engineers with a few years of experience and up, but graduates who can explain questions 3, 7 and 9 clearly stand out.

Do I need to write code in the interview?

Often a short piece: a synchroniser, a Gray counter or a small FSM. Keep it synthesizable, reset everything that needs it, and say which clock each signal belongs to.

What should I read to prepare?

Clifford Cummings' papers on clock domain crossing and asynchronous FIFO design (Sunburst Design, SNUG) are widely used, along with the IEEE 1801 (UPF) standard for power intent and your tool vendor's STA exception guides.