EDI Application Note for Clock Tree Debugging Techniques

Cadence Design Systems, Inc.

Application Note

Clock Tree Synthesis Debugging Techniques

Encounter Digital Implementation (EDI) System

Rev 1.0

July 2011

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 1
 EDI Application Note for Clock Tree Debugging Techniques

Table Of Content

Purpose ............................................................................................................................... 3
Audience ............................................................................................................................. 3
Overview ............................................................................................................................. 3
1. Debugging the clock QoR issue ................................................................................ 4
2. Debugging CTS PreRoute issues .............................................................................. 5
1. Transition Violation: ............................................................................................................ 5
1. Debugging Transition Violation ................................................................................... 5
2. Fixing Transition violation: .......................................................................................... 6
2. Latency Violation................................................................................................................. 6
1. Debugging Latency Violation ...................................................................................... 6
2. Fixing Latency Violation: ............................................................................................. 7
3. Skew Violation..................................................................................................................... 8
1. Debugging Skew Violation .......................................................................................... 8
2. Fixing Skew Violation: ................................................................................................. 9
3. Debugging CTS clkRouteOnly issues ....................................................................... 9
1. Debugging Routing Issue ............................................................................................. 9
2. Fixing Skew Violation: ............................................................................................... 10
3. Debugging CTS postCTS issues ............................................................................. 11
1. Debugging post CTS Routing Issue ........................................................................... 11
2. Fixing Skew Violation: ............................................................................................... 11
4. Debugging Long Run Time ...................................................................................... 12

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 2
 EDI Application Note for Clock Tree Debugging Techniques

Purpose
This document provides information about different debugging techniques for improving Clock
Tree Synthesis (CTS).

Audience
This document is meant for users and designers performing Clock Tree Synthesis (CTS) using
the Encounter Digital Implementation (EDI) system versions 9.1 and 10.1

Overview
This document provides information about debugging and fixing CTS issues.

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 3
 EDI Application Note for Clock Tree Debugging Techniques

1. Debugging the clock QOR issue

To start debugging, first determine the stage at which CTS quality of results (QOR) turn bad.
This could be (preRoute, clkRouteOnly, postCTS or postRoute stages).

Clock QOR issues

Is QOR bad Y
before routing? Debugging CTS PreRoute issues
(preRoute)

Is QOR turnings Y
bad after clock Debugging CTS clkRouteOnly issues
only routing?
(clkRouteOnly)

Is QOR turning Y
bad postCTS? Debugging CTS postCTS issues
(postRoute)

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 4
 EDI Application Note for Clock Tree Debugging Techniques

2. Debugging CTS PreRoute issues

1. Transition Violation:

1. Debugging Transition Violation

Check the log file:

Check the warning messages in the log file. This may provide hints for improper clock
constraints, settings or poorly characterized libraries. These issues can cause transition
violations that might not be fixable. Look for message codes: ENCCK-6002, 6003, 6004,
6005, 6009, 6314, 6315, 6316, 6320, 6317, 6322.
For example:
**WARN: (ENCCK-6002): The input capacitance of cell RAM2P_128x32 (CLKB) is
0.168pF, (timing library RAM2P_128x32_slow_syn is 0.168pF, macro-model definition
is 0.000pF), which may make it difficult to meet max sink transition constraint. Number
of leaf instances having this cell type = 1.
Check if RootInputTran setting is worse than SinkMaxTran and bufMaxTran.

Check if there are placement blockages that prevent the tool from inserting a buffer to fix
the DRV. A possible log file message is: cannot find a reasonable buffer location for
insertion.

Check if clock instances are set to DontTouch or Fixed These settings prevent DRV
from being fixed by upsizing cell.

Check if the pin is placed in an un-routable area (caused by routing blockage).

Transition violations caused by routing include:

o Wire detouring due to blockage modeling, and
o Change of routing layer

Transition violations caused by unreasonable huge pin cap in .lib or in macromodel.

Check for the following logfile message
**WARN: (SOCCK-3305): 0: Term abc_reg has huge inputcap = 100.00PF

Transition violations caused when the cell specified in the library has scalar output
transition that already violates the requirement.
#Example of scalar output transition
rise_transition( scalar ){
values (400);}

Transition issue caused by buffer driving too high fanout (more than 50).

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 5
 EDI Application Note for Clock Tree Debugging Techniques

2. Fixing Transition violation:

Use the following to fix the transition violation issues:
Specify ForceMaxTran Yes in the spec file otherwise BufMaxTran and
SinkMaxTran are soft constraints. If the violation is around 1000ps, then using
ForceMaxTran Yes does not help because it cannot fix such a big violation.

For fixing the transition violations use command ckECO fixDRVOnly.

For transition violations caused by routing issues do the following:

o Wire Detouring: CTS internals default blockage modeling is two-

dimensional and requires two layers (H and V) to form polygon. If not, it does
not see the blockage and routes directly to the pin. Use the command
setCTSMode routeBlockageHV true to block the H/V layers on
the blockages.

o Changing Layer: CTS expects routing layer to be the preferred routing layer
but actual nanoRoute uses non-preferred routing layer that has a much bigger
RC. To fix this check the nanoRoute option of preferred routing layer.

For huge pin cap issue, change the capacitance to less than 1pF. Anything more is
considered big.
MacroModel pin abc_reg 0.2ns 0.2ns 0.2ns 0.2ns 1pF

For high fanout issue, use set MaxFanout 50 in the clock specification file.

2. Latency Violation

1. Debugging Latency Violation

Check the log file:

Check for the following warnings messages in the log file: ENCCK-6336, 6337, 6338.
**WARN: (ENCCK-6336): Clock clk includes equivalent gates that have overlap
between the bounding boxes of their leaf pins. This may be due to cloning without
adequate placement information. Consider the following instances for declining followed
by physical cloning:
clk_latch
FECTS_CLONE_I7
FECTS_CLONE_I1
**WARN: (ENCCK-6338): The instance rcc_clk__L2_I0 of clock g140/ZN is outside the
bounding box of its immediate sinks and the clock source by 99.1uM. This placement may
lead to detour in the clock path through this instance.
Tight constraints such as MaxTran, MaxCap or MaxFanout increase the latency.

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 6
 EDI Application Note for Clock Tree Debugging Techniques

Clock gating Instances set to FIXED or DontTouch before synthesis impact latency.

Routing layer assignment may impact latency due to different RC characteristics.

Buffer List may be too limited. For example buffer with big driving strength is not
included.

Clock tree already has many levels before synthesis. For example 20.

Clock tree buffers are not removed completely before CTS.

Macromodels having large pin capacitance or clock pin of instances in timing libraries
have large input pin capacitance.

Floorplan has an irregular shape block, for example U shape.

2. Fixing Latency Violation:

Use the following settings to fix the latency
setCTSMode optLatency true synthLatencyEffort high
setCTSMode moveGate true moveGateLimit 10000

Ensure that big buffers are listed in the clock specification file

Check whether clock instances have DontTouch, DontUse attributes or FIXED placement
attribute.
o reportDontUse
o get_property [get_lib_cells <cell_name>]is_dont_touch
o get_property [get_lib_cells <cell_name>]is_dont_use

Use higher routing layers if there are fewer cell/routing blockages in those layers.

Use non-default rule and multi-cut vias for routing, or choose higher routing layers that
have smaller RCs.

To display the paths with minimum and maximum latency open Global Clock Debug
(Clock->Debug Clock Tree) and select Tool => Find Object > Min/MaxPath
(displayClockMinMaxPaths)

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 7
 EDI Application Note for Clock Tree Debugging Techniques

3. Skew Violation

1. Debugging Skew Violation

Check the log file for the following warning messages:

**WARN: (ENCCK-6323): The placement of clk_gated__L4_I27 was moved by 5.07
microns during refinePlace. Original location:: (195.5 169.74), Refined location ::
(194.12 166.05)

Check if skew degradation is caused by transition fixing.

