Vous êtes sur la page 1sur 2

How to model CTS congestion during placement and pre-CTS optimization

How To...
I see congestion after CTS, due to heavy clock-tree buffering in a localized area. What is the best way to resolve this at
the placement stage instead of after CTS?

I tried creating cell padding on the CTS leaf cells using specifyCellPad. However, this did not solve the problem. Is
there an automated way to get the predictable post CTS congestion results after placement?

Answer
There are several methods that can be used within Encounter/Innovus to predict the CTS congestion during
place_opt_design. These features are designed for situations where congestion occurs after the clock trees are
inserted and optimized.

Early clock flow


The early clock flow is a limited access feature introduced in Innovus 16.1. The early clock flow does fast clock tree
clustering with CCOpt and annotates the latencies for timing optimization (you do not need to do any additional handling
of the clock latencies). The flow also enables the CCOpt ideal mode useful skew. Congestion analysis becomes aware of
the clock. In the early clock flow, you must define the clock tree specification before place_opt_design.

setDesignMode -earlyClockFlow true


create_ccopt_clock_tree_spec
place_opt_design

Global fast CTS (Quick CTS)


setPlaceMode -quickCTS introduced in EDI 14.26, is used with place_opt_design. In 16.1, this option has been
renamed to –place_global_fast_cts {true|false}.

The –place_global_fast_cts true option for quick CTS flow inside placement, uses CCOpt to create a fast zero
skew clock tree. The clock is still ideal for timing optimization, but the inserted clock buffers help in better estimation of
post CTS congestion during the placement stage. The CTS configuration should be moved before place_opt_design.

For these two options, the CCOpt CTS configuration is used to build the clock tree. For example, minimally define the
NDRs, buffers, inverters, and so on that CCOpt should use. Ideally, your full CCOpt CTS configuration should be in place
before place_opt_design. In this case, it does not have to be updated again before running your CTS step.

A sample flow is:

set_ccopt_property buffer_cells {CLKBUFX8 CLKBUFX12 CLKBUFX16 CLKBUFX20}


set_ccopt_property inverter_cells {CLKINVX8 CLKINVX12 CLKINVX16 CLKINVX20}
create_route_type -name clockRoute -non_default_rule 2w2s \
-top_preferred_layer Metal6 -bottom_preferred_layer Metal5
set_ccopt_property route_type clockRoute -net_type trunk

setPlaceMode –place_global_fast_cts true

Or,

setDesignMode –earlyClockFlow true

place_opt_design

The clock buffers may remain in the design, after the pre-CTS optimization. When CCOpt is run at the CTS stage, it
deletes the buffers and starts building the clock tree from scratch. If you want to manually delete the clock buffers for
some reason, use delete_clock_tree_repeaters.

If the design team prefers not to use one of the CTS methodologies, the net modeling methodologies are available. These
methods are not as accurate as the CTS versions.
Applying clock net attributes prior to placement
commit_ccopt_clock_tree_route_attributes introduced in Innovus 16.1, can be used with the early global route
(which is the default starting from 15.2), rather than the trial route. The command traces the clock tree as defined by the
CCOpt spec and applies the routing preferences such as, top_preferred_layer , bottom_preferred_layer,
non_default_rule, and shield_net based on the route_type CCOpt properties. The CTS configuration should be
moved before place_opt_design.

Example:

create_route_type -name clockRoute -non_default_rule 2w2s \


-top_preferred_layer Metal6 -bottom_preferred_layer Metal5
set_ccopt_property route_type clockRoute -net_type trunk
commit_ccopt_clock_tree_route_attributes
place_opt_design

Specifying the tracks required for clocks


Starting with release 14.1, the TrialRoute router was enhanced to consider the extra routing demand for clock nets, when
a clock specification has not been loaded. You can use the setTrialRouteMode -clkNetRoutingDemandInTracks
parameter to detect the clock nets and add extra tracks for the wires.

The following is the syntax of the new parameter:

setTrialRouteMode -clkNetRoutingDemandInTracks { positive # }

where, positive # is the number of tracks. Its default value is 1.

Check for the following message in the runlog when this switch is set to a value greater than 1:

There are clock nets (with default rule).


The option "-clkNetRoutingDemandInTracks 3" will be honored for all clock nets with
default rule.

To understand the behavior of the switch in detail:

Value of 1: This is the default behavior, no extra space is allocated for the clock nets.
Value of 2: This is the same as specifying an extra spacing of 1, which is called double spacing in NDR. This is a
replacement of preferred_extra_space 1.
Value of 2-5: As explained earlier, this translates to an extra spacing of value 1.
Note: Using an NDR along with this switch gives precedence to the NDR. For example, if the NDR has double spacing
and clkNetRoutingDemandInTracks is set to 3, you get an extra spacing of 1 (double spacing) on the clock nets.

Message:

There are <number> clock nets (<number> with NDR).


The option "-clkNetRoutingDemandInTracks 3" will not be honored for all <number>
clock nets with NDR.

Additionally, the following is also recommended for highly congested designs:

setPlaceMode -congEffort high

Note: The setTrialRouteMode -clkNetRoutingDemandInTracks <> command can be used in Encounter.


However, in Innovus it is recommended to use the following command for specifying the required tracks for the clocks.

setRouteMode -earlyGlobalNumTracksPerClockWire <value>

Return to the top of the page

Vous aimerez peut-être aussi