Synopsys Guide

Document downloaded by Sridhara Sree Rame Gowda on 3/7/2019 9:53:08 PM PST. cesdocs$!
2019
y
nl
CUSTOMER EDUCATION SERVICES
O
se
U
al
IC Compiler II:
rn
Block-level Implementation
te
Workshop
Student Guide In
s
20-I-078-SSG-009 2018.06-SP4
sy
op
yn
rS
Fo
ed
Synopsys Customer Education Services

er
690 E. Middlefield Road

Mountain View, California 94043
st
Workshop Registration: https://training.synopsys.com

i
eg
R
Document downloaded by Sridhara Sree Rame Gowda on 3/7/2019 9:53:08 PM PST. cesdocs$!2019
Copyright Notice and Proprietary Information

 2019 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
y
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license
nl
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
O
by the license agreement.
se
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
U
determine the applicable regulations and to comply with them.
Disclaimer
al
SYNOPSYS, INC. AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
rn
WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
te
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
In
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
s
Third-Party Links
sy
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.
op
Synopsys, Inc.
690 E. Middlefield Road
yn
Mountain View, CA 94043

www.synopsys.com
rS
Fo
Document Order Number: 20-I-078-SSG-009

IC Compiler II: Block-level Implementation Student Guide
ed
er
ist
eg
R
Table of Contents
Unit i: Introduction
Facilities ............................................................................................................................ i-2
y
Workshop Overview ......................................................................................................... i-3
nl
Workshop Target Audience .............................................................................................. i-4
O
Workshop Prerequisite Knowledge .................................................................................. i-5
Introductions ..................................................................................................................... i-6
se
Agenda .............................................................................................................................. i-7
Agenda .............................................................................................................................. i-8
Agenda .............................................................................................................................. i-9
U
IC Compiler II ................................................................................................................. i-10
IC Compiler II GUI ......................................................................................................... i-11
al
Task Assistant ................................................................................................................. i-12
rn
Built-In Script Editor ...................................................................................................... i-13
Lab 0 – IC Compiler II GUI ........................................................................................... i-14
te
In
Unit 1: Objects, Blocks and App Options
Agenda ............................................................................................................................. 1-1
s
Objectives ........................................................................................................................ 1-2
sy
Objects ............................................................................................................................. 1-3
Querying Objects Associated with Objects ..................................................................... 1-4
op
Querying Objects / Hierarchy .......................................................................................... 1-5

Querying Objects by Location ......................................................................................... 1-6
Attributes of Objects ........................................................................................................ 1-7
yn
Retrieving and Setting Attribute Values .......................................................................... 1-8

Reporting Attributes of Objects ....................................................................................... 1-9
rS
Accessing Cascaded Attributes ...................................................................................... 1-10

Blocks and Design Libraries .......................................................................................... 1-11
Save the Design Library and Block ............................................................................... 1-12
Fo
Copying then Saving ...................................................................................................... 1-13

Application Options ....................................................................................................... 1-14
Finding / Reporting Application Options ...................................................................... 1-15
ed
Setting Application Options........................................................................................... 1-16

Or Use the GUI .............................................................................................................. 1-17
er
Scope of Application Options ........................................................................................ 1-18

Block-Scoped Application Options ............................................................................... 1-19
st
Global-Scoped Application Options .............................................................................. 1-20

i
Unit Objectives Summary .............................................................................................. 1-21

eg
Appendix ........................................................................................................................ 1-22

Use bounding_box instead of bbox................................................................................ 1-23
R
Removing Objects.......................................................................................................... 1-24

Bus and Name Expansion and Subscripting (1 of 2) ..................................................... 1-25
Bus and Name Expansion and Subscripting (2 of 2) ..................................................... 1-26
Blocks and Libraries ...................................................................................................... 1-27
Synopsys 20-I-078-SSG-009 i IC Compiler II: Block-level Implementation

Table of Contents
Renaming then Saving the Current Block ..................................................................... 1-28

Design Libraries ............................................................................................................. 1-29
Block Handle ................................................................................................................. 1-30
y
nl
Unit 2: Floorplanning
O
Agenda ............................................................................................................................. 2-1
Unit Objectives ................................................................................................................ 2-2
se
General IC Compiler II Flow ........................................................................................... 2-3
Floorplanning Overview .................................................................................................. 2-4
Create the Initial Floorplan .............................................................................................. 2-5
U
Floorplan After Initialization ........................................................................................... 2-6
Create Voltage Areas (for MV Designs) ......................................................................... 2-7
al
Automatic VA Creation: “Shape Blocks”........................................................................ 2-8
rn
Place Macros and Standard Cells ..................................................................................... 2-9
Configuring Macro and Standard Cell Placement ......................................................... 2-10
te
Detailed Macro Constraints, Fixing Macro Placement .................................................. 2-11
Analyze Placement of Macros using Data Flow Flylines (DFF) ................................... 2-12
In
Register Tracing ............................................................................................................. 2-13
Place I/O Pins ................................................................................................................. 2-14
s
Analyze Global Route Congestion................................................................................. 2-15
sy
Congestion Segment Labels ........................................................................................... 2-16
Congestion Potential Around Macro Cells .................................................................... 2-17
op
Apply “Padding” Around Macro Edges ........................................................................ 2-18

Power Planning Challenges ........................................................................................... 2-19
Pattern-Based Power Network Synthesis....................................................................... 2-20
yn
Write out the Floorplan for ICC II ................................................................................. 2-21

Write out Floorplan Information for DC-G ................................................................... 2-22
rS
Second-Pass Synthesis Before Placement ..................................................................... 2-23

Summary ....................................................................................................................... 2-24
Appendix ....................................................................................................................... 2-25
Fo
What is a Site Array? ..................................................................................................... 2-26

Effective Site Array ....................................................................................................... 2-27
Three Types of Site Arrays ............................................................................................ 2-28
ed
Advantages ..................................................................................................................... 2-29

Real Example ................................................................................................................. 2-30
er
Common Site Array Questions ...................................................................................... 2-31

Common Site Array Questions ...................................................................................... 2-32
ist
Unit 3: Placement and Optimization

eg
Agenda ............................................................................................................................. 3-1

R

Unit Objectives ................................................................................................................ 3-3
Key Steps of the Placement Phase ................................................................................... 3-4
Placement and Optimization Commands ......................................................................... 3-5
Synopsys 20-I-078-SSG-009 ii IC Compiler II: Block-level Implementation

Table of Contents
Placement and Logic Optimization: place_opt ................................................................ 3-6

The Five Stages of place_opt .......................................................................................... 3-7
Recommended place_opt Exploration Flow .................................................................... 3-8
Design Status Prior to Placement..................................................................................... 3-9
y
Pre-Placement Check ..................................................................................................... 3-10
nl
check_design Results ..................................................................................................... 3-11
O
Also Recommended: Physical Constraint Checks ......................................................... 3-12
Design and Flow Requirement Setup Steps ................................................................... 3-13
se
Setup for Advanced Nodes ............................................................................................ 3-14
set_technology: Design Setup Check Examples ............................................................ 3-15
Advanced Legalizer ....................................................................................................... 3-16
U
Migrating to the Advanced Legalizer ............................................................................ 3-17
Configure Scenarios for MCMM Optimization ............................................................. 3-18
al
Configuring place_opt for SPG ..................................................................................... 3-19
rn
High Fanout Synthesis Port Punching ........................................................................... 3-20
Even Distribution of Spare Cells - Automatic ............................................................... 3-21
te
Spare Cells Identification – Automatic versus Manual ................................................. 3-22
Add Spare Cells Not Already in the Netlist ................................................................... 3-23
In
Remove Unwanted Ideal Networks ............................................................................... 3-24
Library Cell Purpose ...................................................................................................... 3-25
s
Restrict Library Cell Usage ........................................................................................... 3-26
sy
Preroute Power Optimization ......................................................................................... 3-27
Leakage Power Optimization ......................................................................................... 3-28
op
Leakage Improvement by Vt Swapping ........................................................................ 3-29

Report Multi-Vt Cells .................................................................................................... 3-30
Dynamic Power Optimization........................................................................................ 3-31
yn
Dynamic Power Optimizations Require Switching Activity ......................................... 3-32

Limitations with the set_switching_activity Approach ................................................. 3-33
rS
Inferring Static Values for Control Signals ................................................................... 3-34

Inferring Switching Activity for Other Essential Points ................................................ 3-35
Recommended Setup for infer_switching_activity ........................................................ 3-36
Fo
Total Power Optimization .............................................................................................. 3-37

Test For Understanding (1 of 2)..................................................................................... 3-38
Test For Understanding (2 of 2)..................................................................................... 3-39
ed
Congestion-Focused Setup Steps ................................................................................... 3-40

Global-Route Congestion Analysis................................................................................ 3-41
er
Global Route Congestion Map....................................................................................... 3-42

Congestion Segment Labels ........................................................................................... 3-43
st
Increase Placement/Congestion Effort ........................................................................... 3-44

i
Global Route-Based HFS and DRC Fixing (GR-opto).................................................. 3-45

eg
Keepout Margins and Placement Blockages.................................................................. 3-46

Cell and Pin Density Analysis ....................................................................................... 3-47
R
Is High Cell Density Causing Congestion? ................................................................... 3-48

Limit Cell Density with Partial Blockages .................................................................... 3-49
Considering the Congestion of Each Layer ................................................................... 3-50
Optimizing Pin Access ................................................................................................... 3-51
Synopsys 20-I-078-SSG-009 iii IC Compiler II: Block-level Implementation

Table of Contents
Congestion-Driven Restructuring (CDR) ...................................................................... 3-52

CDR Setup ..................................................................................................................... 3-53
CDR with SPG ............................................................................................................... 3-54
Test For Understanding.................................................................................................. 3-55
y
Timing-Focused Setup Steps ......................................................................................... 3-56
nl
Timing/DRC QoR Summary Report ............................................................................. 3-57
O
Capture Comprehensive Design Metrics ....................................................................... 3-58
Analyze Metrics in Depth .............................................................................................. 3-59
se
Design Fusion - Logic Restructuring for Area and Timing ........................................... 3-60
Logic Restructuring for Area and Timing ..................................................................... 3-61
Design Fusion – Logic Restructuring for Area and Timing .......................................... 3-62
U
Restructuring – Wire Length Cost ................................................................................. 3-63
Timing Driven Placement .............................................................................................. 3-64
al
Buffering Aware Timing Driven Placement (BAP) ...................................................... 3-65
rn
Two-Pass Placement Flow ............................................................................................. 3-66
Controlling Cell Density ................................................................................................ 3-67
te
Setting Cell Density Manually ....................................................................................... 3-68
Reporting Design Utilization ......................................................................................... 3-69
In
Legalization: Minimizing Large Displacements ............................................................ 3-70
Stream Legalization Targets Smaller Moves ................................................................. 3-71
s
Enable Stream Legalization ........................................................................................... 3-72
sy
Post-CTS ICG Enable Timing Problem......................................................................... 3-73
Pre-CTS ICG Enable Timing is OPTIMISTIC.............................................................. 3-74
op
Solution: ICG Optimization ........................................................................................... 3-75

Trial CTS ....................................................................................................................... 3-76
CTS Setup Needed for Trial CTS .................................................................................. 3-77
yn
ICG Splitting and Clock-Aware Placement ................................................................... 3-78

Enabling ICG Optimization ........................................................................................... 3-79
rS

Power- and Area-Focused Setup Steps .......................................................................... 3-81
Power Analysis .............................................................................................................. 3-82
Fo
Area Analysis ................................................................................................................. 3-83

Power and Area Optimization Effort ............................................................................. 3-84
Pre-route / Post-route Correlation .................................................................................. 3-85
ed
Pre-Route Layer Optimization ....................................................................................... 3-86

Route-Driven Extraction (RDE) for Preroute Optimization .......................................... 3-87
er
RDE in the Pre-Route Flow ........................................................................................... 3-88

Dynamic Power-Driven Placement................................................................................ 3-89
st
Placement and Optimization Application Options Summary ........................................ 3-90

i

eg
Summary ....................................................................................................................... 3-92

Appendix ........................................................................................................................ 3-93
R
Appendix A .................................................................................................................... 3-94

Optimization: Cell Naming Convention ........................................................................ 3-95
Appendix B .................................................................................................................... 3-96
Magnet Placement .......................................................................................................... 3-97
Synopsys 20-I-078-SSG-009 iv IC Compiler II: Block-level Implementation

Table of Contents
Performing Magnet Placement ...................................................................................... 3-98

Standalone Coarse Placement ........................................................................................ 3-99
Enhance the Placement ................................................................................................ 3-100
Appendix C .................................................................................................................. 3-101
y
Create Move Bounds.................................................................................................... 3-102
nl
Soft versus Hard Bounds ............................................................................................. 3-103
O
Appendix D .................................................................................................................. 3-104
Default Path Groups ..................................................................................................... 3-105
se
Problem with Large Violating I/O Paths ..................................................................... 3-106
Place I/Os into Separate Path Groups .......................................................................... 3-107
Separate Path Groups May Not Be Enough ................................................................. 3-108
U
Apply Path Group Weights .......................................................................................... 3-109
Appendix E .................................................................................................................. 3-110
al
Incremental Optimization with refine_opt ................................................................... 3-111
rn
Path Optimization ........................................................................................................ 3-112
Focusing refine_opt ..................................................................................................... 3-113
te
Appendix F................................................................................................................... 3-114
Net length attribute support ......................................................................................... 3-115
In
Stand-Alone Trial CTS ................................................................................................ 3-116
Categorizing Design Violations ................................................................................... 3-117
s
Enable Multiple Port Net Buffering ............................................................................. 3-118
sy
Standard Cell Spacing Rules ........................................................................................ 3-119
Creating Cell Spacing Labels and Rules ...................................................................... 3-120
op
ICG Auto-Bounds ........................................................................................................ 3-121

Appendix G .................................................................................................................. 3-122
Relative Placement....................................................................................................... 3-123
yn
What’s Special about Data Path Logic?....................................................................... 3-124

The Ideal Layout for Data Path .................................................................................... 3-125
rS
Data Path Layout using Traditional P&R Tool............................................................ 3-126

Relative Placement Group ........................................................................................... 3-127
RP Constraints ............................................................................................................. 3-128
Fo
Concurrent Placement of RP Groups ........................................................................... 3-129

Candidates for Relative Placement .............................................................................. 3-130
Physical Datapath In DC-T/G & ICC II ...................................................................... 3-131
ed
RP in DCT/G................................................................................................................ 3-132
Appendix H .................................................................................................................. 3-133
er
Placement-Based Scan Chain Re-Ordering ................................................................. 3-134

Re-ordering Chains within Same “Partition” ............................................................... 3-135
st
Example SCANDEF from Synthesis with DFT .......................................................... 3-136

i
Example: Placement with Existing Ordering............................................................... 3-137

eg
Example: Reordering Within Scan-Chains .................................................................. 3-138

Example: Reordering Within Partitions ....................................................................... 3-139
R
Synopsys 20-I-078-SSG-009 v IC Compiler II: Block-level Implementation

Table of Contents
Unit 4: NDM Cell Libraries

Agenda ............................................................................................................................. 4-1
Unit Objectives ................................................................................................................ 4-2
y
IC Compiler II Library Manager...................................................................................... 4-3
nl
IC Compiler II NDM Cell Library ................................................................................... 4-4
Cell Library Characteristics ............................................................................................. 4-5
O
Two Ways to create CLIBS ............................................................................................. 4-6
Ease of Use: Tech-Only NDM Library ............................................................................ 4-7
se
Technology File ............................................................................................................... 4-8
Read TLU+ Models ......................................................................................................... 4-9
U
Placement Sites and Symmetry ...................................................................................... 4-10
Routing Direction and Track Offset .............................................................................. 4-11
al
Track Offset Explained .................................................................................................. 4-12
rn
Tech Library Prep – icc2_lm_shell ................................................................................ 4-13
Source File Information ................................................................................................. 4-14
te
Appendix ........................................................................................................................ 4-16
In
Library Manager (icc2_lm_shell) Flow ......................................................................... 4-17
Exploration Flow: Automated Cell Library Creation .................................................... 4-18
s
PVT Configuration......................................................................................................... 4-19
Exploration Flow – Example Output ............................................................................. 4-20
sy
Retrieving Version Information ..................................................................................... 4-21

Separate Reference Libraries ......................................................................................... 4-22
op
Aggregate Reference Library ......................................................................................... 4-23

Aggregate Library – Example Script ............................................................................. 4-24
yn
Unit 5: Design Setup

rS
Agenda ............................................................................................................................. 5-1

Design Setup Objectives .................................................................................................. 5-2
Fo

Design Setup .................................................................................................................... 5-4
Create a “Container”: The Design Library ...................................................................... 5-5
ed
Technology Information .................................................................................................. 5-6

Design Library Compression ........................................................................................... 5-7
er
Reference Library Paths ................................................................................................... 5-8

Moving Design and/or Reference Libraries ..................................................................... 5-9
st
Rebind a Design Library ................................................................................................ 5-10

Read .db and .frame directly into ICC II ....................................................................... 5-11
i
eg
Library Configuration Example ..................................................................................... 5-12

Library Configuration Flow Options ............................................................................. 5-13
R
Example: Using an Updated DB .................................................................................... 5-14

Read the Netlist and Create a Design ............................................................................ 5-15
Linking ........................................................................................................................... 5-16
Load the Power Intent .................................................................................................... 5-17
Synopsys 20-I-078-SSG-009 vi IC Compiler II: Block-level Implementation

Table of Contents
Support of Golden-UPF and UPF’/UPF” Flows............................................................ 5-18

Modifying Power Intent after commit_upf .................................................................... 5-19
Load a DEF Floorplan File ............................................................................................ 5-20
Caution: Unsupported Constructs in DEF ..................................................................... 5-21
y
Load the Floorplan ......................................................................................................... 5-22
nl
Specify Unused Routing Layers .................................................................................... 5-23
O
Load Scan Chain Identification Information ................................................................. 5-24
Connect PG Pins to Supply Nets ................................................................................... 5-25
se
Enable Use of Tie-High/Low Cells................................................................................ 5-26
TIP: Design Library Packages ..................................................................................... 5-27
Usage Details – pack / unpack ....................................................................................... 5-28
U
Test for Understanding (1 of 2) ..................................................................................... 5-29
al
Summary: Design Setup ................................................................................................ 5-31
rn
Appendix ........................................................................................................................ 5-33
te
Appendix A .................................................................................................................... 5-34
ICC II Initialization Files ............................................................................................... 5-35
In
Example User’s .synopsys_icc2.setup File .................................................................... 5-36
Appendix B .................................................................................................................... 5-37
s
High Level Multi-Voltage Design Concepts ................................................................. 5-38
sy
UPF Example: Supplies and Power Domains ................................................................ 5-39
UPF Example: Power Ports and Nets ............................................................................ 5-40
op
UPF Example: Level Shifters ........................................................................................ 5-41

UPF Example: Power States and PS Table .................................................................... 5-42
yn
Unit 6: Timing Setup

rS
Agenda ............................................................................................................................. 6-1

Timing Setup Objectives.................................................................................................. 6-2
Fo
Multiple Modes and Corners ........................................................................................... 6-4

Concurrent MCMM Optimization ................................................................................... 6-5
Creating Modes, Corners and Scenarios .......................................................................... 6-6
ed
Current Corner + Current Mode ↔ Current Scenario ..................................................... 6-7

Classifying Constraints .................................................................................................... 6-8
er
Commands Listed by Classification ................................................................................ 6-9

Scenario Constraints ...................................................................................................... 6-10
st
Loading Constraints ....................................................................................................... 6-11

i
Use write_script to Separate Constraints ....................................................................... 6-12

eg
Minimize Modes and Corners with Scenario Analysis.................................................. 6-13

Check Timing Constraints ............................................................................................. 6-14
R
Reports Usually Apply to Current Scenario .................................................................. 6-15

Controlling MCMM Timing Reports............................................................................. 6-16
Controlling Scenario Analysis / Optimization ............................................................... 6-17
Examples: Modifying Scenario Status ........................................................................... 6-18
Synopsys 20-I-078-SSG-009 vii IC Compiler II: Block-level Implementation

Table of Contents
Reporting Scenario Status Settings ................................................................................ 6-19

Defining Corner PVT by Operating Condition.............................................................. 6-20
Defining PVT Directly - Recommended ....................................................................... 6-21
Reporting Library Details: report_lib ............................................................................ 6-22
y
VT Matching .................................................................................................................. 6-23
nl
Use Process Labels to Help the Matching ..................................................................... 6-24
O
Process Label Specification ........................................................................................... 6-25
Process Label Exercise .................................................................................................. 6-26
se
Reporting ALL Corners with PVT Mismatches ............................................................ 6-27
Selective Library Loading.............................................................................................. 6-28
Using Selective Library Loading ................................................................................... 6-29
U
Specify TLUplus Parasitic RC Models .......................................................................... 6-30
Restricting Cells in Specific Modules/Regions ............................................................. 6-31
al
Target Library Subset Example ..................................................................................... 6-32
rn
OCV Effects on Timing ................................................................................................ 6-33
Traditional Timing Derate Method for Modeling OCV ................................................ 6-34
te
Example: OCV Analysis with Timing Derate ............................................................... 6-35
Derate Factor in Timing Report ..................................................................................... 6-36
In
Timing Pessimism with OCV Analysis ......................................................................... 6-37
AOCV Calculates Derating Based on Depth and Distance ........................................... 6-38
s
Enabling Advanced On-Chip Variation Modeling ........................................................ 6-39
sy
Pessimism in Graph-Based Analysis (GBA) AOCV ..................................................... 6-40
Parametric On-Chip Variation Modeling of Random Variation.................................... 6-41
op
POCV Input Data: Sigma (𝜎) - Two Formats .............................................................. 6-42

POCV Path Calculation Example .................................................................................. 6-43
POCV Input Data: Distance-based Derating ................................................................. 6-44
yn
POCV Setup ................................................................................................................... 6-45

POCV Additional Setup................................................................................................. 6-46
rS
Perform a ‘Timing Sanity Check’ .................................................................................. 6-47

Additional Timing Settings ............................................................................................ 6-48
Fo

ed
Appendix ........................................................................................................................ 6-53

Appendix A .................................................................................................................... 6-54
er
Scaling Groups ............................................................................................................... 6-55

Using Scaling Groups .................................................................................................... 6-56
st
Notes on Scaling Groups ............................................................................................... 6-57

i
Appendix B .................................................................................................................... 6-58

eg
Sources of Variations ..................................................................................................... 6-59

Early/Late with Non-Gaussian Distributions ................................................................. 6-60
R
How is sigma_slack calculated? .................................................................................... 6-61

Data Path Pessimism Reduction .................................................................................... 6-62
report_timing -variation ................................................................................................. 6-63
Appendix C .................................................................................................................... 6-64
Synopsys 20-I-078-SSG-009 viii IC Compiler II: Block-level Implementation

Table of Contents
Modeling OCV Using Min/Max Libraries .................................................................... 6-65

Exercise: Constraints in OCV ....................................................................................... 6-66
Data I/O Port Constraint –max/-min Options ................................................................ 6-67
Ideal Clock Constraint –max/-min Options ................................................................... 6-68
y
nl
Unit 7: Running CTS
O
Agenda ............................................................................................................................. 7-1
se
Unit Objectives ................................................................................................................ 7-3
Clock Tree Synthesis Goal and Flows ............................................................................. 7-4
U
Comparing Classic CTS versus CCD .............................................................................. 7-5
Classic CTS and CCD Flow ............................................................................................ 7-6
al
Setup for Classic CTS and CCD Flows ........................................................................... 7-7
rn
Setup for Classic CTS and CCD Flows ........................................................................... 7-8
Is the Design Ready for CTS? ......................................................................................... 7-9
te
Clock Tree Specific Checks ........................................................................................... 7-10
Modes / Corners for CTS ............................................................................................... 7-11
In
Hold Fixing .................................................................................................................... 7-12
Minimize Hold Time Violations in Scan Paths ............................................................. 7-13
s
Clock Reconvergence Pessimism .................................................................................. 7-14
sy
Clock Reconvergence Pessimism Removal ................................................................... 7-15
Congestion-Aware Initial CTS ...................................................................................... 7-16
op
Local Skew Optimization .............................................................................................. 7-17

Enable Local Skew CTS and CTO ................................................................................ 7-18
CCD and Boundary Registers ........................................................................................ 7-19
yn
Restricting the Amount of CCD Skewing ..................................................................... 7-20

Skipping Path Groups during CCD................................................................................ 7-21
rS
Hold Criticality during CCD .......................................................................................... 7-22

Additional Settings to Consider ..................................................................................... 7-23
Classic CTS and CCD Execution .................................................................................. 7-24
Fo
Classic CTS Flow Stages ............................................................................................... 7-25

Classic CTS Flow: clock_opt vs. Atomic ...................................................................... 7-26
CCD Flow Stages........................................................................................................... 7-27
ed
Post-CTS: Post-route Clock Tree Optimization ............................................................ 7-28

CCD Power or Area Recovery ....................................................................................... 7-29
er
Enable CCD Power/Area Recovery ............................................................................... 7-30

CCD Clock Power Recovery: Leakage, Dynamic or Total ........................................... 7-31
st
Global Route Optimization (GRO) ................................................................................ 7-32

i
GRO in the Overall Flow ............................................................................................... 7-33

eg
Using Global Route Optimization ................................................................................. 7-34

Example Script ............................................................................................................... 7-35
R
Example Script ............................................................................................................... 7-36

Analyzing CTS Results: Clock QoR Report .................................................................. 7-37
Analyzing CTS Results: Clock Timing Report ............................................................. 7-38
Analysis Using the CTS GUI ......................................................................................... 7-39
Synopsys 20-I-078-SSG-009 ix IC Compiler II: Block-level Implementation

Table of Contents
GUI Analysis: Clock Tree Levelized Graph .................................................................. 7-40

GUI Analysis: Clock Tree Levelized Graph .................................................................. 7-41
Pre-CTS: Ideal Clock Latencies..................................................................................... 7-42
Post-CTS: Propagated Clock Sources / Updated Latencies ........................................... 7-43
y
Post-CTS: Update Latencies in ALL Scenarios............................................................. 7-44
nl
CAUTION: Propagated Clock Objects .......................................................................... 7-45
O
Auto-Update with Virtual Clocks .................................................................................. 7-46
Limiting Auto-Latency Update ...................................................................................... 7-47
se
Limiting Auto-Latency Update ...................................................................................... 7-48
CCD during place_opt ................................................................................................... 7-49
Ideal Clock Adjustment during place_opt ..................................................................... 7-50
U
place_opt CCD with Trial CTS...................................................................................... 7-51
Enabling and Controlling place_opt CCD ..................................................................... 7-52
al
rn
Appendix ........................................................................................................................ 7-54
CCD: Timing-Driven Clock Tree Creation ................................................................... 7-55
te
CCD: Clock Tree Latency Refinement .......................................................................... 7-56
CAUTION: Propagated Clock Objects .......................................................................... 7-57
In
Solutions: Propagated Clock Objects............................................................................. 7-58
Independent I/O Clock Latencies (1 of 2)...................................................................... 7-59
s
Independent I/O Clock Latencies (2 of 2)...................................................................... 7-60
sy
Unit 8: Setting Up CTS

op
Agenda ............................................................................................................................. 8-1

yn
Unit Objectives ................................................................................................................ 8-3

Where Does the Clock Tree Begin and End? .................................................................. 8-5
rS
Balance Points: Sink and Ignore Pins .............................................................................. 8-6

Generated and Gated Clocks ............................................................................................ 8-7
User-defined or Explicit Sink Pins .................................................................................. 8-8
Fo
Defining an Explicit Sink Pin .......................................................................................... 8-9

Defining an Explicit Sink Pin With Delay..................................................................... 8-10
Defining an Explicit Ignore (or Exclude) Pin ................................................................ 8-11
ed
Defining a Clock Skew Group ....................................................................................... 8-12

Exceptions – Mode Specific .......................................................................................... 8-13
er
Auto Exceptions ............................................................................................................. 8-14

Controlling Auto Exceptions ......................................................................................... 8-15
st
Auto Exceptions: Scaling Delay Requirements ............................................................. 8-16

i
How Can You Check Exceptions? ................................................................................. 8-17

eg
Default Clock Tree Targets ............................................................................................ 8-18

CCD: Skew and Latency Considerations ....................................................................... 8-19
R
User-Defined Clock Tree Targets .................................................................................. 8-20

Automatically-Derived Balance Points.......................................................................... 8-21
Control CTS Cell Selection ........................................................................................... 8-22
Existing Cells on Clock Tree ......................................................................................... 8-23
Synopsys 20-I-078-SSG-009 x IC Compiler II: Block-level Implementation

Table of Contents
No Inter-Clock Skew Balancing by Default .................................................................. 8-24

Create Balancing Groups ............................................................................................... 8-25
Balancing Occurs During clock_opt .............................................................................. 8-26
Inter-clock Balancing is Important for CCD ................................................................. 8-27
y
Summary: Clock Tree Balancing Setup ......................................................................... 8-28
nl
Pre-Existing Clock Buffers Are Removed ..................................................................... 8-30
O
Preserving Pre-Existing Clock Trees ............................................................................. 8-31
Propagation Limitation of dont_touch on Clock Networks ........................................... 8-32
se
Preserving Pre-Existing Cells ........................................................................................ 8-33
Preserving Pre-Existing Cells – Allow Sizing ............................................................... 8-34
Cells that Should Not Be Moved ................................................................................... 8-35
U
Clock Tree Removal Behavior....................................................................................... 8-36
Non-Default Routing Rules ........................................................................................... 8-38
al
Non-Default Via Rules .................................................................................................. 8-39
rn
Defining Non-Default Routing and Via Rules............................................................... 8-40
Example Technology File .............................................................................................. 8-41
te
Defining Via NDRs with -vias ....................................................................................... 8-42
Applying Non-Default Routing Rules ........................................................................... 8-43
In
NDRs on Clock Nets...................................................................................................... 8-44
Different NDRs for Root, Internal, Sink Nets ............................................................... 8-45
s
Classification of Root, Internal, Sink............................................................................. 8-46
sy
Relaxing Spacing Requirements .................................................................................... 8-47
Clock Crosstalk Prevention through NDR Promotion ................................................... 8-48
op
Are all Clock Drivers and Loads Specified?.................................................................. 8-50

Example: Reporting Clock Port Constraints .................................................................. 8-51
Defining CTS-Specific DRC Values ............................................................................. 8-52
yn
Remove Skew from Uncertainty .................................................................................... 8-53

Uncertainty on Output Ports .......................................................................................... 8-54
rS
Reporting Settings Summary ......................................................................................... 8-55

Appendix ........................................................................................................................ 8-57
Fo
Post-CTS Skew on Outputs (1 of 2) .............................................................................. 8-58

Post-CTS Skew on Outputs (2 of 2) .............................................................................. 8-59
Reduce Electromigration ............................................................................................... 8-60
ed
Clock Cell Spacing ........................................................................................................ 8-61

er
Unit 9: Routing & Optimization

st
Agenda ............................................................................................................................. 9-1

i

eg
Unit Objectives ................................................................................................................ 9-3

Routing Phase Goal.......................................................................................................... 9-4
R
ICC II Routing Flow ........................................................................................................ 9-5

Recommended Routing Flow .......................................................................................... 9-6
Route Operations: Global Route (GR) ............................................................................. 9-7
Route Operations: Global Route Summary ..................................................................... 9-8
Synopsys 20-I-078-SSG-009 xi IC Compiler II: Block-level Implementation

Table of Contents
Route Operations: Track Assignment .............................................................................. 9-9

Route Operations: Detail Routing .................................................................................. 9-10
Pre-Routing Checks and Setup ..................................................................................... 9-11
Check for Routing “Readiness” ..................................................................................... 9-12
y
Routability Check .......................................................................................................... 9-13
nl
Secondary PG Pin Connections ..................................................................................... 9-14
O
NDRs for Secondary PG Routing .................................................................................. 9-15
Inserting Redundant Vias on Signal Nets ..................................................................... 9-16
se
Redundant Vias and Small Geometries ......................................................................... 9-17
Enable Wire and Via Optimization ............................................................................... 9-18
Concurrent Antenna Fixing: Layer Jumping ................................................................. 9-19
U
Controlling Router Behavior: Routing Guides .............................................................. 9-20
Preventing Routing: Routing Blockages ........................................................................ 9-21
al
Controlling Scope for Rerouting .................................................................................... 9-22
rn
Timing Driven Routing .................................................................................................. 9-23
Crosstalk Analysis ......................................................................................................... 9-24
te
Crosstalk Prevention ...................................................................................................... 9-25
Static Noise .................................................................................................................... 9-26
In
Align ICCII and PrimeTime Settings ............................................................................ 9-27
s
sy
Routing and DRC Fixing ............................................................................................... 9-30
Route the Signal Nets..................................................................................................... 9-31
op
Detail Route Iterations ................................................................................................... 9-32

Check Zroute DRC Violations ....................................................................................... 9-33
Viewing Cell Internal Structures ................................................................................... 9-34
yn
Layout versus Schematic Check .................................................................................... 9-35

Detail Routing Loops ..................................................................................................... 9-36
rS
Change Routing Options ................................................................................................ 9-37

Rerouting Problematic Nets ........................................................................................... 9-38
Optimization and Reroute .............................................................................................. 9-39
Fo
Post Route Full Optimization......................................................................................... 9-40

Post Route Optimizations: Power and CTO .................................................................. 9-41
Post Route Optimizations: CCD .................................................................................... 9-42
ed
Using PrimeTime Delay Calculation ............................................................................. 9-43

Using the PrimeTime Delay Calculator during route_opt ............................................. 9-44
er
StarRC InDesign ............................................................................................................ 9-45

Faster QoR Convergence ............................................................................................... 9-46
st
Recommended route_opt Flow ...................................................................................... 9-47

i
ECO Fusion.................................................................................................................... 9-48

eg
ECO Fusion Workflow .................................................................................................. 9-49

Example Flow ................................................................................................................ 9-50
R
Notes on ECO Fusion .................................................................................................... 9-51

Unit Summary ................................................................................................................ 9-52
Appendix ........................................................................................................................ 9-53
Notes on Repeatability ................................................................................................... 9-54
Synopsys 20-I-078-SSG-009 xii IC Compiler II: Block-level Implementation

Table of Contents
Enabling Post-Route Redundant Via Insertion .............................................................. 9-55

Custom “Via Mapping” Table ....................................................................................... 9-56
Example: Prioritizing Vias for DFM ............................................................................. 9-57
Concurrent Soft-Rule-Based Via Optimization ............................................................. 9-58
y
Concurrent Hard-Rule-Based Via Optimization ............................................................ 9-59
nl
Random Particle Defects................................................................................................ 9-60
O
Reduce Short/Open Critical Area .................................................................................. 9-61
Routing Blockages – Comparison to IC Compiler ........................................................ 9-62
se
Routing Blockages (Continued) ..................................................................................... 9-63
Antenna Violations ........................................................................................................ 9-64
Fixing Antenna Violation by Layer Jumping ................................................................ 9-65
U
al
Unit 10: Top Level Implementation
rn
Agenda ........................................................................................................................... 10-1
Objectives ...................................................................................................................... 10-2
te
Top Level Implementation ............................................................................................. 10-3
Using Completely Implemented Blocks ........................................................................ 10-4
In
Parallel Blocks and Top Implementation ....................................................................... 10-5
Extracted Timing Model (ETM) .................................................................................... 10-6
s
Abstract View ................................................................................................................ 10-7
sy
Creating an Abstract ...................................................................................................... 10-8
Frame View .................................................................................................................... 10-9
op
Keep Everything in the Abstract .................................................................................. 10-10

At the Top-Level (1 of 2) ............................................................................................. 10-11
At the Top-Level (2 of 2) ............................................................................................. 10-12
yn
Check the Design ......................................................................................................... 10-13

Implement the Top ....................................................................................................... 10-14
rS
Unit Objectives Summary ............................................................................................ 10-15

Appendix ...................................................................................................................... 10-16
Clock Tree Modeling in Abstracts ............................................................................... 10-17
Fo
Attributes to Identify the Hierarchy Owner ................................................................. 10-18

ed
Unit 11: Signoff

Agenda ........................................................................................................................... 11-1
er
General IC Compiler II Flow ......................................................................................... 11-2

Signoff / DFM ............................................................................................................... 11-3
st
Signoff / DFM Tasks .................................................................................................... 11-4

i
Functional ECOs ............................................................................................................ 11-5

eg
Pre vs. Post Tape-out ECO ............................................................................................ 11-6

Unconstrained (Pre Tape-out) ECO Flow...................................................................... 11-7
R
Pre-Tapeout ECO Or Unconstrained Flow .................................................................... 11-8

ECO Placement: place_eco_cells .................................................................................. 11-9
Unconstrained Flow ..................................................................................................... 11-10
Freeze Silicon ECO Flow ............................................................................................ 11-11
Synopsys 20-I-078-SSG-009 xiii IC Compiler II: Block-level Implementation

Table of Contents
Map ECO Cells to Spare Cells..................................................................................... 11-12

Timing ECOs ............................................................................................................... 11-13
PrimeTime Signoff-driven Physically Aware ECO Flow ........................................... 11-14
Export Data from ICC II for PrimeTime ..................................................................... 11-15
y
Example StarRC Command File .................................................................................. 11-16
nl
PrimeTime ECO Guidance Flow ................................................................................. 11-17
O
Example Physically Aware ECO in PT (1 of 2) .......................................................... 11-18
Example Physically Aware ECO in PT (2 of 2) .......................................................... 11-19
se
Apply PT ECOs in ICC II using Minimum Physical Impact....................................... 11-20
Filler Cell Insertion ...................................................................................................... 11-21
Standard Cell Fillers and Metal Filling........................................................................ 11-22
U
Filler Cell Insertion ...................................................................................................... 11-23
Example Script ............................................................................................................. 11-24
al
Signoff DRC ................................................................................................................ 11-25
rn
In-Design Signoff DRC Checking and Fixing ............................................................. 11-26
Signoff DRC using IC Validator.................................................................................. 11-27
te
ICV Usage Examples ................................................................................................... 11-28
Viewing Error Data in the Error Browser .................................................................... 11-29
In
Filtering Error Data ...................................................................................................... 11-30
Metal Filling with ICV................................................................................................. 11-31
s
Metal Fill Insertion ...................................................................................................... 11-32
sy
Viewing and Editing Metal Fill ................................................................................... 11-33
Example Script ............................................................................................................. 11-34
op
Unit Summary .............................................................................................................. 11-35

yn
Unit CS: Customer Support

Synopsys Support Resources ....................................................................................... CS-2
rS
SolvNet Online Support ................................................................................................ CS-3

SolvNet Registration ..................................................................................................... CS-4
Support Center .............................................................................................................. CS-5
Fo
Other Technical Sources ............................................................................................... CS-6

Summary: Getting Support ........................................................................................... CS-7
ed
er
ist
eg
R
Synopsys 20-I-078-SSG-009 xiv IC Compiler II: Block-level Implementation

y
nl
O
se
U
al
rn
te
In
© 2019 Synopsys, Inc. All Rights Reserved Synopsys 20-I-078-SSG-009
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Introduction © 2019 Synopsys, Inc. All Rights Reserved. i-1

IC Compiler II: Block-level Implementation Workshop by Sridhara Sree Rame Gowda on 3/7/2019 9:53:08 PM PST.
Document downloaded cesdocs$!2019
Facilities
y
Building Hours Meals
nl
O
Emergency EXIT Smoking
se
U
Restrooms Recycling
al
rn
Please turn off or silence your cell phone
te
In
s i- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Workshop Overview
y
nl
O
 This workshop will cover the entire block-level implementation flow:
se
 Design & Timing Setup
Floorplanning (introduction)
U

 Placement and Optimization
al
 Clock Tree Synthesis and Optimization
rn
 Routing and Post-Route Optimization, including InDesign PrimeTime and StarRC
Top-level Implementation, Signoff DRC, fill and ECO
te

In
s i- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Workshop Target Audience
y
ASIC, back-end, or layout designers who will be
nl
using IC Compiler II to perform placement, CTS
O
and routing on block-level designs
se
U
al
rn
te
In
s i- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Workshop Prerequisite Knowledge
 Prior knowledge of IC Compiler or IC Compiler II is not needed
y
nl
 Knowledge of general standard cell-based placement, CTS and routing
O
concepts and terms is helpful
se
 An understanding of basic digital ASIC design concepts is assumed,
U
including:
al
 Combinational and sequential logic functionality
rn
 Setup and hold timing
te
In
s i- 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Introductions
 Name
y
nl
 Company
O
 Job Responsibilities
se
 Relevant Experience
U
 Main Goal(s) and Expectations for this Course
al
rn
te
In
s i- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
i Introduction and GUI Lab
O
1 Objects, Blocks and App Options
se
U
2 Floorplanning
al
3
rn
Placement & Optimization
te
In
s i- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
4 NDM Cell Libraries
O
5 Design Setup
se
U
6 Timing Setup
al
7
rn
Running CTS
te
In
s i- 8
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
8 Setting Up CTS
nl
O
9 Routing & Optimization
se
10 Top Level Implementation
U
al
11 Signoff
rn
CS Customer Support
te
In
s i- 9
sy
op
yn
rS
Fo
ed
er
i st
eg
R

IC Compiler II
 To maximize the capabilities and performance of IC Compiler II,

we recommend that you start with new ICC II Reference Methodology
y
(RM) scripts: solvnet.synopsys.com  Methodology
nl
Many things that you are used to doing in IC Compiler
O

are no longer valid in IC Compiler II
se
 On the other hand, many concepts / use models are carried over
to IC Compiler II
U
 Similar commands can have subtle or big differences!
al
 Always consult the man page
rn
te
In
s i- 10
sy
RM: https://solvnet.synopsys.com/rmgen
op
yn
rS
Fo
ed
er
i st
eg
R

IC Compiler II GUI
Command Search
y
Menus Example: List menus, commands
Commands and options related to “place_opt”
nl
You can also run the commands
from right here or pull up a dialog for
O
setting application options.
se
U
al
Layout Visibility and
view Selection
rn
window control
te
In
s i- 11
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Task Assistant
F4 launches the
Task Assistant
y
nl
O
se
U
al
rn
te
Settings and commands available in one convenient place
In
based on the recommended flow for the task at hand
s i- 12
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Built-In Script Editor
y
nl
O
# This is a script
source $SETUP_FILE
read_verilog ../design_data/my_chip.v
se
U
al
 Create scripts interactively
rn
 Execute entire script or a selection
te
 Save script to a file
In
s i- 13
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Lab 0 – IC Compiler II GUI
y
 Navigate the IC Compiler II layout view
nl
 Control object and layer visibility
O
 Select and query layout objects
se
 Control the view level
U
 Rearrange panels in the GUI
Use the Recent menu and favorites
al

rn
 Use help and man to get help and additional
information about commands and options
te
In
s i- 14
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
O
se
U
2 Floorplanning
al
3
rn
te
In
Synopsys 20-I-078-SSG-009 © 2019 Synopsys, Inc. All Rights Reserved
s 1- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Objects, Blocks and App Options © 2019 Synopsys, Inc. All Rights Reserved. 1-1
Objectives
y
nl
After completing this unit, you should be able to:
O
 Query objects and retrieve design information using attributes
se
 Perform block/library manipulation operations
(open, save, rename, copy)
U
 Query and set application options to control ICC II’s behavior
al
rn
te
In
s 1- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Objects
 ICC II contains many different object classes:

design, port, cell, pin, net …
y
The get_* commands are used to find objects by name:
nl

O
get_nets *_clk
{ate_clk net_sdram_clk net_sys_2x_clk net_sys_clk sdram_clk sys_2x_clk}
se
 To list all available object classes (or types):
U
help_attributes
al
block bound bound_shape
budget_clock budget_path_type budget_pin_constraint
rn
budget_pin_data budget_segment bundle
cell clock clock_balance_group
clock_group clock_group_group clock_path
te
constraint_group core_area corner
...
In
 Can also use: get_defined_attributes -return_classes
s 1- 3
sy
ICC II provides a full set of object classes and associated Tcl commands to create, remove, query, and
modify all primary design data
op
• Logical objects, such as ports, cells, and nets

• Timing data, such as modes and corners
• Physical objects, such as shapes, vias, tracks, and blockages
yn
• Reference library objects, such as libraries, library cells, and library pins
rS
Most design objects have basic commands for object creation, removal, and querying
• To create an object: create_<object_class>
Fo
• To remove an object: remove_<object_class>

• To create a collection of objects: get_<object_class>
• To move a collection of objects: move_objects
ed
• To mirror a collection of objects: flip_objects

• To rotate a collection of objects: rotate_objects
er
Some design objects also have specialized commands, such as add_to_bound, set_lib_cell_purpose,
st
connect_net
i
eg
R
Querying Objects Associated with Objects
You can find objects associated with, or connected to, specific
y

objects by using the -of_objects option:
nl
 For example, you can find the cells associated with other cells, or with
O
pins, nets, bounds, voltage areas, voltage area shapes, etc.:
se
get_cells –of_objects [get_nets net_sdram_clk]
U
{snps_OCC_controller I_SDRAM_TOP}
al
See the man page of each get_* command for detailed information
rn

about the supported relationships and associations
te
In
s 1- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Querying Objects / Hierarchy
 Object queries are performed using a logical context

 Object names must match the logical hierarchy name attribute
y
get_cells I_SDRAM_TOP/I_SDRAM_IF/sd_mux* or
nl
get_cells */I_SDRAM_IF/sd_mux*
O
{I_SDRAM_TOP/I_SDRAM_IF/sd_mux_0 I_SDRAM_TOP/I_SDRAM_IF/sd_mux_1 ...}
get_cells *I_SDRAM_IF/sd_mux*
se
Warning: No cell objects matched '*I_SDRAM_IF/sd_mux*' (SEL-004)
U
 With get_flat_cells hierarchy is optional
al
get_flat_cells *I_SDRAM_IF*sd_mux*
{I_SDRAM_TOP/I_SDRAM_IF/sd_mux_0 I_SDRAM_TOP/I_SDRAM_IF/sd_mux_1 ...}
rn
 The *flat* commands use the full_name of objects for searching
te
 Also available: get_flat_nets, get_flat_pins
In
 You can match using regular expressions with the -regexp option
s 1- 5
sy
The get_flat_* commands were introduced with 2015.06-SP4. The get_flat_cells command returns leaf cells
(except physical-only cells) with the full_name attribute matching the pattern:
get_flat_cells *mux* (to include physical-only cells use -all)
op
leaf_clk_mux
HIER1/leaf_mux_sel_reg[0] .. [3]
HIER1/HIER2/leaf_mux_dq
yn
HIER1/HIER2_mux/U1 .. U4
rS
get_cells -hierarchical returns leaf and hierarchy cells with the name attribute matching the pattern, at all
levels of hierarchy: get_cells -hierarchical *mux*
leaf_clk_mux
Fo
HIER1/HIER2_mux
ed
To return only leaf cells: get_cells -hierarchical *mux* -filter !is_hierarchical

leaf_clk_mux
er
st
To return cells that are at a particular hierarchy:

i
eg
get_cells HIER1/*mux*
HIER1/HIER2_mux
R
To return cells that are at or below a particular hierarchy:

get_flat_cells HIER1*mux*
HIER1/HIER2_mux/U1 .. U4
Querying Objects by Location
icc2_shell> get_cells –at {10 0}

I5 {10,10}
y
{I4}
nl
icc2_shell> get_cells –within {{0 0} {10 10}}
{I1}
O
I6
icc2_shell> get_cells –touching {{0 0} {10 10}} I2 I1
se
{I1 I2}
icc2_shell> get_cells –intersect {{0 0} {10 10}} {0,0}
I4
U
{I2 I3 I4 I5} I3
al
rn
 Many get_<object> commands support the location query options
te
 Regions can be rectangular or rectilinear polygons
In
s 1- 6
sy
The behavior of the -within and the -intersect options matches ICC behavior.
get_<object> query-by-location options:
-at: Returns objects at the specified point
op
-within: Returns objects that are strictly inside the queried-region; Does not include objects
that are touching the queried-region from the inside
yn
-touching: Returns objects that are strictly inside the queried-region, including objects that are
touching the queried-region from the inside (superset of -within).
rS
-intersect: Returns objects that are overlapping with queried-region as well as objects that
are touching the queried-region from the inside or the outside.
Fo
There is also an alternative command in ICC2 that provides similar functionality:

get_objects_by_location –class <object_type>
ed
• This command has different behavior for -within and -intersect, by default
• Use the application option design.enable_icc_region_query to make it match the behavior
er
described on the main slide

st
For more details, please review the man page.

i
eg
R
Attributes of Objects
 Each object has a set of related attributes (with values)
 For example, a net has the following attributes:
y
 full_name
nl
 net_type
 route_length, etc.
O
 To list all application-defined attributes (and user-defined, if any)
se
of a specific object class:
U
list_attributes -application -class net
Attribute Name Object Type Properties Constraints
al
----------------------------------------------------------------------------------------
...
dont_touch net boolean A,S (Application-defined; Settable)
rn
full_name net string A
is_bbt_object net boolean A
is_global net boolean A
is_ideal net boolean A
te
...
max_layer net collection A,S
max_layer_mode net string A,S allow_pin_connection, hard, soft, unknown
In
...
s 1- 7
sy
Use get_defined_attributes to get a TCL list of the attributes (useful for scripting purposes).
op
To learn about attributes of a specific class:

man <class>_attributes, for example:
yn
icc2_shell> man net_attributes

net_attributes : Description of the predefined attributes for nets.
rS
DESCRIPTION
Attributes are properties assigned to objects such as pins, cells and nets.
Definitions for net attributes are provided in the subsections that follow.
Fo
Attributes are read-only unless marked as settable. Read-only attributes are

informational, and you cannot set its value. A settable attribute can be modified
with the set_attribute command.
ed
To determine the value of an attribute, use the get_attribute command. To see a

er
list of all attributes available for a class of objects use

the list_attributes -application command.
st
Net Attributes
base_name
i
A string attribute for the name of a net. This name does not include a
eg
the instance path prefix.

full_name
A string attribute for the name of a net. This name includes a prefix
R
for the instance path to this net.

is_global
A Boolean attribute. Possible values are "true" and "false". Global
nets are those tied to logic 0 and logic 1.
Retrieving and Setting Attribute Values
 To retrieve an attribute value of an object:
y
get_attribute object_list attribute_name
nl
# For example:
O
get_attribute [get_cells I_RAM_3] physical_status
se
placed
U
 To apply an attribute value on objects:
al
rn
set_attribute object_list attribute_name attribute_value
te
# For example:
set_attribute [get_cells I_RAM_3] physical_status fixed
In
s 1- 8
sy
Alternatively, you can use the following syntax for get_/set_attribute:
get_attribute –objects [get_cells I_RAM_3] –name physical_status
set_attribute –objects [get_cells I_RAM_3] –name physical_status –value fixed
op
yn
rS
Fo
ed
er
i st
eg
R
Reporting Attributes of Objects

To generate a list of attributes and values of a currently selected object:
report_attributes -application [get_selection]
y
M2 route (shape) selected in GUI
nl
Design Object Type Attribute Name Value
--------------------------------------------------------------------------------
ORCA_TOP PATH_13_658 rect bbox {306.0320 0.0000}
O
{306.2240 596.9040}
ORCA_TOP
Attribute value can PATH_13_658
be a collection string design_name ORCA_TOP
…
(example on next page) PATH_13_658
se
ORCA_TOP boolean is_via_ladder false
ORCA_TOP PATH_13_658 collection layer M2
ORCA_TOP PATH_13_658 string layer_name M2
…
U
al
Use the -compact option to improve readability of long object names
rn
report_attributes -compact -app [get_pins I_BLENDER_1/shift_reg[9][3]/D]
te
--------------------------------------------------------------------------------
ORCA_TOP I_BLEN...][3]/D string activity_type propagated
In
ORCA_TOP I_BLEN...][3]/D string actual_related_clock SYS_CLK
ORCA_TOP I_BLEN...][3]/D string direction
s in 1- 9
sy
Note: The above report_attributes command is similar to doing an object query in the GUI,
except that the GUI query only lists the attribute name and value, not the other columns, e.g. type.
op
yn
rS
Fo
ed
er
i st
eg
R
Accessing Cascaded Attributes

 Some object attributes have “sub-attributes”
 Called cascaded attributes
For example: The layer attribute of a shape object (e.g. M2 route)
y

nl
 To generate an attribute report of a collection attribute:
O
report_attributes -application \
[get_attribute [get_selection] layer]
se
U
-------------------------------------------------------------------------
...
ORCA_TOP M2 string pattern twelldot
al
ORCA_TOP M2 float pitch 0.152000
ORCA_TOP M2 string purpose_name drawing
rn
 To access the cascaded pitch attribute directly:
te
get_attribute [get_selection] layer.pitch
In
0.152000
s 1- 10
sy
Two (and more) level attribute query is supported:
icc2_shell> get_attribute [get_cells U6 ] ref_block.lib.voltage_unit
1.00V
op
yn
rS
Fo
ed
er
i st
eg
R
Blocks and Design Libraries
 A block is the container of design data
y
 read_verilog creates a block for the Verilog netlist
nl
 The basic block operation commands are named *_block
O
 E.g. open_block, save_block
se
 A design library stores blocks, together with other library-level
U
data such as technology data
The basic library operation commands are named *_lib
al

 For example, create_lib, open_lib, save_lib
rn
te
In
s 1- 11
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Save the Design Library and Block
 It is good practice to save the design after each key design phase,
for example: design setup, placement, etc.
y
nl
 Using a block label is a convenient way of doing this:
O
save_block -as ORCA/init_design
Optional:
se
Block label
 Saves the design library to disk (if not previously done
U
with save_lib) and the block to a new name
al
 By default, save_block -as saves a new copy of a block to disk,
but does not change the name of the block in memory *
rn
 Blocks with the same block name but different labels are independent
te
In
s 1- 12
sy
Using the block label to name a newer version of the block, instead of changing the block name itself (e.g.
ORCA/init_design instead of ORCA_init_design), is very convenient for top-level integration: The
top-level design, which references the block you are designing, can continue referencing the sub-block ORCA,
op
even if you save the block with different labels.

yn
Using the above method, at the end of the physical design flow, a block will have many labels (for example:
init_design, floorplan, placed, cts, routed). To specify which label should be used for the
rS
ORCA reference when it is instantiated in the top-level design:

change_abstract -reference ORCA -label routed
Fo
*) To rename the block in memory before saving it to disk set the following application option:
set_app_options –list {design.morph_on_save_as true}
ed
• Does not rename the block data that is already on-disk

• Does not rename the block in memory if the block being saved is instantiated in other blocks in memory
er
or the block is saved into a different library

• Allows you to save a block to a new name and continue the flow with the newly saved block with a single
st
save_block -as command

In IC Compiler, you would have to save the cell to another name, then close the current cell, then open the
i
eg
new cell.
R
Copying then Saving

Use the following method to create a copy of the block to a new name,
then save it after optimization (RM method)
y
open_lib ORCA_LIB.dlib
nl
copy_block -from ORCA/init_design \
O
-to ORCA/place_opt
# Copied block is automatically opened, so open_block is not needed, but it is
# not automatically the current_block; There is no current_block at this point:
se
current_block ORCA/place_opt
...
U
place_opt
...
al
save_block
rn
exit
te
copy_block copies into memory, by default.
Set design.on_disk_operation to true to copy to disk.
In
See notes below for an example of copying to another library
s 1- 13
sy
After copying, you can list the available blocks, as follows:
icc2_shell> current_block ORCA/place_opt
{ORCA_LIB.dlib:ORCA/place_opt.design}
op
icc2_shell> list_blocks
Lib ORCA_LIB.dlib /remote/..../ORCA_LIB.dlib tech current
yn
* 0 ORCA/place_opt.design Jul-10-11:57 current

- 0 ORCA/init_design.design Jun-18-08:57
rS
Newly-created or modified open blocks are marked with a "*". Unmodified or saved open blocks are
marked with a "+". Unopened blocks are marked with a "-". Designs are tagged with their modification date
Fo
or last saved date. The current block is tagged "current". Lib cell blocks are tagged "lib_cell".
You can also copy a block to another library:

ed
% icc2_shell
copy_lib -no_designs -from_lib ORCA_LIB.dlib –to_lib BACKUP.dlib
er
copy_block -from_block ORCA_LIB.dlib:ORCA/place_opt \
st
-to_block BACKUP.dlib:ORCA/place_opt
save_lib BACKUP.dlib
i
eg
current_block BACKUP.dlib:ORCA/place_opt
R
Application Options
 Application Options control the behavior and features of

IC Compiler II’s commands
y
nl
O
 For example, the application option
place_opt.flow.do_spg
se
controls whether the command place_opt takes SPG placement into
account or not
U
al
 Application options use the following naming convention:
rn
category.sub_category.option_name
te
 The sub_category field is optional
In
s 1- 14
sy
category is the name of the engine affected by the application option, such as place, cts, and route.
Some application option categories have subcategories to further refine the area affected by the application
option. For example, the route category has the following subcategories: common, detail, global,
op
and track
yn
rS
Fo
ed
er
i st
eg
R
Finding / Reporting Application Options
To find the application options for a specific engine, use

report_app_options or get_app_options
y
nl
Timing-related application options start with time
O

To report all timing-related application options, use
se
icc2_shell> report_app_options time.*
U
 List all application options with changed (non-default) values:
al
icc2_shell> report_app_options –non_default
rn
te
In
s 1- 15
sy
Here is an example report_app_options output:

op
Name Type Value User-default System-default Scope

------------------------------------------- ------ ------ -------------- ----------------------------- --------
time.all_clocks_propagated bool -- -- false block
yn
time.aocvm_analysis_mode enum -- -- separate_launch_capture_depth block

time.aocvm_enable_analysis bool -- -- false block
time.aocvm_enable_clock_network_only bool -- -- false block
rS
time.aocvm_enable_single_path_metrics bool -- -- false block

time.case_analysis_propagate_through_icg bool -- -- false block
time.case_analysis_sequential_propagation enum -- -- never block
time.clock_gating_propagate_enable bool -- -- true block
Fo
...
get_app_options will simply list the application options:

ed
icc2_shell> get_app_options route.global.*

er
route.global.connect_pins_outside_routing_corridor route.global.crosstalk_driven
route.global.double_pattern_utilization_by_layer_name route.global.effort_level
route.global.exclude_blocked_gcells_from_congestion_report route.global.extra_blocked_layer_utilization_reduction
st
route.global.force_full_effort route.global.macro_boundary_track_utilization route.global.macro_boundary_width

route.global.macro_corner_track_utilization route.global.timing_driven route.global.timing_driven_effort_level
route.global.voltage_area_corner_track_utilization
i
eg
write_script –include app_options creates a directory called wscript in the current

working directory. This includes, among others, a file called design.tcl, which contains all non-default
R
block-scoped application option settings. This file can be edited and then sourced, as needed. There is
currently no simple way to write out non-default global-scoped application option settings in a script. Block
versus global scope will be explained in upcoming pages.
Setting Application Options
There are several ways to set an application option
y
set_app_options \
nl
–name time.remove_clock_reconvergence_pessimism \
–value true
O
set_app_options –list {
se
time.remove_clock_reconvergence_pessimism true
time.aocvm_enable_analysis true }
U
set_app_options –category time –list {
remove_clock_reconvergence_pessimism true
al
aocvm_enable_analysis true }
rn
# Query the value:
get_app_option_value \
te
-name time.remove_clock_reconvergence_pessimism
true
In
s 1- 16
sy
The following commands are available for application option manipulation:
• Use set_app_options to set application options, either on the current block or the global scope
• Use reset_app_options to reset application options to the unset status
op
• Use get_app_options to get the set of application options for specific categories or subcategories based
on a user-specified pattern
yn
• Use report_app_options to report the application options that match a specified pattern
• Use get_app_option_value to return the current value of an application option in the block or global
rS
scope, its default value, or the detailed information about the application option
Fo
ed
er
i st
eg
R
Or Use the GUI
y
nl
O
se
U
Edit the value
right here
al
rn
te
In
s 1- 17
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Scope of Application Options
 Application options have either a block scope or a global scope

 The scope cannot be changed by the user
y
The source column shows
 To find the scope of an application option: where this option was set
nl
O
icc2_shell> report_app_options
Name Type Value User-default System-default Scope Status Source
se
--------------------------------------------------- ------- ----- ------------ -------------- -------- ------ -------------
...
custom.route.via_allow_offset bool -- -- false block normal
...
U
custom.route.via_redundant_effort_level enum {} {} high block normal
custom.route.via_strictly_follow_pref_orientation bool -- -- false block normal
design.bus_delimiters enum -- -- [] block normal
design.eco_restrictions bool -- -- false global normal
al
design.edit_read_only_libs bool -- -- true global normal
design.name_expansion_delimiters enum -- -- () block normal
rn
...
place_opt.flow.optimize_layers enum false {} true block normal /path…/pl.tcl:21
...
mv.incomplete_upf.missing_va enum {} {} off block deprecated
te
...
place.rp.allow_non_rp_cells bool -- -- -- block obsolete
...
In
Only block scoped values
are saved with the block s 1- 18
sy
report_app_options –global lists only global-scoped application options.
report_app_options –block [current_block] lists only block-scoped application options.
report_app_options –non_default lists application options which have a user-defined value that is
op
different than the system-default.

yn
Regarding the Status column:

Instead of normal, this can also be “deprecated” or “obsolete”.
rS
deprecated means that the application option is still functional, but will be removed in a future release.
If you set such an option, you will get a Warning:
Fo
Warning: application option <xyz> is deprecated and scheduled for removal in a

future release. See the man page for this application option for migration
assistance. (NDMUI-441)
ed
obsolete means that the option is not used any longer, and will have no effect. It is still reported so you can
find an alternative setting and update your scripts.
If you set such an option, you will get an Error:
er
Error: application option <xyz> is obsolete. See the man page for this
st
app_option for migration assistance. (NDMUI-439)

i
eg
R
Block-Scoped Application Options
 Block-scoped application options apply to the current block, and are

saved with the block
y
Block value applied with: set_app_options –list|-name ...
nl

Many block-scoped app options have a system default value
O

 Applies to all blocks loaded in the current tool session
se
 Block value overrides system default value
U
 While it is possible to override the system default with a user default
al
value, this is not recommended
rn
 Applied with: set_app_options –as_user_default –list|-name ...
Since there is no practical advantage of doing this, and the setting is not saved
te

with the block, this is not recommended – apply block value(s) instead
In
s 1- 19
sy
In a design with physical hierarchy, use set_app_options -block (only for block-scoped application
options) to specify which block to apply the value to. If -block is not used the application option value is
op
applied to the current block.
The block value of a block-scoped application variable can be removed by:

yn
reset_app_options <app_option_name>
rS
The user-default value of a block-scoped application variable can be removed by:

reset_app_options –user_default <app_option_name>
Fo
Note: For the special sub-set of application options, time.port_* (for example
time.port_slew_derate_from_library), their user-default value is set to match the corresponding
ed
value defined in the technology library. This commonly happens when the design library is first created, at
which time the technology library is also loaded, for example:
er
create_lib DESIGN_LIB -use_technology_lib TECH_LIB_FILE -ref_libs REF_LIBS.

The user can override any technology file value with set_app_options –as_user_default.
i st
eg
R
Global-Scoped Application Options
 Global-scoped application options apply to all blocks loaded in the
y
current tool session, and are not saved with the block(s)
nl
 Global value applied with: set_app_options –list|-name ...
O
 Can be specified before any block is read in
Global value overrides system default value
se

U
 Good practice:
al
Include global application option settings in a file to be sourced
upon tool start-up
rn
te
In
s 1- 20
sy
The global value of a global-scoped application variable can be removed by:
reset_app_options <app_option_name>
op
Note: For global-scoped application options, the –as_user_default option is ignored:

set_app_options –as_user_default –list|-name ...
yn
and
set_app_options –list|-name ...
rS
will both apply user-defined “global values”.

Fo
ed
er
i st
eg
R
Unit Objectives Summary
y
nl
You should now be able to:
O
 Use attributes to retrieve design information
se
 Perform block/library manipulation operations
U
(open, save, rename, copy)
Query and set application options to control ICC II’s behavior
al

rn
te
In
s 1- 21
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix
y
nl
Attribute: bbox vs. bounding_box
O
Removing Objects
se
Bus and Name Expansion and Subscripting
U
Legal characters and name length for libraries and blocks
Design library layout
al
Renaming blocks
rn
More on block labels and views
te
In
s 1- 22
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Use bounding_box instead of bbox 2016.12-SP2
 ICC II has added a new attribute called bounding_box, which allows

direct query and filtering of the involved coordinates
y
nl
icc2_shell> get_attribute [get_cells U92] bbox
{15.6778 16.3166} {17.1628 17.8666}
O
icc2_shell> get_attribute [get_cells U92] bounding_box
se
{{{15.6778 16.3166} {17.1628 17.8666}}}
icc2_shell> get_attribute [get_cells U92] bounding_box.ll_x
U
15.6778
icc2_shell> get_cells -hierarchical -filter "bounding_box.ll_x >= 15.0"
al
{U92}
rn
te
 Use the following cascaded attributes to query the various coordinates:
ll, ll_x, ll_y, ur, ur_x, ur_y
In
s 1- 23
sy
Using bbox, if you want to access the individual point of the bounding box, you have to use the lindex
command to parse the attribute:
icc2_shell> lindex [get_attribute [get_cells U92] bbox] 0
op
15.6778 16.3166
yn
rS
Fo
ed
er
i st
eg
R
Removing Objects
 To remove an object from a block, use remove_<object_class> or

remove_objects
y
nl
 remove_objects can remove a heterogeneous collection of objects
from the block, and returns the number of objects removed
O
 By default, you cannot remove or modify objects if their
se
physical_status attribute is locked
U
 To remove or modify these objects, use the -force option or use set_attribute to
reset the physical_status attribute to unrestricted
al
 If you remove objects that are included in an existing collection, the
rn
collection is updated
te
In
s 1- 24
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Bus and Name Expansion and Subscripting (1 of 2)
 ICC II supports bus and name expansion and subscripting, which

makes it easier to query bus or same-pattern nets, ports, and pins in the
y
block
nl
O
 Applies to the get_nets, get_pins, and get_ports commands, as
se
well as all commands that accept a collection of nets, ports, or pins
U
al
rn
te
In
s 1- 25
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Bus and Name Expansion and Subscripting (2 of 2)
Usage example Result Comments

get_nets a(0:3) {a0 a1 a2 a3} Name expansion:
A digit followed immediately by a colon(:) then
another digit in “()” specifies a name
y
expansion range
nl
get_nets {a[0:3]} {a[0] a[1] a[2] a[3]} Bus subscripting:
A digit followed immediately by a colon(:) then
O
another digit in “[]” specifies a bus
subscripting range
get_nets {a[0:1,6:8]} {a[0] a[1] a[6] a[7] Bus subscripting:
se
a[8]} Two ranges separated by a comma and
enclosed by “[]”
get_nets {a[0:4:2]} {a[0] a[2] a[4]} Bus subscripting:
U
From 0 to 4 with a step of 2, enclosed by “[]”
get_nets a(0:4:2) {a0 a2 a4} Name expansion:
al
From 0 to 4 with a step of 2, enclosed by “()”
get_nets {a0b[0] a0b[2] a0b[4] Combined usage of name expansion and bus
rn
{a(0:2)b[0:4:2,3]} a0b[3] a1b[0] a1b[2] subscripting
a1b[4] a1b[3] a2b[0]
a2b[2] a2b[4] a2b[3]}
te
Use “{}” or “\” to escape “[]” to prevent the Tcl interpreter
from evaluating the characters between “[]”
In
s 1- 26
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Blocks and Libraries

Legal Characters and Name Length
Library Block
y
name name Comments * You should always
nl
Illegal / / :, /, and . are not avoid nonprinting
characters * : : allowed because characters and
O
NULL (‘\0’) . they are delimiters in avoid characters
NULL (‘\0’) library and block other than
se
names
alphanumeric
Maximum 255 The length of any characters in library
length library or block name
U
or block names,
is limited by the file
although they are
system to 255
allowed
al
characters
rn
Note: There is no limit on the name length for design objects such as
nets, cells, pins, modules, and terminals
te
In
s 1- 27
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Renaming then Saving the Current Block
You can rename the block in memory before saving
y
nl
O
open_block ORCA/init_design
place_opt
se
rename_block -to_block ORCA/place_opt
U
# Current block in memory is now “ORCA/place_opt”
al
;# saves current block in current library
rn
save_block
or
te
save_lib ;# saves all unsaved blocks in current library
In
s 1- 28
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Design Libraries
my_design.dlib  The design library is a directory
y
 The library catalog and technology data
lib.ndm tech.ndm block1 block2 …
nl
are files in the library directory
Blocks are directories in the library
O
cstrs cstrs cstrs 
directory, one block per directory
se
design_label.* design_label.* design_label.*
 Views (such as design and frame) of a
block are individual files under the
U
… … …
block directory
 Blocks saved with a user-specified label
al
directory design.ndm design.ndm design.ndm
file
are stored in a subdirectory named
rn
frame.ndm frame.ndm frame.ndm design_label.label_name under the
block directory
te
… … …
In
s 1- 29
sy
The other library storage method is the “distributed file system” storage.
This is mainly used for design library.
op
Note: You should never manually remove/change anything under the library directory by system commands,
it will cause library corruption.
yn
rS
Fo
ed
er
i st
eg
R
Block Handle
 In a session, you can have multiple libraries, blocks, and views

opened, either explicitly or implicitly
y
nl
 You can open and switch to a block from any library by using the
unified block handle, which has the following format:
O
[library_name:]block_name[/label_name][.view_name]
se
 If you do not specify a library, it implies the current library
If you do not specify a label, it implies the “” (empty) label
U

 If you do not specify a view, it implies the design view
al
 Example: open the design view of a block named MyDesign with a label of
rn
placed from the design_lib.dlib library
open_block design_lib.dlib:MyDesign/placed.design
te
In
s 1- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Agenda
DAY
y
nl
O
se
U
2 Floorplanning
al
3
rn
te
In
s 2- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Floorplanning © 2019 Synopsys, Inc. All Rights Reserved. 2-1

IC Compiler II: Block-level Implementation
Unit Objectives
y
nl
After completing this unit you should be
O
able to describe some key block-level
floorplanning steps in IC Compiler II
se
U
(does not cover a complete design planning flow)
al
rn
te
In
s 2- 2
sy
This unit is only intended to provide an overview of some of the key steps involved in creating a block-level
floorplan. It is not intended to cover a complete hierarchical design planning flow, which is a lot more
op
complicated. There are many additional steps and iterations which are not covered in this unit.
yn
rS
Fo
ed
er
i st
eg
R

General IC Compiler II Flow

Synthesis
y
Design & Timing Setup
nl
O
Floorplan Definition This Unit
se
U
CTS & Optimization
al
rn
Routing & Optimization
te
Signoff
In
s 2- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Floorplanning Overview
RTL synthesis with default This unit provides an overview

floorplan (DC-G)
of some of the key steps in
floorplanning:
y
Design setup (ICC II)
nl
 Defining
O
Define block size/shape  Block shape/size
Place VAs and hard macros  Voltage area shapes/locations
se
 Macro cell locations
Place I/O pins
U
 I/O pin locations
Apply placement blockages  Standard cell placement
al
blockages (to address
Build power network
rn
congestion)
Write out floorplan  Overview of PNS
te
 Exporting the floorplan
In
s 2- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Create the Initial Floorplan
 Floorplan Initialization
y
 Defines standard cell
nl
placement site array
within the core area
O
 Supports various
core shapes:
se
 Rectangular
U
 L-shape
 T-shape
al
 U-shape
rn
 Custom
te
initialize_floorplan -shape U -...
In
s 2- 5
sy
initialize_floorplan also creates the routing tracks based on the definitions from your technology file.
op
To define a floorplan other than the regular shapes listed above, select the “Custom” option for
“Boundary/Shape” and provide the coordinates of the boundary. Here’s an example:
initialize_floorplan -boundary { {0.0 0.0} {800.0 0.0} {800.0 200.0} \
yn
{1013.08 200.0} {1013.08 780.8240} {416.4800 780.8240} ...}

rS
Fo
ed
er
i st
eg
R

Floorplan After Initialization

IO-Core
distance
y
Edge of
nl
block
Unplaced
O
Macro row orientation key
cells
Edge of
se
core
U
Core area Site array
al
containing
site rows
rn
te
Unplaced
Standard cells
In
and ports
s 2- 6
sy
The picture on the right is a zoom-in to the lower-left corner of the block.
A site array is a container of site rows. You can resize/move a site array, stack several site arrays on top of
op
one another, change the ordering and transparency, with the goal of specifying what standard cells are
allowed where. Additional site arrays can be created using the create_site_array command.
See the appendix for details.
yn
rS
Fo
ed
er
i st
eg
R

Create Voltage Areas (for MV Designs)
 ICC II automatically creates a voltage area called VDD VDD1

DEFAULT_VA, associated with the top-level UPF
y
DEFAULT_VA
power domain (PD_Top in this example)
nl
PD_Top (0.9V)
You must create voltage areas for all other UPF PD1 (0.7V)
O

power domains before running placement, unless VDD2
se
this occurs using shape_blocks (shown next):
U
PD2 (1.1V)
create_voltage_area -power_domains PD1 \
al
-region {{377 377} {215 377} {215 485}
rn
{404 485} {404 215} {377 215}} VSS VSS VSS
create_voltage_area -power_domains PD2 \
te
-region {{215 215} {350 350}}
In
s 2- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Automatic VA Creation: “Shape Blocks”
PD_RISC_CORE
 Automatically place and shape
the voltage areas using:
y
nl
shape_blocks
O
DEFAULT_VA
 Voltage areas do not need to be
se
created prior to shape_blocks
U
 You can define a “hard keepout margin”
(called guard band) around voltage areas
al
 No cells, including LS and ISO, can be placed within the guard band margin
rn
te
set_shaping_options –guard_band_size 10
In
s 2- 8
sy
If there is a power domain which has no corresponding voltage area, the VA will first be created by
shape_blocks.
op
A guard band is the space along the boundary of a voltage area shape where cells cannot be placed. A guard
band expands outward from the region. It essentially acts as a keepout margin.
Note that set_shaping_options also has a -min_channel_size option, which is used to control the
yn
minimum spacing between hierarchical blocks and macros. It is not used for voltage areas.
rS
If you want to apply a certain target utilization for a voltage area, which shape_blocks should take into
account while placing and shaping the VAs, you need to create the VA first (see next page), then set a target
Fo
utilization on its shape(s).

icc2_shell> get_voltage_area_shapes -of_objects [get_power_domains PD_RISC_CORE]
{VOLTAGE_AREA_SHAPE_1}
ed
icc2_shell> set_attribute [get_voltage_area_shapes VOLTAGE_AREA_SHAPE_1] \

target_utilization 0.4
icc2_shell> shape_blocks
er
…
voltage_area PD_RISC_CORE
st
utilization 0.450
target utilization 0.400
i
eg
If, after shaping, you want to preserve a certain voltage area from further shaping runs, or you want to create
R
a voltage area manually and not have it shaped by shape_blocks, you need to set this VA to “fixed” using:
set_voltage_area PD_RISC_CORE -is_fixed

Place Macros and Standard Cells
 Perform coarse placement of macros and standard cells
y
nl
O
se
U
al
rn
te
In
create_placement –floorplan [-congestion …]
s 2- 9
sy
The -floorplan option includes macro placement and special effort levels which are tuned for speed.
Usage: create_placement # Create a coarse placement
op
[-floorplan] (Run design planning styled placement)

[-host_options host_options_name]
yn
(Host options to use)

[-use_seed_locs] (Use current cell locations as a seed for placement)
[-timing_driven] (Run timing-driven placement)
rS
[-congestion] (Run congestion driven placement)

[-congestion_effort string]
Fo
(Congestion driven placement effort)

[-effort string] (Placement effort)
[-incremental] (Run incremental placement)
ed
er
i st
eg
R

Configuring Macro and Standard Cell Placement

Placement can be configured using
plan.place.* and plan.macro.*
application options
y
nl
Always start with the defaults
O

 Macros at the same hierarchy level
se
and of the same size are automatically
grouped into arrays, by default
U
plan.macro.auto_macro_array*
 Channels between macros are
al
automatically sized based on the
rn
number of pins
 Soft placement blockages are
te
automatically applied in thin channels
In
s 2- 10
sy
To disable auto-spacing set the application option plan.place.default_keepout to false.
op
To manually specify macro spacing use:

plan.macro.spacing_rule_heights
plan.macro.spacing_rule_widths
yn
In most cases, pins are only located on one of the macro edges (RAMs). By default, macros are flipped such
rS
that the sides with the pins are opposite each other. This reduces the number of channels necessary for
routing to the pins. Fewer channels translates into less effort during implementation (buffering, routing).
This is controlled using plan.macro.auto_macro_array_minimize_channels
Fo
Automatic blockage generation is controlled through the application option

ed
plan.place.auto_generate_blockages
Enable hard blockage creation, and control the max width of hard/soft blockages with:
er
plan.place.auto_generate_soft_blockage_channel_width
st
plan.place.auto_generate_hard_blockage_channel_width
i
eg
R

Detailed Macro Constraints, Fixing Macro Placement
 There are many more possibilities for constraining macro placement.

Review the documentation for the following commands if required:
y
nl
set_macro_constraints
set_macro_relative_location
O
create_macro_array
se
create_macro_relative_location_placement
U
 Finally, prior to running place_opt, fix the placement of all macros:
al
rn
set_fixed_objects [get_flat_cells -filter "is_hard_macro"]
te
In
s 2- 11
sy
To unfix the macros, use set_fixed_objects –unfix
There is another command, set_locked_objects, which will have the same effect: The location of cells
op
will be locked. For most operations there is no difference between fixed and locked. In the case of locked
objects, you will not be able to use remove_cell/remove_objects. This will only work with fixed
yn
objects. Neither fixed nor locked are protected from setting attributes directly. If you decide to change the
location of an object using set_attribute, then the object will move, regardless of the fixed/locked setting,
rS
for example: set_attribute [get_cells mymacro] origin {300 400}
If you try to run create_placement (without the -floorplan option) or place_opt with unfixed
Fo
macros, the command will abort:

Error: There are non-fixed macros in design. Use the -floorplan option to place
ed
macros or fix all macros. (DPUI-083)
As an alternative to fixing the macros’ placement, you could set the following application option:
er
set_app_options –list { place.coarse.fix_hard_macros true }

st
There are a couple of downsides:

• If you happen to run the command reset_placement, the macros will also be unplaced
i
• When you write a floorplan DEF or Tcl file, the macros will not have a locked attribute
eg
• You cannot set the application option before running “create_placement -floorplan”, otherwise
macros will not be placed!
R
Because of the above limitations, we recommend against using the application option, and instead to lock the
macros using set_fixed_objects or set_locked_objects.

Analyze Placement of Macros using Data Flow Flylines (DFF)
y
nl
O
se
DFF allows exploration of the netlist
U
connectivity by using netlist tracing.
A “flyline” can be configured to
al
pass through several levels of
combinational gates as well as
rn
registers.
This allows connectivity analysis
te
beyond the simple “Net Connections”.
In
Connections that terminate in
registers are not shown. s 2- 12
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Register Tracing
y
nl
O
Select one or more start-point objects (macros or non-clock
input ports) to see their connectivity to one or more levels of
se
registers, as well as direct and indirect connections to other
macros or output ports.
U
Flylines only show connections to registers – no combinational
al
logic connections are shown.
rn
Recommended as debugging technique after place_opt
te
In
s 2- 13
sy
Selecting a macro selects all of its data output pins (no PG, clock or scan pins).
Standard cells/pins may also be selected, but due to runtime, only the first 100 of these start-points will be
op
traced.
yn
rS
Fo
ed
er
i st
eg
R

Place I/O Pins
2
 Apply any known:
 Block pin constraints 1
y
Individual pin constraints
nl
 3
6
Place the pins
O
 5
se
4
U
set_block_pin_constraints –self -allowed_layers "M3 M4" \
-sides "1 2 3" | -exclude_sides "4 5 6"
al
set_individual_pin_constraints –ports … -
rn
place_pins -self
te
In
s 2- 14
sy
One might argue that – at the block level – pin placement would have been already passed down from the
top-level. Of course, this would then also have to include the block shape. If that is the case, macro placement
op
would have taken the existing pin placement into account.

If, on the other hand, there are only rough pin placement guidelines, e.g. bus X pins are to be placed on the
right, then the block pin constraints shown above would be sufficient, and pin placement should be run after
yn
macro placement, in order to take the block’s routing into account.

rS
Fo
5 6
4
ed
3
er
2 7
1 12
st
11
i
eg
10
9
R
8
(Side 1 = lower, left‐most, vertical edge)

Analyze Global Route Congestion
y
nl
O
+0/20
se
+7/18 +4/20
U
Congestion segment labels
al
GRC grid
rn
+1/20
te
In
route_global –floorplan true -congestion_map_only true
s 2- 15
sy
With the -floorplan true option the global router performs fast, lower effort global routing.
The global router uses less effort to avoid blockages on blocked pins and makes other simplifying
op
assumptions to complete global routing quickly. Designs can be unlegalized (only coarse placement) in
floorplan mode. Floorplan mode also disables timing or crosstalk-driven routing. The resulting congestion
map shows the location of congestion hot spots in the floorplan.
yn
If borderline congestion, you should confirm with:

rS
route_global -congestion_map_only true -effort_level low|medium|high

Fo
ed
er
i st
eg
R

Congestion Segment Labels
 The congestion segment labels have the format:
y
 “Signed congestion overflow” / “total supply”
nl
 (both numbers are in units of routing tracks)
O
 For example, this segment: +4/20
se
Layer Demand Supply Overflow
M1 10 8 +2
U
M3 9 7 +2
M5 1 5 ‐4
al
rn
 Capacity (supply): 20 tracks
 Overflow: +4 tracks
te
 Underflow (here -4) is counted as 0
In
s 2- 16
sy
Congestion calculation calculates the track usage for each layer and displays it in the GUI. Two methods will
be supported in IC Compiler and IC Compiler II:
op
• Sum of overflow for each layer (new default since K-2015.06)

• Total demand minus total supply (old default in previous releases)
The new default was introduced because of too much optimism in the old method.
yn
rS
Fo
ed
er
i st
eg
R

Congestion Potential Around Macro Cells

 Routing to standard cells can often be difficult near high pin-count
edges or corners of macro cells
y
 Solution: Apply placement blockages around macros,
nl
or use keepout margins
O
 Note however that automatic placement will have added soft placement
blockages already
se
U
al
rn
te
In
s 2- 17
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Apply “Padding” Around Macro Edges
Keepout margins can help reduce

congestion around the pins
y
nl
O
se
RAM5
U
al
Pins are on
left and right
rn
te
create_keepout_margin -type hard -outer {15 0 18 0} RAM5
In
s {left bottom right top} 2- 18
sy
Note: The “left bottom right top” edges, which the numbers in parenthesis are associated with, correspond to
the left, bottom, right and top edges, respectively, of the macro cell in its current orientation in the floorplan.
op
Once applied, the margins will “rotate along” if the cell is rotated.
The following commands allow retrieval, reporting and removal:

yn
get_keepout_margins
report_keepout_margin
rS
remove_keepout_margin
To create general placement blockage regions (e.g. rectangular or rectilinear areas), use the following
Fo
command:
create_placement_blockage \
–boundary {{345 355} {392 400}} \
ed
–name LL_CORNER -type hard | soft

er
Whenever you make changes to your floorplan you need to rerun placement and congestion analysis:
create_placement –floorplan [-incremental]
st
route_global –floorplan true -congestion_map_only true

i
eg
R

Power Planning Challenges
 Mix of digital and analog logic

can require complex core rings
y
nl
O
 Many designs have multiple
voltage areas
se
 Each area requires a unique mesh
structure
U
al
 Special P/G patterns
rn
te
In
s 2- 19
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Pattern-Based Power Network Synthesis
1. Define PG Regions A
B
y
nl
2. Define Pattern: Structure
Defines metal layers, spacing, width, …
O
 M5
M4 M6
se
3. Define Strategy: P/G topology
U
 Applies specific pattern to specific PG region, voltage A
areas or bounds and specific power/ground nets B
al
 Flexible to floorplan change (no fixed coordinates)
rn
te
4. Compile power network
In
s 2- 20
sy
For a PG network, you may need to create rings, meshes and std cell rails.
One design may have one strategy or multiple strategies, depending on the complexity of the design.
The patterns are created using *pattern* commands, e.g. create_pg_mesh_pattern.
op
The strategies are created using set_pg_strategy.

There are also via strategies that can be created using set_pg_strategy_via_rule.
yn
To build the PG mesh, you use compile_pg.

rS
After pattern-based PNS, check the PG network using:

check_pg_drc
Fo
Verifies and reports technology routing design rules violations and illegal overlaps of PG net
objects (shapes, vias and pins)
check_pg_missing_vias
ed
Checks for missing vias between overlapping regions of different metal layers
check_pg_connectivity
er
Generates information for floating wires, vias, pads, macro pins, and standard cell pins
i st
eg
R

Write out the Floorplan for ICC II
 Capture all floorplan information for later re-use in ICC II
y
write_floorplan -output ORCA_TOP.fp
nl
Output directory ORCA_TOP.fp will contain the files:
O

 floorplan.tcl - Main file, sources the following two files
se
 fp.tcl - Reads the DEF file and applies Tcl floorplan constraints that
cannot be captured as DEF
U
 floorplan.def - DEF file
al
To apply the floorplan later in ICC II, use:
rn

te
source ORCA_TOP.fp/floorplan.tcl
In
s 2- 21
sy
Note that by default, read_def assumes -add_def_only_objects none. Therefore, if you have added
physical-only cells during floorplanning, use the following syntax to capture the floorplan:
write_floorplan -read_def_options {-add_def_only_objects all}
op
read_def -add_def_only_objects all | cells | nets | ports | none

yn
Specifies the types of objects that are created by the read_def

command if they exist in the DEF file but not in the current
rS
block. You can specify one or more of (cells, nets, ports)

except for none, which must be used alone.
Fo
ed
er
i st
eg
R

Write out Floorplan Information for DC-G
 Write out the floorplan information that is necessary for DC-G
y
 Standard cell placement is not included!
nl
write_floorplan -format icc -output ORCA_TOP.fp.dc \
O
-net_types {power ground} \
-include_physical_status {fixed locked}
se
Used by Design Compiler Graphical for “second-pass synthesis”. To load:
U

create_net -power VDD
al
create_net -ground VSS
rn
read_floorplan ORCA_TOP.fp.dc/floorplan.tcl
te
In
s 2- 22
sy
Standard cells are not included because a new netlist will be created during “second-pass synthesis”, based on
this floorplan.
op
write_floorplan in ICC II creates a subdirectory named by –output. The example above would
produce:
yn
ORCA_TOP.fp.dc/
floorplan_compare_data.txt
rS
floorplan.def
floorplan.tcl
Fo
fp.tcl
ed
To apply the floorplan in DC-G, you need to create all power and ground nets first, otherwise DC-G will not
apply the PG net information from the DEF file:
er
create_net -power VDD

create_net -power VDDH
st
create_net -ground VSS

read_floorplan ORCA_TOP.fp.dc/floorplan.tcl
i
eg
R

Second-Pass Synthesis Before Placement

 Second pass synthesis with the actual floorplan provides
IC Compiler II with a better optimized netlist for placement
y
Physical synthesis  Synthesis with Synopsys Physical
nl
with default floorplan
Guidance (SPG) also provides
write_icc2_files
coarse placement to IC Compiler II
O
Design setup  Used as a starting-point for placement
se
 Define block size/shape
Physical synthesis with
DC-G
U
ICC II floorplan (SPG)
 Place VAs and hard macros
write_icc2_files

al
Place I/O pins
2nd pass synthesis
 Apply placement blockages
rn
Design setup with re-
 Build power network synthesized netlist
te
 Write out floorplan
SPG
In
Floorplan Definition Placement
s 2- 23
sy
By re-synthesizing the design with DC-Graphical using an accurate floorplan you are providing IC Compiler
with a better starting netlist, which may give better results. If QoR is not critical, the re-synthesis step can be
op
skipped and the resulting cell after floorplan definition, with its netlist from the first synthesis execution, is
taken directly to placement.
The above flow assumes that the RTL code is fairly complete when performing the initial synthesis. If the
yn
RTL contains a fair number of “black boxes” (i.e. undefined sections) you may need to perform additional
iterations of design planning and synthesis, as the RTL code is solidified.
rS
To pass the design from DC-G to ICCII, use Design Compiler’s write_icc2_files (available starting with
Fo
2015.06-SP1), which will also write the standard cell placement as DEF (among many other things):
# Save the file for IC Compiler II
dc_shell-topo> write_icc2_files –output ./icc2_files
ed
dc_shell-topo> quit
# Perform library setup in IC Compiler II (this is a script you create)
icc2_shell> source -echo –verbose icc2_lib_setting.tcl
er
# Load the design

icc2_shell> source –echo –verbose icc2_files/ORCA.icc2_script.tcl
st
# Continue with the flow

i
icc2_shell> commit_upf
eg
icc2_shell> place_opt
R

Summary
You should now be able to describe some key

block-level floorplanning steps in IC Compiler II
y
nl
O
se
U
al
rn
Begin Lab 2: Overview of Floorplanning
te
In
s 2- 24
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix
y
nl
O
Site Arrays
se
U
al
rn
te
In
s 2- 25
sy
op
yn
rS
Fo
ed
er
i st
eg
R

What is a Site Array?
 An object that is a container for site rows
y
 Stacking levels
nl
 Serves the same function as in VAs. The site array with the highest stacking level has highest
priority.
O
 Default site array has a stacking level of 0
se
 If multiple site arrays overlap, then the one with the highest stacking level will occlude the others,
unless transparency is enabled
U
 Each site array has a unique stacking level value
 Transparency
al
 Gives equal priority for the site rows in the current site_array and the site array immediately below it
rn
as determined by stacking level
 When two site arrays overlap, and the site array with the highest stacking level is set as transparent,
te
cells matching the site def for each site array, may be legally placed in the union of the two site
array.
In
s 2- 26
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Effective Site Array
 Default site array

 Cells may be placed anywhere except within SA_1 Default Site Array
y
SA_1 Stacking Level 0
nl
 SA_1
Transparent False
 SA_1 cells may be placed anywhere within SA_1 Stacking Level 1
Default true
O
 Including area A, because SA_2 is transparent Transparent False
 Default site array cells may not be placed here because
se
SA_1 is not transparent A
 SA_2 SA_2
U
 SA_2 cells may be placed anywhere within SA_2 Stacking Level 2
 Including in area A, because SA_2 stacking level is > SA_1 Transparent True
al
 A
rn
 Cells for both SA_2 and SA_1 may be placed here because
SA_2 is transparent
te
 Cell for default site array cannot because SA_1 is not
transparent
In
s 2- 27
sy
Site arrays can be stacked
The site array with the highest stacking level has highest priority.
op
If multiple site arrays overlap, then the one with the highest stacking level will occlude the others, unless
transparency is enabled
Each site array has a unique stacking level value
yn
Transparency
When two site arrays overlap, and the site array with the highest stacking level is set as transparent, cells
rS
matching the site def for each site array, may be legally placed in the union of the two site arrays
Fo
ed
er
i st
eg
R

Three Types of Site Arrays
 Default
y
 Each block has a default site array
nl
 Stacking order = 0
O
 Boundary is the same as the block boundary
 Exception is for chip with IOs
se
 Defines the wire tracks for the block
Wire tracks fill the entire boundary area
U

 Fixed
al
 Stacking order > 0
rn
 Boundary is the same as the block boundary
te
 Floating
In
 stacking order > 0
s 2- 28
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Advantages
 When working with site arrays, there is no need to manage the site
rows. The site rows are automatically created to fill the site array
y
boundary
nl
Working with a single site array object instead of with individual site
O

rows makes working with site rows easier
se
 With support for stacking there is no longer a need to cut and manage
individual site rows. If there is an area in the design where a different
U
site row is needed, create a site array, set its stacking level > the site
al
array below it and the effective site rows will be created automatically.
rn
 This also allows for easy modification of site rows, but simply using the
standard GUI features to move, stretch, edit the site array and all site
te
rows automatically heal
In
s 2- 29
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Real Example
 Block boundary
y
nl
 Effective site rows are
O
determined by inner hard
keepout, and core offset
se
U
 Site rows align with parent
default site array
al
rn
 Wire tracks align with parent
te
wire tracks
In
s 2- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Common Site Array Questions
 When are site arrays created?

 Site arrays are created by initialize_floorplan for the current block.
Site arrays are created by commit_block for child blocks
y

nl
 How are site rows created within a site array?
Will fill the site array boundary as completely as possible
O

 Reduced in size by the inner hard keepout margin
se
 Snapped to tile width
 Why do I have gaps between my site rows and site array boundary?
U
 Gaps can be caused when the site array boundary is not a multiple height or width of the site def
 If the gap is along a top or bottom, then the site array height is not a multiple of the site def height, or
al
site row height
rn
 If the gap is along a left or right, then the site array width is not a multiple of the site def
 Can I modify a site array with the GUI?
te
 GUI object manipulation commands work on site arrays. They can be created, removed, split,
reshaped, etc.
In
s 2- 31
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Common Site Array Questions
 How do I create disjoint areas of site rows?

 Use the create_site_array command and put the site arrays where you need them. If they
don’t overlap with other site arrays, they will remain disjoint
y
If creating disjoint site arrays using the same site def, all site rows will be automatically kept in
nl

alignment with each other. There is no longer a need to ensure alignment manually like when
creating site rows.
O
 How do I change the stacking order?
se
 The command set_site_array_stack_order allows you to modify the stacking order of
already existing site arrays
U
Usage: set_site_array_stack_order # Set the stack order of a site array
[-above site_array] (Name or collection of a site array)
al
[-below site_array] (Name or collection of a site array)
rn
[-raise] (raise site array by one position)
[-lower] (lower site array by one position)
te
[-top] (raise site array to the top of the stack)
[-bottom] (lower site array to the bottom of the stack)
In
site_array (Name or collection of a site array)
s 2- 32
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
O
se
U
2 Floorplanning
al
3
rn
te
In
s 3- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Placement and Optimization © 2019 Synopsys, Inc. All Rights Reserved. 3-1

Synthesis
y
nl
O
Floorplan Definition
se
Placement & Optimization This Unit
U
CTS & Optimization
al
rn
te
Signoff
In
s 3- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Unit Objectives
y
nl
 Apply pre-placement setup to control:
O
 Design and flow requirements
se
 Congestion, timing, area and power QoR
 Perform placement and related optimizations
U
 Analyze congestion, timing, power and area
al
rn
te
In
s 3- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Key Steps of the Placement Phase
Design Setup
y
The “placement phase” involves several key steps:
nl
Pre-placement check
 Placement readiness check
O
Design and flow
requirement setup  One-time design and flow requirement setup
se
 Congestion, timing, power and area QoR setup,
QoR setup
as needed
U
Placement and  Placement and optimization
al
Optimization
rn
Placement
te
CTS
In
s 3- 4
sy
Design and flow requirement setup: These setup steps are dictated by design requirements, and/or by the
required flow (dictated by your group or company). They are applied once, and they generally remain
op
unchanged after that.
Unless noted otherwise, all commands in this unit are scenario independent (apply to all scenarios), or
yn
include information from all active scenarios.

rS
Fo
ed
er
i st
eg
R
Placement and Optimization Commands Placement and

Optimization
Design Setup
y
nl
Pre-placement check
place_opt
O
Design and flow
requirement setup
se
Performs standard cell placement and optimization
QoR setup
U
Placement and  Placement and optimization is discussed next,
al
Optimization
pre-placement checking and setup after that
rn
Placement
te
CTS
In
s 3- 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Placement and Logic Optimization: place_opt

Placement and
Optimization
place_opt Performs placement and logic optimization
y
-list_only List the 5 optimization stages
nl
-from Specify which major stage to start with
O
(default is initial_place)
-to Specify which major stage to end with
se
(default is final_opto)
U
 By default, place_opt runs all five stages
al
 Use the -from / -to controls for exploration and debugging
rn
 Allows you to verify quickly whether each stage will be successful
te
 Various aspects can be controlled via app options
In
s 3- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R
The Five Stages of place_opt

Placement and
Optimization
1. Initial Coarse Placement (initial_place)
y
 Performs buffering aware timing-driven placement and scan chain optimization
nl
2. HFN buffering (initial_drc)
O
 Removes buffer trees, performs high fanout synthesis and logic DRC fixing
Initial Optimization (initial_opto)
se
3.
 Performs quick timing optimization
U
4. Final Placement (final_place )
al
 Performs incremental and final timing-driven and global-route based congestion-
driven placement, as well as scan optimization
rn
5. Final Optimization (final_opto )
te
 Performs final full-scale optimization and legalizes the design
In
s 3- 7
sy
The initial_place stage now performs buffering-aware timing-driven placement, which is controlled by
the application option place_opt.initial_place.buffering_aware (true by default). Details will
be covered later. Prior to 2018.06, the initial_place stage was purely wire-length driven.
op
place_opt uses virtual routing throughout by default, with the exception of congestion estimation and
yn
removal during the final_place stage.

There are various controls that will be covered later that show how global routing can be used for more
rS
operations during place_opt.

Fo
ed
er
i st
eg
R
Recommended place_opt Exploration Flow

Placement and
Optimization
Design Setup  Initially, perform design/flow setup and run all five
stages of place_opt
y
 Analyze congestion
nl
Pre-placement check
 If not acceptable, return to unplaced design
O
Design and flow
requirement setup  Apply congestion-focused setup steps, re-run place_opt
se
 Analyze timing, power and area
QoR setup
(once congestion is acceptable)
U
 If not acceptable, return to initial design
Placement and
al
Optimization  Apply timing-, power- and/or area-focused setup steps,
and re-run place_opt
rn
Placement
 Execute and analyze after intermediate stages to
te
CTS
speed up the QoR iterations (see example below)
In
s 3- 8
sy
By “initial design” we mean the design that initially came from synthesis which may contain SPG placement.
op
The following is an example flow, where serious congestion and timing issues can be uncovered and
addressed earlier:
# Run the initial_place and initial_drc stages of place_opt:
yn
place_opt –to initial_drc

# Analyze congestion, and if serious routability issues exist:
rS
# Return to unplaced design, apply congestion-focused setup steps

# Repeat above place_opt
Fo
# Once serious congestion is under control, run initial_opto:

place_opt –from initial_opto –to initial_opto
ed
# Analyze timing, and if serious timing violations exist:

# Return to unplaced design, apply timing-focused setup steps
# Repeat above place_opt
er
st
# Once serious timing violations are addressed, run final_place and final_opto:
place_opt –from final_place
i
eg
# Analyze congestion and timing, and if needed, return to unplaced design and fine-tune
# congestion and timing setup
# Run complete place_opt.
R
Design Status Prior to Placement

Pre-placement check
Design Setup  Second-Pass synthesis is completed
y
 Based on the best available floorplan design
nl
Pre-placement
check
 Second-Pass Design Setup is completed
O
Design and flow  New block is generated based on
requirement setup
se
second-pass netlist and actual floorplan:
QoR setup  Standard cells may have been placed
U
(coarse placement from SPG synthesis)
Placement and
al
Optimization
rn
Placement
CTS
te
In
s 3- 9
sy
In the example picture, while the power network has been defined, its visibility was turned off, to more
clearly show the macro and standard cell placement.
op
You have seen in the previous unit how to accomplish the following floorplanning steps:
• Define block size/shape
yn
• Perform pin placement

• Define placement blockages
rS
• Place macros and lock their location

• Build the P/G network
Fo
ed
er
i st
eg
R
Pre-Placement Check
Pre-placement check
 IC Compiler II offers a large number of checks that can be performed at

various stages
y
nl
 Use get_design_checks to list all available checks
O
 {routes mib_alignment pg_drc pg_missing_vias pin_placement
analyze_design_violations rp_constraints finfet_grid cts_qor feedthroughs
pre_route_stage legality scan_chain design_mismatch design_extraction
se
clock_trees pre_clock_tree_stage pre_placement_stage timing mv_design
routability …}
U
 The bolded checks are mega-checks – they contain several of the smaller checks
al
 Before placing the design, run the following:
rn
check_design -checks pre_placement_stage
te
In
s 3- 10
sy
Note: The check_design command requires the -checks option. If the option is missing:
Error: Required argument '-checks' was not found (CMD-007)
op
yn
rS
Fo
ed
er
i st
eg
R
check_design Results
Pre-placement check
 All checks print a summary to the screen and store most results in an
EMS database (Enhanced Messaging System)
y
Open the EMS database in the GUI for detailed analysis
nl

O
se
U
al
rn
te
In
s 3- 11
sy
By default, check_design writes the information into an EMS database called check_design.ems.
Subsequent check_design will overwrite this file.
op
To preserve existing EMS databases, specify a new name:

icc2_shell> check_design -checks pre_placement_stage \
-ems_database place.ems
yn
Alternatively, you can store “atomic checks” in an EMS database using dedicated commands:
rS
icc2_shell> create_ems_database place.ems

{.../place.ems}
Fo
icc2_shell> get_current_ems_database
{.../place.ems}
icc2_shell> check_mv_design
ed
1
As you can see, no output is generated by check_mv_design, instead the results will be written to the EMS
er
database.
icc2_shell> save_ems_database
st
icc2_shell> report_ems_database
i
eg
R
Also Recommended: Physical Constraint Checks

Pre-placement check
check_design -checks physical_constraints
y
nl
 Performs various checks on floorplan objects such as layers, bounds,
O
placement blockages, cell instances, macros, site rows, etc., to ensure
correctness
se
 Example:
U
Information: The layer 'M9' does not contain any PG shapes. (DCHK-104)
al
Warning: Keepout margin of cell I_PCI_TOP/PCI_FIFO_RAM_8 lies partially or
rn
completely outside the bounds of the core. (DCHK-085)
te
In
s 3- 12
sy
A few of the checks that are performed:
• boundary and core are not defined for the block or are invalid
op
• site definition missing

• site height is multiple of the normal site height
• site row overlaps with others
yn
• keepout margin is outside the core area

• IO Pad cell instance is in core area or overlaps with other cell instance
rS
• orientation of cell instance is legal

• macro is placed and fixed
Fo
• macro is outside of the core area

• macro is overlapping with other macro or blockage
• movebound is completely covered by blockage
ed
• placement blockage is partially or completely outside the core area

• utilization of group bound/move bound is above 90%
er
• …
i st
eg
R
Design and Flow Requirement Setup Steps

Design/flow requirement
Design and flow requirement setup consists of the

following one-time steps, as applicable:
y
Design Setup
nl
Apply advanced technology setup
O
Pre-placement
check Configure scenarios for MCMM optimization
se
Design and flow Enable SPG Flow
requirement setup
Disable port-punching on sub-designs
U
QoR setup
Control spare cell placement and identification
al
Placement and
Optimization Remove unwanted ideal networks
rn
Placement Restrict usage of specific library cells
te
CTS
Enable leakage, dynamic or total power optimization
In
s 3- 13
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Setup for Advanced Nodes

Design/flow setup
2018.06
 Advanced technology nodes require complex app option setup to
control RC extraction, placement, legalization, routing and via ladders
y
nl
 Most settings are not optional, and can be different for each node
O
 A single command performs node-specific checks and setup
Example:
se

icc2_shell> set_technology -node 7
U
Executing: set_extraction_options -honor_mask_constraints …
Executing: set_ignored_layers
al
……
technology_node=7
rn
 Currently supported nodes by set_technology: 12, 7, 7+, 5
te
 Always use set_technology at the beginning of the physical design flow!
In
s 3- 14
sy
An application note is available on Solvnet #2816760.
op
yn
rS
Fo
ed
er
i st
eg
R
set_technology: Design Setup Check Examples

Design/flow setup
 set_technology also reports node specific design setup issues
y
Identifies missing site definitions Visiting block xyz:abc.design
nl
Design ‘abc' was successfully linked.
which require user correction Warning: cannot find half height (3T) sitedef in the library
O
Warning: cannot find full height (6T) sitedef in the library
Warning: cannot find inbound (6T-Turbo) sitedef in the library
Error: no sitedef for 3T, 6T or 6T-Turbo is found.
se
set_technology will not change placement and legalize settings.
U
al
Identifies missing Warning: Unable to find SVT implant layers VTS_P and VTS_N.
VT implant constraints Please set place.legalize.VT_groups and
rn
place.legalize.VT_group_max_parallel_run_length app options manually
te
In
s 3- 15
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Advanced Legalizer
Design/flow setup
 set_technology also enables the advanced legalizer for 7 and below
y
place.legalize.enable_advanced_legalizer
nl
place.legalize.enable_advanced_prerouted_net_check
O
 Designed for advanced nodes
se
 Natively supports 2D rule legalization in a single pass resulting in higher density
 Multi-row, single-row, and inbound cells
U
 Enables automatic 2D rule detection
al
Running Advanced Node 2D Legalizer....
2D rule auto detection will enable the following rules:
rn
spacing_rule
vt_min_width
od_length
te
tpo_min_width
pg_drc
In
pin_color_align
s 3- 16
sy
An application note is available on SolvNet #2853738.
Information on the new placer DRC checker (NPLDRC) is available in article #2853876.
op
ICC II will enable 2D rules automatically based on the following criteria:

overlap Always on
yn
cell_on_site Always on
legal_orient Always on
rS
spacing_rule Always on
va_bound If design has voltage areas and hard or exclusive move bounds
Fo
vt_min_width If design has implant layers defined in technology file

od_length If diffusion layers are found in the technology file
tpo_min_width If trim-poly layers are found in the technology file
ed
pin_color_align
If the place.legalize.enable_pin_color_alignment_check application option is enabled
er
To manually add a rule to check:

st
# Add vt_min_area check

i
set_app_options -name place.legalize.enable_advanced_legalizer_rules \

eg
-value {vt_min_area}
set_app_options -name place.legalize.enable_advanced_legalizer -value true
legalize_placement
R
Migrating to the Advanced Legalizer

Design/flow setup
 The advanced legalizer is supported in production for various nodes
y
nl
 Synopsys plans to validate and support additional nodes
O
 Please contact your Synopsys AE on current up-to-date support!
se
 In general, if your design has a large number of multi-row or wide cells,
U
QoR benefits can be seen by using AL, even on older process nodes
al
rn
te
In
s 3- 17
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Configure Scenarios for MCMM Optimization

Design/flow setup
 Concurrent MCMM optimization requires creation of scenarios
y
 Optimization occurs in active scenarios, for enabled analysis types:
nl
 setup, hold
O
 leakage_power, dynamic_power
 max_transition, max_capacitance, min_capacitance
se
 Hold analysis type is ignored during place_opt, even if enabled
U
 Configure the scenarios appropriately prior to executing place_opt
al
Covered
# Example configuration for placement: in Unit 6
rn
set_scenario_status * -active false
set_scenario_status <list_of_placement_scenarios> -active true
te
set_scenario_status *corner_FAST -setup false
set_scenario_status mode_TEST* -leakage_power false
In
s 3- 18
sy
Unless noted otherwise, all commands in this unit are scenario independent (apply to all scenarios), or
include information from all active scenarios.
op
In the example configuration above, since all scenarios are active, by default, when they are created, all
scenarios are first made “inactive”, and then the minimum sub-set of scenarios needed for placement are
yn
“activated”. For this sub-set, all seven analysis types (and therefore optimization) are enabled, by default. To
further improve runtime, setup timing analysis/optimization in any “FAST” corner, as well as leakage power
rS
analysis/optimization in any “TEST” mode, are also disabled.

Fo
ed
er
i st
eg
R
Configuring place_opt for SPG

Design/flow setup
 If your input netlist was generated by SPG synthesis with

Design Compiler-Graphical, enable the SPG placement flow:
y
nl
set_app_options –list {place_opt.flow.do_spg true}
O
se
 The initial_place and initial_drc phases are skipped
U
 Coarse placement and HFN/DRC buffering from synthesis are used as the start-
point for initial optimization, followed by final placement and optimization
al
 Any options/commands shown later that affect these two stages will not have an
rn
effect when using the SPG mode
 Standard cell placement must have been read in through DEF
te
 Created using write_icc2_files in DC-G
In
s 3- 19
sy
If the do_spg flow is enabled on a design without SPG placement, place_opt will still run, starting at
initial_opto, however it will be optimizing logic based on unplaced cells, and it will generate error
op
messages for all the unplaced and overlapping cells. It is, therefore, not recommended to do this.
The write_icc2_files command writes the design files and Tcl scripts for the current design to load the
yn
design data into IC Compiler II. Files are written into the directory specified by the -output option. The
written files include the following, if the data is present:
rS
• Netlist in Verilog format

• Propagate backward SAIF
Fo
• Tcl floorplan and DEF files

• Power intent as a UPF command script
• Scan chain information in SCANDEF format
ed
• Constraints in SDC format

• Timing contexts (scenarios)
er
In addition, the write_icc2_files command writes the following:

• The Design Compiler settings in IC Compiler II format
st
• The top-level script to load all data generated in IC Compiler II

i
eg
The following example writes the design files to be loaded in IC Compiler II in the icc2_files directory for
the current design:
R
dc_shell-topo> write_icc2_files -output icc2_files

Next, in IC Compiler II, use the design_name.icc2_script.tcl file to load all the design files, after
creating the library
icc2_shell> source icc2_files/my_design.icc2_script.tcl
High Fanout Synthesis Port Punching

Design/flow setup
 High fanout synthesis / buffering occurs during the initial_drc stage
y
nl
 By default, port punching may add or remove ports at hierarchy
O
boundaries for HF synthesis
se
 To disable port punching on specified cells:
U
al
set_freeze_ports –data|-clock|-all [get_cells cellA]
rn
te
In
s 3- 20
sy
To un-freeze the ports use:
set_freeze_ports –data|-clock|-all [get_cells cellA] false
op
To query the current status:

get_attribute [get_cells I_SDRAM_TOP] freeze_data_ports
yn
get_attribute [get_cells I_SDRAM_TOP] freeze_clock_ports

rS
Setting a dont_touch on a hierarchical cell will preserve the pins along the block boundary but will also
prevent optimization from modifying the internal block logic.
Fo
ed
er
i st
eg
R
Even Distribution of Spare Cells - Automatic

Design/flow setup
 Spare cells can be included in the synthesis netlist
y
 Included in the top module and/or sub-design modules
nl
 With identifiable instance or cell names
O
Spare cells will be placed along with regular standard cells, and
se

automatically spread out evenly
U
 Controlled by place.coarse.enable_spare_cell_placement Default: true
When set to false, spare cells are still placed, but not spread out evenly
al

rn
 Placement is hierarchy aware, so spare cells will be placed along with
te
their intended hierarchy 1
In
s 3- 21
sy
Spare cells are extra gates (ANDs, NORs, XORs, INVERTERs, etc.) which are included in a netlist but are
not functionally connected and used during the initial design phase. If a small functional change is required
op
late in the design cycle, called a “functional ECO”, the layout can be incrementally modified (routing or
metal mask changes only) to take advantage of these spare cells.
yn
1 During standard cell placement, all cells with the attribute is_spare_cell = true will be automatically
placed along with the standard cells. The placement is hierarchy-aware, meaning: Any spare cells that are at
rS
the top-level of the design netlist (top module), will be physically placed throughout the entire design; Spare
cells in sub-module A, for example, will be limited to a rectangular area defined by the placement of the
standard cells in module A.
Fo
ed
er
i st
eg
R
Spare Cells Identification – Automatic versus Manual

Design/flow setup
 All cells in the netlist have the attribute spare_cell_mode set to auto
by default
y
nl
 Cells auto-identified as spare cells will have is_spare_cell set to true
O
 Cells are identified as spare cells if:
 All inputs are floating or tied high or low
se
 Register clock, set/reset and scan pins can be connected
All outputs are floating
U

 Cell is not a physical-only cell
al
 Physical-only: Contain only PG pins or no pins, for example: tap, end-cap, filler cells
rn
 To manually mark cells as spare cells:
te
set_attribute [get_flat_cells *SPARE_REG*] spare_cell_mode true
In
s 3- 22
sy
The spare_cell_mode is the only attribute that should be manipulated by the user - do not
directly/manually modify the is_spare_cell attribute. The is_spare_cell attribute will automatically
be adjusted by the spare_cell_mode setting.
op
If no manual spare cell marking is needed, then no action is required.

yn
If cells are not recognized as spare cells, set the attribute spare_cell_mode to true for that cell.
If you don’t want a cell to be used as spare cell, set the attribute spare_cell_mode to false for that cell.
rS
To query all spare cells in the design, use: get_cells -hier -filter is_spare_cell
Fo
ed
er
i st
eg
R
Add Spare Cells Not Already in the Netlist

Post place_opt
 If your design doesn’t contain spare cells already, or you want to add
additional spare cells, you can add spare cells after place_opt as well
y
nl
Original netlist
O
place_opt ...
# Spare cells from design netlist are
# placed and spread during place_opt
se
20 sets of listed cells are
add_spare_cells \ spread evenly across the
U
core area; The cells
-cell_name SPARE_PREFIX_NAME \ (NOR2 NAND2) are placed
–lib_cell {NOR2 NAND2} \ close together as a set
al
-num_instances 20
legalize_placement -incremental
rn
set_placement_status legalize_only \
[get_flat_cells -filter is_spare_cell]
te
CTS and Routing
In
s 3- 23
sy
Cells added by add_spare_cells are coarse-placed, therefore you need to legalize the cell placement
afterwards.
op
Spare cells are not “fixed” in place, by default - CTS and routing optimizations can move them.
Setting the cells to “fixed” may impede the above optimizations, if there are many fixed cells.
Instead, set the placement status to “legalize_only” once the spare cells are distributed
yn
• Prevents placement and optimization from moving spare cells

• Cells can only be moved by the legalizer after CTS and routing optimizations, if needed
rS
set_placement_status legalize_only [get_flat_cells –filter is_spare_cell]

Fo
Any spare cells which are included in the netlist and tagged with the attribute is_spare_cell=true, will be
automatically placed and evenly spread during place_opt.
If you want to “manually” control the placement of spare cells prior to standard cell placement:
ed
# set_attribute [get_flat_cells *spare*] is_spare_cell true

# or cells recognized automatically at netlist-in stage
spread_spare_cells -cells [get_cells –hierarchical \
er
-filter is_spare_cel] -boundary {{10 10} {490 490}}

place_opt
st
If you want to “manually” control the placement of spare cells after standard cell placement:
i
place_opt
eg
spread_spare_cells -cells [get_cells –hierarchical \

-filter is_spare_cel] -boundary {{10 10} {490 490}}
R
legalize_placement
Remove Unwanted Ideal Networks

Design/flow setup
 Ideal network constraints on high fanout nets
y
D Q
(like set/reset, enable, select) prevent buffering
nl
E
during placement – probably not desired! D Q
O
 Can be found using report_ideal_network E
se
Enable
 Remove all ideal network constraints to allow
U
HFN buffering during placement:
D Q
al
E
remove_ideal_network -all
rn
D Q
E
te
In
s 3- 24
sy
An ideal network prevents Design Compiler from synthesizing buffer trees, to defer buffering to the physical
design phase (no longer recommended with DC-G).
op
To remove pre-existing buffer trees, use the command remove_buffer_trees.

yn
Note that the report_ideal_network command was introduced in ICC II 2017.09.

rS
Fo
ed
er
i st
eg
R
Library Cell Purpose

Design/flow setup
 Every library cell can be restricted to certain optimization tasks using

a library cell purpose (attribute: valid_purposes)
y
nl
O
 The following lib cell purposes are set by default:
power
se

 hold
U
 cts
optimization
al

rn
 If the original cells in the liberty library (used to create the CLIB) have
te
dont_use=true, then no purposes are set
In
s 3- 25
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Restrict Library Cell Usage

Design/flow setup
 You may want to restrict the use of specific cells during CTS, timing,
electrical DRC or power optimizations, for example:
y
nl
 Big drivers (EM or crosstalk issues)
High-leakage registers in ultra-low Vt libraries
O

set_lib_cell_purpose –include none \
se
[get_lib_cells "*/*BUF_X64* */*REG_ulvt*"]
U
 To determine the current lib cell purpose setting:
al
report_lib_cells -columns {name valid_purposes} \
rn
-objects [get_lib_cells "*/*BUFFX2*"]
IBUFFX2_HVT power optimization
te
NBUFFX2_HVT power hold optimization
TNBUFFX2_HVT power optimization
In
s 3- 26
sy
EM = Electro-migration
op
yn
rS
Fo
ed
er
i st
eg
R
Preroute Power Optimization

Design/flow setup
 By default, ICC II does not perform power optimization
y
 The following power optimization modes can be enabled:
nl
 Leakage
O
 Dynamic
 Total (leakage + dynamic)
se
set_app_options –list \
U
{ opt.power.mode none | leakage | dynamic | total }
al
 Power optimization is only performed in active scenarios enabled for
rn
power, for example to enable total power optimization:
set_scenario_status {func.ss_125c} \
te
-leakage_power true -dynamic_power true
In
s 3- 27
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Leakage Power Optimization

Design/flow setup
y
High-Vth Cells Trade-off Low-Vth Cells
nl
Slow, Low Leakage Fast, High Leakage
O
 Includes leakage power in the overall cost function for optimization
se
 Any optimization transformation will take leakage power into account, and therefore
leakage power will be reduced
U
 Leakage has a lower optimization priority (lower cost!) than timing/DRC
al
 Occurs if power optimization mode is leakage or total
rn
te
set_app_options –list {opt.power.mode leakage | total}
In
s 3- 28
sy
You will often see leakage power optimization referred to as “conventional leakage optimization”.
Leakage power consumption is stored in tables in the standard cell libraries
op
yn
rS
Fo
ed
er
i st
eg
R
Leakage Improvement by Vt Swapping

Design/flow setup
 In addition to cost-based leakage optimization, you can also enable

Vt swapping to possibly reduce leakage power further
y
nl
 Algorithm exchanges LVT cells with identical RVT or HVT cells,
O
if positive slack is available
se
 To enable, tag cells to be reduced (e.g. low- and ultra low-Vth) as low_vt:
U
set_threshold_voltage_group_type -type low_vt "LVt ULVt"
al
LVt and ULVt are defined in
the standard cell library
rn
 Vt swapping runs in all active scenarios, independent of whether any power
te
optimization is enabled, or whether the scenarios are configured for leakage opt.
In
s 3- 29
sy
In order to specify which cells are of a low_th threshold voltage group type (e.g.
set_threshold_voltage_group_type -type low_vt “LVt ULVt”), the standard cells must have a
specified threshold_voltage_group attribute value (e.g. LVt and ULVt, for this example).
op
If the standard cells do not have a specified threshold_voltage_group value, execute the following
yn
to tag each library cell with an appropriate threshold voltage group name:
rS
set_attribute -quiet [get_lib_cells -quiet */*ULVT] \

threshold_voltage_group ULVt
set_attribute -quiet [get_lib_cells -quiet */*LVT] \
Fo
threshold_voltage_group LVt
set_attribute -quiet [get_lib_cells -quiet */*RVT] \
threshold_voltage_group RVt
ed
set_attribute -quiet [get_lib_cells -quiet */*HVT] \

threshold_voltage_group HVt
er
(In the example above it is assumed that each standard cell ends with the key Vt identifying letters “ULVT”,
st
“LVT”, “RVT” or “HVT”, and the user has chosen to name their respective Vt voltage groups as “ULVt”,
i
“LVt”, “RVt” and “HVt”)

eg
The threshold_voltage_group attribute is also required for Vt reporting purposes (see next page).
R
Report Multi-Vt Cells

Design/flow setup
At any time, you can generate a report summarizing
y
how many cells are used per Vt type
nl
report_threshold_voltage_groups
O
**************************************** L denotes cells tagged as low_vt using
se
Report : threshold_voltage_group set_threshold_voltage_group_type
Design : ORCA_TOP
...
U
Vth Group All Blackbox Non-blackbox
Name cells cells cells
--------------------------------------------------------------------------------
al
HVt 24867 (48.43%) 0 (0.00%) 24867 (48.43%)
LVt 11312 (22.03%) 0 (0.00%) 11312 (22.03%) L
rn
SVt 14870 (28.96%) 0 (0.00%) 14870 (28.96%)
ULVt 298 (0.58%) 0 (0.00%) 298 (0.58%) L
--------------------------------------------------------------------------------
te
Total 51347 (100.00%) 0 (0.00%) 51347 (100.00%)
Low vth groups 11610 (22.61%) 0 (0.00%) 11610 (22.61%)
In
s 3- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Dynamic Power Optimization

Design/flow setup
 Includes dynamic power in the overall cost function for optimization
y
Any optimization transformation will take dynamic power into account
nl

 Has a lower optimization priority than timing/DRC
O
 Requires switching activity to calculate dynamic power
se
 Occurs if power optimization mode is dynamic or total
U
set_app_options –list {opt.power.mode dynamic | total}
al
rn
te
In
s 3- 31
sy
Power consumption data is stored in tables in the standard cell libraries.
op
yn
rS
Fo
ed
er
i st
eg
R
Dynamic Power Optimizations Require Switching Activity

Design/flow setup
 Accurate power calculation requires accurate switching activity:

 Applied by reading SAIF files from simulation (recommended)
y
set_scenario_status –dynamic_power true slow_ss125
nl
read_saif design_sim.saif –scenario slow_ss125
O
 Alternatively, by “manually” applying toggle information to
primary inputs and black box outputs
se
current_scenario slow_ss125
set_switching_activity [get_ports "rst scan_en"] \
U
–toggle_rate 0.0 -static_probability 0.0 a
set_switching_activity [get_ports a] \ b
–toggle_rate 0.02 -static_probability 0.7 scan_en
al
set_switching_activity [get_ports b] \ rst Black Box
clk
-toggle_rate 0.06 -static_probability 0.3
rn
set_switching_activity applied
Unannotated
 Unannotated points use default switching activity (see notes)
te
Propagated
 ICC II will propagate switching activity throughout the design
In
s 3- 32
sy
SAIF: Switching Activity Interchange Format is an open standard.
The following are standard terms used in SAIF: Toggle Count (TC): A toggle is a logic transition (01 or 10).
Toggle count (TC) is the number of toggles. Toggle Rate (Tr): Number of toggles per unit time (usually the
op
simulation duration). Tr = TC / duration. Synopsys has a utility to convert VCD (IEEE standard) into SAIF.
yn
toggle_rate
Specifies the value of the toggle rate in the switching activity. The rate is a floating point number that
rS
represents the number of 01 and 10 glitch-free transitions that the signal makes during a period of time.
You can specify the period with the -period option. Alternatively, you can annotate a related clock using
the -base_clock option, and the specified toggle rate is relative to the related clock period.
Fo
static_probability
The static probability value represents the percentage of time the signal is at the logic state ‘1’. For
ed
example, a static probability of 0.25 indicates that the signal is in the logic state ‘1’ for 25% of the time, and
‘0’ for the remaining 75% of the time.
er
set_switching_activity
-static_probability static_probability
st
-toggle_rate toggle_rate_value
[-state_condition condition_name]
[-path_sources path_sources]
i
eg
[-period period_value]
[-base_clock clock]
[-scenarios scenario_list] [-modes mode_list] [-corners corner_list]
object_list
R
Default switching activity application option settings – default values shown:

power.default_static_probability = 0.5
power.default_toggle_rate = 0.1
power.default_toggle_rate_reference_clock = fastest
Limitations with the set_switching_activity Approach

Design/flow setup
 Primary control inputs (reset, enable) that are not annotated by

set_switching_activity inherit default switching activity values
y
nl
 Since these inputs typically remain static, dynamic power calculations of the logic
associated with these control inputs can be pessimistically high
O
 Propagated switching activity of sequential output pins tends to
se
approach a zero toggle rate
 Dynamic power calculations of the downstream logic can be optimistically low
U
al
2018.06-SP4
rn
 infer_switching_activity will apply appropriate static values to
control signals, as well as better toggle rates for sequential output pins
te
In
s 3- 33
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Inferring Static Values for Control Signals

EP with static high/low inferred activity
 infer_switching_activity
identifies essential points (EPs)
y
D Q
such as sequential outputs and FF1
nl
n1
input ports1, that drive special
O
S
n3
control inputs (SCIs) such as D Q
FF1
D
FF
Q
resets and enables2 R
se
 An appropriate static high or low port:resetn
U
setting is applied to these EPs to D Q n2
ensure that no resetting, setting, FF2
al
clamping or sleeping occurs SCI
rn
 Based on the majority end-point port:sleep EP driving SCI
behavior3
te
en
port:data iso
In
s 3- 34
sy
1Essential points:
- Primary Input
op
- Primary inout – the ‘in’ part of the port

- Sequential outputs – not including sequential ICG cells
- Tri-state output
yn
- No-func – an output pin without a function describing its behavior, i.e. black box
- No-driver – a net without a driver
rS
2Special control inputs:

Fo
- Reset
- Set
- Scan Enable
ed
- Isolation control
- Power switch control
er
- ICG enable and retention control are not SCIs!

st
3If,for example, seven of the eight SCIs that are driven by an EP are active low reset pins, and one of them is
active high, then infer_switching_activity will apply a toggle rate of 0 and a static probability of 1 so
i
eg
that the majority if the SCIs are not in a reset state.

R
Inferring Switching Activity for Other Essential Points
 infer_switching_activity EP with inferred default activity

can also apply an inferred
y
D Q
n1
FF1
default activity to all EPs that
nl
do not drive any SCIs S
O
D Q
n3 D Q
FF1 FF
 Useful for all sequential output
se
R
pins, to avoid zero toggle rate

port:resetn
 The default activity is calculated
U
using the fastest clock period and D
FF2
Q n2
the values from the app options 1
al
 The inferred activity will override EP that does
rn
not drive SCI
the propagated activity port:sleep
te
en
port:data iso
In
s 3- 35
sy
The three application options used to calculate the default switching activity are
power.default_static_probability (0.5), power.default_toggle_rate (0.1) and
op
power.default_toggle_rate_reference_clock (fastest). The calculated toggle rate will be:

tr = default_tr * fclk
For example, if the fastest clock in the design has a period of 4, the frequency is 1/4=0.25.
yn
The toggle rate tr = 0.1 * 0.25 = 0.025.

You can use the clock connected to the actual register instead of the fastest in the design by setting
rS
power.default_toggle_rate_reference_clock to related.
Fo
The example shows EPs which have been identified as SCIs, and their inferred switching activity:
icc2_shell> infer_switching_activity –sci_based all
****************************************
ed
Report : infer_switching_activity
Design : ORCA_TOP
****************************************
Inferring activity for the scenario: func.ss_125c
er
Mode : func
Corner : ss_125c
Time Unit : 1ns
st
Fastest clock: SYS_2x_CLK with period 2.3

-----------------------------------------------------------------
Object Type : port
i
eg
Object Name : reset

Current Static Probability : 0.5
Current Toggle Rate : 0.1
Proposed Static Probability: 0
R
Proposed Toggle Rate : 0

Receiver Type: set | Receiver Count: 111
-----------------------------------------------------------------
Object Type : pin
Object Name : I_BLENDER_0/mega_shift_reg[5][27]/Q
Proposed Static Probability: 0.5
Proposed Toggle Rate : 0.0434783
Recommended Setup for infer_switching_activity

Design/flow setup
1. Use create_clock to define clock activity
y
2. Use set_switching_activity for any ports with known required activity
nl
current_scenario slow_ss125
O
set_switching_activity –toggle_rate 0.02 -static_probability 0.7 [get_ports a]
set_switching_activity -toggle_rate 0.06 -static_probability 0.3 [get_ports b]
se
…
U
3. Use infer_switching_activity for all remaining unannotated EPs
al
set_scenario_status –dynamic_power true slow_ss125
infer_switching_activity –sci_based all -apply \
rn
–output inferred_activity.tcl
te
In
s 3- 36
sy
The infer_switching_activity command will not apply the inferred activity automatically without the
specification of the -apply option. The user can execute the command without –apply to review inferred
activity only, and/or they can output the inferred set_switching_activity commands to a file for
op
sourcing separately. However, if the latter is done, the activity will be applied as ‘annotated’ activity rather
than ‘inferred’ activity, and activity of type ‘annotated’ will have a higher precedence than ‘inferred’.
yn
Consequently, any subsequent executions of infer_switching_activity will not change these values.
rS
In addition to infer_switching_activity there is also report_essential_points which can be

used to determine what EP is responsible for a particular control point in the design. Using this information
Fo
can help the user determine what activity should be annotated onto the design.
The example below shows how the command can be used to find the essential point(s) driving the reset pin of
the register. You can see that the reset_n port drives 1045 reset pins, and currently has a static probility of
ed
0.5 probability and a 0.125 toggle rate. This active-low port would typically need to be set to a static value of
‘1’ and a toggle rate of ‘0’ in order to ensure that the design is not being reset during power analysis.
er
icc2_shell> report_essential_points H6_reg_reg_1_/RD

...
st
Inferring activity for the scenario: virtual_scenario

Mode : func
Corner : ss_125c
i
Time Unit : 1ns

eg
Fastest clock: clk with period 0.8

-------------------------------------------------
Object Type : port
R
Object Name : reset_n

Receiver Type: reset | Receiver Count: 1045
-------------------------------------------------
Total Power Optimization

Design/flow setup
250 1.4
1.2
Dynamic Power (pin cap)

200
1
Leakage Power
 For FinFET technologies, leakage and 150
y
0.8
dynamic power may trend differently within
nl
100 0.6
a Vt class (different channel lengths) 50

0.4
O
0.2
 Leakage: XLVT-S > XLVT-L L=Long S=Short 0 0
XLVT-S XLVT-L
Dynamic: XLVT-S < XLVT-L
se

Leakage Power Dynamic Power (pin cap)
Total power optimization creates a composite cost of dynamic and
U

leakage power numbers and includes this composite cost in the overall
al
optimization costing function
rn
 Requires switching activity to calculate dynamic power
te
set_app_options -name opt.power.mode -value total
In
s 3- 37
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Test For Understanding (1 of 2)
1. Why would you want to exclude certain cells from being used during
optimization?
y
nl
O
2. For spare cells to be automatically recognized, all inputs and
se
outputs need to be disconnected.
True or False?
U
al
3. Effective leakage power optimization requires (circle all that apply):
rn
a. Multiple libraries with different timing/leakage characteristics
b. Net switching activity (toggle rate) information
te
c. set_scenario_status –leakage_power true applied to all active scenarios
In
s 3- 38
sy
op
yn
rS
Fo
ed
er
1. It might be beneficial to prevent optimization from using certain cells, like high-pin-count (to reduce
congestion), very strong cells (to avoid potential EM or crosstalk issues), or ULVt registers (to reduce
st
leakage power without sacrificing critical timing).

2. False. The spare cells’ inputs need to be either floating or tied, while clock, set/reset and scan pins of
i
eg
spare registers can be connected; outputs should be floating.

3. A. B is incorrect because switching activity is only used during dynamic/total power optimization. C is
R
incorrect, because the sentence says “all” scenarios. Only one scenario is required to be enabled, at a
minimum.
Test For Understanding (2 of 2)
4. Why would you run place_opt stages individually?
y
nl
O
se
5. Which stages of place_opt are skipped when you enable SPG?
U
al
rn
te
In
s 3- 39
sy
op
yn
rS
Fo
ed
er
i st
eg
4. To speed up the QoR iterations: Serious congestion and/or timing issues can be uncovered and addressed
earlier.
R
5. The first two stages: initial_place and initial_drc
Congestion-Focused Setup Steps

Congestion
Design Setup
y
Pre-placement
 After running place_opt analyze
nl
check
congestion and cell/pin density
O
Design and flow
requirement setup
Congestion-focused setup  Perform the following setup steps, as
se
applicable, to improve routability
QoR setup Timing-focused setup
 Increase placement and congestion effort levels
U
Placement and Power/Area-focused setup  Enable global route-based HFS and DRC Fixing
Optimization
al
 Apply keepout margins and placement blockages
Placement
 Enable per-layer congestion and
rn
CTS pin access checking and optimization
Run congestion-driven restructuring (CDR)
te

In
s 3- 40
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Global-Route Congestion Analysis

Congestion
 After any placement run, first analyze congestion
y
Low effort level is recommended for faster runtime
nl

(default is medium)
O
 Results tend to be pessimistic
se
route_global –congestion_map_only true -effort_level low
U
 If congestion is borderline, re-analyze with a higher effort level
al
 More accurate results helps to prevent fixing non-existent congestion problems
rn
route_global –congestion_map_only true –effort_level medium|high|ultra
te
In
s 3- 41
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Global Route Congestion Map

Congestion
y
nl
O
+0/20
se
+7/18 +4/20
U
Congestion segment labels
al
GRC grid
rn
+1/20
te
In
route_global –congestion_map_only true -effort_level ...
s 3- 42
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Congestion Segment Labels

Congestion
 The congestion segment labels have the format:
y
 “Signed congestion overflow” / “total supply”
nl
 (both numbers are in units of routing tracks)
O
 For example, this segment: +4/20
se
Layer Demand Supply Overflow
M1 10 8 +2
U
M3 9 7 +2
M5 1 5 ‐4
al
rn
 Capacity (supply): 20 tracks
 Overflow: +4 tracks
te
 Underflow (here -4) is counted as 0
In
s 3- 43
sy
Congestion calculation calculates the track usage for each layer and displays it in the GUI. Two methods will
be supported in IC Compiler and IC Compiler II:
op
• Sum of overflow for each layer (new default since K-2015.06)

• Total demand minus total supply (old default in previous releases)
The new default was introduced because of too much optimism in the old method.
yn
rS
Fo
ed
er
i st
eg
R
Increase Placement/Congestion Effort

Congestion
 Increasing the congestion effort to high (default is medium) generally

improves congestion, at a cost of runtime and possible timing degradation
y
 Relevant during final_place, and during initial_place when using
nl
two-pass placement (discussed later)
O
 Increasing the final_place effort level to high may improve congestion
se
 May also improve timing
U
set_app_options –name place_opt.congestion.effort –value high
al
set_app_options –name place_opt.final_place.effort -value high
rn
te
In
s 3- 44
sy
The initial_place stage is, strictly speaking, not directly congestion-driven: It is focused on reducing the
overall wirelength, which can, indirectly, be beneficial in improving congestion.
op
yn
rS
Fo
ed
er
i st
eg
R
Global Route-Based HFS and DRC Fixing (GR-opto)

Congestion
y
nl
 For macro-dominated designs, GR-opto
can reduce congestion and improve routability
O
 Global routing is used to improve buffer placement for high-fanout and
se
DRC-violating nets – reduces congestion for nets crossing numerous channels
 Timing analysis (net delay modeling) is still based on virtual route
U
 Benefits the initial_drc stage (Intended for non-SPG flow)
al
rn
set_app_options –list {place_opt.initial_drc.global_route_based 1}
te
 The default is 0
In
s 3- 45
sy
GR-opto mainly helps on channel-based designs to ensure that buffering is picking the right channels and not
overflowing channels.
GR-opto is performed, by default, in DC-G: set_ahfs_options -global_route true
op
yn
rS
Fo
ed
er
i st
eg
R
Keepout Margins and Placement Blockages

Congestion
Apply new, or modify existing keepout margins and/or placement blockages
y
nl
O
se
RAM5
U
al
rn
create_keepout_margin RAM5 \ create_placement_blockage –name LL \
-outer {15 0 18 0} \ –boundary {{345 355} {392 400}} \
te
-type hard|soft -type hard|soft
In
{left bottom right top}
s 3- 46
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Cell and Pin Density Analysis

Congestion
 In addition to global route congestion, the GUI provides

powerful tools to analyze cell and pin density
y
 Help to further understand the causes of congestion
nl
O
se
U
al
rn
te
In
s 3- 47
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Is High Cell Density Causing Congestion?

Congestion
Congestion map
y
 The placer may create high density
nl
areas when optimizing for timing,
O
which can cause congestion
se
 Look at a cell density map
U
 If cell density hotspots coincide with
congestion hotspots  Lower cell density in
al
that area
rn
te
Cell density map
In
s 3- 48
sy
As of ICCII 2016.03-SP5, maximum density and congestion-driven max utilization are set automatically.
You will see messages such as this during placement operations:
Information: Automatic density control has selected the following settings:
op
max_density 0.20, congestion_driven_max_util 0.87. (PLACE-027)

yn
See “Controlling Cell Density” page in the “timing QoR” section for more details on automatic density
control.
rS
Fo
ed
er
i st
eg
R
Limit Cell Density with Partial Blockages

Congestion
y
100,160
nl
O
se
10,20
# Define an area with a maximum utilization of 40%
U
create_placement_blockage –boundary {{10 20} {100 160}} \
-type partial -blocked_percentage 60
al
# Max utilization 30%, allow buffers and inverters only
rn
create_placement_blockage -boundary {{10 20} {100 160}} \
-type allow_buffer_only -blocked_percentage 70
te
# Max utilization 80% partial blockage, no registers allowed
create_placement_blockage -boundary {{10 20} {100 160}} \
In
-type register -blocked_percentage 20
s 3- 49
sy
A “category” type blockage can be used to create user-defined partial blockages. In the example below, the
“dual rail” registers, *dffdr*, are to be completely blocked within a specified boundary:
# Define user attribute BEFORE "link":
op
define_user_attribute -type boolean -class lib_cell DUAL_RAIL

# Apply attribute to the lib_cells to be blocked:
yn
set_attribute [get_lib_cells */dffdr*] DUAL_RAIL true

# Create a category-type blockage, specifying the user-defined
rS
# attribute name as the “-category” name, with 100% blockage:

create_placement_blockage -type category -category DUAL_RAIL \
-blocked_percentage 100 –boundary {{900 800} {1200 880}} -name NO_DUAL_RAIL
Fo
ed
er
i st
eg
R
Considering the Congestion of Each Layer

Congestion
20/22nm and below
y
 Congestion reduction during coarse placement is improved by
nl
considering congestion of each layer separately:
O
place.coarse.congestion_layer_aware Default: true 2018.06-SP4
se
 Prior versions have default: false
U
 Helps to identify congestion in areas with high pin densities that have insufficient
resources on the lower layers for pin connections
al
 Allows for better placement to reduce this type of congestion
rn
te
In
s 3- 50
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Optimizing Pin Access

Congestion
20/22nm and below
 Enable pin density awareness during coarse placement
y
 ICC II will automatically calculate a maximum pin density based on the design
nl
and try to respect it during cell placement
O
place.coarse.pin_density_aware Default: false
se
Enable pin optimization during legalization
U

 Improves the routability of areas with high pin densities by redistributing the cells
al
place.legalize.optimize_pin_access_using_cell_spacing Default: false
rn
Affects the “Classic Legalizer” only.
te
The Advanced Legalizer performs advanced pin access optimization by default
In
s 3- 51
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Congestion-Driven Restructuring (CDR)

Congestion
 Designs with complex

AOI/OAI logic structures can
y
cause many net crossings,
nl
thereby creating substantial
core congestion hotspots
O
Congestion
 CDR identifies tangled nets map
se
that drive input pins of
commutative and associative
U
logic trees ((N)AND/OR/XOR
al
trees), reorders and places Best non-CDR result With CDR
them more optimally
rn
 Alleviates congestion
te
Cell density
 Reduces wire length map
In
s 3- 52
sy
From the “non-CDR” congestion and cell density maps on the left, notice that in the area with high
congestion, there is actually low cell density - the placer avoids placing cells in high congestion areas. This
op
can lead to higher cell density, and therefore increased congestion in surrounding areas.
On the right, once CDR untangles the net crossings and thereby eliminates the congestion, the placer is now
yn
able to place more cells in this same area, which can help to reduce congestion in surrounding high cell
density areas.
rS
Improve wire length and routability:

1. Find commutative-associative pins in logic trees:
Fo
A+B=B+A
(A + B) + C = A + (B + C)
2. Optimize the connections of their driving nets to achieve better wire length, a.k.a “rewiring”
ed
er
i st
eg
R
CDR Setup
Congestion
 Congestion-Driven Restructuring is enabled by default
y
place.coarse.cong_restruct Default: on
nl
By default, one iteration of placement and rewiring will be run during
O

the initial_place stage of place_opt
se
 To increase the number of iterations, use:
place.coarse.cong_restruct_iterations Reasonable values: 1-2
U
 Control the CDR effort level using:
al
place.coarse.cong_restruct_effort Default: medium
rn
 Controls the size of the netlist subset that is made available to CDR
te
 Allowed values: low, medium, high, ultra
In
 Higher efforts consider trees with fewer input pins
s 3- 53
sy
The CDR feature is enabled by default starting with release 2016.12-SP2. Before then, you had to enable this
feature explicitly.
op
place.coarse.cong_restruct_effort
• The low and high effort settings operate differently from the medium effort by importing a
yn
smaller or larger set of permutable pin arrays into the placer

• By default (medium) only trees with >= 8 input pins are considered
rS
• Higher efforts will also consider trees with less than 8 input pins
• The ultra effort mode imports into the coarse placer not only the leaf-level pin arrays of the
Fo
associative commutative trees, but the entire trees instead, allowing rewiring of connections
along multiple cuts inside these trees during placement
ed
er
i st
eg
R
CDR with SPG

Congestion
 CDR is not supported when using SPG place_opt
y
 With SPG, the initial_place stage, where CDR is performed, is skipped
nl
 If you want to use CDR in an SPG flow, use the following flow
O
 The create_placement command starts by performing CDR on the existing
placement, followed by incremental placement (3 iterations)
se
SPG flow
set_app_options -list {place_opt.flow.do_spg true }
U
set_app_options -list {place.coarse.cong_restruct_strategy original}
al
create_placement
rn
set_app_options -list {place_opt.flow.do_spg false}
place_opt -from initial_drc
te
Reminder: Apply all congestion-focused controls to
In
the initial design and re-run place_opt
s 3- 54
sy
Under normal circumstances you should not have to change the application option
place.coarse.cong_restruct_strategy from its default value “embed”. The example shown above is
only recommended if you want to force the use of CDR in an SPG flow.
op
In an SPG flow, create_placement starts by performing restructuring/pin reordering (honoring the current
yn
SPG placement), after which it performs incremental placement. Overall, 3 iterations of CDR occur (CDR,
place, CDR, place, CDR). This is controllable with place.coarse.cong_restruct_iterations.
rS
After the first initial-placement it is important to turn off SPG, otherwise the place_opt command would
not perform the initial_drc stage.
Fo
ed
er
i st
eg
R
Test For Understanding
1. Which designs would benefit the most from Global Route-Based HFS
y
and DRC Fixing (GR-opto)?
nl
O
se
2. What are some placement blockage types, in addition to hard and soft?
U
al
3. Which designs would probably benefit from Congestion Driven
rn
Restructuring (CDR)?
te
In
s 3- 55
sy
op
yn
rS
Fo
ed
er
st
1. GR-opto will primarily benefit designs that are macro-dominated. Global routing can help build better
(less congested) high-fanout trees when HFNs crosses numerous channels.
i
eg
2. Additional –type values: partial, allow_buffer_only, register (which does not allow
registers); Each of these types also requires a –blocked_percentage value.
R
3. Designs with associative/commutative (N)AND / (N)OR / X(N)OR tree structures.
Timing-Focused Setup Steps

Timing
Design Setup
 Once congestion is acceptable,
y
Pre-placement analyze timing and logical DRCs
nl
check
 Perform the following setup steps,
O
Design and flow
requirement setup
Congestion-focused setup
as applicable, to improve timing
se
 Use Design Fusion
 Auto Timing Control
U
Placement and Power/Area-focused setup  Buffering Aware Placement
Optimization
 Enable two-pass placement flow
al
Placement  Control cell max density
rn
CTS  Stream legalization
Enable ICG optimization
te

In
s 3- 56
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Timing/DRC QoR Summary Report

Timing
icc2_shell> report_qor -summary

****************************************  Use report_qor -summary
Report : qor
to obtain a summary of timing
y
-summary
Design : ORCA
violations across all active
nl
...
**************************************** This scenario was probably
not active during place_opt scenarios, listed by type
O
Timing
---------------------------------------------------------------------------
Context WNS TNS NVE (setup, hold), and number of
---------------------------------------------------------------------------
logical DRC violations
se
func.ss_125c (Setup) -0.07 -1.42 47
func.ss_m40c (Setup) 0.19 0.00 0
test.ss_125c (Setup) -2.55 -1694.98 1008
Design (Setup) -2.55 -1696.06 1008  Use report_timing for
U
func.ff_125c
func.ff_m40c
(Hold)
(Hold)
-0.40
-0.52
-25.35
-36.76
677
754
violating timing path details
test.ff_125c (Hold) -0.90 -133.93 4814
al
Design (Hold) -0.90 -134.65 4846
---------------------------------------------------------------------------
 Use report_constraints \
Hold is not addressed
-all -max_tran|-max_cap
rn
Miscellaneous during place_opt
---------------------------------------------------------------------------
Cell Area (netlist): 446630.01 for violating DRC details
te
Cell Area (netlist and physical only): 448978.30
Nets with DRC Violations: 32
In
s 3- 57
sy
WNS = Worst negative slack
TNS = Total negative slack
op
NVE = Number of violating endpoints

yn
rS
Fo
ed
er
i st
eg
R
Capture Comprehensive Design Metrics

Timing
icc2_shell> create_qor_snapshot –name place_opt
icc2_shell> report_qor_snapshot -display
# or later from Linux:
y
% firefox snapshot/index.html
nl
O
se
U
 Setup/Hold Timing across all scenarios
al
 Numbers of violations (max tran/cap/…)
rn
 Cell/buf/inv counts, memory/CPU stats
te
 Timing histograms
In
 Links to detailed reports s 3- 58
sy
This capability was introduced in ICCII 2016.12-SP2.
Execute create_qor_snapshot after each key optimization or design transformation phase, and specify
op
an appropriate –name, e.g. placed in this example. This command creates a directory called snapshot,
which contains several files, with the –name prefix (placed_ in our example), which contain the bulleted
yn
list of information above.

rS
With report_qor_snapshot, you can report a previously generated snapshot. If you use the
–name option, the command will display the named snapshot. If you don’t specify the -name option, all
Fo
previously stored snapshots will be reported. The command also creates a snapshot/index.html file,
which will also contain either the named report, or an index to all reports if the -name option is left off. If
you use the -display option, ICCII will display the result in its built-in browser.
ed
From the index file display, click on a link of interest in the left-most column to open the QoR snapshot
er
report on the right, to see detailed stats per clock path group for all scenarios.
i st
eg
R
Analyze Metrics in Depth

Timing
create_qor_snapshot –name place_opt

report_qor_snapshot
query_qor_snapshot -name place_opt -display
y
nl
O
se
U
al
rn
 Generates table from the QoR snapshot
 Click on the entries for more information
te
 Apply Filtering (false paths)  ignore outliers
In
 Select paths to highlight in the layout
s 3- 59
sy
Filtering:
If, for example, you see a violation on a path that you know should be a false path: Check the box in the left
op
“False Path” column, associated with the violating paths, then select “Create False Paths”. The specified false
path commands are then displayed, and you will be asked whether you want to save the exceptions to a file.
You can also use this technique early in your design cycle if you see paths that have unreasonably large
yn
violations, possibly due to incorrect synthesis.

rS
Fo
ed
er
i st
eg
R
Design Fusion - Logic Restructuring for Area and Timing

Timing + Area
2018.06-SP2
 Design Fusion: Uses the synthesis engine in ICC II to perform logic
restructuring, ensuring the best QoR for area and timing
y
nl
 Restructuring for area is a new optimization technique introduced in ICC II
Restructuring for timing replaces existing ICC II native restructuring capabilities
O

se
 Logic Restructuring is enabled during place_opt final_opto and
U
clock_opt final_opto
al
rn
 Expect to see timing and area improvements and secondarily, leakage
power improvement
te
In
s 3- 60
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Logic Restructuring for Area and Timing

Timing + Area
Area restructuring finds

functionally equivalent
cones of logic that improve
y
area/leakage without
nl
degrading timing
O
se
Timing-based
U
restructuring solutions
are evaluated in parallel
al
with other transforms
rn
like sizing and buffering,
to find the best overall
te
timing solution
In
s 3- 61
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Design Fusion – Logic Restructuring for Area and Timing

Timing + Area
 Enable logic restructuring using
y
nl
opt.common.advanced_logic_restructuring_mode Default: none
O
 Values: “none”, “area”, “timing”, “area_timing”
se
 Requires the RTL2GDS Advanced Fusion Add-on key
U
 place_opt and clock_opt commands will exit immediately when the feature is
al
enabled but the necessary license is not available
rn
te
In
s 3- 62
sy
The following messages indicate that logic restructuring is enabled:
Information: Configuring Design Fusion Restructuring for area ...
Information: Configuring Design Fusion Restructuring for timing ...
op
Cell naming conventions for cells added during logic restructuring:

yn
Logic restructuring for Area: SGI*

Logic restructuring for Timing: ctmTdsLR_*
rS
Restructuring does not occur across logical hierarchies.

Fo
Cells with dont_touch/size_only/fixed attributes will not be considered for restructuring. Refer to the log
message for details
Information: Design Fusion Restructuring targeted 11750 cells out of which 588 are not
ed
optimizable. (OPT-800)
Check your constraints if the majority of the cells are reported as not optimizable.
er
i st
eg
R
Restructuring – Wire Length Cost

Timing + Area
 By default, restructuring moves will be rejected in case of wire length

increase, which can be modified by:
y
nl
opt.common.advanced_logic_restructuring_wirelength_costing Default: high
O
medium: more area reduction; restriction on wire length increase is relaxed
se

 none: maximum area reduction; no restriction on wire length increase
U
al
 Apply “medium” or “none” settings on designs with few routing
rn
challenges to get more benefits out of logic restructuring
te
In
s 3- 63
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Timing Driven Placement 2018.06

Timing
 In release 2018.06, Automatic Timing Control is now on-by-default
y
nl
 Automates and takes care of many issues that required intervention:
O
 Placement focused too much on WNS/near-WNS, too little on TNS
se
 Less critical paths were not adequately placed
 Typical workarounds were to create additional weighted path groups,
U
add move bounds and set net weights
 These workarounds should not be required any longer!
al
rn
place.coarse.auto_timing_control Default: true
te
In
s 3- 64
sy
When this feature is enabled, the following output is added to the log
Information: Automatic timing control is enabled
op
This setting, when on, will also enable TNS driven placement, which focusses on all violating timing
endpoints (used to be enabled using place.coarse.tns_driven_placement – no longer necessary)
yn
place.coarse.auto_timing_control is available in 2017.09 as well, but there it needs to be set to true

rS
(default is false)
Fo
ed
er
i st
eg
R
Buffering Aware Timing Driven Placement (BAP) 2018.06

Timing
Buffering Aware Placement improves initial placement by:
y
 Estimating the timing of un-buffered long nets and high fanout nets
nl
 Performing timing-driven placement
O
se
place_opt.initial_place.buffering_aware Default: true
U
 Applies to non-SPG flow only
al
 Without BAP enabled, initial placement is wire-length driven
rn
 In 2018.06, BAP is supported together with Congestion Driven Restructuring (CDR)
 had to be run serially in previous releases
te
In
s 3- 65
sy
Historically, initial_place performed wirelength driven placement, which could lead to poor register
placement, making it hard to fix critical paths later in the flow. Simply running timing-driven placement as
op
initial placement is problematic, as un-optimized netlists will dominate the timing and appear critical, leading
to poor placement, which can be difficult to recover from later in the flow.
yn
With buffering aware timing driven placement, the delays of un-optimized long or high-fanout nets are
modeled as though they have already been buffered, resulting in more accurate timing-driven placement.
rS
Buffering Aware Placement is on-by-default starting with version 2018.06.

Fo
Prior to that, the application option had to be enabled explicitly, or it could be enabled by executing:
create_placement -buffering_aware_timing_driven
ed
er
i st
eg
R
Two-Pass Placement Flow

Timing
 For macro-dominated designs, enabling the two-pass initial placement

flow, in addition to GR-opto, can improve timing and congestion
y
nl
 In the two-pass flow, the initial_place phase performs:
1. Buffering aware timing-driven coarse placement
O
2. Trial HFNS
se
3. Timing- and congestion-driven placement
 The trial HFNS result is discarded
U
 Remaining place_opt phases remain unchanged
al
 Affects the initial_place stage  Applies to non-SPG flow only
rn
te
place_opt.initial_drc.global_route_based 1 \
place_opt.initial_place.two_pass true }
In
s 3- 66
sy
While an SPG flow is generally recommended for timing-critical designs, it is possible that a non-
SPG flow with two-pass placement may achieve slightly better results. Therefore, if the QoR after
op
SPG placement is not acceptable, and you can afford the additional run time, try both flows and
compare results. Note: The QoR difference between these two flows is entirely design dependent. If
yn
one design shows better results with a two-pass placement flow compared to and SPG flow, do not
assume that this will be true for all designs.
rS
Fo
ed
er
i st
eg
R
Controlling Cell Density

Timing / Congestion
 By default, ICC II sets the placer density settings depending on the
y
placement stage
nl
place.coarse.auto_density_control Default: true
O
se
 Controls two aspects:
 Cell max density / clumping
U
 How densely cells are placed during coarse placement
Congestion-driven max utilization
al

 How densely cells are placed in less congested areas that surround highly congested
rn
areas, so that the cells in the congested areas can be spread out to reduce the
congestion
te
In
s 3- 67
sy
As of ICCII 2016.03-SP5, maximum density and congestion-driven max utilization are set automatically.
You will see messages such as this during placement operations:
Information: Automatic density control has selected the following settings: max_density
op
0.20, congestion_driven_max_util 0.87. (PLACE-027)

yn
The following settings will be applied when place.coarse.auto_density_control is true (default):

step max_density max_util
create_placement 0.20 0.87
rS
place_opt/initial_place 0.20 0.87

create_placement -inc 0.60 0.87
place_opt/final_place 0.70 0.90
Fo
clock_opt/final_opto 0.80 0.93

ed
er
i st
eg
R
Setting Cell Density Manually

Timing / Congestion
 To manually set the placement density parameters, change

auto_density_control to false
y
nl
Cells are spread evenly
 By default, the following settings will be in place:
O
place.coarse.max_density Default: 0
place.coarse.congestion_driven_max_util Default: 0.93
se
 Max density: choose a value between 1 and the overall utilization of the block
U
 If the design’s utilization is 40%, use a number between 0.4 and 1
al
 The closer to 1, the tighter the clumping
rn
set_app_options -list {place.coarse.max_density 0.7}
te
In
* See note below on situations where user value can override even if auto_density_control=true
s 3- 68
sy
*Be aware that automatic density control can be overridden even if set to true:
• place.coarse.max_density: the user-specified value is used if the option is set to a value larger than
op
the average utilization.

• place.coarse.congestion_driven_max_util: The minimum of the user-specified and tool-
derived value is used if set to a value larger than the average utilization
yn
Once you set plan.place.auto_max_density to false, you control the following app. options:
rS
place.coarse.max_density
By default (0), placement is uniform. Specifying a value of 0.75, for example, brings related cells closer,
Fo
up to 75% cell density. This variable only affects coarse placement.

place.coarse.max_density is a global value, and is specified for the entire block: There is no way
to specify different values for voltage areas, exclusive bounds or plan groups, which may have different
ed
average densities than the average overall design density. You can use partial blockages to control the
density of specified areas independently.
er
place.coarse.congestion_driven_max_util
The default value is 0.93, which allows the utilization of non-congested areas to increase up to 93% in
st
order to reduce congestion in congested areas. Reducing the value to 0.85 (allowed values are 0 - 1.0), for
example, will keep more clumped cells together.
i
eg
This setting is respected when congestion removal is enabled (controlled by

place_opt.congestion.effort, which is set to medium by default)
During congestion removal, congestion_driven_max_util overrides the max_density percentage in
R
areas where the cells are being moved to.
Reporting Design Utilization
report_utilization
 Reports the utilization and area statistics used by certain objects:
y
Utilization Ratio: 0.4929
nl
Utilization options:
- Area calculation based on: site_row of block ORCA_TOP/init_design
O
- Categories of objects excluded: hard_macros macro_keepouts soft_macros
io_cells hard_blockages
Total Area: 678847.8506
se
Total Capacity Area: 355617.5997
Total Area of cells: 175285.9124
Area of excluded objects:
U
- hard_macros : 281086.9456
- macro_keepouts : 58615.0097
- soft_macros : 0.0000
al
- io_cells : 0.0000
- hard_blockages : 0.0000
rn
 Also possible for a user-specified region: report_utilization –region {…} 2018.06
te
 Customize the calculation using: create_utilization_configuration
In
s 3- 69
sy
Utilization Ratio = Total Area of cells / Total Capacity Area
The default “Area calculation based on” capacity type is is site_row (other types: core_area,
op
boundary, site_array):
Total Capacity Area (based on site rows) = Total area of site rows - Total area of “excluded objects”
yn
The “Categories of objects excluded” is, by default: hard_macros + macro_keepouts +

soft_macros + io_cells + hard_blockages.
rS
Note: If the macro keepouts are large enough where they overlap, and/or they extend outside the core area,
then a number smaller than the reported “macro_keepouts” area will be subtracted from the “Total
Fo
Area” to calculate the “Total Capacity Area”.

All of the above means that, by default, the reported “Utilization Ratio” is the standard cell utilization,
calculated as: Total Standard Cell Area / Total Standard Cell-only Placement Area. The area calculation
ed
capacity type and excluded objects can be modified with: create_utilization_configuration

er
You can also report the utilization for other objects:

icc2_shell> report_utilization -of_objects [get_voltage_areas PD_RISC_CORE]
st
...
Utilization Ratio: 0.8036
i
Utilization options:
eg
- Area calculation based on: Voltage area PD_RISC_CORE

- Categories of objects excluded: None
R
Total Area: 87651.4253

Total Capacity Area: 87651.4253
Total Area of cells: 70439.4306
Review the man page for more information on -region.
Legalization: Minimizing Large Displacements

Timing
 During legalization, cells could potentially be moved far away,

thereby degrading the timing
y
nl
O
se
U
al
rn
te
In
Default legalization behavior s Better: avoid large displacement 3- 70
sy
The large illegal cell on the left should ideally stay where the placer has placed it, in order to meeting timing.
Ideally, it should not move, but instead other cells should be moved to nearby locations.
op
yn
rS
Fo
ed
er
i st
eg
R
Stream Legalization Targets Smaller Moves

Timing
20/22nm and below

 Stream legalization performs multiple small moves
in order to avoid few large moves
y
 Overall, the original illegal cell stays, other small cells around it are moved slightly
nl
O
1 2 1 2
se
3
U
4 5 4 3
al
6 5
rn
6
te
In
s 3- 71
sy
The final picture on the right shows all the cells that had to be moved in order to allow for the large cell to
stay at its original location.
op
yn
rS
Fo
ed
er
i st
eg
R
Enable Stream Legalization

Timing
Options apply to the “Classic Legalizer” only. 20/22nm and below

The Advanced Legalizer stream-legalizes by default.
y
 To enable stream legalization, use the application option:
nl
place.legalize.stream_place Default: false
O
 Control stream legalization further using:
se
place.legalize.stream_effort Default: low
U
 Setting to higher efforts will improve the accuracy of stream placement and may
result in better displacements at the expense of runtime
al
rn
place.legalize.stream_effort_limit Default: 10
Measured in units of effort relative to design size. As a rule of thumb:
te

 Set the limit to 10 for fast runtime at the expense of displacement
In
 Set it to 100 for higher runtime and reasonable displacement
s 3- 72
sy
The stream legalizer doesn’t make cell displacements worse. It works on the cells with worst cell
displacements first. When the effort limit is reached, it stops working on the remaining cells with large
op
displacements.
yn
Along with stream legalization, you should also consider enabling the application option
place.legalize.optimize_orientations. Orientation optimization changes cell orientation to
rS
satisfy design rules during legalization and avoid cell displacement. This application option targets smaller
design nodes (<= 12 nm).
Fo
ed
er
i st
eg
R
Post-CTS ICG Enable Timing Problem

Timing: ICG enable
 Clock tree synthesis balances the clock latencies to all leaf-level register
clock pins (not ICGs) in the same clock tree : Latency1 ≈ Latency3
y
nl
 The larger the ICG downstream clock latency,
the more critical the ICG enable timing
O
 Can cause ICG enable setup timing violations
se
Latency1 Ctrl
U
al
Critical ICG enable timing path
rn
EN FF
FF
ICG FF
CLK FF
te
Latency3
ICG Downstream Clock Latency
In
Latency2 ≈ Latency1 – Latency2
s 3- 73
sy
ICG cell = Integrated clock gating cell: Inserted by Power Compiler during synthesis.
CTS = clock tree synthesis
op
Clock tree synthesis (CTS) will try to balance the delays from the clock root (the CLK port in the example
above) to all the leaf-level registers, namely the FF and the Ctrl registers above. This means that the clock
yn
latency to the Ctrl register, Latency1, will be approximately equal to the clock latency to the FF
registers, Latency3 (there will always be some clock “skew”, which is why the latencies will be
rS
approximately, not exactly the same).

Fo
Since Latency1 ≈ Latency3 = Latency2 + ICG Downstream Latency, you can infer that
ICG Downstream Latency ≈ Latency1 - Latency2, which is the difference in launch versus
capture clock latencies for the ICG Enable data.
ed
This means that the larger the ICG downstream clock latency is, the smaller the “effective clock period”
between the Ctrl register and the ICG is, which reduces the amount of time available for the enable control
er
signal to meet the setup timing of the enable pin of the ICG. This can create or worsen ICG enable setup
timing violations.
i st
eg
R
Pre-CTS ICG Enable Timing is OPTIMISTIC

Timing: ICG enable
 Pre-CTS clock latencies are “ideal” to all clock pins

 Latency1 = Latency2 = Latency3
(By default 0ns, or defined by set_clock_latency)
y
nl
 Causes optimistic ICG Enable setup timing analysis
Actual ICG enable violations are not seen, therefore not fixed, until after
O

CTS – too late in the design phase to fix effectively
se
Latency1 Ctrl
U
al
Optimistic ICG enable timing
rn
EN FF
FF
ICG FF
CLK Latency3 FF
te
Pre-CTS:
In
Latency2 ICG Downstream Clock Latency = 0
s 3- 74
sy
Pre-CTS, timing analysis uses “ideal” clock latencies for ALL clock pins: Ideal clock latencies are 0ns, by
default, unless specified by the user with set_clock_latency.
op
In the example above, this means that Latency1 = Latency2 = Latency3 (which also implies that the
“ICG downstream clock latency” is zero). Since there is no difference between Latency1 and Latency2,
yn
timing analysis of all ICG enable paths is optimistic. This, in turn, means that the actual post-CTS ICG enable
timing violations will either seem much smaller, or will not violate at all during the placement phase, so logic
rS
optimization during placement will not fix them. Waiting until post-CTS optimization to fix these ICG enable
timing violations reduces the chances of success.
Fo
ed
er
i st
eg
R
Solution: ICG Optimization

Timing: ICG enable
 ICG optimization is recommended for designs with

critical ICG enable timing
y
nl
 Primary goal: Minimize ICG enable setup timing violations
May increase dynamic power dissipation in the clock network
O

 ICG optimization is executed during place_opt, and performs:
se
 Trial CTS
initial_place
U
 ICG splitting
 Clock-aware placement initial_drc • Trial CTS1
al
• Critical ICGs identified
initial_opto • Timing-aware splitting
rn
• CTS update
• Clock-aware placement
te
final_place • CTS update
Trial means that the clock trees will be
In
discarded prior to actual CTS with clock_opt final_opto
s 3- 75
sy
1Note:In an SPG flow, even though initial_place and initial_drc are skipped, “trial CTS” is still
performed.
op
Critical ICGs can be identified in the initial_opto stage because a light timing optimization is
performed first.
yn
rS
Fo
ed
er
i st
eg
R
Trial CTS
Timing: ICG enable
 ICG optimization first performs clock tree synthesis (CTS)

 Enables accurate identification of critical ICG enable timing paths for:
y
 Effective ICG splitting and clock-aware placement (explained next)
nl
 Accurate datapath optimization of timing-critical ICG enable paths
O
 Requires complete CTS setup for good correlation to final CTS
 Clock tree is kept (and updated) throughout all place_opt stages
se
 Results in more accurate general datapath optimization
 Discarded prior to actual CTS (during clock_opt) Ctrl
U
al
rn
Accurate ICG enable timing
EN FF
FF
ICG
te
FF
CLK FF
In
s 3- 76
sy
Trial CTS provides better guidance for ICG splitting and clock-aware placement: Allows accurate
identification of ICGs with critical enable timing, based on realistic ICG placement locations.
op
Trial CTS is performed at the beginning of the initial_drc stage of place_opt, and is updated at the
end of the initial_opto and final_place stages.
yn
Note: In an SPG flow, where the initial_place and initial_drc stages are skipped, trial CTS is
rS
still performed.
Fo
ed
er
i st
eg
R
CTS Setup Needed for Trial CTS

Timing: ICG enable
 For optimum ICG optimization, trial CTS must correlate, as close as

possible, to the actual CTS during clock_opt
y
nl
O
 This relies on complete CTS setup prior to place_opt, which includes:
Clock tree exceptions
se

 Non-default routing and via rules
U
 Post-CTS timing setup
al
CTS setup is covered in CTS units 7 & 8
rn
te
In
s 3- 77
sy
Note that not all cts.* application options are honored during place_opt trial CTS:
The following application options are not honored and will be forcefully turned OFF during trial CTS in the
op
optimize_icg flow:
cts.compile.enable_global_route
cts.compile.enable_cell_relocation
yn
cts.optimize.enable_congestion_aware_ndr_promotion
rS
The remaining cts* application options are honored.

Fo
ed
er
i st
eg
R
ICG Splitting and Clock-Aware Placement

Timing: ICG enable
 After the clock tree is built, ICG optimization performs:

 Splitting of ICGs with critical enable setup timing
y
 Clock-aware placement places ICGs with critical enable timing close to register clusters
nl
 Smaller ICG downstream clock latency  better ICG enable timing
O
Synthesis ICG insertion Automatic Merging ICG splitting/placement
se
RA[0:3]
ICG
RC RA RC RB
RA [1] [1] [2] [2]
RA
U
RB RA
ICG
ICG
[1] [2]
CLK RB[0:3] CLK
ICG
ICG
al
RB RB
ICG
[3]
ICG
RA
RC[0:3]
ICG
rn
[3] [3] [0] [0] [0]
RB RC RA RB RC
RC RC
te
Automatic ICG merging runs independent of ICG optimization:
In
place_opt.flow.merge_clock_gates 2018.06
Default: true s 3- 78
sy
ICG merging occurs during the initial_place stage of place_opt, and during the initial_opto
stage in an SPG flow. This can be disabled using the application option
place_opt.flow.merge_clock_gates. In releases prior to 2018.06, you have to run the
op
merge_clock_gates command manually before running place_opt.

ICG merging occurs across logical hierarchies.
yn
Once the clock tree is built (trial CTS) during initial_drc, ICG optimization identifies the critical ICGs,
rS
performs timing-aware splitting, then updates the clock tree. This happens during the initial_opto stage
of place_opt. Splitting does not duplicate the sequential and combinational logic that drives ICG enable
Fo
inputs.
During the final_place stage of place_opt, ICG optimization performs clock-aware placement: Places
ed
timing-critical ICGs close to clusters of registers. It updates the clock tree again.
er
Splitting and clock-aware placement ensures that the best timing results for ICG enable paths are achieved.
i st
eg
R
Enabling ICG Optimization

Timing: ICG enable
 ICG optimization is recommended for designs with critical ICG enable

timing, in both SPG and non-SPG flows
y
 Trial CTS as well as splitting and clock-aware placement are performed
nl
during placement
O
source CTS_SETUP.tcl
set_app_options –list {place_opt.flow.optimize_icgs true} Default: false
se
# Optional: Control the extent of splitting
set_app_options -list {place_opt.flow.optimize_icgs_critical_range 0.6} Default: 0.75
U
place_opt
al
rn
0 slack ICGs are not split ICGs are split Worst ICG EN violation Reminder: Apply
optimize_icgs_critical_range
all timing-focused
Specified range, as a fraction of Worst ICG EN violation: 1.0 0.6 0
settings to the
te
initial design and
Only ICGs with enable violations that are within 60% of the re-run place_opt
In
worst (WNS) violation will be considered for splitting
s 3- 79
sy
When ICG optimization is enabled (with "place_opt.flow.optimize_icgs true"), clock-aware
placement is performed irrespective of the value of place_opt.flow.clock_aware_placement.
op
ICG cell insertion during synthesis:

yn
ICG cell insertion is performed during synthesis (compile_ultra –gate_clock ...).

rS
By default, a single ICG cell can drive infinite registers (sharing the same clock and enable signals), which
minimizes clock tree dynamic switching power dissipation. This, however, maximizes ICG downstream clock
latency, which increases the potential for ICG enable setup timing violations.
Fo
The user can limit ICG cell fanout, thereby ensuring more than a single ICG per clock/enable, with:
set_clock_gating_style –max_fanout <#>
ed
Estimated ICG clock latencies can be specified to enable synthesis to see, and thereby optimize violating ICG
enable setup timing paths: set_clock_gate_latency ...
er
st
Optional: Controlling the extent of ICG splitting:

i
eg
The extent of splitting can be controlled, for instance, to prevent barely-violating ICGs from being split, for
improved power: place_opt.flow.optimize_icgs_critical_range <#>
R
Acceptable values are between 1.0 and 0.0. The default value is 0.75, which means that ICGs whose EN violations
are within 75% of the worst (WNS) enable violation will be considered for splitting – ICGs with the smallest 25%
EN violations are ignored. Decreasing the value to 0.4, for example, means that fewer ICGs are considered for
splitting – only ICGs whose EN violations are within 40% of the WNS enable violation will be considered for
splitting. A value of 1.0 means that any ICG with even the smallest EN violation will be allowed to split.
1. Which designs may benefit from two-pass placement?

Is this applicable to SPG and non-SPG flows?
y
nl
2. By default, cells are distributed evenly during coarse placement.
O
True or False?
se
3. Circle all that apply related to ICG optimization during place_opt:
U
a. Trial CTS enables accurate identification of critical ICG enable timing paths –
requires complete/accurate CTS setup
al
b. The trial clock tree is maintained after place_opt, for accurate post-
rn
placement “propagated” clock-based timing analysis
te
c. ICG merging is performed when WNS exceeds a certain threshold
d. ICG splitting is based on critical enable setup timing
In
s 3- 80
sy
op
yn
rS
Fo
ed
er
1. Two-pass placement primarily benefits designs that are macro-dominated. It is only applicable to non-
SPG flows, because it affects initial_place, which is skipped in an SPG flow.
st
2. False. By default, auto-density control is enabled and will set the density automatically.
3. A, B and D are correct.
i
eg
What is wrong with the other answers?

C) ICG merging always occurs if the enable and clock signals are common. Merging occurs
R
independently of ICG optimization (place_opt.flow.merge_clock_gates).
Power- and Area-Focused Setup Steps

Power/Area
Design Setup
 Analyze power dissipation and area
y
Pre-placement
nl
check  Perform the following setup steps, as
applicable, to reduce power dissipation
O
Design and flow
requirement setup
Congestion-focused setup and area
se
 Increase power and area optimization
effort levels
U
Placement and Power/Area-focused setup  Enable pre-route layer optimization
Optimization
Enable Route-Driven Extraction (RDE)
al

Placement
 Enable low-power placement
rn
CTS
te
In
s 3- 81
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Power Analysis
Power/Area
 Report power dissipation:
y
nl
icc2_shell> report_power
...
Power Group Internal Power Switching Power Leakage Power Total Power ( % ) Attrs
O
-----------------------------------------------------------------------------------------------------------------------------
io_pad 0.00e+00 0.00e+00 0.00e+00 0.00e+00 ( 0.00%)
memory 2.71e+09 0.00e+00 0.00e+00 2.71e+09 ( 0.63%)
black_box 0.00e+00 0.00e+00 3.22e+07 3.22e+07 ( 0.01%)
se
clock_network 1.40e+11 2.75e+11 5.12e+07 4.15e+11 ( 96.40%)
register 4.42e+08 2.24e+07 3.31e+09 3.77e+09 ( 0.88%)
sequential 2.24e+05 0.00e+00 2.46e+05 4.70e+05 ( 0.00%)
U
combinational 1.99e+08 3.17e+08 8.49e+09 9.01e+09 ( 2.09%)
-----------------------------------------------------------------------------------------------------------------------------
Total 1.43e+11 pW 2.75e+11 pW 1.19e+10 pW 4.30e+11 pW
al
icc2_shell> report_power_calculation ... <pin, net, instance or module>
...
rn
 Control power reporting using the application options power.*
te
In
s 3- 82
sy
A register as shown in the report is a latch or flip flop, which has a defined clock reaching it. A defined clock
is a clock created with the create_clock or create_generated_clock command.
op
A sequential cell in the report is a latch or flip flop, which does not have a defined clock driving it. For
example, a sequential cell can be a register that has its clock pin driven by a data signal.
You can verify whether a latch or flip flop has a defined clock reaching it by querying the clocks attribute
yn
of the cell's clock pin.

You can use the report_power -groups sequential -cell -flat command to get a report of all
rS
the sequential leaf cells in the design and their power consumption information.
Fo
ed
er
i st
eg
R
Area Analysis
Power/Area
 Report area details:

Unit of area determined by
y
icc2_shell> report_design "unit length" in the tech file
nl
...
Cell Instance Type Count Area
O
------------------------------------------
TOTAL LEAF CELLS 56400 448978.305
Standard cells 56360 184094.035
se
Hard macro cells 40 264884.269
Soft macro cells 0 0.000
Always on cells 0 0.000
U
Physical only 1848 2348.291
Fixed cells 1888 267232.560
Moveable cells 54512 181745.745
al
Sequential 5427 314064.946
Buffer/inverter 8414 21337.676
rn
ICG cells 23 136.475
...
te
Core Area : 678847.851
Chip Area : 714438.176
Total Site Row Area : 678847.851
In
s 3- 83
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Power and Area Optimization Effort

Power/Area
 Increasing power optimization effort to medium or high (default is low)

may reduce power (leakage, dynamic or total) at the cost of runtime
y
nl
 With high effort may also worsen TNS and/or area
O
set_app_options –name opt.power.effort \
-value medium | high
se
U
 Increasing area optimization effort to medium, high or ultra (default is
al
low) may reduce area at the cost of runtime and worse TNS
rn
set_app_options –name opt.area.effort \
-value medium | high | ultra
te
In
s 3- 84
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Pre-route / Post-route Correlation
 place_opt uses 2-layer (H/V) virtual routing to calculate net lengths
y
 By default, uses the average RC of all H/V layers
nl
 Modern nodes exhibit large RC variation across layers
O
 Predicting required vias without routing is also difficult
se
 Miscorrelation results in sub-optimal pre-route buffering avg. RC of all H layers
avg. RC of all V layers
U
 Under / over-buffering
 Two techniques to handle miscorrelation:
al
 Layer promotion
rn
 Assigns critical nets to higher less resistive layers
te
 Route Driven Extraction (RDE)
Computes a statistical model for VR nets based on actual global routing data
In

s 3- 85
sy
Metal layer resistance varies substantially in smaller technology nodes, impacting pre-route R estimation,
especially for long nets. This can lead to: increased violations and buffer count, and reduced correlation with
op
post-route results.
The following is an excerpt from a place_opt run that shows the average RC calculation:
yn
Information: Design Average RC for design ORCA_TOP (NEX-011)

Information: r = 1.784360 ohm/um, via_r = 0.432289 ohm/cut, c = 0.086794 ff/um,
rS
cc = 0.000000 ff/um (X dir) (NEX-017)

Information: r = 1.595951 ohm/um, via_r = 0.550351 ohm/cut, c = 0.102538 ff/um,
cc = 0.000000 ff/um (Y dir) (NEX-017)
Fo
Information: The RC mode used is VR for design 'ORCA_TOP'. (NEX-022)

ed
er
i st
eg
R
Pre-Route Layer Optimization

Power/Area
 Automatically assigns longer and more timing-critical nets to higher

layers (using min/max layer constraints)
y
nl
 Reduces the number of buffers needed for the same path
O
 Also promotes layers on nets with long repeater chains, then re-buffers
 Smaller buffer chain may also improve timing
se
set_app_options \
U
–name place_opt.flow.optimize_layers –value true
al
Minimum and maximum layer constraints are carried all the way to
rn

post-route optimization
te
 Layer assignments are by reported by write_script in the file design.tcl 1
In
 Layer optimization incurs extra runtime/memory usage
s 3- 86
sy
The layer optimization also looks for long repeater chains that have been buffered previously, assigns the net
to higher layers and rebuffers, thereby reducing the number of buffers and possibly improving its timing. This
op
optimization occurs in the final-opto stage.

By default, this application option is set to “false”.
yn
Incurs extra runtime/memory for running the router to generate an incremental congestion map and
identifying timing critical nets based on routed timing.
rS
* You can specify which nets get promoted using:

Fo
place_opt.flow.optimize_layers_critical_range
By default this is set to 0.7, which means that nets with a slack in the range of WNS – WNS*0.7 will be
considered for promotion (i.e. nets within 30% of WNS). The smaller you make this number, the more nets
ed
will be candidates for promotion. Consider leaving this at the default setting.
er
1 write_script will capture layer assignments in the file design.tcl, for example:
set_routing_rule -min_routing_layer "M6" -max_routing_layer "M7" \
st
-min_layer_mode soft -max_layer_mode soft -min_layer_mode_soft_cost low \

-max_layer_mode_soft_cost low [get_nets {sd_DQ_in[21]}]
i
eg
…
R
Route-Driven Extraction (RDE) for Preroute Optimization

Power/Area,
Correlation
 RDE uses global routing on the placed design to capture:
y
 Detailed layer occupancy beyond min/max layer usage
place_opt
nl
 GR topology and length
O
 Via resistance clock_opt
 Cell pin geometries
se
U
 Once data is captured, all virtual routes will use the GR RC model for
al
RC extraction
Ensures close parasitic and timing correlation to actual routing
rn

 Tends to result in better area and power with similar post-route timing QoR
te
 Does not increase full flow run time
In
s 3- 87
sy
op
yn
rS
Fo
ed
er
i st
eg
R
RDE in the Pre-Route Flow

Power/Area,
Correlation
y
place_opt -to final_place
 RDE capture occurs twice in the flow
nl
place_opt -from final_opto
RDE  At the beginning of place_opt and clock_opt
capture
O
final_opto
clock_opt -to route_clock
 RDE data is stored with the design, and is
se
RDE reused for any subsequent optimizations
clock_opt -from final_opto capture
U
 RDE is enabled by default for 16nm and below
al
route_auto
opt.common.enable_rde Default: auto
rn
route_opt
To enable for other technologies, set the
te

application option to true
In
s 3- 88
sy
If you have used GRLB (global route layer binning or or route-aware estimation) in the past, RDE replaces
that approach.
op
Reset the GRLB setting to its default (false).

yn
rS
Fo
ed
er
i st
eg
R
Dynamic Power-Driven Placement

Power/Area
 Dynamic power-driven placement reduces dynamic power by moving

cells to shorten high switching (toggle rate) activity signal nets
y
nl
Tr = 0.1
Tr = 0.1
Tr = 0.3
O
Tr = 0.3
se
 Available in all placement stages, including initial placement
 Best results achieved with SAIF switching activity
U
set_scenario_status –dynamic_power true func_ss125c
al
read_saif design_sim.saif –scenario func_ss125c
rn
# Modify low power effort as needed. Allowed settings: none, low, medium, high
set_app_options -name place.coarse.enhanced_low_power_effort -value medium
te
place_opt Default: low
report_power -corners [all_corners]
In
s 3- 89
sy
Dynamic power-driven placement (also called enhanced LPP or eLPP) is available for all placement stages
across place_opt and clock_opt. It optimizes the placement of cells connected to high toggle rate signal
op
(non-clock) nets with the purpose of shortening these net lengths. Shortening high toggle rate nets, which
reduces dynamic power dissipation, may lengthen low toggle-rate nets, which in turn increases power
dissipation and path delay. Power-aware placement ensures that such trade-offs result in a net reduction of
yn
estimated dynamic power dissipation, while not worsening setup timing.

rS
Note that this enhanced LPP supersedes the originally available low power placement, which was enabled
using the application option place.coarse.low_power_placement.
Fo
ed
er
i st
eg
R
Placement and Optimization Application Options Summary

 The previous pages showed several useful placement and optimization
application options that can help produce better QoR
y
 Depending on the design’s specific goals, you may want to consider
nl
other available options:
O
report_app_options {place.* place_opt.* opt.*}
se
------------------------------------------- --------- ------- ------------- ---------------- -------
place.coarse.congestion_analysis_effort enum {} {} high block
U
place.coarse.congestion_driven_max_util float -- -- 0.93 block
place.coarse.detect_detours bool -- -- false block
place.coarse.enable_enhanced_soft_blockages bool -- -- false block
al
...
place_opt.congestion.effort enum {} {} medium block
place_opt.final_place.effort enum {} {} medium block
rn
place_opt.flow.clock_aware_placement bool -- -- false block
...
opt.area.effort enum {} {} low block
opt.common.allow_physical_feedthrough bool -- -- false block
te
opt.common.buffer_area_effort enum {} {} low block
...
In
Apply any QoR control commands to the initial design and re-run place_opt
s 3- 90
sy
op
yn
rS
Fo
ed
er
i st
eg
R
1. How does Pre-Route Layer Optimization help to improve power/area?
y
nl
O
2. Route Driven Extraction is a different technique for constraining routing
(using min-max layers)
se
True or False?
U
3. To perform accurate power-driven placement (circle all that apply):
al
a. Set the option place.coarse.enhanced_low_power_effort
rn
b. Load accurate net switching activity (toggle rate) information
te
c. Apply set_scenario_status –dynamic_power true to at least one active
scenario
In
s 3- 91
sy
op
yn
rS
Fo
ed
er
1. Pre-route layer assignment automatically assigns longer and more timing-critical nets to higher layers
st
(using min/max layer constraints), which results in much smaller average RCs. This reduces the number
of buffers needed for the same path. It also promotes layers on nets with long repeater chains, then re-
i
eg
buffers.
2. False. RDE does not constrain the router. RDE builds a statistical model for RC extraction in all pre-route
R
steps.
3. A, B and C are correct.
Summary
y
 Apply pre-placement setup to control:
nl
 Design and flow requirements
O
 Congestion, timing, area and power QoR
Perform placement and related optimizations
se

 Analyze congestion, timing, power and area
U
al
rn
Begin “Lab 3: Placement”
te
In
s 3- 92
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix
y
nl
O
A – Cell Naming Convention
B – Magnet placement, stand alone placement
se
C – Move Bounds
U
D – Path Groups and Weights
E – Incremental Optimization: refine_opt
al
F – Misc
rn
G – Relative Placement
te
H – Scan chain reordering and SCANDEF
In
s 3- 93
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix A
y
nl
O
Cell Naming Convention
se
U
al
rn
te
In
s 3- 94
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Optimization: Cell Naming Convention
Prefix of newly
Opto Notes
created cell name
Logic and Arithmetic
y
SGI SGI%d_%d
Restructuring
nl
BUFT buffers
AINV Buffering inverters
O
BINV inverters
RBINV Inv polarity maintenance
se
Buffer removal Top level ports to avoid 2 or more ports
RBBUF
driven by the same net
U
APS_FTB FT buffering Feedthrough buffers
APS_TDBUF Tristate isolation
al
APS_PI Port isolation
APS_CLK_ISO Clock-data isolation
rn
BUFT_GROPTO_ Gropto
APSHOLD Hold fixing
te
APSLS Effort sizing (SIZE1) Augmented buffer for weak drivers
optlc Tie-cell insertion Tie cells
In
s 3- 95
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix B
y
nl
O
Magnet Placement
Stand alone placement
se
U
al
rn
te
In
s 3- 96
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Magnet Placement
 Some standard cells must be placed close to a related object
to improve congestion or timing, for example:
 Boundary scan logic placed close to I/O pads
y
 Large macro with many pins connecting to many cells
nl
 Timing-critical cells placed close to start- or end-point
O
 Another example – minimize wire length from mux to output:
ORCA_TOP
se
D Q
sd_mux_dq_out_0
0
sd_DQ_out[0]
U
1 S0
D Q
al
sdram_clk
1 S0
sd_CK
rn
0
sd_mux_CK
I_SDRAM_TOP/I_SDRAM_IF
te
 Magnet placement automates such placement
In
 Easier than manually pre-placing the standard cells s 3- 97
sy
In the example above, there is a design requirement that the delay from the clock input port sdram_clk,
through the select pin of the top mux sd_mux_dq_out, to the data output port sd_DQ_out, matches as
close as possible, the delay from sdram_clk to the feedthrough clock output port sd_CK. To accomplish
op
this, an identical “dummy” mux, sd_mux_CK was added along the clock feedthrough path, to match the
select-to-output delay of sd_mux_dq_out. During clock tree synthesis (in a later CTS lab), the select pins
yn
of both muxes will be converted to clock sinks, enabling CTS to balance the delays to these pins. Since the
same mux is used for the data and clock paths, this guarantees that the sdram_clk path delay to both mux
rS
outputs match as closely as possible. To minimize the delay difference between the mux output pins and their
respective output ports (due to possible difference in wire lengths), magnet placement can be used here to
Fo
physically “pull” the muxes close to their output ports – this minimizes both wirelengths, which minimizes
their delay difference.
ed
Manually pre-placing standard cells requires the designer to identify and then place each of the cells at the
appropriate location, which is very time-consuming. With magnet placement, at a minimum, only the
er
“magnet” object needs to be specified, and the tool automatically places all connected combinatorial cells
near the magnet object. Additional options and variables are available to control magnet placement behavior.
i st
eg
R
Performing Magnet Placement Placement and

Optimization
 Specify fixed objects as magnets

 Macros, macro pins or I/O pins
y
 Perform magnet placement:
nl
 By default, the first level of logic is pulled in
O
 Use command options as needed to further control magnet placement (see notes)
se
magnet_placement [get_ports "sd_DQ_out sd_CK"]
U
You can “fix” the moved cells using –mark_fixed, or allow them to be
al

moved for legalization purposes only:
rn
magnet_placement -mark_legalize_only ...
te
or
set_placement_status legalize_only [get_cells xx]
In
s 3- 98
sy
magnet_placement
[-move_fixed] allow fixed cells to be moved
mark cells as “fixed” after placement
op
[-mark_fixed]
[-move_legalize_only] specifies that a cell marked as legalize_only can be moved
[-mark_legalize_only] mark cells as “legalize_only” after placement
yn
[-stop_by_sequential_cells] specifies to stop pulling cells closer to the magnet objects

when a sequential cell is encountered during level traversal
rS
[-logical_levels level] specifies the number of logical levels to pull (default: 1)

[-cells object_list] specifies to pull only the cells in the specified object list
Fo
magnet_objects a list of magnet objects
set_placement_status can be used at any time to set the physical_status attribute of a cell.
ed
or cells, valid status values are unplaced, placed, legalize_only, application_fixed, fixed,
and locked. For ports, valid status values are unplaced, placed, fixed, and locked.
er
You will find that ICC II will mark cells with “application_fixed” at times (for example after CTS).
The various optimizations can set cells fixed but know that they can then freely change them back to unfixed
st
when desired (”application_fixed”). The user’s input (“fixed”) is never changed, and this gives
ICCII the ability to make the proper distinction.
i
eg
R
Standalone Coarse Placement
 To perform coarse placement on the current design, use the

create_placement command
y
nl
 Hard macros should already be placed
Places hard macros if you use the -floorplan option, which is typically done the
O

Design Planning flow
se
 Supports timing- and congestion-driven modes
 Effort level control for balancing runtime and QoR
U
 Use legalize_placement afterwards
al
 You can unplace all unfixed cells with reset_placement
rn
te
In
s 3- 99
sy
create_placement Options:
-timing_driven
op
Enables timing-driven placement

-congestion
Enables congestion-driven placement
yn
-congestion_effort
Sets the congestion effort. The default is medium
rS
-floorplan
Performs floorplanning placement, which includes macro placement in the ICC II Design Planning
Fo
flow
-effort
Placement effort
ed
-incremental
Run incremental placement
er
i st
eg
R
Enhance the Placement
 You can also run incremental placement in order to reduce congestion

further
y
nl
refine_placement
O
[-effort low | medium | high]
[-congestion_effort low | medium | high]
se
[-perturbation_level low | medium | high]
[-coordinates bbox ]
U
al
 Control the amount of cells moved by using the
rn
-perturbation_level option
te
 If you want to prevent movement of any cells outside of a certain
region, use -coordinates
In
s 3- 100
sy
Quoted from the man page:
-effort low | medium | high
op
Specifies the CPU effort level for coarse placement. The default effort level is medium.
-congestion_effort low | medium | high
Specifies the effort level of congestion removal. The higher effort, the less attention is paid to other
yn
objects: timing, density and total wire-length. The default effort level is medium.
-perturbation_level min | medium | high | max
rS
Specifies the perturbation level for the placement to optimize congestion. Specifying min produces the
least amount of movement from the placement. The higher the level specified, the more movement you
Fo
might expect from the placement. So, specifying max produces the most movement from the
placement. The default effort level is medium.
-coordinates bbox | bbox_list
ed
Specifies one rectangle that defines the region from which to run incremental congestion removal. The
"bbox" is lower-left and upper-right coordinates of a rectangle.
er
The default (without this option) is to run incremental placement for the entire design, which is the
recommended way to use this command. If you want to specify one localized region on which
st
incremental placement should be done, you can use this option to prevent any disturbance of the rest of
the converged design. The region based refinement may cause timing/congestion degradation if regions
i
eg
are not properly specified.

The units of the -coordinates are in microns.
R
No runtime improvement is expected when this option is used; it is primarily used to restrict the placer
from making changes outside the specified rectangles.
Appendix C
y
nl
O
Move Bounds
se
U
al
rn
te
In
s 3- 101
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Create Move Bounds

Timing
 Move bounds can be created to constrain the placement of cells within a

specified region (useful to place cells in timing-critical modules together)
y
 A bound can contain leaf cells and/or hierarchical cells
nl
 All cells inside a listed hierarchical cell are part of the move bound
O
 Move bounds can be:
 Soft: Tries to place cells in bound, while balancing routability and timing needs;
se
Obeyed only by coarse placement, not legalization “Soft” bounds are generally
better for timing-critical cells
Hard: Forces cells in the bound, sacrificing routability and timing;
U

Obeyed by all stages except CTS
al
 Exclusive: Like hard, but non-bound cells not allowed inside;
Obeyed by all stages of the flow
rn
create_bound -name bound_clk -type hard \
te
-boundary {{425 606} {477 707}} {snps_OCC_controller}
In
 If using the SPG flow, soft bounds should have been defined and used in DC-G
s 3- 102
sy
Generally, there is no guarantee that cells will be placed completely within a bound. For instance, coarse placement will
violate bounds if the quality of its primary placement objectives would otherwise be destroyed. In these situations, the
user should revisit their bounds and floorplan to ensure that the design is not over-constrained. Alternatively, the user
op
can specify the bound type to be hard (the default is soft): The coarse placer will try to honor the hard bound as hard
constraints while sacrificing other objectives, such as timing and routability. It is not recommended to use many hard
yn
bounds because this will lead to inferior placement solutions.
create_bound
rS
-name Name of the bound

[-boundary] Creates a move bound with the boundaries specified by a list of rectangles and polygons.
[-dimension] Creates a group bound with the specified dimensions {W H}
Fo
[-effort] Creates an auto soft group bound with the specified effort (low | medium | high | ultra) to bring
cells close to each other, inside a group bound. The dimension is automatically determined.
[-diamond] Port/cell/pin object at center of diamond bound. Requires –dimension to specify diamond size.
[-type] Specify the type of bound (soft | hard)
ed
[-exclusive] Creates an exclusive bound – non-bound cells not allowed inside; Automatically makes the type hard.
[-hierarchical_only] The move bound can contain only cells which represent module boundary objects (floorplanning).
[-design_type] Allow only cells whose reference is of specified design type, e.g: abstract, analog, black_box, …
er
[-cell] Physical cell where the bound is to be added

[cell_and_port_list] List of cells and ports to assign to the bound
st
Use help *bound* for additional “bounds” commands.

i
eg
R
Soft versus Hard Bounds

Timing
Coarse placement Legalization
y
nl
Soft
bound
O
se
Soft bounds are better for timing purposes, because cell placement
within the bound is balanced against possibly-conflicting timing needs
U
al
Hard
rn
bound
te
In
s 3- 103
sy
In the examples above, the highlighted cells are the ones identified to be in the move bounds. The other (not
highlighted) cells are not part of the bounds, but ended up in the bounds. Note: Hard bounds can also be
op
made exclusive, in which case only the specified move bound cells would be placed inside the bound.
The key point to observe is that with a soft bound, coarse placement, and subsequent legalization, are not
yn
forced to place all the cells within the bound: If certain timing-critical cells are better off being near, but
outside the bound, this is allowed.
rS
With a hard bound, on the other hand, all the specified bound cells are forced inside the bound, even if this
Fo
results in worse timing for some cells.

ed
er
i st
eg
R
Appendix D
y
nl
O
Path Groups and Weights
se
U
al
rn
te
In
s 3- 104
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Default Path Groups
 By default, paths are grouped into path groups, defined by

their capture clock
y
 Path groups have a default weight of 1
nl
 In the example below, all I/O and reg-to-reg paths are in the
O
same CLK path group
Register-to-Register Path
se
Input Path Output Path
U
A Z
D Q D Q D Q D Q
FF2 FF1 FF2 FF1
al
CLK
rn
B Y
te
COMBO
In
Combinational Path s 3- 105
sy
To report all available path groups:
report_path_groups –modes [all_modes]
op
yn
rS
Fo
ed
er
i st
eg
R
Problem with Large Violating I/O Paths
 Within a path group, final placement (final_place), which is

timing-driven, focuses on improving WNS and near-WNS paths
y
nl
 If the WNS/near-WNS paths are over-constrained I/O paths,
smaller but real violating reg-to-reg paths are ignored during
O
final placement, and can even get worse!
se
WNS decreased while reg-to-reg
violation increased!
Setup timing slacks
U
FF2 moved
-20ps -100ps -40ps -80ps
al
Z Z
D Q D Q D Q D Q
rn
FF1 FF2 FF1 FF2
CLK CLK
te
All path are in the same CLK path group
In
s 3- 106
sy
WNS = Worst negative slack
op
The paths that are considered “near-WNS paths”, are automatically determined by the placer, and are
dynamically adjusted. This is essentially an automatic creation of a “critical range”. As the WNS gets
smaller, the “critical range” is also reduced, to keep the total number of timing paths considered during
yn
placement reasonable. This automatic “critical range” cannot be changed by the user; Any user-defined
“critical range” (group_path –critical_range) is ignored.
rS
Fo
ed
er
i st
eg
R
Place I/Os into Separate Path Groups

 Placing I/O paths in separate path groups allows final placement to
work on reg-to-reg paths, independent of large violating I/O paths
y
 Can be automatically done:
nl
set_app_options -list {time.enable_io_path_groups true}
O
**in2reg_default** CLK **reg2out_default**
se
U
A Z
D Q D Q D Q D Q
FF2 FF1 FF2 FF1
al
CLK
rn
B Y
COMBO
te
In
**in2out_default** 3- 107
s
sy
The above application option creates and places input, output and combinatorial paths into the following path
groups, respectively, with a default weight of 1:
**in2reg_default**
op
**reg2out_default**
**in2out_default**
yn
Alternatively, path groups can be created “manually”, as follows:

rS
foreach scenario [all_active_scenarios] {

current_scenario $scenario
Fo
group_path -name A_INPUTS -from [get_ports A_IN*]

group_path -name B_INPUTS -from [get_ports B_IN*]
group_path -name OUTPUTS -to [all_outputs]
ed
group_path -name COMBO -from [all_inputs] –to [all_outputs] }

er
i st
eg
R
Separate Path Groups May Not Be Enough
 Across all path groups, final placement focuses on reducing

(or maintaining) the aggregate weighted WNS (AWNS)
y
This may still cause violating reg-to-reg paths to get worse,
nl

even when AWNS is reduced!
O
AWNS maintained while
se
CLK group WNS increased!
FF2 moved
U
-20ps -100ps -40ps -80ps
Z Z
D Q D Q D Q D Q
al
FF1 FF2 FF1 FF2
CLK CLK
rn
CLK **reg2out_default** CLK **reg2out_default**
path group path group path group path group
te
AWNS = 120ps AWNS = 120ps
In
s 3- 108
sy
AWNS = Aggregate weighted Worst Negative Slack = Sum of the weighted WNS value of each path group
op
yn
rS
Fo
ed
er
i st
eg
R
Apply Path Group Weights

 Placement can be focused to improve WNS timing of critical path groups
by applying a higher weight (default = 1)
y
group_path -name CLK –weight 2
nl
 A higher weight path group may cause an increase in WNS within lower-weight path groups
O
 In a path group with a large weight, a relatively small WNS reduction can cause large WNS
increases in default-weighted path groups
CLK group violation eliminated
se
and AWNS decreased!
U
FF2 moved
-20ps -100ps 0ps -120ps
Z Z
al
D Q D Q D Q D Q
FF1 FF2 FF1 FF2
CLK CLK
rn
CLK **reg2out_default** CLK **reg2out_default**
te
path group path group path group path group
weight = 2 weight = 2
In
AWNS = 140 ps AWNS = 120 ps
s 3- 109
sy
Note: In the example above (weight of 2) it is possible that placement would accept a 20ps reduction in the
reg-to-reg path delay at the expense of up to a 2x20=40ps increase in the output path delay. If a larger weight
op
of 5, for example, was applied to the CLK path group, placement would accept a 20ps reduction in the reg-to-
reg path delay at the expense of up to a 5x20=100ps increase in the output path delay (see below). For this
reason it is advisable not to use large weights.
yn
rS
-20ps  0ps -100ps  -200ps In this example, the Q-pin of FF2 has a fanout
Fo
of eight. When FF2 moves to the left, eight Q-

D Q D Q pin wire segments are lengthened, while only
FF2 one D-pin wire segment is shortened. This can
FF1
ed
CLK result in a much larger CLK-Q delay increase

compared
Path group weights do not affect pre-route logic optimization, only final to the in
placement reg-to-reg
place_optdelay .reduction.
er
Furthermore, specifying a path group critical range is ignored by both placement and optimization. Pre-route
st
logic optimization automatically works to improve timing on all violating paths:

Pre-route optimization automatically identifies “near-WNS paths”. All violating timing paths that are not
i
eg
“near WNS”, are considered “TNS paths”. The range of “near WNS paths” is automatically adjusted
throughout the flow. Optimization focuses only on timing for “near WNS paths”. It balances timing, area and
R
power optimization for “TNS paths”, and performs only area and power optimization on positive-slack paths.
Appendix E
y
nl
O
Incremental Optimization: refine_opt
se
U
Obsolete in ICCII 2018.06
al
rn
te
In
s 3- 110
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Incremental Optimization with refine_opt

Post place_opt steps
refine_opt –from <stage> -to <stage>
y
Obsolete in ICCII 2018.06
nl
1. Initial Path Optimization (initial_path_opt)
See next page
O

2. Incremental Placement (inc_place)
se
 Incremental placement to improve routability
U
3. Incremental Optimization (inc_opto)
Incremental timing, area, congestion, and power optimization
al

Final Path Optimization (final_path_opt)
rn
4.
 Final phase of path optimization, followed by legalization
te
In
See notes below for app options to control refine_opt
s 3- 111
sy
Several application options can control the optimizations done by refine_opt
• Coarse placement effort control:
refine_opt.place.effort (medium | high)
op
• Congestion alleviation effort control:

refine_opt.congestion.effort (none | medium | high)
yn
Expect a significant increase in runtime for high effort

• Perform ICG-driven clock-aware placement
rS
refine_opt.flow.clock_aware_placement (true | false)

• Allow fixed cells to be moved to improve QoR
Fo
refine_opt.place.fixed_cell_disturbance (true | false)

• Fix hold violations pre-CTS – if large violations are seen
refine_opt.hold.effort (none | low | medium | high | exclusive)
ed
• The high effort option may result in slight degradation in setup TNS
• Exclusive means only perform hold optimization
er
• Layer Optimization:
refine_opt.flow.optimize_layers (true | false)
i st
eg
R
Path Optimization
 Path optimization during refine_opt can help to further improve

timing after place_opt:
y
1. After place_opt
nl
 Identifies unbalanced register placement R1 R2 R3 4x
4x R4
which contribute to violating paths
O
+30ps +20ps -40ps
 Has a global view – looks at all related data flow
2. After one move in path_opt
paths (reg-to-reg-to-reg-to-reg….)
se
4x
R1 R2 R3 4x R4
 Moves registers and buffers to take advantage
+30ps +0ps -20ps
of nearby positive slack paths to reduce violations
U
3. After path_opt convergence 2x combined gate
 Does not move registers across gates – only buffers
R1 R2 R3 R4
al
 Performs buffer removal, gate sizing and restructuring +0ps +0ps +0ps
 Can also perform layer optimization (if enabled)
rn
te
 Path optimization is not enabled in place_opt by default!
In
s 3- 112
sy
In the example picture above, after place_opt, the design has a -40ps violating path between
R3-R4, but positive 30ps and 20ps slacks between R1-R2 and R2-R3, respectively. During the first move or
op
iteration, path optimization takes advantage of the R2-R3 20ps positive slack by placing R3 closer to R4, and
moving one of the three buffers the left side of R3. This reduces the R3-R4 timing path violation to -20ps.
After the first move, several more moves are performed until convergence: Path optimization takes advantage
yn
of the R1-R2 30ps positive by moving R2 to the right, and moving two buffers between R1 and R2. This
creates some positive slack in R2-R3 (intermediate step, not shown), so R3 can now be moved even closer to
rS
R4, and the third buffer can be removed altogether. As a result, there is now actually a 10ps positive slack in
R3-R4 (intermediate step, not shown), so path optimization now restructures the AND and OR gates into a
Fo
single AND-OR complex gate, and downsize it to a 2X size. The end result is 0ps slack in all three stages
(with an added benefit of smaller cell area).
ed
If the runtime for a full refine_opt (all four stages) is expected to be too long, try refine_opt -from
final_path_opt, which may give you acceptable QoR. If the QoR is not acceptable, you will need to run
er
a full refine_opt.
st
To enable “layer optimization” use refine_opt.flow.optimize_layers.

i
eg
If you want to enable path_opt during place_opt, set the following application option:
set_app_options –name place_opt.flow.do_path_opt –value true
R
Focusing refine_opt
 By default, refine_opt optimizes the entire design
y
 You can focus refine_opt to work on specific end-points or specific
nl
path groups
O
se
refine_opt -end_points <pins|ports>
provide a collection of pins or ports
U
refine_opt -path_groups <pathgroups>
al
provide the names of path groups
rn
te
In
s 3- 113
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix F
y
nl
O
Misc Topics
se
U
al
rn
te
In
s 3- 114
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Net length attribute support
 In 2016.12-SP2, six new attributes are introduced on net object for users to query
various net length information;
y
Attributes Comments
nl
vr_x_length Estimated virtual route length
vr_y_length
O
vr_length
dr_y_length Detailed route lengths
dr_x_length
se
dr_length
 The wire length of each net includes all the net segments across all the physical
U
hierarchies from top to bottom. User can use the full hierarchy name of any of the net
segments to represent the whole net.
al
 For virtual route estimated net length attributes, to get an accurate wire length
rn
estimation, the sub blocks should be of design views.
 If the blocks are of other views, e.g. abstract views, the attributes may return a wire length value
te
quite different from the scenario when blocks are of design views, due to the fact that some of the
cells inside the blocks are either invisible or missing in non-design views.
In
s 3- 115
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Stand-Alone Trial CTS
 In designs where ICG enable timing is not critical, it might still be

beneficial to use trial CTS during place_opt
y
nl
 Use the following to enable trial CTS:
O
set_app_options -name place_opt.flow.trial_clock_tree -value true
se
 Placement and optimization will take the results of CTS into account
U
and consider propagated clock delays along with CRPR
al
rn
te
In
s 3- 116
sy
CRPR = Clock Reconvergence Pessimism Removal
op
yn
rS
Fo
ed
er
i st
eg
R
Categorizing Design Violations
 Categorize violations and understand why some of them did

not get fixed: analyze_design_violations
y
 Analyzes maximum transition, setup or hold time violations in the current
nl
design and generates a summary report for the unfixed violations
O
 Use pre-route (after place_opt, refine_opt, clock_opt)
 Example: Analyze setup violations, count any net with more than 10
se
fanouts as a high-fanout net and any violation with slack less than 0.5 as
a small violation
U
analyze_design_violations \
al
-type setup -fanout 10 -slack 0.5 \
rn
-output my_report
te
output is written to the file my_report.setup.txt
In
s 3- 117
sy
The output is written to the file my_report.setup.txt.
Example output:
category Count Worst Total
op
----------------- ----- ----- -----

* category 1: Large clock skew 0
yn
* category 2: Large external input delay 0

* category 3: Large driver adjustment 0
* category 4: Large clock uncertainty 0
rS
* category 5: Large setup time of end point 30 -3.66 -97.99

* category 6: Large external output delay 0
* category 7: Small violations 38 -0.50 -15.94
Fo
* category 8: Other violating paths 2654 -4.96 -8620.15
Detect 2722 setup violation endpoints

ed
WNS: -4.959 TNS: -8734.081

Please find detailed analysis in analyze_design_violations.setup.txt.
er
The following example analyzes the maximum transition violations in the current design:
analyze_design_violations -type max_trans
i st
eg
R
Enable Multiple Port Net Buffering
 By default, ICC II will not buffer nets that are connected to two or more
ports
y
 Good design practice dictates that each port has a unique driver
nl
 Enable multiple port net buffering:
O
set_app_options –list \
se
{opt.port.eliminate_verilog_assign true}
U
al
rn
Block1 Block1
te
Default: Multiple port With multiple port
nets without buffering net buffering
In
s 3- 118
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Standard Cell Spacing Rules
 It can be helpful to create more space between two high-pin-count cells,

for example
y
nl
 Can reduce pin density  less congestion
You define labels and attach these labels to the right and left side of a reference
O

(e.g. FF*, AND*, BUF*, *)
se
 You specify what spacing is allowed between the labels
U
al
AND FF AND
rn
FF BUF
te
In
s 3- 119
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Creating Cell Spacing Labels and Rules
# Assign the label “X” to the right and left sides of flip-flops and AOIs
# -side accepts left | right | both
set_placement_spacing_label -name {X} \
y
-side both -lib_cells [get_lib_cells "*/SDFF* */AOI*"]
nl
# All other cells have label “Y”; SDFF and AOI cells have both labels
O
set_placement_spacing_label -name {Y} \
-side both -lib_cells [get_lib_cells */*]
se
# Labeled cells “X” next to “X” are to be spaced 4 or more sites apart
set_placement_spacing_rule -labels {X X} {0 3}
U
# Labeled cells “X” next to “Y” are to be spaced 2 or more sites apart
al
set_placement_spacing_rule -labels {X Y} {0 1}
rn
Make sure that spacing rules are not too extreme, otherwise cell
te
legalization will cause large cell displacement
In
s 3- 120
sy
For the set_placement_spacing_rule command, the syntax {0 2} means a spacing of 0-2 sites is
prohibited. If you specify {1 2}, this means a spacing of 1 to 2 is prohibited, but abutting (0) and more than
op
2 sites is OK.
All spacing rules specified by set_placement_spacing_rule commands need to be satisfied to produce
a legal placement. Therefore, the ordering of the commands is irrelevant.
yn
Given two adjacent standard cells with an empty space in between, each label from the right side of the left
cell is checked against each label from the left side of the right cell to see if any spacing rules are violated.
rS
Such pair-wise checking of labels is applied to all adjacent cells to ensure placement legality of a chip.
Use remove_placement_spacing_rules to remove placement spacing labels and rules set with
Fo
set_placement_spacing_label and set_placement_spacing_rule commands.
Note: From 2016.03-SP1, spacing labels and rules are stored with the design. Prior to this release, you
ed
had to re-apply the rules every time you invoke ICC II.
er
If vertical spacing is desired for certain standard cells, then you need to specify keepout margins on the
library cells in ICC II Library Manager. This operation cannot be done in ICC2.
i st
eg
R
ICG Auto-Bounds
 Automatically creates group
y
bounds, which keep ICGs
nl
close to their related registers
O
 Driven by fanout only, not by
enable timing
se
U
al
set_app_options -category place.coarse -list {
icg_auto_bound true # Default is false
rn
icg_auto_bound_fanout_limit 40 } # Default is 100
...
te
place_opt
In
s 3- 121
sy
Setting place.coarse.icg_auto_bound to true enables automatic creation of group bounds, which
keep ICGs close to their related registers, if those registers are moved by any subsequent incremental
op
placement and optimization.
The place.coarse.icg_auto_bound_fanout_limit option can be used to control the maximum

yn
fanout for which auto-bound creation is performed. If set to 40 (default), for example, group bounds are only
created for ICGs that fan out to 40 or fewer registers.
rS
Fo
ed
er
i st
eg
R
Appendix G
y
nl
O
Relative Placement
se
U
al
rn
te
In
s 3- 122
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Relative Placement
REG MUX REG ALU SHIFT
y
Y[0]
X[0] Z[0]
nl
Y[1]
X[1] Z[1]
O
Y[2]
X[2] Z[2]
Data signals
se
Y[3]
X[3] Z[3]
…………………………………….
U
Y[15]
al
X[15] Z[15]
CLK SEL CARRY BIT
rn
Control signals
te
In
s 3- 123
sy
op
yn
rS
Fo
ed
er
i st
eg
R
What’s Special about Data Path Logic?
 Bit-wise data operations are performed

in parallel on each bit of a bus X[15:0] Y[15:0]
y
nl
 Each operation corresponds to a dedicated
function, e.g. adder, multiplier, register, REG REG
O
CLK
multiplexer, etc.
se
SEL MUX
 Two groups of signal flows:
 Data flow: data-in to data-out
U
ALU
 Control flow:
al
 Global: clock, select, enable SHIFT
Local: carry-in, carry-out
rn

Z[15:0]
te
Example data path
functional module
In
s 3- 124
sy
op
yn
rS
Fo
ed
er
i st
eg
R
The Ideal Layout for Data Path

 Best placed in a bit-sliced structure, for example:
 Cells operating on one bit are placed in one row, abutted next to each other
horizontally
y
This row is repeated and abutted vertically for each bit
nl

 Benefits of this placement structure:
O
 Overall placement area of data path cells is minimized
se
 Control and data signals can be routed vertically and horizontally, respectively
 Minimizes routing congestion REG MUX REG ALU SHIFT
U
Y[0]
X[0] Z[0]
 Minimizes interconnect Y[1]
al
parasitic RCs X[1]
Y[2]
Z[1]
Data signals
– Reduced delay X[2] Z[2]
rn
Y[3]
– Reduced power X[3] Z[3]
…………………………………….
te
 Minimizes clock and data skew
Y[15]
X[15] Z[15]
In
CLK SEL CARRY BIT
s Control signals 3- 125
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Data Path Layout using Traditional P&R Tool

Traditional layout tools can not take advantage of the
regular bit-sliced structure, resulting in:
 Larger placement area and routing congestion
y
 Larger delays, skews and power consumption
nl
O
BIT 5
BIT 15
BIT 3
se
BIT 0 BIT 12
BIT 9
U
BIT 2
BIT 7 BIT 13 BIT 10
al
BIT 8
rn
BIT 1
te
BIT 4 BIT 14
BIT 6 BIT 11
In
Example “traditional” layout with carry-signal connections highlighted
s 3- 126
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Relative Placement Group

 Each data path functional module is defined once as a relative
placement (RP) group
 Each cell of an RP group is assigned a row and column
y
nl
 Also known as “tiling”
Done prior to placement through TCL constraints Free Placement
O

col-0 col-1 col-2 col-3 col-4
se
row-3 U14 U15 U16 U17 U18
U
row-2 U10 U11 U12 U13
al
row-1 U5 U6 U7 U8 U9 Relative Placement
rn
row-0 U0 U1 U2 U3 U4
Example relative placement group
te
of a data path functional module
In
s 3- 127
sy
“Relative placement” may also be referred to as “physical datapath” in our literature and documentation.
op
yn
rS
Fo
ed
er
i st
eg
R
RP Constraints
rp_constraints.tcl
create_rp_group rp1 –design MY_DP -columns 4 -rows 4
#
add_to_rp_group MY_DP::rp1 -leaf U0 -col 0 -row 0 RP group name  MY_DP::rp1
y
add_to_rp_group MY_DP::rp1 -leaf U1 -col 1 -row 0
nl
add_to_rp_group MY_DP::rp1 -leaf U3 -col 3 -row 0 3 U12 U13 U14 U15
#
O
2 U8 U9 U10 U11
add_to_rp_group
add_to_rp_group
MY_DP::rp1
MY_DP::rp1
-leaf
-leaf
U5
U6
-col
-col
1
2
-row
-row
1
1
row
se
#
0 1 2 3
U
# column
al
rn
te
source rp_constraints.tcl
place_opt
In
s 3- 128
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Concurrent Placement of RP Groups
 RP groups are placed concurrently with standard cells
y
 Relative placement is maintained through post-route
nl
 RP logic is optimized as needed during placement through post-routing
O
phases
 RP groups are re-sized to accommodate cell-sizing
se
 Placement of RP groups in core is automatically adjusted
U
al
rn
te
In
s 3- 129
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Candidates for Relative Placement
 The following functions are good candidates

for taking advantage of Relative Placement
y
nl
 Classic data path structured elements
CPU execution units
O

 CPU address units
se
 RAMs, FIFOs
 Clock structures
U
 Register banks
al
 Some key design applications include
rn
 Processors, DSPs
Relative placement of RAMs
Graphics
te
 with clock “pin alignment”
 Reduced clock skew and power
 IP providers
In
s 3- 130
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Physical Datapath In DC-T/G & ICC II

Complete Support From RTL To Layout
 Enables designers to create regular Design Compiler

datapath structures from RTL to
y
Layout that meet design QoR
nl
objectives IC Compiler II
O
 Maintains datapath structures Mapped Netlist
with RP Constraints
se
during placement, legalization, and place_opt
optimizations, CTS and routing clock_opt
U
route_*
Preserving RP
 Helps make design schedules more
al
predictable Routed Database
with RP
rn
 Easy to use
te
Predictable design schedule with better QoR
In
s 3- 131
sy
Each data path functional module is defined once as a relative placement (RP) group
op
Uses RP information to place RP structures concurrently with rest of design

Preserving RP structure as design goes through placement, optimization, CTS, and routing, sizing
yn
optimizations, incremental placement and legalization

rS
Fo
ed
er
i st
eg
R
RP in DCT/G
module test (a, out0, out1,out2, out3, out4, out5);
input [2:0] a; U3 U4 U5 group_x1
output out0, out1, out2, out3, out4, out5;
y
// synopsys rp_group (group_x0)
U0 U1 U2 group_x0
nl
// synopsys rp_fill ( 0 0 RX )
and2a1 U0 (a[0], a[1], out0);
O
or2a1 U1 (a[0], a[1], out1);
xor2a2 U2 (a[0], a[1], a[2], out2);
group_x (hier RP group)
// synopsys rp_endgroup (group_x0)
se
// synopsys rp_group (group_x1)
// synopsys rp_fill ( 0 0 RX )
U
GTECH_AND2 U3 (a[0], a[1], out3);
GTECH_OR2 U4 (a[0], a[1], out4);
GTECH_NOR2 U5 (a[0], a[1], out5);
al
// synopsys rp_endgroup (group_x1)
rn
// synopsys rp_group (group_x)
// synopsys rp_place ( hier group_x0 0 0 )
te
// synopsys rp_place ( hier group_x1 0 1 )
// synopsys rp_endgroup (group_x)
endmodule
In
s 3- 132
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix H
y
nl
O
Scan chain reordering and SCANDEF
se
U
al
rn
te
In
s 3- 133
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Placement-Based Scan Chain Re-Ordering
y
nl
O
se
U
al
rn
read_def DESIGN.scandef
te
set_app_options -list {opt.dft.optimize_scan_chain true}
place_opt
In
True by default!
s 3- 134
sy
check_scan_chain: Lists a summary: The number of scan chains, plus their start/end points.
report_scan_chains: Lists all scan chain elements between start and end-points.
op
The DFT re-ordering algorithm first re-partitions (i.e. assign cells to the best chain) and then re-orders the
cells within the individual chains.
yn
The other application options that affect scan chain optimization are:
App option Default value
rS
opt.dft.clock_aware_scan_reorder false
opt.dft.clock_aware_scan_repartition_reorder false
opt.dft.do_repartition true
Fo
opt.dft.hier_preservation false
opt.dft.optimize_scan_chain true
opt.dft.timing_friendly_reorder true
ed
er
i st
eg
R
Re-ordering Chains within Same “Partition”
 To extend flexibility, SCANDEF also supports

reordering within partitions, across multiple buckets
y
 A PARTITION is a group of “SCANDEF chains” that
nl
may exchange flip-flops during reordering
O
se
Lockup
SCANDEF Latch SCANDEF SCANDEF
MUX
SI SO
Chain 1 Chain 2 Chain 3
U
al
Lockup
SCANDEF SCANDEF SCANDEF

Latch
MUX
SI SO
rn
Chain 4 Chain 5 Chain 6
te
PARTITION 1 PARTITION 2
In
s 3- 135
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Example SCANDEF from Synthesis with DFT

DESIGN my_design ; Design name
SCANCHAINS 2 ; Number of chain stubs in
- 1 the design
y
+ START PIN test_si1
+ FLOATING A ( IN SI ) ( OUT Q )
nl
B ( IN SI ) ( OUT Q )
O
C ( IN SI ) ( OUT Q ) “FLOATING” indicates that these
flipflops can be reordered
D ( IN SI ) ( OUT Q )
se
+ PARTITION CLK_45_45 PARTITION keyword in SCANDEF.
+ STOP PIN test_so1 Flipflops can be swapped between two
partitions with the same name
U
- 2
al
+ START PIN test_si2
+ FLOATING E ( IN SI ) ( OUT Q )
rn
F ( IN SI ) ( OUT Q )
G ( IN SI ) ( OUT Q )
te
H ( IN SI ) ( OUT Q )
+ PARTITION CLK_45_45
In
+ STOP PIN test_so2
s 3- 136
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Example: Placement with Existing Ordering
A C G H
y
test_si1 test_so1
nl
O
se
E B D F
U
test_si2 test_so2
al
clk
rn
chain-order DC Netlist
te
Scan Chain 1 ABCD
Scan Chain 2 EFGH
In
s 3- 137
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Example: Reordering Within Scan-Chains
A C G H
y
test_si1 test_so1
nl
O
se
E B D F
U
test_si2 test_so2
al
clk
rn
chain-order DC Netlist SCANDEF w/o
te
PARTITION
Scan Chain 1 ABCD ACBD
In
Scan Chain 2 EFGH EGHF
s 3- 138
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Example: Reordering Within Partitions
Partition_1 Partition_1
A C G H
y
test_si1 test_so1
nl
O
se
E B D F
U
test_si2 test_so2
al
clk
rn
chain-order DC Netlist SCANDEF w/o SCANDEF with
te
PARTITION PARTITION
Scan Chain 1 ABCD ACBD ACGH
In
Scan Chain 2 EFGH EGHF EBDF
s 3- 139
sy
op
yn
rS
Fo
ed
er
i st
eg
R
This page was intentionally left blank
y
nl
O
se
U
al
rn
te
In
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Agenda
DAY
y
nl
O
5 Design Setup
se
U
6 Timing Setup
al
7
rn
Running CTS
te
In
s 4- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
NDM Cell Libraries © 2019 Synopsys, Inc. All Rights Reserved. 4-1
Unit Objectives
y
nl
O
 Describe what elements an NDM cell library contains
se
 Describe the general flow for cell library creation
 Create an NDM technology-only library
U
al
rn
te
In
s 4- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R
IC Compiler II Library Manager
Timing/Power Netlist
(.db) NDM cell
library
y
IC Compiler II SDC
Logic/
nl
Physical Library IC Compiler II
Physical (icc2_shell)
(.frame, Manager
Data Model
O
LEF, GDS) (icc2_lm_shell)
DEF
Standard cells
se
Technology SRAMs
(tf)
IP UPF
U
 NDM Cell Library creation is performed using a stand-alone tool
al
called ICC II Library Manager
rn
 Enables the quality of the library to be checked before implementation begins
 ICC II does not need to check the library setup, which significantly improves runtime
te
 Both applications share a unified logic and physical data model, called NDM
In
s 4- 3
sy
ICCII Library Manager does not require an additional license.
op
yn
rS
Fo
ed
er
i st
eg
R
IC Compiler II NDM Cell Library
NDM Cell Library

Physical
Technology
data
file
y
pvt1 pvt2 pvt4
.db .db ICC II pvt1 Shared
nl
.frame Library cell data
pvt3 pvt4
.db .db Manager pvt2 pvt3
O
LEF GDS
Single, unified, optimized
se
representation
ICC II NDM cell libraries (clibs) are created by merging logic and
U

physical models from the following sources:
al
 Logic libraries (.db files)
rn
 Physical libraries (.frame, LEF and/or GDS files from vendor)
Technology file
te

 After cell library creation, source files are no longer required
In
s 4- 4
sy
clib stands for cell library (standard cells or IP cells with logic, timing and physical data).
op
• Technology file
• Contains layer information and routing rules
• Physical libraries (LEF and GDS files, or .frame)
yn
• Contain physical shape data

• The .frame (frame-only NDMs) were created previously using just the physical data (LEF,GDS).
rS
This is typically done by the vendor.

• Logic libraries (.db files)
Fo
• Contain logic, timing, and power information.

• Each file represents a specific PVT (or “characterization point”)
ed
er
i st
eg
R
Cell Library Characteristics

NDM cell library
 The NDM cell library contains
Physical
pane3
Timing and Frame views
y
 data pane2
Shared
pane1
nl
cell data
 Design and Layout views optionally pane0
O
 The NDM cell library is a directory containing:
se
 The physical library data along with technology data
Since 2017.09
U
 One file for each timing pane
 Each db characterized for a PVT corner is represented as a “pane”
al
 The timing panes can be loaded dynamically by ICC II based on PVT configuration
rn
It is recommended to re-generate the CLIBs using 2018.06, to take
te

advantage of the new DB-less PT InDesign Flow (see unit 9)
In
s 4- 5
sy
Prior to 2017.09, the NDM cell library was a single monolithic file, and ICCII didn’t allow for dynamic pane
loading.
op
The timing and frame views are part of the NDM by default.
The design and layout views have to be enabled specifically in order to be added to the library.
This is controlled by the application options lib.workspace.save_design_views and
yn
lib.workspace.save_layout_views.
Layout Detailed physical shape information (all layers) with no connectivity.
rS
Once connectivity is created, leads to Design view. Imported by the read_gds command
Design Physical shape information with connectivity and pins. Imported by the read_lef or
Fo
read_gds –trace* commands. The basis for frame view creation.

Frame Minimal physical shape information for P&R with connectivity and pins
Created by the check_workspace command. Used by ICC II for routing
ed
Timing All cell timing+power information, arcs, attributes, and so on

Imported by the read_lib or read_db commands. Used for timing optimization/analysis
er
The view type can be accessed through Tcl commands. Use the view name to determine which view type:
Layout get_lib_cells $libName/*/layout
st
Design get_lib_cells $libName/*/design

i
Frame get_lib_cells $libName/*/frame

eg
Timing get_lib_cells $libName/*/timing

Note: The default view is ‘timing’, so the following commands return the same collection
R
get_lib_cells $libName/*/timing
get_lib_cells $libName/*/*
If you need to access the layout/design/frame views, you must use the exact name
To ensure you get the intended view, avoid using ‘*’ and always specify the view type.
Two Ways to create CLIBS
 CLIBS can be created in advance and stored at a central location
y
 Primarily using the “exploration flow” in Library Manager
nl
 This flow can automatically assemble logic and physical data
Could be “owned” by the library group, or project lead
O

 See the appendix for an example
se
U
 CLIBS can be generated “under the hood” by IC Compiler II
 User specifies .db and .frame files
al
 Library Manager (called under the hood) creates .clib transparently
rn
 Resulting .clibs stored in user directory
Also called “library configuration”
te

 More on how this is done in the “Design Setup” unit
In
s 4- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Ease of Use: Tech-Only NDM Library
 The design library that will hold your design data during
implementation must be associated with technology information as well
y
as RC parasitic models (TLU+)
nl
O
 It is possible to create a technology-only NDM that is used as a
se
container to store:
U
 Technology file
 RC parasitic model files (TLUPlus)
al
 Site symmetry and default site settings
rn
 Routing track settings
te
In
s 4- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Technology File
... abc14_9m.tf
 The technology file is unique Layer "M1" {
layerNumber = 11
to each technology isDefaultLayer = 1
y
maskName = “metal1”
pitch = 0.152
 Defines parameters for all
nl
visible = 1
selectable = 1
process layers: blink = 0
O
color = “blue”
 Layer name lineStyle = “solid”
pattern = “impdot”
GDSII layer number minWidth = 0.05
se

maxWidth = 5
 Colors and patterns for display defaultWidth

minSpacing
=
=
0.05
0.05
U
fatTblDimension = 5
 Design rules (width, spacing, fatTblThreshold = (0, …)
fatTblParallelLength = (0, …)
area, pitch, etc.)
al
fatTblSpacing = (0.05, …)
protrusionTblDim = 3
 Via contact definitions protrusionFatThresholdTbl = (0.15, …)
rn
protrusionLengthLimitTbl = (0.1, …)
(lower/upper metal layers, metal protrusionMinWidthTbl = (0.06,…)
enclosure, etc.) minArea = 0.01
te
minEnclosedArea = 0.2
}
 Default via array rules ...
In
 Site definitions s 4- 8
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Read TLU+ Models
read_parasitic_tech -tlup abc14_9T_Cmax.tluplus \
y
-layermap abc14_tf_itf.map -name maxTLU
nl
O
 TLU+ models are generated by StarRC from itf
se
 The name (in this example maxTLU) is used in ICC II during
U
implementation to associate the model with the correct corner
You can read and use as many TLU+ models as you like
al

For example emulation-fill TLU+, etc.
rn

te
In
s 4- 9
sy
StarRC is Synopsys’ sign-off parasitic extraction tool.
To create TLU+ files you need the itf as input to grdgenxo (part of the StarRC installation):
grdgenxo -itf2TLUPlus -input ITF_file -output TLU_file
op
The TLUPlus model file is in a binary format containing an ASCII header section that lists the input files
yn
used.
rS
The Mapping File maps the technology file (.tf) layer/via names to StarRC (.itf) layer/via names. The file is
optional if layers have the same names in the .tf and .itf files.
Fo
E.g. if the .tf file looked like this:

Layer "M1" {
layerNumber = 11
ed
maskName = "metal1"
And the .itf file looked like this:
DIELECTRIC cm1_extra3 { THICKNESS=0.06 ER=4.2 }
er
CONDUCTOR cm1 { THICKNESS=0.26 WMIN=0.16 …}

DIELECTRIC diel1d { THICKNESS=0.435 ER=4.2 }
st
Then the mapping file would have to map M1 to cm1:

i
conducting_layers
eg
PO poly
M1 cm1
R
M2 cm2
Placement Sites and Symmetry
 The technology file does not contain information on:

In the tech file:
y
 The symmetry requirements for cell placement Tile "unit_st" {
width = 0.152
nl
 The default site for floorplan initialization height = 1.672
}
O
 Set the site attributes as follows: Tile "unit_hp" {
width = 0.174
height = 2.58
se
}
set_attribute [get_site_defs unit_st] symmetry {Y}
set_attribute [get_site_defs unit_st] is_default true
U
al
N row N FN
rn
te
FS row FS S
In
Y
s 4- 10
sy
The is_default site attribute is used when creating the default site arrays/rows with initialize_floorplan, when
multiple site definitions exist. If no default site is defined, the first site definition is selected.
You do not need to have double or triple-height site rows! The placer can automatically place standard cells with
op
integer multiple heights of the single height row. You need additional site defs for non-integer heights, e.g. 1.2x or 1.5x
the single height. You can have a block with sections with different site heights: You first initialize the floorplan with
yn
one height, then you create a second site array with the different site height. For more information on creating site
arrays, review the command create_site_array (check the appendix of Unit 2: floorplanning).
rS
The classic way of defining the sites is done using the technology file + the attribute for symmetry shown above. You
can also create site definitions using Tcl:
Fo
create_site_def –name unit_8 –width 0.02 –height 0.16 –symmetry Y

Or you can read site size and symmetry information from a tech-lef:
read_lef LEF/saed32_tech_site.lef
VERSION 5.6 ;
ed
NAMESCASESENSITIVE ON ;
SITE unit
CLASS CORE ;
er
SYMMETRY Y ;
SIZE 0.152 BY 1.672 ;
END unit
st
END LIBRARY
If you read from a tech-lef, you need check_workspace before you commit the workspace.
i
X: Site is symmetric about the x axis. This means that N and FS sites are equivalent, and FN
eg
and S sites are equivalent. A cell with an orientation of N matches N or FS rows.

Y: Site is symmetric about the y axis. This means that N and FN sites are equivalent, and FS
R
and S sites are equivalent. A cell with an orientation of N matches N or FN rows.

X Y: Site is symmetric about the x and y axis. This means that N, FN, FS, and S sites are
equivalent. A cell with orientation N matches N, FN, FS, or S rows.
Generally, site symmetry should be used to control the flipping allowed inside the rows.
For more information, review the LEF documentation.
Routing Direction and Track Offset
 The technology file does not contain the following routing information
y
 Preferred routing direction
nl
 Routing track offset
O
 Specify the routing directions and track offsets:
se
set_attribute [get_layers {M1 M3 M5 M7}] \
U
routing_direction horizontal
set_attribute [get_layers {M2 M4 M6 M8}] \
al
routing_direction vertical
rn
set_attribute [get_layers {M1}] track_offset 0.03
te
In
s 4- 11
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Track Offset Explained

 The track offset equals the distance from the standard cell edge to the
center of the pin
 In the example below, the M1 track offset is the vertical distance between the
y
cell’s horizontal edge, and the center of the closest M1 pin
nl
 The M2 track offset is the horizontal distance between the cell’s vertical edge,
O
and the center of the closest M2 pin
se
M1 tracks CORE area of your block
U
Std cell
al
placement
STD CELL STD CELL row
rn
STD CELL STD CELL
M1 track offset M2 pin
te
M1 pin
In
0,0 M2 tracks
M2 track offset s 4- 12
sy
The lower-left corner (origin) of your block’s core area is (0,0). By default, horizontal and vertical metal
tracks start at this origin, and are spaced a “pitch” apart (defined in the technology file).
op
For maximum standard cell placement flexibility (flipping along X-axis for abutted row placement, and along
the Y-axis for symmetrical placement within rows), you cannot place standard cell pins right along the edges
yn
of the cells – this would cause the pins of abutted cells to short. In order to align with the metal routing
tracks, standard cell pins would, therefore need to be spaced an entire minimum pitch away from the cell
rS
edges, which can restrict pin placement within cells.

Fo
From a DRC spacing perspective (while also ensuring alignment to metal tracks), pins can be as close as ½
pitch away from the edge. Therefore, if standard cell pins are actually placed less than a track pitch away
from the edges, you need to specify a “track offset”, which is equal to this “pin offset” allowed within the
ed
standard cells (e.g. ½ the minimum pitch value, measured from the cell edge to the center of the pin). This
ensures that the metal routes align with their corresponding metal pins.
er
i st
eg
R
Tech Library Prep – icc2_lm_shell
icc2_lm_shell
y
create_workspace TECH_LIB -technology abc14_9m.tf
nl
read_parasitic_tech -tlup abc14_9T_Cmax.tluplus -name maxTLU
O
read_parasitic_tech -tlup abc14_9T_Cmin.tluplus -name minTLU
set_attribute [get_site_defs unit_st] symmetry Y
se
set_attribute [get_site_defs unit_st] is_default true
U
al
set_attribute [get_layers {M1 M3 M5 M7}] routing_direction horizontal
set_attribute [get_layers {M2 M4 M6 M8}] routing_direction vertical
rn
commit_workspace
te
TECH_LIB.ndm written to disk
In
s 4- 13
sy
The commands shown above are executed in icc2_lm_shell.
op
yn
rS
Fo
ed
er
i st
eg
R
Source File Information
 Later in ICC II, when using the cell libraries, you can still find out which
source files were used:
y
nl
icc2_shell> report_lib -physical saed32_1p9m_tech
…
O
Parasitics Name Source File
------------------------------------------------------------------------------------------
maxTLU maxTLU /global/…/tluplus/saed32nm_1p9m_Cmax.lv.tluplus
se
minTLU minTLU /global/…/tluplus/saed32nm_1p9m_Cmin.lv.tluplus
Source File Name
U
------------------------------------------------------------------------------------------
NDM /global/…/saed32_ndm/saed32_1p9m_tech.ndm
al
TF /global/…/tech/techfile/saed32nm_1p9m_mw.tf
...
icc2_shell> report_lib -physical saed32_hvt_lsdn
rn
...
Source .db file:
te
/global/.../lib/stdcell_hvt/db_nldm/saed32hvt_dlvl_ff0p95vn40c_i1p16v.db
...
In
s 4- 14
sy
op
yn
rS
Fo
ed
er
i st
eg
R
y
nl
 Describe what elements an NDM cell library contains
O
 Describe the general flow for cell library creation
Create an NDM technology-only library
se

U
al
rn
te
In
s 4- 15
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix
y
nl
O
Exploration Flow: Automated Cell Library Creation
Retrieving version information
se
Aggregate Libraries
U
al
rn
te
In
s 4- 16
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Library Manager (icc2_lm_shell) Flow
Creates a workspace to build NDM

Create a workspace libraries. Reads the technology file.
y
Read input data from Reads the physical and timing data for
nl
the desired PVT conditions into the
LEF, GDS, .frame, .db workspace.
O
Verifies the input data, identifies and
Check the workspace automatically corrects problems,
se
creates frame views.
User-driven
U
OK? User-driven problem correction
problem solving
al
Writes the combined data to disk as
Commit the workspace an NDM reference library and
rn
removes the workspace.
te
See the appendix for a discussion of the
NDM
In
exploration flow for cell library creation
s 4- 17
sy
When you run check_workspace, these are some of the problems that are fixed automatically:
• If a cell in the physical library has power or ground pins that are not defined in the logic
op
libraries, the tool automatically adds these pins to the logic cell
• If a pin is defined as a signal pin in the logic library, but is defined as a PG pin in the
yn
physical library, the tool issues a warning, redefines the pin as a PG pin, and removes all
timing information from the pin.
rS
• If a pin does not have a pin type in the physical library, as is the case when you read
GDSII files, the tool uses the pin type from the logic libraries.
Fo
See the Library Preparation User Guide for more information.

ed
User-driven problem solving might be as simple as changing an attribute on a pin, or making a

change in the physical view, but it can also entail loading new physical or logic data.
er
i st
eg
R
Exploration Flow: Automated Cell Library Creation
 The exploration flow is an automated flow to create cell libraries

 You use commands to:
y
Load ALL the logic (.db) and physical libraries (LEF, GDS, .frame) for ALL cells
nl

(standard cells, IP cells, etc. at all available PVTs and Vths e.g. HVt, RVt, LVt, …)
O
 Select the PVT parameters (Process, Voltage, Temperature) you desire for your
design
se
U
 Let Library Manager do the rest
al
 Combines the correct logic and physical views
 Checks for consistency
rn
 Creates the frame views for all loaded cells
te
 Creates NDM cell libraries
In
s 4- 18
sy
IC Compiler II Library Preparation Application Notes:
https://solvnet.synopsys.com/retrieve/2244057.html
op
IC Compiler II frame view extraction:

yn
rS
Fo
ed
er
i st
eg
R
PVT Configuration
Used after reading in

libs, if available PVTs
are not known
y
nl
O
se
U
al
Used before reading
in libs, if available
rn
PVTs are known
Using PVT configurations, you can let ICCII library
te
manager find the right timing libraries based on the
P/V/T you specify. Just pass all DBs to the tool.
In
s 4- 19
sy
Using PVT configurations, you can configure the exploration flow to use only a subset of the libraries. You
can set this up before reading any libraries (as shown on the right – just list the voltages, processes and
op
temperatures you want), or after you have read in libraries (shown on the left – there you can pick/select what
you would like to include in the final NDMs).
yn
This makes library configuration simple and accurate

• Even when a specific naming convention is used, it is not a guarantee that the content of the file matches
rS
the file name

• If the file names are obscured, there is no information in the name to indicate the underlying PVT
Fo
It is better for the library manager to pick the files based on the content
• Allows for quicker analysis over many logic library files that can be rejected if they do not match the
desired configuration
ed
• Reference libraries can now be specific to a design because there is now no need for “one-size-fits-all”
libraries
er
• Quicker to create
• Smaller size on disk
i st
eg
R
Exploration Flow – Example Output

icc2_lm_shell
create_workspace EXPLORE -flow exploration -technology tech.tf
set_pvt_configuration –voltages {0.95 1.16} –temperatures {125 -40}
y
read_db [glob ./libs/DB/*.db]
nl
foreach frame [glob ./libs/frames/*.frame] {read_ndm $frame}
O
group_libs
write_workspace -file lib_template.tcl
se
process_workspaces
U
lib_template.tcl
al
# Group 1: # Group 2:
create_workspace "LIB_hvt_ff_c" \ create_workspace "LIB_lvt_ff_c" \
-tech ./LIB_nm_1p9m_ft.tf -tech ./LIB_nm_1p9m_ft.tf
rn
read_db ./libs/DB/LIB_hvt_ff0p95v125c.db read_db ./libs/DB/LIB_lvt_ff0p95v125c.db
read_db ./libs/DB/LIB_hvt_ff0p95v40c.db read_db ./libs/DB/LIB_lvt_ff0p95vn40c.db
read_db ./libs/DB/LIB_hvt_ff1p16v125c.db read_db ./libs/DB/LIB_lvt_ff1p16v125c.db
read_db ./libs/DB/LIB_hvt_ff1p16v40c.db read_db ./libs/DB/LIB_lvt_ff1p16vn40c.db
te
read_ndm ./libs/NDM/LIB_nm_hvt_1p9m.frame read_ndm ./libs/NDM/LIB_nm_lvt_1p9m.frame
check_workspace check_workspace
commit_workspace -output LIB_hvt_ff_c.ndm commit_workspace -output LIB_lvt_ff_c.ndm
In
...
s 4- 20
sy
In an exploration flow, the process_workspaces command expects to work on sub-workspaces, which
must first be created by group_libs.
group_libs
op
• Analyzes all library source files and groups the timing and physical data into the most efficient
final reference libraries
yn
• Creates all the subworkspaces that will be checked and committed – each subworkspace will be
one NDM
rS
• Required in an exploration flow, before process_workspaces

write_workspace
• Generates a Tcl script to re-create the library groupings from the group_libs command
Fo
• This is optional, and not required for final reference library generation
• You can edit the Tcl script if you need to change library names, add process labels, or make any
ed
other modifications
• Source the Tcl script in icc2_lm_shell to re-create the final reference libraries
er
The exploration flow names workspaces using a unique combination of logic library prefix and suffix
characters. Generally this creates a meaningful name. To select different workspace naming strategies, use
st
the lib.workspace.group_libs_naming_strategies application option.

i
eg
Example outout of group_libs:

icc2_lm_shell> group_libs
…
R
Created 5 lib groups

Created sub workspace saed32lvt_c with type normal. 8 logical libs, 1 physical libs, 0 scaling group.
Created sub workspace saed32rvt_c with type normal. 8 logical libs, 1 physical libs, 0 scaling group.
Created sub workspace saed32lvt_dlvl_v with type normal. 4 logical libs, 1 physical libs, 0 scaling group.
Created sub workspace saed32rvt_ulvl_5v with type normal. 4 logical libs, 1 physical libs, 0 scaling group.
Created sub workspace physical_only with type physical_only.
Created 5 sub workspaces
Retrieving Version Information
 To retrieve the version of library manager that was used to generate the
cell library, use the following attributes:
y
nl
O
icc2_shell> get_attribute [get_libs saed32_hvt] read_from_product_name
IC Compiler II Library Manager
se
icc2_shell> get_attribute [get_libs saed32_hvt] read_from_product_version
N-2017.09-SP1 for linux64 -- Oct 10, 2017
U
icc2_shell> get_attribute [get_libs saed32_hvt] read_from_schema_version
1.223
al
rn
te
In
s 4- 21
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Separate Reference Libraries
NDM_A NDM_B NDM_M
y
nl
HVT1 LVT1 MACRO1
HVT2 LVT2 MACRO2
O
HVT3 LVT3 MACRO3
se
 Each reference library is separate
 Must be specified and opened separately
U
 You need to know which cell is in which library
al
 The reference library search order is defined when
the design library is created in ICC II
rn
te
In
s 4- 22
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Aggregate Reference Library
Name: ALIB
Order: NDM_A NDM_B NDM_M
y
nl
NDM_A NDM_B NDM_M
O
HVT1 LVT1 MACRO1
HVT2 LVT2 MACRO2
HVT3
se
LVT3 MACRO3
 An aggregate reference library combines separate
U
NDM reference libraries
 Enables simple distribution of multiple related reference libraries
al
 ICC II refers to one aggregate reference library rather than
multiple separate reference libraries
rn
 An aggregate reference library has
te
 A single name that is used to refer to any cell in the aggregate
library
In
 A defined search order for the included reference libraries
s 4- 23
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Aggregate Library – Example Script
# Create the workspace in aggregate mode

create_workspace std_lib -flow aggregate
y
# Open the existing libraries that are to be part of the aggregate
nl
read_ndm ./LIBRARIES/ndms/hvt_lib.ndm
read_ndm ./LIBRARIES/ndms/lvt_lib.ndm
O
read_ndm ./LIBRARIES/ndms/rvt_lib.ndm
# Report all the open libraries
se
get_libs
report_workspace
U
# Check the aggregate workspace and report any cell eclipse issues
check_workspace
al
# Define the aggregate library search order
rn
set_lib_order {hvt_lib rvt_lib lvt_lib}
te
# Commit the workspace to create the aggregate library
commit_workspace [-output new_std_lib.ndm]
In
s 4- 24
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Agenda
DAY
y
nl
O
5 Design Setup
se
U
6 Timing Setup
al
7
rn
Running CTS
te
In
s 5- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Design Setup © 2019 Synopsys, Inc. All Rights Reserved. 5-1

Design Setup Objectives
y
nl
O
 Create a design library
se
 Load the netlist and power intent (UPF)
U
 Apply the floorplan
al
 Load the scan chain definitions (scan-DEF)
rn
 Connect PG and enable tie cells
te
In
s 5- 2
sy
UPF = Unified Power Format
TLU+ files contain the data needed for RC parasitic extraction
op
yn
rS
Fo
ed
er
i st
eg
R


Synthesis
y
Design & Timing Setup This Unit
nl
O
se
U
CTS & Optimization
al
rn
te
Signoff
In
s 5- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Design Setup
ndm ndm
Cell Libraries Standard IP
(Logic, timing, physical) cells cells
y
Technology Library ndm
nl
(Technology and TLUPlus) Techno- IC Compiler II
logy
Design Library
O
Technology File ORCA.dlib
(.tf file)
se
RC Model Files
(TLU+)
U
Gate-Level Netlist
(Verilog) ORCA
al
MCMM Timing
Constraints Floorplan
rn
(SDC+Tcl) (DEF + Tcl)
Block
te
Power Intent Scan Chain
(UPF) (SCAN-DEF)
In
s 5- 4
sy
The solid arrow indicates that the data from these files are saved in the design block, design library or
reference library. This means that once this data is loaded, and the design database is saved, the files are no
op
longer needed or used, when the design and/or library is closed and subsequently re-opened.
The dotted-line arrow indicates that only “pointers” to this data are saved in the design library. This means
yn
that after this data is loaded, even after the design database is saved, the reference libraries must remain
available to be re-loaded, when the design, the design library and/or the ICC II session is closed and
rS
subsequently re-opened.
Fo
The technology file and TLUPlus files can be loaded into a technology-only reference library
(recommended), and/or in the design library (if preferred by the user).
ed
er
i st
eg
R

Create a “Container”: The Design Library
Create a design library Techno-

logy
Standard
cells
IP
cells
 Specify the technology and cell libraries
y
 Created in memory only (by default) Design Library
nl
ORCA.dlib
O
lappend search_path /x/y/libs
create_lib ORCA.dlib \
se
-use_technology_lib abc14_9m_tech.ndm \
-ref_libs {
U
abc14_9m_tech.ndm
abc14_hvt_std.ndm abc14_svt_std.ndm abc14_lvt_std.ndm
abc14_srams.ndm abc14_ip.ndm
al
}
rn
If -use_technology_lib is used, the technology library must be listed in –ref_libs
te
If you set lib.setting.on_disk_operation to true, create_lib writes to disk upon creation
In
s 5- 5
sy
The design library, created by the user, acts as the “container” for all the associated input data required for
physical design , and will also house the physical module design blocks (referred to simply as designs), which
op
are created and saved at the different stages of the physical design flow (after placement, after CTS, and after
routing, for example).
yn
The first step in data-setup is to create the design library. This entails giving the library a user-defined name,
and specifying the technology library and reference libraries to be used with this design library. The design
rS
library saves “pointers” to the reference and technology libraries (saved as absolute paths) . When a design
library is closed, and subsequently re-opened, these libraries must be available in the UNIX directory
Fo
structure, to be re-loaded.
Note that when you use a separate technology library, even though that library is specified with the
ed
–use_technology_lib option, it has to also be listed in -ref_libs along with all the other reference
libraries.
er
To report the source db file for each pane in a reference library: report_lib <lib_name>
i st
eg
R

Technology Information
 If using a technology library, you should ensure that it

contains all information that was discussed in the NDM unit
y
 If using a technology file, you need to apply TLU+, site and
nl
routing track information in ICC II:
O
create_lib ORCA.dlib -technology abc14_9m_tech.tf –ref_libs …
se
read_parasitic_tech -tlup abc14_9T_Cmax.tluplus -name maxTLU
U
read_parasitic_tech -tlup abc14_9T_Cmin.tluplus -name minTLU
al
set_attribute [get_site_defs unit] symmetry Y
set_attribute [get_site_defs unit] is_default true
rn
set_attribute [get_layers {M1 M2}] track_offset 0.03
set_attribute [get_layers {M1 M3 M5}] routing_direction horizontal
te
set_attribute [get_layers {M2 M4 M6}] routing_direction vertical
In
s 5- 6
sy
If not specified by the user, the following routing directions are automatically used:
M1, M3, M5, …for horizontal routing
op
M2, M4, M6, …for vertical routing

Track offset will be 0 by default.
You will receive warnings in ICC II as long as you don’t set these attributes specifically.
yn
To report the available parasitic models available:

rS
report_lib -parasitic_tech saed32_1p9m_tech

…
Fo
Parasitic tech data:

----------------------------------------
Parasitic tech name: maxTLU
Parasitic itf technology name: saed32nm_1p9m_Cmax
ed
Parasitic tech type: TLUPLUS

Parasitic source file name: ./tluplus/saed32nm_1p9m_Cmax.tluplus.as
er
Parasitic canonical file name: /global/…./tluplus/saed32nm_1p9m_Cmax.tluplus

…
st
If you want to read an updated technology file into your existing design library, use the read_tech_file
i
eg
command to replace the existing tech section in the library. The replacement tech must be compatible with
the existing tech section. Being compatible means that the replacement tech must contain a super-set of the
following list of objects: Layer, ContactCode, Tile.
R
See the man page for more details. Note that once you read an updated technology file, all attributes formerly
applied are lost, and will have to be reapplied.

Design Library Compression
 IC Compiler II can compress blocks in the design library
y
nl
 To enable compression, set the following before creating the library:
O
set_app_options –name lib.setting.compress_design_lib –value true
se
U
 You can compress all blocks or the current block:
al
save_lib -compress
save_block -compress
rn
te
In
s 5- 7
sy
save_lib saves (and compresses) all changed blocks.
If a block changes after saving with the -compress option, any subsequent save operation will
automatically compress the block - the -compress option is not needed.
op
yn
rS
Fo
ed
er
i st
eg
R

Reference Library Paths
When creating a design library, reference libraries can be

specified in two ways
y
 Libraries found using search_path, stored as absolute paths
nl
lappend search_path ../libs
O
-use_technology_lib abc14_9m_tech.ndm \
-ref_libs { \
abc14_9m_tech.ndm
se
abc14_hvt_std.ndm ...
}
U
 Libraries specified with path, stored as given (here: relative paths)
al
-use_technology_lib ../libs/abc14_9m_tech.ndm \
rn
-ref_libs { \
../libs/abc14_9m_tech.ndm
te
../libs/abc14_hvt_std.ndm ...
}
In
s 5- 8
sy
Q: What happens if you specify a “symbolic link” for the paths to the ref libs – is it saved as the symbolic
link, or followed to the actual path?
op
A: Links are never dereferenced, but stored as given (so in this case as the symbolic link). This applies to
both the search_path as well as ref libs given with a path.
yn
It is completely acceptable to rely on the search_path for some libraries, while including relative and/or
rS
absolute paths with other libraries, for example: In a hierarchical design, the “sub-block” libraries might be
specified with a relative path, and the standard cell and hard macro libraries are stored as an absolute path,
Fo
either using the search_path variable, or included in the ref_libs name. If the design library in this
example is moved, as long as the “block” libraries are moved along with it, all references will be resolved
(linked to a reference library).
ed
er
i st
eg
R

Moving Design and/or Reference Libraries
With absolute reference library paths:
y

nl
 If the design library moves, nothing changes – libraries still resolve
 If the reference libraries move, you need to update the search path and rebind
O
se
 With relative reference library paths:
U
 Reference libraries need to move along with the design library
 If they do not move along, you need to update the reference library paths
al
rn
te
In
s 5- 9
sy
The location of a design library can change if, for example, a user copies someone’s design library to their
local working directory. The location of reference libraries commonly change, for example, if newer versions
op
exist elsewhere, or due to disk migration.

yn
rS
Fo
ed
er
i st
eg
R

Rebind a Design Library
icc2_shell> open_lib $DESIGN_LIBRARY

Information: Loading library file 'ORCA.dlib' (FILE-007)
Error: File '/old_location/saed32_1p9m_tech.ndm' cannot be found using
y
search_path of: '.'. (FILE-002)
nl
Information: Loading library file '/old_location/saed32_hvt_std.ndm' (FILE-007)
…
icc2_shell> set search_path "/new_location"
O
icc2_shell> set_ref_libs –rebind Rebinding as shown here only works with
saed32_1p9m_tech.ndm saed32_hvt_std.ndm … absolute paths. For relative paths, use
se
set_ref_libs -remove / -add
icc2_shell> report_ref_libs
U
Name Path Location
--------------------------------------------------------------
*+ saed32_1p9m_tech saed32_1p9m_tech.ndm /new_location/saed32_1p9m_tech.ndm
al
*+ saed32_hvt_std saed32_hvt_std.ndm /new_location/saed32_hvt_std.ndm
…
rn
"*" = Library currently open
"+" = Library has technology information
te
icc2_shell> save_lib
In
s 5- 10
sy
As you see after the first command, it may be that some libraries are no longer at the “old_location”, in which
case an Error is reported.
op
If other libraries are still available at the old location, they will continue to be used.
After rebinding, make sure to check “report_ref_libs”, which should show the new absolute paths to the
reference libraries, and make sure to save the library.
yn
The set_ref_libs command can also be used to add new reference libraries or to entirely update the
rS
library list, for example:

set_ref_libs [-library name] -ref_libs {paths}
set_ref_libs [-library name] -ref_libs {paths} -use_technology_lib path
Fo
set_ref_libs [-library name] -add path [-before path]

set_ref_libs [-library name] -remove path
set_ref_libs [-library name] -clear
ed
set_ref_libs [-library name] -rebind
The method shown on the slide using set_ref_libs -rebind only works with absolute paths. If you
er
wanted to update relative reference libraries, you could do:

st
set_ref_libs -remove ../old_ref/abc_lib.ndm -add ../new_ref/abc_lib.ndm

i
If the CLIB library content changes but not the name/location, nothing special has to be done, the library will
eg
be linked to in the usual manner. You need to ensure though that the techfile information in the new library is
not too different from your design tech file. Currently, you cannot have additional or missing routing layers
R
across libraries.

Read .db and .frame directly into ICC II

2017.09
 Instead of using pre-assembled cell libraries, it is now possible

to read liberty (.db) and frame-only-views (.frame) directly
y
 Library Manager is called under-the-hood to create cell libraries (clibs)
nl
 The generated clibs are automatically linked to the design
O
ASCII
.db .frame Tech-File
se
 Use the search_path and link_library
variables (similar to ICC and DC)
U
IC Compiler II
al
 Generated clibs are automatically re-generated
Place
rn
if their logical or physical source files change:
 Added or removed logic libraries (.db files) .ndm and
te
Route
 Updated source files, e.g. technology file, .frame views
In
s 5- 11
sy
clib stands for cell library (standard cells or IP cells with logic, timing and physical data).
op
To determine whether a source file has changed, source file paths and signatures for both logical and physical
data (.db, .frame, techfile) is stored in the generated clibs, along with tool version and NDM schema. The
next time you open the design library and link to the clibs, the check is performed, and the clibs are
yn
regenerated if a change has occurred.

rS
Fo
ed
er
i st
eg
R

Library Configuration Example
# Specify the search path for finding .db and .frame

set_app_var search_path ". lib_data/DB lib_data/FRAME"
y
nl
# Specify the .db(s)
O
set_app_var link_library "* xx_ff_1p16v_n40c.db … xx_ss_0p95v_125c.db"
se
# Optional – specify where to store the assembled clib(s) (default is ./CLIBs)
set_app_options -name lib.configuration.local_output_dir -value "../MY_CLIBS"
U
al
# Specify the .frame in the create_lib call
# This will launch Library Manager under the hood to create the clib(s)
rn
-technology abc14.tf \
te
-ref_libs {xx_abc14_hvt.frame … RAM_abc14.frame}
In
s 5- 12
sy
If the design library already exists and you only want to update the clibs (library cache):
set_ref_libs -library $DESIGN_LIBRARY $ref_libs
op
To generate the required cell libraries, ICC II launches ICC II Library Manager under the hood and invokes
the exploration flow for automated cell library creation.
yn
Application variables (like search_path and link_library) are non-persistent – they must be re-applied
rS
when ICC II is re-invoked.
Note that library configuration is currently only supported when using a tech file, and not a tech-only NDM.
Fo
ed
er
i st
eg
R

Combination of Pre-Assembled and Generated CLIBs
 Besides generating all CLIBs (.db + .frame), it is possible to generate

CLIBS for some, and use pre-assembled CLIBs (.ndm) for others
y
nl
 Example: .ndm for standard cells and .db + .frame for macros & IP (see notes)
 .ndm(s) take precedence: Specified .db files that are used by .ndm(s) are
O
ignored (see notes)
se
 If pre-assembled CLIBs were originally used, and updated .db files
U
and/or .frame library(ies) become available, CLIB(s) can easily be
al
generated for the updated data (example shown next)
Need to specify .db(s) and .frame(s) for CLIB generation to occur
rn

te
In
s 5- 13
sy
Example using .ndm and .frame+.db:
set_app_var search_path ". lib_data/DB lib_data/FRAME"
set_app_var link_library "* srams_ff_1p16v_n40c.db … srams_ss_0p95v_125c.db"
op
-technology abc14.tf \
yn
-ref_libs {std_lvt.ndm std_hvt.ndm SRAM_abc14.frame}

This will invoke Library Manager to generate the SRAM cell library.
rS
Now assume that link_library was specified as:

set_app_var link_library "* srams_ff_1p16v_n40c.db … std_lvt_ss_0p95_125c.db"
Fo
If the std_lvt*db was used originally to create the std_lvt.ndm cell library, it will be ignored. No
second, redundant, cell library will be generated.
ed
er
i st
eg
R

Example: Using Updated .db Files

 Original set-up of design library using pre-assembled CLIBs:
lappend search_path /x/y/clibs
create_lib ORCA.dlib -technology abc14_9m.tf \
y
-ref_libs { abc14_std.ndm abc14_ls.ndm abc14_sram.ndm }
nl
read_verilog ...
Configuration to use newer SRAM .db files:
O

lappend search_path /x/y/sram_db /x/y/sram_frame
se
# Specify the new .dbs
set link_library "* sram_125C.db sram_20C.db sram_m40C.db"
U
# Replace pre-assembled SRAM .ndm with its original .frame
set_ref_libs { abc14_std.ndm abc14_ls.ndm sram.frame }
It is necessary to replace the
al
...library building process occurs... entry for the existing pre-
assembled CLIB with its .frame
rn
report_ref_libs (.ndm has priority over .db)
*+ abc14_std abc14_std.ndm
te
*+ abc14_ls abc14_ls.ndm
*+ abc14_sram CLIBs/abc14_sram.ndm
In
s 5- 14
sy
The CLIB file name (abc14_sram.ndm) is generated automatically by library manager using the common
sub-strings of the logic db library names (not the db file names).
op
In the example above, if the .frame was updated instead of the .dbs, the original (unchanged) db files would
be listed in the link_library variable, and the updated .frame would be specified in set_ref_libs.
yn
If the .dbs and .frame are updated, specify updated .dbs and .frame libraries.
rS
To avoid the overhead of having every single user store a copy of the CLIBs in their project directory, it is
possible to share CLIBs among users and yet allow creation of new CLIBs in the local directory if needed.
Fo
For example, say user1 stores all generated CLIBs in user1/CLIBs:

set_app_options –name lib.configuration.local_output_dir –value /home/user1/CLIBs
set_app_var link_library "..."
create_lib ORCA ...
ed
user2 can reuse CLIBs in user1’s directory. If a CLIB is not found there, a new CLIB is assembled in user2’s
local directory:
er
set_app_options –name lib.configuration.central_output_dir –value /home/user1/CLIBs

set_app_options –name lib.configuration.local_output_dir –value /home/user2/CLIBs
st
set_app_var link_library "..."

create_lib ORCA ...
i
Note that in this case the central_output_dir will only be used as read-only.
eg
R

Read the Netlist and Create a Design
Techno- Standard IP
logy cells cells
lappend search_path ./netlist
y
read_verilog -top ORCA ORCA.v
nl
link_block
Design Library
O
ORCA.dlib
se
U
Gate-Level Netlist
(Verilog)
al
ORCA
rn
te
Design view of the block,
created when netlist is read in ORCA.dlib:ORCA.design
In
s 5- 15
sy
Note: ICC II uses application options instead of application variables: search_path is an application
variable, which is an exception.
op
The –top option of read_verilog defines the current design. If not specified, the last module in the RTL
becomes the current design.
yn
rS
Fo
ed
er
i st
eg
R

Linking
 Linking is still considered “successful” if there are missing references:
y
icc2_shell> link_block
Using libraries: ORCA_TOP.dlib saed32_1p9m_tech saed32_hvt_std saed32_rvt_std …
nl
Linking block ORCA_TOP.dlib:ORCA_TOP.design
Warning: Unable to resolve reference to 'SRAMLP2RW64x32' in module 'SDRAM_TOP'. (LNK-005)
…
O
Information: Block 'ORCA_TOP.dlib:ORCA_TOP.design' has 4 unbound instances. (LNK-073)
Information: Block 'ORCA_TOP.dlib:ORCA_TOP.design' has 1 unresolved references. (LNK-074)
Design 'ORCA_TOP' was successfully linked.
se
 If you want ICC2 to cause a Tcl error instead: set_message_info -id LNK-005 -stop_on
U
 A successful link allows you to continue with the flow if you choose
al
 For example, you may decide to turn unresolved instances into black boxes
rn
 To report linking issues later, use: (see notes for output)
te
report_design_mismatch –verbose
get_cells -hierarchical -filter is_unbound
In
s 5- 16
sy
The following cause the link_block command to fail: Mismatched port references to a lib cell or to a module in
the same block, and circular or recursive module references. To correct these problems you must remove the
block, correct the Verilog netlist, and reread the design.
op
Be aware that even though linking might be successful, this does not mean that place_opt will run. You need to
resolve unbound references, e.g. by creating black boxes for them, otherwise place_opt will abort.
yn
For example, if you wanted to turn the missing SRAM from the slide example into a black box, you could run the
following commands:
rS
icc2_shell> report_design_mismatch -verbose

==============================
Design : ORCA_TOP
Fo
==============================
Mismatch Type Count Repaired
---------------------------------------------------------------------
missing_logical_reference 1 0
ed
Mismatch Type : missing_logical_reference

ObjName ObjType State Repair Strategy Inst MMObjName
er
-----------------------------------------------------------------------------
saed32_SRAMLP2RW64x8:SRAMLP2RW64x8
st
design not_repaired null 16 missing_logical_\

reference_ORCA_TOP_saed32_SRAMLP2RW64x8:SRAMLP2RW64x8
i
icc2_shell> get_cells -hierarchical -filter is_unbound

eg
I_SDRAM_TOP/I_SDRAM_READ_FIFO/SD_FIFO_RAM_1 I_SDRAM_TOP/I_SDRAM_READ_FIFO/SD_FIFO_RAM_0
I_SDRAM_TOP/I_SDRAM_WRITE_FIFO/SD_FIFO_RAM_1 I_SDRAM_TOP/I_SDRAM_WRITE_FIFO/SD_FIFO_RAM_0
icc2_shell> create_blackbox -type macro I_SDRAM_TOP/I_SDRAM_READ_FIFO/SD_FIFO_RAM_1
R
Information: The hierarchical edit-control of committed block SRAMLP2RW64x32 is set editable in the
top-level context of ORCA_TOP. (NDM-129)
Committed cell I_SDRAM_TOP/I_SDRAM_READ_FIFO/SD_FIFO_RAM_1 to blackbox design SRAMLP2RW64x32
Committed another 3 cells to the same design:
I_SDRAM_TOP/I_SDRAM_READ_FIFO/SD_FIFO_RAM_0
I_SDRAM_TOP/I_SDRAM_WRITE_FIFO/SD_FIFO_RAM_1
I_SDRAM_TOP/I_SDRAM_WRITE_FIFO/SD_FIFO_RAM_0

Load the Power Intent
y
 Unified Power Format (UPF) is an IEEE standard (1801)
nl
 UPF defines the entire “power intent and structure” of a
O
multi-voltage design
se
 The netlist that was read in will already contain multi-voltage (MV)
components from Synthesis, like level shifters (LS), isolation cells
U
(ISO), retention registers
al
rn
te
In
s 5- 17
sy
ICC2 by default is MV-aware and MCMM-aware. That is, even if you don’t load a UPF, internally ICC2
will create a default UPF file, which all the ICC2 engines will be based on.
op
The default UPF only creates one power domain, VDD/VSS SN (Supply Net), SP (Supply Port) and CSN
(connect_supply_net). If your design has DVDD/DVSS, then the default UPF will not work. In that case,
you can set the following application options:
yn
set_app_options -list {mv.pg.default_power_supply_net_name DVDD}

set_app_options -list {mv.pg.default_ground_supply_net_name DVSS}
rS
set_app_options -list {mv.pg.default_power_supply_port_name DVDD }

set_app_options -list {mv.pg.default_ground_supply_port_name DVSS}
Fo
ed
er
i st
eg
R

Support of Golden-UPF and UPF’/UPF” Flows

UPF’/UPF’’ flow load_upf ORCA.prime.upf
UPF RTL commit_upf
…
y
Design Compiler save_upf ORCA.icc2.upf
nl
O
Netlist
UPF’ Golden UPF flow
Golden RTL
se
IC Compiler II UPF
set_app_options –value true \
Netlist Design Compiler –name mv.upf.enable_golden_upf
U
UPF” read_name_map name_map.file
PG netlist
load_upf ORCA.golden.upf
al
S-UPF
Name mapping load_upf ORCA.supplemental.upf
rn
IC Compiler II commit_upf
…
te
PG netlist save_upf ORCA.icc2_suppl.upf
S-UPF
Name mapping
write_name_map name_map_icc2.map
In
s 5- 18
sy
UPF’/UPF’’ flow:
• All UPF changes performed by Design Compiler are captured in a UPF’ file
• All UPF’ changes performed by ICC II are captured in a UPF’’ file
op
Golden UPF flow:

• User UPF is preserved as golden UPF (G-UPF)
yn
• All intent changes captured in supplemental UPF (S-UPF)

• You can optionally use the Verilog netlist to store all PG connectivity information, making
rS
connect_supply_net commands unnecessary in the UPF files. This can significantly simplify
and reduce the overall size of the UPF files.
• All name changes captured in name mapping file
Fo
DC generates supply connectivity info that is normally captured in the UPF’ file. For the Golden UPF flow, that
supply connectivity info can either be captured in the Supplemental-UPF file (without a "PG Netlist”), or the user
has the option to capture it in the “PG Netlist”, in which case that information is not needed in the S-UPF file.
ed
save_upf will write full or supplemental UPF based on the setting of mv.upf.enable_golden_upf.
er
The following is an example of a name mapping file:

st
# Query Rules
set_query_rules hierarchical_separator {/ _} bus_notation {[] __}
i
eg
# Tcl built-in: local variables

set hier_1 A/B/C/D
set hier_2 A_B/B2/this/is/a/long/path
R
# Explicit name maps

define_name_maps -application golden_upf -design_name design \
-columns {class pattern options names} \
[list cell $hier_1/A_reg [list leaf] [list $hier_2/ger_A] ] \
[list cell A/B/X*_reg [list nocase leaf] [list A_B/zar_reg A_B/Y_reg3]]
# cleanup
unset hier_1
unset hier_2

Modifying Power Intent after commit_upf
 After successfully running the commit_upf command, ICC II issues

an error message if you apply additional UPF commands, except for:
y
nl
 set_related_supply_net
 connect_supply_net
O
 set_design_attributes
se
 set_port_attributes
 find_objects
U
 set_scope
al
rn
 To modify the power intent after running commit_upf, you must remove
the existing UPF specification by using reset_upf and then reload the
te
power intent
In
s 5- 19
sy
In order to write out UPF from ICCII, use:
• Golden mode: save_upf -format supplemental mydesign.upf
• UPF’ mode: save_upf mydesign.upf
op
yn
rS
Fo
ed
er
i st
eg
R

Load a DEF Floorplan File
 If the floorplan was saved with write_def (not recommended) load it with:
y
nl
read_def -add_def_only_objects all ORCA.def
O
 By default, the tool ignores cells that exist in the DEF file but not in the netlist (tap
se
and end-cap cells, for example)  use –add_def_only_objects all to add
these cells to the netlist
U
al
 Use DEF version 5.7 or later when possible
rn
te
In
s 5- 20
sy
Starting with version K-2015.06-SP1, the read_def command performs fuzzy name matching when an
object name in the DEF file does not match an object name in the design. Fuzzy name matching supports the
op
following types of constructs in the DEF object names:

• Verilog style name escaping.
These are names that begin with the '\' character to escape all special characters within the name.
yn
• DEF hierarchical separators in places where they do not denote hierarchy

• Escaped DEF hierarchical separators in places where they do denote hierarchy
rS
Fo
ed
er
i st
eg
R

Caution: Unsupported Constructs in DEF

 In version 5.7 of DEF the following constructs are not supported:
 Group bounds (no fixed coordinates)
y
 create_bounds –dimensions ...
nl
 Partial blockages for category / register / allow_buffer_only
create_placement_blockage –type register -blocked_percentage 10 …
O

 Voltage areas
se
 create_voltage_area -power_domains ...
 Layer Assignments
U
 set_routing_rule -min_routing_layer "M6" \
-max_routing_layer "M7" … [get_nets {abc}]
al
rn
If any of the above Tcl commands were used
te
during floorplanning, they must be re-applied in
ICC II after reading the DEF floorplan file
In
s 5- 21
sy
Note that ICC II automatically creates a voltage area called DEFAULT_VA, associated with the top-level UPF
power domain. You must create voltage areas for all other UPF power domains before running placement.
op
yn
rS
Fo
ed
er
i st
eg
R

Load the Floorplan
 If write_floorplan was used in ICC II to save the floorplan:

source orca_top.fp/floorplan.tcl
y
nl
 Applies DEF and Tcl floorplanning commands
O
floorplan.tcl
…
se
source ${_dirName__0}/fp.tcl
fp.tcl
U
…
remove_site_arrays
al
…
read_def … ${_dirName__0}/floorplan.def
rn
remove_voltage_areas -all
te
set voltArea [create_voltage_area
…remaining Tcl floorplanning commands
In
s 5- 22
sy
The following is the desired floorplan information that should be conveyed to ICC II:
op
Die/core definition
Terminals, tracks, site rows
Voltage areas
yn
Hard macros
Fixed location
rS
Memories, physical-only cells, logical cells from DEF

Keepout margins
Fo
Physical-only cells
Fixed location, but no hard macro attribute (e.g. end caps)
PG net shapes and vias
ed
Route guides
Signal-layer blockages
er
Placement Blockages
Soft blockages, partial blockages (with -no_register or -buffer_only)
st
Bounds
Soft move bounds and group bounds
i
eg
Standard cells
Location (for SPG flow)
R

Specify Unused Routing Layers
 By default ICC II uses all metal layers defined in the technology file
y
 If using fewer metal layers this can result in:
nl
 Optimistic congestion analysis pre-route
O
 Inaccurate delay calculations due to inaccurate parasitic RC calculations
Specify the unused or “ignored” layers for accurate congestion and
se

timing analysis prior to routing
U
al
set_ignored_layers –max_routing_layer M7
report_ignored_layers
rn
te
In
s 5- 23
sy
This command is useful if you have a technology file which defines, for example, nine metal layers, but you
plan to use fewer layers, for example, only up to metal 7,
op
The example above ignores the layers above M7 for RC and congestion estimation. It also prevents the router
from routing on layers above M7. This is common if you are reserving the upper layers for top-level routing,
yn
or using the top layers for the power-mesh only, for example.
rS
Fo
ed
er
i st
eg
R

Load Scan Chain Identification Information
 Load SCAN-DEF to help ICC II identify the scan chains and

their re-ordering buckets
y
 Will be used during placement to re-order the scan chains
nl
to reduce congestion
O
read_def ORCA_scan.def
se
U
SCAN_OUT
SCAN_OUT
IN[0] OUT[0] IN[0] OUT[0]

B F D B F D
al
rn
IN[1] OUT[1] IN[1] OUT[1]
E C A E C A
SCAN_IN
SCAN_IN
te
Scan chain re-ordering during
In
placement
s 5- 24
sy
ICC II gets the scan chain information from a SCANDEF file, which specifies the scan chain components
and their pins used for the scan path, along with reordering constraints. To get the best quality of results
op
(QoR) for scan designs and enable repartitioning and reordering of the scan chains, you must annotate the
scan chain information by loading the SCANDEF file.
yn
rS
Fo
ed
er
i st
eg
R

Connect PG Pins to Supply Nets
 Synthesis netlist has no P/G supply Netlist representation

nets or connections (no P/G connections)
y
1’b1
 Must explicitly connect P/G pins to
nl
supply nets 1’b0
O
 These are logical connections, not physical
metal routes
se
Pins connected
 P/G net names defined in UPF to P/G supplies
VDD
– Use –net option with <port_pin_list> for non-
U
UPF designs
al
 This also connects tie-high/low pins to P/G nets
VSS
rn
connect_pg_net
te
check_mv_design
In
s 5- 25
sy
Any cells that are subsequently added by optimization or CTS (e.g. during place_opt, clock_opt, or
route_opt), will be automatically connected to PG nets. After “manually” adding cells (e.g. after filler cell
insertion or ECOs), you need to explicitly rerun connect_pg_net.
op
yn
rS
Fo
ed
er
i st
eg
R

Enable Use of Tie-High/Low Cells

Tie-high/low pins VDD
connected to
 If tie high/low inputs need to be P/G supplies
connected to tie-high/low cells,
y
enable this as shown here
nl
VSS
Tie-high/low cells will be
O
 Post-placement:
inserted during placement
VDD
Tie-high/low pins
connected to tie-
se
optimization high/low cells Tie-hi
U
VSS
Tie-lo
set_dont_touch [get_lib_cells */TIE*] false
al
set_lib_cell_purpose -include optimization [get_lib_cells */TIE*]
rn
 The name of the reference library is determined by the library file name with the .ndm
te
suffix removed
– E.g. std_cell.ndm is named std_cell: get_lib_cells std_cell/AND3*
In
s 5- 26
sy
If a library file is renamed from “std_cell.ndm” to “std_cell_two.ndm”, for example, the library name
inside ICC II will also change to “std_cell_two”.
This only works for the specific extensions .ndm, .nlib and .ndb.
op
The library name of a library with any other extension will be the same as its file name, for example: The
yn
library with a file name of hello.mylib will have a library name of “hello.mylib”!
rS
Fo
ed
er
i st
eg
R

TIP: Design Library Packages
Design setup Design setup

 You can pack a library at any stage
y
Design Design of the design flow by using
nl
planning planning
write_lib_package
O
place_opt place_opt  Design data and reference libraries are
write_lib_package read_lib_package stored into a single file, including all
se
Design application options and Tcl variables
package
clock_opt clock_opt
U
When the design is unpacked by
al
Routing Routing 
read_lib_package, the design is
… …
rn
in the same state as when it was
packaged
te
User 1 @ team 1 User 2 @ team 2
In
s 5- 27
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Usage Details – pack / unpack
 Pack a design library including reference libraries into a single file

icc2_shell> open_lib TOP.dlib
y
icc2_shell> open_block abc Binary archive. Includes all
nl
… blocks in the library, by default
icc2_shell> write_lib_package TOP.packed
O
se
 Unpack a design library
U
read_lib_package TOP.packed
Information: Loading library file '/…/…/TOP.dlib' (FILE-007)
al
Information: Loading library file '/…/…/lib1.ndm' (FILE-007)
…
rn
Opening block 'TOP.dlib:abc.design' in edit mode
te
icc2_shell> ls TOP.dlib/
In
lib.ndm reflibs/ abc/ s 5- 28
sy
When packing:
• All reference libraries are packed unless you specify -exclude_reflibs
op
• You must open a design library before packing it

• The current design library is packed by default. Use -library to pack a different library
• All blocks are packed by default. Use -blocks to pack a specific list of blocks
yn
• Use -verbose for more details about the packing

• Collections are not packed, you can rebuild them from the unpacked design
rS
• All variables and application options are saved as well

Fo
When unpacking:
• opens the library and sets the current block
• All the reference libraries are located in the reflibs directory under the library
ed
• Use -destination to specify the destination directory in which to unpack the design
• Use -overwrite to overwrite an existing library at the destination location
er
i st
eg
R

Test for Understanding (1 of 2)
1. A design library (circle all that apply):

a) Contains the physical designs saved after various design phases (for
example after design setup, floorplanning, placement, clock tree synthesis
y
nl
and routing)
b) Is always tied to a specific technology
O
c) Must contain pointers to all reference libraries which contain one or more
se
cells used by the block(s) in the design library
U
2. DEF is the recommended, and the only format needed to load all
al
floorplan information into ICC II. True or false?
rn
When using the Golden-UPF flow, what additional file is required
te
3.
apart from the (PG) netlist, the golden and the supplemental UPF?
In
s 5- 29
sy
op
yn
rS
Fo
ed
er
1. A, B and C are correct.

st
2. False. DEF does not support group bounds, certain partial blockages, or voltage areas. These
constructs must be applied separately through Tcl commands.
i
eg
3. A name mapping file is required, because DC or ICC II might change the names of objects that
are described in the golden UPF file.
R

4. ICC II can be controlled to connect tie-high/low inputs directly
y
to P/G nets, or to tie-high/low cells.
nl
True or false?
O
Cell placement site and symmetry, as well as preferred
se
5.
routing directions and routing track offset are defined either
U
in the technology file or by the user
(with set_attribute). True or false?
al
rn
te
In
s 5- 30
sy
op
yn
rS
Fo
ed
er
st
4. True
5. False. These site and routing attributes are not defined in the tech file - they must be defined by the user
i
eg
using set_attribute. This can be done either in Library Manager, during the creation of a
“technology-only library” (the recommended approach), or alternatively in ICC II, during design setup.
R

Summary: Design Setup

Reference Libraries Standard IP
(Logic, timing, physical) cells cells
y
Technology Library
nl
(Technology and TLUPlus) Techno- IC Compiler II
logy
Design Library
O
Technology File ORCA.dlib
(.tf file)
se
RC Model Files
(TLU+)
U
Gate-Level Netlist
(Verilog) ORCA
al
MCMM Timing
Constraints Floorplan
rn
(SDC+Tcl) (DEF + Tcl)
Block
te
Power Intent Scan Chain
(UPF) (SCAN-DEF)
In
s 5- 31
sy
The solid arrow indicates that the data from these files are saved in the design block, design library or
reference library. This means that once this data is loaded, and the design database is saved, the files are no
op
longer needed or used, when the design and/or library is closed and subsequently re-opened.
The dotted-line arrow indicates that only “pointers” to this data are saved in the design library. This means
yn
that after this data is loaded, even after the design database is saved, the reference libraries must remain
available to be re-loaded, when the design, the design library and/or the ICC II session is closed and
rS
subsequently re-opened.
Fo
The technology file and TLUPlus files can be loaded into a technology-only reference library
(recommended), and/or in the design library (if preferred by the user).
ed
er
i st
eg
R

y
 Create a design library
nl
 Load the netlist and power intent (UPF)
O
 Apply the floorplan
se
 Load the scan chain definitions (scan-DEF)
U
 Connect PG and enable tie cells
al
rn
Begin “Lab 5: Design Setup”
te
In
s 5- 32
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix
y
nl
A - The .synopsys_icc2.setup file
O
B - UPF Example
se
U
al
rn
te
In
s 5- 33
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix A
y
nl
The .synopsys_icc2.setup file
O
se
U
al
rn
te
In
s 5- 34
sy
op
yn
rS
Fo
ed
er
i st
eg
R

ICC II Initialization Files
User’s General 1
Setup 2
~user $SYNOPSYS/admin/setup
y
Default
nl
.synopsys_icc2.setup .synopsys_icc2.setup Setup
O
se
User’s 2nd General
Setup 3
U
ICC2 startup directory (CWD)
al
.synopsys_icc2.setup
rn
te
Commands in .synopsys_icc2.setup are executed upon
tool startup, in the order shown above.
In
s 5- 35
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Example User’s .synopsys_icc2.setup File
y
.synopsys_icc2.setup
nl
# Example settings – only apply non-project
O
# specific commands and settings here!
history keep 200
se
alias h history
alias rc "report_constraints -all_violators"
U
al
rn
te
In
s 5- 36
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix B
y
nl
O
UPF Example
se
U
al
rn
te
In
s 5- 37
sy
op
yn
rS
Fo
ed
er
i st
eg
R

High Level Multi-Voltage Design Concepts

VDDL VDDH PD_Top
Multi-Voltage Elements
0.9V Power supply nets:
VDDL, VDDH, VSS
y
PD2
my_sw Power switch my_sw
nl
1.1V/OFF NSleep
controlled by sleep
O
AO = Always On buffer
VDDHS supplied by permanent
power VDDH in order to
se
AO VDDH keep sleep signal active
LS ELS
VDDHS VDDH LS = Level shifter
U
shift signal level LH
RR ELS = Enable Level Shifter
al
or ISO if voltage the same
controlled by isolate_ctrl
rn
sleep restore retn isolate_ctrl
VSS PowerController RR = Retention Register
controlled by retn/restore
te
UPF defines the various power domains, retention, isolation
In
and switching strategies for multi-voltage designs s 5- 38
sy
This picture shows a simple design with the elements common in MV designs.
op
yn
rS
Fo
ed
er
i st
eg
R

UPF Example: Supplies and Power Domains
create_supply_net VSS
create_supply_net VDD
y
create_supply_net VDDH
nl
create_supply_set ss_high \
O
-function {power VDDH} -function {ground VSS}
create_supply_set ss_low \
se
-function {power VDD} -function {ground VSS}
U
create_power_domain PD_ORCA_TOP -supply {primary ss_low}
al
create_power_domain PD_RISC_CORE -supply {primary ss_high}
rn
-elements I_RISC_CORE
te
In
s 5- 39
sy
op
yn
rS
Fo
ed
er
i st
eg
R

UPF Example: Power Ports and Nets
y
nl
create_supply_port VDD -domain PD_ORCA_TOP -direction in
create_supply_port VSS -domain PD_ORCA_TOP -direction in
O
create_supply_port VDDH -domain PD_ORCA_TOP -direction in
se
connect_supply_net VSS -ports VSS
connect_supply_net VDD -ports VDD
U
connect_supply_net VDDH -ports VDDH
al
rn
te
In
s 5- 40
sy
op
yn
rS
Fo
ed
er
i st
eg
R

UPF Example: Level Shifters
set_level_shifter risc_ls_in \
y
-domain PD_RISC_CORE \
nl
-applies_to inputs \
-rule low_to_high \
O
-location self
se
set_level_shifter risc_ls_out \
-domain PD_RISC_CORE \
U
-applies_to outputs \
-rule high_to_low \
-location parent
al
rn
te
In
s 5- 41
sy
op
yn
rS
Fo
ed
er
i st
eg
R

UPF Example: Power States and PS Table
set_design_attributes -elements {.} -attribute correlated_supply_group {*}
y
nl
add_power_state -supply ss_high -state ON { -supply_expr {
power == {FULL_ON 0.95 0.95 1.16} && ground == {FULL_ON 0.0} } }
O
add_power_state -supply ss_low -state ON { -supply_expr {
se
power == {FULL_ON 0.75 0.75 0.95} && ground == {FULL_ON 0.0} } }
create_power_state_group PST
U
add_power_state -group PST \
-state RUN {-logic_expr { ss_low==ON && ss_high==ON }}
al
rn
te
In
s 5- 42
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
O
5 Design Setup
se
U
6 Timing Setup
al
7
rn
Running CTS
te
In
s 6- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Timing Setup © 2019 Synopsys, Inc. All Rights Reserved. 6-1

Timing Setup Objectives
y
nl
O
 Perform MCMM setup: Define the corners, modes and
se
scenarios required for analysis and optimization; Load
the MCMM constraints
U
 Apply timing and optimization controls
al
 Confirm implementation phase readiness with
rn
a zero-interconnect timing sanity check
te
In
s 6- 2
sy
MCMM = Multi-Corner Multi-Mode
op
yn
rS
Fo
ed
er
i st
eg
R


Synthesis
y
Design & Timing Setup This Unit
nl
O
se
U
CTS & Optimization
al
rn
te
Signoff
In
s 6- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Multiple Modes and Corners

Today’s chips must operate in multiple modes…
Standby Mode
y
Test Mode
nl
Normal Functional Mode
Low Power Mode
O
High Performance Mode
se
…and across multiple PVT corners
U
Hi T Slow
Hi-T Lo-T Fast
al
Max
rn
Lo-T Slow Leakage Hi-T Fast
te
In
s 6- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Concurrent MCMM Optimization

 ICC II allows concurrent optimization under multiple
corner and mode combinations, called scenarios
y
= @
FUNC_SLOW FUNC SLOW
Scenario Mode Corner
nl
O
 Improves each violation in a scenario, while trying
not to cause/increase a violation in another scenario
se
U
Fixing setup
al
Scenario 3 … will not cause a
here … hold violation here
Scenario 1 Scenario 5
rn
Scenario 2 Scenario n
Scenario 4
te
In
s 6- 5
sy
Concurrent MCMM optimization works on all violations across all scenarios and as such eliminates the
convergence problems observed in sequential approaches. Optimization is performed for setup, hold, max
op
transition, max/min capacitance and power. MCMM optimization utilizes a concurrent costing engine, which
ensures that every transformation is acceptable for all scenarios’ costs.
yn
rS
Fo
ed
er
i st
eg
R

Creating Modes, Corners and Scenarios
 Define modes and corners first, then define scenarios, comprised of

applicable mode+corner combinations
y
 The last mode/corner/scenario created is, by default, the current one
nl
create_mode func
O
create_mode test func test
create_corner ss125c ; ## Common corner to both modes
se
ss125c
create_scenario –mode func –corner ss125c
create_scenario –mode test –corner ss125c
U
current_mode
al
test func::ss125 test::ss125
rn
current_corner
ss125c
te
current_scenario
test::ss125c
In
s 6- 6
sy
Additional corner, mode and scenario commands:
all_corners # Create a collection of all corners in a design

op
get_corners # Create a collection of listed corners

remove_corners # Remove listed corners
yn
report_corners # Report details of listed corners

rS
all_modes # Create a collection of all modes in a design

get_modes # Create a collection of listed modes
remove_modes # Remove listed modes
Fo
report_cell_modes # Report the modes of cell instances

report_modes # Report details of listed modes
reset_cell_mode # Reset the cell mode on listed cell instances
ed
set_cell_mode # Selects the mode of an instance
all_scenarios # Create a collection of all scenarios in the design

er
get_scenarios # Create a collection of listed scenarios

st
remove_scenarios # Remove listed scenarios

report_scenarios # Report details of listed scenarios
i
set_scenario_status # Setup scenario for setup, hold, etc. analysis

eg
R

Current Corner + Current Mode ↔ Current Scenario
fc_shell> current_corner
 The current corner and mode {ss_m40c}
determines the current fc_shell> current_mode
y
{func}
scenario, and vice versa:
nl
fc_shell> current_scenario
{func.ss_m40c}
O
 Switching current corner or fc_shell> current_corner ff_125c
se
mode changes current scenario {ff_125c}
fc_shell> current_scenario
{func.ff_125c}
U
 Switching current scenario fc_shell> current_scenario test.ff_m40c
al
changes current corner and/or {test.ff_m40c}
mode fc_shell> current_mode
rn
{test}
fc_shell> current_corner
te
{ff_m40c}
In
s 6- 7
sy
Once corners and modes are defined, there is always a current corner and mode; However, you can create a
situation where there is no current scenario, even if the scenarios are defined:
If scenario S1 = corner C1 and mode M1, and scenario S2 = corner C2 and mode M2, then if
op
current_corner = C1, and current_mode = M2, there is no current scenario. You will get an empty
return value.
yn
rS
Fo
ed
er
i st
eg
R

Classifying Constraints
 Timing constraints are classified into four categories:
 Mode-specific
Corner-specific
y

nl
 Scenario-specific
Example:
Global
O

M1 constraints: Global constraints:

M1
se
create_clock set_ideal_network
Mode set_case_analysis
U
G C1 constraints:
C1 L set_operating_conditions
Corner O
al
set_timing_derate
B
rn
A
S1 L S1 constraints:
set_input_delay
te
Scenario set_driving_cell
set_output_delay
In
s 6- 8
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Commands Listed by Classification

Mode-Specific Corner-Specific Scenario-Specific Global
Constraints that define or Constraints that modify the Constraints that have a time, load, Constraints that apply to all
modify the topology of the calculated delay on an object resistance, or drive value, and can corners, modes and scenarios of
timing graph refer to a modal object (e.g. -clock) a given netlist
y
create_clock set_aocvm_coefficient read_sdc set_disable_clock_gating_check
nl
create_generated_clock set_extraction_options set_annotated_arrival set_dont_touch
group_path set_load set_annotated_delay set_dont_touch_network*
set_case_analysis set_operating_conditions set_annotated_required set_ideal_network
O
set_annotated_transition
set_cell_mode set_parasitic_parameters set_power_clock_scaling
set_awp_thresholds
set_clock_gating_check set_process_label
set_clock_latency
set_clock_groups set_process_number set_clock_transition
se
set_clock_sense set_temperature set_clock_uncertainty
set_data_check set_timing_derate set_drive
set_disable_timing set_voltage set_drive_resistance
set_false_path
U
set_driving_cell
set_latch_loop_breaker set_fanout_load
set_max_delay set_ideal_latency
set_min_delay set_ideal_transition
al
set_multicycle_path set_input_delay
set_input_transition
set_propagated_clock
set_max_capacitance
rn
set_sense
set_max_time_borrow
set_max_transition
set_min_capacitance
te
set_min_pulse_width
set_output_delay
set_path_margin
set_switching_activity
In
s 6- 9
sy
* While set_dont_touch_network is a global constraint command, it may be applied to clock objects
(which are mode-specific – see below), in which case the constraint will be treated as a mode-specific
op
constraint.
The following is a classification of get_ and all_ commands:
yn
Mode-specific Corner-specific Scenario-specific Global

all_clocks all_corners all_scenarios all_connected
rS
all_exceptions get_corners get_clock_tree_pins all_fanin

all_exception_groups get_input_delays all_fanout
all_inputs get_output_delays
Fo
all_modes get_scenarios
all_outputs get_timing_paths
all_registers get_switching_activity
ed
get_clocks set_scenario_status
get_clock_groups
er
get_clock_group_groups
get_clock_skew_groups
st
get_exception_groups
get_exceptions
i
eg
get_generated_clocks
get_latch_loop_groups
get_lib_timing_arcs
R
get_path_groups
get_timing_arcs

Scenario Constraints
 PrimeTime, DC and ICC use only scenarios
y
 There is no concept of a mode or a corner
nl
 Constraints are either scenario-specific or global
O
 Scenario constraints are typically in a single file
 Contains scenario, modal and corner timing constraints
se
 For example: Scenario func_ss_125c: func_ss125c.sdc
ICC II has modes and corners, which are shareable among scenarios
U

 It is recommended to split SDC constraints into mode-, corner- and
al
scenario-specific constraint file
rn
 Improves constraint loading efficiency (explained next), but is not required
te
 ICC II provides a few commands to simplify the transition to separate
scenario/mode/corner files
In
s 6- 10
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Loading Constraints
 For the most efficient scenario setup, you should split constraints into
separate files
y
 These constraints are then loaded only once, even if shared across scenarios
nl
 Faster load time with less memory required
O
 After the modes, corners, and scenarios are defined,
populate them with constraints
se
 This ensures that no constraints are lost (put into default mode/corner/scenario)
U
current_scenario M1_C1 current_scenario M2_C1
read_sdc C1_corner.sdc read_sdc M2_mode.sdc
al
read_sdc M1_mode.sdc read_sdc M2_C1_scenario.sdc
rn
read_sdc M1_C1_scenario.sdc
te
read_sdc global_constraints.sdc
In
s 6- 11
sy
First bullet: If two modes share the same corner constraints, for example, the shared corner constraints need
to only be loaded once, instead of twice - once for each scenario. Furthermore, if you apply the same
constraints twice in the same mode, for example a create_clock constraint, ICC2 will issue a warning.
op
When applying large constraint files multiple times, you could be faced with thousands of warnings, and it
becomes hard to find “real” problems. See example on next page of how to automatically split constraints.
yn
Second bullet: How can constraints be lost? If, for example, the user applies a modal (or mode-specific)
rS
constraint before creating the first mode, that constraint goes to the default mode, and is essentially lost (will
not be used by any subsequently created mode). The tool creates a default corner, mode, and/or scenario, if
Fo
none is created by the user.

This is true as long as you don’t create a mode first. If you create mode m1, but stay with the default_corner,
the current scenario will be undefined (and not default_scenario as you would expect). If you try to apply a
ed
scenario-constraint in this case, you will receive an error message:

Error: Current scenario does not exist. (UIC-076)
er
Attempted to use current scenario

st
Note: In the example above, if, after executing current_corner C1, you load a modal constraint, that
i
eg
constraint is applied to the current mode, which is M2, in this case.

R

Use write_script to Separate Constraints

 If you inherit constraint files with mixed mode, corner and scenario
constraints, use write_script to help separate the constraints:
Load the mixed constraint file for each scenario
y

nl
 Execute write_script, which creates a wscript directory, containing
separate Tcl files for each mode, corner, scenario and a file for global constraints
O
 When your netlist or floorplan changes, load the files during design setup
se
create_mode M1; create_mode M2; ...
create_corner C1; create_corner C2; ...
U
create_scenario –name S1 –mode M1 –corner C1
al
...
current_scenario S1
rn
read_sdc S1.sdc
current_scenario S2
read_sdc S2.sdc
te
...
write_script
In
s 6- 12
sy
Note: The write_script command does not help you figure out what modes/corner/scenarios you have.
You need to first define the appropriate modes, corners and scenarios in order for write_script to be able
op
to separate the constraints.

write_script # Write Tcl scripts for current design
[-modes mode_list] (Modes to write; default is all modes)
yn
[-corners corner_list] (Corners to write; default is all corners)

[-include include_list]
(Types of data to include:
rS
Values: aocvm_coefficient,
aocvm_coefficient_lib_cell, app_options,
block_to_top_map, budget, case_analysis,
cell_mode, clock, …
Fo
[-exclude exclude_list]
(Types of data to exclude:
Values: aocvm_coefficient,
ed
aocvm_coefficient_lib_cell, app_options,
block_to_top_map, budget, case_analysis,
cell_mode, clock,
er
clock_cell_spacing_rule,
clock_gating_check, …
[-format format] (Target format; default is icc2:
st
Values: dc, icc, icc2, pt)

[-output dir_name] (Directory for output files; default is ./wscript)
i
[-force] (Overwrite existing output directory)

eg
[-nosplit] (Don't split lines if column overflows)

[-compress method] (File compression method:
Values: gzip, none)
R

Minimize Modes and Corners with Scenario Analysis
 If you do not know the correct corners and modes:

 Create unique modes and corners for each scenario
y
 Execute remove_duplicate_timing_contexts to find the minimum set of
nl
modes and corners, remove the duplicates and re-assign the scenarios
Execute write_script to capture the mode-, corner-, scenario-constraints
O

create_mode M1; create_corner C1 C1 C2
se
create_mode M2; create_corner C2 S1 S2
U
... M1 M2
current_scenario S1
al
read_sdc S1.sdc If M1 == M2:
current_scenario S2
rn
read_sdc S2.sdc C1 C2
...
te
S1 S2
remove_duplicate_timing_contexts
M1
In
write_script M2
s 6- 13
sy
Assume that, in the example above, the remove_duplicate_timing_contexts command finds that
modes M1 and M2 are the same mode (because they share the exact same constraints): It deletes mode M2, and
re-assigns scenario S2 to point to M1 (instead of M2).
op
The command will also delete scenarios if they are identical. For example, if S1=M1+C1 and S2=M2+C2, and
further if M1=M2, C1=C2 and S1=S2, then S2, M2 and C2 will be removed.
yn
rS
Fo
ed
er
i st
eg
R

Check Timing Constraints
 The following commands are available for checking constraints:

to check clock crossing, missing input/output delays, …
y
 check_timing
nl
 report_exceptions to identify paths with single-cycle timing exceptions: false
paths, multi-cycle paths, asynchronous min- or max-delay paths
O
 report_case_analysis to confirm the correct mode settings
se
 report_disable_timing to identify paths with disabled timing arcs (these will not
be optimized for timing)
U
check_timing
foreach_in_collection mode [all_modes] {
al
current_mode $mode
rn
report_exceptions
report_case_analysis
report_disable_timing
te
}
In
s 6- 14
sy
check_timing can perform the following checks:
clock_crossing, data_check, gated_clock, generated_clock, loops, multiple_clock,
no_clock, no_input_delay, unconstrained_endpoints
op
The report_exceptions command can be used to check if the design contains any false or multicycle
yn
paths, or any asynchronous min- or max-delay constraints.

rS
The report_disable_timing command reports disabled timing arcs in the current design. Paths
containing one or more disabled timing arcs will not be optimized for timing. Timing arcs can be disabled by
the user with set_disable_timing, or disabled automatically by the tool during timing analysis, in order
Fo
to break timing loops, or when propagating constants in the design (for example, input pins connected to tie-
high/low cells).
ed
The report_case_analysis command reports ports or pins that are set to a constant logic value 1 or 0 by
the constraint set_case_analysis. Case analysis is a way to specify a given “mode” of a design without
er
altering the netlist structure.

st
You can write complete scenario-based SDC files using write_sdc.

i
eg
R

Reports Usually Apply to Current Scenario

icc2_shell> all_scenarios
{func.ff_125c func.ff_m40c ... test.ss_125c}
icc2_shell> current_scenario
{func.ss_125c}
y
icc2_shell> report_case_analysis
Port/Pin Name User case analysis value
 Most report_ commands
nl
---------------------------------------
scan_enable
test_mode
0
0
apply to the current scenario
O
 Some commands have
icc2_shell> report_constraints -all_violators
late_timing –scenario,
----------- -corner, and/or –mode
se
Endpoint Path Delay Path Required Slack Scenario
-----------------------------------------------------------------------------------------
.../shift_reg[3][30]/D (SDFFARX2_LVT) 9.37 r 7.01 -2.35 func.ss_125c
options to modify what is
reported
U
icc2_shell> current_scenario test.ff_125c
{test.ff_125c}
icc2_shell> report_case_analysis
al
Port/Pin Name User case analysis value
---------------------------------------
occ_bypass 0
rn
occ_reset 0
test_mode 1
te
icc2_shell> report_constraints -all_violators
early_timing
-----------
In
Endpoint Path Delay Path Required Slack Scenario
---------------------------------------------------------------------------------------
.../FIFO_RAM_1/A1[0] (SRAMLP2RW32x4) 0.10 f 0.16 -0.06
s test.ff_125c
6- 15
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Controlling MCMM Timing Reports

 Report the single worst setup timing path among all
path groups of all active setup-enabled scenarios:
report_timing
y
nl
 Report the single worst setup timing path from among the listed and active
corners, modes or scenarios, respectively:
O
report_timing –corners “C1 C4”
report_timing –modes FUNC*
se
report_timing –scenarios “S1 S2 S5 S6”
 Report the worst setup timing path for each and every active corner, mode,
U
scenario or path group respectively:
al
report_timing –report_by corner|mode|scenario|group
rn
 Report the worst setup timing path for each listed and active corner, mode
or scenario, respectively:
te
report_timing –report_by corner –corners “C1 C4”
report_timing –report_by mode –modes FUNC*
In
report_timing –report_by scenario –scenarios “S1 S2 S5 S6”
s 6- 16
sy
-report_by group will give you a report for every group in every scenario (if paths exist!).
op
yn
rS
Fo
ed
er
i st
eg
R

Controlling Scenario Analysis / Optimization
 The create_scenario command creates a scenario, makes it active,

and enables the following analysis types:
y
 Setup and hold timing
nl
 Leakage and dynamic power
O
 Max transition, max and min capacitance
se
 Placement, CTS and routing optimizations occur simultaneously on all
U
active scenarios, for their enabled analyses
al
rn
 Use set_scenario_status to limit the analysis types or to make
te
scenarios inactive before compile
See examples on next page
In

s 6- 17
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Examples: Modifying Scenario Status
Without the -name switch,

scenarios are automatically
y
create_scenario –mode mFUNC –corner cSLOW named mode::corner, e.g.
create_scenario –mode mTEST –corner cSLOW
nl
mFUNC::cSLOW
create_scenario –mode mFUNC –corner cFAST
create_scenario –mode mTEST –corner cFAST
O
# Disable setup timing analysis and optimization for the FAST corner scenarios;
se
# Disable leakage power analysis and optimization for the TEST mode scenarios:
set_scenario_status *cFAST -setup false
set_scenario_status mTEST* -leakage_power false
U
# For placement consider only SLOW corner scenarios:
al
set_scenario_status *cFAST -active false
place_opt
rn
# For post-route analysis activate all scenarios and enable all analyses:
te
set_scenario_status * -active true -all
In
s 6- 18
sy
The following warning is issued if an active scenario has no analysis types enabled:
icc2_shell> set_scenario_status mFUNC::cSLOW -none
Scenario mFUNC::cSLOW (mode mFUNC corner cSLOW) is active, but has no analysis
op
configured.
yn
The following warning is issued if an analysis type is enabled on an inactive scenario:

icc2_shell> set_scenario_status mTEST::cFAST –hold true
rS
Warning: Scenario mTEST::cFAST is inactive, so the specified analysis will not

actually be performed. (CSTR-027)
Fo
ed
er
i st
eg
R

Reporting Scenario Status Settings

icc2_shell> report_scenarios
...
Leakage Dynamic
Name Mode Corner Active Setup Hold Power Power Max_tran Max_cap Min_cap
y
--------------------------------------------------------------------------------------------
nl
func.ff_125c * func ff_125c false false true true false true true true
func.ff_m40c * func ff_m40c true false true true false true true true
func.ss_125c * func ss_125c true true true true true true true false
O
func.ss_m40c * func ss_m40c false true false true true true true false
test.ff_125c * test ff_125c false false true false false true true true
se
test.ss_125c * test ss_125c true true false false true true true false
--------------------------------------------------------------------------------------------
# Which scenarios will be optimized for setup timing?
U
icc2_shell> get_scenarios -filter active&&setup
{func.ss_125c test.ss_125c}
al
# Which scenarios will be optimized for hold timing?
rn
icc2_shell> get_scenarios -filter active&&hold
{func.ff_m40c func.ss_125c}
te
# Which scenarios will be optimized for all DRCs?
icc2_shell> get_scenarios -filter active&&max_tran&&max_cap&&min_cap
In
{func.ff_m40c}
s 6- 19
sy
The “*” after the scenario names in the table above indicates that the scenario names were user-specified
(rather than the default names “mode::corner”).
op
In addition to using the report_scenarios command to generate a table containing the scenario status
settings, you can obtain similar information by querying a scenario’s attributes: mode, corner, active,
yn
setup, hold, leakage_power, dynamic_power, max_tran, max_cap, min_cap. This method is more
useful than report_scenarios for scripting purposes. Examples:
rS
icc2_shell> get_scenarios
Fo
{func.ff_125c func.ff_m40c func.ss_125c func.ss_m40c test.ff_125c test.ss_125c}

icc2_shell> get_attribute [get_scenarios] active
false true true false false true
icc2_shell> get_attribute [get_scenarios] hold
ed
true true true false true false

icc2_shell> get_attribute [get_scenarios] min_cap
er
true true false false true false

icc2_shell> get_attribute [get_scenarios] mode
st
{func} {func} {func} {func} {test} {test}

icc2_shell> get_attribute [get_scenarios] corner
i
eg
{ff_125c} {ff_m40c} {ss_125c} {ss_m40c} {ff_125c} {ss_125c}

R

Defining Corner PVT by Operating Condition
 ICC II accepts set_operating_conditions to determine the

PVT values for each corner
y
nl
set_operating_conditions ss0p95v125c
This is an indirect method, relying on an operating condition
O

model name to determine the PVT numbers
se
Operating Conditions:
U
Name Process Temp Voltage Original DB Name Original DB Filename
----------------------------------------------------------------------------------------------
ff0p95vn40c 1.01 -40.00 0.95 saed32lvt_ff0p95vn40c saed32lvt_ff0p95vn40c.db
al
ff0p95v125c 1.01 125.00 0.95 saed32lvt_ff0p95v125c saed32lvt_ff0p95v125c.db
rn
ss0p75vn40c 0.99 -40.00 0.75 saed32lvt_ss0p75vn40c saed32lvt_ss0p75vn40c.db
ss0p75v125c 0.99 125.00 0.75 saed32lvt_ss0p75v125c saed32lvt_ss0p75v125c.db
te
...
- 0.99 125.00 0.95 IP1_ss0p95v125c IP1_ss0p95v125c.db
- 0.99 125.00 0.95 IP2_ss0p95v125c IP2_ss0p95v125c.db
In
s 6- 20
sy
In the example above, specifying the operating condition name of ss0p95v125c determines the nominal
PVT values of 0.99, 125C, and 0.95V, respectively.
op
The tables above (for the different LVt, IP1 and IP2 libraries) and on the following pages were generated
using report_lib.
yn
rS
Fo
ed
er
i st
eg
R

Defining PVT Directly - Recommended
 It is recommended to use the direct method for clarity:
y
set_process_number 0.99
nl
set_voltage 0.75 –object_list VDD
O
set_voltage 0.95 –object_list VDDH
set_temperature 125
se
Operating Conditions:
U
----------------------------------------------------------------------------------------------
al
rn
te
In
s 6- 21
sy
A note about the process (P) value: A couple of decades ago, users were supplied with only one library,
characterized in the “typical” PVT corner. The library would then contain multiple operating conditions, each
op
with a different set of PVT values, to represent the different corners. Timing analysis would then multiply the
typical cell delays by the P value, and by V and T scaling factors (based on process k-factors), to derive the
“max” and “min” corner delays. To represent a slower-than-typical process corner, a P value of > 1.0 was
yn
used, and vice-versa for a faster-than-typical process corner: For example, a P value of 1.2 would mean that
all cell delays would be slowed down by 20% from their typical delay, due to a slower process corner;
rS
Similarly, a P value of 0.8 would mean a speed-up of 20% from typical delays, due to a faster process corner.
Fo
Today the P value (or the V and T, for that matter) is not used for any scaling purposes, since the “nominal”
cell delays in each library is already characterized for a specific PVT corner. The PVT values are only used to
identify the nominal PVT corner of a library. Many library vendors have, therefore, switched to using a value
ed
of 1 for P across all process corners. This practice cause a problem with the direct PVT specification method:
There is no way to distinguish two different libraries, characterized for the same V and T, but for slow and
er
fast process corners, for example, because P = 1 for both libraries. One way around this is to use different P
values for the different process corners (e.g. 0.99 and 1.01 in the example above). The specific values do not
st
matter, as long as they are different. If different P values are not possible, a “process label” can be applied to
differentiate the libraries – discussed later.
i
eg
R

Reporting Library Details: report_lib

Full name: /global/files/ndm/saed32.ndm:saed32
File name: /global/files/ndm/saed32.ndm
Design count: 588
Timing data:
Power rails:
y
Index Name Type
nl
0 <default> power
1 VDD power
2 VDDG power
O
3 VSS ground
Pane count: 2
Pane 0:
se
Process label: (none)
Process number: 0.99
Voltage rail count: 3
U
Voltage for rail 0 (<default>): 0.75
Voltage for rail 1 (VDD): 0.75
al
Voltage for rail 2 (VDDG): 0.75
Temperature: -40
Thresholds:
rn
r/f InputDelay: 0.5/0.5 r/f OutputDelay: 0.5/0.5
l/h RiseTrans: 0.2/0.8 h/l FallTrans: 0.8/0.2
te
TransDerate: 1
Source .db file: /global/files/NLDM/saed32hvt_ss0p75vn40c.db ...
In
s 6- 22
sy
op
yn
rS
Fo
ed
er
i st
eg
R

VT Matching
If the PVT does not match, the VT resolution function finds the
closest VT match between specified and available library panes
y
As a result, if there is at least one timing model available for a cell instance,
nl
whatever the nominal PVT, that cell instance will be timed
O
create_corner Ca;
set_voltage 1.1; 0o C 125oC
P1.0 P1.0 P1.0 P1.0 set_temperature 125;
se
set_process_number 1; Ca
V1.1 V1.1 V0.8 V0.8 1.1v
T125 T0 T125 T0 create_corner Cb; Cb
U
set_voltage 1.05;
set_temperature 25;
set_process_number 1; P=1.0
al
0.8v Cd
P1.NDM create_corner Cc;
set_voltage 0.75;
rn
set_temperature 0; Cc P=1.2
set_process_number 1;
te
Note: It is not recommended
create_corner Cd; Four individual panes:
set_voltage 0.8; Closest VT match is selected
to tape out with anything but
In
set_temperature 125;
exact PVT matches! set_process_number 1.2;
s 6- 23
sy
In case of a P mismatch, IC Compiler II will still pick the closest VT and ignore P. If there are multiple panes
with different P-values, and the VTs are identical, then a VT match occurs, but it is not deterministic as to
op
which pane (which P-value) is picked (therefore the P is not guaranteed to be closest).
If the specified V and/or T value is exactly in the middle of the available pane values, the pane with the lower
yn
"pane number" (as listed in report_lib) is used.

rS
How can you disable the VT resolution, so that ICC II generates an Error to alert the user to fix the issue,
instead of finding the closest match?
Fo
Use the following:

set_message_info -stop_on -id PVT-030
ed
This will force a Tcl error when a PVT-030 message is issued (PVT-030
(warning) Corner %s:
%d process number, %d process label, %d voltage, and %d temperature mismatches.)
er
The warning occurs when closest-match behavior is being used.

i st
eg
R

Use Process Labels to Help the Matching
 Use process labels to augment the PVT matching condition,
y
for example when:
nl
 Slow (ss) and fast (ff) process corners have the same P values
O
----------------------------------------------------------------------------------------------
se
U
 Closest-match does not pick the PVT that you want (example shown next)
al
rn
te
In
s 6- 24
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Process Label Specification
 First, process labels are applied when Liberty libraries are loaded into
Library Manager
y
icc2_lm_shell> read_db –process_label fast saed32hvt_ff0p95v125c.db
nl
icc2_lm_shell> read_db –process_label slow saed32hvt_ss0p95v125c.db
O
se
 Next, process labels are specified as part of the design’s corner
constraints
U
icc2_shell> create_corner c_slow
icc2_shell> set_process_number –corner c_slow 1.0
al
icc2_shell> set_process_label –corner c_slow slow
rn
 The process label, when specified, supersedes the process number, and
te
limits VT matching to only the set of panes with the specified label
In
s 6- 25
sy
To find out the process label name of each pane in a given library: report_lib <lib_name>
To find out the names of loaded libraries: get_libs
op
yn
rS
Fo
ed
er
i st
eg
R

Process Label Exercise

Process Process
Pane Number Label Voltage Temperature Liberty File
0 1.0 slow 0.88 V 125 C .._ slow_0p88v_125c.db
1 1.0 fast 0.90 V 125 C .._ fast_0p90v_125c.db
y
nl
4 1.0 fast 1.00 V 125 C .._ fast_1p00v_125c.db
O
create_corner c_slow
set_process_number 1.0
se
set_voltage –object VDDG 0.9
set_temperature 125
create_scenario –name s_func_slow –mode m_func –corner c_slow
U
Scenario s_func_slow will be used for setup optimization:
al
Which pane is selected?
rn
## add a process label
set_process_label –corner c_slow slow
te
" Which pane is selected now? Note: The slow version of the 0.90/125 library
In
should eventually be added to the NDM library to
s ensure accurate data is used for tape-out. 6- 26
sy
Answers: Without the process label, pane #1 is selected as an exact match, which is a fast process pane.
However, since this corner is intended to be used for setup analysis and optimization, we should be using a
slow process pane, so the selected pane is not the correct intended one. By specifying a slow process label as
op
well, now only panes #0, #2 and #3, which match the slow label, are considered.
Pane #0 is ultimately selected, since its voltage value of 0.88V is closest to the corner’s specified voltage of
yn
0.90V (versus the other pane voltages of 0.95V and 1.00V) .

rS
Fo
ed
er
i st
eg
R

Reporting ALL Corners with PVT Mismatches

PVT-030 messages indicate that
fc_shell> report_pvt there are PVT mismatches
...
--------------------------------------------------------------------------------
y
Warning: Corner corner_S8: 0 process number, 0 process label, 4 voltage,
nl
and 12 temperature mismatches. (PVT-030)
Warning: 136110 cells affected for early, 136110 for late. (PVT-031)
O
--------------------------------------------------------------------------------
Warning: Mismatched temperature in corner corner_S8. (PVT-022)
Library has 27 panes
se
Entry 15:
Lib: saed32lvt Look for the stars * to get more
U
Pane: 24 details about the mismatches:
Process Label: specified: typ effective: typ Specified value versus the
Process Number: specified: 0.99 effective: 0.99 chosen effective value
al
Rail 0 (default) Voltage: specified: -- effective: 1.050000
Rail 1 (VDD) Voltage: specified: 1.050000 effective: 1.050000
rn
Rail 2 (VDDG) Voltage: specified: -- effective: 1.050000
Rail 3 (VSS) Voltage: specified: 0.000000 effective: --
te
Primary rail: 1 Secondary rail: -- N-bias rail: -- P-bias rail: --
* Temperature: specified: 95.000000 effective: 125.000000
In
s 6- 27
sy
Note: In the detailed section of pane # 24 shown above, there is a temperature mismatch.
op
Besides the 12 temperature mismatches, we see from the summary section on the top of the report that there
are also 4 voltage mismatches. We do not have room to include a voltage-mismatch pane, but in that entry of
the report it would list the specified (by the user) versus the effective voltages (selected by VT
yn
matching).
rS
By default, PVT mismatches will only generate a warning, so a script will continue to run.
If you prefer that FC abort, you can error out instead:
Fo
set_message_info -stop_on -id PVT-030

This way, script execution will stop by default, and you will see an error:
Severe Error: Corner ss_125c: 0 process number, 0 process label, 0 voltage,
ed
and 26 temperature mismatches. (PVT-030)

…
er
st
See appendix if interested in scaling groups.

i
eg
R

Selective Library Loading 2017.09
 In past ICC II releases, all timing panes were loaded into memory
y
 Libraries with high pane counts, even if unused, can use up considerable memory
nl
and lead to slight runtime degradation
O
 With 2017.09, ICC II can now load just the required panes
se
U
 This allows your team to use “one-size-fits-all” cell libraries that
al
support multiple projects, rather than project-specific libraries
rn
 Requires that the cell libraries are built using ICC II Library Manager >= 2017.09
te
In
s 6- 28
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Using Selective Library Loading
 To use selective loading, use set_pvt_configuration to specify the

PVTs you will use across your defined corners
y
 For a given library, the tool loads only the matching panes
nl
 The unused panes remain on disk
O
 If you have a 132-pane library but your configuration matches only 8 panes, your
in-memory library has just those 8 panes
se
# Configure PVTs before you open or create your design library
U
set_pvt_configuration -voltages {0.75 0.95} -temperatures {-40 125} \
-process_numbers 1.0 –process_labels {slow fast}
al
create_lib -ref_libs {all_panes.ndm …} ...
rn
read_verilog ...
# Flow continues as usual. Library in ICC II appears to only contain the timing
te
# panes that match above PVT configuration
In
s 6- 29
sy
If after opening the library you need to load additional panes, you need to 1. close the library, 2. change the
set_pvt_configuration call to add the required panes, 3. re-open the library.
op
The configuration is a sequence of rules, each of which specifies process labels, process numbers, voltages, and
temperatures to match. Generally, if you want all data matching a specific set of PVTs, a single rule is sufficient,
yn
as shown in the example above. When you have a specific subset of many PVTs that you want to match,
multiple rules are needed. See the example below. New rules are created with -add.
rS
Here is an example where multiple rules come into play. Let's say you have these panes in a reference library and
you want to use configuration to load panes 1 and 4:
Fo
Pane 0: process = "SS" (1), voltages: 0.6; temperatures: 0

ed
Pane 3: process = "TT" (1), voltages: 0.6; temperatures: 0

Pane 4: process = "FF" (1), voltages: 0.6; temperatures: 0
er

You can use these commands and get the configuration shown:
st
set_pvt_configuration -voltages 1.2 -temperatures 0

set_pvt_configuration -add -name FF -process_label FF -voltages 0.6
i
eg
If you open this library, you will get the two panes you want:
icc2_shell> open_lib p7.ndm
Information: Loading library file 'p7.ndm' (FILE-007)
R
Panes activated based on PVT configuration (7 possible panes):


Specify TLUplus Parasitic RC Models
 Specify the appropriate TLUplus model for each corner

 TLUplus models must have been previously loaded into
y
a technology-only library, or into the design library (shown below)
nl
O
# If the TLUplus models have not been loaded into a technology library,
# they can be loaded into the design library:
se
# read_parasitic_tech -tlup $TLUPLUS_MAX_FILE -name maxTLU
# read_parasitic_tech -tlup $TLUPLUS_MIN_FILE -name minTLU
U
# Specify the TLUplus model for each corner;
al
# If the TLUplus models were loaded into the tech lib use the –library option:
set_parasitic_parameters -corner c_slow \
rn
-library ${techlib} -early_spec maxTLU -late_spec maxTLU
set_parasitic_parameters -corner c_fast \
te
-library ${techlib} -early_spec minTLU -late_spec minTLU
In
s 6- 30
If the TLUplus model was read into the design library, instead of into a technology library, then the –
sy
library ${techlib} option is not used.

op
${techlib} refers to the name of the library (as seen inside of IC Compiler II), not the file name.
yn
To report the available parasitic models:

report_lib -parasitic_tech saed32_1p9m_tech
rS
…
Parasitic tech data:
----------------------------------------
Parasitic tech name: maxTLU
Fo
Parasitic itf technology name: saed32nm_1p9m_Cmax

Parasitic tech type: TLUPLUS
Parasitic source file name: ./tluplus/saed32nm_1p9m_Cmax.tluplus.as
Parasitic canonical file name: /global/…./tluplus/saed32nm_1p9m_Cmax.tluplus
ed
…
er
If the TLU+ file supports temperature scaling (it will contain the parameters GLOBAL_TEMPERATURE, CRT1, and
CRT2), then ICC II will scale the resistance values using the temperature defined for the specific corner
st
(which was set using set_temperature), or you can specify the temperature for scaling explicitly using:
set_parasitic_parameters -early_spec maxTLU -early_temperature 120 \
i
-late_spec maxTLU -late_temperature 125

eg
R

Restricting Cells in Specific Modules/Regions
Specific modules or design regions may need to be restricted to use a
y

sub-set of all available reference library cells, for example:
nl
 Only cells with a double site height
O
 Only high or low speed cells
se
 No ultra-LVth cells allowed
U
 Use set_target_library_subset for these purposes
al
 See following example
rn
te
In
s 6- 31
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Target Library Subset Example
 Sub-design Sub1/suba is timing-critical and can use LVT cells in addition

to SVT/HVT cells, while the rest of the design uses only SVT/HVT cells
y
nl
Top
O
Sub1/suba
HVT/ LVT/SVT/HVT
SVT
se
Sub1 Sub2
HVT
All VT
SVT
U
suba subb subx suby
al
rn
set_target_library_subset –top {lib_HVT lib_SVT}
set_target_library_subset –objects Sub1/suba {lib_HVT lib_SVT lib_LVT}
te
Pre-existing LVT cells at top are not affected, unless they are optimized
In
s 6- 32
sy
op
yn
rS
Fo
ed
er
i st
eg
R

OCV Effects on Timing

 PVT variation across the die, or “on-chip variation” (OCV), causes timing variations
 OCV can cause real timing violations to be missed, if not considered during
analysis and optimization – consider the following extreme example:
y
nl
U3 U4
The PVT corner FF1 FF2
O
U1 U2
in this part of
the chip is the
 Process variations are
random in nature
se
“slowest”:
1.1/0.90V/125OC
 Can vary from transistor to transistor
U
The PVT corner
in this part of
al
the chip is  Voltage and temperature
“less slow”: variations are systemic
rn
0.9/0.96V/107OC
 Increase with distance between
te
related cells
U5 U6
In
s 6- 33
sy
Not every part of the die has the exact same PVT parameters. There can be random process variations (P)
from transistor to transistor, which introduce delay differences. The temperature (T) can vary across the die
op
depending on varying power densities across the placed cells, or proximity to a heat sink. The voltage (V)
can also vary depending on IR-drops along the power grid. Voltage and temperature variations are systemic –
the potential variation increases with distance. The term “on-chip variation” (OCV) is used to describe these
yn
random and systemic variations.

rS
Why is this important?

Fo
In the example above, if you are analyzing setup timing between FF1 and FF2 in the “slowest” corner, and
you assume that all the cells, including the U5 and U6 buffers, are in the same “slowest” PVT corner
(1.2/0.90V/125OC), you could miss an actual setup timing violation. Since the U5 and U6 buffers are
ed
physically placed in a “less slow” or faster area of the die, (1.1/0.96V/107OC), you actually have slightly
less setup time between FF1 and FF2, compared to the time your analysis assumes. If setup timing is just
er
being met using the optimistic assumption that all the cells are in the same slowest corner, you will miss a
real violation!
i st
eg
R

Traditional Timing Derate Method for Modeling OCV

Commonly only one library is available per SLOW or FAST corner
 Apply estimated derating to model the combined effects of PVT variations
y
 LATE derate: Slows down launch paths for setup, and capture paths for hold
nl
set_timing_derate –late 1.04
O
 EARLY derate: Speeds up capture paths for setup, and launch paths for hold
se
set_timing_derate –early 0.92
U
 Can focus on data or clock logic, net or cell delays, etc.
al
Launch path
rn
Capture path
Data cells
te
FF1
FF2 Clock tree cells
Clk
In
s 6- 34
sy
For setup checks, the launch path delays are multiplied by the –late derate factor (> 1), while the capture path
delays are multiplied by the –early derate factor (< 1). For hold checks it is reversed:
(launch path delays ) x (-early factor); (capture path delays ) x (-late factor).
op
If no object list is specified, cell and net delays (but not cell checks) of the current design are derated, by default.
yn
The –cell_delay, -net_delay and –cell_check options apply derating on the specified timing arcs
only; –cell_check derates register setup/hold and recovery/removal timing arcs (considered part of the “launch
rS
path” for early vs late derating). A hold or removal arc is derated by (2 – early_factor) to model a commensurate
increase in hold/removal time, for example: An -early value of 0.88 models a 12% speed-up. Since
hold/removal timing arcs are considered part of the launch path, following the rules in the first paragraph above,
Fo
these arcs should be multiplied by the early factor of 0.88, but this would make the hold checks optimistic.
Instead, these hold check are multiplied by 2-0.88=1.12, which models a proportionate slow-down of 12 %,
for more conservative timing analysis.
ed
Timing constraints (input delay, output delay, ideal clock network latency) are not derated.
er
The –data option indicates that the derate value is to apply to data cells only. The –clock option indicates that
st
the derate value is to apply to clock tree cells only. Data vs. clock cells are illustrated in the picture above. If
neither option is specified, the derate value is applied to both cells.
i
eg
Use report_timing_derate to verify the settings.

R
Use reset_timing_derate to return to default, non-derated timing.

Example: OCV Analysis with Timing Derate
# In the SLOW PVT corner: Models an 8% speed-up and a 4%

set_timing_derate –early 0.92 slow-down from the SLOW PVT
set_timing_derate –late 1.04 corner
y
nl
_RESET U6 U7 4% SLOWER
Slow
O
FF2
Launch Path corner SLOW
se
Delay 8% FASTER
FF1
CLK1 U1 U2
Fast 7% SLOWER
U
Capture Path corner FAST
4% SLOWER
U4 U5 Operating
al
CLK2 U3 Conditions
~ P / -V / T
rn
Setup Hold
Launch uses LATE derate: Launch uses EARLY derate:
te
1.04 x SLOW corner delays 0.92 x SLOW corner delays
Capture uses EARLY derate: Capture uses LATE derate:
In
0.92 x SLOW corner delays s 1.04 x SLOW corner delays 6- 35
sy
Most library providers supply you with one library per PVT corner, for example the SLOW corner library and
the FAST corner library; They do not provide multiple libraries per corner to model OCV differences. It is
therefore up to the user to model the effects of on-chip variation using the set_timing_derate command.
op
This allows launch and capture path delays to be appropriately derated for setup or hold timing analysis and
optimization.
yn
OCV analysis with late/early derating is pessimistic, but it is “safe” (you won’t miss any real violations). It is
rS
pessimistic because it assumes that ALL the launch cells are in one corner (the late-derated corner, for setup
timing), while ALL the capture cells are in a different corner (the early-derated corner, for setup timing). In
Fo
reality, you will rarely have such a “worst-case” situation. AOCV, or Advanced OCV, and POCV or
Parametric OCV are other available ICC II techniques to reduce this pessimism and achieve more realistic
timing analysis and optimization.
ed
er
i st
eg
R

Derate Factor in Timing Report

set_timing_derate –late 1.04
report_timing –path full_clock –derate
y
Point Derate Incr Path
nl
---------------------------------------------------------------------------
clock SYS_CLK (rise edge) 0.00 0.00
source latency 0.00 0.00
O
I_CLOCKING/sys_clk_in_reg/Q ... 1.04 0.00 0.00 r
I_CLOCKING/I_CLK_SOURCE_SYS_CLK/A (NBUFFX16_LVT) 1.04 0.00 0.00 r
... ... ... ... Launch path
se
I_BLENDER_0/R_573/CLK (SDFFX2_LVT) 1.04 0.00 0.00 r
I_BLENDER_0/R_573/Q (SDFFX2_LVT) 1.04 0.34 0.34 r
I_BLENDER_0/U4925/A2 (AND2X1_LVT) 1.04 0.00 0.34 r
... ... ... ...
U
data arrival time 4.64
al
source latency 0.00 4.80
I_CLOCKING/sys_clk_in_reg/Q (DFFX1_LVT)... 0.92 0.00 4.80 r
rn
I_CLOCKING/I_CLK_SOURCE_SYS_CLK/A (NBUFFX16_LVT) 0.92 0.00 4.80 r
I_CLOCKING/I_CLK_SOURCE_SYS_CLK/Y (NBUFFX16_LVT) 0.92 0.00 4.80 r Capture path
... ... ... ...
te
I_BLENDER_0/R_384/CLK (SDFFX1_LVT) 0.92 0.00 4.80 r
clock uncertainty -0.20 4.60
In
library setup time 1.00 -0.14 4.46
data required time s 4.46 6- 36
sy
It is possible to apply incremental timing derates: If your design has existing derates, which you do not want
to modify, you can still apply an additional derate if required. This is controlled using the following
op
commands:
set_timing_derate -increment …
reset_timing_derate -increment …
yn
report_timing_derate -increment …
Note that write_sdc will not write the incremental derates, but write_script will.
rS
The total derate is then calculated depending on the derate method chosen:
Simple derates:
Fo
total derate factor = base derate factor + increment derate factors

AOCVM:
ed
total derate factor = (aocvmGuardband * aocvmDerate) + incremental derate

POCVM:
er
total derate factor = (pocvmGuardband * pocvmDistanceDerate) + incremental derate

i st
eg
R

Timing Pessimism with OCV Analysis

The “min-max” OCV delay range of BF1 in the SLOW corner is 90-100 ps:
BF1 BF1 BF1 BF1 BF1 BF1 BF1 BF1 BF1 BF1
y
1. Assume the above OCV is modelled by early/late derating:
If the launch and capture clock paths each contain ten BF1 buffers,
nl
setup timing analysis assumes:
a. 900 ps for launch path; 1000 ps for capture path
O
b. 1000 ps for launch path; 900 ps for capture path
se
2. On actual silicon, the more realistic total delay for ten BF1 buffers will be
between 900ps and 1000ps. Therefore, OCV timing analysis is:
a. Optimistic
U
b. Pessimistic
al
3. The closer the cells are physically placed to each other:
a. The larger their systemic V/T variations can be
rn
b. The smaller their systemic V/T variations can be
te
4. Since process (P) variation is random, its effects are smaller in a path with:
a. 30 BF1 cells
In
b. 3 BF1 cells
s 6- 37
sy
Answers: 1 B, 2 B, 3 B, 4 A
op
This page serves as a “lead-in” or introduction to the next slides about AOCV and POCV.
Questions 1 and 2 show how OCV is pessimistic by nature: OCV will assume 1000 ps for the launch path and
yn
900 ps for the capture path, for setup timing (Question 1), but in reality the launch/capture path delays will be
something between these extremes (Question 2), not as pessimistic as OCV predicts.
rS
Questions 3 and 4 introduce the concepts that AOCVM are based on: Different, more realistic derating factors
can be applied to cells as a function of the depth of the timing path (number of cells), and the maximum
Fo
distance between the cells along the timing path.

Question 3: The closer the cells are to each other, the less “systemic” V/T variation exists between the cells,
which also means less derating.
ed
Question 4: The more cells there are in a timing path, the closer the total path delay component associated
with “random” process (P) variations will be to the “mean” or average path delay, essentially cancelling out
er
the “random” P variations. This makes the path delay more predictable on “deeper” paths (more cells along a
path).
i st
eg
R

AOCV Calculates Derating Based on Depth and Distance

Advanced On-Chip Variation provides more realistic variable derating by
taking path depth and distance into account
Random P variation modeled as a
y
 Launch Cell Path Depth = 5
function of logical path depth
nl
 Systemic V/T variation modeled as a
O
function of the maximum physical distance
between related timing path cells and nets
se
CRPR
CRPR
AOCV depth+distance variation table Common
Common
U
Point
Point Depth=0 Capture Cell Path Depth = 3
version: 1.0 Depth = 0
object_type: lib_cell
al
delay_type: cell
rf_type: rise
rn
derate_type: late
object_spec: lib/MUX2_1 Depth 1 2 3 4 5 ...
depth: 1 2 3 4 5 … Variable
te
1.214 1.153 1.109 1.078 1.056 ...
distance: 100 500 Derate
table: 1.214 1.153 1.109 1.078 1.056 …\ Flat
In
1.271 1.201 1.145 1.121 1.100 … 1.15 1.15 1.15 1.15 1.15 ...
Derate
s 6- 38
sy
AOCVM reduces the level of pessimism in timing analysis by careful modeling of the factors mentioned
above: A single derate value is determined and applied to all cells along the launch path, if appropriate.
op
Optionally, a different single derate factor can be applied to all the nets along that same path. Similarly,
derate factors for cells and nets are determined and applied to capture paths, if appropriate. The cell and net
derate factors vary based on the “depth” of the path (total number of cells along the path), as well as the
yn
maximum distance between the cells along the path (see example below). The larger the depth, and/or the
smaller the maximum distance, the closer the derate factor should get to 1.0
rS
The example below shows how the maximum distance is calculated for a specific launch/capture sequential
Fo
timing path:
The maximum cell distance (Cell DMAX) is the length of the diagonal of the inner rectangle, which
encompasses the placement of all the related launch and capture path cells.
ed
The maximum net distance (Net DMAX) is the length of the diagonal of the outer rectangle, which
encompasses the routing of all the related launch and capture path nets.
er
Depth and distance information can be provided

st
in the same table as shown above, or carried in

two separate tables, one for depth, one for distance.
i
eg
R

Enabling Advanced On-Chip Variation Modeling
 AOCVM reduces excessive timing margin or pessimism
y
nl
 If you have AOCVM tables, use them!
O
se
set_app_options -name time.aocvm_enable_analysis -value true
set_app_options -name time.ocvm_enable_distance_analysis -value true
U
read_ocvm -corners SLOW SLOW_derate_table Derate tables
provided by your
read_ocvm -corners FAST FAST_derate_table
al
library supplier
rn
report_ocvm –type aocvm
te
In
s 6- 39
sy
The time.aocvm_enable_analysis true setting enables AOCVM analysis.
When time.ocvm_enable_distance_analysis is set to true, derating values are based on both the
distance and the depth of the path. When this option is set to false, only the worst-case distance
op
information in the table is used to calculate the derating values, which is more pessimistic than using all of
the distance information.
yn
The following additional application options can be used to further configure AOCVM analysis:
rS
time.aocvm_analysis_mode
time.aocvm_enable_clock_network_only
Fo
ed
er
i st
eg
R

Pessimism in Graph-Based Analysis (GBA) AOCV
Modeling random P
y
4
variation based on
nl
path depth in AOCV
can be pessimistic
O
due to GBA limitation
se
U
al
• In ICC II, GBA-based AOCV must use the worst-case 9.7% derate for the Stage AOCV %
shared “AND3”, based on the shorter 4-stage path, for the 39-stage timing path Count Derate Increase
rn
1 1.160 16.0%
• In PrimeTime, PBA-based AOCV uses the actual path specific 3.4% derate,
4 1.097 9.7%
based on the actual 39-stage count of the path
te
6 1.072 7.2%
• GBA AOCV pessimism for the long path = 9.7% - 3.4% = 6.3%
39 1.034 3.4%
In
s 6- 40
sy
GBA (graph based analysis) is the only method for STA used in ICCII. In GBA, the cell delays, even if they
are part of multiple paths, are only calculated once. Therefore, in the picture above, the shared cell (circled)
op
can only have a single delay, which has to be the worst delay, in order to not miss timing violations. In this
case, the cell will be derated by the depth-based derate factor determined by the short (4 stages – from the
launch register to the D pin of the capture register) path. For the long (39 stages) path, the derate of this
yn
shared cell will be too pessimistic, and might cause failures that don’t exist. Only in PBA (path based
analysis) can the derates be determined path-by-path.
rS
Fo
ed
er
i st
eg
R

Parametric On-Chip Variation Modeling of Random Variation

 POCV does not rely on path depths to model random variation – instead
uses a Gaussian Distribution model for individual cell delays
y
 Each cell has a nominal or mean (m) delay and a standard deviation (σ) delay value
nl
(σ is also called sensitivity)
O
 The cumulative delay of a path is
se
determined by statistically adding the
delay distribution of each stage
U
a c f
al
e h
b
rn
d g
m
te
 Eliminates GBA-based pessimism
In
s 6- 41
sy
Statistically combining the delay distribution of each stage is more accurate than simply adding the worst-
case value from each stage. The resulting delay and slack values are more realistic and less pessimistic than
op
values calculated by simple min-max addition.

yn
rS
Fo
ed
er
i st
eg
R

POCV Input Data: Sigma (𝜎) - Two Formats
Liberty Variation Format (LVF)

POCV single coefficient file
in standard cell liberty libraries
y
version : 4.0 ocv_sigma_cell_rise ("delay_template_4x4") {
ocvm_type : pocvm sigma_type : "late";
nl
object_type: lib_cell index_1("0.0088, 0.0264, 0.0608, 0.1296");
rf_type : rise fall index_2("0.001, 0.0024, 0.0052, 0.0108");
O
delay_type : cell values("0.000476, 0.000677, 0.001075, 0.001870", \
derate_type: late "0.000651, 0.000901, 0.001303, 0.002081", \
object_spec: lib28nm/invx* "0.000840, 0.001166, 0.001714, 0.002558", \
se
coefficient: 0.05 "0.001115, 0.001520, 0.002193, 0.003317");
}
The POCV Coefficient is LVF: Cell delay variation or σ (time
U
 
characterized at a particular units) is modeled as a function of
al
input transition and output input transition and output load
load per library cell (σ = C * m) per timing arc
rn
 No delay variation dependency to  For finer geometries ( <= 16nm ) and low
te
input transition and output load voltage, delay variation(s) can strongly
depend on the input slew and output load
In
s 6- 42
®
sy
SiliconSmart supports POCV LVF characterization. SiliconSmart is Synopsys’ comprehensive library
characterization solution.
op
yn
rS
Fo
ed
er
i st
eg
R

POCV Path Calculation Example
Both cells have POCVM coefficient of 0.05 or 5%
y
Arrival Time
nl
140ps
Cell 1 Cell 2
O
3 sigma
Nominal or mean delay (m) = 60ps Nominal or mean delay (m) = 80ps
Delay sigma (σ) = 0.05*60 = 3ps Delay sigma (σ) = 0.05*80 = 4ps
2 sigma
se
Path delay mean, mpath = 60 + 80 = 140ps Late path arrival at 2σ = 140 + 2*5 = 150ps
Path delay sigma, σpath = 𝟑𝟐 𝟒𝟐 Late path arrival at 3σ = 140 + 3*5 = 155ps
U
= 5ps
al
Timing analysis uses 3 sigmas, by default:
rn
𝐷𝑎𝑡𝑎 𝐴𝑟𝑟𝑖𝑣𝑎𝑙 𝑜𝑟 𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑚𝑝𝑎𝑡ℎ 3 ∗ σ𝑝𝑎𝑡ℎ
𝐷𝑎𝑡𝑎 𝐴𝑟𝑟𝑖𝑣𝑎𝑙 𝑜𝑟 𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑚𝑝𝑎𝑡ℎ 3 ∗ σ𝑝𝑎𝑡ℎ
te
𝑆𝑙𝑎𝑐𝑘 𝑚𝑠𝑙𝑎𝑐𝑘 3 ∗ σ𝑠𝑙𝑎𝑐𝑘
In
s 6- 43
sy
Path delay mean: 𝑚𝑝𝑎𝑡ℎ m1 m2 m3 …
op
Path delay sigma: σ𝑝𝑎𝑡ℎ σ1 σ2 σ3 …
Slack mean, setup: 𝑚𝑠𝑙𝑎𝑐𝑘, 𝑠𝑒𝑡𝑢𝑝 mdata arrival - mdata required

yn
Slack mean, hold: 𝑚𝑠𝑙𝑎𝑐𝑘, ℎ𝑜𝑙𝑑 mdata required - mdata arrival

rS
Slack sigma: σ𝑠𝑙𝑎𝑐𝑘 σ𝑑𝑎𝑡𝑎 𝑎𝑟𝑟𝑖𝑣𝑎𝑙 σ𝑑𝑎𝑡𝑎 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑑

Fo
(+) if σ𝑑𝑎𝑡𝑎 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑑 is a positive value

(–) if σ𝑑𝑎𝑡𝑎 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑑 is a negative value
ed
See Appendix A for more details on slack sigma calculation including CRPR.
er
i st
eg
R

POCV Input Data: Distance-based Derating
 Systemic or distance-based (V/T) derating factors can also be taken into

account in POCV, and can also be specified in two formats:
y
nl
POCV distance table (side file) POCV distance table (LVF)
O
version : 4.0 ocv_derate(aocvm_distance_design) {
ocvm_type : pocvm ocvm_derate_factors(aocvm_distance_template) {
object_type: design rf_type : rise fall ;
se
rf_type : rise fall derate_type: late ;
delay_type : cell path_type: clock_and_data;
derate_type: late index_1("1000, 10000, 50000, 100000, 500000");
U
object_spec: values("1.004, 1.018, 1.036, 1.055, 1.088");
distance : 1000 10000 50000 100000 500000 }
table : 1.004 1.018 1.036 1.055 1.088 }
al
rn
 The distance derate factor is applied on the
mean delay, independently of the sigma delay
te
In
s 6- 44
sy
Image: shows how the maximum distance is calculated for a specific launch/capture sequential timing path.
The maximum cell distance (Cell DMAX) is the length of the diagonal of the inner rectangle which
op
encompasses the placement of all the related launch and capture path cells.
The unit of distance is defined by the technology file: If unitLengthName = micron and
yn
lengthPrecision = 1000, the unit of length is 0.001 microns, or 1nm.

rS
Timing analysis will interpolate derating values for distances in between the listed distances. If the distance is
larger than the largest listed distance in the table, the last derate value is used (no extrapolation is done).
Fo
Using the example side file table above: If the distance of a cell is 30,000 nm, its derate value will be 1.027
(mid-way between 1.018 and 1.036). If the distance is 500,000 or larger, the derate value will be 1.088.
ed
These are the full formulas for calculating the derated delays:
Cell delay derated = "Cell delay" * ( "POCVM guardband" * "POCVM distance derate" + "Incremental derate" )
er
Cell delay sigma = "Cell delay" * ( "POCVM guardband" * "POCVM coefficient" * "POCVM coef scale factor" )
i st
eg
R

POCV Setup
 Both POCV formats can be applied at the same time
y
 POCV LVF library (.db/NDM) on some cells and POCV side file on others
nl
O
set_app_options -name time.pocvm_enable_analysis -value true
set_app_options -name time.ocvm_enable_distance_analysis -value true
se
# POCV data can be in LVF or in side files:
read_ocvm -corners SLOW SLOW_pocv_coefficient_file
U
read_ocvm -corners SLOW SLOW_pocv_distance_table
al
report_ocvm -type pocvm *1
rn
report_timing -variation *2
te
In
s 6- 45
sy
If your libraries contain LVF data, regenerate ICC II reference libraries using IC Compiler II Library
Manager version K-2015.06-SP1 or later. The LVF information will be included in the design libraries and
op
read into your ICC II session automatically.
Both POCV formats can be applied at the same time. If both are set on the same arcs, POCV side file data
yn
takes precedence, by default. The precedence of LVF data and coefficients in side files is controlled by the
time.pocvm_precedence application option which can have one of three values:
rS
• file (default): preserves the earlier behavior of coefficient files overriding LVF data
• library: POCV LVF data in the library overrides coefficients in side files
Fo
• lib_cell_in_file: IC Compiler II uses the following priority, in decreasing order of precedence, to

determine the POCV data that is used
• Library cell table in coefficient file
ed
• LVF data
• Hierarchical cell table in coefficient file
er
• Design table in coefficient file

This feature only applies to delay variation data since slew and constraint variation (see next page) are only
st
supported in LVF
i
eg
*1reports the design objects that are annotated with POCV coefficients
*2when you use the -variation option, ICC II prints the statistical information (mean and sigma) in the
R
timing report. See appendix A for an example.

POCV Additional Setup
 If your LVF contains setup/hold constraint variation data, use:

time.enable_constraint_variation Default: false
y
nl
 If your LVF contains output slew variation tables, use:
O
time.enable_slew_variation Default: false
se
 Modify the number of sigmas (σ) for timing analysis, if needed:
U
set_pocvm_corner_sigma –corners {ff_corner} 4.0
report_ocvm –type pocvm –corner_sigma –corner ff_corner
al
rn
 By default, timing analysis (and report_timing) uses values at 3 standard
deviations (3σ) from the mean
te
 Increasing σ tightens, and decreasing σ relaxes the timing requirement
In
s 6- 46
sy
If you are using LVF libraries with (setup and hold) constraint variation data, enable the use of constraint
variation during POCV analysis for more accuracy:
set_app_options -name time.enable_constraint_variation -value true
op
Enabling slew variation (fully supported as of 2016.03-SP4) allows even more accuracy when calculating the
yn
path delays.
rS
Here’s an example of a slew variation table in LVF:

ocv_sigma_rise_transition (lvf_table) {
sigma_type : "late";
Fo
index_1(" 0.0056, 0.1016, 0.2616, 0.5336, 1.0696, 1.5 ");

index_2(" 0.004, 0.016, 0.064, 0.18, 0.32 ");
values("0.02475, 0.06234, 0.21407, 0.57290, 1.01250",\
ed
"0.04457, 0.07590, 0.21450, 0.57667, 1.02480",\

"0.06885, 0.11249, 0.24316, 0.58381, 1.02530",\
"0.10093, 0.15659, 0.30315, 0.61987, 1.03060",\
er
"0.15414, 0.22430, 0.41353, 0.73537, 1.11670",\

"0.19200, 0.27223, 0.48577, 0.83396, 1.20230"); }
i st
Instead of using corner-specific sigmas, you can change the global default using the command
eg
set_pocvm_corner_sigma.
R

Perform a ‘Timing Sanity Check’

 Before starting placement it is important to ensure that
the design is not over-constrained
y
 Constraints should match the design’s specification
nl
 Report ‘ZIC’ setup timing before placement
O
 Check for unrealistic or incorrect constraints
 Investigate large zero-interconnect timing violations
se
set_app_options -list {
U
time.delay_calculation_style zero_interconnect
time.high_fanout_net_pin_capacitance 0pF Use if design
has unbuffered
al
time.high_fanout_net_threshold 32 high fanout nets
}
rn
update_timing –full
report_constraints –all_violators –max_delay Use one of
te
report_qor -summary -include setup these reports to
get the WNS
report_timing –slack_lesser_than 0
In
Do NOT save the above app option settings to the block!
s 6- 47
sy
What should you see in a “zero interconnect” timing report? A positive slack for all paths means that the
constraints have passed the check. Small negative slacks are probably OK as well, since these can be fixed by
op
ICC II’s advanced optimization engines.

You are looking for large violations. If, for example, a path shows a timing violation as large as the clock
period, then you should investigate whether the constraints were applied correctly, or whether the design was
yn
not synthesized with the correct constraints. Large violations will most likely NOT be fixed by ICC II, so the
problem must be addressed before beginning placement.
rS
It is common for synthesis to be performed in fewer scenarios than will be used during physical design. In
this case, it is possible to see large violations in these non-synthesis scenarios. You will need to analyze the
Fo
violations in detail, to determine if ICC II is likely to fix the violations, or if the design should be re-
synthesized for those scenarios.
The following two application options are useful if the netlist contains un-synthesized high fanout nets
ed
(HFNs), and these HFNs are not constrained by set_ideal_network: Users sometimes prefer ICC II to
buffer certain HFNs, instead of synthesis. This is accomplished by making these nets ideal. If the timing
er
constraints are the static timing analysis sign-off constraints, set_ideal_network will not be included.
Without the following settings, ZIC timing may then show a large timing violation on these high fanout
st
paths. The example below sets the input pin capacitance of nets with a fanout of 100 or larger (you can
choose an appropriate value for your design), to 0pF. When these setting are applied, a full update_timing
i
eg
is required for timing analysis to see the effects of these settings:

R
time.high_fanout_net_pin_capacitance 0pF
time.high_fanout_net_threshold 100 }
update_timing -full

Additional Timing Settings
 Use report_app_options to find additional timing

control application options
y
nl
 Use the man pages to learn more
O
report_app_options time.*
se
U
al
...
------------------------------------ ---- ----- ------------ -------------- ------
rn
...
time.disable_cond_default_arcs bool -- -- false block
time.disable_internal_inout_net_arcs bool -- -- true global
time.disable_recovery_removal_checks bool -- -- false global
te
time.edge_specific_source_latency bool -- -- true block
...
In
s 6- 48
sy
Note that the following often used application options are global, i.e. not saved in the block. They need to be
set every time the tool is invoked:
time.enable_preset_clear_arcs
op
time.disable_recovery_removal_checks
time.use_pin_capacitance_ranges
yn
You can report all global application options using:

rS
report_app_options -global
Fo
ed
er
i st
eg
R

1. It is recommended to create all required modes, corners and

scenarios before populating them with constraints.
y
nl
True or false?
O
2. What is the recommended way of specifying a corner’s PVT?
se
U
al
3. If there is no exact match between a corner’s specified VT
rn
values and the available library VT panes, what does ICC II do?
te
In
s 6- 49
sy
op
yn
rS
Fo
ed
1. True. This ensures that no constraints are lost by being placed in the default mode, corner or scenario.
er
2. Using set_process_number, set_voltage, and set_temperature, and if needed,

set_process_label.
st
3. ICC II automatically finds the closest match between the specified VT and the multiple non-matching
library VT panes. Only VT matching is performed to find the closest match. If the P value does not
i
eg
match, one will always be picked. Most likely this will be the first pane that matches by VT, meaning the
P value is irrelevant in this case. ICC II will still report a warning though.
R

4. Why is it better to use AOCV rather then set_timing_derate?

And why is POCV even better?
y
nl
O
5. A newly-created scenario is, by default, active, and enabled for
se
setup/hold timing, but not for power and max-transition /
capacitance analysis.
U
True or False?
al
rn
6. The current_scenario can always be independently specified
from the current_mode and current_corner.
te
True or False?
In
s 6- 50
sy
op
yn
rS
Fo
4. AOCV computes a derating factor that is dependent on the depth (and optionally distance) of a path; this
ed
is much closer to actual silicon variation. POCV beats AOCV by getting rid of the inherent shared-path
pessimism that occurs with GBA.
er
5. False. Newly-created scenarios are, by default, enabled for ALL analysis types, not just setup/hold timing.
6. False. Generally, specifying the current_mode and current_corner determine the
st
current_scenario, and vice-versa. The only exception is when a scenario has not been created for a
given mode/corner combination.
i
eg
R

7. Post-placement, post-CTS and post-routing optimization occurs in:
y
a. All active scenarios
nl
b. All current scenarios
c. All active and current scenarios
O
d. All scenarios, whether active or not
se
U
8. Large zero-interconnect (ZIC) timing violations can probably be
ignored if they occur on non-ideal high-fanout (HFN) nets, or in
al
scenarios that were not used during synthesis.
rn
True or False?
te
In
s 6- 51
sy
op
yn
rS
Fo
ed
er
st
7. A. There is only one current_scenario.

8. True.
i
eg
R

y
 Perform MCMM setup: Define the corners, modes and
nl
scenarios required for analysis
and optimization; Load the MCMM constraints
O
 Apply timing and optimization controls
se
 Confirm implementation phase readiness with
U
a zero-interconnect timing sanity check
al
rn
Begin “Lab 6: Timing Setup”
te
In
s 6- 52
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix
y
nl
O
A – Scaling Groups
B – Additional Information on POCV
se
C – Constraints in OCV
U
al
rn
te
In
s 6- 53
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix A
y
nl
O
Scaling Groups
se
U
al
rn
te
In
s 6- 54
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Scaling Groups 2017.09
1.0V
PVT from timing pane
y
PVT generated at design time
nl
0.8V
O
-40 C 0 C 125 C
se
 By using scaling groups, ICC II can interpolate between any voltage and
temperature bounded by the four .db PVT conditions, for example:
U
 0.9V @ -20 deg C
al
 0.8V @ 100 deg C
rn
 Enables efficient multi-voltage design without having to characterize
every possible operating voltage and temperature
te
 Typically not used for tape-out
In
s 6- 55
sy
Scaling groups existed in ICC II prior to 2017.09, but they needed to be created in ICC II Library Manager.
This is no longer necessary. Scaling is now entirely done in ICC II.
op
yn
rS
Fo
ed
er
i st
eg
R

Using Scaling Groups
 Define the scaling groups (SGs) by listing the required .dbs

 The actual db file is not needed - the db name is only used to identify the pane
y
 To find the names, run report_lib and look for “Source .db libraries”
nl
 Process number and label must be identical across the .dbs in an SG
O
 Next, you may specify which SG should be used in which corner
 By default, all SGs can be used in all corners
se
define_scaling_lib_group –name my_sg1 \
U
{ss0p75vn40c.db ss0p95vn40c.db ss0p75v125c.db ss0p95v125c.db}
al
# optional – if you only want to use the scaling group in a specific corner:
rn
set_scaling_lib_group my_sg1 -corners ss_80c
te
# Prevent any scaling groups from being used for analysis for corner ss_120c:
set_scaling_lib_group -none -corners ss_120c
In
s 6- 56
sy
The set_scaling_lib_group command allows specific scaling library groups to be used for analysis in
the specified corner(s). The tool performs interpolation between libraries in this group for voltage,
op
temperature, or both voltage and temperature. You can set scaling library for maximum, minimum, or both
maximum and minimum delay analysis (using the -min and -max options). You can set multiple allowable
scaling library groups on a corner. By default, all defined scaling groups may be used on every corner.
yn
In the example above, where scaling is disabled for a specific corner with
rS
set_scaling_lib_group -none -corners ss_120c, VT-matching will occur for this corner.
Fo
ed
er
i st
eg
R

Notes on Scaling Groups
 When defining a scaling group, the VTs need to form a rectangular grid:
1.0V 1.0V 1.0V
y
0 85
nl
0.8V 0.8V 0.8V
O
-40 C 125 C -40 C 125 C -40 C 125 C
se
1.0V
U
 Values will scale only if within the grid
Anything outside the grid will use the “edge” value
al

0.8V
rn
-40 C 125 C
te
 report_pvt should not show a VT mismatch, unless you
In
specify a value that is out of range (see above)
s 6- 57
sy
A grid can consist of four or eight libraries. For level shifters with two voltages (VDDL and VDDH), you
would need eight panes which form a cubic grid:
op
1.0V
yn
0.9V VDDH
rS
VDDL
0.8V
0.6V
Fo
‐40 C 125 C
ed
er
i st
eg
R

Appendix B
y
nl
O
Additional Information on POCV
se
U
al
rn
te
In
s 6- 58
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Sources of Variations
 Electrical properties of devices vary due to

 Shape variations in transistor polygons
y
 Variations in position and density of doping atoms
nl
 Irregularity of edges
O
Planar
se
 Some affected measurements
Vth: threshold voltage
U

 Leff: effective channel length
al
FinFET
 Ion: on current
rn
 Ioff: off current
 W: width
te
 tox: gate oxide thickness
In
s Source: Jha et. al. IEEE EDS 2011 6- 59
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Early/Late with Non-Gaussian Distributions
 POCV handles non-Gaussian delay

distributions with early and late
y
constructs
nl
 Supported both for single coefficient and
O
LVF flows
se
 Timing analysis is done using the
estimated Gaussians
U
 Setup and Hold timings are reported at
al
their respective late, and early
distribution tails
rn
te
In
s 6- 60
sy
op
yn
rS
Fo
ed
er
i st
eg
R

How is sigma_slack calculated?
sigma_slack = sqrt(sigma_arrival^2 +/- sigma_required^2)
y
nl
(+) if sigma_required is positive value
O
(-) if sigma_required is negative value
se
where
U
sigma_required^2 = sigma_capture_path^2 – sigma_crpr^2
al
where
rn
sigma_crpr^2 = sigma_common_launch_path^2 + sigma_common_capture_path^2
te
In
s 6- 61
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Data Path Pessimism Reduction

 Data Path Pessimism Removal in GBA
Assume 30 ps delay variation per stage
y
AOCV GBA depth
nl
FF
O
1 4 4 4 9 4 4 4 1
FF
se
U
AOCV delay variation = 30 + 15 + 15 + 15 + 10 + 15 + 15 + 15 + 30 = 160ps
al
POCV delay variation (statistical) = √ 30^2 + 30^2 + …… + 30^2 = 90ps
rn
9 times (one for every stage)
70ps pessimism
te
removal
In
Note: POCV is Synopsys Patented Technology
s 6- 62
sy
op
yn
rS
Fo
ed
er
i st
eg
R

report_timing -variation
report_timing –variation –significant_digits 5 -nosplit

Startpoint: i (input port clocked by CLK)
Endpoint: o (output port clocked by CLK)
y
Path Group: CLK
nl
Path Type: max
Point Mean Sensit Incr Path
--------------------------------------------------------------------------
O
∙∙∙∙∙
I/ZN (INVD16BWP) 0.00975 0.00049 0.01121 & 0.01121 f
se
o (out) 0.00007 0.00000 0.00007 & 0.01128 f
data arrival time 0.01128
U
clock CLK (rise edge) 1.00000 1.00000
clock network delay (ideal) 0.00000 1.00000
al
output external delay 0.00000 1.00000
data required time 1.00000 0.00000 1.00000
rn
--------------------------------------------------------------------------
data required time 1.00000 0.00000 1.00000
data arrival time -0.00982 0.00049 -0.01128
te
--------------------------------------------------------------------------
slack (MET) 0.99018 0.00049 0.98872
In
s 6- 63
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix C
y
nl
O
Constraints in OCV
se
U
al
rn
te
In
s 6- 64
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Modeling OCV Using Min/Max Libraries
If “min” and “max” libraries are available to model on-chip

variation for each corner, they are specified as shown
below, instead of applying set_timing_derate
y
nl
O
current_corner SLOW
se
set_voltage 0.95 –object_list VDD Slow
set_voltage 0.98 –object_list VDD -min corner SLOW_MAX
SLOW_MIN
U
set_temperature 125 Delay
set_temperature 117 –min

Fast
al
set_process_number –late 1.10
corner FAST_MAX
set_process_number –early 1.08 FAST_MIN
rn
set_process_label –late SLOW_MAX Operating
Conditions
~ P / -V / T
set_process_label –early SLOW_MIN
te
In
s 6- 65
sy
If a process label is needed (because the same process number is used for both the min and max libraries, for
example):
set_process_label –late SLOW_MAX
op
set_process_label –early SLOW_MIN

yn
rS
Fo
ed
er
i st
eg
R

Exercise: Constraints in OCV

Constrain IN1 of MY_BLOCK for setup and hold, for the SLOW corner,
assuming the input logic is on the same chip as MY_BLOCK:
y
SAME_CHIP T1
nl
Input Delay MY_BLOCK
IN1
O
Corner T1 T2 FF1
FF3
SLOW 6.0 3.0
se
CLK
Derated SLOW 5.4 2.7
Derated FAST 2.0 1.0 FF2
U
FAST 1.8 0.9
T2
al
Input Delay = ClkQ delay + Combo logic delay
rn
set_input_delay –max ______ -clock CLK [get_ports IN1]
te
set_input_delay –min ______ -clock CLK [get_ports IN1]
In
Note: Timing derate affects cell and net delays, and cell checks.
It does not affect timing constraints!
s 6- 66
sy
op
yn
rS
Fo
ed
er
ANS:
st
set_input_delay –max 6.0 –clock CLK [get_ports IN1]

set_input_delay –min 2.7 –clock CLK [get_ports IN1]
i
eg
R

Data I/O Port Constraint –max/-min Options

Constraints applied to data input or output ports (set_input_delay,
set_output_delay, for example) are part of the launch path; Timing
analysis uses their -max values for setup and -min values for hold
y
nl
Input example
FF1
MY_BLOCK
O
IN1
Launch paths FF3
se
CLK
FF2
Capture path
U
Output example
al
MY_BLOCK Launch paths
rn
OUT1
FF2
CLK FF1
te
Capture path
FF3
In
s 6- 67
sy
Additional I/O port constraints with –max/-min options:
set_input_transition -max|-min ...
op
set_load -max|-min ...

set_driving_cell –max|-min ...
yn
rS
Fo
ed
er
i st
eg
R

Ideal Clock Constraint –max/-min Options

Ideal clock constraints (set_clock_latency and
set_clock_transition) apply to both launch and capture paths
y
Setup Hold
nl
Launch uses –max Launch uses –min
Capture uses –min Capture uses –max
O
MY_BLOCK
se
Launch path
U
CLK FF1 FF2
al
Capture path
rn
te
For data and clock paths on the same chip: Do NOT use “slow”
and “fast” corner values for –max and -min constraint options!
In
s 6- 68
sy
The values for set_clock_uncertainty are defined as –setup and –hold values, which do not
follow the OCV max/min rules above.
op
The setup uncertainty is always subtracted from the capturing clock edge, to model the effects (skew, jitter
and added margin) which decrease the effective clock period, and thereby decrease the available time to meet
setup time.
yn
The hold uncertainty is always added to the capturing clock edge, to model the effects which increase the
arrival time of the capture clock relative to the launch clock, and thereby increase the required hold time.
rS
The set_clock_latency command also has –late and –early options, which are intended to be
Fo
used only with –source, to model the arrival time range for external or source latency.
The –late/-early source latency options are treated the same as –max/-min options, respectively, for
network latency, following the OCV max/min rules above.
ed
er
i st
eg
R

Agenda
DAY
y
nl
O
5 Design Setup
se
U
6 Timing Setup
al
7
rn
Running CTS
te
In
s 7- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Running CTS © 2019 Synopsys, Inc. All Rights Reserved. 7-1


Synthesis
y
nl
O
se
U
CTS & Optimization This Unit
al
rn
te
Signoff
In
s 7- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Unit Objectives
y
nl
Execute the “classic” CTS and optimization flow,
O

or the concurrent clock-and-data (CCD) flow
se
 Report and analyze results
U
 Control post-CTS I/O auto-latency update
al
 Use CCD during place_opt
rn
te
In
s 7- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Tree Synthesis Goal and Flows
 Placement should be completed
y
 Acceptable congestion, setup timing, and logical DRCs
nl
 High fanout signal nets (reset, scan enable, etc) are buffered
O
 The goal of the clock tree synthesis design phase is to:
 Build the clock tree buffer structure
se
 Route the clock nets
U
 Optimize datapath logic for setup and hold timing, and DRCs
Two CTS flows are supported:
al

 Classic CTS flow: CTS first, followed by data path optimization
rn
 Concurrent Clock & Data flow (CCD): CTS and data path optimization
te
performed concurrently
Recommended for timing-critical designs
In

s 7- 4
sy
Data path optimization will also reduce leakage power, if enabled.
op
yn
rS
Fo
ed
er
i st
eg
R

Comparing Classic CTS versus CCD

Classic CTS Concurrent Clock&Data
CK CK
y
nl
O
se
 Clock tree is built while ignoring  Clock tree is built with full
U
the data paths knowledge of data path timing
Goal: Minimize skew Goal: Meet setup/hold timing
al
 
 Allows full clock-cycle  Reg-to-reg timing may be larger or
rn
reg-to-reg timing smaller than a clock-cycle
Data path is optimized post-CTS Data path is optimized along with
te
 
- Clock tree remains untouched incremental clock tree modifications
In
(green buffer)
s 7- 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Classic CTS and CCD Flow
CTS Setup: Clock tree structure Unit 8
y
nl
Configure CTS: Optimization algorithms
O
Classic CTS CCD
se
U
clock_opt
al
build_clock route_clock final_opto global_route_opt
rn
te
Signal Routing
In
s 7- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Setup for Classic CTS and CCD Flows
The classic CTS and CCD flows require common setup
y
steps prior to executing CTS and optimization
nl
 Controlling clock tree balancing
O
 Handling pre-existing clock tree elements
se
 Specifying non-default routing and via rules
U
 Specifying clock timing and DRC constraints
al
rn
 Setup will be covered in the next unit Unit 8
te
In
s 7- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Running CTS
• Pre-CTS Checks
y
• Configure CTS
nl
• Running Classic CTS and CCD
O
Analysis
se
U
Post-CTS I/O Latency
al
rn
CCD during place_opt
te
In
s 7- 8
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Is the Design Ready for CTS?
check_design -checks pre_clock_tree_stage
y
Running mega-check 'pre_clock_tree_stage':
nl
Running atomic-check 'design_mismatch'
O
Running atomic-check 'scan_chain'
Running atomic-check 'mv_design'
se
Running atomic-check 'legality'
Running atomic-check 'design_extraction'
Running atomic-check 'timing'
U
Running atomic-check 'clock_trees'
al
rn
 Creates an EMS database. Use the Message Browser to examine
te
 The clock_trees check runs the atomic command check_clock_trees
In
s 7- 9
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Tree Specific Checks
check_design checks for, and suggests solutions to address:
y
 Clock Definitions and Propagation
nl
 Generated clocks cannot be reached by master clock, etc.
O
 Reference Cells
Clock references with dont_touch, etc.
se

 Skew Balancing
U
 Balancing conflicts between clocks, etc.
al
 Multi-Voltage
rn
 Clock nets with MV violations, no AON bufs or invs for CTS etc.
 Capacitance and Transition Constraints
te
 Other Issues: dont_touch nets in clock network, etc.
In
s 7- 10
sy
• Clock Definitions and Propagation: Generated clocks cannot be reached by master clock, clocks with no
sinks, sinks with no clocks, etc.
• Reference Cells: Clock references with dont_touch or dont_use, cells in clock network not in
op
reference list, etc.

• Skew Balancing: Balancing conflicts between clocks, large phase delay in abstracts, balance points
yn
downstream of another clock exception, etc.

• Multi-Voltage: Clock nets with multi-voltage violations, no always-on (AON) buffers or inverters
rS
available for CTS

• Capacitance and Transition Constraints: Excessively small max_capacitance or max_transition,
Fo
set_load exceeding max capacitance limits, set_input_transition exceeding max transition

limits, etc.
• Other Issues: dont_touch nets in clock network, set_max_delay / set_min_delay constraints in
ed
clock network, etc.

er
i st
eg
R

Modes / Corners for CTS
 ICC II builds clock trees for all clocks in all

active setup and/or hold scenarios
y
nl
O
 CTS will also perform clock net logical DRC fixing on scenarios
enabled for max_transition and/or max_capacitance
se
U
 If you do not want a scenario to be used during CTS:
al
rn
set_scenario_status –active false {s1}
te
In
s 7- 11
sy
In general, we recommend that you activate all scenarios prior to CTS, which you will be using for post-CTS
optimization, meaning all the “hold” scenarios as well.
op
yn
rS
Fo
ed
er
i st
eg
R

Hold Fixing
 Hold fixing occurs in all scenarios that are enabled for hold:
y
set_scenario_status { s2 } -hold true
nl
O
 Control what cells are used to fix hold violations:
se
set_lib_cell_purpose -exclude hold [get_lib_cells]
set_lib_cell_purpose -include hold \
U
[get_lib_cells "*/DELLN*_HVT */NBUFF*HVT \
*/DELLN*_RVT */NBUFF*RVT"]
al
rn
 Control the effort for hold fixing:
te
clock_opt.hold.effort none|low|medium|high}
In
s 7- 12
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Minimize Hold Time Violations in Scan Paths
 Enable scan chains reordering to minimize branch crossings

 Can reduce hold time violations in the scan chain
y
nl
set_app_options –list {opt.dft.clock_aware_scan_reorder true} Default: false
O
test_si test_si
se
A C E A C E
U
clk clk
al
B D F test_so B D F test_so
rn
te
In
Without clock tree based reordering With clock tree based reordering
s 7- 13
sy
The app option should never be enabled before actual clock trees have been built. If enabled during
place_opt, you are instructing ICC II to optimize scan chains for hold reduction, which should not be the
case before the clock trees have been inserted. Therefore, make sure this is set to false during place_opt.
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Reconvergence Pessimism
Launch path
FF1 FF2
U5
y
U1 U2 U3 U4
nl
Capture path
U6
O
se
 To reduce OCV effects, clock trees try to share as many buffers as possible
 Remove the pessimism from the timing calculation caused by shared clock
U
paths (late/early for launch/capture calculation)
al
 Otherwise, false data path timing will lead to pessimistic clock trees (especially for CCD)
rn
set_app_options -name time.remove_clock_reconvergence_pessimism
te
-value true Default: false
In
s 7- 14
sy
By default, to account for OCV timing, ICC II calculates delays of the launch versus the capture paths under
different corners (either derated delays, or from different OCV-characterized libraries), even for the common
cells (U1-U4 above). The delays through the common cells can never be different when calculated as part of
op
the launch versus the capture path (assuming the launch and capture clock-triggering edges are the same -
both positive or both negative). The artificial delay difference that ICC II calculates for these shared cells by
yn
default, creates pessimistic timing, and is called “clock reconvergence pessimism” (CRP). The amount of
CRP is defined as the difference between the latest and earliest arrival times, through the shared or common
rS
cells, to the “common point”. For realistic timing analysis, the effect of CRP should be removed.
Fo
ed
er
i st
eg
R

Clock Reconvergence Pessimism Removal
The pessimism is removed for setup timing by adding the

CRP in the capture path, and by subtracting for hold
y
nl
Example setup timing report: Added CRP in capture path
O
clock network delay (propagated) 1.76 6.76
se
clock reconvergence pessimism 0.08 6.84
clock uncertainty -0.10 6.74
U
I_BLENDER_0/s4_op1_reg[30]/CLK (SDFFX1_LVT) 0.00 6.74 r
library setup time -0.26 6.58
data required time 6.58
al
For a hold report this
would be negative
rn
te
In
s 7- 15
sy
Here are default values of more CRP-related variables. Refer to the man pages for more details:
time.crpr_remove_clock_to_data_crp = false
time.clock_reconvergence_pessimism = normal
op
To get more details of a specific reg-to-reg CRP:

yn
report_crpr -from I_BLENDER/op2_reg/CLK -to I_BLENDER/op1_reg/CLK

Startpoint: I_BLENDER/op2_reg
rS
(rising edge-triggered flip-flop clocked by SYS_CLK)

Endpoint: I_BLENDER/op1_reg
(rising edge-triggered flip-flop clocked by SYS_CLK)
Common Point: I_BLENDER/CTS0_INVX16_LVT_G5B2I1/ZN
Fo
Common Clock: SYS_CLK

Launching edge at common point: FALLING
Capturing edge at common point: FALLING
CRPR threshold: 0.02
ed
Arrival Times Early Late CRP

---------------------------------------------------------------
er
Rise 1.60 1.67 0.07

Fall 1.58 1.66 0.08
st
---------------------------------------------------------------
Selection Details
i
---------------------------------------------------------------
eg
Edge Match: Match, using fall CRP

---------------------------------------------------------------
clock reconvergence pessimism 0.08
R

Congestion-Aware Initial CTS Classic CTS + CCD Flow
 Initial clock tree synthesis (build_clock) is not congestion aware!
y
 Based on virtual routing, by default
nl
 On large complex-floorplan designs, this may lead to:
O
 Pre- vs. post-route clock skew, latency,
and logical DRC degradation
se
 Congestion hotspots
Route DRCs
U

al
 Enable global routing for congestion estimation and congestion-
rn
aware clock tree construction during the build_clock stage:
te
set_app_options -list {cts.compile.enable_global_route true} Default: false
In
s 7- 16
sy
The build_clock phase of clock tree synthesis performs two steps: Initial clock tree synthesis or building
of the clock trees (CTS), followed by clock tree optimization (CTO). By default, CTS uses virtual routing,
but CTO uses global routing. If you enable the application option cts.compile.enable_global_route,
op
global routing will also be used during the CTS step.

yn
Virtual routing (VR) uses the shortest Manhattan distance between two points to estimate wire lengths. VR
does not consider areas with high congestion with routing blockages.
rS
Global routing (GR), on the other hand, sees congestion and routing blockages, and either routes around these
Fo
areas, or uses higher (not congested or blocked) routing layers. GR more accurately predicts what the final
detail routing will look like,
ed
er
i st
eg
R

Local Skew Optimization Classic CTS + CCD Flow
y
nl
O
se
U
al
 Performs timing aware clustering (as opposed to location based)
rn
 Optimizes local skew directly for setup and hold timing critical pairs
te
 Can relax skew target where possible (if slack is positive) to save
clock buffer area
In
s 7- 17
sy
Timing aware clustering:
Clusters timing-related clock tree nodes together to improve path sharing without degrading latency.
op
Automatic derivation of target skew:

Derives target skew for clocks based on timing QoR seen with early estimation of timing QoR. As a safe
yn
guard, derived value is limited to within 3% to 10% of clock period.

CTS works to meet derived skew instead of trying to achieve “0” skew and thus reducing clock buffer/cell
rS
area.
Local skew optimization ensures that timing related registers have minimal skew.
Fo
Local skew optimization during CTO:

After (traditional) global skew optimization stage in CTO, it now looks at timing QoR, and optimizes local
ed
skew for timing critical pairs to improve timing QoR.

Makes sure that skew/latency/DRCs across scenarios are not degraded.
er
i st
eg
R

Enable Local Skew CTS and CTO Classic CTS + CCD Flow
y
 When using CCD, local skew CTS and CTO are enabled by default
nl
 Because timing is taken into account for the initial clock tree, this reduces the
work that CCD has to do to further optimize the clock tree to meet timing
O
se
 To use local skew for classic CTS, you need to enable it specifically:
U
cts.compile.enable_local_skew true
al
cts.optimize.enable_local_skew true }
rn
te
In
s 7- 18
sy
There are a few more application options that control cts vs. cto:
CTS = “cts.compile.*”
CTO = “cts.optimize.*”
op
By default, local skew optimization will calculate relaxed skew targets. You might see messages like:
yn
Computing global skew target..

Setting target skew for clock: SYS_2x_CLK as 0.240000
rS
CTS is doing this in order to save on clock area. If, after CTS, hold timing is degrading more than what you
are comfortable with, you might consider turning this feature off using the application option
cts.common.enable_auto_skew_target_for_local_skew. Note that when this feature is enabled,
Fo
user specified target skew, if any, will be overridden.

With relaxed skew target you will save area on the clock trees but you may need to add extra hold buffers on
ed
the data path. Without this feature, you will increase clock area and save some data path hold buffers. This is
a trade-off that needs to be considered.
er
i st
eg
R

CCD and Boundary Registers CCD Flow
din
y
dout
nl
rst
O
 By default, CCD skews all registers (including boundary FFs) for timing
se
 To prevent latency adjustment on boundary registers, use:
U
ccd.optimize_boundary_timing  set to false Default: true
al
Boundary CK pin: en_launch/CK because of port din
Boundary CK pin: ff_1_1/CK because of port din
rn
Optimize_boundary_timing is set to false, 2 registers will not be optimized, 20 registers will be optimized.
Ignore ports for boundary identification (reset, scan_en, …) using:
te

In
ccd.ignore_ports_for_boundary_identification
s 7- 19
sy
In the early stage of a project, I/O timing constraints are often not well defined for all blocks, so conservative
constraints may be used. Since CCD is focused on creating “useful skew” to meet timing, this can cause
op
exceptionally large skews on I/O registers. To prevent this, CCD can be disabled for the I/O or boundary
registers, as shown above. CTS will, instead, perform classic CTS on these registers, so their latencies will be
close to the “average” latencies of all the registers in the same clock domain.
yn
The above options are honored by CCD throughout the ICC II flow.
rS
For identifying boundary registers, all ports are used. Since scan and reset ports go to a large number or all
Fo
registers, they should not be used for this identification process, and should be specified using
ccd.ignore_ports_for_boundary_identification.
ed
er
i st
eg
R

Restricting the Amount of CCD Skewing CCD Flow
 By default, CCD skews as much as needed to meet the timing
y
nl
 You can limit the amount of skewing if needed, for example:
O
set_app_options –name ccd.max_prepone –value 0.2
Default: -1000
se
set_app_options –name ccd.max_postpone –value 0.1
U
 ccd.max_prepone : max latency reduction (advance) allowed to a sink
al
 ccd.max_postpone : max latency increase (delay)
rn
 Setting a limit can impact the timing QoR as this restricts CCD
te
In
s 7- 20
sy
A possible reason to limit the amount of skewing might be if the user is looking for a trade-off between
timing QoR improvement versus uniformity of the clock tree.
op
The ccd.max_pre/postpone values are not corner-specific - they apply to all corners.
yn
The specified pre- and post-one values above are apply to the final CCD skews, whether CCD is performed
only during clock_opt, or during clock_opt as well as route_opt. In other words, if CCD during
rS
clock_opt uses the maximum pre- and post-pone values of 0.2ns and 0.1ns respectively, and if CCD is also
enabled during route_opt, these pre- and post-pone values are not added to the post-CTS skews (which
Fo
would then allow pre- and post-pone totals of 0.4 and 0.2, respectively); After route_opt, the maximum
pre- and postpone values remain 0.2 and 0.1, respectively.
ed
er
i st
eg
R

Skipping Path Groups during CCD CCD Flow
 You can configure CCD to skip the clock pins that belong to
particular path groups during clock latency adjustment
y
nl
O
 Datapath optimization will still be performed on these path groups
se
set_app_options –name ccd.skip_path_groups
–value { pathgroup1 {scenarioA pathgroup2} }
U
al
 If you specify a path group name without a scenario name, all path groups
rn
with the name specified from all scenarios are skipped
If you specify a path group name with a scenario name, only the path group in
te

the specified scenario is skipped
In
s 7- 21
sy
This app option is also honored when CCD is enabled in place_opt or route_opt.
op
yn
rS
Fo
ed
er
i st
eg
R

Hold Criticality during CCD CCD Flow

2018.06
 Although CCD setup optimizations are hold-aware, hold violations can

be introduced to improve setup timing
y
nl
 Usually, data path optimizations are able to address these hold violations
O
 You may want to prioritize hold during CCD if
 Fixing hold in your design is difficult / not possible
se
 Your design is area-critical, and the hold-buffer area increase is to be avoided
U
 To specify hold criticality during CCD, use:
al
ccd.hold_control_effort Default: low
rn
 Set to medium or high to reduce hold degradation
te
 Use only if hold timing is critical, since setup optimizations may degrade
 Only affects final_opto, as well as CCD optimization during route_opt
In
s 7- 22
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Additional Settings to Consider
 Review additional settings prior to running CTS:

 Handle an over-constrained design due to early/bad setup
y
cts.common.enable_dirty_design_mode
nl
 Fix the clock tree sinks (flipflops) after CTS
O
cts.compile.fix_clock_tree_sinks
Increase the placement effort during clock_opt
se

clock_opt.place.effort
U
 Increase the congestion effort
clock_opt.congestion.effort
al
 Control whether CTS is allowed to move pre-existing gates (e.g. ICGs)
rn
cts.compile.enable_cell_relocation default=all
te
 Allow physical feedthroughs in multi-voltage designs
In
opt.common.allow_physical_feedthrough default=false
s 7- 23
sy
cts.common.enable_dirty_design_mode
When the dirty_design_mode is enabled, CTS is allowed to override user settings, such as max transition,
max capacitance, cell spacing rules, and clock routing rules.
op
cts.compile.enable_cell_relocation
yn
This option controls how existing clock tree cells are relocated before clock tree synthesis. Possible values
are leaf_only, all and none. The default value, all, relocates all of the cells in the clock tree, for which
rS
relocation is allowed, in order to achieve the best latency. leaf_only relocates clock tree cells, for which
relocation is allowed, to the center of the bounding box of its fanout, only if none of the sinks in the fanout
has a downstream phase delay. The none argument keeps the incoming clock tree intact and prevents any
Fo
relocation of existing clock tree cells.

ed
opt.common.allow_physical_feedthrough
This option determines if an MVDD design should allow physical feedthroughs. A physical feedthrough cell
is one that physically belongs to a voltage area, but logically does not. In ICC2, these cells are marked with
er
power domain on instance in the UPF.

st
If it is necessary to prevent CTS from creating additional ports on a level of hierarchy, you can control this
i
using the command set_freeze_ports. Note that this can lead to sub-optimal clock tree QoR, it is
eg
therefore not recommended unless absolutely necessary.

R

Classic CTS and CCD Execution
 Clock tree synthesis, clock tree routing, and data path optimization
are all executed by:
y
nl
clock_opt
O
 CCD is enabled using the application option clock_opt.flow.enable_ccd
se
 The four stages of clock_opt are:
optional
U
al
You can control which stages are executed with -from/-to
rn

 For example, to perform only clock tree synthesis (CTS+CTO):
te
clock_opt -to build_clock
In
s 7- 24
sy
CTS buffers will have the prefix name "CT_BUF_####" by default.
op
This can be modified with:

cts.common.user_instance_name_prefix
opt.common.user_instance_name_prefix (applies to place_opt, clock_opt, route_opt,
yn
create_buffer_trees, and remove_buffer_trees)

rS
Fo
ed
er
i st
eg
R

Classic CTS Flow Stages
Command What does it do?
y
clock_opt \
nl
Builds GR clock trees*, and performs inter-clock balancing, for
–to build_clock
minimum skew
O
se
clock_opt \ Routes the clock nets
–from route_clock \
U
–to route_clock Updates I/O latencies
al
rn
clock_opt \
-from final_opto Performs data path optimization to meet timing and DRCs
te
In
s 7- 25
sy
* After the build_clock phase, the clock trees are global-routed. The global routing occurs during the
“optimization” (CTO) part.
If you enable the application option cts.compile.enable_global_route, global routing will also be
op
performed during the “compile” (CTS) part.

yn
rS
Fo
ed
er
i st
eg
R

Classic CTS Flow: clock_opt vs. Atomic Classic CTS Flow
To analyze intermediate results, you can either:

 Run clock_opt stages individually using –from/-to options
y
 Use atomic commands
nl
clock_opt stage Atomic commands
O
clock_opt synthesize_clock_trees
se
–to build_clock balance_clock_groups
U
clock_opt \ route_group –all_clock_nets \
–from route_clock \ –reuse_existing_global_route true
al
–to route_clock compute_clock_latency
rn
clock_opt -from final_opto
te
In
s 7- 26
sy
“final_opto” is the third and last stage of clock_opt
• Performs logic and placement optimization of non-clock logic to fix setup/hold timing and max tran/cap
op
(DRC) violations
• Tries to minimize cell disturbances
yn
rS
Fo
ed
er
i st
eg
R

CCD Flow Stages
set_app_options -name clock_opt.flow.enable_ccd -value true
y
nl
Command What does it do?
O
clock_opt \
Builds timing-driven GR clock trees, and performs inter-
–to build_clock
clock balancing, to improve setup/hold timing and DRCs
se
U
clock_opt \ Routes the clock nets
–from route_clock \
–to route_clock
al
Updates I/O latencies
rn
clock_opt \ Optimizes the data path logic and simultaneously optimizes
te
-from final_opto clock logic to further improve setup/hold timing and DRCs
In
No “atomic command” equivalents as in the classic CTS flow
s 7- 27
sy
Concurrent Clock & Data optimization combines useful skew CTS and data-path optimization, in order to
achieve best post-CTS results.
op
Provides concurrent setup/hold timing and power optimization to achieve good overall QoR
• Optimizes setup timing with lowest cost on clock power
yn
• Optimizes hold timing to reduce hold buffer cost with minimal impact on clock buffer cost
• Optimizations occur across all active, timing-enabled scenarios
rS
The clock optimizations during final_opto include on-route and off-route buffering, sizing and moves, buffer
Fo
removal and reparenting.

ed
er
i st
eg
R

Post-CTS: Post-route Clock Tree Optimization Classic CTS Flow
 Problems:
 Possibility of clock tree QoR degradation (skew, latency, logical DRC) due to
y
miscorrelation between global route (build_clock) and detail route (route_clock)
nl
 Clock tree QoR can further degrade due to coupling capacitance and crosstalk effects
O
 Solution: Post-route clock tree optimization
 Works on detail-routed clock trees to address these degradations
se
 Optimizations performed include on-route buffer insertion, buffer sizing, and gate sizing
U
synthesize_clock_trees –postroute
al
rn
 Post-route CTO can also be performed after signal routing – shown in
the routing unit
te
 If CCD is enabled, the command will only fix logical DRCs
In
s 7- 28
sy
“On-route" buffer insertion inserts buffers along the routed net, which prevents the net from having to be re-
routed.
op
yn
rS
Fo
ed
er
i st
eg
R

CCD Power or Area Recovery Classic CTS + CCD Flow
 The CCD engine can recover power or area downsized

from the clock network removed
D Q
y
FF
 Power/area recovered without any timing QoR impact CLK
nl
D Q
 Optimization includes repeater removal, clock cell and FF
O
CLK
register sizing
D Q
 Applies to either the classic CTS or CCD flow
se
FF
CLK
 Runs during the final_opto stage of clock_opt
U
 Can also be enabled during post-route optimization (route_opt)
al
Choose between power or area recovery:
rn

 Power: Should use accurate SAIF files for accurate dynamic power calculation
te
 Area: Use if accurate SAIF files are not available or if area is an optimization goal
In
s 7- 29
sy
CCD power/area recovery was introduced in release 2016.12.
op
yn
rS
Fo
ed
er
i st
eg
R

Enable CCD Power/Area Recovery
 When CCD power/area recovery is enabled:
y
 In the CCD flow, useful skew is used both for timing and power/area improvements
nl
 In the classic CTS flow, useful skew is used only for power/area improvements
 global skew/latency can degrade
O
se
set_app_options –name clock_opt.flow.enable_clock_power_recovery \
-value area | power | auto | none
U
clock_opt
al
rn
Default setting auto:
te
 In CCD flow, power recovery is enabled
 In non-CCD flow, no recovery occurs ( none)
In
s 7- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R

CCD Clock Power Recovery: Leakage, Dynamic or Total
 Clock power recovery will reduce leakage, dynamic or total power

based solely on the scenario configuration
y
nl
 Does not depend on opt.power.*
For example, to reduce total power
O

se
set_scenario_status func.ss_125c -dynamic_power true -leakage_power true
U
 Change the scenario power status according to your requirements
al
 For best results, make sure you allow CTS to size registers and ICGs (see next unit)
rn
te
In
s 7- 31
sy
If both dynamic and leakage options are false and you have set the recovery mode to “power”, ICCII will
issue a warning.
op
yn
rS
Fo
ed
er
i st
eg
R

Global Route Optimization (GRO)
y
nl
O
 It is possible to perform an additional GR-based optimization step
se
 Optimization based on full signal global routing and GR timing
 Includes setup and hold delay optimization, logic DRC fixing, and leakage
U
optimization
al
 Similar to post-route route_opt optimizations plus HFN rebuffering
 Most designs are expected to benefit from GRO
rn
te
In
s 7- 32
sy
GRO was introduced in release 2016.12-SP2.
op
yn
rS
Fo
ed
er
i st
eg
R

GRO in the Overall Flow
 Upon completion of the global_route_opt stage, the output of clock_opt

will be fully global routed and the subsequent signal routing flow will
y
automatically start with track routing
nl
ICC II Flow build_clock
O
place_opt route_clock
se
clock_opt final_opto
Global signal routing +
U
route_auto global_route_opt
optimization stage
OR
al
route_global
route_track Signal routing automatically
route_track
starts with track routing
rn
route_detail
route_detail
te
route_opt
In
s 7- 33
sy
By default, global_route_opt is not enabled, to not affect existing customer flows, even if you execute
clock_opt -from global_route_opt explicitly.
op
yn
rS
Fo
ed
er
i st
eg
R

Using Global Route Optimization
 By default, GRO is skipped – has to be enabled specifically
y
set_app_options –value true \
nl
Default: false
–name clock_opt.flow.enable_global_route_opt
clock_opt –from global_route_opt
O
Any later calls to global routing will be skipped by default
se

 route_global, route_auto
U
 All routing-related app options must be applied before running GRO
al
 Discussed in the routing unit
rn
 Pre-route of signals (using the route_group command) should be done
before executing GRO
te
 Discussed in the routing unit
In
s 7- 34
sy
If clock_opt.flow.enable_global_route_opt is enabled, clock_opt (without -from or -to) will
run all four stages. Therefore, if you had already run clock_opt previously, use the -from
global_route_opt option as shown.
op
In the event that it is necessary to run global routing after GRO has been completed, it is possible to do so.
yn
We do recommend that you use incremental GR if possible so as to not invalidate the optimization that was
done based on the existing global routing.
rS
To force incremental GR after GRO:

set_app_options -list {route.global.force_rerun_after_global_route_opt true}
route_global -reuse_existing_global_route true
Fo
ed
er
i st
eg
R

Example Script
open_lib design.dlib
open_block placed
y
# CTS setup ( unit 8)
nl
source clock_tree_balance.tcl
source clock_preexisting_cells.tcl
source clock_routing_rules.tcl
O
source clock_constraints.tcl
# Apply CTS configuration steps, as needed
se
set_scenario_status -active true [all_scenarios]
set_scenario_status { s2 s4 } -hold true
set_app_options –name clock_opt.hold.effort –value high
U
set_app_options -name time.remove_clock_reconvergence_pessimism -value true
set_app_options -name cts.compile.enable_global_route –value true
al
set_app_options -name opt.common.allow_physical_feedthrough –value true
rn
# Enable CCD, if applicable:
set_app_options –name clock_opt.flow.enable_ccd -value true
te
clock_opt
In
s 7- 35
sy
Prior to release 2016.12, you have to run ECO routing of the clock nets after clock_opt, as registers may
have moved slightly, breaking the clock pin routes.
# Perform eco routing:
op
route_group –all_clock_nets
yn
rS
Fo
ed
er
i st
eg
R

Running CTS
y
Analysis
nl
O
• Clock tree reports
• GUI tools
se
U
al
rn
te
In
s 7- 36
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Analyzing CTS Results: Clock QoR Report
report_clock_qor \
y
nl
[-type area | balance_groups | drc_violators | latency |
O
local_skew | power | robustness | structure | summary] \
[-histogram_type latency|transition|level|...] \
se
[-modes ...] [-corners ...] ...
U
al
 Reports max global skew (by default), late/early insertion delay,
clock DRC violations, number of clock tree references (buffers),
rn
structure of the clock tree, robustness, histogram…
te
In
s 7- 37
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Analyzing CTS Results: Clock Timing Report
report_clock_timing
-type summary | transition | latency | …
y
-modes {m1 m2}
nl
-corners {c1 c2} ...
O
 Reports actual, relevant skew, latency, inter-clock latency, etc. for
se
paths that are related
U
 Includes effects of early/late timing derates
 report_clock_qor does not consider derates
al
 Example:
rn
te
report_clock_timing -type skew
In
s 7- 38
sy
report_clock_qor uses the CTS timer view, which is the same timer view that clock_opt /
synthesize_clock_trees uses. In this view, no timing derating is considered while calculating skew and
op
latency.
When using CCD, which is timing-driven, late derates are considered.
yn
rS
Fo
ed
er
i st
eg
R

Analysis Using the CTS GUI
 CTS browser
 Identify clock tree object
y
properties and attributes
nl
 Traverse clock tree levels
O
se
 CTS schematic
 Trace clock paths
U
 Cross-probe with layout view
al
rn
 Clock tree levelized graph
 Clock tree latency graph per
te
corner
In
s 7- 39
sy
Menu: Window  New Clock Tree Analysis Window
op
yn
rS
Fo
ed
er
i st
eg
R

GUI Analysis: Clock Tree Levelized Graph
 Based on the abstraction options selected under the ‘Show’ column, the
graph will show the clock and generated clocks, and collapse the
y
remaining objects. The sinks of the clock tree are collapsed into boxes
nl
O
clock
se
Clock gates
U
al
Collapsed
registers
rn
Clock, generated clocks, clock gates, and muxes are shown, the rest is collapsed.
te
In
s 7- 40
sy
On the bottom, you see that gates, buffers and muxes will be colored the same. You can choose difference
colors to make them easier to distinguish.
op
Note: Abstract clock tree graph works on the current scenario.

yn
rS
Fo
ed
er
i st
eg
R

Running CTS
y
Analysis
nl
O
se
• Propagated Clocks
U
• Auto-Update of I/O Latencies
al
rn
te
In
s 7- 41
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Pre-CTS: Ideal Clock Latencies
 Prior to CTS, clock networks are “ideal”:

 Clock latencies are 0ns, by default
y
 Timing analysis uses ideal clock latency constraint values (set_clock_latency)
nl
 Applies to clock latencies inside the current block and to I/O reference clocks
O
(defined by set_input_delay / set_output_delay)
se
The “absolute” arrival time of the
Pre-CTS input data is 1.0 + 2.2 = 3.2ns
U
set_input_delay –clock CLK –max 2.2 [get_ports IN1]
MY_BLOCK
al
IN1
D Q D Q
1.0
rn
FF FF
create_clock –period 4 –name CLK [get_ports CLOCK] CLK CLK
set_clock_latency –max 1.0 [get_clocks CLK] (ideal) 1.0
te
CLOCK
(ideal)
In
Current block and I/O reference clocks are “ideal”
s 7- 42
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Post-CTS: Propagated Clock Sources / Updated Latencies

 clock_opt’s build_clock stage applies set_propagated_clock
to clock sources (ports/pins), and the route_clock stage automatically
updates clock network latencies:
y
nl
 Actual propagated clock network latencies calculated inside the current block
Updated ideal clock network latencies apply to I/O reference clocks
O

 updated to the median value of the block’s propagated latencies
se
The “absolute” arrival time of the
input data is 0.92 + 2.2 = 3.12ns
U
al
create_clock –period 4 –name CLK [get_ports CLOCK]
set_propagated_clock [get_ports CLOCK] D
Q IN1
D
FF
Q
FF CLK
CLK
rn
set_clock_latency –max 0.92 [get_clocks CLK] 0.92 0.90 D
FF
Q
CLOCK CLK
(ideal) 0.94
Updated automatically! (propagated)
te
I/O reference clocks remain “ideal” Current block clock networks
In
but their values are updated become “propagated”
s 7- 43
sy
Automatic latency update is useful if the I/O path logic is on the same chip as the “current design” block and
will be connected to the same clock network, and, the “ideal” clock network latency constraints are only
op
intended for pre-CTS estimates.

If a clock does not have a set_clock_latency constraint pre-CTS, automatic latency update will apply a
new network latency constraint on that clock.
yn
You can run clock latency update by itself with the following atomic command:
rS
icc2_shell> compute_clock_latency
Fo
Mode:Mode1WC Latency(early) Latency(late)

Clock Updated rise fall rise fall Corner
------------------------------------------------------------
ed
SYS_2x_CLK Yes 0.8391 0.8391 0.8391 0.8391 Corner1WC

SYS_CLK Yes 0.8520 0.8321 0.8520 0.8321 Corner1WC
ate_clk Yes 0.8538 0.8571 0.8538 0.8571 Corner1WC
er
st
Mode:Mode1BC Latency(early) Latency(late)

Clock Updated rise fall rise fall Corner
i
------------------------------------------------------------
eg
SYS_2x_CLK Yes 0.3128 0.3128 0.3128 0.3128 Corner1BC

SYS_CLK Yes 0.3209 0.3336 0.3209 0.3336 Corner1BC
R

Post-CTS: Update Latencies in ALL Scenarios
 Only clocks in active scenarios are propagated and get updated latencies
y
 If not all scenarios were active during CTS, explicitly update clock
nl
network latencies in all scenarios immediately after CTS
O
 This also makes any non-propagated clock sources propagated
se
clock_opt
U
compute_clock_latency
al
rn
# To make clocks propagated without latency updating:
# synthesize_clock_trees -propagate_only
te
In
s 7- 44
sy
Note: The atomic command synthesize_clock_trees –propagate_only will only apply
set_propagated_clock constraints to clock sources with an ideal network latency constraint,
set_clock_latency. On the other hand, compute_clock_latency will first apply a new network
op
latency constraints on clocks without a set_clock_latency, and will then also propagate their clock
sources.
yn
You can ensure that the active scenarios are the same before and after propagating the clocks using the
rS
following code:
clock_opt
set CTS_SCN [get_scenarios -filter active]
Fo

compute_clock_latency
set_scenario_status -active false [all_scenarios]
ed
set_scenario_status -active true $CTS_SCN

er
i st
eg
R

CAUTION: Propagated Clock Objects

Some users explicitly propagate “all_clocks” post-CTS
set_propagated_clock [all_clocks]
y
nl
This causes I/O clock latencies to become 0, which
can cause missed or false timing violations!
O
se
U
D Q D Q D Q
IN1
0.0 FF FF FF
CLK
al
CLK CLK
0.0
(propagated) 0.92 (propagated)
CLOCK
rn
(propagated)
te
See Appendix B for two ways to address this!
In
s 7- 45
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Auto-Update with Virtual Clocks

Pre-CTS
Latencies can also be updated create_clock –p 4 –n V_CLK
set_clock_latency 1.0 V_CLK
for I/Os constrained with set_input_delay –clock V_CLK –max 2.2 IN1
y
virtual clocks, if a related 1.0 D Q D Q
nl
FF IN1 FF
CLK CLK
reference clock is defined create_clock –p 4 –n CLK CLOCK

set_clock_latency 1.0 CLK CLOCK
(ideal) 1.0 D
FF
CLK
Q
O
1.0
(ideal)
se
current_mode $mode
U
set_latency_adjustment_options \
–reference_clock CLK \ Updated
-clocks_to_update V_CLK automatically!
al
create_clock –p 4 –n V_CLK
} set_clock_latency 0.92 V_CLK
clock_opt set_input_delay –clock V_CLK –max 2.2 IN1
rn
D
0.92 Q IN1
D
FF
Q
FF CLK
CLK
create_clock –p 4 –n CLK CLOCK (ideal) 0.90 D Q
te
FF
CLOCK CLK
set_clock_latency 0.92 CLK
0.94
(propagated)
In
s 7- 46
sy
By default, the compute_clock_latency command will copy the network latency of the specified
reference_clock to the network latency of the clocks_to_update. If the early and late latency of the
op
reference clock are different because of on chip variation (OCV), then the applied early and late latencies
will also be different.
yn
When -ocv_included is specified, it will be assumed the OCV for the clocks_to_update will
already be accounted for in the clocks’ source latency, and that you don’t want to apply extra OCV in the
rS
network latency. When -ocv_included is specified, the compute_clock_latency command will

apply the single average of the early and late network latencies of the reference clock to the
Fo
clocks_to_update.
ed
er
i st
eg
R

Limiting Auto-Latency Update
 clock_opt always performs latency update
y
 Occurs during the route_clock phase
nl
 Stand-alone command: compute_clock_latency
O
 You can configure I/O latency updates using
set_latency_adjustment_options
se
 By default, all I/Os are updated
U
al
 To disable automatic latency updates for some or for all clocks:
rn
set_latency_adjustment_options –exclude_clocks "CLK1 CLK2 …"
te
In
s 7- 47
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Running CTS
y
nl
Analysis
O
se
U
al
rn
te
In
s 7- 48
sy
op
yn
rS
Fo
ed
er
i st
eg
R


place_opt w/o CCD
Upsized 4 data cells
y
 CCD during place_opt targets
nl
leakage and total power reduction
O
 Some improvement in timing QoR may be seen
se
 Timing violations that can be easily fixed place_opt w/ CCD
U
by skewing the clock can reduce data path Upsized 1 clock cell
(during CTS update)
optimizations, which saves data path power
al
rn
te
In
s 7- 49
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Ideal Clock Adjustment during place_opt
place_opt w/ CCD
 To improve the timing QoR, useful skew
computation adjusts the ideal clock latencies
y
to the sinks
nl
 Datapath optimization during place_opt is based
O
on these annotated latency adjustments
Latency
Requires users to annotate estimated clock latencies
se

annotation
(set_clock_latency) on ICG and macro clock
pins for realistic useful skew computations
U
The clock latency adjustments are stored as clock balance points
al

on clock pins, to be implemented by CTS
rn
 Balance points are scenario-specific
te
 Ensure that the scenarios used during place_opt are not removed/made inactive
during clock_opt
In
s 7- 50
sy
CCD calculates how much useful skew is beneficial to datapath timing and annotates “latency adjustments”
(set_clock_latency) on the clock pins. Datapath optimization during place_opt is based on these
annotated clock pin latency adjustments. No actual clock tree changes take place when place_opt is run
op
with ideal clocks, which is the default behavior.

yn
rS
Fo
ed
er
i st
eg
R

place_opt CCD with Trial CTS
initial_place
y
 If trial-CTS is performed during place_opt,
initial_drc • Trial CTS
nl
a CTS update step implements the useful
• Critical ICGs identified
skews during final_opto
O
initial_opto • Timing-aware splitting
• CTS update
se
• Clock-aware placement
final_place
 Timing analysis, optimization and useful skew • CTS update
computation are based on propagated clocks final_opto • Useful skew
U
computation based on
 Latency annotation on ICGs/Macros not required propagated clocks
al
• CTS update with useful
rn
skew computed
 Trial CTS during place_opt can be performed balance points
te
stand-alone or together with ICG optimization
In
s 7- 51
sy
Useful skew computations are performed multiple times during place_opt final_opto. Each useful skew
computation step adjusts the clock latencies to the sinks to improve the timing QoR (performed only once
during clock_opt build_clock). Subsequent data optimizations work on this improved timing QoR.
op
The clock tree is updated during final_opto to implement the skew offsets from useful skew computation.
yn
ICG optimization during place_opt is enabled using place_opt.flow.optimize_icgs.

rS
Stand-alone Trial CTS is enabled using place_opt.flow.trial_clock_tree.

Fo
ed
er
i st
eg
R

Enabling and Controlling place_opt CCD
 Enable CCD during place_opt:
y
place_opt.flow.enable_ccd Default: false
nl
O
 Control the amount of skewing:
se
place_opt.flow.enable_ccd_useful_skew_max_postpone Default: 100ps
U
place_opt.flow.enable_ccd_useful_skew_max_prepone Default: 300ps
al
 Other CCD app options, like ccd.optimize_boundary_timing,
rn
ccd.skip_path_groups etc. are also honored by place_opt CCD
te
 Apply before running place_opt, if required
In
s 7- 52
sy
op
yn
rS
Fo
ed
er
i st
eg
R

y
nl
 Execute the “classic” CTS and optimization flow, or the
O
concurrent clock-and-data (CCD) flow
 Report and analyze results
se
 Control post-CTS I/O auto-latency update
U
al
rn
Begin “Lab 7: Running CTS”
te
In
s 7- 53
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix
y
nl
O
A - CCD operation during build_clock and final_opto
B - Post-CTS Propagated Clock Objects
se
U
al
rn
te
In
s 7- 54
sy
op
yn
rS
Fo
ed
er
i st
eg
R

CCD: Timing-Driven Clock Tree Creation

Classic CTS: Proximity-driven CCD: Timing-driven
CK CK
y
nl
Latency 50ps
50 50
O
100ps L
50ps 100 100
se
150ps
C
L C 150 150
U
Critical Path
al
 Group related flip-flops based on their timing instead of their
physical location
rn
 Targets to improve design WNS and TNS
te
 Performs multi-stage slack borrowing
In
s 7- 55
sy
A timing driven clock tree topology solution uses a correct by construction approach.
With budgeted useful skew during CTS, it is easier to tap sinks early, because they can be constructed that
op
way during CTS itself. As shown here, by having the launch and capture flops skewed by 50ps, the timing
on the critical path is addressed right when the tree is built.
yn
rS
Fo
ed
er
i st
eg
R

CCD: Clock Tree Latency Refinement
CK CK
y
nl
Latency 50ps
50 50
O
100ps 55 55
20ps
50ps Critical Time
Path
95 100 Borrowing 100
se
150ps 115
+20ps 0ps
150 150 150 150
U
al
 Improves timing by adjusting the latencies on the existing clock tree
rn
 Performs multi-stage slack borrowing
Clock latency adjustment performed through buffer addition, removal,
te

re-parenting and sizing
In
s 7- 56
sy
This approach is also used to modify ICG depth in the clock tree to improve timing on failing enable paths.
op
yn
rS
Fo
ed
er
i st
eg
R

CAUTION: Propagated Clock Objects

Some users explicitly propagate “all_clocks” post-CTS
y
nl
This can cause missed or false timing violations!
O
I/O reference clocks become propagated, but there are no actual
clock paths  Calculated I/O clock latencies become 0!
se
U
Post-CTS: Propagated clock objects The “absolute” arrival time of
set_input_delay –clock CLK –max 2.2 IN1 the input becomes 2.2ns!
al
create_clock –p 4 –n CLK CLOCK D Q D Q
set_clock_latency 1.0 CLK 0.0 FF IN1 FF
set_propagated_clock \
rn
CLK CLK
[get_clocks CLK] (propagated) 0.92

CLOCK
te
I/O network latency (propagated)
becomes propagated and 0!
In
s 7- 57
sy
Note that “set_propagated_clock [all_clocks]” is s mode-specific (applies to the current mode
only). Make sure you apply this in all modes:
op
current_mode $mode
yn
}
rS
With the [all_clocks] argument the command is applied to all clock objects. Since I/O delay constraints
reference clock objects (through their –clock option), the clock latency for the “external I/O registers” also
becomes propagated. For propagated clock networks, ICC II ignores the clock network latency constraint.
Fo
The actual propagation delay through the synthesized clock tree is calculated to determine the clock network
latency. Since there is no synthesized clock network for the I/O’s, the clock latency of the I/O’s becomes
ed
zero! This can lead to missed or false timing violations! There are a couple of different ways to constrain the
I/O’s from the start of the design cycle, with this issue in mind, such that the problem can be avoided – see
er
next pages.
i st
eg
R

Solutions: Propagated Clock Objects
 If possible, remove set_propagated_clock [all_clocks] and rely

on ICC II’s automatic application of set_propagated_clock
y
on clock sources:
nl
O
synthesize_clock_trees –propagate_only
se
U
 If the above is not an option, use one of the two methods on the next
al
pages to constrain your I/O’s such that they are independent of
propagated I/O latencies
rn
te
In
s 7- 58
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Independent I/O Clock Latencies (1 of 2)

 I/O’s can be constrained in one of two ways to ensure that I/O clock
latencies are always correctly taken into account, independent of how
set_propagated_clock is applied:
y
1) Use independent virtual clocks for the I/O’s, with their own latencies
nl
 Virtual clocks remain ideal so their network latencies are determined by their
O
set_clock_latency constraints
se
create_clock –period 4 –name CLK [get_ports CLOCK]
set_clock_latency –max 1.0 [get_clocks CLK]
create_clock –period 4 –name V_CLK
U
set_clock_latency –max 1.0 [get_clocks V_CLK]
set_input_delay –clock V_CLK –max 2.2 [get_ports IN1]
al
MY_DESIGN
rn
I/O virtual clock remains ideal after clock_opt IN1
D Q D Q
1.0 FF FF
te
CLK CLK
(ideal) 0.92
In
CLOCK
(propagated)
s 7- 59
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Independent I/O Clock Latencies (2 of 2)

2) Include the clock network latency in the I/O data path delay
 Example: Instead of doing this …
y
create_clock –period 4 [get_ports CLK]
nl
O
se
 … account for I/O clock network latency by including it in the “data” delay time, and
using –network_latency_included:
U
create_clock –period 4 [get_ports CLOCK] The pre- and post-CTS
“absolute” arrival time of
al
set_clock_latency –max 1.0 [get_clocks CLK] the input data is 3.2ns
rn
set_input_delay –clock CLK –max 3.2 \
-network_latency_included [get_ports IN1]
te
 The –network_latency_included option ensures that the I/O data arrival times
In
are the same for ideal or propagated clocks s 7- 60
sy
When the -network_latency_included option is used with set_input/output_delay, timing analysis
assumes that the network latency for the clock of the register driving/capturing the data on the input/output
op
port, respectively, is zero. This option assumes that the user has “included” the effect of the network latency
in the data arrival/required time at the input/output port, by adjusting the -max/-min delay numbers
accordingly.
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
8 Setting Up CTS
O
se
U
al
11
rn
Signoff
te
In
s 8- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Setting Up CTS © 2019 Synopsys, Inc. All Rights Reserved. 8-1


Synthesis
y
nl
O
se
U
CTS & Optimization This Unit
al
rn
te
Signoff
In
s 8- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Unit Objectives
y
nl
O
 Set up clock tree balancing constraints
se
 Handle pre-existing clock tree elements
Specify non-default rules (NDRs) for clock tree routing
U

 Specify timing and DRC constraints
al
rn
te
In
s 8- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Tree Balancing

• Sink and Ignore Pins
• Clock Tree Skew and Latency Targets
y
• Controlling CTS Cell Selection
nl
• Inter-Clock-Tree Balancing
O
Pre-existing Clock Elements
se
U
Non-Default Routing Rules
al
rn
Timing and DRC Constraints
te
In
s 8- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Where Does the Clock Tree Begin and End?
D Q
y
FF
GATED CLK
nl
O
D Q
FF
CLOCK CLK
se
Start D
FF
Q
End
U
CLK
al
Clock trees start at their Synthesizable clock
“source” defined by trees end (by default)
rn
on clock pins of
create_clock … registers or macros
te
In
s 8- 5
sy
To see the source(s) of a clock, you can either run report_clocks, or use the sources attribute:
icc2_shell> get_attribute [get_clocks PCI_CLK] sources
{pclk}
op
yn
rS
Fo
ed
er
i st
eg
R

Balance Points: Sink and Ignore Pins

skew and insertion
delay are optimized
Implicit Sink pins
Sink Pins:
D Q
y
FF
GATED CLK
CTS optimizes for DRC and clock
nl

tree targets (skew, insertion delay) D Q
O
FF
 Optionally, can consider internal CLOCK CLK
insertion delay
se
IP_CLK
D Q
FF
U
CLKn
 Ignore Pins: Guide buffer IP
al
 CTS ignores skew and insertion
skew and insertion
delay targets
rn
delay are ignored D Q
 CTS inserts a guide buffer FF
CLK
te
 Only DRCs fixed after guide buffer
Implicit Ignore pins CLK_OUT
In
s 8- 6
sy
Implicit sink pins are automatically defined by CTS on:
- Clock pins of sequential cells (FFs and latches)
op
- Clock pins of macros

Implicit ignore (or exclude) pins are automatically defined by CTS on:
- Non-clock input pins of sequential cells (D, Set, Reset, etc)
yn
- output ports (if unconstrained – if the port is constrained by set_output_delay, the port will be marked
as data, and not marked as an implicit ignore pin)
rS
- Pins of combinational cells or integrated clock-gating cells that do not have any fanout or that do not
have any enabled timing arcs
Fo
- Pins with 3-state enable arc

- Select/Control pin of mux used in the data path
- Input pin of pre-existing gate, if all pins in its fanout are exclude pins
ed
- Incorrectly defined clock pins (missing or incorrect pin definition in the standard cell or macro cell
definition)
er
-Clock pins without trigger edge info

-Clock pins without a timing arc to the corresponding output pin
st
- Buffer or inverter input pins that are held constant (by using set_case_analysis)
i
eg
R

Generated and Gated Clocks

D Q
GATED 0.64 FF1

CLK
CLK
ICG
Insertion delays are
D Q
closely matched as
y
0.65 FF2
all sink pins are
nl
CLK
optimized for skew
create_clock D Q
O
FF3
CLK
CLOCK
se
D Q 0.63
FFD D Q
FF4
U
Intermediate ICG and CLK QN
CLK
divider FF CLK pins are not

considered for skew balancing
al
D Q
FF5
CLK
rn
create_generated_clock
Master and generated clocks are part of the same clock domain.
te
Skew is balanced globally (across all clock pins) within each clock domain.
In
s 8- 7
sy
create_clock –p 10 [get_ports CLOCK]
create_generated_clock [get_pins {FFD/Q}] \
–source [get_ports CLOCK] –name DIV_CLK –divide_by 2
op
By default, CTS will not balance the skew of FFs that cross clock domains; generated clocks are considered a
yn
part of the master clock domain.

By default, CTS will balance the skew ‘globally’ per clock. This means that the skew of all sequential
rS
devices in the same clock domain, related or not, will be balanced. Two sequential devices are related if there
is a data path connection between them.
Fo
Added CTS buffers will have the prefix name "CT_BUF_####" by default.
ed
Can modify this with

cts.common.user_instance_name_prefix
opt.common.user_instance_name_prefix (applies to place_opt, clock_opt, route_opt,
er
create_buffer_trees, and remove_buffer_trees)

i st
eg
R

User-defined or Explicit Sink Pins

CLOCK D Q
FF3
CLK
Scenario: If a macro cell
y
clock pin is correctly defined, skew and
nl
insertion
CTS will treat that pin as an delay are
O
implicit sink pin. In this ignored
example the clock pin is not
se
correctly defined.
What will CTS do?
?
IP_CLK
U
D Q
FF
CLKn
Implicit ignore pin
al
no clock pin
rn
definition
The macro’s clock pin is marked
IP
te
as an implicit ignore pin –
no skew optimization!
In
s 8- 8
sy
Typically the clock port of a macro cell is treated as sink pin with internal clock tree delay information. CTS
uses the internal clock tree delay to decide how much more insertion delay it needs to add outside the macro
op
cell during CTS, to meet the skew and insertion delay targets with respect to the rest of the stop pins outside
the macro cell. If there is no internal clock tree, the macro’s clock pin is treated as a stop pin (0 ns internal
latency).
yn
When a clock pin is not defined as a clock, or is incorrectly defined, CTS does not have enough information
to optimize it for skew and insertion delay. This forces CTS to assign it an implicit exclude pin, which will be
rS
isolated by a single buffer.

Incorrectly defined clock pins (missing or incorrect pin definition in the standard cell or macro):
Fo
-Clock pins without trigger edge info

-Clock pins without a timing arc to the corresponding output pin
ed
er
i st
eg
R

Defining an Explicit Sink Pin

CLOCK D Q
FF
0.42 CLK
y
Defining an explicit sink pin skew and insertion delay
nl
0.43 are now optimized
allows CTS to optimize for skew
O
and insertion delay targets.
se
IP_CLK D Q
FF
CLKn
U
Explicit sink pin defined
CTS has no knowledge of the
al
IP-internal clock delay – it can
only “see” up to the sink pin!
IP
rn
set_clock_balance_points \
te
-consider_for_balancing true \
-balance_points [get_pins IP/IP_CLK]
In
s 8- 9
sy
In the above example, CTS is doing the right thing – balancing the insertion delays up to all stop pins. CTS
doesn’t know that internal to the IP, there is a 0.15 delay to the actual clock pins of the flip flops.
op
If you have an extracted timing model and you want to report the internal delay of a clock pin, use the
following command:
yn
report_clock_qor -type latency -show_paths -to i_core/i_etm/clk

In the report, the clock path delay inside the ETM will be reported as
rS
lib cell clock balancing offset

Fo
ed
er
i st
eg
R

Defining an Explicit Sink Pin With Delay

CLOCK D Q
FF
0.42 CLK
y
Defining an explicit sink pin with delay skew and insertion delay
nl
are now optimized
allows CTS to adjust the insertion 0.28
delays based on the specification.
O
se
IP_CLK
U
D Q
FF
Explicit delay balance point 0.15 CLKn
al
0.13 D Q
rn
FF
CLKn
IP
te
-corner ss125c \
-delay 0.15 -late \
In
-balance_points IP/IP_CLK
s 8- 10
sy
To complete the above specification, you need to add an early definition:
op
-corner ss125c \
-delay 0.13 –early \
yn
-balance_points IP/IP_CLK
rS
This balance point constraint (with -delay) can be used to manipulate the placement of the macro - i.e.
move closer to or farther away from the clock root. If a macro has internal clock delays, the balance point
delay values override the macro model's values.
Fo
ed
er
i st
eg
R

Defining an Explicit Ignore (or Exclude) Pin
Explicit ignore pins cause CTS to
y
ignore this pin and down-stream D Q
nl
FF1
sinks for skew balancing. CLK
O
CLOCK
D Q
FF2
se
CLK
A
U
B
Guide buffer AN2
-clock CLOCK \
-consider_for_balancing false \ Explicit ignore
al
-balance_points [get_pins AN2/A] pin defined on
pin AN2/A
rn
 CTS inserts a guide buffer; CTS engine fixes
te
DRCs only along the clock path past ignore pins.
In
s 8- 11
sy
If an explicit ignore is defined on clock pins or on pins leading to clock pins, then CTS will perform DRC
fixing based on CTS DRC settings.
op
To remove the balance point definition:

remove_clock_balance_points -clock CLOCK -balance_points [get_pins AN2/A]
yn
rS
Fo
ed
er
i st
eg
R

Defining a Clock Skew Group
D Q
FF1
CLK
y
CLOCK
D Q
nl
FF2
CLK
Define a clock skew group if you want to
O
balance a group of clock pins independently D
FFx
Q
from the rest of the clock tree.
se
CLK
U
The target skew will be the same as the master clock of D Q
this skew group. You cannot set the skew independently. FFy
al
CLK
rn
create_clock_skew_group -mode TEST –objects {FF1/CLK FF2/CLK}
te
In
s 8- 12
sy
There is no independent control over the skew group’s target skew and latency.
op
In the example above, if FF2 and FFx are a reg-ro-reg pair, and local skew is enabled, the skew group takes
priority. In other words, local skew optimization will work on critical endpoints within a skew group - it will
not work across skew groups.
yn
The report_clock_qor/report_clock_timing commands will report skew of skew group separately

rS
from others. The create_clock_skew_group command gives the skew group a default unique name,
which shows up in the report(s), unless you use the -name option to specify a name.
Fo
ed
er
i st
eg
R

Exceptions – Mode Specific

 Clock tree exceptions apply to the current mode
 To apply exceptions to multiple modes:
y
foreach mode {m1 m2} {
nl
current_mode $mode
O
-clock CLOCK \
-consider_for_balancing false \
se
-balance_points [get_pins AN2/A]
}
U
report_clock_balance_points
al
 Sink exceptions can be made corner-specific *
rn
-... \
te
-corners {c2}
Exceptions apply to all corners if -corners not specified
In

s 8- 13
sy
You cannot make an explicit ignore exception corner-specific!
Error: Cannot specify '-corners' with '-consider_for_balancing false'. (CMD-001)
op
yn
rS
Fo
ed
er
i st
eg
R

Auto Exceptions
 CTS can automatically resolve clock tree balancing conflicts
 Case 1: Conflict between 2 clocks due to missing generated clock
Auto-exception: Derive exclude exception for the clock with missing generated clock
y
nl
 Case 2: Internal sink pins of a cell with clock output pins
O
Auto-exception: Derive exclude exception on the internal sink pins
se
 Case 3: Huge ETM internal skew coming from max_clock_tree_path
and min_clock_tree_path
U
Auto-exception: Derive balance point with max delay at the ETM input pin
al
rn
Unfixable
balance large skew
exclude
te
exclude clkb
clk
ETM
In
Case 1 Case 2
s Case 3 8- 14
sy
Case 1 details
The ignore is put on the clock pin of the divider flop only for the clock with missing generated clock. Since
the mux provides both clka and clkb at the divider flop, both clocks need a generated clock. In the
op
example from the slide, the ignore exception is set only for clkb; clka can still trace through and reach the
downstream flops driven by the Q of the divider flop.
yn
The FF1_1-10 flops are still considered for balancing for clka clock.
rS
Case 2 details
The internal pin in the cell is a sink for CTS, and as such must be balanced with all other sink pins of that
Fo
clock. The outgoing clock path will be driving more sinks at the top level. So the sink inside the cell will
most likely end up as shortest path and CTS will not be able to optimize this path which ends inside the cell.
In this case setting an ignore on the internal sink will enable CTS to go ahead and optimize the skew between
ed
the other flops.

er
Case 3 note:
Auto-exception uses the max_clock_tree_path delay number. If there is a concern that using this max
st
number may be too large, which may force the latencies of all other branches to be increased to match the
ETM’s latency, you need to use the set_clock_balance_points command yourself and specify the min
i
eg
ETM latency as the -late value.

R

Controlling Auto Exceptions
 Auto-exceptions are added automatically during

clock_opt or synthesize_clock_trees
y
nl
cts.common.enable_auto_exceptions Default: true
O
se
 Automatic clock tree balance points for macros with large
U
internal skew is enabled by default:
al
cts.common.auto_exception_macro_balance_point Default: true
rn
te
In
s 8- 15
sy
cts.common.auto_exception_macro_balance_point
Controls whether the synthesize_clock_trees or clock_opt commands set balance points
op
for macros with large internal skew. This balance point is created with an offset equal to the largest
latency inside the macro.
yn
rS
Fo
ed
er
i st
eg
R

Auto Exceptions: Scaling Delay Requirements
 ICC II can scale a user-applied “explicit sink pin with delay” across
corners that are missing values (only to those corners)
y
You supply the delay value in corner A only
nl

 ICC II can scale that value and apply to corners B and C
O
se
 Scaling is calculated using the initial clock tree (prior to clock tree
optimization)
U
al
 You need to make sure that you specify the value in the timing critical
rn
corner – this corner is used to build the initial clock tree
te
 Alternatively, define the primary corner using cts.compile.primary_corner
In
s 8- 16
sy
When you run CTS, you will see a line in your log similar to the following:
Primary corner ss_125c
This indicates that the ss_125c corner will be used to build the initial clock tree.
op
For auto-scaling to work, you need to define the exception in one corner, for example:
yn
set_clock_balance_points -consider_for_balancing true -corner ss_125c \

-delay -0.5 -balance_points [get_pins REG_FILE_D_RAM/CE2]
rS
During the build_clock stage, you will see the following log output:
Fo
Information: Balance point auto scaling set on term 'REG_FILE_D_RAM/CE2' clock 'SYS_2x_CLK' corner
'ff_125c' early rise -0.14761 early fall -0.14761 late rise -0.14761 late fall -0.14761. (CTS-040)
Information: Balance point auto scaling set on term 'REG_FILE_D_RAM/CE2' clock 'SYS_2x_CLK' corner
'ff_m40c' early rise -0.12505 early fall -0.12505 late rise -0.12505 late fall -0.12505. (CTS-040)
ed
er
i st
eg
R

How Can You Check Exceptions?
 The following command reports exceptions, including auto-exceptions:
y
nl
O
 Log messages will indicate auto exceptions if you set the following
se
application option:
U
set_app_options –list {cts.common.verbose 1}
al
 A file is created that contains the auto exceptions:
rn
clock_auto_exceptions_*.tcl
te
In
s 8- 17
sy
Here is an example of what you might see in the log file:
Start Auto-Exception Derivations...
Collected 4 internal pin(s) for explicit ignored pin settings.
op
Collected 2 loop breaking pin(s) for explicit ignored pin settings.

No conflict pin was found.
yn
And here is an example of the clock_auto_exceptions_*.tcl file:

# loop breaking pins
rS
set_clock_tree_balance_point -consider_for_balancing false

-clock [get_clock -mode func DIV_CLK] -balance_points some/mux/D0
set_clock_tree_balance_point -consider_for_balancing false
Fo
-clock [get_clock -mode func REF_CLK] -balance_points other/mux/D0

ed
er
i st
eg
R

Default Clock Tree Targets
 The default target skew and target latency is 0 ns

 SDC uncertainty and network latency constraints are ignored
y
 Relax clock skew targets for non-timing critical clocks
nl
 Reduces overall buffer count, power and run time
O
 Specify network latency targets to help post-CTS timing (see below)
se
 An alternative method using automatically-derived balance points will also be shown
U
Ideal Propagated
network latencies Slack = 0.0ns network latencies Slack = -0.4ns
al
D Q D Q D Q D Q
CLK1
1.4ns FF1 FF2 CLK1
1.4ns FF1 FF2
rn
CK CK CK CK
CLK2 CLK2
2.4ns 2.0ns
te
Pre-CTS, FF1FF2 path relies on the 1.0ns Post-CTS latency difference is only 0.6ns,
latency difference to meet timing causing the FF1FF2 path to violate timing
In
s 8- 18
sy
In the example above, pre-CTS optimization (synthesis, and place_opt with ideal clocks) relies on the
1.0ns total latency difference between CLK1 and CLK2 (2.4 - 1.4) to meet timing for FF1FF2 (0ns slack).
op
CTS, which tries to reduce latency as much as possible, is able to achieve a propagated network latency of
2.0ns to for CLK2 (while the propagated latency for CLK1 remains 1.4ns). This causes a 0.4ns timing
yn
violation from FF1FF2, which post-CTS optimization is not be able to fix. In this example, data path
timing relies on specific pre-CTS clock latency differences, therefore clock network latency targets of 1.4ns
rS
and 2.4ns should be applied to CLK1 and CLK2, respectively, prior to CTS.
Fo
ed
er
i st
eg
R

CCD: Skew and Latency Considerations
 For the classic CTS flow, it is important to specify accurate

skew and latency targets
y
For the CCD flow:
nl

 Target skew is not relevant, because the goal is to intentionally
O
introduce skew to meet timing
Target latency can be applied if needed (for chip-level inter-block
se

timing considerations, for example), but keep in mind that the final
latencies have larger skews compared to classic CTS
U
al
Target Latency
rn
te
In
Latencies after classic CTS Latencies after CCD
s 8- 19
sy
If you want to exclude the boundary registers from being latency-adjusted, use the
ccd.optimize_boundary_timing application option, which we discussed in the previous unit.
op
yn
rS
Fo
ed
er
i st
eg
R

User-Defined Clock Tree Targets

remove_clock_tree_options –all -target_skew -target_latency
set_clock_tree_options -target_skew 0.2 –corners [all_corners]
 max skew target of 0.2 applied to all corners, all clocks, all modes
y
nl
current_corner C1
set_clock_tree_options -target_skew 0.1
O
 max skew target of 0.1 applied in C1, all clocks, all modes
set_clock_tree_options -clocks CLK1 -target_latency 1.4
se
set_clock_tree_options -clocks CLK2 -target_latency 2.4
 latency target of 1.4 applied in C1, to CLK1 in current mode
U
 latency target of 2.4 applied in C1, to CLK2 in current mode
al
report_clock_tree_options
rn
D Q D Q
Targets apply to:
te
Pre-CTS ideal CLK1 1.4ns FF1 FF2 • All clocks if no clock is specified
latencies to be
converted into
CK CK
• Current corner if no corner is specified
In
target latencies • Current mode if clock is specified, otherwise all modes
CLK2 2.4ns
s 8- 20
sy
Apply global targets before applying specific targets!
Note: The value specified for the -target_latency option of set_clock_tree_options should match
op
the pre-CTS ideal network latency value. Do not include the ideal source latency amount (if also defined).
yn
rS
Fo
ed
er
i st
eg
R

Automatically-Derived Balance Points
 Automatically-derived clock balance points can also be used to account for

network latency differences - easier than user-specified clock latency targets
y
nl
icc2_shell> current_scenario FUNC.C1
icc2_shell> set_clock_latency 1.4 [get_clock CLK1]
O
icc2_shell> derive_clock_balance_points -reference_latency 0.0
se
Created balance points for all sinks of CLK1 and CLK2 (only FF1 and FF2 sinks shown):
set_clock_balance_point -delay -1.4 -corner C1 -balance_points FF1/CK -clock CLK1
U
set_clock_balance_point -delay -2.4 -corner C1 -balance_points FF2/CK -clock CLK2
al
Pre-CTS ideal Post-CTS propagated
rn
network latencies Slack = 0.0ns network latencies Slack = 0ns
D Q D Q D Q D Q
1.4ns 1.4ns
te
CLK1 FF1 FF2 CLK1 FF1 FF2
CK CK CK CK
In
CLK2 CLK2
2.4ns s 2.4ns 8- 21
sy
The derive_clock_balance_points command creates set_clock_balance_point constraints based on the ideal
latencies specified by set_clock_latency. The command uses a reference latency per clock. The default reference
latency is the sum of the source- and network-latency specified for the clock. To derive the balance point delay value,
op
the ideal mode total clock latency at a sink is subtracted from the reference latency. In the common situation where
set_clock_latency is defined only at the clock objects (and not at clock sinks), the default reference latency will
yn
match the ideal total latency at all sinks. In that case all -delay values will be 0.0. As a consequence, no balance point
constraints will be generated. If a selected number of sinks have a total ideal latency that differs from the reference
latency, then only for those sinks, clock balance point constraints will be generated. Examples (assume
rS
current_scenario = FUNC.C1):
The following creates no balance point constraints, since the reference latency equals the total sink latency for both
Fo
clocks:
icc2_shell> derive_clock_balance_points
ed
The following example creates one balance point constraint (source latency is included in this example):
icc2_shell> set_clock_latency -source 0.8 [get_clock CLK1]
er
icc2_shell> set_clock_latency 1.9 [get_pin FF1/CK] (overrides the network latency for this sink only)
icc2_shell> derive_clock_balance_points
st
Created balance point (delay value = [reference latency] – [total ideal sink latency] = [0.8+1.4] – [0.8+1.9] = -0.5):
set_clock_balance_point -delay -0.5 -corner C1 -balance_points [get_pin FF1/CK] -clock CLK1
i
eg
Overriding the default –reference_latency with a value of 0.0, ensures that balance point constraints are always
created.
R

icc2_shell> derive_clock_balance_points -reference_latency 0.0
Creates clock balance points for all CLK1 sinks with a delay of: 0 – 1.4 = -1.4ns;
Creates clock balance points for all CLK2 sinks with a delay of: 0 – 2.4 = -2.4ns:
set_clock_balance_point -delay -1.4 -corner C1 -balance_points <all_CLK1_sinks> -clock CLK1
set_clock_balance_point -delay -2.4 -corner C1 -balance_points <all_CLK2_sinks> -clock CLK2

Control CTS Cell Selection

 In the following example, only $cts_libcells are used to build the
clock trees. Modify as needed:
y
set cts_libcells [get_lib_cells \
nl
"*/INVX*_LVT */BUFX8_LVT */BUFX16_LVT \
*/MUX*LVT */AO* */CG* */FF*"]
O
set_lib_cell_purpose -exclude cts [get_lib_cells]
se
set_lib_cell_purpose -include cts $cts_libcells
set_dont_touch $cts_libcells false
U
 In addition to buffers/inverters, include logically equivalent cells of any gates
al
(MUX, AND, ICG, etc.) and FlipFlops*1 in the clock tree
rn
 Allows these to be resized, if needed
 Always-on buffers should be added, to allow always-on CTS for MV designs
te
 If a clock branch needs to feed through a shut-down voltage area, always-on CTS
In
inserts AO buffers – otherwise, must go around it
s 8- 22
sy
MV = Multi-Voltage
*1 ForCCD, it is important to add flipflops to the list as well, since CCD can resize FFs for skew adjustment.
op
This is not necessary for classic CTS, but it doesn’t hurt. Therefore the recommendation is to always add the
FFs.
yn
If library cells have the dont_touch attribute set on them, they are not used by clock tree synthesis even if
rS
you specify them as clock tree references with the set_lib_cell_purpose command. You must ensure
that the library cells specified as clock tree references do not have the dont_touch attribute.
Fo
If you have CTS-only cells in your library (to be used exclusively by CTS), use the following:
set_lib_cell_purpose -exclude cts [get_lib_cells]
set_lib_cell_purpose -include none $cts_libcells
ed
set_lib_cell_purpose -include cts $cts_libcells

set_dont_touch $cts_libcells false
er
Cells on the clock tree that are not in $cts_libcells are not resized, unless they have a logically-
st
equivalent cell in the list (for example AND, OR gates, ICGs).

i
Recommendation: Include all references that are on your clock tree in the cts_libcells list!
eg
R

Existing Cells on Clock Tree
 You need to ensure that $cts_libcells includes LEQs of existing

cells and ICGs, otherwise no resizing takes place
y
nl
 To help with identifying existing clock cells, use
derive_clock_cell_references
O
se
set_lib_cell_purpose -include cts <buf/inv/ao/ff>
derive_clock_cell_references
–output cts_leq_set.tcl
U
al
 The identified LEQs will be listed in the file cts_leq_set.tcl
rn
 Tailor this file to your needs and apply
te
In
s 8- 23
sy
It is also possible to specify references to use on a clock by clock basis, for example:
set_clock_tree_reference_subset -clocks "CLK1" -lib_cells "*/BUF*_HVT"
op
Note that CTS will choose lib_cells from the intersection of set_lib_cell_purpose -include cts
<lib-cells> and set_clock_tree_reference_subset.
yn
rS
Fo
ed
er
i st
eg
R

No Inter-Clock Skew Balancing by Default
D Q
0.75
…
FF1
CLK
y
CLOCK1 D Q
nl
FF2
CLK
O
Synchronous
clocks
D Q
se
0.32 FF3
CLK
U
CLOCK2 D Q
FF4
CLK
al
rn
By default CTS does not perform inter-clock skew balancing
 May result in timing violations
te
In
s 8- 24
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Create Balancing Groups
 There are two ways to balance the clock groups:

 Manual balancing constraints:
y
nl
foreach mode {m1 m2} {
current_mode $mode
O
create_clock_balance_group –name grp1 \
–objects [get_clocks "CLOCK1 CLOCK2"]
}
se
Auto-derived balancing constraints:
U

derive_clock_balance_constraints -slack_less_than -0.3
al
report_clock_balance_groups
rn
 Constraints will be derived for all modes
te
 Only clocks with cross-clock paths meeting the -slack_less_than
In
specification will be selected
s 8- 25
sy
derive_clock_balance_constraints will apply/create the clock balance groups for all modes, based
on the current ideal timing (before CTS).
op
By creating a clock balance group, the clocks CLOCK1 and CLOCK2 will now be balanced with regard to
skew. In order to achieve this, the faster clock’s insertion delay will be increased until it matches the longer
yn
tree.
rS
Note: create_clock_skew_group cannot be specified across clock domains.

Fo
By default, any source latency defined on the clocks is ignored, i.e. not taken into account when balancing
the latencies of the respective clocks.
To change this, set the following application option to true (default is false, i.e. do not consider source
ed
latency):
cts.balance_groups.honor_source_latency
er
Instead of inserting buffers in the respective clock trees to balance the clocks, you can also choose to let ICC
st
II change/set the source latencies of the clocks. This is done by setting the following application option to
true (default is false, i.e. insert buffers):
i
eg
cts.balance_groups.balance_by_source_latency
R

Balancing Occurs During clock_opt
Balancing occurs during the build_clock stage
y
nl
D Q
0.75
…
FF1
O
CLK
CLOCK1 D Q
se
FF2
CLK
…
Buffers inserted at the
U
clock root to balance
insertion delays D Q
al
0.76 FF3
CLK
rn
CLOCK2 D Q
FF4
te
CLK
In
s 8- 26
sy
Balancing can also be run stand-alone using the command balance_clock_groups.
op
yn
rS
Fo
ed
er
i st
eg
R

Inter-clock Balancing is Important for CCD
 If inter-clock balancing is not enabled for the CCD flow,

CCD optimization will try to meet timing by skewing individual sinks
y
(instead of the root)
nl
 Much longer runtime
O
 Inserts many more buffers 0.75
D Q
…
FF1
se
CLK
CLOCK1 D Q
U
FF2
CLK
…
Without inter-clock
al
balancing, CCD
inserts buffers at the
rn
D Q
clock sinks 0.76 FF3

CLK
te
CLOCK2
…
D Q
FF4
In
CLK
s 8- 27
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Summary: Clock Tree Balancing Setup

# Define explicit sink and ignore pins:
set_clock_balance_points ...
y
# Specify target skews/latencies:
nl
set_clock_tree_options ...
O
# Control CTS cell selection:
set_lib_cell_purpose -include cts $cts_cells
se
set_dont_touch $cts_cells false
# OR
derive_clock_cell_references –output cts_leq_set.tcl
U
al
# Enable inter-clock balancing:
rn
create_clock_balance_group ...
# OR
te
derive_clock_balance_constraints -slack_less_than -0.3
In
clock_opt ...
s 8- 28
sy
op
yn
rS
Fo
ed
er
i st
eg
R

y
nl
O
• Removing and Preserving Pre-Existing
Cells on the Clock Tree
se
U
al
rn
te
In
s 8- 29
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Pre-Existing Clock Buffers Are Removed

Pre-existing clock buffers/inverters may
negatively affect CTS QoR
y
D Q
FF1
nl
By default, CTS removes pre-existing CLK
clock buffers/ inverters and builds a
O
0.52
balanced clock tree with fewer buffers! D Q
FFn
se
CLK
CLOCK
U
0.51 D Q
FFa
al
CLK
0.52
rn
D Q
FFb
CLK
te
cts.compile.remove_existing_clock_trees Default: true
In
s 8- 30
sy
If you need to preserve some clock trees and remove others, you need to set the above application options to
false, then remove the specific unwanted pre-existing clock tree(s) manually:
set_app_options -list {cts.compile.remove_existing_clock_trees false}
op
remove_clock_trees -clocks [get_clocks CLOCK1]

yn
By setting this application variable to false, CTS will not remove any remaining pre-existing clock tree
buffers/inverters, however, it can move them, size them, and insert additional buffers/inverters, in order to
rS
meet its clock tree skew and insertion delay targets.
To remove only those buffers and inverters inserted by ICC II, use the
Fo
-clock_repeaters_only option when you execute remove_clock_trees.
Note: If you run clock_opt -to build_clock or synthesize_clock_trees again on already-built

ed
clock trees, all clock buffers will be removed and built from scratch! However, any optimized clock network
gates (e.g. MUX, AND, ICG, FFs) will not revert to pre-CTS gates. So, if “re-doing” CTS you may want to
er
start from the placed design.

i st
eg
R

Preserving Pre-Existing Clock Trees

Pre-existing “un-balanced”clock tree –
D Q
required to remain “as-is” 0.73 FF1
A Y CLK
Disabling auto-removal of pre-existing clock
y
buffers/inverters is not enough: CTS can still
Custom logic
nl
move or size them, or insert buffers hand-built
D
FF2
Q
0.79 CLK
O
Set a dont_touch on the
network from the input pin
CLOCK
se
0.78 D Q
CTS leaves dont_touch clock sub-tree as-is FFa

CLK
U
Other branches try to match the largest
insertion delay in the clock domain 0.79 D Q
al
FFb
CLK
rn
set_dont_touch_network -clock_only [get_pins "buf/A"]
te
May create unnecessary additional buffers.
In
Reported global skew is only as good as pre-existing logic skew!
s 8- 31
sy
In the example above, assume that clock tree buffers were “manually” added to ensure that the FF2 insertion
delay is slightly larger than that of FF1. This was done to help meet the critical setup timing from FF1 to
FF2.
op
By default, clock tree synthesis removes any pre-existing clock tree buffers/inverters. While this automatic
yn
removal can be turned off (keeping the pre-existing buffers/inverters), this does not prevent CTS from
moving or sizing them, or from adding buffers/inverters to improve the skew between the 0.73ns and 0.79ns
rS
sinks. By applying a “dont_touch_network” attribute on the transitive fanout of the pre-existing clock
sub-tree, the pre-existing clock tree remains exactly as-is.
Fo
Since the pre-existing sub-tree has 6-7 levels of logic, the other branches will have to match that, which may
require additional buffers which may otherwise not have been needed if there were no per-existing buffers.
The insertion delays of the other branches will be optimized to match that of the longest path of the pre-
ed
existing sub-tree (0.79 ns).

er
Note: In the example above, the –clock_only option is needed. If the dont-touch is applied to a clock
object (get_clocks CLOCK) instead of a pin, then this option is not needed.
st
To remove the dont_touch_network attribute, use:

i
eg
set_dont_touch_network -clock_only [get_pins pin_name] –clear

To report all the dont_touch attributes set on a block, use:
R
report_dont_touch -all

Propagation Limitation of dont_touch on Clock Networks
 The dont_touch attribute will not propagate past flip-flops downstream

from the set_dont_touch_network point!
y
 If downstream propagation is desired, apply additional “dont_touches”:
nl
O
set_dont_touch [get_cells "DIVIDER_reg"]
set_dont_touch_network -clock_only [get_pins "DIVIDER_reg/Q"]
se
U
 Note that the following “dont_touch” propagates through the entire
transitive fanout of the specified clock(s):
al
rn
mark_clock_trees –dont_touch –clocks [get_clocks clk2]
te
 Note: mark_clock_trees can only be applied to an entire clock domain, not to a pin
In
s 8- 32
sy
Note that the dont_touch_network will propagate through ICGs.
mark_clock_trees
op
[-clock clock_list]
[-clear]
yn
[-dont_touch]
-clock clock_list
rS
Marks only the clock trees specified in clock_list. By default, the command marks for all currently
defined clocks in all active modes.
-clear
Fo
Removes the clock attributes on clock objects. If the "-dont_touch" option is specified, the
tool removes the dont_touch attribute on clock objects.
-dont_touch
ed
Sets dont_touch attribute on clock objects, including cells and nets in the clock trees.
er
i st
eg
R

Preserving Pre-Existing Cells
D Q
Pre-existing cell: Must be kept, FF1
may be moved, but not sized
y
CLK
nl
0.75
…
Set a dont_touch attribute D Q
O
FFn
on the cell CLK
se
CLOCK
mybuf 0.76 D Q
U
FFa
CLK
CTS builds a balanced clock tree
al
0.75 D Q
“mybuf” cell may be moved FFb
but not sized or removed.

CLK
rn
te
set_dont_touch [get_cells "mybuf"]
In
s 8- 33
sy
Example – all clock sources have a hand-instantiated buffer that is to be protected:
set_dont_touch [get_cells "I_CLOCKING/I_CLK_SOURCE*"]

op
report_size_only –all
yn
To remove this attribute, use set_dont_touch <cell> false.

rS
Fo
ed
er
i st
eg
R

Preserving Pre-Existing Cells – Allow Sizing
Pre-existing cell: Must be kept, D Q
may be moved and sized FF1
y
CLK
nl
…
0.75
Set a size_only attribute D Q
O
FFn
on the cell CLK
se
CLOCK
mybuf 0.76 D Q
U
FFa
CLK
CTS builds a balanced clock tree
al
0.75 D Q
“mybuf” cell may be moved and FFb
sized, but not removed
rn
CLK
te
set_size_only [get_cells "mybuf"]
In
s 8- 34
sy
To remove the size_only attribute:
set_size_only [get_cells "mybuf"] false

op
report_size_only –all
yn
Note: Disabling buffer removal with cts.compile.remove_existing_clock_trees = false would

affect all pre-existing buffers; With set_size_only you can select what to keep.
rS
Fo
ed
er
i st
eg
R

Cells that Should Not Be Moved
 Any cells that should not be moved by CTS should

be marked with a legalize_only or a fixed placement status
y
nl
set_placement_status fixed [get_cells "mybuf"]
O
or
se
set_placement_status legalize_only [get_cells "mybuf"]
U
al
 Note: Cells with a fixed placement status will not be up- or down-sized either
rn
te
In
s 8- 35
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Tree Removal Behavior

Object Impact on clock tree removal
Boundary cell Removed
y
Cells on dont_touch net Preserved
nl
Don’t touch cell Preserved
Fixed Cell Preserved
O
Preserved, if generated clock is defined on
Generated clock buffer/inverter pin. Traversal and clock tree removal
se
continue past the generated clock.
Guide buffer Removed
U
Integrated clock-gating cell (ICG) Preserved. Traversal (and clock tree removal)
Block Abstraction Model continues past the ICG cell / BA
Removed in pairs only. If a clock tree contains a
al
Inverter
single inverter, it is not removed.
rn
Isolation cell, level shifter Preserved
Preserved. Traversal (and clock tree removal)
Three-state buffer
stops at the three-state buffer.
te
Buffer or inverter added beyond exception Removed
In
s 8- 36
sy
op
yn
rS
Fo
ed
er
i st
eg
R

y
nl
O
se
• Controlling Wire Width and Spacing
• Controlling Via Selection
U
• Applying Rules on Selected Clock Tree Parts
al
rn
te
In
s 8- 37
sy
op
yn
rS
Fo
ed
er
i st
eg
R

 ICC II can route the clock nets using non-default routing (NDR) rules,
e.g. double-spacing, double-width, shielding
y
nl
 NDR rules are treated as physical DRCs – reported as violations if not met
O
 NDR rules are often used to “harden” the clock, e.g. to make the clock
routes less sensitive to cross-talk and electro-migration (EM) effects
se
U
Sig1
Sig1
al
Clk Clk
Sig2
rn
Sig2
te
Default Routing Rule Effect of NDR route on Clk
In
s 8- 38
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Non-Default Via Rules
 Clock nets are hardened further by often requiring 100% via

optimization to enhance reliability
y
 Minimum size single cut vias are replaced with:
nl
 Multiple-cut via arrays
O
 and/or
 Larger “square” or “bar” cuts
se
 This is also defined using clock NDR rules
U
al
rn
te
Default Routing Rule
In
Effect of different via NDRs on Clk routes
s 8- 39
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Defining Non-Default Routing and Via Rules
 Define the NDR rules:
y
create_routing_rule 2xS_2xW_CLK_RULE \
-widths {M1 0.11 M2 0.11 M3 0.14 M4 0.14 M5 0.14} \
nl
-spacings {M1 0.4 M2 0.4 M3 0.48 M4 0.48 M5 1.1} \
O
-cuts { ... \
{VIA3 {Vrect 1} } \
se
Layer name ... \
cutNameTbl name
{VIA5 {Vrect 1} } \
U
}
Minimum # of cuts
al
 With the –cuts option you use “symbolic” via names defined in the
rn
technology file as cutNameTbl
This simplifies the NDR definition because one symbolic via can match
te

many specific vias and arrays
In
s 8- 40
sy
You can report on the routing rules that were defined using report_routing_rules.
create_routing_rule
[-default_reference_rule | -reference_rule_name ref_rule_name]
op
[-widths {layer_name width ...}]

[-shield]
[-shield_widths {layer_name width ...}]
yn
[-shield_spacings {layer_name spacing ...}]

[-snap_to_track]
[-vias {{via_definition_name site_spec rotation_spec} ...} |
rS
-cuts {{cut_layer_name {cut_name num_of_cuts} ...} ...}]

[-taper_distance distance]
[-driver_taper_distance distance]
Fo
[-taper_over_pin_layers num_of_layers]
[-taper_under_pin_layers num_of_layers]
[-spacings {layer_name {spacing ...} ...}]
[-spacing_weight_levels {layer_name {[low|medium|high|hard ...} ...}]
ed
[-spacing_length_thresholds {layer_name {spacing_length_threshold ...} ...}]

[-multiplier_width width_multiplier]
[-multiplier_spacing spacing_multiplier]
er
[-ignore_spacing_to_pg true|false]
[-ignore_spacing_to_blockage true|false]
[-ignore_spacing_to_shield true|false]
st
[-rdl_taper_distances {layer_name distance ...}]

[-rdl_taper_widths {layer_name width ...}]
i
[-mask_constraints {{layer_name mask_name [fixed]} ...}]

eg
[-via_spacings {{layer_name layer_name spacing} ...}]

rule_name
R

Example Technology File

Layer "VIA3" {
fatTblThreshold = ( 0, 0.13, 0.26 )
fatTblFatContactNumber = ( "2,3,4 ","5,6,20", "5,6,20" )
fatTblFatContactMinCuts = ( "1,1,1", "1,1,2", "2,2,4" )
y
cutNameTbl = ( Vsq, Vrect )
cutWidthTbl = ( 0.05, 0.05 )
nl
cutHeightTbl = ( 0.05, 0.13 )
…
}
O
ContactCode "VIA34_LH" {
contactCodeNumber = 5
cutWidth = 0.13
se
cutHeight = 0.05
…
}
U
ContactCode "VIA34_LV" {
cutWidth = 0.05
al
cutHeight = 0.13
…
rn
}
ContactCode "VIA34_P" {
te
cutWidth = 0.05
cutHeight = 0.05
…
In
}
s 8- 41
sy
The example above uses a one-dimensional “fatTblThreshold” table, which works if the upper (M4) and
lower (M3) metal layers have the same minimum widths. If they have different minimum widths, a two-
op
dimensional table can be used to define contact codes for various combinations of upper and lower metal
layer widths. The tech file in the lab uses two-dimensional tables.
yn
If neither the –cuts nor the –vias option of create_routing_rule are specified, then the router uses the
“fatTblThreshold” table, together with the specified “fatTblFatContactNumber” and
rS
“fatTblFatContactMinCuts” values, to optimize the vias, by default. The –cuts option is used to limit
the available choices: In the example above, metal widths of 0.13 or larger, but less than 0.26, will have a
Fo
minimum of a single via of contact code # 5 or #6, or two vias of contact code #20, by default.
However, because -cuts { {VIA3 {Vrect 1} } ... } was specified, only the rectangular via cuts
#5 and #6 will be used.
ed
The –vias option, shown on the next page, can be used to over-ride the default via NDRs defined by the
“fatTblThreshold” table. It can be used to limit or expand the via choices.
er
i st
eg
R

Defining Via NDRs with -vias

 You may also use the –vias option
 This will require you to specify the exact ContactCode names defined
y
in the technology file
nl
 This example is the equivalent of using
O
-cuts { {VIA3 {Vrect 1} } shown two pages earlier
se
create_routing_rule 2xS_2xW_CLK_RULE \
-widths {M1 0.11 M2 0.11 M3 0.14 M4 0.14 M5 0.14} \
-spacings {M1 0.4 M2 0.4 M3 0.48 M4 0.48 M5 1.1} \
U
-vias { \
{VIA34_LH 1x1 R} {VIA34_LH 1x1 NR} {VIA34_LV 1x1 R} \
al
{VIA34_LV 1x1 NR} {VIA34_LH 1x2 R} {VIA34_LH 1x2 NR} \
{VIA34_LH 2x1 R} {VIA34_LH 2x1 NR} {VIA34_LV 1x2 R} \
rn
{VIA34_LV 1x2 NR} {VIA34_LV 2x1 R} {VIA34_LV 2x1 NR}} \
#
te
# VIA45 and VIA56 definitions go here
}
In
s 8- 42
sy
The –vias example above explicitly lists the 12 possible cuts which are more succinctly defined by -cuts
{ {VIA3 {Vrect 1} } two pages ago. Following is an explanation of how they are equivalent:
From the technology file on the previous page, the Vrect “cut name table” defines cuts with a width of 0.05
op
and height of 0.13 um. For layer VIA3, the “contact codes” VIA34_LH and VIA34_LV, corresponding to
“contact code numbers” 5 and 6 respectively, match these dimensions.
yn
Two pages earlier, the METAL3 and METAL4 widths are defined as 0.14um. In the tech file, the
fatTblThreshold for VIA3 lists three metal dimensions: 0, 0.13 and 0.26. Since 0.14 is less than 0.26, but
rS
greater or equal to 0.13, the 0.13um column applies. This column lists three contact code numbers: 5, 6 and
20. Since contact code 20 does not match the 0.05x0.13 dimensions of Vrect, it is not allowed for layer
Fo
VIA3. In the same “0.13” column, below the contact code numbers, the “1’s” represent the minimum number
of cuts required, namely 1. With METAL3 and METAL4 widths of 0.14, however, two cuts of 0.05x0.13 can fit
side by side along their long edges. This means that there are three possible “array” or (row X column)
ed
configurations: 1 X 1, 2 X 1 and 1 X 2.
Lastly, individual cuts can be placed in their original non-rotated (NR) or 90-degree rotated (R) orientation.
er
The total number of possible mappings for a via layer is (as long as no physical DRCs are violated):
Number of contact codes X Number of possible arrays X Number of allowed orientations, which for our
st
example equals 2 X 3 X 2 = 12, the 12 combinations shown above.

i
eg
R

Applying Non-Default Routing Rules
 Configure clock tree routing:

create_routing_rule 2xS_2xW_CLK_RULE ...
y
nl
set_clock_routing_rules -rule 2xS_2xW_CLK_RULE \
O
-min_routing_layer M4 \
-max_routing_layer M5
se
Automatically tapers NDR widths to connect to pins 1;
U
The lower metal layer in this list is a “soft” rule – will switch to
lower metal layers if needed 2
al
 Note that the NDR was specified also for M1-M3
rn
 Although the clocks will be primarily routed on M4/M5 as shown above, they need
to route on lower layers to connect to the standard cell pins, therefore should be
te
covered by an NDR as well!
In
s 8- 43
sy
1 You can control the tapering using the application option route.detail.pin_taper_mode. Allowed
values: default_width (default) , pin_width, off
op
2 Can use the application option route.common.net_min_layer_mode to make this a “hard” rule. Also,
if left at soft (the default), you can control the cost with
yn
route.common.net_min_layer_mode_soft_cost (default is medium; other options are low and

high).
rS
set_clock_routing_rules
Fo
[-clocks clock_list | -nets net_list]

[-net_type sink | internal | root]
[-min_routing_layer min_layer]
ed
[-max_routing_layer max_layer]
-rule ndr_rule | -default_rule
er
i st
eg
R

NDRs on Clock Nets
 ICC II CTS supports various types of NDR specifications when building

the clock tree
y
1. Net-specific NDR from set_routing_rule <net_list>:
nl
NDR will not get propagated to newly created nets
O
2. Net-specific NDR from set_clock_routing_rules -nets:
NDR will get propagated to newly created nets
se
3. Clock-specific NDR from set_clock_routing_rules -clocks:
Supports separate NDRs for root, sink and internal nets which are clock-specific
U
4. Global NDR from set_clock_routing_rules:
al
Supports separate NDRs for root, sink and internal nets
n1
rn
 The order of priority is 1 > 2 > 3 > 4
te
n1 n2
In
s 8- 44
sy
Looking at the picture:
If a routing rule was set on a net n1 using (1), after CTS inserts a buffer, n1 will keep the NDR, n2 will not
op
have it.
If using (2), n2 will inherit n1’s NDR.
yn
rS
Fo
ed
er
i st
eg
R

Different NDRs for Root, Internal, Sink Nets

set_clock_routing_rules
-rules 3X_RULES
-min_routing_layer M4
-max_routing_layer M5 -net_type:
y
set_clock_routing_rules root | internal | sink
nl
-net_type sink
-rules 2X_RULES
O
-min_routing_layer M4
-max_routing_layer M5 2X_RULES
wires
se
3X_RULES
wires
U
al
G1 G2
rn
root internal sink
te
The highlighted options allows you to specify less aggressive NDR rules for clock
tree “leaf” nets, while allowing more aggressive NDRs for the other nets.
In
Helps to prevent routing DRC violations as well as SI issues
s 8- 45
sy
In the example above, a rule is specified on all clock nets, followed by a specification on sinks only.
Therefore, both the root and internal segments will obey 3X_RULES, and the sinks will obey 2X_RULES.
op
Root NDR: Applied on the root clock net, until the first point of branching or the first pre-existing multi-input
cell on the clock tree, whichever comes first.
yn
Sink NDR: Applied on nets connected to the clock pins of registers.

Internal NDR: Applied on nets other than root and sink nets.
rS
You need to ensure that you apply the min/max routing layer setting for each net type, otherwise all layers
Fo
will be used for clock tree routing.

ed
er
i st
eg
R

Classification of Root, Internal, Sink
 If no gates are present on the clock tree, the first branching point of the
clock starts the “internal” segment, while the last net from the sink to
y
nl
the buffer is the “sink” segment
O
se
U
al
rn
root internal sink
te
In
s 8- 46
sy
Q: What if I want to have a specific NDR for the net that goes from the port to the first cell only? Can I use
the “-net_type root” for this?
A: In that case you need to use set_routing_rule in order to set an NDR on these “I/O nets”
op
specifically.
yn
rS
Fo
ed
er
i st
eg
R

Relaxing Spacing Requirements
 Increased spacing for crosstalk prevention can make routing difficult
y
 Crosstalk is less of an issue on shorter parallel segments
nl
 Relax the NDR by introducing spacing-length thresholds
O
create_routing_rule CLK_RULE \
-spacings { M2 0.16 M3 0.45 M4 0.45 M5 1.1 } \
se
-spacing_length_thresholds { M2 3.0 M3 3.0 M4 4.0 M5 4.0 } ...
U
 Spacing value is ignored if the parallel length is less than the threshold
al
rn
te
1.1 M5 M5
In
0 1 2 3 4 s 0 1 2 3 4 8- 47
sy
-spacing_length_thresholds {layer_name {spacing_length_threshold ...} ...}
Sets the length threshold for the corresponding spacing that is specified in the -spacings option. Each entry in the
list is comprised of a routing layer name and its length threshold list in microns, separated by a space. The length
op
threshold portion of the pair is a list of floating point numbers.

yn
The length threshold values in the -spacing_length_thresholds argument and the spacing values in the -
spacings argument must have a one-to-one correspondence.
rS
Router reports and tries to fix only those DRC violations where the parallel length of the metal involved in the
violation overlaps by at least the specified threshold. Router calculates the parallel length using a shape-based
Fo
formulation. The purpose of this option is to increase the flexibility of DRC convergence but not hurt crosstalk in a
significant way.
ed
The default threshold value is 0.

er
i st
eg
R

Clock Crosstalk Prevention through NDR Promotion
 Crosstalk on clock nets can significantly impact design timing

 Generally, increasing spacing mitigates crosstalk effects
y
Clock tree optimization can automatically promote existing NDRs to
nl

NDRs with larger spacing requirements
O
 Done only in non-congested regions to avoid difficulties in route DRC convergence
se
 Congestion analysis considers full signal GR, not only clock GR!
 NDR promotion is controlled using the application option
U
cts.optimize.enable_congestion_aware_ndr_promotion Default: false
al
cts.optimize.enable_congestion_aware_ndr_promotion_in_ccd Default: true
rn
 CTO first clones existing clock NDRs, then increases their spacing
te
 Iteratively assigns non-congested clock nets to the promoted NDRs
In
s 8- 48
sy
This feature is on-by-default when using CCD.
op
The solution for NDR promotion involves two steps:

1. Creating and preparing clone NDRs with the increased spacing to be used during optimization.
2. Iterative NDR promotion.
yn
Details on step 1:
rS
This step is performed prior to initial global routing the clock nets.
After identifying all used clock net NDRs, these are cloned as follows:
Fo
• If spacing requirement of the NDR is less than or equal to 2 times default spacing
 Spacing requirement is doubled for the cloned NDR
• For all other NDRs (spacing requirement more than 2 times default spacing)
ed
 Spacing requirement is increased by one default spacing

Example:
er
Cloned NDR for 2W2S will be 2W4S

 Spacing requirement doubled as NDR spacing requirement <= 2 times the default spacing
st
Cloned NDR for 2W3S will be 2W4S

 Spacing increased by one default spacing
i
eg
The newly created rule will follow the following naming convention
<original_rule_name>_ext_spacing
R
For the nets with default rules an equivalent rule with double spacing requirement is created with the
following name: default_rule_equivalent_ndr_double_spacing

y
nl
O
se
U
al
• Input Drive and Loads
• Max Transition and Capacitance Constraints
rn
• Clock Uncertainties
te
In
s 8- 49
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Are all Clock Drivers and Loads Specified?
Ensure that all clock input ports have a slew constraint –

needed for accurate clock delay calculation during and after CTS
y
CHIP_TOP
nl
MOD_A MOD_B
O
cbuf2
se
cbuf10
U
cbuf2
al
CLK
cbuf6
rn
te
MOD_B is the
set_driving_cell ... design being
In
set_load ... P&R’d
s 8- 50
sy
It is generally preferred to use set_driving_cell to more accurately model clock port slews. Use of
set_driving_cell allows the timer to adjust the actual input port slew based on the actual capacitive load
op
that is connected to the input port (both internal loads, which changes as CTS and CTO modify the clock tree
network buffers, as well as external loads, which can be modeled by set_load, if applicable). In addition to
accurately modeling input slews, the set_driving_cell command transfers any applicable “max-
yn
capacitance” and/or “max-transition” design rule constraints of the driving cell to the clock input port, which
helps to ensure these DRCs are not violated on the clock ports:
rS
set_driving_cell -lib_cell cbuf10 \

-input_transition_rise 0.2 \
Fo
-input_transition_fall 0.2 [get_ports CLK]

set_load 0.03 [get_ports CLK]
ed
Alternatively, if the spec provides fixed “input transition times” instead of “driving cells”, use the following
(input slews are not adjusted for actual load; no DRCs applied on input ports):
er
set_input_transition –max –rise <n1> [get_ports CLK]

set_input_transition –max –fall <n2> [get_ports CLK]
st
set_input_transition –min –rise <n3> [get_ports CLK]

i
set_input_transition –min –fall <n4> [get_ports CLK]

eg
R

Example: Reporting Clock Port Constraints
report_port -verbose [get_ports *clk]  Every clock input port

... should have a
set_driving_cell or a
y
Pin Cap Wire Cap
Min Max Min Max
nl
Port Dir rise/fall rise/fall rise/fall rise/fall Attributes
--------------------------------------------------------------------------------- set_input_transition
ate_clk in 0.00/0.00 0.00/0.00 0.00/0.00 0.00/0.00
pclk in 0.00/0.00 0.00/0.00 0.00/0.00 0.00/0.00 constraint
O
sdram_clk in 0.00/0.00 0.00/0.00 0.00/0.00 0.00/0.00
sys_2x_clk in 0.37/0.37 0.48/0.48 0.00/0.00 0.00/0.00  Models input slew, for accurate
timing analysis of the first tiers
se
...
set_load
Transition (min/max) of clock tree gates
Input Port Rise Fall Related Clock
U
--------------------------------------------------------------------------------
ate_clk 0.30/0.30 0.30/0.30  Ports with a driving cell
pclk 0.12/0.12 0.12/0.12 set_input_transition
may additionally require a
al
Driving Cell
Input Port Type Cell Mult Clock Attrs
--------------------------------------------------------------------------------
capacitive load for more
rn
sdram_clk
sdram_clk
min_rise NBUFFX16_RVT
min_fall NBUFFX16_RVT
accurate slew calculation
sdram_clk max_rise NBUFFX16_RVT set_driving_cell
 Models the external load seen
te
sdram_clk max_fall NBUFFX16_RVT
sys_2x_clk
sys_2x_clk
min_rise NBUFFX16_RVT
min_fall NBUFFX16_RVT by the driving cell
In
sys_2x_clk max_rise NBUFFX16_RVT
sys_2x_clk max_fall NBUFFX16_RVT
s 8- 51
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Defining CTS-Specific DRC Values
 Max transition and max capacitance design rules can be specified in

two ways: Library and SDC
y
nl
 ICC II will always use the smallest value
O
 You can define your own CTS-specific DRC values:
set_max_transition <value> -clock_path [all_clocks] Default: 0.5ns
se
set_max_capacitance <value> -clock_path [all_clocks] Default: 0.6pF
U
 Design rule constraints can be selectively applied per clock
al
and per scenario (applies to current scenario, by default):
rn
set_max_transition 0.2 -clock_path \
-scenarios "S1 S4" \
te
[get_clocks SYS_CLK]
In
s 8- 52
sy
If no scenarios are specified, constraints apply to the current scenario only (current mode+corner). The same
applies to the remove_max_capacitance/transition commands, they will operate on the current
scenario only. If you want to apply the commands to multiple scenarios, you have to use the -scenarios
op
switch.
yn
Be careful not to over-constrain these clock tree DRC option settings, otherwise ICC II may use more buffers
than necessary, and/or may not be able to meet all DRCs.
rS
Fo
ed
er
i st
eg
R

Remove Skew from Uncertainty
 SDC constraints usually include

set_clock_uncertainty –setup | -hold <number>
y
applied to each clock
nl
 Models estimated effects of clock skew, jitter and additional timing margin on
O
setup/hold timing, pre-CTS
se
 After clock tree propagation, to avoid pessimistic timing analysis,
remove or reduce uncertainty by the estimated skew:
U
set_clock_uncertainty –scenarios s1 –setup | -hold <SMALLER_#> CLK1
al
set_clock_uncertainty –scenarios {s2 s3} –setup | -hold <SMALLER_#> CLK2
rn
...
# OR
te
remove_clock_uncertainty [all_clocks] -scenarios [all_scenarios ]
In
s 8- 53
sy
If the uncertainty constraint values include jitter and/or margin, you can continue to take these effects into
account, while also allowing the tool to calculate the actual skew (by calculating actual propagated insertion
op
delays and seeing the difference in arrival time at register clock pins), by reducing the uncertainty constraint
values by the estimated skew portion. Assuming, for example, that the pre-CTS uncertainty constraints were:
set_clock_uncertainty –setup 0.7 [get_clocks MY_CLK] (Skew 0.4; Jitter 0.2; Margin 0.1)
yn
set_clock_uncertainty –hold 0.5 [get_clocks MY_CLK] (Skew 0.4; Jitter 0.0; Margin 0.1)
rS
It is recommended to change the constraints - before running CTS - as follows, to keep the same
jitter/margin:
Fo
foreach_in_collection scn [all_scenarios] {

set_clock_uncertainty –scenarios $scn –setup 0.3 [get_clocks MY_CLK]
set_clock_uncertainty –scenarios $scn –hold 0.1 [get_clocks MY_CLK]
}
ed
The specified setup uncertainty reduces the effective clock period of all paths captured by the specified clock.
er
This is used during logic synthesis and place_opt to estimate the effects of skew, jitter and margin on setup
timing.
st
The specified hold uncertainty increases the delay of all paths captured by the specified clock. This can be
used during synthesis and place_opt to estimate the effects of skew, jitter and margin on hold timing,
i
eg
although hold timing is not usually considered until after the clock trees are built.
R

Uncertainty on Output Ports
 Removing skew from set_clock_uncertainty causes post-CTS skew on

output paths to be zero!
y
nl
 Results in optimistic setup timing analysis
O
 Consult the appendix for two ways to address this
se
MY_DESIGN
U
OUT1
D Q D Q
FF FF
al
CLK CLK
rn
CLOCK
te
In
s 8- 54
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Reporting Settings Summary
# Report clock tree max_tran/cap/references/… in all clocks+modes:

report_clock_settings
y
[-clock CLOCKS]
nl
[-type type]
type can be: configurations, routing_rules,
O
references, spacing_rules, all
se
# Report clock tree target skew/latency constraints:
report_clock_tree_options
U
# Report explicit balance points (sink/exclude pins), and groups:
al
report_clock_balance_groups
rn
# Report non-default routing rules in a more compact way
te
report_clock_routing_rules
In
s 8- 55
sy
configurations refers to clock tree synthesis configurations, including max transition and max
capacitance specified by set_max_transition and set_max_capacitance;
op
routing_rules refers to clock tree routing rules specified by set_clock_routing_rules;

yn
references refers to available buffers and invertors in clock tree synthesis;

rS
spacing_rules refers to clock cell spacing rules specified by set_clock_cell_spacing;
all refers to all the above types of settings. The default value of this option is all.
Fo
ed
er
i st
eg
R

y
 Set up clock tree balancing constraints
nl
 Handle pre-existing clock tree elements
O
 Specify NDRs for clock tree routing
se
 Specify timing and DRC constraints
U
al
Lab 8: Setting Up CTS
rn
te
In
s 8- 56
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Appendix
y
nl
O
A - Accounting for post-CTS uncertainty on outputs
B - Clock Cell Spacing
se
U
al
rn
te
In
s 8- 57
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Post-CTS Skew on Outputs (1 of 2)

Removing estimated skew from set_clock_uncertainty causes post-CTS
skew on output paths to be zero!
Use one of two methods to avoid this:
y
nl
1) Use virtual clocks for outputs, with independent uncertainties,
which remain unchanged pre- versus post-CTS
O
Estimated “skew” is the same
se
pre- and post-CTS, whether
clocks are ideal or propagated
U
create_clock –p 4 –n V_CLK
create_clock –p 4 –n CLK CLOCK set_clock_latency 1.0 V_CLK
set_clock_latency 1.0 CLK set_clock_uncertainty –setup 0.3 V_CLK
al
set_clock_uncertainty –setup 0.3 CLK set_output_delay –clock V_CLK –max 2.2 OUT1
rn
MY_DESIGN OUT1
D Q D Q
te
FF FF
CLK CLK
In
CLOCK
s 8- 58
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Post-CTS Skew on Outputs (2 of 2)

2) Include the clock skew in the output data path delay post-CTS
 Pre-CTS example: Clock network latency = 1.0ns; Clock skew = 0.2ns;
Clock jitter = 0.1ns; Output delay = 2.2ns
y
nl
Include clock network latency in the output delay (as shown previously), and model skew
and jitter as clock uncertainty:
O
Pre-CTS output required
create_clock –period 4 [get_ports CLOCK] time is 4.0-3.2–0.3=0.5ns
se
set_clock_uncertainty –setup 0.3 [get_clocks CLK]
set_output_delay –clock CLK –max 3.2 \
U
-network_latency_included [get_ports OUT1]
 Post-CTS, reduce uncertainty by the estimated skew amount,
al
and account for the estimated skew amount in the output delay:
rn
Post-CTS output required
create_clock –period 4 [get_ports CLOCK] time is 4.0-3.4–0.1=0.5ns
te
set_clock_uncertainty –setup 0.1 [get_clocks CLK]
set_output_delay –clock CLK –max 3.4 \
In
-network_latency_included [get_ports OUT1]
s 8- 59
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Reduce Electromigration
 Clock cells can consume more power than data cells
y
 Clock cells that cluster together in a small area increase current densities for the
nl
power and ground rails
There is a potential electromigration problem, as a result
O

 A hot-spot may also develop, affecting near-by thermal sensitive circuits
se
U
 One solution to the problem is to define spacing requirements between
clock cells
al
 Spacing requirements may be defined for inverters, buffers, and integrated clock-
rn
gating cells on the clock network
te
In
s 8- 60
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Clock Cell Spacing

 Example:
set_clock_cell_spacing -lib_cells "*/bufx2" -x_spacing 2 -y_spacing 2
set_clock_cell_spacing -lib_cells "*/bufx8" -x_spacing 4 -y_spacing 2
y
nl
 Validate placement y_spacing
O
check_legality –verbose 6 x_spacing
bufx2 bufx8
se
8
By default, the distance is equal to the larger
U
bufx8
of the cells’ respective spacing rules
al
(max(x1,x2) and max(y1,y2)). bufx2
rn
To change the distance to be equal to the sum
of the respective spacing rules (x1+x2 and y1+y2):
te
cts.placement.cell_spacing_rule_style cumulative }
In
s 8- 61
sy
The unit for “spacing” is microns.
op
The following commands are also available:

report_clock_cell_spacings
remove_clock_cell_spacings
yn
Example:
rS
Cell c1 has x-spacing x1 and y-spacing y1, and cell c2 has x-spacing x2 and y-spacing y2. The default
spacing style (cts.placement.cell_spacing_rule_style = maximum) will apply a spacing rule of
Fo
max(x1,x2) in the x direction and max(y1,y2) in the y direction. If you set the above app option to
cumulative, then (x1 + x2) and (y1 + y2) for the x- and y-spacing will be used instead.
ed
er
i st
eg
R

y
nl
O
se
U
al
rn
te
In
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Agenda
DAY
y
nl
8 Setting Up CTS
O
se
U
al
11
rn
Signoff
te
In
s 9- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Routing & Optimization © 2019 Synopsys, Inc. All Rights Reserved. 9-1

Synthesis
y
nl
O
se
U
CTS & Optimization
al
rn
Routing & Optimization This Unit
te
Signoff
In
s 9- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Unit Objectives
y
nl
 Perform pre-routing checks and setup
O
 Route the signal nets using route_auto
se
 Optimize the design using route_opt
U
 Report and fix DRC violations
al
rn
te
In
s 9- 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Routing Phase Goal
y
 Placement and CTS should be completed
nl
 Acceptable congestion, setup/hold timing, and logical DRCs
O
 Clock nets should be routed
se
The goal of the routing phase is to:
U

 Route all the signal nets with minimal physical DRC violations
al
 Optionally perform post-route CTO or CCD
rn
 Optimize datapath logic for timing, DRCs, and power
te
In
s 9- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R
ICC II Routing Flow
CTS +
Clock routing
y
The “routing phase” involves
nl
Pre-routing several key steps:
O
checks and setup
 Pre-routing checks and setup
se
Routing  Signal routing
U
 Optimization and rerouting
Optimization
al
and Reroute
rn
Routing
te
In
Signoff
s 9- 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Recommended Routing Flow
 Clock nets should have been routed already
y
 Signal nets are routed first – no cell optimization:
nl
route_auto
O
 Routing performs:
Global Routing  Track Assignment  Detail Routing
se
 Afterwards, post-route optimization is performed:
U
route_opt
al
 Concurrently optimizes:
rn
 Timing and max-tran/max-cap (by default),
 Clock tree, power (optionally)
te
 Optionally uses PrimeTime delay calculation and StarRC Extraction
In
s 9- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Route Operations: Global Route (GR)

 GR assigns nets to specific metal layers (in the preferred routing
direction) and through specific global routing cells (GRC or Gcells)
y
 No metal traces are created
nl
 Uses colored zero-width lines to indicate global routes and
assigned metal layers
O
 GR tries to avoid congested Gcells while minimizing detours:
se
 Congestion exists when more tracks Global Route
are needed than available
U
 Detours increase wire length (delay)
al
 GR also avoids:
rn
 P/G (rings/straps/rails)
te
GRC
 Routing blockages
Congested area
In
s 9- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Route Operations: Global Route Summary
 Global routing does not create
y
metal shapes
nl
 You can select and interact with
O
global routing in the GUI
se
U
Global
al
route
Preroute
rn
te
In
s 9- 8
sy
For example if you want to see how certain nets were global routed, you can use change_selection to
select named nets from the console:
icc2_shell> change_selection [get_nets A/B/net_pbus*]
op
yn
rS
Fo
ed
er
i st
eg
R
Route Operations: Track Assignment
 Track Assignment (TA):
y
Jog reduces
Assigns each net to a specific track via count
nl

within each global routing cell and
O
creates the actual metal shapes
Attempts to:
se

 Make long, straight traces
U
 Reduce the number of vias TA metal
shapes
traces
al
 After Track Assign, there should be
no global routes or GR vias left Preroute
rn
te
After TA finishes, all nets are routed, but not very carefully. There are many violations, particularly
where the routing connects to pins. Detail routing works to correct those violations.
In
s 9- 9
sy
If track assignment can reduce the number of jogs and jumps in metal traces, this will generally improve
timing (since each jump generally requires a via to jump to a higher or lower level metal layer). Reducing the
op
number of vias is generally a plus for reliability and yield since their failure rate is slightly higher than that of
a simple, straight metal track in a modern, planarized process.
yn
After track assignment, there should not be any left-over global routes. If this is the case, make sure that these
nets don’t have the attribute physical_status=locked, which would prevent track assignment.
rS
Fo
ed
er
i st
eg
R
Route Operations: Detail Routing
 Detail route fixes physical design rule violations

 Performs multiple iterations with varying repair box sizes
y
nl
O
se
Notch
Notch Spacing
Spacing
U
al
Min
rn
Thin&Fat Spacing
Spacing
te
In
s 9- 10
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Pre-Routing Checks and Setup
CTS +
Clock routing Check for routing readiness
y
Control secondary P/G pin routing
nl
Pre-routing
Enable redundant via insertion
O
checks and setup
Increase wire/via optimization level
se
Routing
Enable antenna fixing (layer jumping)
U
Optimization Apply route guide/blockage, if needed
al
and Reroute
Control the scope for rerouting
rn
Routing
Enable crosstalk analysis and prevention
te
In
Signoff
s 9- 11
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Check for Routing “Readiness”
 Run checks to ensure that you are ready for routing:
y
icc2_shell> check_design -checks pre_route_stage
nl
Running mega-check 'pre_route_stage':
O
Running atomic-check 'design_mismatch'
Running atomic-check 'scan_chain'
Running atomic-check 'mv_design'
se
Running atomic-check 'design_extraction'
Running atomic-check 'timing'
Running atomic-check 'routability‘
U
…
Info: EMS database is saved to file 'check_design.ems'.
Info: Non-EMS messages are saved to file 'check_design2015Jul07025739.log'.
al
rn
 Open a Message Browser Window to analyze the violations in the EMS database
te
In
s 9- 12
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Routability Check
 The routability check calls check_routability to confirm that the
y
design is ready for routing:
nl
 Blocked ports, out-of-boundary pins
O
 A logical port can have several physical pins
A port is considered blocked if none of its pins are accessible
se
 Pin access edge rules honored
Minimum-grid violations
U

al
rn
te
In
s 9- 13
sy
check_routability (these are not all options!)
[-check_standard_cell_blocked_ports true | false]
[-check_non_standard_cell_blocked_ports true | false]
op
[-check_pg_blocked_ports true | false]

[-check_frozen_net_blocked_ports true | false]
[-check_min_grid true | false]
yn
[-check_out_of_boundary true | false]

[-obey_access_edges true | false]
rS
[-access_edge_whole_side true | false]

[-report_no_access_edge true | false]
[-obey_direction_preference true | false]
Fo
[-allow_via_rotation true | false]

[-connect_standard_cells_within_pins true | false]
[-check_no_net_pins true | false]
[-honor_layer_constraints true | false]
ed
er
i st
eg
R
Secondary PG Pin Connections

Primary Power Rail Secondary power pin
 Secondary PG pins (e.g. backup power/ground for

always-on cells) should be routed first
y
nl
route_group –nets {VDDH}
O
se
 By default, there is no maximum to the number of PG
U
pin connections from a strap - choose your own
al
maximum value based on your PG grid
rn
Primary Ground Rail
set_app_options -list \
te
{route.common.number_of_secondary_pg_pin_connections 4}
In
s 9- 14
sy
route.common.number_of_secondary_pg_pin_connections
This application option specifies the maximum number of secondary PG pins in a cluster.
The definition of a cluster is a set of connected secondary PG pins. Each cluster has one connection with a
op
PG strap or ring. If the value is greater than 0, a cluster should not contain more than the specified number of
secondary PG pins.
yn
By default, the setting is 0, which means that there is no maximum.

rS
Fo
ed
er
i st
eg
R
NDRs for Secondary PG Routing
 It is not uncommon to use NDRs for Secondary PG

 Restrict routing to certain layers
y
Prevents tie-off
Use only certain vias
nl

connections from
 Specify width using NDRs
O
se
route.common.separate_tie_off_from_secondary_pg true }
create_routing_rule sec_pg \
U
–widths {M1 0.2 M2 0.2 M3 0.2} \
-vias {...}
al
set_routing_rule {VDDH} -rule sec_pg \
rn
-min_routing_layer M2 \
-max_routing_layer M3
te
route_group –nets {VDDH}
In
s 9- 15
sy
route.common.separate_tie_off_from_secondary_pg
By default (false), tie-off connections and secondary PG power connections are considered the same nets,
so non-default routing rules, minimum and maximum layer constraints, and other constraints on the net
op
apply to both tie-off connections and secondary PG power connections.

When you separate the tie-off connections from the secondary PG power connections by setting this option to
yn
true, you can apply nondefault routing rules, minimum and maximum layer constraints, and other
constraints only to the secondary PG power connections.
rS
There is an additional application option that controls tie-off connections, route.common.tie_off_mode.

By default (all), the router can connect tie-off nets to any power or ground (PG) structures, such as straps,
Fo
rails, or pins. When set to rail_only, tie-off connections are made to PG rails only.
ed
er
i st
eg
R
Inserting Redundant Vias on Signal Nets
y
nl
 Replaces single-cut vias with multiple-cut via arrays or another single-
O
cut via with a better contact code (done for DFM and Reliability)
By default, single-cut vias are replaced by two-cut via arrays
se

 Use add_via_mapping for custom via mapping (see appendix)
U
# Enable redundant via insertion. Conversion occurs after every detail route step
al
route.common.post_detail_route_redundant_via_insertion  medium Default: off
Increasing # Concurrent soft-rule based redundant via insertion increases conversion rate:
rn
conversion route.common.concurrent_redundant_via_mode  reserve_space Default: off
rate # Near 100% redundant via insertion can be achieved with:
te
route.common.concurrent_redundant_via_mode  insert_at_high_cost
In
s 9- 16
sy
DFM = Design for Manufacturability
op
While the term “redundant via insertion” is commonly used, a better term to describe the optimization is “via
optimization”. This is because “via optimization” does not rely only on replacing single-cut vias with
multiple-cut via arrays (redundant vias). Single-cut vias can also be replaced with larger single-cut square
yn
vias, or with “bar” vias (rectangular shape), or with vias with better metal overlaps, which can also improve
the yield of vias.
rS
As the redundant via rate increases, it becomes more difficult to converge on the routing design rules and you
Fo
might see a reduction in signal integrity; therefore, you should use near 100% redundant via insertion only for
those blocks that truly require such a high redundant via rate. In addition, achieving very high redundant via
rates might require you to modify the floorplan utilization to allow enough space for the redundant vias.
ed
er
i st
eg
R
Redundant Vias and Small Geometries

 In smaller geometries (< 20nm), it is recommended to reserve space and run
standalone add_redundant_vias after detail route changes (to improve
DRC convergence and minimize overall runtime)
y
nl
route.common.post_detail_route_redundant_via_insertion off
O
route.common.concurrent_redundant_via_mode reserve_space
route.common.eco_route_concurrent_redundant_via_mode reserve_space }
se
route_auto
route_detail –incremental true
U
add_redundant_vias
…
al
route_opt
add_redundant_vias
rn
 Perform redundant via insertion again after completing all post-route optimization runs
te
 RVI runtime is high – perform fewer RVI runs
In
 Make sure that your design has no routing DRC violations before performing RVI
s 9- 17
sy
Performing RVI stand-alone after route_auto (with add_redundant_vias) instead of during, routing, is
purely a runtime-saving technique – it does not result in better conversion rates: If the design has many DRCs
(not RVI-related), route_auto may need to be run multiple times. The above method allows all such
op
routing operations, needed to fix those DRCs, to be completed first, without the added runtime to perform
RVI. After that, run stand-alone RVI is executed once (and then again after route_opt, if needed).
yn
rS
Fo
ed
er
i st
eg
R
Enable Wire and Via Optimization
 Via and wire optimization is recommended when adding redundant vias
y
 Attempts to make long straight traces and reduce the need for vias (using small
nl
jogs in non-preferred direction)
 Default effort is low  Set to high
O
se
route.detail.optimize_wire_via_effort_level high }
U
 Alternatively, use optimize_routes to run this same optimization stand-alone
al
after route_auto
rn
te
In
s 9- 18
sy
To reduce the amount of jogging in the non-preferred direction on specific layers, use the following option:
set_app_options \
op
-name route.common.extra_nonpreferred_direction_wire_cost_multiplier_by_layer_name \
-value {{layer multiplier}...}
yn
The multiplier value must be between 0 and 20. The default is 0. Specifying large values can prevent routing
rS
in the non-preferred direction altogether. If non-preferred direction routing is required, use smaller values. A
small multiplier like 0.25 or 0.5 is valid and can sometimes be enough to achieve the desired results. You
should also examine the total wirelengths on all layers and directions when evaluating multipliers, as too
Fo
strong a multiplier may increase lengths by limiting router freedom.
Run wire/via optimization with 3 iterations:

ed
optimize_routes -max_detail_route_iterations 3
Reroute all shapes of specified nets:
er
optimize_routes -nets {N1 N2 N3} -reroute_all_shapes_in_nets true

st
To avoid jogs altogether, apply a routing guide:

i
create_routing_guide -boundary {{0.0 0.0} {100.0 100.0}} \

eg
-layers {M1 M2 ...M9} -preferred_direction_only

R
Concurrent Antenna Fixing: Layer Jumping

 Antenna rule violations can be fixed by layer jumping (hopping) and by
diode insertion
Layer jumping is recommended during detail route
y

nl
 Diode insertion is recommended post-route
Concurrent layer jumping during detailed routing is enabled, by default
O

 Requires antenna rules provided as a TCL file source antenna_rules.tcl
se
 The following antenna options are the DEFAULT settings
U
route.detail.antenna Default: true
route.detail.antenna_fixing_preference Default: hop_layers
al
route.detail.hop_layers_to_fix_antenna Default: true
rn
 Many antenna fixing options available – see notes below
Diode insertion is disabled, by default
te

 Usually performed during the final block preparation phase
In
s 9- 19
sy
Example antenna rules:
define_antenna_rule -mode 6 -diode_mode 2 -metal_ratio 1800 -cut_ratio 20
define_antenna_layer_rule -mode 6 -layer {METAL1} \
op
-ratio 1800 -diode_ratio {0.336 -0.5 1800 4500}

To enable diode insertion, set the following options:
yn
set_app_options -list {route.detail.diode_libcell_names "DIODE1x" }

set_app_options -list {route.detail.insert_diodes_during_routing true}
rS
To prioritize diode insertion, use:

set_app_options -list {route.detail.antenna_fixing_preference use_diodes}
Fo
Antenna fixing options listed below. Refer to the man page for details. Showing default values:
******** App Options *********
route.detail.antenna = true
ed
route.detail.antenna_fixing_preference = hop_layers
route.detail.antenna_on_iteration = 1
route.detail.antenna_verbose_level = 1
er
route.detail.check_antenna_on_pg = false
route.detail.default_port_external_antenna_area = 0
route.detail.hop_layers_to_fix_antenna = true
st
route.detail.macro_pin_antenna_mode = normal
route.detail.max_antenna_pin_count = -1
i
eg
route.detail.merge_gates_for_antenna = true
route.detail.port_antenna_mode = float
route.detail.skip_antenna_fixing_for_nets =
R
route.detail.top_layer_antenna_fix_threshold = -1
Controlling Router Behavior: Routing Guides
 Using a routing guide, you can change the default routing behavior in a
particular area, e.g. change the preferred routing direction:
y
nl
create_routing_guide -name rg_0 -boundary {{270 340} {491 385}} \
O
-layers {M6} -switch_preferred_direction
Menu: CreateRouting Guide
se
U
al
 Other uses:
rn
 Change track utilization percentage
te
 Use river routing
In
s 9- 20
sy
-river_routing
If you have limited metal layers (e.g. 5), and a RAM uses M1-M4, so only M5 is available to route over
the macro, river routing will allow M5 to route in the non-preferred direction over the macro; Without
op
this, the default preferred routing direction would cause the router to create shorts over the macro.
yn
rS
Fo
ed
er
i st
eg
R
Preventing Routing: Routing Blockages
 To prevent signal routing in a certain area, define a routing blockage:
y
create_routing_blockage
nl
-layers layers
O
-boundary {list_of_points}
[-net_types net_type_list]
se
[-zero_spacing]
[-reserve_for_top_level_routing]
[-nets list_of_nets] …
U
Routing guides and blockages should be applied before place_opt, as
al

they are fully respected by global routing as well
rn
te
-zero_spacing
A zero-spacing routing blockage disables the minimum spacing rule between the routing blockage boundary and the net shapes.
-reserve_for_top_level_routing
In
Top-level routing uses the area reserved by this kind of routing blockages as a routing channel through the block.
s 9- 21
sy
-net_types net_type_list
Specifies the net types that must respect the generated routing blockages.
You can specify one or more of the following values: analog_ground, analog_power,
op
analog_signal, clock, deep_nwell, deep_pwell, ground, nwell, power, pwell, reset, scan,
signal, tie_high, and tie_low.
yn
The default is all net types.

This option is mutually exclusive with the -nets option.
rS
Fo
ed
er
i st
eg
R
Controlling Scope for Rerouting
 By default, the router is allowed to reroute any pre-routed nets

(e.g. custom-routed bus, unless shape is marked as “user”)
y
nl
 To control the scope for rerouting, set the physical_status attribute
on the net:
O
se
set_attribute <nets> physical_status
unrestricted | minor_change | locked
U
al
 For example, to prevent rerouting on specific nets:
rn
set_attribute "net1 net2" physical_status locked
te
In
s 9- 22
sy
Custom-routed nets with the attribute setting, set_attribute <net> shape_use user, will be treated
the same as a “locked physical status” from the router’s perspective. Using the shape_use attribute allows
op
the user to easily identify custom-routed nets.

yn
rS
Fo
ed
er
i st
eg
R
Timing Driven Routing
 By enabling timing-driven routing, timing-critical nets are prioritized by

the routers (default: false)
y
nl
O
route.global.timing_driven true
route.track.timing_driven true
se
route.detail.timing_driven true }
U
 You can control the effort of timing driven global routing with:
al
route.global.timing_driven_effort_level Default: high
rn
 Allowed values: low, medium, high
te
 High effort level emphasizes timing QoR over congestion, while low effort is more
congestion-driven (resulting in better physical DRC convergence)
In
s 9- 23
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Crosstalk Analysis
 Enable crosstalk delta delay

 Delta delay affects setup and hold timing
y
 Affects timing of the net, and therefore affects timing driven routing
nl
set_app_options -name time.si_enable_analysis -value true
O
 Delta delay calculation is pessimistic by default - not based on
se
timing arrival windows
U
time.enable_si_timing_windows Default: false
al
A
rn
A A
V V
te
V
Partially overlapping timing windows Non-overlapping timing windows
In
Delta delay effect is applied No delta delay effect
s 9- 24
sy
By not using timing windows by default, SI timing is pessimistic, because all aggressor nets are taken into
account all the time. With timing windows enabled, aggressor nets are only taken into account if the timing
op
windows overlap partially or fully with those of the victim net. A timing window describes the time of when
a signal transitions from lowhigh or highlow based on min/max arrival calculation.
Timing window calculation is generally turned off by default because it incurs a runtime cost.
yn
rS
Fo
ed
er
i st
eg
R
Crosstalk Prevention
 Crosstalk prevention happens during routing
y
route_auto
nl
 Prevention avoids putting long parallel nets on adjacent tracks
O
 Focuses on timing-critical nets
se
 Prevention is controlled by:
set_app_options -name route.global.crosstalk_driven -value false
U
set_app_options -name route.track.crosstalk_driven -value true
al
 Current recommendation:
rn
Enable crosstalk only during track assignment
Enabling crosstalk during global routing has shown mixed results
te

In
s 9- 25
sy
Prevention happens during the global routing and track assignment stages of routing. During global routing,
timing-critical nets are spread across GRCs, to avoid having many critical nets in one GRC, while having few
op
or none in a neighboring GRC. During track assignment, when actual metal traces exist, simple crosstalk
modeling is used to estimate the effects of crosstalk on delay and static noise. Timing- and noise-critical nets
are prevented, wherever possible, from being routed on adjacent tracks.
yn
rS
Fo
ed
er
i st
eg
R
Static Noise 2017.09
 Noise analysis is also enabled with SI: time.si_enable_analysis
y
 Uses CCSN libraries
nl
 Supports a user-defined noise margin (set_noise_margin)
O
 Noise optimization not available currently
se
 To report static noise violations, use:
U
icc2_shell> report_noise
al
noise_region: above_low
pin name width height slack
----------------------------------------------------------------------
rn
U484/A1 0.61 0.28 -0.02
noise_region: below_high
te
pin name width height slack
----------------------------------------------------------------------
In
I_CONTEXT_MEM/U162/A2 0.64 0.29 -0.03
s 9- 26
sy
CCSN = Composite Current-Source Noise
When you use the report_noise command without any options, it reports a single pin with the largest high
op
and low noise slack. To report all the violators, use the -all_violators option
yn
set_noise_margin
Each library cell input can tolerate a certain amount of noise without causing a failure at the cell output. This
rS
characteristic is called noise immunity. This command specifies noise immunity at library pins to determine
whether noise failures occur as well as the amount of noise slack. Noise immunity in the library can be
Fo
specified as noise immunity curves, polynomials, or tables or in terms of noise margins. This command
specifies a noise margin for a library pin, design port, or pin. It can be used in the absence of library-specified
noise immunity characteristics, or to override the library-specified characteristics by replacing them with
ed
noise margins.
er
i st
eg
R
Align ICCII and PrimeTime Settings
 To increase accuracy and better align with PrimeTime, you should set
the following application options:
y
nl
 Use the Synopsys CCS receiver capacitance model during timing analysis:
O
set_app_options -name time.enable_ccs_rcv_cap -value true Default: false
se
 Enable CCS-based waveform analysis (requires libraries with Composite Current-
Source (CCS) timing and CCS noise data)
U
set_app_options -name time.delay_calc_waveform_analysis_mode \
Default: disabled
al
-value full_design
rn
 Align the waveform analysis algorithm with Primetime:
te
set_app_options -name time.awp_compatibility_mode -value false Default: false
In
s 9- 27
sy
AWP = Advanced Waveform Propagation
time.awp_compatibility_mode
op
By default (setting: false), ICC2 uses the new AWP engine that is more aligned to PrimeTime results. This
new engine requires NDM cell libraries built by M-2016.12-SP2 or later versions of icc2_lm_shell. There
yn
should not be a reason any longer to switch back to the old engine (setting: true).
rS
You should also make sure to align the crosstalk filter values with PrimeTime:
time.si_filter_accum_aggr_noise_peak_ratio
time.si_filter_per_aggr_noise_peak_ratio
Fo
time.si_xtalk_composite_aggr_noise_peak_ratio
ed
er
i st
eg
R
1. What does Global Routing do in congested areas?
y
nl
2. Assignment of nets to metal layers is done during the Track
Assignment stage.
O
True or False?
se
U
3. By default, ICC II will route a metal trace:
al
a) Only in the preferred routing direction
rn
b) In any direction
c) Primarily in the preferred routing direction, except for small jogs
te
in the non-preferred direction
In
s 9- 28
sy
op
yn
rS
Fo
ed
er
1. It routes around the congestion by moving nets out of congested global route cells (GRCs ) to less
st
congested GRCs.
2. False. This is done during Global Route.
i
eg
3. C. You may see a "jog" now and then. To control the routing cost in the non-preferred direction, review
the application option:
R
route.common.extra_nonpreferred_direction_wire_cost_multiplier_by_layer_name
4. “Redundant via insertion” replaces single-cut vias with two-cut

via arrays, by default.
y
True or False?
nl
O
se
5. Which of the following is enabled by default?
a) Crosstalk delta delay
U
b) Timing arrival windows
al
c) Static noise
rn
te
In
s 9- 29
sy
op
yn
rS
Fo
ed
er
st
4. True. By default, the router generates a default via mapping table from the tech file:
i
eg
1-cut  2x1 (X by Y) arrays

5. A and B are off by default. Static noise (C) is enabled together with A – crosstalk analysis.
R
Routing and DRC Fixing
CTS +
Clock routing
y
nl
Pre-routing
O
checks and setup
Route signal nets
se
Routing Check DRCs
U
Optimization Incremental Routing
al
and Reroute
rn
Routing
te
In
Signoff
s 9- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Route the Signal Nets
y
route_auto
nl
Initial routing entails global routing, track assignment and
O

detail routing – no post-route optimization
se
 To run the three phases individually:
U
route_global
al
route_track
route_detail
rn
Modify routing or crosstalk options, routing guides, or via
te

mapping rules and re-route, as needed
In
s 9- 31
sy
route_auto
[-max_detail_route_iterations num]
[-reuse_existing_global_route true | false]
op
[-stop_after_track_assignment true | false]

[-save_after_global_route true | false]
yn
[-save_after_track_assignment true | false]

[-save_after_detail_route true | false]
[-save_cell_prefix name]
rS
Fo
ed
er
i st
eg
R
Detail Route Iterations
y
 By default, route_auto performs a maximum of 40 detail route
nl
iterations to fix DRCs
O
 If your technology requires more iterations, set the value using:
se
route_auto -max_detail_route_iterations 60
U
al
rn
te
In
s 9- 32
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Check Zroute DRC Violations
check_routes
 Checks signal and clock routing for physical DRCs, NDRs, shorts, opens, antenna
y
and voltage area violations
nl
 Does not check DRCs amongst pre-routed nets only (e.g. P/G grid structure)
O
se
U
al
rn
te
In
s 9- 33
sy
Wire shapes hand-created by the designer, not associated with any net (e.g. logo, alignment marker, etc.), are
marked as type “user”, and are not checked by default. To check DRCs to these nets run check_routes -
check_from_user_shapes true.
op
check_routes outputs a summary at the end of processing. If an option is false or inappropriate, the
yn
summary reports “not checked”

rS
Verify Summary:
Total number of nets = 55984, of which 0 are not extracted

Fo
Total number of open nets = 1, of which 0 are frozen

Total number of excluded ports = 0 ports of 0 unplaced cells connected to 0 nets
0 ports without pins of 0 cells connected to 0 nets
ed
0 ports of 0 cover cells connected to 0 non-pg nets

Total number of DRCs = 0
Total number of antenna violations = no antenna rules defined
er
Information: Routes in non-preferred voltage areas = 154 (ZRT-559)

Total number of tie to rail violations = not checked
st
Total number of tie to rail directly violations = not checked

i
eg
For checking PG DRC use the command check_pg_drc.

R
Viewing Cell Internal Structures
y
nl
O
se


U
al
 By increasing the view level alone, cell internal structures will
rn
not be visible – important for understanding DRC violations
te
 You need to enable “Expanding cell types” for Standard
In
and/or Hard Macro cells s 9- 34
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Layout versus Schematic Check
 Use check_lvs to check for open, short, and floating nets

Errors can be displayed using the error browser
y

nl
check_lvs -checks all -open_reporting detailed \
O
-check_child_cells true
se
open_reporting=detailed. GUI uses
U
arrow to shows exact open location.
Short indicator
al
rn
te
In
s 9- 35
sy
check_lvs
[-nets {collection_of_nets}]
[-checks {collection_of_check_items}]
op
[-max_errors number_of_max_error]
[-check_child_cells true | false]
yn
[-exclude_child_cell_types {abstract analog black_box corner cover

diode end_cap fill filler flip_chip_driver flip_chip_pad lib_cell
rS
macro module pad pad_spacer physical_only well_tap }]

[-check_zero_spacing_blockages true | false]
[-open_reporting { bounding_box | detailed }]
Fo
[-report_floating_pins true | false]

ed
er
i st
eg
R
Detail Routing Loops
 Run additional detail route iterations at any time to fix DRC violations
y
nl
route_detail \
-incremental true
O
-max_number_iterations 50
-coordinates {{llx1 lly1} {urx1 ury1} ...}
se
With -coordinates, you can specify the routing area –
U

multiple rectangles are supported
al
rn
te
In
s 9- 36
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Change Routing Options
 Many detail route and common route options affect the

behavior of the routing
y
 Examine the various options:
nl
report_app_options route.detail.*
O
report_app_options route.common.*
se
 For example, the following controls how much effort is spent
on fixing shorts over macros:
U
al
set_app_options \
-name route.detail.repair_shorts_over_macros_effort_level \
rn
-value off|low|medium|high}
te
route_detail -incremental true; # Fix DRC violations
In
s 9- 37
sy
route.detail.repair_shorts_over_macros_effort_level: Controls the effort level applied to the
automatic repairing of shorts over macros. When the effort level is off (the default), shorts over macros are
op
repaired only during the detail routing phase, over smaller “partitions”, which can result in remaining shorts.
If the effort level is set to low|medium|high, any shorts over macros that remain after detail routing can
trigger the deletion of the involved wires and a full ECO rerouting of the involved nets (global routing, track
yn
assignment, and detail routing). Higher effort levels can increase the number of ECO repair iterations, which
might decrease the final DRC count at the expense of run time.
rS
Fo
ed
er
i st
eg
R
Rerouting Problematic Nets
 Nets that have DRC issues, huge delay due to excessive layer hopping
or crosstalk violations might benefit from being rerouted
y
nl
 Use remove_routes to remove the net routing
Use route_eco to reroute the net
O

se
 Remember that you can lock a net’s routing so that it will not be
U
touched by the router later:
al
set_attribute \
rn
-objects [get_nets <dont_reroute_nets>] \
-name physical_status \
te
-value locked
In
s 9- 38
sy
Example:
op
The following removes the global and detail routing on a specific net:
icc2_shell> remove_routes -nets I_SDRAM_TOP/abc123 -detail_route

yn
Successfully removed 31 route shapes.

rS
icc2_shell> route_eco –nets I_SDRAM_TOP/abc123

Fo
ed
er
i st
eg
R
Optimization and Reroute
CTS +
Clock routing
y
nl
Pre-routing
O
checks and setup
Optimize the design for
se
timing, crosstalk and power
Routing
U
Incremental Routing
Optimization
al
and Reroute
rn
Routing
PrimeTime/StarRC ECO
te
Using ECO Fusion
In
Signoff
s 9- 39
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Post Route Full Optimization
 Perform post-route optimization, which includes:
y
 Post route setup/hold timing optimization
nl
 Logical DRC and Area optimization
O
 ECO placement and routing
se
route_opt
U
 Power, CTO and CCD optimizations are OFF by default
al
rn
 Application options that affect route_opt start with route_opt.*
te
In
s 9- 40
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Post Route Optimizations: Power and CTO
 To enable power optimization:

set_app_options –name route_opt.flow.enable_power \
y
-value true
nl
O
 Power optimization, once enabled, is based on the scenario configuration
 Active scenario with leakage+dynamic: total power optimization 2017.09-SP2-1
se
 Active scenario with leakage only: leakage power optimization
U
 To optimize clock tree skew/latency (for classic CTS flow only)
al
after route_opt:
rn
synthesize_clock_trees –postroute \
te
-routed_clock_stage detail_with_signal_routes
In
 If CCD is enabled, the command will only fix logical DRCs
s 9- 41
sy
In releases prior to 2017.09-SP2-1, route_opt only performed leakage power optimization if
route_opt.flow.enable_power was set.
op
You may encounter the application option route_opt.flow.xtalk_reduction. This will enable router-
based net separation that can help to reduce crosstalk effects. In general, this option is no longer
yn
recommended, as it increases runtime and may not show enough QoR improvement.
rS
In previous releases you would use route_opt.flow.enable_cto to perform skew/latency optimization

within route_opt. As of 2016.12-SP4, this is no longer the case, and you need to run
Fo
synthesize_clock_trees stand-alone if this is required.

ed
er
i st
eg
R
Post Route Optimizations: CCD
 Enable concurrent clock and data optimization

to help setup timing closure:
y
nl
set_app_options –name route_opt.flow.enable_ccd \
-value true
O
Post-route CCD can be used even if classic CTS was used during clock_opt
se

 To enable CCD power recovery during route_opt:
U
set_app_options –name route_opt.flow.enable_clock_power_recovery \
al
-value none | auto | area | power
rn
 CCD power recovery works on the clock cells and registers only
te
 By default (auto), if CCD is enabled, performs power recovery, otherwise none
In
s 9- 42
sy
Even though you may not have used CCD during clock_opt, you can still enable CCD during route_opt.
Performing useful skew clock optimization might help in closing the last few picoseconds of negative setup
op
slack (currently this feature does not address hold).
Control concurrent clock and data optimization by using the common CCD application options:
yn
ccd.optimize_boundary_timing (default true)

ccd.ignore_ports_for_boundary_identification (default none)
rS
ccd.skip_path_groups (default none)

ccd.max_prepone
Fo
ccd.max_postpone
ed
er
i st
eg
R
Using PrimeTime Delay Calculation
 Use the integrated PrimeTime delay calculator in ICC II when

performing post-route timing analysis and optimization with route_opt
y
nl
 Improves accuracy and correlation with PrimeTime SI,
leading to overall faster timing closure
O
se
 PT delaycalc is enabled by default if using 2018.06 CLIBs 2018.06
U
 CLIBs must have been generated using Library Manager 2018.06
 In earlier releases, or older CLIBs, the .db files of the reference libraries must be
al
available in addition to the NDM cell libraries (see notes)
rn
 In this case, you have to enable PT delaycalc explicitly
te
In
s 9- 43
sy
PrimeTime delay calculation is built into ICC II. ICC II’s route_opt does not rely on an external PT
executable. You still use the ICC II time.* app options to control timing analysis.
op
You need to update the CLIBs to 18.06 in order to run PT delay calculation. 1806 CLIBs contain complete
timing data needed for signoff delay calculation.
yn
To use PT delaycalc in ICCII versions prior to 2018.06, or to use CLIBs that were generated using earlier
rS
versions of Library Manager, you have to ensure that you have all the necessary db files in addition to the
clibs:
Fo
• The original .db file locations are stored in the NDM cell libraries
• If the original .db locations have changed, use the search_path variable to include the new locations of
the .db files of the reference libraries
ed
icc2_shell> lappend search_path <db_locations ...>

er
i st
eg
R
Using the PrimeTime Delay Calculator during route_opt

2018.06
 All route_opt optimizations are supported with PT delay calculation
y
# Align ICCII and PT timing analysis
nl
set_app_options –name time.enable_ccs_rcv_cap -value true
set_app_options –name time.delay_calc_waveform_analysis_mode –value full_design
O
set_app_options -name time.enable_si_timing_windows -value true
se
# PT delay calculation is enabled by default if using 2018.06 CLIBs. Otherwise, enable explicitly (use dbs)
# set_app_options –list {time.use_pt_delay true}
U
# Enable optional route_opt optimizations
set_app_options –name route_opt.flow.enable_ccd -value true
al
set_app_options –name route_opt.flow.enable_power -value true
rn
route_opt
...
te
In
s 9- 44
sy
If you see the following in the log, then PT delay calculation has bee successfully enabled:
Information: Update timing is using PrimeTime delay calculation. (TIM-201)
Information: Timer using 'PrimeTime Delay Calculation, SI, Timing Window Analysis, AWP,
op
CRPR'. (TIM-050)
yn
For PT delay calculation to run by default, time.enable_ccs_rcv_cap needs to be true.

rS
Fo
ed
er
i st
eg
R
StarRC InDesign
 In addition to using Primetime delay calculation, you can also enable

StarRC signoff extraction from within ICC II
y
Transparent: Extracts your current block using the same CLIBs
nl

 Recommendation: Use in combination with PrimeTime delaycalc
O
set_app_options -name extract.starrc_mode -value true
se
set_starrc_in_design -config ./scripts/starrc_config.txt
U
SIGNOFF_IMAGE: /apps/starrc/bin/StarXtract
al
MAPPING_FILE: /…/tech/saed32nm_tf_itf_tluplus.map
CORNER_GRD_FILE: ./scripts/starrc_corner_grd.txt
rn
te
ss_125c /remote/…/saed32nm_1p9m_Cmax.nxtgrd
ff_125c /remote/…/saed32nm_1p9m_Cmin.nxtgrd
In
ff_m40c /remote/…/saed32nm_1p9m_Cmin.nxtgrd
s 9- 45
sy
StarRC extraction is not built into ICC II. ICC II calls StarRC at the path indicated in the config file as shown
above.
op
SIGNOFF_IMAGE: Pointer to StarRC executable to be invoked by ICC II

yn
MAPPING_FILE: Lists layer name mapping between TECH file and ITF file (may be called "METAL1" in tf
and "cm1" in ITF)
rS
CORNER_GRD_FILE: File that maps which nxtgrd files (used by StarRC for extraction) are associated with
which corners
Fo
Note that the paths specified in the CORNER_GRD_FILE file must be absolute paths!
ed
er
i st
eg
R
Faster QoR Convergence
 QoR (timing, DRC) convergence is rarely achieved in one route_opt run
y
nl
 A three-run approach is recommended for QoR convergence
O
 Use path-based optimization after the first round for more accurate timing analysis
Both “path” and “exhaustive” are supported
se

 Disabling soft-rule-based timing optimization during ECO routing limits spreading,
U
which can affect multiple routes and impact convergence
 Size-only is recommended for the last route_opt in the flow
al
rn
te
In
s 9- 46
sy
The above flow is used in the RM scripts available on SolvNet.
route.detail.eco_route_use_soft_spacing_for_timing_optimization: By default (true), the router
op
creates soft spacing rules in order to improve the timing. While this is good during the early stages, this can
lead to convergence issues. It is therefore recommended to turn this feature off for the second route_opt.
route_opt.flow.size_only_mode: Specifies whether the route_opt command runs in the size-only
yn
flow and avoids inserting any repeaters. The available options are footprint, equal ,
equal_or_smaller, and none. The default value is an empty string “” or none.
rS
Every route_opt includes an ECO route, to patch up broken connections. In some cases, the number of
Fo
ECO loops might not be sufficient to close DRC violations. In that case, increase the number of iterations
using the route.detail.eco_max_number_of_iterations setting.
The default value of route.detail.eco_max_number_of_iterations is -1, which means that
ed
route_opt and route_eco determine the number of iterations (route_opt performs 5 by default). The
application option route.detail.force_max_number_iterations controls whether the maximum
er
number of iterations must be run when DRCs do not converge (default is false).
i st
eg
R
Recommended route_opt Flow

# Ensure that PT delay calc is enabled, and all timing settings are aligned. You should see:
# Information: Timer using 'PrimeTime Delay Calculation, SI, Timing Window Analysis,
AWP, CRPR'. (TIM-050)
y
# Optionally, enable StarRC extraction:
nl
# set_app_options -name extract.starrc_mode -value true
O
...
route_opt
se
set_app_options –name time.pba_optimization_mode –value path
set_app_options –value false \
U
-name route.detail.eco_route_use_soft_spacing_for_timing_optimization
al
route_opt
rn
set_app_options -name route_opt.flow.enable_ccd -value false
set_app_options –name route_opt.flow.enable_power -value true
te
set_app_options -name route_opt.flow.size_only_mode -value equal_or_smaller
In
route_opt
s 9- 47
sy
Path based optimization is off by default (value: none). To enable, se the app option to path or exhaustive.
When you specify path, path-based analysis is applied to the worst GBA path to each endpoint. When you
specify exhaustive, an exhaustive path search algorithm is applied to determine the worst pba path to an
op
endpoint. To avoid long runtimes and memory increases, consider running pba optimization when the design is
ready for signoff. Initial iterations can be done with 'path' mode, which gives the best total power savings with
yn
the fastest path-based analysis runtime. Final passes can be done with the computationally more expensive
'exhaustive' mode. The app-option currently applies only for route_opt with PrimeTime Delay Calculation
rS
enabled. This app-option does not change the behavior of any analysis or report command. To get PBA timing
reports, you are expected to use the pba_mode option available in report_qor, report_timing and
report_global_timing.
Fo
The above flow is used in the RM scripts available on SolvNet.

route.detail.eco_route_use_soft_spacing_for_timing_optimization: By default (true), the router creates soft
ed
spacing rules in order to improve the timing. While this is good during the early stages, this can lead to
convergence issues. It is therefore recommended to turn this feature off for the second route_opt.
er
route_opt.flow.size_only_mode: Specifies whether the route_opt command runs in the size-only flow and
avoids inserting any repeaters. The available options are footprint, equal , equal_or_smaller, and none. The
st
default value is an empty string “” or none.

i
eg
Every route_opt includes an ECO route, to patch up broken connections. In some cases, the number of ECO
loops might not be sufficient to close DRC violations. In that case, increase the number of iterations using the
R
route.detail.eco_max_number_of_iterations setting.
The default value of route.detail.eco_max_number_of_iterations is -1, which means that route_opt and
route_eco determine the number of iterations (route_opt performs 5 by default). The application option
route.detail.force_max_number_iterations controls whether the maximum number of iterations must be
run when DRCs do not converge (default is false).
ECO Fusion
 Blends IC Compiler II, StarRC and ECO Fusion

PrimeTime in a single, ICCII-native
y
invocation system
IC Compiler II
nl
 Accelerates implementation closure
O
route_opt
se
set_pt_options
Set up
set_starrc_options
StarRC &
U
PrimeTime ECO
al
Execute eco_opt
rn
Signoff
te
Report check_pt_qor
In
s 9- 48
sy
op
yn
rS
Fo
ed
er
i st
eg
R
ECO Fusion Workflow
• Extract parasitics and generate PT run files
y
nl
• Run PT update_timing with DMSA
Build
O
Signoff
eco_opt view • Execute specified optimization flow (e.g. setup, hold)
se
• Generate ECO changelist
Perform
optimization
U
• Source ECO changelist in ICCII
• Execute ECO place & route in ICCII
al
ICCII
rn
ECO
te
In
Licensing: Requires the RTL2GDS Advanced Fusion Add-on key 9- 49
s
sy
DMSA = Distributed Multi-Scenario Analysis
op
yn
rS
Fo
ed
er
i st
eg
R
Example Flow
… after completing 3-run route_opt approach …
y
nl
# Set up PrimeTime. Liberty DBs required – add to search_path
O
lappend search_path "/remote/…/DBs"
set_pt_options -pt_exec /apps/pt/pt_2018.06-SP2/bin/pt_shell
se
# Set up StarRC signoff extraction
U
set_starrc_options -config ./scripts/starrc_config.txt (same file as shown earlier)
al
eco_opt -types "setup hold" -pba_mode path -physical_mode open_site
rn
# Generate timing reports. Do NOT use report_qor/report_timing
te
check_pt_qor -pba_mode path
In
s 9- 50
sy
Using set_pt_options, you configure the path to the PrimeTime executable. Optionally, you can select the host options
that were set up using set_host_options for the PT runs. In addition, you can select Tcl scripts that should be sourced before
op
and after the design has been linked in PT, the ECO work directory, as well as the buffers to use for hold time fixing.
eco_opt can optimize for all PT ECO types, specifically timing (setup, hold), drc (max_transition, max_capacitance),
yn
leakage_power, dynamic_power, total_power, max_clock_transition, useful_skew, noise.

eco_opt
rS
[-types type_names]
[-pba_mode mode_name] Path-based analysis mode. Values: none, path, exhaustive (Default is none)
[-physical_mode mode_name] PrimeTime ECO physical mode. Values: occupied_site, open_site (Default is open_site))
Fo
[-setup_margin margin] /
[-hold_margin margin] Specifies an additional setup/hold margin for fixing
[-port_punch] Perform port punching for max_transition violation fixing
ed
[-sequential_sizing] Fixing is performed by sizing sequential cells to fix violations

[-eco_script file_name] TCL script file for customized PrimeTime ECO
er
[-write_change_file_only] Write PrimeTime ECO changes to a file but do not source it in ICC II
[-no_eco_place_and_route] Do not perform ICCII ECO place and route
st
[-save_session directory] Write PT sessions to specified directory

i
eg
R
Notes on ECO Fusion
 In order to analyze PrimeTime’s timing results from within ICC II,

always use check_pt_qor
y
nl
 Accesses PrimeTime to generate reports
O
check_pt_qor -pba_mode path
se
check_pt_qor -max_paths 5 -to regB
U
 StarRC parasitics are written by StarRC, stored on disk and used by
al
PrimeTime – they are not loaded into ICC II
rn
 Do not use ICCII’s update_timing/report_qor – this will trigger ICC II
extraction and STA
te
In
s 9- 51
sy
check_pt_qor supports the full set of PT reports:
-significant_digits
-nosplit
op
-group
-to / -rise_to / -fall_to
-from / -rise_from / -fall_from
yn
-through / -rise_through / -fall_through

-exclude / -rise_exclude / -fall_exclude
-nworst
rS
-max_paths
-unique
-slack_lesser_than / -slack_greater_than
Fo
-start_end_pair
-path_type
-input_pins / -nets
-transition_time / -capacitance
ed
-crosstalk_delta
-derate / -variation
-exceptions
er
-voltage
st
check_pt_qor # Check and show PrimeTime timing and power QoR

[-type type_name] QoR type.
i
Values: global_timing, scenario_timing, summary, max_delay,

eg
min_delay, max_transition, max_capacitance, power, noise

[-pba_mode pba_mode] Path-Based analysis mode: Values: none, path, exhaustive
[-save_session directory] Save PT sessions to specified dir
R
[-reset] Stop PrimeTime sessions)
Unit Summary
y
 Perform pre-routing checks and setup
nl
 Route the signal nets using route_auto
O
 Report and fix DRC violations
se
 Optimize the design using route_opt
U
 Use ECO Fusion for faster timing signoff
al
rn
Lab after lecture 11
te
In
s 9- 52
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix
y
nl
O
Repeatability
Redundant Via Insertion – details
se
Custom via mapping tables and via prioritization
U
Wire spreading / widening
al
Routing Blockages in ICC vs. ICC2
rn
Antenna violations
te
In
s 9- 53
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Notes on Repeatability
 Routing is non-deterministic when multi-threaded, so for repeatable results must use:

set_host_options -max_cores 1
y
 This will drastically increase runtime, and is not recommended
nl
 The global router can be made deterministic even with multiple threads
O
route.global.deterministic Default: false
se
 place_opt is deterministic by default
U
place_opt.flow.repeatability Default: true
al
 Temporarily sets route.global.deterministic to on during place_opt
rn
 Routing during clock_opt can be made deterministic with:
te
clock_opt.flow.repeatability Default: false
In
s 9- 54
sy
Setting clock_opt.flow.repeatability to true uses deterministic multi core global routing and
switches to single core detail routing to ensure repeatability.
op
To disable single core detail routing and save runtime:

set_app_options –name clock_opt.flow.repeatability –value false
set_app_options –name route.global.deterministic –value on
yn
Explicitly turn on single core if there is a standalone route_group command in your clock_opt flow.
rS
Fo
ed
er
i st
eg
R
Enabling Post-Route Redundant Via Insertion

 Setting the post-detail route option below enables via
optimization after each detail routing change
y
nl
route.common.post_detail_route_redundant_via_insertion medium }
O
...
# Via optimization happens after any detail route
se
# changes from the following commands:
route_auto
route_opt
U
route_detail -incremental true
route_eco ...
al
rn
 Replaces single-cut vias with two-cut via arrays, by default,
as long as no DRC violations are introduced
te
 For 28nm and below it is recommended to create a custom “via
In
mapping table” (discussed next) s 9- 55
sy
Setting the route.common.post_detail_route_redundant_via_insertion option to medium
prior to any routing operation is equivalent to explicitly executing add_redundant_vias after the same
op
routing operations.
Increasing the effort level to high can increase the via conversion rate by an additional 3 to 5 percent by
yn
shifting the vias to make room for additional vias. However, because high-effort via optimization may move
the vias more, it can result in a less lithography-friendly pattern at the 45-nm technology node and below. In
rS
this case, you should use concurrent soft-rule-based via optimization to improve the via conversion rate.
Fo
ed
er
i st
eg
R
Custom “Via Mapping” Table
 The router generates a default via mapping table

(1-cut  2-cut arrays) from the tech file
y
 Check the default mapping, and if OK, proceed with routing
nl
add_redundant_vias -list_only true
O
 Create custom via mapping rules, if needed,
to improve conversion rates:
se
add_via_mapping -transform rotate \
U
-from {VIA12SQ_C 1x1} \
-to {VIA12BAR 1x1}
al
add_via_mapping ...
rn
 Some vias may be better for DFM, while others are better for routability
te
 Use -weight option to set priorities (integer 1-10)
Use -from_icc_file to read redundant via definitions written in ICC syntax
In

s 9- 56
sy
Use report_via_mapping to check the manually defined mappings.
Use remove_via_mappings to remove some or all via mapping definitions.
op
By default, the router automatically maps all single “contact code” vias, defined in the technology file, to 2-
by-1 (x-by-y) arrays of contact codes with “isDefaultContact = 1”. All mappings
yn
have an equal “weight” of 1.

rS
-transform all | flip | none | rotate

Specifies the types of rotated via arrays that can be used during signal routing and redundant via insertion.
Fo
The definition for each mode is:

• none : Do not rotate or swap via arrays.
• flip : Use 1 x N and N x 1 via arrays as rotated equivalent vias.
ed
• rotate : Rotate line via arrays instead of flipping (swapping row and column numbers).
• all : Use all four possible via arrays. This option is the default.
er
By default all mappings or conversions have the same priority. Alternatively, specify preferred via mappings
st
using the -weight option and assigning a weight value (1-10) to each mapping definition. During via
optimization, the router will try the higher weighted conversions first.
i
eg
R
Example: Prioritizing Vias for DFM
 For DFM, assume preference order: VL > VB > VS

 Convert single vias to double-vias, in that order
y
 If single vias remain, replace with single vias, in that order
nl
 A single VL is preferred over a double VB or VS
O
 A single VB is preferred over a double VS
 Example for Via 1 layer… add others as needed
se
add_via_mapping -transform all –from {VL1 1x1} –to {VL1 1x2} –weight 5
U
add_via_mapping -transform all –from {VB1 1x1} –to {VL1 1x2} –weight 5
add_via_mapping -transform all –from {VS1 1x1} –to {VL1 1x2} –weight 5
add_via_mapping -transform all –from {VB1 1x1} –to {VB1 1x2} –weight 4
al
add_via_mapping -transform all –from {VS1 1x1} –to {VB1 1x2} –weight 4
add_via_mapping -transform all –from {VS1 1x1} –to {VS1 1x2} –weight 3
rn
add_via_mapping -transform all –from {VB1 1x1} –to {VL1 1x1} –weight 2
te
add_via_mapping -transform all –from {VS1 1x1} –to {VL1 1x1} –weight 2
add_via_mapping -transform all –from {VS1 1x1} –to {VB1 1x1} –weight 1
In
s 9- 57
sy
VL = Large square via; VB = Bar via; VS = Small square via
op
yn
rS
Fo
ed
er
i st
eg
R
Concurrent Soft-Rule-Based Via Optimization
 Via optimization rates can be improved by reserving space during initial

route, followed by post-route insertion:
y
nl
route.common.post_detail_route_redundant_via_insertion medium
O
route.common.concurrent_redundant_via_mode reserve_space
route.common.concurrent_redundant_via_effort_level medium }
se
...
route_auto
U
route.common.concurrent_redundant_via_mode off }
al
Reserving space increases routing runtime
rn

 Suggestion: Use this method when improved via conversion rates are needed
te
beyond that provided by post-route via optimization, and the post-route approach
resulted in a via conversion rate of at least 80%
In
s 9- 58
sy
Since routing is rarely done in one pass, it is recommended to try the post-route via optimization algorithm
for the first-pass of routing, and to analyze the resulting conversion rates. If the rates are not acceptable, then
op
try the “reserve space” algorithm during the next routing pass. If the conversion rates are still not high
enough, “hard-rule” based via optimization can be enabled during the next routing pass (see next page).
yn
The “80%” number on this page (and 90% on the next page) are not hard “rules”, but serve as a rough
guidance. The point to consider is that, if post-route via optimization yields a conversion rate much lower
rS
than 80% or so, the concurrent algorithm(s) may increase run time dramatically, without a worthwhile
increase in conversion rates.
Fo
After routing the design with route_auto, it is recommended to turn off concurrent via optimization.
Leaving it enabled will make DRC fixing in later detail route iterations more difficult.
ed
er
i st
eg
R
Concurrent Hard-Rule-Based Via Optimization
 Via optimization rates can be maximized to near 100%

by forcing insertion during initial route
y
Use soft-rule-based via optimization during ECO routing to preserve the
nl

conversion achieved during initial routing
O
set_app_options -category route.common -list {
post_detail_route_redundant_via_insertion medium
se
concurrent_redundant_via_mode insert_at_high_cost
concurrent_redundant_via_effort_level high
U
eco_route_concurrent_redundant_via_mode reserve_space
eco_route_concurrent_redundant_via_effort_level high }
route_auto
al
rn
 Concurrent hard-rule based via optimization can result in large runtime
increase in congested designs
te
 Suggestion: Use when maximum conversion rate is required, and the soft-rule-
In
based approach resulted in a conversion rate of at least 90%
s 9- 59
sy
Note: Since concurrent hard-rule based via optimization is intended to achieve near 100% optimized vias, it is
important to use this technique only if the standard cell pins are designed to accommodate double vias or bar
op
vias. If, for example, the pins can only accommodate small square vias, and you force hard insertion, the
router will try to insert double or bar vias on the pin and will generate DRC errors. Hard insertion should only
be used when that is a required design technique and the floorplan and libraries support it.
yn
rS
Fo
ed
er
i st
eg
R
Random Particle Defects
 Random particle defects during manufacturing may cause shorts or

opens during the fabrication process
Wires at minimum spacing are most susceptible to shorts
y

nl
 Minimum-width wires are most susceptible to opens
O
se
U
Center of conductive defects within Center of non-conductive defects within
critical area – causing shorts critical area – causing opens
Metal 3
al
rn
Critical Areas
te
Center of conductive defects Center of non-conductive defects
In
outside critical area – no shorts outside critical area – no opens
s 9- 60
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Reduce Short/Open Critical Area
spread_wires \
-timing_preserve_setup_slack_threshold 0.1 \
-timing_preserve_hold_slack_threshold 0.1
y
widen_wires \
nl
-timing_preserve_setup_slack_threshold 0.1 \
O
-timing_preserve_hold_slack_threshold 0.1
se
U
Wire Tracks Spreading off-track
by ½ pitch
al
rn
te
Widening up to
In
1.5x default width s 9- 61
sy
spread_wires
[-timing_preserve_nets] (collection of nets to skip to preserve timing)
[-timing_preserve_setup_slack_threshold]
op
(skip nets with worst setup slack less than this threshold)
[-timing_preserve_hold_slack_threshold]
yn
(skip nets with worst hold slack less than this threshold)
[-min_jog_length] (min jog length in layer pitch unit on preferred direction, default is 2)
rS
[-min_jog_spacing_by_layer_name] (specify layer name and min jog spacing)

[-pitch <real>] (Number of pitches to spread on either side of the wire, default is 0.5)
Fo
widen_wires
[-timing_preserve_nets] (collection of nets to skip to preserve timing)
ed
[-timing_preserve_setup_slack_threshold]
(skip nets with worst setup slack less than this threshold)
er
[-timing_preserve_hold_slack_threshold]
(skip nets with worst hold slack less than this threshold)
st
[-spreading_widening_relative_weight] (balance weight between wire spreading (> 0.5) and

widening (< 0.5): Range: 0 to 1; Default = 0.5
i
eg
[-widen_widths_by_layer_name] (specify layer name and valid widen widths)

R
Routing Blockages – Comparison to IC Compiler
IC Compiler II blockages
IC Compiler blockages
y
Object Commands
nl
Real metal or via blockage Shape on metal or create_shape
(shape without net id on metal via layer remove_shapes
O
or via layer)
Regular metal or via blockage Routing blockage create_routing_blockage
se
remove_routing_blockages
System metal or via blockage N/A N/A
U
(rectangle on system reserved
blockage layer, layer 218,
219… 224, 225…)
al
Route guide (no-signal route N/A N/A
rn
guide on layer 190)
Zero-minimum-spacing Blockage with zero create_routing_blockage
te
route guide minimum spacing -min_spacing 0
In
s 9- 62
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Routing Blockages (Continued)
Blockage modeling is the same in both the

frame view and the top-level design
y
nl
O
Type Object DRC check
Real metal or via Shape on metal or Apply all DRC rules
se
blockage via layer
Regular metal or via Blockage with Apply all DRC rules;
U
blockage unset minimum basically treat as real metal or
spacing via but do not write into GDS file
al
Zero-minimum- Blockage with zero Check for overlap
spacing metal or via minimum spacing
rn
blockage
te
In
s 9- 63
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Antenna Violations
 As the total area of a wire increases during processing, the
voltage stressing the gate oxide increases
 Antenna rules define acceptable total areas of wires
y
nl
Oscillating + + + + + + + + + +
charges in
O
plasma etchant Protective coating
- - Metal 3 - -
- Metal 2 -
se
Oxide - Metal 1 -
- Poly -
U
Substrate
Damaged gate oxide
al
Antenna Ratios:
rn
gate Area of Metal Connected to Gate
Combined Area of Gate
te
Or
poly Area of Metal Connected to Gate
diffusion Combined Perimeter of Gate
In
s 9- 64
sy
Metal wires (antennae) placed in an EM field generate voltage gradients and during the metal etch stage,
strong EM fields are used to ionize the plasma etchant causing voltage gradients at MOSFET gates can
op
damage the thin oxide.
The ASIC vendor will specify antenna design rules in terms of allowable ratios of antenna metal to gate oxide.
yn
Basic Antenna rules are:

rS
(antenna-area) / (gate-area) < (max-antenna-ratio)

Gate-area:
Fo
Boolean AND (or intersection) of the ‘poly’ and the ‘diffusion’ layers
Recognized as the gate area of the transistors by essentially all foundries
Antenna-area:
ed
Amount of metal area attached to the input pin

Calculation method varies for different processes
er
Max-antenna-ratio:
Represents max allowed ratio of antenna area to gate area
st
Calculation method varies for different processes

i
eg
R
Fixing Antenna Violation by Layer Jumping
Before layer jumping
metal 3 M3 blockage
y
nl
M1 gate
blockage metal 1
poly
O
Unacceptable antenna area
driver
diffusion
se
U
M1 is split by
jumping to
After layer jumping, to meet Antenna rules M3 and back
al
metal 3 M3 blockage metal 3
rn
M1 gate
blockage metal 1
poly
te
driver
Acceptable antenna area
In
diffusion
s 9- 65
sy
Until the top metal 3 link is in place, the metal 1 wire can generate large voltage gradients that may damage
the gate oxide. This method of fixing antenna rule violations uses jumps in metal layers to keep the total
op
length of lower level metal traces that are directly connected to polysilicon gates below maximum. Once the
top metal ‘link’ is in place and the polysilicon gate is connected to its driver, it is relatively safe. The pn
junction of the source/drain of the driver will help shunt large voltage swings – it acts like a reverse-biased
yn
diode.
rS
This is the preferred method for fixing antenna problems. Antenna violations that cannot be fixed by this
method must be provided with special shunting diodes. These diodes use up additional silicon placement and
Fo
metal routing resources, which may be challenging – diode insertion is therefore the second choice, over
layer jumping, to address antenna violations.
ed
Run an Search and Repair to fix antenna violations. The search & repair engine will reroute antenna violators
adding multiple jumps to the long traces.
er
i st
eg
R
y
nl
O
se
U
al
rn
te
In
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Agenda
DAY
y
nl
8 Setting Up CTS
O
se
U
al
11
rn
Signoff
te
In
s 10- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Top Level Implementation © 2019 Synopsys, Inc. All Rights Reserved. 10-1
Objectives
y
nl
O
 List the steps necessary for top-level implementation
se
 Describe what an abstract is and what it contains
 Describe how to assemble the top-level design
U
al
rn
te
In
s 10- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Top Level Implementation
 When implementing the top level, blocks can be design views,

or they can be abstracted by using a block abstract or an ETM
y
 Design views are OK up to 100k gates
nl
Top.design
 Block abstracts can be generated in ICCII
and are the preferred choice
O
.abstract /
.design
 ETMs can provide memory and runtime
se
CLK
benefits for very large designs
 Also useful for IP that needs to be hidden CLK
U
(ETM)
al
.abstract
 The blocks can be at any design phase CLK

/.design
CLK
rn
 Placed
Clocks completed
te

 Completely routed and optimized
In
s 10- 3
sy
By “implementing the top level” we mean performing placement, CTS and routing along with all
optimizations at the top level of a physically hierarchical design.
op
After the models have been instantiated, there’s no difference between implementing a block and the top-
level. Everything presented in the previous units applies to the top-level as well.
yn
rS
Fo
ed
er
i st
eg
R
Using Completely Implemented Blocks
 All blocks are completely implemented first

 Top-level is implemented afterwards
y
Block-Level
Block-Level Flow
Block-LevelFlow
Flow
nl
O
Placement and Optimization Top-Level Flow
se
Clock Tree Synthesis Placement and Optimization
Abstract / ETM + Frame
U
Post-CTS Optimization Clock Tree Synthesis
al
Post-CTS Optimization
rn
Route
Route
te
Postroute Optimization
In
s 10- 4
sy
In a serial flow, you implement all blocks entirely, then generate models from the fully routed and
implemented blocks.
op
Then the top-level implementation starts by using the models from the fully implemented blocks.
yn
rS
Fo
ed
er
i st
eg
R
Parallel Blocks and Top Implementation

 For each implementation step at the top-level, use a block for
which the same or subsequent implementation step is completed
 For example:
y
Block-Level
Block-Level Flow
Block-LevelFlow
Flow place_opt on blocks complete  perform place_opt at top
nl
O
Placement and Optimization Top-Level Flow
se
Abstract / ETM + Frame
Clock Tree Synthesis Placement and Optimization
U
Post-CTS Optimization Clock Tree Synthesis
al
Post-CTS Optimization
rn
Route
Route
te
In
s 10- 5
sy
In a parallel flow, you don’t wait until all blocks have been fully implemented, instead you complete the first
step (place_opt) for all blocks, then you pass the place_opt models to top-level place_opt. Then you
op
perform CTS on all blocks, and you pass on CTS-models for top-level CTS, etc.
Of course, you can always use a model from a later block stage to perform an earlier stage at the top-level, for
example use post-CTS models to perform place_opt at the top.
yn
rS
Fo
ed
er
i st
eg
R
Extracted Timing Model (ETM) Top.design

Extracted
Timing Model
IN
IN Setup & Hold Arc
OUT
 Timing model derived from block design data Clock to out Arc
CLK
y
CLK CLKOUT
CLK2
nl
CLK2
Feedthrough Arc
 Generated in PrimeTime
O
 For more information about generating the model, see
PrimeTime User Guide > Hierarchical Analysis > Extracted Model Options
se
U
 Can be used to model IP blocks, where internal details need to be hidden
al
rn
For more information about using ETMs at the top level, see
te
SolvNet article 2284429: Top-level Closure Flow With Extracted Timing Models
In
s 10- 6
sy
When generating an ETM in PrimeTime, use the following variables settings to store the clock path delays in
the ETM:
set extract_model_with_clock_latency_arcs true
op
set extract_model_clock_latency_arcs_include_all_registers false

PrimeTime stores the longest and shortest clock path delay to the interface registers using the
yn
max_clock_tree_path and min_clock_tree_path arcs on the clock pin.

The timing arcs for clock feedthroughs are also stored.
rS
Fo
ed
er
i st
eg
R
Abstract View Abstract View (.abstract)
A X
B Y
 Partial netlist view derived from design view
y
CLK
nl
O
 Much smaller than design view, therefore leads to much better
performance when implementing the top-level
se
U
 Can include the following additional information:
al
 Clock exceptions
Crosstalk data
rn

 Power information (leakage and/or dynamic)
te
 Signal EM data
In
s 10- 7
sy
For routed blocks, if signal integrity analysis is enabled, the following crosstalk data is included:
• For each net included in the abstract, its aggressor nets are also retained
op
• For each aggressor, the following information is included

• Coupling capacitance between the victim and aggressor
• Driver of the aggressor net.
yn
• If any of the inputs of the driver are dangling, transition time is also annotated
rS
Fo
ed
er
i st
eg
R
Creating an Abstract
 To create an abstract:
y
create_abstract -read_only
nl
O
 Identifies and retains interface logic across all active modes
 Retains pins in the interface that have timing constraints
se
 across all modes, active and inactive
U
 Retains RC parasitics of all corners (active and inactive)
 Stores UPF information relevant to the retained interface logic
al
 Promoted to the top level during linking
rn
Ensure that all the scenarios used at top level are defined
te
and active while creating an abstract
In
s 10- 8
sy
By default, if you run create_abstract, the design view is locked, and the abstract view becomes
editable. This is useful when performing hierarchical design planning. For top-level implementation, keep the
op
designs writable and lock the abstracts instead.
If there is a mismatch between the modes/corners/scenarios defined at the top vs. the blocks, you will need to
yn
use the command set_block_to_top_map to define the relationships (what top-level mode corresponds to
what block-level mode etc.)
rS
Fo
ed
er
i st
eg
R
Frame View
Frame View (.frame)
y
 The frame view is the physical abstraction
nl
required by the router, including the virtual router
O
 You must create a frame view for each sub-block
se
create_frame
U
 By default (for design blocks) complete routing blockages are only created for
the layers used in the block (corresponds to -block_all used_layers)
al
 To block all layers, use: create_frame -block_all true
rn
te
In
s 10- 9
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Keep Everything in the Abstract

# Enable SI in order to store crosstalk data in the abstract:
# Power information is only stored for active scenarios that are enabled for
y
# leakage power, dynamic power, or both
nl
set_scenario_status -leakage_power true -dynamic_power true \
[get_scenarios –filter active]
O
set_app_options -name abstract.annotate_power -value true
# In order to use the abstract for signal electromigration analysis:
se
set_app_options -name abstract.enable_signal_em_analysis -value true
U
# You can create an abstract with StarRC parasitics:
al
# You can use PrimeTime for timing analysis to calculate the critical paths:
rn
set_app_options -name time.use_pt_delay -value true
te
create_abstract -read_only
In
create_frame -block_all true
s 10- 10
sy
• Power information is only stored for objects that are removed during abstraction
• When the abstract is instantiated in the top level
op
• Power for the cells in the abstract is recomputed, in context, based on the switching activity and
loading seen from the top level.
• If the activity information or boundary loading information is different between the block and the
yn
instantiation of that block in the top level, it is therefore possible that the power reported at the top
level differs from the power reported in the block
rS
• Power for cells removed during abstract creation is retrieved directly from the abstract
Fo
At the time of abstract creation, the following information is copied to the abstract view as well:
• Nondefault routing rule definitions
• For the nets that are retained in the abstract view:
ed
• Their NDR association and

• The minimum and maximum layer constraints, if any
er
StarRC parasitics:
st
When the abstract is used at the top-level, ICC II performs parasitic extraction of the top-level nets and
stitches it with the StarRC extracted parasitics stored in the abstracts.
i
eg
During abstract creation, PT can be used to determine the slowest and fastest paths to/from the outputs/inputs.
R
These are kept in the default, “compact”, BA.

PT delay calculation at the top level:
ICC II stitches the parasitics stored in the abstract with the parasitics of the nets at the top level.
Timing is then calculated using the PrimeTime delay calculator.
At the Top-Level (1 of 2)
 After you have generated abstract and frame views for all blocks:
y
 Add the sub-block design libraries containing the abstracts to your top level
nl
library reference list:
O
set_ref_libs -add "MYBLOCKS/A.dlib MYBLOCKS/B.dlib ..."
se
 Use the abstracts generated at the end of block implementation:
U
change_abstract -label route_opt \
al
-references {BLENDER_0 BLENDER_1 SDRAM_TOP}
rn
 The corresponding frame views are automatically loaded
te
In
s 10- 11
sy
Swapping of abstracts
Use the change_abstract command to swap abstracts while preserving the cross-boundary timing
constraints. For example to swap to the abstract created after the clock_opt command:
op
change_abstract –label clock_opt –references block1

To take advantage of the benefits of the change_abstract command, you must use labels when saving the
yn
intermediate versions of the design during block and top implementation

rS
Changing from abstract view to design view

Remove the existing timing constraints
Fo
remove_scenarios –all; remove_modes –all; remove_corners –all

Use the change_abstract command to change from abstract view to design view
change_abstract –view design –references <block_reference>
ed
Apply full-chip scenario creation script

source full_chip_scenario_creation.tcl
er
Why do you need to remove all timing constraints before changing to design view, and then re-apply them?
st
Internal constraints may be missing in ABSTRACT constraints, therefore, you need to re-apply the FULL set
of constraints.
i
eg
R
At the Top-Level (2 of 2)
 Verify that you have the correct abstracts

icc2_shell> report_abstract
y
Abstract_Design Design_Type Abstract_Type Editable Compression
nl
SDRAM_TOP.dlib:SDRAM_TOP/route_opt module timing,compact no 68.79
BLENDER_1.dlib:BLENDER_1/route_opt module timing,compact no 76.19
O
BLENDER_0.dlib:BLENDER_0/route_opt module timing,compact no 74.83
se
 Promote clock related data from the lower levels to the top
 Use the following command to promote the clock balance points from the lower-
U
level physical hierarchy
al
icc2_shell> promote_clock_data -balance_points
rn
Information: Promoting clock_data for instance 'I_SDRAM_TOP'. (CSTR-430)
te
 Skip this step if the clock exceptions that you apply at the top level also include the
needed balance points for the pins inside the physical hierarchy
In
s 10- 12
sy
The promote_clock_data command causes specific clock data from lower levels of the physical
hierarchy to be applied to the top level. The data includes mesh annotations set using
set_annotated_delay and set_annotated_transition commands and CTS balance points set
op
using set_clock_balance_points command. The promoted data is added to any data that is already
applied to the top-level design.
yn
You should consider using this command when:

• The annotations and balance points of a lower level block have changed locally and you want to see this
rS
data during top-level analysis

• You have changed the design view of your lower-level block from “abstract” to “design”, and your current
Fo
data only covers the abstract part of the block
Note that in order for promote_clock_data to work you need to have the design views available in the
ed
library as well, in addition to the abstracts.

er
Promoting set_voltage from subblocks to the top level (automatic) also requires design views to be
available in the design libraries. When this is the case, for supply nets corresponding to a voltage area that is
st
isolated from the top level, ICC II promotes the supply voltage
Information: Automatically promoting voltage 0.95 for supply net 'u0_1/VDDS_MIB'
i
eg
in corner RCworst from the block constraints of 'my_blk'. (CSTR-038)

When the design view is not present, you must specify the voltage using the set_voltage command from
the top level
R
Check the Design
 As usual, run check_design to ensure implementation readiness
y
check_design -checks hier_timing
nl
hier_pre_placement
hier_pre_clock_tree
O
hier_pre_route
se
...
TL-101 Error 1 Missing %view view for block reference %block in library %lib.
TL-107 Error 3 Abstract view of block reference %block created using non-recomm...
U
TL-111 Error 1 Missing core area in block %block. Can not run top-level timing ...
TL-115 Error 1 Internal Consistency Failure. Voltage area %voltageAreaStr does ...
TL-116 Error 1 Internal Consistency Failure. Internal voltage area %voltageArea...
al
TL-126 Error 33 Missing physical location for %msgStr %port of block reference %...
TL-130 Error 1 Missing location of block instance %inst (Reference: %block) in ...
rn
...
 In addition, a number of implementation commands (e.g. place_opt)
te
will generate Errors if hierarchy issues are encountered
In
s 10- 13
sy
The following commands will generate hierarchy related Errors (as of 2016.12):
create_buffer_tree, remove_buffer_tree, create_placement, refine_placement,
place_opt, refine_opt, or clock_opt
op
yn
rS
Fo
ed
er
i st
eg
R
Implement the Top
 The ICC II Hierarchical Place and Route Reference

Methodology (ICC2-HIER-PNR-RM) provides Top-Level Flow
y
reference methodology scripts for performing place
nl
and route for each level of the physical hierarchy Placement and Optimization
O
 Supports place and route using abstracts and extracted
Clock Tree Synthesis
timing models (ETMs)
se
 Uses the same scripts and supports all the flows as the Post-CTS Optimization
U
Flat Place and Route Reference Methodology (ICC2-
FLAT-PNR-RM) Route
al
 Supports designs with multiple levels of physical hierarchy
rn
 For more information, see the training at: Postroute Optimization
te
In
s 10- 14
sy
op
yn
rS
Fo
ed
er
i st
eg
R
y
nl
 List the steps necessary for top-level implementation
Describe what an abstract is and what it contains
O

 Describe how to assemble the top-level design
se
U
al
rn
te
In
s 10- 15
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Appendix
y
nl
O
Clock Tree Modeling in Abstracts
Attributes to Identify the Hierarchy Owner
se
U
al
rn
te
In
s 10- 16
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Clock Tree Modeling in Abstracts Interface Registers

Generated Clock
Source
Sink for minimum and
Clock Source (PLL)
maximum clock path
 Clock-tree information is retained in the abstract, OUT1
which is needed to perform CTS, timing analysis,
y
IN1
OUT2
and optimization at the next level above:
nl
OUT3
1) Clock connections to identified interface logic ( ) OUT4
O
1)
2) Longest and shortest clock paths for each clock pin. 1)
For a clock defined on multiple block pins, paths are CK
se
retained for each clock pin ( ) 2)
3) Clock feedthroughs ( )
U
2)
4) Connection from master clock to generated clock, for all 3)
al
generated clocks that clock interface registers ( ) CKOUT
IN2
5) Connection from the clock to the port, for each internal
rn
4)
clock. During this, the tool traces through any
sequential cells in the path ( ) 5)
te
CK2OUT
In
s 10- 17
sy
Contents of an abstract:
Netlist
• Data Path
op
• Critical setup and hold interface timing paths

• Feedthroughs
yn
• Interface logic cells that have timing constraints

• Clock Path
• Longest and shortest clock paths for each clock pin
rS
• Clock connections to already identified interface logic

• Clock feedthroughs
Fo
• For generated clocks clocking interface registers, the connection from master clock to generated clock
• For internal clocks, the connection from the clock to the output port
Physical data
ed
• Placement information of cells and pins

• Blockages, site rows, voltage areas, and net nondefault routing rules
Constraints and timing data
er
• Parasitic information
• Crosstalk data
st
• Transition and case values on dangling pins

i
• Clock tree exceptions

eg
Multivoltage and UPF

• Power management cells
R
• UPF associated with interface logic

Power annotation
Signal EM information
Attributes to Identify the Hierarchy Owner
y
Attribute Values
nl
O
Object parent_block parent_cell parent_block_cell
wire1 TOP NULL NULL
se
U2/U3/wire2 C U2/U3 U2/U3
U
U4/U5/wire3 D U4/U5 U4
U1/X1 TOP U1 NULL
al
U2/U3/Y1 C U2/U3 U2/U3
rn
U4/U5/Z1 D U4/U5 U4
te
In
s 10- 18
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Agenda
DAY
y
nl
8 Setting Up CTS
O
se
U
al
11
rn
Signoff
te
In
s 11- 1
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Signoff © 2019 Synopsys, Inc. All Rights Reserved. 11-1


Synthesis
y
nl
O
se
U
CTS & Optimization
al
rn
te
Signoff This Unit
In
s 11- 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Signoff / DFM
 After route_opt has completed, there are several tasks that are
required, and some that might be required
y
nl
 Required:
O
 Sign-off Extraction and STA, with possible ECO
 Sign-off DRC
se
 Filler cell insertion (fill gaps between standard cells)
U
 Metal Filling (fill metal layers for CMP)
 Possibly required:
al
 Functional ECO (pre- or post-freeze-silicon)
rn
te
In
s 11- 3
sy
DFM = Design For Manufacturing
CMP = Chemical Mechanical Polishing
op
yn
rS
Fo
ed
er
i st
eg
R

Signoff / DFM Tasks
route_opt
y
nl
Manually, or using
Timing ECOs (PT/StarRC) ECO Fusion
O
Functional ECOs
se
Can occur anytime
Filler cell insertion
U
al
Signoff DRC checking / fixing (ICV)
rn
Since flow uses signoff quality
te
Metal filling (ICV) runset from foundry, fills are DRC
clean by construction
In
s 11- 4
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Functional ECOs
route_opt
y
nl
Timing ECOs (PT/StarRC)
O
Functional ECOs
se
U
al
rn
te
Metal filling (ICV)
In
s 11- 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Pre vs. Post Tape-out ECO
ECO Spare
Pre Tape-out ECO
y
Cell Plan
Functional
Unconstrained flow
nl
ECO 
ECO logic
changes
O
se
Incremental
implementation Post Tape-out ECO
U
[P&R] (Freeze silicon flow)
[Timing/DRC fix]
Silicon layers are frozen
al
… 
[Chip finishing]  New cells are getting
rn
mapped to pre-prepared
spare cells
te
Tape-out  Only routing layers change
In
s 11- 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Unconstrained (Pre Tape-out) ECO Flow
 Update netlist with ECO changes

Update netlist with  Tcl commands/scripts
y
ECO changes
for Verilog with ECO changes
nl
 eco_netlist
Place new ECO cells
O
ECO Placement 
 place_eco_cells
se
Update clock-tree
and Scan  Update clock and scan (if FFs are
added/removed)
U
ECO route  Manual steps (e.g. connect_net, disconnect_net)
al
 Route new nets
rn
Fix Timing/DRC
 route_eco
te
 Fix timing/DRC
In
 route_opt
s 11- 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Pre-Tapeout ECO Or Unconstrained Flow
 eco_netlist identifies changes between
y
Current Netlist (ECO)
Design
two netlist versions
nl
 A netlist-editing script is generated, which can
O
then be applied to the design
Applied at the module level
se
 eco_netlist
 Implementation of newly inserted ECO cells
U
occurs through incremental P&R
Incremental
al
P&R Flow
rn
te
In
s 11- 8
sy
PG objects are kept unchanged even if there is a difference between working and golden blocks.
No changes made for the following
op
• creation/deletion of PG port or net

• disconnection of PG net from PG port/pin
• connection of PG net to PG port/pin
yn
Changes will be made for the following

rS
• disconnection of PG net from non-PG port/pin

• connection of PG net to non-PG port/pin
Fo
ed
er
i st
eg
R

ECO Placement: place_eco_cells
place_eco_cells -eco_changed_cells \
-legalize_mode free_site_only | free_site_only
y
allow_move_other_cells |
ECO cell
nl
minimum_physical_impact
O
 free_site_only (default)
 ECO cells are legalized on free sites without moving
se
preexisting cells
 allow_move_other_cells allow_move_other_cells
U
 ECO cells are legalized to their nearest legal location
by moving preexisting cells
ECO cell
al
 minimum_physical_impact
rn
 Combines both ECO cell legalizations into a single-pass
legalization
te
 Valid only with –legalize_only
 To be used with the “Physically-aware ECO flow with
In
PrimeTime” (covered next)
s 11- 9
sy
-displacement_threshold distance
When this option is used in different legalizer modes, the behavior is different:
free_site_only mode
op
Does not legalize cells whose legalization displacement exceeds the specified threshold
Reports the total number of rejected cells due to the specified threshold and creates a collection named
yn
epl_legalizer_rejected_cells to track these cells

For the cells in the collection, you can run
place_eco_cells -legalize_mode allow_move_other_cells -legalize_only
rS
to make space for the ECO cells

minimum_physical_impact mode
Fo
The command first legalizes cells on free sites, but does not legalize the cells whose legalization displacement
exceeds the specified threshold
Performs incremental legalization on the rejected cell collection
ed
If the design already contains filler cells, use the -remove_filler_references option of
place_eco_cells (see page 33 for details).
er
i st
eg
R

Unconstrained Flow
Perform ECO comparison

eco_netlist -by_verilog_file ECO_netlist.v \
-write_changes ECO_changes.tcl
y
nl
Apply ECO changes and place
O
source ECO_changes.tcl
connect_pg_net
se
place_eco_cells -eco_changed_cells -…
U
Manually buffer clock tree, connect scan, …
al
ECO routing and post-route optimization
rn
route_eco -max_detail_route_iterations 5 \
-utilize_dangling_wires true \
te
-open_net_driven true \
-reroute modified_nets_first_then_others
In
route_opt
s 11- 10
sy
You must use the -write_changes option, and either the -by_verilog_file or
-by_block option. These options are mutually exclusive.
op
place_eco_cells: This command places cells which were added to the design.
The -eco_changed_cells option is needed to automatically identify the new ECO cells: Any cells that
yn
were added, sized, or swapped in, will have an eco_change_status attribute with values create_cell,
add_buffer, change_link, size_cell, or add_buffer_on_route, which are automatically ECO-
rS
placed if the -eco_changed_cells option is used. Otherwise, you must specify either -cells or -
unplaced_cells. These three options are mutually exclusive.
Fo
route_eco: Performs incremental routing for the new cells. Executes all three phase of routing: global
route, track assign and detail route.
ed
The -open_net_driven option controls whether ECO route fixes DRC violations for the whole design
(false, the default) or only in the neighborhood (bounding box) of the open nets. By default (false), ECO
er
route connects the open nets in the design and fixes design rule violations for the entire design. When true,
ECO route connects the open nets in the design and fixes DRC violations only in the neighborhood of the
st
open nets. This option is ignored if the -nets option is specified.

i
eg
R

Freeze Silicon ECO Flow
Insert and place spare cells  Insert and place spare cells (spare cell planning)
 Update netlist with ECO changes in freeze-silicon mode
y
 set_app_options -list {design.eco_freeze_silicon_mode true}
Update netlist with
nl
 with Tcl editing commands
ECO changes
 eco_netlist + source
O
Update clock,  Manually update clock tree, scan chain, UPF
scan chain, UPF
se
 Feasibility analysis
Feasibility analysis  check_freeze_silicon
U
 Map newly created cells to spare cells
Map newly created cells
 place_freeze_silicon, automatic mapping
to spare cells
al
 map_freeze_silicon, manual mapping
Connect PG and Tie Connect PG, Connect tie-off pins to tie cells, if needed
rn

 connect_pg_net
Update routing with
 connect_freeze_silicon_tie_cells
te
ECO changes
 Update routing with ECO changes
In
 route_eco
s 11- 11
sy
design.eco_freeze_silicon_mode: The option puts ICCII in the freeze-silicon mode. Most of
ICCII’s commands are disabled in this mode and only a limited number of commands which are freeze
op
silicon aware or freeze silicon tolerant are available.
The insertion of spare cells was already covered in the placement unit.
yn
add_spare_cell; spread_spare_cell; place_eco_cells –legalize_only

icc2_shell> check_freeze_silicon
rS
================================================================================
Check Freeze Silicon Summary
================================================================================
Type Eco Number Spare Number
Fo
--------------------------------------------------------------------------------
Total 36 22
--------------------------------------------------------------------------------
================================================================================
ed
ECO Cells Mapping Feasibility

================================================================================
* These references do not have spare cells
er
Voltage Area Reference Eco Number Spare Number

--------------------------------------------------------------------------------
st
DEFAULT_VA BUFFLVTD16 6 0
DEFAULT_VA INVLVTD0 6 0
i
alu/d2 BUFFLVTD16 3 0
eg
--------------------------------------------------------------------------------
The connect_freeze_silicon_tie_cells command connects tie-pins, which are already connected to P/G
R
nets, to tie cells. With the –cells option, only tie-pins of listed cells are connected to tie cells. Tie pins are
connected to the closest available tie cells. Tie-pins are connected only to tie cells in the same voltage area as
the pin’s P/G net. Both spare tie cells and non-spare tie cells are supported: Non-spare tie cells can only be
connected to pins in the same hierarchy; For a spare tie cell, it may be moved to another hierarchy (swapped
out, and a new tie cell is created) and connected to pins in that hierarchy.

Map ECO Cells to Spare Cells

 Placement based mapping (place_freeze_silicon)
 Coarse placement on ECO cells
y
 Map ECO cells to the closest compatible spare cells (same reference name)
nl
 Manual mapping (map_freeze_silicon)
Map file for batch operation
O
 Resized or removed cells are recycled as spare cells eco1_cell spares_329
eco2_cell spares_88
se
……
U
Spare cell Netlist (eco)
al
instance cell instance
names names
rn
te
In
s 11- 12
sy
With map_freeze_silicon, a file can be supplied that contains the mappings between the ECO’d cells
and the existing spare cells.
op
yn
rS
Fo
ed
er
i st
eg
R

Timing ECOs
route_opt
y
nl
Timing ECOs
(PT/StarRC)
O
se
U
al
rn
te
Metal filling (ICV)
In
s 11- 13
sy
op
yn
rS
Fo
ed
er
i st
eg
R

PrimeTime Signoff-driven Physically Aware ECO Flow
 PrimeTime inputs:
IC Compiler II StarRC  Netlist (Verilog)
y
Extraction
 Timing constraints (SDC)
nl
ECO Guidance change list
Netlist &
Constraints  Power Intent (UPF)
Layout (NDM or DEF+Tcl)
O

PrimeTime SI
 RC Parasitics with coordinates
se
STA/SI
Coupled SPEF
(SPEF, GPD)
 Standard cell spacing rules
U
No (Encrypted Tcl)
Violations? Signoff
 Logic dbs
al
Yes
 Tech Info (CLIB or LEF)
rn
ECO
 Physical libraries (CLIB or LEF)
te
 PrimeTime output:
ASCII ECO file with coordinates
In

ECO Fusion – shown in unit 9 - automates this process
s 11- 14
sy
StarRC can read NDM.
PrimeTime reads the netlist through Verilog, but can use the physical layout data from the NDM design
op
library.
The Galaxy Parasitic Database (GPD) is a distributed and scalable parasitic database that is designed for
efficient communication between StarRC and PrimeTime.
yn
rS
Fo
ed
er
i st
eg
R

Export Data from ICC II for PrimeTime
y
nl
save_block –as ORCA_TOP/route_opt
O
# Save netlist and UPF
write_verilog ORCA_TOP.v; # Writes out hierarchical netlist (-hier not needed)
save_upf ORCA_TOP.upf
se
# Write out library standard cell spacing rules
U
export_advanced_technology_rules lib_spacing_rules.tcl.enc
al
# Optional: write SDC files for each scenario
current_scenario func.ss125c
rn
write_sdc –output ORCA_TOP_func.ss125c.sdc
te
In
s 11- 15
sy
Your standard cell reference libraries may contain special spacing rules, for example: Cell X has to be spaced
a minimum distance from cell Y, or LVt cells can not be placed right next to HVt cells, etc. The
export_advanced_technology_rules command writes out these spacing rules as an encrypted Tcl file
op
(gzipped), which can be read by PrimeTime.

yn
PrimeTime respects the set_dont_touch constraint. Note that write_sdc will not write dont_touch
constraints. In order to capture these, use “write_script -include dont_touch”
rS
Fo
ed
er
i st
eg
R

Example StarRC Command File
NDM_DATABASE: ORCA_TOP.dlib
BLOCK: ORCA_TOP/route_opt Name of NDM design
*****************************
y
library and block
*COUPLING OPTIONS
nl
*****************************
COUPLE_TO_GROUND: NO
O
OPERATING_TEMPERATURE: 100
TCAD_GRD_FILE: SigCmax_effective.nxtgrd
MAPPING_FILE: mapfile
se
REMOVE_DANGLING_NETS: YES
NETLIST_FORMAT: SPEF
U
*****************************
*SETTINGS FOR PHYSICAL ECO REDUCTION: YES
***************************** should not be used *
al
REDUCTION: NO_EXTRA_LOOPS
NETLIST_NODE_SECTION: YES
rn
***************************** To include location
*OUTPUT DATA: information in SPEF
te
*******************************
NETLIST_FILE: eco_inputs/orca_top.spef.max
In
STAR_DIRECTORY: STAR_orca_top
s 11- 16
sy
* REDUCTION: NO_EXTRA_LOOPS
Performs netlist reduction, but ensures that no resistive loops are introduced, for use with delay calculators
that cannot interpret resistive loops. The netlist is 10 to 20 percent larger than with the YES setting.
op
This option retains loops in the parasitic netlist that result from the layout topology. For example, overlapping
metals connected by parallel vias can produce meshes in the parasitic netlist even with the NO_EXTRA_LOOPS
yn
setting, because such meshes reflect the physical topology of the layout.
rS
Fo
ed
er
i st
eg
R

PrimeTime ECO Guidance Flow
Recommended Power Final leakage

DRC, noise, and timing fixing
ECO guidance recovery recovery
y
nl
Sizing DRC and noise use Setup uses Hold uses Sizing
Buffer removal buffer insertion and buffer insertion buffer
Fix mechanism
O
sizing and sizing insertion
and sizing
Does not DRC and noise alter Setup honors Hold honors Does not introduce new
se
introduce new setup and hold slack DRC, alters setup slack timing or DRC violations
Precedence rules timing or DRC as needed (fix noise hold if needed and DRC
violations after DRC and timing)
U
• ECOs can result in many changes, requiring extensive rerouting Final step after timing
al
Flow options
• Implement the changes in ICC II before next PrimeTime ECO run closure
rn
• Supports full-chip STA, SI, AOCV GBA and PBA flows
Highlights
• Fixes across all scenarios
te
PrimeTime ECO now also supports clock tree ECOs.
In
s 11- 17
sy
In PrimeTime, we recommend that ECO fixing is performed in the above order. The reason power recovery
is first is because this step generally downsizes cells: That can make additional room, which subsequent
op
DRC, noise and timing fixing can take advantage of. After timing fixing, final leakage recovery can be
performed to take advantage of any remaining DRC and timing slack.
yn
The precedence rules listed above reflect the order in which we recommend the violations be fixed (after
initial power recovery). For instance, DRC and noise fixing have the freedom to alter timing as needed;
rS
Fixing setup violations honors DRC/noise, but can impact hold violations if needed, and so on.
Fo
Despite the recommended order, sometimes the choice of which type of violations to fix first may depend on
the overall ECO flow. For instance, if the design has significantly more hold violations than setup violations,
it may make sense to fix the hold violations first, since the impact of all the changes on implementation
ed
would be greater. Once these changes are implemented, the user could come back into PrimeTime ECO to
reassess what should be fixed next.
er
The techniques available to PrimeTime for all Eco guidance or fixing (DRC, noise, timing, power) are cell
st
sizing and buffer insertion.

i
eg
You can take advantage of additional fix_eco_xxx command options, for example:
fix_eco_timing –setup_margin controls the slack or margin for fixing setup timing; The margin is 0
R
by default; A positive value specifies over-fixing by that amount, and a negative value specifies under-fixing.
Regardless of the type of violation being fixed, there is a rich array of features and advanced SI analysis
techniques to draw upon for ECO guidance for both single and multiple scenario analysis.

Example Physically Aware ECO in PT (1 of 2)

read_verilog ORCA_TOP.v; link_design ORCA_TOP
set_app_var read_parasitics_load_locations true
read_parasitics -format SPEF -keep_capacitive_coupling orca_top.SPEF Load UPF and
y
load_upf design.upf constraints as done in
nl
read_sdc design.sdc normal MV analysis
O
# Update timing with pin slack and arrival info
se
set_app_var timing_save_pin_arrival_and_slack true
update_timing -full
U
# Configure Physical Information needed for ECO along with Voltage Areas
NDM lib/block
al
set_eco_options -physical_icc2_lib "./ORCA_TOP.dlib" \
-physical_icc2_blocks "ORCA_TOP/route_opt" \
rn
-physical_lib_constraint_file lib_spacing_rules.tcl.enc.gz \
-log_file ./phys.log
te
# Identify violations
In
report_constraints –all –max_cap –max_tran; report_noise; report_timing; report_power
s 11- 18
sy
You should review the eco options log file for possible issues with the input data.
By reading the NDM design and block, PT will also read the associated NDM cell libraries (CLIBs), and any
op
other physical design constraints (blockages, voltage areas, etc.)
If the design contains filler cells, you can have PrimeTime ignore them. Make sure you first identify the filler
yn
cell masters:
set_eco_options -filler_cell_names "FILLER1 FILLER2 FILLER4 …"
rS
Then set the following variable:

set_app_var eco_allow_filler_cells_as_open_sites true
Fo
ed
er
i st
eg
R

Example Physically Aware ECO in PT (2 of 2)

# Power recovery
fix_eco_power -methods {size_cell | remove_buffer}
# Fix DRC violations
set buffer_list { BUF_1 BUF_2 … BUF_N}
y
fix_eco_drc -type max_tran -physical_mode open_site -buffer_list $buffer_list
nl
fix_eco_drc -type max_cap -physical_mode open_site -buffer_list $buffer_list
O
# Fix noise violations
fix_eco_drc -type noise ...
se
# Fix setup and hold violations
Physical mode:
open_site |
fix_eco_timing -type setup -physical_mode open_site ...
occupied_site |
U
fix_eco_timing -type hold -physical_mode open_site ...
freeze_silicon
al
# Write changes
write_changes -format icctcl -output pt_eco.tcl
rn
.....
# Implement PT ECOs in ICC II; Repeat above steps as necessary.
te
# After timing closure, return to PT for final leakage power recovery
fix_eco_power -power_mode leakage
In
write_changes -format icctcl -output pt_eco_fslr.tcl
s 11- 19
sy
The -physical_mode option of the fix_eco* commands has the following settings:
• none (the default) - Does not use physical data while fixing violations.
op
• open_site - Sizes a cell if there is enough room available around the cell and inserts a buffer if there is
an empty site. This mode avoids moving existing cells; it places cells only in empty sites.
• occupied_site - PrimeTime considers layout density in the cell neighborhood and can place or resize a
yn
cell overlapping existing neighbor cells when the local placement density can accommodate the change.
This mode places or resizes a cell even if no empty site is available; to implement the change list, you
rS
need a place-and-route tool to move existing cells to create room for the new or sized cell.
• freeze_silicon - This mode is meant for use with ICC II only. It inserts a buffer directly on top of a base
Fo
layer, matching programmable spare cells specified by set_eco_options. This buffer will appear in the
changelist file as an insert_buffer or an add_buffer_on_route command output with location. The
exact location of the buffer in the programmable spare cell will be guided by the layout and the net
ed
topology. Each such buffer will have a corresponding ICC II map_freeze_silicon command output in
the changelist file as well. This command will be used by ICC II to program the spare cell into the mapped
er
buffer. When the programmable spare cell is wider than the buffer, the map_freeze_silicon command
will backfill the left-over space inside it with base layers that match smaller programmable spare cells.
st
PrimeTime freeze_silicon physical ECO guidance will ensure that when such a backfill is required,
the buffer location leaves room for the left over space to fit one or more smaller programmable spare cells
i
eg
specified by set_eco_options.
R
Consider using the occupied_site physical mode early in the ECO flow, while you’re expecting to
perform multiple iterations: This allows the most flexibility for fixing violations, relying on ICC II to make
room, as needed. Once you are close to timing closure and tape-out, you can minimize any additional changes
to the design by switching to open_site.
The -format icctcl option of with write_changes is applicable to both ICC and ICC II.

Apply PT ECOs in ICC II using Minimum Physical Impact
# Apply PT Physical ECO guidance The displacement

source pt_eco.tcl threshold is important as
it makes sure that cells
y
# Legalize ECO cells
place_eco_cells -legalize_only -eco_changed_cells \ are not placed too far
nl
away from their intended
-legalize_mode minimum_physical_impact \
location. Messages will
O
-displacement_threshold 10 \ be issued if this does
-remove_filler_references $filler_refs happen.
se
# Set up non-timing-driven ECO routing
set_app_options –list { References of filler cells,
U
route.global.crosstalk_driven false which can be removed
route.track.crosstalk_driven false
during ECO legalization.
al
route.global.timing_driven false
route.track.timing_driven false Re-fill with smaller filler
route.detail.timing_driven false } cells, if needed, after
rn
routing.
te
# Perform ECO routing
route_eco -reroute modified_nets_first_then_others
In
s 11- 20
sy
The –legalize_only and –eco_changed_cells options of place_eco_cells are used when the
PrimeTime-generated ECO file contains placement information for added cells. In this case, we want ICC II
op
to respect PrimeTime’s recommended placement, and just legalize the cells.

minimum_physical_impact + displacement_threshold 10:
The command first legalizes cells on free sites, i.e. legalize_mode = free_site_only, but does not legalize the
yn
cells whose legalization displacement will exceed the specified threshold. It then collects these cells to do
another incremental legalization, this time using legalize_mode = allow_move_other_cells, meaning that now
rS
other cells will be moved out of the way, prioritizing the ECO cells.
Fo
Why turn off timing for ECO routing?

PrimeTime (PT) is telling ICC II what to do, based on sign-off timing, so that is exactly what ICC II should
“blindly” follow. PT knows where the routes are, and their RCs (from DEF and SPEF with coordinates). We
ed
do not want the router to do its own timing-driven analysis, since this may cause the router to make
unnecessary routing changes. We want to keep the original routes as is, except for routes to newly added
er
cells.
st
-remove_filler_references references
Specify the references of filler cells which can be ignored during ECO legalization. Unfixed filler cells of the
i
eg
specified references will be ignored and ECO cells can be placed in locations that overlap with these filler
cells. At the end of legalization, those filler cells overlapped with other cells will be removed. Other filler
R
cells that are not of the specified references are still treated as normal cells and cannot be ignored during Eco
legalization. Fixed filler cells are always treated as normal cells and cannot be ignored even if their references
are specified. Since some filler cells may be removed, you may need to reinsert smaller filler cells afterwards.

Filler Cell Insertion
route_opt
y
nl
O
Functional ECOs
se
U
al
rn
te
Metal filling (ICV)
In
s 11- 21
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Standard Cell Fillers and Metal Filling
Boundary (endcap/corner)
cell insertion
y
place_opt
nl
clock_opt
O
Initial Route
Near (route_auto) Remove all filler cells
closure on
se
timing/DRC Post-route Opt (w/o Fill) Post-route Opt (w/Fill RC)
(route_opt) (route_opt)
U
Filler cell Insertion Filler cell Insertion
al
Add Metal Fill Rerun Metal Fill
rn
Timing/DRC
violations? Yes
te
No
In
s 11- 22
sy
Rerun Metal Fill: If the design has a small amount of routing changes, metal fill can also run incrementally.
op
yn
rS
Fo
ed
er
i st
eg
R

Filler Cell Insertion
Metal Filler Cell Insertion
y
create_stdcell_fillers  Perform filler cell insertion with
nl
P/G Update
metal first
O
connect_pg_net
 PG connection and checking are
Filler DRC Checking
done afterwards in separate steps
se
(Violating Filler Removal)
remove_stdcell_fillers_with_violation
 May have to iterate with different
U
Non-Metal Filler Cell Insertion sized fillers
al
create_stdcell_fillers
 Perform non-metal filler cell
insertion next
rn
P/G Update
connect_pg_net
te
In
s 11- 23
sy
You may have to iterate when inserting filler cells with metal, going from larger to smaller filler cells.
op
Non-metal filler cells need to be connected to PG just like any cells because they have power and ground
rails, but no other metal shapes apart from that.
yn
rS
Fo
ed
er
i st
eg
R

Example Script
 Filler cell insertion:
# Insert filler cells. First cells with metal, then without
# Should be sorted from largest to smallest
y
set FILLER_CELL_METAL "saed32/FILL128 saed32/FILL64
nl
... saed32/FILL3 saed32/FILL2 saed32/FILL1"
O
create_stdcell_fillers -lib_cells $FILLER_CELL_METAL
connect_pg_net
se
remove_stdcell_fillers_with_violation
create_stdcell_fillers -lib_cells $FILLER_CELL_NO_METAL
U
connect_pg_net
al
 Filler cell removal:
rn
eval_with_undo -disable {
remove_cells [get_cells -hierarchical \
te
-filter design_type==filler]
}
In
s 11- 24
sy
create_stdcell_fillers # Insert filler cells in empty spaces
[-lib_cells collection] (collection of filler lib cells)
[-prefix string] (fillers prefix)
op
[-bboxes list] (area insertion bounding box list)

[-voltage_area collection] (collection of voltage areas)
yn
[-rules rules] (filler insertion special rules:

Values: no_1x)
[-continue_on_error] (continue on error)
rS
Fo
To speed up the removal of the filler cells, we are disabling the “undo-ability” for the command.
eval_with_undo
[-atomic name]
ed
[-disable]
commands
This command executes a set of TCL commands as a single unit, with the option of disabling undoability of
er
the commands in commands. If the -atomic flag is used, then the execution of the commands in
st
commands appears as a single command with name in the undo stack, and undoing name restores the
database to the state before the execution of this command.
i
eg
R

Signoff DRC
route_opt
y
nl
O
se
U
Signoff DRC checking /
al
fixing (ICV)
rn
te
Metal filling (ICV)
In
s 11- 25
sy
op
yn
rS
Fo
ed
er
i st
eg
R

In-Design Signoff DRC Checking and Fixing
IC Compiler II  Eliminates the need to stream
y
out the design to run DRC
nl
Place &Route
O
Foundry
DRC IC Validator  Signoff quality results using
se
Runset
Signoff Check DRC
foundry DRC signoff runset
U
DRC Error Display
 ICV guidance: Directs Zroute
al
IC Validator
Signoff DRC Fixing
DRC
to perform targeted DRC fixing
rn
Violations
 Negligible impact on timing due to

limited scope of expected
te
changes
Requires an IC Validator (ICV) license - invoked from ICC II
In
s 11- 26
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Signoff DRC using IC Validator
 DRC checking:
 Sign-off DRC checking on all routing metal and
y
via layers, by default
nl
 DRC fixing:
O
 Auto-fix performs sign-off DRC repair
 The design should be near timing closure with
se
only a small number of DRC violations left
 ICV opens the block on disk
U
 Save the block before invoking ICV
al
rn
save_block
set_app_options –list { signoff.check_drc.runset "my_runset" }
signoff_check_drc –select_layers {M1 VIA1 M2 VIA2 M3}
te
signoff.fix_drc.init_drc_error_db "signoff_check_drc_run" }
In
signoff_fix_drc
s 11- 27
sy
Sign-off DRC checking is performed on all routing metal and via layers (created by router, by user, PPNS).
The -select_layers option of signoff_check_drc can be used to specify a sub-set of routing layers
op
(metal or via layers) on which to perform design rule checking. The layer names must be the names defined
in the technology file.
Automatic Incremental Checking (called “auto_eco”) allows ICV to automatically find areas with routing
yn
DRCs compared to a previously checked design, and will only run DRC in the changed areas.
rS
Sign-off DRC fixing (signoff_fix_drc) invokes the ICC II router to fix selected signoff DRC violations,
based on the results from a prior IC Validator run, and then reruns IC Validator signoff DRC checking. This
Fo
command provides tight integration between ICC II and IC Validator for post-route signoff DRC fixing. It
assumes that the current design is near timing closure and there are only a small number of remaining DRC
violations left after the place and route stage.
ed
signoff.fix_drc.init_drc_error_db <initial_icv_error_dir>
er
Specifies the path of the directory that contains the initial DRC error database generated by IC Validator. The
path can be either relative or absolute. Sign-off DRC fixing uses this database. This application option is not
st
set by default, so you need to set it. In our example above, it is set to the default output directory name for
DRC checking. If you don’t set this application option, DRC checking will be run again.
i
eg
IC Validator can be run “stand-alone” with % icv. This is helpful if you do not want to keep an ICC II
R
license checked out while also using ICV.

ICV Usage Examples

 Full-chip DRC checking (metal and via layers) or specific rules
signoff_check_drc
y
signoff_check_drc –select_rules {"M2.S.*" "M3*"}
nl
 Use design view or merge GDSII/OASIS, for double-pattern DRCs
O
set_app_options –list {signoff.check_drc.read_design_views {*}}
-or-
se
set_app_options –list {signoff.physical.merge_stream_files \
{stream_file1.gds stream_file2.oas} }
U
For full-layer signoff DRC checking,
merge full-layer GDSII and/or OASIS
al
signoff_check_drc [-check_all_runset_layers true] stream files with existing NDM libs
rn
 If tech file and runset (GDSII) layer names differ
te
set_app_options –list {signoff.physical.layer_map_file "filename"}
In
s 11- 28
sy
The full design view may be needed, instead of the frame view, when checking DRCs with double-
patterning, for example. The application option expects a list of the cell masters for which design views are to
op
be read. Use “*” to read design views for all cells. There is an equivalent app option to use the layout view:
signoff.check_drc.read_layout_views
yn
Alternatively, use signoff.physical.merge_stream_files

With this app option, you can merge GDSII and/or OASIS stream data with the existing NDMs, without
rS
having to create a new “full” NDM library. The stream files are provided by the vendor. Cells in the stream
files with the same name as in the current design will replace those cells in the reference library. The file
names can be relative or absolute path names of the current run. The results of the signoff_check_drc or
Fo
signoff_create_metal_fill commands are expected to be the same as if run directly on a stream

version of the entire design.
ed
signoff.physical.layer_map_file <file_name>
er
specifies the layer mapping file for the signoff_check_drc or signoff_create_metal_fill

command. This file maps ICC II layers to runset (GDSII) stream layers. The format of the file is the same
st
as the layer map file used by read_gds and write_gds commands. This is needed, if, for example,
blocking layer names in the tech file are different than in GDSII.
i
eg
R

Viewing Error Data in the Error Browser
y
nl
O
se
U
al
rn
te
In
s 11- 29
sy
You can also use the menu ViewError Browser…
op
yn
rS
Fo
ed
er
i st
eg
R

Filtering Error Data
y
nl
O
se
U
al
rn
te
In
s 11- 30
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Metal Filling with ICV
route_opt
y
nl
O
se
U
al
rn
te
Metal filling (ICV)
In
s 11- 31
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Metal Fill Insertion
 Full-chip metal fill insertion and

removal using IC Validator
y
nl
 Pattern-based flow
(user-specified runset)
O
 Track-based fill flow
se
(automatically-generated runset)
U
 Timing-driven metal fill
al
 Auto-eco: Automatically refill
rn
changed areas
te
 If route changes are >20%
(default), full metal fill is run
In
s 11- 32
sy
If you enable the track-based flow, ICC II inserts track-based fill with an automatically generated runset. The
track-based flow does not use a user-specified runset. ICV currently supports the following technologies for
op
track-based metal fill:

"tsmc20" for TSMC 20nm
yn

rS
"samsung14" for Samsung 14nm

"samsung10" for Samsung 10nm
Fo
"intel14" for Intel 14nm

ed
In addition, there is a “generic” mode that will work with any technology.
er
By default, track-based metal fill insertion uses sparse mode, and skips one track between signal shapes and
fill shapes. To use dense mode, which does not skip tracks, set the -fill_all_tracks option to true.
st
If you are using generic track-based metal fill insertion on a design with double-patterning technology, you
must use sparse mode unless the design is precolored.
i
eg
For the auto-eco function, you can set the threshold at which you want to trigger a full refill. This is
R
controlled using the app option signoff.create_metal_fill.auto_eco_threshold_value.

Viewing and Editing Metal Fill To edit shapes,

check “Multiple
levels active”
In the View Settings panel:
1. Set the view level to 1
y
Enable “Fill Cell” under
nl
2.
Expanding cell types
O
3. Set “Fill Cell” visible (default)
se
4. Set “Area Fill” visible (default)
U
al
To select and edit shapes:
rn
1. Check “Multiple levels active”
checkbox
te
Fill cells are instantiated at the top level of the
2. Delete, resize, … block with a default name of FILL_INST_0
In
s 11- 33
sy
Metal fill is stored in fill cell objects: Fill shapes have a shape_use attribute of area fill
To query the fill cells, use the get_fill_cells, e.g. for a flat design, this would return “FILL_INST_0”.
To remove use remove_fill_cells. A “fill cell” includes all the fill shapes. Alternatively, use the GUI to
op
selectively remove individual shapes.

Fill cells can be flat or hierarchical. Flat fill cell contains rectangle shapes only. Hierarchical fill cells contain
yn
other fill cell instances and rectangles.

rS
Fo
ed
er
i st
eg
R

Example Script
save_block
y
signoff.create_metal_fill.runset saed32_mfill_rules.rs
nl
signoff.create_metal_fill.read_design_views {*}
-or-
O
signoff.physical.merge_stream_files {stream_file1.gds stream_file2.oas}
}
se
signoff_create_metal_fill \
-timing_preserve_setup_slack_threshold 0.05 For full-layer metal fill, merge full-layer
GDSII and/or OASIS stream files with
U
existing NDM libs
# Timing analysis shows new small violations
# Remove filler cells, re-run route_opt, then re-insert filler cells
al
...
rn
# Run auto-eco metal fill
signoff_create_metal_fill
te
–auto_eco true \
-timing_preserve_setup_slack_threshold 0.05
In
s 11- 34
sy
For signoff metal fill, all layers in the original GDSII or OASIS databases (not LEF) are preferred.
You can use the application options signoff.create_metal_fill.read_design_views or
signoff.create_metal_fill.read_layout_views to use the design or layout view in the referenced
op
NDM cell libraries, or use signoff.physical.merge_stream_files.

With this app option, you can merge the complete GDSII and/or OASIS stream data with the existing NDMs,
yn
without having to create a new “full” NDM library. The stream files are provided by the vendor. Cells in the
stream files with the same name as in the current design will replace those cells in the reference library. The
rS
file names can be relative or absolute path names of the current run.
Fo
To perform metal-fill of specific layers:

signoff_create_metal_fill -select_layers {M2}
signoff_create_metal_fill -mode add -select_layers {M3}
ed
-timing_preserve_setup_slack_threshold <threshold>
Specifies the setup slack threshold in library time units. The command considers all nets with slack less than
er
the specified threshold as critical nets and preserves the timing for these nets by preventing fill shapes within
st
the minimum spacing of these critical nets.

i
eg
R

Unit Summary
y
 Implement functional ECOs
nl
 Implement physically-aware ECOs
O
 Perform filler cell insertion
se
 Perform signoff DRC checking and fixing with IC Validator
U
 Perform and ICV metal filling
al
rn
Lab 11: Routing + Signoff
te
In
s 11- 35
sy
op
yn
rS
Fo
ed
er
i st
eg
R

y
nl
O
se
U
al
rn
te
In
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R

y
Customer Support
nl
O
se
U
al
rn
te
In
© 2019 Synopsys, Inc. All Rights Reserved 20181001
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R
Customer Support © 2019 Synopsys, Inc. All Rights Reserved. CS-1

Synopsys Support Resources
 Build a solid foundation:

Hands-on training for Synopsys tools
and methodologies
y
nl
https://synopsys.com/support/training.html
 Workshop Schedule and Registration
O
 Download Labs (SolvNet ID required)
 Drill down to areas of interest:
se
SolvNet online support
https://solvnet.synopsys.com
U
 Online technical information and access to
support resources
al
 Documentation & Media
Ask an Expert:
rn

Synopsys Support Center
te
https://onlinecase.synopsys.com
In
https://training.synopsys.com
s CS - 2
sy
op
yn
rS
Fo
ed
er
i st
eg
R

SolvNet Online Support
 Immediate access to
the latest technical information
y
 Product Update Training
nl
 Methodology Training
O
 Thousands of expert-authored
articles, Q&As, scripts and tool tips
se
 Open a Support Center Case
 Release information
U
 Online documentation
License keys
al

 Electronic software downloads
rn
 Synopsys announcements (latest
tool, event and product information)
te
In
s https://solvnet.synopsys.com CS - 3
sy
op
yn
rS
Fo
ed
er
i st
eg
R

SolvNet Registration
1. Go to SolvNet page:
 https://solvnet.synopsys.com/
y
2. Click on:
nl
 “Sign Up for an Account”
O
3. Pick a username and password.
4. You will need your “Site ID”
se
 For Information on how to find your
Site ID, select the “Synopsys Site ID”
U
link
5. Authorization typically takes
al
just a few minutes.
rn
te
In
https://solvnet.synopsys.com/ProcessRegistration CS - 4
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Support Center
 Industry seasoned Application Engineers:
y
 50% of the support staff has
>5 years applied experience
nl
 Many tool specialist AEs with
O
>12 years industry experience
 Engineers located worldwide
se
 Great wealth of applied knowledge:
 Service >2000 issues per month
U
 Remote access, and interactive debug,
al
available via WebEx
rn
Contact us:
Open a support case
te
https://www.synopsys.com/support/global-support-centers.html
In
s CS - 5
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Other Technical Sources
 Application Consultants (ACs):
y
 Tool and methodology pre-sales support
nl
 Contact your Sales Account Manager for more information
O
se
 Synopsys Professional Services (SPS) Consultants:
 Available for in-depth, on-site, dedicated, custom consulting
U
 Contact your Sales Account Manager for more details
al
rn
 SNUG (Synopsys Users Group):
https://www.synopsys.com/community/snug.html
te
In
s CS - 6
sy
op
yn
rS
Fo
ed
er
i st
eg
R

Summary: Getting Support
 Customer Training
https://www.synopsys.com/support/training.html
y
 Register for a Class
nl
 Download Labs
O
 SolvNet
se
https://solvnet.synopsys.com
 Tool Documentation and Support Articles
U
 Product Update and Methodology Information / Training
al
 Open a Support Case (Support Center)
rn
 Other Technical Resources
Synopsys Users Group (SNUG)
te

 Application Consultants
In
 Synopsys Professional Services s CS - 7
sy
op
yn
rS
Fo
ed
er
i st
eg
R

This page was intentionally left blank.
y
nl
O
se
U
al
rn
te
In
s
sy
op
yn
rS
Fo
ed
er
i st
eg
R


Synopsys Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Synopsys Guide

Uploaded by

Copyright:

Available Formats

Document downloaded by Sridhara Sree Rame Gowda on 3/7/2019 9:53:08 PM PST. cesdocs$!

Synopsys Customer Education Services

690 E. Middlefield Road

Workshop Registration: https://training.synopsys.com

Copyright Notice and Proprietary Information

Mountain View, CA 94043

Document Order Number: 20-I-078-SSG-009

Querying Objects / Hierarchy .......................................................................................... 1-5

Retrieving and Setting Attribute Values .......................................................................... 1-8

Accessing Cascaded Attributes ...................................................................................... 1-10

Copying then Saving ...................................................................................................... 1-13

Setting Application Options........................................................................................... 1-16

Scope of Application Options ........................................................................................ 1-18

Global-Scoped Application Options .............................................................................. 1-20

Unit Objectives Summary .............................................................................................. 1-21

Appendix ........................................................................................................................ 1-22

Removing Objects.......................................................................................................... 1-24

Synopsys 20-I-078-SSG-009 i IC Compiler II: Block-level Implementation

Renaming then Saving the Current Block ..................................................................... 1-28

Apply “Padding” Around Macro Edges ........................................................................ 2-18

Write out the Floorplan for ICC II ................................................................................. 2-21

Second-Pass Synthesis Before Placement ..................................................................... 2-23

What is a Site Array? ..................................................................................................... 2-26

Advantages ..................................................................................................................... 2-29

Common Site Array Questions ...................................................................................... 2-31

Unit 3: Placement and Optimization

Agenda ............................................................................................................................. 3-1

General IC Compiler II Flow ........................................................................................... 3-2

Synopsys 20-I-078-SSG-009 ii IC Compiler II: Block-level Implementation

Placement and Logic Optimization: place_opt ................................................................ 3-6

Leakage Improvement by Vt Swapping ........................................................................ 3-29

Dynamic Power Optimizations Require Switching Activity ......................................... 3-32

Inferring Static Values for Control Signals ................................................................... 3-34

Total Power Optimization .............................................................................................. 3-37

Congestion-Focused Setup Steps ................................................................................... 3-40

Global Route Congestion Map....................................................................................... 3-42

Increase Placement/Congestion Effort ........................................................................... 3-44

Global Route-Based HFS and DRC Fixing (GR-opto).................................................. 3-45

Keepout Margins and Placement Blockages.................................................................. 3-46

Is High Cell Density Causing Congestion? ................................................................... 3-48

Synopsys 20-I-078-SSG-009 iii IC Compiler II: Block-level Implementation

Congestion-Driven Restructuring (CDR) ...................................................................... 3-52

Solution: ICG Optimization ........................................................................................... 3-75

ICG Splitting and Clock-Aware Placement ................................................................... 3-78

Test For Understanding.................................................................................................. 3-80

Area Analysis ................................................................................................................. 3-83

Pre-Route Layer Optimization ....................................................................................... 3-86

RDE in the Pre-Route Flow ........................................................................................... 3-88

Placement and Optimization Application Options Summary ........................................ 3-90

Test For Understanding.................................................................................................. 3-91

Summary ....................................................................................................................... 3-92

Appendix A .................................................................................................................... 3-94

Synopsys 20-I-078-SSG-009 iv IC Compiler II: Block-level Implementation

Performing Magnet Placement ...................................................................................... 3-98

ICG Auto-Bounds ........................................................................................................ 3-121

What’s Special about Data Path Logic?....................................................................... 3-124

Data Path Layout using Traditional P&R Tool............................................................ 3-126

Concurrent Placement of RP Groups ........................................................................... 3-129

Placement-Based Scan Chain Re-Ordering ................................................................. 3-134

Example SCANDEF from Synthesis with DFT .......................................................... 3-136

Example: Placement with Existing Ordering............................................................... 3-137

Example: Reordering Within Scan-Chains .................................................................. 3-138

Synopsys 20-I-078-SSG-009 v IC Compiler II: Block-level Implementation