Static Timing Analysis

Encounter™ Timing Closure Guide
Product Version 4.2.1

June 2005
 2002-2005 Cadence Design Systems, Inc. All rights reserved.
Printed in the United States of America.
Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in
this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s
trademarks, contact the corporate legal department at the address shown above or call 800.862.4522.
All other trademarks are the property of their respective holders.
Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this
publication may violate copyright, trademark, and other laws. Except as specified in this permission
statement, this publication may not be copied, reproduced, modified, published, uploaded, posted,
transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants
you permission to print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used solely for personal, informational, and noncommercial purposes;
2. The publication may not be modified in any way;
3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other
proprietary notices and this permission statement; and
4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be
discontinued immediately upon written notice from Cadence.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. The information contained herein is the proprietary and confidential
information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence’s
customer in accordance with, a written agreement between Cadence and its customer. Except as may be
explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any
representations or warranties as to the completeness, accuracy or usefulness of the information contained
in this document. Cadence does not warrant that use of such information will not infringe any third party
rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of
such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Encounter Timing Closure Guide
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1
Timing Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Recommended Timing Closure Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Validating the Netlist and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Checking Timing Constraint Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Validating Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Resolving Footprint Inconsistencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Validating the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Generating the Capacitance Table File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Pre-Placement Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Optimizing the Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Netlist-to-Netlist Optimization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Guidelines for using N2N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Recommended Use of the runN2NOpt Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Troubleshooting a Lengthy N2N Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Floorplanning and Initial Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Ensuring Routability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Timing-Driven Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Troubleshooting Timing and Congestion Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Pre-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Guidelines for Pre-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Pre-CTS optDesign Command Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Improving Pre-CTS Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Clock Tree Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
June 2005 1 Product Version 4.2.1

Creating the Clock Specification File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Synthesizing the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Optimizing the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Clock Specification File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sample CTS Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Post-CTS Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Post-CTS Optimization Command Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Checking Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Detailed Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Improving Timing during Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Routing Command Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Timing Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Post-Route Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Fixing Timing and Design Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Resolving Signal Integrity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Modifying the Default Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Timing Sign Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A
Timing Closure Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

About This Guide
The Cadence® Encounter™ family of products provides an integrated solution for an RTL-to-
GDSII design flow. This document addresses issues related to timing closure for challenging
designs. It presents a recommended task flow and provides tips on how to resolve or avoid
common timing closure problems typically found in a design.
Audience
This manual is written for experienced designers of digital integrated circuits. Such designers
must be familiar with design planning, placement and routing, block implementation, chip
assembly, and design verification. Designers must also have a solid understanding of UNIX
and Tcl/Tk programming. This manual also assumes that you are familiar with the operation
of Cadence Encounter design tools.
Before starting a new project, you should be familiar with the commands and options used in
the tools and have a basic understanding about how the Encounter software interprets LEF
constructs and timing constraints.
How This Manual Is Organized

This manual contains one main chapter, which is organized to correspond to the design flow
for closing timing on a design. There is also an appendix which provides a copy of the entire
timing closure script for reference.

About This Guide
Conventions Used in This Manual

This section describes the typographic and syntax conventions used in this manual.
text Indicates text that you must type exactly as shown. For
example:
analyze_connectivity -analyze all
text Indicates information for which you must substitute a name

or value.
In the following example, you must substitute the name of a
specific file for configfile:
wroute -filename configfile
text Indicates the following:

■ Text found in the graphical user interface (GUI),
including form names, button labels, and field names
■ Terms that are new to the manual, are the subject of
discussion, or need special emphasis
■ Titles of manuals
[ ] Indicates optional arguments.
In the following example, you can specify none, one, or
both of the bracketed arguments:
command [-arg1] [arg2 value]
[ | ] Indicates an optional choice from a mutually exclusive list.

In the following example, you can specify any of the
arguments or none of the arguments, but you cannot
specify more than one:
command [arg1 | arg2 | arg3 | arg4]
{ | } Indicates a required choice from a mutually exclusive list.

In the following example, you must specify one, and only
one, of the arguments:
command {arg1 | arg2 | arg3}

About This Guide
{[ ] [ ]} Indicates a required choice of one or more items in a list.

In the following example, you must choose one argument
from the list, but you can choose more than one:
command {[arg1] [arg2] [arg3]}
{ } Indicates curly braces that must be entered with the

command syntax.
In the following example, you must type the curly braces:
command arg1 {x y}
... Indicates that you can repeat the previous argument.

. Indicates an omission in an example of computer output or
.
. input.
Command – Subcommand Indicates a command sequence, which shows the order in

which you choose commands and subcommands from the
GUI menu.
In the following example, you choose Floorplan from the
menu, then Power Planning from the submenu, and then
Add Rings from the displayed list:
Floorplan – Power Planning – Add Rings
This sequence opens the Add Rings form.
Related Documents
For more information about the Encounter family of products, see the following documents.
You can access these and other Cadence documents with the CDSDoc online documentation
system.
■ Encounter Database Access Command Reference
Lists all of the Encounter database access commands and provides a brief description
of syntax and usage.
■ Encounter Known Problems and Solutions
Describes important Product Change Requests (PCRs) for the Encounter family of
products, including solutions for working around known problems.
■ Encounter Library Development Guide

About This Guide
Describes library development guidelines for the independent tools that make up the
Encounter family of products.
■ Encounter Menu Reference
Provides a detailed reference of all the menu options and forms of the Encounter user
interface.
■ Encounter Text Command Reference
Describes the Encounter text commands, including syntax and examples.
■ Encounter User Guide
Describes how to use the various features and tools of the Encounter family of products.
■ What’s New in Encounter
Provides information about new and changed features in this release of the Encounter
family of products.
■ README file
Contains installation, compatibility, and other prerequisite information, including a list of
product change requests (PCRs) that were resolved in this release. You can read this file
online at downloads.cadence.com.
For a complete list of documents provided with this release, see the CDSDoc library.
6/10/05

1
Timing Closure
Achieving timing closure on a design is the process of creating a design implementation that
is free from logical, physical, and design rule violations and meets or exceeds the timing
specifications for the design. For a production chip, all physical effects, such as metal fill and
coupling, must be taken into account before you can confirm that timing closure has been
achieved.

Timing Closure
Recommended Timing Closure Flow

The following figure shows the recommended timing closure flow with the steps used during
the prototyping and sign-off design stages of the flow. The continuous convergence
methodology provides increasing accuracy as the design progresses through the flow. The
sign-off processes provide the greatest accuracy, but require longer run times than the earlier,
prototyping processes.
Data Preparation RC
Extraction Route STA
Pre-Placement Optimization
Floorplanning and Initial Placement
Full Trial Route
Static Timing Analysis

Pre-CTS Optimization
Default
Clock Tree Synthesis
Post-CTS Optimization
Detailed Routing
Detailed
Post-Route Optimization
Timing Sign Off

Timing Closure
Data Preparation C DataPrep

PPO
When you start a new project, you first have to determine whether the
design data is valid and consistent. Unless the data has already been FP/IP
checked and validated, you should assume that there are Pre-CTS
inconsistencies and other problems that must be resolved before
CTS
proceeding.
Post-CTS
The goals of data preparation include: Route
PRO
■ Confirming that the Encounter system has a complete and
consistent set of design data (all library views and versions must Timing Sign Off
be consistent). See “Validating the Netlist and Libraries” on page 9.
■ Ensuring that all tools in the flow interpret the timing constraints consistently. See
“Validating Timing Constraints” on page 11.
■ Validating the floorplan (if one is provided). See “Validating the Floorplan” on page 12.
■ Making sure that the footprint file is correct. See “Resolving Footprint Inconsistencies”
on page 11.
■ Creating a capacitance table file that matches the process technology.“Generating the
Capacitance Table File” on page 12.
■ Correlating parasitics among the prototyping and sign-off extraction tools. See
“Generating the Capacitance Table File” on page 12.
It is helpful to keep a log of all your runs including notes of your expectations for the run and
how you resolved any problems. Inserting comments in script files help you track changes you
make as you refine the process.
Validating the Netlist and Libraries

