Crosstalk and Noise

In deep submicron technologies, crosstalk plays an important role in the signal integrity of the design. The crosstalk noise refers to unintentional coupling of activity between two or more sig nals. Relevant noise and crosstalk analysis techniques, namely glitch analy sis and crosstalk analysis, allow these effects to be included during static timing analysis and are described in this chapter. These techniques can be used to make the ASIC behave robustly.

6.1 Overview

Noise refers to undesired or unintentional effects affecting the proper oper ation of the chip. In nanometer technologies, the noise can impact in terms of functionality or in terms of timing of the devices.

Why noise and signal integrity? There are several reasons why the noise plays an important role in the deep submicron technologies: Increasing number of metal layers: For example, a 0.25mm or 0.3mm process has four or five metal layers and it increases to ten or higher metal layers in the 65nm and 45nm process geometries. Figure 4-1 depicts the multiple layers of the metal interconnect. • Vertically dominant metal aspect ratio: This means that the wires are thin and tall unlike the wide and thin in the earlier process geometries. Thus, a greater proportion of the capacitance is com prised of sidewall coupling capacitance which maps into wire to wire capacitance between neighboring wires. • Higher routing density due to finer geometry: Thus, more metal wires are packed in close physical proximity. • Larger number of interacting devices and interconnects: Thus, greater number of active standard cells and signal traces are packed in the same silicon area causing a lot more interactions. • Faster waveforms due to higher frequencies: Fast edge rates cause more current spikes as well as greater coupling impact on the neighboring traces and cells. • Lower supply voltage: The supply voltage reduction leaves little margin for noise.

In this chapter, we study the effect of crosstalk noise in particular. The crosstalk noise refers to unintentional coupling of activity between two or more signals. The crosstalk noise is caused by the capacitive coupling be tween neighboring signals on the die. This results in switching activity on a net to cause unintentional effects on the coupled signals. The affected signal is called victim, , and the affecting signals are termed as aggressors. Note that two coupled nets can affect each other, and often a net can be a victim as well as an aggressor.

Broadly, there are two types of noise effects caused by crosstalk- glitch, which refers to noise caused on a steady victim signal due to coupling of switching activity of neighboring aggressors, and change in timing (cross talk delta delay), caused by coupling of switching activity of the victim with the switching activity of the aggressors. These two types of crosstalk noise are described in the next two sections. Note: Some analysis tools refer to glitch as noise. Similarly, some tools use crosstalk to refer to crosstalk effect on delay.

6.2 Crosstalk Glitch Analysis

The magnitude of the glitch caused is dependent upon a variety of factors. Some of these factors are: i. Coupling capacitance between the aggressor net and victim: The greater the coupling capacitance, the larger the magnitude of the glitch. ii. Slew of the aggressor net: The faster the slew at the aggressor net, the larger the magnitude of glitch. In general, faster slew is be cause of higher output drive strength for the cell driving the ag gressor net. iii. Victim net grounded capacitance: The smaller the grounded capaci tance on the victim net, the larger the magnitude of the glitch. iv. Victim net driving strength: The smaller the output drive strength of the cell driving the victim net, the larger the magnitude of the glitch.

Overall, while the steady value on the victim net gets restored, the glitch can affect the functionality of the circuit for the reasons stated below. • Theglitch magnitude may be large enough to be seen as a differ ent logic value by the fanout cells (e.g. a victim at logic-0 may ap pear as logic-1 for the fanout cells). This is especially critical for the sequential cells (flip-flops, latches) or memories, where a glitch on the clock or asynchronous set/reset can be catastrophic to the functionality of the design. Similarly, a glitch on the data signal at the latch input can cause incorrect data to be latched which can also be catastrophic if the glitch occurs when the data is being clocked in. • Even if the victim net does not drive a sequential cell, a wide glitch may be propagated through the fanouts of the victim net and reach a sequential cell input with catastrophic consequences for the design.

6.2.1 Types of Glitches

As discussed in an earlier subsection, a glitch caused by coupling from a switching aggressor can propagate through the fanout cell depending upon the fanout cell and glitch attributes such as glitch height and glitch width. This analysis can be based upon DC or AC noise thresholds. The DC noise analysis only examines the glitch magni tude and is conservative whereas the AC noise analysis examines other at tributes such as glitch width and fanout cell output load. Various threshold metrics used in the DC and AC analyses of the glitches are described be low. For a given cell, increasing the output load increases the noise margin since it increases the inertial delay and the width of the glitch that can pass through the cell.

