How do you read a report_si_bottleneck report to find the worst nets?

Short Answer

The report_si_bottleneck (PT) command ranks nets by how much crosstalk delay or noise they contribute across every scenario, then prunes duplicates so you get one unique, sorted list of the worst offenders instead of scrolling through a separate report per scenario. You read it top to bottom, fixing the highest-cost net first, since it usually touches the most violating paths per unit of repair effort.

Technical Explanation

Without this report, finding the nets worth fixing means digging through individual path reports and mentally tallying which nets keep reappearing. report_si_bottleneck does that tallying for you.

• It ranks nets, not paths. A single problem net can sit on dozens of violating paths at once, so ranking by net — rather than by path — points straight at the fix with the widest impact.
• The -cost_type option decides what "worst" means. For example, -cost_type total_victim_delay_bump (PT) ranks by how much total delay a net's coupling adds across all the paths it affects, which is one practical way to prioritize.
• It works across every scenario at once. Rather than running the report separately per corner or mode, the command gathers results across all active scenarios, sorts them, and removes duplicate nets so the same physical net does not appear once per scenario.
• The -slack_lesser_than option filters out noise from nets that barely matter, keeping the list focused on nets whose associated paths are close to or past a violation, rather than every net that has any coupling at all.
• Why it matters: SI fixes — shielding, spacing, resizing a driver — cost layout effort, so spending that effort on the net at the top of this list clears the most violations per fix, instead of chasing whichever net happens to show up in the first path report you open.
• What breaks: fixing nets in the order they appear in a plain report_timing (PT) path dump instead of this ranked view — that order reflects which paths happen to be worst, not which net, once fixed, removes the most violations.

Follow-up Question & Model Response

If the top net in a report_si_bottleneck list is a clock network net, would you fix it the same way as a top-ranked data net?

Candidate Model Response: No, and that distinction matters before doing anything else. A clock net acting as an aggressor against data nets is fixed on the aggressor side — shielding it, or reducing its coupling to nearby data routing — since you generally do not want to touch clock tree structure to fix a data-side SI problem. A clock net acting as a victim is more serious, because crosstalk on a clock net can shift an entire downstream launch or capture edge, not just one data path's arrival time, so I would prioritize that case even above a data net with a similar cost ranking, and verify the fix with report_clock_timing (PT) afterward.