Fwd: 68-95-99.7 rule - Wikipedia, the free encyclopedia

Helen, Jeffrey and Stephane

408-896-8810

---------- Forwarded message ----------
From: Jeffrey CUI <huijun.cui@gmail.com>
Date: Thu, Oct 28, 2010 at 4:48 PM
Subject: 68-95-99.7 rule - Wikipedia, the free encyclopedia
To: Jeffrey CUI <huijun.cui@gmail.com>

1 sigma

2 sigma

3 sigma distribution

http://en.wikipedia.org/wiki/68-95-99.7_rule

Clock reconvergence pessimism removal (CRPR) 2

CRPR: is to remove the unnecessary pessimism for the common clock path for the launching and receiving registers.

The removal portion or the credit is the difference between max delay and min delay of the common portion.

There is a command called : report_crpr which could give the exact crp value. Calculate crpr is quite expensive, so report_timing won't give you the exact cpr value. The value given by the report_timing is the exact value +/- the range of "timing_crpr_threshold_ps".  That is the reason that you could see different crp value between report_crpr and report_timing.

To deal with the above issue, synopsys create another variable "timing_crpr_enable_adaptive_engine" to handle, when this variable is set to true, only the path with violation will be recalculate cpr, so the cpr will be accurate.

Clock reconvergence pessimism removal (CRPR)

Clock reconvergence pessimism removal (CRPR)


In the adaptive CRPR mode, PrimeTime SI calculates CRPR only for the critical path set
(the violating portion of the design), thereby reducing the complexity of CRPR analysis. The
critical path set is the set of all paths with a slack of less than zero, for both setup and hold
timing constraints. The adaptive mode operates only when crosstalk analysis is enabled and
the maximum iteration count is set to 2 or more.


Typically, more nets are reselected for analysis in the second iteration using adaptive CRPR
because no CRPR is done in the first iteration. The resulting analysis is more accurate (less
pessimistic) because more nets are reselected for analysis.



report_timing and report_crpr

CRPR, or clock reconvergence pessimism removal, accounts for the difference in min/max delay of the portion of the clock network that is common to both the launch and the capture paths. For a path, it finds the common pin where the clock paths diverge, computes the difference between the min/max arrival times (the "CRP" value), and applies this as a credit to the path slack.

pt_shell> report_app_var *crpr*
Variable                             Value Type Default    Constraints
----------------------- --------- ------- ---------- -----------------------
timing_crpr_enable_adaptive_engine   false bool false
timing_crpr_minimize_grouping        false bool false
timing_crpr_remove_clock_to_data_crp false bool false
timing_crpr_remove_muxed_clock_crp    true bool true
timing_crpr_threshold_ps              1000 real  20         val >= 1


CRPR should be set to true to get things closer to the .........

Talk with Oscar ( library guy )

1. Library team will provide CCSN model for each library, sure it has corner ( fast, slow etc. ), it is cell-based and text so it is readable.

2. It doesn't make sense to use set_nose_margin, set_noise_immunity_curve, it is a coarse setting and some teams use it to add extra margin.

3. We do have lef file available ( I love lef file, I could extract lots of information from it ).

PTL, I got all the information I need.

Question: which corner we use when we analyze noise ???

set_noise_margin

-----Original Message-----
From: Jeffrey H Cui [mailto:jeffrey@marvell.com]
Sent: Monday, October 25, 2010 6:25 PM
To: Jeffrey Cui
Subject:

2. Synopsys Commands Command Reference
set_noise_margin

Copyright 2009 Synopsys, Inc. All rights reserved.

NAME
set_noise_margin
Sets noise margin for a library pin, port, or pin.

SYNTAX
int set_noise_margin
[-above]
[-below]
[-low]
[-high]
margin_value
object_list

float margin_value
list object_list

ARGUMENTS
-above Specifies the noise margin for above ground or power rail noise
analysis region.

-below Specifies the noise margin for below ground or power rail noise
analysis region.

-low Specifies the noise margin for ground rail noise.

-high Specifies the noise margin for power rail noise.

margin_value
Specifies a margin value. The value is the input height in
units of voltage. 1.0.

object_list
Specifies a list of lib-pins or ports.

DESCRIPTION
Each library cell input can tolerate a certain amount of noise without
causing a failure at the cell output. This characteristic is called
noise immunity. This command specifies noise immunity at library pins
to determine whether noise failures occur as well as the amount of
noise slack.

Noise immunity in the library can be specified as noise immunity
curves, polynomials, or tables or in terms of noise margins.