You must have a complete set of data to validate the libraries and netlist. The Encounter
configuration file specifies all of the library and design data loaded into memory. The libraries
and netlist should have no errors or warnings.
■ Library mismatches
The loadConfig command displays warning and error messages about mismatches
between timing and physical libraries. You may have missed loading a LEF file, or there
is an inconsistency between the timing libraries and physical libraries specified in the
configuration file.

Timing Closure
■ Nets should be optimized with assign statements

Check the Verilog netlist for assign statements. If assign statements exist, use one of the
following procedures to enable optimization to work on those nets (they are equivalent):
❑ Use setDoAssign on before loading the design data.
❑ Use set rda_Input(assign_buffer) {1} in the configuration file.
■ Blackboxes in the netlist
A blackbox is an instance declaration in the netlist for which no module or macro
definition is found. Unless your design is being done using a blackbox style of
floorplanning, there should be no blackboxes in the design. If there are blackboxes
reported, be sure to load the Verilog file that defines the logic module, and make sure
you include the LEF file that defines the macro being referenced in the netlist.
Checking Timing Constraint Syntax

In addition to checking the libraries, the loadConfig command also checks the syntax of
timing constraints. After running loadConfig, check for the following problems:
■ Unsupported constraints
The Encounter software may not support the SDC constraints being used with the
design, or the constraints may not match the netlist. If the constraints are not supported,
they may need to be re-expressed (if possible) in constraints that the Encounter software
does support.
■ Ignored timing constraints
Syntax errors can cause the tools to ignore certain constraints resulting in the
misinterpretation of important timing considerations. Check for the number of constraints
that are accepted or skipped. The tool displays messages similar to the following:
Reading timing constraint file ‘temp.sdc’ ...
*info: create_generated_clock : 2 accepted, 1 skipped!
*info: create_clock : 1 accepted, 0 skipped!
*info: refer to log file for more detail on skipped constraints if any
The encounter.log file contains more information about each constraint that was
skipped. For example:
Related message on constraint file temp.sdc:
**WARN[line 3]: -add and -master_clock options must be used together in
create_generated_clock statement
**WARN[line 3]: skip “create_generated_clock
The following are possible causes for ignored constraints.

Timing Closure
❑ A design object is not found.

If the constraints refer to pins, cells, or nets that are not found in the netlist, then
consider the following possible causes:
❍ There could be a naming convention problem in the constraint file.
❍ The netlist and constraints are out of sync, and a new set of constraints and/or
a new netlist needs to be obtained.
❑ An incorrect type of object is being passed to a constraint.
❑ An option is being used incorrectly or an unknown option is used.
❑ Illegal endpoints are used in assertions.
Use the primary IOs (top-level ports, CK or D register pin) to define starting and
endpoints of set_false_path and set_multicycle_path. A combinatorial pin
or a Q register pin is not valid.
Validating Timing Constraints

As described in the previous section, the loadConfig command checks the syntax of
specified timing constraints. However, it is also important to ensure that the timing constraints
are valid for the design. A good first-pass method is to check the zero wire-load model timing.
To validate timing constraints, use the command:

timeDesign -prePlace -outDir preplaceTimingReports
This command generates a quick timing report using zero wire load and provides a first
indication, before placement and routing, of how much effort will be required to close timing
and whether the timing constraints are valid for the design. During pre-placement timing
analysis, high fanout nets are temporarily set as ideal so that more immediate timing issues
can be addressed first.
Resolving Footprint Inconsistencies

Inconsistencies in how footprints are defined in the footprint file can lead to sub-optimal or
erroneous optimization results. Make sure that all cells for a given footprint are functionally
equivalent and are the proper set for the step being performed. For example, clock buffers
should generally not be used for optimization.
■ Create and load footprints correctly.

Timing Closure
❑ Load the data and use the reportFootPrint -outfile file_name

command to create a footprints file.
❑ Check the footprint name for buffers, inverters, and delay cells.
❑ Update your configuration file with the footprint information for buffer, inverter, and
delay cells. You can use the commands setInvFootprint,
setDelayFootprint, and setBufFootprint, or you can edit the configuration
files and add the lines
set rda_input(ui_buf_footprint) {xxx}
set rda_input(ui_delay_footprint) {xxx}
set rda_input(ui_inv_footprint) {xxx}
❑ Use the loadFootPrint -infile file_name command to load the footprints
file.
❑ Use the command checkFootPrint after loadFootPrint as an essential check
before optimization.
■ Make sure that library cells have the same names as their footprint definitions.
■ Make sure that all buffer cells for optimization are defined in the footprint file.
Validating the Floorplan

A congested or unroutable design at this stage will not get better during optimization. If a
floorplan is provided, you should be able to:
■ Place the design in the floorplan without issues
■ Create a routable placement
Perform a visual inspection of the floorplan to make sure there are no overlapping I/O blocks.
Generating the Capacitance Table File

The generateCapTbl command reads a detailed process description file in Interconnect
Technology (ICT) format and a LEF technology file, and outputs a capacitance table file. The
Interconnect Technology (ICT) file describes the detailed process information for a given
technology (layer thicknesses, materials, profiles, dielectric constants, and so forth). Any non-
default rules for the design should be defined in the LEF file you are using.
The capacitance table file consists of two parts:

■ Basic Capacitance Table

Timing Closure
Provides a table of spacing versus capacitance information for each layer.

■ Extended Capacitance Table
Provides encoded extraction patterns that are derived using a 3D field solver which
provides much greater accuracy during detailed extraction. A capacitance table file
(basic or extended) is process-specific and not design dependent, so it only needs to be
created once per technology. If a capacitance table already exists for your process, use
it and do not recreate it.
The following example shows how to generate an extended capacitance table using the
default field solver (Coyote).
generateCapTbl
-lef tech.lef
-ict process.ict
-coyote
-output process.xCapTbl
Determining and Setting the Scaling Factors
To obtain the parasitics measurements to determine the appropriate scaling factors, use the
generateRCFactor command. This command sets the capacitance factors by comparing
FE extraction with the results of either Fire & Ice extraction or a SPEF file.
For more information, see generateRCFactor in the Encounter Text Command

Reference.

Timing Closure
Pre-Placement Optimization DataPrep

C PPO
The goals of pre-placement optimization is to optimize the netlist to
FP/IP
■ Improve the logic structure
Pre-CTS
■ Reduce congestion CTS
■ Reduce area Post-CTS

Route
■ Improve timing
PRO
In some situations, the input netlist (typically from a poor RTL Timing Sign Off
synthesis) is not a good candidate for placement since it might contain
buffer trees or logic that is poorly structured for timing closure. In most
cases, high-fanout nets should be buffered after placement. It is more reliable to allow buffer
insertion algorithms to build and place buffer trees rather than to rely on the placer to put
previously inserted trees in optimal locations. Additionally, having buffer trees in the initial
netlist can adversely affect the initial placement.
Because of these effects, it can be advantageous to run pre-placement optimization or simple

buffer and double-inverter removal (area reclamation) prior to initial placement. This can be
accomplished by using the deleteBufferTree and removeClockTree commands.
For designs where the logical structure of the critical paths or high congestion are the sources
of closure problems, restructuring or remapping the elements on the paths (or related
portions of the design) can provide better timing results. This is done by running netlist-to-
netlist optimization using the runN2NOpt command on the initial netlist prior to place and
route. Additional restructuring can be performed later in the flow using the Encounter
optimization commands with more physical information.
Optimizing the Netlist

The initial netlist is optimized at the beginning stage of a design implementation. The
runN2NOpt command compares the timing correlation between RTL Compiler and
Encounter.If the timing correlates, the netlist is restructured to simplify the gates in the critical
paths. This restructuring allows for easier placement and optimization later in the flow.
If significant timing correlation issues are found, the command does not modify the initial
netlist and simply ends its operation.
The highlights of netlist-to-netlist optimization include:

■ Access to RTL Compiler from Encounter

Timing Closure
■ Different degrees of synthesis transformation depending on the specified effort: Netlist-

to-netlist performs either low or high efforts to make small or large changes on the netlist
with faster or slower run times.
■ Gate-level Verilog inputs with timing constraints and timing libraries in.lib format
■ Verilog output which is automatically loaded back into Encounter
■ The detection of wireload definition and selection in the timing library and the generation
of custom wireload as needed
■ Automatic and customized modes for novice and expert RC users
Netlist-to-Netlist Optimization Flow

The following figure shows the high-level data flow for netlist-to-netlist optimization.
Timing Gate-Level Timing

Libraries Verilog Constraint
Design Import
SoCE
N2N Optimization
Optimized Netlist
Floorplan, P&R, Optimization
Guidelines for using N2N

Use the following guidelines when you use the runN2NOpt command for pre-placement
optimization:
■ In general, try netlist optimization on designs with:
❑ High-utilization
❑ Very bad slack (less than -4 ns) after pre-CTS timing optimization

Timing Closure
❑ Long logic-dominated worst slacks

■ Always check for STA correlation first (ec::precheckTiming). Start with SDC error
and warning messages.
■ Avoid running N2N on an RTL Compiler netlist, timing-closed designs, and designs with
bad STA correlation.
■ Dangling instances such as spare cells may be removed. Use an explicit “preserve”
statement to prevent the removal.
■ Explore RC path_adjust for a design with worst path timing correlation problems. For
example:
rc> path_adjust -delay <negative_picosec> will tighten the paths
rc> path_adjust -delay <positive_picosec> will relax the paths
■ Use -idealHighFanout to idealize high-fanout nets; use -highFanoutLimit to
control the high-fanout threshold.
■ A customized floorplan created from the original netlist may not work for the new netlist.
Check the module guide, region, fence, and density.
Recommended Use of the runN2NOpt Command

The following example shows the recommended use of the runN2NOpt command.
runN2NOpt \
-effort high \
-inDir n2n.input \
-outDir n2n.output \
-report all \
-saveToDesignName n2n.enc
For the complete syntax and descriptions of parameters, see runN2NOpt in the Encounter
Text Command Reference.
Troubleshooting a Lengthy N2N Process

If the N2N optimization process appears to be taking too long for the size of the design, it
might be due to abnormally large timing violations. Typical runtimes on Linux range from one
hour (low effort) to two hours (high effort) per 100K instances.
1. Review the initial timing report in outDir/init.timing to see if the timing is
reasonable.

Timing Closure
2. Review the encounter.log file and find the section of the file that has the Global
mapping status heading. The following example indicates a problem:
Global mapping status
=====================
Group
Total
Total Worst
Operation Area Slacks Worst Path
---------------------------------------------
global_map 38482084 -1319526
3. Examine the Incremental optimization status and check the values for Group Total
Worst Slacks and Total Neg Slack to determine if the timing is abnormal. For
example:
Incremental optimization status
===============================
Group
Total Total - - DRC Totals - -
Total Worst Neg Max Max
Operation Area Slacks Slack Trans Cap
-----------------------------------------------------------------
init_delay 37912449 -1344356 -16404559956 0 162472282
4. If the values reported are excessively large, as in the previous example, discontinue the
N2N synthesis run.
5. Check the constraints file to see if there are missing timing exceptions, such as false or
multicycle paths. If there are, update the constraints file to include the appropriate
exceptions.
6. Determine if the wireload model used for the design is missing or too pessimistic. If so,
use one of the following procedures:
❑ Specify a different wireload model, or
❑ Manually generate a custom wireload model using a post-FE-optDesign database.
The following example shows how to manually generate the custom wireload model
and then use it with runN2NOpt command:
loadConfig init_design.conf
amoebaPlace -timingdriven
optDesign -preCTS
wireload -file mycwlm -percent 1.0 -cellLimit 10000
freedesign

Timing Closure
Then, to use the custom wire load model with N2N, use the following commands:
loadConfig init_design.conf
runN2NOpt -cwlm -cwlmLib mycwlm.flat -cwlmSdc myclwm.flat.sdc

Timing Closure
Floorplanning and Initial Placement DataPrep

PPO
The goals of floorplanning and initial placement include:
C FP/IP
■ Creating prototypes using multiple iterations with a focus on
Pre-CTS
routability
CTS
■ Moving toward timing-driven placement as routability stabilizes Post-CTS
■ Adding power routing once timing and congestion converge Route
PRO
The initial placement and the floorplan has a primary impact on the
Timing Sign Off
performance of a design. Encounter allows you to use prototypes to
analyze various placements and floorplans before you begin the
optimization process. Prototyping allows you to create a floorplan that can be implemented
with high confidence before you spend time and effort on optimization and routing.
Prototyping involves multiple placement iterations that converge on a solution which meets a
design's requirements for routability, timing (including clocks), power, and signal integrity. The
initial floorplan drives the constraints leveraged by amoeba placement and partitioning to
meet these objectives. The following steps outline a basic procedure for obtaining an initial
placement.
1. Run the initial placement without any regions and guides. It is best to get a baseline
placement without constraining the placer.
2. Analyze the placement for timing and routability issues, and make necessary
adjustments.
3. Employ module guides, density screens, placement blockages, and other techniques to
refine the floorplan.The placement engine automatically detects low-utilized designs and
turns on the options required to achieve an optimal placement.
Ensuring Routability
Initial prototype iterations should focus on routability as the key to achieving predictable timing
closure. You should attempt to resolve congestion before attempting timing closure. Designs
which are congested are more likely to have timing jumps during timing and SI closure. Tools
such as module guides, block placement, block halos, obstructions, and density screens are
used to control the efficient routing of the design.
Use the following guidelines during floorplanning and placement to avoid congestion.
1. Choose an appropriate floorplan style.

Timing Closure
❑ If possible, review a data flow diagram or a high-level design description from the
chip designer to determine an appropriate floorplan style.
❑ Assess different floorplan styles such as hard macro placement in periphery, island,
or doughnut (periphery and island). Keep the macro depth at 1 to 2 for best CTS,
optimization, and DFT results. If possible, consider different aspect ratios to
accommodate a shallower macro depth. Consider using relative floorplanning
scripts to simplify floorplan iterations.
2. Preplace I/Os and macros.
❑ Review hard macro connectivity and placement based on the minimum distance
from a hard macro to its target connectivity.
❑ Preplace high-speed and analog cores based on their special requirements for
noise isolation and power domains.
3. Review I/O placement to identify I/O anchors and associated logic.
❑ Verify that logic blocks and hard macros which communicate with I/O buffers are
properly placed and have optimal orientation for routability. Push down into module
guides to further assess the quality of the floorplan and resulting placement.
❑ Use the placeDesign -fp command to get an initial idea for how to place blocks.
If the design is not too large, consider using the -mediumeffort mode for the initial
placement. While -fp mode enforces non-timing-driven placement, use the
command setPlaceMode -noTimingDriven before running placeDesign in
medium effort mode to ensure non-timing-driven behavior. After the initial
placement, the location for macro blocks can be better determined and fixed for
another run of placeDesign to place the standard cells.
4. Allow enough space between preplaced blocks.
❑ Allow space between I/Os and peripheral macros for critical logic such as JTAG,
PCI, or Power management logic. Use the specifyJtag and placeJtag
commands prior to placing blocks.
❑ Use block halos, placement obstructions or fences around blocks prior to
optimization or CTS. Placement generally does not do a good job of placing cells
between macros. Reduce or remove halos and obstructions after placement to
make sufficient space available around macros for optimization, CTS, DRV, or SI
fixing to add buffers.
5. Use module guides carefully.
❑ Place module guides, regions, or fences only when greater control is required. Be
careful not to place too many module constraints early in the floorplanning process