In general, a single stage cell will stop any input glitch which is much narrower than the delay through the cell. This is because with a narrow glitch, the glitch is over before the fanout cell can respond to it. Thus, a very narrow glitch does not have any effect on the cell. Since the output load increases the delay through the cell, increasing the output load has the effect of minimizing the impact of glitch at the input though it has the adverse effect of increasing the cell delay.

The AC threshold (or noise immunity) region depends upon the output load and the glitch width.

What happens if the glitches are larger than the AC threshold? In such a case where the glitch magnitude exceeds the AC threshold, the glitch at the cell input produces another glitch at the output of the cell. The output glitch height and width is a function of input glitch width and height as well as the output load. This information is characterized in the cell library which contains detailed tables or functions for the output glitch magnitude and width as afunctionof the input pin glitch magnitude, glitch width and the load at the output pin. The glitch propagation is governed by propagated_noise models which are included in the library cell description. The propagated_noise (low and high) models are described in detail in Chap ter 3. Based upon the above, the glitch is computed at the output of the fanout cell and the same checks (and glitch propagation to the fanout) are fol lowed at the fanout net and so on.

To summarize, different inputs of a cell have different limits on the glitch threshold which is a function of glitch width and output capacitance. These limits are separate for input high (low transition glitch) and for input low (high transition glitch). The noise analysis examines the peak as well as the width of the glitch and analyzes whether it can be neglected or whether it can propagate to fanouts.

6.2 Noise accumulation with multiple aggressors

For multiple aggressors, the use of timing windows reduces the pessimism in the analysis by considering the switching window during which a net can possibly switch. In addition, another factor to be considered is the func tional correlation between various signals. For example, the scan1 control signals only switch during the scan mode and are steady during functional or mission mode of the design. Thus, the scan control signals cannot cause a glitch on other signals during the functional mode. The scan control sig nals can only be aggressors during the scan mode. In some cases, the test and functional clocks are mutually exclusive such that the test clock is ac tive only during testing when the functional clocks are turned off. In these designs, the logic controlled by test clocks and the logic controlled by func tional clocks create two disjoint sets of aggressors.

6.3 Crosstalk Delta Analysis

The capacitance extraction for a typical net in a nanometer design consists of contributions from many neighboring conductors. Some of these are grounded capacitances while many others are from traces which are part of other signal nets. The grounded as well as inter-signal capacitances are illustrated in Figure 6-1. All of these capacitances are considered as part of the total net capacitance during the basic delay calculation (without con sidering any crosstalk). When the neighboring nets are steady (or not switching), the inter-signal capacitances can be treated as grounded. When a neighboring net is switching, the charging current through the coupling capacitance impacts the timing of the net. The equivalent capacitance seen from a net can be larger or smaller based upon the direction of the aggres sor net switching. This is explained in a simple example below.

Why V(Cc) = 0 both before AND after, when aggressor switches in same direction Again, V(Cc) = V(N1) - V(aggressor) Before the transition

N1 is LOW → V(N1) = 0 Aggressor is also LOW (about to rise) → V(aggressor) = 0 V(Cc) = 0 - 0 = 0 ✓

After the transition

N1 is HIGH → V(N1) = Vdd Aggressor is also HIGH (switched together) → V(aggressor) = Vdd V(Cc) = Vdd - Vdd = 0 ✓

6.3.1 Positive and negative crosstalk

The base delay calculation (without any crosstalk) assumes that the driving cell provides all the necessary charge for rail-to-rail transition of the total capacitance of a net, Ctotal (= Cground + Cc). As described in the previous subsection, the charge required for the coupling capacitance Cc is larger whenthecoupled (aggressor) net and victim net are switching in the oppo site directions. The aggressor switching in the opposite direction increases the amount of charge required from the driving cell of the victim net and increases the delays for the driving cell and the interconnect for the victim net

Similarly, when the coupled (aggressor) net and the victim net are switch ing in the same direction, the charge on Cc remains the same before and af ter the transitions of the victim and aggressor. This reduces the charge required from the driving cell of the victim net. The delays for the driving cell and the interconnect for the victim net are reduced. As described above, concurrent switching of victim and aggressor affects the timing of the victim transition. Depending upon the switching direc tion of the aggressor, the crosstalk delay effect can be positive (slow down the victim transition) or negative (speed up the victim transition).

Most analyses for coupling due to multiple aggressors add the incremental contribution from each aggressor and compute the cumulative effect on the victim. This may appear conservative, however it does indicate the worst case crosstalk delay on the victim.