This command specifies a noise margin for a library pin, design port,
or pin. It can be used in the absence of library-specified noise immu-
nity characteristics, or to override the library-specified characteris-
tics by replacing them with noise margins. Noise immunity curves that
have been annotated using the set_noise_immunity_curve command will
override noise margins set by this command.

Noise margins consider only the bump heights at the cell inputs. Using
height-only noise margins is simpler, faster, and more conservative
than the other methods.

For high, narrow noise bumps, using height-only noise margins is pes-
simistic because it treats some bumps as noise failures that would oth-
erwise pass with the immunity curve model. However, for wide noise
bumps, using noise
margins gives the same results as using noise immunity curves.

Noise immunity characteristics can vary for different noise bump types,
so there can be four different noise margins associated with each
input: below low, above low, below high, and above high. All values are
specified as positive numbers for all four types of noise bumps.

In the absence of command-specified or library-specified noise immunity
data, PrimeTime SI calculates the maximum allowable noise bump heights
based on DC noise margins of the driver and receiver, as defined in the
.lib technology library by the input/output logic-level parameters.

report_noise_calculation will show whether noise margin information was
taken from the library or annotated by this command.

EXAMPLES
This example specifies a margin of 4 for above the ground rail noise
for pin A of library cell IV in the lsi_10k library:

pt_shell> set_noise_margin -above -low 4 lsi_10k/IV/A

SEE ALSO
set_noise_immunity_curve (2), report_noise_calculation (2),
remove_noise_margin (2).

B-2008.12-SP2 Copyright (c) 2009 Synopsys, Inc. All rights reserved.

set_noise_margin -above -low 4 m9hpd_std_slow/hpd_sao21bx2/A2

set_noise_immunity_curve

-----Original Message-----
From: Jeffrey H Cui [mailto:jeffrey@marvell.com]
Sent: Monday, October 25, 2010 6:25 PM
To: Jeffrey Cui
Subject:

2. Synopsys Commands Command Reference
set_noise_immunity_curve

Copyright 2009 Synopsys, Inc. All rights reserved.

NAME
set_noise_immunity_curve
Sets noise immunity curve for a library pin or port.

SYNTAX
int set_noise_immunity_curve
[-above]
[-below]
[-low]
[-high]
[-height height_value]
[-width width_value]
[-area area_value]
object_list

float height_value
float width_value
float area_value
list object_list

ARGUMENTS
-above Specifies an immunity curve for above ground or power rail noise
analysis region.

-below Specifies an immunity curve for below ground or power rail noise
analysis region.

-low Specifies an immunity curve for ground rail noise.

-high Specifies an immunity curve for power rail noise.

-height height_value
Specifies the height of the input voltage bump at the threshold
of logic failure. The height is in the voltage units of the
library.

-width width_value
Specifies the width of the input voltage bump at the threshold
of logic failure. The width is in the time units of the
library.

-area area_value
Specifies an area value for the curve. This parameter specifies
the size of the hyperbolic curve. 1.0.

object_list
Specifies a list of lib-pins or ports.

DESCRIPTION
Each cell input can tolerate a certain amount of noise without causing
a failure at the cell output. This characteristic is called noise immu-
nity. This command specifies noise immunity at library pins to deter-
mine whether noise failures occur as well as the amount of noise slack.

Noise immunity in the library can be specified as noise immunity
curves, polynomials, or tables or in terms of noise margins that con-
sider only the bump heights at the cell inputs.

This command specifies a noise immunity curve for a library pin or
design port. It can be used in the absence of library-specified noise
immunity characteristics, or to override the library-specified charac-
teristics by replacing them with a noise immunity curve. This command
will also override noise margins that have been annotated using the
set_noise_margin command,

The curve is hyperbolic with three coefficients to fully specify the
hyperbola: height and width of the input voltage bump at the threshold
of logic failure, and an area value to specify the size of the curve.
The three coefficients should be chosen to match the hyperbolic curve
to the data points obtained by laboratory characterization.

Noise immunity characteristics can vary for different noise bump types,
so there can be four different noise immunity curves associated with
each input: below low, above low, below high, and above high. All coef-
ficients are specified as positive numbers for all four types of noise
bumps.

report_noise_calculation will show whether noise immunity information
was taken from the library or annotated by this command.

EXAMPLES
This example specifies a noise height of 2, width of 3, area of 4 for
above the ground rail noise for pin A of library cell IV in the lsi_10k
library:

pt_shell> set_noise_immunity_curve -above -height 2 -width 3 \
-area 4 lsi_10k/IV/A

SEE ALSO
set_noise_margin (2), report_noise_calculation (2), remove_noise_immu-
nity_curve (2).

