10. Crosstalk Analysis

10. 1. Requirements

Crosstalk Analysis is done after the UTD construction performed with the hitas function. Only the detailed timing information file of the database is needed (DTX file), together with the interconnect information (RCX file) and the delay models (STM file).

The Crosstalk Analysis is coupled with the Static Timing Analysis, and is therefore performed with the same function stb. The inputs needed for crosstalk analysis are the same as the input needed for STA.

10. 2. Understanding Crosstalk in STA

10. 2. 1. The Issues Involved

A coupling capacitance is a capacitance between two nets. Let us consider a signal carried by a net, which we shall call the victim. All other signals carried by nets linked to the victim via a coupling capacitance are called aggressors. A signal is considered to be 'quiet' when no transitions occur on it, and 'active' whenever transitions occur. We define 'quiet' or 'active' to be the state of the aggressor.

The influence of a coupling capacitance depends upon the state of victim and the state of the aggressor. From the point of view of the victim four cases exist:

In the last case, there are two different effects depending on victim and aggressor transitions:

10. 2. 2. Algorithm

In order to compute the effect of a coupling capacitance, we need to know whether two signals can switch at the same time, and if they switch in same or opposite direction. The detailed Static Timing Analysis gives switching windows for all the edges (reference points and others) of a timing graph. Given a victim and its set of aggressors, it is therefore possible to determine switching window overlaps, and to detect aggressions inducing noise and delta-delays on the victim.

This approach requires that initial detailed switching windows propagation is performed from initial delay values without any knowledge of aggressor behavior. Two options are possible:

It is then possible to compute initial values for driver delays and interconnect delays, and perform an initial switching windows propagation. For each victim, the algorithm creates its effective list of aggressors, by analyzing the overlap of the switching windows of its aggressors.

Depending on the chosen initial state, the list of aggressors will either increase or decrease. In both cases, the effective coupling capacitance seen by the victim will change, inducing a re-evaluation of the driver delay and interconnect delay of each victim. Another STA (switching window propagation) is performed with these updated delays. If this second propagation induces no change in the aggressor lists, the algorithm finishes. If this is not the case, further iterations are performed until the algorithm converges.