The crosstalk can affect the delay of the victim, only if the ag gressor can switch at the same time as the victim. This is determined using the timing windows of the aggressor and the victim. the timing windows represent the earliest and the latest switching times during which a net may switch within a clock cycle. If the timing windows of the aggressor and the victim overlap, the crosstalk effect on delay is computed.

Based upon above description, the setup (or max path) analysis assumes that: • Launchclockpathsees positive crosstalk delay so that the data is launched late. • Datapath sees positive crosstalk delay so that it takes longer for the data to reach the destination. • Capture clock path sees negative crosstalk delay so that the data is captured by the capture flip-flop early. Since the launch and capture clock edges for a setup check are different (normally one clock cycle apart), the common clock path (Figure 6-19) can have different crosstalk contributions for the launch and capture clock edg es.

6.3.2 Hold Analysis##

The worst-case hold (or min path) analysis for STA is analogous to the worst-case setup analysis described in the preceding subsection. Based upon the logic shown in Figure 6-19, the worst condition for hold check oc curs when both the launch clock path and the data path have negative crosstalk and the capture clock path has positive crosstalk. The negative crosstalk contributions on launch clock path and data path result in early arrival of the data at the capture flip-flop. In addition, the positive crosstalk on capture clock path results in capture flip-flop being clocked late. There is one important difference between the hold and setup analyses re lated to crosstalk on the common portion of the clock path. The launch and capture clock edge are normally the same edge for the hold analysis. The clock edge through the common clock portion cannot have different cross talk contributions for the launch clock path and the capture clock path. Therefore, the worst-case hold analysis removes the crosstalk contribution from the commonclock path. The worst-case hold (or min path) analysis for STA with crosstalk assumes: • Launch clock (not including the common path) sees negative crosstalk delay so that the data is launched early. • Datapathsees negative crosstalk delay so that it reaches the des tination early. • Capture clock (not including the common path) sees positive crosstalk delay so that the data is captured by the capture flip flop late. As described above, the crosstalk impact on the common portion of the clock tree is not considered for the hold analysis. The positive crosstalk contribution of the launch clock and negative crosstalk contribution of the capture clock are only computed for the non-common portions of the clock tree. In STA reports for hold analysis, the common clock path may show different crosstalk contributions for the launch clock path and the capture clock path. However, the crosstalk contributions from the common clock path are removed as a separate line item labeled as common path pessi mism removal. Examples of common path pessimism removal in STA re ports are provided in Section 10.1. As described in the preceding subsection, the setup analysis concerns two different edges of the clock which may potentially be impacted differently in time. Thus, the common path crosstalk contributions are considered for both the launch and the capture clock paths during setup analysis.

Hierarchical Design and Analysis Hierarchical methodology for verifying a large design was introduced in Section 4.5. A similar approach is also applicable for reducing the complex ity of extraction and analyses. For a large design, it is normally not practical to obtain parasitic extraction in one run. The parasitics for each hierarchical block can be extracted sepa rately. This in turn requires that a hierarchical design methodology be used for the design implementation. This implies that there be no coupling be tween signals inside the hierarchical block and signals outside the block. This can be achieved either with no routing over the block or by adding a shield layer over the block. In addition, signal nets should not be routed close to the boundary of the block and any nets routed close to the bound ary of the block should be shielded. This avoids any coupling with the nets from other blocks.

6.3.3 Noise Avoidance Techniques

The preceding sections described the impact and analysis of crosstalk ef fects. In this section, we describe some noise avoidance techniques which can be utilized in the physical design phase. i. Shielding: This method requires that shield wires are placed on either side of the critical signals. The shields are connected to power or ground rails. The shielding of critical signals ensures that there are no active aggressors for the critical signals since the nearest neighbors in the same metal layer are shield traces at a fixed potential. While there can be some coupling from routes in the different metal layers, most of the coupling capacitances are due to the capacitive coupling in the same layer. Since the immediate metal layers (above and below) would normally be routed orthogonally, the capacitive coupling across layers is minimized. Thus, placing shield wires in the same metal layer ensures that there is minimal coupling for the critical signals. In cases where shielding with ground or power rails is not possible due to routing congestion, signal with low switching activity such as scan control which are fixed during functional mode can be routed as immediate neighbors for the critical signals. These shielding approaches ensure that there is no crosstalk due to ca pacitive coupling of the neighbors. ii. Wire spacing: This reduces the coupling to the neighboring nets. iii. Fast slew rate: A fast slew rate on the net implies that the net is less susceptible to crosstalk and is inherently immune to cross talk effects. iv. Maintain good stable supply: This is important not for crosstalk but for minimizing jitter due to power supply variations. Significant noise can be introduced on the clock signals due to noise on the power supply. Adequate decoupling capacitances should be added to minimize noise on the power supply. v. Guard ring: A guard ring (or double guard ring) in the substrate helps in shielding the critical analog circuitry from digital noise. vi. Deep n-well: This is similar to the above as having deep n-well1 for the analog portions helps prevent noise from coupling to the digital portions. vii. Isolating a block: In a hierarchical design flow, routing halos can be added to the boundary of the blocks; furthermore, isolation buffers could be added to each of the IO of the block.

