How do you find and fix the nets that cause the most crosstalk delay?

Short Answer

Start with report_si_bottleneck -cost_type delta_delay (PT) to rank victim nets by the crosstalk delay they add on failing paths. Then fix them with fix_eco_drc -type delta_delay -delta_delay_threshold <v> (PT), which sizes drivers and inserts buffers on victims whose delta delay exceeds the threshold. A threshold is needed because there is no delta delay constraint, and so no delta delay slack to drive the fixing.

Technical Explanation

• report_si_bottleneck (PT) has four cost types. delta_delay ranks victims by absolute delta delay, delta_delay_ratio by delta delay relative to stage delay, total_victim_delay_bump by the sum of bump heights, and delay_bump_per_aggressor ranks aggressor nets by the bumps they cause on victims.
• The default slack level is zero, so only nets on violating paths get a cost. -slack_lesser_than widens it. Without -max or -min both setup and hold are considered, and clock nets are left out unless you add -include_clock_nets.
• For one reported net, report_delay_calculation -crosstalk (PT) from the driver pin to a load pin lists the aggressors, which ones are active, their bump heights and whether their timing windows line up.
• fix_eco_drc -type delta_delay (PT) targets victims whose delta delay cost exceeds the threshold and that lie on a negative-slack path. The threshold must be positive and applies to both slowdown and speedup. It picks nets with the same bottleneck analysis, so the report previews its targets, and in DMSA the report merges all scenarios.
• Delta delay fixing requires a PrimeTime-ADV-PLUS license (PT UG, ECO chapter).
• Sizing and buffering help because a stronger victim driver holds its net more firmly, and a buffer shortens the coupled run each driver sees. Long parallel routes may still need spacing or shielding in ICC2; set_coupling_separation (PT) lets you test that gain in PrimeTime first.

What To Check

• The top victims by delta delay on failing paths, setup and hold separately.
• Active aggressors per victim and whether their windows really overlap.
• Delta delay on the same nets after fixing, and the path slack they sit on.
• Nets sizing could not help, which need a routing fix.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The top 20 victims drop from 40 to 60 ps of delta delay to under 15 ps, and their paths pass.
• Suspicious (illustrative): Delta delay falls but path slack barely moves, meaning crosstalk was not what limited those paths.
• Hard stop: Victims left above threshold with the note that no fix fits, or new noise violations after fixing.

What The Interviewer Is Testing

• Knows why delta delay fixing needs a threshold.
• Uses the bottleneck report to preview targets before fixing.
• Knows when sizing cannot help and routing must change.

Follow-up Question & Model Response

"Why not fix the aggressor instead of the victim?"

Candidate Model Response: Sometimes you should: the delay_bump_per_aggressor cost type finds aggressors that hurt many victims at once. But slowing an aggressor's edge can break the aggressor's own timing, since it is a signal on some other path. fix_eco_drc -type delta_delay (PT) works on victims, which is safer for timing. When one aggressor dominates, the cleaner fix is often physical, such as spacing or shielding the pair in ICC2.