Ctcug

Physical Compiler®
Clock Tree Synthesis

User Guide
Version U-2003.06-PCE3.0, June 2003
Comments?
E-mail your comments about Synopsys
documentation to doc@synopsys.com
Copyright Notice and Proprietary Information
Copyright  2003 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”
Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CoCentric,
COSSAP, CSim, DelayMill, Design Compiler, DesignPower, DesignWare, Device Model Builder, EPIC, Formality,
HSPICE, Hypermodel, I, iN-Phase, in-Sync, InSpecs, LEDA, MAST, Meta, Meta-Software, ModelAccess, ModelExpress,
ModelTools, PathBlazer, PathMill, Photolynx, Physical Compiler, PowerArc, PowerMill, PrimeTime, RailMill, Raphael,
RapidScript, Saber, SiVL, SmartLogic, SNUG, SolvNet, Stream Driven Simulator, Superlog, System Compiler, Testify,
TetraMAX, TimeMill, TMA, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™)
abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail,
Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit
Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE,
Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design
Analyzer, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, Direct RTL, Direct Silicon Access, DW8051,
DWPCI, Dynamic Model Switcher, Dynamic-Macromodeling, ECL Compiler, ECO Compiler, EDAnavigator, Encore,
Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FormalVera, FoundryModel, FPGA
Compiler II, FPGA Express, Frame Compiler, Frameway, Galaxy, Gatran, HDL Advisor, HDL Compiler, Hercules,
Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace,
HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, iQBus, Jupiter, Jupiter-DP, JupiterXT,
JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Libra-Visa, Library Compiler, LRC, Mars, Mars-Rail, Mars-Xtalk,
Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200,
MS-3400, NanoSim, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, OpenVera,
Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT,
Power Compiler, PowerCODE, PowerGate, ProFPGA, Progen, Prospector, Proteus OPC, Protocol Compiler, PSMGen,
Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow
Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel
Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT,
Star-Sim, Star-Sim XT, Star-Time, Star-XP, SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography,
Taurus-OPC, Taurus-Process, Taurus-Topography, Taurus-Visual, Taurus-Workbench, The Power in Semiconductors,
TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4,
TymeWare, VCS, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator,
VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)

DesignSphere, MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
AMBA is a trademark of ARM Limited. ARM is a registered trademark of ARM Limited.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.
Document Order Number: 37847-000 QA

Physical Compiler Clock Tree Synthesis User Guide, Version U-2003.06-PCE3.0
ii
Contents
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
1. Introduction to Physical Compiler Clock Tree Synthesis

Benefits of Using Physical Compiler Clock Tree Synthesis . . . . . . . 1-2
Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Commands Specific to Clock Tree Synthesis . . . . . . . . . . . . . . . . . 1-12
2. Running Clock Tree Synthesis

Preparing the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Preparing Your Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Reading Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Validating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Validating Your Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
iii
Analyzing the Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Documenting Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Defining the Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Specifying the Clock Tree Root . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Using an Input Port As the Clock Tree Root . . . . . . . . . . . . . 2-12
Using an Output Pin As the Clock Root . . . . . . . . . . . . . . . . 2-13
Reporting the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Verifying the Clock Tree Root . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Determining the Default Clock Sinks . . . . . . . . . . . . . . . . . . . . . 2-17
Specifying Clock Tree Exceptions . . . . . . . . . . . . . . . . . . . . . . . 2-20
Excluding Clock Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Defining Stop Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Defining Float Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Specifying the Clock Tree References . . . . . . . . . . . . . . . . . . . . 2-24
Setting Constraints for Clock Tree Synthesis. . . . . . . . . . . . . . . . . . 2-28
Optimization Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Setting Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Setting Clock Tree Design Rule Constraints . . . . . . . . . . . . . . . 2-30
Setting Clock Tree Timing Constraints . . . . . . . . . . . . . . . . . . . . 2-34
Setting Clock Tree Buffering Constraints . . . . . . . . . . . . . . . . . . 2-35
Setting Clock Tree Routing Constraints . . . . . . . . . . . . . . . . . . . 2-38
Specifying Routing Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38
Specifying Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Determining the RC Coefficients . . . . . . . . . . . . . . . . . . . . . 2-40
iv
Handling Specific Design Characteristics . . . . . . . . . . . . . . . . . . . . 2-42
Handling Hard Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Handling Existing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
Locating Existing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . 2-44
Preserving Portions of an Existing Clock Tree . . . . . . . . . . . 2-44
Removing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Handling Non-Unate Gated Clocks . . . . . . . . . . . . . . . . . . . . . . 2-47
Handling Convergent Clock Trees . . . . . . . . . . . . . . . . . . . . . . . 2-48
Handling Overlapping Clock Paths . . . . . . . . . . . . . . . . . . . . . . 2-50
Balancing Multiple Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Verifying the Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Synthesizing the Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
Synthesizing High-Fanout Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
Analyzing the Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-60
Fine-Tuning Clock Tree Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64
Controlling the Design Rule Optimization Effort . . . . . . . . . . . . 2-64
Controlling the Skew Optimization Effort . . . . . . . . . . . . . . . . . . 2-65
Using Selective Skew Balancing . . . . . . . . . . . . . . . . . . . . . . . . 2-66
Controlling Buffer Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
Minimizing Movement of Critical Cells . . . . . . . . . . . . . . . . . . . . 2-67
Analyzing the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68
Performing Detail Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
Analyzing Routability Before Detail Routing . . . . . . . . . . . . . . . 2-70
Performing Detail Routing With a Stand-Alone Router . . . . . . . 2-71
Analyzing the Post-Route Design . . . . . . . . . . . . . . . . . . . . . . . 2-72
v
3. Hierarchical Clock Tree Synthesis
Overview of Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Creating the Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Preparing the Block for Modeling. . . . . . . . . . . . . . . . . . . . . . . . 3-5
Identifying the Interface Logic . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Extracting the Interface Logic Model . . . . . . . . . . . . . . . . . . . . . 3-6
Identifying Obstructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Deriving Keepouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Defining Keepouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Reporting Keepouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Preparing for Top-Level Clock Tree Synthesis . . . . . . . . . . . . . . . . . 3-10
Running Top-Level Clock Tree Synthesis . . . . . . . . . . . . . . . . . . . . 3-11
4. Analyzing Clock Tree Synthesis Results

Accessing Clock Tree Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Accessing Clock Tree Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Analyzing Clock Tree Timing Information . . . . . . . . . . . . . . . . . . . . 4-7
Updating Clock Tree Timing Information . . . . . . . . . . . . . . . . . . 4-7
Accessing Clock Tree Delay Information . . . . . . . . . . . . . . . . . . 4-8
Generating Clock Tree Reports . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Default Clock Tree Report . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Clock Tree Settings Report. . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Clock Tree Exceptions Report . . . . . . . . . . . . . . . . . . . . . . . 4-15
Clock Tree Design Rule Violations Report . . . . . . . . . . . . . . 4-16
Clock Tree Levels Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Clock Tree Structure Report. . . . . . . . . . . . . . . . . . . . . . . . . 4-19
vi
Viewing Clock Trees in the Physical Compiler GUI . . . . . . . . . . . . . 4-21
Viewing the Clock Trees in Visual Mode . . . . . . . . . . . . . . . . . . 4-23
Viewing the Clock Tree Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 4-28
Glossary
Index
vii
viii
Preface FIX ME!
This preface includes the following sections:
• What’s New in This Release

• About This Guide
• Customer Support
ix
What’s New in This Release
This section describes the enhancements included in Physical
Compiler clock tree synthesis version U-2003.06-PCE3.0. Unless
otherwise noted, you can find additional information about these
changes later in this book.
Enhancements
Physical Compiler clock tree synthesis version U-2003.06-PCE3.0
includes the following enhancements:
• Support of generated clocks

Physical Compiler now traces through generated clocks. During
clock tree synthesis, Physical Compiler considers both the sinks
of the primary clock and the sinks of the generated clock.
For more information about tracing through generated clocks,

see “Determining the Default Clock Sinks” on page 2-17.
• Ability to explicitly specify unbuffered nets

In prevw[ious.02 Releudes toncit en
x
• Ability to retime clock trees after clock tree synthesis
In previous releases, the timing information for synthesized clock
trees was based on the back-annotation data. The new
retime_clock_tree command enables you to retime the
synthesized clock trees in the current environment.
For more information about retiming the clock trees, see

“Updating Clock Tree Timing Information” on page 4-12.
• Local skew reporting

In many cases, local skew (the difference in arrival times of the
clock signal at sequentially adjacent registers) is a better
measure of quality of the clock tree than global skew (the
difference in arrival times of the clock signal among all registers
in a clock domain). The new cts_use_local_skew variable
controls whether the clock tree report displays global skew only
or both global and local skew.
For more information about reporting local skew data, see

“Default Clock Tree Report” on page 4-19.
Known Limitations and Resolved STARs

Information about known problems and limitations, as well as about
resolved Synopsys Technical Action Requests (STARs), is available
in the Physical Compiler Expert Release Notes.
xi
About This Guide
The Physical Compiler Clock Tree Synthesis User Guide describes
the methodology for performing clock tree synthesis using the
Physical Compiler Expert tool.
Audience
This user guide is for engineers who run clock tree synthesis within
Physical Compiler. You need to be familiar with
• Logic design, physical design, and timing principles

• Synopsys physical synthesis tools
• The UNIX operating system
If you are using a platform other than a Sun workstation, you might
see minor differences in the way you interact with your operating
system.
xii
Related Publications
For additional information about Physical Compiler clock tree
synthesis, see
• Synopsys Online Documentation (SOLD)

• Documentation on the Web, which is available through SolvNet
at http://solvnet.synopsys.com
• The Synopsys MediaDocs Shop, from which you can order
printed copies of Synopsys documents, at
http://mediadocs.synopsys.com
You might also want to refer to the documentation for the following
related Synopsys products:
• Astro
• Design Compiler
• Physical Compiler
xiii
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates command syntax.
Courier italic Indicates a user-defined value in Synopsys

syntax, such as object_name. (A user-defined
value that is not Synopsys syntax, such as a
user-defined value in a Verilog or VHDL
statement, is indicated by regular text font
italic.)
Courier bold Indicates user input—text you type verbatim—

in Synopsys syntax and examples. (User input
that is not Synopsys syntax, such as a user
name or password you enter in a GUI, is
indicated by regular text font bold.)
[] Denotes optional parameters, such as

pin1 [pin2 ... pinN]
| Indicates a choice among alternatives, such as

low | medium | high
(This example indicates that you can enter one
of three possible values for an option:
low, medium, or high.)
_ Connects terms that are read as a single term

by the system, such as
set_annotated_delay
Control-c Indicates a keyboard combination, such as

holding down the Control key and pressing c.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Indicates a path to a menu command, such as

opening the Edit menu and choosing Copy.
xiv
Customer Support
Customer support is available through SolvNet online customer
support and through contacting the Synopsys Technical Support
Center.
Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles
and answers to frequently asked questions about Synopsys tools.
SolvNet also gives you access to a wide range of Synopsys online
services including software downloads, documentation on the Web,
and “Enter a Call With the Support Center.”
To access SolvNet,
1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not
have a Synopsys user name and password, click New Synopsys
User Registration.)
If you need help using SolvNet, click SolvNet Help in the column on
the left side of the SolvNet Web page.
xv
Contacting the Synopsys Technical Support Center
If you have problems, questions, or suggestions, you can contact the
Synopsys Technical Support Center in the following ways:
• Open a call to your local support center from the Web by going to
http://solvnet.synopsys.com (Synopsys user name and
password required), then clicking “Enter a Call With the Support
Center.”
• Send an e-mail message to support_center@synopsys.com.
• Telephone your local support center.
- Call (800) 245-8005 from within the continental United States.
- Call (650) 584-4200 from Canada.
- Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.
xvi
1
Introduction to Physical Compiler Clock Tree
Synthesis 1
Performing clock tree synthesis within the Physical Compiler tool is
an integral part of the Synopsys RTL-to-placed-gates methodology.
Built on top of a common synthesis, placement, and timing
infrastructure, Physical Compiler clock tree synthesis uses
proprietary technologies to extend the Physical Compiler
capabilities, achieving the best clock tree synthesis quality of results
(QOR) with fewer iterations.
Physical Compiler clock tree synthesis uses a global approach

during timing optimization. Physical Compiler clock tree synthesis
optimizes the complete clock tree simultaneously, improving skew
without sacrificing insertion delay and vice versa, while maintaining
the critical path timing. This leads to fewer iterations to achieve
designs that meet timing and are more routable.
Introduction to Physical Compiler Clock Tree Synthesis

1-1
Physical Compiler clock tree synthesis is introduced in these
sections:
• Benefits of Using Physical Compiler Clock Tree Synthesis

• Product Overview
• Methodology Overview
• Commands Specific to Clock Tree Synthesis
Benefits of Using Physical Compiler Clock Tree

Synthesis
Physical Compiler clock tree synthesis offers the following benefits:
• Support for a variety of design styles

Physical Compiler clock tree synthesis supports the following
design characteristics:
- Flat or hierarchical designs (logical and physical hierarchy)

- Single or multiple clocks
- Generated clocks
- Ungated, simple gated, and multilevel (cascaded) gated clocks
- Hard macros, such as RAMs
In addition, Physical Compiler clock tree synthesis supports
synthesis of high-fanout nets, such as reset and scan enable
nets.
Introduction to Physical Compiler Clock Tree Synthesis: Benefits of Using Physical Compiler Clock Tree
1-2
• User control of the clock tree synthesis process
Physical Compiler clock tree synthesis allows you to guide the
following aspects of clock tree synthesis:
- Clock tree structure, including buffer and inverter reference

specification
- Maximum number of clock tree levels and number of instances
per level (for ungated clocks only)
- Clock tree exceptions (exclude pins, stop pins, and float pins)
- Design rule constraints, including maximum capacitance,
maximum fanout, and maximum transition time
- Clock tree timing constraints, including maximum skew,
maximum insertion delay, and minimum insertion delay
- Priority of clock tree timing constraints
- Routing constraints, including specification of routing layers
and routing rules
- Effort level for design rule and skew optimization
• Concurrent optimization of clock tree skew, clock tree insertion
delay, and overall design timing
Because of the integrated timing analysis capability, Physical
Compiler can direct its clock tree optimization efforts based on
the overall design timing. Physical Compiler clock tree synthesis
can
- Minimize the movement of cells on the critical path (critical cell

costing)
- Use selective skew balancing (gated clock designs only)
1-3
• Ease of use
Because Physical Compiler clock tree synthesis is built into
Physical Compiler, the design flow and methodology are
efficient. Physical Compiler clock tree synthesis
- Shares the Physical Compiler psyn_shell and graphical user

interfaces
- Shares the Physical Compiler design database
- Uses standard Synopsys logical and physical libraries
- Provides tight integration with timing analysis
- Fully supports all Physical Compiler constraints
- Enables efficient incremental physopt runs to fix setup and
hold and design rule violations after clock tree synthesis
• Built-in debug capabilities
Physical Compiler clock tree synthesis provides the following
debug capabilities:
- Textual analysis of the clock tree by using the

report_clock_tree command
- Visual analysis of the clock tree by using the Physical Compiler
graphical user interface (GUI)
- Queries of clock tree objects and attributes
• Proven timing correlation after detail routing
By using the Physical Compiler clock tree synthesis data to drive
stand-alone detail routers, excellent timing correlation has
consistently been achieved after detail routing.
1-4
• Faster turnaround time
Turnaround time is the elapsed time between starting the
synthesis step and obtaining a netlist that meets requirements.
Using an integrated tool set reduces turnaround time.
Product Overview
To use Physical Compiler clock tree synthesis, you must
• Have both a PhysOpt license and a PhysOpt-ClockTree license

• Provide the following information:
- A legalized, placed design
- A physical library with extraction parameters (for most
accurate RC calculations)
- Synthesis constraints
- Floorplan information
- Routing grid information
- Clock tree definition
Physical Compiler clock tree synthesis has the following capabilities:
• Produces clock trees that are optimized for skew and insertion
delay while preserving critical path timing
• Considers physical information (back-annotates parasitics and
wire delays)
• Recognizes placement and layer-specific routing blockages
Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

1-5
• Supports clock tree exceptions
• Has automated support for convergent and overlapping clock
trees
• Allows you to optimize for different operating conditions
• Generates detailed reports about the clock trees
The current release does not support automatic interclock skew
optimization. You can perform interclock skew optimization by
specifying both the minimum and maximum insertion delay
constraints (see “Balancing Multiple Clocks” on page 2-52 for more
information).
Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

1-6
Methodology Overview
Figure 1-1 shows the flow for clock tree synthesis within Physical
Compiler.
Figure 1-1 RTL-to-GDSII Flow
Design planning
RTL
Physical Compiler
unified synthesis
and
placement
Constraints Within
psyn_shell
Physical Compiler
clock tree synthesis
Placed design
To router
This user guide describes the methodology used to run Physical

Compiler clock tree synthesis in this flow. It is assumed that you have
used Physical Compiler to generate a legally placed design and
have the synthesis constraints and floorplan for the design.
Introduction to Physical Compiler Clock Tree Synthesis: Methodology Overview

1-7
To perform clock tree synthesis,
1. Prepare your design for clock tree synthesis.

If your design is not already in Physical Compiler memory, you
must read your design (both logical and physical information) into
Physical Compiler. To prepare for clock tree synthesis, validate
that your design
- Links to the logical and physical libraries

- Has a legal placement
- Does not have timing or congestion problems
For more information, see “Preparing Your Design” on page 2-5.
2. Define the clock trees.

- Specify the root and sinks of the clock tree.
Use the set_clock_tree_options command to define the
clock tree. For more information, see “Defining the Clock
Trees” on page 2-10.
- Specify the set of buffers and inverters used for clock tree
synthesis.
Use the set_clock_tree_references command to
specify the buffers and inverters. For more information, see
“Specifying the Clock Tree References” on page 2-24.
- Handle specific design characteristics.
Some design characteristics, such as hard macro cells,
existing clock trees, and gated clocks, require special
handling. For more information, see “Handling Specific Design
Characteristics” on page 2-42.

