ctcug

Comments?E-mail your comments about Synopsys documentation to [email protected]

Physical Compiler®

Clock Tree SynthesisUser GuideVersion U-2003.06-PCE3.0, June 2003

ii

Copyright Notice and Proprietary InformationCopyright 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 DocumentationThe 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 StatementAll 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.

DisclaimerSYNOPSYS, 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 QAPhysical Compiler Clock Tree Synthesis User Guide, Version U-2003.06-PCE3.0

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-12Using an Input Port As the Clock Tree Root . . . . . . . . . . . . . 2-12Using an Output Pin As the Clock Root . . . . . . . . . . . . . . . . 2-13Reporting the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Verifying the Clock Tree Root . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Determining the Default Clock Sinks . . . . . . . . . . . . . . . . . . . . . 2-17

Specifying Clock Tree Exceptions . . . . . . . . . . . . . . . . . . . . . . . 2-20Excluding Clock Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Defining Stop Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22Defining 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-38Specifying Routing Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38Specifying Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39Determining the RC Coefficients . . . . . . . . . . . . . . . . . . . . . 2-40

iv

Handling Specific Design Characteristics . . . . . . . . . . . . . . . . . . . . 2-42

Handling Hard Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42

Handling Existing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43Locating Existing Clock Trees . . . . . . . . . . . . . . . . . . . . . . . 2-44Preserving Portions of an Existing Clock Tree . . . . . . . . . . . 2-44Removing 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-8Deriving Keepouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Defining Keepouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Reporting 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-11Default Clock Tree Report . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Clock Tree Settings Report. . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Clock Tree Exceptions Report . . . . . . . . . . . . . . . . . . . . . . . 4-15Clock Tree Design Rule Violations Report . . . . . . . . . . . . . . 4-16Clock Tree Levels Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Clock 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

• 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 [email protected].

• 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

1Introduction 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.

1-1

Introduction to Physical Compiler Clock Tree Synthesis

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.

1-2

Introduction to Physical Compiler Clock Tree Synthesis: Benefits of Using Physical Compiler Clock Tree

• 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

1-5

Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

• 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).

1-6

Introduction to Physical Compiler Clock Tree Synthesis: Product Overview

Methodology Overview

Figure 1-1 shows the flow for clock tree synthesis within Physical Compiler.

Figure 1-1 RTL-to-GDSII Flow

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.

RTL

Placed design

To router

Constraints

Physical Compiler

Design planning

Physical Compiler

Withinpsyn_shell

unified synthesisand

placement

clock tree synthesis

1-7

Introduction to Physical Compiler Clock Tree Synthesis: Methodology Overview

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

Prepare design forConstraints Floorplan information

Placed design

clock tree synthesis

Fine-tuneclock tree synthesis

Define clock trees

Verify clock trees

Synthesize clock trees

Set constraints for clock tree synthesis

Analyze clock trees

Save design

Violationsexist?

yes

no

Analyze design

Violationsexist?

yes noPerformphysical synthesis

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 constraintset_clock_tree_options -root CLK_port -clock CLK

-max_fanout 50

# specify clock tree exceptionsset_clock_tree_exceptions -exclude TEST_port

# specify clock reference listset_clock_tree_references -references {CLKBUF16 CLKBUF20}

# verify clock treesreport_clock_tree -clock CLK -settings -exceptions

# perform clock tree synthesiscompile_clock_tree

# analyze resultsreport_clock_tree -clock CLK -level_info -settingsreport_constraintreport_timing

# refine the designphysopt -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.

1-12

Introduction to Physical Compiler Clock Tree Synthesis: Commands Specific to Clock Tree Synthesis

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.

Table 1-1 Summary of Commands Specific to Clock Tree Synthesis (Continued)

Command Description

1-13


1-14


2Running 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

2-1

Running Clock Tree Synthesis

• 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.

2-2

Running Clock Tree Synthesis

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

2-3

Running Clock Tree Synthesis: Preparing the Libraries

• 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

2-4

Running Clock Tree Synthesis: Preparing the Libraries

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.

2-5

Running Clock Tree Synthesis: Preparing Your Design

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_designpsyn_shell-t> link my_designpsyn_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.

2-10

Running Clock Tree Synthesis: Defining the Clock Trees

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


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

psyn_shell-t> set_clock_tree_options \-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 SummaryDesign : my_designVersion: Date : Thu Mar 28 09:36:57 2002****************************************Clock Tree Name : "CLK"Clock Tree root pin : "my_design/CLK"Number of Sinks : 712Number of CT Buffers : 0Number of Preexisting Cells : 0Total gate capacitance : 2.136000----------------------------------------- Level 0 Level 1-----------------------------------------No of Buffers 0 0No of Preexist. Cells 0 0No of Sinks 0 712Min driven gate cap 2.13600 N/AMax driven gate cap 2.13600 N/Amin fanout 712 N/Amax 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

psyn_shell-t> set_clock_tree_exceptions \-exclude_pins [get_pins U2/A]

2-21


Figure 2-1 Explicit Exclude Pin

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.

CLK

U2

AB

n1

2-22


For example, to specify pin U2/A as a branch endpoint, enter

psyn_shell-t> set_clock_tree_exceptions \-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

psyn_shell-t> set_clock_tree_exceptions \-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 TreeDesign : my_designVersion: 2002.05-PCE1Date : Thu Aug 15 09:12:15 2002****************************************

Clock Tree Name : "CLK"...

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 ) "clk1a15" (maxLoad: 2.000 , maxSlew: 0.700 *, maxFanout: 75 *) "clk1a15" -library- (maxLoad: 2.000 , maxSlew: 0.500 , maxFanout: 25 ) "clk1a27" (maxLoad: 2.000 , maxSlew: 0.700 *, maxFanout: 100 *) "clk1a27" -library- (maxLoad: 2.000 , 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

2-28

Running Clock Tree Synthesis: Setting Constraints for Clock Tree Synthesis

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


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

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

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


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" (maxLoad: 1.239 , maxSlew: 1.000 *, maxFanout: 177 *)"clk1a9" -library- (maxLoad: 1.239 , maxSlew: N/A , maxFanout: N/A )"clk1a6" (maxLoad: 0.821 , maxSlew: 1.000 *, maxFanout: 118 *)"clk1a6" -library- (maxLoad: 0.821 , maxSlew: N/A , maxFanout: N/A )

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)} ...

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

Table 2-2 Default Design Rule Constraints for Clock Tree Synthesis

Constraint Default

Maximum capacitance 1 pF

Maximum transition time 1 ns

Maximum fanoutInteger portion of

(with a minimum value of 20)

input_pin_loadmax_capacitance----------------------------------------------

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

psyn_shell-t> set_clock_tree_options \-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

psyn_shell-t> set_clock_tree_options \-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.

psyn_shell-t> set_clock_tree_options \-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 routing rule that y

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_tx125m_L2I28949_Y : SP1xW2xS ck_tx125m_L2I28947_Y : SP1xW2xS ck_tx125m_L2I28941_Y : SP1xW2xS ck_tx125m_L2I28940_Y : SP1xW2xS ck_tx125m_L2I28939_Y : SP1xW2xS .. .. ck_rxX125m_L4I28480_Y : SP ck_rxX125m_L4I28476_Y : SP ck_rxX125m_L4I28475_Y : SP ck_rxX125m_L4I28473_Y : SP ck_rxX125m_L4I28464_Y : SP ck_rxX125m_L4I28463_Y : SP ck_rxX125m_L4I28400_Y : SP ck_rxX125m_L4I28399_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

2-42

Running Clock Tree Synthesis: Handling Specific Design Characteristics

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:

psyn_shell-t> set_clock_tree_exceptions \-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

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

U0

A

B

CLK

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

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)

CLKA

B

MUX_A

Z

CK

CK

CK

CK CK

CK CK

CK

CK

CK

CK

Primary clock root

Convergence cell

Convergentclock subtree

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 Clocksset_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

CLKA

CLKBMUX_A

Overlappingclock subtree

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 Clocksset_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.

2-52

Running Clock Tree Synthesis: Verifying the Clock Trees

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.

2-53

Running Clock Tree Synthesis: Synthesizing the Clock Trees

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


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.

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

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.

2-57

Running Clock Tree Synthesis: Synthesizing High-Fanout Nets

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 tree synthesis process)

