What does a PrimeTime message about an unconstrained endpoint mean, and how do you find it?

Short Answer

An unconstrained endpoint is a register, port, or latch input with no required time defined for it, so PrimeTime cannot check setup or hold there at all; it is not a passing path, it is simply not being checked. Finding it means turning on unconstrained-path reporting with the timing_report_unconstrained_paths variable (PT) and running check_timing (PT) or report_timing -exceptions all (PT), which lists the endpoint and states why it has no required time.

Technical Explanation

• Every timing endpoint needs a required time to be checked against, which normally comes from a clock definition reaching that endpoint, or an explicit output or input delay for a port.
• If a register's clock pin was never reached by a defined clock, for example because create_clock (SDC) was applied to the wrong pin or the clock network was disabled at some point, PrimeTime has nothing to compare the data path against and drops it from every normal report.
• The check_timing (PT) command's unconstrained-endpoints check specifically looks for this and lists the endpoints affected, though it only reports unconstrained endpoints, not unconstrained startpoints, so a missing input constraint on the other side of the same path needs a separate check.
• Setting timing_report_unconstrained_paths (PT) to true and running report_timing -exceptions all (PT) reports these unconstrained paths under a path group called "(none)", along with path attributes like the endpoint's unconstrained reason that state the specific cause.
• Because an unconstrained endpoint produces no violation at all, silently missing one is more dangerous than a reported failing path: a real hold or setup problem at that endpoint would never appear in a slack-based signoff summary.
• This is why signoff requires both a clean timing report and zero unconstrained endpoints, since the first alone does not prove the whole design was actually checked.
• An endpoint can also be unconstrained because a port was never given an output delay, or because a case-analysis value cut off the only clock path that would otherwise have reached it, so the message's stated reason should always be read before assuming the cause is a missing clock definition.
• Because SDC changes tend to accumulate over many engineers and many revisions, a design with a long history is more likely to accumulate an unconstrained endpoint quietly, which is why this check is worth running on every signoff pass rather than only after a suspicious result.

Follow-up Question & Model Response

If check_timing only reports unconstrained endpoints and not unconstrained startpoints, how do you catch a missing input constraint on the other side of a path?

Candidate Model Response: You need a separate look at startpoint coverage, since check_timing's unconstrained-endpoint check is deliberately one-sided. Setting timing_report_unconstrained_paths (PT) and reviewing the path attributes from report_timing -exceptions all (PT), specifically the startpoint's unconstrained reason, surfaces the startpoint side the same way the endpoint attribute does. In practice, teams check both directions as part of the same signoff pass, because a missing constraint at either end produces the identical symptom: a path quietly excluded from every normal report.