Crosstalk in VLSI: Glitch Noise, Delta Delay, Timing Windows and Fixes

Two wires that run side by side on a chip are also two plates of a capacitor. When one of them switches, some of that charge moves onto its neighbour. On a quiet neighbour this shows up as a small bump in voltage, called a glitch. On a neighbour that is switching at the same moment, it makes the edge faster or slower. This is crosstalk, and on any design at a modern node it is part of normal timing and noise sign-off, not a rare corner case.

This guide explains crosstalk in VLSI for physical design engineers: where coupling comes from, glitch noise and delta delay, how SI-aware STA uses timing windows, and how to debug and fix violations, with illustrative worked examples, a flowchart, interview questions and an FAQ.

Related reading: Signal Integrity and Crosstalk (overview), Static Timing Analysis (STA) in VLSI, Setup and Hold Violations and Routing in VLSI Physical Design.

What crosstalk is#

Every routed net has capacitance to ground (to the substrate and to the layers above and below) and capacitance to the wires next to it. The second part is the coupling capacitance, usually written Cc. Two names are used throughout crosstalk analysis:

• Aggressor: the net that switches and injects charge.
• Victim: the net that receives the disturbance.

Any net can be both. A long bus bit is an aggressor to its neighbours on one transition and a victim of them on the next.

Coupling capacitance grows when:

• Spacing shrinks. Coupling is roughly inversely related to the gap between the wires, so minimum-spaced routes couple the most.
• Parallel run length grows. Two wires that run next to each other for a long distance on the same layer share a large sidewall area.
• Wires get taller relative to their width. At smaller nodes, metal lines are narrow and tall, so a larger share of each wire's total capacitance is sidewall coupling to its neighbours rather than capacitance to ground.

A victim is more sensitive when its own driver is weak (a high-resistance driver cannot quickly pull the injected charge back) and when it is long and lightly loaded otherwise. An aggressor is more harmful when its driver is strong and its transition is fast, because a fast edge pushes charge through Cc in a short time.

Effect 1: crosstalk glitch (noise)#

When the victim is not switching (held steady by its driver) and an aggressor switches, the charge coupled through Cc briefly pulls the victim away from its steady value. The victim driver then restores it, so the result is a pulse: a glitch, also called a noise bump.

There are four kinds, named by the victim's steady state and the direction of the bump:

• Rise glitch: victim steady low, rising aggressor pushes it up.
• Fall glitch: victim steady high, falling aggressor pulls it down.
• Overshoot: victim steady high, rising aggressor pushes it above the supply.
• Undershoot: victim steady low, falling aggressor pulls it below ground.

Rise and fall glitches can cause logic failures because they move the victim toward the opposite level. Overshoot and undershoot rarely change the logic value but are checked on some designs for reliability.

When does a glitch cause a failure?#

A glitch is only a problem if the receiving logic responds to it. Whether that happens depends on the glitch height and width compared with the noise immunity of the receiver. A tall, very narrow glitch may be filtered out by the gate capacitance of the receiver; a lower but wider glitch may get through. Noise analysis tools compare the glitch against a noise immunity limit for each receiving pin, and some libraries carry noise models for this purpose.

The serious cases are:

• Clock nets. A glitch above the switching threshold on a clock pin is an extra clock edge. A flop can capture data it should not.
• Asynchronous set, reset and clear pins. A glitch can reset a flop or a memory with no clock involved at all.
• Data nets near the capture edge. A glitch that propagates through logic and arrives at a flop D pin inside its setup/hold window can be captured as the wrong value.
• Dynamic logic, latches and level-sensitive inputs, which have smaller noise margins than static CMOS.

A data-path glitch that dies out well before the capture edge is normally harmless.

Worked example 1: a charge-sharing estimate (illustrative)#

All numbers in this example are made up to show the arithmetic. They are not taken from any process or library.

A victim net has 60 fF of capacitance to ground and 20 fF of coupling capacitance to one aggressor. Suppose, as a worst case, the victim driver is too slow to react while the aggressor switches through a full 0.8 V swing, so the victim behaves as if it were floating. Simple charge sharing gives an upper bound on the glitch height:

V(glitch) ≈ Vdd × Cc / (Cc + Cg) = 0.8 V × 20 / (20 + 60) = 0.2 V

That is 25% of the supply, enough to worry about on a clock or reset pin. In reality the victim driver pulls the net back while the aggressor is still switching, so the actual peak is lower. How much lower depends on the ratio of the aggressor transition time to the victim's RC time constant: a fast aggressor and a weak victim driver approach the bound; a slow aggressor and a strong victim driver produce only a small bump. This is why the two quickest glitch fixes are a stronger victim driver and a slower or more distant aggressor.

Devgan's noise metric, cited below, is a more refined version of the same idea: an easy-to-compute upper bound on coupled noise for RC interconnect, similar in spirit to the Elmore delay used for timing.

Effect 2: crosstalk delta delay#