3. Places and legalizes the buffers and inverters (step 3 in the clock tree synthesis process)

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.”

2-60

Running Clock Tree Synthesis: Analyzing the Clock Trees

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.

2-64

Running Clock Tree Synthesis: Fine-Tuning Clock Tree Synthesis

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-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.

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.

2-68

Running Clock Tree Synthesis: Analyzing the Design

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

2-69

Running Clock Tree Synthesis: Analyzing the Design

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.

2-70

Running Clock Tree Synthesis: Performing Detail Routing

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


3Hierarchical 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.

3-2

Hierarchical Clock Tree Synthesis: Overview of Interface Logic Models

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

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.

Data

Clock

Data

in out

3-3

Hierarchical Clock Tree Synthesis: Overview of Interface Logic Models

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.

3-4

Hierarchical Clock Tree Synthesis: Creating the Interface Logic Models

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.

For the complete syntaxes, see the man pages.

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.

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.cstrpsyn_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.

3-10

Hierarchical Clock Tree Synthesis: Preparing for Top-Level Clock Tree Synthesis

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.

3-11

Hierarchical Clock Tree Synthesis: Running Top-Level Clock Tree Synthesis

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

………

clk_in

clk_out

Top-levelsubtree

U1

TOP

clk

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


4Analyzing 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

4-1

Analyzing Clock Tree Synthesis Results

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.

4-2

Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Objects

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_objectsCLK {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.

4-5

Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Attributes

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_tree1clock_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: Because the result is intended to be packed into an associative array, the order in which each clock tree and each attribute is returned is not guaranteed.

Table 4-2 Clock Tree Attributes

Attribute Command option

ct_is_compiled -compiled

ct_num_levels -num_levels

name -name

4-6

Analyzing Clock Tree Synthesis Results: Accessing Clock Tree Attributes

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.

4-7

Analyzing Clock Tree Synthesis Results: Analyzing Clock Tree Timing Information

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


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 current instance and any of the sink pins that it drives (on a falling input transition at the clock tree root).

late_fwd_r float The longest (late) 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).

late_fwd_f float The longest (late) path delay between the output of the current instance and any of the sink pins that it drives (on a 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.

Table 4-3 Clock Tree Instance Attributes (Continued)


4-9


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_element1element2 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: Because the result is intended to be packed into an associative 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.

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.

Table 4-3 Clock Tree Instance Attributes (Continued)


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)****************************************Report : Physical Compiler Clock TreeDesign : my_designVersion: U-2003.06-PCE3.0Date : Tue Jun 10 23:10:41 2003****************************************

Clock Tree Name : "CLK"Compiled Tree : 1Clock Tree root pin : "my_design/CLK"Number of Levels : 4Number of Sinks : 712Number of CT Buffers : 42Number of Preexisting Cells : 0Total Area of CT Buffers : 2494.79956Max Global Skew : 0.05527Early Rise-to-Rise endpoint : "REG1/CLK"Late Rise-to-Rise endpoint : "REG6/CLK"Rise to Rise Delay (Early/Late): 1.258433 / 1.313705Clock Root Rising Edge Skew : 1.313705 - 1.258433 = 0.055272

4-13


Example 4-2 Default Clock Tree Report (Both Local and Global Skew)****************************************Report : Physical Compiler Clock TreeDesign : my_designVersion: U-2003.06-PCE3.0Date : Tue Jun 10 23:10:41 2003****************************************

Clock Tree Name : "CLK"Compiled Tree : 1Clock Tree root pin : "my_design/CLK"Number of Levels : 4Number of Sinks : 712Number of CT Buffers : 42Number of Preexisting Cells : 0Total Area of CT Buffers : 2494.79956Max Local Skew : 0.05527Rise 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.258433Root Rising Edge Local Skew : 1.313704 - 1.258433 = 0.055271

