ExpertQuestion 57 of 69Source: Synopsys PrimeTime User Guide: Signal Integrity Analysis and report_si_bottleneck

How do you debug a crosstalk-induced hold failure that only appears post-route?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A hold failure that only shows up after routing, and not before, usually means crosstalk delay is pulling in (speeding up) the data path or the clock path once real coupling capacitance exists between physical wires. The debug approach is to re-run with signal integrity analysis on, find which net actually moved the arrival time, and confirm the aggressor and victim really switch inside the same timing window. The fix targets the coupling itself, not the derate margin.

A routed clock buffer output net running parallel to a data bus for 180 microns, with a shared switching window highlighted showing a 62ps crosstalk pull-in that turns 45ps of hold margin into a 17ps violation. — Technical Reference DiagramHow do you debug a crosstalk-induced hold failure that only appears post-route?

Technical Explanation

Before routing, PrimeTime typically times nets using an estimated wire model or placement-based extraction, which has no real neighbor geometry, so no crosstalk is possible yet.
After routing, the tool has real parasitics from the SPEF (Standard Parasitic Exchange Format, the file listing each net's resistance and capacitance) file, including coupling capacitance to nearby switching nets.
A fast crosstalk "pull-in" on the data path shortens its arrival time, or a pull-in on the clock path moves the capture edge earlier, and either one alone can turn comfortable post-route margin into a hold violation.
Crosstalk only applies when the aggressor actually switches inside the victim's timing window, the time slice PrimeTime allows for the pessimism calculation, so a fail at the graph-based level does not always survive path-based re-timing with real windows.
Whether a net is analyzed for crosstalk at all is controlled by set_app_var si_enable_analysis true (PT), and report_si_bottleneck (PT) ranks the worst-offending nets by delta delay once analysis is on.
Because hold checks measure a same-edge race between launch and capture, a crosstalk push on the clock path itself, not just the data net, is often the real cause, so debugging has to check both sides of the check.
A practical debug order is: confirm the violation still shows up under path-based analysis with SI enabled, run report_si_bottleneck to shortlist the worst nets on that path, then check each shortlisted net's physical layout for spacing to its neighbors before touching any SDC constraint.
Because post-route parasitics come from the SPEF the extraction tool produced, a debug session should also confirm that file actually reflects the current routing, since a stale SPEF can either hide a real crosstalk problem or report one that routing already fixed.

Common Mistake

The Trap: blaming derate or CRPR settings for a hold fail that only appears post-route, and re-tuning OCV margins instead of checking whether one net's crosstalk delta is doing the damage.

Re-tuning derate factors hides the problem instead of fixing it; a coupling-driven pull-in on the clock path is still there at the next ECO.
Reading only the top-level report_timing (PT) summary and skipping report_si_bottleneck misses which net is the actual aggressor.

Follow-up Question & Model Response

If turning off SI analysis makes the violation disappear, does that prove the fail is a false positive?

Candidate Model Response: No, it proves the mechanism, not that the fail is fake. Turning off SI removes the crosstalk delta from the delay calculation entirely, so any real coupling-driven pull-in disappears along with it — that is expected, not evidence the violation was wrong. The right next step is confirming the aggressor genuinely switches inside the victim's timing window at that corner, using a path-based report rather than the graph-based one, since graph-based crosstalk pessimism can overstate how often that window really overlaps. If path-based analysis with SI enabled still shows the violation, treat it as real and fix the coupling, for example by adding spacing on the aggressor net, rather than loosening the hold margin.

Practical Example

Consider a design at 400MHz where a scan-mode clock buffer output net, u_scan_clk/buf12/Z, runs parallel to a fast-toggling 250MHz data bus wire for 180 microns after routing. Pre-route, the estimated wire model gives the launch-side hold path 45ps of margin. Post-route, report_si_bottleneck -cost_type delta_delay (PT) shows that same net pulled in by 62ps of crosstalk delay from the neighboring bus, because both switch inside a shared 90ps timing window at the worst corner. Net effect: 45ps of margin becomes a 17ps hold violation. Before touching anything physical, the designer first re-runs the path with path-based analysis and SI enabled to confirm the aggressor and victim genuinely overlap in time at this corner, rather than only in the graph-based worst case, and the violation holds. Re-routing that 180-micron segment with one extra track of spacing to the aggressor cut the coupling capacitance enough to bring the delta delay under 20ps, restoring 28ps of margin, without touching any SDC exception or derate value.

Complete STA Handbook