Hierarchical Static Timing Analysis using ETMs (Extracted Timing Models

SYNOPSYS, INC.
700 East Middle Field Road, Mountain View, CA 94043
Hierarchical Static Timing Analysis using

ETMs (Extracted Timing Models)
Version 1.0
Abstract
ASIC devices are often composed of third-party IP (Intellectual Property), custom or semi-custom
functional blocks, fab-vendor memory macros, standard cell glue logic, etc. As design sizes increase
and customers migrate to static timing analysis solutions that incorporate delay calculation using
parasitic information and signal integrity analysis, capacity and runtime issues for full-chip analysis
become increasingly important. PrimeTime’s Extracted Timing Models (ETMs) are timing
abstractions of designs for complex blocks or IP blocks that can improve capacity and runtime while
preserving reasonable accuracy. This document describes Extracted Timing Model flows and discusses
how these models are generated, verified and used. The limitations of Extracted Timing models are also
discussed. The focus of this document is to provide a recommended methodology to help the user
produce sign-off quality ETMs, but it is not an exhaustive description. For more information, see the
chapter “Extracted Timing Models” in the PrimeTime Modeling User Guide.
PrimeTime CAE Document PAGE i

Proprietary Information-Not for distribution without Synopsys Approval.
SYNOPSYS, INC.
Table of contents
1 Introduction 1
1.1 BENEFITS OF HIERARCHICAL VERSUS FLAT STA FLOW 1
1.2 EXTRACTED TIMING MODELS (ETMS) 1
1.3 INTERFACE LOGIC MODELS (ILMS) 2
2 Model Extraction 2
2.1 BLOCK-LEVEL STATIC TIMING ANALYSIS USING PARASITICS 3
2.2 PREPARING FOR MODEL EXTRACTION 3
2.3 GENERATING ETMS AS LIBRARY CELLS 3
2.4 EXTRACTION VARIABLES 4
2.4.1 Slew Propagation 4
2.4.2 Other Variables 5
2.5 TIMING EXCEPTIONS 5
2.6 GENERATED CLOCKS 5
2.7 BLOCK SCOPE 6
2.8 MODEL MODES 6
2.9 DIFFERENT OPERATING CORNERS 6
3 Model Validation 6
3.1 MODEL VALIDATION COMMANDS 6
3.2 MODEL VALIDATION FLOW 7
3.3 TROUBLESHOOTING MODEL VALIDATION MISMATCHES 8
3.4 OPERATING CONDITIONS AND ANALYSIS MODES 8
3.5 MULTICYCLE PATH TIMING CONSTRAINTS 8
3.6 ASYNCHRONOUS TIMING CONSTRAINTS 8
3.7 TEST DESIGN 9
3.8 BACK-ANNOTATED BLOCKS 9
3.8.1 Outputs 9
3.8.2 Inputs and Driving Cells 9
3.9 USING REPORT_ETM_ARC TO TROUBLESHOOT MISMATCHES 11
4 Model Scope 12
4.1 BLOCK SCOPE GENERATION 14
4.2 BLOCK SCOPE CHECKING 14
4.2.1 check_block_scope 14
4.2.2 Relative versus Absolute 16
5 Usage flow 17
5.5 BLOCK-LEVEL ANALYSIS 18
5.6 MODEL VALIDATION FOR TEST DESIGN 18
5.7 CHIP-LEVEL ANALYSIS 19
6 Conclusion 20
7 Appendix: prep_for_etm_verification.tcl 21
7.1 FLOW 21
7.2 SCRIPT 21
PrimeTime CAE Document PAGE ii

SYNOPSYS, INC.
Table of figures
Figure 1 : ETMs ..............................................................................................................................................2
Figure 2 : Test design with ETM instance.......................................................................................................9
Figure 3 : back-annotated boundary nets.......................................................................................................10
Figure 4 : Clock Waveform in Block Scope Information..............................................................................13
Figure 5 : Block Scope Slack definition .......................................................................................................15
Figure 6 : Absolute Checking for U1/CLOCK1............................................................................................16
Figure 7 : Block Representation ....................................................................................................................16
Figure 8 : Relative Checking for U1/CLOCK1 .............................................................................................17
Figure 9 : Usage Flow: Block level; ..............................................................................................................18
Figure 10 : Usage Flow: Validation step .......................................................................................................19
Figure 11 : Usage Flow: Chip level...............................................................................................................20
PrimeTime CAE Document PAGE iii

SYNOPSYS, INC.
700 East Middlefield Road, Mountain View, CA 94043 USA
1 Introduction
PrimeTime is a full-chip, gate-level static timing and signal integrity analysis tool.
PrimeTime provides hierarchical analysis capabilities by enabling the creation and
usage of timing models to represent the timing characteristics of complex blocks in a
design. Once a block has met its timing constraints at the gate level, the detailed
internal timing of the block is not needed for chip-level timing analysis. A timing
model of the block should completely model the full input/output timing
characteristics without requiring the complete netlist of the block.
Timing models do not model every path in the block. Internal register-to-register
paths are generally discarded, as these paths can be analyzed at the block level using
the complete gate-level netlist. However, using the concept of block scope ensures
that none of theses internal paths are affected by top level constraints. So the
hierarchical analysis with PrimeTime can be sign-off quality.
1.1 Benefits of Hierarchical versus Flat STA Flow

In the flat full-chip static timing analysis (STA) approach, the gate-level netlist of
entire chip is submitted to PrimeTime together with chip-level timing constraints,
SPEF or SDF annotation, and technology library files. Using this approach, designers
must wait for the completion of every block in a design prior to performing full-chip
STA. Also, design sizes have increased over the years and most designs are now in
the range of multi-million gates, which can sometimes be too much to fit in the
available memory for analysis.
Hierarchical STA allows large designs to be analyzed within reasonable runtimes and
memory constraints of available hardware. Using a hierarchical STA approach, a
design can be partitioned into different blocks using timing models. PrimeTime
provides the following types of timing models: ETMs (Extracted Timing Models),
Interface Logic Models (ILMs), and QTMs (Quick Timing Models).
Using a hierarchical STA flow has several benefits. Hierarchical STA reduces
runtime and memory usage compared to flat STA. The actual run time savings
depend on the design complexity. Using ETMs to abstract the timing model of a
complex block or IP hides the detailed design implementation information. This
usage model is ideal for IP providers. QTMs can be used to efficiently specify
estimated timing for blocks not yet designed. This usage model allows full-chip STA
in the early stages of the design cycle, enabling designers to examine design timing
requirements prior to chip completion.
1.2 Extracted Timing Models (ETMs)

The Extracted Timing Model (ETM) is an abstraction of the block using sequential
and combinational timing arcs. NLDM lookup tables are extracted for each of the
Version 4.0
Synopsys PROPRIETARY
10/11/06
1
SYNOPSYS, INC.
timing arcs whose delay is a function of input transitions and output loads, which
makes the ETM usable with different input transition times and different output
loads.
The major advantages of the ETM approach are:
• ETMs enable IP reuse with the content protected because the model contains
abstracted timing information, without any netlist information.
• In addition to PrimeTime, ETMs enables capacity increase for other tools
throughout the design flow such as Design Compiler, Physical Compiler, and
Astro.
1.3 Interface Logic Models (ILMs)
The Interface Logic Models (ILM) is another model type supported by PrimeTime
but is not covered in this application note. An ILM is a partial netlist of the block
that includes the boundary logic, but hides most of the internal register-to-register
logic, for full-chip analysis. Both ETMs and ILMs can be used in a hierarchical static
analysis flow when flat analysis is not possible because of runtime and/or memory
usage. An ILM offers more visibility into the netlist, which can result in easier
verification, but provides less IP protection.
2 Model Extraction
Gate-level static timing analysis (STA) should be performed on the block prior to
model extraction. The ETM model is not only a collection of timing arcs representing
the boundary paths, but also a block "scope" that is a binary representation of the
constraints impacting the internal paths at the time of extraction. The user specifies
these constraints to make a conservative analysis in max and min mode so that the
extracted model is conservative.
There are two kinds of ETMs available: one type is a netlist, and the other type is a
Liberty library cell. Both can be used at the top level. However, given that the main
advantage of ETM versus ILM is the ability to deliver an accurate model to the
customer while hiding the inside, the most frequent usage is extracting a Liberty
library cell. This is what is described in this application note.
U3 U5
IN OUT1
OUT1 U1/A U5/Z
U1 U4 U6
IN U7 U8
OUT2
U2 CLK U2/A OUT2
CLK U6/Z
Figure 1 : ETMs Library cell ETM
Version 4.0
10/11/06
2
SYNOPSYS, INC.
2.1 Block-Level Static Timing Analysis Using Parasitics

The recommended full-chip hierarchical STA flow uses parasitics for accurate
PrimeTime RC delay calculation. During model extraction, the ETM takes into
account the delays computed by PrimeTime’s RC delay calculator. If PrimeTime SI
crosstalk delay analysis is performed at the gate level, the ETM takes into account
crosstalk delay effects due to coupling capacitors. At full-chip hierarchical STA,
parasitics should be back-annotated for top-level nets.
2.2 Preparing for Model Extraction

Prior to performing model extraction, the user needs to perform the following tasks:
Run check_timing –verbose. The user needs to understand the warnings and verify
that they are acceptable. For example, unconstrained paths or unclocked registers
must be addressed.
Verify that the timing constraints are correct. It is recommended to define clock
arrival time ranges and clock transition ranges. This task determines the operational
range for the block.
Verify that the design does not have timing violations. This is preferred but not
mandatory. Timing violations should be addressed or acknowledged. Timing
violations on boundary paths may cause timing violations at full-chip STA.
Verify the warnings during update_timing. Parasitic back-annotation warnings/errors
and library problems can induce accuracy issues.
2.3 Generating ETMs as Library Cells

For ETMs generated as library cells, PrimeTime computes the delays due to
boundary nets using its RC delay calculator and combines those delays into the
lookup tables. The ETM is “context independent” for input slew and load
capacitance, which means that the model works correctly for a range of slews and
load capacitance.
In the example below, the name of the block is blockA. The following command
generates the ETM as a library cell.
pt_shell> extract_model -output model_lib -format {db lib} –lib \
–block_scope –test …
The following are the output files.
A .db file for the library named blockA_lib that contains the reference blockA.
A .lib file that is the source file for the library named blockA_lib.
Version 4.0
10/11/06
3
SYNOPSYS, INC.
The ETM is extracted for the current_mode. Multiple ETMs can be extracted for
different modes and merged into one single timing model using the merge_lib
command.
2.4 Extraction Variables

A set of specific variables may be applied to control the quality of the extraction.
This section describes commonly used variables.
Number of Points in the LUT (Lookup Table)
The following variables control the number of index points in the ETM.
set extract_model_num_capacitance_points 5
This variable controls the number of loads values defined in the LUT.
set extract_model_num_clock_transition_points 5
This variable controls the number of input transition values defined in the LUT for
clocks.
set extract_model_num_data_transition_points 5
This variable controls the number of input transition values defined in the LUT for
data inputs.
The recommendation for the best trade-off between accuracy performance is to have
the same sizes of the extracted lookup-table as the lookup tables of the initial library.
This is not the default selection. If you do not have access to this information, the
recommended LUT size for good accuracy is 7x7, what means setting:
set extract_model_num_capacitance_points 7
set extract_model_num_data_transition_points 7
2.4.1 Slew Propagation
set extract_model_use_conservative_current_slew TRUE

It is recommended to set this variable to TRUE when timing analysis of the netlist is
being performed in worst-slew propagation mode. During model extraction, the slew
is adjusted to use the worst slew if it is more conservative than the context slew.
Version 4.0
10/11/06
4
SYNOPSYS, INC.
Setting this variable to TRUE may generate a more conservative ETM model but will
provide consistent timing information for the model validation step.
2.4.2 Other Variables
set extract_model_single_pin_cap TRUE

This variable must be set to FALSE if libraries are defined with input capacitance
ranges to model the Miller effect, and you want these ranges to be maintained in the
ETM. An example of this syntax is
pin (pin_name) {
....
rise_capacitance_range (float, float);
fall_capacitance_range (float, float);
...
set extract_model_with_clock_latency_arcs FALSE
When this variable is set to TRUE, extract_model traverses all clock tree paths,
computes the insertion delay of the paths, and creates clock latency arcs in the model.
The clock latency arcs are intended for physical implementation tools such as Astro
and ICC to compensate and balance clock tree skews at chip level. PrimeTime also
understands these clock latency arcs.
2.5 Timing Exceptions

When timing exceptions are applied to the netlist, model extraction creates a
constraint file that must be sourced when the ETM is instantiated at chip level. The
name of this file is <model_name>_constr.pt
2.6 Generated Clocks

Generated clocks are maintained in the ETM and are visible in chip-level analysis.
The following naming convention is used for generated clocks in the ETM:
<instance name>/<generated clock name>
The above naming convention should be used in the chip-level constraint file to
reference generated clocks.
Version 4.0
10/11/06
5
SYNOPSYS, INC.
2.7 Block Scope

In a bottom up approach, when the user does the verification at chip level, the user
must ensure the constraints at top level are more restrictive then the constraints used
at block analysis and model extraction. This can be done thanks to block scope
checking:
pt_shell> extract_model -block_scope -output …
Block scopes are pictures of the constraints impacting internal paths. It is an
important part of the ETM, and it needs to be checked at chip level to ensure that no
violations are missed. See the section Scope checking for more information.
2.8 Model Modes

Some blocks have different modes of operations: for example test/functional, or
read/write. In such cases, you must do the analysis/extraction for each of the given
modes, and then merge the different results into a single model using merge_model.
pt_shell> merge_model .... -output merge_model \
-mode_names {WRITE READ}
Then the final model contains the two modes of operation.
2.9 Different Operating Corners

You need to create one ETM model for each corner or set of operating conditions that
you need to analyze.
3 Model Validation
This step is a verification of the ETM generation. A timing picture of the initial
netlist is taken and compared to the ETM timing pictures. You can compare each
path slack or each I/O timing arc delay.
3.1 Model Validation Commands

write_interface_timing
This command must be applied to the netlist of the block and to the test_design that
contains an instance of the ETM library cell. The command generates a timing file
with slack or timing arc values. You decide whether to use slack or timing arcs as the
criteria for comparison. A comparison using slack is a function of the timing
constraints and arc delays. A comparison using timing arc values is independent of
timing constraints.
Version 4.0
10/11/06
6
SYNOPSYS, INC.
compare_interface_timing
This command compares timing between the netlist and the test_design containing an
instance of the ETM library cell. A number of command options are available to
specify the criteria and the pass/fail tolerance for comparison. A report is generated
with failing and matching arcs based on the tolerance.
3.2 Model Validation Flow

Below is a typical model validation flow.
read verilog
Read the block-level netlist.
read_parasitics (-keep_coupling_capacitance ) –format (spef or sbpf)
….
source <constraint.sdc>
Apply block-level timing constraints that must be conservative for min analysis and
max analysis. As a result, you have arrival windows for input and ranges for input
transitions.
check_timing
update_timing
report_timing
Perform update_timing and generate timing reports.

extract_model -library_cell …. –test_design … -block_scope
The option -block_scope creates the "scope" for constraints that affect internal path
checking.
The option -test_design is useful for model validation, as it creates a test design
with the newly generated library cell instantiated. The write_interface_timing
command is done on that one design and compared to the initial netlist.
write_interface_timing –timing_type slack … ref_netlist.tim –test
Typically, model validation is performed using slack as this includes the effects of
both the timing constraints and timing arcs.
remove_design –all
set link_path ”* …. <model>_lib.db”
read_db <model>_test.db
Reads the test design generated by extract_model.
link
read_parasitics (-keep_coupling_capacitance ) –format (spef or sbpf)
….
Version 4.0
10/11/06
7
SYNOPSYS, INC.
source <constraint.sdc>
Apply block constraints. Notice, however, that the current_design name is now
<design>_test.
update_timing
report_timing
Perform update_timing and generate timing reports.

write_interface_timing –timing_type slack … etm.tim
The timing_type should be the same as the timing_type used at the block level.
compare_interface_timing Ref_netlist.tim etm.tim –output
comparison.tim –absolute_tolerance 0.020
The above commands compare slacks with an absolute tolerance of 20ps if the library
unit is in ns.
3.3 Troubleshooting Model Validation Mismatches

This section references the “netlist design” and the “test design”. The netlist design is
the block design from which an ETM is extracted. The test design is the design
created by extract_model –test, instantiating the library cell created for the ETM.
This test design is used for model validation only.
3.4 Operating Conditions and Analysis Modes

You must be careful to use the exact same conditions of analysis between the block
analysis and the test design analysis. Most of the issues come from user setup errors.
3.5 Multicycle Path Timing Constraints

When multicycle paths exist in the block-level timing constraint, the constraint files
<etm_name>_constr.pt is must be sourced when the model is instantiated.
Multicycle paths on internal timing paths are not recommended and can be an issue
for verification. These constraints are no longer applied to the ETM model because
the internal paths are not visible in the ETM. This will cause serious discrepancies
during the verification step.
3.6 Asynchronous Timing Constraints

Asynchronous timing constraints such as set_max_delay are not supported by ETM
model extraction and validation. These constraints must be removed before extraction
and validation.
Version 4.0
10/11/06
8
SYNOPSYS, INC.
3.7 Test Design

The test design is an instantiation of the ETM library cell with nets connected from
the ports to the ETM I/Os. The delay to be seen on these nets for verification must be
null. So to get rid of the wire load model delay, you must back-annotate a zero
capacitance value on all the nets of this test design.
pt_shell> set_cap 0 *
ETM test design
ETM instantiation
In1 In1
Out1 Out1
In2 In2 Out2
Out2
In3 In3 Out3
Out3
In4 In4
In4
Clk1 Clk1
Clk2 Clk2
Figure 2 : Test design with ETM instance
3.8 Back-Annotated Blocks

When a block has been back-annotated with parasitics, extract_model lumps all the
boundary net capacitors onto the ports of the model.
3.8.1 Outputs
For each primary output, the pin delay is computed using the range of external loads
characterized for the driving device. In order to have a successful validation, you can
store the lumped capacitance from the block and back-annotate it on the test design at
the time of the validation. You can find a methodology to automate that process in
the appendix.
3.8.2 Inputs and Driving Cells

When driving cells are used in the timing analysis of a block netlist and RC parasitics
exist at the boundary, differences in validation are due to a different calculation when
Version 4.0
10/11/06
9
SYNOPSYS, INC.
this driving cell drives a net with distributed parasitics (block analysis) and when the
same driving cell drives a lumped capacitance (ETM in test design).
ETM Library cell
Etm timing arc

Netlist
Input
capacitance =
Lumped load
Figure 3 : back-annotated boundary nets
To address this issue, it is recommended that you use the set_input_transition

command instead of the set_driving_cell command prior to model extraction.
Otherwise, to address the slack differences during model validation, you can annotate
the load equal to the effective capacitance seen from the driving cell in the netlist. To
save the effective capacitance value, you must set the following variable before
update_timing:
pt_shell>set rc_cache_min_max_rise_fall_ceff true
Version 4.0
10/11/06
10
SYNOPSYS, INC.
The effective capacitance values on the driving cells are saved in the attributes
cached_ceff_min/max_rise/fall. These attributes are available to the user.
Please refer to the appendix for an example of a procedure that helps to perform the
two changes mentioned above.
3.9 Using report_etm_arc to Troubleshoot Mismatches

When a comparison mismatch is reported, the command report_etm_arc may be used
for troubleshooting. This commands reports the timing paths associated with the
netlist and ETM timing arcs.
Below is an example on how to use the report_etm_arc command. In this example,
the command compare_interface_timing reports the following mismatch:
SigA(r) SigB[](f) max_combo_delay 0.4634 0.4377 0.0257 FAIL
The report_etm_arc command may be used as follows:

pt_shell > report_etm_arc -rise_from SigA -fall_to SigB \
-arc_type max_combo_delay \
-include {clock_path netlist_path } \
-lib -sig 4 -etm etm.rpt -netlist net.rpt
The above command generates the following two reports for comparison:
Netlist Report:
Data path:
Point Cap Trans Incr Path

--------------------------------------------------------------------
SigA (in) 0.0250 0.1438 0.0000 & 0.0000 r
U182/i (inv0) 0.1438 0.0001 & 0.0001 r
U182/zn (inv0) 0.1911 0.1631 0.0995 & 0.0996 f
U206/a1 (oaim22) 0.1822 0.0326 & 0.1323 f
…
U122/zn (nr02) 0.0454 0.1319 0.1347 & 1.3603 f
U88/a2 (nd12) 0.1318 0.0005 & 1.3607 f
U88/zn (nd12) 0.0220 0.7602 0.4056 & 1.7663 r
…
SigB (out) 0.1399 0.0085 & 2.3374 f
Version 4.0
10/11/06
11
SYNOPSYS, INC.
--------------------------------------------------------------------
ETM report:
ETM Report for arc : SigA_SigB_inv

Point Cap Trans Incr Path
--------------------------------------------------------------------
SigA (in) 0.0000 0.1438 0.0000 0.0000 r
U182/i (inv0) 0.1438 0.0001 & 0.0001 r
U182/zn (inv0) 0.1911 0.1631 0.0995 & 0.0996 f
U206/a1 (oaim22) 0.1822 0.0326 & 0.1323 f
…
U122/zn (nr02) 0.0454 0.1319 0.1347 & 1.3595 f
U88/a2 (nd12) 0.1318 0.0005 & 1.3600 f
U88/zn (nd12) 0.0220 0.7478 0.4056 & 1.7656 r
…
SigB (out) 0.1409 0.0094 & 2.3623 f
--------------------------------------------------------------------
The situation above is likely to be a slew propagation issue. You should verify that
the following variables are set for model extraction:
set timing_slew_propagation worst_slew
set extract_model_use_conservative_current_slew true
4 Model Scope
At this stage, ETM model validation has been completed successfully and the model
is ready to be used for chip-level timing analysis. Model scope checking verifies that
the ETM is being used within the bounds of the context in which it was generated.
The user must ensure the generated ETM will be used at the chip level with
constraints that are consistent with or more restrictive than the constraints used
during the block netlist analysis.
Given that the internal timing arcs of the model are no longer available, the user
should not change any boundary constraints that could have an impact on the block’s
internal timing paths.
Version 4.0
10/11/06
12
SYNOPSYS, INC.
Let's look at a simple example for a better understanding:
Setup Setup slack: 0.9

: slack: 1.1
7.3 7.5
7.2 7.4
7.3 7.5
Figure 4 : Clock Waveform in Block Scope Information
In this example, the clock range was from 7.3ns to 7.5ns for model extraction. The
constraint on the clock at the chip level is now applied between 7.2ns and 7.5ns. The
ETM analyzed at the chip level meets the setup slack constraint because the setup
slack was large enough. However, the change on the clock timing constraint may
have impact on the internal paths of the block and may cause chip-level timing
failures even though there are no timing violations associated with the ETM. Usage
of the block scope feature flags situations where the ETM is being used outside of
range of the block-level timing constraints. The block scope feature allows you to
safely perform chip-level timing analysis using ETM models.
Version 4.0
10/11/06
13
SYNOPSYS, INC.
The block scope records the constraints that have been used for extraction and that
are impacting internal paths. In a non-crosstalk analysis, only constraints related to a
clock must be checked. In PrimeTime SI crosstalk delay and noise analysis, the data
arrival times must also be checked because the inputs can act as aggressors on
internal nets that are not visible in the ETM for chip-level analysis. These constraints
are checked when the ETM is used in the chip-level analysis.
4.1 Block Scope Generation

During ETM model generation, specify the –block_scope command option to
generate a block scope file.
pt_shell > extract_model –block_scope …
The block scope file contains block-level timing constraints that can be checked
when the block is used in chip-level analysis.
4.2 Block Scope Checking
4.2.1 check_block_scope
Block scope checking is performed when the ETM is used in chip-level timing
analysis. This step ensures that the ETM is used under the same or less restrictive
conditions in which the block was analyzed and extracted.
pt_shell > check_block_scope
Any external signal that can have an impact on internal paths must be checked in the
block scope. For both PrimeTime and PrimeTime SI, clocks must be checked. For
PrimeTime SI, in addition, data input nets must be checked as they can act as
aggressors on internal nets. A list of instances can be passed as an argument of
check_block_scope so that the check is done on all ETM instances.
By default, check_block_scope checks clocks and data in relative mode. It does

not check the exact absolute times when the clocks/data arrive at the boundary of the
ETM versus the values coming from each of the block scopes. Instead, a shift delay
value per clock domain is considered for the analysis. This value is selected to
minimize the number of violations for data and clocks.
Below is an example of a report from check_block_scope:
3. Checking arrival and transition times at block boundary pins.

Clock max condition early rise
Scope Required Actual
Pin Clock Arrival Arrival Arrival Slack
---------------------------------------------------------------
U1/CLK1 CLK1 1.000 1.100 1.200 0.100 (MET)
Version 4.0
10/11/06
14
SYNOPSYS, INC.
U1/CLK2 CLK2 ….
Clock max condition late rise
Scope Required Actual

Pin Clock Arrival Arrival Arrival Slack
---------------------------------------------------------------
U1/CLK1 CLK1 1.500 1.600 1.600 0.000 (MET)
U1/CLK2 CLK2 …
The scope arrival column contains values from the scope file. The actual arrival
column contains values of the clock arrival times at the block boundary in chip-level
analysis. The required arrival column contains the shifted values from the scope file.
check_block_scope compares the actual versus required times and deduces the slack:
Early edge Late edge
Required
Actual
Slack
Figure 5 : Block Scope Slack definition

So the slack is defined by Actual - Required for early edges and Required - Actual
for late edges.
Version 4.0
10/11/06
15
SYNOPSYS, INC.
4.2.2 Relative versus Absolute
Required arrival :
Scope arrival
1 1.5
Actual arrival
1.2 1.6
Slack: 0.2
Violation: -0.1
Figure 6 : Absolute Checking for U1/CLOCK1

In Figure 6, the top waveform represents the clocks with values from the constraints
used to extract the model and to generate the scope.
Path checked at Path not checked Path checked at top

top level in the model level
anymore
Figure 7 : Block Representation
Version 4.0
10/11/06
16
SYNOPSYS, INC.
Figure 7 shows that the goal is to check all constraints that would impact internal
paths which are no longer visible in the ETM. Here, only the delay between the clock
edges is of importance. If we ensure that these respective edges delays are kept, the
exact arrival time of the clock edge is not relevant.
Block Scope
1 1.5
Shift: 0.1
Required arrival:
Block Scope shifted
1.1 1.6
Actual arrival
1.2 1.6
Violation: 0
Slack: 0.1
Figure 8 : Relative Checking for U1/CLOCK1

Figure 8 demonstrates how the check_block_scope command moves the reference by
adding a “delay shift value” to the block scope value. This creates a new reference in
the report called the required arrival. This value is selected to minimize the number
of violations. If there are still violations, this means that the block is not used under
the same conditions as at the block level analysis.
5 Usage flow
The following section summarizes the flows that have been described so far.
Version 4.0
10/11/06
17
SYNOPSYS, INC.
5.5 Block-Level Analysis
For the block, you carefully define the SDC constraints. For each input, you
define a window on arrival time and a range on input transitions. These bound
values are defined so that the model is conservative.
Read Netlist
Back-annotation
create_clock -name Clock -period … \
[get_ports <clock_pin>
Apply block level set_clock_latency -source … -rise/fall Clock
–early/late –min/max <clock>
constraints set_input_transition -rise –min/max \
<clock_pin>
set_input_transition –fall –min/max … \
STA <clock_pin>
Model creation extract_model … -block_scope … \

-output <block_model name> …
Write interface timing
Figure 9 : Usage Flow: Block level;
5.6 Model Validation for Test Design

This step is needed to verify that the timing values for each endpoint of the initial
netlist and the extracted timing match.
Version 4.0
10/11/06
18
SYNOPSYS, INC.
Read test design
Back-annotation
Apply block level

constraints +
timing
exceptions
STA
Write interface timing
compare interface
timing
Figure 10 : Usage Flow: Validation step
5.7 Chip-Level Analysis

Now the hierarchical blocks are replaced by the library cells created by
extract_model, and static timing analysis is done at the chip level, together with block
scope checking.
Version 4.0
10/11/06
19
SYNOPSYS, INC.
Read Chip Netlist • The user is going to

Read Models check the top level clo
definitions (arrival,
Back-annotation Top slews) are more
level
restrictive compared to
Apply top level block_level clock
constraints
definitions.
STA check_block_scope \
-instance
Check Block Scope <block_instance>
<scope file>
Figure 11 : Usage Flow: Chip level
6 Conclusion
This application note's intent is to summarize the steps and common pitfalls the user
may encounter when using ETMs. For a bottom up analysis, the user makes an
accurate and conservative analysis of each of the blocks. Then the model is extracted
and the block scope is generated. Model validation is recommended to ensure that the
timing model is equivalent to the original netlist. When instantiating these ETMs at
the top level, the static timing analysis is done with significantly improved runtime
and memory usage. The user can ensure sign-off quality by using the block scope
feature.
Version 4.0
10/11/06
20
SYNOPSYS, INC.
7 Appendix: prep_for_etm_verification.tcl
7.1 Flow
This procedure generates two scripts that must be applied to the netlist and the ETM.
These scripts remove the set_driving_cell constraints, replace them with
set_input_transition for the netlist design, and apply set_annotated_transition for the
test design. The scripts also generate the back-annotation script that can be applied to
the test design to specify the effective net capacitance values from the netlist.
The usage flow is the following:
in the ETM extraction session:
- source prep_for_etm_verification.tcl
- read block netlist
- read parasitics back-annotation file
- apply block constraints
- prep_for_etm_verification.tcl
- netlist_changes_for_etm_verification
- update_timing
- extract_model
- write_interface_timing
In the test-design session:
- read test design
- read parasitics back-annotation file
- apply block constraints
- source etm_changes_for_etm_verification.tcl
- update_timing
- write_interface_timing
7.2 Script
proc prep_for_etm_verification {} {
sh touch etm_changes_for_etm_verification.tcl
Version 4.0
10/11/06
21
SYNOPSYS, INC.
sh touch netlist_changes_for_etm_verification.tcl
sh rm etm_changes_for_etm_verification.tcl
sh rm netlist_changes_for_etm_verification.tcl
sh touch etm_changes_for_etm_verification.tcl
sh touch netlist_changes_for_etm_verification.tcl
foreach_in_collection input_pin [all_inputs] {

set input_name [get_att $input_pin full_name]
if { [llength [get_attribute -quiet [get_ports $input_pin] driving_cell_fall_max]]}
{
echo "set_annotated_transition -max -fall [get_attribute $input_pin
actual_fall_transition_max]" $input_name >> etm_changes_for_etm_verification.tcl
echo "set_input_transition -max -fall [get_attribute $input_pin
actual_fall_transition_max]" $input_name >> netlist_changes_for_etm_verification.tcl
echo "remove_driving_cell -max -fall" $input_name >>
etm_changes_for_etm_verification.tcl
echo "remove_driving_cell -max -fall" $input_name >>
netlist_changes_for_etm_verification.tcl
set effcapmaxfall [get_attribute -quiet [get_ports $input_pin]
cached_ceff_max_fall ]
if {[llength $effcapmaxfall]} {
echo "set_load -max -subtract_pin_load " $effcapmaxfall {[get_net -of }
$input_name {]} >> etm_changes_for_etm_verification.tcl
}
}
if { [llength [get_attribute -quiet [get_ports $input_pin] driving_cell_fall_min]]}
{
echo "set_annotated_transition -min -fall [get_attribute $input_pin
actual_fall_transition_min]" $input_name >> etm_changes_for_etm_verification.tcl
echo "set_input_transition -min -fall [get_attribute $input_pin
actual_fall_transition_min]" $input_name >> netlist_changes_for_etm_verification.tcl
echo "remove_driving_cell -min -fall" $input_name >>
echo "remove_driving_cell -min -fall" $input_name >>
set effcapminfall [get_attribute -quiet [get_ports $input_pin]
cached_ceff_min_fall ]
if {[llength $effcapminfall]} {
echo "set_load -min -subtract_pin_load " $effcapminfall {[get_net -of }
}
}
if { [llength [get_attribute -quiet [get_ports $input_pin] driving_cell_rise_max]]}
{
echo " set_annotated_transition -max -rise [get_attribute $input_pin
actual_rise_transition_max]" $input_name >> etm_changes_for_etm_verification.tcl
echo "set_input_transition -max -rise [get_attribute $input_pin
actual_rise_transition_max]" $input_name >> netlist_changes_for_etm_verification.tcl
echo "remove_driving_cell -max -rise" $input_name >>
echo "remove_driving_cell -max -rise" $input_name >>
set effcapmaxrise [get_attribute -quiet [get_ports $input_pin]
cached_ceff_max_rise ]
if {[llength $effcapmaxrise]} {
echo "set_load -max -subtract_pin_load " $effcapmaxrise {[get_net -of }
}
}
if { [llength [get_attribute -quiet [get_ports $input_pin] driving_cell_rise_min]]}
{
echo "set_annotated_transition -min -rise [get_attribute $input_pin
actual_rise_transition_min]" $input_name >> etm_changes_for_etm_verification.tcl
echo "set_input_transition -min -rise [get_attribute $input_pin
actual_rise_transition_min]" $input_name >> netlist_changes_for_etm_verification.tcl
Version 4.0
10/11/06
22
SYNOPSYS, INC.
echo "remove_driving_cell -min -rise" $input_name >>