1-8
3. Set the constraints for clock tree synthesis.
The constraints used for clock tree synthesis might differ from the
constraints used to synthesize the design. Set the following
constraints for clock tree synthesis: operating conditions, design
rule constraints, and routing constraints. For more information,
see “Setting Constraints for Clock Tree Synthesis” on page 2-28.
4. Verify the clock tree definitions.

Use the report_clock_tree -settings -exceptions
command to verify the clock tree definitions. For more
information, see “Verifying the Clock Trees” on page 2-52.
5. Synthesize the clock trees.

Use the compile_clock_tree command to synthesize the
clock trees. For more information, see “Synthesizing the Clock
Trees” on page 2-53.
6. Analyze the results.

Use the report_clock_tree command and the Physical
Compiler GUI visualization tools to analyze the synthesized clock
trees. For more information, see Chapter 4, “Analyzing Clock
Tree Synthesis Results.”
If your design contains violations after clock tree synthesis, run

physical synthesis to improve timing (use the
optimize_placement and physopt -incremental
commands).
When you are satisfied with the results, save your design.
Figure 1-2 on page 1-10 shows the clock tree synthesis flow.

1-9
Figure 1-2 Clock Tree Synthesis Flow
Placed design
Prepare design for

Constraints clock tree synthesis Floorplan information
Define clock trees
Set constraints for

clock tree synthesis
Verify clock trees
Synthesize clock trees
Analyze clock trees
Fine-tune yes Violations

clock tree synthesis exist?
no
Analyze design
Perform yes Violations no

Save design
physical synthesis exist?

1-10
Example 1-1 shows a sample clock tree synthesis script. For more
information about the commands shown in the script, see Chapter 2,
“Running Clock Tree Synthesis.”
Example 1-1 Sample Clock Tree Synthesis Script

# define clock tree and clock tree design rule constraint
set_clock_tree_options -root CLK_port -clock CLK
-max_fanout 50
# specify clock tree exceptions

set_clock_tree_exceptions -exclude TEST_port
# specify clock reference list

set_clock_tree_references -references {CLKBUF16 CLKBUF20}
# verify clock trees

report_clock_tree -clock CLK -settings -exceptions
# perform clock tree synthesis

compile_clock_tree
# analyze results
report_clock_tree -clock CLK -level_info -settings
report_constraint
report_timing
# refine the design

physopt -incremental

1-11
Commands Specific to Clock Tree Synthesis
Table 1-1 summarizes commands specific to Physical Compiler
clock tree synthesis.
Table 1-1 Summary of Commands Specific to Clock Tree

Synthesis
Command Description
compile_clock_tree Based on the clock tree definition, builds a clock tree

for the driver pin of each specified net.
get_clock_tree_attributes Returns attribute lists of specified clock trees at or

below the current design or current instance.
get_clock_tree_delays Returns raw data about the clock tree delays. This
command is best used as input to a script that
manipulates the reported data.
get_clock_tree_objects Returns a formatted list of collections of clock tree

objects for the specified clock tree at or below the
current design or current instance.
remove_clock_tree Removes the specified clock trees.
remove_clock_tree_exceptions Removes previously defined float pins, exclude pins,

stop pins, and don’t touch subtree pins from a clock
tree.
remove_clock_tree_options Removes the clock tree object from the database.
report_clock_tree Reports the clock tree definition settings and

exceptions, the clock tree structure, the clock tree
timing characteristics, and the clock tree design rule
violations.
reset_clock_tree_references Removes a previously defined reference from a clock

tree.
set_clock_tree_references Specifies the buffers and inverters that can be used in

synthesizing a specified clock tree.
Introduction to Physical Compiler Clock Tree Synthesis: Commands Specific to Clock Tree Synthesis
1-12
Table 1-1 Summary of Commands Specific to Clock Tree
Synthesis (Continued)
Command Description
set_clock_tree_exceptions Defines float pins, stop pins, exclude pins, and don’t
touch subtree pins.
set_clock_tree_options Defines the clock tree, including the clock root, the
design rule constraints, buffering constraints, and
routing constraints. Also traces the net and determines
the default set of clock sinks.
1-13
1-14
2
Running Clock Tree Synthesis 2
You use Physical Compiler to perform clock tree synthesis as
described in these sections:
• Preparing the Libraries

• Preparing Your Design
• Defining the Clock Trees
• Setting Constraints for Clock Tree Synthesis
• Handling Specific Design Characteristics
• Verifying the Clock Trees
• Synthesizing the Clock Trees
• Synthesizing High-Fanout Nets
• Analyzing the Clock Trees
Running Clock Tree Synthesis

2-1
• Fine-Tuning Clock Tree Synthesis
• Analyzing the Design
• Performing Detail Routing
If your design has no physical hierarchy, you perform these steps on
the top-level design. If your design contains physical hierarchy, you
perform these steps on each block, then complete the clock tree
synthesis by creating models for each block and using these models
to perform clock tree synthesis at the top level. For more information
about hierarchical clock tree synthesis, see Chapter 3, “Hierarchical
Clock Tree Synthesis.”
You can also use Physical Compiler clock tree synthesis to

synthesize buffer trees on high-fanout nets, such as reset and scan
enable nets. For more information about synthesizing high-fanout
nets, see “Synthesizing High-Fanout Nets” on page 2-57.
Running Clock Tree Synthesis

2-2
Preparing the Libraries
Physical Compiler clock tree synthesis uses both logical and
physical libraries. Before running clock tree synthesis, verify that
• The logical library does not have dont_use or dont_touch

attributes on the clock references
• The logical library contains valid trip-point values
Some libraries define the trip-point values as 100/0. These are
invalid trip-point values and can cause a large number of design
rule violations to occur after clock tree synthesis.
To see the trip-point values set in the technology library, run the
report_lib command. If your technology library uses 100/0
trip points, disable the library trip points and use user-defined trip
points instead. To disable the library trip points, set the
lib_thresholds_per_lib variable to false (the default value
is true). To set user-defined trip points, set the following variables:
- rc_slew_lower_threshold_pct_rise
- rc_slew_lower_threshold_pct_fall
- rc_slew_upper_threshold_pct_rise
- rc_slew_upper_threshold_pct_fall
If your library does not contain trip points and you do not specify
user-defined values, Physical Compiler uses the default trip-point
values of 80/20.
• The physical library contains all clock references
Running Clock Tree Synthesis: Preparing the Libraries

2-3
• The physical library contains information about minimum
conditions (for hold time calculations)
If your library does not contain minimum conditions, use the
set_delay_estimation_options command to specify the
scaling factor for minimum conditions.
• The physical library contains the information required for routing

If your design requires wide wires for the clock tree, the physical
library must also contain these nondefault routing rules. You can
add routing rules to the physical library by using the
define_routing_rules command.
• The physical library contains the extraction parameters required

for determining the RC coefficients.
The required extraction parameters are
- field_oxide_thickness
- field_oxide_permittivity
- avg_lateral_oxide_thickness
- lateral_oxide
- avg_lateral_oxide_permittivity
- oxide_thickness
- oxide_permittivity
- metal_thickness
- metal_resistivity
Running Clock Tree Synthesis: Preparing the Libraries

2-4
If your physical library does not contain these extraction
parameters, use the extract2plib utility to extract them from
existing technology files. For more information about the
extract2plib utility, see the man page.
For information about how Physical Compiler determines RC

coefficients during clock tree synthesis, see “Determining the RC
Coefficients” on page 2-40.
Preparing Your Design

Before running clock tree synthesis, you must complete the following
tasks:
1. Read your design into Physical Compiler.

Physical Compiler clock tree synthesis requires both logical
information (netlist and synthesis constraints) and physical
information (floorplan, placement, and routing track definition)
about the design.
2. Validate your design.

Do not proceed until you have validated your design and are
happy with the results. Your design must be linked to the logical
and physical technology libraries, have a legal placement, and be
without congestion problems before you can continue.
3. Validate your clocks.

Although the clock objects defined by the create_clock
command are independent of the clock tree objects used by clock
tree synthesis, the clock objects must be correctly defined in
order for you to get the best results from clock tree synthesis.
Running Clock Tree Synthesis: Preparing Your Design

2-5
4. Analyze the clock trees.
Before you begin clock tree synthesis, you must understand the
characteristics of each clock tree structure in your design and the
relationships between the clock trees (especially if you have
convergent or overlapping clocks).
5. Document the design’s status before clock tree synthesis.

Generate and save the design performance reports. You will
compare these reports with the reports you generate after
running clock tree synthesis.
The following sections describe these tasks.
Reading Your Design

Physical Compiler clock tree synthesis requires both logical
information (netlist and synthesis constraints) and physical
information (floorplan, placement, and routing track definition) about
the design.
The Physical Compiler design database generated by the physopt

or compile_physical command provides this information for
clock tree synthesis. This design database contains both the logical
and physical information. If the design database is not already in
Physical Compiler memory, read in the file you previously saved in
Synopsys database (.db) format.
If the design database does not contain a routing track definition or

if the defined routing tracks do not cover the entire placement area,
clock tree synthesis ends with the following message:
Error: Design database does not have routing grid. (CTS-134)

2-6
If you see this message, you must update the design database with
the routing track definition (DEF_TRACK statements in the Physical
Design Exchange Format (PDEF) file) before running clock tree
synthesis. Physical Compiler cannot perform global routing on the
clock nets without this information.
Validating Your Design

Validate your design by generating the following reports:
• Link report
Link the design to the logical and physical technology libraries
specified by the link_library and physical_library
variables.
psyn_shell-t> current_design my_design

psyn_shell-t> link my_design
psyn_shell-t> link_physical_library
• Placement legality report

To ensure that the design is legally placed, run the
check_legality command.
psyn_shell-t> check_legality
• Routing congestion
Determine the routability of the design by using the
report_congestion command and the Physical Compiler
GUI congestion map.
psyn_shell-t> report_congestion > my_design_prects.cong
If your design is highly congested, you must fix the congestion

problem before running clock tree synthesis. If your design has a
high concentration of clock sinks in a congested area, apply a

2-7
region-based congestion threshold
(set_congestion_options -coordinate command) to
that area and rerun the physopt command with the appropriate
congestion options. For more information about resolving
congestion problems, see the Physical Compiler User Guide.
Validating Your Clocks

To validate the clocks, ensure that
• The clock root is correctly modeled

Verify that the library model for the root cell is accurate and that
the input transition time is correct.
• The timing budget used during physical synthesis (the physopt

command) reflects the clock tree synthesis goals
- Set the clock network latency as the internal clock delay (the
target maximum insertion delay)
psyn_shell-t> set_clock_latency delay my_clk
- Set the clock source latency as the external clock delay (the
clock latency)
psyn_shell-t> set_clock_latency -source delay my_clk
- Include the clock source latency when specifying the input and
output delays
psyn_shell-t> set_input_delay -clock my_clk \
delay ports
psyn_shell-t> set_output_delay -clock my_clk \
delay ports

2-8
• The network uncertainty and network transition time are correctly
defined
- Set the clock network uncertainty as the target maximum skew
psyn_shell-t> set_clock_uncertainty skew my_clk
- Set the clock network transition time as the maximum range of

clock ramps inside the clock tree
psyn_shell-t> set_clock_transition ramp my_clk
Analyzing the Clock Trees

Before running clock tree synthesis, analyze each clock tree in your
design to determine its characteristics and its relationship to other
clock trees in the design.
For each clock tree, determine
• What the clock root is

• What the desired clock sinks and clock tree exceptions are
Physical Compiler supports the following types of clock tree
exceptions: exclude pins, stop pins, and float pins. For details
about these exceptions, see “Specifying Clock Tree Exceptions”
on page 2-20.
• Whether the clock tree contains preexisting cells, such as clock

gating cells
• Whether the clock tree converges, either with itself (a convergent
clock path) or with another clock tree (an overlapping clock path)
• Whether the clock tree has timing relationships with other clock
trees in the design, such as interclock skew requirements

2-9
Use this information when you define the clock trees and to validate
that Physical Compiler has the correct clock tree definitions before
you run clock tree synthesis.
Documenting Your Design

Document the performance of the design before clock tree synthesis
by generating the following reports:
• Timing
psyn_shell-t> report_timing > my_design_prects.tim
• Constraints
psyn_shell-t> report_constraints > my_design_prects.cstr
Save the results. You will compare these reports with the reports you
generate after running clock tree synthesis.
Defining the Clock Trees

A clock tree is defined by its startpoint (referred to as the clock root
or clock source) and its endpoints (referred to as the clock sinks).
During clock tree synthesis, Physical Compiler balances the delay
and optimizes the skew from the clock tree root to the clock sinks.
You must specify the clock tree root. Physical Compiler uses timing
arcs to trace the network from the clock tree root to the clock pins of
sequential elements to determine the default set of clock sinks. You
can modify this default set of clock sinks to meet your requirements.
Running Clock Tree Synthesis: Defining the Clock Trees

2-10
Each clock tree must have a unique root and a unique name. You
define a clock tree by specifying its root and, optionally, its name. If
you do not specify a clock tree name, Physical Compiler uses the
root name as the clock tree name.
Use the set_clock_tree_options command to define the clock

tree. Use the required -root option to specify the clock root and the
optional -clock_tree_name option to specify the clock tree name,
if desired.
Note:
The set_clock_tree_options command creates a clock
tree object. Clock tree objects are independent of the clock
objects created by the create_clock command.
A clock tree can have only one root. If you rerun

set_clock_tree_options with a previously specified clock root,
the new definition is added to the existing one. If you redefine an
existing option, the new definition overwrites the existing one. To
redefine a clock tree starting with the default values, use the
remove_clock_tree_options command to remove the existing
clock tree definition, before running the
set_clock_tree_options command.
Physical Compiler adds a prefix consisting of the clock tree name

and level to all instances added during clock tree synthesis. For
example, the prefix for objects added to level 2 of clock tree CLK1 is
CLK1L2. If you prefer to use a string other than the clock tree name
in the prefix, specify the string by using the -prefix option. The
level is added to the prefix whether you use the clock tree name or a
user-specified string.

2-11
Specifying the Clock Tree Root
A clock tree root can be either an input port of the design or an output
pin of a cell in the design. In either case, you specify the clock tree
root by using the -root option of the set_clock_tree_options
command. This option is required to define a clock tree. In some
cases, you must provide additional information to define the clock
tree.
Using an Input Port As the Clock Tree Root

If the clock tree root is an input port, in addition to specifying the port
name, you must accurately specify th

2-12
Using an Output Pin As the Clock Root
You can use an output pin of the following types of cells as a clock
root: library cells, hierarchical blocks, interface logic models, and
black box cells.
If the cell has a single timing arc to the clock root, you need only
specify the pin name to define the clock tree.
For example, to define a clock tree, CLK1, that uses output pin Z of
instance U1 as its root, enter
psyn_shell-t> set_clock_tree_options \
-root [get_pins U1/Z] -clock_tree_name CLK1
If the cell has multiple timing arcs to the clock root, Physical Compiler
selects a timing arc for you and generates a warning message.
However, to get the best results, you should identify the controlling
input by specifying the -timing_arc option.
For example, if output Z of clock gating cell U1 drives the root of clock
tree CLK1 (and the clock input is input U1/A), enter
-root [get_pins U1/Z] -clock_tree_name CLK1 \
-timing_arc [get_pins U1/A]
If there are no timing arcs to the clock root, Physical Compiler

generates a warning message and assumes that the clock root has
infinite drive strength.

2-13
Reporting the Clock Tree
When you run the set_clock_tree_options command, it
generates a clock tree summary report. This report shows the
number of clock sinks for the specified root, as shown in
Example 2-1.
Example 2-1 Clock Tree Summary

****************************************
Report : Clock Tree Summary
Design : my_design
Version:
Date : Thu Mar 28 09:36:57 2002
****************************************
Clock Tree Name : "CLK"
Clock Tree root pin : "my_design/CLK"
Number of Sinks : 712
Number of CT Buffers : 0
Number of Preexisting Cells : 0
Total gate capacitance : 2.136000
-----------------------------------------
Level 0 Level 1
-----------------------------------------
No of Buffers 0 0
No of Preexist. Cells 0 0
No of Sinks 0 712
Min driven gate cap 2.13600 N/A
Max driven gate cap 2.13600 N/A
min fanout 712 N/A
max fanout 712 N/A

2-14
Verifying the Clock Tree Root
In some cases, if the clock tree root violates the design rule or clock
tree timing constraints, Physical Compiler will not synthesize the
clock trees.
Therefore, before running clock tree synthesis, verify that your clock
tree root does not have any of the following violations:
• Maximum capacitance violation

This error occurs when the clock tree root is a top-level port and
the back-annotated external load (the sum of the wire
capacitance and the load attributes of the port) violates the
maximum capacitance design rule.
• Maximum transition time violation

This error occurs in the following situations:
- The clock tree root is a top-level port and the transition time
(assuming zero internal load) violates the maximum transition
time design rule.
- The clock tree root is a leaf-cell pin and the transition time
(assuming a minimum load) violates the maximum transition
time design rule.
• Maximum insertion delay violation
This error occurs when the clock tree root is a leaf-cell pin and
the insertion delay (assuming a minimum load) violates the
maximum insertion delay constraint.
If these violations occur, the compile_clock_tree command

generates an error message and stops running.

2-15
To fix these violations when the clock tree root is a top-level port, use
the following methods:
• Increase the drive strength of the clock tree root port.

• Relax the design or clock tree synthesis maximum capacitance
constraint.
• Remove or reduce the load and wire_capacitance attributes
of the clock tree root port.
To fix these violations when the clock tree root is a leaf-cell pin, use
the following methods:
• Replace the root cell with a logical equivalent cell that has a
higher drive strength.
• Verify that the constraint on the library model of the root cell is
feasible.
• Verify that the constraint for the design and for clock tree
synthesis is reasonable. Do not try to control constraint priority by
setting the constraint to zero—use the
set_clock_tree_options -priority command instead.
• If the root cell has high input transition times, determine the
cause and fix them.
Methods for fixing high input transition times include (but are not
limited to)
- Buffering the fanin of the root cell

- Increasing the drive strength of the fanin net driver
- Removing or relaxing ideal or back-annotated clock transitions
propagated to the root cell input

2-16
For details about a specific violation, see the error message man
page. For more information about design rule constraints (maximum
capacitance and maximum transition time), see “Setting Clock Tree
Design Rule Constraints” on page 2-30. For more information about
clock tree timing constraints (maximum insertion delay), see “Setting
Clock Tree Timing Constraints” on page 2-34.
Determining the Default Clock Sinks

