Interviewer is testing

whether you check coverage as well as violations.

Bad answer

"I would celebrate and move on."

Better answer

"I would check that all registers have a clock and all ports have constraints, and look at the exception list."

Strong answer (a 4)

Names the four ghosts: missing clock (600 of 6,600 registers unclocked is 9.1% of the design unchecked), wrong clock sense (half-cycle analysed as full), an overbroad false path (1,120 paths covered where 2 were expected), and a multicycle without hold; plus the heuristic that a constraint-only gain above a threshold needs review.

Follow-ups

How do you measure coverage?

Common trap

Reading WNS as proof of closure.

Evidence to cite

Coverage report, exception register with counts, semantic constraint diff.

Taught in

Missing Clock

Interviewer is testing

whether you localise before digging.

Bad answer

"I look at the worst path in both."

Better answer

"I check that the inputs match, then compare stage by stage."

Strong answer (a 4)

Describes staged comparison (netlist, constraints, libraries, parasitics, derates) with differences after each stage, finding that a 12 ps library difference and a 47 ps parasitic difference are two causes; classifies the shape of the differences first (uniform shift, localised, mixed); runs unit and corner-ordering sanity checks on library data.

Follow-ups

What if everything matches and results differ?

Common trap

Starting from the worst endpoint.

Evidence to cite

Staged comparison table and run manifests.

Taught in

Same Design, Different Numbers

Interviewer is testing

whether you avoid double counting.

Bad answer

"TNS counts every failing endpoint once per scenario."

Better answer

"Union TNS counts each endpoint once, at its worst slack across views; summing per-view TNS counts an endpoint once per failing view."

Strong answer (a 4)

Gives the example: three views, four endpoints; per-view TNS of -0.07 each sums to -0.21 with six violations, but the union is -0.15 with three. Says the union is the job size, the per-view rows show where to look, and that run comparisons should be on common endpoints.

Follow-ups

How does a changed endpoint set affect trends?

Common trap

Comparing totals between runs whose endpoint sets differ.

Evidence to cite

Per-view and union rows in the same table.

Taught in

Reporting by View

Interviewer is testing

whether you think of it as an evidence trail.

Bad answer

"The final reports."

Better answer

"Reports for all scenarios, constraints, and a list of waivers."

Strong answer (a 4)

Lists method and data versions, the margin ledger, results per scenario and union, the near-critical histogram, derate audit output, a comparison with the previous milestone on common endpoints, SI and noise signoff, and open items with owners; adds that completeness is checked before numbers, since a clean number from an unaudited setup proves nothing.

Follow-ups

What is a blocker, and what is a major?

Common trap

A package assembled from the latest run only.

Evidence to cite

Checklist with weights and evidence links.

Taught in

Signoff Package, Final Checklists

Interviewer is testing

whether you use the pattern of scenarios.

Bad answer

"I fix that path in that scenario."

Better answer

"I look at which attributes the failing scenarios share and which passing ones differ."

Strong answer (a 4)

Applies the attribute method: shared mode points to constraints, shared temperature at low voltage to inversion, one interconnect corner to extraction. Discriminates with a test: a slack loss proportional to path delay means a library or derate effect (check the derate audit and the library data); a constant offset means uncertainty or margin; fixes shared segments first and rechecks the neighbouring scenarios.

Follow-ups

How would you check the library claim?

Common trap

Starting from the endpoints before looking at the scenario table.

Evidence to cite

Scenario table by attribute and a per-endpoint comparison.

Taught in

Symptoms to Views

Interviewer is testing

whether you are careful about waivers and name the evidence.

Bad answer

"If it is small, or if the schedule demands."

Better answer

"When there is evidence the path cannot matter, for example it is not functionally used, with an owner and an expiry."

Strong answer (a 4)

Gives general guidelines: waivers are for paths shown by logic or constraint not to occur, never for margin, and never for hold on a path that can occur, since frequency does not fix hold; a waiver names the evidence, the owner, the scope (these instances) and an invalidating condition; waived items are reported separately from fixed ones; critical receivers (clock, reset) are never waived on the strength of simulation.

Follow-ups

Who approves? What if the evidence changes?

Common trap

Treating a waiver as a fix in the dashboard.

Evidence to cite

Waiver register with evidence references.

Taught in

Noise Review, Final Checklists