A design has both set_annotated_delay on some arcs and a full SPEF read. How does PrimeTime resolve the overlap, and what's the debugging implication?

Short Answer

Annotated delays win by precedence, not by which one was applied last. set_annotated_delay (PT) sits at tier 1 and SPEF-derived parasitics sit at tier 3, so on any arc where both apply, PrimeTime uses the annotated value and ignores the SPEF-derived delay for that arc.

Technical Explanation

• Precedence decides it, not read order. set_annotated_delay (PT) is a tier-1 override; detailed parasitics loaded with read_parasitics (PT) from an SPEF file sit at tier 3. Wherever the two overlap on the same arc, the annotated delay wins - it does not matter which command ran second.
• The SPEF is not thrown away. It still supplies resistance and capacitance for design-rule checks and still drives every arc that has no annotation. Only the delay of the specific annotated arc is overridden.
• Where this bites in debug. A stray set_annotated_delay - often a leftover debug override from an earlier session - freezes one arc's delay no matter what SPEF you read afterward. The symptom looks like "my SPEF delay isn't showing up on this one arc," which is confusing because everything about the parasitic read looks correct.
• How to check for it. Run report_annotated_delay (PT) on the arc in question. If it lists an entry there, that arc is shadowed and the SPEF value for it is not in play.
• How to fix it. remove_annotated_delay (PT) clears the specific override. reset_design (PT) clears the whole session, and reset_design -keep_parasitics clears everything except the parasitics you already read, if you want a clean slate without re-reading the SPEF.
• The pattern to remember. This is the same shadowing hazard as set_load (SDC) overriding SPEF capacitance, just one tier further up the precedence stack - an explicit override always beats a derived value.

Follow-up Question & Model Response

You re-read a corrected SPEF after fixing a routing issue, but a critical hold path still reports the old delay. What's the fastest way to confirm whether an annotation is the cause, and what do you do next?

Candidate Model Response: Run report_annotated_delay on the specific arc the path passes through - if it shows an entry, the arc is shadowed and the corrected SPEF is being ignored for that stage regardless of how clean the new parasitic read looks. The fastest fix is remove_annotated_delay on that arc, or reset_design -keep_parasitics if you'd rather clear every stray override at once without re-reading the SPEF you just fixed. Rerun report_timing (PT) afterward to confirm the delay now tracks the new parasitics. Checking report_annotated_delay first saves you from wrongly blaming the extraction tool.