By default, Physical Compiler traces through all cells in the transitive
fanout of the clock root as long as it finds at least one output pin that
satisfies the following conditions:
• At least one valid path exists from the input pin on the clock path
to the output pin. Physical Compiler considers the following types
of paths to be valid:
- A combinational timing path
The following types of timing arcs create noncombinational
timing paths: clock posedge, clock negedge, three-state
enable, three-state disable, and all timing check arcs. All other
types of timing arcs create combinational timing paths.
- A sequential timing path (clock posedge or clock negedge)
when the output pin is the source of a generated clock
Combinational timing paths have priority over generated clocks.
If a cell has both types of paths, Physical Compiler traces through
the combinational path and ignores the generated clock.
If a cell has more than one combinational timing path, Physical

Compiler selects an output pin and generates the CTS-019
warning message to notify you of the choice. Use the

2-17
set_disable_timing command to disable as many unwanted
timing arcs in the cell as needed to force a specific output pin to
be selected.
• The output pin has at least one fanout.

• The output pin is not connected to a pad cell or a top-level output
port.
Note:
Physical Compiler does not trace through cell timing arcs that
have been disabled with the set_disable_timing or
set_case_analysis commands. Physical Compiler does
trace through all net timing arcs, even if they are disabled.
If the tracing stops due to a noncombinational timing arc, the input

pin of the last cell becomes a clock sink.
The types of pins that become default clock sinks include
• Clock pins of sequential cells (unless an output of the sequential

cell is the source of a generated clock)
Note:
To prevent tracing through generated clocks on a specific clock
tree, specify the -dont_trace_generated_clocks option
when you run the set_clock_tree_options command.
• Three-state enable pins
To view the list of default clock sinks, generate a verbose clock tree
report (report_clock_tree -verbose command).

2-18
Note:
The report_transitive_fanout command does not take
into account the exceptions specified by the
set_clock_tree_exceptions command. Its results might
differ from the clock tree report.
When the tracing stops because one of the other conditions is not
met, Physical Compiler creates an implicit exclude pin (for
information about exclude pins, see “Excluding Clock Sinks” on
page 2-21). The types of pins that become implicit exclude pins
include
• Pins of combinational cells that do not have at least one fanout

• Pins of combinational cells with disabled timing arcs
• Top-level output ports
• Input pins of pad cells
• Some data pins of flip-flops or memories
To view the list of implicit exclude pins, generate a clock tree
exceptions report (report_clock_tree -exceptions). In the
clock tree exceptions report, the implicit exclude pins are reported as
“inferred.”
Note:
Implicit exclude pins are not stored in the design database.
To prevent Physical Compiler from inferring exclude pins, set the

cts_no_implicit_exclude_pins variable to true.
To override an inferred exclude pin (and use the pin as a clock sink),
define the pin as a stop pin. For information about defining stop pins,
see “Defining Stop Pins” on page 2-22.

2-19
The following configurations are not supported and cause errors
when the compile_clock_tree command is run:
• A net in the clock network has more than one driver.

• The clock root is not a top-level input port, and the root cell does
not have any timing arcs ending at the root pin.
Specifying Clock Tree Exceptions

You can modify the default set of clock sinks by specifying clock tree
exceptions. Physical Compiler supports the following types of clock
tree exceptions:
• Exclude pins
Exclude pins are clock tree endpoints that are not included in the
set of clock sinks. Physical Compiler does not use exclude pins
in clock tree timing (skew and insertion delay) calculations and
optimizations.
• Stop pins
Stop pins are clock tree endpoints that you explicitly specify.
Physical Compiler treats the specified pin as a clock sink, adding
clock instances and calculating insertion delay up to this pin.
Physical Compiler does not trace beyond the stop pin. Any
insertion delay between the specified pin and a default clock sink
is ignored.
• Float pins
Float pins are clock pins that have special insertion delay
requirements. Physical Compiler adds the float pin insertion
delay (positive or negative) to the calculated insertion delay up to
this pin.

2-20
Excluding Clock Sinks
Clock tree endpoints that are not used in clock tree timing (skew and
insertion delay) calculations and optimizations are called exclude
pins. There are two types of exclude pins:
Implicit
Physical Compiler creates implicit exclude pins during clock tree
tracing. For more information about implicit exclude pins, see
“Determining the Default Clock Sinks” on page 2-17.
Explicit
You create explicit exclude pins by using the
set_clock_tree_exceptions -exclude_pins command
to specify excluded pins.
Physical Compiler identifies explicit exclude pins by setting the
ct_is_exclude_pin attribute on the specified pins.
When you create an explicit exclude pin, the pin you specify as
the exclude pin does not need to be a clock sink. If the pin is not
a clock sink, the tree branches that fan out from the specified pin
are excluded.
For example, to exclude clock sink U2/CLK, enter
psyn_shell-t> set_clock_tree_exceptions \
-exclude_pins [get_pins U2/CLK]
For another example, assume that a clock tree also drives

combinational logic, as shown in Figure 2-1. To exclude all branches
of the clock tree that fan out from this point, enter
-exclude_pins [get_pins U2/A]

2-21
Figure 2-1 Explicit Exclude Pin
CLK
A n1
B
U2
During clock tree synthesis, exclude pins (both implicit and explicit)
are typically connected at the last level of the clock tree. Although
Physical Compiler does not perform skew or insertion delay
optimization beyond the exclude pin (net n1 in Figure 2-1), it does
trace beyond this pin and fixes design rule constraint violations that
occur beyond the exclude pin.
Defining Stop Pins

Defining a stop pin creates a clock sink on a pin that is not a default
clock sink. For example, you might define a stop pin to end a branch
at an input to a combinational cell or to use an implicit exclude pin as
a clock sink.
Physical Compiler adds clock instances and calculates insertion

delay only up to the stop pin. Physical Compiler does not trace
beyond the stop pin. Any insertion delay between the stop pin and a
default clock sink is ignored.
To define a stop pin, use the set_clock_tree_exceptions

-stop_pins command. Physical Compiler sets the
ct_is_stop_pin attribute on the specified pins.

2-22
For example, to specify pin U2/A as a branch endpoint, enter
-stop_pins [get_pins U2/A]
Defining Float Pins

When you define a pin as a float pin, you change the relative arrival
time of that pin by specifying a float pin insertion delay. During timing
computations, Physical Compiler adds the specified float pin
insertion delay to the external insertion delay computed to the float
pin.
You can specify either a positive or a negative value for the float pin
insertion delay. If you specify a positive insertion delay for a float pin,
Physical Compiler decreases the external insertion delay to that pin
by connecting the float pin closer to the clock root. If you specify a
negative insertion delay for a float pin, Physical Compiler increases
the external insertion delay to that pin by adding extra buffers.
To define a float pin and its timing characteristics, use the following
options of the set_clock_tree_exceptions command:
• -float_pins
• -float_pin_max_delay
• -float_pin_min_delay

2-23
Physical Compiler places the following attributes on a float pin:
ct_floatpin_clock_tree_name
Boolean value that indicates whether the pin is a float pin.
ct_floatpin_min_del
Minimum insertion delay of the float pin.
ct_floatpin_max_del
Maximum insertion delay of the float pin.
For example, to decrease the insertion delay to register U1, enter
-float_pin [get_pins U1/CLK] \
-float_pin_max_delay 0.10 \
-float_pin_min_delay 0.10
Specifying the Clock Tree References

By default, Physical Compiler can use all buffers and inverters in your
technology library during clock tree synthesis. Use the
set_clock_tree_references command to restrict the set of
buffers and inverters used during clock tree synthesis.
Note:
For best results, specify the intended clock buffers and inverters.
Do not rely on the default set of buffers and inverters.
You can specify several references (both buffers and inverters) to

give the clock tree algorithm flexibility in constructing the clock tree
and generally to improve clock tree results. For best results, limit the
size of the reference list to a maximum of five.

2-24
Black box cells with a single input, single output, and appropriate
timing information can be specified as clock tree references.
If you issue the set_clock_tree_references command

multiple times, the new references you specify are added to existing
references. References you previously listed but omit from a later list
are not deleted. To delete references, use the
reset_clock_tree_references command.
You can specify the reference list for a specific clock tree (use the
-clock_tree option) or for all clock trees (omit the -clock_tree
option). To specify the reference list for a specific clock tree, you must
define the clock tree before you run the
set_clock_tree_references -clock_tree command. If the
specified clock tree is not defined, the tool generates the CTS-110
warning message and ignores the specified reference list.
For example, to create a reference list for clock tree CLK1, enter
psyn_shell-t> set_clock_tree_references -clock_tree CLK1 \

-references {clk1a3 clk1a6 clk1a9}
To create a global reference list, enter
psyn_shell-t> set_clock_tree_references \
-references {clk1a6 clk1a9 clk1a15 clk1a27}
For more control, you can select a specific reference from a clock
tree’s reference list to use on each level of the clock tree. To specify
a level-specific reference, use the set_clock_tree_options
-reference_per_level reference_list command. The
reference_list argument is a list of references that specifies one
reference per level. You can use an asterisk (*) to indicate that
Physical Compiler should select a reference from the clock tree’s
reference list for a specific level. Physical Compiler uses the

2-25
rightmost reference for the last (nth) level of the clock tree (the level
closest to the clock sink). Previous references in reference_list are
used for level n-1, level n-2, and so on.
Note:
The -reference_per_level option is supported only for
ungated and one-level gated clocks.
For example, assume that you require the clk1a9 reference on the
last and second-to-last levels of the clock tree, and you want Physical
Compiler to select the reference for all other levels of the clock tree.
To specify this requirement, enter
psyn_shell-t> set_clock_tree_options -clock_tree CLK1 \

-root [get_port CLK1] \
-reference_per_level {clk1a9 * clk1a9}
The priority that Physical Compiler uses to determine the reference

list used for a specific clock tree level during clock tree synthesis is
1. Level-specific reference
2. Clock tree-specific reference list
3. Global reference list
4. Default reference list
The report generated by the report_clock_tree -settings
command shows the references that are available for clock tree
synthesis. Example 2-2 shows the portion of a clock tree report that
contains this information. In addition to listing the available
references, the report shows the design rule constraint settings used
for these references during clock tree synthesis. For information
about interpreting and validating these values, see “Setting Clock
Tree Design Rule Constraints” on page 2-30.

2-26
Example 2-2 Clock Tree Report—Reference List
****************************************
Report : Physical Compiler Clock Tree
Design : my_design
Version: 2002.05-PCE1
Date : Thu Aug 15 09:12:15 2002
****************************************

...
Settings for Clock Tree CLK {

...
Buffers Available for clock tree synthesis

"clk1a9" (maxLoad: 1.239 , maxSlew: 0.700 *, maxFanout: 50 *)
"clk1a9" -library- (maxLoad: 1.239 , maxSlew: 0.500 , maxFanout: 25 )
Design DRC constraints (maxLoad: 2.000, maxSlew: 0.500, maxFanout: 25)

Clock Tree DRC constraints (maxLoad: N/A , maxSlew: 0.700, maxFanout: N/A )
Root DRC constraints (maxLoad: 2.000, maxSlew: 0.500, maxFanout: 25)
}

2-27
Setting Constraints for Clock Tree Synthesis
The constraints used for synthesizing the design and the constraints
used for synthesizing the clock tree might differ. Before running clock
tree synthesis, you must understand the clock tree synthesis
optimization priorities, which are covered in the next section. Then
perform the following steps to ensure that you are using the proper
constraints:
• Set the operating conditions

• Set the design rule constraints
• Set the timing constraints
• Set the buffering constraints
• Set the routing constraints
Optimization Priorities
By default, Physical Compiler prioritizes the clock tree synthesis
optimization goals as follows:
1. Design rules
a. Meet maximum capacitance constraint
b. Meet maximum transition time constraint
c. Meet maximum fanout constraint
Running Clock Tree Synthesis: Setting Constraints for Clock Tree Synthesis
2-28
2. Clock tree timing and buffering
a. Meet maximum skew constraint
b. Meet maximum insertion delay constraint
c. Minimize instance area
d. Minimize instance count
Note:
Although the other constraints discussed in the following
pages affect the clock tree synthesis results, they are not
considered optimization goals, so they are not listed here.
During clock tree synthesis, Physical Compiler can synthesize
several versions of the clock trees and use the clock tree timing
and buffering priorities to select the implementation that best
meets your requirements. This capability is called iterative
optimization and is automatically done for any clock tree with up
to 2000 sinks.
By default, Physical Compiler does not perform iterative

optimization for clock trees with more than 2000 sinks. You can
improve the clock tree QOR, at a cost of increased runtime and
memory usage, by enabling iterative optimization. To enable
iterative optimization, set the cts_iterative_optimization
variable to true.
If meeting the skew constraint is not your highest priority, use the
set_clock_tree_options -priority command to specify
your highest priority goal. Note that to change the optimization
priority, you must also set the
cts_iterative_optimization variable to true. For more
information about this variable, see “Fine-Tuning Clock Tree
Synthesis” on page 2-64.
Table 2-1 shows the keywords supported by this command.
2-29
Table 2-1 Constraint Priority Keywords
Keyword Clock tree optimization goal
skew Meet maximum skew constraint
delay Meet maximum insertion delay constraint
area Minimize instance area
instances Minimize instance count
Setting Operating Conditions

The operating conditions for optimizing the design might not be the
same as the conditions you want when you synthesize clock trees.
First use the set_operating_conditions command with no

options to remove the existing operating conditions, then use the
command again with options to set the minimum and maximum
operating conditions you want for clock tree synthesis. Physical
Compiler uses the minimum operating conditions only to update the
minimum delays on the clock nets; it does not use the minimum
values during clock tree synthesis.
For more information about this command, see the man page.
Setting Clock Tree Design Rule Constraints

Physical Compiler supports the following design rule constraints for
clock tree synthesis:
• Maximum capacitance
• Maximum transition time
• Maximum fanout
2-30
You can set these design rule constraints in the logical library, on the
design, on the clock trees, or on the clock references. Physical
Compiler determines the design rule constraints for clock tree
synthesis in the following order:
1. Design rule constraints on the clock references (as set by the

set_clock_tree_references command)
Design rule constraints set on a clock reference apply only to new
buffers and inverters with that reference added during clock tree
synthesis.
2. Design rule constraints on the clock trees (as set by the

set_clock_tree_options command)
Design rule constraints set on a clock tree apply to all cells in the
clock tree, including any preexisting cells.
3. Synthesis design rule constraints

If you do not specify design rule constraints for a clock tree,
Physical Compiler uses the most restrictive values from the
technology library, the design, or the clock port.
4. Clock tree synthesis defaults

If synthesis design rule constraints do not exist for a clock tree,
Physical Compiler uses the defaults shown in Table 2-2.
2-31
Table 2-2 Default Design Rule Constraints for Clock Tree Synthesis
Constraint Default
Maximum capacitance 1 pF
Maximum transition time 1 ns
Maximum fanout input_pin_load

Integer portion of ----------------------------------------------
max_capacitance
(with a minimum value of 20)
The clock tree settings report generated by the

report_clock_tree -settings command shows design rule
constraint settings for the design, each clock tree, the clock tree root,
and each reference that is available for clock tree synthesis. The
following values are reported: maximum capacitance (maxLoad),
maximum transition time (maxSlew), and maximum fanout
(maxFanout). Example 2-3 shows a portion of a clock tree settings
report that contains this information.
Example 2-3 Design Rules for Clock Tree References

...
Buffers Available for clock tree synthesis
"clk1a9" -library- (maxLoad: 1.239 , maxSlew: N/A , maxFanout: N/A )
"clk1a6" -library- (maxLoad: 0.821 , maxSlew: N/A , maxFanout: N/A )
Clock Tree DRC constraints (maxLoad: N/A , maxSlew: 0.700, maxFanout: N/A)
}
...
The values reported for the design, the clock trees, and the clock tree
root are the clock tree synthesis constraints. For each reference,
both the logic synthesis and clock tree synthesis constraints are
listed. The first line for a reference (without -library-) shows the
design rule constraints that are used for clock tree synthesis. The
2-32
second line (with -library-) shows the design rule constraints that are
used for logic synthesis. An asterisk in the first line indicates that the
design rule constraint is specific to clock tree synthesis (a value
specified in a set_clock_tree_options or
set_clock_tree_references command, or a default value set
by Physical Compiler).
Review these values. If any of the values are incorrect for clock tree
synthesis, you can override them by using the -max_capacitance,
-max_transition, and -max_fanout options of the
set_clock_tree_references or set_clock_tree_options
command.
Note:
The report_constraint command does not account for clock
tree synthesis design rule constraints; only the synthesis design
rule constraints are considered in their results.
2-33
Setting Clock Tree Timing Constraints
You can specify the following clock tree timing constraints for a clock
tree:
• Maximum skew
During optimization, Physical Compiler computes the skew value
by comparing the arrival times of all clock signals in a clock
domain, including those that do not communicate through data
paths (global skew).
To specify the maximum skew for a clock tree, use the

set_clock_tree_options -max_skew command.
• Maximum insertion delay

To specify the maximum insertion delay for a clock tree, use the
set_clock_tree_options -max_delay command.
• Minimum insertion delay

To specify the minimum insertion delay for a clock tree, use the
set_clock_tree_options -min_delay command. You can
also use this command to guide the skew balancing between
clock trees. For more information, see “Balancing Multiple
Clocks” on page 2-52.
By default, the priority of clock tree timing constraints is
1. Maximum skew
2. Maximum insertion delay
You can change the priority by using the
set_clock_tree_options -priority delay command.
2-34
Physical Compiler checks the minimum insertion delay after
synthesizing the initial clock tree based on the constraints listed in
“Optimization Priorities” on page 2-28. If the synthesized clock tree
does not meet the specified minimum insertion delay, Physical
Compiler inserts buffers at the clock root to fix the violation.
Setting Clock Tree Buffering Constraints

Physical Compiler automatically determines the appropriate clock
tree buffering configuration for your design. You should not specify
buffering constraints for your initial clock tree synthesis run.
Physical Compiler provides buffering constraints to fine-tune your