o Check if there are bad transition violations in the report. For example 1ns against
300ps constraint. Bad slew causes long delay and therefore bad skew.
# Complete Clock Tree Timing Report

(Actual) (Required)
Trig. Edge Skew : 1872(ps) 200(ps)
Max. Rise Buffer Tran : 1380.6(ps) 250(ps)

***** Max Transition Time Violation *****

Pin Name (Actual) (Required)
-------------------------------------------------------
FE_clk__L4_I3/I [1380.6 1360.7] (ps) 250(ps)

Check if skew degradation is caused by physical constraints.

o Placement obstruction (blockage) limits CTSs freedom in finding the optimal

location for the clock driver where the route is the shortest and is able to achieve
equal load for each receiver.
more blockages imply less optimal location for the buffers

o Uniform distribution of flops are easier to balance than non-uniform distribution

of flops

o Check if instances are set to Fixed or DontTouch unintentionally.

When an instance is set to Fixed or dont_touch, CTS is not able to
resize it if it is causing a skew or bad slew and long insertion delay issue.

o Choose higher routing layers if routing blockages at those layers are less.

Check if skew degradation is caused by Clock Structure. Gated clock is more difficult to
balance than free running clock.

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 8
 EDI Application Note for Clock Tree Debugging Techniques

A higher number of clock tree levels mean greater difficulty in balancing. Anything more
than 10 levels can be considered high.

Uneven gated structure raises the difficulty level.

o Uneven here means a wide range and widespread Fanout. For example, the
biggest gate drives 1000 flops, the smallest drives 2 flops and Gated level
sometimes have flops with 1 level gated, some have more than 8 levels.

In general, a symmetric buffer or inverter gives better skew than a non-symmetric one in
mixed inversion clock structure.
o Mixed inversion clock is the clock domain that has both rising and falling edge
flops, and non-inverting and inverting clock paths.

More re-convergent paths mean more paths to be balanced. That results longer insertion
delay and more buffer count.

2. Fixing Skew Violation:

Use the following to fix skew violations:
Previous fixing tips on transition and latency can also apply here.

Use LeafPinGroup and DynamicmacroModel to reduce the skew.

If possible, break Reconvergent path.

Provide wide range of buffer choices for CTS.

It worth to try running ckECO multiple times.

Set MaxSkew to 0 does not always give best result

3. Debugging CTS clkRouteOnly issues

1. Debugging Routing Issues

Check the log file for the following warnings:

**WARN: (ENCCK-6327): The final routing for net "clk" is significantly different from
the pre-route estimation. Pre-route length estimation: total = 37.325000 microns, max
path length = 37.325000 microns; Routed result: total = 57.225000 microns, max path
length = 57.225000 microns.

**WARN: (ENCCK-6328): The utilization of preferred routing layers (layer M5 to M6)

for net "clk__L1_N0" is 0.895796

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 9
 EDI Application Note for Clock Tree Debugging Techniques

Correlation between CTSs estimation and actual routing by NanoRoute can cause QOR
to turn bad after routing.

o Wire topology difference or clock wire detour. Follow the procedure detailed
below to debug the wire topology difference:

Use Display Clock Tree Obstruction form (Clock->Display->Display

Obstruction) to display the obstruction seen by CTS.
Use displayClockTreeMinMaxPaths pin to compare the clock
delay for preRoute and ClkRouteOnly modes.
Run displayClockTree skew allLevel preRoute to see
the RouteGuide displayed in yellow colors.

o Routing layer difference where CTS always assume preferred layers are used but
non-preferred layer is chosen by NanoRoute for certain segment. The root cause
can be:

CTS: Obstruction modeling, route guide generation issue. The internal

obstruction model of CTS does not follow the actual physical obstruction.
It uses some heuristics to speed up run time without causing QOR impact
for most cases.
NanoRoute: Effort level in choosing the preferred layers, jogging of
wires, not following route guide, routing congestion.

2. Fixing Skew Violation:

Run ckECO postCTS |clkRouteOnly to fix the issue after CTS Routing

Choose a routing layer that has fewer routing blockages

Avoid mixing routing layers that have a big difference in RC.

