Jin Final

Tips and Techniques on How to Ensure High Quality of
Results in Static Timing Analysis

London Jin
Toshiba America Electronic Components, Inc.
jinl@taec.toshiba.com
1.
ABSTRACT
This paper presents useful product-proven tips, techniques, and flow to
ensure the high quality of results in static timing analysis. It shows that it is
very important to understand all clocks in a design, clean up clock networks,
and justify all unchecked setup and hold before generating timing reports.
SNUG San Jose 2000 1 Tips & Techniques on QOR in STA

STA Obstacles and Challenges
1.0 Introduction
1.1 STA Obstacles and Challenges

Static timing analysis (STA) plays an even more important role in today’s
digital hardware design flow with ever-increasing design gate count and
aggressive time-to-market
1. requirement. However, there are many obstacles
and challenges towards successful STA. Two major obstacles and
challenges are 1) availability and quality of timing models; and 2) STA
expertise with PrimeTime (PT).
STA relies on accurate and complete timing models. In reality, however,

there is lack of high quality models for complex I/O cells, various types of
embedded memory cells and embedded IPs, which are typically represented
as black box models in the Synopsys .lib1 format. Synopsys supports three
types of timing models, QTM, extract_model and Stamp. Unfortunately,
there is a great deal of confusion in applications and design community as
to what type of models is suitable for a particular application.
On the other hand, STA is relative new, and not many people have very good
knowledge and expertise in STA and using PrimeTime. In some cases,
people performed STA with PT as it is required by design flow. However, it
can be garbage-in and garbage-out. Here are some examples.
Example 1: The timing report is generated. However, 3 clock networks (out

of 5) are all “unknown” when reviewed with
report_clock_transitive_fanout -clock_tree.
Example 2: The timing report is generated. However, there are 5% setup’s

and 5% hold’s that are “untested”, (or uncovered) as shown in Table 1 when
reviewed with report_analysis_coverage.
Table 1: Results of report_analysis_coverage

Type of Check Total Met Violated Untested
--------------------------------------------------------------------------------
setup 11288 10229 ( 91%) 480 ( 4%) 579 ( 5%)
hold 11288 9127 ( 81%) 1582 ( 14%) 579 ( 5%)
recovery 9703 6801 ( 70%) 28 ( 0%) 2874 ( 30%)
removal 9703 6823 ( 70%) 6 ( 0%) 2874 ( 30%)
min_pulse_width 21802 21802 (100%) 0 ( 0%) 0 ( 0%)
--------------------------------------------------------------------------------
All Checks 63784 54782 ( 86%) 2096 ( 3%) 6906 ( 11%)
1. Library Compiler is not capable of handling these type of macro cells.

Overview of STA Flow
The command report_timing in PT will always report something since there

are many many timing paths in a design it can pick and report. It, however,
does not tell you directly how many paths are not checked and what they are
in a typical report. As a result, it is very important to make sure that all paths
are covered and tested in STA. It is equally important to understand why
there are uncovered and untested paths.
1.2 Overview of STA Flow

1.
The STA flow consists of four phases as shown in Figure 1. Phase 1: setup
of timing environment; phase 2: examination of timing environment (phase
1); phase 3: generation of timing report; and phase 4: timing analysis and
violation elimination.
Phase 1: Setup of timing environment
Phase 2: Examination of timing environment
Phase 3: Generation of timing report
Phase 4: Timing analysis and violation elimination
Figure 1 STA flow with four phases
1.2.1 Phase 1: Setup of Timing Environment

In this phase, users are responsible for setting up the following items.
• all clocks with cycles and waveforms
• input and output delays
• timing exceptions
• capacitive loads

Software Version
1.2.2 Phase 2: Examination of Timing Environment

In this phase, the following items should be carefully examined
• all clocks
• clock networks
• untested setup/hold, removal/recovery, and min pulse width
1.2.3 Phase 3: Generation of1.Timing Report

In this phase, timing report is generated in terms of
• max delay
• min delay
1.2.4 Phase 4: Timing Analysis and Violation Elimination

In this phase, user
• analyzes the timing report, and
• fixes timing violations if any.
Of the four phases, this paper will address phase 2 only, examination of
timing environment because we have experienced that we cannot simply
assume that the timing environment be clean, and that there might be issues
hidden. We strongly think that we cannot get good QOR without a clean
timing environment. In this paper, we will present tips, techniques and the
phase 2 flow with visible examples that are extracted from real production
designs to ensure QOR in STA.
1.3 Software Version

The version of Design Compiler and PrimeTime used for the experiments
presented in this paper is 99.10.
1.4 Technology Library

Artisan/TSMC 0.25 µ m.
1.5 Commands and Options

All commands and options in this paper are in italics.

Example
2.0 Extract and Understand All Clocks

In STA, it is very important that all clocks are completely specified. This
step is supposed to be done in Phase 1. In reality, however, it is possible to
miss specification of some clocks. The reasons may be as follows.
• There is no document to tell all types of clocks, such as gated clocks,
1.
internally generated clocks, and muxed clocks.
• The STA is performed by CAD engineers who may not be fully
involved in detail of a design.
We found the command derive_clocks very helpful for reporting all types of
clocks for a given design.
2.1 Example
Shown in Figure 2 is the test circuit; Figure 3, the DC script; and Figure 4
the outputs of Figure 3.
Figure 2 Circuit A

Example
read -f verilog ddt.pre_scan.v

design_name = ddt
current_design design_name
link
derive_clocks
report_clocks
quit
Figure 3 DC script
derive_clocks
Information: Updating design information... (UID-85)
1.
create_clock find(port,"CLK")
create_clock find(pin,"ff11_reg/Q")
create_clock find(pin,"U49/Y")
report_clocks
****************************************
Report : clocks
Design : ddt
Version: 1999.10
****************************************
Attributes:
d - dont_touch_network
f - fix_hold
p - propagated_clock
Clock Period Waveform Attrs Sources
--------------------------------------------------------------------------------
CLK - - {CLK}
U49/Y - - {U49/Y}
ff11_reg/Q - - {ff11_reg/Q}
--------------------------------------------------------------------------------
Warning: Some clocks have no period defined. These clocks will not
be considered for timing. (RPT-27)
1
quit
1
dc_shell>
Thank you...
Figure 4 The outputs of Figure 3
As can be seen in Figure 4 that all clock sources including clock divider and
gating clock are reported with derive_clocks, and are further confirmed by
report_clocks.
It should be noted in Figure 3 that derive_clocks works on an ASCII netlist,

not on .db. The advantage of using an ASCII netlist is that derive_clocks
displays all clocks in a design, while it only displays those clocks that are
not specified (possibly missed) when the .db is used.
Shown in Figure 5 is the Tcl script for PT, and Figure 6, its outputs.

Tips
read_verilog ddt.pre_scan.v
set design_name ddt
current_design $design_name
link_design
derive_clocks -p 10
report_clock
quit
Figure 5 PT script
derive_clocks -p 10
Information: Using automatic max wire load selection group ’WireAreaCon’. (ENV-003)
1.
create_clock -period 10.000000 [get_ports {CLK}]
create_clock -period 10.000000 [get_pins {ff11_reg/Q}]
create_clock -period 10.000000 [get_ports {TM}]
1
report_clock
****************************************
Report : clock
Design : ddt
Version: 1999.10
****************************************
Attributes:
p - propagated_clock
G - Generated clock
Clock Period Waveform Attrs Sources
--------------------------------------------------------------------------------
CLK 10.00 {0 5} {CLK}
TM 10.00 {0 5} {TM}
ff11_reg/Q 10.00 {0 5} {ff11_reg/Q}
1
quit
Figure 6 The outputs of Figure 4
As can be seen from Figure 6 that PT generates slightly different report from
DC. It does not stop at the clock output of AND gate, and it traces through
all way to the primary input while DC stops at the clock output of AND
gate.
It must be noted that PT requires the option -period (or -p) when
derive_clocks is used while it is not required in DC.
2.2 Tips
1. Always run derive_clocks to extract all of clocks, and check if there are
any clock specifications missing.
2. Recommend to run derive_clocks in DC, not in PT, as it reports clock
sources.
3. Latch enable is considered as clock, and thus derive_clocks also reports
sources of all latch enables.