results when you rerun clock tree synthesis. Physical Compiler tries
to meet these constraints, but design rule constraints have a higher
priority. Physical Compiler might violate the buffering constraints to
meet the design rule constraints.
You can specify the following buffering constraints:
• The maximum number of levels (for ungated clocks only)

Use the set_clock_tree_options -number_of_levels
cnt command to specify this constraint. For example, to specify
that clock tree CLK has a maximum of four levels, enter
-root [get_port CLK] -number_of_levels 4
Note:
If the clock reference list contains only inverters, Physical
Compiler might adjust the maximum number of levels to
maintain the correct logic and polarity.
2-35
• The minimum number of instances per level (for ungated clocks
only)
Use the set_clock_tree_options
-number_of_instances_per_level cnt_list command
to specify this constraint. The last number in the list specifies the
minimum number of instances in the last level (closest to the
clock sinks), the preceding number specifies the minimum
number of instances for the next-to-last level, and so on. For
example, to specify 8 instances at the last level, 4 instances at
the second-to-last level, 2 instances at the third-to-last level, and
1 instance at the fourth-to-last level, enter
-root [get_port CLK] \
-number_of_instances_per_level {1 2 4 8}
• The unbuffered nets

In your initial clock tree synthesis run, you should not modify the
buffering requirements. However, there might be cases in which
you can improve the results by preventing Physical Compiler from
buffering certain nets (Physical Compiler still performs global
prerouting on these nets).
You can prevent buffering by
- Specifying minimum buffering requirements

You can specify either a fanout requirement, a delay
requirement, or both. The two limits work together, so you
might need to adjust both limits.
By default, Physical Compiler inserts instances into the clock
tree after any driver that has a fanout greater than 32. To
prevent Physical Compiler from inserting clock tree instances
after a low-fanout driver, set the set_clock_tree_options
2-36
-fanout_limit_for_route_only_clock_net cnt
command to specify the minimum fanout required for Physical
Compiler to insert instances after a driver.
Also by default, Physical Compiler inserts instances into the
clock tree wherever they are required. To prevent Physical
Compiler from inserting clock tree instances in fast paths, use
the set_clock_tree_options
-delay_limit_for_route_only_clock_net delay
command to specify the minimum delay required for Physical
Compiler to insert instances in a path. If you are using a 0.18
micron technology, a typical minimum delay value is between
0.4 and 0.5 ns. To buffer more nets, use a minimum value of
0.3 ns.
- Explicitly specifying the unbuffered nets
The only nets that you can explicitly specify as unbuffered are
nets that directly drive a clock sink. To prevent Physical
Compiler from buffering this type of net, use the
set_clock_tree_exceptions
-global_route_only_subtrees pins command to
specify the output pin that drives the net.
Caution!
If you specify this exception for a net that does not directly drive
a clock sink, Physical Compiler does not generate a warning
message; however, the tool ignores the exception and buffers
the net.
To control buffering on these nets, specify minimum buffering
requirements, as described on page 2-36.
2-37
Setting Clock Tree Routing Constraints
Physical Compiler allows you to specify two types of clock tree
routing constraints:
• The routing layers to use

• The routing rule (type of wire) to use
You can specify none, one, or both of these constraints.
Specifying Routing Layers

If you do not specify which routing layers to use for clock tree
synthesis, Physical Compiler uses the routing layers that result in the
best timing (the minimum amount of insertion delay). Typically, the
selected routing layers have lower resistance and capacitance and
are less congested.
To override the default routing layers, use the

set_clock_tree_options -layer_list command.
-clock_tree_name CLK1 -root [get_ports CLK1] \
-layer_list {metal4 metal5}
Note:
Physical Compiler ignores absolute user-defined RC coefficients
when you specify the routing layers; however, it applies
user-defined RC scaling factors.
2-38
Specifying Routing Rules
If you do not specify which routing rule (wire type) to use for clock
tree synthesis, Physical Compiler uses the default routing rule
(default wires) to route the clock trees. To reduce the wire delays in
the clock trees, you can use wide wires instead. Wide wires are
represented by nondefault routing rules.
Use the set_clock_tree_options -routing_rule command

to specify the routing rule for a clock tree. You can specify a single
routing rule per clock tree. The rout
2-39
To see which nets have nondefault routing rules, run the
report_net_routing_rules command.
psyn_shell-t> report_net_routing_rules \
[get_nets * -filter "@has_cts_ba==true"]
--------- Nets with non-default routing rules ---------

ck_rxX125m : SP
ck_tx125m : SP1xW2xS
ck_tx125m_L2I28950_Y : SP1xW2xS
..
..
ck_rxX125m_L4I28480_Y : SP
..
..
Determining the RC Coefficients

If your physical library contains extraction parameters, such as
field_oxide_thickness and lateral_oxide_thickness,
Physical Compiler computes the resistance and capacitance
coefficients for the specified routing layers and routing rules based
on these extraction parameters.
Note:
“Preparing the Libraries” on page 2-3 provides the complete list
of extraction parameters required to perform extraction-based
RC computation.
2-40
To indicate that RC computation is based on extraction parameters,
Physical Compiler generates the following message:
Information: Extractor based RC computation is enabled. (PSYN-140)
If you want to use extracted RCs and you do not see this message,
check for the following conditions:
• The design has user-defined RCs.

If user-defined RCs exist, use the
set_delay_estimation_options -default command to
remove them.
• The physical library does not contain extraction parameters.

If you have a technology file, run the extract2plib utility to add
extraction parameters to the physical library. For more
information about the extract2plib command, see “Preparing
the Libraries” on page 2-3.
• The lateral_oxide and metal_thickness numbers in the

physical library are the same.
If these numbers are the same, Physical Compiler ignores the
extraction parameters. Overcome this condition by running
extract2plib and checking that the numbers are different.
If your library does not contain extraction parameters, Physical

Compiler uses the area capacitance and edge capacitance (or area
capacitance, coupling capacitance, and fringe capacitance,
depending on the style of your physical library). In this case, to get
the best results you should route your design after running clock tree
synthesis, correlate the RC coefficients, and then rerun clock tree
synthesis.
2-41
Handling Specific Design Characteristics
There are several design styles that might require special
considerations during clock tree synthesis. These design styles
include
• Hard macro cells

• Existing clock trees
• Non-unate gated clocks
• Converging clock paths
• Overlapping clock paths
• Multiple clocks (with balanced skew)
The following sections describe how to use Physical Compiler clock
tree synthesis with these design styles.
Handling Hard Macro Cells

The internal delays for a hard macro cell are represented in the cell’s
timing model. Physical Compiler uses the timing model to determine
the external clock pins of the hard macro cell and uses these pins as
clock sinks. During clock tree synthesis, Physical Compiler performs
skew balancing and insertion delay minimization up to these external
clock pins. No additional specification is required for hard macro
cells.
If you do not have a timing model for the hard macro cell, use float
pins to specify the timing characteristics of the clock trees internal to
the hard macro. You define the timing characteristics by specifying
Running Clock Tree Synthesis: Handling Specific Design Characteristics

2-42
the minimum and maximum insertion delay seen from the float pin to
the clock sinks that are internal to the macro. For information about
defining float pins, see “Defining Float Pins” on page 2-23.
Caution!
Do not define float pins if you have a timing model for the hard
macro cell. Doing so can cause invalid timing information and can
create timing violations in your design.
For example, assume that you do not have a timing model for a RAM.
Timing analysis shows that the delay of the precompiled clock tree
from the RAM_block/CLK port to the earliest sink is 0.33 ns, and the
delay to the latest endpoint is 0.52 ns.
The following command defines these timing characteristics for

Physical Compiler clock tree synthesis:
-float_pin [get_pins RAM_block/CLK] \
-float_pin_max_delay 0.52 \
-float_pin_min_delay 0.33
Handling Existing Clock Trees

If your design contains existing clock trees, you must decide how to
handle them before you perform clock tree synthesis. You can
choose to keep a clock tree (or a portion of it) or to remove the clock
tree.

2-43
Locating Existing Clock Trees
The clock tree summary generated by the
set_clock_tree_options command (as shown in Example 2-1
on page 2-14) indicates the number of preexisting cells identified in
the clock tree. (You can also run the report_clock_tree
command to display this information.)
Preexisting cells form a clock tree when they meet both of the
following conditions:
• The cells are either buffers or inverters.

To report the cell types, run the report_clock_tree
-verbose or report_transitive_fanout -clock_tree
command.
Note:
The report_transitive_fanout command does not take
into account the exceptions specified by the
set_clock_tree_exceptions command. Its results might
differ from those in the clock tree report.
• The number of levels reported by the report_clock_tree
-clock_tree clk_tree -level_info is two or greater.
Preserving Portions of an Existing Clock Tree

In some cases you will want to preserve a portion of an existing clock
tree. You need to do this, for example, when two clock networks
share part of some clock logic behind a multiplexer or when you have
a bottom-up physical hierarchy flow (for an example, see “Handling
Overlapping Clock Paths” on page 2-50). The portion of the clock
tree that is preserved is called a don’t touch subtree.

2-44
During clock tree synthesis, the don’t touch subtree is not affected,
but Physical Compiler considers the sinks in the don’t touch subtree
when balancing clock delays and computing the clock skew.
There are two types of don’t touch subtrees: implicit and explicit.
Physical Compiler creates an implicit don’t touch subtree when it

finds a clock net with the has_cts_ba attribute set. The driving pin
of that net becomes the startpoint of the don’t touch subtree.
You create an explicit don’t touch subtree by using the

-dont_touch_subtrees option of the
set_clock_tree_exceptions command. Physical Compiler
sets the ct_is_dont_touch_subtree attribute on the specified
pin to identify it as the startpoint of an explicit don’t touch subtree.
Before you use this exception, ensure that the nets in the subtree are
routed and that back-annotation is applied to the nets. If some nets
in the transitive fanout were not properly buffered and
back-annotated when they were inserted or completed using a
third-party tool, the post-layout correlation of clock tree delays will
probably be very poor. Best practice is to run the
compile_clock_tree command on the subtree root; this does all
the necessary steps: global preroute, delay estimation,
back-annotation, and preservation of the data.
Important:
The nets in the subtree must have the has_cts_ba attribute set.
If this attribute is not set, the compile_clock_tree command
generates an error message and exits.

2-45
During clock tree synthesis, no modifications are made on the clock
tree nets in the don’t touch subtree (for example, no buffering, global
prerouting, attribute setting, or back-annotation). Physical Compiler
calculates the insertion delay value during clock tree synthesis by
using the existing back-annotated delays.
Note:
Clock tree synthesis does not honor the dont_touch attribute.
If you apply a dont_touch attribute to a clock tree net or cell and
do not apply the dont_touch_subtrees exception, the clock
tree might be modified.
Removing Clock Trees

Use the remove_clock_tree command to remove existing clock
trees.
psyn_shell-t> remove_clock_tree -clock_trees my_clock
By default, the remove_clock_tree command ignores synthesis

attributes, such as dont_touch and dont_touch_placement,
while honoring clock tree attributes, such as
dont_touch_subtrees. To have both synthesis attributes and
clock tree attributes honored, specify the -honor_dont_touch
option when running remove_clock_tree.
By default, the remove_clock_tree command removes all buffers

and inverters in the clock tree. To remove only those buffers and
inverters inserted by Physical Compiler, specify the
-synopsys_only option when running remove_clock_tree.
Note:
Use the remove_clock_tree command before resynthesizing
the clock trees only when you want to keep some of the inserted
trees but resynthesize others. If you want to resynthesize all clock

2-46
trees, rerun clock tree synthesis using your original design from
Physical Compiler as input, as described in “Reading Your
Design” on page 2-6.
Handling Non-Unate Gated Clocks

If the clock gating logic uses a non-unate cell, such as an XOR or
XNOR gate, Physical Compiler uses the positive-unate timing arc
when tracing the clock path. If this choice does not correspond to the
functional mode of your design, use the set_case_analysis
command to hold all nonclock inputs of the cell at a constant value.
In this way you force the cell into the desired functional mode for
timing analysis during clock tree synthesis.
For example, suppose your design has the gating logic shown in
Figure 2-2.
Figure 2-2 Non-Unate Gated Clock

CLK A
U0
B
To force the XOR gate (U0) into functional mode for timing analysis,
enter the following command:
psyn_shell-t> set_case_analysis 0 U0/B

2-47
Handling Convergent Clock Trees
Figure 2-3 shows a convergent clock tree. In this figure, MUX_A is
the convergence cell. The output pin of the convergence cell is the
root of the convergent clock subtree.
Figure 2-3 Converging Clocks
Convergence cell
CK CK
Primary clock root
CK CK CK
MUX_A
A Z
CLK CK
B
CK
CK
CK
CK
CK
Convergent
clock subtree
Synthesizing the convergent clock tree requires first synthesizing the

convergent clock subtree, then synthesizing the primary clock tree.
Physical Compiler automatically detects convergent clock paths

within a single clock tree and synthesizes the convergent clock
subtree before the primary clock tree. When Physical Compiler
detects a convergent clock, it generates the CTS-123 message. This
message identifies the root of the convergent clock subtree.
Information: Convergent clock paths in clock network at output pin

subtree_root (CTS-123)

2-48
If you do not specify a prefix when you define a convergent clock
tree, Physical Compiler uses clk_name_sub_subtree_root for all
instances inserted into the convergent clock subtree.
If you want to manually compile the portions of a convergent clock

tree (for example, to apply different compile options for the various
portions), disable automatic handling of convergent clock trees by
setting the cts_use_auto_convergence_subtrees variable to
false.
Note:
You must either allow Physical Compiler to automatically detect
and synthesize all convergent clock paths in your design or you
must manually compile all convergent clock paths in the design.
You cannot mix these two methods within a single
compile_clock_tree run.
To manually compile the portions of a convergent clock tree,
1. Set the cts_use_auto_convergence_subtrees variable to

false.
You must define both the primary clock tree and the convergent
clock subtree (which has the output pin of the convergence cell
as its root).
3. Compile the clock trees.

You must compile the convergent clock subtree first, then compile
the primary clock trees. After compiling the subtree, Physical
Compiler places a dont_touch_sub_tree attribute on the
convergent clock subtree.

2-49
If a convergent clock subtree contains converging clock paths, follow
this procedure for each subtree, compiling the subtrees in bottom-up
order.
Example 2-4 shows a script to manually compile the convergent

clock tree shown in Figure 2-3 on page 2-48.
Example 2-4 Script to Manually Compile Convergent Clocks

set_clock_tree_options -root [get_pin MUX_A/Z]
set_clock_tree_options -root [get_port CLK]
compile_clock_tree -clock_trees {MUX_A/Z CLK}
Handling Overlapping Clock Paths

Figure 2-4 shows an overlapping clock path. In this figure, MUX_A is
the overlap cell. The output pin of the overlap cell is the root of the
overlapping clock subtree.
Figure 2-4 Overlapping Clocks

Overlapping
clock subtree
CLKA
MUX_A
CLKB
Overlap cell

2-50
Physical Compiler automatically handles overlapping clock paths.
When you synthesize the first primary clock in the overlapping clock
path, Physical Compiler synthesizes the entire clock tree, including
the overlapping clock subtree. When you synthesize subsequent
primary clocks in the overlapping clock subtree, Physical Compiler
synthesizes the clock only up to the overlap cell.
If you want to manually compile the portions of an overlapping clock

path (for example, to apply different compile options for the various
portions), use the following procedure:

Define both the overlapping clock subtree (which has the output
pin of the overlap cell as its root) and the primary clock trees.
2. Compile the clock trees.

You must compile the overlapping clock subtree first, then
compile the primary clock trees. After compiling the subtree,
Physical Compiler places a dont_touch_sub_tree attribute
on the overlapping clock subtree.
Example 2-5 shows a script to compile these overlapping clock

paths.
Example 2-5 Script to Compile Overlapping Clocks

set_clock_tree_options -root [get_pin MUX_A/Z]
set_clock_tree_options -root [get_port CLKA]
set_clock_tree_options -root [get_port CLKB]
compile_clock_tree -clock_trees {MUX_A/Z CLKA CLKB}

2-51
Balancing Multiple Clocks
If your design has multiple clocks and you want the clock skew
balanced between the clocks, you must perform two passes of clock
tree synthesis.
In the first pass, perform clock tree synthesis on each clock to get the
best individual results.
Before running the second pass, determine the largest minimum

insertion delay value and specify this value as the minimum insertion
delay (set_clock_tree_options -min_delay) for each clock.
Rerun clock tree synthesis, using your original design from Physical
Compiler as input.
Verifying the Clock Trees

Before you synthesize the clock trees, verify that the clock trees are
properly defined. To see the current clock tree definition, use the
report_clock_tree -settings -exceptions command. For
more information about this command, see “Generating Clock Tree
Reports” on page 4-17.
Running Clock Tree Synthesis: Verifying the Clock Trees

2-52
Synthesizing the Clock Trees
Use the compile_clock_tree command to synthesize the clock
trees.
psyn_shell-t> compile_clock_tree
By default, Physical Compiler synthesizes the clock trees in the order

that you specified them with the set_clock_tree_options
command.
To control the order of synthesis, specify the -clock_trees

clk_list option when you run compile_clock_tree. Physical
Compiler compiles the clock trees in the specified order. The names
in the clk_list argument must match either the root pin or the clock
tree name of clock trees you specified using
set_clock_tree_options.
When you synthesize the clock trees, usually you sequence the
clocks so that the clock with the largest number of sinks or with the
tightest constraints is first. You can determine which clock has the
most sinks from the clock tree report.
The compile_clock_tree command performs the following

tasks:
1. Checks for design rule violations on the clock root

If the clock root has design rule violations before clock tree
synthesis begins, it will not be possible to meet the design rule
constraints after clock tree synthesis. If Physical Compiler
detects design rule violations on the clock root, it generates an
error message and does not synthesize the clock tree.
Running Clock Tree Synthesis: Synthesizing the Clock Trees

2-53
2. Synthesizes and balances the clock trees
Physical Compiler uses two passes to synthesize the clock trees.
In the first pass, Physical Compiler uses a bottom-up approach to
synthesize the clock trees. In the second pass, Physical Compiler
performs a top-down refinement of the clock trees.
In the first pass, Physical Compiler uses only the buffers and
inverters included in the clock reference list to build the clock
trees. For information about specifying the clock reference list,
see “Specifying the Clock Tree References” on page 2-24.
In the second pass, Physical Compiler can use any buffer or

