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?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Annotated delays win. set_annotated_delay is tier 1 and read_parasitics detailed parasitics are tier 3, so on any arc where both apply the annotated delay is used and the SPEF-derived delay for that arc is ignored.
Complete Technical Explanation
Precedence decides this, not read order. set_annotated_delay sits at tier 1 and detailed parasitics from read_parasitics sit at tier 3, so wherever the two overlap, PrimeTime uses the annotated delay and ignores the SPEF-derived delay on that arc. The SPEF is not discarded - it still supplies R and C for design-rule checking and it still drives every other arc - but on the annotated arc its contribution to delay is simply not consulted. The debugging implication is where the real value of this question lies. A stray set_annotated_delay, say a debug override someone left behind from an earlier session, freezes that arc's delay at the annotated value no matter what parasitics you subsequently read. The symptom presents as my SPEF delay is not showing up on this specific arc, and it is maddening precisely because everything about the parasitic read looks correct. The move is to check report_annotated_delay for a manual annotation shadowing the arc. The fix is remove_annotated_delay on that arc, or a broader reset with reset_design or reset_design -keep_parasitics if you want to clear the session while holding on to what you read. It is the same shadowing hazard as set_load beating SPEF capacitance, one tier further up.
In Pd / Signoff
This is a debug reflex for a single wrong arc in a session that otherwise annotates fine. Before re-extracting or re-reading anything, run report_annotated_delay and look for a manual annotation on the arc in question, then clear it with remove_annotated_delay . It also argues for keeping debug overrides out of shared constraint and annotation scripts, since they outrank everything the parasitic flow produces.
Common Trap
Assuming a later read_parasitics overwrites an earlier set_annotated_delay because it came second. Precedence, not order, decides: the tier-1 annotation stays in force, the arc's delay is frozen, and the parasitic read appears to have had no effect on that one arc.
Expect Next
Why does a completeness check on the parasitics still pass on an arc whose delay is being shadowed by set_annotated_delay?
Topic And Primetime Commands
Back Annotation / SPEF & Parasitics. set_annotated_delay, reset_design, read_parasitics, report_annotated_delay
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising