Beruflich Dokumente
Kultur Dokumente
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.
1.0 Introduction
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.
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.
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
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...
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.
Shown in Figure 5 is the Tcl script for PT, and Figure 6, its outputs.
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
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.
1.
Figure 7 Circuit B
****************************************
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
Driver Pin Load Pin Type Sense
------------------------------------------------------------
u_clk/NQ U49/A (net arc) unknown
Load Pin Driver Pin Type Sense
------------------------------------------------------------
U49/A U49/NQ invp3 unknown
Driver Pin Load Pin Type Sense
------------------------------------------------------------
U49/NQ ff22_reg/C (net arc) unknown
U49/NQ ff21_reg/C (net arc) unknown
U49/NQ ff12_reg/C (net arc) unknown
U49/NQ ff11_reg/C (net arc) unknown
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.
****************************************
Report : transitive_fanout
-clock_tree
Design : ddt 1.
Version: 1999.10
****************************************
Fanout network of source ’CLK’:
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 opposite
Driver Pin Load Pin Type Sense
------------------------------------------------------------
u_clk/NQ U49/A (net arc) opposite
Load Pin Driver Pin Type Sense
------------------------------------------------------------
U49/A U49/NQ invp3 same
Driver Pin Load Pin Type Sense
------------------------------------------------------------
U49/NQ ff22_reg/C (net arc) same
U49/NQ ff11_reg/C (net arc) same
U49/NQ ff21_reg/C (net arc) same
U49/NQ ff12_reg/C (net arc) same
Report : transitive_fanout
-clock_tree
Design : ddt
Version: 1999.10
****************************************
The fanout network of source U49/NQ is as follows:
Driver Pin Load Pin Type Sense
------------------------------------------------------------
U49/NQ ff22_reg/C (net arc) same
U49/NQ ff21_reg/C (net arc) same
U49/NQ ff12_reg/C (net arc) same
U49/NQ 1.
ff11_reg/C (net arc) same
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.
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.
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")
all_data_in1 = all_inputs() - find(port, all_clocks())
all_data_in2 = all_data_in1 - RESET
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
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.
****************************************
Report : analysis_coverage
-status_details {untested }
-sort_by slack
-check_type {setup }
Version: 1999.10 1.
****************************************
Type of Check Total Met Violated Untested
--------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
--------------------------------------------------------------------------
All Checks 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
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
****************************************
Report : analysis_coverage
Design : ddt
Version: 1999.10
****************************************
Type of Check Total Met Violated Untested
--------------------------------------------------------------------------------
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%)
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
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.
2. When the clock is missed on a register, both setup and hold are
“untested”.
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.
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.
5. It does check unconstrained end points. However, it checks for max delay, and thus setup only.
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*")
all_data_in1 = all_inputs() - find(port, all_clocks())
all_data_in2 = all_data_in1 - RESET
set_input_delay 0.5 -clock CLK1 all_data_in2
set_output_delay 0.5 -clock CLK2 all_outputs()
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.
****************************************
Report : analysis_coverage
-status_details {untested }
-sort_by slack
-check_type {setup }
Design : ddt
Version: 1999.10
****************************************
Type of Check Total Met Violated Untested
--------------------------------------------------------------------------------
setup 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
--------------------------------------------------------------------------------
All Checks 4 2 ( 50%) 0 ( 0%) 2 ( 50%)
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
1.
Extract and understand all clocks derive_clocks
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.
1.