BeginnerQuestion 44 of 95Source: Synopsys PrimeTime User Guide: Checking and Analyzing the Design

What does it mean for a timing path to be unconstrained?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

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.

A block diagram with one output port highlighted in red because it has no set_output_delay constraint and never appears in report_timing — Technical Reference DiagramWhat does it mean for a timing path to be unconstrained?

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 the timing_report_unconstrained_paths variable to true also makes report_timing (PT) list those paths under a path group called "(none)", which is why running both is part of trusting any report.

Common Mistake

The Trap: assuming a completely clean report_timing output means every signal has been checked.

A designer only ever runs report_timing for the worst paths and never runs check_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