---

Brief Version of this page

Crosstalk is unintentional coupling between two or more signal nets caused by the coupling capacitance (Cc) between them on the die. The signal being affected is the victim, and the signal causing the disturbance is the aggressor — note a net can be both at once. It shows up in two forms:

Glitch (noise) analysis – when the victim is steady/quiet but a switching aggressor injects a bump on it through Cc. If the glitch is big/wide enough, downstream logic can misread it — especially dangerous on clock, set/reset, or data pins of sequential cells. Crosstalk delta delay – when the victim itself is switching at the same time as the aggressor, altering its effective delay:

Aggressor switches opposite direction to victim → more charge needed → positive crosstalk (slows the victim down) Aggressor switches same direction as victim → less charge needed → negative crosstalk (speeds the victim up)

Whether an aggressor’s switching is even considered depends on whether its timing window overlaps with the victim’s.

Some questions to think about: Fundamentals / mechanism

1. Glitch vs. delta delay — Glitch = noise on a steady victim caused by a switching aggressor (functional/logic-value risk). Delta delay = change in delay on a victim that’s also switching at the same time as the aggressor (timing risk, not logic risk).
2. Can a net be both victim and aggressor? — Yes. Coupling is symmetric through Cc; whether a net is “victim” or “aggressor” in a given analysis just depends on which one you’re currently checking. A single net can be the victim in one check and the aggressor for its neighbor in another.
3. Why worse in deep submicron? — Taller/thinner wires (vertical aspect ratio) → more sidewall area facing neighbors → more Cc relative to Cground. Plus higher routing density (nets closer together) and faster edge rates (more current spike per transition) and lower Vdd (less noise margin to absorb it).
4. Grounded cap vs. coupling cap — Cground goes to a fixed potential, so it doesn’t change with neighbor switching — contributes to a stable baseline delay. Cc is between two signal nets, so its effective value swings depending on whether the aggressor switches with or against the victim, which is what makes delay non-deterministic without crosstalk analysis.

Glitch analysis specifics

1. Four factors — Bigger Cc → bigger glitch. Faster aggressor slew → bigger glitch. Smaller victim grounded cap → bigger glitch (less charge needed to divert it). Weaker victim driver → bigger glitch (can’t fight back against the injected charge as well).
2. DC vs AC noise analysis — DC only checks glitch height/magnitude against a threshold — conservative, ignores width. AC also factors in glitch width and the fanout cell’s output load, since a narrow glitch may not have time to propagate through a cell even if it’s tall.
3. Load increases delay but reduces glitch — which matters more? — Frame it as a genuine tradeoff, not a free lunch: heavier output load slows the victim’s own propagation (bad for setup) but also raises the cell’s inertial delay so narrow glitches get filtered out (good for noise immunity). In practice you don’t blanket-upsize; you use it selectively on cells with margin, or address root cause (spacing/shielding) instead of paying a delay penalty everywhere.
4. Clock/set-reset glitch vs data-net glitch — A glitch on a clock or async set/reset can directly cause a spurious clocking event or spurious reset — irrecoverable, functional failure. A glitch on a random combinational data net is more likely to settle before it reaches a flop, and even if it propagates, it only matters if it arrives at a clock edge.

Delta delay specifics

