print

Crosstalk Analysis and Its Impact on Timing in 7nm Technology

Thumbnail

By Vimal Gohel, Maitreyee Patel and Arpita Rupareliya, einfochips

As we dive deep into lower technology nodes in IC (integrated circuit) design, we always see a downscale of design compared to previous technology nodes. With every shrinkage in technology nodes, it tends to downscale multiple things like the width of metal wires along with transistor size. Therefore, RC (Resistive-capacitive) delays are much more severe in 7nm technology nodes. 7nm designs are denser in terms of routing resources than previous nodes. Hence, Crosstalk Delay and Crosstalk Noise play a significant role when we refer to timing in 7nm.

In this article, we will discuss the crosstalk effect and analysis for universal routing topology, used in chip design, based on the experiment conducted by eInfochips’ engineers. We will consider a few variables like metal layers, drive strength of buffer, length, and spacing of wires, etc. In addition, we will have a basic idea of how to take care of crosstalk in the early stages of the design cycle by analyzing the results from the experiment.

What is Crosstalk?

Crosstalk refers to undesired or unintentional effects, which can cause functional failure in the chips. This functional failure refers to either change in the value of the signal voltage or change in timing.

There are two types of noise effects, namely,

  1. Crosstalk Glitch: This refers to noise/glitch caused on a steady victim signal due to the coupling of switching activity of the neighboring aggressors.
  2. Crosstalk Delay: This is due to the coupling between the switching activity of the victim and the switching activity of the aggressors, which results in the change of timing on a particular victim signals.

Let’s discuss them in detail:

Crosstalk Glitch Analysis

A steady signal net can have a glitch due to the charge transferred by the switching aggressors through coupling capacitances. The glitch magnitude may be large enough to be seen as a different logic value by the fan-out cells of the victim nets.

For example, as shown in Figure 1, when the output of “UNAND0” is switching from 0->1, it can introduce a glitch in the victim net due to the cross-coupling capacitance. This glitch can change the input value of “UNAND1”, which results in undesired output values (Logic-0 may appear as Logic-1 and vice-versa). Here, victim net is connected from “INV2” to “UNAND1”.

Figure 1. Glitch due to an aggressor

Crosstalk glitch can be classified as below:   

  • Rise and Fall Glitches
    • Rise glitch: Raising aggressor net induces a rise glitch on a steady low
    • Fall glitch: Falling aggressor net induces a fall glitch on a steady high
  • Overshoot and Undershoot Glitches
    • Overshoot glitch: Raising aggressor net induces overshoot glitch on a steady high This takes the victim net voltage above its steady high value.
    • Undershoot glitch: Falling aggressor net induces an undershoot glitch on a steady low This takes the victim net voltage below its steady low value.

Types of crosstalk glitches are as shown in Figure 2.

Figure 2. Types of glitches

Crosstalk Delay Analysis:

Crosstalk delay is the same as crosstalk noise, however, the only difference is that the nets are not at steady state values and there are some switching activities happening on both victim and aggressor nets. Crosstalk delay depends on the propagating direction of aggressor and victim nets. This results in either slower transition or faster transition of victim nets.

This can be classified as below:

  • Negative crosstalk delay

If the aggressor and victim nets are switching in the same direction, it results in a smaller delay for the victim net. The reduction in delay is known as a negative crosstalk delay. This is shown as below in Figure 3.

Figure 3. Negative crosstalk delay

  • Positive crosstalk delay

If the aggressor net is switching in the opposite direction of the victim net, it results in a larger delay for the victim net. The increase in delay is known as a positive crosstalk delay. This is shown below in Figure 4.

Figure 4. Positive crosstalk delay

Workflow

Below Figure 5 shows a basic flow diagram of the workflow. The workflow can be divided into below steps.

  • Perform PnR (IO/Port planning, placement, routing, and shielding)
  • RC extraction in spef/spice format in each metal layer
  • Simulation in HSpice using above spef/spice and verify delay and transition values

Figure 5. Flow chart

Experiments to Calculate Delay

The primary goal is to perform multiple experiments using 7nm TSMC library. The experiment includes multiple input ports, output ports, and buffers. There are a few variables in this experiment like the drive strength of the buffer, spacing between metal layers and length of metal layers.