Timing Closure
because it is time consuming and greatly constrains the placement. Module guides
should be used for floorplan refinement or hierarchical partitioning.
❑ Review the placement of module guides related to datapath and control logic relative
to the associated hard macros. Datapath logic can be a source of congestion
problems due to poor aspect ratios, high fanout, and large amounts of shifting.
Consider tuning the locations of these module guides and lowering the density to
reduce congestion.
❑ Review the placement of module guides related to memories. These modules can
typically have higher densities due to the inclusion of the memories.
6. Reorder scan chains
When evaluating congestion, make sure that scan chains are reordered to eliminate
“false” hot spots in the design. Failing to reorder the scan chain can cause a routable
floorplan to appear unroutable. By default, placeDesign performs scan tracing and
scan reordering based on global or user-specified scan reorder settings and specified or
imported scan chain information. If scan chain information is missing, no reordering is
performed.
Timing-Driven Placement
As the routability of the floorplan stabilizes, you should begin to review the timing-critical
paths. Depending on the size of the design, it may be difficult to see the critical path without
first proceeding through an optimization run. At this point, you can consider switching to
timing-driven placement.
Use the following guidelines when doing timing-driven placement.

■ Use placement command options
The following placement options can be used with the placeDesign command to
improve timing for different situations:
❑ Recommended setting (by default, placeDesign is timing-driven)
placeDesign
❑ Congested designs
setPlaceMode -highEffort
placeDesign
❑ In-place optimization enables additional optimization and placement. In general, it

will improve timing and congestions, but add to the runtime overhead.
placeDesign -inPlaceOpt

Timing Closure
■ Set a default transition value

Set a default input transition number for delay calculation to use on high fanout networks
based on your design characteristics. For example:
setInputTransitionDelay 400.
See also Guidelines for Pre-CTS Optimization on page 24.
The following figure shows the placement decision tree when the default timing-driven
placement does not produce an adequate pre-CTS optimization result. Always gauge quality
using pre-CTS timing, not post-placement timing.
Is the design congested?

Yes No
Add -highEffort option in TDP
No Debug / Slack Browser

Still congested? Regroup Netlist
Create Soft Guide Region
Pre-CTS
optimization Further analysis is
results are still required before
bad proceeding.
Troubleshooting Timing and Congestion Problems

■ Make sure you are using the correct footprints.
Problems during optimization often come from wrong or missing footprints. If you are
using timing-driven placement, make sure you set the correct buffer footprints.
AmoebaPlace needs the buffer footprint to correctly predict optimization results. So, if
you have not correctly set the footprints for buffers, inverters, and delays, you won’t see
the errors until you run optimization.
See Resolving Footprint Inconsistencies on page 11 for more information.

Timing Closure
■ Never try to compare post-placement slacks for quality purposes.

Always use post-optimization slacks for comparison. After placement, there will be some
basic buffering and resizing to get cells into their characterized region of timing as
defined by their lookup tables. Until the cells are in that region, any timing analysis results
are highly suspect.
A placement should always be followed by an optimization run to bring the cells into line
prior to making a timing and routability judgment. It is not uncommon to have the original
“worse” placement come out better post-optimization than the “better” placement. This
seems non-intuitive, but it is often the case.
You can use the command timeDesign -preCTS to check the current timing, but
remember that timing will continue to improve throughout the design process.
■ Use the slack browser to view obvious placement problems leading to negative slack.
■ Check to see that failing paths do not run through areas of either global or local
congestion. You can use the selectCritNet or selectCritInst commands.
These congested areas will cause optimization problems since the area in need of
optimization is overcrowded, leading to additional place and route detours requiring more
optimization.
Do not proceed if this situation is present. Instead consider the following potential
floorplan changes:
❑ Modify module pin placements or try a better alignment for hard macro pins.
❑ Make sure that hard block placement is not over-constraining the routing resources
needed.
❑ Add, delete, or modify guide, region, or soft guide constraints.
❑ Consider restructuring the logic.
❑ Consider modifying the aspect ratio of problem modules.
■ Add power routing after congestion and timing are converging:
❑ Review power routing relative to macro pins
❑ Re-evaluate congestion and timing results

Timing Closure
Pre-CTS Optimization DataPrep

PPO
The goal of pre-CTS optimization is to repair
FP/IP
■ Setup slack
C Pre-CTS
■ Design rule violations (DRVs) CTS
■ Setup times Post-CTS

Route
■ Remaining DRVs
PRO
Use the optDesign -preCTS command only if optimization has not Timing Sign Off
been done already. During subsequent optimization runs, be sure to
use the -incr option.
The use of the optDesign command for post-CTS optimization and post-route optimization
is described in the corresponding sections of this document. For more information on the
optDesign command, see optDesign in the Encounter Text Command Reference,
and refer to the Timing Optimization chapter in the Encounter User Guide for more
procedures on optimizing the design.
Guidelines for Pre-CTS Optimization

Consider the following points during pre-CTS optimization:
■ Create and load footprints correctly. See “Resolving Footprint Inconsistencies” on
page 11 for more information.
■ Handle assign statements correctly. See “Nets should be optimized with assign
statements” on page 10 for more information.
■ Set input transitions for the high fanout nets for delay calculation to use on high fanout
networks.
For nets with a fanout higher than 1000, the default transition is 120ps, the default delay
is 1ns, and the default capacitance is 0.5pf. The defaults can be changed with the
commands: setDefaultNetDelay, setDefaultNetLoad, and
setInputTransitionDelay.During optimization, all nets with a fanout greater than
100 will be buffered.

Timing Closure
Pre-CTS optDesign Command Sequences

You can use optDesign for pre-CTS optimization in the following ways. You can use any of
these features separately or in combinations.
■ To optimize timing placed designs for the first time (with ideal clocks), use the following
command:
optDesign -preCTS
Note: To perform rapid timing optimization for design prototyping, use the following
commands:
setOptMode -lowEffort
optDesign -preCTS
Encounter performs gate resizing and global buffer insertion, but does not perform netlist
restructuring.
■ To further optimize a design after you have already run optDesign -preCTS, use the
following command:
optDesign -preCTS -incr
You can also take advantage of the following features in either first-time or incremental pre-
CTS optimization:
Note: The [-incr] notation means that you can run optDesign -preCTS with or without
the -incr parameter.
■ To perform optimization with useful skew, use the following commands:
setOptMode -usefulSkew
optDesign -preCTS [-incr]
■ To perform optimization on specific path groups, use the following commands:

clearClockDomains
setClockDomains -fromType domainName -toType domainName
For example, to perform optimization on register-to-register paths, use the following

commands:
clearClockDomains
setClockDomains -fromType register -toType register

Timing Closure
Cadence recommends that you optimize timing with the default values; however, you can
change or add parameters for the following commands and parameters that -optDesign
runs automatically:
setAnalysisMode Encounter sets -noClockTree and -noClkSrcPath by

default. You can add other options.
setClockDomain Encounter uses the options you specify. The default is all path
groups.
setExtractRCMode The mode is set to -default for pre-CTS mode. Ensure that
you set the appropriate extraction scale factor. You cannot
override -default.
setOptMode Encounter sets the following options:
■ -drcMargin
If you use setOptMode -drcMargin, this value is added
to a dynamically calculated, internal margin. Encounter
writes the margin value to the log file.
■ -holdTargetSlack
If you use setOptMode -holdTargetSlack, this value
is added to a dynamically calculated, internal margin.
Encounter writes the hold target slack value to the log file.
■ -setupTargetSlack
If you use setOptMode -setupTargetSlack, this value
Encounter writes the setup target slack value to the log file.
You cannot override -noPreserveRoute. You cannot set
-incrTrialRoute. You can override other options.
setTrialRouteMode You can add options, but never override the default settings.
Encounter sets -handlePreRoute.
Improving Pre-CTS Timing