When the victim is switching and an aggressor switches during the same transition, the voltage across Cc changes by a different amount than it would with a quiet neighbour, so the victim's driver sees a different effective load.

• Opposite directions (victim rising, aggressor falling, or the reverse): the voltage across Cc changes by about twice the supply swing. The victim driver must move extra charge, the edge slows down and the delay increases. This is a positive delta delay (slowdown).
• Same direction: the voltage across Cc hardly changes, so Cc is almost free to the victim driver. The edge speeds up and the delay decreases. This is a negative delta delay (speedup).

A common simplification is a switch factor (also called the Miller factor) that scales Cc when it is lumped to ground: about 0 for same-direction switching, 1 for a quiet aggressor, and 2 for opposite-direction switching. Kahng, Muddu and Sarto showed in their DAC 2000 paper that 2 is not a true upper bound once real (ramp) transitions with different slews are considered; for ramps the worst case reaches a factor of 3. Sign-off tools therefore compute delta delay from the actual waveforms and timing windows instead of a fixed factor, but the switch-factor picture is still the right way to reason about the direction of the effect.

Which direction hurts setup and which hurts hold?#

Getting this right matters more than any formula, and it is a common interview question. Think of the effect on arrival times:

• Setup fails when data arrives late or the capture clock arrives early. So setup analysis applies slowdown to the launch clock path and the data path, and speedup to the capture clock path.
• Hold fails when data arrives early or the capture clock arrives late. So hold analysis applies speedup to the launch clock path and the data path, and slowdown to the capture clock path.

This means a crosstalk victim in the clock tree can hurt both checks, depending on whether it sits on the launch or capture side, and a victim on a data path hurts setup when slowed and hold when sped up.

Timing windows: which aggressors count#

If every aggressor were assumed to switch at the worst possible moment, almost every long net would fail. SI-aware STA avoids that pessimism with timing windows. For each net, STA knows the earliest and latest time it can switch in a cycle. An aggressor can only affect a victim's transition if its switching window overlaps the victim's window. Aggressors whose windows do not overlap are filtered out for delta delay.

The windows themselves depend on delays, and the delays depend on crosstalk, so SI analysis is iterative: a first pass may treat windows as very wide (pessimistic), compute delta delays, update the windows, and repeat until results settle. The tools also usually:

• Filter small coupling capacitances below a threshold, or lump them to ground, to keep run time reasonable.
• Combine multiple aggressors, checking whether their windows and logic allow them to switch together, rather than simply adding up every possible bump.
• Use logical correlation where available, for example two nets that are logical complements cannot both rise at once.

Worked example 2: a setup path that fails only with SI (illustrative)#

Again, all numbers are made up.

A register-to-register path at 1.0 GHz shows +18 ps setup slack in STA with SI turned off. With SI turned on, the same path reports −22 ps. The report shows a 40 ps positive delta delay on one net: a 600 µm route on a lower metal layer, driven by a small buffer, running at minimum spacing next to a 64-bit bus for most of its length.

Reading the report:

1. The delta delay is concentrated on one victim net, not spread across the path. That points to a routing fix rather than a logic change.
2. Several bus bits are listed as aggressors, and their timing windows overlap the victim's window. Moving the victim in time is not practical; reducing the coupling is.
3. The victim driver is small for a 600 µm load.

Two fixes are tried in the engineer's ECO run: upsizing the victim driver by two sizes, and re-routing the net one track away from the bus (or applying a double-spacing non-default rule). After re-extraction, the delta delay falls to a few picoseconds and the path closes with positive slack.

Worked example 3: a hold violation on the capture clock (illustrative)#

A hold check between two flops fails by 9 ps only when SI is enabled. The data path is short and has no significant crosstalk. The delta delay is on the capture clock branch: a clock net in the leaf level of the tree runs next to a fast data net with a strong driver. When that data net switches in the opposite direction during the clock edge, the capture clock is slowed, which delays the capture edge and eats hold margin.

Adding delay to the data path would fix the symptom, but the real problem is an unshielded clock net. The better fix is to re-route the clock segment with the clock non-default rule (wider spacing) or shielding, which removes the delta delay on every path through that clock branch, not just this one. This is why clock nets are usually routed with double spacing and, for critical clocks, VSS/VDD shields during clock tree synthesis.

Where crosstalk is handled in the flow#

Crosstalk is cheapest to prevent early. Floorplan and placement should avoid long shared channels for unrelated buses and clocks; CTS should give clock nets non-default rules and shields; crosstalk-aware detailed routing limits parallel run length around critical nets; post-route optimization fixes the rest on extracted parasitics with coupling; and SI-enabled timing and noise analysis on sign-off parasitics is the final check.

Crosstalk interacts with other checks covered on iVLSI: slow transitions make victims more susceptible and aggressors with fast edges more harmful, which links SI with max transition and max capacitance DRVs; layer choice and spacing are constrained by metal layer rules and technology DRCs; and in hierarchical designs, interface nets routed at the top level need SI margin in their time budgets.

