Problem solved. See the following :
dc_shell> man set_clock_gate_latency
2. Synopsys Commands Command Reference
set_clock_gate_latency
NAME
set_clock_gate_latency
Specifies clock network latency values to be used for clock-gat-
ing cells, as a function of clock domain, clock-gating stage and
fanout.
SYNTAX
status set_clock_gate_latency
[-clock clock_list]
[-overwrite]
-stage cg_stage
-fanout_latency cg_fanout_list
[-transitive_fanout]
Data Types
clock_list list
cg_stage integer
cg_fanout_list string
ARGUMENTS
-clock clock_list
Specifies that the latency must be applied with respect to the
specified clocks. If the -clock option is not specified, the
latency is applied with respect to all clock domains to which
the clock-gating cell belongs.
-overwrite
Specifies that clock latency values previously set on clock-gat-
ing cells should be overwritten.
-stage cg_stage
Specifies the clock-gating stage to which the clock latency data
from the fanout range is applied. Registers are considered as
stage 0.
-fanout_latency cg_fanout_list
Specifies the list of clock-gating cells fanout and clock
latency values; for example, {1-5 0.9, 6-20 0.5, 21-inf 0.3}. A
fanout of 1 to 5 has a latency of 0.9; a fanout of 21 or larger
has a latency of 0.3. If the same latency value is wanted for
the entire fanout range, it can be specified as {1-inf 0.9}.
-transitive_fanout
Specifies that transitive fanout should be used instead of
direct fanout when annotating clock gate latency. Direct fanout
is the default.
DESCRIPTION
The set_clock_gate_latency command allows you to specify clock network
latency values for clock-gating cells, as a function of clock domain,
clock-gating stage, and fanout. These latency values are annotated on
the clock pins of clock-gating cells when running the compile_ultra
command, or when running the apply_clock_gate_latency command.
The clock-gate latency settings specified using the
set_clock_gate_latency command are stored as an attribute on the source
port of each specified clock. Invoke this command after defining all
clocks of the design. These stored latency values are annotated on the
clock pins of clock-gating cells by means of one of the following pro-
cesses:
o Using the apply_clock_gate_latency command, which applies latency on
any existing clock-gating cells
o During compile_ultra command, which applies latency on any existing
clock-gating cells or those inserted or modified during the compile
NOTE: The stages of the clock gating network are numbered from 0 for
the register stage number and increasing toward the clock source. For
example, in a four stage clock gating tree, Stage 0 drives register
clocks directly, and Stage 3 is the clock gating cell with its input
directly connected to the clock source.
Use the set_clock_gate_latency command to specify the latency for gated
registers by specifying the command for stage 0. By definition stage 0
has no fanout, so use the following syntax:
prompt> set_clock_gate_latency -stage 0 -fanout_latency \
{ 1-inf value }
When clock latency settings are provided for stage 0, the values are
annotated on the output pin (enabled clock pin) of each clock-gating
cell that is directly driving gated registers. If no clock latency is
set for stage 0, but a clock latency has been set on the clock object
by using set_clock_latency command, then this value is used for clock
latency. For ungated registers, the latency is propagated by the timer
from the clock object latency.
You can use the -clock and -overwrite options with the -stage 0 option.
Use the -transitive_fanout option to calculate latency value based upon
the transitive fanout of a clock-gating cell instead of the direct
fanout. The transitive fanout of a clock-gating cell is defined as the
total number of all driven leaf registers. The registers driven by a
stage 1 clock-gating cell, ICG_1, are counted as part of the transitive
fanout of the stage 2 clock-gating cell, ICG_2, that drives ICG_1. By
definition:
stage 2 transitive fanout >= stage 1 transitive fanout
NOTE: Transitive fanout only counts registers, unlike the direct fanout
which counts both registers and driven clock-gating cells.
When the -transitive_fanout option is used for the first time, a fanout
mode is set, and this is indicated by the PWR-916 information message.
You cannot mix fanout modes of the set_clock_gate_latency command,
where some instances use the -transitive_fanout option and others do
not. If you want to switch between fanout modes, use the
reset_clock_gate_latency command.
If you specify fanout ranges in the cg_fanout_list and you do not cover
all values from 1 to inf, the fanout ranges with missing latency infor-
mation are filled by the tool with the smallest latency value from the
adjacent ranges.
In a clock tree, latency values are lowest for cells closest to the top
of the tree (clock source). Transitive fanout values are highest for
cells at the source and decrease toward the registers. Therefore, spec-
ified clock latency values must decrease with respect to fanout ranges
otherwise a PWR-742 warning message is generated.
If clock latency settings are not specified for a certain clock-gating
stage and a clock-gating cell within this stage exists, the latency is
propagated from the driving clock-gating cell or from clock object
latency, and a warning message is issued. These actions are performed
during the annotation process:
apply_clock_gate_latency or compile_ultra command.
If specified clock latency values do not decrease with respect to clock
gating stages, the PWR-744 warning message is generated. This check is
disabled if the -transitive_fanout option is used. In addition, if an
inconsistent clock latency annotation is detected when running the
apply_clock_gate_latency or compile_ultra command, the tool attempts to
fix it by assuming the smallest value from the clock latencies anno-
tated on gated clock-gating cells or registers. This ensures that
clock latencies are monotonically increasing values in the path going
from the clock source to the gated registers. The following actions
can be performed by the tool to achieve this:
o If clock-gating cell A is directly driving one or more registers,
and some clock latency settings have been provided for the timing of
these gated registers (by using value 0 for the -stage option of
set_clock_gate_latency command or by propagation of latency specified
for clock object), and the latency annotated on cell A is higher than
the latency provided for gated registers, then the latency on clock-
gating cell A is overwritten with the latency provided for gated reg-
isters. If this fix is done, the PWR-746 warning message is gener-
ated.
o If clock-gating cell A is driving another clock-gating cell B, and
the clock latency set on A is higher than the one set on B, the tool
resolves it by overwriting the clock latency on A with the value set
on B. If this fix is done, the PWR-746 warning message is generated.
To remove the settings specified using set_clock_gate_latency, use the
reset_clock_gate_latency command.
If the variable power_cg_physically_aware_cg is enabled, then the anno-
tation of latency values from set_clock_gate_latency is disabled.
Multicorner-Multimode Support
This command is scenario dependent and affects the current scenario
only.
The actual clock latency annotation performed during the execution of
the compile_ultra or apply_clock_gate_latency commands is done for all
the scenarios for which a clock latency value is available.
EXAMPLES
The following example specifies the clock latency values for the com-
plete fanout range of clock-gating cells for stages 1, 2, and 3. This
latency data applies to the clock-gating cells whose clock pins belongs
to clock clk1.
prompt> set_clock_gate_latency -clock [get_clocks clk1] -stage 1 \
-fanout_latency {1-30 2.1, 31-100 1.7, 101-inf 1.1}
prompt> set_clock_gate_latency -clock [get_clocks clk1] -stage 2 \
-fanout_latency {1-5 0.9, 6-20 0.5, 21-inf 0.3}
prompt> set_clock_gate_latency -clock [get_clocks clk1] -stage 3 \
-fanout_latency {1-10 0.28, 11-inf 0.11}
In the following example, fanout ranges specified in the
-fanout_latency cg_fanout_list do not cover all values from 1 to inf.
In this case, the tool assumes a clock latency value of 1.7 to be
applied to fanout range 11-30 and a clock latency of 1.1 for fanouts
higher than 80.
prompt> set_clock_gate_latency -stage 1 \
-fanout_latency {1-10 2.1, 31-80 1.7, 101-300 1.1}
The following example shows how to specify and annotate different clock
latency values using the transitive fanout.
prompt> set_clock_gate_latency -clock [get_clocks clk1] -stage 1 \
-fanout_latency {1-30 2.1, 31-100 1.7, 101-inf 1.1} \
-transitive_fanout
prompt> set_clock_gate_latency -clock [get_clocks clk1] -stage 2 \
-fanout_latency {1-5 0.9, 6-20 0.5, 21-inf 0.3} \
-transitive_fanout
The following example shows how to specify and annotate different clock
latency values for different multicorner-multimode scenarios.
prompt> current_scenario sc1
prompt> set_clock_gate_latency -stage 1 \
-fanout_latency {1-inf 0.11}
prompt> current_scenario sc2
prompt> set_clock_gate_latency -stage 1 \
-fanout_latency {1-inf 0.15}
prompt> compile_ultra -gate_clock
SEE ALSO
apply_clock_gate_latency(2)
power_cg_physically_aware_cg(3)
remove_clock_latency(2)
report_clock_gating(2)
reset_clock_gate_latency(2)
set_clock_latency(2)
Home
Help
Search
Login
Register
