In a design review the interviewer proposes something and watches how you respond. Strong answers disagree politely, quantify, and offer an alternative.
Field | Answer |
|---|---|
Interviewer is testing | whether you test a plan against the matrix and the evidence. |
Bad answer | "Six should be fine if they are the worst ones." |
Better answer | "I would ask how the six were chosen and whether any scenario is missing a voltage or temperature extreme." |
Strong answer (a 4) | Asks for the ownership data (which scenarios own which endpoints), checks voltage domains and modes are each covered, checks temperature extremes at low voltage for inversion, accepts pruning with a stated tolerance and a full-matrix run before signoff, and records the optimism it accepts. |
Follow-ups | What if run time really is the limit? |
Common trap | Accepting a number of scenarios without asking what each covers. |
Evidence to cite | Matrix document, ownership table and tolerance. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know that crosstalk speedups hurt hold. |
Bad answer | "Hold is a fast-corner problem so SI does not matter." |
Better answer | "Crosstalk can speed up data and delay the capture clock, so hold with SI is worse than without it." |
Strong answer (a 4) | Quantifies it: in an example the same flop loses 13 ps of hold slack and 16 ps of setup slack to crosstalk, so hold slack of 30 ps becomes 17 ps; says clock nets must be in the analysis, offers to cut run time by pruning scenarios or filters with a documented hidden total instead of dropping SI, and says what evidence would change the answer. |
Follow-ups | How would you reduce the run time instead? |
Common trap | Treating hold as only a fast-corner, no-crosstalk check. |
Evidence to cite | Hold reports with and without SI on a sample. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you treat margins as owned decisions. |
Bad answer | "If it closes, it is fine." |
Better answer | "Margins should be approved and recorded; local margins are invisible in the total." |
Strong answer (a 4) | Asks for the ledger entry, owner and evidence; shows that unowned margin is the first to challenge (0.04 of 0.30 ns in the example); measures the cost with a sensitivity run on violations; and notes that a locally added margin is not removed later unless somebody owns it. |
Follow-ups | How do you take margin out safely? |
Common trap | Judging a margin by whether the block closes. |
Evidence to cite | Margin ledger and a sensitivity run. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you diagnose a stall rather than push harder. |
Bad answer | "Add more people and keep fixing." |
Better answer | "Check whether the fix rate has fallen and what the fixes break." |
Strong answer (a 4) | Computes the ratio of successive days and a floor (from differences of -6 then -3 from 109 violations the floor is near 106), uses the stall model (floor = breakage × near-critical endpoints / fix rate) to say reducing breakage helps more than speed, screens the remaining endpoints for a negative setup-plus-hold sum that needs structural fixes, and changes approach: structural fixes, a method change, or evidence-based waivers. |
Follow-ups | How do you verify a fix without rerunning everything? |
Common trap | Repeating the fix type that has stopped working. |
Evidence to cite | Daily ratio series, breakage per ECO, sum screen. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you build policy from data with governance. |
Bad answer | "Use the same derates as last time." |
Better answer | "Get variation data from the process, derive derates at a stated coverage and check them against silicon." |
Strong answer (a 4) | Derives derates as one plus k sigma over mean from measured variation (ten samples gave 1.07 and 0.93 in the illustration, with the caveat that real data need many dies), compares flat, depth-based and statistical methods on real paths, runs a derate audit on applied settings, records margins in a ledger with owners and approvals, and plans a revisit at process milestones. |
Follow-ups | What if the data are not ready at the start? |
Common trap | Copying a previous node's values. |
Evidence to cite | Derivation, method comparison and audit output. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you apply the gating model. |
Bad answer | "Add delay cells on all of them." |
Better answer | "The enable is changing while the clock is high; add delay or launch the enable from the falling edge." |
Strong answer (a 4) | States the AND gate rule (the enable must change while the clock is low; setup against the next rising edge, hold against the falling edge), notes that a falling-edge launch gives a half-cycle setup budget (0.30 ns against 2.30 ns in the example) and so must be checked for setup, prefers integrated gating cells that hold the enable through the high phase, and counts gates against checks to be sure none was missed. |
Follow-ups | What if the enable comes from an input port? |
Common trap | Fixing hold with delay and breaking the half-cycle setup. |
Evidence to cite | Gating checks per corner and the gate count. |
Taught in |
Both ask for the evidence behind a plan (ownership data, ledger entry) before accepting or rejecting it, and both record what is being accepted.