Encounter makes use of useful skew to improve timing. The purpose of useful skew is to
speed up the clock to the path begin point. A relatively simple way to determine whether there
is an opportunity for useful skew on the critical path is to measure the slack on each side of

Timing Closure
the path endpoint. During pre-CTS optimization, you can borrow from the left side (A) of the
violated path to advance the clock.
pre-CTS post-CTS
B
A
+ slack + slack
Violated
Paths

Timing Closure
Clock Tree Synthesis DataPrep

PPO
The goal of clock tree synthesis is to build a buffer distribution network
to meet the timing requirements among the leaf pins. It includes the FP/IP
following jobs. Pre-CTS
■ Creating clock tree spec file C CTS

Post-CTS
■ Building a buffer distribution network
Route
■ Routing clock nets using CTS-NanoRoute PRO
Timing Sign Off
Creating the Clock Specification File

Clock tree synthesis is a series of procedures to build a buffer distribution network to meet
the design’s timing targets. The clock tree specification file is used to direct clock tree
synthesis and includes:
■ Design constraints including latency, skew, and design rule
■ Buffer and routing type definitions
■ Trace and synthesis controls like: MacroModel, ClkGroup, NoGating, LeafPin,
ExcludedPin, PreservePin, ThroughPin, and GatingGroupInstances
■ Flow controls like:
❑ Defining the delimiter for added buffers
❑ Whether or not to generate a detail report
❑ Whether or not to route the clock net
❑ Whether or not to perform post-CTS optimization
You can generate the default clock tree spec file with the command
clockDesign -genSpecOnly filename
Automatically generating a clock tree specification translates the following information from
the timing constraint file into suitable records for the clock tree spec file.
Timing Constraints Clock Tree Specs

create_clock AutoCTSRootPin / ClkGroup
create_generated_clock Add suitable ThroughPin on the divided clock pin

Timing Closure
set_clock_latency Maxdelay
set_clock_uncertainty Maxskew
set_clock_transition BufMaxTran / SinkMaxTran
You can control the buffer types to build clock trees by specifying the footprint or listing the
buffer types in the config file. You can also control the routing types for the clock nets. Route
types for nets connected to leaf cells and nets connected to non-leaf cells can be specified
separately with LeafRouteType and Routetype. Also, you can use setCTSMode before
running specifyClockTree to change the default routing type and global clock tree
synthesis controls.
The clock tree specification file is very important and directly affects the result of clock tree
synthesis. A good clock tree plan including suitable constraints and placement space can
improve the results of clock tree synthesis and avoid problems for post-CTS timing closure.
A custom clock tree specification file can be used to drive clock tree synthesis. To read in a
custom clock tree specification file, use the command
clockTree -specFile filename
The Pre-CTS Clock Tree Tracer user interface can be used to traverse the clock tree structure
logically and physically based on the applied clock specification file before committing clock
tree synthesis. You can use it as a basis for changing the clock tree specification file to
consolidate the clock tree structure and improve the results of clock tree synthesis.
Synthesizing the Clock Tree

To generate the clock tree, use the clockDesign command. This command performs the
following operations during clock tree synthesis:
■ Deletes any existing buffers on the clock nets
■ Builds a buffer distribution network to distribute the clock signal(s) to the registers
■ Routes the clock nets using CTS-NanoRoute
■ Optimizes the clock tree
The clockDesign command sets the following options by default.
Option Setting Default

RouteClkNet Yes No
PostOpt Yes Yes

Timing Closure
OptAddBuffer Yes No
The clockDesign command generates the default clock tree specification file; builds the
clock tree; calls NanoRoute to route the clock nets; and then optimizes the clock tree to
improve the skew including resizing buffers or inverters, adding buffers, refining placement,
and correcting routing.
If you performed useful skew optimization (setOptMode -usefulSkew), clockDesign

automatically checks for any scheduling file in the working directory, or checks for
rda_Input ui_scheduling_file, and honors the scheduling file while building the
clock tree.
If the clockDesign command calls NanoRoute to route the clock nets, you can direct
NanoRoute to follow the route guide by using the command
setCTSMode -useCTSRouteGuide. By default, NanoRoute does not follow the guide. This
operation can improve the correlation between pre-route and post-route clock nets.
Optimizing the Clock Tree

You can use the ckECO command to optimize the clock tree optimization after clock tree
synthesis based on different routing patterns and timing analysis results.
Options Routing patterns and timing analysis results

-preRoute Creates clock tree timing analysis results that are based on a
Steiner estimation of the clock tree.
-clkRouteOnly Creates clock tree timing analysis results that are based only
on clock tree wires, even if other wires (such as signal net
wires) exist in the design.
-postRoute Creates clock tree timing analysis results that are based on
clock tree wires and signal wires.
Additionally, you can use the Clock Tree Browser user interface to fine tune the clock tree to
improve the results. From the user interface you can perform the following operations:
■ Add buffers
■ Delete buffers
■ Size cells
■ Change net connections

Timing Closure
Refer to the chapter, Synthesizing Clock Trees, in the Encounter User Guide for more
information. Also, see the chapter, Clock Menu, in the Encounter Menu Reference for
descriptions of the forms and fields of the user interface.

Timing Closure
Clock Specification File Example

The following example shows a clock specification file.
#
# FirstEncounter(TM) Clock Synthesis Technology File Format
#
MacroModel pin freg/mod004048/CLK 20ps 18ps 20ps 18ps 30ff
ClkGroup
+ CGEN_1
+ CGEN_2
RouteTypeName CK1
PreferredExtraSpace 1
TopPreferredLayer 4
BottomPreferredLayer 3
End
RouteTypeName LF1
PreferredExtraSpace 0
TopPreferredLayer 4
BottomPreferredLayer 3
End
AutoCTSRootPin cgen/i_5/Y
MaxDelay 5.0ns
MinDelay 0ns
MaxFanout 2
MaxSkew 250ps
SinkMaxTran 550ps
BufMaxTran 550ps
NoGating NO
DetailReport YES
Obstruction YES
useCTSRouteGuide YES
RouteType CK1
LeafRouteType LF1
RouteClkNet YES
PostOpt YES

Timing Closure
OptAddBuffer YES
OptAddBufferLimit 100
Buffer BUFX4 BUFX8 BUFX12 INVX1
MaxCap
+ BUFX4 1pf
+ BUFX8 1pf
+ BUFX12 1pf
ThroughPin
+ df/mod000446/CK
ThroughPort
+ df/mod002300/ax2
LeafPin
+ PCLK66_gate_i/A rising
LeafPort
+ ssfd2s/D rising
PreservePin
+ cgen/mod000043/A
ExcludedPin
+ freg/mod004048/CLK
ExcludedPort
+ DFF_B/CLK
End

Timing Closure
Sample CTS Script

## Specify multiple processors for routing.
setNanoRouteMode envNumberProcessor ${NUMBER_OF_PROCESSORS}
## Use "-useCTSRouteGuide" to use routing guide during CTS.

setCTSMode -useCTSRouteGuide
## In 4.2, the clockDesign command performs clock tree synthesis.

## Specify the clock buffer and inverter footprints in the config file.
## Please refer to the section "Variables to set for default settings."
## It defines the required variables to be used in the config file.
## If default settings or parameters in the clock spec
## need to be changed, generate the clock spec file, make
## the necessary changes, and read back the spec file.
#clockDesign -genSpecOnly clk.ctstch
#clockDesign -specFile clk.ctstch -outDir ${BLOCK_NAME}_clock_reports
## Perform clocktree synthesis; clock reports are saved in the default

## directory clock_reports.
clockDesign -outDir ${BLOCK_NAME}_clock_reports

Timing Closure
Post-CTS Optimization DataPrep

PPO
The goals of post-CTS optimization include:
FP/IP
■ Fixing remaining design rule violations
Pre-CTS
■ Optimizing remaining setup violations CTS
■ Correcting timing with propagated clocks C Post-CTS

