How does crosstalk show up in a PrimeTime timing report?

Short Answer

With crosstalk analysis on, PrimeTime already includes crosstalk in every path delay, but you only see it separately if you ask. report_timing -crosstalk_delta (PT) adds a Delta column that shows the delay change on each victim net arc caused by switching neighbours. To find the nets that cause the most trouble across many paths, report_si_bottleneck (PT) ranks them.

Technical Explanation

• Crosstalk analysis must be enabled with si_enable_analysis (PT) and needs coupling capacitance in the parasitics. Without it the Delta column is empty and no delta delay is included.
• A delta delay is the change in a victim net's delay because nearby aggressor nets switch within its timing window. An aggressor switching in the opposite direction slows the victim, which hurts setup; one switching in the same direction speeds it up, which hurts hold.
• The delta appears on the input pin row of the cell the victim net drives, because it is a net arc effect. -crosstalk_delta turns on input pins in the report even if you did not ask for -input_pins.
• The Incr column already contains the delta, so do not add it twice. The Delta column tells you how much of each incremental delay is crosstalk.
• report_si_bottleneck -cost_type delta_delay (PT) lists the victim nets with the largest absolute delta delay among nets with slack below a threshold. The threshold is 0 by default, so only violating nets appear; -slack_lesser_than widens it.
• Clock nets are excluded from the bottleneck report by default, because they carry no slack. -include_clock_nets adds them, which matters when crosstalk on a clock trunk shifts many paths.
• report_delay_calculation -crosstalk (PT) on one victim arc lists the aggressors, which are active and how large each bump is. ICC2 also accepts report_timing -crosstalk_delta (ICC2) with time.si_enable_analysis (ICC2) on, but PT's numbers are the ones signed off.

What To Check

• That SI analysis is enabled and coupling parasitics are loaded, before reading any delta.
• The Delta column on the worst setup and hold paths, and which rows carry the largest values.
• The top victims from report_si_bottleneck (PT) and how many violating paths share them.
• Aggressor details for the worst victim, to decide between spacing, shielding or driver sizing.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Deltas of a few picoseconds per victim, and no net in the bottleneck report shared by many violating paths.
• Suspicious (illustrative): One net shows 18 ps of delta on a setup path and appears in 40 violating paths, a single-cause crosstalk problem worth a targeted fix.
• Hard stop: SI disabled in a signoff run, or a clock net with large delta that nobody included in the bottleneck report.

What The Interviewer Is Testing

• Knowing where the delta appears, on the victim's input pin row, and that it is already in Incr.
• Which direction of aggressor switching hurts setup, and which hurts hold?
• Using the bottleneck report to find shared victims instead of fixing path by path.

Follow-up Question & Model Response

"How would you fix a net that shows large delta delay on many paths?"

Candidate Model Response: First I would look at its aggressors with report_delay_calculation -crosstalk (PT) to see whether one or two dominate. A weak driver on the victim is often the easiest fix, since upsizing it shortens the transition and makes the net less sensitive. If the coupling itself is the problem, I would ask for extra spacing or shielding on that net in ICC2 and reroute it. After the change I would re-extract and confirm both the delta and the path slack improved.