How do you find missing constraints and unsafe timing exceptions?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
A clean slack summary can lie to you — paths that were never checked (missing clocks, missing I/O delays) or paths that got exception'd out of analysis entirely both disappear from the report without ever actually passing. Walk representative input-to-register, register-to-register, and register-to-output paths by hand, and confirm generated clocks actually reach their intended registers and that case analysis matches whatever mode is active.
Technical Explanation
- A clean slack summary can lie to you — paths that were never checked (missing clocks, missing I/O delays) or paths that got exception'd out of analysis entirely both disappear from the report without ever actually passing.
- Walk representative input-to-register, register-to-register, and register-to-output paths by hand, and confirm generated clocks actually reach their intended registers and that case analysis matches whatever mode is active.
- False paths and multicycle paths are powerful but dangerous tools: a false path removes a timing relationship from analysis entirely, so it needs a real functional justification, not convenience; a multicycle constraint changes which launch/capture edge pair is being checked — it's not a shortcut for logic that's simply too slow, and a "standard" setup-side multicycle almost always needs deliberate hold-edge treatment too.
- Derive the actual edge relationship from the protocol instead of copy-pasting a memorized multicycle pair everywhere — validate every exception against real architecture or verification evidence, check how many objects each selector actually matched, and inspect the resulting timing report. A pattern written for one synchronizer can accidentally swallow an entire unrelated interface.
Command Checks & Actions
check_timingSurfaces missing or inconsistent timing setup, including unconstrained endpoints, as an explicit list rather than leaving them to be discovered as unexpectedly-clean timing later.
report_analysis_coverage -status_details {untested}Shows exactly which checks were never exercised and why -- for example a no_clock status -- which is how an unconstrained path is distinguished from a genuinely passing one.
report_exceptionsLists every currently loaded false-path, multicycle, and max-delay exception, so an overly broad exception is visible directly rather than only inferred from suspiciously clean timing.
Common Mistake
The Trap: Explaining false paths as 'paths that fail timing' or assuming a positive worst slack proves complete coverage.
Follow-up Question & Model Response
"What evidence makes a multicycle path legitimate?"
Candidate Model Response: The functional protocol must guarantee the intended capture opportunity, and the reported setup/hold edge relationships must match that guarantee.
Practical Example
Tapeout Scenario: A wildcard false-path constraint aimed at debug_status* also matches a newly added functional status bus. The run appears cleaner while a real transfer loses checking. Compare selections before and after the netlist update.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising