You are on page 1of 8

The Differences Between the report_clock_tree and

report_clock_timing Commands
Doc Id: 031744 Product: IC Compiler
Average User Rating:

Save Article

Tag Article

Print

Last Modified: 03/17/2011


(10) Rate Article:

Send comment

Email

Question:

Why do the report_clock_tree and report_clock_timing commands report


different
results?
Answer:

The report_clock_tree command is used to report the clock tree


information before
and after clock tree synthesis, including not only the settings and
clock tree
exceptions, but also the clock tree skew and latencies after clock
tree synthesis.
On the other hand, the report_clock_timing command is a clock tree
timing analysis
command. The command originally came from PrimeTime, so it reports
the timing along
the clock tree without taking clock tree synthesis attributes into
consideration.
Here are the main differences between the two commands about
reporting clock skew
and latencies:

The report_clock_timing command considers source latency in


its calculations.

By default, the report_clock_tree command reports global skew,

while the report_clock_timing command reports local skew.

The report_clock_tree command considers clock tree exceptions.

The report_clock_timing command considers timing derating.

Source Latencies
For details about source latencies, see the following SolvNet
028398:
Do both report_clock_tree and report_clock_timing commands consider
source latencies?

Global Skew Versus Local Skew


By default, the report_clock_tree command reports the global skew
for clock trees.
The global skew is the largest skew within the specified clock tree.
As shown in
the following figure, the global skew might be between the FF1 and
FF4 flip-flops.
This skew number only helps with assessing the overall quality of
the clock tree,
not with the specific timing situation. There is no timing path
between the FF1
and FF4 flip-flops; a large skew there will have little effect. The
skew between
the FF1 and FF2 flip-flops is much more relevant.
.

The report_clock_timing command reports local skew by default. The


local
skew is the largest skew within a clock tree between two flip-flops
that are
connected, such as the FF1 and FF2 flip-flops.
The local skew should always be smaller than or equal to the global
skew.
Starting with the D-2010.03 release, you can also report local skew
by
using the report_clock_tree command as shown in the following
example:
icc_shell> report_clock_tree -local_skew
Note that the reported skew of this command includes integrated
clock-gating cells
if they exist. You might want to use the -local_skew_skip_icg option
to exclude
integrated clock-gating cells.

The following reports show another subtle difference between the two
commands:
icc_shell> report_clock_tree -local_skew
...
============ Local Skew Report ================
Clock: clk
(I: ICG cell pin, N: non-stop pin)
(L: longest arrival, S: shortest arrival, E: arrival derived
from cts exceptions)
Clock arrival time is calculated from the source(s) of the
master clock.
Clock Pin
Latency
Skew
---------------------------------------------------------------------------------FF3/CP
0.74 (S)
FF4/CP
0.96 (L)
0.21
icc_shell> report_clock_timing -type skew
...
Clock: clk
Clock Pin
Latency
Skew
--------------------------------------------------------------------------FF1/CP
0.76
wrp-+
FF2/CP
0.74
0.02
wrp-+
--------------------------------------------------------------------------Clock: div_clk
No local skews.
The reports show a large discrepancy. The report_clock_timing
command sees the
clk and div_clk clocks as two distinct clocks, while the
report_clock_tree command
and clock tree synthesis consider the divided div_clk clock as part
of the clk clock.
To resolve the difference, use the following command:
icc_shell> report_clock_timing -type interclock_skew -from_clock clk
-to_clock div_clk
...
Clock Pin
Latency
Skew
--------------------------------------------------------------------------FF3/CP
0.74
wrp-+
FF4/CP
0.96
-0.21
wrp-+

---------------------------------------------------------------------------

Clock Tree Exceptions


The report_clock_tree command considers clock tree exceptions when
calculating
the skew. For example, the following command uses a float pin that
is defined
on the flip-flop driven by the divided clock as shown in the
previous figure:
icc_shell> set_clock_tree_exceptions -float_pins FF4/CP
-float_pin_max_delay_rise 0.5
icc_shell> report_clock_tree -local_skew
...
Clock: clk
(I: ICG cell pin, N: non-stop pin)
(L: longest arrival, S: shortest arrival, E: arrival derived
from cts exceptions)
Clock arrival time is calculated from the source(s) of the
master clock.
Clock Pin
Latency
Skew
---------------------------------------------------------------------------------FF3/CP
0.74 (S)
FF4/CP
1.46 (LE)
0.71
icc_shell> report_clock_timing -type interclock_skew -from_clock clk
-to_clock div_clk
...
Clock Pin
Latency
Skew
--------------------------------------------------------------------------FF3/CP
0.74
wrp-+
FF4/CP
0.96
-0.21
wrp-+
--------------------------------------------------------------------------As expected, the report_clock_timing command does not consider clock
tree
exceptions, but the report_clock_tree command takes the exceptions
into account
in the report. As shown in the report, the "E" in (LE) under the
Latency column
next to the value of 1.46 indicates the arrival time derived from
clock tree
synthesis exceptions.

For another example,


icc_shell> set_clock_tree_exceptions -exclude_pins FF4/CP
icc_shell> report_clock_tree -local_skew
...
============ Local Skew Report ================
Clock: clk
(I: ICG cell pin, N: non-stop pin)
(L: longest arrival, S: shortest arrival, E: arrival derived
from cts exceptions)
Clock arrival time is calculated from the source(s) of the
master clock.
Clock Pin
Latency
Skew
---------------------------------------------------------------------------------FF1/CP
0.76 (L)
FF2/CP
0.74 (S)
0.02
As shown in the report, the worst local skew has disappeared because
it was
declared as an exclude pin exception for clock tree synthesis. The
report_clock_timing
command still shows the skew between the FF3 and FF4 flip-flops.

Timing Derating
The report_clock_timing command considers timing derating when
calculating the
clock tree latency. Timing derating is applied by using the
set_timing_derate
command or by using advanced on-chip variation (AOCV). The
report_clock_tree
command does not perform derating, so you do not get an accurate
skew or latencies.
When you run the report_timing command, the latencies are the same
as the results
reported by the report_clock_timing command.
For example,
icc_shell> set_timing_derate -late 1.05
icc_shell> set_timing_derate -early 0.95
icc_shell> report_clock_tree -local_skew
...
Clock: clk
(I: ICG cell pin, N: non-stop pin)
(L: longest arrival, S: shortest arrival, E: arrival derived
from cts exceptions)

Clock arrival time is calculated from the source(s) of the


master clock.
Clock Pin
Latency
Skew
---------------------------------------------------------------------------------FF3/CP
0.74 (S)
FF4/CP
0.96 (L)
0.21
icc_shell> report_clock_timing -type interclock_skew -from_clock clk
-to_clock div_clk
...
Clock Pin
Latency
Skew
--------------------------------------------------------------------------FF3/CP
0.78
wrp-+
FF4/CP
0.91
-0.13
wrp-+
--------------------------------------------------------------------------In general, the reports with and without timing derating should not
differ much.

Summary
In short, the two commands differ in many ways. If you run into
another situation
that is not explained in this article, contact the Synopsys
Technical Support Center.

Do both report_clock_tree and report_clock_timing


commands consider source latencies?
Doc Id: 028398 Product: IC Compiler
Average User Rating:

Save Article
Question:

Tag Article

Print

Last Modified: 10/22/2009


(1) Rate Article:

Send comment

Email

Do both report_clock_tree and report_clock_timing commands consider


source latencies?
Answer:

You should use the report_clock_tree -summary command for reporting


global skew
and the report_clock_timing -type skew command for reporting local
skew.
The differences are:

The report_clock_tree command considers network latencies


during clock tree synthesis.

The report_clock_timing command considers both source and


network latencies.

For example,
icc_shell> set_clock_latency -source 5 pclk
1
## report_clock_timing considers (source latency of 5.00 + network
latency of 0.23)
## 5.00 + 0.23 = 5.23 as latency
icc_shell > report_clock_timing -type latency -from pclk
Clock: PCI_CLK
--- Latency --Clock Pin
Trans
Source
Network
Total
--------------------------------------------------------------------------I_PCI_TOP/I_PCI_WRITE_FIFO/PCI_FIFO_RAM_1/CE2
0.27
5.00
0.23
5.23
wrp-+
--------------------------------------------------------------------------1
icc_shell> report_clock_timing -type skew
**************
**************************
Report : clock timing
-type skew
-nworst 1
-setup
Design : ORCA_TOP
Version: C-2009.06-ICC
Date
: Wed Jul 15 20:13:31 2009
****************************************
Clock: PCI_CLK

-from pclk

Clock Pin
Latency
Skew
--------------------------------------------------------------------------I_PCI_TOP/I_PCI_READ_FIFO/PCI_FIFO_CTL/U1/count_int_reg_3_/CP
5.23
wrp-+
I_PCI_TOP/I_PCI_READ_FIFO/PCI_FIFO_RAM_3/CE1
5.21
0.02
wrp-+
--------------------------------------------------------------------------1
##report_clock_tree considers only network latency as 0.23 and
reports skew
icc_shell> report_clock_tree -from pclk -summary
***************************************
Report : clock tree
Design : ORCA_TOP
Version: C-2009.06-ICC
Date
: Wed Jul 15 20:11:58 2009
********************************
============= Clock Tree Summary ==============
Clock
Sinks
CTBuffers
ClkCells Skew
LongestPath
TotalDRC
BufferArea
----------------------------------------------------------------------------------PCI_CLK
201
4
4
0.02
0.23
0
66.568
*********8

You might also like