Max Global Skew : 0.05527Early Rise-to-Rise endpoint : "REG1/CLK"Late Rise-to-Rise endpoint : "REG6/CLK"Rise to Rise Delay (Early/Late): 1.258433 / 1.313705Clock 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 ReportSettings 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 "clk1a9" (maxLoad: 1.239 , maxSlew: 0.700 *, maxFanout: 50 *) "clk1a9" -library- (maxLoad: 1.239 , maxSlew: 0.500 , maxFanout: 25 ) "clk1a15" (maxLoad: 2.000 , maxSlew: 0.700 *, maxFanout: 75 *) "clk1a15" -library- (maxLoad: 2.000 , maxSlew: 0.500 , maxFanout: 25 ) "clk1a27" (maxLoad: 2.000 , maxSlew: 0.700 *, maxFanout: 100 *) "clk1a27" -library- (maxLoad: 2.000 , 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)}

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 ReportExceptions 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 Exclude Pin (Inferred) : MUX4/B Exclude Pin (Inferred) : MUX5/B Exclude Pin (Inferred) : MUX6/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 ReportNumber 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 0Buffer Used N/A clk1a27 clk1a15 clk1a15 clk1a15 N/ANo of Preexist. Cells 0 0 0 0 0 0No of Sinks 0 0 0 0 0 712No MaxFanout Viol. 0 0 0 0 0 0Min driven cap 0.02815 0.05598 0.06137 0.19223 0.06122 N/AMax driven cap 0.02815 0.05598 0.07026 0.20389 0.11033 N/ANo MaxCap Violators 0 0 0 0 0 0No of ndrule nets 0 0 0 0 0 0Min Rise Prop delay 0.00000 0.44340 0.21743 0.32128 0.27334 N/AMin Fall Prop delay N/A N/A N/A N/A N/A N/AMax Rise Prop delay 0.00000 0.44340 0.22398 0.33337 0.31117 N/AMax Fall Prop delay N/A N/A N/A N/A N/A N/AMin Rise Transition 0.00000 0.00011 0.02490 0.03190 0.07508 0.03437Min Fall Transition N/A N/A N/A N/A N/A N/AMax Rise Transition 0.00000 0.00011 0.02490 0.03481 0.07901 0.04897Max Fall Transition N/A N/A N/A N/A N/A N/ANo MaxSlew Violators 0 0 0 0 0 0Early Rise-Rise arrival 0.00000 0.00031 0.44395 0.66168 0.98355 1.25843Late Rise-Rise arrival 0.00000 0.00031 0.44398 0.66850 1.00473 1.31370Early Rise-Fall arrival N/A N/A N/A N/A N/A N/ALate 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/ALate Fall-Rise arrival N/A N/A N/A N/A N/A N/AEarly Fall-Fall arrival 0.00000 N/A N/A N/A N/A N/ALate 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_elementobject1

object2

...objectn

Example 4-7 shows a portion of a clock tree structure report.

Example 4-7 Clock Tree Structure Report****************************************Report : Physical Compiler Clock TreeDesign : addressVersion: 2002.05-PCE1Date : 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> CLKL1I9984:buffer, cellName:clk1a15, in:A, out:Y, time (posedge, noninverting)= 0.443980(r) 0.472948(f), driven net: CLKL1I9984_Y, routing rule: <default> CLKL1I9985:buffer, cellName:clk1a15, in:A, out:Y, time (posedge, noninverting)= 0.443955(r) 0.472923(f), driven net: CLKL1I9985_Y, routing rule: <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, time (posedge, noninverting)= 1.293517(r) 1.325696(f) PHYSICAL_ADDRESS_ZETA_REG_14A:sink pin, cellName:fdf1a3, in:CLK, out:NIL, time (posedge, noninverting)= 1.293506(r) 1.325685(f) ... Y1_X_XRES_COLOR2_REG_27A:sink pin, cellName:fdf1a3, in:CLK, out:NIL, time (posedge, noninverting)= 1.293668(r) 1.325847(f)

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.

4-21

Analyzing Clock Tree Synthesis Results: Viewing Clock Trees in the Physical Compiler GUI

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


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


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.

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.

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 timeThe delay of the clock tree to a particular level.

cascaded gated clockA gated clock that contains more than one level of clock gating logic. Also called multilevel gated clock.

clock latencyMinimum 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 objectThe clock object is created by the create_clock command. It identifies the clock source pin for Design Compiler and Physical Compiler.

Arrival time for level 1Arrival time for level 2

GL-1

