Crosstalk and ECO questions test whether you understand directions and trade-offs: which way an aggressor moves, what a fix costs, and what each fix does to the other check.
Field | Answer |
|---|---|
Interviewer is testing | whether you know the three aggressor cases. |
Bad answer | "Neighbouring wires slow each other down." |
Better answer | "A switching neighbour changes the effective capacitance: opposite-direction switching slows the victim, same-direction speeds it up, a quiet neighbour is the reference." |
Strong answer (a 4) | Gives the first-order model (effective capacitance equals ground plus k times coupling, with k near 0, 1 and 2), a number (8 fF ground, 6 fF coupling and a 2 kΩ driver give 11.0, 19.3 and 27.6 ps), and says setup uses the slowdown on data and the speedup on the capture clock while hold uses the reverse. |
Follow-ups | Why is hold affected? Do clock nets count? |
Common trap | Thinking crosstalk only affects setup. |
Evidence to cite | SI-enabled setup and hold reports in all scenarios. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know how pessimism is reduced. |
Bad answer | "They tell the tool when signals switch." |
Better answer | "A net's window is the earliest and latest time it can switch; an aggressor only counts if its window overlaps the victim's." |
Strong answer (a 4) | Shows an example (four aggressors worth 18 ps in total; two overlap the victim's 1.00 to 1.30 ns window, so 9 ps is counted), says windows are conservative, move with every ECO and so must be recomputed, and that asynchronous aggressors have no window relationship and are assumed to overlap. |
Follow-ups | What if an ECO shifts an arrival time? |
Common trap | Fixing a victim by moving an aggressor's window without checking other victims. |
Evidence to cite | Overlap flags in the SI report. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you separate the two effects and rank risk. |
Bad answer | "Noise is the same as crosstalk delay." |
Better answer | "Delta delay is on switching nets; a glitch is a pulse on a quiet net that can be read as a transition. Clock, reset and latch-enable receivers matter most." |
Strong answer (a 4) | Gives the glitch model (divider bound 0.343 V on 0.8 V, lower with a strong victim driver or slow aggressor), the receiver's tolerance as a curve of height against width, and a stricter policy for critical receivers: any violation fixed, with a margin, and no open critical items at signoff. |
Follow-ups | How can you reduce a glitch cheaply? |
Common trap | Judging a glitch by height alone. |
Evidence to cite | Noise summary by receiver class. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know the interaction. |
Bad answer | "Hold first, because it cannot be fixed by frequency." |
Better answer | "Setup speed-ups erode hold, so I fix setup first and then hold with delay within the remaining setup slack, then rerun everything." |
Strong answer (a 4) | Adds the screen done first: setup-plus-hold slack per endpoint, since delay insertion trades the two one for one; endpoints with a negative sum need structural fixes and drive the schedule; and the closure model: each round fixes a fraction and breaks a few, so the stall level is breakage times near-critical endpoints over the fix rate. |
Follow-ups | What if hold must be fixed in the fast corner but setup is tight in the slow one? |
Common trap | Fixing hold everywhere before setup is stable. |
Evidence to cite | Before-and-after endpoint table over the full matrix. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you know the setup-plus-hold invariant. |
Bad answer | "You just add more buffers." |
Better answer | "Delay added at an endpoint costs setup slack by the same amount, so it only works if the setup slack covers it." |
Strong answer (a 4) | Gives a case: hold -0.025 and setup +0.010 sum to -0.015, below the 0.010 needed for a 5 ps margin on each, so no delay at the endpoint fixes both; structural options are to reduce the spread between longest and shortest paths, restructure the logic, or add a per-path delay on the short branch before the merge point. |
Follow-ups | How would you find all such endpoints? |
Common trap | Inserting delay and discovering new setup violations later. |
Evidence to cite | The sum screen over all hold endpoints. |
Taught in |
Field | Answer |
|---|---|
Interviewer is testing | whether you treat it as a budget with a window. |
Bad answer | "Delaying a clock to fix setup, and it costs nothing elsewhere." |
Better answer | "Delaying a flop's clock moves slack from the stage after it to the stage before it, and costs hold on the input stage." |
Strong answer (a 4) | Writes the four inequalities and the window for one example (stage 1 setup -0.050 and hold +0.080, stage 2 setup +0.100 and hold +0.030 give a window of 55 to 75 ps with a 5 ps margin). As a different example, skew built from cells is quantised and varies: in the Clock Tree Side Effects lesson (stage 1 setup -0.040, hold +0.100) 3 buffers worked for both checks and 2 did not. Says useful skew must be signed off per corner because delivered skew scales with the corner. |
Follow-ups | What if the total slack around a pipeline is negative? |
Common trap | Quoting the nominal skew as the gain and ignoring cell variation. |
Evidence to cite | Window per flop per corner and the downstream stage's slack. |
Taught in |
Q4 and Q5: delay insertion at an endpoint trades setup for hold one for one, which sets both the order of fixes and the limit on what insertion can do.