Suggestion to Synopsys
2.3 Suggestion to Synopsys

To avoid confusion from derive_clocks, provide options -edge_triggered,
master_slave, and -level_sensitive to separate edge-triggered registers from
level-sensitive and mast-slave ones, just like those options in all_registers.
1.

Unknown Clock Network
3.0 Clean Up Clock Networks

Assuming that every clock is understood, and specified. the user now must
then make sure that the clock networks are clean. The possible issues of
clock networks are incorrect timing models of clock drivers, synchronous
memory cells, and registered IPs.
1.
3.1 Unknown Clock Network
Here is an example. Its circuit with a single clock is shown in Figure 7 in
which u_clk is the clock buffer. Shown in Figure 8 are the constraints in DC.
Figure 7 Circuit B

The Cause
create_clock "CLK" -period 2 -waveform {0 1}

set_clock_skew -uncertainty 0.4 find(clock,"CLK")
all_data_in1 = all_inputs() - find(port, all_clocks())
all_data_in2 = all_data_in1 - RESET
set_input_delay 0.5 -clock CLK all_data_in2
set_output_delay 0.5 -clock CLK all_outputs()
Figure 8 The constraints for Figure 7
****************************************
Report : transitive_fanout 1. -clock_tree
Design : ddt
Version: 1999.10
****************************************
The fanout network of source CLK is as follows:
Driver Pin Load Pin Type Sense
------------------------------------------------------------
CLK u_clk/PAD (net arc) same
Load Pin Driver Pin Type Sense
------------------------------------------------------------
u_clk/PAD u_clk/NQ clkbuf unknown
------------------------------------------------------------
u_clk/NQ U49/A (net arc) unknown
------------------------------------------------------------
U49/A U49/NQ invp3 unknown
------------------------------------------------------------
U49/NQ ff22_reg/C (net arc) unknown
Figure 9 The outputs of report_transitive_fanout -clock_tree
Shown in Figure 9 are the outputs of report_transitive_fanout -clock_tree.

As can be seen that the entire clock network is “unknown”. The
consequence of an unknown clock network can be an incorrect delay
calculation. The STA tool will choose the more pessimistic delay arc
(positive edge or negative edge) even if a design uses all positive-edge
triggered flip-flops in the design. This behavior can result in a more
pessimistic static timing analysis. As a result, it is recommended that
unknown clock networks be corrected to ensure higher quality of results.
3.2 The Cause

The unknown clock network is caused by black box cell of clkbuf. This is
a very complex input buffer with multiple outputs and built-in boundary-
scan register. A cell is denoted as black box in the .lib when the attribute “b”

Fix
is assigned to the cell. This can be viewed either by using report_lib or

report_reference. Shown in Figure 10 are the results of report_reference for
Figure 7.
****************************************
Report : reference
Design : ddt
Version: 1999.10
****************************************
Attributes:
b - black box (unknown) 1.
d - dont_touch
Reference Library Unit Area Count Total Area Attributes
-----------------------------------------------------------------------------
an2ip1 q35l0_uh_std_tlu_ss
88.199997 1 88.199997
an2p1 q35l0_uh_std_tlu_ss
70.559998 1 70.559998
fdrp1 q35l0_uh_std_tlu_ss
299.880005 2 599.760010 n
fdrp2 q35l0_uh_std_tlu_ss
335.160004 2 670.320007 n
invp1 q35l0_uh_std_tlu_ss
35.279999 1 35.279999
52.919998 1 52.919998
52.919998 2 105.839996
na2p3 q35l0_uh_std_tlu_ss
105.839996 1 105.839996
clkbuf q35l0_io_ss
144495.000000
1 144495.000000 b, d
xn2p1 q35l0_uh_std_tlu_ss
141.119995 1 141.119995
-----------------------------------------------------------------------------
Total 10 references 146364.843750
Figure 10 The results of report_reference
3.3 Fix
There are two techniques to fix this particular issue. Technique one is to fix
the model. Due to a limitation of Library Compiler, it is impossible to fix it
with Library Compiler for such a cell. We can not simply treat it as black
box in timing analysis because the clock is inverted from input to its output.
Stamp model can help. Technique two is to bypass the clock buffer by using
a virtual clock.