inverter in your technology library to improve the timing of the
clock trees. To restrict top-down refinement to the use of the
buffers and inverters included in the clock reference list, set the
cts_use_all_buffers_for_refinement variable to false
before running the compile_clock_tree command.
3. Places and legalizes the clock buffers and inverters

Physical Compiler places the clock buffers and inverters in the
locations required by the clock tree. If necessary, Physical
Compiler moves existing (unfixed) cells to accommodate the
clock tree cells.
If your design has logical hierarchy, Physical Compiler places the

clock buffers and inverters in the same logical block as the
original clock driver. Physical Compiler adds new pins to the
hierarchical blocks as required by the clock tree.
After placing the clock tree cells, Physical Compiler legalizes the
placement of these cells. Physical Compiler legalizes the
placement of the non-clock-tree cells after completing clock tree
synthesis (see step 10).

2-54
4. Performs global routing on the clock tree nets and saves this
information in the design database
5. Estimates clock delays and parasitics based on the global routes
6. Back-annotates the clock delays and parasitics onto the design
Physical Compiler sets the has_cts_ba attribute on the clock
nets to prevent subsequent physopt or run_router
commands from updating the back-annotated clock trees.
Physical Compiler back-annotates minimum delays based on the

minimum conditions in the physical library. If your physical library
does not contain minimum conditions, use the
set_delay_estimation_options command to specify the
scaling factors for minimum conditions.
7. Marks the clock root, nets, cells, gating cells, and sinks as
dont_touch, dont_touch_network, and
dont_touch_placement
Note:
Physical Compiler places these attributes on all clock tree
objects, including those in don’t touch subtrees.
If you plan to do an incremental physical optimization on the clock
tree, you can prevent these attributes from being placed on the
clock tree objects. Table 2-3 lists the compile_clock_tree
options you can use for this purpose.

2-55
Table 2-3 compile_clock_tree Options to Control Attribute Setting
Attribute Option
dont_touch -no_dont_touch
dont_touch_network -no_dont_touch_network
dont_touch_placement -no_dont_touch_placement
8. Places the ct_is_snps_added attribute on the inserted clock

tree instances and nets
9. Converts the synthesized clock networks from ideal to
propagated
After clock tree synthesis, the timing behavior of clocks is as
follows:
- The clock roots (clock tree objects) are changed to propagated

mode (the clock paths to internal clock pins have propagated
delays).
- The clock root (clock tree object) uncertainty is set to zero.
- The clock objects remain in ideal mode (ideal latency of I/O
port timing is preserved).
- The clock object uncertainty is preserved.
- The ideal clock transition is removed from the clock object.
To prevent Physical Compiler from updating the clock attributes
after clock tree synthesis, specify the -no_clock_attributes
option when you run the compile_clock_tree command.

2-56
10. Legalizes the design
After all clock trees are synthesized, Physical Compiler legalizes
the design by legalizing the overlapping non-clock-tree cells.
11. Performs global routing on the non-clock-tree nets and

back-annotates the delays and parasitics for these nets onto the
design
Synthesizing High-Fanout Nets

In addition to synthesizing clock trees, you can use Physical
Compiler clock tree synthesis to synthesize buffer trees on
high-fanout nets. This section describes how to do this and explains
the differences between high-fanout net synthesis and clock tree
synthesis.
To synthesize a buffer tree for a high-fanout net,
1. Define the high-fanout nets.

Like a clock tree, a high-fanout net is defined by its startpoint
(root) and its endpoints. Use the set_clock_tree_options
command with the -high_fanout option to define the
high-fanout nets. Physical Compiler uses the same algorithm to
determine the endpoints of a high-fanout net as for a clock tree.
For details about defining the root, see “Specifying the Clock Tree
Root” on page 2-12. For details about the endpoint tracing
algorithm, see “Determining the Default Clock Sinks” on
page 2-17.
Running Clock Tree Synthesis: Synthesizing High-Fanout Nets

2-57
2. Set constraints for the high-fanout nets.
During high-fanout net synthesis, Physical Compiler focuses on
meeting the maximum capacitance and maximum transition time
design rule constraints. By default, Physical Compiler ignores the
maximum fanout constraint during high-fanout net synthesis. To
make the tool honor the maximum fanout constraint, specify the
-honor_max_fanout option when running
compile_clock_tree. For details, see “Setting Constraints for
Clock Tree Synthesis” on page 2-28.
3. Synthesize the high-fanout nets.

Use the compile_clock_tree command to synthesize the
high-fanout nets.
When synthesizing high-fanout nets, the compile_clock_tree

