Before fixing a violation, how do you prove it's real?

Short Answer

Before you spend an ECO on a violation, walk a short checklist. Confirm the constraints are complete, the clocks and their relationship are right, no exception is missing or ignored, the derates are the intended ones, the path still fails under exhaustive PBA, and it fails in a scenario you sign off. Only a violation that survives every step earns a fix.

Technical Explanation

• Constraints: check_timing (PT) reports unclocked registers, missing input delays, unconstrained endpoints, timing loops and ignored exceptions. Its warnings are not always design problems, but each one needs an explanation before you trust the report.
• Clocks: read the launch and capture clocks in the report. Asynchronous clocks timed as related, a generated clock on the wrong master, or two clocks whose periods give a tiny edge window all produce violations no ECO should touch.
• Exceptions: report_exceptions (PT) shows what applies and why some are partly ignored, and -ignored lists fully ignored ones. A missing hold multicycle or false path turns a correct design into hundreds of violations.
• Derates and uncertainty: the report shows them per stage. Check they match the signoff specification and that no extra placement-stage margin was left in the SDC.
• Pessimism: report_timing -pba_mode exhaustive (PT) recalculates each path with its own slews, removing graph-based worst-slew merging. A path that passes there is pessimism, not a real failure. Never waive on ml_exhaustive, which is accelerated with machine learning and may miss worse violations.
• Scenario and parasitics: confirm the failing scenario is a real signoff mode and corner, and that parasitics are fully annotated. Missing annotation gives wrong net delays.
• Order matters. Constraint and clock problems hide many violations behind one cause, so check them before per-path analysis.

What To Check

• check_timing (PT) warnings, each explained or fixed.
• Launch and capture clocks and their edge relationship on the failing path.
• Applied, partly ignored and fully ignored exceptions on the path.
• Derate and uncertainty values against the signoff specification.
• Exhaustive PBA slack and the scenario the path fails in.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_timing (PT) clean or fully explained, exceptions as intended, and violations that still fail under exhaustive PBA.
• Suspicious (illustrative): Many violations sharing one clock pair, or clearing under exhaustive PBA by 10 ps or more.
• Hard stop: Unclocked registers or ignored exceptions in a signoff scenario, which make every number in the report untrustworthy.

What The Interviewer Is Testing

• Has an ordered checklist, starting with constraints and clocks.
• Knows what exhaustive PBA removes and why ML-PBA is not enough for a waiver.
• A strong answer groups violations by cause before looking at single paths.

Follow-up Question & Model Response

"A path fails under GBA but passes under exhaustive PBA. Can you leave it?"

Candidate Model Response: If your signoff methodology accepts PBA results, yes, and the passing exhaustive result is the evidence. Record it rather than relying on memory, because the next run will show the GBA failure again. When you do fix nearby violations, run fix_eco_timing (PT) with exhaustive PBA too, so the tool does not over-fix a path that only fails in GBA. Never base the decision on ml_exhaustive, since it can miss a worse path.