What does it mean for a timing path to be unconstrained?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Last updated:
Short Answer
An unconstrained path is one the tool can trace electrically but has no timing requirement attached to — no clock relationship or set_input_delay/set_output_delay (SDC) tells it what "on time" means. The tool will not report a slack number for it at all, good or bad.
Technical Explanation
A path needs a requirement before slack means anything.
- What makes a path constrained: every path needs a startpoint and endpoint each tied to a clock, or an I/O delay statement, so the tool has both an arrival time and a required time to compare.
- A missing constraint, not a missing wire: an unconstrained path still physically exists and carries a real signal — the netlist connection is fine, but nothing tells the tool what deadline that signal must meet.
- Why it happens: a common cause is a new output port added late in the flow that never got a matching
set_output_delay(SDC), or an asynchronous reset pin the SDC file never mentions. - The tool stays silent, it does not fail:
report_timing(PT) simply shows no path there, and a design can look perfectly clean while an entire signal is never being timed at all. - How you find them:
check_timing(PT) reports every unconstrained endpoint by default; setting thetiming_report_unconstrained_pathsvariable to true also makesreport_timing(PT) list those paths under a path group called "(none)", which is why running both is part of trusting any report.
| Cause | What's missing | Where it hides | How it's checked |
|---|---|---|---|
| New output port added late | A matching set_output_delay | report_timing shows no path there, clean or not | check_timing -include unconstrained_endpoints |
| New input port added late | A matching set_input_delay | Same -- no entry anywhere in report_timing | check_timing -include unconstrained_endpoints |
| An async reset or similar pin the SDC never mentions | Any clock relationship or I/O delay at all | Same | check_timing, or report_timing with timing_report_unconstrained_paths set |
Common Mistake
The Trap: assuming a completely clean report_timing output means every signal has been checked.
- A designer only ever runs
report_timingfor the worst paths and never runscheck_timing(PT) to look for missing constraints. - An unconstrained output pin ships to silicon having never been timed once, and any real delay problem on it is discovered only after tapeout.
Follow-up Question & Model Response
Why doesn't the tool just assume a default requirement for an unconstrained path? Candidate Model Response: Because the tool has no way to know what the outside world expects from that signal — a chip output could be read by a slow off-chip device or a fast one, and only the designer knows which. Guessing a default would silently hide real problems instead of flagging them, so the tool leaves the path unreported and relies on check_timing (PT) to surface it as something the designer must explicitly fix by adding the missing constraint.
Practical Example
A block adds a new debug output port, DBG_OUT, late in the design cycle. The SDC file is never updated with a matching set_output_delay. report_timing never mentions DBG_OUT in any of its top-worst-path lists; only check_timing -include unconstrained_endpoints (PT) reveals it, three weeks later, still missing a delay constraint.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
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.
Instant PDF by email · Secure checkout via Razorpay · Full refund if the files fail to arrive or open
Continue practising