B-2008.12-SP2 Copyright (c) 2009 Synopsys, Inc. All rights reserved.

si_noise_composite_aggr_mode

NAME
       si_noise_composite_aggr_mode
              Specifies the composite aggressor mode for noise analysis.

TYPE
       String

DEFAULT
       disabled

DESCRIPTION
       This  variable  specifies  which  composite  aggressor  mode is used in
       PrimeTime  SI  noise  analysis.   Allowed  values  are  disabled   (the
       default),  which  turns  off  the composite aggressor feature.  normal,
       causes PrimeTime SI to calculate noise by utilizing the non-statistical
       composite aggressor feature.  Selecting statistical causes PrimeTime SI
       to calculate noise by using the statistical composite aggressor flow.

       In disabled composite aggressor mode, PrimeTime SI  uses  its  original
       flow with composite aggressor completely off to analyze the noise.

       In  normal composite aggressor mode, PrimeTime SI aggregates the effect
       of multiple small aggressors into a single composite aggressor, thereby
       reducing the computational complexity and improving the performance.

       statistical  composite  aggressor  mode reduces the pessimism for noise
       analysis by reducing the effect of composite aggressor.

       For the current value of this variable, type printvar  si_noise_compos-
       ite_aggr_mode.

si_xtalk_double_switching_mode

NAME
       si_xtalk_double_switching_mode
              Controls  the double switching detection during the PrimeTime-SI
              timing analysis.

TYPE
       String

DEFAULT
       "disabled"

DESCRIPTION
       Double switching detection mode can have one  of  these  three  values,
       "disabled",  "clock_network"  or "full_design". When this mode is "dis-
       abled", the default  mode,  this  double  switching  detection  is  not
       enabled.  When  this  variable  is  enabled  (set to "clock_network" or
       "full_design"), during update_timing PrimeTime-SI checks  that  whether
       crosstalk bump on the switching victim could cause the output to switch
       twice (and cause a pulse) instead of of desiered single signal propaga-
       tion.

       To  detect  the  potential double switching in the clock network, which
       could cause the double clocking (where the clock could switch  twice on
       a  the  sensitive  edge) or false clocking (where the switching bump on
       the non-sensitive edge could actually latch the state), set this  value
       to "clock_network".

       To  detect  the  potential double switching in the data path as well as
       clock path set this variable to "full_design".  Double switching  on  a
       data path is less severe then double switching on the clock network.

       The  double  switching  detection needs CCSN library information on the
       victim load cell.

       After the update_timing user could access these information in two ways
       1)  by  command  report_si_double_switching or 2) by the net attributes
       si_has_double_switching &  si_double_switching_slack.   Refer  the  man
       page  of report_si_double_switching for the command details. The victim
       net attribute si_has_double_switching is true  when  ever  there  is  a
       potential  double  switching  on  any of the load pins.  The victim net
       attribute si_double_switching_slack has the bump  slack,  reducing  the
       switching  bump  by that much amount could remove the double switching.
       If the victim net  doesn't  cause  double  switching  si_double_switch-
       ing_slack  will be "POSITIVE". If the victim net load pins doesn't have
       CCS-Noise model information, the attribute will be reported as "INIFIN-
       ITY".

       The victim nets having the double switching is automatically reselected
       to higher iteration so that they could be reanalyzed with more accurate
       analysis.

       The double switching happens when, the switching bump & transition time
       are large and fed into driver which  strong  enough  amplify  this.  To
       avoid double switching either of them can be reduced.

Mock response to Devang

How's going with the ptsi ?

I am trying to understand several more options. I have some questions to ask Felicia/Amit and waiting for their response.  I think I could have some recommendation middle this week.

NOISE

pt_shell> report_noise_parameters 

****************************************

Report  : noise_parameters

Design  : gfx3D

Version : B-2008.12-SP2

Date    : Mon Oct 25 10:19:34 2010

****************************************

 analysis mode        : report_at_source

 analysis effort      : high

 ignore arrival       : false

 include beyond Rails : false

 enable propagation   : false

Helen, Jeffrey and Stephane

408-896-8810

0ps input transient time issue

1. I guess it is because lack of input_driving_cell

2. the input cap zero issue: I guess it is because the port is floating

3. Big output transient time, there is no output load.

-Jeff

primetime_si

To get best-case/worst-case analysis results (best-case conditions for min analysis and worst-case conditions for max analysis), you need two crosstalk analysis runs: one using only best-case conditions, and another using only worst-case conditions. For example, for non-crosstalk analysis, suppose that you are using:
pt_shell> set_operating_conditions -analysis_type bc_wc \
            -min BEST -max WORST
