SPR Flow

Synthesis Place-and-Route (SP&R) Flow Guide
Product Version 4.0.8 May 2001
2001 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadences trademarks, contact the corporate legal department at the address shown above or call 1-800-862-4522. All other trademarks are the property of their respective holders. Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specied in this permission statement, this publication may not be copied, reproduced, modied, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions: 1. The publication may be used solely for personal, informational, and noncommercial purposes; 2. The publication may not be modied in any way; 3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement; and 4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be discontinued immediately upon written notice from Cadence. Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and condential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadences customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information. Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 12 13 13 14
1 IntroductionRTL to GDSII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Overall Flow and Associated Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Initial Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical (RTL) Design Data (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Design Data (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GCF File (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Library (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Constraints (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Library (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer Usages Table (Recommended) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run Scripts and Encapsulation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Filessetup.tcl, library.tcl, and design.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . General Setup of PKS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SE-PKS Compatibility Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 19 20 20 21 21 22 22 23 24 27 28 30
May 2001
Product Version 4.0.8
3 RTL Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
RTL Synthesis Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL SynthesisInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL SynthesisRun Script (do_rtl) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_rtl (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL SynthesisRecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Separate floor.tcl File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL SynthesisExample Output Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34 35 35 36 36 37
4 Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Floorplanning Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FloorplanningInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FloorplanningRecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power Striping Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 40 41 42
5 Synthesis, Placement, and Optimization
. . . . . . . . . . . . . . . . . . . . . . 43 43 44 45 45 46 46 47
SPOTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPOInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPORun Script (do_pks) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_pks (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPORecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running PKS Optimizations Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling High Fanout Nets During PKS Optimization . . . . . . . . . . . . . . . . . . . . . . . .
6 Clock Tree Generation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 50 50 51 52
CTPKSAdvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKSPrerequisites for Generating Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKSDependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKSTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
May 2001
CTPKSInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKSRun Script (do_ctpks) Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_ctpks (Example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_ctpks (Example2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKSRecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53 54 54 55 55
7 Post Clock Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Post-CTPKS OptimizationTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-CTPKS OptimizationInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-CTPKS OptimizationRun Script (do_post_ctpks_optimize) . . . . . . . . . . . . do_post_ctpks_optimize (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-CTPKS OptimizationRecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . Setup Fixing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hold-Time Fixing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 58 59 59 60 60 60
8 Global Routing and Post-Groute Optimizations . . . . . . . . . . . . . . . 61

Global Routing and Post-Groute OptimizationsTasks . . . . . . . . . . . . . . . . . . . . . . . . . Global Routing and Post Groute OptimizationsInputs and Outputs . . . . . . . . . . . . . . . Global Routing and Post Groute OptimizationsRun Script (do_groute) . . . . . . . . . . do_groute (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing Hold-Time Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 62 63 63 64
9 Final (Detail) Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Final RoutingTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Full Routing with Search-and-Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Final RoutingInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Final RoutingEncapsulation Script (do_wroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_wrouteAssumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_wrouteOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_wrouteCommand Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_wrouteExample Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 68 68 69 69 70 70 70
May 2001
Final RoutingRecommended Practices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10 Parasitic Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Parasitic ExtractionTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parasitic ExtractionInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parasitic ExtractionEncapsulation Script (do_hyperextract) . . . . . . . . . . . . . . . . . do_hyperextractAssumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_hyperextractOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_hyperextractCommand Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_hyperextractExample Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parasitic ExtractionRecommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating A Cross-Coupling File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 74 74 75 75 76 76 76 76
11 Static Timing and In-Place Optimizations
. . . . . . . . . . . . . . . . . . . . . 77 78 78 79 79 79 80 81 81 81 82
Static Timing and IPOTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static TimingInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static TimingRun Script (do_post_route_optimize) . . . . . . . . . . . . . . . . . . . . . . . do_post_route_optimize (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPOInputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPOEncapsulation Script (do_post_route_eco) . . . . . . . . . . . . . . . . . . . . . . . . . . . do_post_route_ecoAssumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_post_route_ecoOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_post_route_ecoCommand Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do_post_route_ecoExample Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
VericationTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
May 2001
A Complete Sample Run Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 B Documentation Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 C A More Sophisticated Directory Structure . . . . . . . . . . . . . . . . . . . . . 93 D Inputting Floorplanning Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Setting the Die Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Automatically Calculating the Die Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Automatic Growing Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Supporting Floorplan Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Generating the Initial Floorplan from a DEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
E Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Setting the Appropriate PKS Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Timing-Driven Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
F CTPKS Constraint File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

CTPKS Constraint File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKS Clock Tree Structure File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CTPKS Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 108 108 109
May 2001
G Post Clock Tree Optimization Constraints . . . . . . . . . . . . . . . . . . . . 111

Clock Insertion Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
H Performing Global Routing, In-Place Timing Corrections, and Post Groute Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Performing Global Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Performing In-Place Timing Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Performing Post Groute Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
I Final (Detail) Route Options and Commands . . . . . . . . . . . . . . . . 117

Setting the Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Wroute in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping Wroute in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Wroute from within the SE GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 117 118 118
J Running HyperExtract in Standalone Mode . . . . . . . . . . . . . . . . . . 119

HyperExtract Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HyperExtract Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running HyperExtract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dlcInitFile Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 119 120 120
K Pearl Commands used to Create an SDF . . . . . . . . . . . . . . . . . . . . 121

Creating An SDF With Pearl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delay Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delay CalculationRun Script (do_delay_calc) . . . . . . . . . . . . . . . . . . . . . . . . . do_delay_calcAssumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 122 122 122
May 2001
do_delay_calcOperation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
L GCF File to Load Timing Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

example_gcf_le.gcf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
M Command Syntax for Encapsulation Scripts . . . . . . . . . . . . . . . . . 125

The do_ctpks Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The do_wroute Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wroute Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The do_hyperextract Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HyperExtract Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The do_post_route_eco Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wroute Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 125 125 126 127 127 127 127 128 129 129 129 130 130 130 131 131 132 132 133 133 133 133 134 134
May 2001
N Synopsys Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
May 2001
10
Preface
This preface contains the following sections:
s s s s
About This Manual on page 11 Other Information Sources on page 11 Syntax Conventions on page 12 About the Graphical User Interface on page 13
About This Manual

This document describes the Cadence synthesis place-and-route (SP&R) ow. The SP&R ow integrates the Cadence physically knowledgeable synthesis (PKS) tool with the Silicon Ensemble place-and-route (SE) tool to take your complex deep sub-micron digital IC designs all the way from RTL to GDSII.
Other Information Sources

For more information about Ambit BuildGates Synthesis and other related products, you can consult the sources listed here.
s s s s s s s
Ambit BuildGates Synthesis User Guide Command Reference for Ambit BuildGates Synthesis and Cadence PKS Timing Analysis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS HDL Modeling for Ambit BuildGates Synthesis Distributed Processing of Ambit BuildGates Synthesis Constraint Translator for Ambit BuildGates Synthesis and Cadence PKS
May 2001
11
Synthesis Place-and-Route (SP&R) Flow Guide Preface Depending on the product licenses your site has purchased, you could also have these documents.
s s s
Datapath Option of Ambit BuildGates Synthesis and Cadence PKS Low Power Option of Ambit BuildGates Synthesis and Cadence PKS PKS User Guide
BuildGates synthesis is often used with other Cadence tools during various design ows. The following documents provide information about these tools and ows. Availability of these documents depends on the product licenses your site has purchased.
s s s
Cadence Timing Library Format Reference Cadence Pearl Timing Analyzer User Guide Cadence General Constraint Format Reference
The following books are helpful references.

s s
IEEE 1364 Verilog HDL LRM TCL Reference, Tcl and the Tk Toolkit , John K. Ousterhout, Addison-Wesley Publishing Company
Syntax Conventions
This section provides the Text Command Syntax used in this document.
Text Command Syntax

The list below describes the syntax conventions used for the Ambit BuildGates synthesis text interface commands.
Important
Command names and arguments are case sensitive. User-dened information is case sensitive for Verilog designs and, depending on the value specied for the global variable hdl_vhdl_case, may be case sensitive as well.
literal
Nonitalic words indicate keywords that you must enter literally. These keywords represent command or option names.
May 2001
12
Synthesis Place-and-Route (SP&R) Flow Guide Preface Words in italics indicate user-dened arguments or information for which you must substitute a name or a value. Vertical bars (OR-bars) separate possible choices for a single argument. Brackets denote optional arguments. When used with OR-bars, they enclose a list of choices from which you can choose one. Braces are used to indicate that a choice is required from the list of arguments separated by OR-bars. You must choose one from the list. { argument1 | argument2 | argument3 }
{ }
argument
[ ]
{ }
Bold braces are used in Tcl commands to indicate that the braces must be typed in literally. Three dots (...) indicate that you can repeat the previous argument. If the three dots are used with brackets (that is, [argument ]...), you can specify zero or more arguments. If the three dots are used without brackets (argument...), you must specify at least one argument, but can specify more. The pound sign precedes comments in command les.
...
About the Graphical User Interface

This section describes the conventions used for the BuildGates synthesis graphical user interface (GUI) commands and describes how to use the menus and forms in the BuildGates synthesis software.
Using Menus
The GUI commands are located on menus at the top of the window. They can take one of three forms.
CommandName CommandName
A command name with no dots or arrow executes immediately. A command name with three dots displays a form for choosing options.
May 2001
13
Synthesis Place-and-Route (SP&R) Flow Guide Preface
CommandName ->
A command name with a right arrow displays an additional menu with more commands. Multiple layers of menus and commands are presented in what are called command sequences, for example: File Import LEF. In this example, you go to the File menu, then the Import submenu, and, nally, the LEF command.
Using Forms
A menu button that contains only three dots provides browsing capability. When you select the browse button, a list of choices appears. The Ok button executes the command and closes the form. The Cancel button cancels the command and closes the form. The Defaults button displays default values for options on the form. The Apply button executes the command but does not close the form. The Help button provides information about the command.
Ok Cancel Defaults
Apply
Help
May 2001
14
1
IntroductionRTL to GDSII
This document describes the Cadence synthesis place-and-route (SP&R) ow. The SP&R ow integrates the Cadence physically knowledgeable synthesis (PKS) tool with the Silicon Ensemble place-and-route (SE) tool to take your complex deep sub-micron digital IC designs all the way from RTL to GDSII.
RTL
SP&R
GDSII
May 2001
15
Synthesis Place-and-Route (SP&R) Flow Guide IntroductionRTL to GDSII This SP&R ow has been developed to address the issues of timing closure and design reliability, both of which are gaining signicance as device geometries continue to shink further into the deep sub-micron realm. Confronting these issues requires new levels of integration between logic design and physical implementation technologies. The SP&R ow tightly integrates RTL synthesis with nal placement and routing. This new ow yields greater timing correlation at all stages of the design process, which results in smaller designs and faster completion. There are many ways a design may be conveyed from RTL through GDSII; this document describes a typical base ow. You can make modications to this ow to suit your specic requirements. Each step in the SP&R ow provides the required inputs and resulting outputs, the setup requirements, the command les, and recommended practices. It also includes descriptions of the utilities available to automate the steps in the SP&R ow, explanations of how and where they are used, and information on how to get these utilities. A comprehenisve list of documentation sources, including application notes, pertinent to each step in the ow is provided to help you quickly locate more detailed information as needed. To keep the descriptions simple, unless otherwise noted, its assumed that the logical design at the RTL-level is represented in Verilog, but it can also be represented in VHDL. Similarly, its assumed that gate-level logical netlists are described with Verilog, but they can also be described with VHDL or EDIF. The following diagram shows the high-level interaction between the two main technologies (PKS and SE) within the SP&R ow.
May 2001
16
Synthesis Place-and-Route (SP&R) Flow Guide IntroductionRTL to GDSII
Overall Flow and Associated Commands

LEGEND Main Steps
Commands RTL Synthesis Initial Area Estimation and Timing Driven Block Placement RTL Synthesis
PKS
3rd Party Synthesis
RTL Synthesis RTL Synthesis

do_rtl
SE
Floorplanning Floorplanning
use SE interface Block Refinement Power Routing
Synthesis, Placement, Synthesis, Placement, Optimization and Optimization

do_pks
Pre-Placement Optimization Timing Driven Placement Post-Placement Optimization Generate CTPKS command and constraint files, then generate the clock tree
Clock Tree Generation Clock Tree Generation

do_ctpks
Post Post Clock Tree Clock Tree Optimizations Optimizations

do_post_ctpks_optimize
Propagated Clocks Post Clock Tree Optimization
Global Routing Global Routing

do_groute
Timing Driven Global Routing Post Route Optimizations Hold Time Fixing WROUTE
Final (Detail) Routing

do_wroute
Final Route Search and Repair HyperExtract 2.5D Parasitic extraction
Parasitic Extraction
do_hyperextract
Delay Calculation
do_delay_calc Static Timing and InPlace Optimizations Static Timing and
Parasitic reduction and delay calculation
In-place Optimizations
do_post_route_optimize do_post_route_eco
SDF Back Annotation Timing Correction Hold Time Fixing
Verification
Verification
use HECK interface use SE interface
HECK
Formal Verification Verify Geometry Verify Connectivity
May 2001
17
Synthesis Place-and-Route (SP&R) Flow Guide IntroductionRTL to GDSII
May 2001
18
2
Getting Started
This chapter describes the initial requirements you must meet before getting started with the Cadence synthesis place-and-route (SP&R) ow.
Initial Input Files

Several input les and libraries must be available before starting the SP&R ow. Figure 2-1 shows how the input les and libraries are categorized along with their supported formats. Figure 2-1 Initial Files and Libraries Required By the SP&R Flow
Logical (RTL) Design Data

Verilog
Physical Design Data

DEF TLF
Timing Library
ALF
Physical Library
LEF
Timing Constraints
TCL
VHDL
PDEF
OLA (DCL)
LUT
Only one type is required
Optional (see notes)
Only one type is required, but multiple types can be used (see notes)
LEF required, LUT recommended
Required
Logical (RTL) Design Data (Required)

The original logical design data is presented in register transfer level (RTL) format and can contain a mixture of high-level statements, gate-level netlists, and macro instantiations.
May 2001
19
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started
Supported Formats Verilog VHDL
Source Generated manually or from design capture tools, including block diagram, schematic, state diagram, ow chart, truth table, and textual HDL editors.
Physical Design Data (Optional)

Physical design data can be represented using the de facto standard DEF or industry standard PDEF formats. (Note that PDEF can only describe placement and bounding box data, while DEF can include additional information such as routing grids, power grids, preroutes, and rows.) This physical data is an optional input that would typically be available if this were a redesign of an existing device. Also note that Cadence physically knowledgeable synthesis (PKS) provides simple oorplanning features and can automatically generate an initial oorplan. More detailed design data becomes available as you proceed through the SP&R ow.
Supported Formats DEF 5.1+ PDEF 2.0
Source Generated by a physical design tool such as a oor planner or a placement engine.
GCF File (Optional)

A GCF le may be generated from PKS for use in standalone versions of delay calculation (Pearl), clock tree synthesis (CTGen), or the timing-driven place-and-route tools (Qplace and Wroute). However, each of these functions are available in the PKS 4.0 release do not require that you create a GCF le. When running the standalone tools as noted above, the GCF le loads timing libraries and sets the operating conditions for the library. (An example GCF le is shown in GCF File to Load Timing Libraries on page 123.)
Supported Formats GCF 1.3 GCF 1.4
May 2001
20
Timing Library (Required)

A timing library includes all of the timing information associated with a particular manufacturing process. Only a single timing library is required by the SP&R ow, but it is possible to use a mixture of timing libraries if you wish. For example, you may want to use an ALF for standard cells and a TLF for macro libraries. Note: If you use multiple timing library formats within the ow, you must ensure that they are well correlated.
Supported Formats ALF 3.0 OLA (DCL) TLF 4.3a
Source Timing libraries can come from various sources. Most common are ASIC vendors or foundries, internal CAD library development departments, or library vendors. Alternatively, new timing library formats can be derived from existing timing libraries. For example, translators exist to generate TLF or ALF libraries from the Synopsys .LIB format. Note that you may use the syn2tlf utility with the -4.3 option to create new TLF 4.3 models (recommended).
a.Using TLF 4.3 provides a significant number of timing engine enhancements versus using CTLF 3.x or TLF 4.1. TLF 4.3 provides the slew measurement points (20%/80% or 10%/90%) resulting in better timing. Using TLF 4.3 is recommended, but if you must use CTLF 3.x or TLF 4.1, do the following: set_global auto_slew_and_delay_degradation false
Timing Constraints (Required)

The timing constraints are presented to the SP&R ow in the form of a TCL le (this le is named constraints.tcl throughout this document).
Supported Format TCL
Source The initial constraints are generated manually or programmatically and are derived from the designs timing specication. (Note that a conversion utility that can convert Synopsys write-script into TCL is provided with the SP&R ow. See Synopsys Conversion Utility on page 135 for more information.
Note: Be sure to run check_timing to validate that your constraints are correct.
May 2001 21 Product Version 4.0.8
Physical Library (Required)

The physical library describes the physical characteristic for a particular standard cell library. This includes information like physical footprints, pin locations, and so on. Supported Formats LEF 5.2 LEF 5.3 LEF 5.3.1 Note: In order to achieve the most accurate results possible, it is important that the R and C values in the LEF are well correlated with the results from HyperExtract (HE). This means that the library development team should use the lefCap.pl functionality to take the output from HE and update the LEF. (For values that are non-design-specic, this tuning can be performed using a representative design at the high-end of the typical utilization spectrum.) Check with your Cadence representative for more information. If you are not using HyperExtract , you must make sure your LEF R and C values correlate well with the extraction tool you are using. Note: Be sure to run check_library to verify that your physical and timing libraries match. Source As with timing libraries, physical libraries are generated primarily by ASIC vendors, foundries, internal CAD library development groups, or library vendors.
Layer Usages Table (Recommended)

The layer usages table (LUT) is an ASCII text le used to provide information to the fast router in PKS. This information guides PKS in its initial estimation phase to use the specied percentages of each metalization layer for horizontal and vertical routes. For example, horizontal tracks = 35% on metal layer 1, 40% on metal layer 3, and 25% on metal layer 6; vertical tracks = 45% on metal layer 2, 45% on metal layer 4, and 10% on metal layer 6 (the actual percentages used will be based on empirical data gathered from previous designs). The LUT also includes resistance information for vias, the average number of vias that typically appear on straight routes, and so on. (Different values for this data can be associated with different route lengths.)
Supported Format ASCII text (see Note below)
Source Based on empirical data gathered from previous designs.
May 2001
22
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started Note: The LUT is considered to be part of the physical library data and is recommended every time a LEF physical library is used. An example LUT for a four-layer device technology is shown below. Further details can be found in Appendix A of the PKS User Guide .
Layer_Usages () { Length_Range (0) { Utilization_Horizontal: "0.229 0.005 0.765 0.001" ; Utilization_Vertical: "0.002 0.585 0.001 0.412" ; Contact_Spacing_Vertical: "20" ; Contact_Spacing_Horizontal: "20" ; } }
To view the layer usages tables used in the system, use the write_layer_usages command found in the Command Reference for Ambit BuildGates Synthesis and Cadence PKS .
Run Scripts and Encapsulation Scripts

Each step in the design ow can be controlled manually or by using run scripts and encapsulation scripts to dene the ow environment. Note that you can load the appropriate libraries and design data by keying in individual instructions, but this approach is prone to errors. It is recommended that you use the following run scripts and encapsulation scripts to dene the ow environment and to load the appropriate libraries and design data: Script Type Run script Run script Run script Run script Run script Encapsulation Encapsulation Run script Run script Design Flow Script do_rtl do_pks do_ctpks Description Performs RTL synthesis. Performs synthesis, placement, and optimization. Performs clock tree generation.
do_post_ctpks_optimize Performs post clock tree optimizations. do_groute do_wroute do_hyperextract do_delay_calc Performs global routing and optimization. Performs nal (detail) routing. Performs parasitic extraction. Performs delay calculations.
do_post_route_optimize Performs post route optimizations.
May 2001
23
Script Type Encapsulation
Design Flow Script do_post_route_eco
Description Performs post route engineering changes.
These scripts correspond to the steps in the ow and are discussed in more detail in the following sections. However, you should note the following:
s
Run Scripts Because each design ow is unique, it is necessary for you to create your own run scripts. The run scripts presented in this document are intended to offer a starting point and can be customized to meet your own unique requirements.
Encapsulation Scripts Encapsulation scripts automatically generate appropriate command and constraint les and then execute a specic function. These scripts are provided in the release hierarchy under the release/BuildGates/version/examples/spnr_flow directory in a le called spnr_utils.tcl.
Note that standalone run scripts are used throughout this document to show you how to perform each step. By comparison, Complete Sample Run Script on page 85 provides a complete example script that takes you through the ow from start to nish without the necessity of going in and out of sub-scripts.
Command Filessetup.tcl, library.tcl, and design.tcl

One way to create your run scripts is as a series of discrete (in-line) commands that explicitly reference each and every le as shown in the example below: example_run_script.tcl
read_alf <library>.alf read_lef <library>.lef read_verilog <design>.v do_build_generic source <timing_constraints.tcl> source <physical_constraints.tcl> do_optimize pks : etc.
May 2001
24
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started However, this technique can prove to be unwieldy should you wish to make any modications to your ow (such as using an alternative library). For this reason, it is recommended that you use a combination of global variables and command les. The initial set of global variables you might consider are as follows:
Global Variable design_root library_root work_dir opt_flow
Description The path to the designs top level/directory. The path to the library les which are usually stored in some central location. The path to your current working directory. The current optimization ow you wish to perform (that is, working with RTL or a gate-level netlist).
You will notice that the bulk of these discussions are based on the concept that all of your working les are located in a single working directory. It is possible to create more sophisticated environments as discussed in A More Sophisticated Directory Structure on page 93. Next, it is suggested that you create the following three TCL command les as shown below.
TCL Command Files setup.tcl library.tcl design.tcl
Description Initializes the environment. Loads the libraries. Loads the design data.
setup.tcl (example)
set library_root <path_to_library_data> set work_dir <path_to_current working directory> source ${library_root}/library.tcl
Note the reference to the library.tcl le from within the setup.tcl le. This illustrates that the library.tcl le is typically stored alongside its associated library les in some central location.
May 2001
25
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started library.tcl (example)

######################################################## # Load TLF or ALF libraries ######################################################## read_tlf ${library_root}/TLF/cells.tlf read_tlf ${library_root}/TLF/macros.tlf # # Load LEF libraries # read_lef ${library_root}/LEF/cells.lef read_lef_update ${library_root}/LEF/macros.lef # # Define other library setup information: #set_dont_utilize, set_layer_availability, #select a layer usages table (LUT), etc. ########################################################
design.tcl (example)
######################################################## # Selectively load the source design data (rtl or gates) ######################################################## if {${opt_flow} == rtl} { read_verilog $design_root/rtl_src/<rtl_design>.v } elseif {$opt_flow == gates} { read_verilog $work_dir/<gate_level_design>.v } do_build_generic ########################################################
These les can then be sourced from your run scripts as shown in the following generic example (note that setup.tcl itself sources library.tcl). This technique provides portability and exibility when creating scripts to run jobs and analyze data.
May 2001
26
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started Generic run script (example)
Set design_root <path_to_top_level_design_directory> set opt_flow <rtl or gates> source ${design_root}/setup.tcl source ${design_root}/design.tcl source ${design_root}/floor.tcl source ${design_root}/constraints.tcl do_optimize -pks : etc
Note: The floor.tcl le referenced in this generic example is described in more detail in the chapter, RTL Synthesis on page 33.
General Setup of PKS Parameters

There are a wide range of PKS parameters you may wish to use when setting up your environment. These parameters would be added to the setup.tcl le shown above. Some typical examples include:
set_global placement_initialize_auto_pass true set_min_wire_length 10 set_steiner_mode 1
You also need to be aware of a number of changes that have been made to the default settings in the PKS 4.0 release. The new defaults are as follows (Use report_globals to view global variable settings):
Global Variable auto_slew_prop_selection path_style_constraints
Default Value true true
clock_gating_to_be_checked true extra_space_for_opt 0
May 2001
27
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started The slew prop setting enables the automatic handling of slew propagation through cells during optimization and also automatically sets the timing mode for report timing to worst . If you have been using the former default for depth_for_fast_slew_prop 0 and you have a library containing cells that are sensitive to input slew, report_timing will show worse slack for the same design in the PKS 4.0 release as compared to the PKS 3.0 release. Details on these (and other) PKS commands are provided in the Command Reference for Ambit BuildGates Synthesis and Cadence PKS . You can also see Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization on page 103.
Example Directory Structure

The following example directory structure is provided to illustrate one possible scenario. Note that you can use any directory structure you wish to manage the command les, source les, and output data associated with your designs. Lets assume that you are working with a chip design called demo. In this case, you might start off by creating the directory structure shown in Figure 2-2. Figure 2-2 The Initial Directory Structure for a Chip Design Called demo
demo
setup.tcl design.tcl constraints.tcl floor.tcl
rtl_src demo.v demo.def (optional)
The four main TCL command les (setup.tcl, design.tcl, constraints.tcl, and floor.tcl) reside in the top level of the demo folder (floor.tcl is described in the chapter, RTL Synthesis on page 33) . Note that the spnr_utils.tcl le containing the encapsulation scripts and all of the libraries containing technology-specic timing and physical information would typically reside in some central location (see Run Scripts and Encapsulation Scripts on page 23). Also note that the library.tcl command le is typically stored alongside its associated library les
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started in some central location (see Command Filessetup.tcl, library.tcl, and design.tcl on page 24). Lets assume that under the demo folder theres a sub-folder called rtl_src, which contains the initial RTL-level design source les. Lets further assume that the top-level RTL source le is called demo.v. This directory would contain any existing physical information in the form of a demo.def le. (Remember that the demo.def le is an optional input as discussed in Initial Input Files on page 19.) To complement the command les discussed above, it is strongly recommended that your environment be designed to: 1. Accommodate running the job from any directory. 2. Keep all results data separate from the directory containing your source data. 3. Support multiple test runs and prevent new results from accidentally overwriting the results from previous evaluations. With respect to this last point, it is in the nature of digital IC designs that you will want to experiment with a number of different what-if scenarios. In order to accommodate this, it is recommended that you create an individual sub-directory associated with each what-if evaluation. For your rst evaluation, you could create a subdirectory called test1 , which could be used to hold all of the les you create during the course of this evaluation. When you subsequently run one of your scripts, such as the do_rtl run script (as discussed in RTL Synthesis on page 33), you would dene the paths to your input and output les to use this test1 working directory (test1/input.file and test1/output.file) (Figure 2-3). Figure 2-3 Example of the Files Generated After Running do_rtl
demo test1 setup.tcl design.tcl constraints.tcl floor.tcl demo_rtl.adb demo_rtl.v demo_rtl.def timing_rtl.txt
Results from the RTL Synthesis step
May 2001
29
Synthesis Place-and-Route (SP&R) Flow Guide Getting Started Based on this scenario, each subsequent step in the SP&R ow associated with this what-if evaluation will use the les that were generated by the preceding step as its inputs and create its own set of results in the test1 directory. Storing the results from subsequent what-if evaluations in directories called test2 , test3 , and so forth makes it relatively easy to keep the results from each evaluation separate and distinct (Figure 2-4). Figure 2-4 Each what-if Evaluation Should Have Its Own Working Directory
demo
test1
test2
test3
SE-PKS Compatibility Matrix

PKS Release (Production Version) 4.0 Release 4.0.8 (SPR40_S008) 4.0.7 (SPR40_S007) SE-Pompeii Release (Production Version) 5.3 Release 5.3.123 (S123) 5.3.123 (S123)
Wroute Version 2.2 Release 2.2.31 2.2.31
Wroute DB Change a (SE-PKS versions not compatible with Wroute 2.2.31) 4.0.6 (SPR40_S006) 4.0.5 (SPR40_S005) 4.0.5 (SPR40_S005) 4.0.4 (SPR40_S004) 5.3.121 (S121) 5.3.121 (S121) 5.3.118 (S018) 5.3.118 (S018) 2.2.30 2.2.30 2.2.30 2.2.30
May 2001
30
PKS Release (Production Version) 4.0.4 (SPR40_S004) 4.0.3 (SPR40_S003) 4.0.3 (SPR40_S003) 4.0.2 (SPR40_S002)b 4.0.2 (SPR40_S002) 4.0.1 (SPR40_S001) 4.0.1 (SPR40_S001) 4.0 (SPR40) 4.0 (SPR40) 3.0 Release 3.0.31 3.0.30 3.0.30 3.0.29 3.0.28 3.0.27
SE-Pompeii Release (Production Version) 5.3.117 (S017) 5.3.117 (S017) 5.3.116 (S016) 5.3.116 (S016) 5.3.113 (S013) 5.3.113 (S013) 5.3.111 (S011) 5.3.111 (S011) 5.3.107 (S07) 5.3 Release 5.3.117 (S017) 5.3.116 (S016) 5.3.113 (S013) 5.3.113 (S013) 5.3.107 (S07) 5.3.107 (S07)
Wroute Version 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2 Release 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30 2.2.30
a.Older versions that are not compatible with DB released on 4/13/01 (PKS 4.0.7/SE 5.3.123). b.TLF 4.3 flow compatibility begins to be supported in PKS 4.0.2/SE 5.3.116.
May 2001
31
May 2001
32
Synthesis Place-and-Route (SP&R) Flow Guide RTL Synthesis
3
RTL Synthesis
This chapter describes how to perform the RTL Synthesis tasks as a component of the Cadence synthesis place-and-route (SP&R) ow.
RTL Synthesis Tasks

The primary tasks that take place in RTL synthesis are: 1. Input the RTL design. 2. Input any oorplanning information in the form of Cadence physically knowledgeable synthesis (PKS) parameters as described in Inputting Floorplanning Information on page 97. Note: PKS can be used to create an initial oorplan (existing physical data may be imported in the form of a DEF le). During this step in the SP&R ow, PKS performs the following oorplanning operations:
u u u
Determines the size of the chip. Sets the location of any xed elements (blocks and pads). Places all macro blocks.
3. Perform synthesis and placement. 4. Output a gate-level Verilog netlist along with a DEF containing the initial oorplanning information.
Synthesis Place-and-Route (SP&R) Flow Guide RTL Synthesis Note: Scan synthesis is not covered in the main ow discussions in this document. The Command Reference for Ambit BuildGates Synthesis and Cadence PKS describes the recommended scan ows in detail.
RTL SynthesisInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. The input les to this step are as follows: Input Files <library>.tlf <library>.lef <library>.lut demo.v demo.def constraints.tcl oor.tcl Description TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. A LUT, which is referenced by the library.tcl command le (optional, but recommended). The original RTL source le, which is located in the rtl_src directory. The original physical data le, which is located in the rtl_src directory (optional). The original timing constraints TCL le, which is located in the main demo directory. A oorplanning TCL le which is located in the main demo directory (optional see Creating a Separate oor.tcl File on page 36 for more details).
The output les that are typically generated by this step are: Output Files demo_rtl.adb demo_rtl.v demo_rtl.def timing_rtl.txt
May 2001
Description An Ambit database containing design, oorplan, and constraint information. The hierarchical gate/macro-level netlist for the entire design. The at physical data containing initial oorplanning and power design information. A timing report le.
34 Product Version 4.0.8
RTL SynthesisRun Script (do_rtl)

Note: The commands shown below can be used as a basis for creating your own do_rtl run script.
do_rtl (example)
set opt_flow rtl set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl source ${design_root}/design.tcl source ${design_root}/floor.tcl source ${design_root}/constraints.tcl do_optimize pks write_def $work_dir/demo_rtl.def write_verilog -hier $work_dir/demo_rtl.v write_adb -hier $work_dir/demo_rtl.adb report_timing > $work_dir/timing_rtl.txt
This script should access the original RTL design (located in the rtl_src directory) along with any other input les (through the use of the setup.tcl, library.tcl, and design.tcl command les discussed earlier in the previous chapter). The script should then perform the synthesis and initial oorplanning steps and store any result les in the test1 working directory (Figure 3-1). Figure 3-1 Example Files That May Be Generated By RTL Synthesis
demo
test1 demo_rtl.adb demo_rtl.v demo_rtl.def timing_report.txt
Results from the RTL Synthesis step
May 2001
35
RTL SynthesisRecommended Practices

This section provides the recommended practices for RTL synthesis.
Creating a Separate floor.tcl File

It is recommended that you create a separate TCL le called floor.tcl to load oorplan data and dene the oorplan parameters (see example below). This floor.tcl le, which would typically be stored in your top-level design directory, can then be sourced from your run scripts. oor.tcl (example)
######################################################## # Define the floorplan information # This shows the ability to run with a variable # floorplan when starting from RTL but with a fixed # floorplan when starting from a gate level netlist # The assumption here is that the fixed floorplan # already contains rows cut around the macro cells so # no block halo is required. ######################################################## if {${opt_flow} == rtl} { set_floorplan_parameters -initial_row_utilization 80 set_floorplan_parameters -lr_block_halo 20 set_floorplan_parameters -tb_block_halo 20 } elseif {$opt_flow == gates} { read_def $work_dir/demo_floorplan.def } ########################################################
Note: The set_floorplan_parameters command is discussed in more detail in Inputting Floorplanning Information on page 97. The demo_floorplan.def le referenced in floor.tcl is generated by the Floorplanning step.
May 2001
36
RTL SynthesisExample Output Reports

You can use the report_floorplan_parameters command (after the design has been loaded) to generate a oorplan parameter report. An example of the oorplan parameter report is shown below.
+--------------------------------------------------+ | FloorplanParameter | Value | Source | |-----------------------------+----------+---------| | -bbox_initial <lx> | 0.000 | DEF | | -bbox_initial <ly> | 0.000 | DEF | | -bbox_initial <ux> | 7925.400 | DEF | | -bbox_initial <uy> | 7925.600 | DEF | | -lr_io_to_core_distance <l> | 647.100 | DEF | | -lr_io_to_core_distance <r> | 633.600 | DEF | | -tb_io_to_core_distance <b> | 633.600 | DEF | | -tb_io_to_core_distance <t> | 648.800 | DEF | | -aspect_ratio_initial | 1.000 | Default | | -fixed_floorplan | Y | Default | | -height_initial | 0.000 | Default | | -width_initial | 0.000 | Default | | -max_height | | Default | | -max_width | | Default | | -row_utilization_initial | 40.144% | Derived | | -max_row_utilization | 90.000% | Default | | -row_spacing | 0.000 | DEF | | -abut_row_pairs | N | DEF | | -flip_alternate_rows | Y | DEF | | -lr_block_halo | 0.000 | Default | | -tb_block_halo | 0.000 | Default | +--------------------------------------------------+
May 2001
37
May 2001
38
4
Floorplanning
This chapter describes how to perform the Floorplanning tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. In this step, the macro blocks and pads are placed into their nal positions and the power grid is added. Note: This SP&R ow is based on using Silicon Ensemble place-and-route (SE) to perform the detailed oorplanning tasks. You can also perform Floorplanning tasks using Cadence physically knowledgeable synthesis (PKS) or Design Planner (DP) tools.
Floorplanning Tasks
The primary tasks that take place in Floorplanning are: 1. Load the design. Requires reading the LEF and any DEFs into SE. Since you will not be performing any timing operations there is no need to read a TLF into the database. 2. Fix block placements. Requires setting the nal location of the macro blocks using the move cell functions. One of the main things to watch for here is that the power pins of the macros may dictate where the macro blocks are located.
May 2001
39
Synthesis Place-and-Route (SP&R) Flow Guide Floorplanning 3. Add cells. Requires adding the power pads and any other pre-placement ller cells, such as EndCaps. 4. Power planning. Requires creating a grid of the main power busses in the design using the power planner in SE, and also creating power rings around macros as required. 5. Output a new DEF le. Requires outputting a new DEF le (after completing the oorplan) that contains the nal placement of the pads, macro blocks, power routes, and any additional pre-placement ller cells.
FloorplanningInputs and Outputs

The input les to this step are as follows: Input Files <library>.lef demo_rtl.def Description LEF physical library data le(s), which are referenced by the library.tcl command le. The physical data le located in the test1 working directory (which was generated by the RTL synthesis step).
The output les generated by this step are: Output Files demo_se.def Description The new at physical data containing oorplanning and power design information.
Note: Floorplanning is an interactive step in the ow in which you use the SE interface directly. In this example ow, you will store any result les from this oorplanning step in your test1 working directory (Figure 4-1).
May 2001
40
Synthesis Place-and-Route (SP&R) Flow Guide Floorplanning Figure 4-1 Only One Main File is Generated By Floorplanning
demo
test1
demo_rtl.adb demo_rtl.v demo_rtl.def timing_rtl.txt
demo_se.def
Results from the floorplanning step
FloorplanningRecommended Practices
This section provides the recommended practices for oorplanning. During PKS optimization, PKS attempts to gauge how much routing resource is taken by supply rails in the oorplan. Supply rails are the power and ground stripes that connect the standard cells and are created using the followpins command in SE. If you provide a DEF le which contains supply rails in the SPECIAL NETS section, PKS uses them during congestion analysis and global routing. If supply rails are not provided in the DEF le, PKS estimates the routing resource consumed by the rails in the standard cell areas. If no power stripes exist in the DEF oorplan, PKS automatically adds followpins power stripes in each row of the oorplan in the do_route step. The geometries generated by PKS only go up to the edges of the rows and are not connected to any rings or power stripes running perpendicular to the standard cell rows. Power stripes running perpendicular to the rows remain unchanged. If the DEF oorplan contains followpins stripes, they are left untouched by optimization and are input to the do_route step. If you provide power stripes through a cover macro, which is instantiated in your design, PKS is unable to detect those power stripes that have been provided. Alternatively, PKS estimates rails during optimization and creates its own power rails as described above. To prevent this from happening, set the following global:
set_global estimate_supply_rail_congestion false
May 2001
41
Synthesis Place-and-Route (SP&R) Flow Guide Floorplanning Then, when you run do_route, use the -no_followpins option as shown below:
do_route -no_followpins
Power Striping Strategies

If you use SE to generate your oorplan, you may use the followpins utility and a script similar to that shown in Inputting Floorplanning Information on page 97 to generate your standard cell power stripes. An example of adding followpins power routing to an unplaced oorplan is also provided. Note: The example script assumes that power rings and stripes have already been generated, and that the followpins stripes are connected to the rings and stripes with vias. You can use one of the following three power striping ows depending upon your design criteria: 1. If there are no standard cells with jogs in the power lines (feedthru power), and if there are no metal1 metal obstructions in your oorplan, use the followpins created in SE by providing a DEF oorplan. 2. If you have feedthru-type power pins in your standard cell library, PKS will insert routing sections between standard cells during global routing. If your DEF le had power rails already inserted, they will be removed and replaced with power segments that do not overlap the standard cells. 3. Create the power rings using SE. Note: If you do not want to add followpins during oorplanning in SE, then you can use the following stripe generation rules to create your vertical power stripes (assuming the rows are horizontal), and then let PKS create the followpins stripes. After nal routing, do the following: a. Run the Connect Rings command in SE. This connects the power stripes generated by PKS to your rings and also connects the followpins to the power stripes. PKS does not generate any vias or attempt to connect the followpins stripes with the vertical power stripes. b. Run a search-and-repair with the nal router. This cleans up any shorts created by the Connect Rings command. Because of this nal step, this option is the least favorable of the three power striping ows.
May 2001
42
5
Synthesis, Placement, and Optimization
This chapter describes how to perform the synthesis, placement, and optimization (SPO) tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. After completing the power plan and nalizing the macro block placement in the oorplanning step, you are now ready to place and optimize your netlist.
SPOTasks
The primary tasks that take place in synthesis, placement, and optimization are: 1. Input the DEF le with the updated oorplan and power plan. The read_def must overwrite the placement, rows, and pre-routes of the design. The information that will be read from this DEF is: rows, tracks, pre-routes (in the SPECIALNETS section), and placements. 2. Set the appropriate Cadence physically knowledgeable synthesis (PKS) controls (this is discussed in more detail in Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization on page 103). 3. Perform timing driven placement. 4. Perform optimization.
May 2001
43
Synthesis Place-and-Route (SP&R) Flow Guide Synthesis, Placement, and Optimization
SPOInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. First, you require the following standard library les: Standard Library Files Description <library>.tlf <library>.lef <library>.lut TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. A layer utilization table (LUT), which is referenced by the library.tcl command le.
Next, if the original RTL has not changed and the timing in your design is good, you may decide to use the following input les: Input Files demo_rtl.adb demo_se.def Description The hierarchical gate-level or macro-level netlist located in the test1 working directory (generated in the RTL Synthesis step). The physical data le located in the test1 working directory (generated in the Floorplanning step).
If the original RTL has changed, or if you wish to start from scratch so that all of the RTL synthesis is based on your new physical data, you may decide to use the following input les (this takes longer): Input Files demo.v demo_se.def constraints.tcl Description The original RTL source le, which is located in the rtl_src directory. The physical data le located in the test1 working directory (generated in the Floorplanning step). The original timing constraints TCL le, which is located in the main demo directory.
May 2001
44
Synthesis Place-and-Route (SP&R) Flow Guide Synthesis, Placement, and Optimization The output les that are typically generated by this step are: Output Files demo_pks.adb demo_pks.v demo_pks.def timing_pks.txt Description An Ambit database containing design, oorplan, and constraint information. The new hierarchical gate/macro-level netlist for the entire design. The new at physical data containing oorplanning, placement, and power design information. A timing report le.
SPORun Script (do_pks)

Note: The commands shown below can be used as a basis for creating your own do_pks run script.
do_pks (example)
set opt_flow <rtl or gates> set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl source ${design_root}/design.tcl read_def $work_dir/demo_se.def source ${design_root}/constraints.tcl do_place -timing_driven do_xform_optimize_slack -pks write_def demo_pks.def write_verilog -hier demo_pks.v write_adb -hier demo_pks.adb report_timing > $work_dir/timing_pks.txt
This script accesses the gate-level netlist and the DEF le located in the test1 working directory, along with any other input les. The script then performs the synthesis, placement, and optimization steps and stores any results back in the test1 working directory (Figure 5-1).
May 2001
45
Synthesis Place-and-Route (SP&R) Flow Guide Synthesis, Placement, and Optimization Figure 5-1 Example Files That May Be Generated by Synthesis, Placement, and Optimization
demo
test1
Results from the synthesis, placement, and optimization step
demo_rtl.adb demo_rtl.v demo_rtl.def timing_report.txt
demo_se.def
demo_pks.adb demo_pks.v demo_pks.def timing_pks.txt
SPORecommended Practices
This section provides the recommended practices for synthesis, placement, and optimization.
Running PKS Optimizations Automatically

PKS-based optimizations run automatically when you load a oorplan or placement le, or after you set the oorplan parameters. The initial starting point can be RTL, gate-level, or placement (note that the compile strategies can very greatly depending upon what you start with). There are no hard rules on which transform you should or should not use. You have access to all of them and they can all be used effectively. However, there are a couple of things to remember:
s
If you are starting PKS with a netlist that has already been optimized but is not yet placed, you may not need to run any pre-placement optimizations. Simply do the following:
do_place do_xform_optimize_slack
PKS creates a much smaller design if you start from RTL. This is something that has been empirically proven on numerous designs, and is particularly important in a congested design where a decrease in area can signicantly affect the routability of the design. However, you can expect increased run times when there is a lot of reclaimable area.
May 2001
46
Handling High Fanout Nets During PKS Optimization

An enhancement has been included that enables more efcient handling of large fanout nets during PKS optimization. The global, large_fanout_size, was introduced to control the number of fanouts at and beyond which a net is considered to have large fanouts. This number defaults to 200, which is the same number at and beyond which do_place considers a net to have large fanouts and to be ignored during placement. During pre-placement optimization, nets which have number of fanouts greater than or equal to large_fanout_size will be ignored during DRV xing. However, if there are timing violations on these nets, attempts will still be made by the optimizer to x these timing violations. After placement, these large_fanout_size nets will be buffered up with a fast physical buffer tree algorithm similar to CTPKS. For any such net that this physical buffer tree algorithm failed to buffer up, one of the following actions will be taken:
s
if the net has number of fanouts greater than or equal to 1000, it will be marked as a large-fanout net and will be ignored for subsequent DRV xing or DRV calculations. Once again, if there are timing violations on these nets, the optimizer will still attempt to x these timing violations, possibly taking a long time. It is thus, imperative to make sure that large fanout nets do not unnecessarily or inadvertently have timing constraints on them. if the net has number of fanouts less than 1000, it will be buffered up by the regular DRV xing algorithm, considering only reducing the number of fanouts (without calculating and trying to x other DRVs) until this number gets below large_fanout_size and become more manageable. Note: To aid the review of which nets have fanouts that exceed a given threshold, the user can use report_net -hier -min_fanout n -summary, where n is the fanout threshold that the user is interested in.
May 2001
47
May 2001
48
6
Clock Tree Generation
This chapter describes how to perform clock tree generation tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. Clock tree synthesis (CTPKS) has been integrated into the Cadence physically knowledgeable synthesis (PKS) 4.0 release. It uses the same core algorithm found in CTGen, but the timing, parasitics, placement, and path tracing are provided by PKS instead of using the CTGen engine. If a CTGen constraint le already exists, it can be converted into CTPKS TCL constraints with the ctgen2pks conversion utility, which is available through your Cadence AE. A new procedure (do_ctpks) called from the spnr_utils.tcl script is provided to generate constraints based on the design constraints (Figure 6-1). Figure 6-1 Example Files That May Be Generated By CTPKS
demo
test1
Command files for, and results from, the CTPKS step
rtl_src demo.v demo.def (opt.)
demo_pks.adb demo_pks.v demo_pks.def timing_pks.txt
ctpks.tcl demo_ctpks.adb clock_tree.rpt clock_tree_violations.rpt
May 2001
49
Synthesis Place-and-Route (SP&R) Flow Guide Clock Tree Generation
CTPKSAdvantages
s
Timing consistency is maintained throughout the ow using a single timing engine (Ambit BuildGates synthesis or PKS) to calculate the timing. File exchange between standalone tools and PKS is reduced. There is no need to load the Verilog/DEF back into PKS after the clock tree is generated. No GCF le is required to generate a clock tree when using CTPKS. Timing libraries with non-monotonically increasing delays are supported by the BuildGates synthesis timing engine. (CTGen required monotonically increasing delays in the timing tables.)
CTPKSPrerequisites for Generating Clock Trees

s
Timing library les (TLF, ALF), a physical library le(s) (LEF), and a layer utilization table (LUT) must be loaded. The design must have been fully and legally placed. If mutliplexers are used to select one of several clocks, the command set_constant_for_timing must be set on the multiplexer's select pin(s) to select which clock will be used for timing analysis. All of the clock roots must be specied by set_clock_root. Clock latencies are specied by set_clock_insertion_delay. Timing constraints must be loaded into the design. Components that appear in the logical library but are missing in the physical library must be set in the constraint le as set_cell_property dont_utilize true {$cellrefs}. By default all buffers and inverters are usable. You must disable cells you do not want the clock tree tool to utilize. (This is different from how CTGen worked.) Use get_clock_tree_objects buffer|-inverter for the listing of usable buffers/inverters for the clock tree. Use set_attribute $cellrefs ct_dont_utilize true for any cells not to be used in CTPKS. Use set_attribute $cellrefs ct_dont_utilize false for desired cells to be used in CTPKS.
s s
s s
May 2001
50

s
Make sure the dont_modify property has not been set on any cell in the clock networks and clock roots.
CTPKSDependencies
s
Parasitic estimations made by CTPKS will be determined by the stage in the ow:
u u u u
WLM (no placement) Half Perimeter (set_route_mode halfperim) Steiner (set_route_mode_steiner) Layer usage table (read_layer_usages filename )
The following are for reporting only (report_clock_tree, report_clock_tree_violations):

u u u s
Global Route (do_route) RSPF SDF
Timing
u
Only 1 case of PVT (process, voltage, and temperature) can be handled at a given time, resulting in the clock tree being built for this one particular PVT. In the ow, you will have to check the clock trees for other PVTs afterwards. Slew at root (slew will propagate in the tree from the root use set_slew_time to model the input port clock root on top level) Slew propagation mode (recommended: slew_propagation_mode = fast, depth_for_fast_slew_prop = 1) False paths, disable timing, set_constant_for_timing, dont_modify
May 2001
51
CTPKSTasks
The primary tasks that take place in CTPKS are: 1. Create a TCL constraint le with the lename (ctpks.tcl) in the run directory. Note: Default new clock components and net names are specied as:
set_global instance_generator ctpks_${clockroot}_%d set_global net_generator ctpks_net_${clockroot}_%d
2. Generate default clock tree constraints with specied clock roots.

set_clock_tree_constraints pin $clock_pin min_delay 2.0 -max_delay 2.5 -max_leaf_transition 1.0
Note: You may need to modify these default numbers later. 3. Dene the clock tree boundary. The design is uniquied through the running of the command do_uniquely_instantiate (this is required by CTPKS). It will then traverse through the netlist and nd the boundary of a clock tree with the clock root specied by the user. Leaf pin/ports or excluded pin/ports are specied accordingly with the following scenarios:
u u
Clock tree into data network. If a reconvergent clock occurs at the same instance, the second input pin that shares the same clock phase is automatically set as an excluded pin. A false path is also set through that pin. If a clocks boundary is the output port of the top module, the port is declared as excluded (or the input pin of the previous non buffer/inverter gated component is declared as excluded). If an XOR or tri-state buffer component is found in the clock path, the input pin of the component is declared as excluded. If a clock connects into a ip-ops NON clock pin, the pin is declared as a leaf. If a clock connects into an input port of a soft or hard macro, the input port is declared as a leaf. If two clock trees collide at the same point, a message is output into the CTPKS constraint le. In this case, you need to resolve the conict or appoint the proper leaf pin for the proper clock at the collision point. Write out set_attribute $pin_hier_name ct_leaf rising (or falling) for leaf pins.
u u
May 2001

u
Write out set_attibute $pin_hier_name ct_excluded true for excluded pins.
4. Write out do_build_clock_tree noplace pin $clock_pin save_structure $clock_structure into the constraint le (ctpks.tcl). Note: During the do_build_clock_tree command, set_clock_propagation is automatically set to propagated and will remain in that setting unless you change it. 5. Write out report_clock_tree -pin $clock_pin > clock_tree.rpt 6. Write out report_clock_tree_violations -pin $$4clock_pin > clock_tree_violations.rpt 7. Adjust the values in the constraint le. You should make proper adjustments (if needed) to the values specied in set_clock_tree_constraints after the constraint le is generated. Then you can source this constraint le to generate clock trees. Use report_clock_tree_violations and output a report to determine if clock tree constraints are met. If not, you can either change the placement of the design, modify timing constraints and re-generate the CTPKS constraint le and new clock trees, OR you can relax the clock tree constraints and re-run CTPKS until the criteria are met. 8. If clock trees are properly built, run do_place eco to legalize the newly-inserted clock tree buffers. Note that do_place -eco only needs to be run once.
CTPKSInputs and Outputs

The input les to this step are as follows: Input Files <library>.tlf <library>.lef <library>.lut demo_ctpks.adb Description TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. An LUT Layer utilization table, which is referenced by the library.tcl command le. An Ambit database containing design, oorplan, and constraint information.
May 2001
53
Synthesis Place-and-Route (SP&R) Flow Guide Clock Tree Generation The output les generated by this step are: Output Files ctpks.tcl demo_ctpks.adb clock_tree.rpt Description The new constraints TCL le. An Ambit database containing design, oorplan, and constraint information. The clock tree report.
clock_tree_violations.rpt The clock tree violations report.
CTPKSRun Script (do_ctpks) Assumptions

s
A legally and fully placed design is loaded. (If the design is unplaced, wire-load models will be used to derive the timing.) The spnr_utils.tcl script is sourced. (This is only if you want the clock constraints automatically generated.) The prerequisites of running CTPKS are met. The timing of the design is clean (run check_timing).
s s
do_ctpks (Example)
Below is an example of the do_ctpks script being used in the ow. Physical and logical libraries are loaded with setup.tcl. Usable and non-usable cells are set in dont_utilize.tcl. The placed.adb le contains the placed design and constraints. Note that do_ctpks is a procedure embedded in the spnr_util.tcl le. Last but not least, ctpks.tcl is a CTPKS constraint le written by do_ctpks. Once the clock tree has been built and meets the constraints, invoke do_place eco to legalize the clock tree buffers/inverters placements.
set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl source $(design_root)/dont_utilize.tcl read_adb demo_placed.adb source $(design_root)/spnr_util.tcl do_ctpks -command_file ctpks.tcl source ./ctpks.tcl report_clock_tree > clock_tree.txt report_clock_tree_violations > clk_tree_violations.txt
May 2001
54

# if clktree violations found, fix the design or relax the constraints in ctpks.tcl # and then source ./ctpks.tcl again # if happy with the results do_place eco
do_ctpks (Example2)
set opt_flow <rtl or gates> set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl source ${design_root}/design.tcl read_def $work_dir/demo_se.def source ${design_root}/constraints.tcl do_place -timing_driven do_ctpks set_clock_propagation propagated do_xform_optimize_slack -pks write_def $work_dir/demo_ctpks.def write_verilog -hier $work_dir/demo_ctpks.v write_adb -hier $work_dir/demo_ctpks.adb report_timing > $work_dir/timing_ctpks.txt
CTPKSRecommended Practices
This section provides the recommended practices for CTPKS. See Post Clock Tree Optimization Constraints on page 111 for guidelines on how to write timing constraints for the design I/Os which will apply to both pre- and post- clock tree insertion.
s
In order to prevent long run times, you should try to limit the types of buffers/inverters being used by CTPKS to build your clock trees. Follow the example below to choose the desired buffers/inverters:
set buf_list [get_clock_tree_object buffer] set inv_list [get_clock_tree_object inverter] # set all of them ct_dont_utilize first foreach cell $buf_list {set_attributes $cell ct_dont_utilize true}
May 2001
55

foreach cell $inv_list {set_attributes $cell ct_dont_utilize true} # then pick the buffer(s) or inverter(s) you want to use, for example set_attribute [find cellref BUFX3] ct_dont_utilize false set_attribute [find cellref INVX3] ct_dont_utilize false s
Note that you should always check the ctpks.tcl constraint le generated by the script to ensure that the clock constraints have been set as planned. It is recommended that you run report_clock_tree before and after do_build_clock_tree. You may wish to insert the clock tree immediately after placement so that optimization has a real clock tree to work with (the clock buffers and registers will be xed during the optimization process). However, this will prevent the placement of the ip-ops from being optimized, so compare this with the results obtained by adding the clock tree after optimization. This may vary from design to design.
Note: For more information, see CTPKSPKS Clock Tree Synthesis in the PKS User Guide.
May 2001
56
7
Post Clock Tree Optimization
This chapter describes how to perform post clock tree (Post-CTPKS) optimization tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. This step addresses any Post-CTPKS optimizations of the design for setup violations. This is also the rst point at which hold-time violations will be xed. During the optimization in the propagated clock mode, all elements of the clock network are xed in both placement (dont_move) and timing (dont_modify).
Post-CTPKS OptimizationTasks
The primary tasks that take place in Post-CTPKS Optimization are: 1. Perform the optimizations. With the clock network xed, the optimizations cannot change any of the clock tree elements, or any of the sequential elements connected to the clock tree. 2. Fix hold times. See Post Clock Tree Optimization Constraints on page 111. 3. Output the following les:
u u
A new gate-level ADB A Verilog netlist
May 2001
57
Synthesis Place-and-Route (SP&R) Flow Guide Post Clock Tree Optimization

u
A new DEF for use with the global routing step
Post-CTPKS OptimizationInputs and Outputs

The input les to this step are as follows: Input Files <library>.tlf <library>.lef <library>.lut constraints.tcl demo_ctpks.adb Description TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. A layer utilization table (LUT), which is referenced by the library.tcl command le. The original timing constraints TCL le, which is located in the main demo directory. An Ambit database containing design, oorplan, and constraint information.
The output les generated by this step are: Output Files Description
demo_post_ctpks.adb An Ambit database containing design, oorplan, and constraint information. demo_post_ctpks.v The new hierarchical gate/macro-level netlist for the entire design.
demo_post_ctpks.def The new at physical data containing oorplanning, placement, and power design information.
May 2001
58
Post-CTPKS OptimizationRun Script (do_post_ctpks_optimize)

Note: The commands shown below can be used as a basis for creating your own do_post_ctpks_optimize run script.
do_post_ctpks_optimize (example)
set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl read_adb $work_dir/ctpks.adb set_clock_propagation propagated do_xform_ipo do_route -timing_driven write_def $work_dir/demo_post_ctpks.def write_verilog -hier $work_dir/demo_post_ctpks.v write_adb -hier $work_dir/demo_post_ctpks.adb
This script performs the appropriate optimizations and stores the results back into the test1 working directory (Figure 7-1). Figure 7-1 Example Files That May Be Generated By Post-CTPKS Optimization
demo
test1
Results from the post CTPKS optimization step
ctpks.tcl demo_ctpks.adb clock_tree.rpt clock_tree_violations.rpt
demo_post_ctpks.adb demo_post_ctpks.v demo_post_ctpks.def
May 2001
59
Post-CTPKS OptimizationRecommended Practices

This section provides the recommended practices for post-CTPKS optimization. Post-CTPKS optimizations can include both setup and hold-time xing (in some cases, holdtime xing can also be done after the global routing step).
Setup Fixing
s
If accurate insertion delays and skew (uncertainty) were used during optimization, the setup xing should be minimal. A timing correction is typically all that is required for setup xing.
Hold-Time Fixing
s
Hold-time xing can be done at the same time as setup xing if the timing library supports multiple operating conditions (this is only supported in TLF 4.0). If TLF 4.0 is not available, you may be required to perform several iterations between hold-time xing and setup xing.
May 2001
60
8
Global Routing and Post-Groute Optimizations
This chapter describes how to perform global routing and post-Groute optimization tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. This step involves running the global route portion of Wroute inside the Cadence physically knowledgeable synthesis (PKS) timing environment. The initial timing for global route optimization is based on the fast route estimate done inside the PKS tool. For subsequent optimization passes of the global route, the timing is based on RC information derived from the actual routes. During global routing, the router interconnects the regular (signal) nets for the design, based on the supply and demand of routing tracks. It nds generalized pathways, without laying down actual wires, and makes iterative passes to optimize the global routing, shorten wire length, and minimize the use of vias. During global routing, the router also updates the congestion map. Once the route is complete, the global route RC information is back-annotated into PKS as predictors on each net. A predictor is the difference between the steiner route estimate of the net RC value and the actual RC value from the global route. Any change that effects the net will calculate the RC value by estimating the steiner route of the net, and then reapplying the predictor (delta).
May 2001
61
Synthesis Place-and-Route (SP&R) Flow Guide Global Routing and Post-Groute Optimizations
Global Routing and Post-Groute OptimizationsTasks

The primary tasks that take place in global routing and post-Groute optimization are: 1. Input the Verilog netlist and DEF les created by the post clock tree optimizations step or a previously saved .adb le. 2. Perform in-place timing corrections (see Performing Global Routing, In-Place Timing Corrections, and Post Groute Optimizations on page 115 for more details). 3. Perform global routing (see Performing Global Routing, In-Place Timing Corrections, and Post Groute Optimizations on page 115 for more details). 4. Output a global routed database (WDB) for use with the nal (detail) routing step.
Global Routing and Post Groute OptimizationsInputs and Outputs

Note: The input and output lenames used in these discussions are for example only, and are not hard-coded into any scripts provided with the SP&R ow. First, you require the following standard library les: Standard Library Files Description <library>.tlf <library>.lef <library>.lut TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. An layer utilization table (LUT), which is referenced by the library.tcl command le.
Next, you can either: (1) Use the Ambit database generated by the previous step: Ambit Database Description
demo_post_ctpks.adb An Ambit database containing design, oorplan, and constraint information located in the test1 working directory (this was generated by the Post Clock Tree Optimization step).
May 2001
62
Synthesis Place-and-Route (SP&R) Flow Guide Global Routing and Post-Groute Optimizations Or (2) Use the following Ambit database alternatives: Ambit Database Alternatives demo_post_ctpks.v Description The hierarchical gate/macro-level netlist located in the test1 working directory (this was generated by the Post Clock Tree Optimization step).
demo_post_ctpks.def The physical data le located in the test1 working directory (this was generated by the Post Clock Tree Optimization step). constraints.tcl The original timing constraints TCL le, which is located in the main demo directory.
The output les generated by this step are: Output Files demo_groute.adb demo_groute.v demo_groute.def demo_groute.wdb Description An Ambit database containing design, oorplan, and constraint information. The new hierarchical gate/macro-level netlist for the entire design. The new at physical data containing oorplanning, power design, clock tree, and global routing information. A binary Wroute database le (the information in the demo_groute.def le corresponds to this database).
Global Routing and Post Groute OptimizationsRun Script (do_groute)

Note: The commands shown below can be used as a basis for creating your own do_groute run script.
do_groute (example)
set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl read_adb $work_dir/demo_post_ctpks.adb do_route -timing_driven true report_timing -nworst 1 -max_points 10
May 2001
63
do_xform_ipo do_route -timing_driven true -output_db_name $work_dir/demo_groute.wdb write_def $work_dir/demo_groute.def write_verilog -hier $work_dir/demo_groute.v write_adb -hier $work_dir/demo_groute.adb
The do_groute script uses the PKS database to perform global routing, check timing, and perform an incremental optimization based on the parasitics that are automatically passed back from global routing. The script then performs another global route based on the optimized results (Figure 8-1). Note: If you want to route certain nets rst (before all other nets in the design), you can use the -route_select_net net_names and -route_select_net_first options in the do_route command. Figure 8-1 Example Files That May Be Generated By Global Routing
demo
test1
Results from the global routing step
demo_post_ctpks.adb demo_post_ctpks.v demo_post_ctpks.def
demo_groute.adb demo_groute.v demo_groute.def demo_groute.wdb timing_groute.txt
Fixing Hold-Time Violations

At this point in the ow you can x hold-time violations. If your timing library contains both best and worst case conditions, you simply change modes for the library. If not, you have to restart the tool to clear out the library and reload the design with its Verilog and DEF les (see below). If the timing library contains the best and worst case conditions, do the following: 1. Change the operating conditions to best case.
May 2001
64
Synthesis Place-and-Route (SP&R) Flow Guide Global Routing and Post-Groute Optimizations 2. Run:
do_xform_fix_hold -incremental -dont_reclaim -critical_ratio 0.0
This xes the hold-time violations with minimal impact to creating setup violations. If an alternate timing library must be loaded to get the best case conditions, do the following: 1. Run write_verilog. This saves the Verilog le at the end of optimization. 2. Run write_def. This saves placement information at the end of optimization. 3. Quit and restart. This restarts PKS and loads the best case timing library. 4. Run read_verilog. This reads the design, builds the generic (link), and sources the constraints. 5. Run read_def. This reads the placement information. 6. Run:
do_xform_fix_hold -incremental -dont_reclaim -critical_ratio 0.0
This xes the hold-time violations with minimal impact to creating setup violations.
May 2001
65
May 2001
66
9
This chapter describes how to perform nal (detail) routing tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. In this step, the router routes placed and globally routed components using information described in the Wroute database.
Final RoutingTask
The primary task that takes place in nal (detail) routing is to invoke Wroute with an associated conguration le (some of the Wroute options are presented in Final (Detail) Route Options and Commands on page 117. Cadence physically knowledgeable synthesis (PKS) supports two levels of routing technology:
s
Wroute Router The Wroute router provides high quality routing, and routes up to six metal layers. The Wroute tool can be called from within PKS as part of the SP&R ow, can be run from the Silicon Ensemble place-and-route (SE) GUI, or can be run as a standalone utility. For simplicity, lets assume that Wroute is being called from within PKS by means of the do_wroute function.
ULTRA Router The ULTRA router extends the capabilities of the Wroute router to nine routing layers. It can also be called from within PKS, run from the SE GUI, or run as a standalone utility.
May 2001
67
Synthesis Place-and-Route (SP&R) Flow Guide Final (Detail) Routing
Full Routing with Search-and-Repair

A nal routing pass consists of nal routing and search-and-repair routing.
s
During global routing, the router interconnects the regular (signal) nets dened in the NETS section of the DEF le for the design, based on the supply and demand of routing tracks. It nds generalized pathways, without laying down actual wires, and makes iterative passes to optimize the global routing, shorten wire length, and minimize the use of vias. During global routing, the router also updates the congestion map. During nal routing, the router follows the global routing plan and lays down actual wires to connect the pins to their corresponding nets. It also removes routing violations and minimizes wire length and the number of vias. Final routing automatically runs searchand-repair routing unless you specify otherwise. Final routing stops automatically if it exceeds the time limit you set for routing, or if it cannot make further progress on routing the design. During search-and-repair routing, the router corrects violations. It delineates areas that are centered on design violations and reroutes each area to eliminate the violations.
Final RoutingInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. First, you need a conguration le: Conguration File wroute.config Description A Wroute conguration le (automatically generated by the do_wroute encapsulation script or provided by the user).
Next, use the following database le: Database File demo_groute.wdb Description A binary Wroute database le located in the test1 working directory (this was generated by the Global Routing and PostGroute Optimizations step).
May 2001
68
Synthesis Place-and-Route (SP&R) Flow Guide Final (Detail) Routing The output les that are typically generated by this step are: Output Files demo_wroute.def demo_wroute.wdb demo_wroute.log Description The new at physical data containing oorplanning, power design, clock tree, and nal routing information. A binary Wroute database le (the information in the demo_wroute.def le corresponds to this database). A log le.
Final RoutingEncapsulation Script (do_wroute)

The do_wroute encapsulation script rst creates a conguration le called wroute.config. The script then calls Wroute using the wroute.config conguration le. The results are a DEF le, a WDB Wroute database, and various report les (Figure 9-1). Figure 9-1 Example Files That May Be Generated By Final (Detail) Routing
demo
test1
Results from the final routing step
demo_rtl.v demo_rtl.def demo_rtl.adb timing_rtl.txt
demo_groute.adb demo_groute.v demo_groute.def demo_groute.wdb timing_groute.txt
wroute.wrconfig demo_wroute.def demo_wroute.wdb demo_wroute.log
do_wrouteAssumptions
s s
The design has been global routed and a WDB database exists. Does not require the design to be loaded in PKS to run.
May 2001
69
do_wrouteOperation
1. Checks the validity of the specied options. 2. Requires a global route database (WDB) as a command line argument. 3. Checks that the output les/directories can be created in the run directory. 4. Creates a command le. 5. Executes the command le if -run is set to true (default: false). 6. Writes out a fully routed DEF le and Wroute database (WDB).
do_wrouteCommand Syntax
See Command Syntax for Encapsulation Scripts on page 125.
do_wrouteExample Usage
s
If you are running Wroute from within PKS, use the following script to create the Wroute conguration le and run Wroute:
do_wroute -command_file $work_dir/wroute.config \ -inputDbName $work_dir/demo_groute.wdb \ -outputDbName work_dir/demo_froute.wdb \ -outputDefName $work_dir/froute.def
If you are running Wroute in standalone mode from the UNIX prompt, do the following:
wroute [-q configFileName] [-l filename] [-v] [-h]
where:
u
-q configFileName species the router conguration le. The default value uses the wroute.config le in the current directory. -l filename species the journal (log) lename. The default value uses the wr.log in the current directory. -v outputs the router version number. -h displays a brief description of the options.
u u
May 2001
70
Final RoutingRecommended Practices

This section provides the recommended practices for nal routing.
s
If antenna rules are included in the original LEF les read into PKS, then antenna repair will also be done during Final (Detail) Routing. If there are violations in the nal route, then load the WDB into SE to view the violations graphically (see Final (Detail) Route Options and Commands on page 117 for more details on how to do this).
May 2001
71
May 2001
72
10
This chapter describes how to perform parasitic extraction tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. In this step, you will use the HyperExtract tool to calculate the resistance and capacitance (RC) parasitics of design interconnections for all of the nets (or a subset) at the block or chip level. HyperExtract extracts parasitics for overlapping areas, interlayer fringe, and coupling capacitance, including fringe capacitance in the presence of an adjacent conductor. These parasitics include effects for nets routing over the cell (OTC) and over the block (OTB). These OTC and OTB effects include coupling interactions to conductors within the cell or block. HyperExtract runs on a connectivity-based layout and outputs extracted RC values in a variety of SPF formats. HyperExtract can generate either a capacitance le for each net or an RC le with a SPICE-like description of each net.
Parasitic ExtractionTask
The primary task that takes place in parasitic extraction is to invoke HyperExtract from within the Cadence physically knowledgeable synthesis (PKS) interface with an associated rules le.
May 2001
73
Synthesis Place-and-Route (SP&R) Flow Guide Parasitic Extraction
Parasitic ExtractionInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. The input les to this step are as follows: Input Files <library>.lef demo_wroute.def Description A LEF physical library data le. The at physical data containing oorplanning, power design, clock tree, and nal routing information located in your test1 working directory (this le was generated by the Final Routing step).
hyperextract.rules This rules le is provided by the company who supplies you with the main library and is typically located in the library directory (see the HyperExtract reference manual for more details). The output les that are typically generated by this step are: Output Files demo_hext.dspf or demo_hext.rspf demo_hext.log A reduced standard parasitic format (RSPF) le. A HyperExtract run log le. Description A standard parasitic format (DSPF) le.
Parasitic ExtractionEncapsulation Script (do_hyperextract)

The do_hyperextract encapsulation script is used to create a standard parasitic format (DSPF) le or a reduced standard parasitic format (RSPF) le and places it in your test1 working directory, along with a log le (Figure 10-1).
May 2001
74
Synthesis Place-and-Route (SP&R) Flow Guide Parasitic Extraction Figure 10-1 Example Files That May Be Generated By Parasitic Extraction
demo
test1
Results from the parasitic extraction step
wroute.wrconfig demo_wroute.def demo_wroute.wdb demo_wroute.log
demo_hext.dspf or demo_hext.rspf demo_hext.log
do_hyperextractAssumptions
s s s
Fully routed DEF le exists. HyperExtract Rules le matches technology specied in the LEF(s). Does not require the design to be loaded in PKS to run.
do_hyperextractOperation
1. Checks the validity of all specied options.
u u u u
LEF le(s) exist and are readable HyperExtract rules le exists and is readable Specied output directory can be created Specied DEF le exists and is readable
2. If the command le is not specied, create it.

u
Generate command_file with automatic and user-specied options
3. If create_script is false and the command le is specied, use the existing command le. 4. If run is set to true, invoke HyperExtract.
u
exec command_file
May 2001
75
Synthesis Place-and-Route (SP&R) Flow Guide Parasitic Extraction 5. Generate updated LEF capacitance numbers from the HyperExtract.log.
u
Reformat areaCap and fringeCap numbers in the log to LEF syntax and output them to the <lef_cap_file>
6. Check for the existence of the DSPF le.
do_hyperextractCommand Syntax
do_hyperextractExample Usage
s
If you are running HyperExtract from within PKS, use the following command to create the HyperExtract command le and run HyperExtract:
do_hyperextract def_file routed.def run
If you run HyperExtract in standalone mode from the UNIX prompt, use the following command:
hyperExtract
For more details on running in standalone mode, see Running HyperExtract in Standalone Mode on page 119.
Parasitic ExtractionRecommended Practices

This section provides the recommended practices for parasitic extraction.
Generating A Cross-Coupling File

To generate a cross-coupling le using HyperExtract in standalone mode, see the following example:
hyperExtract -libName lib -cellName cell -lefFileName lef \ -defFileName routed.def -extRulesFile hyperExtract.rules \ -allSliding -maxCouplingDistance 2000 -overCell \ -noPinCap -designPinCap -noTopPinCap -annotdesignPinCap \ -dSPF design_hext.dspf -siCouplingFile design_hext.xcoup -breakUpLen 60.0
May 2001
76
11
Static Timing and In-Place Optimizations
This chapter describes how to perform static timing and in-place optimization tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. Once the SPF parasitic le (DSPF or RSPF) of a routed design has been created, you can run static timing analysis and, if necessary, perform additional In-Place Optimizations. To do this, read the SPF le for the design back into the Cadence physically knowledgeable synthesis (PKS) tool to create predictors for the nets. These predictors are used to keep track of the difference between the PKS prediction for a net and the actual delay of the net. An Engineering Change Order (ECO) is a process that reads a new logical netlist, compares it to the existing layout, and changes the layout where there are differences. During ECO routing, the router tries to reroute nets that have been modied. During global ECO routing, the router removes the routes for nets that have been modied and reroutes them. Also, during nal ECO routing, the router runs nal routing on a routed design that has already had at least one nal routing pass. An ECO input le has the same syntax as a netlist DEF le. The ECO system automatically determines the differences between the new netlist and the database in memory. All such differences cause ECO actions. For example, ECO deletes nets that appear in the database but not in the new netlist. ECO also adds nets or cells that occur in the new netlist but not in the design. Therefore, the new netlist must be complete, even if you want to make successive changes to the same database.
May 2001
77
Synthesis Place-and-Route (SP&R) Flow Guide Static Timing and In-Place Optimizations
Static Timing and IPOTasks

The primary tasks that take place in static timing and in-place optimization are: 1. Load the SPF parasitic le. 2. Check timing. 3. Perform a post-route optimization. 4. Route only those parts of the netlist that have been modied.
Static TimingInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. The input les to this step are as follows: Input Files <library>.tlf <library>.lef <library>.lut demo_groute.v Description TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. A layer utilization table (LUT), which is referenced by the library.tcl command le. The hierarchical gate/macro-level netlist for the entire design located in your test1 working directory (this was generated by the Global Routing and Post-Groute Optimizations step). The at physical data containing oorplanning, power design, and clock tree information located in your test1 working directory (this was generated by the Global Routing and PostGroute Optimizations step). Parasitic le from HyperExtract.
demo_groute.def
demo_hext.rspf
The output les that are typically generated by this step are: Output Files timing_ipo.rpt Description Timing report.
May 2001
78
Static TimingRun Script (do_post_route_optimize)

Note: The commands shown below can be used as a basis for creating your own do_post_route_optimize run script.
do_post_route_optimize (example)
set design_root <path_to_top_level_design_directory> source ${design_root}/setup.tcl read_adb $work_dir/demo_post_ctpks.adb read_spf $work_dir/demo_hext.rspf report_timing -nworst 1 -max_points 10 > $work_dir/timing_post_route.rpt do_xform_ipo # Note: timing driven wroute is not performed for an ECO route. write_def demo_ipo.def write_verilog demo_ipo.v write_adb -hier demo_ipo.adb
This script loads the ADB le generated just before nal route and the SPF parasitics le from HyperExtract. The parasitics are used to run delay calculations and timing analysis. If timing is not met, optimization is performed.
IPOInputs and Outputs

Note: The input and output lenames used in this section are for example only, and are not hard-coded into any scripts provided with the SP&R ow. The input les to this step are as follows: Input Files <library>.tlf <library>.lef <library>.lut wroute_eco.cmd Description TLF timing library data le(s), which are referenced by the library.tcl command le. LEF physical library data le(s), which are referenced by the library.tcl command le. A layer utilization table (LUT), which is referenced by the library.tcl command le. A command le that is automatically created by the encapsulation script and stored in your test1 working directory.
May 2001
Input Files demo_groute.v
Description The hierarchical gate/macro-level netlist for the entire design located in your test1 working directory (this was generated by the Global Routing and Post-Groute Optimizations step). The at physical data containing oorplanning, power design, clock tree, and global routing information located in your test1 working directory (this was generated by the Global Routing and Post-Groute Optimizations step).
demo_groute.def
The output les generated by this step are: Output Files demo_ipo.adb demo_ipo.v demo_ipo.def Description An Ambit database containing design, oorplan, and constraint information. The new hierarchical gate/macro-level netlist for the entire design. The new at physical data containing oorplanning, power design, clock tree, and global routing information.
IPOEncapsulation Script (do_post_route_eco)

The do_post_route_eco encapsulation script creates a wroute_eco.cmd command le and places it in your test1 working directory. The script then calls Wroute using the wroute_eco.cmd command le. The resulting Verilog netlist, DEF le, ADB database, and various report les are also stored in the test1 working directory (Figure 11-1).
May 2001
80
Synthesis Place-and-Route (SP&R) Flow Guide Static Timing and In-Place Optimizations Figure 11-1 Example Files That May Be Generated By Static Timing and In-Place Optimization
demo Command files and results from the static timing and in-place optimizations step
test1
wroute_eco.cmd demo_ipo.v demo_ipo.def demo_ipo.adb
do_post_route_ecoAssumptions
s s
The design has been optimized in PKS after SPF back-annotation. A modied (PKS optimized) DEF exists.
do_post_route_ecoOperation
1. Checks the validity of the specied options. 2. Reads the original and modied DEF les and creates an ECO-based DEF le. 3. Checks that the DEF le is readable and the output les/directories can be created in the run directory. 4. Creates a command le. 5. Executes the command le if -run is set to true (default: false). 6. Writes out a fully routed (ECO) DEF le.
do_post_route_ecoCommand Syntax
May 2001
81
do_post_route_ecoExample Usage
To run do_wroute_eco within PKS, do the following: 1. set -run to true.
do_post_route_eco -lef_files $lef_files \ -routed_def $work_dir/froute.def \ -modified_def $work_dir/groute_eco.def \ -output_wr_eco_def $work_dir/wroute_eco.def \ -run
If you want to utilize the PKS license for another job while Wroute is running, do the following: 1. Generate a wroute.cmd le (set -run to false). 2. Exit PKS shell. 3. Issue the following command:
wroute -q wroute_eco.cmd
May 2001
82
12
Verification
This chapter describes how to perform the verication tasks as a component of the Cadence synthesis place-and-route (SP&R) ow. After the design is complete, you will need to verify it. You can perform a quick check to see that all nets were routed, and you can also perform a preliminary DRC check of the physical routing. Both of these checks are performed inside of Silicon Ensemble place-and-route (SE). See the Silicon Ensemble Place-and-Route Reference for more details.
VericationTasks
The primary tasks that take place in Verication are: 1. Verify Geometry. This veries that the routing does not violate spacing and width rules. You should turn off the same cell checks. Turning these off will prevent false violations, which are often created inside of the abstracts used for the LEF, from being agged. This is performed inside of SE (see the SE reference manual for more details). 2. Verify Connectivity This veries that all the nets in the DEF are completely connected. If the design being run is a sub-block, it is recommended that only the regular nets be checked with this command, as power nets will often have disconnected stripes that are connected at a higher level of the design. This is performed inside of SE (see the SE reference manual for more details).
Synthesis Place-and-Route (SP&R) Flow Guide Verication 3. Use HECK to perform formal verication (see the HECK reference manual for more details).
May 2001
84
A
Complete Sample Run Script
The main body of this document provides standalone run scripts to illustrate how each step in the Cadence synthesis place-and-route (SP&R) ow can be performed. For ease of use and to eliminate the need to search for specic scripts, this Appendix provides a complete sample run script that takes you through the SP&R ow from start to nish.
set design_root /home/usr/sample set work_dir $design_root/work_dir set opt_flow test1 set library_root ${design_root}/libs source ${design_root}/setup.tcl ###################################################### # Run Optimization ####################################################### # $design_file (design.tcl) - loads the design # $floor_file (floor.tcl) - defines the floorplan # $constraint_file (constraint.tcl) - defines the constraints # # This example assumes a def floorplan has already been # created and is in a def file. ###################################################### source design.tcl source floor.tcl source constraints.tcl do_optimize -pks write_def $work_dir/placed.def write_adb -hier $work_dir/placed.adb write_verilog -hier $work_dir/placed.v
May 2001
85
Synthesis Place-and-Route (SP&R) Flow Guide Complete Sample Run Script

# Here is an alternate synthesis strategy # do_optimize -pks -stop_after_placement # write_* ... # do_ctpks ... # do_remove ... # read_verilog ... # read_def ... # do_xform_optimize_slack ... ###################################################### # Run CTPks ####################################################### do_ctpks source ./ctpks.tcl report_clock_tree_violations > clk_violations.txt # if clktree violations found, fix the design or relax the constraints # in ctpks.tcl and then source ./ctpks.tcl again. # If happy with the results then ... do_place -eco # source post_clocktree_constraints.tcl # no longer needed set_clock_propagation propagated report_timing write_adb -hier $work_dir/clock.adb ###################################################### # Global Route design, check timing, & optimize if necessary ####################################################### do_route -timing_driven write_adb -hier work_dir/groute.adb write_def work_dir/groute.def report_timing -nworst 1 -max_points 10 do_xform_timing_correction -incremental -resize -buffer -dont_reclaim_area do_place -eco do_route -timing_driven true -output_db_name $work_dir/groute.wdb
May 2001
86
report_timing -nworst 1 -maxpoints 100 > $work_dir/groute_timing.rpt ###################################################### # Do Final Routing on Design ####################################################### do_wroute -command_file $work_dir/wroute.config \ -inputDbName $work_dir/groute.wdb \ -outputDbName work_dir/froute.wdb \ -outputDefName $work_dir/froute.def ###################################################### # Extract design with HyperExtract ####################################################### # $lef_files was set in the setup.tcl file. set he_rules_file ${design_root}/he/hyperExtract.rule do_hyperextract -lef_files $lef_files \ -def_file $work_dir/froute.def \ -rules_file $he_rules_file \ -dspf_file $work_dir/froute.dspf \ -run ###################################################### # Run Final Timing ###################################################### read_spf $work_dir/froute.dspf report_timing -nworst 1 -max_points 100 > $work_dir/wroute_timing.rpt ###################################################### # If timing is not met, do some more optimization ####################################################### do_xform_ipo # no global routing here. Timing is based on the dspf-based delays # & final route is eco only. report_timing -nworst 1 -maxpoints 100 >$work_dir/groute_eco_timing.rpt write_def $work_dir/groute_eco.def write_adb -hier $work_dir/groute_eco.adb
###################################################### # Run Final Timing ECO ###################################################### do_post_route_eco -create_command_file true \ -wr_command_file wr_eco.cmd \ -se_command_file se_eco.cmd \ -routed_def ./def/froute.def \ -modified_def ./def/post_do_xform_ipo.def \ -se_eco_def ./def/se_eco.def \ -lef_files $lef_files \ -wr_eco_def ./def/wr_eco.def \ -run true # Repeat hyperextract, delay calculation and timing analysis # (as shown above)
May 2001
88
B
Documentation Sources
This Appendix lists the documents that are available upon request from your Cadence application engineer. Note: Documents that are not linked are included with the Silicon Ensemble place-androute documentation set and can be viewed with the OpenBook online viewer. Document Type Data Sheets Document Name
SE_PKS Data Sheet SE_SI Data Sheet PKS Data Sheet HyperExtract Data Sheet SPR&R Flow Presentation SE_PKS Product Presentation PKS Product Presentation PKS Technical Presentation HyperExtract Technical Presentation
Presentations
May 2001
89
Synthesis Place-and-Route (SP&R) Flow Guide Documentation Sources
Document Type SE Application Notes
Document Name, continued
New Process Antenna Calculation Optimize LEF Technology Power Routing TLF Threshold Setting User Guide PVT Derating Guide Detailed Calculation of Process Antenna Effect Updating LEF Capacitance Coefficients & lefCap.pl Script & Correlation Result Wroute Clock Tree Synthesis Using CT_Gen Controlling QPlace and Wroute in the Silicon Ensemble/ Gate Ensemble 5.1 Release Effective Use of the SE 5.1 Power Planner and Router Virtual Pin and Subnet Process Antenna Effect Via Array and Minimum Area Rule Stack Vias QPlace RC Extraction AutoAbgen Flow AutoAbgen Clock Tree Synthesis Cross Talk Layer Usages Table
PKS Application Notes
May 2001
90
Document Type Other Documentation
Document Name, continued
Ambit BuildGates Synthesis User Guide Command Reference for Ambit BuildGates Synthesis and Cadence PKS Timing Analysis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Low Power Option of Ambit BuildGates Synthesis and Cadence PKS Datapath Option of Ambit BuildGates Synthesis and Cadence PKS Constraint Translator for Ambit BuildGates Synthesis and Cadence PKS HDL Modeling for Ambit BuildGates Synthesis Distributed Processing of Ambit BuildGates Synthesis PKS User Guide HyperExtract Breaking the Timing Barrier HyperExtract Reference Manual
May 2001
91
May 2001
92
C
A More Sophisticated Directory Structure
The main body of this document describes a relatively simple directory structure. This Appendix describes how to use a more sophisticated directory structure if needed. Assuming you are working with a chip design called demo, you might start by creating a directory structure like the one shown in Figure C-1. Figure C-1 The Initial Directory Structure for a Chip Design Called demo
demo
setup.tcl library.tcl design.tcl constraints.tcl
Figure C-1 shows the four main TCL control les (setup.tcl , library.tcl , design.tcl , and constraints.tcl ) residing in the top level of the demo folder. Note that the utilities.tcl le containing the encapsulation scripts (discussed earlier), along with all of the libraries containing technology-specic timing and physical information, would typically reside in some central location. The library.tcl le can be used to point to these technology-specic libraries. Lets assume that under the demo folder is a sub-folder called rtl_src . This folder contains the initial RTL-level design source les. Lets further assume that the top-level RTL source le is called demo.v. This directory would also contain any existing physical information in the form of a demo.def le. (Remember that the demo.def le is an optional input as discussed in Initial Input Files on page 19.)
May 2001
93
Synthesis Place-and-Route (SP&R) Flow Guide A More Sophisticated Directory Structure As previously mentioned, when you perform your rst what-if evaluation you could create a subdirectory called test1 (see Figure C-2). However, its at this point where you start to diverge from a simple directory structure. This is because under test1 you could create a further subdirectory called rtl , which will be used to hold the results from the RTL Synthesis step (in the form of the do_rtl run script). Figure C-2 shows that executing the do_rtl run script results in the output les being generated in the rtl directory. Figure C-2 The Directory/File Structure after Running do_rtl
demo test1 setup.tcl library.tcl design.tcl constraints.tcl rtl rtl_src demo.v demo.def (opt.) demo_rtl.v demo_rtl.def demo_rtl.adb timing_rtl..txt
Similarly, each subsequent step in the SP&R ow that is associated with this what-if evaluation should have its own directory under the test1 directory. Each step uses the les from the preceding steps results directory as its inputs and generates its own set of results as outputs (see Figure C-3).
May 2001
94
Synthesis Place-and-Route (SP&R) Flow Guide A More Sophisticated Directory Structure Figure C-3 Each Step in the Flow has its own Results Directory
demo
setup.tcl library.tcl design.tcl constraints.tcl
test1
test2
test3
rtl demo_rtl.v demo_rtl.def demo_rtl.adb timing_report.txt
floorplan demo_floorplan.v demo_floorplan.def
pks demo_pks.v demo_pks.def demo_pks.adb timing_report.txt
Also, storing the results from subsequent what-if evaluations in directories called test2 , test3 , and so forth makes it relatively easy to keep the results from each evaluation separate and distinct. A key point to remember is that each of the run and encapsulation scripts could be created so as to automatically access the input les from the correct source directory and automatically create and populate the appropriate output directory.
May 2001
95
Synthesis Place-and-Route (SP&R) Flow Guide A More Sophisticated Directory Structure
May 2001
96
D
Inputting Floorplanning Information
This Appendix describes how to automatically create a oorplan using the options in the Cadence physically knowledgeable synthesis (PKS) set_floorplan_parameters command. The information below summarizes how to use the options available with this command.
Setting the Die Size

The following set_floorplan_parameters options set the die size:
s
-bbox_initial {llx lly urx ury} This option forces the die size to a specic bounding box. This bounding box will remain constant throughout the optimization, unless growing is enabled. Note: This option overrides the aspect_ratio_initial, height_initial, width_initial, and row_utilization_initial options if they are set.
-height_initial <float> This option sets the height of the design. The io_to_core distances, row_utilization_initial, block_halo, and row_spacing options are used to calculate the width of the oorplan. Note: This option overrides the aspect_ratio_initial option.
-width_initial <float> This opiton sets the width of the design. The io_to_core distances, row_utilization_initial, block_halo, and row_spacing options are used to calculate the height of the oorplan. Note: This parameter overrides the aspect_ratio_initial option.
May 2001
97
Synthesis Place-and-Route (SP&R) Flow Guide Inputting Floorplanning Information
Automatically Calculating the Die Size

To automatically calculate the die size, use the following option:
s
-aspect_ratio_initial <float>
This option creates the default die area. The default for the aspect_ratio is 1.0. This option is used with the supporting options below to dene the rows for the die area.
Automatic Growing Control

Automatic growing takes place during optimization if the routability analysis determines that congestion cannot be removed, or if row utilization reaches its maximum before slack is met. To automatically control growing, use the following options:
s
-fixed_floorplan / -no_fixed_floorplan This option acts like a toggle switch to turn on or turn off growing.
-fixed_aspect_ratio This option (when set) tells the growing mechanism to maintain the aspect ratio set in aspect_ratio_initial as the growing takes place.
-max_height <float> This option tells the growing mechanism the upper limit for the height. If fixed_aspect_ratio is set, reaching this limit will prevent further growing. If the fixed_aspect_ratio is not set, the growing will continue until the max_width is reached.
-max_width <float> This option tells the growing mechanism the upper limit for the width. If the fixed_aspect_ratio is set, reaching this limit will prevent further growing. If the fixed_aspect_ratio is not set, the growing will continue until the max_height is reached.
May 2001
98
Supporting Floorplan Generation Options

The following options support oorplan generation:
s
-by_tracks This option (If set) states that the distances for io_to_core, block_halo, and row_spacing are to be taken as tracks. If not set, the distances are provided in microns and will be rounded to the nearest track.
-lr_io_to_core_distance {distance1 [distance2]} This option sets the distance from the edge of the die to the core rows on the left and right edges. If you specify one distance, it will be applied to both the left and right sides. If you specify two distances, the rst is applied to the left side, and the second is applied to the right side.
-tb_io_to_core_distance {distance1 [distance2]} This option sets the distance from the top and bottom of the die to the core rows on the top and bottom edges. If you specify one distance, it will be applied to both the top and bottom sides. If you specify two distances, the rst is applied to the top side, and the second is applied to the bottom side.
-row_utilization_initial <float> This option determines the initial die size for the design.
-max_row_utilization <float> This option sets the upper limit for row utilization during optimizations. If this limit is reached, the design will grow if possible. If growing is not enabled, optimizations will stop.
-row_spacing <float> This option sets the distance between rows (or row pairs if the abut_row_pairs toggle is set).
-abut_row_pairs This option informs PKS that pairs of rows must be abutted.
-flip_alternate_rows This option instructs PKS to ip every other row. The rst (bottom) row will always be set in the North position.
May 2001
99

s
-lr_block_halo <float> This option sets the default for block halos on the left and right sides of macro blocks in the design. You can set instance-based block halos using the set_block_halo command.
-tb_block_halo <float> This option sets the default for block halos on the top and bottom sides of macro blocks in the design. You can set instance-based block halos using the set_block_halo command.
Generating the Initial Floorplan from a DEF File

You can also generate an initial oorplan from a DEF le, as opposed to using the PKS set_oorplan_parameters command to drive the automatic creation of the oorplan. For example, you may want to use the DEF le if this were a re-design of an existing chip. In this case, the following information will be read or calculated from the DEF le: Note: You can override these DEF-derived parameters with the PKS set_floorplan_parameters command.
s
DieSize Identies the bounding box.
Rows Identies the rows used for the bins in PKS, passes the information to Qplace, and writes the information back into the DEF le at the end of PKS.
Tracks Identies the tracks used to calculate congestion. This information is also used by Qplace and the global router called by do_route.
IO to Core distance Identies the distance from the die edge to core rows.
Row orientation Identies the rows as being horizontal or vertical.
Row flipping Identies how the rows are ipped.
May 2001
100

s
Row Spacing Identies how the rows are spaced.
The following is also determined by the DEF le:

s s s s s
Initial utilization is calculated. Any instance placed in the DEF le that can be found in the netlist will get placed. Any placed instance labeled as + FIXED will be set with the dont_move attribute. Cover Macros found in the DEF le will be placed. Filler Cells from the DEF le can be included at your request.
Note: Some DEF-derived parameters cannot be overridden with the PKS set_floorplan_parameters command. This information will be available in a future release. Contact your Cadence representative for more information. Silicon Ensemble place-and-route (SE) has been enhanced to allow you to add followpins power stripes (power stripes which connect standard cells together) before placement. Here is an example script (it is assumed that power stripes and rings have already been added):
FLOAD DESIGN "library" ; INPUT LEF FILENAME "design.lef" noreport ; INPUT DEF FILENAME floorplan.def noreport ; SAVE DESIGN "design" ; FLOAD DESIGN "design" ; SET VAR SROUTE.LPR.STACKVIASATCROSSOVER TRUE ; SET VAR SROUTE.LPR.VIASATCROSSOVER TRUE ; SET VAR SROUTE.STACKVIASATCROSSOVER TRUE ; SET VAR SROUTE.FOLLOWPINS.FILL TRUE ; CONNECT RING NET "GND" NET "VDD" FOLLOWPIN ; ~
May 2001
101
May 2001
102
E
Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization
This Appendix describes how to set the appropriate Cadence physically knowledgeable synthesis (PKS) controls for Synthesis, Placement, and Optimization.
Setting the Appropriate PKS Controls

There are a number of PKS control settings that should be considered before moving ahead. Some are related to the utilization of the oorplan, while others are associated with optimization criteria.
s
Utilization: Target Information: sets the maximum limits.

u
set_floorplan_parameters -max_row_utilization <float> This command limits the overall utilization for the design.
Congestion: Target Information: calculates congestion by subtracting the demand for routing and placement from the supply of the bins. You can affect the supply by changing the availability of the layers from the routing supply.
u
get/set_route_availability <layer Name> <percent available> These commands set the availability for the layer. If you set Metal1 to 50%, then 50% of the tracks in the DEF will be available for congestion analysis.
May 2001
103
Synthesis Place-and-Route (SP&R) Flow Guide Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization Another way to reduce routing resources is to create blockages. Placement blockages can affect congestion, while routing blockages can affect both timing and congestion. Use the following command and its associated options:
s
get/set_preroute_parameters These commands set the size and layers to recognize the placement and/or routing obstructions. The available options include:
u
-min_place_obstacle_size <float> This option sets the minimum size of a pre-route or blockage that will be seen as a placement obstruction. Default is 6 metal1 pitches.
-min_route_obstacle_size <float> This option identies the minimum size of a pre-route or blockage that will be seen as a routing obstruction. Default is 6 metal1 pitches.
-place_obstacle_layers {lay1 lay2...} This option species the list of layers to be seen as placement obstructions. Default is the lowest two routing layers.
-route_obstacle_layers {lay1 lay2...} This option identies the list of layers that will be seen as routing obstructions. The default requires that all layers must be in an area for the area to be considered a routing obstruction.
-use_pads_for_place_obstacles <0|1> This option tells PKS to use pads (IO or Area) as placement obstacles. The default is 1 (true).
-use_pads_for_route_obstacles <0|1> This option tells PKS to use pads (IO or Area) as routing blockages. The default is 1 (true).
May 2001
104
Synthesis Place-and-Route (SP&R) Flow Guide Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization
Timing-Driven Placement
Timing-driven placement is performed automatically when do_optimize -pks is called.
Optimization
Once a designs cells have been placed, you can run any do_xform command as required and new cells will be placed. The following commands do a placement legalization as part of the command:
do_xform_optimize_slack do_xform_ipo
Any of the other do_xform commands must be followed by one of the following commands:
do_place -eco do_xform_tcorr_eco
May 2001
105
Synthesis Place-and-Route (SP&R) Flow Guide Setting Appropriate PKS Controls for Synthesis, Placement, and Optimization
May 2001
106
F
CTPKS Constraint File Example
This Appendix provides a clock tree synthesis (CTPKS) constraint le example.
CTPKS Constraint File Example

# define naming for ctpks set_global instance_generator "ctpks_CLK_%d" set_global net_generator "ctpks_net_CLK_%d" # leaf pin set_attribute [find pin DSP_INST/I_10/B1 ] ct_leaf rising # reconvergent clock set_false_path through [find pin DATA_INST/I_5/A] set_attribute [find pin DATA_INST/I_5/A] ct_excluded true set_clock_tree_constraints -pin [find port CLK] -min_delay -max_delay 2.5 max_skew 0.3 -max_leaf_transition 1.0 max_tree_transition 0.8 do_build_clock_tree -noplace pin [find port CLK] 2.0
report_clock_tree pin [find port CLK] > clock_tree_CLK.txt report_clock_tree_violations pin [find port CLK ] > clock_tree_vio_CLK.txt set_clock_tree_constraints -max_delay 2.5 max_skew -pin 0.3 [find pin CLK_int] -min_delay -max_leaf_transition 1.0 2.0
# build a clock tree using structure do_build_clock_tree noplace pin [find pin CLK_int] -use_structure CLK_int.structure do_place eco
May 2001
107
Synthesis Place-and-Route (SP&R) Flow Guide CTPKS Constraint File Example
CTPKS Clock Tree Structure File Example

define_structure from_pin DATA_INST/I_10 Q noninverting_tree INVX8 1 INVX8 1 BUFX3 1 INVX81 INVX8 1 to_pin DATA_SAMPLE/I_9 A from_pin DATA_SAMPLE/I_9 Y inverting_tree INVX8 1 to_pin TEST_CONTROL/I_8 A1 from_pin TEST_CONTROL/I_8 Y noninverting_tree to_rising_clock_pins BUFX3 1
CTPKS Commands
This section describes the CTPKS commands. Note: The commands are listed in functional order.
s s s s
reset_clock_tree_constraints set_clock_tree_constraints get_clock_tree_constraints set_attribute

u u u u u u
ct_dont_utilize ct_no_leaf ct_preserve ct_preserve_tree ct_leaf ct_excluded
s s s s
do_build_clock_tree report_clock_tree report_clock_tree_violations do_build_physical_tree
May 2001
108
Synthesis Place-and-Route (SP&R) Flow Guide CTPKS Constraint File Example Please refer to the Command Reference for Ambit BuildGates Synthesis and Cadence PKS and the PKS User Guide for more detailed information.
CTPKS Flow Diagram

Placed design Set timing constraints Set clock tree constraints Report clock tree Build clock tree Report do_place_eco Report
-Clock Tree -Violations -timing -Clock Tree -Violations -timing -Clock Tree
Design w clock tree
May 2001
109
Synthesis Place-and-Route (SP&R) Flow Guide CTPKS Constraint File Example
May 2001
110
G
Post Clock Tree Optimization Constraints
This Appendix provides post clock tree optimization constraint information.
Clock Insertion Delay

The Cadence physically knowledgeable synthesis (PKS) 4.0 release uses the set_clock_insertion_delay command to model source and network insertion delay. The difference between Source Insertion Delay and Network Insertion Delay is illustrated in Figure G-1. Figure G-1 Source Insertion Delay and Network Insertion Delay Differences
IN
FF FF
Out
External Clock Source
CLK
Source Insertion Delay Network Insertion Delay
IN represents an input OUT represents an output FF represents a flip-flop
Chip Boundary
With the ability to specify the network insertion delay, a relatively accurate clock network could be modeled; therefore, the design could be optimized so that the pre- and post-clock tree results correlate. The PKS 4.0 release utilizes the timing engine to take into account the clock insertion delays and adjusts the timing reports accordingly. The following example illustrates the clock insertion delay and how it affects the timing report on an output pin called OUT.
May 2001
111
Synthesis Place-and-Route (SP&R) Flow Guide Post Clock Tree Optimization Constraints Consider the following user-dened constraints:
set_clock vclk -period 20.0 -waveform {0 10} set_clock_root -clock vclk -pos CLK set_clock_uncertainty 0.250 #specifying the network insertion delay of 2 on CLK port set_clock_insertion_delay -pin CLK 2 set_external_delay -clock vclk 3.1 OUT
So for the following path in a design:
Q inv1
OUT
CK reg4
pks_shell> report_timing -to OUT Path 1: MET External Delay Assertion Endpoint: OUT (^) checked with leading edge of 'vclk' Beginpoint: reg4/Q (v) triggered by leading edge of 'vclk' Other End Arrival Time 0.00 - External Delay 3.10 + Phase Shift 20.00 - Uncertainty 0.25 = Required Time 16.65 - Arrival Time 3.28 = Slack Time 13.37
+---------------------------------------------------------------+ | Instance | Arc | Cell | Delay | Arrival | Required | | | | | | Time | Time | |----------+-------------+---------+-------+---------+----------| | |clk1 ^ | | |2.00 |15.37 | |reg4 |CK ^ -> Q v |DFFHQXL |1.13 |3.13 |16.49 | |inv1 |A v -> Y ^ |INVX2 |0.16 |3.28 |16.65 | | |O1 ^ | |0.00 |3.28 |16.65 | +------------------------------------------------------------------------------------------+ Notice that the Arrival Time column in the above report shows that the network insertion delay of 2 has already been accounted. If no insertion delay were specied, the arrival time to the clock pin of the register reg4 would have been 0.
May 2001
112
Synthesis Place-and-Route (SP&R) Flow Guide Post Clock Tree Optimization Constraints If the clock tree had been inserted in the design, you would have to change the clock propagation mode using:
set_clock_propagation propagated pks_shell> report_timing -to OUT Path 1: MET External Delay Assertion Endpoint: O1 (^) checked with leading edge of 'vclk' Beginpoint: reg4/Q (v) triggered by leading edge of 'vclk' Other End Arrival Time 0.00 - External Delay 3.10 + Phase Shift 20.00 - Uncertainty 0.25 = Required Time 16.65 - Arrival Time 3.08 = Slack Time 13.57
+---------------------------------------------------------------+ | Instance | Arc | Cell | Delay | Arrival | Required | | | | | | Time | Time | |----------+-------------+---------+-------+---------+----------| | |clk1 ^ | | |0.00 |13.74 | |buf_L1 |A ^ -> Y ^ |BUFX2 |0.80 |0.80 |14.54 | |buf_L2 |A ^ -> Y ^ |BUFX2 |0.80 |1.80 |15.37 | |reg4 |CK ^ -> Q v |DFFHQXL |1.13 |2.93 |16.49 | |inv1 |A v -> Y ^ |INVX2 |0.16 |3.08 |16.65 | | |O1 ^ | |0.00 |3.08 |16.65 | +---------------------------------------------------------------+ The report shows that in the propagated mode, the specied network insertion delay of 2.0 is ignored and actual delay through the clock tree buffers (buf_L1 & buf_L2) is considered. Unlike previous releases, no modications to the boundary constraints are required.
May 2001
113
Synthesis Place-and-Route (SP&R) Flow Guide Post Clock Tree Optimization Constraints
May 2001
114
H
Performing Global Routing, In-Place Timing Corrections, and Post Groute Optimizations
This Appendix describes how to perform global routing, in-place timing corrections, and post Groute optimizations.
Performing Global Routing

To perform global routing, use the do_route -timing_driven command to run the global router of Wroute, using the Cadence physically knowledgeable synthesis (PKS) timing engine for the timing of nets to determine their criticality and order. During routing, timing reports are generated showing the worst case slack. These reports are printed periodically as the run progresses. The rst timing report is based on the steiner estimates before the global route begins, all other timing reports are generated during the route and are based on RC information extracted from the global route. As the run progresses, the timing may get worse due to the fact that trade-offs will be made between congestion and timing. After the routing is completed, a Wroute database (WDB) is created along with a new DEF le that corresponds exactly to the database inside Wroute. Also, the RC information is backannotated into the PKS database. Note: If you ran the global router with the -route_select_net and -route_select_net_first options (do_route command), you should also use the equivalent options in Wroute (routeSelectNet and routeSelectNetFirst).
Performing In-Place Timing Correction

After the global route is completed and the RC information is back-annotated as predictors into the design, you can reoptimize the design using the new (more accurate) RC information. The scope of optimizations at this stage should be very limited in order to prevent the routing from changing signicantly.
Synthesis Place-and-Route (SP&R) Flow Guide Performing Global Routing, In-Place Timing Corrections, and Post Groute Optimizations Rerun the do_route -timing_driven command. Since Wroute does not support timingdriven ECO routing capability, it is necessary to route the result of the optimization again. Repeat the above steps until the timing at the end of the second route is satisfactory.
Performing Post Groute Optimizations

Once the route is complete, it may be necessary to run post groute optimizations. At this level, minimal changes to the netlist should be made to ensure timing closure. Unless the design has undue congestion, there should be a limited number of issues to x. At this point, it is recommended to do only resizing and/or buffering and to not allow area reclamation. This can be accomplished using the following command:
do_xform_timing_correction -buffer -resize -incremental -dont_reclaim_area -ORdo_xform_ipo
May 2001
116
I
Final (Detail) Route Options and Commands
This Appendix provides nal (detail) route options and commands. Note: The Wroute conguration le contains the conguration options set for the run.
Setting the Options

If you are running the router as a standalone tool, you can use the default values for all options with the following exceptions:
s
Your conguration le must contain values for inputDbName or inputDefName and inputLefName If you want the router to save the routed data, set outputDbName and/or outputDefName
Running Wroute in Standalone Mode

You can use the following commands when running Wroute in standalone mode:
inputDBName groute.wdb outputDbName wroute.wdb outputDefName wroute.def outputFullDef true timingRSPFReportName wroute.rspf routeGlobal false routeFinal true
Note: If you ran the global router with the -route_select_net and -route_select_net_first options using the do_route command, you should also use the equivalent options in Wroute (routeSelectNet and routeSelectNetFirst).
May 2001
117
Synthesis Place-and-Route (SP&R) Flow Guide Final (Detail) Route Options and Commands
Stopping Wroute in Standalone Mode

To stop the router in standalone mode, press Control-C.
s s
If the router is performing global routing it stops and does not save any data. If the router is performing nal routing or search-and-repair routing in standalone mode, it stops and saves the current routing into the design database.
Running Wroute from within the SE GUI

You can use the following commands when running Wroute from within the Silicon Ensemble place-and-route (SE) GUI:
INPUT DEF FILENAME groute.wdb.def ; INPUT WROUTE DB groute.wdb ; SET VAR WROUTE.GLOBAL false ; SET VAR WROUTE.INPUT.DBNAME groute.wdb ; SET VAR WROUTE.FINAL TRUE ; SET VAR WROUTE.INCREMENTAL.FINAL TRUE ; SET VAR WROUTE.SEARCHREPAIR TRUE ; WROUTE NOCONFIG ; OUTPUT DEF FILENAME "routed.def" ;
May 2001
118
J
Running HyperExtract in Standalone Mode
This Appendix describes how to run HyperExtract in standalone mode.
HyperExtract Inputs
HyperExtract supports the following inputs, which support a variety of optional HyperExtract features:
s s s
GDS les to input detailed block descriptions and increase OTC extraction accuracy A timing library (TLF) for delay calculation and pin cap A via resistance table
HyperExtract Outputs
HyperExtract generates the following outputs:
s s s s s s
Allows you to import an existing database for HyperExtract to extract Creates and extracts a pillar or Genesis database from a design Creates a cell Library in LEF Creates a routed design in DEF Creates a technology le named tech.dpux Creates a pillar or Genesis design database that contains a routed design
May 2001
119
Synthesis Place-and-Route (SP&R) Flow Guide Running HyperExtract in Standalone Mode
Running HyperExtract
You can run HyperExtract in standalone mode using the hyperExtract command at the UNIX prompt. After invoking HyperExtract, the following menu appears: Note: Fill in the form and click OK . LibName Pillar database library name
CellName V LefFileName DefFilename FromChar FromHierChar CellsListFile LayerMapFile ExtRulesFile AllSliding MaxCouplingDistance DlcInitFile AllPinCap TimingLibCap AllTopPinCap RSPF DSPF ToChar ToHierChar
Top level cell name View name layout LEF le DEF le BUS character Hierarchy delimiter GDSII cell name le Pillar GDSII tech le HyperExtract rule le
Coupling distance File containing the TLF les Enabling HE to include Cells/blocks pincap data
Enabling HE to include external loading data from the synthesis constraint le RSFP le name to be generated by HE DSPF le name to be generated by HE BUS character to map to Hierarchy delimiter to map to
dlcInitFile Syntax
CTLF_FILE <full path to the ctlf file A> CTLF_FILE <full path to the ctlf file B>
May 2001
120
K
Pearl Commands used to Create an SDF
This Appendix describes how to create an SDF le using Pearl commands. It also includes information about how to perform delay calculation tasks.
Creating An SDF With Pearl

Note: Creating an SDF with Pearl commands is no longer needed in the Cadence synthesis place-and-route (SP&R) ow. This information is provided for reference only. The following command le is used to generate an SDF le for a design:
Logfile pearl.sdflog SetMaxPossibilities 100 ReadGCFTimingLibraries /ambit/pks/libs/tsmc_25/tsmc_25.gcf ReadTechnology /ambit/pks/libs/pearl.tch ReadDefNetlist wroute.def IdealClocks yes ReadSPF wroute.rspf ReadGCFConstraints /ambit/pks/glenng/regress/Test7/Test7.gcf WriteSDFDelays -port_interconnect -precision 6 -version 2.1 -ns wroute.sdf ReadSDF wroute.sdf TimingVerify ShowPossibility 1 100 > sdf.rpt Quit
May 2001
121
Synthesis Place-and-Route (SP&R) Flow Guide Pearl Commands used to Create an SDF
Delay Calculation
Note: Delay calculation tasks are shown here to illustrate the ow as it used to be in the SP&R ow based on the Cadence physically knowledgeable synthesis (PKS) 3.0.x release. In the new SP&R ow based on the PKS 4.0.x release, delay calculations are performed internally to PKS and there are no dedicated run scripts or specic delay calculation tasks for you to carry out. Parasitic reduction and delay calculation are now done in Ambit BuildGates synthesis and PKS tools. All you need is a DSPF or RSPF parasitic le from either Wroute (parallel plate extraction) or HyperExtract (2.5D extraction).
Delay CalculationRun Script (do_delay_calc)

The do_delay_calc run script reads a parasitic le (either detailed or reduced) and reports timing based on those parasitics. Figure K-1 shows the les that may be generated after running delay calculation. Figure K-1 Example Files That May Be Generated By Delay Calculation
demo
test1
Results from the delay calculation step
demo_hext.dspf or demo_hext.rspf demo_hext.log
sdf.cmd demo_pearl.sdf
do_delay_calcAssumptions
n
A parasitic le is available from either global or nal routing.
do_delay_calcOperation
1. Requires an SPF le (generated by the parasitic extraction step). 2. Reads the SDF parasitic le. 3. Reports timing.
May 2001
122
L
GCF File to Load Timing Libraries
This Appendix provides an example GCF le for loading timing libraries. Note: A GCF le for loading timing libraries is no longer needed in the Cadence synthesis place-and-route (SP&R) ow. This information is provided for reference only. The Pearl timing engine and the CTGen clock tree synthesis tool both require a GCF le to load the timing libraries. This GCF le is also used to set the operating conditions for the library. An example GCF le is shown below:
example_gcf_le.gcf
(GCF (HEADER (VERSION "GCF Version 1.3" ) (DESIGN "Test2" ) (DELIMITERS "/[]" ) (TIME_SCALE 1E-9 ) (CAP_SCALE 1E-12 ) (RES_SCALE 1E3 ) (VOLTAGE_SCALE 1E0 ) ) (GLOBALS (GLOBALS_SUBSET ENVIRONMENT (PROCESS 1.0000 1.0000) (VOLTAGE 2.3 2.3 ) (TEMPERATURE 85 85) (OPERATING_CONDITIONS "TYP" 1.0000 2.3000 85.0000) (VOLTAGE_THRESHOLD 10.0000 90.0000) (EXTENSION "CTLF_FILES" (/ambit/pks/lib/stdcells.ctlf /ambit/pks/lib/ios.ctlf /ambit/pks/lib/macros.ctlf) )
Synthesis Place-and-Route (SP&R) Flow Guide GCF File to Load Timing Libraries
) ) )
May 2001
124
M
Command Syntax for Encapsulation Scripts
This Appendix provides the command syntax for encapsulation scripts.
The do_ctpks Command

The following do_ctpks command information is provided:
s s s
Encapsulation Prerequisites Outputs
Encapsulation
do_ctpks -command_file <filename>
Create a ctpks.tcl script which declares all of the possible ct_leaf and ct_excluded pins/ports and prompts you for reconvergent clocks and multiple clock trees collision scenarios. The -command_file option species the constraint le name written out by do_ctpks. This option defaults to ctpks.tcl.
Prerequisites
s
Timing library les (TLF/CTLF/ALF), a physical library le or les (LEF), and a layer utilization table (LUT) must be loaded. The design must have been fully and legally placed. All of the clock roots mut be specied by set_clock_root. Clock latencies are specied using the set_clock_insertion_delay command.
s s
May 2001
Synthesis Place-and-Route (SP&R) Flow Guide Command Syntax for Encapsulation Scripts
s s
Timing constraints must be loaded into the design. Components that appear in the logical library, but are missing in the physical library, must be set in the constraint le as:
set_cell_property dont_utilize true {$cellrefs}.
By default all buffers and inverters are usable. You must specically disable the cells you do not want used by setting the attribute ct_dont_utilize to true on those cells. (This behavior is different from CTGen.) Use get_clock_tree_objects buffer|-inverter for a listing of usable buffers/ inverters for the clock tree. Use set_attribute $cellrefs ct_dont_utilize true for any cells you do not want used in CTPKS. Use set_attribute $cellrefs ct_dont_utilize false for cells you want used in clock tree synthesis (CTPKS). Note: If you declare any cells to be used by CTPKS, you will also need to declare cells that you do NOT want used by CTPKS. (This is different from CTGEN.)
Make sure the dont_modify property is set on any of the cells in the clock networks or clock roots.
Outputs
s
A CTPKS constraint le with:

u u u
Clock tree constraints are set to default values. Proper ct_leaf and ct_excluded are declared. Disable paths are properly set for reconvergent clock.
Important
Currently there are hard-coded values for clock tree constraints in the script. In a future release, options will be available to customize the clock tree constraints.
May 2001
126
The do_wroute Command

The following do_wroute command information is provided:
s s s s s s
Wroute Encapsulation Required Inputs Outputs Command Syntax on page 128 Assumptions on page 129 Operation on page 129
Wroute Encapsulation
do_wroute
Creates a Wroute command le and invokes Wroute using the -run option.
Required Inputs
s
inputDbName The name of the Groute database (if the -inputDbName is not specied, the script performs a global route rst).
Outputs
s
Fully routed DEF le
May 2001
127
Command Syntax
Below is a list of Wroute options. Only the options specied at the command line are included in the command le. To override the default values, enter the option with the appropriate selection when invoking do_wroute. For example:
do_wroute -run -inputDbName groute
Wroute Option -run -inputDbName -command_file -create_command_file -routeFinal -routeGlobal -outputDbName -outputDefName -frouteSearchRepair -routeSelectNetFirst -selectNets
Description Invokes Wroute {true | false}. The default is false. Name of the input Groute database. Name of the Wroute command le. The default is wroute.cmd Creates the command le with the name specied by command_file . The default is true. Performs nal routing if set to true {true | false}. The default is true. Performs global routing if set to true {true | false}. The default is false. Name of the output Wroute database. The default is wroute.wdb. Name of the output DEF le. The default is wroute.def. Performs search and repair when set to true {true | false}. The default is true. Routes the net specied as routeSelectNets rst {true |false}. The default is true. Name of the select nets. The default value is @CLOCK .
-routeBottomLayerLimit Limits the bottom routing layer to the specied value. Disabled if 0 (0-6). The default value is 0. -routeTopLayerLimit Prevents routing above the specied layer. Disabled if 0 (06). The default value is 0.
To run Wroute within the Cadence physically knowledgeable synthesis (PKS) tool, use the -run option. If you want to utilize the PKS license for another job while Wroute is running, do the following:
May 2001
128
Synthesis Place-and-Route (SP&R) Flow Guide Command Syntax for Encapsulation Scripts 1. Generate a wroute.cmd le (set -run to false by default). 2. Exit the PKS shell. 3. Issue the wroute -q wroute.cmd command.
Assumptions
s
Design is loaded in PKS.
Operation
s s s
Unlike other scripts, do_wroute doesnt require any LEF or CTLF le information do_wroute performs global and/or nal routing If -inputDbName is provided as a command line option, do_wroute will not perform global routing Checks that a design is loaded in PKS Checks that all the input les are readable and the output les/directories can be created in the run directory Creates a command le Executes the command le if -run is used as a command line option (default: false) Writes out a fully routed DEF le
s s
s s s
The do_hyperextract Command

The following do_hyperextract command information is provided:
s s s s s s
HyperExtract Encapsulation on page 130 Required Inputs on page 130 Outputs on page 130 Command Syntax on page 131 Assumptions on page 131 Operation on page 132
May 2001
129
HyperExtract Encapsulation
do_hyperextract def_file routed.def run
Creates HyperExtract run script and invokes HyperExtract.
Required Inputs
s
LEF le(s)
u u
Specied in-line, through a global, or from a new ac_shell command Error checking to detect le(s) exists and is readable
Routed DEF
u u
Must be a fully routed DEF and specied in-line Error checking to detect le exists and is readable
Command le
u
If specied in-line and create script ag is true, uses specied command le error checking to detect le exists and is readable otherwise, create on the y
HyperExtract rules le
u u
Must be specied in-line Error checking to detect le exists and is readable
Outputs
s s s s
DSPF or RSPF Updated LEF capacitance le Optional set_load/set_resistance le Optional wire load model le
May 2001
130
Command Syntax
do_hyperextract
HyperExtract Option Description -run -directory -command_file -create_script -lef_files -def_file -dspf_file -lef_cap_file -rule_file Invokes HyperExtract after creating/validating command le (default: false). Name of directory to write les and run (default: he_rundir). Name of command le to use (default: auto-create he.cmd). Creates the command le with the name specied by command_file (default: true:). Name of LEF les [ex: lef1 lef2] (default: or $lef_les if dened). The full path and name of existing routed DEF to use (default: ). The full path and name of output DSPF le (default: <top_cell>.dspf). Name of output updated LEF capacitance le (default: lefCap.lef). The full path and name of HyperExtract extraction rules le (default: hyperExtract.rules).
-wire_load_model The full path and name of output wire load model le for design (no default). -set_load -gds_layer_map -gds_file -shrink_factor The full path and name of output set_load le for design (no default). Name of GDSII layer map le (no default). Name of le containing name and paths of the GDSII (no default). The factor value used to shrink the entire design by (default: 1.0).
Assumptions
s s
Fully routed DEF exists HyperExtract Rules le matches technology specied in the LEF(s)
May 2001
131
Operation
s
Checks validity of all specied options

u u u u
LEF le(s) exist and are readable HyperExtract rules le exists and is readable Specied output directory can be created Specied DEF le exists and is readable
If command le is not specied, create command le

u
Generate command_file with automatic and user specied options
s s
If create_script is false and command le is specied, use existing command le If run set true, invoke HyperExtract
u
exec <command_file>
Generate updated LEF capacitance numbers from HyperExtract.log

u
Reformat areaCap and fringeCap numbers in log to LEF syntax and output to <lef_cap_file>
Check existence of dSPF le
The do_post_route_eco Command

The following do_post_route_eco command information is provided:
s s s s s s
Wroute Encapsulation on page 133 Required Inputs on page 133 Outputs on page 133 Command Syntax on page 133 Assumptions on page 134 Operation on page 134
May 2001
132
Wroute Encapsulation
do_post_route_eco -routed_def <filename> -modified_def <filename>
Creates wroute_eco command le and invokes wroute in SE environment.
Required Inputs
s
lef_files
u u
Specied as a command line, through a global, or from a new ac_shell command. The script performs an error check to detect if the le(s) exists and is readable.
Original DEF
u u
Original routed DEF le is required as a command line argument. The script performs an error check to detect if the le exists and is readable.
Modied DEF
u u
Modied DEF le from PKS is required as a command line argument The script performs an error check to detect if the le exists and is readable.
Outputs
s
Fully routed (eco) def le
Command Syntax
do_post_route_eco
Wroute Option -run -lef_files -routed_def -modified_def
Description Invokes Wroute in eco mode (true | false default: false). Name of LEF les [ex: "lef1 lef2"] (no default -- required parameter). Name of full routed DEF le (no default -- required parameter). Name of modied DEF le (no default -- required parameter).
May 2001
133
Wroute Option -se_command_file -wr_command_file
Description Name of the SE command le (default: se_eco.cmd) Name of the Wroute command le (default: wr_eco.cmd ).
-create_command_file Creates the command le with the name specied by -command_file (default: true). -se_eco_def -wr_eco_def Name of the eco DEF le created by SE (default: se_eco.def ). Name of the eco DEF le created by Wroute (default: wr_eco.def )
To run do_post_route_eco within PKS, set -run to true. If you want to utilize the PKS license for another job while wroute is running, do the following: 1. Generate a wroute.cmd le (set -run to false, by default). 2. Exit the PKS shell. 3. Issue the following command:
wroute -q wr_eco.cmd
Assumptions
s s
Design is optimized in PKS after SDF back annotation An original and modied (PKS optimized) DEF exists
Operation
s s s
Takes the original and modied DEF le and invokes SE to generate an eco DEF Requires original and modied DEF les as a command line argument Checks that the DEF le is readable and the output les/directories can be created in the run directory Creates a command le for Wroute with wr_eco.cmd Executes the command le if -run is a command line option Writes out a fully routed (eco) DEF le
s s s
May 2001
134
N
Synopsys Conversion Utility
This Appendix describes how to use the Cadence constraint translator to translate Synopsys constraints into the Ambit BuildGates synthesis constraint format. In the Synopsys environment, constraints can be specied or derived from a variety of sources. You can enter hand-written constraints for Design Compiler (DC) using the dc_shell language constructs, or using the pt_shell language constructs for PrimeTime (PT). Both dc_shell and pt_shell provide constraint commands along with general scripting capability including control structures and variables. DC and PT are both capable of generating a write_script output, which is essentially an unrolled view of the original constraints. The Ambit BuildGates synthesis constraint translator is capable of translating DC or PT write_script output (in DCSH and TCL formats) into a BuildGates synthesis format constraints le using the read_dc_script command. The translator issues detailed error and warning messages if problems are encountered during translation. The translator is invoked using the read_dc_script TCL command in the BuildGates synthesis ac_shell or pks_shell environments. Prior to invoking the translator, you must do the following: 1. Invoke ac_shell (or pks_shell). 2. Read in the libraries. 3. Read the design netlist into ac_shell (or pks_shell). This is a must for translation. 4. Run do_build_generic (if you read in the RTL netlist).
May 2001
135
Synthesis Place-and-Route (SP&R) Flow Guide Synopsys Conversion Utility Now you are ready to translate Synopsys constraint les. For the translator to perform effectively, the following set of guidelines are recommended and should be applied to the Synopsys constraint le being convertion:
s
The Synopsys constraints should be in the write_script output form (using write_script -no -hierarchy). The name used for the operating condition in the Synopsys construct set_operating_conditions should match a name for the operating conditions in the Ambit library (and the two environments must specify the same values for the process, voltage and temperature operating conditions). The library and cell names of the driver cell (in the set_driving_cell construct) should match those used on the Ambit side.
Note: The translator may run into issues with certain commands, in which case it will issue warning or error messages to the ac_shell.log le. Examine this le closely and manually x any problem areas before using the translated BuildGates synthesis constraints. In order to check the accuracy of the translation process, always generate a timing report in the BuildGates synthesis tool and compare this to the report that is generated by Design Compiler or PrimeTime using the original constraints. Details of the constraint translator are provided in the Constraint Translator for Ambit BuildGates Synthesis and Cadence PKS . Useful information is also provided in the following two solutions articles that are available through Cadence's Sourcelink website (http://sourcelink.cadence.com):
s s
1839351 TCL script to verify the correctness of Synopsys to Ambit constraint translation. 1839887 read_dc_script elimination of constraints during translation.
May 2001
136

SPR Flow

Uploaded by

Document Information

Original Description:

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

SPR Flow

Uploaded by

Copyright:

Available Formats

Synthesis Place-and-Route (SP&R) Flow Guide

Product Version 4.0.8 May 2001

Synthesis Place-and-Route (SP&R) Flow Guide

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

5 Synthesis, Placement, and Optimization

6 Clock Tree Generation

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

7 Post Clock Tree Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8 Global Routing and Post-Groute Optimizations . . . . . . . . . . . . . . . 61

9 Final (Detail) Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

Final RoutingRecommended Practices

11 Static Timing and In-Place Optimizations

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

F CTPKS Constraint File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

G Post Clock Tree Optimization Constraints . . . . . . . . . . . . . . . . . . . . 111

I Final (Detail) Route Options and Commands . . . . . . . . . . . . . . . . 117

J Running HyperExtract in Standalone Mode . . . . . . . . . . . . . . . . . . 119

K Pearl Commands used to Create an SDF . . . . . . . . . . . . . . . . . . . . 121

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

L GCF File to Load Timing Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

M Command Syntax for Encapsulation Scripts . . . . . . . . . . . . . . . . . 125

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

N Synopsys Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

About This Manual

Other Information Sources

Product Version 4.0.8

The following books are helpful references.

Text Command Syntax

Product Version 4.0.8

About the Graphical User Interface

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide Preface

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide

Product Version 4.0.8

Product Version 4.0.8

Synthesis Place-and-Route (SP&R) Flow Guide IntroductionRTL to GDSII

Overall Flow and Associated Commands

3rd Party Synthesis

RTL Synthesis RTL Synthesis

Synthesis, Placement, Synthesis, Placement, Optimization and Optimization

Clock Tree Generation Clock Tree Generation

Post Post Clock Tree Clock Tree Optimizations Optimizations

Propagated Clocks Post Clock Tree Optimization

Global Routing Global Routing

Final (Detail) Routing

Final (Detail) Routing

Final Route Search and Repair HyperExtract 2.5D Parasitic extraction

Parasitic reduction and delay calculation

SDF Back Annotation Timing Correction Hold Time Fixing

Product Version 4.0.8