How do you trace a slack difference between two PrimeTime runs back to its root cause?

Short Answer

Comparing two PrimeTime runs on the same path means comparing them section by section the way a single report is read -- same startpoint and endpoint, same check type, then the clock path, the data path, and the required-time computation one arc at a time -- until the first point where the two runs diverge. That divergence point, not the final slack difference, tells the designer whether the change came from the library, the parasitics, the constraints, or an actual netlist edit.

Technical Explanation

A slack delta between two runs can come from several independent sources changing at once -- a library update, a re-extracted SPEF, an SDC edit, or an ECO netlist change -- and the final slack number alone cannot distinguish which one moved.

• The most direct method is running report_timing -path_type full_clock_expanded (PT) on the identical path in both runs and comparing the incremental delay column arc by arc, since the first arc where the two reports disagree marks where the change entered.
• If the divergence starts in the clock path section, the cause is a clock-tree or clock-constraint change -- a different source latency, a different derate, a CTS re-run -- not anything in the combinational logic.
• If the divergence starts in the data path section at a specific cell, checking that cell's size and its arc's characterization against both runs' libraries confirms whether an ECO resize or a library revision changed its delay.
• If no single arc differs but the required-time section changed, the cause is upstream of individual delays -- most often an SDC edit to clock uncertainty, an updated derate factor, or a changed setup/hold constant from a library swap.
• Automating this arc-by-arc diff across many paths at once, rather than checking one path by hand, is what a regression-tracking script typically does between two full-chip signoff runs, flagging only the paths whose divergence point moved rather than every path whose final slack changed by any amount.

Follow-up Question & Model Response

If two runs use the identical netlist, SDC, and library, but different SPEF files, where in the report would that difference actually show up first?

Candidate Model Response: A pure SPEF difference changes only the net delay contribution within the data path's incremental delay column, since parasitics affect wire resistance and capacitance, not cell delay or the clock definition itself. The divergence would appear at the first net arc in the arrival path, not at any cell arc and not in the required-time section, because SPEF has no bearing on setup/hold constants, clock uncertainty, or library-derived cell timing. If the divergence instead showed up at a cell arc or in the required-time section, that would rule out SPEF as the sole cause and point back toward a library or SDC change instead. This kind of elimination -- checking which section first diverges -- is exactly how a designer separates several simultaneously changed inputs without re-running each change in isolation.