BeginnerQuestion 83 of 95Source: Synopsys PrimeTime User Guide: Reporting and Debugging Analysis Results

What is the difference between report_timing and report_constraint in PrimeTime?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_timing (PT) prints one path in full detail — every pin, every incremental delay, down to a single slack number. report_constraint (PT) instead scans the whole design and prints a summary: how many endpoints pass, how many fail, and by how much, for every check type at once. You reach for report_timing once you already know which path you care about, and for report_constraint when you still need to find out what is broken.

A two-panel diagram: report_constraint's summary table listing 12 failing endpoints with slack values on the left, feeding one endpoint name into a report_timing pin-by-pin path detail on the right. — Technical Reference DiagramWhat is the difference between report_timing and report_constraint in PrimeTime?

Technical Explanation

The two commands answer different questions, and mixing them up wastes debug time.

report_constraint (PT) walks every endpoint in the design and checks setup, hold, and design-rule limits like maximum transition, then prints one line per violation with its slack.
report_timing (PT) takes one specific path — one startpoint, one endpoint — and prints the full arrival and required-time build-up that produced that single slack number.
A typical debug session starts with report_constraint -all_violators (PT) to see the whole picture, then moves to report_timing on the one or two worst endpoints it names.
report_constraint counts violations design-wide; it does not show you pin-by-pin delay, so it cannot tell you why a path is slow.
report_timing shows you exactly why one path is slow, but it says nothing about the other thousand endpoints in the design.
Running report_timing on every endpoint one at a time to find the worst violations works, but it is far slower than letting report_constraint rank them first.

Common Mistake

The Trap: treating report_timing as the first command to run on an unfamiliar design.

Without a report_constraint summary first, a designer can spend an hour tracing one path in detail while missing that a different endpoint fails by ten times as much.
The fix is cheap: run the summary first, then drill into the worst offenders it names.

Follow-up Question & Model Response

Once report_constraint has named the worst endpoint, is there a way to jump straight to that path's full report_timing output without retyping the pin names?

Candidate Model Response: Yes. report_constraint -all_violators (PT) prints the failing endpoint names, and those same names can be passed straight into get_timing_paths (PT) or typed after report_timing -to (PT) without re-deriving them by hand. This is the normal handoff between the two commands in a debug session: the summary names the problem endpoint, and the detailed report explains it. Copying the exact pin name from the summary avoids a common typo — endpoint names in a real design are often long hierarchical paths like u_core/u_fifo/rd_ptr_reg[3]/D, and a mistyped one silently reports a different, healthy path instead.

Practical Example

A block with 40,000 endpoints runs report_constraint -all_violators -path_type slack_only (PT) and gets back 12 failing setup checks, worst slack -85ps at endpoint u_dsp/acc_reg[15]/D. The designer then runs report_timing -to u_dsp/acc_reg[15]/D (PT) and sees the -85ps comes from one long combinational adder chain, not from clock skew — telling them to look at the datapath, not the clock tree, for the fix.

Complete STA Handbook