1. Positive vs negative crosstalk — Aggressor switches opposite direction to victim → driver needs to supply extra charge to flip Cc’s polarity → slower → positive (delay increases). Aggressor switches same direction → Cc’s voltage doesn’t need to change → less charge needed → negative (delay decreases, i.e., speeds up).
2. Why setup assumes positive on data/launch, negative on capture clock — Setup is a “worst-case slow data / worst-case early capture” check. So you assume the worst combination: data arrives as late as possible (positive crosstalk lengthens launch clock path and data path) while the capture clock edge arrives as early as possible (negative crosstalk shortens capture path) — squeezing the setup margin from both sides.
3. Why hold is the opposite — Hold is a “worst-case fast data / worst-case late capture” check — the danger is data arriving too early and getting captured on the wrong edge. So you assume negative crosstalk on launch clock and data path (data arrives early) and positive crosstalk on capture clock (capture edge arrives late) — again squeezing margin, but from the opposite direction because the failure mode is opposite.
4. Why common clock path crosstalk is removed for hold but not setup — For hold, launch and capture use the same clock edge, so the shared/common portion of the clock tree can’t have two different crosstalk contributions — it’s the same physical edge traveling through the same wires. Keeping crosstalk pessimism there would double-count divergence that isn’t real, so it’s backed out as common path pessimism removal (CPPR). For setup, launch and capture are different edges (usually a cycle apart), so even the common portion can legitimately see different crosstalk depending on which edge is transiting it — no double-count, so it stays.
5. Timing windows and crosstalk applicability — Crosstalk delay only matters if aggressor and victim can actually switch at the same time. The timing window (earliest/latest possible switching time in the cycle) for each net is computed; if the aggressor’s and victim’s windows don’t overlap, that aggressor’s contribution is excluded — this avoids pessimistically assuming every neighbor switches simultaneously in the worst possible way.

Multi-aggressor / practical

1. Do you just sum all aggressor contributions? — Yes, most tools do sum incremental contributions from every aggressor whose timing window overlaps the victim — deliberately conservative/pessimistic, because it guarantees you’re covering the worst case even though it’s statistically unlikely all aggressors switch adversely at once. It’s accepted because missing a real crosstalk failure in silicon is far more costly than some margin loss from over-conservatism.
2. Functional correlation reducing pessimism — Example: scan control signals only toggle in scan/test mode and are static during functional mode — so they can’t be aggressors during functional-mode timing analysis, only during scan-mode analysis. Similarly, if test and functional clocks are mutually exclusive (one is off when the other’s active), their fanout logic forms two disjoint aggressor sets that never apply simultaneously — cutting down the aggressor list you need to consider per mode.

Physical design / avoidance techniques

1. Avoidance techniques at layout — Shielding (ground/power wires flanking critical signals), wire spacing (physically separate to reduce Cc), fast slew rate on the driver (less time-sensitive to injected charge), stable/well-decoupled supply (reduces coupled jitter, especially on clocks), guard rings and deep n-well (isolate sensitive analog from digital switching noise), and routing halos/isolation buffers at hierarchical block boundaries.
2. Why shields mainly guard against same-layer neighbors — Most coupling capacitance comes from sidewall-to-sidewall coupling within the same metal layer, since adjacent layers are typically routed orthogonally (perpendicular), which minimizes overlap area and therefore cross-layer Cc. So a shield wire on either side, same layer, at a fixed potential removes the dominant coupling path.
3. Preventing cross-boundary coupling in hierarchical extraction — No routing directly over the block (or add a shield layer over it), keep signal nets away from the block boundary, and shield any nets that must route close to the boundary — this ensures each block’s parasitics can be extracted independently without needing visibility into neighboring blocks’ switching activity.
4. Spacing vs shielding under congestion — Shielding costs dedicated tracks (power/ground wires) which is expensive under congestion; wire spacing is “free” in the sense of not consuming extra tracks but costs area/routing resources indirectly by not allowing dense packing. When shielding isn’t feasible due to congestion, a fallback is routing low-activity signals (like scan control, since they’re static in functional mode) as the immediate neighbor instead of a fully shielded rail — gets most of the benefit without dedicating power/ground tracks.

Judgment / experience-based For these three, outline your own story with this shape rather than a canned answer:

1. Debugging a real crosstalk issue: (1) what symptom you saw (timing violation appearing only post-route/post-extraction, not in pre-route estimates; or a functional failure traced to a glitch), (2) how you distinguished it from OCV/derate or plain RC delay issues — usually by checking if the delay/glitch correlated with a specific neighboring net’s switching activity in the report, (3) the fix you chose and why (spacing vs shielding vs re-route) balancing congestion/area cost.
2. Prioritizing which nets to shield: rank by criticality — clock nets and async set/reset first, then high-fanout/long data nets on timing-critical paths, then use switching-activity/correlation data to deprioritize nets that can’t realistically align in time.
3. Crosstalk vs OCV/AOCV double-counting: acknowledge it’s a legitimate concern — both add pessimism on top of nominal delay — but note tools typically apply them as separate, additive derates rather than compounding multiplicatively, and mention that some flows apply correlation/statistical (SSTA/AOCV) techniques specifically to reduce this stacked pessimism rather than dropping either check.
4. Read about if xtalk will be credited back if it exists in common clock path?

TO CHECK

1. Generally what do we shield with VSS or VDD and why?