Route
At this point in the design flow, the clocks are inserted and are possibly PRO
routed. You’ll also want to do the following:
Timing Sign Off
■ Perform timing analysis using propagated constraints.
This takes into account the real clock insertion latencies and skews of the inserted trees.
■ Adjust the clock uncertainty to model only jitter.
You need to update the constraints after clock tree synthesis to adjust clock jitter
according to the design. Modeling only the jitter avoids making the timing appear worse
than it is. Remember that, since the actual clock skew data is now available, it is possible
that critical path timing will be worse.
■ Fixing hold time violations at this point in the flow is an optional step depending on the
number of violations and the needs of the particular design and methodology.
Post-CTS Optimization Command Sequences

■ Use the timeDesign command to check the post-CTS timing:
timeDesign -postCTS -outDir postctsTimingReports
■ To optimize timing after the clock tree has been built, use the following commands:
optDesign -postCTS -outDir postctsOptTimingReports
Encounter corrects setup violations and DRVs as it does in pre-CTS mode, except that
it does not reclaim area.
■ To reclaim area during optimization, use the following commands:
setOptMode -reclaimArea
optDesign -postCTS [-incr]
■ To perform optimization on specific path groups, use the following commands:

clearClockDomains
setClockDomains -fromType domainName -toType domainName

Timing Closure
For example, to perform optimization on register-to-register paths, use the following

commands:
clearClockDomains
setClockDomains -fromType register -toType register
■ To correct only hold violations in post-CTS mode, specify the following command:
optDesign -postCTS -hold
■ To take advantage of useful skew when optimizing timing in post-CTS mode, use the
following commands:
If you have already performed detail routing on the clock tree, Encounter performs global
and detailed ECO routing automatically using nanoRoute in post-CTS useful skew
mode. If you do not want Encounter to do this, specify the -noECORoute parameter as
follows:
optDesign -postCTS -noECORoute [-incr]
If you specify -noECORoute before running optimization, Encounter performs trial

routing to estimate clock delays.
Cadence recommends that you optimize timing with the default values, but you can change
or add parameters for the following commands and parameters that -optDesign runs
automatically:
setAnalysisMode Encounter sets -clockTree and -clkSrcPath by default.

You can add other options.
groups.
setExtractRCMode The mode is set to -default for post-CTS mode. Ensure that
override -default.

Timing Closure

■ -drcMargin
writes the margin value to the logfile.
Encounter writes the hold target slack value to the logfile.
Encounter writes the setup target slack value to the logfile.
The optDesign command is also used during “Pre-CTS Optimization” on page 24 and “Post-
Route Optimization” on page 40. See the Encounter Text Command Reference for more
information on the optDesign command, and refer to the Timing Optimization chapter in
the Encounter User Guide for more procedures on optimizing the design.
Checking Timing
You can use the following command to report hold-time violations after post-CTS
optimization.
timeDesign -postCTS -hold -reportOnly -outDir postctsOptTimingReports
See the Encounter Text Command Reference for more information about timeDesign.

Timing Closure
Detailed Routing DataPrep

PPO
After post-CTS optimization, there should be few, if any, timing
violations left in the design. The goals of detailed routing include: FP/IP
Pre-CTS
■ Routing the design without DRC or LVS violations. NanoRoute
performs a DRC and cleans up violations CTS
Post-CTS
■ Routing the design without degrading timing or creating signal
C Route
integrity violations
PRO
NanoRoute can perform timing-driven and SI-driven routing Timing Sign Off
concurrently. NanoRoute routes the signals which are critical for signal
integrity appropriately to minimize cross-coupling between these nets
which would lead to post-route signal integrity issues.
Improving Timing during Routing

The following tips can help achieve better timing results during the routing phase of the
design.
■ Make sure the LEF file contains a sufficient number and variety of vias (hammer-head,
stacked, and so forth).
■ Check the definition of tracks in the DEF file. If the tracks are poorly defined, regenerate
tracks with the generateTracks command.
■ If timing is way off and/or there is local or global congestion, return to post-CTS
optimization and optimize further or run non-timing-driven routing.
■ Unfix the clock nets before using NanoRoute
Routing Command Example

The following example shows the use of NanoRoute to do detailed routing.
changeUseClockNetStatus -noFixedNetWires
setNanoRouteMode routeWithTimingDriven true
setNanoRouteMode routeWithSiDriven true
globalDetailRoute

Timing Closure
Timing Check
Use the following command to do a post-route timing check:
timeDesign -postRoute -outDir postrouteTimingReports

Timing Closure
Post-Route Optimization DataPrep

PPO
The goals of post-route optimization include:
FP/IP
■ Fixing timing problems and design rule violations without
Pre-CTS
introducing new problems
CTS
■ Resolving signal integrity (SI) issues Post-CTS
Encounter corrects setup violations and design rule violations unless Route
you specify otherwise. Encounter performs incremental RC and delay C PRO
calculation, and runs NanoRoute to perform ECO routing. Timing Sign Off
Fixing Timing and Design Rule Violations

During post-route optimization, there should be very few violations that need correction. The
primary sources of these timing violations include:
■ Inaccurate prediction of the routing topology during pre-route optimization due to
congestion-based detour routing
■ Incremental delays due to parasitics coupling
Important
Since the violations at this stage are due to inaccurate modeling of the final route
topology and the attendant parasitics, it is critical at this point not to introduce any
additional topology changes beyond those needed to fix the existing violations.
Making unnecessary changes to the routing at this point can lead to a scenario where
fixing one violation leads to the creation of others. This cascading effect creates a
situation where it becomes impossible to close on a final timing solution with no design
rule violations.
One of the strengths of post-route optimization is the ability to simultaneously cut a wire and
insert buffers, create the new RC graph at the corresponding point, and modify the graph to
estimate the new parasitics for the cut wire without re-doing extraction.
To take advantage of this feature with an external SPEF generated by a sign-off extraction
tool for improved convergence, a full SPEF must be used (reduced SPEF will not work), and
one of the following conditions must be met:
■ The SPEF must be generated with node locations using the starN format. The runQX
command in Encounter has been enhanced to output this format using the -
spefOutput starN option. For example: runQX -spefOutput starN.

Timing Closure
or
■ The resistance values in the LEF file must match those in the technology file used by Fire
& Ice or starRC to generate the SPEF, which enables Encounter extraction to match the
routes with the SPEF RC graph.
You can use the optDesign command to fix timing during post-route optimization in the
following ways:
➤ To optimize timing after detailed routing, use the following command.
optDesign -postRoute -outDir postrouteOptTimingReports
Encounter corrects DRVs and setup violations, as it does in pre-CTS and post-CTS
modes. Encounter also performs an additional register-to-register optimization if the
worst negative slack does not occur on a register-to-register path. Encounter cuts wires
during buffer insertion and resizing, and simultaneously cuts the RC graph at the
corresponding point to estimate RCs on the cut wires.
In post-route mode, Encounter refines placement, then runs NanoRoute in ECO mode
to reroute affected wires. Encounter extracts RCs and reports final timing results. After
post-route optimization is complete, you can run a sign off extractor and compare the
results with those generated by Encounter.
➤ To correct only hold violations in post-route mode, specify the following commands:
optDesign -postRoute -hold -outDir postrouteOptTimingReports
This command sequence corrects only hold violations during post-route optimization,
without correcting setup violations. You benefit from correcting hold violations before
correcting setup violations because the hold repairs might cause more setup violations,
which you can correct in a later step.
Resolving Signal Integrity Issues

In addition to the timing violations caused by inaccurate route topology modeling, the
parasitics cross-coupling of neighboring nets can cause the following problems that need to
be addressed in high speed designs:
■ An increase or decrease in incremental delay on a net due to the coupling of its
neighbors and their switching activity.
■ Glitches (voltage spikes) that can be caused in one signal route by the switching of a
neighbor resulting in a logic malfunction.
These effects need to be analyzed and corrected before a design is completed. They are
magnified in designs with small geometries (180 nm and below) and in designs with high
clock speeds.