clock skewThe 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 objectThe 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 uncertaintyThe 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 constraintsDesign 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 pinSee sink.

exclude pinA sink of a clock tree that is not considered when the clock is buffered.

GL-2

float pinA 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.

gated clockA clock network that contains preexisting cells on the clock path.

hold timeThe 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 delayMinimum 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.

float

clkA

Float pin

B

Hard IP

Insertion delay = A + Bwhere

A is clock tree insertedB is specified in set_clock_tree_exceptions

Insertion delay

stop

clkStop pin

GL-3

levelA 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.

multilevel gated clockA gated clock that contains more than one level of clock gating logic. Also called cascaded gated clock.

propagation delayDelay of the clock tree cell at that level.

root pinThe startpoint of the clock tree. Can be an output pin of a cell or an input port of the design. Also called source.

1 Level 2 Level 3 Level

propagation delayfor level 1

propagation delayfor level 2

GL-4

setup timeThe 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.

sinkA clock tree termination pin; sometimes called end pin.

skewSee clock skew; called clock uncertainty in Design Compiler.

local skew—skew within a blockglobal skew—skew at the chip level

sourceThe startpoint of the clock tree. A clock tree can have a single source. Also called root pin.

stageSee level.

stop pinModified sink of a clock tree (a pin that would not otherwise be treated as a sink).

transition delayTransition time of the cell’s output pin.

ungated clockA clock network that contains no logic on the clock path (even buffers or inverters).

GL-5

GL-6

Index

Aarrival time

defined GL-1reporting 4-17

attributesct_floatpin_clock_tree_name 2-24ct_floatpin_max_del 2-24ct_floatpin_min_del 2-24ct_is_dont_touch_subtree 2-45ct_is_exclude_pin 2-21ct_is_snps_added 2-56ct_is_stop_pin 2-22has_cts_ba 2-45, 2-55

Bbuffering constraints, setting 2-35buffers

resetting 2-25sizing 2-67specifying 2-24viewing 2-26

Ccapacitance constraint, maximum

setting 2-30viewing 2-32

cascaded gated clockdefined GL-1See also gated clock

check_legality command 2-7clock latency

defined GL-1network 2-8source 2-8

clock net, routing without bufferingby delay 2-37by fanout 2-36specifying 2-37

clock networkerrors 2-20tracing 2-17

clock objectcompared to clock tree object 2-11defined GL-1

clock pathconvergent 2-48overlapping 2-51

clock rootconstraint violations on 2-15defined 2-10specifying 2-11

IN-1

clock sinkdefault

tracing rules 2-17viewing 2-18

defined 2-10excluding 2-21noncritical 2-66stop pin 2-22

clock sourceSee clock root

clock treedefining 2-11removing 2-46reporting 4-11synthesizing 2-53viewing 4-21

clock tree constraintsbuffering 2-35design rule 2-30operating conditions 2-30routing 2-38timing

defined 2-34maximum insertion delay 2-34maximum skew 2-34minimum insertion delay 2-34priority 2-34

clock tree definitioncreating 2-11removing 2-11reporting 4-14

clock tree exceptiondon’t touch subtrees 2-44exclude pins 2-21float pins 2-42route-only nets 2-37stop pins 2-22

clock tree hierarchy viewdefined 4-28displaying 4-28

example 4-28clock tree objects

accessing 4-2creating 2-11defined 4-2naming 2-11

clock tree referencesresetting 2-25specifying 2-24viewing 2-26

clock tree reportdefault 4-12design rule violations 4-16exceptions 4-15generating 4-11levels 4-17settings 4-14structure 4-19verbose 4-19

clock tree structureactual, reporting 4-19settings, reporting 4-14specifying 2-10

clock tree timingdefault computation 4-7updating 4-7

CMD-041 message 4-3commands

check_legality 2-7compile_clock_tree 2-53compile_physical 2-6extract_ilm 3-6extract_rc 2-70, 2-72get_clock_tree_delay 4-10get_clock_tree_objects 4-2identify_interface_logic 3-5optimize_placement 2-68physopt 2-6, 2-8

-incremental 2-69propagate_ilm 3-10

IN-2