To render crosstalk analysis less pessimistic, it is possible to refine the modeling of the effect of an aggression. In many cases, an aggression only changes the driver delay of the victim over a short time, switching windows not being significantly affected (victim's earliest and latest switches not being affected). This kind of aggression can then be considered as a non-observable aggression.

Ignoring non-observable aggression results in less pessimistic results, in regard of the setup and hold violations, only affected by the earliest and latest switches. The user can choose to enable analysis with only observable aggression with the stbCtkObservab1leModevariable.

On the other hand, it might be usefull to consider very close - but non overlapping - switching windows as overlapping, as shown in the following example:

The M value is controlled by the variable stbCtkMargin.

10. 2. 3. Delay Calculation

The main factor in computing crosstalk-aware delays is the proper modeling of the effective capacitance. In HITAS, the effective capacitance is computed by an enhanced Miller model, taking into account the relative strengthes of the drivers (actually the slopes at their outputs). The tool computes a crosstalk-aware delay by feeding this updated capacitance to the timing model of a driver.

In order to reduce computational time, HITAS makes the following assumptions:

The figure below illustrates those assumptions:

The most accurate delay calculation is done with the following configuration:

avt_config rcxCtkSlopeDelay SLOPE_DELAY_ENHANCED

10. 2. 4. Noise Calculation

The figure below illustrates those assumptions:

HITAS computes voltage peaks on each net, by modeling the coupled network as illustrated in the figure below:

The assumptions made are:

The most accurate noise analysis is done with the following configuration:

avt_config rcxCtkSlopeNoise SLOPE_REAL

10. 3. Running the Crosstalk Analysis

Relevant configuration:

stbCrosstalkMode Activates the crosstalk analyzer within the STA engine. Aggressions are detected according the switching windows intersections. Multiple iterations are automatically performed until no more aggression is detected. This variable should be set to yes.
stbDetailedGraph Aggressor detection has a meaning only on a detailed graph, (and not on a path graph). This variable should be set to yes.
stbDetailedAnalysis Tunes the building of switching windows either to single or multiple windows per period. Less pessimistic results are obtained with multiple switching windows. It is better to set this variable to yes, but it requires more memory.
stbCtkNoInfoActif If the aggressor is not a timing signal (eg: internal signal in a gate), there is no timing information for it. If this variable is set to yes, then this aggressor is considered to be always active, else it is considered to be always quiet. It is better to set this variable to yes (default).
stbCtkReportFile Activates the generation of the report file (.ctk). Since Tcl functions provide an efficient way to browse crosstalk results, and considering the size of this file, this variable is better set to no (default).

The crosstalk analysis is done with the stb Tcl command, based on a previously generated timing DB. The timing DB may come from the hitas Tcl command:

set fig [hitas my_design]
 
avt_config stbCrosstalkMode yes
avt_config stbDetailedGraph yes
avt_config stbDetailedAnalysis yes
 
stb $fig

The timing DB may also come from disk, loaded with the ttv_LoadSpecifiedTimingFigure command:

set fig [ttv_LoadSpecifiedTimingFigure my_design]
 
avt_config stbCrosstalkMode yes
avt_config stbDetailedGraph yes
avt_config stbDetailedAnalysis yes
 
stb $fig

10. 4. Output Files

Since HITAS crosstalk engine is coupled with the STA engine, it generates the same output files (STO and STR files). In addition, the crosstalk engine creates two or three extra files. The first one contains details of all crosstalk adjusted delays throughout the design hierarchy. This file .ctx is intended to be browsed using Xtas or the functions of the Tcl interface. The second file (.agr) contains the list of all nodes with the states of their aggressor. This file is intended to realize the report of crosstalk analysis with the Tcl interface. The third file is a human readable file (.ctk file) which contains all crosstalk related information. This file is drived if the stbCtkReportFile is set

The CTX file is an ASCII text file containing all the delays calculated with crosstalk effects of a complete design hierarchy. This file is associated with all of the original files describing the hierarchy (DTX, STM and RCX). It is intended to be viewed using the timing browser Xtas. This file contains top level delays and instance delays.

10. 5. Browsing Crosstalk Analysis Results

10. 5. 1. Crosstalk Impact on Delays

After the run of the stb Tcl command, the timing DB contains nominal propagation delays and crosstalk-aware propagation delays. Therefore, when based upon a crosstalk-annotated timing DB, browsing commands such as ttv_GetPaths show crosstalk impact on propagation delays:

set fig [ttv_LoadSpecifiedTimingFigure my_design]
avt_config stbCrosstalkMode yes
stb $fig
set clist [ttv_GetPaths $fig * * uu 5 critic path max]

This stb command (the crosstalk analysis) generates the .ctx file for crosstalk impact on delay, suitable for further browsing, in order to dissociate crosstalk analysis and browsing. As crosstalk analysis may be cpu consuming, this will save time. It is then possible to browse crosstalk-annotated timing DBs generated from previous crosstalk analysis runs:

set fig [ttv_LoadSpecifiedTimingFigure my_design]
ttv_LoadCrosstalkFile $fig
set clist [ttv_GetPaths $fig * * uu 5 critic path max]

10. 5. 2. Crosstalk Noise

HITAS provides a set of Tcl functions for crosstalk noise analysis. Those functions work on the crosstalk database generated with the stb function. If the stb function has been launched in the current Tcl script, the crosstalk database is available in memory, and the Tcl noise analysis functions can be used directly:

set fig [ttv_LoadSpecifiedTimingFigure my_design]
avt_config stbCrosstalkMode yes
set stbfig [stb $fig]
ctk_DriveStatCtk $stbfig 

If the stb function has been launched in a separate script, then the crosstalk database (.ctx, .sto and .agr files) must be loaded from disk before using noise analysis functions:

set fig [ttv_LoadSpecifiedTimingFigure my_design]
ttv_LoadCrosstalkFile $fig
set stbfig [stb_LoadSwitchingWindows $fig my_design.sto]
ctk_LoadAggressionFile $stbfig
 
ctk_BuildCtkStat $stbfig 
ctk_DriveStatCtk $stbfig 

The ctk_BuildCtkStat function is used to re-built consistent information from the crosstalk database files, according to the scoring configuration variables (see later in this chapter).

10. 5. 3. Browsing Information on Event

For noise and score, the Timing Event stores informations corresponding to the initial state of this transition : the up event correspond to the low logical level, and the down event correspond to the high logical level.

Crosstalk information on nodes are stored in an internaly table. This table can be sorted with the command ctk_SortCtkStatNode. Information are available through the command ctk_GetStatNodeProperty. The index parameter is the position in the internal table, from 1 to the value returned by the command ctk_GetNumberOfCtkStatNode. To get the position of a particular event, uses command ctk_GetCtkStatNodeFromEvent.

10. 5. 4. Browsing Local Crosstalk Impact on Delay

This information allow to know the elementary delays the most modified by crosstalk effect due to two net switching simultaneously. This information is stored in an internale table. This table can be sorted with the tcl command ctk_SortCtkStatLine. Information on delays are available with the tcl command ctk_GetStatLineProperty. The index parameter is a number from 1 to the value returned by the command ctk_GetNumberOfCtkStatLine.

10. 5. 5. Browsing Aggressor

The aggressor list of a Timing Event is available through the tcl command ctk_GetAggressorList. Property for an aggressor in this list are available with the tcl command ctk_GetAggressorProperty. This list must be freed with the tcl command ctk_FreeAggressorList.

The property SIGNAL return the Timing Signal corresponding to the aggressor. If the aggressor is an internal net of a gate, there is no Timing Signal built on it, then the property SIGNAL return NULL.

10. 6. Score-Based Result Analysis

Signals presenting a risk of noise violation are sorted by a score based method. Four scores, ranging from 0 to 10, are reported. Scores assess both the crosstalk impact and the aggression occurrence probability. Scores are reported in the output files, and in the slack and path reports, under the following tags:

C Number of significant aggressors; the closer to 10 is the score, the more significant part of crosstalk is due to a few number of aggressors.
N Noise peak value; 0 means that the noise peak reaches or exceeds the logical threshold of at least one gate in the fanout.
I Switching windows criteria; based upon number of aggressors simultaneously active
A Activity of the aggressor; 10 means that aggressors belong to a clock path, or belong to another clock domain (and assumed to be always active); 0 means that nothing can be gathered about activity, it doesn't mean that aggressors are not active.

A total weighted score is also reported, under the T tag, combining the individual scores. The individual weighting of the C, N, I and A scores can be tuned with the variables stbCtkCoefCtk, stbCtkCoefNoise, stbCtkCoefInterval and stbCtkCoefActivity, respectively.

If a signal obtains a mark lower than the value specified in stbCtkMinNoise, stbCtkMinInterval, stbCtkMinCtk or stbCtkMinActivity, it is not displayed in the report file.