User Guide
Version Z-2007.03, March 2007
Comments?
Send comments on the documentation by going
to http://solvnet.synopsys.com, then clicking
Enter a Call to the Support Center.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks ()
Synopsys, AMPS, Cadabra, CATS, CRITIC, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM,
HSPICE, iN-Phase, in-Sync, Leda, MAST, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler,
PrimeTime, SiVL, SNUG, SolvNet, System Compiler, TetraMAX, VCS, Vera, and YIELDirector are registered trademarks
of Synopsys, Inc.
Trademarks ()
AFGen, Apollo, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, Columbia, Columbia-CE, Cosmos,
CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, DC Expert, DC Professional, DC Ultra, Design Analyzer,
Design Vision, DesignerHDL, Direct Silicon Access, Discovery, Encore, Galaxy, HANEX, HDL Compiler, Hercules,
plus
Hierarchical Optimization Technology, HSIM
, HSPICE-Link, i-Virtual Stepper, iN-Tandem, Jupiter, Jupiter-DP,
JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Magellan, Mars, Mars-Xtalk, Milkyway,
ModelSource, Module Compiler, Planet, Planet-PL, Polaris, Power Compiler, Raphael, Raphael-NES, Saturn, Scirocco,
Scirocco-i, Star-RCXT, Star-SimXT, Taurus, TSUPREM-4, VCS Express, VCSi, VHDL Compiler, VirSim, and VMC are
trademarks of Synopsys, Inc.
ii
Contents
Whats New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xlviii
xlviii
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lii
1. Introduction to Astro
Benefits of Using Astro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-3
Astro Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-4
1-6
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-6
1-7
1-9
1-10
1-11
1-11
1-12
1-13
iii
2-3
2-3
2-4
2-9
2-10
2-10
Detaching Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-12
Types of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-12
2-13
2-13
2-15
2-16
2-17
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-17
2-17
2-18
2-21
2-22
iv
2-8
2-22
2-22
2-23
Creating Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-26
2-27
2-28
2-28
2-30
2-31
2-33
2-34
2-34
2-35
2-35
Replay Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-36
Startup Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tool Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Library Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-37
2-37
2-38
Load Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-38
Script Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-39
2-39
2-41
2-43
3-2
3-2
3-2
3-2
3-3
GDSII Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netlist Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synopsys Design Constraints File . . . . . . . . . . . . . . . . . . .
Design Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synthesis Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Input Requirements for Astro . . . . . . . . . . . . . . . . . . . .
3-4
3-6
3-6
3-8
vi
3-3
3-3
3-3
3-3
3-4
3-9
3-11
3-15
3-24
3-29
3-35
3-36
3-37
3-38
3-39
3-39
3-40
3-42
4-2
4-8
4-8
4-11
4-16
4-18
4-19
4-23
4-28
4-28
4-28
4-29
4-29
4-29
4-30
5-2
Floorplanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-5
5-10
vii
5-14
5-18
6-3
6-6
6-9
6-11
6-12
6-13
6-14
Unit Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
6-16
6-17
6-18
6-18
6-18
6-19
Environment Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ECS and Slew Degradation . . . . . . . . . . . . . . . . . . . . . . . .
Setting Ideal Network Delay (Clock Latency) . . . . . . . . . . .
6-20
6-29
6-30
Optimization Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-31
Library Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-37
Parasitics Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-38
Model Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-42
Xtalk Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-45
6-49
6-50
6-50
6-51
6-52
6-53
6-55
6-58
6-59
6-60
6-60
6-60
6-62
6-62
6-53
6-63
7. Analyzing Timing
Using Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Clock Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Probing Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Analyzer Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-3
7-10
7-11
7-12
ix
7-14
7-14
7-15
7-17
7-17
7-18
7-19
Interactive Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
astEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-21
astChangeNetlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-23
7-21
7-25
Placement Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-27
7-27
Timing/Optimization Information . . . . . . . . . . . . . . . . . . . . . .
7-27
DRC Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-29
7-30
7-32
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-34
Hints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-36
7-36
7-37
Design Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-39
7-39
7-40
7-40
7-41
7-41
7-43
7-43
7-45
7-46
7-47
8-3
8-9
8-14
Defining Magnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-14
8-15
Using astMagnetPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-16
8-17
8-20
8-20
8-21
xi
Using astAutoPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating Automatic Placement . . . . . . . . . . . . . . . . . . . . . . . . . .
8-28
8-28
8-31
8-32
8-33
8-33
Optimizing Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-35
8-36
8-36
8-38
8-40
8-43
8-43
8-45
8-45
8-45
xii
8-22
8-46
8-46
8-47
8-48
8-52
8-58
8-58
8-63
8-63
8-64
8-64
8-65
8-66
8-67
8-68
Refining Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Search and Refine . . . . . . . . . . . . . . . . . . . . . .
Moving Standard Cells in a Specific Area . . . . . . . . . . . . .
8-69
8-69
8-71
9-3
9-7
9-9
xiii
9-12
9-14
9-18
9-18
9-20
9-22
9-24
9-26
9-28
9-29
9-33
9-36
9-37
9-39
9-43
9-47
9-49
9-49
9-54
9-56
9-58
9-59
9-60
9-60
xiv
9-62
9-63
9-64
9-65
9-66
9-66
9-66
9-67
9-67
9-68
9-70
9-72
9-75
9-76
9-77
9-78
9-79
9-80
9-80
9-81
9-81
9-82
9-82
9-83
9-85
9-90
9-91
xv
9-94
9-96
9-99
9-102
9-107
9-109
9-111
10-3
Routing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-5
10-6
Preroutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-7
10-7
10-8
10-9
10-10
10-16
10-18
xvi
10-22
10-23
10-27
10-28
10-28
10-29
10-30
10-30
10-32
10-32
Track Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Density-Driven Track Assignment . . . . . . . . . . .
Limiting Net Layer Length to Prevent Floating
Antennas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Track Assignment. . . . . . . . . . . . . . . . . . . . . . .
Optimizing After Track Assignment. . . . . . . . . . . . . . . . . . .
10-33
10-34
Detail Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Detail Routing . . . . . . . . . . . . . . . . . . . . . . . . .
Handling Misaligned Tracks and Off-Grid Pins . . . . . . . . . .
Optimizing After Detail Routing . . . . . . . . . . . . . . . . . . . . .
10-36
10-36
10-36
10-37
Search-and-Repair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-37
10-34
10-35
10-35
10-39
xvii
10-39
Shielding Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shielding With Rules Defined As Variable Routing
Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ignoring Shielding During Detail Routing . . . . . . . . . . . . . .
Shielding With Default Spacing Rules . . . . . . . . . . . . . . . .
10-40
10-44
10-41
10-42
10-42
10-46
Track Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-48
Detail Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-48
Search-and-Repair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-50
10-53
10-55
xviii
11-2
11-4
11-6
Inverter-Only Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . .
11-7
11-8
11-11
11-13
11-14
11-14
11-19
12-3
Using axDrouteOptimizeContact . . . . . . . . . . . . . . . . . . . . . .
12-6
Using axgOptimizeContact . . . . . . . . . . . . . . . . . . . . . . . . . .
12-7
12-14
12-16
12-17
xix
12-29
12-31
13-2
13-2
Connectivity Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-7
13-9
13-3
13-5
13-6
13-13
13-15
13-17
xx
14-3
14-5
14-6
14-6
14-7
Diode Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14-8
Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14-8
14-9
14-11
14-13
15-2
Preventing Crosstalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15-6
15-7
15-10
xxi
15-13
15-13
15-13
15-14
15-17
15-18
Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15-19
15-19
15-20
15-20
15-25
15-26
15-27
15-30
15-31
15-36
15-43
15-22
15-23
15-24
15-24
15-25
xxii
15-53
15-56
15-58
15-60
15-62
15-62
15-64
15-66
16-3
16-4
16-4
16-4
16-7
16-8
xxiii
16-17
16-20
16-26
16-30
16-36
16-37
16-39
Appendix A.
Appendix B.
Scan Chains
xxiv
B-2
B-2
B-5
B-7
B-7
B-7
B-9
B-9
B-10
B-11
B-13
B-14
B-14
B-15
B-15
B-16
B-16
B-16
B-19
B-19
B-19
B-21
B-21
Appendix C.
C-3
C-3
C-6
C-6
C-7
xxv
C-9
C-10
C-11
xxvi
C-8
C-12
C-12
C-13
C-13
C-14
C-16
C-16
C-17
C-17
C-19
C-20
C-21
C-21
C-22
C-23
C-23
C-24
C-25
C-27
C-28
C-30
C-31
C-31
C-33
C-33
C-33
Astro Parameters
D-2
D-5
D-6
D-6
D-8
D-10
D-11
D-11
D-12
D-13
D-13
xxvii
xxviii
ECO weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
legalize placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set OV maximum displacement . . . . . . . . . . . . . . . . . . . . .
D-14
D-15
D-15
D-16
D-17
D-17
D-18
D-19
D-20
D-21
D-21
D-22
D-23
D-24
D-24
D-25
D-25
D-26
D-27
D-28
D-29
D-30
D-30
D-31
D-32
D-32
D-33
D-34
D-34
D-35
D-35
D-36
D-37
D-37
D-38
D-38
D-39
D-39
D-40
D-40
D-41
D-41
D-42
D-42
D-43
D-43
D-44
D-44
D-45
D-46
D-47
D-47
D-48
D-49
D-49
D-50
D-50
D-51
xxix
xxx
D-51
D-52
D-52
D-53
D-54
D-55
D-56
D-56
D-57
D-57
D-58
D-58
D-59
D-59
D-60
D-60
D-61
D-61
D-62
D-63
D-63
D-64
D-64
D-65
D-65
D-66
D-66
D-67
ignore set_clock_uncertainty . . . . . . . . . . . . . . . . . . . . . . .
D-68
D-69
CGHIER_ENABLE_FAST_REPAIR. . . . . . . . . . . . . . . . . . . .
D-70
cg_opt_context_flag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-70
disable_escape_char . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-71
dont_touch_nets_connecting_ls_and_io . . . . . . . . . . . . . . . .
D-72
dont_use_means_dont_touch . . . . . . . . . . . . . . . . . . . . . . . .
D-72
enable_ibt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-72
enable_connection_class. . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-73
max_boolean_syntax_warnings . . . . . . . . . . . . . . . . . . . . . .
D-74
optimize_mix_signal_net . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-74
replace_backslash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-75
save_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-75
Crosstalk Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-76
xtDeltaDelayScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-77
xtDeltaTransScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-77
xtEnableRailToRailDeltaDelay . . . . . . . . . . . . . . . . . . . . . . . .
D-78
xtNoAdaptiveInMediumEffort . . . . . . . . . . . . . . . . . . . . . . . . .
D-79
xtNumOfTopAggr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-79
xtTimingWindowHighEffort. . . . . . . . . . . . . . . . . . . . . . . . . . .
D-80
xtUseAdaptiveDetailWvfmThresh . . . . . . . . . . . . . . . . . . . . .
D-81
xtUseNoiseWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-82
xtXtalkDetailWvfmThreshold . . . . . . . . . . . . . . . . . . . . . . . . .
D-83
D-84
D-87
xxxi
xxxii
avoidCouplingUser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-88
avoidXtalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-89
blncdToSkewCntrlRatio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-89
blockEdgeAccess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-90
brokenNetsThresholdPercent . . . . . . . . . . . . . . . . . . . . . . . .
D-90
clockBalanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-91
clockComb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-92
combDistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-92
combMaxConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-93
compactMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-93
congestionWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-94
densityDriven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-95
detourLimitMinNetLen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-96
extraCostsApplyPercent. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-96
extraWireLengthOpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-97
forceUpperLayersForCritNets . . . . . . . . . . . . . . . . . . . . . . . .
D-97
horReserveTracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-98
ignoreViaBlockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-98
incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-99
macroBndryDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-100
macroBndryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-100
macroBndryTrkUtil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-101
macroBndryWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-102
macroCornerTrkUtil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-102
mapOnly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-103
maxDetourPercent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-103
netCriticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-104
noTopLevelBusFeedThroughs . . . . . . . . . . . . . . . . . . . . . . . .
D-105
paEqPinNetMaxPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-105
powerDriven. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-106
rcOptByLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-106
reportDemandOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-107
reportEffectiveOverflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-107
reportGCellDensity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-108
reportNetOrdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-108
reserveTracksForPowerFile . . . . . . . . . . . . . . . . . . . . . . . . . .
D-109
skewControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-109
skewControlNetBBLowBound . . . . . . . . . . . . . . . . . . . . . . . .
D-110
skewControlWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-111
speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-111
timingDriven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-112
timingWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-113
turboMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-113
VABoundaryToLSWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-114
verReserveTracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-114
xtalkWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-115
D-118
buf_ins_hold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-119
flag_cr_opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-119
hfn_fanout_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-120
hfn_max_fanouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-120
xxxiii
max_iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-121
max_level_buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-121
max_runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-122
max_utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-123
move_flip_flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-123
no_new_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-124
ov_max_displaced_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-124
ov_max_displacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-125
pds_message_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-125
pr_use_fpclass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-126
slack_range_hold_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-126
slack_range_hold_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-127
slack_range_setup_max . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-127
slack_range_setup_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-128
target_hold_slack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-129
target_setup_slack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-129
target_utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-130
topo_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-130
use_child_router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-131
use_global_cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-132
wire_delay_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-133
xtalk_noise_limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-134
xxxiv
allowMovePG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-136
controlparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-136
core2Bottom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-137
core2Left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-138
core2Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-138
core2Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-139
doubleBack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-139
flipfirst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-140
forceTrackAlignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-140
lengthMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-141
macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-141
rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-142
rowDirction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-143
rowRatio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-143
rpinECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-144
startfirst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-144
stdcells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-145
utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-145
D-149
ata_crp_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-150
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-150
ata_crpr_threshold_ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-150
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-151
capture_path_propagate_worst_slew . . . . . . . . . . . . . . . . . .
D-151
case_analysis_disable_entire_path . . . . . . . . . . . . . . . . . . . .
D-152
case_analysis_sequential_propagation . . . . . . . . . . . . . . . . . D-153
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-154
clock_cell_has_multiple_edge . . . . . . . . . . . . . . . . . . . . . . . .
D-154
xxxv
clock_gating_propagate_enable . . . . . . . . . . . . . . . . . . . . . . D-154
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-155
clock_tree_report_debug_mode . . . . . . . . . . . . . . . . . . . . . .
D-155
disable_cond_default_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . D-156
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-156
driving_cell_include_cell_delay . . . . . . . . . . . . . . . . . . . . . . .
D-156
early_launch_at_borrowing_latches . . . . . . . . . . . . . . . . . . . D-157
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-158
group_path_opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-159
max_RG_size_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-159
multicycle_hold_follow_setup. . . . . . . . . . . . . . . . . . . . . . . . .
D-160
non_unate_clock_compatibility . . . . . . . . . . . . . . . . . . . . . . . D-161
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-161
print_Clock_Timing_For_Mixed_Edges . . . . . . . . . . . . . . . . .
D-162
pulse_latch_as_ICG_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-162
rc_degrade_min_slew_when_rd_less_than_rnet . . . . . . . . . D-163
Equivalent PrimeTime Parameter. . . . . . . . . . . . . . . . . . . . D-163
remove_Escape_From_Bus. . . . . . . . . . . . . . . . . . . . . . . . . .
D-164
report_timing_through_sync_pin . . . . . . . . . . . . . . . . . . . . . .
D-164
rpt_max_cap_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-165
rpt_max_tran_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-165
rpt_min_cap_multiplier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-166
rpt_min_tran_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-167
splitEK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-167
Glossary
Index
xxxvi
Preface
FIX ME!
Customer Support
xxxvii
Preface
xxxviii
Audience
This user guide is for design engineers who use Astro to implement
designs. To use Astro,
Related Publications
For additional information about Astro, see
You might also want to refer to the documentation for Milkyway and
the following related Synopsys products:
Library Compiler
Design Compiler
IC Compiler
Physical Compiler
PrimeTime
Star-RCXT
JupiterXT
See also Physical Implementation Online Help and the Astro User
Guide: Advanced Topics.
Preface
xl
Conventions
The following conventions are used in Synopsys documentation.
Convention
Description
Courier
Courier italic
Courier bold
[]
Control-c
Customer Support
Customer support is available through SolvNet online customer
support and through contacting the Synopsys Technical Support
Center.
Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles
and answers to frequently asked questions about Synopsys tools.
SolvNet also gives you access to a wide range of Synopsys online
services including software downloads, documentation on the Web,
and Enter a Call With the Support Center.
To access SolvNet,
1. Go to the SolvNet Web page at http://solvnet.synopsys.com.
2. If prompted, enter your user name and password. (If you do not
have a Synopsys user name and password, follow the
instructions to register with SolvNet.)
If you need help using SolvNet, click HELP in the top-right menu bar
or in the footer.
Preface
xlii
Open a call to your local support center from the Web by going to
http://solvnet.synopsys.com (Synopsys user name and
password required), then clicking Enter a Call With the Support
Center.
Customer Support
xliii
Preface
xliv
1
Introduction to Astro
Astro Packages
1-1
Supported Platforms
Astro Packages
Synopsys provides a spectrum of Astro product packages, which
vary in complexity with the features offered. Each package in this
hierarchy (Figure 1-1) is a superset of the previous package, except
for Astro Multiroute, which can be added to any configuration.
Figure 1-1
Astro-Rail
Astro
Multiroute
Astro-Xtalkcapabilities include
- Crosstalk analysis and optimization
- Static noise (glitch) analysis and optimization
- Signal electromigration analysis
Astro-Railcapabilities include
- Power analysis
- Rail analysis
Astro Packages
1-5
Supported Platforms
Astro software runs on various UNIX platforms. For detailed
information about supported platforms, see the Supported Platforms
Guide at
http://www.synopsys.com/products/sw_platform.html
Table 1-1
Task
Floorplanning
Routing
Postrouting optimization
Table 1-1
Task
Verification and
back-annotation
Other
Tcl online Help and man pages describe the Astro Tcl commands
(see Finding Commands in Tcl Mode on page 2-15)
Astro-Rail
Astro-Rail is designed to be integrated with Astroyou can access
its features from the Power menu and you can make settings in the
Place Common Options dialog box (astPlaceOptions) when you
have the power performance license. Alternately, you can use
Astro-Rail as a stand-alone product, which requires its own license
package.
Astro-Rail provides the following capabilities:
PrimeRail
PrimeRail is built on the Synopsys sign-off technologies, including
the Star-RCXT, HSPICE, NanoSim and PrimeTime tools. It offers
gate-level and transistor-level static and dynamic voltage drop and
electromigration analysis with on-chip decoupling capacitance and
full-chip sign-off with package parasitics. The integration of
PrimeRail with the Galaxy design platform helps you achieve fast
design convergence and provides a predictable path to sign-off.
PrimeRail requires its own licensing package. PrimeRail is a
stand-alone product and is not accessible in Astro.
PrimeRail provides the following capabilities:
Design Flow
You can use Astro-Rail or PrimeRail at different points in the design
flow, after global routing is performed. When global routing is
completed, you can use Astro-Rail or PrimeRail to calculate total
power consumption and to check for voltage drop and
electromigration violations on a circuit. This capability enables you to
detect potential violations before you perform detailed placement
and routing and, therefore, significantly reduces turnaround time
later in the design cycle.
After the detailed routing is complete, use Astro-Rail or PrimeRail to
verify the reliability of your design for sign-off.
Figure 1-2 shows when to use Astro-Rail or PrimeRail in the design
flow.
Figure 1-2
LM view
Milkyway
database
Floorplanning
Placement
Global routing
Conversion
reliability
analysis
Milkyway
database
LM view
Detailed routing
reliability
analysis
2
Using the Astro GUI and Command Files 2
The Astro graphical user interface (GUI) lets you run Scheme and
Tcl commands as well as view and analyze your design by using a
series of windows. You can also create and replay Scheme and Tcl
command files.
This chapter contains the following sections:
User Interfaces
Getting Help
2-1
User Interfaces
The Astro GUI includes a command window as well as graphical
layout windows that provide views of a cell (a representation of a
design).
When you start an Astro session, the Astro command window that
appears provides menu commands and a command-line interface
(Scheme shell or Tcl shell). Every menu command has an underlying
Scheme or Tcl function. When you select a command from the
menu, the command either runs immediately or displays a dialog
box.
When you open a cell (you must first open the library containing the
cell), the tool creates and opens a graphical layout window
containing the cell. The graphical layout window provides a view of
the cell and several tools and commands for easy access and use.
You can open multiple graphical layout windows, each containing a
different cell or different views of the same cell.
User Interfaces
2-3
Figure 2-1
Prompt area
Title bar
Command window
Figure 2-2
Prompt area
Title bar
Command window
Note:
When you run Astro in Scheme mode, the command log file
starts with ;# Scheme. When you run Astro in Tcl mode, the
command log file starts with ;#Tcl. This allows you to write a
smart load command where you identify the file type (Scheme
or Tcl) and use one command to process either Scheme or Tcl
files.
The Astro window contains the areas described in Table 2-1.
Table 2-1
Area
Description
Title bar
Menu bar
Prompt area
Command
window
Command History
or Tcl History
You can change the scripting or tool language setting while you are
in an Astro session.
-nullDisplay
display to an Null X Server
-nogui
do not show gui windows and use text-shell initially
-msmc
enable distributed Multiple Scenario (msmc) commands
-caseSensitive
set process in case sensitive mode
-trueColor
select visual type
-version
display version information
-release <key...>
release license keys
-buffer
use double buffering
-astroiu
astro iu licensing
-freeAllOptionKeys release all optional license keys
-galaxy
set Galaxy mode
-x <command>
Execute a Tcl command after setup
-no_init
don't load user Tcl initialization files (optional)
-environ <var=value,var2=value2,etc> specify shell variable environment
settings (optional)
-help
display this information
The -buffer option affects the way objects are drawn in the overlay
planeit provides a smooth object-dragging appearance. In
buffering mode, the wire is drawn in an internal pixmap and then
copied to the window; in no buffering mode, the wire is drawn directly
to the window.
Figure 2-4
Choose Tools > Data Prep to replace the Astro menus with the Data
Prep menus. The menu bar changes, as shown in Figure 2-5.
Figure 2-5
To change back to the Astro menus, choose Tools > Astro. The menu
bar changes, as shown in Figure 2-6.
Figure 2-6
Astro Menus
Detaching Menus
You can detach a menu so you can access frequently used
commands by clicking the dashed line, as shown in Figure 2-3.
Figure 2-7 shows the detached Library menu.
Figure 2-7
All detached menus are closed when you change to a different tool,
for example, by choosing Tools > Astro when you are using the Data
Prep menus.
Types of Commands
The physical implementation commands come in several types:
This lists all commands that contain the character string, regardless
of case or location in the command name.
Within the string, you can use the special characters listed in
Table 2-2 to be more specific about the command name.
Table 2-2
Character
Representation
[]
You can use the Tab key for command name completion. For
example, if you enter the following command and then press the Tab
key:
atTim
help
help
help
help
help
help
milkyway
cts
router
timing
core_selection
get*
Figure 2-8
For more information about using Tcl, see Using Tcl in the Milkyway
Environment in Physical Implementation Online Help and the Using
Tcl With Synopsys Tools manual.
To list all Astro commands and the license required, in the command
window enter
getFunctionLicensing
To leave the GUI and return to running Astro without the GUI, at the
system prompt enter
% stop_gui
Getting Help
Astro provides a comprehensive online documentation system, as
well as an online command help facility, and provides man pages for
selected Tcl commands.
Getting Help
2-17
The syntax is
setHelpBroswer "browser_name"
2. In the toolbar, you can click Back and Forward to see Help topics
in your browsing history.
Getting Help
2-19
Use the help command and specify the command name or enter
the specific command with the -help option
Both approaches are shown in Figure 2-9.
Figure 2-9
Getting Help
2-21
2. If you want to look at the cell but not edit it, select read only.
This ensures that Astro does not save the cell.
3. Specify a cell name. Do one of the following:
- Next to Cell Name, enter the cell name.
The cell name is the name of the cell you want to open. Enter
top to open a layout cell in the sample library.
- Click Browse to browse the cells in the current library.
The Browse Cell dialog box appears.
- Next to List:, select all versions to show all version of all cells
in the selected library, as shown in the next figure.
Creating Cells
To create a new cell,
1. Enter geCreateCell, create_design, or choose Cell >
Create.
The Create Cell dialog box appears.
2. Next to Cell Name, enter the name you want to assign to the new
cell.
If you enter the name of an existing cell, the tool will increment
the current version number of the existing cell for the new cell.
3. Click OK.
The tool creates an empty cell in the open library.
Navigation Buttons
Use the buttons at the left of the graphical layout window to navigate
around the design, as described in Table 2-3. If you hold the pointer
over a button, a Tool Tip appears that tells you what the button does.
Table 2-3
Navigation Buttons
Button
Views > Up
Redraw
Scroll up
Fit cell
Zoom out 4X
Scroll left
Table 2-3
Button
Move center to
Scroll right
Zoom out 2X
Pan to
Scroll down
Zoom in 2X
Table 2-3
Button
None
None
Previous view
Next view
Zoom to area
Additional
commands
Table 2-4
Button name
Window option
Layer panel
Query-object
Query-net
Select-point
Select-line
Select-window
Deselect-point
Deselect-all
Ruler
The graphical layout window on which you want the side button
to appear. A value of 0 applies the button to all open windows.
Position
The button position on the side bar. Valid values are 110.
Name
Command
0
0
0
0
0
0
0
0
0
0
To see how the context view works, use commands from the Views
menu to pan and zoom the current window.
Load files, which are created by the user and generally contain
db functions that provide information needed by the tool.
When you replay or load a command file, the tool reads the file and
executes the commands and functions it contains.
Replay Files
Each time you run Astro, Astro automatically generates a command
file called a replay file, which contains all the commands executed
during a session. You can replay a replay file by opening the tool with
the -replay startup option. Use the following syntax at the system
prompt:
ToolName -replay fileName
where ToolName is the name of the tool you want to start, such as
Astro, and fileName is the name of the replay file.
For Tcl, use
ToolName -file fileName
Caution!
Replay files should not contain replay functions. The behavior of
the replay file when executing a replay function is unpredictable.
In Tcl mode, there is no distinction. Your Tcl file can contain other
Tcl files.
Loading files by using the -load startup option is nearly identical
to replaying files, except that they usually do not flush graphic
operations as often as replay. This means that some GUI display
operations might be skipped; that is, you might see fewer window
or drawing operations with -load.
Startup Files
A startup file is a special type of replay file used to set up your
environment. This startup file is .avntrc in Scheme mode and
.synopsys_astro.tcl in Tcl mode. Use the startup files to set the
environment for Astro in general or for a particular library.
You can create a startup file manually by using a UNIX text editor.
You can also create a startup file by running the tool and editing the
automatically generated replay file. For example, you might create a
startup file to automatically open the library you typically use when
you start the tool or to automatically open the top-level cell when you
open a particular library.
Load Files
Throughout the design flow, you can provide information to the tool
by using load files. These files generally contain db functions. For
example, a port information file that contains
dbSetCellPortTypes functions is a load file.
To load a load file, use the following syntax in the command window:
load fileName
Script Files
A script file is a combination of Scheme or a combination of Tcl
functions and command syntax in a text file, which you can use to
accomplish a series of tasks in sequence.
You execute scripts in Astro by using the load_scheme command
or the source command. Enter these commands in the command
window.
2. In the Save Cells dialog box, select the cells you want to save
from the list of cells, click Save All, or Click Discard All.
3. Click OK.
You can also use the geNameSelect command to select cells to
be saved. In the Name Select dialog box, enter the cell names or
use pattern matching to select all cells with names that match a
pattern and click select. For example, enter .*CEL to select all
cells with names that end with CEL.
4. Enter geConfirmCloseLib or choose Library > Close, and
click OK to confirm that you want to close the library.
5. Enter menuQuit or choose Tools > Quit.
Astro terminates the session and closes any open windows.
7
(up/left)
8
(up)
9
(up/right)
4
(left)
6
(right)
1
(down/left)
2
(down)
3
(down/right)
Starting point
End point
First stroke
segment
Second stroke
segment
When you use this strokeby left-clicking the mouse and dragging
it down and then to the rightthe AstroPlace Options dialog box
opens.
To undefine a stroke, use the undefineStroke command. The
syntax is
undefineStroke "strokeSequence"
3
Creating Milkyway Reference Libraries
When using Astro, you need to create and use Milkyway reference
libraries of standard cells, macro cells, and pad cells.
This chapter includes the following sections:
3-1
Technology Files
A technology file defines the characteristics of a Milkyway library, for
example, units of measure, graphical specifications, layer and device
definitions, and design rules.
GDSII Files
GDSII is a standard format for physical layout information. This file is
used to transport physical layout designs between different design
environments.
Netlist Files
Verilog, VHDL, and EDIF are standard formats for describing logical
designs. Using Milkyway, you can easily translate data in these
formats to tool cell format, or you can write tool data to these
standard formats.
File content
Design .sdf
Post-floorplanning timing
Parasitic information
Optimized netlist
After you create a design library and complete the physical design in
Astro, the design library can become a reference library for another
design in a hierarchical design environment.
Figure 3-1 shows the structure of a Milkyway library directory.
Figure 3-1
lib
CEL
EXP
FRAM
LM
LOGIC
NETL
PARA
PWR
TIM
Directory/View
File
Data
View
Content
Geometry
and
physical
data
CEL view
FRAM view
SMASH view
HTV view
LM view
PWR view
TIM view
LOGIC view
Timing,
power, and
logic
Netlist
Table 3-2
Data
Other
Content
NETL view
EXP view
HNET view
PARA view
CONN view
ERR view
FILL view
GAP view
NOTC view
ROUTE view
Figure 3-2
Technology file
GDSII stream file
Prepare
Physical
Data
Create LM view
gePrepLibs
Prepare
Logical
Data
Prepare
Physical
Data
When you select one of the options, the dialog box expands to
show the physical library preparation options, as shown in the
following figure. The options are listed in the order you typically
use them when creating the library, the first step being to create
the library.
You can click Check Library to check for any problems in the
library at any step in the flow.
6. Complete the physical library preparation steps indicated in the
standard cell library creation flow in Figure 3-2 on page 3-10.
7. After you complete the physical library preparation steps, click
Prepare Logical Library to display the library logical preparation
options.
8. Click LIB/DB for Logical Input Format. This displays the Library
Preparation dialog box, shown on page 3-22.
9. After you prepare the logical data, click Prepare Logical Library,
and click Check Library to check for any problems in the library.
This creates CEL views for all the cells in the GDSII file.
The complete physical descriptions from the GDSII file are stored
in the CEL views. Although this is more data than is required by
Astro for place and route, the data is retained to ensure that all
the design data is included when you write files from Astro.
5. Identify power and ground ports. Use dbSetCellPortTypes.
For example, create a text file named pg_only.porttypes with the
following:
dbSetCellPortTypes "cb_mini_a" "*" '(
("VDD" "Power" )
("VSS" "Ground" )
) #f
This creates the FRAM views, which are abstractions of the CEL
views for place and route.
8. Set the place and route boundary. Enter auSetPRBdry or
choose Cell Library > Set PR Boundary to display the Set PR
Boundary dialog box.
If you have one or more Synopsys .db files with PVT data for
analysis, click Import Logic Model DB, then click Select DB to
display the Import Logic Model DB options.
Enter a .db file name in the appropriate Min DB File, Max DB File,
Typical DB File, or Other DB File fields, which represent various
process corners for analyzing process, temperature, and voltage.
If you have multiple .db files for one process corner, enter the file
names in the field, separated by a space.
This creates LM views for storing the PVT information.
For information about the other options for importing PVT data,
see Creating LM Views for Timing and Power Analysis on
page 3-29 and the gePrepLib command in Physical
Implementation Online Help.
11. Load logical equivalent cell information. Enter astExtrLEQ or
choose CLF > Extract LEQ.
See Creating Logical Equivalent Cell Information on page 3-35.
12. Load supplemental CLF data. Enter auLoadCLF or choose CLF
> Load.
See Loading Pad Orientation, Diode Protections, and Gate Size
Data on page 3-40.
Technology file
Create library
cmCreateLib
Smash cells
cmSmash
Prepare
Physical
Data
Create LM view
gePrepLibs
Prepare
Logical
Data
Prepare
Physical
Data
As shown in Figure 3-3, the macro cell library creation flow includes
several tasks. You can use the read_lib command to select the
various library preparation commands, as described in Creating the
Library With the read_lib Command on page 3-11. Or you can run
the individual library preparation commands separately, as
described in the following steps:
1. Display the Milkyway Data Prep menus. Choose Tools > Data
Prep or start the Milkyway executable file.
2. Create the library. Enter cmCreateLib or choose Library >
Create to display the Create Library dialog box.
This creates CEL views for all the cells in the GDSII file. The
complete physical descriptions from the GDSII file are stored in
the CEL views.
5. Identify power and ground ports. Use dbSetCellPortTypes.
For example,
dbSetCellPortTypes "nand_macro" '(
("VDD" "Power" )
("VSS" "Ground" )
) #f
e. Click Extract Pin by Text and enable Identify Macro Pin By Pin
Text.
This creates a FRAM view that is blocked in all metal layers,
except the area that is cut out for accessing pins.
Note:
If a place and route boundary is not defined in the GDSII
description, Astro uses the cell boundary to represent the
macro size and dimension.
f. Close the nand_macro cell and the nand_macro_lib library.
7. (Optional) For top-level rail analysis with Astro-Rail, you need to
create a CONN view.
8. You can import the logical timing process, temperature, and
voltage (PVT) information by entering gePrepLibs or choosing
Cell Library > Library Preparation, as described in step 10 in
Creating the Library With the Individual Commands on
page 3-15.
This creates LM views for storing the PVT information.
9. Load supplemental CLF data. Use auLoadCLF or choose CLF >
Load.
See Loading Pad Orientation, Diode Protections, and Gate Size
Data on page 3-40.
Note:
The TIM and PWR views, which provide almost the same
information as the LM view, are being replaced by the LM view.
The LM view has full backward compatibility with both the TIM
and PWR views. When TIM and PWR views exist, as well as an
LM view, the LM view has a higher priority.
The gePrepLibs command can handle all combinations of
minimum, typical, and maximum operating conditions. The LM view
might have multiple databases for each of these operating
conditions. When you run the gePrepLibs command, it creates the
LM view and does the following:
When you generate an LM file from a .lib file, Astro uses the Library
Compiler tool to convert the .lib format to .db format. You must have
lc_shell in your path before you start Astro.
Note:
For more information about the gePrepLibs command and
options, see Physical Implementation online Help. Also see
Chapter 6, LM View and Delay Calculation in the Astro User
Guide: Advanced Topics.
To generate an LM view for a .lib file,
1. Enter gePrepLibs or choose Tools > Data Prep > Cell Library >
Library Preparation.
2. Click Import Logic Model DB to display the Import Logic Model
DB options.
3. Click From .lib to display the options. The following figure shows
the Library Preparation dialog box with the import .lib options
displayed.
Alternatively, it might be easier for you to use the compiled .db file
directly. In this process, gePrepLibs does not regenerate the .db
fileit needs to establish the Milkyway category file only. This is
faster than generating the LM view from the .lib file, because there is
no need to invoke Library Compiler to convert the .lib format to .db
format. For detailed information about converting .lib format to .db
format, see the Library Compiler documentation.
To generate an LM view from a .db file,
1. Enter gePrepLibs or choose Tools > Data Prep > Cell Library >
Library Preparation.
2. Click Import Logic Model DB to display the Import Logic Model
DB options.
3. Click Select DB to display the options. The following figure shows
the Library Preparation dialog box with the import .db options
displayed.
cell5 cell6
cell7 cell8
The file is stored in the top-level design CEL view, and the design
LEQ cells are stored in the design library.
To use this command, you must have the library and cell open, and
the cell must be ready for timing analysis. Sample output follows:
** class 151 ***
cell=dl04d4 type=BUFFER "volt_gr=0"
Z = I
cell=bufbd1 type=BUFFER "clock_cell" "volt_gr=0"
Z = I
cell=dl04d1 type=BUFFER "delay_cell" "volt_gr=0"
definePad
defineDiodeProtection
defineGateSize
3. Click OK.
Note:
You can also load a supplemental CLF file created during LEF-in
with the auLoadCLF command.
4
Creating a Design Library and Adding Data4
A design library is a design-level cell of a block or chip that is
implemented in Astro. You need to create a design library and add
other data to implement a design with Astro.
This chapter contains the following sections:
4-1
2. Enter auVerilogToCell.
The Verilog To Cell dialog box appears.
Chapter 4: Creating a Design Library and Adding Data
4-2
*****
Start PASS 1 *****
(Please check the file for mapping Verilog to GDS cell)
** Cannot open map file. **
***** PASS 1 Complete *****
Elapsed =
0:00:01, CPU =
*****
0:00:00
*****
Start PASS 2 *****
(Please check the file for mapping Verilog to GDS cell)
** Cannot open map file. **
Module inv0d0 was referenced in creating instance before definition.
Create hccell inv0d0 according to FRAM view.
Module nd02d0 was referenced in creating instance before definition.
Create hccell nd02d0 according to FRAM view.
Module oaim21d1 was referenced in creating instance before definition.
Create hccell oaim21d1 according to FRAM view.
...
Module bufbd7 was referenced in creating instance before definition.
Create hccell bufbd7 according to FRAM view.
*****
*****
Verilog HDL translation completed! *****
Elapsed =
0:00:02, CPU =
0:00:00
Verilog conversion completed.
Peak Memory Usage = 52 M,
Top Module Name
(super_watch).
Remember to set the correct bus style for the library. If the bus
style is incorrect, Astro issues a warning when generating
hierarchical Verilog.
Save the cell prior to inserting the clock tree. That way you can
use the saved cell instead of using astDeleteClockTree to
remove the clock tree in case of problems. Deleting clock trees
sometimes causes problems.
2. Create a cell by
- Creating a cell view (CEL view) and binding a netlist view (EXP
view). Use geCreateCell and axgBindNetlist or
auVerilogToCell.
- Adding cells not in the netlist, such as power and ground pads.
- Setting power and ground ports. Use aprPGConnect.
3. Initialize hierarchy preservation information. Use
astInitHierPreservation or auVerilogToCell.
See Initializing Hierarchy Preservation on page 4-16.
4. Mark the module instances in the design you want preserved.
Use astMarkHierAsPreserved.
See Marking Module Instances As Preserved on page 4-18.
5. Add cells not in the netlist, such as VDD/VSS pads.
6. Set power and ground ports. Use aprPGConnect.
7. Initialize timing information by loading timing constraints, using
SDC. At this point, the cell is ready for Astro optimization.
See Loading Timing Constraints on page 6-6.
8. Place and route the cell. Run the following
- Floorplanning
- Preplacement and in-placement optimizations
- Clock tree synthesis and clock tree optimization
- Postrouting and routing optimizations
9. Delete hiconn nets (nets that connect a module port and ports
outside of the module). Use astRepairHierPreservation.
See Repairing Hierarchy Preservation and Deleting Hiconn
Nets on page 4-23.
10. Generate a hierarchical Verilog netlist by using the
astDumpHierVerilog command.
See Generating Hierarchical Verilog on page 4-19.
11. Check the hierarchy preservation consistency. Use
astCheckHierPresConsistency.
See Checking Hierarchy Preservation Consistency on
page 4-28.
For information about preserving hierarchy for ECOs, see
Engineering Change Order Methods on page 12-22.
- No power/ground ports
Prevents power or ground ports from being generated for all
the cell instances, module instances, and module definitions,
including the topmost module. For each power or ground net in
a module, a power or ground port is generated for the module
instances and module definition. If such nets exist in the
original netlist, no new port is generated. However, these ports
from the original netlist can never be ignored and are always
generated, regardless of this switch.
- No power/ground nets
Prevents power and ground nets from being declared as
supply1 and supply0 nets in all the module definitions.
Any netlist update done outside the common graph code, either
by use of ECO commands or by direct use of database
commands. For hierarchical ECO, see the Milkyway
implementation commands auHierECO and auHECOByFile.
Hier
Hier
Hier
Hier
Hier
Cell
Port
Cell
Nets
Port
Masters *
Inst Masters *
Insts *
*
Insts *
Note:
Be aware that astDumpHierPreservation writes all
hierarchy preservation information to the log file; this output can
be quite large for some designs.
2. Next to TDF File Name, enter the name of the TDF file containing
the power supply information.
3. Click OK or Apply.
Here is a sample TDF file:
tdfSetPowerSupply "VDD" 1.08 1.2 1.32
5
Floorplanning and Connecting Power and
Ground
5
After you create the design library, you need to define the power and
ground connections, use floorplanning to create the boundary and
core area, and create the power and ground rings and straps.
This chapter contains the following sections:
Floorplanning
5-1
8. Click OK.
This connects all VDD ports to the VDD net.
9. In the Connect/Disconnect PG dialog box, now specify
- Net Name: VSS
- Port Pattern: VSS
- Net Type: Ground
- Update Tie Up/Down: Enabled
Note:
You need to enable this option the last time you execute this
command to apply the tie-up and tie-down port information
for the entire cell. In a Verilog file, these are 1b1 and 1b0.
- Model: Connect
Floorplanning
It is recommended that you use JupiterXT for floorplanning. For
details about floorplanning with JupiterXT, see the JupiterXT Virtual
Flat Flow User Guide.
You can also use Physical Compiler for floorplanning and creating a
floorplan file, as described in Defining Multiple Tiles for Placement
on page 3-42.
Floorplanning
5-5
In Astro, you can create a simple floorplan that determines the size
of the design cell, creates the boundary and core area, and creates
wire tracks for placement of standard cells.
To create a floorplan in Astro,
1. With the design library and top design cell open in Astro, enter
axgPlanner or choose Design Setup > Floorplan Set Up
Floorplan.
The Floor Planner dialog box appears.
Floorplanning
5-7
The wire tracks are not visible in the cell view. To see the text format
that includes the wire tracks, enter axgDumpFloorPlan or choose
Design Setup > Floorplan Dump Floorplan.
Following is a partial example of the wire tracks information:
;******************
;* Tracks
*
;******************/
define _cell (geGetEditCell)
axPurgeSingleRecordType _cell "track"
axPurgeSingleRecordType _cell "wire dir"
axCreateWireDirRecord _cell 16 #t
axCreateWireDirRecord _cell 18 #f
axCreateWireDirRecord _cell 28 #t
Floorplanning
5-9
axCreateWireDirRecord _cell 31 #f
axCreateWireDirRecord _cell 3 #t
axCreateWireDirRecord _cell 45 #f
axCreateTrackRecord _cell 16 #t 0.56
0.5600) '(280.5600 279.4400)
axCreateTrackRecord _cell 18 #t 0.56
0.5600) '(280.5600 279.4400)
axCreateTrackRecord _cell 18 #f 0.28
0.0000) '(280.2800 280.0000)
axCreateTrackRecord _cell 16 #f 0.28
0.0000) '(280.2800 280.0000)
...
axCreateTrackRecord _cell 31 #t 0.58 0.61
0.5800) '(280.5600 279.3500)
axCreateTrackRecord _cell 45 #t 0.58 0.61
0.5800) '(280.5600 279.3500)
axCreateTrackRecord _cell 45 #f 0.98 0.95
0.0000) '(279.3300 280.0000)
axCreateTrackRecord _cell 3 #f 0.98 0.95 294
'(279.3300 280.0000)
458 '(0.0000
458 '(0.0000
294 '(0.9800
'(0.9800 0.0000)
- R-Width: 5
- B-Width: 5
- T-Width: 5
- L-Layer: 45
- R-Layer: 45
- B-Layer: 3
- T-Layer: 3
- Offsets: Absolute
- Left, Right, Bottom, Top: 1
- Extend: Enable all options, which makes it easy to run
Astro-Rail
3. Click OK.
Looking at the cell layout, you will see the power and ground rings
around the core.
6
Setting Up the Design Timing
Before you can run Astro on your design, you need to set up the
design timing and prepare other data. Astro provides several
commands you can use for checking design data at various points in
the design flow.
This chapter contains the following sections:
Unit Consistency
6-1
Figure 6-1
Contains expanded
netlist bound to cell
Set up timing
Timing > AstroTime Timing Setup
(atTimingSetup)
Set astCells
astSetClockCell, astSetDelayCell,
astSetDontUse
Check timing
Timing >Timing Data Check (astTimingDataCheck)
Check design
astCheckDesign
Design feasibility
2. Next to SDC File Name, enter the name of the SDC file to be
loaded.
3. Set the options or keep defaults.
For descriptions of the ataLoadSDC command options, see
Physical Implementation Online Help.
4. Click OK.
Note:
Astro cannot load an SDC file that uses the [%d] bus naming
style when the library has the bus naming style set to <%d>. To
solve this problem, use the following syntax in your Scheme
script:
sdc "set enable_bus_name_mapping 1"
Note:
The tcl "sdcCommandSyntax" syntax is obsolete. Use sdc
"sdcCommandSyntax" instead. Scripts using tcl
"sdcCommandSyntax" still work, but Astro issues a warning
message.
-min
-min
-max
-max
-rise
-fall
-rise
-fall
2.33 { {clk} }
2.33 { {clk} }
5.9 { {clk} }
5.9 { {clk} }
# clock uncertainty
set_clock_uncertainty -setup 0.15 {clk}
set_clock_uncertainty -hold 0.15 {clk}
# clock transition
set_clock_transition
set_clock_transition
set_clock_transition
set_clock_transition
-min
-min
-max
-max
-rise
-fall
-rise
-fall
0.1
0.1
0.1
0.1
{
{
{
{
{clk}
{clk}
{clk}
{clk}
}
}
}
}
Note:
In the initial release of Astro, the ataWriteTC command wrote
ata commands. Now these ata commands are obsolete. When
you write constraints from a design started in the initial release
version of Astro, you should see messages such as the following,
showing conversion to SDC:
SDC:
SDC:
SDC:
SDC:
For major changes to the SDC file or to reload the original SDC file
with some modifications, first use ataRemoveTC and then use
ataLoadSDC to load the SDC file. The ataRemoveTC command
completely removes the existing SDC constraints prior to loading the
new SDC file.
Be aware that loading a new SDC does not necessarily overwrite the
existing constraint. If you want to change an existing constraint,
either follow the procedure for major changes (listed in the preceding
paragraph) or use the appropriate SDC syntax to remove the
constraint (usually syntax that begins with remove_) and then load
the new constraint. Remove unwanted constraints because Astro
observes the most limiting constraint when multiple constraints exist
for the same object.
Note:
You cannot remove partial path exceptions from your constraints
by using SDC syntax such as remove_path_exception. The
Astro remove command removes all of them. Instead, save the
SDC, modify it, remove the old SDC information by using
ataRemoveTC, and then load the modified SDC.
If you must go back to a previous version of Astro and the tool reports
a corrupted or invalid SDC file attached to the design, do the
following: In the older version of Astro, use ataRemoveTC to remove
all constraints and then use ataLoadSDC to reload the SDC file. The
following sample log file reports incompatibility when a design was
opened in a previous version of Astro:
SDC information is not backward compatible
SDC stored is version X, while this executable can only read
up to Y.
Reload the SDC files.
Failed to read sdc data
astSetClockCell
astSetDelayCell
astSetDontUse
astSetDontTouch
astSetSizeOnly
astSetLevelShifter
Note:
Use astRemoveDC to remove all design constraints, such as the
astSetClockCell, astSetDelayCell, astSetDontTouch,
astSetDontUse, astSetLevelShifter, and
astSetPreserveLogic commands.
Example 6-4 Sample File With Internal Constraints
I io_if/io_decode2/inv0d0_Q5266 (inv0d0) NotBypass
N io_if/io_decode0/G4819 NotBreak NotBypass
N io_if/O1956 NotDelete
Unit Consistency
Design units (resistance, capacitance, timing, voltage, power, and so
forth) come from technology information in design libraries. When
units that differ from those in the design library are used in defining
the constraints in the SDC file, the constraints interpretation can be
affected by the mismatched units, producing unexpected results.
Chapter 6: Setting Up the Design Timing
6-16
Unit Consistency
6-17
:
:
:
:
:
:
pF
kOhm
ns
V
mA
mW
Model Sets the cell delay model information and the net delay
model to be run for timing.
See Model Page on page 6-42.
The settings on these tabs are saved (except for the Ignore
Interconnect option on the Environment page) when the cell is
saved. You can use the AstroTime Timing Setup dialog box or the
astCheckDesign command to see the current settings stored in
the cell.
Note:
Equivalent ata commands are referenced in the following
descriptions, when available.
Environment Page
Use the Environment page to easily access the parameters that
affect timing analysis and optimization. You can use the default
settings, which provide the most-typical selections needed for
optimization, or change the settings to meet your objectives.
You might need to change some default settings to achieve
correlation with the Synopsys timing analyzer tool, PrimeTime. In
some cases, the defaults for Astro and PrimeTime might differ (for
example, some default settings in PrimeTime are not good for
optimizing the netlist). Also, the Astro default settings override the
Disable this option after clock tree synthesis, when you want to
propagate clocks to get timing information about the clock
paths.
Note:
If set_propagated_clock SDC commands are not
specified, deselecting the option will have no effect (the ideal
clock values will be used).
There is no equivalent ata command. You can use the following
syntax to specify an argument (1 to activate, 0 to disable):
atCmdSetField "Ignore Propagated Clock" "1" or "0"
- Set IO Clock Latency Computes, for every I/O port, the clock
latency to that port that provides the minimal clock skew on the
I/O port. For example, when the input --> three fanouts, Astro
checks the clock arrival time at all the fanouts and selects the
minimum value. (Astro selects the maximum for output ports.)
The default is off.
There is no equivalent ata command. You can use the following
syntax to specify an argument (1 to activate, 0 to disable):
atCmdSetField "Set IO Clock Latency" "1" or "0"
In Astro you get the same answer for either syntax. For a boundary
constraint such as the following:
set_input_delay 1 -clock [get_clocks {clk}] -add_delay
[get_ports {lap}]
You get 0.9 ns in the network delay field of the timing report, if youre
using ataEnableIdealNetworkDelay, as shown below.
Clock Network delay
0.9000
20.9000
0.0000
20.0000
Set this switch to control how the circuit is timed. You can also control
this switch by selecting or deselecting Enable Ideal Network Delay in
the Environment page of the AstroTime Timing Setup dialog box. In
PrimeTime, you control it with the clock latency command, by using
the get_clock or get_port command syntax.
In other words, the network delay for the launching flip-flop and the
capturing flip-flop is accounted for, except at the boundaries, where
the set_output_delay boundary constraint usually does not
account for the network delay of the imaginary capturing flip-flop
outside of the block. This is a way to add or not add the network delay
back for the imaginary capturing flip-flop on the other side of the
input or output pin.
Optimization Page
Use the Optimization page to control certain aspects of optimization.
For example, you can optimize parameters or set certain targets and
thresholds. In addition, you can use this page to control the use of
logic equivalency for cells and to set placement legalizer options.
The Optimization page does not have direct equivalent commands
for setting options like the ata commands associated with the
Environment page. Instead, you can use a command file to specify
Optimization page options, as shown in Example 6-5.
Library Page
Use the Library page to set the runtime process, voltage, and
temperature (PVT) values under which timing analysis and
optimization are run. For multi-VDD designs, you can specify the use
of multiple nonlinear delay model (NLDM) libraries with the same cell
name.
To select library options that affect timing and optimization,
1. Open the AstroTime Timing Setup dialog box (atTimingSetup)
and click the Library tab.
The Library page appears.
Parasitics Page
Use the Parasitics page to select options, such as the parasitic
source, the layout parasitic extraction mode, and the capacitance
model for timing.
Astro uses a congestion-based coupling model and TLU or TLUPlus
capacitance tables to accurately model the prerouting capacitance
for nets. This methodology eliminates the questionable derivation of
the linear capacitance coefficient and improves the accuracy of the
model by considering increased coupling due to increased
congestion in different regions of the chip or block.
TLU or TLUPlus capacitance tables are required for capacitances. If
TLU capacitance models do not exist, use Tools > Data Prep >
Techfile > Create Capacitance Model (cmCreateCapModel) to
build them from the process information. TLUPlus uses Star-RCXT
model generation to create capacitance tables.
To select parasitics options that affect timing and optimization,
1. Open the AstroTime Timing Setup dialog box (atTimingSetup)
and click the Parasitics tab.
Chapter 6: Setting Up the Design Timing
6-38
Model Page
Use the Model page to set cell delay model information and to
choose which net delay model to run for timing.
To select model options that affect timing and optimization,
1. Open the AstroTime Timing Setup dialog box (atTimingSetup)
and click the Model tab.
The Model page appears.
2. In the Cell Delay Model area, choose the operating condition and
specify cell delay or propagation delay values or keep defaults.
- Next to Operating Cond, click the Max, Nom, and/or Min
buttons to choose which corners of the loaded library
information are used during optimizations. Normally Max and
Min are selected.
- Under Cell Delay Method or Propagation Delay Method,
specify input and output time characterization points for the
rise and fall, in percentages, and specify transition delay rise
and fall time from start to end, in percentages.
For the cell delay method, also specify the floating number in
the Slew Derate From Table box that shows how the transition
time found in the table must be derated to match the transition
time between the start points and endpoints.
Click Load to load the settings of the cell delay method from the
reference libraries.
Note:
Astro determines the cell delay model to be used based on
your reference timing library. When using LM (logic model)
views, Astro has a consistent cell delay model with PrimeTime.
For more information, see Creating LM Views for Timing and
Power Analysis on page 3-29.
3. In the Net Delay Model area, select one of the methods for
analyzing net delay (Low Effort, Medium Effort, or High Effort).
- Use high effort for interconnect analysis that is consistent with
PrimeTime.
- For low or medium effort, it is recommended that you choose
low effort prior to routing and medium effort after routing. This
can produce faster runtimes when the added accuracy of
medium effort is not needed. However, you can choose to set
medium effort from the beginning. If you do so, low effort net
delay analysis is used by various parts of the tool, even though
medium effort is set, when the added accuracy of medium
effort is not needed (typically during optimizations prior to
routing).
Note:
Before running any timing function or Astro optimization, you
need to set at least one basic setting for the interconnect
model by selecting the appropriate net delay model.
4. Click Apply.
Chapter 6: Setting Up the Design Timing
6-44
Xtalk Page
Use the Xtalk page to set the crosstalk circuit model and to specify
crosstalk filtering thresholds (aggressor and electrical) and global
noise thresholds.
The ability to set global noise thresholds in the Xtalk page enables
postplacement optimization, crosstalk analysis, and postrouting
optimization to all use the same noise thresholds. The filtering
thresholds and global noise thresholds specified are honored in
crosstalk fixing as well as crosstalk analysis. See also Chapter 15,
Signal Integrity: Crosstalk Prevention, Analysis, and Fixing."
To select crosstalk options that affect timing and optimization,
1. Open the AstroTime Timing Setup dialog box (atTimingSetup)
and click the Xtalk tab.
The Xtalk page appears.
Star-RCXT parameter
Default
Default
COUPLING_REL_THRESHOLD
3%
3%
COUPLING_ABS_THRESHOLD
3 fF
3 fF
COUPLING_AVG_THRESHOLD
0%
0%
Table 6-2 lists the electrical filters. These filters are used by crosstalk
analysis for consistency with PrimeTime SI.
Table 6-2
Electrical Filters
PrimeTime parameter
Default
Default
si_filter_per_aggr_
noise_peak_ratio (xVdd)
0.01
0.01
si_filter_accum_aggr_
noise_peak_ratio (xVdd)
0.03
0.03
Sample Report
Following is the sample output file in Scheme format:
;; DB Capacitance Unit: pf
;; Aggressor filering:
;; Absolute total coupling capacitance threshold is 0.03pf
;; Relative total coupling capacitance threshold is 3%
ekSetCoupleCapThreshold 0.03 30
;; Average relative total coupling capacitance threshold is
;;25%
ekSetCoupleCapAvgPerThreshold 0.25
;; electrical filtering:
;; Peak Noise threshold is 0.01
xtSetPeakNoiseThreshold 0.01
;; Accumulate peak noise threshold is 0.03
xtSetAccumPeakNoiseThreshold 0.03
The first part defines the noise constraint groups and defines
their noise thresholds
The syntax for defining constraint groups and their noise thresholds
is
xtDefineXtalkConxGroup groupId riseThreshold fallThreshold
where
-setup
is used in the calculation of required time in the ideal mode, as
shown here:
Setup time
0.1000
2.7951
--------------------------------------Required time
2.7951
-hold
is used in the calculation of the required time in both ideal and
borrowing mode, as shown here:
Hold time
1.2000
6.4760
--------------------------------------------------Required time
6.4760
DL
is the instance name of the three-state buffer that is used as a
dynamic latch.
The setup and timing checks differ with borrowing and without
borrowing.
The timing checks for the path from the three-state buffer to FF2, as
shown in Figure 6-2 on page 6-55, are the same as when the
three-state buffer is treated as a level-sensitive latch, either without
time borrowing (ideal mode) or with time borrowing (time borrowing
mode).
Note:
Astro supports the definition of clock latency on the enable pin.
For example,
set_clock_latency -max 1 [get_pins
{THREE_STATE_BUFFER/EN}]
set_clock_latency -min 0.5 [get_pins
{THREE_STATE_BUFFER/EN}]
This feature is useful if you perform the timing check when the
clock is not propagated.
For example,
ataSetAndPropagateMaxCapBoundPort "IN1" 0.3
For example,
ataSetAndPropagateMaxCapClockData "clk1" 0.1
ataSetAndPropagateMaxCapClockData commands.
Alternatively, you can use the set_max_transition Tcl command
for setting this constraint.
Note:
Loading ataSetNetCapTransAndDelayTime creates a TIM
view to store the information. You should immediately save the
TIM view after the loading step, by using the
geSaveAllOpenCells command or Cell > Save All Open
Cells.
In a replay script, you can avoid the query boxes that pop up for
the geSaveAllOpenCells command (especially helpful in
nullDisplay mode), by specifying the following:
setDisplayMode "QueryBoxes" #f
geSaveAllOpenCells
7
Analyzing Timing
Astro provides various ways for you to analyze and understand the
timing results of your design. For example, after optimizing a design,
you can generate reports to analyze your timing, area, and
component selection results. When you study the reports, note any
constraint violations in the design. You might have to apply different
placement and routing techniques to improve the designs timing
results.
This chapter contains the following sections:
Probing Timing
Interactive Editing
7-1
Design Feasibility
Max and Min (next to Delay Type) and Max Trans and Max Cap
(under Report Constraints) and Show Histogram (under Other
Options). This produces a quick, summary report for the current
timing. Because only one path is reported for setup and hold (the
default), the report will not be very large. You can search for a
specific path as well as specify additional paths to be reported.
When you select Net Based (under Report Constraints), the
report includes the net name instead of only the port instance
(useful for debugging transition and capacitance violations).
Select Clock Trans to locate transition violations in the clock
network.
You can select Show Clock Path (under Other Options) to print
out detailed clock paths for the start points and endpoints of the
constrained timing path. You must first propagate the clock to get
the clock path to appear. To propagate the clock, include
set_propagated_clock <clk> in the SDC file, or use the
following syntax:
sdc "set_propagated_clock <clk>"
Example
Here is a sample timing report:
************************************************************************************************************
*
*
Astro Timing Report
*
*
Tool
: Astro
*
Version : V-2004.06-Development for IA.32 -- May 27, 2004
*
Design : TCS03_postIR
*
Date
: Thu May 27 17:05:15 2004
*
************************************************************************************************************
*
************************************************************************************************************
*
*
Design Setup
*
*
Analysis Type
: Max
*
Parasitic Source
: from LPE
*
LPE Operating Cond
: Max
*
LPE Mode
: Real_RC
*
Wire Delay
: AWE
*
Time Borrowing
: Enabled
*
Time Borrowing Method
: Standard
*
Preset/Clear Arcs
: Disabled
*
Recovery/Removal Arcs
: Enabled
*
Scan Enable
: Enabled
*
Inter Clock Paths
: Enabled
*
Default Clock
: Enabled
*
Ideal Network Delay
: Enabled
*
Mixed Clock/Signal Paths
: Enabled
*
Include Xtalk Induced Delay
: Enabled
*
Include Timing Window in Xtalk : Enabled
*
Include Non-Propagated Nets
: Disabled
*
Include Lib Max Transition
: Enabled
*
Include Lib Max Capacitance
: Enabled
*
Ignore Clock Uncertainty
: Disabled
*
Ignore Propagated Clock
: Disabled
*
Set IO Clock Latency
: Disabled
*
Enable Data Check
: Enabled
*
Load Useful Skew From DB
: Disabled
*
Enable Clock Gating Checks
: Enabled
*
Multiple Clocks Per Register
: Disabled
*
Include CRPR
: Disabled
*
Operating Conditions
: cb13os120_tsmc_max (Max)
*
cb13os120_tsmc_max (Min)
*
************************************************************************************************************
*
************************************************************************************************************
*
*
Reasons For No Optimization
*
*
NDT : Don't touch net.
*
IDT : Don't touch instance.
*
FIX : Fixed instance.
*
MDR : Multi-Driven net.
*
PCP : Huge pin cap on the net.
*
TRI : Tristate net.
*
PRE : Preserve Logic.
*
DIS : Disabled edges on the net.
*
NEQ : No equivalent cells.
*
************************************************************************************************************
************************************************************************************************************
*
*
Start point : V2Y_RDY_reg/CP
*
( Rising edge-triggered flipflop clocked by PE_CLK )
*
*
End point
: V2Y_RDY
*
( Output port clocked by FE_CLK )
*
*
Clock Group : FE_CLK
*
Delay Type : Max
*
Slack
: 16.1429 (MET)
*
************************************************************************************************************
Port/Pin
Cap Fanout
DTrans.
Trans.
Delta
Incr
Arri
DArri Reason Master/Net
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay (propagated)
736.3976
736.3976
-----------------------------------------------------------------------------------------------------------V2Y_RDY_reg/CP
0.0000
219.1833
0.0000
0.0000
736.3976
0.0000 r
sdnrb1
V2Y_RDY_reg/Q
0.0634
2
548.8898
580.2972
1316.6948
0.0000 f
V2Y_RDY
V2Y_RDY
0.0000
548.8898
0.0000
1.1857
1317.8805
0.0000 f
-----------------------------------------------------------------------------------------------------------Rising edge of clock FE_CLK
8000.0000
8000.0000
Clock Source delay
0.0000
8000.0000
Clock Network delay
0.0000
8000.0000
Clock Skew
0.0000
8000.0000
Output delay
6665.9766
1334.0234
-----------------------------------------------------------------------------------------------------------Required time
1334.0234
Arrival time
1317.8805
-----------------------------------------------------------------------------------------------------------Slack
16.1429 (MET)
************************************************************************************************************
*
*
Start point : REG_SEL_reg_00/CP
*
( Rising edge-triggered flipflop clocked by PE_CLK )
*
*
End point
: REG_DATA_reg_310/D
*
( Rising edge-triggered flipflop clocked by PE_CLK at CP )
*
*
Clock Group : PE_CLK
*
Delay Type : Max
*
Slack
: -225.8125 (VIOLATED)
*
************************************************************************************************************
Port/Pin
Cap Fanout
DTrans.
Trans.
Delta
Incr
Arri
DArri Reason Master/Net
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay (propagated)
723.1982
723.1982
-----------------------------------------------------------------------------------------------------------REG_SEL_reg_00/CP
0.0000
222.8459
0.0000
0.0000
723.1982
0.0000 r
sdnrb2
REG_SEL_reg_00/Q
0.0220
2
131.2129
435.8871
1159.0853
0.0000 f
n4186
U23330/I
0.0000
131.2129
0.0000
0.2576
1159.3429
0.0000 f
invbd4
U23330/ZN
0.0665
8
147.3377
86.9199 & 1246.2628
0.0000 r
n27428
U23333/I
0.0000
147.3377
0.0000
2.7320
1248.9948
0.0000 r
inv0d1
U23333/ZN
0.0260
4
235.9641
143.9407 & 1392.9354
0.0000 f
n27429
U990/A1
0.0000
236.0962
0.0000
0.0902
1393.0256
0.0000 f
nd02d2
U990/ZN
0.0110
2
129.0408
81.3385
1474.3641
0.0000 r
n5719
U15810/I
0.0000
129.0670
0.0000
0.0261
1474.3903
0.0000 r
invbd2
U15810/ZN
0.1088
14
413.6400
220.1883 & 1694.5786
0.0000 f
n4391
U8270/A2
0.0000
413.6400
0.0000
2.5494
1697.1281
0.0000 f
nd13d1
U8270/ZN
0.0169
2
143.1420
262.8775 & 1960.0055
0.0000 r
n4460
U15090/I
0.0000
143.1420
0.0000
0.2411
1960.2466
0.0000 r
inv0d1
.
.
.
U11131/A2
0.0000
105.5660
0.0000
0.0254
8230.0469
120.8064 f
an12d2
U11131/Z
0.0203
1
112.7747
146.3714 & 8376.4180
120.8064 f
n15540
U11132/I0
0.0000
112.7747
1.3620
1.9609
8378.3789
122.1685 f
mx02d1
U11132/Z
0.0038
1
105.2416
174.3659
8552.7451
122.1685 f
n3185
U4132/B1
0.0000
105.2424
0.0000
0.0008
8552.7461
122.1685 f
aoim21d1
U4132/ZN
0.0062
1
88.5375
278.5966
8831.3428
122.1685 f
n4720
REG_DATA_reg_310/D
0.0000
88.5758
0.0000
0.0382
8831.3809
122.1685 f
sdnrb2
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
8000.0000
8000.0000
Clock Source delay
0.0000
8000.0000
Clock Network delay (propagated)
777.0566
8777.0566
Clock Skew
0.0000
8777.0566
Setup time
171.4879
8605.5684
-----------------------------------------------------------------------------------------------------------Required time
8605.5684
Arrival time
8831.3809
-----------------------------------------------------------------------------------------------------------Slack
-225.8125 (VIOLATED)
************************************************************************************************************
*
*
Start point : DX13_reg_210/CP
*
( Rising edge-triggered flipflop clocked by PE_CLK )
*
*
End point
: DX13[21]
*
( Output port clocked by FE_CLK )
*
*
Clock Group : FE_CLK
*
Delay Type : Min
*
Slack
: 3952.0249 (MET)
*
************************************************************************************************************
Port/Pin
Cap Fanout
DTrans.
Trans.
Delta
Incr
Arri
DArri Reason Master/Net
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay (propagated)
721.0165
721.0165
-----------------------------------------------------------------------------------------------------------DX13_reg_210/CP
0.0000
211.8713
0.0000
0.0000
721.0165
0.0000 r
sdnrb1
DX13_reg_210/Q
0.1254
3
942.1585
732.2551 & 1453.2717
0.0000 r
DX13[21]
DX13[21]
0.0000
942.1585
-20.0640
-13.0700
1440.2018
-20.0640 r
-----------------------------------------------------------------------------------------------------------Rising edge of clock FE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay
0.0000
0.0000
Clock Skew
0.0000
0.0000
Output delay
-2511.8232
-2511.8232
-----------------------------------------------------------------------------------------------------------Required time
-2511.8232
Arrival time
1440.2018
-----------------------------------------------------------------------------------------------------------Slack
3952.0249 (MET)
************************************************************************************************************
*
*
Start point : ZERO_N03_reg/CP
*
( Rising edge-triggered flipflop clocked by PE_CLK )
*
*
End point
: ZERO_N04_reg/D
*
( Rising edge-triggered flipflop clocked by PE_CLK at CP )
*
*
Clock Group : PE_CLK
*
Delay Type : Min
*
Slack
: 433.3459 (MET)
*
************************************************************************************************************
Port/Pin
Cap Fanout
DTrans.
Trans.
Delta
Incr
Arri
DArri Reason Master/Net
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay (propagated)
715.7313
715.7313
-----------------------------------------------------------------------------------------------------------ZERO_N03_reg/CP
0.0000
208.6769
0.0000
0.0000
715.7313
0.0000 r
sdnrq1
ZERO_N03_reg/Q
0.0097
2
115.9748
348.0074
1063.7386
0.0000 f
n18876
ZERO_N04_reg/D
0.0000
116.0561
0.0000
0.0555
1063.7942
0.0000 f
sdnrq1
-----------------------------------------------------------------------------------------------------------Rising edge of clock PE_CLK
0.0000
0.0000
Clock Source delay
0.0000
0.0000
Clock Network delay (propagated)
716.9586
716.9586
Clock Skew
0.0000
716.9586
Hold time
-86.5103
630.4483
-----------------------------------------------------------------------------------------------------------Required time
630.4483
Arrival time
1063.7942
-----------------------------------------------------------------------------------------------------------Slack
433.3459 (MET)
************************************************************************************************************
*
*
* Xtalk Noise Violations (static noise)
*
*
*
************************************************************************************************************
Violation Constraint Reason Net
-----------------------------------------------------------------------------------------------------------No xtalk noise violations found in the design.
The syntax is
(tcl "report_timing -path_type full_clock_expanded")
Probing Timing
The timing probe allows for the interactive querying of paths, the
display of histograms, a schematic display of paths, and case
analysis; also, the timer can be reinitialized.
To launch the Astro timing probe,
The AstroTime Timing Probe dialog box includes several tabs, listed
in this table and described in the following sections.
Tab
Description
Timing Analyzer
Path Timing
Lists the end port and start port names of the path
ports and displays a text window and histogram of
the path end and path start ports.
Instance Timing
Net Timing
Schematic Probe
Probing Timing
7-11
Probing Timing
7-13
- Free Timer, which frees the timing graph so that when you
update the timer, the timing analysis is done from the
beginning. If you change the operating condition in the
AstroTime Timing Setup dialog box, you must free the timer.
Search Results
The Search Results window lists all path start ports, thru ports, and
end ports that match the values you enter in the SPECIFY PATH
SEARCH CRITERIA area, as shown in Figure 7-1.
Figure 7-1
List Path
After you locate the path, click List Paths In Text, in the top-right
corner under PATH TIMING COMMANDS, to list the details of the
path in the List Path window that appears, as shown in Figure 7-2.
Probing Timing
7-15
Figure 7-2
Use this window to cross-probe cells and nets. You can either
highlight nets after routing or highlight the flylines of the nets before
routing. At the top of each path listed is an option for highlighting all
the cells in the path and/or all the nets in a path. Alternatively, you
can select individual cells and nets.
To cross-probe the path, click Export This Path To Schematic Probe
(at the bottom of each path).
Histogram
After you locate the path, click Show Histogram, in the top-right
corner under PATH TIMING COMMANDS, to display the distribution
of path timing in the Histogram window that appears, as shown in
Figure 7-3.
Figure 7-3
Histogram Window
Probing Timing
7-17
Probing Timing
7-19
Interactive Editing
Two commands are provided for interactive editing: the astEdit
command, which is graphically based, and the astChangeNetlist
command, which is name based.
astEdit
Use the astEdit command to find critical paths and interactively
modify the design with techniques such as cell instance sizing, buffer
insertion, net bypassing, net splitting, and cell moving.
The astEdit command should be used after the placement, global
routing, or detail routing phases of the design flow.
To find critical paths or modify the design,
1. Enter astEdit or choose PostPlace > Optimization Interactive
Edit.
The Netlist Change dialog box appears.
Interactive Editing
7-21
astChangeNetlist
Use the astChangeNetlist command to remove and insert
buffers, size cell instances, and change cell masters.
To change the netlist,
1. Enter astChangeNetlist or choose PostPlace >
Optimization Change Netlist.
The Change Netlist dialog box appears.
Interactive Editing
7-23
Placement Information
The Placement Information section reports both the first full-chip
placement statistics and the statistics on area and ECO placement
operations. When you run a full-chip placement, the HISTORY
subsection is reset. The TOTAL RUN TIME subsection provides the
sum of a full-chip placement and all area and ECO placement
operations.
Timing/Optimization Information
A sample Timing/Optimization Information section follows.
This section reports information for ideal timing and the various
optimization processes that you can run throughout the design flow:
IDEAL
This is the timing without any interconnect and is theoretically the
best answer possible (there can be some optimization without
interconnect, some remapping, and so on). Generally, when this
is not a reasonable number, you need to go back to synthesis.
PRE
These statistics occur after preplacement optimizationthat is,
after high-fanout net analysis, remapping, and simple area
recovery are run. This is a starting point.
IPO
These statistics occur after in-placement optimization.
In-placement optimization intermixes optimization with
placement to minimize congestion and optimize timing. At each
stage, there might not be a valid, complete placement, but
optimization can be executed to help the timing-driven
placement. Although this optimization should remove any large
errors, it is not complete, because not all transition/capacitance/
hold violations are fixed.
Depending on the design, in-placement optimization can be
executed several times throughout the placementit should get
progressively better. Because this happens in the middle of
placement, the timing result does not take into account all of the
placement moves associated with optimization. This is why
POST can be worse than IN (if there were placement moves due
to sizing, buffers, and so on that had not been accounted for in
the IN place number).
PPO1
These statistics occur after postplacement optimization,
phase 1 (astPostPS1).
PPO
These statistics occur after postplacement optimization,
phase 2 (astPostPS).
GLOBAL
These statistics occur after global routing optimization
(astPostGR).
IN-RT
These statistics occur after postrouting optimization
(axgAdvRouteOpt).
DETAIL
These statistics occur after postrouting detail optimization
(astPostRT).
DRC Information
The DRC Information section reports the number of shorts, the
number of different net spacing violations, and the total number of
errors.
- Unconstrained Endpoints
Reports all the primary outputs and registers data pins that are
not time-constrained in the design and are not on any false
paths.
- No Input Delay
Reports all the primary inputs that have no delay specified.
Astro assumes that DEFAULT CLOCK is the reference clock
for these inputs.
- No Clock Fanin
Reports all the register clock pins that are not connected to any
clock signal.
- Multiple Clock fanins
Reports all the register clock pins that can be reached from
multiple clock signals.
- Combinational feedback loops
Reports all the combinational loops found in the design. These
loops are automatically broken by Astro, and you can use the
ataSetDisableTiming command to break such loops
manually.
- Latch Fanout
Reports all the latch pairs with the same clock. The output of
one latch goes to the input of the other latch in the pair. Also
reports latch self-loops, a situation where a latch output might
drive its input through combination logic. The data can flow
through the latch multiple times during the active phase.
Information
The check design report includes information such as
Design Information
- Cell instances, macro instances
- Pins, nets
- Utilization, hierarchy preservation, scan chain connections
Timing Information
- Operating condition, LPE information
- Environment panel settings
- Thresholds
Optimization Information
- Target setup slack, target hold slack
- Maximum fanout
- Target utilization, maximum utilization
SDC Information
- Clocks, generated clocks, global constraints
Buffer/Inverters in Design
Library Information
- Buffers/inverters sorted by driver resistance
- Buffers/inverters sorted by area
- Buffers/inverters sorted by delay
- Buffers/inverters sorted by maximum transition
- Buffers/inverters sorted by maximum capacitance
- DontUse buffers/Inverters sorted by area
- Library sorted by driver resistance
- Library sorted by area
- Library sorted by maximum transition
- Library sorted by maximum capacitance
Hints
The check design report includes hints on what to do, based on what
is found in the design, such as the following:
It does not make sense to continue the optimization process until you
are fairly certain that these questions have been answered
satisfactorily. Astro provides several utilities and reports to handle
these issues.
Note:
To run zero interconnect timing in PrimeTime, do not provide any
wire load models in the .lib files read by PrimeTime. The .lib files
written by Astro do not contain wire load models.
Design Feasibility
See Performing Preplacement Optimization on page 8-58. It is best
to use the astCheckDesign command after preplacement
optimizations are completed.
Which timing models are used in synthesis, place and route, and
timing sign-off?
These timing models should be consistent.
Are the timing models accurate enough for ultra deep submicron
processes?
Design Feasibility
7-39
Layer Scope
This is the number of layers the TLU model considers to be the
interlayer capacitance from above and below the reference
layers. The default is set to maxMetalLayerNum + 1 in Astro.
Use the ekSetLayerScope command to set it in Astro.
Note:
By default, this number is 2 in Apollo, so be careful to
synchronize the setting when comparing Apollo and Astro.
Note:
By default, this number is 3 in Apollo, so be careful to
synchronize the setting when comparing Apollo and Astro.
and
(axSetRealParam "ek" "resMultiplier" 1.05)
THICKNESS_VS_DENSITY,
DENSITY_BOX_WEIGHTING_FACTOR, RPSQ_VS_SI_WIDTH,
ETCH_VS_WIDTH_SPACING, RPSQ_VS_WIDTH_SPACING,
THICKNESS_VS_WIDTH_SPACING, and temperature deration
(GLOBAL_TEMPERATURE, CRT1, CRT2). During RC extraction,
you should consider using these complex variations to get accurate
capacitance and resistance values for timing closure analysis.
For more information, see the Star-RCXT documentation.
Option
Description
-positive
-negative
-clocks
port_pin_list
If the -clocks option is used, only the specified clock domains are
applied. Otherwise, all clocks passing through the given pin objects
are considered.
Astro will issue warning messages if the specified sense on given
pins cannot be respected in the case where there is predefined
unateness for given pins. Hierarchical pin is not supported.
To undo set_clock_sense, use the remove_clock_sense
command.
8
Placement and Placement Optimizations 8
After you have a design set up, you are ready to place your design
and run placement optimizations, including preplacement
optimization, in-placement optimization, and postplacement
optimization before clock tree synthesis and after clock tree
synthesis.
This chapter contains the following sections:
Placement Flow
8-1
Optimizing Power
Placement Flow
Placement is performed in four optimization phases:
Preplacement optimization
In-placement optimization
Placement Flow
8-3
Placement Flow
8-5
astFanoutSetup
See Optimizing High-Fanout Nets on page 8-68.
pdsHFNOptimization
See High-Fanout Net Optimization on page 8-88.
astDesignRules
See Design Rule Fixing in Astro on page 8-87
Placement Flow
8-7
Figure 8-1
Evaluate placement
axgDisplayPLCongestionMap
axgDisplayCouplingCapMap
To routing
For example,
netWeight /core_datapath/net1 10 10
Ignore off-grid via region Select if you want the placer to ignore
all off-grid via regions of a pin. Use this option when you have
pins with off-grid via regions but do not want to use off-grid
routing. The exception is when a pin does not have any on-grid
via regions; in this case, Astro considers all the pins via regions
to avoid nonroutable placement.
3. Click OK or Apply.
Defining Magnets
To perform magnet placement, you must first define, or select, the
magnets by using the select operations, accessible from the Select
menu. Typically, a fixed object with net connections to placeable
standard cells, such as macros, I/O pins, and pads, can become a
magnet.
Important:
The weight settings for magnet placement are generally not
suitable for global placement. Make sure you use a different set
of weights when performing global placement.
Using astMagnetPlace
After you select your magnets, you are ready to use
astMagnetPlace. This command identifies the cells to be placed
and places the cells in legal locations. It also issues a warning for
magnets that are ignored, such as vias or blockages.
To run magnet placement,
1. Enter astMagnetPlace.
The AstroPlace Magnet Placement dialog box appears.
Note:
Astro automatically switches from row-based overlap removal to
area-based overlap removal when the design has cell instances
that are marked with the size_only attribute.
To view the size_only constraints, as well as other constraints in
your design, use the astWriteDC command (for information, see
Writing ast Design Constraint Commands on page 6-14).
Placement blockages
The keepout margin of hard macros is not included in the sliver size.
Hard macro slivers are measured from the edge of the keepout
margin, not from the edge of the macro.
The syntax is
axSetIntParam "place" "sliver_size" value
Using astAutoPlace
To perform placement and optimizations before clock tree synthesis,
1. Enter astAutoPlace or choose InPlace > AutoPlace.
The Astro Auto Place dialog box appears.
For the In-Place stage, in the In-Place Optimization area you can
select Netlist Change, which performs netlist changes for fixing
setup violations during in-placement optimization.
For the Post-Place stage, in the Post-Place Optimization area
select from the following options:
- Use Global Routing, which performs global routing first, after
which design rule fixing is performed, and then the routing
removed. This flow is useful for top-level designs or for designs
that have several channels between macros.
- Prevent Crosstalk, where crosstalk noise is estimated from the
congestion, and noise is computed based on the estimated
aggressors. From this information, violating nets are fixed by
increasing the driver strength or by buffering the net. This
technique attempts to preserve the current timing of the design
and skips prevention when the change causes too much timing
degradation.
- Fix Max Length, which limits all nets to the specified length by
inserting buffers.
For information about the Post-CTS Optimization area, see
Performing Postplacement Optimization After Clock Tree
Synthesis on page 8-40.
8. Click OK.
Note:
If the astAutoPlace command does not give satisfactory
results after the preplacement, in-placement, and postplacement
stages, another option is to run astMagnetPlace. This
command seeds the locations of standard cells to magnet
objects (typically macros) before proceeding to clock tree
Figure 8-2
Wire tracks
Global routing
cells
Two-dimensional congestion map shows the edges of the overflowing global routing
cells. The color of the global routing cell edge in your graphics window shows the
severity of the overflow.
Macro cell
One-dimensional
congestion map
for vertical
routing
The demand is
greater than the
capacity for vertical
routing crossing
this line.
Standard cells
Macro cell
One-dimensional congestion
map red line
Macro cell
Optimizing Power
Use the astPowerRecovery command to perform power
optimization after postplacement optimization. Typically, you
optimize for timing and then optimize for power, preserving setup,
hold, transition, and capacitance. Postplacement power optimization
sizes and removes buffers.
To begin power optimization,
1. Enter astPowerRecovery or choose PostPlace >
Optimization Power Recovery.
The Power Recovery dialog box appears.
3. Click OK or Apply.
By default, Astro clock tree synthesis synthesizes clock trees under
the worst-case operating condition. Its function is to minimize global
skew using timing constraints you specify.
After running clock tree synthesis, you get the following results:
A buffer tree for each clock net. The driver of the buffer tree is a
preexisting cell or the clock source in your clock tree. There is no
buffer tree added to the small net if the driving strength of the
preexisting cell is strong enough.
The connected power and ground for all inserted buffers and
inverters. There are no power and ground connections when your
design has more than one power line.
The same routing rules you defined before clock tree synthesis
on all new created nets. When a buffer is added to a net, a new
net is created at the buffers output side. The new net inherits all
the routing rules of the original net (the input net).
With clock tree synthesis completed, you need to propagate the
clock using
sdc "set_propagated_clock [all_clocks]"
Force optimization of some paths that are not the most critical
paths
2. Specify the filler cell lists to be loaded for use during insertion.
You can do one or more of the following:
- Enter the names of the master cells to be used in the Master
Cell Name(s) Without Metal or the Master Cell Name(s) With
Metal boxes.
Astro inserts the specified filler cells in two passes. In the first
pass, filler cells with metal are inserted, but filler cells that
cause DRC violations are removed. In the second pass, filler
cells without metal are inserted to complete the insertion
process.
- Select include all VT filler (the default) to specify that all
voltage threshold filler cells are to be loaded. Deselect this
option, and enter one or more names of the voltage threshold
filler cells in the VT Filler Name(s) box, to limit insertion to the
named cells.
For information about defining the filler cells to be used in
mixed-voltage threshold designs, see the Astro User Guide:
Advanced Topics.
3. Select other options, depending on your requirements. You can
- Specify that filler cells be placed in named voltage areas only
by entering the voltage area names in the Only in Voltage
Area(s) box.
- Select Check only to check that fillers are inserted correctly,
based on the specified requirements. This operation checks
that
The left-and-right filler cells are inserted as specified
The filler cells do not overlap with neighboring cells
The filler cells are not outside of the cell row
The filler cells power and ground pins are connected to the
specified power and ground nets
The filler cells are assigned the correct voltage area in
multivoltage designs
This process enables the tie-off of unused cell inputs to tie cells. The
connect_tie_cells command does the following:
The maximum number of cells that can be tied to a single tie cell
(this is the maximum fanout constraint), or you can use the
default constraint
The syntax is
connect_tie_cells
-objects {<collection>}
-object_type [cell_inst |lib_cell |port_inst]
-tie_high_lib_cell string
-tie_low_lib_cell string
-tie_highlow_lib_cell string
-tie_high_port_name string
-tie_low_port_name string
-max_fanout n
-max_wirelength n
-incremental [true | false]
TIEHL only
- The -tie_high_lib_cell and -tie_low_lib_cell
options must not be used
- The -tie_highlow_lib_cell option must be used
- Both the -tie_high_port_name and
-tie_low_port_name options must be used
Quick placement
High-fanout collapse
Gate sizing
Cell moving
Gate duplication
Net splitting
Area recovery
Remapping
- Cell Downsize
Enables downsizing during preplacement optimization. The
box to the right specifies how far it can downsize. For example,
a value of 1 allows downsizing by only one drive strength; a
value of 0 downsizes all the way. Downsizing all cells could
create a huge impact on placement and, because Astro might
not be able to upsize all the cells in the design, use this only
when absolutely necessary.
- Area Recovery
Eliminates buffers and downsizes cells. By default, the
utilization at which this occurs is 50 percent or higher, as
specified in the AstroTime Timing Setup dialog box. Use the
AstroTime Timing Setup dialog box to lower this threshold
when you want more recovery to occur.
Use the Remove Buffers option to remove buffer that do not
affect the setup slack.
Under Quick Placement, the option is
- Enforce Full Place
Forces the tool to complete a full quick placement before trying
to fix high-fanout nets. When unselected, it simply runs the
ECO placement. Assuming you already have a valid
placement in your design, you do not need to rerun a full
placement; an ECO placement suffices. Previously, the
strategy was to do more massive changes, such as a
high-fanout nets optimization, before detail placement began.
When the location constraint options in the Place Common
Options dialog box need to be changed from the defaults, do
so prior to running preplacement optimization. For example, if
you have preroutes on metal 1 that are of the strap type and
High-Fanout Collapse
High-fanout nets are addressed automatically while the astPrePS
command is running. There is no need to set the high-fanout net
transition delay. Use the ataSetNetCapTransAndDelayTime
command to force the astPrePS command to exclude a specific
net. For nets such as reset, use the stand-alone pdsHFNOptNet
command. To reduce congestion, run high-fanout collapse before
preplacement optimization to clean up the synthesis netlist. You can
select High Fanout Collapse and enter 10 (the default) in its text box
in the Pre-Placement Optimization dialog box.
Astro Resynthesis
Astro resynthesis focuses on physical optimization. Traditional
synthesis has netlist elaboration, which is typically netlist translation.
Netlist optimization, with accurate and accessible physical
information, is the key to achieving fast timing closure. Astro
synthesis technology provides various optimization approaches that
are applied to different scales at each place and route stage.
Unlike traditional synthesis tools with design-size limitations, Astro
synthesis focuses on optimization by allocating reasonable clusters
or working regions. It does not have an inherent design-size
limitation. As long as the design can be accepted by the Astro
system, depending on 32-bit or 64-bit architecture, the Astro
synthesis technology can work on it.
Remapping
Remapping includes the following algorithms and techniques:
Optimizes the worst setup slack and the total negative setup
slack; does not fix hold time
In that case you need to update the congestion map with the
axgUpdateCongMap command and restart the astPlaceDesign
command.
After automatic placement, Astro displays a congestion map that
contains an estimate of the routing congestion in the design. The
astPlaceDesign command also performs cell sizing, cell moving,
cell bypassing, buffer and inverter insertion, gate duplication, and net
splitting optimization techniques.
Refining Placement
After you run automatic placement, you can improve placement by
using the astSearchRefine and astPlaceArea commands, as
described in the next sections.
placement when it cannot improve the placement. You can use the
astAddPlaceSRConst command to specify areas in which Astro
runs the astSearchRefine command.
To run search and refine placement,
1. Enter astSearchRefine or choose InPlace > AstroPlace
Search and Refine.
The AstroPlace Search & Refine dialog box appears.
If the hold violations in your design are considerable, run hold fixing
during postplacement optimization phase 2 and fix any remaining
violations in the postrouting stage. Postrouting optimization can
make only small changes and might not be capable of fixing
numerous hold violations.
Layout changes during postplacement optimization phase 2 might
also disturb the clock structure. Therefore, clock tree optimization is
required at the end of postplacement optimization. For detailed
information about clock tree optimization, see Optimizing Clock
Trees on page 9-75.
Topology-Based Methodology
Topology-based optimization, which is used throughout the Astro
postplacement optimization flow, greatly assists in timing
optimization and has powerful techniques that allow you to close
timing where other approaches cannot.
During routing, the optimization uses the actual topology of the
routing to place new cells along the route while honoring all
placement and routing blockages, thus minimizing congestion and
improving timing. Before global or detail routing, however, the tool
must be capable of handling placement blockages, routing
blockages, and future congested channels while accurately placing
cells in desired locations. Topology-based optimization and its
interaction with placement and routing constitute the topology-based
methodology.
nets and the new nets generated from them. This file is generated
during optimization and read in during the reconnect procedure of
the routing repair flow.
If you want to maintain predictability of the results during the routing
repair flow, the number of broken nets should not be too large. A
placement engine internally controls the number of broken nets and
interrupts the optimization when a certain threshold is reached. If this
happens, you see the OV-INTERRUPT message in your log file. The
routing repair is called after that and the optimization continues.
The following situation illustrates topology-based methodology:
Assume that a transition violation occurred that requires the buffers
on the right and left to be inserted as shown in Figure 8-4. Because
the routing is not blocked by using the dotted line path, the routing
estimate can route over the block. If you are trying to fix the transition
violation, however, you must insert a buffer, but when it is inserted
under the estimated routing, it is considered illegal. Topology-based
fixing considers both the routing and placement blockages to
determine that the optimal solution is to insert one buffer on the left
and one in the gap on the right. If you do not use topology-based
optimization, the solution is not obvious.
Figure 8-4
Placement blockage
Routing blockage
Figure 8-5
Macro
Congested routing channel
Medium effort takes nearly two times as long as the Low effort
and usually provides a noticeably better total negative setup
slack and a worst negative setup slack at the end.
HIGH Adds one more loop of total negative setup slack
optimization and worst negative setup slack optimization,
using logic restructuring and detail optimization algorithms.
The runtime in High effort significantly increases as a tradeoff
for extra stress on the worst negative setup slack optimization.
- Re-do HFN Synthesis
Because placement ignores nets with fanouts more than 32,
you might end up with a bad placement for nets that contribute
to increased wire length and congestion. This might happen
when you perform timing-driven or congestion-driven
placement without in-placement optimization and your starting
netlist has synthesized high-fanout nets (HFN). In this case,
resynthesize all such nets. The Re-do HFN Synthesis option
performs high-fanout net collapsing and then rebuilds the
high-fanout nets based on final placement clustering. This
helps relieve congestion in the design.
When an in-placement optimization flow is run, this step has
already been performed and must not be rerun in
postplacement optimization phase 1.
- Use Global Routing
Sometimes the layout floorplan is so complicated that the
estimation of the layout parasitics as well as the prediction of
the routing topology-based optimization on virtual routing
algorithms is often inaccurate. As a result, they cannot be used
for timing estimation and topology-based optimization. An
example of such a layout is a design with narrow routing
Use the Preserve option to control the effort. Select WNS for
medium effort and TNS for low effort.
- Design Rule Fixing
Fix Max Length On some designs, it helps to place buffers at
specified lengths before doing detailed optimization. Typically,
these are large designs or designs with several macro
blockages. The buffers serve as a guide.
Fix Tran/Cap Fixes maximum transition and capacitance
violations.
Activating the Detailed Message Report option in the
Optimization page of the AstroTime Timing Setup dialog box
(atTimingSetup command) might help debug unfixed
violations. For example, the following message for a given net
Cannot Insert Buffers #Times : Placement
Area recovery
Buffer insertion
Cell sizing
Logic restructuring
Net splitting
Gate duplication
Inverter insertion
Cell moving
You can specify that astPostPS not add any new instances during
optimization (gate sizing and gate moving only are allowed). To
enable this behavior, enter
axSetIntParam "pds" "no_new_instance" 1
3. Set the other circuit mode conditions (if any), and repeat the
optimization several times.
In this way, the design is best optimized for the operating condition
but is also optimized for other operating conditions. The same
procedure can be repeated during postrouting optimization.
To begin postplacement optimization phase 2,
1. Enter astPostPS or choose PostPlace > Optimization
Post-Place Optimization.
The Post-Placement Optimization dialog box appears.
also appears.
Another debug message:
Cannot Insert Buffers #Times: Hierarchy
exceed the worst setup slack. If you select high effort, the fixing hold
becomes the primary goal of the optimization. All netlist changes that
improve the hold slack are accepted without considering the setup
slack. The algorithm simultaneously considers the best and worst
operating conditions for cells and parasitics.
To fix topology-based hold slack violations with optimization,
1. Enter astTopoHold.
The Hold Slack Optimization dialog box appears.
Requiring cells with large delays but with a small area optimized
only for hold time fixing
Only buffers are extracted from the list; inverters or other cells are
not extracted.
Only the buffer insertion algorithm honors the buffer list you
define; the cell sizing algorithm uses logical equivalent
information for buffer sizing.
The buffers specified in the buffer list are used only by the
astTopoHold command and do not affect other commands or
optimizations.
hold fixing algorithms can use other buffer cells for hold fixing. In this
instance, the cells marked as DELAY_CELL are an exclusive subset
of the buffer cells used by the hold fixing algorithm. In summary,
For setup fixing, only those buffers that are not marked as
DELAY_CELL are used.
create a cut set of nets for hold fixing that does not overlap with any
setup critical path. With this cut set of nets, you can perform hold
fixing without disturbing the setup slack.
You use the astHoldGenerateCutSet command to generate
names of nets that have to be buffered for hold violation fixing. The
astHoldGenerateCutSet command gets the list of hold violated
paths from the timing report. Before running the
astHoldGenerateCutSet command, you use the timing report
options from, through, and to to get a subset of hold violated
paths that you are interested in fixing (see Using Timing Reports
on page 7-3).
The syntax for astHoldGenerateCutSet is
astHoldGenerateCutSet "file.name"
The last net on every hold violated path makes a default cut set.
The list of nets might include a second and third field for each entry,
which specify the required rise and fall delays that need to be
inserted into the net. If the optional delay numbers are specified,
optimization introduces delay equal to or greater than these values
for rise and fall, possibly with a chain of buffers. If only one delay
number is specified, that number is used for both rise and fall delays.
If no delay is specified for the net, a single buffer attempting to fix the
hold slack is inserted into the net.
You use the User specified insertion delay option in the Hold Slack
Optimization dialog box to specify whether to use the rise and fall
delays. If the User specified insertion delay option is deselected,
the rise and fall delays are ignored, and optimization tries to fix hold
by inserting one buffer into the specified net. If the User specified
insertion delay option is selected, optimization tries to honor the
delay numbers specified.
Note:
Optimization is driven by the setup and hold slack calculated by
the Astro timer, so the optimization might not completely solve
correlation problems. You might need to control target setup and
hold slack to achieve the best result for the flow.
Debugging Messages for Unfixed Violations. This section lists
debugging messages and possible causes reported for unfixed
violations.
>>Rejected by OV : Move
An action was rejected because of big cell displacement during
placement legalization. The maximum displacement is reported
in the log file as
"PRO: OV CONSTRAINT :: Maximum displacement = 69120"
>>Rejected by OV : Number
An action was rejected because a large number of cells were
moved during placement legalization. The maximum number of
moved cells is reported in the log file as
"PRO: OV CONSTRAINT "Maximum number of moved cells = 100"
Area Recovery
Use the astAreaRecovery command to perform area recovery on
your design. This command downsizes cells or removes buffers to
decrease the utilization of the cell while maintaining certain timing
aspects. The default behavior is to not make the setup slack worse.
You can run astAreaRecovery before or after the routing stage.
The astAutoPlace command performs area recovery during
preplacement optimization and postplacement optimization after
clock tree synthesis.
9
Clock Tree Synthesis and Clock Tree
Optimizations
9-1
The timing information for clock tree synthesis is obtained from the
SDC file. Some timing information can be changed and set at the
command line or by using Astro. If you have used the timing-driven
layout capabilities of Astro, you already have most of the relevant
timing information.
The following two tables summarize many of the commands you can
use that pertain to clock tree synthesis. Table 9-1 lists Scheme
commands and Table 9-2 lists Tcl commands.
Table 9-1
Task
Scheme command
astClockOptions
astClockTiming
astCTO
astClockBrowser
astCTOInterClocksBalance
astCheckDesignForCTS
astCTS
astCTSBasic
astDeleteClockTree
astECOCTS
astMarkClockTree
astPostRouteCTO
astSkewAnalysis
astSplitClockNet
Provide additional
constraints for transition
delay
ataSetAndPropagateMaxTransClock
Table 9-1
Task
Scheme command
astReportClockTreePower
axgDefineVarRule
axgSetMinMaxLayer
axgSetNetConstraint
ctiCTS
Table 9-2
Task
Tcl command
set_clock_tree_options
optimize_clock_tree
balance_inter_clock_delay
compile_clock_trees
remove_clock_tree
optimize_clock_tree -eco
mark_clock_tree
optimize_clock_tree -post_route
Table 9-2
Task
Tcl command
split_clock_net
set_clock_tree_exceptions
remove_clock_tree_exceptions
set_clock_tree_references
check_design_for_cts
useful_skew_opt
Table 9-3
Timing Information
Timing information
Defined in
clfCreateTable
clfCreateTable
dbDefineIgnorePort
Boolean function
defineBooleanFunction
defineCellDontTouch
defineCellDontUse
Maximum capacitance
defineCellMaxCapacitance
Maximum fan-out
defineCellMaxFanout
defineCellMaxTransition
defineClockNetworkTLU
Flip-flop definition
defineFlipFlopFunction
Latch definition
defineLatchFunction
Port capacitance
definePortCapacitance
Note:
The trigger edge (rise or fall) information is highly important in
clock tree synthesis. If there is no trigger edge information at a
clock porteven though you have defined it as a clock port with
the dbSetCellPortTypes commandit is identified as an
implicit ignore pin by the tool, because the tool does not know
whether it should be synchronized at the rising or falling edge.
If a sequential cells input port has no clock port definition but has a
constraint timing arc defined such as Setup_rising,
Setup_falling, Hold_rising, Hold_falling, it is considered
a clock port in Astro clock tree synthesis.
Use the astSetDontTouch and astSetDontUse commands to
define the dont touch and dont use cell masters. Use the
ataDumpSDC command to write these settings to a text file for
reference.
Timing information
Defined with
Clock cell
Delay cell
The ataSetNetCapTransAndDelayTime
command
Table 9-4
Timing information
Defined with
Clock source
Generated clock
Driving resistance
Driving cell
Note:
The clock source information (the create_clock command) is
essential in clock tree synthesis. Without this information, Astro
clock tree synthesis will not insert any clock trees.
If you have defined the set_clock_latency command, Astro
clock tree synthesis tries to insert a clock tree with the delay as close
as possible to your settings so that you will have similar timing
reports for both ideal clock and real clock.
Figure 9-1
Source
Sink pin
count
Ignore pin
Note:
The time required to load the common graph data increases
with design complexity. Allow more time for larger designs.
The clock browser does not automatically refresh the common
graph data. If another command or process changes or unloads
the common graph data while the clock browser is running, the
changes are not reflected in the clock list or clock path structure.
To see the changes, click the Close button and restart the clock
browser.
2. Click Show Selected to display the path of the clock net selected
in the clock list. The clock list shows all the clocks in the design
by name.
To view more detail about a particular clock, click the expansion
(+) icon to expand the clock tree and show the next level of the
clock structure.
When you double-click a clock name in the clock browser, that
clock is highlighted in a preslected color, and the full clock path is
visible in the design layout window in the same color. Each time
you double-click another clock name in the browser and then
click Show Selected, the clock path is displayed in a different
preselected color in the design layout window.
3. Use the color option to control the color of the clock path
displayed in the clock list and design layout window. You can
enter a color to use, or you can use the preselected color.
Note:
Color appears only if the clock is highlighted, otherwise it
remains gray.
4. Click Clear All to clear all clock paths highlighted in the clock
browser and the design layout window.
Chapter 9: Clock Tree Synthesis and Clock Tree Optimizations
9-16
Select the clock information you want in written to a file and enter
a file name or use the default file name, as shown in Figure 9-2.
When you enable all the options in the Save to File dialog box,
the report generated is identical to the report generated with the
astReportClockTree command when all its options are
enabled. The clock summary generated by the
astClockBrowser command, however, reports ignored
subtrees of the clock tree, which are not reported by the
astReportClockTree commands.
6. Click Close to exit the clock browser.
For details about the astClockBrowser command options, see the
Physical Implementation online Help.
Figure 9-3
Enter the subtrees net name in the Clock Nets box in the Clock
Common Options dialog box. Because you have a defined clock at
the top, it is not necessary to have a clock definition for each subtree.
Note:
When you define a clock for a subtree of the defined clock, you
create multiple clocks that have a domain overlap. This might
result in increased runtime.
To find the subtrees net name,
1. Click the Search button next to the Clock Nets box.
The Search Clock Nets dialog box appears.
2. Set a pattern to Net Pattern.
3. Click Search.
All nets that match the pattern appear in the Net Name List.
4. Select the nets you want in the Net Name List.
5. Click OK.
The selected nets appear in the Clock Nets box in the Clock
Common Options dialog box.
Case 3: You want to synthesize clock trees in the order you expect.
You must specify the clock nets in the Clock Nets box of the Clock
Common Options dialog box. The order you provide is the order of
synthesis.
Important:
The most critical clock should be the last clock, because the
buffer that is inserted last has higher priority for the location
calculated by the placement overlap removal engine. That is,
when placed cells overlap with an inserted buffer, those cells are
moved away to place the buffer. As a result, the timing of the
latest inserted clock tree has fewer disturbances due to overlap
removal.
The Clock Nets box of the Clock Common Options dialog box can be
used for pin names or clock names. The clock name is the name you
provide when you use the create_clock command.
where leaving the cellName as "" defines the top cell boundary
port as a synchronous port.
ataPurgeSyncPort "*"
ataPurgeSyncPin cellId "*"
Astro supports only the purging of all synchronous ports and pins.
If you are not sure whether the clock ports of sequential cells in your
libraries have trigger edge information, review your library
preparation or use the auDumpCLF command to write a text file. In
the file, you must have defineTimingTLU statements with the
following keywords for all sequential cells.
Setup_rising
Setup_falling
Hold_rising
Hold_falling
Clock_rising
Clock_falling
Example 2:
defineTimeTLU "SDFFSRX2" "D" "CK" "NONUNATE" "Hold_rising"
...
Example 3:
defineTimeTLU "SDFFSRX2" "CK" "Q" "NONUNATE" \
"Clock_rising"...
Note:
If a sequential cell is defined as a clock-gating integrated cell with
the dbSetLModeSubType command, or its output port has a
create_generated_clock defined, its clock port is not
treated as a clock sink (synchronous) pin, even if it has trigger
edge information. Astro clock tree synthesis traverses that pin
and synthesizes clock trees beyond that pin.
If you want to synchronize a nonclock pinsuch as a combination
logic gates pin, a macros pin, or a sequential gates set/reset pin
you must define it as a synchronous pin explicitly, using the
dbDefineSyncPin or dbDefineSyncPort command. The
dbDefineSyncPin command is used for the instance; whereas,
the dbDefineSyncPort command is used for the master.
Review your library preparation and design preparation to make sure
your synchronous port and synchronous pin definitions are
completed.
To verify that you have synchronous ports defined in your libraries,
use the auDumpCLF command to write a text file. In the file, you must
have dbDefineSyncPort statements for all defined synchronous
ports.
To verify that you have synchronous pins defined in your design, use
the dbDumpSyncPin command to write a text file. In the file, you
must have dbDefineSyncPin statements for all defined
synchronous pins.
Pulse-Generated Clocks
Astro supports the use of non-increasing clock edges when defining
pulse-generated clocks. The -edges option of the
create_generated_clock command allows you to define a
pulse clock.
Consider the two clocks shown in Figure 9-4.
Figure 9-4
TIME
10
CLK
1.5 2.5
11.5 12.5
PULSECLK
Here is the Tcl command syntax that defines these two clocks:
create_clock -waveform {0 5} -period 10
-name clock [get_port clock]
create_generated_clock -edges {1 1 3} -name pulseclk
-source [get_ports clock] [get_pins PG/z]
The latency and the duration of the pulse for the pulse clock depend
on the timing from the source point of the master clock to the source
point of the pulse clock. As with all generated clocks, Astro
automatically computes the latency from the master clock to the
pulse-generated clock.
For the clocks defined in Figure 9-4, the latency from the master
clock to the generated clock is as follows:
Clock (Rising) to PulseClk (Rising) 1.5 ns
Clock (Rising) to PulseClk (Falling) 2.5 ns
The waveform definition of the pulse-generated clock is shown in the
output that is generated with the report_clock -attribute Tcl
command.
For report_clock -attribute, the information is as follows:
****************************************
Report : clock
Design : fp
Version: 2007.03
Date
: Thu Feb 1 03:00:48 2007
****************************************
Attributes:
p - Propagated clock
G - Generated clock
I - Inactive
clock
Clock
Period
Waveform
Attrs
Sources
-----------------------------------------------------------------------------clk
10.00 {0.00
5.00}
p
clk
pulseclk
10.00 {0.00
0.00}
p G
PG/z
The waveform definition for the pulse clock is {0 0}, and the period is
10 ns. Therefore the phase relationship between the two clocks is as
follows:
Setup:
Clock -> Pulse-generated Clock : 0 -> 10
Pulse-generated Clock -> Clock : 0 -> 10
Hold:
Clock -> Pulse-generated Clock : 0 -> 0
Pulse-generated Clock -> Clock : 0 -> 0
Logic gates input pin without a timing arc to its output pin
Any pin, such as a boundary output pin, that makes clock tree
traversing stop
Note:
Astro clock tree synthesis reports all ignore pins in the log file.
Review the warnings in the log file carefully. If you find that a
synchronous pin or the clock port of a sequential gate is ignored,
see Clock Tree Sink Pins and Synchronous Pins on page 9-24
for information about how to fix the problems.
Note:
In the Astro CTS flow, Astro clock tree synthesis isolates ignore
pins from its clock tree by inserting a small buffer. Then you use
the pdsHFNOptNet command to fix transition and capacitance
violations for nonclock nets.
In this case, enter the buffers or inverters you want to use in the
Buffers/Inverters box in the Clock Common Options dialog box. If you
do not know the name of the buffers and inverters,
1. Click the Search button next to the Buffers/Inverters box.
The Search Cells dialog box appears.
2. Click Show Buffers/Inverters.
All buffers and inverters appear in the Cell Name List.
3. Click the objects in the Cell Name List to select the buffers or
inverters you want.
4. Click OK.
The selected buffers and inverters appear in the Buffers/Inverters
box in the Clock Common Options dialog box.
Important:
The more buffers and inverters you provided, the better results
and more runtime you might have.
The priority of available buffers and inverters in clock tree synthesis
is as follows:
1. Buffers and inverters entered in the Buffers/Inverters box in the
Clock Common Options dialog box
2. Buffers and inverters defined as clock buffers and inverters by the
astSetClockCell command
3. Buffers and inverters in your libraries, except cells marked as
dont_use
Case 2: You want to use the buffers or inverters with dont_use cell
attributes for clock tree construction.
In this case, enter the buffers or inverters with dont use cell attributes
in the Buffers/Inverters box of the Clock Common Options dialog
box.
The buffers or inverters with dont_use cell attributes might be
interpreted differently by different customers. In some customer
libraries, they are designed for clock tree synthesis only and not used
for logic synthesis or datapath optimization. In other customer
libraries, they are designed for simulation only and not used for real
designs.
To make sure Astro clock tree synthesis uses them for clock tree
synthesis, you must define them as clock cells by using the
astSetClockCell command or specify them in the Buffers/
Inverters box in the Clock Common Options dialog box.
For example, when buffers bufA, bufB, bufC, and bufD are defined in
the library and the dont_use attribute is set for bufA and bufB, the
following cases show how you control which buffers are used for
clock tree synthesis and clock tree optimization.
Case A:
- In the Clock Common Options Synthesis Buffers/Inverters
box, specify bufC and bufD.
- In the Clock Common Options Optimization Buffer Sizing:
LEQ Cells box, specify bufA, bufB, bufC, and bufD.
- No cells are specified with the astSetClockCell command.
Clock tree synthesis uses only bufC and bufD.
Case B:
- In the Clock Common Options Synthesis Buffers/Inverters
box, specify bufC and bufD.
- In the Clock Common Options Optimization Buffer Sizing:
LEQ Cells box, specify bufC and bufD.
- Buffers bufA and bufB are specified with the
astSetClockCell command.
Clock tree synthesis and clock tree optimization use only bufC
and bufD because the buffers defined in the Clock Common
Options dialog box take precedence over those defined with the
astSetClockCell command.
Case C:
- In the Clock Common Options Synthesis Buffers/Inverters
box, no buffers are specified.
- In the Clock Common Options Optimization Buffer Sizing:
LEQ Cells box, no buffers are specified.
- No cells are specified with the astSetClockCell command.
Clock tree synthesis and clock tree optimization use only bufC
and bufD because they are the only buffers without the
dont_use attribute.
Case D:
- In the Clock Common Options Synthesis Buffers/Inverters
box, no buffers are specified.
customer libraries, they are designed for simulation only and are
not used for real designs. For Astro clock tree synthesis to use
them for clock tree optimization, you must define them as clock
cells by using the astSetClockCell command or specify them
in the LEQ Cells box in the Clock Common Options dialog box.
Case 3: You want to limit some of the gates (such as NAND or NOR
gates) in clock tree optimization.
In this case, enter the cells you want to use in the LEQ Cells box in
the Clock Common Options dialog box. If you do not know the name
of the cells,
1. Click the Search button next to the LEQ Cells box.
The Search Cells dialog box appears.
2. Select a pattern in the Cell Pattern box.
3. Click Search.
All cells match the pattern that appears on the Cell Name List.
4. Click the objects in the Cell Name List to select the cells you
want.
5. Click OK.
The selected cells appear in the LEQ Cells box in the Clock
Common Options dialog box.
Delay Cells
Astro clock tree synthesis uses buffers or inverters as delay cells for
delay balance. The tool identifies the buffers and inverters if their
Boolean function is defined in library preparation. If you want to limit
some of them for delay balance only, use the astSetDelayCell
command to define them as delay cells.
By default, Astro clock tree synthesis balances delays with buffers
and inverters that are defined in the Clock Common Options dialog
box, with the astSetDelayCell command, with the
astSetClockCell command, and in the libraries. It is not
necessary to specify all of them explicitly in the Delay Cells box in the
Clock Common Options dialog box (Figure 9-3 on page 9-19) to run
delay balance. However, you might want to use the Delay Cells box
in the following cases:
Case 1: You want to limit some buffers and inverters in delay
balance.
In this case, you enter the buffers and/or inverters you want to use in
the Delay Cells box of the Clock Common Options dialog box. If you
do not know the names of the buffers and inverters,
1. Click the Search button next to the Delay Cells box.
The Search Cells dialog box appears.
2. Click Show Buffers/Inverters.
All buffers and inverters appear on the Cell Name List.
3. Click the objects in the Cell Name List to select the buffers or
inverters you want.
4. Click OK.
The selected buffers and inverters appear in the Delay Cells box
of the Clock Common Options dialog box.
Important:
The more delay cells you provide, the better results and more
runtime you might have.
Case 2: You want to use the delay cells with dont use cell attributes
for delay balance.
In this case, you put the delay cells with the dont use cell attributes
in the Delay Cells entry of the Clock Common Options dialog box.
The priority of delay cells used in delay insertion is as follows:
Dummy Cells
Astro clock tree synthesis uses buffers or inverters as dummy cells
for load balance. The tool identifies the buffers and inverters if their
Boolean function is defined in library preparation.
Note:
When the Dummy Load option in the Clock Common Options
dialog box is selected, Astro clock tree optimization inserts
dummy load with all available buffers and inverters in your
libraries by default. It is not necessary to specify all of them
explicitly in the Dummy Cells box in the Clock Common Options
dialog box to run dummy load insertion. However, you might want
to use the Dummy Cells option in the following cases.
Case 1: You want to limit some buffers and inverters in dummy load
insertion.
In this case, enter the buffers and/or inverters you want to use in the
Dummy Cells box of the Clock Common Options dialog box. If you
do not know the name of the buffers and inverters,
1. Click the Search button next to the Dummy Cells box.
The Search Cells dialog box appears.
2. Click Show Buffers/Inverters.
All buffers and inverters appear in the Cell Name List.
3. Click the objects in the Cell Name List to select the buffers or
inverters you want.
4. Click OK.
The selected buffers and inverters appear in the Dummy Cells
box in the Clock Common Options dialog box.
Case 2: You want to use the buffers or inverters with dont use cell
attributes for load balance.
In this case, you enter the buffers or inverters with dont use cell
attributes in the Dummy Cells box of the Clock Common Options
dialog box.
The priority of dummy cells used is as follows:
Note:
When using a clock configuration files, macros will be connected
to the clock tree level based on the assigned phase delay of the
macros clock pin. The the phase delay is not specified or set to
zero on the clock pin, the macro will be connected to the top level
of the clock tree.
The first word on each line of the clock configuration file is a keyword.
<string:instance_name:pin>
clock_net core/clk
buffer_level bufx12
buffer_level bufx12
buffer_level bufx12
buffer_level bufx12
end_clock_tree
7
11
48
268
buffer_level scivx16 4
buffer_level scivx16 20
buffer_level scivx4 120
buffer_level_pin Top/Inst1/my_t_reg[5]:CKB
buffer_level_pin Top/Inst1/my_t_reg[4]:CKB
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
end_clock_tree
Maximum fanout
Figure 9-5
Note:
The number of delay cells inserted by Astro clock tree synthesis
is not limited by the maximum buffer-level constraint. The longest
path delay in the clock tree becomes the constraint for delay
balance.
The maximum insertion delay and minimum insertion delay you
specify in the Clock Tree Constraints dialog box are based on the
operating conditions you select in the Clock Common Options dialog
box. When the shortest path delay after clock tree synthesis is less
than the minimum insertion delay (when the minimum insertion delay
is greater than zero), clock tree synthesis inserts more delay cells at
the clock root so that the difference to that target value is at a
minimum. When the longest path delay exceeds the maximum
insertion delay (when the maximum insertion delay is greater than
zero), clock tree synthesis stops even if design rule checking
violations exist. As a result, you might encounter DRC violations,
which are reported as warnings in your log file.
When the maximum or minimum insertion delay is zero, clock tree
synthesis does not insert delay padding.
When you select only the Worst operating condition,
minimum < worst-shortest path < worst-longest path < maximum
When you select both the Worst and Best operating conditions, clock
tree synthesis stops when either target is reached.
minimum < best-shortest path < worst-longest path < maximum
When you ignore SDC constraints and insertion delay is 3ns after
clock tree synthesis, clock tree optimization does the following:
Minimum insertion
delay
Maximum insertion
delay
>0
Target fanout
Note:
The units in the commands are the same as those in your
technology file.
Astro clock tree synthesis synthesizes a clock tree so that the
transition delay at any clock port of sequential cells is as close as
possible to the target transition delay.
If a clock has set_clock_transition defined, its transition delay
becomes the target transition delay. Thus, you have the target
transition delay goal for each clock. For clocks without
set_clock_transition defined, their target transition delay is
still set by the default (0.25 ps).
When you achieve the target transition delay goal, you will have
similar timing reports for both ideal clock and real clock.
It is not necessary to know which parameters provide the optimal
results, because the clock tree analyzer searches the optimal
parameter for clock tree synthesis by default.
If you want more control of the synthesis results, turn off the clock
tree analyzer:
axSetIntParam "acts" "CTA" 0
Clock
source
Gating
cell
Gating
cell
Gating
cell
2000
FFs
100
FFs
50
FFs
Clock
source
Gating
cell x 200
Gating
cell x 10
Gating
cell x 5
200 gates
x 10 FFs
= 2000 FFs
10 gates
x 10 FFs
= 100 FFs
5 gates
x 10 FFs
= 50 FFs
2. You need to mark the clock gating cells as LEQ cell in the
reference library using the defineLEQCell command. For
example,
defineLEQCell "GCELL8" "GCELL12"
defineLEQCell "GCELL8" "GCELL4"
defineLEQCell "GCELL8" "GCELL16
3. Define the dont use and dont touch settings for the gating cells
in the design library.
astSetDontUse "GCELL12" #f
astSetDontUse "GCELL8" #f
astSetDontUse "GCELL4" #f
astSetDontTouch "GCELL12" #f
astSetDontTouch "GCELL8" #f
astSetDontTouch "GCELL4" #f
6. Enter the name of the file you created in steps 1 through 5 in the
Clock Gated Cells File Name box.
7. Select the Conditions and Optimization options for your design.
2. Leave the Clock Net Name(s) box blank or enter the clock net
names.
Note:
When the Clock Net Name(s) box is blank, the command
processes all clocks defined in SDC.
3. Select Fix.
4. Select Flip Flops Only.
5. Click OK or Apply to accept your changes.
Setting this switch to 1 excludes any variable routing rule on the leaf
nets. Instead, the default width and spacing specified in the
technology file will be assumed and no shielding will be applied for
those leaf nets either. Leaf nets usually are the nets that connect to
one or more clock port. This switch is 0 by default.
For example, if you set the default route rule to 1, your variable route
rule does not apply to the leaf nets, if you set the default route rule to
0, your variable route rule does apply to the leaf nets.
axSetIntParam "acts" "set default route rule on bottom \
level" n
This rule applies to the buffer level only, not to the gate level. It
excludes any variable routing rule for the bottom n level of nets for
each gate level. The default width and spacing specified in the
technology file will be assumed, and no shielding will be applied for
the bottom n level of nets for each gate level. This switch is 0 by
default.
Sample Flow
If all nets in your clock tree have the same special routing rule and
you want to propagate the rule downstream to all the clock nets in
the tree except the leaf nets, do the following:
1. Define a variable routing rule by using the axgDefineVarRule
command.
2. Assign the variable routing rule to the root clock net by using the
axgSetNetConstraint command.
3. Propagate the rule in the clock tree by using the
astMarkClockTree command.
5. Run clock tree synthesis (astCTS), and, optionally, run clock tree
optimization (astCTO).
6. Route the clock nets by using the axgRouteGroup command.
2. To delete all clock trees, leave the Root Clock Net Name(s) entry
blank. (To delete a specific clock net, specify a clock net name.)
When the Root Clock Net Name(s) box is blank, the command
deletes all buffers and an even number of inverters in the clock
trees defined in SDC.
3. Select Detect Buffer/Inverter Automatically.
You must select the Detect Buffer/Inverter Automatically option to
delete all clock trees including those inserted by other tools.
4. Click OK or Apply to accept your changes.
Note:
By default, this command only deletes the clock trees inserted by
Astro clock tree synthesis.
This command deletes only buffers and even numbers of inverters in
each clock tree. If you find some buffers or pairs of inverters that are
not deleted, they might be marked as fixed or dont touch or they
might be connected to dont touch nets. You can use the
astMarkClockTree command to reset those attributes and delete
them again.
Use the astClockBrowser command, as described in Viewing
Clock Structures in the Design on page 9-14, to report the clock
structure and clock summary. This command does not report these.
likely, clock tree synthesis was traced to the nets that had been
prerouted and then Astro performed the synthesis, which is not the
expected behavior.
To prevent this problem, clock tree synthesis now stops at the
specific net (providing its not the root clock net) and issues the
following warning:
CTS-Warning: no clock tree synthesis on routed net Net_Name
When you see this warning, you can remove the clock tree and its
corresponding routing before you run clock tree synthesis. This
behavior applies not only to the root clock net but also to specific nets
or partial nets that are being routed.
32 } \
16 } \
CLK1
CLK2
Group A
Group B
In this situation, Astro clock tree synthesis can construct the clock
trees in two ways.
Note:
Using nested create_clock commands is not recommended.
Replace the second create_clock definition with a
create_generated_clock definition.
Clock Tree
Clock
source
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF
2. Select the options you want in the Clock Tree Synthesis dialog
box.
The options are described in the sections following this
procedure.
3. Click OK or Apply.
By default, Astro clock tree synthesis synthesizes clock trees under
the worst-case operating condition. Its function is to minimize global
skew under user-specified timing constraints.
After running clock tree synthesis, you get the following results:
A buffer tree for each clock net. The driver of the buffer tree is a
preexisting cell or the clock source in your clock tree. There is no
buffer tree added to the small net if the driving strength of the
preexisting cell is strong enough.
The connected power and ground for all inserted buffers and/or
inverters. There are no power and ground connections if your
design has more than one power line.
The same routing rules you defined before clock tree synthesis
on all newly created nets. When a buffer is added to a net, a new
net is created at the buffers output side. The new net inherits all
the routing rules of the original net (the input net).
Table 9-5
Skew result
clock tree synthesis condition
Best
Worst
Best
51
182
Worst
216
116
66
145
When clock tree synthesis synthesizes the clock tree in the worst
case only, it minimizes the skew in the worst case to 116, but the
skew in the best case becomes 216even larger than the skew in
the worst case. When the clock tree is synthesized in both the best
case and the worst case simultaneously, skews in both the best case
and the worst case are optimized.
Note:
When you select both best and worst cases, the runtime of
synthesis might increase.
Local skew clock tree synthesis constructs clock trees in a way that
puts the sequential cells with logic relationships under a common
subtree. As a result, the skew due to on-chip variation is minimized
by this kind of clock tree.
Before running clock tree synthesis with local skew, make sure
Note:
The last requirement is not necessary for global skew clock tree
synthesis.
To synthesize clock trees with local skew,
1. Enter the astCTS command or choose Clock > Clock Tree
Synthesis Clock Tree Synthesis.
The Clock Tree Synthesis dialog box appears.
2. Select the skew type Local.
3. Click OK or Apply.
Note:
When Astro clock tree synthesis runs in global skew mode, it
processes only the clock pathsnot the datapaths. This is the
main reason that global skew clock tree synthesis uses less
memory and runtime than local skew clock tree synthesis.
Useful Skew
Slack 1 -> 0
Slack 1 -> 0
F1
F2
2 -> 1
F3
T=5
CLOCK
5 ns
period
In this example, the clock period is 5 ns. Between the first and third
flip-flops, there are two clock periods of 10 ns. When the clock is built
with zero skew, it arrives at the flip-flops at the same time. This
constrains the first and second flip-flop path as well as the second
and third flip-flop paths to 5 ns. However, the logic between the first
and second requires only 4 ns, whereas the logic between the
Chapter 9: Clock Tree Synthesis and Clock Tree Optimizations
9-70
second and third requires 6 ns. Therefore, the circuit fails. But if you
intentionally skew the clock by decreasing the arrival time of the
clock by 1 ns, the first part of the circuit is constrained to 4 ns and the
second part to 6 ns and the design meets timing.
In a simple test case (12K standard cells, RAM, ROM, PLL, 10
clocks, 200 MHz), the following results were achieved:
Note:
The clock tree synthesis algorithm that you select applies to all
clock trees. You cannot select the clock tree synthesis algorithm
on a per-clock basis.
Top-level clock tree synthesis performs clock tree global planning
based on the floorplan and distribution of synchronous pins before
construction of clock trees. The astCTS command Top mode
detects buffers that are placed far away from the desired location and
attempts to place the buffers in the corrected routing topology.
Note:
The astCTS command Top mode is enhanced to improve QOR
for clock tree synthesis in most designs by allowing buffer
insertion and flexible space buffer insertion. You can invoke the
previous Top mode behavior by setting the following parameter:
axSetIntParam "acts" "length fixed buffer insertion on
top" 1
The other settings in the Clock Tree Synthesis dialog box as well as
the settings for the Clock Common Options dialog box remain the
sameyou can follow the normal Astro clock tree synthesis flow
when performing top-level clock tree synthesis.
To synthesize clock trees with the Top option,
1. Enter astCTS or choose Clock > Clock Tree Synthesis Clock
Tree Synthesis.
The Clock Tree Synthesis dialog box appears.
2. Select Top.
3. Click OK or Apply.
Sample Flow
If special routing rules are to be used, they should be taken into
account when you insert the clock trees so that the consistency of
RC estimation and the extraction between prerouting and
postrouting is maintained. Follow these steps:
1. Set Skew Control in the Route Common Options dialog box. Use
the axgSetRouteOptions command.
Cell fixed
2. Leave the Clock Net Name(s) box blank or enter clock net names.
3. Select Reset Dont Touch and click Apply.
4. Select Unfix and Clock Tree Only.
5. Click OK or Apply.
Buffer Sizing
Astro clock tree synthesis constructs clock trees with a single type of
buffer for each buffer level. Different buffer levels might have different
types of buffers. The buffer sizing optimization function varies the
size of the buffers in the inserted clock trees, to improve both clock
skew and clock insertion delay.
If you want the same buffer type in each buffer level, to minimize the
skew due to on-chip variations, deselect the Buffer Sizing option in
the Clock Tree Optimization dialog box.
The buffers and inverters used in buffer sizing are the logically
equivalent cell lists extracted by the tool. However, you can use Astro
clock tree synthesis to limit some buffers and inverters in the logically
equivalent cell lists by doing the following:
List the buffers and inverters in the LEQ Cells box in the Clock
Common Options dialog box.
For detailed information about logically equivalent cells for clock tree
optimization, see Setting Clock Tree Synthesis Common Options
and Preparing Clocks on page 9-18.
Buffer Relocation
Astro clock tree synthesis performs buffer placement with all the
features of Astro OVthe Astro placement enginesuch as
Overlaps removal
When you select the Buffer Relocation option in the Clock Tree
Optimization dialog box, the buffer relocation optimization function
improves clock skew and clock insertion delay.
Except for considerations of runtime, there is no reason not to use
buffer relocation.
Gate Sizing
The gate sizing optimization function changes the size of preexisting
cells, as well as buffers inserted by the astCTS command, in your
clock trees to improve both clock skew and clock insertion delay.
If you do not want Astro clock tree synthesis to change the cell type
of preexisting cells, deselect the Gate Sizing option in the Clock Tree
Optimization dialog box.
The cells used in gate sizing are the logically equivalent cell lists
extracted by the tool. However, you can use Astro clock tree
synthesis to limit some cells in the logically equivalent cell lists by
doing the following:
List the cells in the LEQ Cells box in the Clock Common Options
dialog box.
For detailed information about logically equivalent cells for clock tree
optimization, see Setting Clock Tree Synthesis Common Options
and Preparing Clocks on page 9-18.
Gate Relocation
If you select the Gate Relocation option in the Clock Tree
Optimization dialog box, the gate relocation optimization function
improves clock skew and clock insertion delay by physically moving
gates close to flip-flops.
Level Adjustment
If you select the Level Adjustment option in the Clock Tree
Optimization dialog box, the level adjustment optimization function
improves clock skew and clock insertion delay.
Note:
If the skew is improved by adjustment of a pin to its upper or lower
logically equivalent net, it means that the pin was connected to a
bad point during the clock tree construction. This might happen if
the delay estimation at the pin was incorrect. In other words, if
you find no improvement during level adjustment optimization, it
doesnt mean that this function doesnt work.
Reconfiguration
If you select the Reconfiguration option in the Clock Tree
Optimization dialog box, the reconfiguration optimization function
improves clock skew and clock insertion delay. The reconfiguration
optimization function is a reclustering function, which requires more
runtime, because buffer placement must be performed after
reclustering.
This function is deselected by default.
Important:
Select this function if you want more improvement for small clock
trees.
Delay Insertion
If you select the Delay Insertion option in the Clock Tree Optimization
dialog box, the delay insertion optimization function improves clock
skew. Delay insertion is for low-fanout nets where no clock tree is
inserted.
The delay cells used in delay insertion are buffers and inverters
extracted by the tool. It is recommended that you prepare some
delay cells in your libraries and define them as delay cells, using the
astSetDelayCell command. The priority of delay cells used in
delay insertion is as follows:
For detailed information about delay cells for clock tree optimization,
see Setting Clock Tree Synthesis Common Options and Preparing
Clocks on page 9-18.
is equivalent to
useful_skew_opt -buffer_insertion
Any other option that you specify by itself disables the default
buffer insertion. For example,
useful_skew_opt -level_adjustment
or
useful_skew_opt -buffer_sizing_n_insertion
the tool selects buffer insertion and ignores sizing because the
latter can only be applied alone.
When you use the useful_skew_opt Tcl command, the ideal
worst negative slack (WNS) is reported in the log. This is the upper
bound of the WNS that can be reached in an ideal environment. Here
is a sample excerpt from the log:
USK: finishes useful skew scheduling with 2 iterations and
WNS -0.321439.
options. These two options can also define the effort level to be used
for setup and hold time violation fixing. The default for both setup and
hold time is 0.
If you want to relax hold time fixing, set the hold target to a very large
value (larger than any expected number of path violations). For
example, a -hold_target setting of 100 ns specifies that hold
time violations be ignored, while a -hold_target setting of 0.5 ns
specifies that the useful skew optimization engine direct more effort
toward setup time violation fixing.
Furthermore, you can use the -low and -high options to limit
optimization to pins that have slack between the [low high]
bounds. The number value specified with -low and -high refers to
setup slack (not the same as using the -setup_target option).
When you use the buffer sizing options (-buffer_sizing and
-buffer_sizing_n_insertion), a CPU runtime penalty is
expected for large designs due to the recursive approach. In this
case, you can choose to control the CPU runtime with -cpu_time,
specifying CPU time in hours.
Additional useful_skew_opt command options are described as
follows:
If you want to control the ECO route settings, you can skip the
automatic ECO routing step and invoke ECO routing manually by
doing the following:
1. Prevent the automatic ECO route after postrouting clock tree
optimization by entering
define acoSkipECORoute 1
ECO clock tree synthesis searches for an optimal level in the clock
tree for the new flip-flops. When the flip-flops are not the spare cells,
ECO clock tree synthesis searches for an optimal location for them.
Data
Use the Data page to load the clock tree data. You can then
manipulate the data interactively from the hierarchical clock tree
to the layout and the layout to the hierarchical clock tree.
Info
Use the Info page to report skew and path information by using
options to generate your report criteria, such as shortest/longest
paths, fastest/slowest top paths, clock overlap domains, and
delay information.
Under Node, you can select Phase Delay to show the phase
delay information for the ports shortest and longest path output
for each clock tree node in the order of worst condition, typical
condition, and best condition. As a result, you do not need to quit
the ctiCTS command to perform skew analysis to show the tree
nodes phase delay.
Browse
Use the Browse page to select and deselect various levels of a
clock tree, including all its child and leaf cells.
Cross-Probe
Use the Cross-Probe page to cross-probe between the physical
layout and the logical clock tree hierarchy.
Constraint
Use the Constraint page to query or set the SyncPin/ignore_tns
status for a clock pin.
ECO
Use the ECO page to perform ECO placement processes,
including adding cells before or after a specified reference node,
deleting buffers or inverter pairs, reparenting selected cells to a
designated node, and final ECO placement.
You can click Cancel to close the Interactive CTS dialog box.
To quickly display flylines for the entire tree, use the Browse page:
Click Select FFs, Select Buffers, Select Inverter Pairs, and so forth.
Then use the Cross-Probe page: Select output and click Highlight.
The entire tree appears with the levels displayed in various colors.
Cell delay from an input pin to an output pin and wire delay from
an output pin to an input pin
Note:
The phase delay at a pin is the longest and shortest path delay
from the pin to its transitive clock sink pins.
To obtain a clock timing report,
1. Enter astClockTiming or choose Clock > Reports Clock
Tree Timing.
The Clock Tree Timing Report dialog box appears.
2. In the Clock Names box, enter the names (root clock pin names
or net names) of the clocks for which skew information is to be
reported.
To specify that skew analysis is to start from an intermediate net
of the clock tree, enter the name of the net along with the clock
domain. For example, if you enter my_net(my_clock), the skew
analysis will start from my_net in the clock structure.
Note:
Do not use clock names with (" and ") special characters. For
example, for a clock name of (my_clock), do not use
my_net((my_clock)).
3. Select an operating condition (Worst, Typical, or Best).
4. Specify the type of clock skew to be analyzed and reported
(Global Clock Skew, Local Clock Skew, and Inter Clock Skew).
The default is to generate a global clock skew report. The global
clock skew is the maximum difference of clock arrival times
between any two flip-flops in a design.
Under Global Clock Skew, you can select one or more of the
following:
- Detailed Report Reports all pins in the clock tree, with global
skew sorted.
- Pulse Width Reports the active pulse width rather than the
required value.
- Skew Group Reports the rise and fall delays separately.
For descriptions of all the astSkewAnalysis command
options, see Physical Implementation Online Help.
5. Click OK or Apply.
The clock skew report contains the following four comparison
categories:
Unate state at the input port and the clock source are the same,
and the clock output signal is rising.
Unate state at the input port and the clock source are the same,
and the clock output signal is falling.
Unate state at the input port and the clock source are inverses,
and the clock output signal is rising.
Unate state at the input port and the clock source are inverses,
and the clock signal is falling.
Note:
When the detailed report does not contain enough information,
you can also try
astDumpClockTiming "fileName" "clockName"
See Figure 9-8 and Figure 9-9 for examples of global and local skew
reports.
Figure 9-8
Figure 9-9
2. In the Net File Name box, enter the name of the file for
high-fanout nets.
3. Select the options or keep defaults.
4. Click OK or Apply.
Basically, the astHFCTS command performs clock tree synthesis.
Like astCTS, it uses most of the settings in the Clock Common
Options dialog box. The astHFCTS command is different from clock
tree synthesis in the following ways:
Except for these differences, all the settings for clock tree
synthesisand the settings in the Clock Common Options dialog
box, such as the constraints and buffers to be usedare necessary
for high-fanout net synthesis. For more details on other settings, see
Setting Clock Tree Synthesis Common Options and Preparing
Clocks on page 9-18.
Note:
The astHFCTS command cannot be run on a net within a logical
hierarchy unless the net has a clock definition.
10
Routing
10
After you place your design and run clock tree synthesis, and
optimize before and after clock tree synthesis, you are ready to route
your design. Routing includes global routing, track assignment,
detail routing, and search-and-repair.
This chapter contains the following sections:
Routing Flow
Routing Considerations
10-1
Routing Flow
Routing includes the global routing, track assignment, detail routing,
and search-and-repair phases. You can run these routing phases by
using the axgAutoRoute command or by using alternative routing
commands (axgGlobalRoute, axgAssignToTracks,
axgDetailRoute, and axgSearchRepair).
The axgAutoRoute command simplifies the routing flow, and in
most cases, it is recommended that you use axgAutoRoute in
default mode, where the global routing, track assignment, detail
routing, and search-and-repair processes are run sequentially in one
step. You can use the axgAutoRoute command or the alternative
commands to customize the design flow. For example, you might
want to run optimization after track assignment, or break up the flow
for designs with long runtime.
The axgAutoRoute command is described in Performing
Automatic Routing on page 10-25. The axgGlobalRoute,
axgAssignToTracks, axgDetailRoute, and
axgSearchRepair commands are described in Using Alternative
Routing Commands on page 10-46.
After routing is completed, you can run wire length and via
optimization by using the axgRoutOpt command, as described in
Reducing Wire Length and Via Count on page 10-38.
Optimizations for global routing, track assignment, and detail routing
are described in Chapter 11, Postrouting Optimization.
Astro optimizes memory usage during routing by splitting
timing-driven global routing jobs and timing-driven track assignment
jobs into a router process and a timer process, under the following
conditions: when the job is run on a 32-bit machine and the number
Routing Flow
10-3
To postrouting optimization
Routing Considerations
Following are points for you to consider and data to prepare before
you run the commands to route your design.
Routing Considerations
10-5
Preroutes
When a wire is prerouted, Astro checks to see whether it is
completely connected. If the net is completely connected, Astro
treats the net as a blockage; if the net is partially connected, Astro
connects all parts of the net. Keep in mind that
The net-based routing rule table can be removed from the current
cell by using the ekDeleteNetRoutingRuleTabInfo command,
and you can write the table to an ASCII file by using the
ekDumpNetRoutingRuleTabInfo command. For more
information about the net-based routing rule table commands, see
Physical Implementation Online Help.
Routing Considerations
10-9
Routing Considerations
10-11
Table 10-1 shows the commands you can use to set, edit, and get
information about variable routing rules for specific nets.
Table 10-1 Commands Pertaining to Variable Routing Rules
Task
Command
axgDefineVarRule or
dbDefineVarRouteRule
dbDumpAllVarRouteRules
dbDeleteAllVarRouteRules
axgSetNetConstraint
geQueryNetConstraint
You should specify variable routing rules for the root clock net in your
design before running clock tree synthesis. Clock tree synthesis
propagates the rules attached to the parent net to all the daughter
nets created during clock tree synthesis or clock tree optimization.
Alternatively, clock tree synthesis produces a file of nets for the nets
it creates (the default file name is net.acts). You can use this file to
determine which nets are part of the clock network. Make sure you
Routing Considerations
10-13
2. Next to Rule Name, enter the name you want for the set of rules
you are defining.
After you enter the rule name, you can click Get to update all the
data boxes.
3. For shielding,
- Select Shield associated nets to apply shielding width and
spacing rules for nets assigned this variable routing rule.
Routing Considerations
10-15
2. Next to Net Name, enter the name of the nets for which you are
assigning variable routing rules.
3. Under Assign,
- Select MinMax Layer and enter a number that corresponds to
the minimum layer and maximum layer constraint you want to
assign to the named nets. When you click the small box to the
right of the data entry boxes, the Edit Layer Panel dialog box
appears, from which you can select a layer number.
- Select Timing-Driven Spacing to assign timing-driven spacing
controls to the named nets. This means that when crosstalk
problems occur around a named net or the intra-layer coupling
capacitance of the net is too high, Astro moves the net away
from other nets and avoids placing long, parallel wires next to
the net.
- Select Top Layer Probe to assign top-metal-layer routing
constraints to the named nets so that the top-layer segment of
the nets can be used for probing purposes.
You can choose the following:
- AnyPort (the default) to specify that a net needs to reach the
top layer only once and that location does not matter (for signal
probing only).
- Outport to specify that only the output pin on a net needs to
reach the top layer (useful for disconnecting the driving pin of
a net).
- AllPort to specify that every pin on a net needs to reach the top
layer (useful for disconnecting any pin from the net).
4. Click OK or Apply.
Routing Considerations
10-17
Skew control increases the wire length slightly but should not
significantly affect the routability of your design.
It is recommended that you enable skew control when you
don't want to do timing-driven global routing (skew control has
an indirect effect on timing).
Note that skew control for clock nets occurs only when the
balanced clock routing style is enabled (the default is on).
- To enable incremental global routing, select Incremental
(under Global Routing).
Astro uses the global routes already created for nets during an
earlier global routing run as a guide to maintain similar
patterns. For more information, see Running Incremental
Global Routing on page 10-32.
3. Click OK or Apply.
Make sure the location of the pseudo pins is accessible to the router.
Do not specify coordinates that are located in blockage areas. The
coordinates are in user-defined units.
When you define a pseudo pin and select balanced (next to Clock
Routing) in the Route Common Options dialog box, Astro treats the
pseudo pin as the driving pin of the net. The router connects all input
pins to the pseudo pin in a balanced style and then makes a direct
connection from the pseudo pin to the actual driver. The routing
conforms to wire-to-wire and via rules, variable routing rules, and
layer and cost controls. (The Route Common Options dialog box is
shown in Figure 10-2 on page 10-19.)
You can generate a report for all the nets with pseudo pin constraints
by using the axgDumpPseudoPinConstr command. The syntax is
axgDumpPseudoPinConstr "filename"
Using axgRouteGroup
To route a group of nets,
1. Enter axgRouteGroup or choose Route > Route Net Group.
The Route Net Group dialog box appears.
One initial routing phase, where all the unconnected nets are
routed
One or more rip-up and reroute phases, where for a selected set
of nets, the routing results from the previous phase are deleted
and nets are rerouted to reduce the congestion
2. Make sure the global, track assign, and detail phases are all
selected. The default is all three.
For details about these phases, see
- Global Routing on page 10-27.
- Track Assignment on page 10-33.
- Detail Routing on page 10-36.
3. Next to Search Repair Loop, enter the number of times to perform
incremental search-and-repair. (You can disable
search-and-repair by entering 0.)
4. Specify the global routing speed by selecting one of the following:
- prototype, which runs only initial global routing
- fast, which runs initial global routing and one rerouting pass
- medium, which runs initial global routing and four rerouting
passes (this is the default)
- slow, which runs initial global routing and eight rerouting
passes
5. Next to Save After Phase, select one or more options (global,
track assign, detail) to specify that the design be saved after the
global routing, track assignment, and detail routing phases.
6. Select Distributed Routing to use the distributed routing feature.
Your network must be properly setup before running this option
(see Using Distributed Routing on page 10-52). Also, enter the
number of CPUs that Astro can use (a value of 0 or 1 disables
distributed routing and Astro uses a single CPU).
7. Click OK or Apply.
Global Routing
Global routing maps general pathways through the design for each
unrouted net (signal nets and clock nets). The global router uses a
two-dimensional array of global routing cells to model the demand
and capacity of global routing. Astro uses the average height of the
standard cells to create the height and width of each global routing
cell.
During global routing, Astro assigns nets to the global routing cells
through which they pass. For each global routing cell, the routing
capacity is calculated according to the blockages, pins, and routing
tracks inside the cell. Although the nets are note assigned to the
actual wire tracks during global routing, the number of nets assigned
to each global routing cell is noted. Astro calculates the demand for
wire tracks in each global routing cell and reports the overflows,
which are the number of wire tracks still needed after Astro assigns
nets to the available wire tracks in a global routing cell.
Astro might reduce overflows by detouring nets around congested
areas and increasing the wire length. You can examine the global
routing report that appears in the command window and display
congestion maps to help you decide whether your design can be
routed. See also Displaying Global Routing Congestion Maps on
page 10-30.
The global router considers spacing and wide-wire variable routing
rules, as well as shielding variable routing rules, when calculating
congestion.
The design should have the delay tables that are needed to calculate
the estimated RC. If no delay tables exist, you need to set extra cost
for all layers. While in the RC optimization-by-net-length mode for
nontiming-driven global routing, Astro interprets these settings as
the estimated RC value for each layer. If you do not set extra cost for
layers and the design does not have any delay tables, the RC
optimization-by-net-length mode is not triggered.
To specify that the RC optimization-by-net-length mode not be
triggered, enable the ignoreRCOptByLength parameter by
entering the following syntax:
axSetIntParam "groute" "ignoreRCOptByLength" 1
Incremental global routing uses the global routes already created for
nets during an earlier global routing run as a guide to maintain
similar patterns. If a new net is created because of netlist changes,
the global routing pattern of the parent net is used to route the new
net.
Track Assignment
Before running the detail router, run track assignment to specify
which tracks within each global routing cell are to be used for each
net. Track assignment operates on the entire design at once; it can
make long routes straight and reduce the number of vias, whereas
the detail router routes a small area at a time. Track assignment
accounts for large vias that need more tracks than the wire to which
they are connected.
After track assignment finishes, all nets are routed, but not very
carefully. There are many violations, particularly where the routing
connects to pins. The detail router works to correct the violations.
M1 300000 M3 200000
M1 250000 M2 280000 M3 300000
M2 300000
where NetA is the net name, M1 is the layer name in the technology
file, and 300000 is the length limit in the user unit. Each net must
have its own line in the trackAssignNetLLL.file.
For all the nets in the design that need layer length limits, except the
ones described in the trackAssignNetLLL.file, set parameters, as
shown in the following sample commands:
axSetIntParam "trackAssign" "m0LayerLengthLimit" 200000
axSetIntParam "trackAssign" "m1LayerLengthLimit" 350000
.
.
.
axSetIntParam "trackAssign" "m12LayerLengthLimit" 300000
Detail Routing
Detail routing uses the general pathways suggested by the global
routing and track assignment processes to route the nets (paths and
contacts).
For a design with off-grid pins, you can set the maxOffGridTrack
parameter to help resolve DRC violations as they are worked on
during detail routing with search-and-repair. You can manually cycle
Chapter 10: Routing
10-36
Search-and-Repair
After the detail routing phase, you can run incremental
search-and-repair routing passes. During these routing passes,
Astro searches for DRC violations and reroutes wires in an effort to
avoid violations. The Astro router does not add metal stubs on frozen
nets to fix DRC violations even when the nets have DRC violations.
You can perform search-and-repair by running the axgAutoRoute
command in detail routing mode. Simply select the detail phase in
the Auto Route dialog box (Figure 10-3 on page 10-26) and enter the
number of times to perform incremental search-and-repair.
Alternatively, you can perform search-and-repair with the
axgSearchRepair command, as described in
Search-and-Repair on page 10-50.
You can also use geNewFillNG command to fill notches and gaps,
but this command does not check 90-nm rules. To use
geNewFillNG, make sure ignore, next to Same Net Notch, is
deselected in the Route Common Options dialog box. The
geNewFillNG command fills notches and gaps that are smaller
than the minimum distance allowed between objects of the same net
on the same layer. It generates notch-and-gap-filling information that
is stored in the FILL view cell and can be used when you translate
your design data to GDSII format with the auStreamOut command
(with fill options selected).
For descriptions of the geNewFillNG command options, see
Physical Implementation Online Help.
Shielding Nets
You can shield routed nets with axgAutoShieldRoute or by using
the Shield Net option in the Quick Signal Route dialog box
(axgQuickSignalRoute). Because these commands only
generate shielding wires that do not cause DRC violations, whenever
Chapter 10: Routing
10-40
there might be DRC violations, the target net might not be shielded.
The router attempts to drop as many contacts as possible between
the shielding wires and power and ground preroutes. Shielding is
added after detail routing is performed.
The axgAutoShieldRoute command uses shielding rules defined
with axgDefineVarRule (see Defining Variable Routing Rules on
page 10-13); whereas, the shielding option for quick signal routing
uses default spacing rules. Use axgAutoShieldRoute because
you get the benefit of Astro honoring the shielding rules during clock
tree synthesis.
Global Routing
The axgGlobalRoute command considers spacing and wide-wire
variable routing rules, as well as shielding variable routing rules,
when calculating congestion.
Track Assignment
To perform track assignment,
Detail Routing
To perform detail routing,
1. Enter axgDetailRoute or choose Route > Detail Route
Detail Route.
The Detail Route dialog box appears.
Search-and-Repair
After detail routing, you can run incremental search-and-repair
routing passes. During these routing passes, Astro searches for
DRC violations and reroutes wires in an effort to avoid violations. The
Astro router does not add metal stubs on frozen nets to fix DRC
violations even when the nets have DRC violations.
To perform search-and-repair,
1. Enter axgSearchRepair or choose Route > Detail Route
Detail Route Search & Repair.
The Search & Repair dialog box appears.
11
Postrouting Optimization
11
11-1
The default is -1. You can specify that the processes always be split,
rather than spit depending on internal criteria, by setting a value of
1. To specify that they not be split, set a value of 0.
Astro uses topology-based optimization, which interacts with
placement and routing. For more information, see Topology-Based
Methodology on page 8-74.
If you want to control the delta value used in reporting the slack
histogram, use the pds_histogram_delta_value parameter
with the define command. For example, enter
define pds_histogram_delta_value 0.02
With a delta value defined, the histogram starts from the target slack
value, steps to the worst negative slack (WNS), and stops at the
smallest slack before reaching the WNS. For example, if the target
slack is 0.1, the delta value is 0.02, and the WNS is -0.075, the top
slack in the histogram will be -0.06 (because the step to the WNS is
-0.08, which is less than -0.075). In this case, where the
pds_histogram_delta_value is defined as 0.02, the following
sample histogram report is printed:
PDSHIST: Total Paths = 29
PDSHIST: Total Negative Slack Paths = 22
PDSHIST: User defined delta value: 0.02
PDSHIST:
Slack
Paths
Target=0.1000
PDSHIST:
-0.06
x
PDSHIST:
-0.04
x
PDSHIST:
-0.02
x
PDSHIST:
0.00
x
PDSHIST:
0.02
x
PDSHIST:
0.04
x
PDSHIST:
0.06
x
PDSHIST:
0.08
x
PDSHIST:
0.1000
x
Inverter-Only Optimization
You can use an inverter-only (that is, no buffers) library set and
perform inverter-only prerouting and postrouting optimization
(without making use of any buffers). The inverter-only algorithms are
included in the astPostRouteOpt command, as well as the
astAutoPlace command and topology-based stand-alone
optimization commands, such as astTopoHold, astTopoSetup,
astTopoTransCap, and astFanoutSetup.
To perform inverter-only optimization, you must set the
inverter_mode parameter to 1. For example, enter
axSetIntParam "pds" "inverter_mode" 1
If your reference libraries have buffers, make sure you assign the
dont_use attribute to all of them before you run optimization
processes, using the astSetDontUse command. The syntax is:
astSetDontUse objectName #t
Astro does not check whether the size and pin location are
identicalyou must guarantee this. Astro checks that cells defined
as footprint equivalent belong to the same LEQ class.
Note:
It is recommended that crosstalk constraints be ignored during
power recovery at the postrouting stage. This approach is
recommended because the crosstalk cost function is pessimistic
compared to full-blown crosstalk analysis, which could produce
long runtimes and lower QoR.
Because the number of footprint-equivalent cells is usually less than
the number of logical-equivalent cells, footprint-based power
recovery should have lower runtimes than power recovery based on
logical equivalence.
You define footprint equivalence with the
defineFootPrintEQCell command. The syntax is
defineFootPrintEQCell "cell1" "cell2"
Using axgAdvRouteOpt
The axgAdvRouteOpt command optimizes timing and crosstalk
the design must be fully routed and include the necessary timing
information. Advanced postrouting optimization calls the timer to
analyze the critical paths and then the optimization uses various
techniques to improve timing and minimize crosstalk problems. It
attempts to fix the crosstalk problems by using spacing controls and
layer adjustment as well as buffer insertion and gate sizing. For more
information, see Fixing Crosstalk With axgAdvRouteOpt on
page 15-56.
The axgAdvRouteOpt command uses built-in, quick extraction.
The extraction is approximately 5 percent more pessimistic than the
normal Astro postrouting extractiontherefore, you should run
axgAdvRouteOpt before astPostRT. (The preferred methodology
is to use axgAdvRouteOpt after astPostRouteOpt.)
To run advanced postrouting optimization,
1. Enter axgAdvRouteOpt.
The optimize effort means that the router tries to improve the
slack timing based on the slack target. The preserve effort
means that the router ignores the slack target setup and
attempts to not make the slack timing any worse than the
existing result during the optimization process.
- Use the Optimization Operations area to choose the types of
fixing to be performed, including buffer insertion and bypass
and gate sizing. You can also instruct the router to reduce the
intralayer coupling capacitance on the critical path.
- Next to Search & Repair Loop, enter the number of search and
repair loops to run after the optimization to clean up the
remaining DRC violations. The default is 5.
- Next to Run Time Limit (min), specify the number of minutes
Astro can perform the in-routing optimization process. A value
of 1 (the default) means no time limitation.
- Select Skip ECO Routing to specify that the axgAdvRouteOpt
command does not perform DRC fixing or search and repair.
The default is off.
- Select Rerun Timer after finished to specify that the timer is
called to check the timing of the design.
3. Click OK or Apply.
You might want to fix crosstalk noise only, without buffer insertion,
using axgAdvRouteOpt. To do so, select Crosstalk Noise
Constraints and R/C Reduction. Also, adjust the setup effort
setting when you want to fix crosstalk only, besides preserving
timing.
Note:
Running in this mode can be useful at the end of the design
flow, when you might need to run minor routing steps on a
design that already meets timing and crosstalk requirements.
The additional routing steps must consider crosstalk to be able
to prevent the creation of new crosstalk violations.
Using astPostRT
The astPostRT command optimizes setup, hold, transition, and
capacitance constraints on a routed design. (These optimizations
are similar to postplacement optimizations.)
The astPostRT command makes small, localized changes to the
routing, working to repair timing violations that remain after the
design is fully routed. Such changes include cell sizing and buffer/
inverter insertion.
To run postrouting optimization,
1. Enter astPostRT.
The Post-Route Optimization dialog box appears.
12
Design Finishing and Interactive Changes12
After routing and postrouting optimization, you can optimize contacts
and perform design finishing processes to improve the reliability of
your design. You can also make interactive routing changes.
This chapter contains the following sections:
Optimizing Contacts
Optimizing Yield
12-1
Using Edit-In-Place
Optimize contacts
axDrouteOptimizeContact
or
axgOptimizeContact
Optimizing Contacts
The axDrouteOptimizeContact and axgOptimizeContact
commands replace the specified single-cut via or ContactCode with
a multiple-cut via array or a different ContactCode that has the same
metal layer. You can specify multiple target vias for one via type;
Astro tries all the target vias in the order specified. These commands
work on all the nets except the frozen nets. For
axgOptimizeContact, the default is to replace vias on all the nets,
but you can also specify particular net names for via optimization.
Optimizing Contacts
12-3
Optimizing Contacts
12-5
Using axDrouteOptimizeContact
The axDrouteOptimizeContact command (no GUI) performs
the same functionality as axgOptimizeContact, with the
exception of not having the capability to specify particular nets for via
optimization.
The syntax is
(axDrouteOptimizeContact "cellId"
((fromContactName toContactName
) #t|#f 1
cellId
toContactSize)...)
fromContactName
toContactName
toContactSize
#t
#f
Using axgOptimizeContact
The axgOptimizeContact command provides a GUI for
performing the same functionality as
axDrouteOptimizeContact. In addition, with
axgOptimizeContact you can specify particular net names for via
optimization (the default is to replace vias on all the nets).
To optimize contacts,
1. Enter axgOtpimizeContact or choose Route > Detail Route
Detail Route Contact Optimization.
The Optimize Contact dialog box appears.
Optimizing Contacts
12-7
Optimizing Contacts
12-9
There is an adjacent via located less than N microns from the via.
You use the isolatedViaSpacing parameter to define this
constraint. The syntax is
isolatedViaSpacing range
; range 0 to 5.0 default 1.0 micron
There are adjacent vias that cover all four quadrants located less
than N microns from the via.
You use the isolatedViaQuadrantSpacing parameter to
define this constraint. The syntax is
isolatedViaQuadrantSpacing range
; range 0 to 50.0 default 10.0 micron
To apply via isolation rules to specific layers rather than all layers,
use the checkIsolatedViaPerLayer parameter. Enter
axSetIntParam "droute" "checkIsolatedViaPerLayer" 1
After enabling this parameter, specify both the isolated via spacing
and quadrant spacing for each layer. For example,
axSetIntParam "droute" "via1IsolatedViaSpacing" 5.0
axSetRealParam "droute" "via1IsolatedViaQuadrantSpacing"
10.0
Using axgFillWireTrack
To perform metal density filling,
1. Enter axgFillWireTrack or choose Route Utility > Fill Wire
Track.
The Fill Wire Track dialog box appears.
Optimizing Yield
Manufacturability and yield-related issues become increasingly
important in deep submicron designs. At the post detail-routed
design stage, you can perform wire spreading and display critical
area heat maps to help reduce critical areas in the layout.
You can also run density-driven global routing and track assignment
to potentially improve yield. For more information, see Specifying
Density-Driven Global Routing on page 10-28 and Specifying
Density-Driven Track Assignment on page 10-34.
Option
Description
-particle_distr_func_file
distr_funct
-input_layers layer
-fault_type type
-multi_particle_report_format
You use a secret key to encrypt the particle probability function. The
encrypted file cannot be decrypted without the key. Critical area
analysis takes the encrypted file as its input and processes it without
the key. The output will be the heat map based on the encrypted
particle probability function; it will be in text format. The text format of
the particle probability function is still accepted as input to critical
area analysis. If an encrypted file is given as input, the file is
internally decrypted and used.
The syntax is
process_particle_probability_file
-key string
-input_file fileName
[-output_file fileName]
Option
Description
-key string
-input_file fileName
-output_file fileName
Optimizing Yield
12-19
5. Enter and select the appropriate values for the map and select a
color to represent the value.
6. Click OK or Apply.
auECOByChangeFile
astRepairHierPreservation
astDumpHierVerilog
A typical flow for ECO changes with hierarchy, using an edited netlist,
includes these major steps:
1. Perform netlist in, bind the netlist, and initialize hierarchy
preservation for the original netlist. The view in the database is
represented by the following:
NETL1
CEL1
HP1
2. Perform optimization that changes the CEL1 and HP1. You now
have
CEL2
HP2
HP2
HVO2
HVO3
CEL3
HP3
HVO3
Using Edit-In-Place
Edit-in-place can help you fix difficult DRC problems across the
hierarchy (useful for going down one level to see cell geometries). It
also lets you fix hierarchical antenna problems by allocating a lower
module error spot and then performing overall antenna analysis
without hopping along different hierarchies.
To use edit-in-place,
Point-to-Point Routing
Use the Astro Interactive Ultra tools point-to-point routing feature to
help complete the routing of your design. Access this feature from
the Route Utility menu in Astro. This replaces the Astro point-to-point
routing feature.
To activate point-to-point routing,
1. Enter leaPointToPointRoute or choose Route Utility >
Interactive Ultra Point-to-Point Route.
You can also activate point-to-point routing by choosing Tools >
AstroIU > Interactive Ultra > Interactive Routing Point-to-Point
Route.
The Point To Point Route dialog box appears.
2. Select the options or keep defaults. You can control the metal
layer preference, the guidance point, and other settings such as
the following:
- Select Honor Variable Net Rules to observe variable routing
rules.
- Select Snap To Track to route on track. The default is off
(routes off track).
For detailed information about the leaPointToPointRoute
command options, see the Astro Interactive Ultra User Guide and
Physical Implementation Online Help.
3. Perform point-to-point routing with global guidance.
Enter trPanel or choose Tools > AstroIU > Auto Ultra > Control
Panel.
The Control Panel dialog box appears.
The Control Panel dialog box includes the Net, Rule, Cost, Option,
Global, Bus, PreRoute, Utility, DFM, and Advanced tabs that you can
use to control all aspects of routing.
For detailed information about the trpanel command options, see
the Astro Interactive Ultra User Guide and Physical Implementation
Online Help.
13
Verification and Back-Annotation
13
You can verify your design by performing design rule checking (DRC)
and connectivity verification. You can also generate output for
back-annotation.
This chapter contains the following sections:
13-1
types (see Using the Error Browser on page 13-9). Also, you can
run design rule checking and verification with the
axgRouterVerify command.
Use geAdvDRC and axgRouterVerify when your design
technology is 90 nm and below. When working with technologies that
are 0.13 microns and above, you might choose to perform DRC with
geNewDRC.
DRC violations
Opens
Connectivity Verification
Use geNewLVS to verify the connectivity of your designthis
process creates an error cell, from which you can request a
summary of errors or highlight errors or specific types (see Using
the Error Browser on page 13-9).
- Click Load to load the error tree in the pane located at the lower
left. This displays the errors stored in the named error cells in
a tree-style graphic.
3. In the error tree pane, select the error types for which you want
to list error objects in the pane located at the lower right.
4. In the error object pane, which reports the number of errors at the
top of the pane, you can
- Use the sorted by list box to select a sorting method for the
error objects (none, type, layer, info). The default is none,
which means the errors are listed in numerical order.
- Use the Maximum errors box to enter the maximum number
of error objects to be listed.
5. In the Error-Probing page (Error-Operation area), you can
- Select show error object by click to choose what error objects
are to be highlighted in the graphics window by selecting them
from the list in the error object pane.
- Select query error in layout window to get information about
highlighted error objects. After you select objects in the
graphics window, the information is printed in the message
area of the Astro application window.
- Select flash to specify that the errors to be highlighted in the
graphics window, flash.
- Use the Zoom Scale box to enter a number at which the
graphics window is zoomed.
- Click Show Errors to enable the highlighting of errors in the
graphics window.
- Click Turn Off Errors to turn off the highlighting of errors in the
graphics window.
6. Click Hide. (The dialog box can be nested with other dialog
boxes.)
3. Click OK or Apply.
2. Next to File Name, enter the name of the file that contains the
timing functions.
3. Next to Table Template File Name, enter the name of the Scheme
file that contains the table template format to be used during the
timing model generation.
Here is a sample template file:
defineTableTemplate "tablex1" "CellDelayAndTransTable"
(("OutputCapacitance" (0.004 0.12 0.3 0.6 1.2 ))
("InputNetTransition" ( 0.02 0.5 1 2 3 )))
defineTableTemplate "tablex2" "ConstraintTable"
(("ConstrainedPinTransition" (0.02 0.5 1 2 3))
("RelatedPinTransition" (0.02 0.5 1 2 3)))
Note:
Use the astDumpHierVerilog command to generate a
hierarchical Verilog netlist for a given flat cell when the cell
contains hierarchical information. For more information, see
Generating Hierarchical Verilog on page 4-19.
In addition to a hierarchical or flat netlist, Astro outputs the following
RC and delay information in different formats for back-annotation:
14
Antenna Checking and Fixing
14
Deleting Diodes
14-1
Mode = 0 4
Run search-and-repair
Router lists violations in the log file
For runtime speed:
(axSetIntParam "droute" "topAntennaFixRange" n)
defineExtDiodeProtection
defineExtAntennaArea
defineExtGateSize
Diode Cell
To prepare the diode cell, do the following:
Technology File
If a sidewall is used for antenna calculations, define the thickness by
specifying the following in the technology file:
unitMinThickness
unitNomThickness
unitMaxThickness
move routing from top-layer metal to lower-layer metals, you can set
a threshold specifying that Astro move routing to lower layers only
when a small amount of wires needs to be moved.
The syntax is
(axSetIntParam "droute" "floatingWireMode" 0)
;; range [0,2], default=0, stored in cell;
;; 0: fixing based on antenna conx (if any)
;; 1: fixing based on floating antenna conx only
;; 2: fixing based on floating antenna conx only (ignore
;; violations on user routes)
Following is the syntax for the detail routing parameters that you can
set for checking floating wire antennas:
Deleting Diodes
Use the axgDeleteDiode command to delete all diode cells or
specific diode cells that were inserted to fix antenna violations. This
command does the following:
1. Disconnects all the diode port on the named nets.
2. Deletes the named diode cells that are fully disconnected. A fully
disconnected cell instance contains no connected port (except
power and ground) and no connected diode port.
3. Deletes all dangling wires (when you select this option in the
Delete Diode dialog box).
Deleting Diodes
14-17
where dbId is the name of the Milkyway database, cellId is the cell
window ID of the active cell, and fileName is the name of the antenna
report generated by Hercules with the antenna run set.
For example,
axImportAntennaReport (geGetEditCell) "herc.ant.rpt"
15
Signal Integrity: Crosstalk Prevention,
Analysis, and Fixing
15
Preventing Crosstalk
Analyzing Noise
15-1
As shown in Figure 15-1, the flow for crosstalk prevention and fixing
includes these major steps:
1. Set crosstalk options. Use atTimingSetup.
In the Environment page, turn on Enable Crosstalk Effects. In the
Xtalk page, specify crosstalk filtering thresholds, specify global
noise thresholds, and select the crosstalk circuit model to be
used during analysis.
See Environment Page on page 6-20 and Xtalk Page on
page 6-45.
2. Perform crosstalk prevention during placement and placement
optimization. Use astAutoPlace.
See Using astAutoPlace to Prevent Crosstalk on page 15-7.
3. Perform clock tree synthesis, followed by clock tree optimization.
Use astCTS and astCTO, respectively.
See Performing Clock Tree Synthesis After Placement on
page 9-62 and Optimizing Clock Trees on page 9-75.
4. Enable crosstalk prevention options (for global routing and track
assignment). Use axgSetRouteOptions.
See Crosstalk Prevention During Global Routing and Track
Assignment on page 15-11.
5. Perform crosstalk prevention during global routing and track
assignment. Use axgAutoRoute.
See Crosstalk Prevention During Global Routing and Track
Assignment on page 15-11.
Preventing Crosstalk
Astro works to prevent crosstalk as early as the placement and
placement optimization stages of the design flow, where
congestion-based coupling capacitances are estimated. Further
crosstalk prevention occurs during global routing and track
assignment.
It is recommended that you use the astAutoPlace command for
crosstalk prevention during placement and placement optimizations.
Alternatively, you can use the stand-alone astPostPS1 command.
These optimizations use the global noise thresholds that you set in
the Xtalk page of the AstroTime Timing Setup dialog box
(atTimingSetup).
Another crosstalk prevention approach is to use shielding, where
strong aggressor nets can be shielded by ground wires.
Preventing Crosstalk
15-7
Preventing Crosstalk
15-9
When these options are enabled, because timing has a higher cost
than crosstalk, Astro attempts to reduce crosstalk while it preserves
timing. (The Route Common Options dialog box is shown in
Figure 10-2 on page 10-19.)
Preventing Crosstalk
15-11
Then continue with the normal global routing and track assignment
settings and execution (for more information, see Performing
Automatic Routing on page 10-25). Fifty to ninety percent of
crosstalk problems can be prevented by use of crosstalk prevention
during global routing and track assignment.
Global Routing
During global routing, the axgAutoRoute command uses a wire
spreading approach to prevent crosstalk. You can enhance crosstalk
avoidance by decreasing the global noise threshold valuesuse the
Xtalk page of the AstroTime Timing Setup dialog box
(atTimingSetup).
Track Assignment
Track assignment is the initial phase of detail routing, and it
determines the locations of most long wires. Because most crosstalk
problems occur on long, parallel wires, track assignment can be
effective in reducing crosstalk problems by assigning long wires
differently.
To minimize crosstalk-induced delay, the axgAutoRoute command
avoids putting long, parallel wires on adjacent tracks during track
assignment. To minimize noise, track assignment estimates the
potential noise with a simplified crosstalk checker and reassigns
wires to reduce the potential noise. Track assignment uses the noise
threshold you specify in the Xtalk page of the AstroTime Timing
Setup dialog box (atTimingSetup). For most designs, a noise
threshold of 0.30 to 0.35 is recommended (the default is 0.35).
Analyzing Noise
You can perform crosstalk analysis on a design that has global
routing, track assignment, or detail routing completed. The minimum
requirement is a global-routed design.
Analyzing Noise
15-13
Analyzing Noise
15-15
Analyzing Noise
15-17
Guidelines
Make sure that the input transition time for all the cells in the design
is reasonable (less than 1 ns). This is to avoid pessimism in the
calculation of peak noise and crosstalk-induced delta delay.
The boundary conditions you specify for the input pins determine the
driving resistance calculated for the nets assigned to the pins. It is
recommended that you specify the driving cell instead of the input
transition for each input pin, using the set_driving_cell SDC
command. This approach enables Astro to estimate the driving
resistance more accurately and to correlate better with
PrimeTime SI.
Analyzing Noise
15-19
CLF Constraints
Astro-Xtalk includes both height and width noise constraints for cells
or pins of the cells to further reduce the pessimism of noise analysis.
The noise heights and widths are estimated and compared with the
noise constraints. When the noise widths are smaller, even if the
noise peak is higher than the noise threshold, the nets are filtered
out.
You can input cell- and pin-based noise pulse widths and noise
height (margin) constraints with a cell library format (CLF) file. These
constraints overwrite global noise constraints on the specified cells
or pins. For more information, see the
defineStaticNoiseMargin and defineStaticNoiseWidth
commands in Physical Implementation Online Help.
Noise Libraries
When you specify the medium-effort crosstalk circuit model in the
Xtalk page (atTimingSetup), Astro-Xtalk can use the noise
immunity characteristics of the cell inputs from the noise library to
detect noise violations. Astro-Xtalk first checks for the presence of
noise immunity curves in the noise library. When not available, it
checks for CLF constraints. When CLF constraints are not available,
it uses the global noise thresholds that you specify (in the Xtalk
page).
When you specify low effort, Astro-Xtalk checks for CLF constraints
and when CLF constraints are not available, it uses the global noise
thresholds.
You can obtain noise libraries from your library vendor. Noise
libraries that are in the .lib format, can be loaded into your reference
libraries. For more information, see Creating LM Views for Timing
and Power Analysis on page 3-29.
Note:
When you attach noise .lib files to reference libraries, make sure
the noise library file is the first .lib file in the list. Astro picks up the
first cell definition that appears in the list of .lib files. If you have
the same cell definition in the first and last .lib file, and the noise
immunity and I-V characteristics are in the cell definition in the
last .lib file, that cell definition will not be loaded into Astro.
Analyzing Noise
15-21
For each cell master, Astro writes out the noise information present
in each of the reference libraries linked to that design.
Sample Report
Following is the sample report:
---------------------------------------------------------noise1/foo
pin: noise1/foo/a
hyper_noise_high: (0.200000 0.300000 0.400000)
hyper_noise_low: (0.100000 0.200000 0.300000)
from noise1/foo/a to noise1/foo/y
si_has_immunity_below_high true
si_has_immunity_above_low true
si_has_iv_below_high true
si_has_iv_above_low true
si_has_resistance_below_high
si_has_resistance_above_low
---------------------------------------------------------CORELIB/CLOCKTREE
pin: CORELIB/CLOCKTREE/A
hyper_noise_high:
hyper_noise_low:
from CORELIB/CLOCKTREE/A to CORELIB/CLOCKTREE/Z
si_has_immunity_below_high false
si_has_immunity_above_low false
si_has_iv_below_high false
si_has_iv_above_low false
si_has_resistance_below_high false
si_has_resistance_above_low false
---------------------------------------------------------CORELIB/FD1
pin: CORELIB/FD1/D
hyper_noise_high:
hyper_noise_low:
pin: CORELIB/FD1/CP
hyper_noise_high:
hyper_noise_low:
from CORELIB/FD1/CP to CORELIB/FD1/D
si_has_immunity_below_high false
si_has_immunity_above_low false
si_has_iv_below_high false
si_has_iv_above_low false
si_has_resistance_below_high false
si_has_resistance_above_low false
from CORELIB/FD1/CP to CORELIB/FD1/Q
Analyzing Noise
15-23
si_has_immunity_below_high false
si_has_immunity_above_low false
si_has_iv_below_high false
si_has_iv_above_low false
si_has_resistance_below_high false
si_has_resistance_above_low false
Use the global noise threshold settings in the Xtalk page of the
AstroTime Timing Setup dialog box
Analyzing Noise
15-25
Using xtXTalkAnalysis
The xtXTalkAnalysis command sorts the nets to be reported
according to their noise levels and reports those with the highest
values. You can modify the number of nets to be reported, and when
you know which net is most susceptible to crosstalk problems, you
can specify its name. Use a comma to separate the net names for
multiple nets, or use pattern matching for analysis on several nets.
To perform crosstalk analysis,
1. Enter xtXTalkAnalysis or choose Crosstalk > Crosstalk
Analysis.
The Crosstalk Analysis dialog box appears.
Analyzing Noise
15-27
Analyzing Noise
15-29
8,498 nets are filtered because the peak noise value is below the
noise threshold.
The 956 crosstalk-free nets and the 499 pruned nets are included
in the 8,498 filtered nets, which leaves 1,559 nets (10,057 minus
8,498) with a peak noise value above the noise threshold.
Of the 1,559 nets, some might have rise violations, fall violations,
or both rise and fall violations.
For NOISESUM,
- 1,559 of the 1,559 nets have fall violations and 105 of the 1559
nets have rise violations.
- The Slack column indicates the worst noise violator and the
Total column indicates the sum of noise slack for each violator.
Noise slack for each net is calculated as follows:
noise threshold (scaled by supply voltage) minus peak noise
reported on net
Noise slack is reported in terms of voltage.
Analyzing Noise
15-31
Analyzing Noise
15-33
Example 15-2
Analyzing Noise
15-35
X3[2]
(X3[2])
1.1876e+00 3.8483e-01 -2.1951e-01 User Peak(0.180
)
W2[23]
(W2[23])
1.4794e+00 3.8470e-01 -2.7323e-01 User Peak(0.180
)
T02[5]
(T02[5])
1.0612e+00 3.7406e-01 -1.8472e-01 User Peak(0.180
)
W03[6]
(W03[6])
1.4872e+00 3.7369e-01 -2.5831e-01 User Peak(0.180
)
X1[10]
(X1[10])
9.9837e-01 3.7121e-01 -1.7093e-01 User Peak(0.180
)
X3[27]
(X3[27])
1.3428e+00 3.6864e-01 -2.2645e-01 User Peak(0.180
)
W12[29]
(W12[29])
7.6932e-01 3.6719e-01 -1.2862e-01 User Peak(0.180
)
X3[11]
(X3[11])
8.4058e-01 3.6136e-01 -1.3564e-01 User Peak(0.180
)
W11[4]
(W11[4])
1.1435e+00 3.6112e-01 -1.8424e-01 User Peak(0.180
)
U12332/I1
(n244)
1.4355e+00 3.6010e-01
2.9597e-01 * U12332/I1
U12346/I1
(n244)
1.4434e+00 3.5695e-01
3.0319e-01 * U12346/I1
U12350/I1
(n244)
1.4453e+00 3.5591e-01
3.0606e-01 * U12350/I1
W12[30]
(W12[30])
1.0600e+00 3.5966e-01 -1.6924e-01 User Peak(0.180
)
U11953/I2
(n300)
1.4829e+00 3.5262e-01
3.0591e-01 * U11953/I2
U11967/I2
(n300)
1.4826e+00 3.5204e-01
2.9361e-01 * U11967/I2
U11972/I2
(n300)
1.4819e+00 3.5166e-01
3.0857e-01 * U11972/I2
T11[27]
(T11[27])
1.0891e+00 3.5075e-01 -1.6418e-01 User Peak(0.180
)
W02[7]
(W02[7])
4.5864e-01 3.4562e-01 -6.6788e-02 User Peak(0.180
)
T01[9]
(T01[9])
1.2582e+00 3.4520e-01 -1.8268e-01 User Peak(0.180
)
X3[7]
(X3[7])
8.3410e-01 3.4517e-01 -1.2109e-01 User Peak(0.180
)
X2[11]
(X2[11])
7.3832e-01 3.4050e-01 -1.0374e-01 User Peak(0.180
)
X3[3]
(X3[3])
7.7310e-01 3.3897e-01 -1.0744e-01 User Peak(0.180
)
G2[9]
(G2[9])
7.1740e-01 3.3677e-01 -9.8115e-02 User Peak(0.180
)
U10242/I2
(n99)
1.3390e+00 3.3607e-01
3.1825e-01 * U10242/I2
U10253/I2
(n99)
1.3399e+00 3.3576e-01
3.1244e-01 * U10253/I2
U10265/I2
(n99)
1.3399e+00 3.3575e-01
3.1573e-01 * U10265/I2
X3[8]
(X3[8])
1.7644e+00 3.3350e-01 -2.3555e-01 User Peak(0.180
)
A2[14]
(A2[14])
7.1324e-01 3.3343e-01 -9.5171e-02 User Peak(0.180
)
W12[20]
(W12[20])
1.0142e+00 3.3332e-01 -1.3521e-01 User Peak(0.180
)
X1[3]
(X1[3])
1.1170e+00 3.3260e-01 -1.4811e-01 User Peak(0.180
)
U7108/I2
(n1226)
1.1821e+00 3.3080e-01
3.9589e-01 * U7108/I2
U7647/I
(n1226)
1.1826e+00 3.2943e-01
2.0307e-01 * U7647/I
Y1[25]
(Y1[25])
7.3955e-01 3.2803e-01 -9.4682e-02 User Peak(0.180
)
T11[3]
(T11[3])
1.1896e+00 3.2802e-01 -1.5229e-01 User Peak(0.180
)
---------------------------------------------------------------------------------------------------------------
Analyzing Noise
15-37
- Net Value >= to specify that the nets with noise levels equal to
or greater than the specified value be reported (the default is
0.35). The specified value is in terms of percentage of voltage.
Astro calculates noise height in terms of absolute voltage. The
threshold that is specified as a percentage of voltage is
therefore scaled so as to be represented as an absolute
voltage as well. For example, when you specify a threshold of
0.35 and the supply voltage is 1.2, the noise constraint shown
in the report is 0.420 (0.35 times 1.2).
By default, all top aggressor nets are reported, or you can enter
a number to specify a certain number of top aggressors to be
reported.
You can choose to output the report to a window or file. If you
select File, enter its name in the File Name box.
3. Click OK or Apply.
The detailed crosstalk report that xtXTalkReport generates
reports information about victim nets and their respective
aggressors. The crosstalk report is a more detailed report than the
one generated with xtXTalkAnalysis (see also Noise Analysis
Reports on page 15-31).
Example 15-3 is a sample detailed crosstalk report for static noise,
using the low-effort crosstalk circuit mode. An explanation of the
fields in the report follows the example.
Note:
Although Astro calculates timing windows for each aggressor
and victim net for each clock domain, the detailed crosstalk
report (xtXTalkReport) generated with the low-effort crosstalk
circuit model no longer prints timing window information.
Example 15-3
Cc
0.002991
0.002908
0.000732
0.000587
0.000632
0.000563
Driver
MUX4ND1
MUX4ND1
MUX4ND1
MUX4ND1
MUX2ND1
MUX2ND1
Driver
MUX4ND0
IndividualPeak(R:F)
(0.168236:0.205024)
(0.165795:0.200029)
(0.037914:0.049062)
(0.033657:0.040426)
(0.026136:0.039489)
(0.022448:0.034759)
Filtered(R:F)
(N:N)
(N:N)
(N:N)
(N:N)
(N:N)
(N:N)
Net precedes the name of the net for which the subsequent
information applies.
Driver is the cell master name for the driver of the victim net.
Analyzing Noise
15-39
**************************************************************************
Report : noise_calculation
-to X2[26]
Design : TCS15
Version: W-2004.12-SP1
Date
: Fri Feb 4 14:03:52 2005
**************************************************************************
Region
: above_low
Victim driver pin
: U12343/ZN
Victim driver library cell : MUX4ND0
Victim net
: X2[26]
Driver voltage swing
: 0.90
Noise calculations:
Attribute:
E - aggressor is excluded by user
Y - aggressor is filtered by timing window or elec. filtering
Height Width
Area
Attribute
---------------------------------------------------------------Aggressors:
X1[9]
0.0163 1.1162
0.0091
X1[31]
X2[20]
X1[28]
n685
n708
0.0259
0.0191
0.0290
0.1282
0.1315
0.7293
1.0720
0.8329
0.7303
0.7432
0.0095
0.0102
0.0121
0.0468
0.0489
Total:
0.3500
0.7802
0.1365
The report prints information for each pin. The format of the crosstalk
report is as follows:
Victim driver pin indicates the pin driving the victim net.
Analyzing Noise
15-41
Analyzing Noise
15-43
2. Next to Net Name, specify the name of the net for which the
crosstalk analysis results are to be displayed.
3. Select Show P/G Bus to display power and ground buses (when
they are aggressor nets) for the named net. Power and ground
buses are usually viewed as quiet nets and provide some
shielding from neighboring wires.
4. Choose whether to display the analyzed net and how many
neighboring nets to display (the default is 17). Also, you can
change the display colors or keep the defaults. Select Flash to
display them more clearly.
5. Click OK or Apply.
The graphics window is zoomed in to the bounding box of the
victim net and the selected nets are colored and/or flashing. The
display is accompanied by a report (in the application window)
that shows the noise values contributed by each aggressor net.
Sample Report
Following is the sample stage delay report:
---------------------------------------------------------- Astro Stage Delay Report
- Tool : Astro
- Version : W-2004.12-SP1_rel-Development for SUN.32 -Mar 16, 2005
- Design : add16
- Date : Wed Mar 16 15:50:14 2005
- Timer : Xtalk effect is ON, DeltaTransScaling Factor = 0.00
- : Store Delta Trans and Delay is ON
- Format : Delay for stage stage_chain is:
(rise_min rise_max) (fall_min fall_max)
- Stage Delay Includes Both Cell Delay and Net Delay
- If Xtalk Effect is ON, Stage Delay is Normal Delay + Delta
Delay
---------------------------------------------------------Delay for stage buf_clk/andclk/A -> buf_clk/Z -> ffa0/CP is:
(0.0000 0.0000) (0.0000 0.0000)
Delay for stage buf_clk/andclk/A -> buf_clk/Z -> ffa1/CP is:
(0.0000 0.0000) (0.0000 0.0000)
Delay for stage ffa13/CP -> ffa13/Q -> xadd13/an4/B is:
(0.1643 0.4572) (0.1721 0.4516)
Delay for stage ffa13/CP -> ffa13/Q -> xadd13/xo1/B is:
(0.1643 0.4572) (0.1721 0.4516)
Delay for stage ffa13/CP -> ffa13/Q -> xadd13/an3/A is:
(0.1642 0.4571) (0.1720 0.4515)
Delay for stage ffb12/CP -> ffb12/Q -> xadd12/an4/C is:
(0.1704 0.4500) (0.1731 0.4486)
Analyzing Noise
15-45
xtDumpDeltaTransDelay filename
Sample Report
Following is the sample delta transition report:
---------------------------------------------------------- Astro Delta Transition Report
- Tool : Astro
- Version : W-2004.12-SP1_rel-Development for SUN.32 -Mar 16, 2005
- Design : add16
- Date : Wed Mar 16 16:17:52 2005
- Timer : Xtalk effect is ON, DeltaTransScaling Factor = 0.00
- : Store Delta Trans and Delay is ON
- Format : pin_name : ((rise_min)(fall_min))
((rise_max)(fall_max))
- rise_min
- fall_min
- rise_max
- fall_max := normalTrans:deltaTrans:annotatedTrans
-
---------------------------------------------------------ffb15/CP : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
ffb15/D : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
ffb15/Q : ((0.1549:0.0000:0.1549)(0.0989:0.0000:0.0989))
((0.3612:0.0000:0.3612)(0.2237:0.0000:0.2237))
ffb15/QN : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
ffa15/CP : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
ffa15/D : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
ffa15/Q : ((0.1541:0.0000:0.1541)(0.0985:0.0000:0.0985))
((0.3580:0.0000:0.3580)(0.2218:0.0000:0.2218))
ffa15/QN : ((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
((0.0000:0.0000:0.0000)(0.0000:0.0000:0.0000))
xadd14/Z : ((0.1552:0.0000:0.1552)(0.1176:0.0000:0.1176))
((0.3681:0.0000:0.3681)(0.2691:0.0000:0.2691))
xadd12/B : ((0.0635:0.0000:0.0635)(0.0503:0.0000:0.0503))
xadd12/B : ((0.0635:0.0000:0.0635)(0.0503:0.0000:0.0503))
((0.1592:0.0000:0.1592)(0.1157:0.0000:0.1157))
Analyzing Noise
15-47
Analyzing Noise
15-49
3. Click OK or Apply.
Note:
By default, the crosstalk effect on transitions not considered with
the low-effort crosstalk model. To see the crosstalk effect, as well
as the propagation of the crosstalk effect on the transition time,
you can use the xtDeltaTransScale parameter. The syntax is
axSetRealParam "xt" "xtDeltaTransScale"value
Analyzing Noise
15-51
Coupling capacitance
Lumped
Not used
Used
I-V curve
Used
Used
Used
Not used
Noise height
Computed
Computed
Noise width
Estimated
Computed
Noise slack
Delta transition
Scaled to 0 by default
Computed
Delta delay
Computed
Computed
Computed
Optimization
Default
Not used
Analysis
Default
Used
Va
Cx
Ca
Vv
Rv
Cv
Cc
Vx(t)
In Figure 15-4, the aggressor net at the top is coupled with the victim
net at the bottom, with coupling capacitance equal to Cc.
Compared to the low-effort crosstalk model, the medium-effort
crosstalk model provides better accuracy at the cost of longer
runtime. The medium-effort crosstalk model performs more detailed
RC modeling, and it utilizes a topology-sensitive coupling
capacitance Cc. The latter feature means that the coupling strength
is not only related to the value of Cc, but also to the values of the
resistors on the left and right sides of Cc.
A closed-form formula can be derived for Vx(t). Noise and delta delay
based on the waveform of Vx(t) can be obtained.
16
Signal Integrity: Signal and Cell
Electromigration
16
16-1
Examples of Scripts
2. Enter the name of the ALF file to be loaded in the ALF file name
box.
3. Enter the name of the library that is specified in the ALF file in the
Library Name box.
If the library name in the ALF file is inconsistent with the design
library name, the library name you enter here has precedence.
Note:
Do not have the design library open when you load the ALF file.
4. Click OK or Apply.
You can write the loaded constraints by using the auDumpALF
command (or choosing Tools > Data Prep > CLF > Dump ALF). For
descriptions of the auDumpALF command options, see Physical
Implementation Online Help.
You can purge the constraints by using the auPurgeSIOfALF
command. The syntax is
auPurgeSIOfALF "library_name"
LAYER metal1 {
PURPOSE = routing ;
LIMIT {
CURRENT absavg_limit {
MEASUREMENT = absolute_average;
MAX { HEADER {
TEMPERATURE { TABLE { 50 75 90 100 115 160 195 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
6.6773 4.4319 2.2734 1.11 0.80589 0.65571 0.33536 } }
}
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 50 75 90 100 115 160 195 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
6.6773 4.4319 2.2734 1.11 0.80589 0.65571 0.33536 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 50 75 90 100 115 160 195 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
42.558 33.154 21.764 12.8 6.9554 3.3834 2.3212 } }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 50 75 90 100 115 160 195 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
88.95 66.96 44.54 23 16.304 8.784 4.392 } }
}
}
}
Note:
When you use LM views and you define power supply information
with tdfSetPowerSupply commands, the xtSignalEM
command will only use the tdfSetPowerSupply definitions if it
fails to find power supply information in the LM views.
To load the ASCII file that contains power supply information,
1. Enter poLoadPowerSupply or choose Power > Data
Preparation Load Power Supply.
The Load Power Supply dialog box appears.
2. Next to TDF File Name, enter the name of the TDF file containing
the power supply information.
3. Click OK or Apply.
Save the cell to save the loaded power supply information.
Here is a sample TDF file:
tdfSetPowerSupply "VDD" 1.8
tdfSetPowerSupply "VDD1" 2.5
Clock period is defined in the SDC file, and clock period is used
in the current calculation. When no real clocks are defined, Astro
assumes 100 MHz for the virtual clock.
You can define net switching activities in any of the following formats:
A Scheme file
VCD is a standard Verilog output format that prints the time and
value information whenever a monitored net experiences a value
change. VCD files can be parsed into time frames for performing
frame-by-frame analysis or lumped as average net switching
activities.
In this example, the ".*" pattern matching capability specifies all net
names, and 0.2 specifies the net switching activity. The 0.2 value is
the number of switches or toggles (rise plus fall) per unit of time, as
defined in the unitTimeName parameter of your technology file. For
example, if unitTimeName is defined as ns, 0.2 corresponds to 100
MHz because 0.2 means it toggles twice (one rise plus one fall)
every 10 ns.
Usually you can determine the value to be used in the
defineNetSwitchingActivity command by assuming at what
percentage of the clock frequency the nets are switching. For
example, to calculate the number to be assigned when you want a
net switching activity at 20 percent of the clock frequency that is set
at 125 MHz, where the unit of time is ns, use either of these two
equivalent methods:
(geGetEditCell)
(geGetEditCell)
(geGetEditCell)
(geGetEditCell)
(geGetEditCell)
(geGetEditCell)
(geGetEditCell)
".*" 0.2
"A/.*" 0.3
"A/a/.*" 0.4
"B/.*" 0.5
"B/b/.*" 0.6
"clk.*" 0.7
"clk" 0.8
When you load this switching activity in a Scheme file, Astro does the
following:
Assigns a switching activity of 0.7 to all nets with names that start
with clk.
The last two lines show that you can assign different switching
activities to nets that belong to different clock domains, based on the
patterns of the net names.
The command options are briefly described in the next steps. For
detailed descriptions of all the xtSignalEM command options,
see Physical Implementation Online Help.
2. Specify the names of the nets for which you want to run signal
electromigration analysis. You can specify the net names from a
window list, including specifying a pattern to match the names of
multiple nets, or read the list of net names from an ASCII file.
3. Specify the names of the nets that you want to exclude from
signal electromigration analysis. You can specify the net names
from a window list, including specifying a pattern to match the
names of multiple nets, or read the list of net names from an
ASCII file.
You can select Exclude Nets without Driver to specify that
electromigration analysis not be performed for the named nets
without drivers. The default is off.
4. Select Hierarchical to perform analysis for top-level nets that are
routed to pins of soft macros.
Signal electromigration analysis of a top-level design with soft
macros not only includes analysis of the top-level nets, it also
accounts for the segments of nets that are inside the blocks and
connected to the top-level nets through ports.
Hierarchical signal electromigration analysis allows you to better
analyze top-level nets that are routed to blocks because it
accounts for the segments of the nets that are within the blocks.
You need to create the models for each block that retain the
geometry information for all the boundary nets. Boundary nets
are nets that are routed to the ports of the block and, therefore,
will be part of top-level routing.
When you run signal electromigration analysis in hierarchical
mode, the resulting repair file will contain variable routing rules
for block-level nets (from the HTV model) as well as for top-level
nets. When this repair file is loaded at the top level, the router
modifies only the top-level nets and not the block-level (HTV)
nets. You will need to fix the signal electromigration violations that
occur within the block at the block level.
# Signal EM Report
16
[ 613,
2]
min
5.1755e-02 2.9532e-01
Via
16
[ 613,
2]
max
5.1755e-02 2.9532e-01
Metal
Metal
21
21
[ 623,
[ 623,
2] 0.14 min
2] 0.14 max
5.2277e-02 2.9982e-01
5.2277e-02 2.9982e-01
Via
Via
18
18
[ 613,
[ 613,
2]
2]
5.1788e-02 2.9560e-01
5.1788e-02 2.9560e-01
1
1
min
max
AWE Order refers to the specified order that is used for AWE
calculation.
Metal/Via and Layer denote the metal or via edge and the
corresponding layer number.
Note:
Because no actual geometries exist in the virtual routing
stage, the Metal/Via and Layer fields are not present in
prerouting analysis.
N nClk
AWE Order: 4
Met/Via Layer
bBox
Width Mode Eff_AbsAvg Eff_Rms
Rel_AbsAvg Rel_RMS
Metal
12
M2 [ 242, 779] 0.14 min 5.1610e-01 6.7542e-01 1.0393e-01 7.7940e-01
Metal
12
M2 [ 242, 779] 0.14 max 5.2402e-01 5.3575e-01 1.0553e-01 6.1822e-01
Via
Via
22
22
V2 [ 240, 772]
V2 [ 240, 772]
1
1
min
max
Average
2 T 2
2 T 2
I avg = -------
I n ( t ) dt
I p ( t ) dt -------
T 0
T 0
Absolute average
2 T 2
2 T 2
I absavg = -------
I n ( t ) dt
I p ( t ) dt + -------
T 0
T 0
rms
I rms =
T2 2
2 T 2 2
I n ( t ) dt
I p ( t ) dt +
-------
T 0
0
Peak
D p = Width ( I p ) 2 ( T )
D n = Width ( I n ) 2 ( T )
1
2
------- = -- ( defineNetSwitchingActivity )
2
T
where the units are 1 divided by the time units you define.
To load the variable routing rules, use the load command. Enter
load "EMRepair.net"
Do the following:
- Next to Transition Time, click From Timer or From Window.
The xtSignalEM command uses transition time from the
Astro timer, and uses calculated transition times from static
timing analysis that is done in Astro.
- Enter a pattern to match the names of multiple nets (use .* to
specify all nets).
Then select the net of interest from the list of nets that appears.
3. Under the list of nets, click Compare and wait for the HSPICE
simulation to be completed.
The results are displayed in the Debug Manager window.
For descriptions of all the demOpen command options, see Physical
Implementation Online Help.
I mean ( debug, p ) =
T2
I mean ( debug, n ) =
T2
I p ( t ) dt
I n ( t ) dt
I rms ( debug, p ) =
T2
2
I p ( t ) dt
T2
2
I n ( t ) dt
I rms ( debug, n ) =
Note:
All the values reported in the Debug Manager window are
expressed in terms of signal integrity units. Width uses second;
peak uses ampere; rms uses ampere / (square root of second);
and mean uses ampere * second.
You can derive the values for current densities that are reported by
the xtSignalEM command from those reported in the Debug
Manager window, through the following relationships:
Average current
2
Eff Avg = ( Vdd ) ------- [ I mean ( debug, p ) I mean ( debug, n ) ]
T
2 2
2
Eff Rms = ( Vdd ) ------- I rms ( debug, p ) + I rms ( debug, n )
T
For each net, the Debug Manager only reports the currents for the
first edge that connects to the driver and the last edge that connects
to the receiver, whereas the report generated by the xtSignalEM
command lists the currents of all the edges, including metals and
vias.
These lines define the units as uA for currents and nm for widths.
Replace library_name with the name of the library in the ALF file.
LIBRARY library_name {
LAYER metal1 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
5.8773 3.3319 1.9734
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
32.058 18.174 10.764
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
73.98 41.94 24.84 18
}
}
}
LAYER metal2 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE {
WIDTH { TABLE
} TABLE { 0
7.9323
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal3 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
7.9323 4.4969 2.6634 1.93 1.22169 0.61374 0.33196 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal4 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
7.9323 4.4969 2.6634 1.93 1.22169 0.61374 0.33196 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal5 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE {
WIDTH { TABLE
} TABLE { 0
7.9323
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal6 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
7.9323 4.4969 2.6634 1.93 1.22169 0.61374 0.33196 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal7 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
7.9323 4.4969 2.6634 1.93 1.22169 0.61374 0.33196 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
28.77 16.31 9.66 7 4.431 2.226 1.204} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
98.64 55.92 33.12 24 15.192 7.632 4.128 } }
}
}
}
LAYER metal8 {
PURPOSE = routing ;
LIMIT {
CURRENT avg_limit {
MEASUREMENT = average;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
20.3445 11.5335 6.831 4.95 3.13335 1.5741 0.8514 } }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0
0
0
0
55.485 31.455 18.63 13.5 8.5455 4.293 2.322 } }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
WIDTH { TABLE { 0 1 } }
} TABLE { 0
0
0
0 0
0
0
246.6 139.8 82.8 60 37.98 19.08 10.32 } }
}
}
}
}
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110 125 150 175 } }
AREA { TABLE { 0 0.0361 } }
} TABLE { 0
0
0
0
0
0
0
0.81789 0.46367 0.27462 0.199 0.125967 0.063282 0.034228
} }
}
CURRENT rms_limit {
MEASUREMENT = rms;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110
AREA { TABLE { 0 0.0361 } }
} TABLE { 0
0
0
0
0
4.521 2.563 1.518 1.1 0.6963
} }
}
CURRENT peak_limit {
MEASUREMENT = peak;
MAX { HEADER {
TEMPERATURE { TABLE { 70 85 100 110
AREA { TABLE { 0 0.0361 } }
} TABLE { 0
0
0
0
0
10.275 5.825 3.45 2.5 1.5825
} }
}
}
}
Examples of Scripts
This section contains a sample script for running signal
electromigration analysis and fixing and a sample script for running
signal analysis and prevention.
Examples of Scripts
16-37
xtSignalEM
setFormField "Signal EM Analysis" "Output To" "File"
setFormField "Signal EM Analysis" "File Name"
"EM.report-after"
formOK "Signal EM Analysis"
Examples of Scripts
16-39
axgAutoRoute
formOK "Auto Route"
xtSignalEM
setFormField "Signal EM Analysis" "Output To" "File"
setFormField "Signal EM Analysis" "File Name" "EM.report"
formOK "Signal EM Analysis"
A
Astro Design Flow
The Astro design flow is shown in Figure A-1. This flow drawing is a
compilation of the flow drawings appearing in various chapters
throughout this user guide. When there is a choice of using a
combined command rather than individual commands, it shows the
combined command. Because of the many differences in design
structures and methods, you might need to use a variation of this
flow.
See also the Astro-Rail and PrimeRail flow (Figure 1-2 on
page 1-14), the charge-collecting antenna fixing flow (Figure 14-1 on
page 14-4, and the crosstalk prevention, analysis, and fixing flow
(Figure 15-1 on page 15-4).
A-1
Contains created
cell bound to
expanded netlist
Set up timing
atTimingSetup
Check timing
astTimingDataCheck
Check design
astCheckDesign
To next page
Evaluate placement
axgDisplayPLCongestionMap
axgDisplayCouplingCapMap
To next page
A-3
To next page
A-5
B
Scan Chains
B-1
When you perform scan chain optimization, you can also specify a
routing preference (horizontal or vertical).
Note:
Scan chain optimization accepts multiple scan-out ports and
honors minimum edge lengths. Specifying the minimum edge
lengths prevents hold-time violations in some cases.
Before you define and optimize scan chains, complete all placement
operations and identify the scan input and output ports.
For information about identifying scan ports, see the Milkyway Data
Preparation User Guide.
Perform placement
Update netlist
To routing
Methodology
As shown in Figure B-1, the netlist-defined scan chain optimization
flow includes these major steps:
1. Set scan input and output ports. Use dbSetCellPortTypes.
See Setting Scan Input and Output Ports on page B-7.
2. Create scan chains by tracing the netlist. Use axgScanTrace.
See Creating Scan Chains by Tracing the Netlist on page B-7.
3. Detach scan chains. Use axgScanChainOptimization.
See Detaching Scan Chains on page B-9.
4. Perform placement.
See Chapter 8, Placement and Placement Optimizations.
5. (Optional) Create and apply constraints.
See Creating and Applying Constraints on page B-10.
6. Optimize scan chains. Use axgScanchainOptimization.
See Optimizing Scan Chains on page B-19.
7. Trace scan chains. Use axgScanTrace.
See Tracing Scan Chains on page B-21.
8. Write new scan chain information to a file. Use
dbDumpScanChain.
See Writing Out New Scan Chain Information on page B-21.
To routing
Methodology
As shown in Figure B-2, the user-defined scan chain optimization
flow includes these major steps:
1. Create scan chains manually. Use
dbMakeScanChainByCellInst and
dbMakeScanChainByMaster.
See Creating Scan Chains Manually on page B-9.
2. Write new scan chain information to a file. Use
dbDumpScanChain.
See Writing Out the Scan Chains on page B-11.
3. Optimize scan chains. Use axgScanchainOptimization.
See Optimizing Scan Chains on page B-19.
4. Trace scan chains. Use axgScanTrace.
See Tracing Scan Chains on page B-21.
5. Perform clock tree synthesis and optimization.
See Chapter 9, Clock Tree Synthesis and Clock Tree
Optimizations.
2. Next to Start Port Name, enter the name of the port that is the
starting point of the scan chain. Also, select the type of cell for
which the port exists (top cell or cell instance). If you select cell
instance, enter the name of the cell instance for which the
specified port exists (next to Instance Name).
3. Select the options, depending on your requirements.
For descriptions of the axgScanTrace command options, see
Physical Implementation Online Help.
4. Click Apply.
5. Repeat steps 1 and 2 for each scan chain defined in the netlist.
6. Click OK the last time you execute the command.
Appendix B: Scan Chains
B-8
Meaning
Default group
priority
Edge constraint
Fixed edge
Free edge
Group priority
2. Enter the name of the file to which you want to save the scan
chain information.
You can select Print Clock Nets to print the clock nets in the scan
chain file to verify the results of scan chain optimization with clock
net reordering.
3. Click OK or Apply.
Here is a sample output file:
dbCreateScanChain (geGetEditCell) "SCAN1"
dbAddFreeEdgeToScanChain (geGetEditCell) "SCAN1"
((("S" "so") ("F1" "si")) (("F2" "so") ("F3" "si"))
(("F3" "so") ("R" "si2")))
dbCreateScanChain (geGetEditCell) "SCAN2"
dbAddFreeEdgeToScanChain (geGetEditCell) "SCAN2"
((("S" "so") ("F4" "si")) (("F4" "so") ("F5" "si"))
(("F5" "so") ("F6" "si")) (("F6" "so") ("R" "si1")))
Next, you can edit this file to include fixed-edge constraints and
group-ordering constraints.
Now you can edit the file containing the scan chain information to
create your scan chain constraints file. Use the information that
follows to help you specify your constraints.
Task
Command
dbDeleteScanChain
dbCreateScanChain
dbAddInstGroupToScanChain
dbSetScanChainDefaultPriority
dbAddFreeEdgeToScanChain
dbAddFixedEdgeToScanChain
IA
IB
IC
ID
IE
SCAN1, which contains three free edges and one fixed edge.
SCAN2, which contains four free edges and two scan chain
groups. The scan chain groups include the following:
- registers1, which contains cell instances F5 and F6 and has a
priority of 10. It is defined by the
dbAddInstGroupToScanChain command.
- Cell instance F4, with a default priority of 0. The group is
defined by Astro.
Fixed edge
S so
si S so
si F2 so
si F3 so
si F4 so
si F5 so
si F6 so
si2
R
si1
a C1
b
C2
a
Note that C1 and C2 are not in a scan chain. They are included in
the diagram to illustrate that when Astro reorders the chain, it
disconnects from the input ports. Thus, any connections external to
the scan chain move with the cells that contain the output ports. For
example, if Astro swaps F5 and F6, C2 moves with F5, as shown in
the next diagram.
Fixed edge
si S so
S so
si F4 so
si F2 so
si F3 so
si F6 so
si F5 so
a C1
si2
R
si1
b C2
a
After you run scan chain optimization, trace the scan chain to see the
scan chain connections; then write the scan chain information to a
file. You can also use the axgDisplayScanChain command to
highlight a scan chain within the design.
C
Routing Design Rules
C-1
"M1" {
minLength = 0.35
}
You control the scope of the check for most of these rules by
specifying a mode value (0 or 1) with the minEdgeMode attribute in
the Technology section of the technology file. For example,
Technology{
minEdgeMode = 0
}
The mode values are described in the table and figure that follow.
Mode value
Description
Must have concave corner to trigger violation (See the figure below
and Table C-1).
A
B
B
C
Metal 1
Metal 1
Concave Corner
Convex Corner
"M1" {
minEdgeLength = 0.07
maxTotalMinEdgeLength = 0.11
}
or
Layer
"M1" {
minEdgeLength = 0.07
maxNumMinEdge = 2
}
Corner
Violation?
Concave
Yes
Convex
No
Corner
Violation?
Concave
Yes
Convex
Yes
Note:
For this syntax sample, when minEdgeMode has a value of 1, a
violation also occurs when maxNumMinEdge < 2.
"M1" {
minEdgeLength = 0.4
maxNumMinEdge = 2
...
For example,
Technology{
minEdgeMode = 1
}
Layer
"M1" {
minEdgeLength = 0.07
maxTotalMinEdgeLength = 0.11
}
"M1" {
minEdgeLength2 = 0.4
minEdgeLength3 = 0.26
...
Table C-3 and the following figure show how to interpret this syntax.
Table C-3 Specifying Special Notch Rule Attributes
Attribute
Value
Description
minEdgeLength2
0.4
minEdgeLength3
0.26
270
L1
W
L2
270
You can fix special notch rule violations by rerouting wires, rotating
vias, or adding stubs.
"VIA1" {
cornerMinSpacing = 0.12
}
Value
Description
= 0.13
= 0.05
= 0.16
"M1"
{
minEnclosedArea = 0.2
"M1" {
fatTblDimension = 3
fatTblThreshold = (0, 0.155, 1.605)
fatTblMinEnclosedArea = (0.3, 1.0, 1.0)
}
In this example, Astro avoids creating any metal wires with widths
greater than or equal to 0.155.
You must also set the fatTblMinEnclosedAreaMode attribute in
the Technology section of the technology file. This attribute
determines the mode in which the router checks for and avoids a
violation.
"M1" {
minEnclosedArea = 0.2
minEnclosedWidth = 0.7
}
Value
Description
Check all pin connections to avoid creating new fat shapes that could
cause either fatVia or minEnclosedArea rule violations.
For example,
layer
"VIA1" {
fatTblDimension = 3
fatTblThreshold = (0, 0.155, 1.605)
fatTblFatContactNumber = (1, 21, 31)
fatTblFatContactMinCuts = (1, 2, 4)
}
Note:
In the two-dimensional fat contact tables the horizontal index is
for the lower metal layer (fatTblThreshold) and the vertical
index is for the upper metal layer (fatTblThreshold2).
Define these attributes in the via Layer section of the technology file.
For example,
Layer "VIA23" {
fatTblDimension = 4
fatTblThreshold = (0,0.421,0.701,0.981)
/* Threshold for lower layer metal width */
fatTblThreshold2 = (0,0.221,0.501,0.781)
/* Threshold for upper layer metal width */
fat2DTblFatContactNumber = (1,18,17,20,
20,17,18,20,
21,18,18,19,
20,20,20,20)
fat2DTblFatContactMinCuts = (1,2,2,2,
2,3,3,4,
4,4,4,6,
4,4,4,4)
}
In this example, if the lower metal width value is greater than or equal
to .421 and less than .701, then the tool will consider that value as
element 2 of fatTblThreshold. If the upper metal width value is
greater than or equal to .501 and less than .781, then the tool will
consider that value as element 3 of fatTblThreshold2.
Consequently, the tool will pick up the (2,3) element value from
fat2DTblFatContactNumber, which is 18, and the (2,3) element
from fat2DTblFatContactMinCuts, which is 3. So, Astro will
use the via whose contactCode value is 18 and use 3 cuts of the
via to connect the lower and upper metal layers.
Both the power and ground routing and the detail routing operations
honor the two-dimensional table rule. A rule violation is flagged as a
DRC error.
If these parameters are not set, Astro uses the original pin width to
determine the fat metal spacing around the pin without considering
the adjacent blockage.
"M1" {
stubSpacing = 0.14
stubThreshold = 0.2
}
0.035 um
K
0.035 um
S1
<Q
W
S2
For example,
Technology {
stubMode = 1
}
Layer "M7" {
stubSpacing
stubThreshold
stubLengthThreshold
}
= 0.24
= 0.24
= 0.28
For example,
Layer
"V3" {
enclosedCutNumNeighbor
=
enclosedCutNeighborRange
=
enclosedCutToNeighborMinSpacing =
}
4
0.4
0.25
For example,
DensityRule {
layer = "M1"
windowSize = 200
minDensity = 20
maxDensity = 80
}
The power and ground routing operation honors the via array rule.
Define this attribute in the via Layer section of the technology file.
For example,
Layer
"VIA5"{
sameNetMinSpacing = 0.28
minSpacing = 0.35
}
Note:
If the sameNetMinSpacing value for the via layer is greater
than the minSpacing value, the router will use the minSpacing
value.
The metal width is less than the value specified with the
sameNetWidthThreshold attribute (W/X).
The notch spacing is less than the value specified with the
sameNetMinSpacing attribute (L/Y).
W
L
X =<5
Y =>10
Metal
"M5" {
sameNetWidthThreshold = 0.5
sameNetMinSpacing = 1.0
}
In such cases, the thin wire width must be wider than the width value
(W) specified with the protrusionFatThresholdTbl attribute.
"M2" {
protrusionTblDim = 2
protrusionFatThresholdTbl = (1.20,2.40)
protrusionLengthLimitTbl = (0.60,0.90)
protrusionMinWidthTbl = (0.30, 0.45)
}
Mode value
Description
Ignore the maximum stack level rule check when all stacked vias
are via arrays.
Check the maximum stack level rule for stacked via arrays.
Ignore the maximum stack level rule check when at least one
stacked via is a via array.
Ignore the maximum stack level rule check when all stacked vias
are aligned via arrays (overlapped with at least two cuts.
The following figure and table show the scope of the maximum stack
level check for each checkViaArrayMaxStackLevel mode when
you specify a maxStackLevel value of 4.
Case A
Case B
Case C
Case D
Case E
M6
M6
M6
M6
M6
M5
M5
M5
M5
M5
M4
M4
M4
M4
M4
M3
M3
M3
M3
M3
M2
M2
M2
M2
M2
M1
M1
M1
M1
M1
checkViaArrayMaxStackLevel Case A
Mode
Violation
Violation
Violation
Violation
Case B
Case C
Case D
Case E
Violation
Violation
Violation
Violation
Violation
neighboringLayerFatThreshold
neighboringLayerFatExtensionRange
neighboringLayerM1RecommendedSpacing
neighboringLayerM2RecommendedSpacing
...
neighboringLayerM12RecommendedSpacing
M3
M3
M3
M3
ext range
ext range
ext range
M2
width
ext range
The syntax is
(axSetRealParam "droute"
"neighboringLayerFatThreshold"0.000)
;; range [0.000,100.000], default=0.000, stored in cell;
;; N: neighboring layer fat threshold (applied to all layers)
(axSetRealParam
"droute""neighboringLayerFatExtensionRange" 0.000)
;; range [0.000,100.000], default=0.000, stored in cell;
;; N: neighboring layer fat extension range (applied to all
;; layers)
(axSetRealParam "droute"
"neighboringLayerM1RecommendedSpacing" 0.000)
;; range [0.000,100.000], default=0.000, stored in cell;
;; N: neighboring layer recommended spacing for M1
(axSetRealParam "droute"
"neighboringLayerM2RecommendedSpacing" 0.000)
;; range [0.000,100.000], default=0.000, stored in cell;
;; N: neighboring layer recommended spacing for M2
...
(axSetRealParam "droute"
"neighboringLayerM12RecommendedSpacing" 0.000)
;; range [0.000,100.000], default=0.000, stored in cell;
;; N: neighboring layer recommended spacing for M12
The syntax is
axSetIntParam droute parallelLengthMode value
Value
Description
Before you set the parallel length rule mode, you must first define the
following attributes in the technology file: fatTblThreshold,
fatTblParallelLength, and fatTblSpacing. For example,
fatTblThreshold = (0,0.201,0.381,1.501,4.501)
fatTblParallelLength = (0,0.381,0.381,1.501,4.501)
fatTblSpacing = (0.1,0.12,0.16,0.5,1.5,
0.12,0.12,0.16,0.5,1.5,
0.16,0.16,0.16,0.5,1.5,
0.5,0.5,0.5,0.5,1.5,
1.5,1.5,1.5,1.5,1.5)
The syntax is
axSetIntParam "droute" "smallJogMinLength" value
Value
Description
The jog length needs to be larger than or equal to 1/4 pitch of the wire
tracks for the routing layer.
The jog length needs to be larger than or equal to 1/2 pitch of the wire
tracks for the routing layer.
When you specify a value of 1 or 2, the small jog rule is checked, and
then fixed by the search-and-repair operation. A violation occurs
when the length of the jog is shorter than 1 or 2 times the quarter
pitch of the wire tracks.
a violation occurs when the length of the jog is shorter than half the
pitch of the wire track.
= "M1"
= "V1"
= 0
= 3
= (0.005,0.015,0.025)
= (0.08,0.06,0)
=
=
=
=
=
=
=
=
"V1"
"M2"
0
0
2
(0.5,1.0)
(0.18,0.36)
(0.05,0.10)
{
layer1
layer2
minSpacing
minEnclosure
fatWireViaKeepoutTblSize
fatWireViaKeepoutWidthThreshold
fatWireViaKeepoutMinSize
fatWireViaKeepoutEnclosure
=
=
=
=
=
=
=
=
"V1"
"M1"
0
0
1
(0.5)
(0.18)
(0.05)
D
Astro Parameters
Crosstalk Parameters
Rectilinear Parameters
Timing Parameters
D-1
Option
Description
operation
The operation for which you are setting a parameter. For example,
place indicates placement, route indicates routing, trackAssign
indicates track assignment, groute indicates global routing, droute
indicates detail routing, xt indicates crosstalk, and so forth.
param
value
Go to http://solvnet.synopsys.com.
Description
best condition
typical condition
worst condition
Range.
The valid values of best condition, typical condition, and
worst condition range between 0 and 999999. The default is 1.
The cto: cell sizing parameter sets the order of cell sizing
in optimization.
"acts"
"acts"
"acts"
"acts"
"acts"
"acts"
"acts"
"acts"
"cto:
"cto:
"cto:
"cto:
"cto:
"cto:
"cto:
"cto:
buffer sizing" 4
buffer relocation" 6
cell sizing" 3
cell relocation" 5
level adjustment" 0
delay insertion" 1
dummy load insertion" 7
reconfiguration" 2
Range.
The valid values of all these parameters range between -1 and 8.
Table D-2 lists the default values of these parameters.
Table D-2 Default Values of Parameters
Parameter Name
Default Value
Default Value
cto: reconfiguration
Range.
The valid values are 0 or 1. The default is 1.
Using this parameter, all gating cells in the clock tree are moved and
then located at the center of their fanout before any other processing.
With the dialog box option, the clock gates will be moved only if
necessary.
Usage.
To force all clock gates to move to the center of their fanout, enter the
following:
axSetIntParam "acts" "move clock gates" 1
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 1.
Description
ECO placement
ECO weight
legalize placement
OV
ECO placement
The ECO placement parameter is used to perform a global ECO
placement after initial clock tree synthesis; that is, before embedded
clock tree optimization. While this parameter is set to 1 by default, the
Range.
The valid values are 0 or 1. The default is 1.
ECO weight
The ECO weight parameter defines an ECO weight that is given to
all cells connected to the clock tree (sinks, inverters, or buffers) to
give preference to clock-related cells during overlap removal.
Usage.
axSetIntParam "acts" "ECO weight" 2
Range.
The valid values of this parameter range between 0 and 6. The
default is 2.
legalize placement
The legalize placement parameter controls whether placement
legalization for cells added by clock tree synthesis is performed or
not. Disabling legalization makes the switches for overlap and ECO
placement ineffective.
Without legalization, buffers will be dropped exactly at the location
deemed optimal by clock tree synthesis. Therefore, not performing
legalization can be useful for debugging to get an upper bound on
quality of results (QoR) and to separate legalization problems from
other issues.
Usage.
To control whether placement legalization is performed for the cells
added by clock tree synthesis, use the following syntax:
axSetIntParam "acts" "legalize placement" 1
Range.
The valid values are 0 or 1. The default is 1.
OV
The OV parameter controls whether overlap removal is used to
legalize clock buffers added by Astro. If overlap removal is used,
every buffer will be individually legalized as soon as it gets created.
If overlap removal is turned on, ECO placement will be automatically
turned off.
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values of this parameter range between 0 and 999999999.
The default is 2147483647.
Description
clustering effort
reclustering iterations
synthesis effort
clustering effort
The clustering effort parameter sets the clustering effort
during clock tree synthesis. Clustering effort is orthogonal to the
number of reclustering iterations. For example, if effort is set to high,
the high-effort clustering will be executed for the number of iterations
determined by the reclustering iterations and synthesis
effort parameters.
Low and medium effort are the same. If high effort is selected, a
more involved clustering algorithm based on pairing is invoked.
Usage.
To set the effort to low, enter the following:
axSetIntParam "acts" "clustering effort" 1
Range.
The valid values of this parameter range between 1 and 3. The
default is 1.
Table D-5 lists the valid values of the clustering effort
parameter.
Table D-5 Valid Values of the clustering effort Parameter
Value
Description
Low effort
Medium effort
High effort
reclustering iterations
The reclustering iterations parameter sets the minimum
number of iterations that the clustering algorithm takes during clock
tree construction. The actual number of iterations is determined by
the product of synthesis effort and reclustering
iterations.
Usage.
To set the minimum number of iterations taken by the clustering
algorithm during clock tree construction, use the following syntax:
axSetIntParam "acts" "reclustering iterations" 4
Range.
The valid values of this parameter range between 0 and 999999. The
default is 4.
synthesis effort
The synthesis effort parameter sets the synthesis effort which
is identical to the Synthesis Effort option in the Clock Common
Options dialog box.
Setting the value in the Clock Common Options dialog box
overwrites the value of the parameter and setting the parameter after
using the dialog box overwrites the dialog box value.
The value of this parameter is multiplied by the value of
reclustering iterations to determine the number of
reclustering iterations actually used.
Usage.
To set a value for synthesis effort, use the following syntax:
axSetIntParam "acts" "synthesis effort" 2
Range.
The valid values of this parameter range between 1 and 3. The
default is 2.
Description
target fanout
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
clock net has a transition time close to the target. This means that
the actual transition time can be slightly bigger or smaller than the
target.
If the clock tree analyzer is used, the target transition value will be
overridden by the clock tree analyzer. This best rise transition target
will override the target: transition delay rise.
Usage.
To set the target of the best rise transition time of each clock net, use
the following syntax:
axSetRealParam "acts" "target: best transition delay rise"
0.000
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Usage.
To set the clock insertion delay, use the following syntax:
axSetRealParam "acts" "target: clock insertion delay" 0.000
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
target fanout
The target fanout parameter sets the fanout target. It can be
used directly by clock tree synthesis when creating the tree topology.
The clustering and buffer level creation will be done such that the
fanout of each clock buffer is close to the target. This means that the
actual fanout can deviate by a few fanouts from the specified target.
Usage.
To set the fanout target, use the following syntax:
axSetIntParam "acts" "target fanout" 32
Range.
The valid values range between 0 and 999999. The default is 32.
Usage.
To control relaxation of the target load with each buffer level, use the
following syntax:
axSetRealParam "acts" "target load relax" 1.000
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
If the clock tree analyzer is used, the target transition value will be
overridden by the clock tree analyzer. This fall transition target will be
overridden if the fall target for best and worst are specified
separately.
Usage.
axSetRealParam "acts" "target: transition delay fall" 0.000
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Range.
The valid values range between 0.000 and 999999.000. The default
is 0.0.
Description
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is -0.5.
Usage.
To limit the maximum insertion delay time of each clock net, use the
following syntax:
axSetRealParam "acts" "rule: maximum insertion delay" 0.000
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0.0.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0.0.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is -0.5.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is -0.5.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0 which will use a default value (2000
um).
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0.0.
Range.
The valid values of this parameter range between 0.000 and
999999.000. The default is 0.0.
this constraint will be applied per gate level; that is, if your clock tree
has several serial gating cells, each subtree can have up to rule
maximum buffer levels levels.
Another thing to note is that when the maximum number of levels is
reached clock tree synthesis will stop any further processing; that is,
if an unrealistic constraint is specified the resulting tree will still
contain DRC violations.
Usage.
To limit the level of buffers clock tree synthesis might add, use the
following syntax:
axSetIntParam "acts" "rule maximum buffer levels" 20
Range.
The valid values range between 0 and 99. The default is 20.
Range.
The valid values range between 0 and 999999. The default is 64.
Description
cto: FF relocation
cto: FF sizing
optimization level
cto: FF relocation
The cto: FF relocation parameter enables or disables flip-flop
relocation during optimization. This parameter is used only for
embedded CTO.
Usage.
To turn on flip-flop relocation during optimization, enter the following:
Range.
The valid values are 0 or 1. The default is 0.
cto: FF sizing
The cto: FF sizing parameter enables or disables flip-flop sizing
during optimization. This parameter is used only for embedded CTO.
Usage.
To turn on flip-flop sizing during optimization, enter the following:
axSetIntParam "acts" "cto: FF sizing" 1
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 0.
optimization level
The optimization level parameter sets the optimization level.
It is the same as the Optimization Effort option in the Clock Common
Options dialog box. Higher values correspond to higher effort.
Usage.
To set the optimization level, use the following syntax:
axSetIntParam "acts" "optimization level" 3
Range.
The valid values of this parameter range between 0 and 999999. The
default is 3.
Description
ECO Route
ECO Route
The ECO Route parameter determines whether ECO route is
performed after postroute clock tree optimization.
Usage.
To perform ECO route after postroute clock tree optimization, enter
the following:
axSetIntParam "acts" "ECO Route" 1
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values of this parameter range between 0 and 999999. The
default is 0.
Range.
The valid values are 0 or 1. The default is 0.
Description
Range.
The valid values of this parameter range between 0.000 and 1.000.
The default is 0.05.
Range.
The valid values of this parameter range between 0.000 and 1.000.
The default is 0.01.
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values of this parameter range between 0 and 3. The
default is 2.
Table D-11 lists the valid values of the minimize placement
changes effort parameter and their description.
Table D-11 Valid Values of the minimize placement changes effort
Parameter
Value
Description
Low effort
Medium effort
High effort
Description
CTA
skew type
Description
Range.
The valid values range between 0 and 99999999. The default is 1.
CTA
The CTA parameter enables or disables the clock tree analyzer.
Clock tree synthesis buffer selection and clustering is driven by
target capacitance and target transition parameters. If the CTA
parameter is set to 1, the user-supplied targets for skew and
insertion delay will be converted to target transition and target
capacitance values that meet the skew and insertion delay targets
with the best overall QoR of the tree.
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 0.
Appendix D: Astro Parameters
D-48
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values range between 0 and 999999. The default is 32.
skew type
The skew type parameter used to set the skew type. It is equivalent
to the skew type selection in the Clock Tree Synthesis dialog box.
Usage.
To set the skew type as global, enter the following:
axSetIntParam "acts" "skew type" 0
Range.
The valid values of this parameter range between 0 and 2. The
default is 0.
Table D-13 lists the valid values of the skew type parameter and their
description.
Table D-13 Valid Values of the skew type Parameter
Value
Description
Global
Local
Useful
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 1.
Clock Tree Synthesis Parameters
D-53
Range.
The valid values of this parameter range between 1 and 3. The
default is 2.
Table D-14 lists the valid values of the wire capacitance
accuracy parameter and their description.
Table D-14 Valid Values of the wire capacitance accuracy Parameter
Value
Description
Low
Medium
High
Description
Description
Usage.
axSetStringParam "acts" "file name: buffer instances"
"buffer.acts"
Usage.
axSetStringParam "acts" "file name: synthesized nets"
"net.acts"
Description
Description
ignore SDC
ignore set_clock_latency
ignore set_clock_transition
ignore set_clock_uncertainty
Usage.
To turn off DRC constraints coming from the library, enter the
following:
axSetIntParam "acts" "ignore library constraints" 1
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 0.
Usage.
To ignore the maximum fanout set in a library, enter the following:
axSetIntParam "acts" "ignore library maximum fanout" 1
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 0.
ignore SDC
The ignore SDC parameter is set to ignore the constraint setting in
the SDC file (DRC set_max_xxx and target values
set_clock_xxx).
Usage.
To ignore constraint setting in the SDC file, enter the following:
Appendix D: Astro Parameters
D-64
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 0.
Range.
The valid values are 0 or 1. The default is 1.
Range.
The valid values are 0 or 1. The default is 0.
ignore set_clock_latency
When set to 1, the ignore set_clock_latency parameter
causes the clock latency set in the SDC file to be ignored. Clock tree
synthesis can use set_clock_latency to specify an insertion
delay target for clock tree synthesis. If the ignore
set_clock_latency parameter is set to 1, this target will not be
applied and the insertion delay will be minimized or the target
specified in the dialog box will be used.
This feature is useful to achieve delay balancing and to avoid pre- to
post-clock tree synthesis differences in IO timing. If both the dialog
box and SDC target are given and this parameter is set to 0, the SDC
setting will override the dialog box.
Usage.
To ignore the clock latency set in the SDC file, enter the following:
axSetIntParam "acts" "ignore set_clock_latency" 1
Range.
The valid values are 0 or 1. The default is 0.
ignore set_clock_transition
When set to 1, the ignore set_clock_transition parameter
causes the clock transition set in the SDC file to be ignored. Clock
tree synthesis can use set_clock_transition to specify a
target for the clock net transition times clock tree synthesis needs to
achieve at the sink pins.
If the ignore set_clock_transition parameter is set to 1, the
target will not be applied and transition times are built according to
the cell library and global limits. In other words, the transition times
at the clock buffers in the tree will adhere only to the rule: max
transition value and stay close to the target: max
transition value.
Even if the parameter is set to 1, the set_clock_transition
value will be considered only at the clock sink pins.
Usage.
To ignore the clock transition set in the SDC file, enter the following:
axSetIntParam "acts" "ignore set_clock_transition" 1
Range.
The valid values are 0 or 1. The default is 0.
ignore set_clock_uncertainty
When set to 1, the ignore set_clock_uncertainty parameter
causes the clock uncertainty set in the SDC file to be ignored. Clock
tree synthesis can use set_clock_uncertainty to specify a
skew target for clock tree synthesis. If the ignore
set_clock_uncertainity parameter is set to 1, the target will
not be applied and the skew will be minimized. If using the
set_clock_uncertainty from SDC is turned on, the SDC
constraint and the dialog box setting are compared, and the tighter
constraint is applied. Therefore, to ensure that the SDC value is
used, set the dialog box to a large dummy value.
Usage.
To ignore clock uncertainty set in the SDC file, enter the following:
axSetIntParam "acts" "ignore set_clock_uncertainty" 1
Range.
The valid values are 0 or 1. The default is 1.
Description
CGHIER_ENABLE_FAST_REPAIR
cg_opt_context_flag
disable_escape_char
dont_touch_nets_connecting_ls_and_io
dont_use_means_dont_touch
enable_ibt
enable_connection_class
max_boolean_syntax_warnings
optimize_mix_signal_net
Description
replace_backslash
save_cell
CGHIER_ENABLE_FAST_REPAIR
The CGHIER_ENABLE_FAST_REPAIR parameter is set to skip the
hierarchy net uniqueness check and hierarchy cell unification during
astRepairHierPreservation.
Usage
axSetIntParam "cg" "CGHIER_ENABLE_FAST_REPAIR" 0
Range
The valid values are 0 or 1. The default is 0.
cg_opt_context_flag
The cg_opt_context_flag parameter controls connection class
constraint and IBT (Instance Based Target) library usage in
optimization.
Usage
To turn on the connection class constraint in optimization, enter the
following:
axSetIntParam "cg" "cg_opt_context_flag" 1
Range
The valid values of this parameter range between 0 and 3. The
default is 0.
Table D-18 lists the valid values of this parameter and their
description.
Table D-18 Valid Values of the cg_opt_context_flag Parameter
Value
Description
Turn on IBT
disable_escape_char
The disable_escape_char parameter determines whether the
enable/disable escape character will be added to the local name of
a hierarchy net. When set to 1, the escape character is added. The
escape character is \ by default.
Usage
axSetIntParam "cg" "disable_escape_char" 0
Range
The valid values are 0 and 1. The default is 0.
dont_touch_nets_connecting_ls_and_io
The dont_touch_nets_connecting_ls_and_io parameter
controls the marking of level_shifter/isolation_cell
connected flat nets as dont_touch.
Usage
To mark level_shifter/isolation_cell connected flat nets
as dont_touch, enter the following:
axSetIntParam "cg" "dont_touch_nets_connecting_ls_and_io" 1
Range
The valid values are 0 or 1. The default is 0.
dont_use_means_dont_touch
When the dont_use_means_dont_touch parameter is set to 0,
the cell instances whose masters are marked as dont_use are
sized to other usable cells.
Usage
axSetIntParam "cg" "dont_use_means_dont_touch" 1
Range
The valid values are 0 or 1. The default is 1.
enable_ibt
The enable_ibt parameter controls IBT usage in Astro.
Usage
To turn on IBT usage, enter the following:
axSetIntParam "cg" "enable_ibt" 1
Range
The valid values are 0 or 1. The default is 0.
enable_connection_class
The enable_connection_class parameter controls connection
class constraint usage in Astro.
Usage
To turn on connection class constraint usage, enter the following:
axSetIntParam "cg" "enable_connection_class" 1
Range
The valid values are 0 or 1. The default is 0.
max_boolean_syntax_warnings
The max_boolean_syntax_warnings parameter causes a
warning message to be printed if the number of warnings is greater
than the specified value. The following warning message appears as
a result of setting this parameter:
"CG: warn_number Invalid syntax warnings."
Usage
axSetIntParam "cg" "max_boolean_syntax_warnings" 5
Range
The valid values of this parameter range between 0 and 1000000.
The default is 5.
optimize_mix_signal_net
The optimize_mix_signal_net parameter is turned on to
consider mixed-signal paths during optimization.
Usage
To consider mixed-signal paths during optimization, enter the
following:
axSetIntParam "cg" "optimize_mix_signal_net" 1
Range
The valid values are 0 or 1. The default is 0.
replace_backslash
The replace_backslash parameter determines whether to
replace a backslash (\) with an underscore (_) in bus net names
during postroute optimization. This is done for compatibility with
PrimeTime.
Usage
To replace a backslash (\) with an underscore (_) during postroute
optimization, enter the following:
axSetIntParam "cg" "replace_backslash" 1
Range
The valid values are 0 or 1. The default is 0.
save_cell
The save_cell parameter determines whether to save cells.
Usage
To save cells, enter the following:
axSetIntParam "cg" "save_cell" 1
Range
The valid values are 0 or 1. The default is 1.
Crosstalk Parameters
Table D-19 lists the Astro crosstalk parameters.
Table D-19 List of Crosstalk Parameters
Parameter
Description
xtDeltaDelayScale
xtDeltaTransScale
xtEnableRailToRailDeltaDelay
xtNoAdaptiveInMediumEffort
xtNumOfTopAggr
xtTimingWindowHighEffort
xtUseAdaptiveDetailWvfmThresh
xtUseNoiseWidth
xtXtalkDetailWvfmThreshold
xtDeltaDelayScale
The xtDeltaDelayScale parameter is used to control delta delay
scaling. It works only in the low-effort mode during crosstalk-induced
delay calculation. In the low-effort mode, the scaling factor is 1.0 by
default, which means no adjustment on delta delay. In the
medium-effort mode, the delta delay is calculated more accurately
and this parameter setting is not required.
You can set the scaling factor between 0.0 and 1.0 for better
correlation with PrimeTime SI.
Usage
To control delta delay scaling, use the following syntax:
axSetRealParam "xt" "xtDeltaDelayScale" float
Range
The valid values are 0.0 to 1.0. The default is 1.0.
xtDeltaTransScale
The xtDeltaTransScale parameter controls the delta transition
time scaling. It works only in the low-effort mode during
crosstalk-induced delay calculation. In the low-effort mode, the
scaling factor is zero by default, which indicates no delta transition
time. In the medium-effort mode, the delta transition is calculated
more accurately and this parameter setting is not required.
Beginning with version W-2004.12-SP5, you can set the scaling
factor between 0.0 and 1000.0 for better correlation with PrimeTime
SI.
Crosstalk Parameters
D-77
Usage
To control the delta transition time scaling, use the following syntax:
axSetRealParam "xt" "xtDeltaTransScale" float
Range
The valid values of this parameter range between 0.0 and 1000.0.
The default is 0.0.
xtEnableRailToRailDeltaDelay
The xtEnableRailToRailDeltaDelay parameter multiplies
delta delay by 1/(upper_slew_threshold lower_slew_threshold).
This option is turned off by default. When the designs slew
thresholds are really close (such as, 40%-60%) and PrimeTime SI is
more pessimistic than Astro, setting this parameter to 1 improves
correlation.
Usage
axSetIntParam "xt" "xtEnableRailToRailDeltaDelay" 0
Range
The valid values are 0 or 1. The default is 0.
xtNoAdaptiveInMediumEffort
The xtNoAdaptiveInMediumEffort parameter lets crosstalk
analysis run faster in the medium-effort mode and provides equally
accurate results. This is achieved by choosing the right model
adaptively.
Usage
To use the most sophisticated model, enter the following:
axSetIntParam "xt" "xtNoAdaptiveInMediumEffort" 0
Range
The valid values are 0 or 1. The default is 0.
xtNumOfTopAggr
The xtNumOfTopAggr parameter controls the number of effective
aggressors to be included in crosstalk noise analysis or induced
delay analysis.
Usage
To specify that all effective aggressors are to be included in the
crosstalk noise or induced delay analysis, enter the following:
axSetIntParam "xt" "xtNumOfTopAggr" 0
Crosstalk Parameters
D-79
Range
The valid values of this parameter range between 0 and
2147483647. The default is 0.
xtTimingWindowHighEffort
The xtTimingWindowHighEffort parameter is used to perform
crosstalk-induced delay analysis with better timing window
correlation. This requires more runtime. This parameter is effective
only when timing window is turned on during crosstalk analysis.
Usage
To perform crosstalk-induced delay analysis with better timing
window correlation, enter the following:
axSetIntParam "xt" "xtTimingWindowHighEffort" 1
Range
The valid values are 0 or 1. The default is 0.
When set to 1, the
xtUseAdaptiveDetailWvfmThresh
The xtUseAdaptiveDetailWvfmThresh parameter is used to
improve transition time correlation with PrimeTime SI. It is effective
in both low and medium effort crosstalk models.
Usage
To improve transition time correlation with PrimeTime SI, enter the
following:
axSetIntParam "xt" "xtUseAdaptiveDetailWvfmThresh"
Crosstalk Parameters
D-81
Range
The valid values are 0 or 1. The default is 0.
xtUseNoiseWidth
The xtUseNoiseWidth parameter controls whether noise width is
used during noise prune. It works only in the low-effort mode. In low
effort, the noise width is not calculated by default. In medium effort,
the noise width is always calculated and used for pruning when
information is available.
Usage
To specify that the noise width is to be estimated and checked
against the internal estimated noise width constraints for pruning,
enter the following:
Appendix D: Astro Parameters
D-82
When set to 0, noise width is not used in the noise pruning operation.
Range
The valid values are 0 or 1. The default is 1.
xtXtalkDetailWvfmThreshold
The xtXtalkDetailWvfmThreshold parameter controls the
switching noise bump height threshold above which a net qualifies
for detailed waveform-based crosstalk analysis. This parameter is
effective only in the medium-effort mode.
Usage
To change the default value of switching noise bump height, use the
following syntax:
axSetRealParam "xt" "xtXtalkDetailWvfmThreshold" 0.35
With this setting, all the nets with switching noise bump height
greater than 0.35 are analyzed with detailed waveform based
crosstalk analysis.
If xtUseAdaptiveDetailWvfmThresh is set to 1, the algorithm is
activated when the switching noise bump height is greater than
minimum (the slew and trip point difference,
xtXtalkDetailWvfmThreshold).
Range
The valid values are 0.000 to 1.000. The default is 0.35.
Crosstalk Parameters
D-83
Description
accessPolyPin
avoidCouplingUser
avoidXtalk
blncdToSkewCntrlRatio
blockEdgeAccess
brokenNetsThresholdPercent
clockBalanced
clockComb
combDistance
combMaxConnections
compactMode
Description
congestionWeight
densityDriven
detourLimitMinNetLen
extraCostsApplyPercent
extraWireLengthOpt
forceUpperLayersForCritNets
horReserveTracks
ignoreViaBlockage
incremental
macroBndryDir
macroBndryExt
macroBndryTrkUtil
macroBndryWidth
macroCornerTrkUtil
Description
mapOnly
maxDetourPercent
netCriticality
noTopLevelBusFeedThroughs
paEqPinNetMaxPort
powerDriven
rcOptByLength
reportDemandOnly
reportEffectiveOverflow
reportGCellDensity
reportNetOrdering
reserveTracksForPowerFile
skewControl
skewControlNetBBLowBound
Description
skewControlWeight
speed
timingDriven
timingWeight
turboMode
VABoundaryToLSWeight
verReserveTracks
xtalkWeight
accessPolyPin
The accessPolyPin parameter specifies whether poly pins can be
used during global routing for connections. If the value is set to 1, the
router can route to poly pins. If the value is set to 0, the router cannot
use poly pins. This parameter has no effect if the current design does
not contain poly pins, as is the case in most designs.
Usage
To access poly pins, enter the following:
axSetIntParam "groute" "accessPolyPin" 1
Range
The valid values are 0 or 1. The default is 1.
Note:
This is the only global route parameter that is saved into the
Milkyway CEL view. It is persistent across different sessions.
avoidCouplingUser
The avoidCouplingUser parameter enables the global router to
space nets during routing. The nets to be considered need to be set
with the Set Net Constraints command. If this parameter is set to 1,
timing spacing will be honored.
Usage
To turn on coupling avoidance on user selected nets, enter the
following:
axSetIntParam "groute" "avoidCouplingUser" 1
Range
The valid values are 0 or 1. The default is 0.
avoidXtalk
The avoidXtalk parameter turns on/disables crosstalk prevention
during global routing. If this parameter is set to 1, the global router
tries to avoid assigning nets with coupling to the same gcell.
Usage
To turn on the crosstalk avoidance, enter the following:
axSetIntParam "groute" "avoidXtalk" 1
Range
The valid values are 0 or 1. The default is 0.
blncdToSkewCntrlRatio
The blncdToSkewCntrlRatio parameter sets a threshold for
turning on the balanced skew control mode. For nets with an aspect
ratio smaller than the parameter value, balanced skew control mode
is enabled. The aspect ratio is calculated based on the bounding box
formed by enclosing the pins.
Usage
To set the aspect-ratio threshold for balanced mode skew control,
use the following syntax:
axSetIntParam "groute" "blncdToSkewCntrlRatio" 3
Range
The valid values of this parameter range between 0 and 100. The
default is 3.
blockEdgeAccess
The blockEdgeAccess parameter allows the global router to
access pins on edges of hard macros. By default, the global router
reaches pins on edges of hard macros. When the parameter is set to
1, it allows the global router is allowed to access or drop vias on
whole macro pins without edges limitation.
Usage
To turn on only macro block edge access, enter the following:
axSetIntParam "groute" "blockEdgeAccess" 1
Range
The valid values are 0 or 1. The default is 1.
brokenNetsThresholdPercent
The brokenNetsThresholdPercent parameter specifies a
threshold for incremental global routing to be performed. This is
effective when incremental is set to 1.
Usage
To specify the maximum broken nets for incremental global route,
enter the following syntax:
axSetIntParam "groute" "brokenNetsThresholdPercent" -1
Range
The valid values of this parameter range between -1 and 100. The
default is -1.
clockBalanced
The clockBalanced parameter turns balanced routing on clock
nets on and off.
Usage
To turn on balanced routing for clock tree synthesized nets, enter the
following:
axSetIntParam "groute" "clockBalanced" 1
Range
The valid values are 0 or 1. The default is 0.
clockComb
The clockComb parameter enables the global router to connect
ports directly to the prerouted clock trunks to minimize clock skew.
Be aware that this requires greater routing resources, if the clock
pins are not close to the clock trunks.
The Comb mode works on designs with pre-existing clock nets.
Usage
To turn on comb routing for clock nets with mesh or trunk, enter the
following:
axSetIntParam "groute" "clockComb" 1
When set to 0, comb routing for clock nets with mesh or trunk is
turned off.
Range
The valid values are 0 or 1. The default is 0.
combDistance
The combDistance parameter sets a distance threshold, in gcell
units, for clock routing to connect clock pins directly to clock nets.
Usage
To set the threshold for connecting clock pins directly to clock nets,
use the following syntax:
axSetIntParam "groute" "combDistance" 2
Range
The valid values of this parameter range between 0 and 50. The
default is 2.
combMaxConnections
The combMaxConnections parameter limits the number of direct
connections allowed to the clock pins from the same clock trunk. The
default value of -1 allows a clock net to be connected to any number
of clock pins.
Usage
To specify the maximum number of pin connections to any clock
strap, use the following syntax:
axSetIntParam "groute" "combMaxConnections" -1
Range
The valid values of this parameter range between -1 and 1000. The
default is -1.
compactMode
The compactMode parameter determines the size of gcell used for
global routing. If it is set to 0, gcells of 1 cellrow height will be created.
If it is set to 1, the global router automatically adjusts the global route
cell size.
Increasing the size of gcell will complete the global routing faster at
the cost of quality as routing becomes coarser.
Usage
To specify the mode to adjust GRC size, enter the following:
axSetIntParam "groute" "compactMode" 1
Range
The valid values of this parameter range between -1 and 10. The
default is 1.
congestionWeight
The congestionWeight parameter specifies the relative
importance of routing congestion versus wire length. As the
parameter value increases, the router tries harder to avoid routing
congestion at the cost of increased wire length.
Usage
To balance routing congestion relative to the wire length, use the
following syntax:
axSetIntParam "groute" "congestionWeight" 4
Range
The valid values of this parameter range between 1 and 12. The
default is 4.
densityDriven
The densityDriven parameter turns density-driven global routing
on or off. In the default mode, the router decides the weight given to
density relative to wire length during global routing. If timing driven
or crosstalk is turned on, global route turns on the densityDriven
automatically.
Usage
To turn on the density-driven mode, enter the following:
axSetIntParam "groute" "densityDriven" 1
Range
The valid values of this parameter range between -1 and 2. The
default is -1.
Table D-21 lists the valid values of this parameter and their effect.
Table D-21 Valid Values of the densityDriven Parameter
Value
Description
-1
detourLimitMinNetLen
The detourLimitMinNetLen parameter controls the way the
global router implements maxDetourPercent on nets. If the value
is set to 0, the router forces maxDetourPercent on all nets. If the
value is set to n, maxDetourPercent is applied only to nets of
length greater than n gcells.
Usage
To apply maxDetourPercent to all nets, enter the following:
axSetIntParam "groute" "detourLimitMinNetLen" 0
Range
The valid values of this parameter range between 0 and 1000000.
The default is 0.
extraCostsApplyPercent
The extraCostsApplyPercent parameter applies the
wireCost and viaCost settings to the top n percent of nets in the
design. The wireCost and viaCost parameters are route
parameters. The route extra cost applies to GR, TA and DR. This
parameter applies the extra cost percentage only for global route.
Usage
To specify extra cost apply percentage on a wire and via, use the
following syntax:
axSetIntParam "groute" "extraCostsApplyPercent" 50
Range
The valid values of this parameter range between 0 and 100. The
default is 50.
extraWireLengthOpt
The extraWireLengthOpt parameter instructs the global router to
run an additional rerouting phase to reduce wire length on nets that
have no congestion. It does not perform any optimization.
Usage
To run an extra pass for optimizing the wire length, enter the
following:
axSetIntParam "groute" "extraWireLengthOpt" 1
Range
The valid values are 0 or 1. The default is 0.
forceUpperLayersForCritNets
The forceUpperLayersForCritNets parameter specifies the
mode for upper layers usage. To improve timing, Astro will route
timing critical nets on upper layers which have lower RC.
Usage
To specify the mode on upper layers usage on critical nets, enter the
following:
Range
The valid values are 0 or 1. The default is 0.
horReserveTracks
The horReserveTracks parameter determines the number of
horizontal free tracks reserved in each gcell.
Usage
To specify the number of horizontal free tracks reserved in each
gcell, use the following syntax:
axSetIntParam "groute" "horReserveTracks" 2
Range
The valid values of this parameter range between 0 and 20. The
default is 2.
ignoreViaBlockage
The ignoreViaBlockage parameter specifies the mode to honor
a via blockage. By default, global route ignores via blockage.
Usage
To ignore via blockage, enter the following:
axSetIntParam "groute" "ignoreViaBlockage" 1
Range
The valid values are 0 or1. The default is 1.
incremental
The incremental parameter controls whether global router runs
incrementally.
Usage
To specify the global route incremental mode, enter the following:
axSetIntParam "groute" "incremental" 1
Range
The valid values of this parameter range between 0 and 2. The
default is 0.
Table D-22 provides the list of valid values of this parameter and their
description.
Table D-22 Valid Values of the incremental Parameter
Value
Description
macroBndryDir
The macroBndryDir parameter controls the use of
macroBndryTrkUtil for layers in different directions. If the value
is set to 1, macroBndryTrkUtil will be applied to layers in both
directions.
Usage
To apply macroBndryTrkUtil to the layers in both directions,
enter the following:
axSetIntParam "groute" "macroBndryDir" 1
Range
The valid values are 0 or 1. The default is 0.
macroBndryExt
The macroBndryExt parameter along with the
macroBndryWidth defines the area in which the global router
obeys macroCornerTrkUtil and macroBndryTrkUtil. By
default, one row or column of gcells is included in the macro
boundary.
This value basically forms the width of the area, where length is
defined by macroBndryWidth.
Usage
To define the area in which the global router obeys
macroCornerTrkUtil and macroBndryTrkUtil, use the
following syntax:
axSetIntParam "groute" "macroBndryExt" -1
Range
The valid values of this parameter range between -5 and 20. The
default is -1.
macroBndryTrkUtil
The macroBndryTrkUtil parameter limits the utilization of tracks
available in the gcells near a macro boundary to a specified
percentage. This parameter is used to control the accessibility of
pins and congestion at the macro boundaries. By default, the router
uses 100% of available tracks in the macro boundary width.
Usage
To set the percent usage of tracks available in the gcells near the
macro boundary, use the following syntax:
axSetIntParam "groute" "macroBndryTrkUtil" 100
Range
The valid values of this parameter range between 0 and 100. The
default is 100.
macroBndryWidth
The macroBndryWidth parameter specifies a distance from the
corners of macros. Within this distance, the global router obeys the
limits on track utilization specified by macroCornerTrkUtil and
macroBndryTrkUtil. By default, one row or column of gcells is
considered from the corners of the macro.
Usage
To specify the distance from the corners of the macros within which
limits on track utilization apply, use the following syntax:
axSetIntParam "groute" "macroBndryWidth" 1
Range
The valid values of this parameter range between -1 and 20. The
default is 1.
macroCornerTrkUtil
The macroCornerTrkUtil parameter limits the utilization of
tracks available in the gcells near a macro corner to a specified
percentage. This parameter is used to control the accessibility of
pins and congestion at the macro corners. By default, the router uses
100% of available tracks in the macro boundary width.
Usage
To set the percent usage of tracks available in the gcells near the
macro corner, use the following syntax:
axSetIntParam "groute" "macroCornerTrkUtil" 100
Range
The valid values of this parameter range between 0 and 100. The
default is 100.
mapOnly
The mapOnly parameter specifies whether the router generates the
congestion map based on global routing without creating the global
wires.
Usage
To generate the congestion map and the glinks, enter the following:
axSetIntParam "groute" "mapOnly" 0
Range
The valid values are 0 or 1. The default is 0.
maxDetourPercent
The maxDetourPercent parameter directs the global router to
have no more than the specified percentage of detours on any net. If
the value is set to -1, the router is free to make any number of detours
(or none).
Usage
To direct the global router to have no more than the specified
percentage of detours on any net, use the following syntax:
Range
The valid values of this parameter range between -1 and 1000. The
default is -1.
netCriticality
The netCriticality parameter determines the order in which the
global router routes the nets during initial route. Net criticality can be
set on nets in the design by using the Scheme function
dbSetNetCriticality.
If this parameter is set to 1, the global router first routes the nets with
higher criticality value. If the value is set to 0, net criticality has no
effect on routing order. However, net criticality always has an effect
on the congestion cost.
Usage
To turn on the net-criticality mode, enter the following:
axSetIntParam "groute" "netCriticality" 1
Range
The valid values are 0 or 1. The default is 1.
noTopLevelBusFeedThroughs
The noTopLevelBusFeedThroughs parameter determines
whether feedthroughs are allowed on bus signals.
Usage
To allow feedthroughs on bus signals during pin assignment, enter
the following:
axSetIntParam "groute" "noTopLevelBusFeedThroughs" 1
Range
The default values are 0 or 1. The default is 0.
paEqPinNetMaxPort
Setting the paEqPinNetMaxPort parameter to 1 creates
equivalent pins for nets with no more than n ports.
Usage
To specify the number of ports on nets, use the following syntax:
axSetIntParam "groute" "paEqPinNetMaxPort" 20
Range
The valid values of this parameter range between 0 and 1000. The
default is 20.
powerDriven
The powerDriven parameter turns power-driven global routing on
or off.
Usage
To turn on the power-driven mode, enter the following:
axSetIntParam "groute" "powerDriven" 1
Range
The valid values are 0 or 1. The default is 0.
rcOptByLength
The rcOptByLength parameter controls the choice of layers for
global router to reduce RC. The global router chooses layers with
lower RC values based on the value of this parameter.
Usage
To turn on RC-based layer bias mode, enter the following:
axSetIntParam "groute" "rcOptByLength" 1
Range
The valid values of this parameter range between 0 and 2. The
default is 1.
Table D-23 lists the valid values of this parameter and their effect.
Table D-23 Valid Values of the rcOptbyLength Parameter
Value
Description
reportDemandOnly
The reportDemandOnly parameter specifies the mode to report
demand only. In this mode, Astro performs virtual route only, with no
reroute phases. In the log file, it reports average gcell capacity per
layer.
Usage
To report demand, enter the following:
axSetIntParam "groute" "reportDemandOnly" 0
Range
The valid values are 0 or 1. The default is 0.
reportEffectiveOverflow
The reportEffectiveOverflow parameter specifies the mode
for generating an effective overflow report.
Usage
To report effective overflow, enter the following:
Global Route Parameters
D-107
Range
The valid values are 0 or 1. The default is 0.
reportGCellDensity
The reportGCellDensity parameter controls reporting of gcell
density for each layer. In density-driven mode, the router generates
a report of gcell density. However, this parameter is independent of
the density-driven switch.
Usage
To specify the mode to generate a gcell density report, enter the
following:
axSetIntParam "groute" "reportGCellDensity" 1
Range
The valid values are 0 or 1. The default is 0.
reportNetOrdering
The reportNetOrdering parameter specifies the number of nets
to be reported according to the routing order. By default, the global
router does not report on net ordering. If this parameter is set to n,
global route will report the first n nets in the order of routing.
Usage
To turn off report net ordering, enter the following:
axSetIntParam "groute" "reportNetOrdering" -1
When set to 0, net ordering is reported for the first 100 nets.
Range
The valid values of this parameter range between -1 and 1000. The
default is -1.
reserveTracksForPowerFile
The file indicated by the reserveTracksForPowerFile
parameter is used to define the percentage of routing tracks on each
layer that are reserved for power routing. For example,
reserveTracksForPowerFile = "reservedTracks.rc"
skewControl
The skewControl parameter turns skew control on or off during
global routing. If the value is set to 1, the global router tries to
minimize the gross delay in net skew. Skew control applies to all
signal nets (except for small nets) but skew control for clock nets
occurs only when clockBalanced is set to 1.
Usage
To turn on skew control pattern routing, enter the following:
axSetIntParam "groute" "skewControl" 1
Range
The valid values are 0 or 1. The default is 0.
skewControlNetBBLowBound
The skewControlNetBBLowBound parameter determines which
nets are considered for skew control during global routing. The
choice is made based on the size of the net measured in number of
gcells. Only nets with size greater than the specified value will be
considered for skew control.
Usage
To specify the minimum size (in gcells) for nets to be subject to skew
control, use the following syntax:
axSetIntParam "groute" "skewControlNetBBLowBound" 5
Range
The valid values of this parameter range between 1 and 100. The
default is 5.
skewControlWeight
The skewControlWeight parameter determines the importance
given to skew control on the net during global routing. You can set
the skew control weight from 1 to 10 based on net criticality.
Usage
To specify the weight of skew control, enter the following syntax:
axSetIntParam "groute" "skewControlWeight" 5
Range
The valid values of this parameter range between 0 and 10. The
default is 5.
speed
The speed parameter specifies the effort at which the global router
should run. The global router runs a different number of phases,
depending on the specified value. It is recommended you run the
router in default mode.
Usage
To perform global routing in the medium-effort mode, enter the
following:
axSetIntParam "groute" "speed" 2
Range
The valid values of this parameter range between 0 and 3. The
default is 2.
Table D-24 lists the default values of this parameter and their effect.
Table D-24 Valid Values of the speed Parameter
Value
Description
timingDriven
The timingDriven parameter turns timing-driven global routing on
or off. The timingWeight parameter controls the trade-off between
timing and wire length during global routing. By default, timing-driven
mode is turned off.
Usage
To turn on timing-driven mode, enter the following syntax:
axSetIntParam "groute" "timingDriven" 1
Range
The valid values are 0 or 1. The default is 0.
timingWeight
The timingWeight parameter sets the weight given to the timing
relative to wire length during global routing. This parameter is
effective only in timing-driven mode.
Usage
To set the timing weight to 4, enter the following:
axSetIntParam "groute" "timingWeight" 4
Range
The valid values of this parameter range between 1 and 7. The
default is 4.
turboMode
The turboMode parameter is used to improve runtime.
Usage
To turn on turbo mode, enter the following:
axSetIntParam "groute" "turboMode" 1
Range
The valid values of this parameter range between 0 and 3. The
default is 1.
Table D-25 lists the values of this parameter and their effect.
Table D-25 Valid Values of the turboMode Parameter
Value
Description
VABoundaryToLSWeight
The VABoundaryToLSWeight parameter is used in multivoltage
mode. It specifies the value to adjust the cost for a level shifter
connection when switching voltage area from one to another.
Usage
To specify the cost value for level shifter connection, enter the
following syntax:
axSetIntParam "groute" "VABoundaryToLSWeight" 0
Range
The valid values of this parameter range between 0 and 10, The
default is 0.
verReserveTracks
The verReserveTracks parameter determines the number of
vertical free tracks reserved in each gcell.
Usage
To specify the number of vertical free tracks reserved in each gcell,
use the following syntax:
axSetIntParam "groute" "verReserveTracks" 2
Range
The valid values of this parameter range between 0 and 20. The
default is 2.
xtalkWeight
The xtalkWeight parameter defines the weight given to crosstalk
prevention during global routing.
Usage
To specify the weight given to crosstalk prevention during global
routing, use the following syntax:
axSetIntParam "groute" "xtalkWeight" 4
Range
The valid values of this parameter range between 0 and 64. The
default is 4.
Description
aggOpt
buf_ins_hold
flag_cr_opt
hfn_fanout_threshold
hfn_max_fanouts
max_iteration
max_level_buffer
max_runtime
Description
max_utilization
move_flip_flop
no_new_instance
ov_max_displaced_cells
ov_max_displacement
pds_message_level
pr_use_fpclass
slack_range_hold_max
slack_range_hold_min
slack_range_setup_max
slack_range_setup_min
Description
target_hold_slack
target_setup_slack
target_utilization
topo_only
use_child_router
use_global_cost
wire_delay_model
xtalk_noise_limit
aggOpt
The aggOpt parameter determines whether aggressors are
optimized during postroute optimization signal integrity flow.
Usage
To optimize the aggressors during postroute optimization signal
integrity flow, enter the following:
Range
The valid values are 0 or 1. The default is 1.
buf_ins_hold
The buf_ins_hold parameter controls the insertion of buffers
during hold optimization that is performed in postroute optimization.
Usage
To insert buffers during hold optimization, enter the following:
axSetIntParam "pds" "buf_ins_hold" 1
Range
The valid values are 0 or 1. The default is 0.
flag_cr_opt
The flag_cr_opt parameter controls whether critical regions are
fixed during placement optimization. When this parameter is set,
additional buffers are inserted.
Usage
To fix critical regions during placement optimization, enter the
following:
axSetIntParam "pds" "flag_cr_opt" 1
Range
The valid values are 0 or 1. The default is 1.
hfn_fanout_threshold
The hfn_fanout_threshold parameter sets the threshold value
for the number of fanouts sufficient to trigger high-fanout
optimization. This value is persistent and stored in the CEL view.
Usage
To specify the threshold value for the number of fanouts to trigger
high-fanout optimization, use the following syntax:
axSetIntParam "pds" "hfn_fanout_threshold" 40
Range
The valid values of this parameter range between 2 and 10000000.
The default is 40.
hfn_max_fanouts
The hfn_max_fanouts parameter is used to set the maximum
number of fanouts for a buffer used for high-fanout optimization.
Usage
To specify the maximum number of fanouts for a buffer used for
high-fanout optimization, use the following syntax:
Range
The valid values of this parameter range between 4 and 100. The
default is 40.
max_iteration
The max_iteration parameter sets the maximum number of
iterations for setup and hold fixing while running astPostPS,
astSetUpFix, astHoldFix, and pdsMoveCell. Setup and hold
fixing stops when the specified maximum number of iterations is
reached.
Usage
To set the maximum number of iterations for setup and hold fixing,
enter the following syntax:
axSetIntParam "pds" "max_iteration" 100000
Range
The valid values range between 0 and 100000. The default is
100000.
max_level_buffer
The max_level_buffer parameter is used to set the maximum
number of levels of buffers inserted in high-fanout optimization. Do
not change the default value of this parameter without specific
design requirement.
Usage
To specify the level of buffers inserted in the high-fanout optimization,
use the following syntax:
axSetIntParam "pds" "max_level_buffer" 6
Range
The valid values of this parameter range between 1 and 100. The
default is 6.
max_runtime
The max_runtime parameter sets a maximum runtime for setup
and hold fixing while running astPostPS, astSetupFix,
astHoldFix, and pdsMoveCell. Setup and hold fixing stops on
reaching the specified maximum runtime.
Usage
To set a maximum runtime for setup and hold fixing while running
astPostPS, astSetupFix, astHoldFix, and pdsMoveCell,
use the following syntax:
axSetRealParam "pds" "max_runtime" 604800.000
Range
The valid values range between 0.0 and 2419200.0. The default is
604800.0.
max_utilization
The max_utilization parameter sets a maximum utilization of
the design before PDS optimization stops. You can control this
parameter value if the chip design and congestion requirements are
stringent.
Usage
To set maximum utilization of the design before PDS optimization
stops, use the following syntax:
axSetRealParam "pds" "max_utilization" 95.000
Range
The valid values of this parameter range between 5.000 to 100.000.
The default is 95.000.
move_flip_flop
The move_flip_flop parameter determines whether flip-flop
movement is allowed for placement-driven synthesis (PDS)
optimization (post CTS). The flip-flop movement changes the clock
tree; therefore, do not use this parameter after the clock tree is
created.
Usage
To allow flip-flop movement for PDS optimization, enter the following:
axSetIntParam "pds" "move_flip_flop" 1
Range
The valid values are 0 or 1. The default is 0.
no_new_instance
The no_new_instance parameter is used to prevent the addition
of new instances while running astPostPS, astTranFix,
astCapFix, and astHoldFix.
Usage
To prevent the addition of new instances while running astPostPS,
astTranFix, astCapFix, and astHoldFix, enter the following:
axSetIntParam "pds" "no_new_instance" 0
Range
The valid values are 0 or 1. The default is 0.
ov_max_displaced_cells
The ov_max_displaced_cells parameter specifies the
maximum number of cells to be moved during overlap.
Usage
To specify the maximum number of cells to be moved during overlap,
use the following syntax:
axSetIntParam "pds" "ov_max_displacement" 500
Range
The valid values range between -1 and 500. The default is -1.
ov_max_displacement
The ov_max_displacement parameter specifies the distance of
maximum displacement (in microns) during overlap.
Usage
To define the distance of maximum displacement during overlap, use
the following syntax:
axSetIntParam "pds" "ov_max_displacement" 1000
Range
The valid values range between -1 and 1000. The default is -1
pds_message_level
The pds_message_level parameter controls the level of detail in
the messaging report in the log file during optimization.
Usage
To receive a messaging report in the log file during optimization for
every buffer insertion, deletion, cell sizing, and so on, enter the
following:
axSetIntParam "pds" "pds_message_level" -1
Range
The valid values range between -1 and 10. The default is -1.
pr_use_fpclass
Set the pr_use_fpclass parameter to 1 when you to want to use
the footprint class.
Two cells are defined as footprint-equivalent if they have identical
physical layout, that is, the pin locations and names are identical,
vias and blockages are identical, and they are of the same size.
Usage
To use the footprint class, enter the following:
axSetIntParam "pds" "pr_use_fpclass" 1
Range
The valid values are 0 or 1. The default is 0.
slack_range_hold_max
The slack_range_hold_max parameter sets the maximum hold
slack for slack range optimization.
Usage
To set the maximum hold slack for slack range optimization, use the
following syntax:
Range
The valid values of this parameter range between
-99999996802856924650656260769173209088.000 and
99999996802856924650656260769173209088.000. The default is
0.000.
slack_range_hold_min
The slack_range_hold_min parameter sets the minimum hold
slack for slack range optimization.
Usage
To set the minimum hold slack for slack range optimization, use the
following syntax:
axSetRealParam "pds" "slack_range_hold_min" -100.000
Range
The valid values of this parameter range between
-99999996802856924650656260769173209088.000 and
99999996802856924650656260769173209088. The default is
-100.000.
slack_range_setup_max
The slack_range_setup_max parameter sets the maximum
setup slack for slack range optimization.
Usage
To set the maximum setup slack for slack range optimization, use the
following syntax:
axSetRealParam "pds" "slack_range_setup_max" 0.100
Range
The valid values of this parameter range between
-99999996802856924650656260769173209088.000 and
99999996802856924650656260769173209088.000. The default is
0.100.
slack_range_setup_min
The slack_range_setup_min parameter sets the minimum
setup slack value for slack range optimization.
Usage
To set the minimum setup slack value for slack range optimization,
use the following syntax:
axSetRealParam "pds" "slack_range_setup_min" -100.000
Range
The valid values of this parameter range between
-99999996802856924650656260769173209088.000 and
99999996802856924650656260769173209088. The default is
-100.000.
target_hold_slack
The target_hold_slack parameter sets the target hold time
value for PDS optimization to stop.
Usage
To specify the target slack in hold time for PDS optimization to stop,
use the following syntax:
axSetRealParam "pds" "target_hold_slack" 0.000
Range
The valid values of this parameter range between -1000.000 to
1000.000. The default is 0.000.
target_setup_slack
The target_setup_slack parameter specifies the target setup
time value. This value controls PDS optimization that is
recommended to do iterative change according to the slack
requirement of the design during postroute /postplace optimization.
Usage
To specify the target slack in setup time for PDS optimization to stop,
use the following syntax:
axSetRealParam "pds" "target_setup_slack" 0.100
Range
The valid values of this parameter range between -1000.000 to
1000.000. The default is 0.100.
target_utilization
The target_utilization parameter sets the target utilization
value for area recovery to stop. In some cases, it can be used for
controlling the congestion distribution effectively.
Usage
To set the target utilization for area recovery to stop, use the following
syntax:
axSetRealParam "pds" "target_utilization" 50.000
Range
The valid values of target_utilization range between 0.000
and 100.000. The default is 50.
topo_only
The topo_only parameter controls the use of topology-based
techniques during postroute optimization flow.
Usage
To use topology-based techniques during postroute optimization
flow, enter the following:
axSetIntParam "pds" "topo_only" 1
Range
The valid values are 0 or 1. The default is 1.
use_child_router
The use_child_router parameter controls the use of a child
router to reduce peak memory usage in the routing engine when it is
called during optimization. For example, as in ECO routing during
postroute optimization.
Usage
To reduce peak memory usage in the routing engine when it is called
during optimization, enter the following:
axSetIntParam "pds" "use_child_router" 0
Range
The valid values range between 0 and 2. The default is 0.
Table D-27 provides a description of the valid values of the
use_child_router parameter.
Table D-27 Valid Values of the use_child_router Parameter
Value
Description
Description
use_global_cost
When set to 1, the use_global_cost parameter turns on the
global cost function for astPostRouteOpt. Using this parameter,
Astro performs optimization based on a cost function with each
metric, such as setup, hold, trans, cap, and so on.
The use_global_cost parameter performs optimization to accept
or reject certain transforms. It can used only before
astPostRouteOpt and does not have any user control to change
the cost.
Usage
To turn on the global cost function for the astPostRouteOpt
command, enter the following:
axSetIntParam "pds" "use_global_cost" 1
Range
The valid values are 0 or 1. The default is 0.
wire_delay_model
The wire_delay_model parameter sets a wire delay model during
optimization. It overrides the GUI option in the Timing Setup dialog
box. When the optimization is completed, the original delay model is
restored.
The wire_delay_model parameter can be changed in each stage
of optimization. As timing setup automatically takes care of the delay
models to be used in each design stage, changing this parameter is
not recommended. This parameter is persistent and stored in the
CEL view.
Usage
To set a wire delay model during optimization, use the following
syntax:
axSetIntParam "pds" "wire_delay_model" 0
Range
The valid values of this parameter range between 0 and 2. The
default is 0.
Table D-28 lists the valid values of wire_delay_model and their
associated delay models.
Table D-28 Valid Values of the wire_delay_model parameter
Value
Description
ATA_ELMORE_WIREDELAY
ATA_AWE_WIREDELAY
ATA_ARNOLDI_WIREDELAY
xtalk_noise_limit
The xtalk_noise_limit parameter determines the noise limit
value used by crosstalk optimization during Pre/Post-Placement
optimization and Post-CTS optimization. It controls area recovery
during these stages.
Usage
To set the noise limit value used by crosstalk optimization during Pre/
Post-Placement optimization and Post-CTS optimization, use the
following syntax:
axSetRealParam "pds" "xtalk_noise_limit" 0.450
Range
The valid values of this parameter range between 0.000 and 1.000.
The default is 0.450.
Rectilinear Parameters
Table D-29 lists the Astro rectilinear parameters.
Table D-29 List of Rectilinear Parameters
Parameter
Description
allowMovePG
controlparameter
core2Bottom
Description
core2Left
core2Right
core2Top
doubleBack
flipfirst
forceTrackAlignment
lengthMode
macros
rotation
rowDirction
rowRatio
rpinECO
Rectilinear Parameters
D-135
Description
startfirst
stdcells
utilization
allowMovePG
The allowMovePG parameter controls the movement of power and
ground pins on a rectilinear design.
Usage
To move power and ground pins, enter the following:
axSetIntParam "rectilinear" "allowMovePG" 1
When set to 0, the power and ground pins are not moved.
Range
The valid values are 0 or 1. The default is 0.
controlparameter
The controlparameter parameter specifies the shape of a
floorplan.
Usage
To add an L-shaped rectilinear object, enter the following:
axSetIntParam "rectilinear" "controlparameter" 1
Range
The valid values of this parameter range between 1 and 5. The
default is 1.
Table D-30 lists the valid values of controlparameter and their
associated shapes.
Table D-30 Valid Values of controlparameter
Value
Description
L shape
T shape
U shape
Cross shape
core2Bottom
The core2Bottom parameter specifies the distance between the
bottom side of the core and top side of the boundary.
Usage
To specify the distance between the bottom side of the core and top
side of the boundary, use the following syntax:
axSetRealParam "rectilinear" "core2Bottom" 10.000
Rectilinear Parameters
D-137
Range
The valid values of this parameter range between 0.0 and 100000.0.
The default is 10.0.
core2Left
The core2Left parameter specifies the distance between the left
side of the core and right side of the boundary.
Usage
To specify the distance between the left side of the core and right
side of the boundary, use the following syntax:
axSetRealParam "rectilinear" "core2Left" 10.000
Range
The valid values of this parameter range between 0.0 and 100000.0.
The default is 10.0.
core2Right
The core2Right parameter specifies the distance between the
right side of the core and left side of the boundary.
Usage
To specify the distance between the right side of the core and left
side of the boundary, use the following syntax:
axSetIntParam "rectilinear" "core2Right" 10.000
Range
The valid values of this parameter range between 0.0 and 100000.0.
The default is 10.0.
core2Top
The core2Top parameter specifies the distance between the top
side of the core and bottom side of the boundary.
Usage
To specify the distance between the top side of the core and bottom
side of the boundary, use the following syntax:
axSetRealParam "rectilinear" "core2Top" 10.000
Range
The valid values of this parameter range between 0.0 and 100000.0.
The default is 10.0.
doubleBack
The doubleBack parameter is set when you want the core to
contain pairs of cell rows, with one row in each pair flipped.
Usage
If you want the core to contain pairs of cell rows, with one row in each
pair flipped, enter the following:
axSetIntParam "rectilinear" "doubleBack" 1
Rectilinear Parameters
D-139
Range
The valid values are 0 or 1. The default is 0.
flipfirst
The flipfirst parameter is used if you selected Double Back and
want a flipped row at the bottom of a horizontal core area or left side
of a vertical core area.
Usage
If you selected Double Back and want a flipped row at the bottom of
a horizontal core area or left side of a vertical core area, enter the
following:
axSetIntParam "rectilinear" "flipfirst" 1
Range
The valid values are 0 or 1. The default is 0.
forceTrackAlignment
When set to 1, the forceTrackAlignment parameter forces the
alignment of tracks in double-back mode.
Usage
To force track alignment, enter the following:
axSetIntParam "rectilinear" "forceTrackAlignment" 1
Range
The valid values are 0 or 1. The default is 0.
lengthMode
The lengthMode parameter is used to calculate the core utilization
on a rectilinear design.
Usage
To calculate the core utilization on a rectilinear design, enter the
following:
axSetIntParam "rectilinear" "lengthMode" 0
Range
The valid values are 0 or 1. The default is 0.
macros
The macros parameter controls movement of macros.
Usage
To turn on macro movement, enter the following:
axSetIntParam "rectilinear" "macros" 0
Rectilinear Parameters
D-141
Range
The valid values are 0 or 1. The default is 0.
rotation
The rotation parameter rotates a rectilinear object.
Usage
To rotate a rectilinear object by 90 degrees, enter the following:
axSetIntParam "rectilinear" "rotation" 1
Range
The valid values of this parameter range between 0 and 3. The
default is 0.
Table D-31 lists the valid values of rotation parameter with their
description.
Table D-31 Valid Values of the rotation Parameter
Value
Description
Rotation is 0 degree
Rotation is 90 degree
rowDirction
The rowDirction parameter sets the row direction as horizontal or
vertical.
Usage
To set the row direction as horizontal, enter the following:
axSetIntParam "rectilinear" "rowDirction" 0
Range
The valid values are 0 or 1. The default is 0.
rowRatio
The rowratio parameter specifies the amount of channel space
that needs to be provided for routing between cell rows. The smaller
the number, the more space Astro leaves for routing channels.
Usage
To indicate the amount of channel space that needs to be provided
for routing between the cell rows, enter the following syntax:
axSetRealParam "rectilinear" "rowRatio" 0.00
Range
The valid values range from 0.0 to 1.0. The default is 1.0.
Rectilinear Parameters
D-143
rpinECO
The rpinECO parameter controls ECO mode for rectilinear pin
placement.
Usage
To turn on ECO mode for rectilinear pin placement, enter the
following:
axSetIntParam "rectilinear" "rpinECO" 1
Range
The valid values are 0 or 1. The default is 0.
startfirst
The startfirst parameter is used if you selected Double Back
and want a pair of rows at the bottom of a horizontal core area or left
side of a vertical core area.
Usage
If you want a pair of rows at the bottom of a horizontal core area or
left side of a vertical core area, enter the following:
axSetIntParam "rectilinear" "startfirst" 1
Range
The valid values are 0 or 1. The default is 1.
stdcells
The stdcells parameter controls movement of standard cells.
Usage
To move standard cells, enter the following:
axSetIntParam "rectilinear" "stdcells" 0
Range
The valid values are 0 or 1. The default is 0.
utilization
The utilization parameter specifies the core utilization area for
cell placement, as a ratio of the total cell area (standard and macro
cells) to the core area.
Usage
To set the set the smallest core utilization area value for cell
placement, enter the following:
axSetRealParam "rectilinear" "utilization" 0.0
Rectilinear Parameters
D-145
Range
The valid values of this parameter range between 0.0 and 1.0. The
default is 0.8.
Timing Parameters
Table D-32 lists the Astro timing parameters.
Table D-32 List of Timing Parameters
Parameter
Description
all_macro_as_VR_block
ata_crp_transition
ata_crpr_threshold_ps
capture_path_propagate_worst_slew
case_analysis_disable_entire_path
case_analysis_sequential_propagation
clock_cell_has_multiple_edge
Description
clock_gating_propagate_enable
clock_tree_report_debug_mode
disable_cond_default_arcs
driving_cell_include_cell_delay
early_launch_at_borrowing_latches
group_path_opt
max_RG_size_multiplier
multicycle_hold_follow_setup
non_unate_clock_compatibility
Timing Parameters
D-147
Description
print_Clock_Timing_For_Mixed_Edges
pulse_latch_as_ICG_cell
rc_degrade_min_slew_when_rd_less_t
han_rnet
remove_Escape_From_Bus
report_timing_through_sync_pin
rpt_max_cap_multiplier
rpt_max_tran_multiplier
rpt_min_cap_multiplier
Description
rpt_min_tran_multiplier
splitEK
all_macro_as_VR_block
The all_macro_as_VR_block parameter determines whether a
macro that is not blocked on all the metal layers is treated as a virtual
route blockage.
Usage
To consider all macros as virtual route blockages even if they do not
block all metal layers, enter the following syntax:
axSetIntParam "ata" "all_macro_as_VR_block" 1
If set to 0, macros that do not block all the metal layers are not treated
as blockages.
Range
The valid values are 0 or 1. The default is 0.
Timing Parameters
D-149
ata_crp_transition
The ata_crp_transition parameter determines how the clock
reconvergence pessimism value is computed depending upon the
transition sense at common point.
Usage
To use the minimum of rise and fall clock reconvergence pessimism
values in the event of a mismatch at a common point, enter the
following:
axSetIntParam "ata" "ata_crp_transition" 0
Range
The valid values are 0 (normal) or 1(same_transition). The
default is 0.
ata_crpr_threshold_ps
The ata_crpr_threshold_ps parameter specifies amount of
pessimism that CRPR is allowed to leave in the timing report. This
parameter is measured in picoseconds (ps), regardless of the main
library units.
The larger the value, the faster the runtime when CRPR is active.
The recommended setting is about one half of the stage (gate plus
net) delay of a typical stage in the clock network. This value provides
a reasonable trade-off between accuracy and runtime in most cases.
You might want to use large values during the design phase and
small values during signoff. Experiment and try a different value
when moving to a different technology.
Usage
To specify the amount of pessimism that CRPR is allowed to leave in
a report, enter the following syntax:
axSetRealParam "ata" "ata_crpr_threshold_ps" 20.000
Range
The valid values of this parameter range between 1.0 and
99999996802856924650656260769173209088.000. The default is
20.0. The threshold values range between 1 and 1e+38
picoseconds.
capture_path_propagate_worst_slew
The capture_path_propagate_worst_slew parameter is used
for improved correlation with PrimeTime under bc_wc timing
analysis. It controls the propagation of worst slew at merge points in
the capture clock path.
Timing Parameters
D-151
Usage
To improve correlation with PrimeTime under bc_wc timing analysis,
enter the following:
axSetIntParam "ata" "capture_path_propagate_worst_slew" 0
Range
The valid values are 0 or 1. The default is 1.
During bc_wc timing analysis, when the parameter is set to the
default value at slew merge points along the capture clock path,
Astro propagates the worst slew (fastest slew during max delay
analysis and slowest slew in min delay analysis) forward. This makes
the analysis in Astro pessimistic when compared to PrimeTime.
Set this parameter to 0 to correlate with PrimeTime.
case_analysis_disable_entire_path
The case_analysis_disable_entire_path parameter
determines whether only the last edge is disabled or all the edges
are disabled along a path where a constant is propagated.
Usage
axSetIntParam "ata" "case_analysis_disable_entire_path" 0
When the parameter is set to 1, it disables all those edges along the
path until the constant does not affect the design anymore. It means
that all affected edges along the path are disabled. So, timing
information cannot propagate through those timing arcs. Therefore,
both arrival time and slope values are affected.
If an arc is disabled, both arrival time and transition time are not
propagated through the arc.
Range
The valid values are 0 or 1. The default is 0.
case_analysis_sequential_propagation
The case_analysis_sequential_propagation parameter
determines whether case analysis is propagated across sequential
cells.
Usage
To enable case analysis constants to propagate across sequential
cells, enter the following:
axSetIntParam "ata" \
"case_analysis_sequential_propagation" 1
Range
The valid values are 0 or 1. The default is 0.
Timing Parameters
D-153
clock_cell_has_multiple_edge
The clock_cell_has_multiple_edge parameter reduces the
clock traverse time for reconvergent clock networks.
Astro supports this parameter starting from version Y-2006.06-SP3.
Usage
To reduce the clock traverse time for reconvergent clock networks,
enter the following:
axSetIntParam "ata" "clock_cell_has_multiple_edge" 1
Range
The valid values are 0 or 1. The default is 0.
clock_gating_propagate_enable
The clock_gating_propagate_enable parameter controls
whether the delay and slew of the clock signal or the gating signal is
propagated to the output of a cell, where clock gating occurs.
Usage
By default, when the parameter is set to 1, Astro propagates the
delay and slew of the gating signal. Setting the parameter to 1 is
recommended when the output of the gating cell goes to a data pin.
To allow the delay and slew from the clock line set the parameter to 0:
axSetIntParam "ata" "clock_gating_propagate_enable" 0
Range
The valid values are 0 or 1. The default is 1.
clock_tree_report_debug_mode
The clock_tree_report_debug_mode parameter, when turned
on, generates astReportClockTree output that exactly matches
with IC Compiler exception pins report.
Astro supports this parameter starting from version Y-2006.06-SP3.
Usage
To get a report that exactly matches the IC Compiler report, enter the
following:
axSetIntParam "ata" "clock_tree_report_debug_mode" 1
Range
The valid values are 0 or 1. The default is 0.
Timing Parameters
D-155
disable_cond_default_arcs
The disable_cond_default_arcs parameter enables or
disables the default nonconditional timing arcs between pins that
have conditional arcs.
Usage
To disable nonconditional timing arcs between any pair of pins that
have at least one conditional arc, enter the following:
axSetIntParam "ata" "disable_cond_default_arcs" 1
Range
The valid values are 0 or 1. The default is 0.
driving_cell_include_cell_delay
The driving_cell_include_cell_delay parameter
determines whether to include or ignore the cell delay of a driving cell
in the timing path delay.
Usage
To include the cell delay of a driving cell in the timing path delay,
enter the following:
axSetIntParam "ata" "driving_cell_include_cell_delay" 1
When set to 0, the cell delay of a driving cell is ignored in the timing
path delay.
Range
The valid values are 0 or 1. The default is 1.
early_launch_at_borrowing_latches
When set to 1, the early_launch_at_borrowing_latches
parameter removes clock latency pessimism from the launch times
for paths that begin at the data pins of transparent latches. This
parameter is turned off when clock reconvergence pessimism
removal (CRPR) is enabled.
Sometimes there is a difference between launching and capturing
clock latencies, either due to reconvergent paths in the clock network
or different minimum and maximum delays of cells in the clock
network. For setup paths, Astro uses the late value to launch and the
early value to capture. This achieves the tightest constraint and
avoids optimism.
However, for paths starting from latch data pins (latches where time
borrowing has occurred and that are in transparent phase), this is
pessimistic since data simply passes through and therefore does not
even observe the clock edge at the latch. The
Timing Parameters
D-157
Usage
Set this parameter to 1 to use early clock latency for launching setup
paths starting from the data pin of latches. The syntax is
axSetIntParam "ata" "early_launch_at_borrowing_latches" 1
When set to 0, late clock latency is used to launch all setup paths in
the design.
This form of pessimism removal is recommended, since it does not
cause the runtime of analysis to increase. CRPR may not be applied
to paths which have been launched using an early latency or the
results may be optimistic. Since CRPR is a more sophisticated and
accurate means of pessimism removal, Astro turns off this
parameter when CRPR is turned on.
Range
The valid values are 0 or 1. The default is 1.
group_path_opt
The group_path_opt parameter controls optimization by path
group.
Usage
To enable optimization by path group, enter the following:
axSetIntParam "ata" "group_path_opt" 1
Range
The valid values are 0 or 1. The default is 1.
max_RG_size_multiplier
The max_RG_size_multiplier parameter controls the minimum
size of the route guides considered by virtual route for RC
estimation. This parameter is used only for virtual routing and does
not affect the routing behavior.
Virtual route is used to estimate pre-route RC and therefore should
consider large route guides only. Small route guides are not useful to
virtual route because their effect on RC estimation is negligible.
If you process small route guides, it results in CPU and memory
wastage. Regardless of what is done in virtual route, both large and
small route guides are handled by the router.
Timing Parameters
D-159
Usage
By default, a route guide that is smaller than two row heights is
ignored by the virtual route. To set the row height of the route guide
as 2, enter the following:
axSetRealParam "ata" "max_RG_size_multiplier" 2.0
Range
The valid values of this parameter range between 0.0 and 5.0. The
default is 2.0.
multicycle_hold_follow_setup
The multicycle_hold_follow_setup parameter determines
whether multicycle path exceptions defined on setup relationships
affect the hold relationship.
Changing the setup relationship implicitly changes the hold
relationship because all hold relationships are based on valid setup
relationships. Astro verifies that the data launched by setup launch
edge is not captured by the previous capture edge.
Usage
To specify that multicycle path exceptions defined on setup
relationships affect the hold relationship, enter the following:
axSetIntParam "ata" "multicycle_hold_follow_setup" 1
When set to 0, the setup relationship does not affect the hold
relationship.
Range
The valid values are 0 or 1. The default is 1.
non_unate_clock_compatibility
The non_unate_clock_compatibility parameter controls the
clock sense considered for analysis in a non-unate clock network.
Usage
To consider only the noninverting sense of the clock, enter the
following:
axSetIntParam "ata" "non_unate_clock_compatibility" 1
Range
The valid values are 0 or 1. The default is 1.
Timing Parameters
D-161
print_Clock_Timing_For_Mixed_Edges
The print_Clock_Timing_For_Mixed_Edges controls whether
it is the clock path or the data path whose delay and transition values
are reported for mixed signal edges in the report_delay
calculation and SDF output. This parameter affects report delay
calculation and SDF export.
Usage
To obtain the clock path value report, enter the following:
axSetIntParam "ata" "print_Clock_Timing_For_Mixed_Edges" 1
Range
The valid values are 0 or 1. The default is 0.
pulse_latch_as_ICG_cell
The pulse_latch_as_ICG_cell parameter determines whether
the pulse latch cell is considered as an ICG cell. This parameter
controls the tracing through the pulse latch.
Usage
To specify the pulse latch cell as an ICG cell, enter the following:
axSetIntParam "ata" "pulse_latch_as_ICG_cell" 1
Range
The valid values are 0 or 1. The default is 0.
rc_degrade_min_slew_when_rd_less_than_rnet
The rc_degrade_min_slew_when_rd_less_than_rnet
parameter enables or disables slew degradation through the RC
network in minimum analysis when the library-derived drive
resistance is significantly less than the dynamic RC network
impedance to ground.
Usage
To perform slew degradation in minimum analysis mode, enter the
following:
axSetIntParam "ata"\
"rc_degrade_min_slew_when_rd_less_than_rnet" 1
By default, when the value is 0, Astro does not degrade the transition
for minimum delay computation on affected nets.
Range
The valid values are 0 or 1. The default is 0.
Timing Parameters
D-163
remove_Escape_From_Bus
The remove_Escape_From_Bus parameter is used to control the
filtering of backslash in a bus name while exporting SDF.
Usage
To filter out backslashes (used as escape characters) from a bus
name while exporting SDF, enter the following:
axSetIntParam "ata" "remove_Escape_From_Bus" 1
By default, Astro writes out backslash for buses in SDF, for example,
A\/\\B\[2\]/C.
To avoid inconsistencies with the Verilog file written out of Astro and
consequent issues during mapping in PrimeTime, use this
parameter to prevent the backslash from being written out, for
example, A/\B[2]/C.
Range
The valid values are 0 or 1. The default is 0.
report_timing_through_sync_pin
The report_timing_through_sync_pin parameter is used in
JupiterXT during clock planning. This parameter controls clock
propagation beyond sync pin.
Usage
To turn on the propagation at sync pin, enter the following:
axSetIntParam "ata" "report_timing_through_sync_pin" 1
Appendix D: Astro Parameters
D-164
Range
The valid values are 0 or 1. The default is 1.
rpt_max_cap_multiplier
The rpt_max_cap_multiplier parameter determines the
maximum capacitance constraint considered by
astReportTiming to report maximum capacitance violations.
Usage
axSetRealParam "ata" "rpt_max_cap_multiplier" 1.050
Range
The valid values of this parameter range between 0.5 and 10.0. The
default is 1.050.
rpt_max_tran_multiplier
The rpt_max_tran_multiplier parameter determines the
maximum transition constraint considered by astReportTiming to
report maximum transition violations.
Timing Parameters
D-165
Usage
axSetRealParam "ata" "rpt_max_tran_multiplier" 1.050
Range
The valid values of this parameter range between 0.5 and 10.0. The
default is 1.050.
rpt_min_cap_multiplier
The rpt_min_cap_multiplier parameter determines the
minimum capacitance constraint considered by astReportTiming
to report minimum capacitance violations.
Usage
axSetRealParam "ata" "rpt_min_cap_multiplier" 1.050
Range
The valid values of this parameter range between 0.5 and 10.0. The
default is 1.050.
rpt_min_tran_multiplier
The rpt_min_tran_multiplier parameter determines the
minimum transition constraint considered by astReportTiming to
report minimum transition violations.
Usage
axSetRealParam "ata" "rpt_min_tran_multiplier" 1.050
Range
The valid values of this parameter range between 0.5 and 10.0. The
default is 1.050.
splitEK
The splitEK parameter determines whether to split the extraction
kernel during timing analysis. Splitting the process reduces peak
memory used by Astro.
Usage
To split the extraction kernel, enter the following:
axSetIntParam "ata" "splitEK" 1
Timing Parameters
D-167
In the above example, the extraction kernel process is split after the
number of instances in a design exceeds 150000.
Range
The valid values are 0 or 1. The default is 1.
Glossary
GL
block
The meaning of block depends on the context in which the term is
used.
blockage
Rectangular areas in which cells cannot be placed. Blockages can
be soft or hard.
GL-1
cluster
Partitioning of cells in a design on a physical chip, used to guide the
layout tools and optimization commands. Clusters in the hierarchy
for the top level must match the hierarchy for the logic modules in
the top level. Clusters are sometimes called physical blocks or
floorplan blocks. Clusters have hard boundaries.
core area
The area where standard cells are placed.
die area
The silicon area of the chip.
DRC
Design rule checking, which differs between the logic and physical
domains.
filler cell
A physical-only cell used by silicon vendors to fill open areas in the
rows to make sure all power nets are connected. Usually this is
done after placement is complete.
fixed
A status assigned to cell instances. Cell instances of fixed status
can neither be placed nor optimized. They can be moved only with
the geMove command. A fixed cell instance automatically prevents
netlist optimization commands from changing it. A fixed status
implies a dont touch status. A fixed cell instance can legally stay
within any placement blockages (hard or soft).
GL-2
flyline
A pin-to-pin connection (segment), drawn as a straight line between
two pins.
hot spot
A place in the floorplan that is highly congested.
isolation cell
A cell that is used to isolate the signals coming from an unpowered
voltage area.
legalized cell
A placed cell that does not overlap other cells or blockages and is
placed on a legal tile location. Different die technologies have
different rules that specify which cells are legal and where.
legalized placement
A placement in which no row contains more cells than the number
of tiles available. All cells are placed on legal locations, snapped to
the tile array grid.
level-shifter cell
A special cell that can carry a signal across different voltage areas.
operating condition
The combined process, operating voltage, temperature, and other
information that controls the performance of a cell instance. This
information is needed to compute the proper timing delay of a cell.
pin
The input and output of cells within a design (such as gates and
flip-flops). The ports of a subdesign are pins within the parent
design.
pitch
The centerline-to-centerline spacing of metal tracks on the same
layer. Pitch is defined in the physical technology library.
GL-3
port
The inputs and outputs of a design. Port direction is designated as
input, output, or inout.
RC correlation
The process of comparing RC parameters before and after routing
and then tuning RC parameter values to reflect the true wire delays.
region constraint
Rectangular areas in which you can constrain the placement of a
subset of standard cells.
routing guide
The process of changing the routing direction or prohibiting
automatic prerouting as well as global routing within a defined area
on specific layers.
soft-fixed
A status assigned to cell instances. Cell instances of soft-fixed
status cannot be placed or moved but can be optimized with netlist
optimization commands. A soft-fixed cell instance cannot legally
stay within hard placement blockages. Netlist optimization
commands can create buffers or inverters in soft placement
blockage areas (during in-placement optimization or postplacement
optimization) with soft-fixed status. During optimization, soft-fixed
cells can be moved to improve timing. Soft-fixed cells cannot be
moved during global placement.
spare cell
A logic gate added to a design to allow quick, logic changes to be
made without replacing all mask layers of the chip. Spare cells exist
in the netlist and the input PDEF. Spare cells are not the same as
filler cells.
GL-4
unfixed
A status assigned to cell instances. Cell instances of unfixed status
can be placed, moved, or optimized. However, when being placed,
they cannot be placed within any (hard or soft) placement blockage.
unit tile cell
The smallest unit of placement. The width of the unit tile is the
metal2 pitch. The height is the standard cell height, unless you are
using double-, triple-, and multiple-height cells. Each standard cell
library contains a unit tile cell. There is no need to redefine the unit
tile cell when using double-, triple-, and multiple-height cells.
voltage area
An area you define that describes the legal locations of cells in a
voltage domain. You create a voltage area by drawing a rectilinear
shape that defines its boundary. Typically, voltage areas need to
coincide with the power supply structures of the chip.
voltage domain
A physical or logical grouping of cell instances that share an
identical power supply with a certain operating voltage.
GL-5
GL-6
Index
A
ALF (Advanced Library Format) files
loading 16-4
sample constraints 16-30
antennas
about fixing 14-10
checking and fixing floating wire 14-11
data preparation
CLF requirements 3-40, 14-6
diode cell 14-8
hierarchical requirements 14-7
TDF requirements 14-6
technolgy file 14-8
deleting diodes 14-17
flow for fixing 14-3
importing reports from Hercules 14-18
inserting diodes 14-15
inserting diodes on preroute nets 14-9
reporting violations 14-18
setting the mode 14-13
application startup files 2-37
application window
exiting 2-39
starting 2-4
aprAddGroupBySelSet command 8-47
aprCmdCreateHierGroup command 8-47
aprCmdFixCell command 8-47
IN-1
IN-2
IN-3
IN-4
B
back-annotation
data exchange formats, list of 13-17
RC and delay output formats, list of 13-18
balance_inter_clock_delay command 9-6
begin_scheme command 2-8
begin_tcl command 2-7
block, defined GL-1
blockage, defined GL-1
buffer tree, inserting for each high-fanout net
9-109
buffers
clock tree (delay cells) 9-36
defining for clock tree synthesis 9-30
dummy cells are, clock tree 9-37
nonclock nets, asynchronous 8-65
relocation, clock tree 9-79
setting level for clock tree 9-43
sizing, clock tree 9-78
C
capacitance, settings for clock tree 9-43
capacitance, TLU model
checking parameters 7-41
setting 4-9, 6-38, 6-41
capacitance, TLUPlus model
about 7-43
generating 7-44
writing information to an ASCII file 7-46
case analysis, setting an operating condition
6-7
cell electromigration
about 16-3
performing analysis 16-28
cell instance groups, adding to a scan chain
B-15
cell sizing, clock tree optimization 9-33
cells
creating new 2-26
displaying in a layout window 2-27
legalized, defined GL-3
opening existing 2-23
spare, defined GL-4
using edit-in-place 12-28
cells, filler
adding 8-48
adding back after optimization 11-18
defined GL-2
removing 10-8
cells, tie-high, tie-low, and tie-highlow
examples 8-57
inserting 8-52
modes 8-55
check_design_for_cts command 9-7
CLF (Cell Library Format) files
about 3-2
antenna requirements 3-40, 14-6
clock tree synthesis 9-7
constraints for noise analysis 15-20
loading supplemental 3-40
clfCreateTable command 9-8
IN-5
IN-6
multiple 9-67
pulse generated 9-26
cluster, defined GL-2
cmAttachStarRCXT command 11-26
cmCmdECODump command 12-24
cmCmdExpand command 4-14
cmCreateCapModel command 3-4, 4-9, 6-38,
6-41, 7-42, 7-44
cmCreateLib command 3-15, 3-25
cmDumpTech command 3-42
cmDumpTLUPlus command 7-46
cmItfToTLUPlus command 4-9, 7-44
cmMarkLefSite command 3-42
cmRefLib command 3-25
cmReplaceTech command 3-7, 3-42
cmReplaceTLUPlus command 7-46
cmSetMultiHeightProperty command 3-20,
3-42
cmSmash command 3-17, 3-27
command files
creating and running 2-35
load 2-38
replay 2-36
script 2-39
startup
about 2-37
application 2-37
library 2-38
command menu, using 2-10
command processing, interrupting 2-9
command window, using 2-13
commands
aprAddGroupBySelSet 8-47
aprCmdCreateHierGroup 8-47
aprCmdFixCell 8-47
aprCreateGCTSExplorer 9-66
aprPGConnect 4-15, 5-2, 11-18
aprSetDensity 8-71
astAddPlaceSRConst 8-70
astAreaRecovery 8-103
IN-7
IN-8
auNDOApi 13-18
auNLOApi 13-18
auPurgeSIOfALF 16-5
auSetPRBdry 3-19, 3-42, 14-8
auStreamIn 3-16, 14-8
auStreamOut 13-18
auto_place 8-4
auVerilogIn 4-14
auVerilogOut 13-17
auVerilogToCell 4-2, 4-14, 4-15
auVhdlOut 13-18
axComputeHierAntennaProp 14-7
axDrouteOptimizeContact 12-6
axgAddDiodeForPreroute 14-9
axgAddFillerCell 8-48, 8-49
axgAddFillerCellByArea 8-48
axgAddRouteGuide 10-10
axgAdvRouteOpt 7-29, 7-41, 11-21, 15-56
axgAssignToTracks 10-48
axgAutoRoute 10-3, 10-25, 10-26
axgAutoShield 10-40, 10-41, 15-13
axgBindNetlist 4-15
axgCheckDesignForRoute 6-5, 10-6
axgCreateRectangularRings 5-10
axgCreateRegion 8-11
axgCreateStraps 5-14, 5-18
axgDefineVarRule 9-6, 9-57, 9-75, 10-12,
10-13, 10-41
axgDefineWireTracks 3-20
axgDeleteDiode 14-17
axgDetailRoute 10-48
axgDisplayCouplingCapMap 8-34
axgDisplayCritAreaHeatMap 12-19
axgDisplayGRCongestionMap 10-30
axgDisplayPLCongestionMap 8-31
axgDisplayScanChain B-9, B-21
axgDumpFloorPlan 5-9
axgDumpPseudoPinConstr 10-23
axgECOPlace 8-48
axgECORouteDesign 9-92, 10-44
axgFillWireTrack 12-11, 12-12
axgGlobalRoute 10-46, 10-47
axgInsertDiode 14-15
axgListPRSummary 7-25
axgLoadPLCongMap 8-33
axgLoadPseudoPinConstr 10-22
axgOptimizeContact 12-7
axgPlaceOptions 8-9
axgPlanner 5-6, 5-8
axgPrerouteInstances 5-18
axgPrerouteStandardCells 5-18
axgQuickSignalRoute 10-40, 10-42, 12-20,
15-13
axgRouteGroup 9-58, 10-23
axgRouterVerify 13-6
axgRoutOpt 10-38
axgSavePLCongMap 8-33
axgScanChainOptim B-9, B-14, B-19
axgScanTrace B-7
axgSearchRepair 10-50, 14-12
axgSetHPORouteOptions 14-13, 15-59
axgSetMinMaxLayer 9-6
axgSetNetConstraint 9-6, 9-57, 9-75, 10-12,
10-15, 10-16
axgSetRouteOptions 9-74, 10-18, 10-32,
10-39, 15-11
axgSlotWire 12-14
axgSpreadGroupCells 8-47
axgUpdateCongMap 8-32, 8-33, 8-66
axImportAntennaReport 14-8, 14-18
axPrintParams D-2
axReportAntennaRatio 14-18
axReportIsolatedVia 12-10
axRouteAddBufferByFile 12-22
axSearchParams D-3
axSetIntParam
act 9-56, 9-58
acts 9-48, 9-57, 9-66, 9-94
apl 6-34
ata 7-47, 8-45
droute 10-36, 10-37, 10-39, 10-40, 11-3,
12-4, 12-5, 12-6, 12-10, 12-11, 12-12,
12-16, 14-11, C-16, C-27
groute 10-28, 10-29, 10-32, 10-33
IN-9
IN-10
defineExtGateSize 14-6
defineFlipFlopFunction 9-8
defineFootPrintEQCell 11-17
defineGateSize 14-6
defineHierAntennaProp 14-7
defineLatchFunction 9-8
definePad 3-40
definePortCapacitance 9-8
defineStaticNoiseMargin 15-20
defineStaticNoiseWidth 15-20
defineStroke 2-41
defineTimingTLU 9-8, 9-24
disableStroke 2-41
ekDeleteNetRoutingRuleTabInfo 10-8
ekDumpNetRoutingRuleTabInfo 10-8
ekGenNetRoutingRuleTabInfo 10-7
ekGenVRCCMapAttachFile 8-33
ekIgnoreShieldNDRinDR 10-42
ekSetLayerScope 7-42
ekSetMaxIntraCapDistRatio 7-42
ekSetTLUPlus 7-45
geAdvDRC 13-3
geConfirmCloseLib 2-40
geCreateCell 2-26, 4-15
geCreateLib 3-7
geCreateLogicView 4-31
geErrorBrowser 10-6, 13-9
geGetEditCell 7-33
geMove GL-2
geNameSelect 2-40
geNewDRC 13-5
geNewFillNG 10-40
geNewLVS 13-8
geNewMakeMacro 3-27
geOpenCell 2-23, 5-2
geOpenLib 2-22, 3-20, 5-2
gePrepLibs 3-21, 3-29, 3-30, 3-31, 3-33
geQueryNetConstraint 10-12
geSaveAllOpenCells 6-64
grdgenxo -itf2TLUPlus 7-44
group_path 8-43
help 2-21
hmiHierAntenna 14-7
jpParallelJob 10-53
leaPointToPointRoute 12-29
load 2-36, 2-38
load_scheme 2-39
mark_clock_tree 9-6
menuQuit 2-40
menuReload 4-9
open_design 2-23
open_mw_lib 2-22
optimize_clock_tree 9-6
pdsCROptimization 8-86, 8-87
pdsHFNCollapse 7-36
pdsHFNOptimization 8-65, 8-91
pdsHFNOptNet 8-63, 9-29
pdsMoveCell 8-86, 8-87
pdsMoveIOPaths 8-86
pdsSplit3StateNet 8-87
poLoadNetSwitchingInfo 9-111, 16-8, 16-9,
16-11
poLoadPowerSupply 4-30, 9-111, 15-19,
16-7
poPowerAnalysis 9-111
post_route_opt 11-2
process_particle_probability_file 12-17
read_lib 3-11, 3-25
remove_clock_sense 7-48
remove_clock_tree 9-6
remove_clock_tree_exceptions 9-7
remove_dynamic_latch 6-57
report_clock 9-27
report_critical_area 12-17
report_path_group 8-45
report_timing 7-10
report_units 6-18
route_spreadwire 12-16
rsh 10-55
set_case_analysis 6-7
set_clock_sense 7-47
set_clock_transition 6-58
set_clock_tree_exceptions 9-7, 9-22
set_clock_tree_options 9-6
IN-11
set_clock_tree_references 9-7
set_data_check 6-26
set_drivng_cell 15-19
set_dynamic_latch 6-56
set_max_capacitance 6-62
set_noise_lib_pin 15-24
set_propagated_clock 6-6, 7-5
set_si_analysis 15-17
set_si_delay_analysis 15-18
set_units 6-17
setSideButton 2-32
source 2-36, 2-39
split_clock_net 9-7
tdfSetPowerSupply 16-7
trPanel 12-31
undefineStroke 2-43
unitMaxThickness 14-8
unitMinThickness 14-8
unitNomThickness 14-8
useful_skew_opt 9-7, 9-85
write_mdb 3-43
write_sdc 6-6, 6-18
xtCellEM 16-3, 16-28, 16-29
xtDefineXtalkConxGroup 6-54
xtDumpDeltaTransDelay 15-45, 15-46
xtDumpStageDelay 15-44
xtGetXtalkFilter 6-50
xtIgnoreTieHighLowNet 15-17
xtReportNoiseLibInfo 15-22
xtSignalEM 16-3, 16-4, 16-7, 16-13, 16-23
xtXTalkAnalysis 7-3, 15-27, 15-53
xtXTalkDisplayNet 15-43
xtXTalkReport 15-36
common graph data
loaded and reloaded by the clock browser
9-15
not refreshed by the clock browser 9-16
compile_clock_trees command 9-6
configuration file
hard 9-39
soft 9-39
syntax 9-40
IN-12
congestion
fixing with search-and-refine 8-67
placement cleanup of 8-61
routing and placement 8-29
congestion maps
about 8-28
global routing, displaying 10-30
placement
displaying 8-31
saving and restoring 8-33
updating 8-32
connect_tie_cells command 8-52, 8-54
constraints
about loading timing (SDC) 6-6
backward compatibility (SDC) 6-13
check timing (SDC) 7-36
clock tree 9-43
command to load timing (SDC) 6-9
generate crosstalk 15-28
modifying (SDC) 6-12
timing flow 6-7
writing to a file 6-11
constraints, scan chains
applying to B-19
creating a file B-13
editing the file B-14
sample file B-16
specifying order B-10
contacts, optimizing
about 12-3
using axDrouteOptimizeContact 12-6
using axgOptimizeContact 12-7
control nets, creating for a scan chain B-19
control panel, using 12-31
core area, defined GL-2
coupling capacitance maps
displaying 8-34
generating 8-33
CPUs, distributed routing 10-52, 10-53, 10-55
create_clock command 9-60
create_design command 2-26
D
data exchange output formats, list of 13-17
data preparation
creating LM views 3-29
data preparation, design
about generating hierarchical Verilog out
4-11
clock tree synthesis 9-9
dynamic latch analysis 6-55
loading power supply information 4-29
loading SDC 6-6
preserving hierarchy 4-12
setting capacitance constraints on clock
domains 6-60
setting capacitance, transition, and delay
defaults for nets 6-63
setting clock transition defaults 6-58
setting net transition defaults for nonclock
nets 6-59
timing setup 6-19
data preparation, library
IN-13
IN-14
IN-15
about 13-2
cleaning up errors 12-20
defined GL-2
fixing problems across the hierarchy 12-28
running advanced 13-3
running basic 13-5
running with verification 13-6
DRC errors, displaying in browser 10-6, 13-9
dynamic latch analysis 6-55
E
ECO
change file method 12-23
clock tree changes 9-94
generating during scan chain optimization
B-19
methods, list of 12-22
net compare method 12-24
running after postrouting clock tree
optimization 9-92
running on detail routing 10-44
updating netlist changes 4-24
EDIF netlist, creating a design library with 4-8
editing, interactive 7-21
edit-in-place 12-28
ekDeleteNetRoutingRuleTabInfo command
10-8
ekDumpNetRoutingRuleTabInfo command
10-8
ekGenNetRoutingRuleTabInfo command 10-7
ekGenVRCCMapAttachFile command 8-33
ekIgnoreShieldNDRinDR command 10-42
ekSetLayerScope command 7-42
ekSetMaxIntraCapDistRatio command 7-42
ekSetTLUPlus command 7-45
electrical filters, crosstalk
list of 6-50
setting 6-46
electromigration
about 16-3
IN-16
F
falling edge, clock tree 9-9
fanout nets, high
about 8-63
buffering of 8-62
optimization, in-placement 8-68
optimization, preplacement 8-62
reporting skew for non-clock 9-107
setting maximum for clock tree 9-43
synthesizing 9-109
files
ALF (Advanced Library Format) 16-4, 16-30
CLF (Cell Library Format) 3-2
design database 3-3
GDSII 3-3
netlist 3-3
output from Astro, list of types 3-6
.rhost 10-55
SDC 3-3
SDF (Standard Delay Format) 15-50
G
gated clock tree
defining cell 9-25
setting option for 9-49
gates
relocation, clock tree 9-80
sizing, clock tree 9-80
GDSII files, about 3-3
IN-17
H
hard blockage, defined GL-1
help command 2-21
Help, online, using the Web browser 2-18
Hercules, importing antenna reports from
14-18
hierarchical antenna properties
hard macros 14-5, 14-7
routed blocks 14-7
hierarchical common graph
checking consistency information 4-28
hierarchical Verilog
about outputting 4-11
dumping information 4-19, 4-28
hierarchy preservation
about 4-12
deleting 4-28
initializing 4-16
maintaining information during ECO 12-23
marking instances 4-18
methodology for 4-14
repairing 4-23
high-fanout nets
about 8-63
buffering of 8-62
optimization, in-placement 8-68
optimization, preplacement 8-62
IN-18
I
ideal slack, preplacement optimization 8-63
in-placement optimization
command to run 8-66
preventing crosstalk during 15-7
in-routing optimization, running with crosstalk
options enabled 15-56
integer set parameter commands, using and
getting information D-2
interactive editing 7-21
interrupt, commands 2-9
inverter-only optimization 11-7
inverters
clock tree (delay cells) 9-36
defining for clock tree synthesis 9-30
dummy cells are, clock tree 9-37
isolation cell, defined GL-3
ITF (Interconnect Technology Format) 7-44
J
jpParallelJob command 10-53
JupiterXT, working with 5-5
L
latch pairs, reporting master-slave 7-32
latency, clock
about 9-48
M
macro cells, hard, hierarchical antenna
properties 14-5, 14-7
man pages 2-22
mark_clock_tree command 9-6
menu commands, using 2-10
menuQuit command 2-40
menuReload command 4-9
metal density filling 12-11
metal slotting 12-14
Milkyway application directory
CLF (Cell Library Format) files 3-2
design database file 3-3
GDSII files 3-3
IN-19
N
net switching information, loading 16-8
netlist files, about 3-3
netlist-defined scan chain optimization flow B-2
netlists
creating a design library with 4-2, 4-8
updating for ECOs B-19
nets
analyzing crosstalk 15-36, 15-43
displaying timing information 7-18
setting capacitance, transition, and delay
defaults 6-63
setting constraints 10-16
shielding 10-40
NLDM libraries, timing setup 6-37
noise analysis
delay shift 15-47
during routing 15-62
reporting 15-31
sample report 15-33, 15-34
sample statistics 15-30
specifying net-based thresholds with an input
file 6-53
noise analysis, crosstalk
about 15-13
command to run 15-27
excluding nets from 15-17
IN-20
O
online command help facility 2-8
online documentation system, about 2-17
online Help, using the Web browser 2-18
open_design command 2-23
open_mw_lib command 2-22
operating condition, defined GL-3
operating conditions, case analysis 6-7
optimization
adding back filler cells 11-18
area recovery 8-103
detail routing 11-14, 11-21
global routing 11-13, 11-19
histogram reports 11-6
in-placement 8-66
inverter-only capablility 11-7
netlist-defined scan chains B-2
performing length-based buffer insertion
8-93
postplacement phase 1 8-78
postplacement phase 2 8-83, 8-84
postrouting clock tree 9-90
postrouting command 11-4
preplacement 8-58
scan chains B-19
setting the size_only constraint 8-20
setting the time borrowing method 6-22
topology-based
about 8-74
fixing hold violations 8-96
track assignment 11-14
P
pad orientation, CLF requirements 3-40
PARA view
generating 13-13, 15-13
postrouting optimization 11-5
parameters
crosstalk D-76
global route D-84
optimization D-116
rectilinear D-134
timing D-146
using and getting information D-2
parasitic aggressor filters, crosstalk
list of 6-49
setting 6-46
parasitic extraction, layout
determining mode 7-41
fast 11-25
in-routing 11-21, 15-62
setting mode for 6-40
setting mode for signal electromigration
analysis 16-13
using a net-based routing rule table 10-7
Parasitics page, timing setup 6-38
paths
clear from graphics window 7-10
display in graphics window 7-10
display in schematic view 7-19
display information 7-14
show in timing report 7-10
timing probe histogram 7-17
view details of between the master and the
generated clocks 7-10
IN-21
IN-22
R
RC and delay output formats, list of 13-18
RC correlation
defined GL-4
prerouting 7-40
RC layer optimization, global routing 10-28
read_lib command 3-11, 3-25
real set parameter commands, using and
getting information D-2
rectilinear parameters D-134
reference library, data requirements for 3-4
region constraint, defined GL-4
remove_clock_sense command 7-48
remove_clock_tree command 9-6
remove_clock_tree_exceptions command 9-7
remove_dynamic_latch command 6-57
replay files 2-36
report_clock command 9-27
report_critical_area command 12-17
report_path_group command 8-45
report_timing command 7-10
report_units command 6-18
reports
clock skew 9-5, 9-96
clock tree synthesis 9-99
detailed crosstalk analysis 15-36
generated clocks 7-32
ideal slack 8-63
master-slave latch pairs 7-32
noise analysis 15-31
noise information from reference libraries
15-22
place and route summary 7-25
synthesized net skew 9-107
timing 7-3
timing with crosstalk consideration 15-48
resistance, TLUPlus model
about 7-43
considerations 7-45
generating 7-44
writing information to an ASCII file 7-46
.rhosts file 10-55
rings, adding power and ground 5-10
IN-23
about 13-2
cleaning up errors interactively 12-20
fixing problems across the hierarchy 12-28
running advanced 13-3
running basic 13-5
running with verification 13-6
routing, ECO
after postrouting clock tree optimization 9-92
on detail 10-44
routing, flow 10-4
routing, groups of nets
about 10-21
clock nets 9-114, 10-22
command to run 10-23
defining pseudo pins for balanced clock
10-22
routing, guide, defined GL-4
routing, optimization
after detail routing 11-14, 11-21
after global routing 11-13, 11-19
after track assignment 11-14
reducing wire length and via count 10-38
using alternative commands 11-18
using astPostRouteOpt 11-4
routing, point-to-point 12-29
routing, running LVS checking 13-7
routing, setting common options
about 10-18
command to run 10-18
crosstalk prevention during global and track
assignment 10-20
timing driven 10-20
routing, variable rules
about 10-11
assigning 10-15
defining 10-13
rsh command 10-55
S
scan chain constraints file
IN-24
creating B-13
editing B-14
scan chains
adding cell instance groups B-15
adding fixed edges B-16
adding free edges B-16
applying constraints B-19
applying order constraints B-10
control nets B-19
creating B-9
creating by extraction B-7
creating manually B-9
defining and optimizing B-2
deleting B-14
detaching B-9
disconnecting 8-46
disconnecting and optimizing 8-46
dumping to a file B-11, B-21
generating an ECO B-19
minimum edge length B-20
netlist-defined B-2
optimizing B-19
setting group priority B-15
user-defined B-5
Scheme
about 2-3
changing mode to Tcl 2-7
command to run script 2-39
setting mode 2-4
script files 2-39
SDC commands
about file 3-3
about loading 6-6
backward compatibility 6-13
checking timing constraints 7-36
command to load 6-9, 6-12
modifying 6-12
specifying units 6-17
timing constraint flow 6-7
writing ast-type to a file 6-14
writing to a file 6-11
T
Tcl
about 2-3
changing mode to Scheme 2-8
command to run script 2-39
IN-25
IN-26
about 10-33
command to run 10-25
command to run (alternative) 10-48
limiting net layer length to prevent floating
antennas 10-34
optimization 11-14
preventing crosstalk during 15-12
specifying density-driven 10-34
transition, clock
about 9-48
settings for 9-12
trPanel command 12-31
W
Web browser, using to view online Help 2-18
write_mdb command 3-43
write_sdc command 6-6, 6-18
U
undefineStroke command 2-43
unfixed, defined GL-5
unit tile cell, defined GL-5
unitMaxThickness command 14-8
unitMinThickness command 14-8
unitNomThickness command 14-8
useful skew, optimizing 9-85
useful_skew_opt command 9-7, 9-85
V
variable routing rules
about 10-11
assigning 10-15
defining 10-13
propagating for clock nets 9-56
Verilog netlist, creating a design library with 4-2
VHDL netlist, creating a design library with 4-8
vias, preventing isolated 12-10
views, library, list of 3-8
violations
about DRC 13-2
cleaning up DRC errors and shielding 12-20
displaying in browser 10-6, 13-9
fixing problems across the hierarchy 12-28
X
Xtalk page, timing setup 6-45
xtCellEM command 16-3, 16-28, 16-29
xtDefineXtalkConxGroup command 6-54
xtDumpDeltaTransDelay command 15-45,
15-46
xtDumpStageDelay command 15-44
xtGetXtalkFilter command 6-50
xtIgnoreTieHighLowNet command 15-17
xtReportNoiseLibInfo command 15-22
xtSignalEM command 16-3, 16-4, 16-7, 16-13,
16-23
xtXTalkAnalysis command 7-3, 15-27, 15-53
xtXTalkDisplayNet command 15-43
xtXTalkReport command 15-36
Y
yield, optimizing
displaying critical area heat maps 12-19
encrypting and decrypting the particle
probability function 12-17
reporting critical area heat maps 12-17
spreading wires 12-16
IN-27
IN-28