An ECO created new crosstalk violations on untouched nets. Why, and how do you fix it?

Short Answer

Crosstalk depends on the neighbours and on timing windows, and an ECO can change both without touching the victim. ECO routes fill gaps next to existing nets, upsized drivers switch faster, and shifted arrival times make aggressor and victim windows overlap. Find the victims with report_si_bottleneck (PT), fix delta delay with fix_eco_drc -type delta_delay (PT), and implement with route_eco (ICC2).

Technical Explanation

• New coupling capacitance: ECO routing uses whatever space is left. A rerouted or new net can run parallel to an untouched net for hundreds of microns, adding coupling the original route never had.
• Stronger aggressors: an upsized cell or a new buffer switches with a sharper slew and more drive, so the same coupling now injects more noise and delta delay into its neighbour.
• Moved timing windows: fixing one path changes arrival times downstream. An aggressor that used to switch well away from the victim transition can now overlap it, and the delta delay appears with no geometry change at all.
• report_si_bottleneck -cost_type delta_delay -min -max (PT) lists victim nets ranked by the absolute delta delay, max and min analysis together, merged across scenarios in DMSA. Use it to preview what fixing will target.
• fix_eco_drc -type delta_delay -delta_delay_threshold 0.05 (PT) sizes cells and inserts buffers on victim nets whose delta delay cost exceeds the threshold. There is no delta delay slack, so the threshold is required, and it applies to both slowdown and speedup. By default only nets on paths with negative slack are targeted; -slack_lesser_than changes that. This needs a PrimeTime-ADV-PLUS license.
• In ICC2, keep SI analysis on during post-ECO checks with time.si_enable_analysis (ICC2), and compare report_timing -crosstalk_delta (ICC2) with report_timing -crosstalk_delta (PT). The numbers differ because the extraction and SI engines differ.
• Routing fixes such as spacing or shielding a victim are done in ICC2 and then re-extracted; PrimeTime can only evaluate them.

What To Check

• Victim nets with new delta delay after the ECO compared with the pre-ECO run.
• Which aggressors are ECO-touched nets or upsized drivers.
• Timing window overlap on the worst victims.
• Whether the new violations are setup (slowdown) or hold (speedup).

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): After delta delay fixing, the worst victim delta drops under the threshold and no new victims appear.
• Suspicious (illustrative): The same victims return after route_eco because the new route runs next to them again.
• Hard stop: Hold violations from speedup delta delay in a fast scenario that the setup-only check missed. Fix before signoff.

What The Interviewer Is Testing

• Can you name the three ways an ECO creates crosstalk on untouched nets?
• Knowing the delta delay fixing option, its threshold and its license.
• Checking both slowdown and speedup, and correlating PT with ICC2.

Follow-up Question & Model Response

"Why does fix_eco_drc need a threshold for delta delay?"

Candidate Model Response: Delta delay has no constraint behind it, so there is no delta delay slack for the tool to drive to zero. The threshold tells it which victims are worth fixing: any net on a negative-slack path whose delta delay cost exceeds the value. The same threshold covers slowdown and speedup. Set it too low and the tool changes many nets for tiny gains; too high and it leaves the real victims alone.