report_congestion 2-7reset_clock_tree_references 2-25route_global 2-70set_clock_latency 2-8set_clock_tree_exceptions

-dont_touch_subtrees 2-44-exclude_pins 2-21float pin options 2-23, 2-42-global_route_only_subtrees 2-37-stop_pins 2-22

set_clock_tree_options 2-11set_clock_tree_references 2-24set_congestion_options 2-8set_delay_estimation_options 2-4set_disable_timing 2-18set_input_delay 2-8set_operating_conditions 2-30set_output_delay 2-8write_def 2-71

compile_clock_tree command 2-53-clock_trees 2-53-drc_effort 2-64-no_clock_attributes 2-56-no_dont_touch 2-56-no_dont_touch_network 2-56-no_dont_touch_placement 2-56-size_gates 2-67-skew_effort 2-65

compile_physical command 2-6congestion

fixing 2-8reporting 2-7

constraintsclock tree timing 2-34

maximum insertion delay 2-34maximum skew 2-34minimum insertion delay 2-34

maximum capacitance 2-30maximum fanout 2-30maximum transition time 2-30

convergent clock pathdefined 2-9synthesizing 2-48

critical cell costing 2-67ct_floatpin_clock_tree_name attribute 2-24ct_floatpin_max_del attribute 2-24ct_floatpin_min_del attribute 2-24ct_is_dont_touch_subtree attribute 2-45ct_is_exclude_pin attribute 2-21ct_is_snps_added attribute 2-56ct_is_stop_pin attribute 2-22cts_cell_costing variable 2-67cts_iterative_optimization variable 2-29cts_no_implicit_exclude_pins variable 2-19cts_skip_high_fanout_default_settings variable 2-59cts_use_all_buffers_for_refinement variable 2-54cts_use_auto_convergence_subtrees variable 2-49cts_use_local_skew variable, variables

cts_use_local_skew 4-12

Ddata requirements 1-5DEF

generating 2-71SOURCE TIMING construct 2-71USE CLOCK construct 2-71

design rule constraintsoptimization effort 2-64priority 2-31setting 2-30viewing 2-32violations on clock root 2-15

detail routinganalyzing design after 2-72analyzing design before 2-70third-party tool 2-71

IN-3

don’t touch subtreeattribute 2-45defined 2-44explicit 2-45implicit 2-45interface logic models 3-12reporting 4-15

DRCSee design rule constraints

Eeffort level

design rule optimization 2-64skew optimization 2-65

exceptions for clock tree synthesisdon’t touch subtree 2-44exclude pin 2-21float pin 2-42route-only net 2-37stop pin 2-22

exclude pinattribute 2-21defined 2-20explicit

defined 2-21specifying 2-21

implicitdefined 2-19listing 2-19overriding 2-19preventing 2-19

reporting 4-15extract_ilm command 3-6extract_rc command 2-70, 2-72extract2plib utility 2-5extraction parameters

in RC computations 2-40required in physical library 2-4

Ffanout constraint, maximum

setting 2-30viewing 2-32

float pinattributes 2-24defined 2-20, 2-42reporting 4-15setting 2-42uses

controlling arrival time 2-23modelling hard macros 2-42

Ggated clock

cascaded, defined GL-1defined GL-3multilevel, defined GL-4unsupported constraints 2-26, 2-35, 2-36

generated clock, tracing through 2-18get_clock_tree_delays command 4-10get_clock_tree_objects command 4-2global routing

clock ne 0 Tc, dWpG19 Tc-Tc-0.9c-

IN-4

Iidentify_interface_logic command 3-5input delay, specifying 2-8insertion delay

maximumclock network latency 2-8specifying 2-34

minimum, specifying 2-34interclock skew, balancing 2-52interface logic model

adding logic to 3-6creating 3-4defined 3-2don’t touch subtrees 3-12extracting 3-6keepouts

defining 3-9deriving 3-8reporting 3-9

reading 3-10reducing size of 3-5

interface logic modelskeepouts

propagating 3-10interface logic, defined 3-3inverters

resetting 2-25specifying 2-24viewing 2-26

iterative optimization, defined 2-29

Llegalizing

clock buffers 2-54critical cells 2-67nonclock buffers 2-57

