ExpertQuestion 28 of 69

Construct a scenario where the back-annotation precedence order produces a subtly wrong result that passes all obvious checks.

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

A forgotten set_resistance override on one net outranks a later, accurate SPEF read for that same net, because PrimeTime's back-annotation precedence puts lumped resistance and capacitance commands above detailed parasitics. report_annotated_parasitics -check still passes, because the net does have a complete RC network — it just is not the one everyone assumes.

Back-annotation precedence order: a stale set_resistance 5-ohm override on long_route outranking accurate 38-ohm SPEF data, both showing complete in report_annotated_parasitics -check — Technical Reference DiagramConstruct a scenario where the back-annotation precedence order produces a subtly wrong result that passes all obvious checks.

Technical Reference DiagramConstruct a scenario where the back-annotation precedence order produces a subtly wrong result that passes all obvious checks.

Technical Explanation

PrimeTime resolves conflicting back-annotation data with a fixed order of precedence, highest to lowest: an SDF file or set_annotated_delay (PT), then lumped values from set_resistance/set_load (PT), then detailed parasitics from read_parasitics (PT reading SPEF), then wire-load models as the fallback. Each tier fully overrides the ones below it, net by net.

How the trap gets set. Before real extraction existed, someone added set_resistance 5 [get_nets long_route] (PT) to a shared constraint file to approximate a known-long route, and nobody removed it once the project moved on.
How it stays invisible. Later, the team reads an accurate, full-chip SPEF with read_parasitics (PT) and runs report_annotated_parasitics -check (PT), which reports a complete RC network for long_route — the net genuinely has RC data from the SPEF read, and the check cannot see that a higher-precedence override exists for it.
Why the completeness check cannot catch it. -check verifies that annotation data exists, not which precedence tier is actually driving the timing calculation.
The actual result. Because set_resistance outranks detailed parasitics, PrimeTime computes long_route's delay from the stale 5-ohm lumped value, not the real extracted resistance the SPEF carries — nothing errors, and the report shows a fully-annotated design.
What it can do to the signoff verdict. Depending on whether the stale value is optimistic or pessimistic relative to the real extraction, this either masks a genuine violation or manufactures a fake one, undetectable from the completeness report alone.
How you actually catch it. A precedence-shadowing audit is separate from a completeness check: compare report_annotated_delay (PT) or the net's actual resistance against the SPEF's value for it, or search the constraint set for lingering set_resistance/set_load (PT) commands on nets that now have real extraction.
Why this class of bug is easy to reintroduce. Early-stage estimation commands are often added by whoever owns floorplan or timing-budget work at that stage, and removed by whoever owns extraction later — if those are different people on different schedules, there is no natural point where the override gets deleted unless someone specifically audits for it.

Common Mistake

The Trap: treating a clean report_annotated_parasitics -check (PT) as proof that every net's timing comes from the intended data source.

A clean completeness check only confirms every net has some RC data annotated — it says nothing about which precedence tier is actually in effect for a given net.
Old set_resistance/set_load (PT) overrides from early-stage estimation are especially easy to leave behind, because they sit in shared constraint files that nobody revisits once extraction becomes available.

Follow-up Question & Model Response

"How would you build an automated check that catches this class of bug across a whole design, rather than one net at a time?"

Candidate Model Response: I would script a comparison that walks every net carrying a set_resistance or set_load (PT) override, checks whether that same net also has SPEF data from read_parasitics (PT), and flags any net where both exist — since a net with a lingering lumped override and real extraction is exactly the shadowing case. That flag list gets reviewed before signoff, and any override the team cannot justify keeping gets removed with remove_annotated_check/reset_design -keep_parasitics (PT) so the SPEF data actually governs the calculation.

Practical Example

During an early floorplan pass, set_resistance 5 [get_nets long_route] (PT) was added to model a 3 mm cross-die route before place-and-route existed. Six months later, post-route SPEF extraction gives the same net a real resistance of 38 ohms due to its actual metal layer and width. report_annotated_parasitics -check (PT) reports long_route as fully annotated with an RC network, and the timing report shows the path passing with 65 ps of setup slack. Running the precedence-shadowing script reveals the leftover set_resistance command still in the constraint file; removing it and re-running timing drops the same path to −40 ps, because the true 38-ohm resistance produces far more delay than the stale 5-ohm placeholder ever modeled.

Complete STA Handbook