command behaves differently than it does in the process described
in “Synthesizing the Clock Trees” on page 2-53. The
compile_clock_tree command performs the following tasks
when synthesizing high-fanout nets:
1. Checks for design rule violations on the root (step 1 in the clock
tree synthesis process)
2. Synthesizes and balances the buffer trees (step 2 in the clock
3. Places and legalizes the buffers and inverters (step 3 in the clock
During high-fanout net synthesis, Physical Compiler does not put
dont_touch and dont_touch_placement attributes on the
newly added buffers.

2-58
4. Places the ct_is_snps_added attribute on the inserted buffer
tree instances and nets (step 8 in the clock tree synthesis
process)
5. Converts the synthesized clock networks from ideal to
propagated (step 9 in the clock tree synthesis process)
This step affects nets driven by a clock object. If the root of the
high-fanout net is not defined as a clock, this step has no effect
for high-fanout net synthesis.
6. Legalizes the design (step 10 in the clock tree synthesis process)

Because the newly added buffers do not have dont_touch or
dont_touch_placement attributes, these buffers might be
moved during legalization.
7. Performs global routing on all nets (including the synthesized

high-fanout nets) and back-annotates the delays and parasitics
for these nets onto the design (step 11 in the clock tree synthesis
process)
Unlike a synthesized clock tree, the global preroutes for the
high-fanout net are not stored in the design database.
Optimizing or legalizing the design after high-fanout net synthesis

can change the placement of the buffers in the high-fanout buffer
tree. If this occurs, Physical Compiler reestimates the synthesized
net and updates the delay information.
To use the default behavior of the compile_clock_tree

command instead of the modified behavior, set the
cts_skip_high_fanout_default_settings variable to true
before running high-fanout net synthesis.

2-59
Analyzing the Clock Trees
After synthesizing the clock trees, analyze the results to verify that
they meet your requirements. Use the clock tree levels report
(report_clock_tree -level_info command), the clock tree
design rule violations report (report_clock_tree
-drc_violators command), and the Physical Compiler GUI
visual analysis capabilities to analyze the results.
Use the clock tree reports to check the following parameters:
• Maximum skew
• Maximum insertion delay
• Wire length (and routing layers used)
• Design rule constraint violations
• Number of levels in each clock tree
• Number and area of clock instances (buffers and inverters)
Use the Physical Compiler GUI visual analysis mode to verify the
clock instance placement.
For details on these analysis capabilities, see Chapter 4, “Analyzing

Clock Tree Synthesis Results.”
Running Clock Tree Synthesis: Analyzing the Clock Trees

2-60
If the synthesized clock trees do not meet your requirements, first
check the following items:
• The input design

Ensure that the input design meets the requirements for clock
tree synthesis. For information about the presynthesis design
requirements, see “Validating Your Design” on page 2-7.
• The physical library

Ensure that the physical library contains the appropriate routing
and extraction information. For information about physical library
requirements, see “Preparing the Libraries” on page 2-3.
• The preexisting gates

For gated clocks, if the preexisting gates are low-drive gates, you
should size them up before running clock tree synthesis.
• The clock root

Verify that you have correctly defined the clock root, including
setting a driving cell if the clock root is a top-level input port. Verify
that the attributes of the clock root, such as the input transition
time and output capacitance, are correct. Verify that the library
model for the root cells is accurate. For more information, see
“Specifying the Clock Tree Root” on page 2-12.
• The clock sinks

Run the report_clock_tree -exceptions command to
verify that the clock tree exceptions (both implicit and explicit) are
correctly set. For information about default clock sinks and clock
tree exceptions, see “Specifying Clock Tree Exceptions” on
page 2-20.

2-61
• The trip-point values
Changing the trip points can lead to differences in the number of
design rule violations and the QOR of the resulting clock tree.
Using a very small trip point can result in a large number of
design rule violations. If you get the TIM-163 warning message,
verify that you are using accurate trip points. For information
about checking and setting trip points, see “Preparing the
Libraries” on page 2-3.
• The design rule constraints

Run the report_clock_tree command to verify the design
rule constraints and check that they are realistic. If your clock
trees have too many cells or levels, this typically indicates that the
design rule constraints are too tight. For information about
checking and modifying the design rule constraints, see “Setting
Clock Tree Design Rule Constraints” on page 2-30.
If these items are correct, you can fine-tune the clock tree synthesis
process and resynthesize the clock trees. Physical Compiler
provides the following methods to fine-tune the clock tree synthesis
process:
• Modifying the clock tree optimization algorithm

For more information, see “Fine-Tuning Clock Tree Synthesis” on
page 2-64.
• Defining the clock tree structure

For more information, see “Setting Clock Tree Buffering
Constraints” on page 2-35.

2-62
• Refining the reference list
If your clock tree has too many levels, it could be that the clock
tree references have a low drive strength. Evaluate the
references in your reference list and modify it, if necessary. For
information on specifying the reference list, see “Specifying the
Clock Tree References” on page 2-24.
To resynthesize all clock trees, rerun clock tree synthesis using your
original design from Physical Compiler as input, as described in
“Reading Your Design” on page 2-6.
To keep some of the inserted clock trees but resynthesize others,

use the remove_clock_tree command to remove the clock trees
to be resynthesized. For more information about removing clock
trees, see “Removing Clock Trees” on page 2-46. The
compile_clock_tree command does not remove existing clock
instances.

2-63
Fine-Tuning Clock Tree Synthesis
By default, Physical Compiler uses a default algorithm for optimizing
the clock tree. When you perform your initial clock tree synthesis run,
use this default algorithm.
To fine-tune your results when rerunning clock tree synthesis, you

can vary the algorithm. Physical Compiler provides the following
ways of controlling clock tree optimization:
• Controlling the design rule optimization effort

• Controlling the skew optimization effort
• Using selective skew balancing
• Controlling buffer sizing
• Minimizing movement of critical non-clock-tree cells
The following sections describe these methods.
Controlling the Design Rule Optimization Effort

Physical Compiler provides two levels of design rule optimization
effort. You control which effort level is used by specifying the
compile_clock_tree -drc_effort option. Table 2-4 shows
the keywords and recommended uses for each effort level. By
default, Physical Compiler uses medium design rule effort.
Running Clock Tree Synthesis: Fine-Tuning Clock Tree Synthesis

2-64
Table 2-4 Design Rule Effort Levels
Design rule effort keyword Recommended use
medium (default) Use medium effort for your initial clock tree synthesis run.
high Use high effort if medium effort does not result in suitable
DRC QOR. Using high effort improves the DRC QOR, but
might increase the number of buffers in the clock tree.
Controlling the Skew Optimization Effort

Physical Compiler provides four levels of skew optimization effort.
You control which effort level is used by specifying the
compile_clock_tree -skew_effort option. Table 2-5 shows
the keywords and recommended uses for each effort level. With the
exception of low effort, all effort levels are suitable for both gated and
ungated clock trees. By default, Physical Compiler uses medium
skew effort.
Table 2-5 Skew Effort Levels

Skew effort keyword Recommended use
low Use low effort only for ungated clock trees.
medium (default) Use medium effort for your initial clock tree synthesis run.
high Use high effort if medium effort does not result in suitable
QOR.
ultra Use ultra effort if you require further skew improvements than
the high effort results provide; however, ultra effort can result
in longer clock nets.

2-65
Using Selective Skew Balancing
In some gated clock designs, Physical Compiler can improve both
clock tree QOR (buffer count) and overall design timing by ignoring
noncritical sinks during skew balancing. Physical Compiler
determines which sinks are noncritical based on the timing of the
paths originating from the sinks.
Note:
For best results, you must set the clock uncertainty to realistic
values before starting clock tree synthesis. For more information
about clock uncertainty, see “Validating Your Clocks” on
page 2-8.
To ignore noncritical sinks during skew balancing, modify the clock

tree definition for each affected clock by using the
set_clock_tree_options -ignore_noncritical_sinks
command.
psyn_shell> set_clock_tree_options -clock_tree_name CLK1 \

-root [get_ports CLK1] -ignore_noncritical_sinks
Note:
This technique works only for gated clocks. It does not affect
results for ungated clocks.
When you specify the -ignore_noncritical_sinks option for a

clock, Physical Compiler calculates the skew and insertion delay
only to the gate that drives the noncritical sinks. This affects both
clock tree synthesis and clock tree reporting. To force the
report_clock_tree command to report the skew and insertion
delay to all sinks in the design, including those in the noncritical
subtrees, specify the -include_noncritical_sinks option
when you run the command.

2-66
Controlling Buffer Sizing
To meet the constraints, Physical Compiler sizes preexisting cells in
the clock tree. By default, Physical Compiler selects the minimum
buffer size that meets the constraints. If you prefer stronger drivers,
Physical Compiler can use the largest drivers instead. To upsize the
drivers, specify the -size_gates option when running the
compile_clock_tree command.
Minimizing Movement of Critical Cells

During clock tree synthesis, the legalization process moves
non-clock-tree cells that overlap with clock tree cells. In some cases,
this movement can degrade the timing of the design.
Physical Compiler can use a critical cell costing algorithm to

minimize timing degradation that is due to the movement of critical
cells. The critical cell costing algorithm assigns a relative cost to
each cell, then takes this cost into account when determining the
placement of the clock tree cells. To enable the critical cell costing
algorithm, set the cts_cell_costing variable to true.
Note:
Critical cell data is not stored in the design database.

2-67
Analyzing the Design
After you are satisfied with the clock tree synthesis results, analyze
the QOR of the entire design by running the following commands:
• report_constraint
• report_timing
Use the reports to check the following parameters:
• Worst negative slack (WNS)

• Total negative slack (TNS)
• Design rule constraint violations
If necessary, refine your design by using the following optimizations:
1. Optimize the placement

If the design is close to meeting your requirements, optimizing
the placement might be all that is required to complete the
design. This option makes the fewest changes to the existing
design.
To optimize the placement, use the optimize_placement

command. This command optimizes timing for critical paths by
relocating cells in critical paths.
psyn_shell-t> optimize_placement
For more information about the optimize_placement

command, see the man page.
Running Clock Tree Synthesis: Analyzing the Design

2-68
2. Perform an incremental physical optimization
An incremental physical optimization uses the existing placement
as the starting point for a new run, allowing you to continue
working on the design to achieve timing closure.
To perform incremental physical optimization, use the physopt

-incremental command.
psyn_shell-t> physopt -incremental
For more information about incremental physical optimization,

see the Physical Compiler User Guide.
Both of these optimizations might affect the congestion of your

design. After optimizing your design, always check the congestion.
For information on analyzing and correcting congestion problems,
see the Physical Compiler User Guide.
When you are satisfied with the results, save your design.
psyn_shell-t> write -hierarchy -format db \

-output design_postcs.db
Running Clock Tree Synthesis: Analyzing the Design

2-69
Performing Detail Routing
Before performing detail routing, you can analyze the routability of
the design and predict the post-route correlation by running global
routing in Physical Compiler.
When you perform detail routing, you should first route the clock
trees, then route the rest of the design. To perform detail routing,
export the design database to a stand-alone router (either Astro or a
third-party router).
After routing, read the post-route design back into Physical Compiler
to perform post-route analysis.
Analyzing Routability Before Detail Routing

To analyze the routability of the design,
1. Perform global routing.

Use the route_global command to perform global routing on
the design. This command performs global routing on the entire
design. During global routing, Physical Compiler considers the
global preroutes added for the clock trees during clock tree
synthesis.
2. Extract the parasitics.

Use the extract_rc command to extract the RC information
from the global routed design.

Use the report_clock_tree command to analyze the routed
clock trees.
Running Clock Tree Synthesis: Performing Detail Routing

2-70
Performing Detail Routing With a Stand-Alone Router
To use a stand-alone router (Astro or a third-party router), you must
provide a netlist and a Design Exchange Format (DEF) file.
To achieve good post-route correlation, you must forward-annotate

the global preroute and routing rule information for the clock nets
from Physical Compiler to the stand-alone router.
To generate the netlist, enter the following command:
psyn_shell-t> write -hierarchy -format fmt \

-output design_postcts.fmt
To generate the DEF file, enter the following command:
psyn_shell-t> write_def -output design_postcts.DEF
The write_def command updates the USE CLOCK (on clock nets)
and SOURCE TIMING (on inserted clock instances) constructs in
the DEF file.

2-71
Analyzing the Post-Route Design
To analyze the design after detail routing,
1. Read the post-route design (in PDEF format) back into Physical
Compiler.
2. Extract the parasitics.
Use the extract_rc command to extract the RC information
from the global routed design.

Use the report_clock_tree command to analyze the routed
clock trees.

2-72
3
Hierarchical Clock Tree Synthesis 3
To perform hierarchical clock tree synthesis, you use interface logic
models to represent the blocks, then you perform physical
optimization and clock tree synthesis at the top level. This chapter
provides an overview of interface logic models and describes the
steps required to complete clock tree synthesis on a hierarchical
design. It is assumed that you have already run clock tree synthesis
on each of the blocks in your design, using the steps described in
Chapter 2, “Running Clock Tree Synthesis.”
This chapter contains the following sections:
• Overview of Interface Logic Models

• Creating the Interface Logic Models
• Running Top-Level Clock Tree Synthesis
3-1
Overview of Interface Logic Models
This section provides an overview of interface logic models. For
detailed information about using interface logic models with Physical
Compiler, see the chapter about interface logic models in the
Physical Compiler User Guide, Volume 1.
An interface logic model is a structural model of a circuit that is

modeled as a smaller circuit representing the interface logic of the
block. The interface logic model contains the cells whose timing is
affected by or affects the external environment of a block. Using
interface logic models enhances capacity and reduces runtime for
top-level optimization and clock tree synthesis.
By default, an interface logic model contains the following logic:
• The logic between the input ports and the first register
• The logic between the last register and the output ports
• The logic from the clock input port to the clock pins of the
interface registers
• The logic that loads the nets along the clock path to an interface
register (these elements are called side-load cells)
• The logic on purely combinational paths
An interface logic model does not contain logic from register-to-
register paths within the block.
Hierarchical Clock Tree Synthesis: Overview of Interface Logic Models

3-2
Figure 3-1 shows the elements contained in an interface logic model
(these elements are referred to collectively as the interface logic).
The shaded elements are the elements on the clock path; the striped
elements are the side-load cells. Unshaded elements are not
included in the model.
Figure 3-1 Interface Logic Model
Data Data
out
in
Clock
To reduce the model size, you can exclude certain ports and their
fanout or fanin logic from the model.
For a more detailed model, you can include the following logic in the
interface logic model:
• All macro cells, even those that are not on interface timing paths
Macro cells include both cells that are defined as macro cells in
the physical library and large black box cells.
• Boundary logic of all ignored ports

The boundary logic includes the cells and nets directly connected
to ignored ports.
Hierarchical Clock Tree Synthesis: Overview of Interface Logic Models

3-3
Generated clocks are treated like clock ports. Interface registers
driven by a generated clock are retained in the model. Registers
driven by a generated clock that are in internal register-to-register
paths are not included in the model.
By default, latches found in interface logic are assumed to be

potential borrowers and are considered to be combinational logic.
However, you can specify the number of latch levels over which time
borrowing can occur for latch chains that are a part of the interface
logic.
Creating the Interface Logic Models

Before you can create an interface logic model, you must complete
all the steps described in Chapter 2, “Running Clock Tree
Synthesis.”
To create an interface logic model,
1. Prepare the block for modeling.

2. Identify the interface logic cells of the block.
3. Extract the interface logic model.
4. Identify obstructions caused by the interface logic model
(optional).
The following sections describe these steps.
Hierarchical Clock Tree Synthesis: Creating the Interface Logic Models

3-4
Preparing the Block for Modeling
To prepare a block for modeling,
1. Read and link the placed and legalized .db file for the block you
are modeling. The .db file must contain placement data and
constraints. Use the read_db and link commands.
2. Identify all clocks by using the appropriate commands, for
example, create_clock or create_generated_clock.
Identifying the Interface Logic

Run the identify_interface_logic command on the block.
This command identifies the interface logic and puts the
is_interface_logic attribute on the identified cells, pins, and
nets.
psyn_shell-t> identify_interface_logic
To reduce the model size, you can exclude ports from the interface
logic model. Ports that are commonly excluded include
• Ports that are startpoints or endpoints of a false path

• Reset and scan enable ports
There are two methods for excluding ports:
• Explicitly specifying the input and output ports to exclude by

using the -ignore_ports port_list option
• Letting Physical Compiler automatically select which input ports
to exclude by using the -auto_ignore option

3-5
For a more detailed model, you can include the following logic in
addition to the default model contents:
• All macro cells, including those that are not on interface timing
paths (-keep_macros option)
• The boundary cells connected to ignored ports
(-keep_boundary_cells option)
Extracting the Interface Logic Model

Run the extract_ilm command to extract the interface logic
model from the design database. This command transforms the
current design into an interface logic model, then writes the model in
.db format to a file you specify. When the process is complete, the
design in memory is the interface logic model for the current design.
Note:
To ensure that you generate a context-independent model, do
not specify “what if” constraints such as set_case_analysis
and set_disable_timing at the time of interface logic model
generation.
You must use the -physical option to ensure that sufficient

information is included in the interface logic model to perform
top-level clock tree synthesis.
psyn_shell-t> extract_ilm -verbose -physical -output block_ilm.db

3-6
When you specify the -physical option, the extracted model
includes the following items:
• Physical information, such as cell and port locations and

estimated, global, or detailed routing information present in the
database at the time of the model extraction for all the nets
internal to the interface logic model
• The full netlist of all the nets which are on clock paths to the
interface registers (boundary side loads)
This side-load information provides Physical Compiler with an
accurate and dynamic picture of the clock delays and internal
clock transitions based on a given input clock transition.
The commands and options listed in Table 3-1 provide information

about interface logic models.
Table 3-1 Reporting Information About Interface Logic Models

Command Description
extract_ilm -verbose Reports statistics for the original design and the
interface logic model.
get_ilm_objects Determines the objects in the current design that

are identified as belonging to interface logic.
get_ilms Determines the interface logic models that are

defined as part of the current design.
report_area Reports statistics for both the original netlist and

the interface logic model netlist so that you know
how much the area was reduced.
report_design Reports whether the design is an interface logic

model.
For the complete syntaxes, see the man pages.

3-7
Identifying Obstructions
To properly place cells that are not interface logic models and to
correctly estimate wire lengths for the top-level nets, Physical
Compiler must have information about the obstructions caused by
the interface logic models. Physical Compiler uses keepouts to
model placement and routing obstructions.
By default, Physical Compiler derives the keepouts when you run the
extract_ilm command. If the derived keepouts are not sufficient,
you can explicitly define the keepouts for the block. The following
sections describe these methods.
Deriving Keepouts
The extract_ilm command automatically derives the keepouts
for rectangular interface logic blocks.
Note:
You can derive keepouts automatically only for rectangular
interface logic blocks.
When you use derived keepouts, Physical Compiler automatically

takes into account the obstructions caused by the interface logic
model block at the top level. These obstructions are placement
keepouts, so no cells for any other blocks are placed within these
areas. The areas occupied by interface logic model blocks are
considered keepouts on all the layers used for routing.
When you use derived keepouts, keep the following points in mind:
• Derived keepouts are placement keepouts and routing keepouts

on all layers. You cannot selectively block only some layers.

3-8
• Derived keepouts are not saved in the database.
• You cannot view derived keepouts in the Physical Compiler GUI.
Defining Keepouts
Define the keepouts instead of using the derived keepouts in the
following cases:
• The block is rectilinear, rather than rectangular.

• You want to use over-the-block routing.
Use the following commands to identify keepouts within the interface
logic model:
• create_placement_keepout
• create_wiring_keepout
For detailed information about creating keepouts, see the Physical
Compiler User Guide, Volume 1.
In some cases, the keepouts defined within a block can be used as

a placement or routing resource at the top level. To identify such
keepouts, use the following commands:
• set_inverted_placement_keepout
• set_inverted_wiring_keepout
Reporting Keepouts
You can use the report_placement_keepout and
report_wiring_keeput commands to report on the keepouts
defined for the current design. Inverted keepouts are indicated with
an I before the keepout name.

3-9
Preparing for Top-Level Clock Tree Synthesis
To prepare for top-level clock tree synthesis,
1. Read the top-level design into Physical Compiler.

psyn_shell-t> read_db top_design.db
2. Remove the subdesigns to be replaced by interface logic models.

Use the remove_design command.
psyn_shell-t> remove_design blockA.db blockB.db ...
3. Read the interface logic models into Physical Compiler.

psyn_shell-t> read_db blockA_ilm.db blockB_ilm.db ...
4. Set the top-level design as the current design.

psyn_shell-t> current_design top_design
5. Read in the top-level constraints (generated from the placed

design database by running write_script), the PDEF file, and
so forth.
psyn_shell-t> source top_design.cstr
psyn_shell-t> read_pdef top_design.pdef
6. Link the design.

psyn_shell-t> link
7. Propagate the placement, keepout, and information from the

blocks up to the top-level design.
When the interface logic model is generated, cell locations are
based on the block’s origin. When working at the top-level
design, use the propagate_ilm command to adjust the
locations of the interface logic model cells according to the
top-level floorplan.
Hierarchical Clock Tree Synthesis: Preparing for Top-Level Clock Tree Synthesis
3-10
In addition to adjusting the locations of the interface logic model
cells, the propagate_ilm command propagates the keepout
and delay information from the interface logic models to the
top-level design. By default, the propagate_ilm command
does not propagate delay information for the boundary cells. For
clock tree synthesis, include this information by specifying the
-include_all_boundary_cell_delays option.
psyn_shell-t> propagate_ilm -include_all_boundary_cell_delays
8. Verify the propagated information (optional).

psyn_shell-t> report_cell -physical blockA/* blockB/* ...
psyn_shell-t> report_placement_keepout [get_placement_keepout *]
psyn_shell-t> report_wiring_keepout [get_wiring_keepout *]
psyn_shell-t> report_annotated_delay
9. Run physical optimization on the top-level design.

During top-level physical optimization, optimization is not done
for cells within interface logic models.
Running Top-Level Clock Tree Synthesis

To run top-level clock tree synthesis,

For details, see “Defining the Clock Trees” on page 2-10.
2. Set the constraints for clock tree synthesis.

For details, see “Setting Constraints for Clock Tree Synthesis” on
page 2-28.
Hierarchical Clock Tree Synthesis: Running Top-Level Clock Tree Synthesis

3-11
3. Generate reports about the existing block-level clock trees.
For details, see “Generating Clock Tree Reports” on page 4-17.
4. Synthesize the clock trees.

To prevent top-level clock tree synthesis from modifying the clock
trees within an interface logic model, Physical Compiler
automatically infers don’t touch subtrees at block-level clock
ports.
If an interface logic model has feedthrough clock logic, such as

the path from input port clk_in to output port clk_out in the
interface logic model for instance U1 shown in Figure 3-2,
Physical Compiler also treats the top-level clock subtrees that
are driven by an interface logic model output port as don’t touch
subtrees.
Figure 3-2 Feedthrough Clock Logic
Top-level
subtree
clk
clk_in
…
clk_out …
U1
…
TOP

3-12
To perform clock tree synthesis on a top-level clock subtree that
is driven by a clock output port of an interface logic model, you
must either compile the subtree separately before running
top-level clock tree synthesis or define the input pin of the cell
driving the clock output port as a stop pin to prevent tracing of the
feedthrough logic.
To compile the top-level clock subtree separately, follow steps 1

through 4 in this procedure, using the interface logic model
output ports (for example, pin U1/clk_out in Figure 3-2 on
page 3-12) as the clock tree roots. Then repeat the process,
using the primary clock sources (for example, port clk in
Figure 3-2) as the clock tree roots.
For information about defining stop pins, see “Defining Stop Pins”
on page 2-22.
Physical Compiler considers the annotated maximum and

minimum insertion delays for the clock trees within the interface
logic models while building the top-level clock tree. Thus, skew
balancing is done to the deepest sink inside the model without
any logic being modified or inserted in the models.
For details about clock tree synthesis, see “Synthesizing the

Clock Trees” on page 2-53.
5. Analyze the clock trees.

For details, see “Analyzing the Clock Trees” on page 2-60.
Note:
Remember that Physical Compiler does not optimize global
chip skew when you use interface logic models to run top-level
clock tree synthesis. Physical Compiler optimizes the skew
relevant to the top-level register interfaces.

3-13
If you replace the interface logic models with block-level
netlists when you do timing analysis, you might see larger
skew numbers. These numbers are not relevant, as long as
your design meets timing.

3-14
6. Analyze the design.
For details, see “Analyzing the Design” on page 2-68.
7. Route the top-level design.

For details, see “Performing Detail Routing” on page 2-70.

3-15
3-16
Clk_in

3-17
3-18
4
Analyzing Clock Tree Synthesis Results 4
You check the results of clock tree synthesis by generating clock tree
reports and by using the Physical Compiler GUI for visual analysis,
as described in these sections:
• Accessing Clock Tree Objects

• Accessing Clock Tree Attributes
• Analyzing Clock Tree Timing Information
• Generating Clock Tree Reports
• Viewing Clock Trees in the Physical Compiler GUI
Analyzing Clock Tree Synthesis Results

4-1
Accessing Clock Tree Objects
Clock trees consist of the following design objects: cells, pins, nets,
and possibly ports. Use the get_clock_tree_objects command
to access the design objects that make up a clock tree. By default,
the get_clock_tree_objects command returns the clock tree
objects for all currently defined clock trees. To specify the clock trees
of interest, use the -clock_trees option to specify the clock
names or root pins.
The get_clock_tree_objects command returns a formatted list

of collections of clock tree objects for the specified clock trees.
Because you can apply the command to more than one clock tree in
one invocation, the result is an associative list that has this form:
clock_tree1 {type1 collection1 type2 collection2 ...}

clock_tree2 {type1 collection1 type2 collection2}
...
Usually you assign the result to an array set command to provide

an associative array that is indexed by the specified clock tree names
or root pins.
Note:
Because the result is intended to be packed into an associative
array, the order in which each clock tree and each collection is
returned is not guaranteed.
By default, the get_clock_tree_objects command returns a

single collection that contains all design objects in the clock tree. You
can use the filter_collection command to extract a collection
of specific design objects.
Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Objects

4-2
The following example shows how to extract a collection of nets from
the collection list returned by the get_clock_tree_objects
command:
psyn_shell-t> get_clock_tree_objects
CLK {all _sel10}
psyn_shell-t> array set clk_trees[get_clock_tree_objects]
Information: Defining new variable 'clk_trees(CLK)'. (CMD-041)
psyn_shell-t> array set clk_objs $clk_trees(CLK)
Information: Defining new variable ’clk_objs(all)’. (CMD-041)
psyn_shell-t> filter_collection $clk_objs(all) {@object_class == "net"}
{"CLK", "CTS_L0I11934_Y", "CTS_L1I11935_Y", "CTS_L1I11936_Y",
"CTS_L2I11937_Y"...}
Note:
When you enter array set commands, you might get many
CMD-041 (defining new variable) information messages. If you
do these manipulations for many clock trees, use the
suppress_message command to disable message CMD-041.
The types of collections returned by the

get_clock_tree_objects command depend on the options you
specify on the command line.
Table 4-1 describes the collection types and their associated option
names.

4-3
Table 4-1 Collection Types for get_clock_tree_objects
Collection type Command option Contents
all none Each collection contains all design

objects that make up a clock tree.
0, 1, ...n -levels {* | l1 [l2]} Each collection contains the

following design objects for each
cell at the specified level of a clock
tree: the driven input pin, the cell,
the driven output pin, and the
driven output nets. Level 0 is the
clock root, level 1 is the level
closest to the clock root, and so on.
buffer -buffer_types buffer Each collection contains the cells

and pins of all buffers in a clock
tree.
gate -buffer_types gate Each collection contains the cells

and pins of all preexisting cells in a
clock tree.
inverter -buffer_types inverter Each collection contains the cells

and pins of all inverters in a clock
tree.
leaf -buffer_types leaf Each collection contains all leaf

pins in a clock tree.
root -sources Each collection contains the clock

root (input port or output pin) for a
clock tree.
trace -trace The collection contains the design

objects in a clock tree from the
specified clock tree object back to
the clock root.

4-4
Accessing Clock Tree Attributes
Clock trees have the following attributes associated with them:
• ct_is_compiled
This Boolean attribute specifies whether or not the clock tree has
been compiled.
• ct_num_levels
This integer attribute specifies the number of levels in the clock
tree. The number of levels is computed as the number of levels
plus one level for the clock sinks.
• name
This string attribute contains the clock tree name, as defined by
the set_clock_tree_options command.
Use the get_clock_tree_attributes command to return these

attribute values for a clock tree.
psyn_shell-t> get_clock_tree_attributes
By default, the get_clock_tree_objects command returns all

attributes for the currently defined clock trees.
To return information for specific clock trees, use the

-clock_trees option. To return values for specific attributes, use
the options shown in Table 4-2. You can specify zero or more
attribute options on the command line.
Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Attributes

4-5
Table 4-2 Clock Tree Attributes
Attribute Command option
ct_is_compiled -compiled
ct_num_levels -num_levels
name -name
Because you can apply the command to more than one clock tree in
one invocation, the result is an associative list that has this form:
clock_tree1 attribute_list_for_clock_tree1
clock_tree2 attribute_list_for_clock_tree2
...
Usually you assign the result to an array set command to provide

an associative Tcl array that is indexed by the specified clock tree
names or root pins.
Note:
array, the order in which each clock tree and each attribute is
returned is not guaranteed.
Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Attributes

4-6
Analyzing Clock Tree Timing Information
This section describes the following aspects of clock tree timing
analysis:
• How to update the clock tree timing after clock tree synthesis
• How to access the clock tree timing information by using clock
instance attributes
• How to generate clock tree reports
Updating Clock Tree Timing Information

After clock tree synthesis, Physical Compiler uses the
back-annotated net delay and capacitance values to determine the
clock tree timing information. For more accurate timing information,
run the retime_clock_tree command to update the net delay
and capacitance values based on the current environment
(operating conditions, libraries, and delay estimation options). The
retime_clock_tree command modifies the back-annotated net
delay values based on the global route segments. If a clock tree
contains unrouted nets, the retime_clock_tree command
generates a CTS-199 warning message and does not change the
back-annotated values for the unrouted nets.
Limitation:
In the current release, the retime_clock_tree command
recognizes only global-routed nets. Any detail-routed nets are
considered to be unrouted.
By default, the retime_clock_tree command updates the timing

information for all clock trees in the design. To update specific clock
trees, use the -clock_trees option.
Analyzing Clock Tree Synthesis Results: Analyzing Clock Tree Timing Information
4-7
Accessing Clock Tree Delay Information
Each instance in the clock tree has attributes associated with it that
allow you to access delay- and netlist-related information about the
instance. Table 4-3 lists each of these attributes and their
descriptions.
Table 4-3 Clock Tree Instance Attributes

Attribute Type Description
instance string The full hierarchical name of the current instance.
address integer The identifier of the current instance.
is_leaf Boolean Specifies whether the current instance drives other clock
tree instances in its fanout. The value is 1 if the current
instance does not drive other clock tree instances.
parent integer The identifier of the clock tree instance that drives the
current instance.
children list of integers List of the identifiers of the clock tree instances driven by the
current instance.
input string The name of the input pin of the current instance that is
connected to the clock tree.
output string The name of the output pin of the current instance that is
connected to the clock tree.
path_pol Boolean Specifies whether the logic between the input of the clock
tree root and the input of the current cell inverts the clock
signal. The value is 1 if the signal is not inverted.
cell_pol Boolean Specifies whether the clock signal is inverted while

traversing the current instance. The value is 1 if the signal is
not inverted.
in_rc float The RC delay from the driving output pin of the parent
instance to the input pin of the current instance.
4-8
Table 4-3 Clock Tree Instance Attributes (Continued)
prop_r float The delay through the current instance associated with a
rising input transition on the clock tree root.
prop_f float The delay through the current instance associated with a
falling input transition on the clock tree root.
load float The lumped capacitance driven by the selected output of the
current instance.
iftrans float The input transition resulting from a falling input transition on
the clock tree root.
irtrans float The input transition resulting from a rising input transition on
the clock tree root.
oftrans float The output transition resulting from a falling input transition
on the clock tree root.
ortrans float The output transition resulting from a rising input transition
on the clock tree root.
early_fwd_r float The shortest (early) path delay between the output of the
current instance and any of the sink pins that it drives (on a
rising input transition at the clock tree root).
early_fwd_f float The shortest (early) path delay between the output of the
falling input transition at the clock tree root).
late_fwd_r float The longest (late) path delay between the output of the
rising input transition at the clock tree root).
late_fwd_f float The longest (late) path delay between the output of the
falling input transition at the clock tree root).
end_efwd_r string The sink pin on which the early rise path is encountered.
end_efwd_f string The sink pin on which the early fall path is encountered.
4-9
Table 4-3 Clock Tree Instance Attributes (Continued)
end_lfwd_r string The sink pin on which the late rise path is encountered.
end_lfwd_f string The sink pin on which the late fall path is encountered.
Use the get_clock_tree_delays command to return these

attribute values for the clock tree instances.
psyn_shell-t> get_clock_tree_delays -clock_trees CLK
You must specify the -clock_trees option. The argument to

-clock_trees must be a single clock tree object, identified either
by its root or its name.
The get_clock_tree_delays command returns an associative

list that has this form:
element1 attribute_list_for_element1
element2 attribute_list_for_element2
...
Assign the result to an array set command to provide an

associative array that is indexed by the clock tree instance identifiers
(address attribute).
Note:
array, the order in which each clock tree instance and each
attribute is returned is not guaranteed.
The get_clock_tree_delays command is best used as input to

a script that manipulates the reported data.
4-10
Generating Clock Tree Reports
Use the report_clock_tree command to generate clock tree
reports. This command generates several different types of reports,
based on the specified options.
Note:
Always use report_clock_tree, rather than
report_timing -from clk, to evaluate the clock tree QOR.
The insertion delay values might differ between the two reports.
You can generate the following types of clock tree reports:
• Default (no options)

• Settings (-settings option)
• Exceptions (-exceptions option)
• Design rule violations (-drc_violators option)
• Levels (-level_info option)
• Structure (-verbose option)
Except with the -verbose option, you can specify multiple report
type options in a single report_clock_tree command.
All clock tree reports have the following items in common:
• By default, the report is generated for all clock trees in the design.
To restrict the report to specific clock trees, use the
-clock_trees option.
• Only those timing numbers that are relevant to the active edge of
the clock are reported.
4-11
The following sections describe the various clock tree reports.
Default Clock Tree Report

The default clock tree report provides basic information about the
clock trees. This information is provided whenever you run the
report_clock_tree command (except when you use the
-verbose option).
By default, the clock tree report displays the maximum global skew.
In many cases, local skew (the difference in arrival times of the clock
signal at sequentially adjacent registers) is a better measure of
quality of the clock tree than global skew (the difference in arrival
times of the clock signal among all registers in a clock domain). To
report both maximum local skew and maximum global skew, set the
cts_use_local_skew variable to true.
Note:
This variable affects reporting only. During clock tree synthesis,
Physical Compiler minimizes only global skew.
Example 4-1 shows a default clock tree report that reports global
skew. Example 4-2 on page 4-22 shows a default clock tree report
that reports both local and global skew.
4-12
Example 4-1 Default Clock Tree Report (Global Skew Only)
****************************************
Design : my_design
Version: U-2003.06-PCE3.0
Date : Tue Jun 10 23:10:41 2003
****************************************

Compiled Tree : 1
Number of Levels : 4
Total Area of CT Buffers : 2494.79956
Max Global Skew : 0.05527
Early Rise-to-Rise endpoint : "REG1/CLK"
Late Rise-to-Rise endpoint : "REG6/CLK"
Rise to Rise Delay (Early/Late): 1.258433 / 1.313705
Clock Root Rising Edge Skew : 1.313705 - 1.258433 = 0.055272
4-13
Example 4-2 Default Clock Tree Report (Both Local and Global Skew)
****************************************
Design : my_design
Version: U-2003.06-PCE3.0
Date : Tue Jun 10 23:10:41 2003
****************************************

Compiled Tree : 1
Number of Levels : 4
Total Area of CT Buffers : 2494.79956
Max Local Skew : 0.05527
Rise Induced Launching endpoint: "Q_REG_3_1AF/CLK"
Rise Induced Receiving endpoint: "Q_REG_10A/CLK"
Rise Local Skew Arrivals (L/R) : 1.313704 / 1.258433
Root Rising Edge Local Skew : 1.313704 - 1.258433 = 0.055271
Max Global Skew : 0.05527

Early Rise-to-Rise endpoint : "REG1/CLK"
Late Rise-to-Rise endpoint : "REG6/CLK"
Rise to Rise Delay (Early/Late): 1.258433 / 1.313705
Clock Root Rising Edge Skew : 1.313705 - 1.258433 = 0.055272
Clock Tree Settings Report

The clock tree settings report lists the clock tree settings as specified
in the set_clock_tree_options and
set_clock_tree_references commands. You generate this
report by using the report_clock_tree -settings command.
Example 4-3 shows a clock tree settings report (without the default
report information).
4-14
Example 4-3 Clock Tree Settings Report
Settings for Clock Tree CLK {
Prefix : non set
Max Delay Constraint : non set
Min Delay Constraint : non set
Max Skew Constraint : non set
number_of_levels : non set
number_of_instances_per_level: non set
reference_per_level : non set
Clock Tree Nets Routing Rule : "<default>"
fanout_limit_for_route_only : non set
delay_limit_for_route_only : non set
priority : non set
Layers Available for Clock Routing {

"m4"
"m5"
}
Buffers Available for Clock Tree Synthesis

Clock Tree DRC constraints (maxLoad: N/A , maxSlew: 0.700, maxFanout: N/A)
}
Clock Tree Exceptions Report

The clock tree exceptions report lists the clock tree exceptions
specified in the set_clock_tree_exceptions command. This
report also lists the exceptions inferred by Physical Compiler while
tracing the clock paths. You generate this report by using the
report_clock_tree -exceptions command. If there are no
clock tree exceptions, the default clock tree report is generated.
Example 4-4 shows a clock tree exceptions report (without the

default report information).
4-15
Example 4-4 Clock Tree Exceptions Report
Exceptions Specified on Clock Tree CLK
Stop Pin : U1/A
Exclude Pin : REG7/CP
Float Pin : REGEN/GN {
Early Delay : 0.80000
Late Delay : 1.00000
Input Capacitance : 0.35000
}
Dont-Touch Pin (Inferred) : U2/A
Dont-Touch Pin (Inferred) : MUX1/D2
Dont-Touch Pin (Inferred) : MUX1/D3
Exclude Pin (Inferred) : MUX2/D0
Exclude Pin (Inferred) : MUX3/B
}
In this example, there are several exceptions that are inferred by

Physical Compiler. The don’t touch pins are inferred either due to a
don’t touch subtree specification or due to convergent clocks. The
inferred exclude pins are the implicit exclude pins detected during
tracing of the clock paths.
Clock Tree Design Rule Violations Report

The clock tree design rule violations report lists the design rule
violations that occur in the clock trees. You generate this report by
using the report_clock_tree -drc_violators command. If
there are no violations, the default clock tree report is generated. The
clock tree design rule violations report prints values for the active
edge only.
Note:
This report does not list the design rule constraint settings. To
see the design rule constraint settings, generate a clock tree
settings report.
4-16
Example 4-5 shows a clock tree design rule violations report.
Example 4-5 Clock Tree Design Rule Violations Report

Number of MaxTran Violators : 3
max transition violators

------------------------
+------------+------------+------------+------------+--------+--------+------+
|input pin |input pin |preexisting |preexisting |required|actual |actual|
| |net |driver |driver net | |(rise) |(fall)|
+------------+------------+------------+------------+--------+--------+------+
|CLK |CLK | | |0.500000|44.28865| N/A|
|C | | | | | | |
|TS_L0I4279/A|CLK |CLK |CLK |0.500000|44.28865| N/A|
|C |C | | | | | |
|TS_L1I4280/A|TS_L0I4279_Y|CLK |CLK |0.500000|1.360769| N/A|
Clock Tree Levels Report

The clock tree levels report provides structural and timing
characteristics for all levels of a compiled clock tree. You generate
this report by using the report_clock_tree -level_info
command.
Example 4-6 shows a clock tree levels report.
4-17
Example 4-6 Clock Tree Levels Report
-----------------------------------------------------------------------------
Level 0 Level 1 Level 2 Level 3 Level 4 Level 5
-----------------------------------------------------------------------------
No of Buffers 0 1 2 4 35 0
Buffer Used N/A clk1a27 clk1a15 clk1a15 clk1a15 N/A
No of Preexist. Cells 0 0 0 0 0 0
No of Sinks 0 0 0 0 0 712
No MaxFanout Viol. 0 0 0 0 0 0
Min driven cap 0.02815 0.05598 0.06137 0.19223 0.06122 N/A
Max driven cap 0.02815 0.05598 0.07026 0.20389 0.11033 N/A
No MaxCap Violators 0 0 0 0 0 0
No of ndrule nets 0 0 0 0 0 0
Min Rise Prop delay 0.00000 0.44340 0.21743 0.32128 0.27334 N/A
Min Fall Prop delay N/A N/A N/A N/A N/A N/A
Max Rise Prop delay 0.00000 0.44340 0.22398 0.33337 0.31117 N/A
Max Fall Prop delay N/A N/A N/A N/A N/A N/A
Min Rise Transition 0.00000 0.00011 0.02490 0.03190 0.07508 0.03437
Min Fall Transition N/A N/A N/A N/A N/A N/A
Max Rise Transition 0.00000 0.00011 0.02490 0.03481 0.07901 0.04897
Max Fall Transition N/A N/A N/A N/A N/A N/A
No MaxSlew Violators 0 0 0 0 0 0
Early Rise-Rise arrival 0.00000 0.00031 0.44395 0.66168 0.98355 1.25843
Late Rise-Rise arrival 0.00000 0.00031 0.44398 0.66850 1.00473 1.31370
Early Rise-Fall arrival N/A N/A N/A N/A N/A N/A
Late Rise-Fall arrival N/A N/A N/A N/A N/A N/A
Early Fall-Rise arrival N/A N/A N/A N/A N/A N/A
Late Fall-Rise arrival N/A N/A N/A N/A N/A N/A
Early Fall-Fall arrival 0.00000 N/A N/A N/A N/A N/A
Late Fall-Fall arrival 0.00000 N/A N/A N/A N/A N/A
In some cases the labels in the levels report differ from the
terminology used in this book. The following definitions describe
these differences.
No of Buffers
Number of instances, including both buffers and inverters
Buffer Used
Reference used
4-18
ndrule nets
Nets that use a nondefault routing rule
MaxSlew
Maximum transition time
arrival
Insertion delay
Clock Tree Structure Report

You generate the clock tree structure report by using the
report_clock_tree -verbose command. The clock tree
structure report lists all objects in the clock tree, with the timing
information to each object.
Note:
This report does not include the default clock tree report.
Each object in the clock tree is reported in the following format:
object_name:object_type, cellName:reference, in:input_pin,

out:output_pin, time (clk_edge, unateness)= rise_arrival_time(r)
fall_arrival_time(f), driven net: net_name, routing rule: routing_rule
The object_type argument has one of the following values:

hierarchical pin, buffer, sink pin, or preexisting cell.
The report contains a block of data for each level of the clock tree.
The first line in the block describes the driving pin or cell for that level.
The objects composing that level are indented under the driving
object. The report structure for a level looks like the following:
4-19
driving_element
object1
object2
...
objectn
Example 4-7 shows a portion of a clock tree structure report.
Example 4-7 Clock Tree Structure Report

****************************************
Design : address
Version: 2002.05-PCE1
Date : Thu Aug 15 23:34:07 2002
****************************************
address:hierarchical pin, cellName:address, in:CLK, out:CLK, time (posedge,

noninverting)= 0.000000(r) 0.000000(f), driven net: CLK, routing rule: <default>
CLKL0I9983:buffer, cellName:clk1a27, in:A, out:Y, time (posedge,
noninverting)= 0.000315(r) 0.000315(f), driven net: CLKL0I9983_Y, routing rule:
<default>
CLKL0I9983:buffer, cellName:clk1a27, in:A, out:Y, time (posedge, noninverting)=

0.000315(r) 0.000315(f), driven net: CLKL0I9983_Y, routing rule: <default>
<default>
<defaut>
...
CLKL3I10018:buffer, cellName:clk1a15, in:A, out:Y, time (posedge, noninverting)=

1.003270(r) 1.050465(f), driven net: CLKL3I10018_Y, routing rule: <default>
Y1_X_XRES_COLOR2_REG_23A:sink pin, cellName:fdf1a3, in:CLK, out:NIL,
time (posedge, noninverting)= 1.293661(r) 1.325839(f)
PHYSICAL_ADDRESS_COLOR_REG_9A:sink pin, cellName:fdf1a3, in:CLK, out:NIL,
PHYSICAL_ADDRESS_ZETA_REG_14A:sink pin, cellName:fdf1a3, in:CLK, out:NIL,
...
Y1_X_XRES_COLOR2_REG_27A:sink pin, cellName:fdf1a3, in:CLK, out:NIL,
4-20
Viewing Clock Trees in the Physical Compiler GUI
This section describes the clock tree analysis capabilities of the
Physical Compiler GUI. For general information about the Physical
Compiler GUI, see the Physical Compiler User Guide. For detailed
information about the GUI, see the Physical Compiler GUI online
Help system.
To invoke the Physical Compiler GUI, enter the psyn_gui

command:
% psyn_gui
You access the clock tree analysis capabilities in the Physical

Compiler GUI by choosing from the CTS menu, which is shown in
Figure 4-1.
Figure 4-1 CTS Menu
Using the Physical Compiler GUI, you can
• View the clock trees in visual mode (CTS > Configure Visual
Mode)
This mode is useful for analyzing the clock tree structure after
clock tree synthesis. Analyzing the structure enables you to
identify possible sources for clock tree timing problems, such as
a restrictive floorplan or the use of nonoptimal references.
Analyzing Clock Tree Synthesis Results: Viewing Clock Trees in the Physical Compiler GUI
4-21
When you are viewing clock trees in visual mode, opening a clock
tree hierarchy view window or executing a clock tree command,
such as get_clock_tree_objects or
report_clock_tree, causes Physical Compiler to exit visual
mode.
• View the hierarchy of the clock trees (CTS > New Clock Tree
Hierarchy View)
This mode is useful for analyzing complex clock tree structures
before or after clock tree synthesis.
When you are viewing clock trees in the clock tree hierarchy view,
invoking visual mode or executing a clock tree command, such as
get_clock_tree_objects or report_clock_tree,
causes Physical Compiler to close the clock tree hierarchy view
window.
The following sections describe these capabilities.
4-22
Viewing the Clock Trees in Visual Mode
Before you can view the clock trees in visual mode, the layout view
must be active. To activate the layout view, either click in the layout
view window or click the layout view tab. Figure
4-23
To view the clock trees in visual mode,
1. Choose CTS > Configure Visual Mode.

The Physical Compiler GUI displays the Configure Clock Tree
Visual Mode dialog box (shown in Figure 4-3).
Figure 4-3 Configure Clock Tree Visual Mode Dialog Box
2. Select the clock tree levels or cell types that you want displayed.
Table 4-4 describes the clock tree display choices.You must
select at least one level or cell type. To select more than one
display choice, hold down the Shift key.
4-24
Table 4-4 Clock Tree Display Choices
Partition name Description
All Displays the entire clock tree in a single color.
Level 0...Level n Displays each selected clock tree level in a

different color.
buffer Displays the buffers inserted into the clock tree

by Physical Compiler.
inverter Displays the inverters inserted into the clock tree

by Physical Compiler.
preexisting Displays the preexisting gates in the clock tree.
sink Displays the clock tree sinks.
To analyze the synthesized clock tree, you would typically select

one or more clock tree levels (Level 0...Level n) to be displayed.
You can use this display to debug the placement of the clock tree
cells.
3. Select the display mode for routed clock tree nets.

To display the routed clock tree nets as global preroutes, select
Routes. To display the routed clock tree nets as flylines, select
Flylines.
Note:
If you have not yet synthesized the clock tree, the clock nets
are always displayed as flylines.
4. Click OK.
The Physical Compiler GUI displays the selected clock tree levels
and cell types in the layout view window.
4-25
The Visibility-Selection panel controls which objects are
displayed in the layout view window. By default, the following
clock tree objects are displayed:
- Cells
- Nets
- Ports
You can control which clock tree objects (cells, pins, or ports) are
displayed by changing the settings in the Visibility-Selection
panel. Clock tree nets are always displayed in visual mode—they
are not controlled by the Visibility-Selection panel.
To turn off the display of objects that are not in the clock tree,
deselect the Gray check box (next to the Update button in the
lower-left corner of the layout view window).
Figure 4-4 shows levels 0, 1, and 2 (Level0, Level1, and Level2

display choices) of a clock tree, with the clock nets displayed as
global preroutes. Figure 4-5 also shows levels 0, 1, and 2 of a
clock tree, but with the clock nets displayed as flylines. Figure 4-6
shows the entire clock tree (All display choice) with the clock nets
displayed as flylines.
4-26
Figure 4-4 Displaying Clock Tree Levels With Nets as Global Preroutes
Figure 4-5 Displaying Clock Tree Levels With Nets as Flylines
4-27
Figure 4-6 Displaying Clock Trees
Viewing the Clock Tree Hierarchy

The clock tree hierarchy view provides a hierarchical listing of the
clock tree. To display the clock tree hierarchy view, choose CTS >
New Clock Tree Hierarchy View. Figure 4-7 shows a clock tree as
viewed in the clock tree hierarchy view.
4-28
Figure 4-7 Clock Tree Hierarchy View
The left pane of the window shows the hierarchical view of the clock
tree. The pane contains two columns: the Clock Tree column shows
the instance names at each level of the clock tree, and the Reference
column shows the reference associated with each instance. You can
resize the columns as needed. In the Clock Tree column, clock tree
instances added by Physical Compiler clock tree synthesis have the
notation NEW under the gate symbol.
The right pane of the window provides information about the fanout
of the selected clock tree object (if no object is selected, the right
pane displays information about the last selected clock tree object).
The right pane displays the following information for each cell (you
might have to use the scroll bar or resize the columns to see all of the
information):
• Cell name
• Cell type
• Clock tree exceptions set on the cell
• Fanout
4-29
• Input pin on the clock path
• Maximum input transition time
• Output pin on the clock path
• Maximum output transition time
• Maximum capacitance constraint
• Maximum fanout constraint
• Output net on the clock path
If you move the pointer to a clock tree object in the left pane, the
Physical Compiler GUI displays information about that object (as
shown in Figure 4-8).
Figure 4-8 Clock Tree Object InfoTip
4-30
4-31
4-32
4-33
4-34
4-35
4-36
4-37
4-38
4-39
4-40
4-41
4-42
4-43
4-44
4-45
4-46
Glossary GL
arrival time
The delay of the clock tree to a particular level.
Arrival time for level 1
Arrival time for level 2
cascaded gated clock

A gated clock that contains more than one level of clock gating
logic. Also called multilevel gated clock.
clock latency
Minimum clock latency is the predicted shortest delay to any sink in
the design. Maximum clock latency is the predicted largest delay to
any sink in the design. Clock latency is defined for a clock object.
clock object
The clock object is created by the create_clock command. It
identifies the clock source pin for Design Compiler and Physical
Compiler.
GL-1
clock skew
The delta between the minimum insertion delay and the maximum
insertion delay of the clock sinks. Clock skew is constrained and
measured on a clock tree object.
clock tree object
The clock tree object is created by the
set_clock_tree_options command. It identifies the clock tree
root for Physical Compiler clock tree synthesis.
clock uncertainty
The predicted delta between the minimum insertion delay and the
maximum insertion delay of the clock sinks. Clock uncertainty is
defined for a clock object.
design rule constraints
Design rule constraints differ between the logical and physical
domains.
• logical domain: Design rule constraints specify timing
requirements that the synthesized tree must meet before further
optimization for skew and insertion delay, for example, fanout,
transition time, and capacitance.
• physical domain: Design rule constraints specify physical
requirements, such as wire spacing.
end pin
See sink.
exclude pin
A sink of a clock tree that is not considered when the clock is
buffered.
GL-2
float pin
A user-specified definition for the internal clock characteristics for
hard macros; describes the insertion delay seen from the float pin to
the sinks internal to the macro.
Hard IP
clk
A B
float
Float pin
Insertion delay = A + B
where
A is clock tree inserted
B is specified in set_clock_tree_exceptions
gated clock
A clock network that contains preexisting cells on the clock path.
hold time
The time that a signal on the data pin must remain stable after the
active clock edge; creates a minimum delay requirement for paths
leading to the data pin of the cell. Hold time is specified in the
technology library and applies to sequential cells. Hold time can be
scaled by operating conditions if the library contains scaling factors
for hold.
insertion delay
Minimum insertion delay is the shortest delay to any sink in the
design. Maximum insertion delay is the largest delay to any sink in
the design. Insertion delay is constrained and measured on a clock
tree object.
Stop pin
clk
stop
Insertion delay
GL-3
level
A single level equals one component, which can be a buffer,
inverter, multiplexer, or other logic gate. Two levels equate to two or
more components connected sequentially.
1 Level 2 Level 3 Level
multilevel gated clock

A gated clock that contains more than one level of clock gating
logic. Also called cascaded gated clock.
propagation delay
Delay of the clock tree cell at that level.
propagation delay propagation delay
for level 1 for level 2
root pin
The startpoint of the clock tree. Can be an output pin of a cell or an
input port of the design. Also called source.
GL-4
setup time
The time that data must remain stable before the active clock edge;
creates a maximum delay requirement for paths leading to the data
pin of the cell. Hold time is specified in the technology library and
applies to sequential cells. Setup time can be scaled by operating
conditions if the library contains scaling factors for setup.
sink
A clock tree termination pin; sometimes called end pin.
skew
See clock skew; called clock uncertainty in Design Compiler.
local skew—skew within a block
global skew—skew at the chip level
source
The startpoint of the clock tree. A clock tree can have a single
source. Also called root pin.
stage
See level.
stop pin
Modified sink of a clock tree (a pin that would not otherwise be
treated as a sink).
transition delay
Transition time of the cell’s output pin.
ungated clock
A clock network that contains no logic on the clock path (even
buffers or inverters).
GL-5
GL-6
Index
A setting 2-30
viewing 2-32
arrival time
cascaded gated clock
defined GL-1
defined GL-1
reporting 4-17
See also gated clock
attributes
check_legality command 2-7
ct_floatpin_clock_tree_name 2-24
clock latency
ct_floatpin_max_del 2-24
defined GL-1
ct_floatpin_min_del 2-24
network 2-8
ct_is_dont_touch_subtree 2-45
source 2-8
ct_is_exclude_pin 2-21
ct_is_snps_added 2-56 clock net, routing without buffering
by delay 2-37
ct_is_stop_pin 2-22
by fanout 2-36
has_cts_ba 2-45, 2-55
specifying 2-37
clock network
B errors 2-20
tracing 2-17
buffering constraints, setting 2-35
clock object
buffers
compared to clock tree object 2-11
resetting 2-25
defined GL-1
sizing 2-67
specifying 2-24 clock path
convergent 2-48
viewing 2-26
overlapping 2-51
clock root
C constraint violations on 2-15
defined 2-10
capacitance constraint, maximum
specifying 2-11
IN-1
clock sink example 4-28
default clock tree objects
tracing rules 2-17 accessing 4-2
viewing 2-18 creating 2-11
defined 2-10 defined 4-2
excluding 2-21 naming 2-11
noncritical 2-66 clock tree references
stop pin 2-22 resetting 2-25
clock source specifying 2-24
See clock root viewing 2-26
clock tree clock tree report
defining 2-11 default 4-12
removing 2-46 design rule violations 4-16
reporting 4-11 exceptions 4-15
synthesizing 2-53 generating 4-11
viewing 4-21 levels 4-17
clock tree constraints settings 4-14
buffering 2-35 structure 4-19
design rule 2-30 verbose 4-19
operating conditions 2-30 clock tree structure
routing 2-38 actual, reporting 4-19
timing settings, reporting 4-14
defined 2-34 specifying 2-10
maximum insertion delay 2-34 clock tree timing
maximum skew 2-34 default computation 4-7
minimum insertion delay 2-34 updating 4-7
priority 2-34
CMD-041 message 4-3
clock tree definition
commands
creating 2-11
check_legality 2-7
removing 2-11
compile_clock_tree 2-53
reporting 4-14
compile_physical 2-6
clock tree exception
extract_ilm 3-6
don’t touch subtrees 2-44
extract_rc 2-70, 2-72
exclude pins 2-21
get_clock_tree_delay 4-10
float pins 2-42
get_clock_tree_objects 4-2
route-only nets 2-37
identify_interface_logic 3-5
stop pins 2-22
optimize_placement 2-68
clock tree hierarchy view physopt 2-6, 2-8
defined 4-28 -incremental 2-69
displaying 4-28 propagate_ilm 3-10
IN-2
report_congestion 2-7 convergent clock path
reset_clock_tree_references 2-25 defined 2-9
route_global 2-70 synthesizing 2-48
set_clock_latency 2-8 critical cell costing 2-67
set_clock_tree_exceptions ct_floatpin_clock_tree_name attribute 2-24
-dont_touch_subtrees 2-44 ct_floatpin_max_del attribute 2-24
-exclude_pins 2-21
ct_floatpin_min_del attribute 2-24
float pin options 2-23, 2-42
ct_is_dont_touch_subtree attribute 2-45
-global_route_only_subtrees 2-37
-stop_pins 2-22 ct_is_exclude_pin attribute 2-21
set_clock_tree_options 2-11 ct_is_snps_added attribute 2-56
set_clock_tree_references 2-24 ct_is_stop_pin attribute 2-22
set_congestion_options 2-8 cts_cell_costing variable 2-67
set_delay_estimation_options 2-4 cts_iterative_optimization variable 2-29
set_disable_timing 2-18 cts_no_implicit_exclude_pins variable 2-19
set_input_delay 2-8 cts_skip_high_fanout_default_settings
set_operating_conditions 2-30 variable 2-59
set_output_delay 2-8 cts_use_all_buffers_for_refinement variable
write_def 2-71 2-54
compile_clock_tree command 2-53 cts_use_auto_convergence_subtrees variable
-clock_trees 2-53 2-49
-drc_effort 2-64 cts_use_local_skew variable, variables
-no_clock_attributes 2-56 cts_use_local_skew 4-12
-no_dont_touch 2-56
-no_dont_touch_network 2-56
-no_dont_touch_placement 2-56 D
-size_gates 2-67 data requirements 1-5
-skew_effort 2-65 DEF
compile_physical command 2-6 generating 2-71
congestion SOURCE TIMING construct 2-71
fixing 2-8 USE CLOCK construct 2-71
reporting 2-7 design rule constraints
constraints optimization effort 2-64
clock tree timing 2-34 priority 2-31
maximum insertion delay 2-34 setting 2-30
maximum skew 2-34 viewing 2-32
minimum insertion delay 2-34 violations on clock root 2-15
maximum capacitance 2-30 detail routing
maximum fanout 2-30 analyzing design after 2-72
maximum transition time 2-30 analyzing design before 2-70
third-party tool 2-71
IN-3
don’t touch subtree
attribute 2-45
F
fanout constraint, maximum
defined 2-44
setting 2-30
explicit 2-45
viewing 2-32
implicit 2-45
interface logic models 3-12 float pin
attributes 2-24
reporting 4-15
defined 2-20, 2-42
DRC
See design rule constraints reporting 4-15
setting 2-42
uses
E controlling arrival time 2-23
modelling hard macros 2-42
effort level
design rule optimization 2-64
skew optimization 2-65 G
exceptions for clock tree synthesis
gated clock
don’t touch subtree 2-44
cascaded, defined GL-1
exclude pin 2-21
defined GL-3
float pin 2-42
multilevel, defined GL-4
route-only net 2-37
unsupported constraints 2-26, 2-35, 2-36
stop pin 2-22
generated clock, tracing through 2-18
exclude pin
attribute 2-21 get_clock_tree_delays command 4-10
defined 2-20 get_clock_tree_objects command 4-2
explicit global routing
defined 2-21
specifying 2-21
implicit
defined 2-19
listing 2-19
overriding 2-19
preventing 2-19
reporting 4-15
extract_ilm command 3-6
extract_rc command 2-70, 2-72
extract2plib utility 2-5
extraction parameters
in RC computations 2-40
required in physical library 2-4
IN-4
I defined 4-12
identify_interface_logic command 3-5
input delay, specifying 2-8 M
insertion delay maximum capacitance
maximum setting 2-30
clock network latency 2-8 violation on clock tree root 2-15
specifying 2-34
maximum fanout, setting 2-30
minimum, specifying 2-34
maximum insertion delay
interclock skew, balancing 2-52
setting 2-34
interface logic model violation on clock tree root 2-15
adding logic to 3-6
maximum skew, setting 2-34
creating 3-4
maximum transition time
defined 3-2
setting 2-30
don’t touch subtrees 3-12
violation on clock tree root 2-15
extracting 3-6
keepouts messages, CMD-041 4-3
defining 3-9 minimum conditions, specifying 2-4
deriving 3-8 minimum insertion delay, setting 2-34
reporting 3-9 minimum scaling factor, setting 2-4
reading 3-10 multilevel gated clock
reducing size of 3-5 defined GL-4
interface logic models See also gated clock
keepouts
propagating 3-10
interface logic, defined 3-3 N
inverters naming style, clock tree objects 2-11
resetting 2-25 noncritical sink 2-66
specifying 2-24 noncritical subtrees
viewing 2-26 ignoring 2-66
iterative optimization, defined 2-29 reporting timing in 2-66
L O
legalizing operating conditions, setting 2-30
clock buffers 2-54 optimize_placement command 2-68
critical cells 2-67 output delay, specifying 2-8
nonclock buffers 2-57 overlapping clock path
license requirements 1-5 defined 2-9
local skew synthesizing 2-51
IN-5
P default 2-38
setting 2-38
physical optimization
routing rule
after clock tree synthesis 2-55, 2-69
default 2-39
fixing congestion 2-8
nondefault
incremental 2-69
defined 2-39
initial 2-6
reporting 2-40
timing budget for 2-8
specifying 2-39
physopt command 2-6, 2-8 wide wire, specifying 2-39
-incremental 2-69
post-route design, analyzing 2-72
propagate_ilm command 3-10 S
scan enable network, synthesizing 2-2
See also high-fanout net
R selective skew balancing 2-66
RC coefficients set_clock_latency command 2-8
capacitance-based 2-41
set_clock_tree_exceptions command
extraction-based 2-40 -dont_touch_subtrees 2-44
references, clock tree -exclude_pins 2-21
See clock tree references
float pin options 2-23, 2-42
remove_clock_tree_options command 2-11 -global_route_only_subtrees 2-37
report, clock tree, generating 4-11 -stop_pins 2-22
report_congestion command 2-7 set_clock_tree_options command 2-11
requirements, clock tree synthesis -clock_tree_name 2-11
data 1-5 -delay_limit_for_route_only_clock_net 2-37
license 1-5 -fanout_limit_for_route_only_clock_net 2-36
reset network, synthesizing 2-2 -high_fanout 2-57
See also high-fanout net -ignore_noncritical_sinks 2-66
reset_clock_tree_references command 2-25 -layer_list 2-38
root -max_delay 2-34
See clock root -max_skew 2-34
routability -min_delay 2-34
after clock tree synthesis 2-70 -number_of_instances_per_level 2-36
before clock tree synthesis 2-7 -number_of_levels 2-35
route_global command 2-70 -prefix 2-11
route-only clock nets -priority 2-16, 2-29
by delay 2-37 -reference_per_level 2-25
by fanout 2-36 -root 2-11
specifying 2-37 -routing_rule 2-39
routing constraints, setting 2-38 -timing_arc 2-13
routing layers -use_default_routing_for_sinks 2-39
IN-6
set_clock_tree_references command 2-24 T
set_congestion_options command 2-8
third-party router, interface 2-71
set_delay_estimation_options command 2-4
timing constraints, clock tree 2-34
set_disable_timing command 2-18 maximum insertion delay 2-34
set_input_delay command 2-8 maximum skew 2-34
set_operating_conditions command 2-30 minimum insertion delay 2-34
set_output_delay command 2-8 transition time constraint, maximum
sink setting 2-30
See clock sink viewing 2-32
sizing buffers 2-67 turnaround time 1-5
skew
global 2-34
local 4-12 U
specifying maximum 2-34 ungated clock, defined GL-5
skew balancing
between clocks 2-52
selective, within a clock 2-66 V
skew optimization, effort levels 2-65 variables
source cts_cell_costing 2-67
See clock root cts_iterative_optimization 2-29
stop pin cts_no_implicit_exclude_pins 2-19
attribute 2-22 cts_skip_high_fanout_default_settings 2-59
defined 2-20 cts_use_all_buffers_for_refinement 2-54
reporting 4-15 cts_use_auto_convergence_subtrees 2-49
specifying 2-22
structure, specifying for clock tree 2-10
synthesizing W
clock trees wide wires
command 2-53 reporting 2-40
fine-tuning 2-64 specifying 2-39
process 2-53 wire type
high-fanout nets 2-58 default 2-39
specifying 2-39
write_def command 2-71
IN-7

Ctcug

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ctcug

Încărcat de

Drepturi de autor:

Formate disponibile

Physical Compiler®

Clock Tree Synthesis

Destination Control Statement

Service Marks (SM)

Printed in the U.S.A.

Document Order Number: 37847-000 QA

What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1. Introduction to Physical Compiler Clock Tree Synthesis

2. Running Clock Tree Synthesis

4. Analyzing Clock Tree Synthesis Results

This preface includes the following sections:

• What’s New in This Release

• Support of generated clocks

For more information about tracing through generated clocks,

• Ability to explicitly specify unbuffered nets

For more information about retiming the clock trees, see

• Local skew reporting

For more information about reporting local skew data, see

Known Limitations and Resolved STARs

• Logic design, physical design, and timing principles

• Synopsys Online Documentation (SOLD)

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys

Courier bold Indicates user input—text you type verbatim—

[] Denotes optional parameters, such as

| Indicates a choice among alternatives, such as

_ Connects terms that are read as a single term

Control-c Indicates a keyboard combination, such as

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

Physical Compiler clock tree synthesis uses a global approach

Introduction to Physical Compiler Clock Tree Synthesis

• Benefits of Using Physical Compiler Clock Tree Synthesis

Benefits of Using Physical Compiler Clock Tree

• Support for a variety of design styles

- Flat or hierarchical designs (logical and physical hierarchy)

- Clock tree structure, including buffer and inverter reference

- Minimize the movement of cells on the critical path (critical cell

- Shares the Physical Compiler psyn_shell and graphical user

- Textual analysis of the clock tree by using the

• Have both a PhysOpt license and a PhysOpt-ClockTree license

Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

Figure 1-1 RTL-to-GDSII Flow

This user guide describes the methodology used to run Physical

Introduction to Physical Compiler Clock Tree Synthesis: Methodology Overview

1. Prepare your design for clock tree synthesis.

- Links to the logical and physical libraries

2. Define the clock trees.

Introduction to Physical Compiler Clock Tree Synthesis: Methodology Overview

4. Verify the clock tree definitions.

5. Synthesize the clock trees.

6. Analyze the results.

If your design contains violations after clock tree synthesis, run

Introduction to Physical Compiler Clock Tree Synthesis: Methodology Overview

Prepare design for

Define clock trees

Set constraints for

Verify clock trees

Synthesize clock trees