pt_shell> report_timing -delay_type min_max
Then, for crosstalk max analysis under WORST operating conditions, you would use:
pt_shell> set si_enable_analysis true
pt_shell> set_operating_conditions -analysis_type \
            on_chip_variation WORST
pt_shell> report_timing -delay_type max
Then, for crosstalk min analysis under BEST operating conditions, you would use:
pt_shell> set_operating_conditions -analysis_type \
            on_chip_variation BEST
pt_shell> report_timing -delay_type min 

10_18_2010 PDS Error issue - Create_cell

I have the ESD cell in the macro_placement already, I created these cells again, then I have Error and was Errored out.

So the solution is easy, just add two lines before I create cells to make sure these cells are not there when I am trying to create cell.  Basically, def could play the role of create_cell too.

ICC bound vs plan

Background:  I am trying to use bound to place a group cells inside certain region, but looks like quite a few cells are out of the region. So I spent sometime to study the difference. 

bound: is kind of constraint, ICC will try to meet, but it won't guarantee. It is kind of "nice-to-have"

plan: is s requirement,  ICC will meet the requirement.

ICC scenario

set_scenario_options:    

 -cts_corner min | max | min_max | none
              When set to min (max), the min (max) corner of the scenario will
              be considered by the optimize_clock_tree command.  When  set  to
              min_max, both of the min and max corners of the scenario will be
              considered by the optimize_clock_tree command. Default value  of
              this option is none.

40nm spacing rules ..........

The reason I found the following problem is that I have metal1 gap between standard cell row and the dro cell which is not really a macro, which is built from standard cell.
________________________________________________


Filler insertion. the 40nm minimum spacing  rule is  2 placement grid. which is 0.28.

The problem is when the space is say, 4 x 0.14, you have 3x filler cell in your list, 3x is chosen first, then only 1x space is left. You have a gap left.  This part is relative easy to resolve by controlling the size of standard rows, make the size always even number of 0.14. But it will become impossible after you place the standard cell, you can't control the gap between standard cells, it could be 2,3,4,5,6.

Because of the above reason, Synopsys creates this option -no_x1, which is to resolve the issue I mentioned above. It could resolve like 4x gap, it will try 3x filler, then use two 2x filler to fill the gap.

ESD and DRO cells

These two cells are user friendly cells, they don't use metal4. They follow standard cell rails.

DRO used up to metal3, composed by standard cell. So I will treat it as standard cell, I won't add any blockage,  any route_guide to it, I will let ICC to take care of everything. The only thing I need to take care is to make sure the cell is on the right row and make sure the hookup won't be messed up.

    metal1 is run all the way across the block, so no need to take care the

    To play safe which is not super necessary. create_preroute_via   from metal6 to metal3

ESD used up to metal2. Two set of pins, VDD/VSS and VDD_ESD/VSS_ESD, since there is only one set of VDD/VSS here, so the connect is simple. Here is the deal, pease ESD as standard cell, make sure it is on the right row. After all the conn

    metal1 rail is only on the boundary, so some trouble over there.

     create_preroute_via  from metal6 to metal2 for VDD_ESD and VSS_ESD

Found out no need to take care the connection from upper metal to lower metal, the tool is smart enough to take care of it by itself. Walla, ICC.

I still want to take care WPE for around these blocks.

Small problem, there is no odd width filler cell in daxing's script, this may create gap for power rail. The problem is not that small, need to tell him to fix it.

spacing rule and wpe

Macro/memory:

    Side is easy,  keep 0.28, use spacing rule to make sure this, then 2.1 wpe blockage. ( No, I will not use spacing rule, I will use blockage to make sure that )

    Top and bottom, basically, need 1.5 rows to 2 rows to make sure M1 rails are there for the one row for add filler cells.

   Then there will be no spacing rule to SNPS.

Boundary boundary to meet the wpe rule:

    Top/Bottom: one row will be blocked for placement, these will be wpe blockage, remove and put back.

    Left/Right: 2.1um wide straps placement blockages will be added.

The blockages generated from addM5_xxx:

    Will be removed permeability.

My blockage:

    1. regular placement blockage:  snap to standard cell placement grid and wpe blockage will generated around it.

    2. core-area blockage: will be generate from my placement blockage gen script.

Tap cell:

     Same as before to play around the blockage, reversed blockage to place the tape cell, But I will improve the generating of the blockage to be snapped to 0.14 placement grid.

    I could have another way to place the tap cell without using blockage, I could use step to place the tap cell in the right place. And I could use spacing rule to push out other function cells next to tapecell.