How does PrimeTime decide which nets actually need crosstalk analysis?

Short Answer

PrimeTime starts from every net that has coupling capacitance to at least one neighbor and an overlapping timing window with that neighbor, then narrows the list using explicit include and exclude commands the designer supplies for cases the tool cannot infer on its own, such as two nets that are physically close but logically guaranteed never to switch together. Without SI enabled at all, the tool skips crosstalk analysis entirely and times every net as an isolated wire.

Technical Explanation

The net list crosstalk analysis actually walks through is built in stages, from a broad automatic pass down to designer-supplied refinements.

• Stage one: coupling capacitance must exist. A net with no coupling capacitance to any neighbor in the annotated parasitics has nothing for the SI flow to evaluate, so it is automatically out of scope.
• Stage two: timing windows must overlap. Among nets that do have coupling capacitance, the tool keeps only the aggressor-victim pairs whose timing windows overlap, since a pair that can never plausibly switch together contributes nothing real to the analysis.
• Stage three: explicit inclusion and exclusion commands adjust the automatic list. set_si_delay_analysis (PT) and set_si_noise_analysis (PT) let a designer explicitly include or exclude specific nets from delay or noise analysis respectively, and set_si_aggressor_exclusion (PT) removes aggressor-to-aggressor pairs known to always switch in the same direction.
• These commands exist because the tool cannot see functional intent. It has no way to know that two nets are logically forbidden from switching in opposite directions, for example, so a designer who knows that has to state it explicitly to avoid needless pessimism.
• The whole flow is off if SI is not enabled. Without si_enable_analysis (PT) set to true, none of these stages run — every net is timed as if it were alone.

Follow-up Question & Model Response

If you exclude a net pair with set_si_aggressor_exclusion and the underlying RTL logic changes later so the exclusion is no longer true, how would that surface?

Candidate Model Response: It would not surface automatically — the exclusion is a static PT-session command, not something the tool re-derives from logic each run, so a stale exclusion stays in effect silently after the assumption stops being true. This needs an owner and a review trigger, the same discipline a false path exception needs: a change to the logic feeding excluded nets should prompt someone to recheck the same-direction-only assumption, not leave it unexamined.