Electromagnetic (EM) Crosstalk Analysis: Unlocking the Mystery

Ignoring electromagnetic crosstalk is highly risky and can cause significant time-to-market delays as well significant cost over runs. Most current SoC design flows fundamentally ignore inductance and EM effects, and the term “EM crosstalk analysis” may sound Greek to them. This short article provides a quick overview of the basic steps involved in doing EM crosstalk analysis as part of an SoC design flow.

There are four basic steps involved in doing EM crosstalk analysis, as shown in Figure 1.

Figure 1: Basic Steps of EM Crosstalk Analysis

1. Victim/Aggressor Net Selection: In a typical SoC, there are many victim/aggressor pairs that could be analyzed. Analyzing all possibilities may not be feasible due to the resources required. Ideally, one should assess the victim/aggressor pairs to identify the ones that most likely exhibit EM crosstalk, so that they can be analyzed first.

2. The Formation of a Design Partition: Given a selected victim and aggressor(s), the next step is to decide what design elements to include in the partition that will be analyzed for EM crosstalk. On one extreme, the entire chip design is too large to analyze in full, but at the same time we must include all design features that may contribute to EM crosstalk. Most EM crosstalk tools available on the market have capacity limitations, and these limitations can result in the exclusion of certain design features that might be crucial to the final result. As we discussed earlier, proximity rules don’t apply too well to EM crosstalk analysis as magnetic fields can travel along relatively long loops. Typically, the design partition to be analyzed crosses several design hierarchies, and may include all kinds of structures such as the power and ground nets, package layers, the substrate, coupling caps, fill metal, seal rings, etc.

3. Extraction and Model Generation: In this important step, an accurate extraction is performed on the design partition of step 2 to calculate the resistance, coupling capacitance, inductance, and mutual inductance for all nets, metal structures, etc. The goal is to generate a full and accurate EM model of that design partition. That model can take several forms such as S-parameter model, state-space matrices, rationally fitted model, or a full RLCK model. The latter is preferred to support Spice simulation in the next steps. When extracting a signal net, or a portion of a metal layer, it is usually necessary to break that into multiple segments to be able to accurately extract each of these segments. Calculating the capacitance, for example, of one of these segments may require very smart meshing to capture curve effects created by the imperfections of advanced technology manufacturing. Hence, the extraction engine must be aware of very complex layout effect rules. Without that level of accuracy, the results of crosstalk analysis will not be accurate. Given the size of typical design partitions and all the features that it contains, this places substantial pressure on the extraction engine to handle this capacity and keep the run time reasonable without sacrificing any accuracy. Moreover, the size of the model generated must be compact, otherwise subsequent simulation steps becomes impossible. Balancing capacity, speed, accuracy and model-manageability is extremely important to successfully deal with this complex task.

4. Back Annotation and Simulation: In this step, the EM RLCK model is back annotated into the design database. Obviously, it is important that the EM tool work seamlessly with other EDA tools used by the SoC design team, such as their DRC tool, LVS tool, other extraction tools, etc. Last but not least, Spice simulation is performed to observe the impact of crosstalk on the victim signal, or to observe the impact on one of the system performance metrics, such as bit error rate, clock jitter, etc. A key requirement of this step is the availability of a test-bench to drive the simulation.

Post-Silicon Debug: In some unfortunate cases, EM crosstalk analysis is required post-silicon to diagnose and debug some unexpected silicon measurement. Under these circumstances, the block diagram of Figure 2 illustrates the steps involved.

Figure 2: Using EM Crosstalk Analysis to Debug Silicon Issues

Even though there is an unexpected observed silicon measurement mismatch, postulating a cause can be very difficult. Determining who is the aggressor or aggressors may not be straightforward. Also, the victim itself may not be obvious because the observed measurement is usually a system performance measurement without a clear indication to what may have caused it. Hence the loop of postulating different causes and analyzing them one by one to get a match between the simulation results and the silicon measurements.

Of course, there might not be a single cause for the problem, which might complicate the debugging process. This flow relies on the expertise of the users and it is iterative in nature. The causes considered are limited by what can be analyzed by the EM crosstalk analysis tools. Many of the commercially available tools are limited in their ability to extract and model a large design area with all the surrounding layout structures. Not modeling certain structures may lead to erroneous results hiding the real crosstalk effects. There is no guarantee that a “limited and handicapped” iterative process could lead to a real diagnosis of the actual problem. This can obviously lead to delays in getting the product to market and excessive cost over-runs.

With time at an extreme premium during these debug situations, the ability of the EM crosstalk tool to handle larger design chunks and to model all the design artifacts can accelerate the identification of the real channels of interference. This can quickly lead to a fix and avoiding costly silicon revs that don’t fix the real issue. This is not only valuable, it is priceless and life-saver!