Clock Tree Latency Calculation Difference between reportClockTree & report_timing

Hi All,

I had the same problem by the past. I want to make script to calculate model, and teh two command report_clock_timing and reportClockTree did not report the same latency. I used these two command on a routed adtabase and by reading a dspf file. So no extraction under
encounter ... and the two command gave me two different latencies. I do not remember to have a clean status on this difference by Cadence support.
The only thing is that the two command sdo not use the same method to calculate the latency. The cadence answer was that reportClockTree use the CTS infrastucture (read by cts specification file) and report_clock_timing the CTE infrastructure (from SDC file). This second
command use the setAnalysisMode status.
There is also a reportClockTreeOCV command. I had this problem with encounter 5 and 6 version. Now I am working with 71 but I do not try again these
commands.
You can try to run your two commands with verbose mode and compare the slew for each level. Generally you have a small differnce for each level, but a lot of small gives a big.

report_clock_timing is the same command that you can find under prime time:

-type report_type
Specifies the type of report to be
generated. Allowed values are as
follows:
transition - To specify a transition
time report.
latency - To specify a latency report.
skew - To specify a skew report; you
cannot use the -launch, -capture,
-rise, -fall, and -lesser_than options
if you specify a skew report, and you
can use the
-include_uncertainty_in_skew option
only in a skew, interclock_skew or
summary report.

interclock_skew - To specify an
interclock skew report; you cannot use
the -launch, -capture, -rise, -fall,
and -lesser_than options if you specify
an interclock skew report, and you can
use the -include_uncertainty_in_skew
option only in a skew, interclock_skew
or summary report.

summary - To specify a summary report,
which shows the worst instances of
transition time, latency and skew over
the clock network(s) or sub-network(s)
of interest. You can use only the
-clock, -to_list, -from_list,
-include_uncertainty_in_skew, -nosplit,
and -significant_digits options if you
specify a summary report.
-setup Indicates that only the setup data path
is to be used in the report, and that
the skews, latencies or transition times
reported must correspond to those used
by report_timing in the verification of
setup constraints. -setup and -hold are
mutually exclusive; if neither is
specified, -setup is assumed. This
option cannot be used in summary
reports.
-nworst worst_entries
Specifies the number of worst report
entries to be reported per clock domain;
the default is 1. Entries are sorted
with respect to the attribute of
interest (transition time, latency or
skew) specified with -type report_type.

The worst entries are those most likely
to cause a violation. For example, if
you request a latency report using
-setup and -capture, the smallest
worst_entries are listed, sorted in
ascending order, because small capture
latencies for setup paths are more
likely to lead to a violation than large
capture latencies. By contrast, for skew
reports, the worst entries always
correspond to the largest skews over the
specified domain. This option cannot be
used in summary reports.

Regards ...[b] [/b][b] [/b][b] [/b]

Hi All,

I had the same problem by the past. I want to make script to calculate model, and teh two command report_clock_timing and reportClockTree did not report the same latency. I used these two command on a routed adtabase and by reading a dspf file. So no extraction under
encounter ... and the two command gave me two different latencies. I do not remember to have a clean status on this difference by Cadence support.
The only thing is that the two command sdo not use the same method to calculate the latency. The cadence answer was that reportClockTree use the CTS infrastucture (read by cts specification file) and report_clock_timing the CTE infrastructure (from SDC file). This second
command use the setAnalysisMode status.
There is also a reportClockTreeOCV command. I had this problem with encounter 5 and 6 version. Now I am working with 71 but I do not try again these
commands.
You can try to run your two commands with verbose mode and compare the slew for each level. Generally you have a small differnce for each level, but a lot of small gives a big.

report_clock_timing is the same command that you can find under prime time:

-type report_type
Specifies the type of report to be
generated. Allowed values are as
follows:
transition - To specify a transition
time report.
latency - To specify a latency report.
skew - To specify a skew report; you
cannot use the -launch, -capture,
-rise, -fall, and -lesser_than options
if you specify a skew report, and you
can use the
-include_uncertainty_in_skew option
only in a skew, interclock_skew or
summary report.

interclock_skew - To specify an
interclock skew report; you cannot use
the -launch, -capture, -rise, -fall,
and -lesser_than options if you specify
an interclock skew report, and you can
use the -include_uncertainty_in_skew
option only in a skew, interclock_skew
or summary report.

summary - To specify a summary report,
which shows the worst instances of
transition time, latency and skew over
the clock network(s) or sub-network(s)
of interest. You can use only the
-clock, -to_list, -from_list,
-include_uncertainty_in_skew, -nosplit,
and -significant_digits options if you
specify a summary report.
-setup Indicates that only the setup data path
is to be used in the report, and that
the skews, latencies or transition times
reported must correspond to those used
by report_timing in the verification of
setup constraints. -setup and -hold are
mutually exclusive; if neither is
specified, -setup is assumed. This
option cannot be used in summary
reports.
-nworst worst_entries
Specifies the number of worst report
entries to be reported per clock domain;
the default is 1. Entries are sorted
with respect to the attribute of
interest (transition time, latency or
skew) specified with -type report_type.

The worst entries are those most likely
to cause a violation. For example, if
you request a latency report using
-setup and -capture, the smallest
worst_entries are listed, sorted in
ascending order, because small capture
latencies for setup paths are more
likely to lead to a violation than large
capture latencies. By contrast, for skew
reports, the worst entries always
correspond to the largest skews over the
specified domain. This option cannot be
used in summary reports.

Regards ...[b] [/b][b] [/b][b] [/b]