By default, does STA assume every path is single-cycle, and what happens if a genuinely multicycle path isn't declared?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Yes -- by default STA assumes single-cycle for ALL paths. A path that's actually allowed multiple cycles to reach its capture flip-flop (e.g. a configuration-register-driven enable stable across several clocks) still gets checked as if it needed to close in one cycle unless explicitly declared with set_multicycle_path. Without that declaration, the tool over-constrains the path and misreports it as violating, when it actually has legitimate extra cycles to work with.
Technical Explanation
- By default, STA assumes single-cycle timing for ALL paths -- there's no automatic detection of which paths are actually allowed more than one cycle.
- A path that's genuinely multicycle (e.g. a configuration-register-driven enable, stable across several clock cycles) still gets checked as single-cycle unless explicitly declared with
set_multicycle_path. - Without that declaration, the tool over-constrains the path and misreports it as violating -- the path isn't actually broken, the constraint is just wrong.
- A false path, by contrast, will NEVER be functionally exercised at all (e.g. tied-together mux selects making certain input-output combinations impossible) -- it needs
set_false_path, notset_multicycle_path, and correctly identifying false paths has a real impact on tool performance since the tool stops wasting analysis effort on paths that can't happen. - The two exceptions have distinct real commands:
set_false_path -from [get_pins ...] -to [get_pins ...]for a structurally impossible path, andset_multicycle_path <n> -setup -from ... -to ...for a path legitimately allowed more than one cycle.
Common Mistake
The Trap: Seeing a reported violation on a path that's genuinely multicycle by design and trying to fix the physical implementation, when the real fix is declaring set_multicycle_path -- the path was never actually broken, the constraint was.
Follow-up Question & Model Response
"Why does correctly identifying false paths specifically improve tool performance, beyond just cleaning up the timing report?"
Candidate Model Response: Because every path STA analyzes costs real computation, and a path incorrectly left as a default single-cycle check (when it's actually false) still gets fully analyzed and potentially chased by optimization -- declaring it false lets the tool skip that wasted analysis and optimization effort entirely.
Practical Example
Debug Scenario: A path driven by a configuration register that only changes value once at boot shows a reported setup violation. Investigating, the path is legitimately allowed several cycles to settle -- it was never declared with set_multicycle_path, so STA was checking it against an artificially tight single-cycle requirement.
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Continue practising