As shown in Figure 6, input port IN1 is connected to the input pin of BUF_1_1, the output pin of BUF_1_1 is connected to the input pin of BUF_1_2 and output pin of BUF_1_2 is connected to the output port OUT1. There are three nets running in parallel to each other. Here, upper and lower nets are considered as aggressor nets and the middle net is considered as the victim net. Total Net length (X) from BUF_1_1 to BUF_1_2 and BUF_1_2 to output port OUT1 is similar. Similarly, spacing (S) between these three nets is same.

Figure 6. Basic layout. Where,
BUF = x6, x8, x12, x14 buffer
S = Spacing between two metal
X = length driven by one buffer

 

We have conducted multiple experiments considering all the variables as mentioned i.n Table 1. Drive strength of both buffers is the same for each experiment.

Table 1

A detailed implementation of the experiment is as follows:

 [A] PNR (IO/Port planning, placement, routing, and shielding) 

We had the complete IO planning, considering SPACING as a variable parameter. We defined multiple values for spacing like Min-Space, 1trackSkip, 1.5trackSkip, 2trackSkip. This is shown in Figure 7.

Figure 7. Port placement and custom net routing

Here, the middle net is the victim net affected by upper and lower aggressor nets.

We completed buffer placement considering LENGTH as a variable parameter. We defined multiple values of length based on the metal layer used. For example, net-length values are 150um, 200um, 300um, 400um for metal layer-10. This is shown in Figure 8.

Figure 8. Buffer placement

We did custom/manual straight wire routing for all the connections. We allowed the tool to use via-pillars for connections to/from buffers. It used all vias to connect pins of buffers as shown in Figure 9.

Figure 9. Pin connection

We also did shielding of Power/Ground in lower and upper metal layers. The main purpose of shielding is to see the coupling cap effect over timing and transition values.

For example, as shown in Figure 10, if Mx is a metal layer used for experiment then, Mx+1 and Mx-1 are used for shield wires.

Figure 10. Shields

[B] RC extraction in spef/spice format in each metal layer

After doing the Place and Route process, we did extraction in Star-RC to analyze parasitic capacitance and resistance values in design. We need DEF (Design Exchange Format), LEF (Library Exchange Format), mapping file, corners files as inputs and SPF (Standard parasitic format) file comes as output after extraction.

Here, RC values of victim net (middle net) are directly affected due to the coupling cap of the aggressors (upper and lower nets).

The main content of the file is resistance and capacitance values for each defined node for one particular NET.

For example, RC values for each node are defined for net “net_gr0_buf_in_min_[0]” as shown below:

*|NET net_gr0_buf_in_min_[0] 0.00753977PF

*|I (cell_gr0_U0_1:I cell_gr0_U0_1 I I 0 42.978 7.22)

*|P (net_gr0_buf_in_min_[0] I 0 0.375 7.68)

*|S (net_gr0_buf_in_min_[0]:3 42.172 7.28)

*|S (net_gr0_buf_in_min_[0]:4 42.256 7.196)

*|S (net_gr0_buf_in_min_[0]:5 10.3 7.68)

Cg1_1 cell_gr0_U0_1:I 0 7.4519e-18

Cg1_2 net_gr0_buf_in_min_[0] 0 8.16756e-16

Cg1_3 net_gr0_buf_in_min_[0]:3 0 2.87167e-17

Cg1_4 net_gr0_buf_in_min_[0]:4 0 4.19668e-17

Cg1_5 net_gr0_buf_in_min_[0]:5 0 3.93516e-16

R1_1 cell_gr0_U0_1:I net_gr0_buf_in_min_[0]:20 0.981026 $l=0.04 $w=0.037 $lvl=37 $m=1

R1_2 net_gr0_buf_in_min_[0] net_gr0_buf_in_min_[0]:5 77.5233 $l=9.925 $w=0.04 $lvl=8

R1_3 net_gr0_buf_in_min_[0] net_gr0_buf_in_min_[0]:25 2.93353 $l=0.375 $w=0.04 $lvl=8

R1_4 net_gr0_buf_in_min_[0]:3 net_gr0_buf_in_min_[0]:15 0.864125 $l=0.084 $w=0.04 $lvl=6