license requirements 1-5local skew

defined 4-12

Mmaximum capacitance

setting 2-30violation on clock tree root 2-15

maximum fanout, setting 2-30maximum insertion delay


maximum skew, setting 2-34maximum transition time


messages, CMD-041 4-3minimum conditions, specifying 2-4minimum insertion delay, setting 2-34minimum scaling factor, setting 2-4multilevel gated clock

defined GL-4See also gated clock

Nnaming style, clock tree objects 2-11noncritical sink 2-66noncritical subtrees

ignoring 2-66reporting timing in 2-66

Ooperating conditions, setting 2-30optimize_placement command 2-68output delay, specifying 2-8overlapping clock path

defined 2-9synthesizing 2-51

IN-5

Pphysical optimization

after clock tree synthesis 2-55, 2-69fixing congestion 2-8incremental 2-69initial 2-6timing budget for 2-8

physopt command 2-6, 2-8-incremental 2-69

post-route design, analyzing 2-72propagate_ilm command 3-10

RRC coefficients

capacitance-based 2-41extraction-based 2-40

references, clock treeSee clock tree references

remove_clock_tree_options command 2-11report, clock tree, generating 4-11report_congestion command 2-7requirements, clock tree synthesis

data 1-5license 1-5

reset network, synthesizing 2-2See also high-fanout net

reset_clock_tree_references command 2-25root

See clock rootroutability

after clock tree synthesis 2-70before clock tree synthesis 2-7

route_global command 2-70route-only clock nets

by delay 2-37by fanout 2-36specifying 2-37

routing constraints, setting 2-38routing layers

default 2-38setting 2-38

routing ruledefault 2-39nondefault

defined 2-39reporting 2-40specifying 2-39

wide wire, specifying 2-39

Sscan enable network, synthesizing 2-2

See also high-fanout netselective skew balancing 2-66set_clock_latency command 2-8set_clock_tree_exceptions command

-dont_touch_subtrees 2-44-exclude_pins 2-21float pin options 2-23, 2-42-global_route_only_subtrees 2-37-stop_pins 2-22

set_clock_tree_options command 2-11-clock_tree_name 2-11-delay_limit_for_route_only_clock_net 2-37-fanout_limit_for_route_only_clock_net 2-36-high_fanout 2-57-ignore_noncritical_sinks 2-66-layer_list 2-38-max_delay 2-34-max_skew 2-34-min_delay 2-34-number_of_instances_per_level 2-36-number_of_levels 2-35-prefix 2-11-priority 2-16, 2-29-reference_per_level 2-25-root 2-11-routing_rule 2-39-timing_arc 2-13-use_default_routing_for_sinks 2-39

IN-6

set_clock_tree_references command 2-24set_congestion_options command 2-8set_delay_estimation_options command 2-4set_disable_timing command 2-18set_input_delay command 2-8set_operating_conditions command 2-30set_output_delay command 2-8sink

See clock sinksizing buffers 2-67skew

global 2-34local 4-12specifying maximum 2-34

skew balancingbetween clocks 2-52selective, within a clock 2-66

skew optimization, effort levels 2-65source

See clock rootstop pin

attribute 2-22defined 2-20reporting 4-15specifying 2-22

structure, specifying for clock tree 2-10synthesizing

clock treescommand 2-53fine-tuning 2-64process 2-53

high-fanout nets 2-58

Tthird-party router, interface 2-71timing constraints, clock tree 2-34

maximum insertion delay 2-34maximum skew 2-34minimum insertion delay 2-34

transition time constraint, maximumsetting 2-30viewing 2-32

turnaround time 1-5

Uungated clock, defined GL-5

Vvariables

cts_cell_costing 2-67cts_iterative_optimization 2-29cts_no_implicit_exclude_pins 2-19cts_skip_high_fanout_default_settings 2-59cts_use_all_buffers_for_refinement 2-54cts_use_auto_convergence_subtrees 2-49

Wwide wires

reporting 2-40specifying 2-39

wire typedefault 2-39specifying 2-39

write_def command 2-71

IN-7

ctcug

Documents

design compiler

power compiler

library compiler

system compiler

vhdl compiler

fpga compiler

ecl compiler

dft compiler