Fix
3.3.1 Technique One - Stamp Model

With Stamp model, we get a clean and correct report from
report_transitive_fanout -clock_tree as shown in Figure 11.
****************************************
Report : transitive_fanout
-clock_tree
Design : ddt 1.
Version: 1999.10
****************************************
Fanout network of source ’CLK’:
------------------------------------------------------------
CLK u_clk/PAD (net arc) same
------------------------------------------------------------
u_clk/PAD u_clk/NQ clkbuf opposite
------------------------------------------------------------
u_clk/NQ U49/A (net arc) opposite
------------------------------------------------------------
U49/A U49/NQ invp3 same
------------------------------------------------------------
U49/NQ ff22_reg/C (net arc) same
Figure 11 The outputs of report_transitive_fanout -clock_tree with Stamp

model
3.3.2 Technique Two - Virtual Clock

The creation of a virtual clock along with other constraints is shown in
Figure 12. With this script, we also get a clean and expected clock network
report from report_transitive_fanout -clock_tree as shown in Figure 13.
create_clock -name VCLK -period 2 -waveform {0 1} find(pin, U49/NQ)
set_clock_latency 0.2 -source VCLK
set_ideal_net find(net, VCLK)
set_clock_skew -uncertainty 0.4 find(clock,"VCLK")
set_input_delay 0.5 -clock VCLK all_data_in2
set_output_delay 0.5 -clock VCLK all_outputs()
Figure 12 DC script in support of a virtual clock

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

Tips
Report : transitive_fanout
-clock_tree
Design : ddt
Version: 1999.10
****************************************
The fanout network of source U49/NQ is as follows:
------------------------------------------------------------
U49/NQ 1.
ff11_reg/C (net arc) same
Figure 13 The outputs of report_transitive_fanout -clock_tree with virtual

clock
We also found that incorrect timing models of embedded memory cells and
IPs are possible causes of unknown clock networks. The black box timing
model such as QTM is not sufficient in some applications in timing analysis,
and should not be encouraged in use.
3.4 Tips
1. Investigate clock networks with report_transitive_fanout -clock_tree,
and make it as a necessary step in timing analysis flow.
2. Clean up all issues if any before moving to next step. The timing
reported may not be correct without a clean clock network.
3. Examine all cells and libraries used in a design, and pay special
attention to all cells with attribute “b” - black box attribute, and try to
resolve them.
3.5 Suggestions to Synopsys

