Double switching analysis

SI coupling effect can be introduced by

- crosstalk delay shift when both victims and aggressors are switching. This induces on
the victim speed up or slow down effect depending on the respective direction victim and
aggressors are switching. In PrimeTime SI this is analyzed by update_timing and
reported for example by report_timing -crosstalk.
- noise effect when the victim is static (logic 1 or logic 0). When the aggressor is
switching this induces a noise glitch above low (rising) or below high (falling). In
PrimeTime SI this is analyzed by update_noise and reported for example by
report_noise.
- if the victim is transitioning very slowly. It can happen the aggressor produces such a
bump on the victim that we have a double switching: the waveform crosses twice the
delay threshold. This may not be flagged by update_noise as the victim is not static.
Also users want to be warned as if this happen in the clock tree for example it can be
really destructive for the data as you may have false clocking if this happens on the
inactive of the clock or double clocking if this happens on the active edge of the clock.

CLK
CLK

False clocking on inactive Double clocking on

edge active edge
This analysis is made possible in PTSI if the libraries are having CCS noise models for
the cells: PrimeTime SI detects these potential double switching situations. Of course this
phenomenon can get attenuated along the fanout of the cells.
User has to set variable si_xtalk_double_switching_mode prior to
update_timing. It can take 3 different values:
-disabled (default): that analysis is not going to be performed
-full_design: that analysis is going to be performed for every single net of the design.
-clock_network: that analysis is going to be performed for nets belonging to clock tree.
It is indeed recommended to use this last analysis, as this double switching phenomenon
can destroy data only when occurring on the clock tree. It is secure to fix double
switching violations on the clock tree, so a signal integrity ECO flow will use this
analysis as well as Crosstalk Delay violations and noise violations.

After update_timing user can get access to this double switching information either
thanks to command report_si_double_switching or by accessing net attributes
si_has_double_switching and si_double_switching_slack.

Ex:
 Aggressor
d1

d2

Victim

report_si_double_switching -fall d2
****************************************
Report : si_double_switching
d2_P0 -fall
…
****************************************

Victim Switching Actual Required Double Switching

Net Direction Bump Height Bump Height Slack
~~~~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~
d2 max_fall 0.873576 0.469430 -0.404146 (VIOLATING)
d2 min_fall 0.949958 0.615177 -0.334781 (VIOLATING)

this report is the list of violations, i.e. the list of the victim nets of the design that are
double crossing delay threshold while falling in that example. The victim transitions are
usually slow if user looks at report_timing -trans on the victim net.
The actual bump height cannot be really correlated with a spice simulation as the signal is
transitioning but is a function of victim and aggressor's drivers slope and strength, of the
victim and aggressor network including cross capacitance and victim and aggressor's load
cells.
This report displays also the required bump height, what would be the maximum bump
height that would be safe and not produce a double switching. Of course the slack is the
difference between the required bump height and the actual bump height, and a violation
is displayed when this slack is getting negative.
The net attributes si_has_double_switching and
si_double_switching_slack reflect the same and can be used for ECO scripting.

In that example for net d2 we have 2 violations, in max_fall and min_fall.

Max_fall is the case where the victim is falling and the aggressor is rising.
By creating a spice simulation on that circuit we get these waveforms:
 Output of victim load:
double switching

Victim

Aggressor

Min_fall is the case where the victim is falling and the aggressor is falling as well:

Having min switching violation is very rare but it can happen. It is the boundary of
crosstalk delay & noise. If the bump is very very sharp on a very slow transition victim,
the victim waveform becomes non-linear. That gets amplified by a strong receiver cell..
In that case on the same net report_noise flags violations as well. Of course the
probability is high that double switching violations are also flagged as noise violations.
But it may happen that these bumps are only harmful when the victim is transitioning and
in that case you may have violations in double switching but not in noise analysis.

noise_region: above_low
pin name (net name) width height slack
-----------------------------------------------------
bufb_reg1a/I (d2) 0.790714 0.804138 -0.231469

noise_region: below_high
pin name (net name) width height slack
-----------------------------------------------------
bufb_reg1a/I (d2) 1.195714 0.860561 -0.394644
By creating a spice simulation on that circuit we get these waveforms:

Output of victim load:

double switching

Victim

Aggressor

In conclusion report_si_double_switching can save you a lot of simulation

time by flagging this double crossing situations that can be potentially ignored by noise
analysis. This should be used as a driver for an ECO flow all together with timing
analysis and noise analysis.
For that feature libraries with CCS noise models are needed.