These open most timing interviews. The interviewer is calibrating whether you reason from the circuit or recite definitions.
Field | Answer |
|---|---|
Interviewer is testing | whether you know what STA covers (every path) and what it cannot see (function). |
Bad answer | "It is faster than simulation." |
Better answer | "STA checks every path against setup and hold limits without test vectors. Simulation only checks the paths the vectors exercise." |
Strong answer (a 4) | Adds the assumption (constraints are correct and complete), the mechanism (arrival and required times propagated through the timing graph, linear in design size), the trade-off (pessimistic by design, and blind to function and to false paths nobody declared) and the evidence (constraint coverage report plus equivalence and simulation for function). |
Follow-ups | What does STA not check? Why is it pessimistic? |
Common trap | Saying STA replaces simulation. They check different things. |
Evidence to cite | Coverage report (no unclocked registers), path reports. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you tie the definitions to edges and to delay extremes. |
Bad answer | "Setup is how long data must be stable before the clock, hold is after." (and nothing more) |
Better answer | "Setup: data must arrive before the capture edge less the setup time, worst when paths are slowest. Hold: data must not change before the capture edge plus the hold time, worst when paths are fastest." |
Strong answer (a 4) | Adds the formulas (setup slack = capture edge + capture latency - setup - arrival; hold slack = min arrival - capture latency - hold), the corners (setup at slow, hold at fast, with temperature inversion at low voltage as an exception), the fix asymmetry (setup is fixed by speed, hold by delay, and delay costs setup) and the evidence (per-scenario reports). |
Follow-ups | Can a path fail both? What changes with skew? |
Common trap | Saying hold depends on the clock period. It does not for a same-edge pair. |
Evidence to cite | Setup and hold slack per scenario. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know slack exists at every node, not only endpoints. |
Bad answer | "It is how much the path fails or passes by." |
Better answer | "Required time minus arrival time, at a node. At an endpoint it is the setup margin." |
Strong answer (a 4) | States that slack is defined at every node through arrival times propagated forward and required times backward, that every node on one critical path has the same slack, and that this is why a fix anywhere on a shared segment helps every path through it. Gives a number: required 1.54 ns, arrival 1.25 ns, slack 0.29 ns. |
Follow-ups | Why do nodes on one path share a slack? What is TNS? |
Common trap | Defining slack only at flop pins. |
Evidence to cite | A path report with arrival and required times. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you can reason about the capture clock moving. |
Bad answer | "Skew is bad for timing." |
Better answer | "A later capture clock gives data more time to arrive, which helps setup, but it also moves the hold window later, which hurts hold." |
Strong answer (a 4) | Gives the numbers (a capture clock 0.05 ns later adds 0.05 ns to setup slack and removes 0.05 ns from hold slack), notes that the effect reverses for the next stage (it launches later), and names useful skew as the deliberate use, with its hold cost and the window of feasible values. |
Follow-ups | What is useful skew? What does uncertainty do? |
Common trap | Saying skew only matters at the capture flop. The launch flop's latency matters too. |
Evidence to cite | Launch and capture clock latencies from the path report. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you understand why the credit exists. |
Bad answer | "It is optional margin recovery." |
Better answer | "Launch and capture clocks share part of their path; derating that shared part as both late and early is impossible, so the difference is credited back." |
Strong answer (a 4) | Computes it: a shared segment of 0.30 ns with late 1.08 and early 0.92 gives 0.30 × 0.16 = 0.048 ns. Adds that the credit exists because one buffer cannot be both slow and fast at once, that it depends on the branch point (a longer shared trunk gives more credit), and that it is part of the variation analysis, not an optimisation. |
Follow-ups | Does it apply to hold? How does clock tree design affect it? |
Common trap | Treating it as optional margin recovery rather than correcting double counting. |
Evidence to cite | CRPR credit per path in the report. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you determine the capture edge from the clock senses. |
Bad answer | "A path between a flop and a latch." |
Better answer | "A path from a rising-edge flop to a falling-edge flop: the capture edge is half a period after launch." |
Strong answer (a 4) | Computes: period 1.0 ns gives 0.5 ns minus setup; a 0.42 ns path with 0.05 ns setup has +0.03 ns. Notes that an inverted clock modelled as non-inverted turns a half-cycle into a full-cycle and makes slack optimistic by T/2, and says how to check (capture edge in the path report). |
Follow-ups | What if the clock gating uses an inverted clock? How does a latch change it? |
Common trap | Assuming every path gets a full period. |
Evidence to cite | The capture edge printed in the path report, compared with the schematic. |
Taught in |
Q2, Q3 and Q6 test derivation (formulas and edges); Q1, Q4 and Q5 test judgement (what STA cannot see, what skew costs, why the credit exists).