Timing Closure
➤ To correct signal integrity violations when optimizing timing in post-route mode, use the
following command:
optDesign -postRoute -si
This command has its maximum effect once most other timing-related issues have been
corrected. It uses CeltIC to perform the SI analysis and corrects any problems by using a
combination of buffer resizing and/or routing modifications.
The optDesign -postRoute -si command should be used after using the optDesign
-postRoute command.
➤ To input a SPEF file for use during post-route SI optimization, use the following
commands.
spefIn spefFileName
optDesign -postRoute -si
Tips for Solving SI Closure Problems
Consider the following techniques if you have difficulty achieving signal integrity closure on
your design.
■ Watch for routing congestion during floorplanning and especially after detailed routing.
❑ Consider running the congOpt command on the design to eliminate local hot spots
or adjust your floorplan
■ Use NanoRoute advanced timing with SI-driven routing options during detailed routing.
For example:
❑ setNanoRouteMode routeWithTimingDriven true
❑ setNanoRouteMode routeWithSiDriven true
■ Fix transition time violations.
❑ Slow transitions introduce a larger delay penalty or incremental delay.
■ Prepare all of the required noise models.
❑ Highly-accurate CeltIC analysis requires the use of accurate noise models like cdB,
ECHO, or xILM. The use of blackbox (missing) models could lead to a significant
number of false violations.
Important
You must recalibrate the noise library with each release of CeltIC. New features may
not function properly when used with an old .cdB file.

Timing Closure
❑ Characterize your memory and analog block using the make_cdb utility.
❑ Create XILM models for sub blocks to model their noise sensitivity at the chip level.
Modifying the Default Operation Modes

Cadence recommends that you optimize timing with the default values, but you can change
or add parameters for the following commands and parameters that -optDesign runs
automatically:
setAnalysisMode Encounter sets -clockTree and -clkSrcPath. You can

override other options.
groups.
setExtractRCMode The mode is set to -detail for post-route mode. Ensure that
override -detail.
■ -drcMargin
writes the margin value to the logfile.
Encounter writes the hold target slack value to the logfile.
Encounter writes the setup target slack value to the logfile.

Timing Closure
Timing Sign Off DataPrep

PPO
The goal of timing sign off is to verify that the design meets the
specified timing constraints. This is accomplished by first using Fire & FP/IP
Ice QX to generate detailed extraction data and then using the Pre-CTS
specified timing analysis engine for a final analysis of setup and hold
CTS
data.
Post-CTS
At this point in the design process, final routing and post-route Route
optimization is complete. PRO
C Timing Sign Off
The following command sequence generates the reports needed to
verify timing:
timeDesign -signoff -outDir signOffTimingReports
timeDesign -signoff -hold -reportOnly -outDir signOffTimingReports
These commands perform the following operations:

1. Runs Fire & Ice to generate detailed parasitics.
2. Uses the detailed parasitics and generates the setup timing reports.
3. Generates the hold timing reports.
For Fire & Ice to run, you need to ensure that the FE configuration file includes a technology
file and a LibGen cell library database created with the runLibGen command. For more
information about setting up the libraries for Fire & Ice, refer to the chapter RC Extraction in
the Encounter User Guide.

