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

What does report_delay_calculation show you that report_timing does not?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_timing (PT) shows you the final delay number for each pin along a path. report_delay_calculation (PT) shows the underlying math behind one specific delay: the drive strength, the load it is driving, the slew it produces, and which library model or SPEF entry the tool used to compute it. You reach for it when a single delay number looks wrong and you need to see what produced it, not just that it exists.

A single timing arc diagram showing input slew, driven load capacitance, and the resulting output delay and slew, labeled with the NLDM table lookup that produced them. — Technical Reference DiagramWhat does report_delay_calculation show you that report_timing does not?

Technical Explanation

A path report gives you the result of a calculation; report_delay_calculation opens up the calculation itself.

report_delay_calculation (PT) prints the inputs to one arc's delay computation: input slew, output load (capacitance from LIB/SPEF data), and the resulting delay and output slew.
This is the level where a bad SPEF annotation, a missing parasitic, or a mismatched Liberty (LIB) table shows up as an obviously wrong load or slew value.
report_timing (PT) would only show you the same delay number sitting quietly in the path, with no hint that its inputs were wrong.
A common use is comparing the reported load capacitance against what the layout tool actually extracted, to catch a net whose parasitics never got annotated.
Because it inspects one arc at a time, it is normally used after report_timing has already pointed at a suspicious pin, not as a first-pass debug step.
The command can also show whether a delay came from a table lookup (NLDM) or a curve model (CCS), which matters when the two give different answers for the same load.

Common Mistake

The Trap: assuming a strange delay number is a tool bug rather than a missing or wrong parasitic.

A net with zero extracted capacitance produces an unrealistically fast delay that looks like good news until report_delay_calculation shows the load is missing, not small.
Chasing the wrong root cause here can send a designer resizing cells that were never the actual problem.

Follow-up Question & Model Response

If report_delay_calculation shows the correct load and slew but the delay still looks wrong, what should you check next?

Candidate Model Response: At that point the load calculation is not the problem, so check the Liberty (LIB) timing arc itself — confirm the correct process/voltage/temperature (PVT) corner's library file was loaded, since a delay from the wrong corner's table can look believable but still be wrong. It is also worth confirming the arc's edge: rising and falling edges use separate table entries, and comparing the wrong one produces the same symptom. Both checks sit one level below report_delay_calculation, in the library data rather than PrimeTime's calculation.

Practical Example

A path's arrival time looks 90ps faster than a similar sibling path. report_delay_calculation (PT) on the suspect net shows 0.02pF of load, while the sibling net shows 0.19pF for a visually similar layout — pointing straight at a missing SPEF entry for that one net rather than a real design difference.

Complete STA Handbook