o Check the RC table in the log file (when specifyClockTree is run)
o CTS takes the average RC to estimate the wire delay (shown in pre-Route clock
report)
o Limit CTS to two routing layers to achieve better correlation between CTS and
NanoRoute.

Use PreferredLayerEffort Medium because although high will yield the best
result, in may cause DRC violation.

To override CTS obstruction modeling, use the following:

CellObstruction
+ cellName Entire|Ignored|Detailed|HV

InstanceObstruction
+ instanceName Entire|Ignored|Detailed|HV

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 10
 EDI Application Note for Clock Tree Debugging Techniques

3. Debugging CTS postCTS issues

1. Debugging post CTS Routing Issue

RC Correlation issue is caused a difference in RC parasitic model between clkRouteOnly

and PostCTS mode. This is detailed below

o clkRouteOnly
Length-based
unit length capacitance is C for each Layer
unit length resistance is R for each Layer
Enclosure model

o PostCTS
Grid-based
unit length capacitance is C for each Layer in each grid
unit length resistance is R for each Layer in each grid
Wire density model

2. Fixing Skew Violations:

Run displayClockTreeMinMaxPaths pin to search for the net that has a big
difference in capacitance (Load) between the two modes.

Run ckECO postCTS. This might fix the skew violation.

For RC correlation, use the following variable to avoid local congestion:

setenv CK_EVEN_CHANNEL_PLACEMENT 1
setCTSMode -placeWithChannelSpreading true
setenv CK_MAX_CHANNEL_SPREADING_WIDTH 80.0 ;

For routing correlation, remove all power routing and unblock all memories using
forceClockTreeBlockage
o Set routeBlockageHV true

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 11
 EDI Application Note for Clock Tree Debugging Techniques

For RC grid model, use the below setting before performing the CTS.

setCTSMode -rcAdvancedCorrelation true

setCTSMode considerpinAccessViaRes true
setCTSMode -rcGridModel true useEffCap true
setExtractRCMode -engine preRoute
setExtractRCMode -prerouteClkCapHighAccuracy true
specifyClocktree genRCGrid
Note: For 10.1 and later releases, use the command setCTSMode
rcCorrelationAutoMode true to invoke all the settings mentioned above.

4. Debugging Long Run Time

The first step to debug is to check the log file and determine which command and which
section is increasing the run time.
For example: during latency reduction
resized 0 standard cell(s).
inserted 0 standard cell(s).
*** Optimized Clock Tree Latency (cpu=0:22:09 mem=993.8M) ***
For Example: during post optimization of skew
Inserted cell (CTBUFLLX4):i_c8ves_ves_comp/i_c8ifp_top/clk_ifp_gated__I50
resized 207 standard cell(s).
inserted 50 standard cell(s).
*** Gated Clock Tree Optimization (cpu=0:08:59 mem=1370.8M) ***

If long run time is observed in clock tree construction, determine the net (sub-tree) for
which CTS is taking a long run time
o Investigate if there is anything abnormal on the net. For Example: placement
blockage prevents CTS from adding buffer.
o Common root cause for long clock tree construction is fixing DRV or inserting
buffer chain

Long run time can be caused by CTS spending effort in meeting skew and latency. A
good way to debug is to reduce the effort level by using the following settings:
setCTSMode verbose true # verbose true gives more detailed log message
setenv CKTDDEBUG 1
Set MaxSkew to 100ns
Set MaxDelay to 100ns
Re-run CTS

Another option is to try out multi-CPU CTS using the following settings:
setBetaFeature CTS-MT 1
setMultiCpuUsage localCpu <num>

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 12
 EDI Application Note for Clock Tree Debugging Techniques

Many narrow channels take time to evaluate a routing channel to route the clock nets.
Use forceClockTreeBlockage to block the whole block.

forceClockTreeBlockage [-name routeTypeName] [-block

cell/inst names] [-unblock cell/inst names]

COPYRIGHT 2011, CADENCE DESIGN SYSTEMS, INC.

ALL RIGHTS RESERVED. PAGE 13