These questions separate people who have closed timing from those who have read about it. Strong answers give numbers and name what each approach cannot see.
Field | Answer |
|---|---|
Interviewer is testing | whether you know what each dimension varies. |
Bad answer | "One worst-case corner is enough because the chip runs in one condition." |
Better answer | "Delay varies with process, voltage and temperature, and modes change clocks and constraints. Setup is worst at the slowest conditions and hold at the fastest, so no single corner covers both." |
Strong answer (a 4) | Counts the matrix (4 modes × 5 conditions × 4 interconnect corners = 80 scenarios), explains the selection (a starting plan of 32: slow conditions with the worst interconnect for setup, fast with the best for hold) and the guideline status of that plan, and describes how scenarios are added from evidence. |
Follow-ups | How do you prune? When would you add a scenario? |
Common trap | Saying one worst-case corner is enough. |
Evidence to cite | Matrix document with reasons for each scenario. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know that slow does not always mean hot. |
Bad answer | "Hot is always slower." |
Better answer | "In many modern technologies, at low supply voltage delay is larger when cold, so the slowest corner can be the cold one." |
Strong answer (a 4) | Gives the consequences: at low voltage setup needs a cold scenario and hold a hot one, at high voltage the old rule holds; an example (0.80 ns path with 0.044 ns of setup slack cold against 0.140 ns hot at 0.72 V in illustrative data); and says the evidence is the library data at each voltage, not a rule. |
Follow-ups | How does this change a low-power mode? Which check is affected? |
Common trap | Copying the corner list of one voltage domain to another. |
Evidence to cite | Library delay versus temperature at each voltage. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know what each assumes about variation. |
Bad answer | "They are different derate methods; POCV is the newest." |
Better answer | "Flat OCV applies one derate. AOCV derates by logic depth because random variation averages out. POCV carries a sigma per cell and combines them statistically." |
Strong answer (a 4) | Compares on the same paths: with a 1.15 flat derate two of three example paths fail; depth-based passes all three; statistical fails only the path with two noisy cells, which the depth table cannot see. States what each misses (flat ignores averaging, depth-based ignores cell identity, statistical assumes independence) and says the choice is made from data and policy, not from the violation count. |
Follow-ups | Where do the derates come from? What about clock paths? |
Common trap | Switching method to remove violations. |
Evidence to cite | A comparison on real paths and the derate audit. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you reason from evidence and state a tolerance. |
Bad answer | "I drop the ones that never fail." |
Better answer | "I drop scenarios that are never the worst at any endpoint, with a stated tolerance, and keep at least one per voltage domain and mode." |
Strong answer (a 4) | Shows the effect of tolerance on a small example: with zero tolerance three of four scenarios are needed, with 0.025 ns one is enough at the cost of up to 0.02 ns of optimism; says final signoff runs the full list or an evidenced equivalent, and that ownership data is refreshed after large changes. |
Follow-ups | What is a dominated scenario? Who approves the tolerance? |
Common trap | Dropping a scenario only because it never fails is wrong: a scenario can own endpoints without failing, so prune on ownership with a tolerance, not on failure count; and never prune on one iteration of the design. |
Evidence to cite | Ownership table and the tolerance used. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you treat margins as owned decisions. |
Bad answer | "Add some margin to be safe." |
Better answer | "Each margin has an owner and evidence, and the total is reviewed." |
Strong answer (a 4) | Describes the ledger (OCV 0.18 ns, uncertainty 0.05, IR drop 0.03, legacy 0.04 gives 0.30 ns, of which 0.04 is unowned), the cost of excess (raising the derate from 1.05 to 1.10 flips three more of ten endpoints in an example) and the habit of normalising trends to a baseline margin so that margin edits are not mistaken for progress. |
Follow-ups | Who approves a change? How do you remove margin? |
Common trap | Letting block owners add local margins to close their own block. |
Evidence to cite | Margin ledger and a sensitivity run. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you can measure and manage a correlation gap. |
Bad answer | "The tools are different." |
Better answer | "They use different views, parasitics and delay calculators; I measure the gap and add a margin in implementation." |
Strong answer (a 4) | Defines escapes (pass in implementation, fail in signoff), shows the margin trade-off on a sample (margin 0 leaves two escapes, 0.08 ns leaves none and over-fixes one), decomposes a gap into cell, net and clock components to find the cause, and starts any investigation by diffing the inputs of the two flows. |
Follow-ups | How would you choose the margin on thousands of endpoints? What if the gap is not uniform? |
Common trap | Carrying a margin forever without revalidating it. |
Evidence to cite | Per-endpoint comparison table. |
Taught in |
Q2: 'slow means hot' is the rule that temperature inversion breaks.