Why does crosstalk delay analysis require separate early- and late-mode runs?

Short Answer

Crosstalk delay analysis checks two opposite effects on the same victim net: an aggressor switching the same direction can push the victim's edge later (delay push-out), while an aggressor switching the opposite direction can pull it earlier (delay pull-in). A setup check needs the worst push-out delay and a hold check needs the worst pull-in delay, and no single crosstalk-adjusted delay number captures both, so PrimeTime (PT) computes an early-mode and a late-mode delay for the same arc.

Technical Explanation

Coupling capacitance between two adjacent nets means a switching aggressor injects charge onto a victim net through that shared capacitor, on top of whatever the victim's own driver is doing.

• If the aggressor switches the same direction as the victim, the extra injected charge slows the victim's edge -- the push-out (late-mode) delay, the one setup checks care about because it makes arrival later than expected.
• If the aggressor switches the opposite direction, the injected charge fights the victim's own edge and speeds it up -- the pull-in (early-mode) delay, the one hold checks care about because it makes arrival earlier than expected.
• The tool cannot know in advance which direction a real aggressor will switch relative to the victim, so signoff-quality crosstalk analysis evaluates both directions and reports whichever is worst for the check -- setup or hold -- currently running.
• Because setup and hold pull the delay number in opposite directions, applying only one crosstalk-adjusted delay to both checks would under-report one of them; an averaged delay would look fine on paper while missing the actual worst case on at least one side.
• The switching window matters as much as direction: an aggressor only affects the victim if their transitions overlap in time, so the tool tracks each aggressor's timing window before deciding whether to include its contribution at all.

Follow-up Question & Model Response

If an aggressor's switching window doesn't overlap the victim's transition at all, does the tool still apply a crosstalk delta to that pair?

Candidate Model Response: No -- PrimeTime first checks each aggressor's timing window, derived from its own arrival-time analysis, against the victim's transition window before including any delta from that pair. An aggressor that switches well before or after the victim's edge cannot inject charge during the window that matters, so its contribution is excluded rather than added as a fixed worst-case penalty regardless of timing. This is why crosstalk analysis needs a full timing solve to even begin -- the tool needs arrival-time windows for every net before it can decide which aggressor-victim pairs are physically capable of interacting. Skipping this window check and simply summing every physically adjacent aggressor's worst-case contribution is the more common shortcut, and it is what the related question on additive crosstalk pessimism actually addresses.