How to fix crosstalk violations#

Two practical rules: fix clock and asynchronous victims first, because one fix protects many paths, and re-extract after every routing fix, because moving a wire changes its coupling to every neighbour.

Debugging crosstalk violations#

1. Separate noise from timing. Glitch and delta delay violations are reported differently and have different fixes.
2. Check what the victim drives. Clock, asynchronous set/reset and memory control pins come first; a data glitch that settles before the capture edge may be acceptable after review.
3. Look for a dominant aggressor. If one aggressor contributes most of the coupling, space it away, re-route it or downsize its driver if it has margin.
4. Check the victim's driver and length. A small driver on a long net is the most common root cause; upsizing or buffering fixes both effects.
5. Look at the routing. Break long same-layer parallel runs with a layer change or track swap.
6. Check the timing windows. A violation that depends on a barely overlapping window will come and go with unrelated changes; fix it with margin.
7. Re-extract and re-run SI timing and noise analysis, checking both setup and hold on the changed nets.

Interview questions and answers#

Q1. What is crosstalk in VLSI? The unwanted coupling of a signal from one net to a neighbouring net through coupling capacitance. The switching net is the aggressor and the affected net is the victim.

Q2. What are the two main effects of crosstalk? Glitch (noise) on a quiet victim, and delta delay (a change in delay) on a switching victim.

Q3. Does same-direction switching speed up or slow down the victim? It speeds it up, because the voltage across the coupling capacitor barely changes. Opposite-direction switching slows it down.

Q4. Which crosstalk effect hurts setup and which hurts hold? For setup, slowdown on the launch clock and data path and speedup on the capture clock are pessimistic. For hold, speedup on the launch clock and data path and slowdown on the capture clock are pessimistic.

Q5. Why are timing windows used in SI analysis? An aggressor can only change a victim's delay if both switch at overlapping times. Windows remove aggressors that cannot switch together with the victim, which removes a large amount of pessimism.

Q6. Why are clock nets shielded or double-spaced? A glitch on a clock can create a false clock edge, and delta delay on a clock affects every path through that branch. Protecting clock nets during CTS prevents both.

Q7. How does a stronger victim driver reduce crosstalk? It has lower output resistance, so it pulls the victim back to its steady level faster (smaller glitch) and is less affected by the coupled charge during a transition (smaller delta delay).

Q8. What is a switch factor (Miller factor)? A multiplier applied to coupling capacitance when it is lumped to ground: about 0 for same-direction, 1 for quiet and 2 for opposite-direction switching. Published work has shown the factor can exceed 2 for realistic ramp inputs, so sign-off tools compute the effect from waveforms instead.

FAQ#

Is crosstalk the same as signal integrity? Crosstalk is one part of signal integrity. In on-chip physical design, "SI" is often used to mean crosstalk delay and noise, but the broader term also covers effects such as power supply noise and, in some teams, related reliability checks.

Does shielding always help timing? It removes the coupling to the shielded neighbour, but a grounded shield adds capacitance to ground, so the nominal delay of the shielded net can go up slightly. The benefit is that its delay no longer depends on what its neighbours do.

Can a crosstalk glitch fail a chip even if STA is clean? Yes. Timing analysis checks delay; a glitch on a reset or clock pin is a functional problem that only noise analysis reports. Both checks are needed.

Summary#

• Crosstalk is coupling through the capacitance between neighbouring wires; the switching net is the aggressor and the affected net is the victim.
• On a quiet victim it causes glitches (rise, fall, overshoot, undershoot); on a switching victim it causes delta delay (slowdown for opposite-direction, speedup for same-direction switching).
• Coupling grows with smaller spacing, longer parallel runs and taller, narrower wires; weak victim drivers and fast aggressor edges make it worse.
• SI-aware STA uses timing windows and iteration to decide which aggressors can switch together, and applies slowdown or speedup to each part of a path depending on whether it is checking setup or hold.
• Fixes are spacing, shielding, victim upsizing or buffering, aggressor downsizing, and re-routing. Protect clocks and asynchronous nets first, and re-extract after every routing change.

References#

• J. Bhasker and R. Chadha, Static Timing Analysis for Nanometer Designs: A Practical Approach, Springer, 2009 (chapter "Crosstalk and Noise"): https://link.springer.com/book/10.1007/978-0-387-93820-2
• A. Devgan, "Efficient Coupled Noise Estimation for On-Chip Interconnects," ICCAD 1997: https://research.ibm.com/publications/efficient-coupled-noise-estimation-for-on-chip-interconnects
• A. B. Kahng, S. Muddu and E. Sarto, "On Switch Factor Based Analysis of Coupled RC Interconnects," DAC 2000: https://www.cecs.uci.edu/~papers/compendium94-03/papers/2000/dac00/pdffiles/04_4.pdf
• Crosstalk (overview): https://en.wikipedia.org/wiki/Crosstalk