echo "remove_driving_cell -min -rise" $input_name >>
set effcapminrise [get_attribute -quiet [get_ports $input_pin]
cached_ceff_min_rise ]
if {[llength $effcapminrise]} {
echo "set_load -min -subtract_pin_load " $effcapminrise {[get_net -of }
}
}
}
foreach_in_collection output_pin [all_outputs] {
set output_name [get_att $output_pin full_name]
set output_driv [get_pins -of [get_nets -of $output_name] -filter "direction=~out"]
set output_driv_name [get_att $output_driv full_name]
set output_cap_max [get_attribute -quiet [get_pins $output_driv_name]
effective_capacitance_max ]
if {[llength $output_cap_max]} {
echo "set_load -subtract -max " $output_cap_max {[get_net -of } $output_name
{]} >> etm_changes_for_etm_verification.tcl
}
set output_cap_min [get_attribute -quiet [get_pins $output_driv_name]
effective_capacitance_min ]
if {[llength $output_cap_min]} {
echo "set_load -subtract -min " $output_cap_min {[get_net -of } $output_name
{]} >> etm_changes_for_etm_verification.tcl
}
}
}
Version 4.0
10/11/06
23

Hierarchical Static Timing Analysis using ETMs (Extracted Timing Models

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Hierarchical Static Timing Analysis using ETMs (Extracted Timing Models

Încărcat de

Drepturi de autor:

Formate disponibile

SYNOPSYS, INC.

700 East Middle Field Road, Mountain View, CA 94043

Hierarchical Static Timing Analysis using

PrimeTime CAE Document PAGE i

PrimeTime CAE Document PAGE ii

PrimeTime CAE Document PAGE iii

1.1 Benefits of Hierarchical versus Flat STA Flow

1.2 Extracted Timing Models (ETMs)

Figure 1 : ETMs Library cell ETM

2.1 Block-Level Static Timing Analysis Using Parasitics

2.2 Preparing for Model Extraction

2.3 Generating ETMs as Library Cells

2.4 Extraction Variables

2.4.1 Slew Propagation

set extract_model_use_conservative_current_slew TRUE

2.4.2 Other Variables

set extract_model_single_pin_cap TRUE

set extract_model_with_clock_latency_arcs FALSE

2.5 Timing Exceptions

2.6 Generated Clocks

2.7 Block Scope

2.8 Model Modes

2.9 Different Operating Corners

3.1 Model Validation Commands

3.2 Model Validation Flow

Perform update_timing and generate timing reports.

Perform update_timing and generate timing reports.

3.3 Troubleshooting Model Validation Mismatches

3.4 Operating Conditions and Analysis Modes

3.5 Multicycle Path Timing Constraints

3.6 Asynchronous Timing Constraints

3.7 Test Design

ETM test design

Figure 2 : Test design with ETM instance

3.8 Back-Annotated Blocks

3.8.2 Inputs and Driving Cells

ETM Library cell

Etm timing arc

Figure 3 : back-annotated boundary nets

To address this issue, it is recommended that you use the set_input_transition

3.9 Using report_etm_arc to Troubleshoot Mismatches

The report_etm_arc command may be used as follows:

Point Cap Trans Incr Path

ETM Report for arc : SigA_SigB_inv

Let's look at a simple example for a better understanding:

Setup Setup slack: 0.9

Figure 4 : Clock Waveform in Block Scope Information

4.1 Block Scope Generation

4.2 Block Scope Checking

By default, check_block_scope checks clocks and data in relative mode. It does

3. Checking arrival and transition times at block boundary pins.

Clock max condition late rise

Scope Required Actual

Early edge Late edge

Figure 5 : Block Scope Slack definition

4.2.2 Relative versus Absolute

Figure 6 : Absolute Checking for U1/CLOCK1

Path checked at Path not checked Path checked at top

Figure 7 : Block Representation

Figure 8 : Relative Checking for U1/CLOCK1

5.5 Block-Level Analysis

Model creation extract_model … -block_scope … \