R1_5 net_gr0_buf_in_min_[0]:4 net_gr0_buf_in_min_[0]:14 0.691175 $l=0.084 $w=0.038 $lvl=7

*

* Instance Section

*

Xcell_gr0_U0_1 cell_gr0_U0_1:I cell_gr0_U0_1:Z VDD VSS VDD VSS BUFFD8BWP240H8P57PDLVT

Xcell_gr0_U0_2 cell_gr0_U0_2:I cell_gr0_U0_2:Z VDD VSS VDD VSS BUFFD8BWP240H8P57PDLVT

Xcell_gr0_U12_1 cell_gr0_U12_1:I cell_gr0_U12_1:Z VDD VSS VDD VSS BUFFD8BWP240H8P57PDLVT

Xcell_gr0_U12_2 cell_gr0_U12_2:I cell_gr0_U12_2:Z VDD VSS VDD VSS BUFFD8BWP240H8P57PDLVT

[C] Simulations in HSpice using above spef/spice and verify delay and transition values

Once we have the SPF file with all parasitic values, we ran HSPICE simulations to see a real delay and transition timing numbers after having a crosstalk impact on victim nets due to both the aggressors.

For example, as shown in Figure 11,

Victim is switching 1 -> 0 and aggressors are switching 0 -> 1.

Figure 11. Simulation waveform for victim net

The Upper waveform is with Min-Space spacing for the first buffer on victim net and Lower waveform is with Min-Space spacing for the second buffer on victim net. GREEN and BLUE waveform signals are at input pins of BUF. YELLOW and RED waveform signals are at OUTPUT pins of BUF.

We can see the distortion introduced in the victim signal. This is caused due to the positive crosstalk delay effect on victim nets due to upper and lower aggressors. The magnitude depends on the values if multiple variables like SPACING, LENGTH, and BUFFER DRIVE STRENGTH.

Table 2

Conclusion

When we work in lower technology nodes like 7nm and below, we see a huge impact of crosstalk delay and crosstalk noise. This will lead to critical timing and noise/glitch violations in the tape-out mode. If this crosstalk is on a clock signal, it will be even more critical to fix timing violations immediately since changing of routing for clock can lead to more timing violations later.

Therefore, we need to address crosstalk in the early stage for 7nm and below technology nodes, based on the lesson learned in the above experiment. Table 2 is the most suitable guidelines for crosstalk fixing in the early stage. Also, Table-2 shows the timing results of each experiment. We can easily get an idea of timing numbers for various cases like a different length of routing wire, a different spacing of routing wire, and a different metal layer by looking at Table 2. We tried to cover all the possible vectors/variables, which are the common routing topology used in back-end chip design work.

Thus, one can find out all possible timing violation numbers at the early phase of design due to crosstalk. We do not need to wait for the signoff tool to report such critical timing violations. Instead, we can use timing numbers from Table 2 as a reference point and target to fix those violations in the early stage of chip design.

 References

[1] https://solvnet.synopsys.com/dow_retrieve/O-2018.09/hspice/hspice_olh/hspice2/baggage/hspice_sa.pdf?otSearchResultSrc=advSearch&otSearchResultNumber=1&otPageNum=1

[2] https://solvnet.synopsys.com/dow_retrieve/O-2018.09/dg/starolh/Default.htm#stug/about.htm?otSearchResultSrc=advSearch&otSearchResultNumber=2&otPageNum=1

[3] Static Timing Analysis for Nanometer Designs by J. Bhasker Rakesh Chadha, Rakesh Chadha, Springer Science-Business Media

 About the Authors

Vimal Gohel is working with eInfochips as a senior physical design engineer for more than three years. He has more than seven years of experience in the semiconductor industry and has successfully taped out multiple projects in 16nm, 28nm, 40nm technologies.

Maitreyee Patel is working as a physical design engineer at eInfochips. She has more than two years of experience in the semiconductor industry. She has done Master of Technology (MTech) in Electronics and Communication (Digital Communication).

Arpita Rupareliya is working as a physical design engineer at eInfochips. Arpita holds an experience of more than two years in the semiconductor industry. She has done Bachelor of Engineering (BE) in Electronics and Communication.

 

 

 

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags:

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.