A
Timing Closure Script
The following is a copy of the complete script for the timing closure flow. Since the script is
subject to change, this may not reflect the latest version.
Commands that are preceded by the comment symbol (#) are optional, depending on the
specific design requirements. Comments are most often preceded by two comment symbols
(##).
An on-line copy of the script, which you can use as a template for your design, is provided in
the gift directory.
install_dir/share/fe/gift/example_flows/block_implementation
/timing_closure_4.2.tcl
A README file in this directory provides additional information about modifying and using the
script.
Important
This script is subject to change. See your AE or Cadence representative to make
sure the script and the version of Encounter match.

############################################################
# Purpose : Block Implementation #
# [Timing Closure in SOCE4.2] #
############################################################
#############################################
# Variables to set for default settings #
# These settings work with the tdsp_core #
# block in the gift directory. #
#############################################
## Specify the block name.
set BLOCK_NAME tdsp_core
## Specify filler cells.
set LIST_OF_FILLER_CELLS {FILL64 FILL32 FILL16 FILL8 FILL4 FILL2 FILL1}
## Specify the number of processors for NanoRoute, QX, and SI setup fix.
set NUMBER_OF_PROCESSORS 2
## Specify the RC Factor.
## You can use “generateRCFactor -all” to generate the RC scale factors.
set DEF_CAP 1.13
set DET_CAP 1.02
## In 4.2, specify clk inv and buf footprints in addition to
## regular inv and buf footprints in the config file for CTS.
## Include the following lines in the config file:
#set rda_Input(ui_cts_cell_footprint) {clkbuf clkinv}
#set rda_Input(ui_cts_cell_list) {}
## Specify the mapfile name for streaming out block gds;
## otherwise, the default name, streamOut.map, is used.
set STREAMOUT_MAP_FILE streamOut
##########################################
# Variables to set for optional settings #
##########################################
## Specify a list of cells for UsefulSkewMode.
#set USEFUL_SKEW_BUF_LIST {CLKBUF1 CLKBUF2 CLKBUF3}
#########################################
# Load Design #
#########################################
loadConfig ${BLOCK_NAME}.conf
## Load Floorplan (contains global power, etc.)
loadFPlan ./${BLOCK_NAME}.fp
## Load DEF (contains placement, etc.)
#defIn ./${BLOCK_NAME}.def
## Or Load the design and floorplan if DB is saved.
#restoreDesign ${BLOCK_NAME}_design.enc.dat ${BLOCK_NAME}
## Check the design for any missing data.
checkDesign -all -outfile ${BLOCK_NAME}_check_design.rpt
## Check timing before placement using zero wire load (ZWL).
#timeDesign -prePlace -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/preplace
## Set RC scale factors for default and detail extraction.
setRCFactor -defcap ${DEF_CAP} -detcap ${DET_CAP}

###############################
# Placement #
###############################
## Set the clock domains appropriately if the goal
## is to close timing only in selected clock domains.
#clearClockDomains
#setClockDomains -fromType register -toType register
## Specify scan chains if the floorplan file does not have this information.
## If there is a scan def file, use defIn to load it.
specifyScanChain chain1 -start BG_scan_in -stop BG_scan_out
## Specify spare gates for placement and optimization consideration.
#specifySpareGate -inst cell_name
## In 4.2, the placeDesign command performs timing-driven placement
## and scanReorder by default. Use the -noReorderscan option if
## there is no need to reorder the scan chain.
#setPlaceMode -noReorderScan
## Use “-highEffort” option if the design is congested.
#setPlaceMode -highEffort
placeDesign
#saveDesign ${BLOCK_NAME}_place.enc
###############################
# PreCTS Optimization #
###############################
## Use “-usefulSkew” if you intend to use usefulSkew, and remove any
## existing scheduling files in the working directory.
#setOptMode -usefulSkew
## Specify the clock buffers that need to be used for usefulSkew.
#setUsefulSkewMode -usecells ${USEFUL_SKEW_BUF_LIST}
## Perform optimization at pre-CTS (ideal clock) phase
## and generate detailed timing reports.
optDesign -preCTS -outDir ${BLOCK_NAME}_reports/prectsOptTimingReports
## Perform incremental optimization in critical clock domains.
#clearClockDomains
#optDesign -preCTS -incr -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/prectsIncrOpt
#saveDesign ${BLOCK_NAME}_prectsopt.enc
###############################
# Clock Tree Synthesis #
###############################
## Specify multiple processors for routing.
setNanoRouteMode envNumberProcessor ${NUMBER_OF_PROCESSORS}
## Use “-useCTSRouteGuide” to use routing guide during CTS.
setCTSMode -useCTSRouteGuide
## Set “routeClkNet” to use NanoRoute during CTS.
setCTSMode -routeClkNet
## In 4.2, the clockDesign command performs clock tree synthesis.
## Specify the clock buffer and inverter footprints in the config file.
## Please refer to the section “Variables to set for default settings”
## at the top of this script.It defines the required variables to be
## used in the config file. If default settings or parameters in the
## clock spec need to be changed, generate the clock spec file, make
## the necessary changes, and read back the spec file.

#clockDesign -genSpecOnly clk.ctstch

#clockDesign -specFile clk.ctstch -outDir ${BLOCK_NAME}_clock_reports
## Perform clocktree synthesis; clock reports are saved in the default
## directory clock_reports.
clockDesign -outDir ${BLOCK_NAME}_clock_reports
## Update the constraints after CTS.
## The value of uncertainty could be reduced to factor in only the
## clock jitter, as the skew numbers are accurate after building the clock tree.
#unloadTimingCon
#loadTimingCon prop.sdc
#saveDesign ${BLOCK_NAME}_cts.enc
###############################
# PostCTS Optimization #
###############################
## The following 3 commands are used to consider OCV for timing analysis.
## The values set here are an example. The derate factors depend on the process.
#setAnalysisMode -crpr
#setTimingDerate -max -early 0.9 -late 1.0
#setTimingDerate -min -early 1.0 -late 1.1
## Set the clock domains appropriately to perform optimization after CTS.
#clearClockDomains
## Perform optimization after CTS and generate detailed timing reports
## for the block.
optDesign -postCTS -prefix TimingReports -outDir ${BLOCK_NAME}_reports/postctsOpt
## Check hold timing after postCTS optimization.
#timeDesign -postCTS -hold -reportOnly -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/postctsOpt
#saveDesign ${BLOCK_NAME}_postcts.enc
###############################
# Add Filler #
###############################
## In 4.2, setFillerMode specifies filler cells to be used by the addFiller command.
## It also deletes and adds filler cells automatically during post-route
## optimization.
setFillerMode -corePrefix ${BLOCK_NAME}_FILL -core ${LIST_OF_FILLER_CELLS}
## Insert filler cells before routing if only decoupling cap filler
## cells are available
addFiller -noFillBoundary
#######################################
# NanoRoute Timing and SI-Driven Flow #
#######################################
## Unfix the clock nets to avoid routing problems.
changeUseClockNetStatus -noFixedNetWires
## Substitute the machine name, the number of cpu’s, and
## the name of the nanoRoute executable for super-threading in
## the following command.
#setNanoRouteMode envSuperThreading {RSH {machinename number_cpus \
# nanoroute_executable} {machinename number_cpus nanoroute_executable}}
## Perform SMART routing.
setNanoRouteMode routeWithTimingDriven true
setNanoRouteMode routeWithSiDriven true

## NanoRoute picks the antennna cell directly from the LEF, if antenna diode
## insertion is set to true. Please check if antenna has class defined as
## CLASS CORE ANTENNACELL.
#setNanoRouteMode routeInsertAntennaDiode true
globalDetailRoute
## Check timing after routing.
timeDesign -postRoute -prefix TimingReports \
-outDir ${BLOCK_NAME}_reports/postroute
## Check hold timing after routing.
#timeDesign -postRoute -hold -reportOnly -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/postroute
#saveDesign ${BLOCK_NAME}_nanoroute.enc
###############################
# Post-Route Optimization #
###############################
## If there is still a correlation issue, then run spefIn using external SPEF.
#spefIn filename
## Perform DRV and setup optimization after detail routing and generate
## detailed timing block reports.
optDesign -postRoute -prefix TimingReports \
-outDir ${BLOCK_NAME}_reports/postrouteOpt
## Perform optimization after detail routing for hold and generate
## detailed timing reports
#optDesign -postRoute -hold -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/postrouteOpt
#saveDesign ${BLOCK_NAME}_postrouteopt.enc
###############################
# Sign-Off Timing Analysis #
###############################
## Check timing for sign off.
## timeDesign uses either the default timer or the CTE timing engine
## depending on the user-specified settings for sign-off timing analysis.
timeDesign -signoff -prefix TimingReports -outDir ${BLOCK_NAME}_reports/signOff
## Check hold timing for sign off.
#timeDesign -signoff -hold -reportOnly -prefix TimingReports \
# -outDir ${BLOCK_NAME}_reports/signOff
#saveDesign ${BLOCK_NAME}_signoff.enc


Index
A netlist restructuring
using runN2nOpt command (RC) 14
Amoeba placement noise models
in floorplanning and placement 19 in SI closure 42
area reclamation
pre-placement optimization 14
P
B pre-placement optimization 14
basic capacitance table 12

buffer and double-inverter removal (area R
reclamation 14
RC vs. FE
runN2nOpt command 14
C related documents, list of 5
Routability
conventions, syntax and typographic 4 considerations during floorplanning and
custom wireload model 17 initial placement 19
runN2NOpt 16
D S
documents, related, list of 5
double-inverter removal SI closure problems
area reclamation 14 resolving 42
slack
borrowing with useful skew 26
E syntax conventions 4
Examples
Capacitance Table generation 13 T
Pre-CTS script 25
Routing script 38 transition violations
fixing in SI closure 42
typographic conventions 4
H
high-fanout nets 16 U
buffering 14
high-fanout threshold 16 useful skew
borrowing slack 26
N
netlist optimization 15

W
WLM
timing constraint validation 11
X
XILM model
noise modeling 43

Static Timing Analysis

Uploaded by

Copyright:

Available Formats

Static Timing Analysis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Static Timing Analysis

Uploaded by

Copyright:

Available Formats

Encounter™ Timing Closure Guide

Product Version 4.2.1

June 2005 1 Product Version 4.2.1

Creating the Clock Specification File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

June 2005 2 Product Version 4.2.1

About This Guide

How This Manual Is Organized

June 2005 3 Product Version 4.2.1

Conventions Used in This Manual

text Indicates information for which you must substitute a name

text Indicates the following:

[ | ] Indicates an optional choice from a mutually exclusive list.

{ | } Indicates a required choice from a mutually exclusive list.

June 2005 4 Product Version 4.2.1

{[ ] [ ]} Indicates a required choice of one or more items in a list.

{ } Indicates curly braces that must be entered with the

... Indicates that you can repeat the previous argument.

Command – Subcommand Indicates a command sequence, which shows the order in

June 2005 5 Product Version 4.2.1

June 2005 6 Product Version 4.2.1

June 2005 7 Product Version 4.2.1

Recommended Timing Closure Flow

Floorplanning and Initial Placement

Full Trial Route

Static Timing Analysis

Timing Sign Off

June 2005 8 Product Version 4.2.1

Data Preparation C DataPrep

Validating the Netlist and Libraries

June 2005 9 Product Version 4.2.1

■ Nets should be optimized with assign statements

Checking Timing Constraint Syntax

The following are possible causes for ignored constraints.

June 2005 10 Product Version 4.2.1

❑ A design object is not found.

Validating Timing Constraints

To validate timing constraints, use the command:

Resolving Footprint Inconsistencies

June 2005 11 Product Version 4.2.1

❑ Load the data and use the reportFootPrint -outfile file_name

Validating the Floorplan

Generating the Capacitance Table File

The capacitance table file consists of two parts:

June 2005 12 Product Version 4.2.1

Provides a table of spacing versus capacitance information for each layer.

Determining and Setting the Scaling Factors

For more information, see generateRCFactor in the Encounter Text Command

June 2005 13 Product Version 4.2.1

Pre-Placement Optimization DataPrep

■ Reduce area Post-CTS

Because of these effects, it can be advantageous to run pre-placement optimization or simple

Optimizing the Netlist

The highlights of netlist-to-netlist optimization include:

June 2005 14 Product Version 4.2.1

■ Different degrees of synthesis transformation depending on the specified effort: Netlist-

Netlist-to-Netlist Optimization Flow

Timing Gate-Level Timing

Floorplan, P&R, Optimization

Guidelines for using N2N

June 2005 15 Product Version 4.2.1