1. Synopsys should limit the number of timing models from three to one.
2. Synopsys should use PDCS2 (Delay and Power Calculation System) for
production or use verilog models directly.
2. It is for the calculation and modeling of delay and power for deep submicron designs, and is a balloted and
approved OVI and Si2 standard and is now an IEEE standard (IEEE 1481, publication #AD5704-NYF).
Refer to www.si2.org for detail.

No Clock
4.0 Justify Unchecked Setup and Hold

In timing analysis, setup/hold, removal/recovery and min pulse width are
checked. However, there are cases where these checks are missed, or cannot
be performed. It is important to understand why they are not checked, and
how to make them properly checked in order to ensure a high quality of
results in your timing
1. analysis. In this section we will explore various
scenarios of unchecked (or untested in PT) setup and hold.
4.1 No Clock
The circuit is shown in Figure 2. The constraints applied to the circuit are
shown in Figure 14.
create_clock "CLK" -period 2 -waveform {0 1}
set_clock_skew -uncertainty 0.4 find(clock,"CLK")
set_input_delay 0.5 -max -clock CLK all_data_in2
set_output_delay 0.5 -max -clock CLK all_outputs()
Figure 14 DC constraints
4.1.1 50% Untested Setup and 75% Untested Hold

As discussed in section 1,1, the command report_analysis_coverage is used
to see the timing check coverage. The outputs are shown in Figure 15, and
they reveal that there are two (50%) setup untested and three(75%) hold’s
untested.
****************************************
Report : analysis_coverage
Design : ddt
Version: 1999.10
****************************************
--------------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
hold 4 1 ( 25%) 0 ( 0%) 3 ( 75%)
recovery 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
min_pulse_width 4 2 ( 50%) 2 ( 50%) 0 ( 0%)
--------------------------------------------------------------------------------
All Checks 16 7 ( 44%) 2 ( 12%) 7 ( 44%)
Figure 15 The output of report_analysis_coverage

No Clock
To understand why there are two setup timing checks untested, the
command report_analysis_coverage -status_details {untested} -sort_by
slack -check_type {setup} is used to see the detail. The outputs are shown in
Figure 16.
****************************************
-status_details {untested }
-sort_by slack
-check_type {setup }
Version: 1999.10 1.
****************************************
--------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
--------------------------------------------------------------------------
All Checks 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
Constrained Related Check

Pin Pin Type Slack Reason
--------------------------------------------------------------------------
ff21_reg/D CK setup untested no_clock
ff22_reg/D CK setup untested no_clock
Figure 16 The output of report_analysis_coverage -status_details

{untested} -sort_by slack -check_type {setup}
It can be seen in Figure16 that the registers with setup unchecked are ff21
and ff21, and the reason that PT provides is “no clock”. Investigation of the
design and constraints validates the claim. This also explains why two hold
timing checks are untested.
4.1.2 Fix
From the design it is understood that the clocks for ff21 and ff22 are
internally generated by ff11 and ff22 respectively. Additionally, the ff22’s
clock is also sequentially gated with a primary input pin TM, and this needs
to be taken care3. The script is shown in Figure 17, and the results of
report_analysis_coverage after fix are shown in Figure 18.
create_generated_clock -name CLK2 -source CLK -divide_by 2 ff11_reg/Q
set_case_analysis 1 TM
create_generated_clock -name CLK3 -source CLK -divide_by 2 ff12_reg/Q
set_clock_latency 0.2 -source CLK3
Figure 17 Fixing script
3. PT automatically performs clock gating check for combinational gating only.

No Clock
****************************************
Design : ddt
Version: 1999.10
****************************************
--------------------------------------------------------------------------------
setup 4 4 (100%) 0 ( 0%) 0 ( 0%)
hold 4 2 ( 50%) 1 ( 25%) 1 ( 25%)
recovery 4 4 (100%) 0 ( 0%) 0 ( 0%)
min_pulse_width 8 6 ( 75%) 2 ( 25%) 0 ( 0%)
1.
--------------------------------------------------------------------------------
All Checks 20 16 ( 80%) 3 ( 15%) 1 ( 5%)
Figure 18 The output of report_analysis_coverage after fix
4.1.3 Early Warnings?

In addition to using report_analysis_coverage -status_details {untested} to
figure out why setup’s and hold’s are untested, other commands such as
derive_clocks and check_timing serve useful early checks and warnings.
4.1.3.1 derive_clocks
The scripts are shown in Figures 3 and 5 for DC and PT respectively, and
their outputs are listed in Figures 4 and 6 respectively. It can be seen from
the outputs of derive_clocks that U49/Y and ff1_reg/Q are two internal
clock sources.
4.1.3.2 check_timing
With check_timing -verbose, it clearly reports that the clocks for ff11 & ff22
are missing as shown in Figure 19.
Warning: There are 2 register clock pins with no clock.
Clock Pin
------------------------------------------------------------
ff21_reg/CK
ff22_reg/CK
Figure 19 The result of check_timing -verbose
4.1.4 Tips
1. Missing clock specification is usually the root cause of untested setup
and hold checks. Use derive_clocks to extract all clocks and check to see
if any clocks are missed in specification. The command
report_analysis_coverage -status_details {untested} identifies the root
cause without confusion. The command check_timing -verbose is useful
means to verify and diagnose the problem.

No Min Constraints of Startpoints
2. When the clock is missed on a register, both setup and hold are
“untested”.
4.2 No Min Constraints of Startpoints

Startpoints are input ports or clock pins on registers.
4.2.1 25% Untested Hold

1.
It is noticed in Figure 18 that there is still one (or 25%) hold untested with
the fix. What is it? And why?
Investigation begins with report_analysis_coverage status_details

{untested} -sort_by slack -check_type {hold}. Shown in Figure 20 is its
output. It shows that the untested hold is on ff12. PT, however, cannot tell
the reason as it states that the reason is “unknown”.
****************************************
-sort_by slack
-check_type {}4
Design : ddt
Version: 1999.10
****************************************
--------------------------------------------------------------------------------
hold 4 3 ( 75%) 0 ( 0%) 1 ( 25%)
--------------------------------------------------------------------------------
All Checks 4 3 ( 75%) 0 ( 0%) 1 ( 25%)

--------------------------------------------------------------------------------
ff12_reg/D CK hold untested unknown
Figure 20 The output of report_analysis_coverage status_details

{untested} -sort_by slack -check_type {hold}
4.2.2 Fix
Careful study of the script, in Figure 14, reveals that the constraints do not
provide any min delay on input ports. This is the cause of the untested hold
time checks. The fix is to simply add min delay constraints as below.
4. The check type “hold” does not get displayed. This is is a bug in the report generation section of the soft-
ware.

No Min Constraints of Startpoints
set_input_delay 0.2 -min -clock CLK I1

set_output_delay 0.2 -min -clock CLK O*
Figure 21 Additional min delay constraints for Figure 2
Shown in Figure 22 are the output s of report_analysis_coverage with the

additional constraints. As can be seen that there is no untested items now.
****************************************
Design : ddt
Version: 1999.10 1.
****************************************
--------------------------------------------------------------------------------
setup 4 4 (100%) 0 ( 0%) 0 ( 0%)
hold 4 3 ( 75%) 1 ( 25%) 0 ( 0%)
recovery 4 4 (100%) 0 ( 0%) 0 ( 0%)
min_pulse_width 8 6 ( 75%) 2 ( 25%) 0 ( 0%)
--------------------------------------------------------------------------------
All Checks 20 17 ( 85%) 3 ( 15%) 0 ( 0%)
Figure 22 The output of report_analysis_coverage with min delay

constraints
4.2.3 Early Warnings?

Unfortunately, we tried all, and found nothing available to indicate the
issue. check_timing5 does not give any indication of the issue. As a result,
missing min delay on input ports is very dangerous.
4.2.4 Tips
In constraints, always make sure that both max and min delays are
specified. Missing min delay is not reported by any Synopsys tools today.
Users may have to write their script to check them.
4.2.5 Suggestions to Synopsys

1. Check min delay specification on input ports and report them if missing.
2. It is not acceptable to state the reason of “unknown” in
report_analysis_coverage status_details {untested} -sort_by slack -
check_type {hold}.
5. It does check unconstrained end points. However, it checks for max delay, and thus setup only.

No Constraints of Endpoints
4.3 No Constraints of Endpoints

Endpoints are output ports or data pins of registers. When constraints are
missed on endpoints, the violation is easily detected using the PT
methodology discussed in this section.
4.3.1 50% Untested Setup and Hold

Shown in Figure1.
23 is the circuit with two clock domains, and Figures 24
and 25 are DC and PT scripts respectively.
Figure 23 Circuit C
create_clock "CLK1" -period 2 -waveform {0 1}
create_clock "CLK2" -period 2 -waveform {0 1}
set_clock_skew -uncertainty 0.4 find(clock,"CLK*")
set_input_delay 0.5 -clock CLK1 all_data_in2
set_output_delay 0.5 -clock CLK2 all_outputs()
Figure 24 DC script for Figure 23

alias rac report_analysis_coverage
read_db ddt.pre_scan.db
set design_name ddt
current_design $design_name
link_design
source define_async_domains.tcl # A Synopsys Tcl script along with tool release

define_async_domains {CLK1 CLK2}

check_timin -verbose
rac > cov.1
rac -status_details {untested} -sort_by slack -check_type {hold} > untested.hold
rac -status_details {untested} -sort_by slack -check_type {setup} > untested.setup
rac -status_details {violated} -check_type {min_pulse_width} > untested.min_pulse_width
Figure 25 PT script for Figure 23
Shown in Figure 26 are the outputs of report_analysis_coverage

1.
****************************************
Design : ddt
Version: 1999.10
****************************************
--------------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
hold 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
recovery 4 4 (100%) 0 ( 0%) 0 ( 0%)
min_pulse_width 8 4 ( 50%) 4 ( 50%) 0 ( 0%)
--------------------------------------------------------------------------------
All Checks 20 12 ( 60%) 4 ( 20%) 4 ( 20%)
Figure 26 The output of report_analysis_coverage
It can be seen from Figure 26 that there are two (50%) setup’s and two
(50%) hold’s that are not checked. The command report_analysis_coverage
-status_details {untested} -sort_by slack -check_type {setup} is used to see
what they are and why, and its outputs are shown in Figure 27.
****************************************
-sort_by slack
-check_type {setup }
Design : ddt
Version: 1999.10
****************************************
--------------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
--------------------------------------------------------------------------------
All Checks 4 2 ( 50%) 0 ( 0%) 2 ( 50%)

--------------------------------------------------------------------------------
ff21_reg/D CK setup untested no_paths
ff22_reg/D CK setup untested no_paths
Figure 27 The output of report_analysis_coverage -status_details

{untested} -sort_by slack -check_type {setup}

It is understood from Figure 27 that the unchecked setup comes from ff21
and ff22. PT reports that the reason why they are not checked is “no paths”,
meaning that the endpoints are not constrained.
How come? The only way to constrain ff21 and ff22 is the clock, which is
obviously specified in Figure 24. What else is going on? It is noticed in the
PT script (Figure 25) that the paths across clock domains are set to false
with Tcl script define_async_domains.tcl, and ff21/D and ff22/D are
endpoints of CLK1,
1. and thus they are not constrained.
4.3.2 Tips
1. All timing checks are not tested for false and multiple-cycle paths set by
commands set_false_path and set_multicycle_path.
2. The command check_timing in DC reports (or complains) these
unconstrained endpoints while check_timing in PT does not (yes, they
are different). Shown in Figures 28 and 29 are the outputs of
check_timing in DC and PT respectively.
Information: Updating design information... (UID-85)
Warning: The following end-points are not constrained for maximum delay.
End point
---------------
O3
ff21_reg/D
ff22_reg/D
Figure 28 The output of check_timing in DC

Warning: There are timing exceptions which are ignored.
From To Setup Hold
--------------------------------------------------------------------------------
CLK2 CLK1 FALSE FALSE
Figure 29 The output of check_timing in PT

3. Count the expected numbers of setup and hold against the reported
numbers from report_analysis_coverage. The following procedure
gives the expected setup and hold accounts
• From libraries, we can know how many setups’ and hold’s there are
on a registered cell.
• From ungroup-all -flatten and report_reference, we can know how
many registered cells there are in a design.

5.0 Recommended Flow and Summary

In this paper we have presented tips and techniques on how to ensure QOR
in STA. In summary, the following are the recommended steps and flow of
phase 2 as shown in Figure 30 with PT.
1.
Extract and understand all clocks derive_clocks
ungroup -all -flatten

Examine libraries report_reference
Clean up clock networks report_analysis_coverage
Justify all untested setup and hold report_transitive_fanout -clock_tree
Figure 30 Steps and flow of Phase 2 in STA
1. Extract and understand all clocks with derive_clocks. Justify all clocks
reported by this command against clock document or designers. Pay
special attention to internally generated clocks, gated cocks, and muxed
clocks as well as latch enables.
2. Examine libraries used for a design with report_lib, or with ungroup -
all -flatten, report_reference and check to see if there are any black box
cells related to clocks, such as clock driver, synchronous memory cells
and registered IPs. If there are, the timing models for them are needed.
3. Clean up clock networks with report_transitive_fanout -clock_tree. The
clock networks may be messed up by incorrect timing models of clock
drivers, synchronous memory cells and registered IPs.
4. Justify all untested setup and hold with report_analysis_coverage. All
setup and hold should be checked except those that are specified by
set_false_path and set_multicycle_path. Check libraries and see how
many setup’s and hold’s there are on a cell, and then check the total
counts of setup and hold in a design against the expected counts.

It is believed and experienced that with the recommended steps of phase 2

flow in STA, we have ensured QOR. We now are ready to move to next
phase, phase 3, generation of timing report.
1.

Jin Final

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jin Final

Uploaded by

Copyright:

Available Formats

Tips and Techniques on How to Ensure High Quality of

Results in Static Timing Analysis

SNUG San Jose 2000 1 Tips & Techniques on QOR in STA

1.1 STA Obstacles and Challenges

STA relies on accurate and complete timing models. In reality, however,

Example 1: The timing report is generated. However, 3 clock networks (out

Example 2: The timing report is generated. However, there are 5% setup’s

Table 1: Results of report_analysis_coverage

1. Library Compiler is not capable of handling these type of macro cells.

SNUG San Jose 2000 2 Tips & Techniques on QOR in STA

The command report_timing in PT will always report something since there

1.2 Overview of STA Flow

Phase 1: Setup of timing environment

Phase 2: Examination of timing environment

Phase 3: Generation of timing report

Phase 4: Timing analysis and violation elimination

Figure 1 STA flow with four phases

1.2.1 Phase 1: Setup of Timing Environment

SNUG San Jose 2000 3 Tips & Techniques on QOR in STA

1.2.2 Phase 2: Examination of Timing Environment

1.2.3 Phase 3: Generation of1.Timing Report

1.2.4 Phase 4: Timing Analysis and Violation Elimination

1.3 Software Version

1.4 Technology Library

1.5 Commands and Options

SNUG San Jose 2000 4 Tips & Techniques on QOR in STA

2.0 Extract and Understand All Clocks

SNUG San Jose 2000 5 Tips & Techniques on QOR in STA

read -f verilog ddt.pre_scan.v

Figure 4 The outputs of Figure 3

It should be noted in Figure 3 that derive_clocks works on an ASCII netlist,

SNUG San Jose 2000 6 Tips & Techniques on QOR in STA

Figure 6 The outputs of Figure 4

SNUG San Jose 2000 7 Tips & Techniques on QOR in STA

2.3 Suggestion to Synopsys

SNUG San Jose 2000 8 Tips & Techniques on QOR in STA

3.0 Clean Up Clock Networks

SNUG San Jose 2000 9 Tips & Techniques on QOR in STA

create_clock "CLK" -period 2 -waveform {0 1}

Figure 8 The constraints for Figure 7

Figure 9 The outputs of report_transitive_fanout -clock_tree

Shown in Figure 9 are the outputs of report_transitive_fanout -clock_tree.

3.2 The Cause

SNUG San Jose 2000 10 Tips & Techniques on QOR in STA

is assigned to the cell. This can be viewed either by using report_lib or

Figure 10 The results of report_reference

SNUG San Jose 2000 11 Tips & Techniques on QOR in STA

3.3.1 Technique One - Stamp Model

Figure 11 The outputs of report_transitive_fanout -clock_tree with Stamp

3.3.2 Technique Two - Virtual Clock

Figure 12 DC script in support of a virtual clock

SNUG San Jose 2000 12 Tips & Techniques on QOR in STA

Figure 13 The outputs of report_transitive_fanout -clock_tree with virtual

3.5 Suggestions to Synopsys

SNUG San Jose 2000 13 Tips & Techniques on QOR in STA

4.0 Justify Unchecked Setup and Hold

4.1.1 50% Untested Setup and 75% Untested Hold

Figure 15 The output of report_analysis_coverage

SNUG San Jose 2000 14 Tips & Techniques on QOR in STA

Constrained Related Check

Figure 16 The output of report_analysis_coverage -status_details

Figure 17 Fixing script