Why does a switching aggressor net push out or pull in a victim signal?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A switching aggressor net pushes out or pulls in a victim through the coupling capacitance between them: current flowing through that shared capacitance either fights against the victim's own edge or helps it along, depending on whether the two nets switch in the same direction or opposite directions at close to the same time. The result is a real change in the victim's arrival time, not just a voltage bump.
Technical Explanation
Think of the coupling capacitor as a physical link that can either slow a signal down or speed it up, depending on which way its other end is moving.
- Coupling capacitance carries current in both directions. Any voltage change on the aggressor side pushes a proportional current through the coupling capacitor into the victim net, on top of whatever current the victim's own driver is already supplying.
- Same-direction switching causes push-out. If both nets are rising (or both falling) at the same time, the coupled current works against the victim's driver, because the capacitor sees less voltage difference to charge or discharge than it would alone — the victim's edge arrives later than it would with a quiet neighbor.
- Opposite-direction switching causes pull-in. If the aggressor falls while the victim rises (or vice versa), the coupled current adds to the victim driver's own effort, and the edge arrives earlier than it would alone.
- The size of the effect scales with coupling capacitance versus the victim's own load. A victim net with a strong driver and mostly ground (non-coupling) capacitance barely notices its neighbors; a weakly-driven, long, tightly-spaced net can see a large shift.
- Why it matters for setup and hold separately: a push-out helps a hold check (later launch-side clock edge) but hurts a setup check (later data arrival) — the same physical effect can be good news on one check and bad news on the other.
Common Mistake
The Trap: treating push-out as the only crosstalk delay direction worth checking, because it is the one that intuitively sounds bad.
- A designer signs off setup timing with worst-case push-out applied everywhere, but never checks the pull-in case for the same paths on hold.
- The tool actually analyzes both directions and picks whichever is worse for the specific check being run — setup uses the worst-case push-out, hold uses the worst-case pull-in — so skipping half the analysis by hand misses real hold risk.
Follow-up Question & Model Response
If an aggressor and a victim always switch in the same direction by design — say, two functionally correlated bus bits — does crosstalk analysis still need the opposite-direction case?
Candidate Model Response: By default, yes, unless the design team removes that pair from consideration entirely. PrimeTime SI has no visibility into functional correlation — it only sees a net's driver, coupling capacitance, and timing window, so it assumes either direction is possible to stay conservative. A verified correlation is not captured as a direction restriction on the pair; it is captured by excluding that specific aggressor-victim relationship with set_si_delay_analysis -exclude -victims [get_nets ...] -aggressors [get_nets ...] (PT), which tells the tool to stop pairing those two nets at all rather than narrowing which direction it still checks.
Practical Example
A victim net driven by a small inverter has a nominal net delay of 85ps with no coupling. With a same-direction switching aggressor active, report_timing (PT) shows the delay pushed out to 118ps — a 33ps penalty that eats into the setup path's slack. Run against the opposite-direction case for the hold check on the same net, the delay pulls in to 61ps, a 24ps improvement that the tool applies specifically to the hold analysis, because a hold check wants the earliest plausible data arrival, not the latest.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising