RTL Architect™ User Guide

RTL Architect™ User Guide
Version S-2021.06-SP4, December 2021

Copyright and Proprietary Information Notice
© 2021 Synopsys, Inc. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc.
and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All
other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
https://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.

www.synopsys.com
RTL Architect™ User Guide 2

S-2021.06-SP4
Feedback
Contents
New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Related Products, Publications, and Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Working With the RTL Architect Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

RTL Architect Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Starting the Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Exiting the RTL Architect Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Entering rtl_shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Interrupting or Terminating Command Processing . . . . . . . . . . . . . . . . . . . . . . . 15
Getting Information About Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Displaying Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Using Application Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Using Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Viewing Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Using Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Using Setup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Using the Command Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Enabling Multicore Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Configuring Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Configuring Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Reporting Multicore Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Removing Multicore Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Running Tasks in Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Running Commands in Parallel on Your Local Host . . . . . . . . . . . . . . . . . . . . . 24
Running Commands in the Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Running Commands in Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2. Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3
Feedback
Contents
Defining the Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Setting Up Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Working With Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Setting Up Reference Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Library Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Restricting Library Cell Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Restricting the Target Libraries Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Specifying Library Subset Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Reading the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Reading RTL Files in SystemVerilog, Verilog, or VHDL Format . . . . . . . . . . . . .36
Reading Designs Using the -autoread Option . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Reading Designs Using the VCS Command-line Options . . . . . . . . . . . . . . . . . 38
Mitigating Design Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Applying the Multivoltage Power Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Loading and Applying UPF Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Saving UPF Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Annotating the Switching Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Scaling the Switching Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Specifying Switching Probability for Supply Nets . . . . . . . . . . . . . . . . . . . . . . . . 43
Specifying Logical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Specifying Logical Design Rule Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Specifying Timing Constraints and Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Splitting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Calculating Subblock Pin Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Promoting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Importing the Floorplan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Reading DEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Fixing Site Name Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Validating DEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Physical Constraints Extracted From the DEF File . . . . . . . . . . . . . . . . . . . 53
Importing a Floorplan Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Ensuring Port Locations are Inherited From Pads . . . . . . . . . . . . . . . . . . . . . . . 59
Specifying Locations for Unmapped Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Using Automatic Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Creating Constraints for Auto Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . 61
4
Feedback
Contents
3. Restructuring the RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Adding Logical Hierarchy Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Removing Logical Hierarchy Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Changing the Parent Module for a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Partitioning the Logical Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Automatic Logical Hierarchy Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Performing Automatic Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Setting Up and Running Automatic Partitioning . . . . . . . . . . . . . . . . . . . . . .73
Files Generated During Automatic Partitioning . . . . . . . . . . . . . . . . . . . . . . 75
Analyzing the Partitioning Results and Selecting a Solution . . . . . . . . . . . . 76
Writing the Restructured RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4. Synthesizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

rtl_opt Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Using the rtl_opt Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
rtl_opt Block-Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
rtl_opt Hierarchical Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Specifying the Optimization Effort of the rtl_opt Command . . . . . . . . . . . . . . . . . . . 85
Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Performing Multibit Register Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Performing Integrated Multibit-Register Optimization . . . . . . . . . . . . . . . . . .88
Specifying Naming Styles for Multibit Registers . . . . . . . . . . . . . . . . . . . . . 89
Reporting Multibit Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Identifying Why Multibit Banking Is Not Performed . . . . . . . . . . . . . . . . . . . 90
DFT Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Inserting DFT Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Performing Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5. Analyzing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Computing Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Clock Gating Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Congestion Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Timing Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Power Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Reporting Power Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Analyzing Metrics in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5
Feedback
Contents
Generating Metrics Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Generating RTL-Based Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Comparing QoR Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Setting Your Baseline Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Changing the QoR Display Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Sorting and Filtering the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Sorting the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Filtering Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Filtering Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Example Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Exploring the Detailed Comparison Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Filtering the Detailed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6. Exploring the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Setting Up the Exploration Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Setting the Distributed Processing Configuration . . . . . . . . . . . . . . . . . . . . . . . 132
Specifying Exploration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Specifying a Range of Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Excluding Parameters From a Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Including Parameters in a Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding User-Defined Parameters in a Run . . . . . . . . . . . . . . . . . . . . . . . . 139
Specifying the Power Analysis Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Reporting Exploration Parameters and Runs . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Launching Exploration Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Handling Missing Data During Design Exploration . . . . . . . . . . . . . . . . . . . . . . . . . 143
Analyzing Exploration Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Generating an Exploration Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Working With Summary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Launching the Comparator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Exploring Different RTL Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6
Feedback
About This User Guide

The Synopsys RTL Architect™ tool is a complete RTL analysis and optimization solution
that enables early RTL exploration to achieve predictable RTL closure and improved
power, performance, and area metrics in less development time. The RTL Architect tool
combines full-featured, physically aware optimization technologies into a unified cockpit,
including design exploration and metrics analysis capabilities.
This guide describes the RTL Architect implementation flow.
Audience
This user guide is for RTL developers who use the RTL Architect tool to perform physically
aware RTL analysis and optimization.
To use the RTL Architect tool, you should be familiar with the following topics:
• High-level design techniques
• Physical design principles
• Timing, congestion, and power analysis principles
• The Linux operating system
• The tool command language (Tcl)
This preface includes the following sections:
• New in This Release
• Related Products, Publications, and Trademarks
• Conventions
• Customer Support
New in This Release

Information about new features, enhancements, and changes, known limitations, and
resolved Synopsys Technical Action Requests (STARs) is available in the RTL Architect
Release Notes on the SolvNetPlus site.

S-2021.06-SP4
Feedback
Related Products, Publications, and Trademarks
Related Products, Publications, and Trademarks

For additional information about the RTL Architect tool, see the documentation on the
Synopsys SolvNetPlus support site at the following address:
https://solvnetplus.synopsys.com
You might also want to see the documentation for the following related Synopsys products:
™
• Fusion Compiler
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates syntax, such as write_file.
Courier italic Indicates a user-defined value in syntax, such as

write_file design_list
Courier bold Indicates user input—text you type verbatim—in examples, such
as
prompt> write_file top
Purple • Within an example, indicates information of special interest.

• Within a command-syntax section, indicates a default, such as
include_enclosing = true | false
[] Denotes optional arguments in syntax, such as

write_file [-format fmt]
... Indicates that arguments can be repeated as many times as

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

low | medium | high
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Bold Indicates a graphical user interface (GUI) element that has an

action associated with it.
Edit > Copy Indicates a path to a menu command, such as opening the Edit
menu and choosing Copy.

S-2021.06-SP4
Feedback
Conventions
Convention Description
Ctrl+C Indicates a keyboard combination, such as holding down the Ctrl

key and pressing C.

S-2021.06-SP4
Feedback
Customer Support
Customer Support
Customer support is available through SolvNetPlus.
Accessing SolvNetPlus
The SolvNetPlus site includes a knowledge base of technical articles and answers to
frequently asked questions about Synopsys tools. The SolvNetPlus site also gives you
access to a wide range of Synopsys online services including software downloads,
documentation, and technical support.
To access the SolvNetPlus site, go to the following address:
https://solvnetplus.synopsys.com
If prompted, enter your user name and password. If you do not have a Synopsys user
name and password, follow the instructions to sign up for an account.
If you need help using the SolvNetPlus site, click REGISTRATION HELP in the top-right
menu bar.
Contacting Customer Support

To contact Customer Support, go to https://solvnetplus.synopsys.com.

S-2021.06-SP4
Feedback
1
Working With the RTL Architect Tool
Developing new RTL that achieves the best quality implementation can be a time-
consuming process when developers lack a fast and efficient way to explore and improve
the data to create a better starting point for RTL synthesis. The RTL Architect tool
addresses these problems by enabling early, physically aware RTL exploration to
achieve a better starting point for RTL synthesis and better convergence during physical
implementation.
With predictive gate modeling that is significantly faster than full synthesis and
automatic floorplanning capabilities, the RTL Architect tool provides early visibility into
implementation results that are typically within 5 percent of the results produced by the
Fusion Compiler tool. The RTL Architect tool lets you efficiently perform what-if analyses of
various design configurations early in the design cycle to speed the development of high-
quality RTL and constraints and drive a faster, more convergent design flow.
The RTL Architect tool takes as input an RTL database, design constraints (timing, power,
floorplan), logic and physical libraries, and foundry-process data.
The RTL Architect tool provides a unified
• Data model, which enables sharing of libraries, design data, constraints, and design
intent throughout the entire flow and is built to support ultra-large designs with a small
memory footprint
• Graphical user interface (GUI), which enables seamless visual analysis of timing and
power with cross-probing between the RTL and gates.
• Design mismatch mitigation infrastructure, which provides user controls to mitigate
incomplete or mismatched library and design data
To learn more about using the RTL Architect tool, see
• RTL Architect Design Flow
• User Interfaces
• Entering rtl_shell Commands
• Using Application Options
• Using Variables

S-2021.06-SP4
Feedback
Chapter 1: Working With the RTL Architect Tool
RTL Architect Design Flow
• Viewing Man Pages

• Using Tcl Scripts
• Using Setup Files
• Using the Command Log File
RTL Architect Design Flow

The following figure shows the design flow for the RTL Architect tool.
Figure 1 RTL Architect Design Flow

The following topics describe how to perform the tasks in this flow:
• Preparing the Design
• Restructuring the RTL

S-2021.06-SP4
Feedback
User Interfaces
• Synthesizing the Design

• Analyzing the Design
• Exploring the Design
User Interfaces
The RTL Architect tool offers two interfaces for RTL analysis and optimization: the
rtl_shell command-line interface (or shell) and the RTL Architect graphical user interface
(GUI). The rtl_shell command-line interface is a text-only environment in which you
enter commands at the command-line prompt. The GUI is a graphical environment for
visualizing design data and analyzing results.
The RTL Architect tool operates in the X Windows environment on Linux. It provides a
flexible working environment with both a shell command-line interface and a graphical user
interface (GUI). The command-line interface is always available during a RTL Architect
session. You can start or exit a session in either the shell or the GUI, and you can open or
close the GUI at any time during a session.
The tool uses the Tool Command Language (Tcl), which is used in many applications in
the EDA industry. Using Tcl, you can extend the rtl_shell command language by writing
reusable procedures and scripts (see the Using Tcl With Synopsys Tools manual).
The following topics describe how to start and exit the tool using the command-line
interface.
• Starting the Command-Line Interface
• Exiting the RTL Architect Tool
For information about using the GUI, see the RTL Architect Graphical User Interface User
Guide.
The following topics describe how to use the user interfaces of the RTL Architect tool:
• Starting the GUI
• Closing the GUI
Starting the Command-Line Interface

The command-line interface is a text-only environment in which you enter commands at
the command-line prompt. It is typically used for scripts, batch mode, and push-button
operations.
Before you start the command-line interface, ensure that the path to the bin directory is
included in your $PATH variable.

S-2021.06-SP4
Feedback
User Interfaces
To start rtl_shell,
1. Make sure the path to the bin directory is included in your PATH variable.
2. Enter the rtl_shell command in a Linux shell.
% rtl_shell
You can include other options on the command line when you start the shell. For example,
you can use
• -file script_file_name to execute a script
• -x command to execute a command
• -output_log_file file_name to create a log file of your session
• -help to display a list of the available options (without starting the shell)
At startup, the tool performs the following tasks:

1. Creates a command log file.
2. Reads and executes the setup files.
3. Executes any script files or commands specified by the -file and -x options,
respectively, on the command line.
4. Displays the program header and rtl_shell> prompt in the shell.
See Also
• Using the Command Log File
Exiting the RTL Architect Tool

You can end the session and exit the RTL Architect tool at any time. To exit the tool, use
the exit or quit command.
Note:
When you exit the tool from the command line, the tool exits without saving the
open blocks.

S-2021.06-SP4
Feedback
Entering rtl_shell Commands

You interact with the RTL Architect tool by using rtl_shell commands, which are based
on the Tool Command Language (Tcl) and include certain command extensions needed
to implement specific RTL Architect functionality. The RTL Architect command language
provides capabilities similar to Linux command shells, including variables, conditional
execution of commands, and control flow commands. You can
• Enter individual commands interactively at the rtl_shell> prompt in rtl_shell
• Enter individual commands interactively on the console command line in the GUI
• Run one or more Tcl scripts, which are text files that contain rtl_shell commands (see
Using Tcl Scripts)
When entering a command, an option, or a file name, you can minimize your typing by
pressing the Tab key when you have typed enough characters to specify a unique name;
the RTL Architect tool completes the remaining characters. If the characters you typed
could be used for more than one name, the RTL Architect tool lists the qualifying names,
from which you can select by using the arrow keys and the Enter key.
If you need to reuse a command from the output for a command-line interface, you can
copy and paste the portion by selecting it, moving the pointer to the rtl_shell command
line, and clicking with the middle mouse button.
When you run a command, the RTL Architect tool echoes the command output (including
processing messages and any warnings or error messages) in rtl_shell and, if the GUI is
open, in the console log view. By default, the tool does not use page mode, so the output
might scroll. To enable page mode, set the sh_enable_page_mode variable to true.
Interrupting or Terminating Command Processing

If you enter the wrong options for a command or enter the wrong command, you can
interrupt command processing and remain in rtl_shell. To interrupt or terminate a
interrupting commandscommandsinterruptingterminatingterminating commands
command, press Ctrl+C.

Some commands and processes cannot be interrupted. To stop these commands or
processes, you must terminate rtl_shell at the system level. When you terminate a process
or the shell, no data is saved.

S-2021.06-SP4
Feedback
When you use Ctrl+C, keep the following points in mind:

• If a script file is being processed and you interrupt one of its commands, the script
processing is interrupted and no further script commands are processed.
• If you press Ctrl+C three times before a command responds to your interrupt, rtl_shell
is interrupted and exits with this message:
Information: Process terminated by interrupt.
Getting Information About Commands

The following online information resources are available while you are using the RTL
Architect tool:
• Command help, which is information about an RTL Architect command
• Man pages
See Also
• Viewing Man Pages
Displaying Command Help

Command help consists of either a brief description of RTL Architect command or a list of
the options and arguments supported by an RTL Architect command.
• To display a brief description of RTL Architect command, enter the help command
followed by the command name. For example, to display a brief description of the
report_timing command, use the following command:
rtl_shell> help report_timing
• To display the options supported by RTL Architect command, enter the command name
with the -help option on the command line. For example, to see the options supported
by the report_timing command, use the following command:
rtl_shell> report_timing -help

S-2021.06-SP4
Feedback
Using Application Options
Using Application Options

The RTL Architect tool uses application options to control the tool behavior. Application
options use the following naming convention:
category[.subcategory].option_name
where category is the name of the engine affected by the application option. Some
application option categories have subcategories to further refine the area affected by the
application option.
Application options have either a global scope or a block scope.
• Block-scoped application options apply only to the block on which they are set. They
are saved in the design library and are persistent across tool sessions.
• Global-scoped application options apply to all blocks, but only within the current
session. They are not saved in the design library; you must specify them in
each rtl_shell session. You might want to consider adding the global settings to
your .synopsys_rtl.setup file.
To get a list of available application options, use the get_app_options command. By
default, this command lists all application options. To restrict the reported application
options, provide a pattern string as an argument to the command.
For example, to list all available application options, use the following command:
rtl_shell> get_app_options
To list all available timer application options, use the following command:
rtl_shell> get_app_options timer.*
To generate a report of application options, use the report_app_options command.

For detailed information about application options, see Application Options in the RTL
Architect Data Model User Guide.
See Also
Using Variables
In general, the RTL Architect tool modifies default behavior by using application options
rather than application variables; however it does support user-defined Tcl variables, as
well as a minimal number of application variables, such as the search_path variable.

S-2021.06-SP4
Feedback
Viewing Man Pages
To list the variables and their values, use the printvar command. For example, to list all
variables defined in the current session, use the following command:
rtl_shell> printvar *
To print the value of the search_path variable, use the following command:
rtl_shell> printvar search_path
See Also
• Defining the Search Path
Viewing Man Pages

To display the man page for an RTL Architect command or application option, enter the
man command followed by the command or application option name. For example, to see
the man page for the report_timing command, use the following command:
rtl_shell> man report_timing
To display the man page for an RTL Architect application option, enter the man command
followed by the option name. You can also view the following types of summary pages for
application options:
• Category summaries
To view a man page that summarizes all of the application options for a specific
category, enter the man command followed by category_options. For example, to
see the man page that summarizes all timer application options, use the following
command:
rtl_shell> man timer_options
• Subcategory summaries
To view a man page the summarizes all of the application options for a specific
subcategory, enter the man command followed by category.subcategory_options. For
example, to see the man page that summarizes all common route application options,
use the following command:
rtl_shell> man route.common_options

S-2021.06-SP4
Feedback
Using Tcl Scripts
• Command summaries
To view a man page the summarizes all of the application options for a specific
command, enter the man command followed by command_options. For example, to see
the man page that summarizes all application options that affect the report_timing
command, use the following command:
rtl_shell> man report_timing_options
If you enter the man command on the rtl_shell command line, the man page is displayed
in the RTL Architect shell and in the console log view if the GUI is open. If you enter this
command on the console command line in the GUI, the man page is displayed in the GUI
man page viewer.
Using Tcl Scripts

You can use Tcl scripts to accomplish routine, repetitive, or complex tasks. You create a
command script file by placing a sequence of RTL Architect commands in a text file. Any
RTL Architect command can be executed within a script file.
In Tcl, a pound sign (#) at the beginning of a line denotes a comment. For example,
# This is a comment
For more information about writing scripts and script files, see the Using Tcl With
Synopsys Tools manual.
Use one of the following methods to run a Tcl script:
• Use the -file option with the rtl_shell command when you start the RTL Architect
tool.
• Use the source command from the rtl_shell command line.
• Choose File > Execute Script in the GUI.
If an error occurs when running a command, the RTL Architect tool raises the
TCL_ERROR condition, which immediately stops the script execution. To tolerate errors
and allow the script to continue executing, either
• Check for TCL_ERROR error conditions with the Tcl catch command on the
commands that might generate errors.
• Set the sh_continue_on_error variable to true in the script file.
See Also
• Starting the Command-Line Interface

S-2021.06-SP4
Feedback
Using Setup Files
Using Setup Files

When you start the RTL Architect tool, it automatically executes the commands in
the .synopsys_rtl.setup file.
The tool looks for this file both in your home directory and in the project directory (the
current working directory in which you start the RTL Architect tool). The file is read in the
following order:
1. The .synopsys_rtl.setup file in your home directory
2. The .synopsys_rtl.setup file in the project directory
The setup files can contain commands that perform basic tasks, such as initializing
application options and setting GUI options. You can add commands and Tcl procedures to
the setup files in your home and project directories. For example,
• To set application options that define your RTL Architect working environment, create
setup files in your home directory.
• To set project- or block-specific application options that affect the processing of a block,
create a setup file in the design directory.
See Also
• User Interfaces
• Using Application Options
• Using Variables
Using the Command Log File

The command log file records the commands processed by the RTL Architect tool,
including setup file commands and application option settings. By default, the RTL
Architect tool writes the command log to a file named rtl_command.log in the directory
from which you invoked rtl_shell.
You can change the name of the command log file by setting the sh_command_log_file
variable in your .synopsys_rtl.setup file. You should make any changes to this variable
before you start the RTL Architect tool. If your user-defined or project-specific setup
file does not contain this variable, the RTL Architect tool automatically creates the
rtl_command.log file.

S-2021.06-SP4
Feedback
Enabling Multicore Processing
Each RTL Architect session overwrites the command log file. To save a command log file,
move it or rename it. You can use the command log file to
• Produce a script for a particular implementation strategy
• Record the physical implementation process
• Document any problems you are having

Several functions in the RTL Architect tool support multicore processing, whether
through multithreading, distributed processing, or parallel command execution. Multicore
processing improves turnaround time by performing tasks in parallel much more quickly
than if they were run sequentially on a single core.
Note:
A single machine has one or more CPUs and each CPU has one or more
cores. The total number of cores available for processing on a machine is the
number of CPUs multiplied by the number of cores in each CPU.
When using multicore processing, you need one RTL Architect license for every 32 parallel
tasks.
In most cases, you configure multicore processing by using the set_host_options
command. The following topics describe how to use the set_host_options command to
configure multicore processing:
• Configuring Multithreading
• Configuring Distributed Processing
• Reporting Multicore Configurations
• Removing Multicore Configurations
The following topic describes how to use distributed processing to run the same task on
several blocks in a hierarchical design:
• Running Tasks in Parallel
The following topic describes how to use parallel command execution for checking and
reporting commands:
• Running Commands in Parallel on Your Local Host

S-2021.06-SP4
Feedback
Configuring Multithreading
Multithreading performs tasks in parallel by using multiple cores on the same machine,
using a single process memory image. When using multithreading, each parallel task
is called a thread. For the best performance during multithreading, you should limit the
number of threads to the number of available cores, which is the number of CPUs in the
machine times the number of cores per CPU.
By default, all commands use a single thread. To enable multithreading for those
commands that support it, set the -max_cores option of the set_host_options command
to a value greater than one and less than or equal to the number of cores available on
your machine, which is the number of CPUs in the machine times the number of cores per
CPU. The number of cores specified by the -max_cores option applies to all commands
that support multithreading.
When you enable multithreading, multithreaded commands create and use the specified
number of threads, even if the number is more than the number of available cores. You
must set an appropriate number of threads, so that the command does not try to use
more resources than it has. Overthreading can reduce performance because the extra
threads compete for resources. For best performance, do not run more than one thread
per available core.
For example, if your machine has two CPUs and each CPU has three cores, specify six as
the maximum number of threads:
rtl_shell> set_host_options -max_cores 6
Configuring Distributed Processing

Distributed processing performs tasks in parallel by using multiple machines; each process
uses its own process memory image. When using distributed processing, each parallel
task is called a process. For the best performance during distributed processing, you
should limit the number of processes to the number of available cores, which is the sum of
the number CPUs times the number of cores per CPU for each host machine.
When you configure distributed processing, you can specify one or more of the following
settings:
• The job submission command (the -submit_command option)
If you do not specify this option, the tool uses the rsh command to submit the parallel
processes.
• The list of host machines (the host_names argument)
• The maximum number of processes (the -num_processes option)

S-2021.06-SP4
Feedback
By default, the tool assigns a name to each configuration you define with the
set_host_options command. To specify the configuration name, use the -name option.
You use the configuration name to select the configuration to use for specific commands
and to remove a configuration.
For example, to specify a distributed processing configuration that uses the qsub
command to submit the parallel processes, use the following command:
rtl_shell> set_host_options -name dp_config \
-submit_command [list qsub -P bnormal -cwd]
Reporting Multicore Configurations

To report the values set by the set_host_options command, use the
report_host_options command.
Removing Multicore Configurations

To remove the multicore configurations defined by the set_host_options command, use
the remove_host_options command. To remove all multicore configurations, use the
-all option. To remove a specific multicore configuration, specify the configuration name
with the -name option.

S-2021.06-SP4
Feedback
Running Tasks in Parallel

To efficiently run the same task on several blocks in your design, you can use the
run_block_script command to enable distributed processing and perform the tasks
in parallel. The run_block_script command accepts a Tcl script and applies the
commands in the script to the blocks you specify.
To control the order in which blocks are processed, use the -run_order option with the
top_down or bottom-up argument. When you specify the -run_order top-down option,
the tool delays processing for a child block until all parent blocks for the child block are
processed. When you specify the -run_order bottom-up option, the tool begins by
processing the child blocks, then processes the parent blocks. By default, blocks are
processed in a bottom-up order.
Running Commands in Parallel on Your Local Host

You can improve runtime by running checking and reporting commands in parallel on
your local host. You can run the commands either in the background (with the redirect
-bg command) or in the foreground (with the parallel_execute command). These
techniques do not require the use of additional licenses beyond the licenses required for
the parent run. They also do not require you to use or configure distributed processing.
When you use these techniques, consider the following guidelines:
• To reduce runtime and memory usage, run the update_timing command before
running the commands in parallel; otherwise, each command that requires updated
timing runs the update_timing command independently.
• To pass variables from a child process to the parent process, you must write the
contents of the variables to a file during the child process, and then read that file in the
parent process.
See Also
• Running Commands in the Background
• Running Commands in Parallel
Running Commands in the Background

To improve runtime, you can run checking and reporting commands in the background
while you run other commands in the foreground. This is useful in interactive sessions
when you want to continue your work while the tool generates a report.
To run commands in the background, use the redirect command with the -bg option.
When you use this command, rtl_shell returns immediately to execute the next command.

S-2021.06-SP4
Feedback
If you issue an exit command in the parent process, the tool waits for all redirect -bg
commands to complete before exiting.
To list the commands supported by the redirect -bg command, use the list_commands
-bg command. You can run either a single command or source a Tcl script that contains
only supported commands. If the command or script includes a redirect -bg command,
the -bg option is ignored.
You can run at most two jobs in the background. If you specify more than two background
jobs, they are queued.
To specify the maximum number of cores to use for the background jobs, use the
-max_cores option with the redirect command. The number of cores available for
the parent process (as specified by the -max_cores option of the set_host_options
command) is reduced by the number of cores allocated for background jobs.
The following example redirects a Tcl script to run in the background:
rtl_shell> set_host_options -max_cores 8
rtl_shell> redirect -bg -max_cores 3 -file bg_log.out \
{source bg_script.tcl}
Information: redirect -bg with max_cores 3 started. The maximum number of
cores available in parent is reduced to 5. (BGE-004)
Reporting Background Jobs

To report the background jobs submitted with the redirect -bg command, use the
report_background_jobs command. This command reports both the completed jobs and
the jobs currently running in the background, as shown in the following example:
rtl_shell> report_background_jobs
JOB 'redirect -bg -file {background.log} source bg_script.tcl
-max_cores 4 ' completed
JOB(pid:13010) 'redirect -bg -file {background_1.log}
source bg_script_1.tcl -max_cores 3 ' is running
To omit the completed jobs, use the -reset option with the report_background_jobs
command.

S-2021.06-SP4
Feedback
Running Commands in Parallel

To improve runtime, you can run checking and reporting commands in parallel and return
to the parent process after the longest running command in the parallel execution list
completes. This is useful in batch scripts.
To run commands in parallel, use the parallel_execute command, as shown in the
following example:
rtl_shell> update_timing
rtl_shell> parallel_execute {
report_cmd1 log_file1
...
}
To list the supported commands, use the -list_allowed_commands option with the
parallel_execute command.
To specify the maximum number of cores to use when running the parallel_execute
command, use the -max_cores option. If you do not use this option, the tool uses the
value of the -max_cores option from the set_host_options command. If you do not
specify the maximum number of cores with either command, the tool runs the commands
sequentially instead of in parallel.
To run commands in parallel as a background job, use the redirect -bg command to run
the parallel_execute command, as shown in the following example:
rtl_shell> redirect -bg -max_cores 3 -file bg_log.out {
parallel_execute {
}
}

S-2021.06-SP4
Feedback
2
Preparing the Design
Before you can use RTL Architect to analyze your RTL design, you must perform the tasks
described in the following topics:
• Defining the Search Path
• Setting Up Libraries
• Reading the Design
• Mitigating Design Mismatches
• Applying the Multivoltage Power Intent
• Annotating the Switching Activity
• Specifying Logical Constraints
• Splitting Constraints
• Promoting Constraints
• Importing the Floorplan Information
Defining the Search Path

The RTL Architect tool uses a search path to look for files that are specified with a relative
path or with no path.
To specify the search path, use the set_app_var command to set the search_path
application variable to the list of directories, in order, in which to look for files. When
the tool looks for a file, it starts searching in the leftmost directory specified in the
search_path variable and uses the first matching file it finds.
You can also use the Tcl lappend command to add your directories to the default search
path, which is the directory from which you invoked the tool. For example,
rtl_shell> lappend search_path ./mylibdir

S-2021.06-SP4
Feedback
Chapter 2: Preparing the Design
Setting Up Libraries
A block is a container for physical and functional design data. A design library is a
collection of related blocks, together with technology data that applies to the block
collection. A chip design consists of one or more blocks, often stored in different design
libraries. A design library uses instances of blocks defined in lower-level libraries, called
reference libraries. A design library can serve as a reference library for another design
library.
To learn about setting up libraries, see the following topics:
• Working With Design Libraries
• Setting Up Reference Libraries
• Library Configuration
• Restricting Library Cell Usage
• Restricting the Target Libraries Used
• Specifying Library Subset Restrictions
Working With Design Libraries

You can create, open, query, save, or close a design library, using an absolute path, a
relative path, or no path, by using the following commands:
• create_lib
This command creates the library in memory and sets it as the current library. When
you run this command to create a new design library, you must specify the library
name. Slash (/) and colon (:) characters are not allowed in library names. The following
command creates the my_libA library using a relative path:
rtl_shell> create_lib ../my_lib_dir/my_libA
{my_libA}
• open_lib
This command opens the specified library, makes that library the current library, and
opens all its associated reference libraries. Opening a library means loading it into
memory and making its blocks accessible. The following example opens the my_libA
library saved on disk:
rtl_shell> open_lib my_libA
Information: Loading library file '/usr/lib/StdCells.ndm' (FILE-007)
Information: Loading library file '/usr/lib/RAMs.ndm' (FILE-007)

S-2021.06-SP4
Feedback
Information: Loading library file

'/usr/lib/PhysicalOnly.ndm' (FILE-007)
{my_libA}
• current_lib
By default, the library most recently opened is the current library. You can explicitly
set any open library to be the current library by using the current_lib command. For
example,
rtl_shell> current_lib my_libA
{my_libA}
• save_lib
When you create or change a library, the changes are stored in memory only. To save
a library to disk, use this command. For example,
rtl_shell> save_lib lib_A
Saving library 'lib_A'
1
• close_lib
When you no longer need access to data in a library, you can close it by using the
close_lib command. Be sure to save the changes in the library before you close it.
For example,
rtl_shell> close_lib
Closing library 'lib_A'
1
In addition, you can use the current_lib, get_libs, and report_lib commands to
query design libraries.
For more information, see the Design Libraries topic in the RTL Architect Data Model User
Guide.

S-2021.06-SP4
Feedback
Setting Up Reference Libraries

You can specify a reference library list for a design library when you create the design
library by using the -ref_libs option of the create_lib command. You can also change
the reference library list at any time by using the set_ref_libs command.
Use the following commands to specify, rebind, and report reference libraries:
• create_lib -ref_libs
You can specify a relationship between a new design library and its lower-level
reference libraries by using the create_lib command. For example,
rtl_shell> create_lib lib_B \
-ref_libs {../LIBS/lib_c ../STND/stdhvt.ndm} ...
{lib_B}
• set_ref_libs -ref_libs
For an existing design library, open the library and then use the set_ref_libs
command to specify the reference libraries. For example,
rtl_shell> current_lib
{lib_B}
rtl_shell> set_ref_libs \
-ref_libs {../LIBS/lib_C ../STND/stdhvt.ndm}
../LIBS/lib_C ../STND/stdhvt.ndm
• report_ref_libs
To report the reference libraries of a design library, use the report_ref_libs

command.
For example,
rtl_shell> create_lib lib_A -ref_libs \
{../libs/SCLL.ndm ../libs/SCHH.ndm ../BLOCKS/MACROS}
{lib_A}
rtl_shell> report_ref_libs...
Name Path Location
---------------------------------------------------------------
*+ SCLL ../libs/SCLL.ndm /remote/project/libs/SCLL.ndm
*+ SCHH ../libs/SCHH.ndm /remote/project/libs/SCHH.ndm
* MACROS ../BLOCKS/MACROS /remote/project/BLOCKS/MACROS
"*" = Library currently open
"+" = Library has technology information
• set_ref_libs -rebind
When you make a change that invalidates the reference library list, such as moving a
reference library to a new location, you need to rebind the reference libraries. To do

S-2021.06-SP4
Feedback
so, use the -rebind option, which rebinds each reference library path specified by the
search_path variable to libraries that are currently loaded in memory. For example,
rtl_shell> current_lib
{lib_A}
rtl_shell> set_app_var search_path {. ../REFLIBS ../CLIBS}
. ../LIBS ../BLOCKs
rtl_shell> set_ref_libs -rebind
../REFLIBS/lib_C ../REFLIBS/lib_D ../CLIBS/stdhvt.ndm}
Rebinding a library does not affect the bindings of blocks already existing in the design
library. To rebind these blocks using an updated reference library list, use the -rebind
option with the link_block command.
Library Configuration
Library configuration allows you to specify which vendor libraries to use as reference
libraries for the current design. You specify the technology file, physical libraries, and logic
libraries by using the search_path and link_library variables, and then you use the
create_lib or set_ref_libs command to assemble the cell libraries.
During library configuration,

• The RTL Architect tool automatically calls the Library Manager tool without user
intervention to generate cell libraries, as shown in the following figure:
ASCII
.db .frame technology
files files file
Cell
libraries Synthesis
• The tool saves the generated cell libraries to disk and adds them to the reference
library list of the design library.
• These cell libraries are the same as when the cell libraries are created during library
preparation in the Library Manager tool.
For more information, see the Configuring Cell Libraries topic in the RTL Architect Data
Model User Guide.

S-2021.06-SP4
Feedback
Restricting Library Cell Usage

By default, the RTL Architect tool can use all of the library cells available in the cell
libraries when performing optimization or clock tree synthesis on the block. To restrict the
cell usage, use the set_lib_cell_purpose command after the block is in memory. The
command has a block scope and is persistent across tool sessions. The specified settings
are restored when the block is reopened.
To specify how the tool can or cannot use library cells, use the -include and -exclude
options with the set_lib_cell_purpose command. Both of these options accept one or
more of the following values: all, cts, hold, optimization, none.
• The -include option sets the included_purposes attribute on the specified library
cells.
• The -exclude option sets the excluded_purposes attribute on the specified library
cells.
Note:
If a library cell has a dont_use attribute, it is excluded from all uses, which is
the same as if you specified set_lib_cell_purpose -include none for that
cell.
When the tool performs optimization, which includes setup, hold, and logical DRC fixing,
it can use library cells that have an included purpose of optimization, hold, or both.
When the tool performs clock tree synthesis, it can use library cells that have an included
purpose of cts.
For example, to disallow the use of a set of library cells for all uses, use the following
command:
rtl_shell> set_lib_cell_purpose -include none lib_cells
To allow a set of library cells to be used only for clock tree synthesis, use the following
commands:
rtl_shell> set_lib_cell_purpose -include none lib_cells
rtl_shell> set_lib_cell_purpose -include cts lib_cells
To allow a set of library cells to be used for all uses except clock tree synthesis, use the
following command:
rtl_shell> set_lib_cell_purpose -exclude cts lib_cells
To use the asterisk wildcard character (*) to query a collection of cells, you must use the
get_lib_cells command. However, the set_lib_cell_purpose command excludes

S-2021.06-SP4
Feedback
synthetic modules by default. Therefore, you should use the set_synlib_dont_use

command to exclude synthetic modules. For example,
rtl_shell> set_lib_cell_purpose \
-include none [get_lib_cells */*01_*_AB]
Warning: The 'set_lib_cell_purpose' command cannot be used on synthetic
library cell 'standard:*OPMOD.DW01_ADD_AB.timing'. (NDMUI-511)
0
Restricting the Target Libraries Used

By default, the tool can select any library cell from the target library during optimization. In
some cases, you might want to restrict the library cells used for clock tree synthesis and
optimization. For example, you might want to exclude specific double-height cells from the
target library for some design blocks during optimization.
To restrict the library cells used for clock tree synthesis and optimization,
1. Specify the library subset by using the set_target_library_subset command.
By default, the library subset restriction applies to
• The top block and all its subblocks
To set it for a specific subblock, use the -objects option.
• Both clock and data paths.
To set it for only the clock or data paths, use the -clock or -data option.
You can further restrict the target library subset setting as follows:
• Specify a list of cells from the libraries that should not be used by using the
-dont_use option.
• Specify that these libraries cannot be used for any other objects, other than the
specified objects, by using the -only_here option.
2. Enable the use of the target library subset by setting the
opt.common.enable_target_library_subset_opt application option to 1.
When you set target library subsets, remember the following points:
• The subset restriction applies to hierarchical cells but not to leaf cells.
• The command enforces the subset restriction on the specified blocks and their
subdesigns in the hierarchy, except those subdesigns where a different subset
restriction is set.
• A subset specified at a lower level supersedes any subset specified at a higher level.

S-2021.06-SP4
Feedback
Figure 2 Logic Hierarchy of Design
For example, assume your design has a logic hierarchy as shown in Figure 2 and you
want to implement the following library restrictions during optimization and clock tree
synthesis:
• Use only the cells from the library named LVT_lib for the Sub1 block and its subblocks,
SubA and SubB.
• Do not use the cells from this library anywhere else in the design.
To do so, use the following settings:
rtl_shell> set_target_library_subset -objects {top/Sub1} \
-only_here [get_lib_cells LVT_lib/*] [get_libs LVT_lib]
rtl_shell> set_app_options \
-name opt.common.enable_target_library_subset_opt -value 1
In addition to these settings, assume you specify the following setting:

rtl_shell> set_lib_cell_purpose -include cts \
{HVT_lib/buf1 HVT_lib/buf2 LVT_lib/buf1 LVT_lib/buf2}
Then, when adding buffers on the clock network during clock tree synthesis, the tool uses
• The buf1 and buf2 cells from the LVT_lib library for the block named Sub1 and its
subblocks
• The buf1 and buf2 cells from the HVT_lib library for the rest of the design
Reporting Target Library Subsets
To find out which target library subsets have been defined for a top block or hierarchical
cell, use the report_target_library_subset command.
Reports that are generated by reporting commands, such as report_cells and
report_timing, show the td attribute attached to the cells that are specified by the
-dont_use or -only_here option.

S-2021.06-SP4
Feedback
Removing Target Library Subsets

To remove a target library subset restriction from a top block or hierarchical cell, use the
remove_target_library_subset command.
Specifying Library Subset Restrictions

You can restrict the mapping and optimization of sequential cells and instantiated
combinational cells to a subset of reference libraries and library cells. To specify one or
more library subset restrictions, use the define_libcell_subset command followed by
the set_libcell_subset command.
Note:
The library subset restrictions apply to leaf cells, but not to hierarchical cells.
To set library subset restrictions on leaf cells,
1. Define a subset of library cells by using the define_libcell_subset command.
After the library cells are grouped into a subset, they are not available for general
mapping during optimization, but for sequential cells and instantiated combinational
cells only.
2. Restrict the optimization of sequential and instantiated combinational cells by using the
set_libcell_subset command.
During optimization, the tool uses the library subset defined in step 1 to optimize
sequential cells (both mapped and unmapped) and mapped combinational cells.
In the following example, the define_libcell_subset command groups the
SDFLOP1 and SDFLOP2 library cells into a subset called special_flops, and then the
set_libcell_subset command restricts the mapping of the LEAF1 leaf cell to the
special_flops library subset.
rtl_shell> define_libcell_subset \
-libcell_list "SDFLOP1 SDFLOP2" -family_name special_flops
rtl_shell> set_libcell_subset \
-object_list "HIER1/LEAF1" -family_name special_flops
Reporting Library Subset Restrictions

To report library subsets specified for sequential cells and instantiated combinational cells,
use the report_libcell_subset command.
Removing Library Subset Restrictions
To remove library subsets, use the remove_libcell_subset command.

S-2021.06-SP4
Feedback
Reading the Design
Reading the Design

Before you read a design, you must create or open the design library associated with the
design, as described in Setting Up Libraries.
The tool can read RTL designs in SystemVerilog, Verilog, or VHDL and gate-level netlists
in Verilog format.
Note:
To use the RTL restructuring capabilities, you must set the
rtl_restructuring.enable_restructured_rtl_generation application
option to true before analyzing and elaborating the RTL. RTL restructuring is
supported only for SystemVerilog and Verilog.
Use the following methods to read designs:
• Reading RTL Files in SystemVerilog, Verilog, or VHDL Format
• Reading Designs Using the -autoread Option
• Reading Designs Using the VCS Command-line Options
By default, when the tool reads the RTL or gate-level netlist files, it creates a block in the
current design library and increments its open count. The tool determines the top-level
module of the block by identifying the module that is not instantiated by any other modules
in the specified files and uses the top-level module name as the block name.
Use the following commands to work with blocks:
• create_block: Creates a block
• open_block: Opens an existing block
• current_block: Sets or reports the current block
• save_block: Saves a block
• close_blocks: Closes a block
See Also
• Working With Design Libraries
Reading RTL Files in SystemVerilog, Verilog, or VHDL Format

Use the analyze and elaborate commands followed by the set_top_module command.
The analyze command automatically creates HDL template libraries on disk based on
the name of the library provided by the -hdl_library option. The location of the HDL

S-2021.06-SP4
Feedback
Reading the Design
template libraries is controlled by the hdlin.hdl_library.default_dirname application

option. When the -hdl_library option is not specified, the default library name is WORK.
To specify a different default library name, use the hdlin.hdl_library.default_name
application option.
Note:
All of the application options that control the RTL reading behavior have the
hdlin prefix.
The elaborate command builds the module specified without linking the rest of the
design. Design linking can be performed only after the entire design is in memory, so
linking is not performed by the elaborate command. This allows multiple elaborate
commands to be run before performing the single linking of the entire design. The top-level
module must be one of the modules that is elaborated.
Linking of the design and setting the top-level module is done using the set_top_module
command. The top-level module is given as an argument to the set_top_module
command. The top-level module must be a module that was previously elaborated with the
elaborate command. The set_top_module command sets the specified module to be
the top-level design, links the entire design, and creates a single block to be used for the
remainder of the synthesis flow.
The following script reads VHDL files using template libraries and creates a block called
top. You do not need to specify the location of the template libraries on disk, which is
automatically created by the analyze command based on the -hdl_library option.
analyze -format vhdl -hdl_library BOT_HDL_LIB bot.vhd
analyze -format vhdl -hdl_library MID_HDL_LIB mid.vhd
analyze -format vhdl top.vhd
elaborate top
set_top_module top
If the top-level design is analyzed to an HDL template library other than the default library,
you should provide the HDL template library name for the top-level design using the
-hdl_library option. For example,
analyze -format vhdl -hdl_library TOP_HDL_LIB top.vhd
elaborate -hdl_library TOP_HDL_LIB top
set_top_module top
You can optionally specify the location of the HDL template libraries on disk by using the
define_hdl_library command. For example,
define_hdl_library BOT_HDL_LIB -path ./TEMPLATES/BOT_HDL_LIB
define_hdl_library MID_HDL_LIB -path ./TEMPLATES/MID_HDL_LIB
define_hdl_library WORK -path ./TEMPLATES/WORK

S-2021.06-SP4
Feedback
Reading the Design

analyze -format vhdl top.vhd
elaborate top
set_top_module top
Reading Designs Using the -autoread Option

To enable the tool to automatically read a list of RTL files, specify the -autoread
option with the analyze command, as shown in the following example. When this
option is specified, the RTL language used to analyze the RTL files is automatically
determined by the file name extension. To control the file name extensions,
use the following application options: hdlin.autoread.verilog_extensions,
hdlin.autoread.sverilog_extensions, hdlin.autoread.vhdl_extensions, and
hdlin.autoread.exclude_extensions.
set DESIGN_NAME top
analyze -autoread -top ${DESIGN_NAME} ${RTL_FILE_LIST}
elaborate ${DESIGN_NAME}
elaborate -hdl_library TOP_HDL_LIB top
set_top_module ${DESIGN_NAME}
Reading Designs Using the VCS Command-line Options

The analyze command with the VCS command-line options provides compatibility with
VCS simulation scripts and makes reading large designs easier. When you use the VCS
command-line options, the tool automatically resolves references for instantiated designs
by searching the referenced designs in the specified libraries and then loading these
referenced designs.
To read designs containing many HDL source files and libraries, specify the -vcs option
with the analyze command. You must enclose the VCS command-line options in double
quotation marks.
For example,
analyze -vcs "-verilog -y mylibdir1 +libext+.v -v myfile1 \
+incdir+myincludedir1 -f mycmdfile2" top.v
To read SystemVerilog files with a specified file extension and Verilog files in one analyze
command, use the -vcs "+systemverilogext+ext" option. When you do so, the files
must not contain any Verilog 2001 styles.

S-2021.06-SP4
Feedback
Mitigating Design Mismatches
For example, the following command analyzes SystemVerilog files with the .sv file
extension and Verilog files:
analyze -format verilog -vcs "-f F +systemverilogext+.sv
Mitigating Design Mismatches

During early design development, frequent design updates can cause incomplete or
inconsistent data, such as pin mismatches between a block-level design and the reference
to it from a top-level design. To enable the tool to successfully link a block even if it has
certain types of design mismatch, set a mismatch configuration for the block.
By default, the tool cannot link any block with inconsistent or mismatching data. When
you set mismatch configurations, the tool either ignores or fixes several different types of
mismatching data and continues the linking process. Blocks linked with mismatching data
can be used only for feasibility analysis.
To learn how to mitigate design mismatches, see the RTL Architect Data Model User
Guide.
Applying the Multivoltage Power Intent

To learn about applying the multivoltage power intent, see
• Loading and Applying UPF Information
• Saving UPF Information
Loading and Applying UPF Information

To load the power intent and apply it to a multivoltage design,
1. Read the UPF file by using the load_upf command.
rtl_shell> load_upf block.upf
2. If you are using the golden UPF flow and have a name-mapping file, read the file by
using the read_name_map command.
rtl_shell> read_name_map block.nmf

S-2021.06-SP4
Feedback
Applying the Multivoltage Power Intent
3. (Optional) Verify the UPF consistency and identify any PG conflicts among the netlist,
floorplan, and power intent.
To verify the UPF consistency and identify PG conflicts, use the resolve_pg_nets
-check_only command. This command identifies any issues and reports the changes
that are made to resolve these issues when you commit the power intent. If you prefer
to resolve the issues differently, you can use manual editing commands to resolve the
issues before running the commit_upf command.
4. Commit the power intent by using the commit_upf command.
rtl_shell> commit_upf
The commit_upf command performs global checks for UPF consistency; resolves PG
conflicts among the netlist, floorplan, and UPF specification; and associates power
strategies with existing multivoltage cells.
5. Report the associations made for the multivoltage cells by using the report_mv_path
command.
If the tool failed to associate any multivoltage cells, the command reports the causes
for these failures. You must successfully commit the power intent before you continue
with the design flow.
Note:
After successfully running the commit_upf command, the tool issues an
error message if you try to use additional UPF commands, except for the
set_related_supply_net, connect_supply_net, set_design_attributes,
set_port_attributes, find_objects, and set_scope commands. To modify
the power intent after running the commit_upf command, you must remove the
existing UPF specification by using the reset_upf command and then reload
the power intent.
Saving UPF Information

During physical implementation, the tool updates the power intent of the design. To
generate an updated UPF file, use the save_upf command. You can use this UPF file in
the subsequent steps of the design flow.
The save_upf command separates the UPF commands based on the input UPF file, and
adds a comment indicating the input UPF file and the time it was loaded.
Assume you load, commit, and save UPF information as shown in the following example
script:
load_upf top_1.upf
load_upf top_2.upf
load_upf top_3.upf

S-2021.06-SP4
Feedback
Annotating the Switching Activity
commit_upf
save_upf top.upf
The resulting top.upf file contains the following information:

## Start - load_upf top_1.upf on Wed Oct 26 17:03:18 2016
…
…
## End – load_upf
…
…
## End - load_upf
…
…
## End - load_upf

When performing low-power placement and dynamic-power optimization, you obtain better
power savings if you annotate switching activity on the design. You can annotate the
switching activity in the following ways:
• Read a switching activity file (SAIF) by using the read_saif command.
The switching activity is scenario specific. So, when you use this command, ensure
that the current scenario is enabled for dynamic power optimization.
• Set the switching activity by using the set_switching_activity command.
When you use this command, you can set the switching activity for a specific mode,
corner, or scenario by using the -mode, -corner, or -scenario options. When doing
so, ensure that the scenarios you specify or the scenarios corresponding to the modes
and corners you specify are enabled for dynamic power optimization.
If you do not specify the switching activity, the tool applies the default toggle rate to the
primary inputs and black box outputs and then propagates it throughout the design.
To report the switching activity of a block, use the report_activity command. To
remove switching activity of specific nets, pins, ports, or the entire block, use the
reset_switching_activity command.

S-2021.06-SP4
Feedback
Scaling the Switching Activity

If the clock frequency used in the SAIF file is different from the clock frequency used in the
RTL Architect tool, you can scale the switching activity by performing the following steps:
1. Read in the SAIF file by using the read_saif command.
2. Enable scaling by setting the power.use_generated_clock_scaling_factor
application option to on.
3. Scale the switching activity by using the set_power_clock_scaling command.
When you use this command, you must specify the following:
• The clock objects associated with the switching activity you want to scale
• The clock period used in the SAIF file by using the -period option or the ratio
between the clock period used in the SAIF file and the clock period used in the RTL
Architect tool by using the -ratio option
In addition, you can specify the scenario for which to apply the scaling by using the
-scenario option.
The following example reads in a SAIF file, enables scaling, scales the switching activity
associated with clocks named CLK1 and CLK2 by a ratio of five, and scales the switching
activity associated with clock named CLK3 by a ratio of two:
rtl_shell> read_saif top.saif
rtl_shell> set_app_options -list \
{power.use_generated_clock_scaling_factor true}
rtl_shell> set_power_clock_scaling -ratio 5 {CLK1 CLK2}
rtl_shell> set_power_clock_scaling -ratio 2 {CLK3}
If you run the set_power_clock_scaling command again for the same clock, the tool
scales the already scaled switching activity.
When you use the set_power_clock_scaling command, the tool scales only the
switching activity applied with the read_saif command. The tool does not scale the
following:
• Switching activity applied with the set_switching_activity command
• Switching activity within block abstracts
The scaled switching activity is persistent in the design. You can write it out by using the
write_saif command and use it in the subsequent steps of the design flow.

S-2021.06-SP4
Feedback
Specifying Switching Probability for Supply Nets

The leakage power of a block is scaled based on the switching probability of its
supply nets, which represents the fraction of time a supply net is in the on state.
You can specify the switching probability for one or more supply nets by using the
set_supply_net_probability -static_probability command. By default, the
switching probability is applied to the current scenario and the corresponding mode and
corner. To specify modes, corners, or scenarios in which to apply the setting, use the
-modes, -corners, or -scenarios option. To get the switching probability of a supply
net, use the get_supply_net_probability command, and to reset the value, use the
reset_supply_net_probability command.
By default, the tool propagates supply net activity through power switches and determines
the static probability of the switched supply net based on the UPF power switch constraint.
For example, consider the following UPF power switch constraint:
create_power_switch my_switch \
-output_supply_port {vout VDDS} \
-input_supply_port {vin VDD} \
-control_port {ms_sel ctrl1} \
-control_port {ms_ctrl ctrl2} \
-on_state {on vin {ms_ctrl && !ms_sel}}
The tool derives the static probability of the supply net named VDDS, which is connected
to the output of the power switch, based on the probability of the power switch being on.
This is derived based on the following:
• The Boolean function specified with the -on_state option, which is ms_ctrl && !
ms_sel, and the switching activity (static probability) of the nets connected to the
corresponding control ports, which are nets named ctrl1 and ctrl2.
• The switching probability of the supply net connected to the input supply port specified
with the -on_state option, which is the supply net named VDD.
The following application options control whether dynamic and leakage power are scaled
based on the supply switching activity:
• The power.scale_dynamic_power_at_power_off option controls whether dynamic
power is scaled. The default is false (no scaling).
• The power.scale_leakage_power_at_power_off option controls whether leakage
power is scaled. The default is true (scaling is performed).

S-2021.06-SP4
Feedback
Specifying Logical Constraints

Logical constraints are declarations that define your design goals in measurable circuit
characteristics, which the RTL Architect too uses to effectively optimize the design. Logical
constraints include
• Design rule constraints, which reflect technology-specific restrictions that your design
must meet to function as intended
For details, see Specifying Logical Design Rule Constraints.
• Timing constraints and settings, which describe the speed and conditions under which
the design might operate
For details, see Specifying Timing Constraints and Settings.
Specifying Logical Design Rule Constraints

Minimum capacitance, maximum capacitance, and maximum transition are logical design
rule constraints that your design must meet to function as intended. They are technology-
specific restrictions that are specified in the logic libraries. However, you can specify more
restrictive design rule constraints by using the constraint commands given in Table 1.
During optimization, the RTL Architect tries to meet the design rule constraints, even if
it means violating optimization constraints such as timing, power, and area goals; these
design rule constraints have a higher priority. After optimization, you can use the reporting
commands given in Table 1 to identify design rule constraint violations in a block.
Table 1 Design Rule Commands
To do this Use this command
Specify the minimum allowed capacitance for input ports, set_min_capacitance

library cell pins, leaf cell pins, clocks, or blocks
Specify the maximum allowed capacitance for input ports, set_max_capacitance

library cell pins, leaf cell pins, clocks, or blocks
Specify the maximum allowed signal transition time for set_max_transition

input ports, library cell pins, leaf cell pins, clocks, or blocks
Remove a user-specified minimum capacitance constraint remove_min_capacitance
Remove a user-specified maximum capacitance constraint remove_max_capacitance
Remove a user-specified maximum transition constraint remove_max_transition
Report minimum capacitance constraint violations report_constraints -min_capacitance

S-2021.06-SP4
Feedback
Table 1 Design Rule Commands (Continued)
To do this Use this command
Report maximum capacitance constraint violations report_constraints -max_capacitance
Report maximum transition constraint violations report_constraints -max_transition
Specify the connection requirements for the network that is For ports:
connected to the specified ports or library cell pins set_connection_class
For pins:
set_attribute \
-name connection_class
Note:
The maximum fanout design rule constraint is not honored by the RTL Architect
tool. However, you can specify a maximum fanout for the data paths in a
block by using the opt.common.max_fanout application option. This is a soft
optimization constraint. During optimization the tool tries to ensure that data
path cells do not drive more than the specified maximum fanout.
Specifying Timing Constraints and Settings

Timing constraints describe the timing requirements of a design. An essential part of
timing constraints are accurately specified clocks and clock effects, such as latency and
uncertainty. When you specify clocks, the tool automatically constrains the paths between
the registers driven by these clocks. However, you can change the default behavior of
these timing paths by specifying timing exceptions such as paths that should not be
analyzed (false paths), paths that require multiple clock cycles (multicycle paths), and so
on. In addition, you can constrain the boundary timing paths by specifying input and output
delays for input and output ports.
The RTL Architect tool uses on-chip variation (OCV) mode to perform timing analysis,
which models the effects of variation in operating conditions across the chip. This mode
performs a conservative timing analysis that allows both minimum and maximum delays to
apply to different paths at the same time. For a setup check, it uses maximum delays for
the launch clock path and data path and minimum delays for the capture clock path. For a
hold check, it uses minimum delays for the launch clock path and data path and maximum
delays for the capture clock path.
A block might operate under several different conditions, such as different temperatures
and voltages, and might operate in several different functional modes. For timing analysis,
each set of conditions is represented by a corner and each functional mode is represented
by a mode. A scenario is a combination of a corner and mode used to perform timing

S-2021.06-SP4
Feedback
Splitting Constraints
analysis and optimization. Before you start working with a block, you must define the
modes, corners, and scenarios that are used for the block, as well as the delay calculation
model and routing layers to use. The routing layer information you specify is used for RC
estimation during timing analysis.
For detailed information about specifying
• Clock and clock effects, see the “Defining Clocks” topic in the RTL Architect Timing
Analysis User Guide.
• Exceptions for timing paths and constraints for boundary paths, see the “Constraining
Timing Paths” topic in the RTL Architect Timing Analysis User Guide.
• Modes, corners, and scenarios, see the “Defining Modes, Corners, and Scenarios”
topic in the RTL Architect Timing Analysis User Guide.
• Operating conditions and on-chip variation (OCV) related settings, see the “Specifying
Operating Conditions” topic in the RTL Architect Timing Analysis User Guide.
• Parasitic information for RC estimation and extraction, see the “Performing Parasitic
Extraction” topic in the RTL Architect Timing Analysis User Guide.
If you have only chip-level constraints for your design, you can use the
split_constraints command to partition the full-chip SDC and UPF constraints
and create separate top-level and block-level constraint files. After running the
split_constraints command, the top-level constraint file contains the top-level UPF and
all top-level and top-to-block boundary timing, without block-level internal constraints. The
block-level constraint files contain internal constraints for the specified block and are used
during block-level optimization.
You can also split constraints automatically as part of the rtl_opt command's hierarchical
flow. For more information, see rtl_opt Hierarchical Flow.
To split the chip-level SDC and UPF constraints,
1. Read the RTL design, as described in Reading the Design.
2. Load and commit the top-level UPF file as described in Applying the Multivoltage
Power Intent.
3. Set up the top-level timing environment as described in Specifying Logical Constraints.
For a design with multiple modes and corners, you must use one or more of the
following commands:
create_corner
create_mode

S-2021.06-SP4
Feedback
read_sdc
set_corner_status
set_parasitic_parameters
set_process_number
set_temperature
set_voltage
If your design uses UPF to describe the power network, you must use the
set_voltage command for all supply net groups defined in the UPF file.
4. Split the timing constraints and UPF file into separate files for each block.
rtl_shell> split_constraints
5. Calculate the input and output delays for the subblock pins as described in Calculating
Subblock Pin Delays.
Split Constraints Options
Use the following options with the split_constraints command to control how the
constraints are split.
• Split only the SDC file or the UPF file with the -sdc_only or -upf_only option.
rtl_shell> split_constraints -sdc_only
rtl_shell> split_constraints -upf_only
• Retain internal constraints for subblocks when using hierarchical abstracts with the
-hier_abstract_subblocks option. Use this option to indicate that the specific blocks
are represented as hierarchical abstracts.
rtl_shell> split_constraints -hier_abstract_subblocks block_names
• Write the constraint files only for certain modes with the -modes option.
rtl_shell> split_constraints -modes {s1.mode}
• Write the constraint files only for certain corners with the -corners option.
rtl_shell> split_constraints -corners {s1.corner}
• Compress the output constraint files with the -compress gzip option.
rtl_shell> split_constraints -compress gzip
• Specify the output directory to use with the -output option.

rtl_shell> split_constraints -output split2

S-2021.06-SP4
Feedback
Promoting Constraints
Calculating Subblock Pin Delays

By default, the split_constraints command does not calculate input and output delays
for the subblock pins. To enable this calculation, use one of the following methods:
• Logic-depth based calculation
To enable this method, use the -logic_depth option with the split_constraints
command.
rtl_shell> split_constraints -logic_depth
To consider the odd or even number of buffers when performing the logic-depth-based
calculation, use the -ignore_repeaters option.
rtl_shell> split_constraints -logic_depth -ignore_repeaters
• Percentage-based calculation
To enable this method, use the -internal_percent option to specify the percentage
to allocate to the input and output delays.
rtl_shell> split_constraints -internal_percent \
{input_percent output_percent}
With either method, by default, feedthrough pins are budgeted at 50% of the available
clock cycle. To modify this value, use the -feedthrough_percent option to specify the
percentage to use for the input and output delays. This option must be used with either the
-logic_depth or -internal_percent option.
rtl_shell> split_constraints -logic_depth \
-feedthrough_percent {input_percent output_percent}
If your design contains logical hierarchy, specify the intermediate levels of hierarchy with
the -design_subblocks option. The nested modules in the design hierarchy are not
abstracted when they are used in the context of their parent block.
rtl_shell> split_constraints -design_subblocks {block_1 block_2}
For hierarchical designs, the tool supports constraint promotion up the logic hierarchy. The
constraints specified by the block-level SDC files are used as a reference for the promoted
constraints. To promote constraints from lower-level blocks to the top-level design, use the
promote_constraints command.
Before promoting constraints, you can use the -report_only option to generate
a preview of the promoted constraints. All preview reports can be found in the

S-2021.06-SP4
Feedback
promote_constraints/report_only/block_instance directory. The directory and files are

overwritten each time the promote_constraints command is run.
The following example generates a preview for the constraints promoted from corner c1
for all the block instances that are directly instantiated in the current design:
rtl_shell> promote_constraints -all -corners c1 -report_only
You can promote the constraints from one or more of the immediate child blocks of the
top-level block. Use exactly one of the following methods to specify the blocks:
• To promote the constraints from all immediate child blocks of the top-level design, use
the -all option.
The following example promotes the constraints from all immediate child blocks:
rtl_shell> promote_constraints -all
• To promote the constraints from a specific child block, use the block argument.
The following example promotes the constraints only from block1:
rtl_shell> promote_constraints block1
• To promote a list of child blocks, use the -blocks option. The following example
promotes the constraints from block1 and block2:
rtl_shell> promote_constraints -blocks {block1 block2}
You can promote the constraints only for specific modes or corners.
• To promote specific modes, use the -modes option. For example,
rtl_shell> promote_constraints -all -modes mode_list
• To promote specific corners, use the -corners option. For example,

rtl_shell> promote_constraints -all -corners corner_list
By default, all constraints are included when promoting constraints. You can specify
constraints to include or exclude when promoting constraints.
• To promote a specific list of constraints, use the -include option. Clocks are
automatically included when using the -include option.
The following example promotes only the input delay constraints from all blocks:
rtl_shell> promote_constraints -all -include input_delay

S-2021.06-SP4
Feedback
Importing the Floorplan Information
• To skip a list of specific constraints, use the -exclude option.

The following example promotes all constraints except the output delay constraints
from block1 and block2:
rtl_shell> promote_constraints -blocks {block1 block2} -exclude
output_delay
The -include and -exclude options are mutually exclusive. For a complete list of valid
constraints that can be included or excluded, see the man page.
If there are any conflicts between the lower-level blocks and the top-level design, the tool
issues an error message. To ignore these errors, use the -force option. The -force
option also allows unmapped clocks in the design when promoting constraints.
The promote_constraints command also promotes block clocks. When matching a top
clock to a block clock, the command assigns the top clock as the master and the block
clock as the source. If there is no top-level clock connected to the block clock, the tool
creates a new clock.
All modes in the top level must be mapped to a mode in the block level. By default, the
promote_constraints command uses the same name for the top mode and block mode.
To specify the mapping for modes, use the set_block_to_top_map command.
You can write the clock-mapping file in the same format as block-to-top mapping files for
all clocks with the -write_clock_map option. There are separate sections for virtual and
nonvirtual clock mapping. Probable top-level clocks for the block-level clocks are also
written out. If there are no top-level clocks, you can use the -write_top_clock_points
option to write out all possible clock definitions at the top level. The clock-mapping file is
written out to the promote_constraints/clock_map/promoted_clock_map.tcl file. Each time
the promote_constraints command is used, the clock-mapping file is overwritten.
To create an enhanced message service (EMS) database in your current directory, use the
-enable_ems option. You can view the EMS database in the ./promote_constraints.ems
file.
rtl_shell> promote_constraints -all -enable_ems
After promoting constraints, a summary of the promoted constraints statistics is written out
in the promote_constraints/summary/promoted_constraints_summary.tcl file.

A floorplan contains physical constraints such as the core area and shape, port locations,
macro locations and orientations, and so on, which are required for performing physical
synthesis and optimization.

S-2021.06-SP4
Feedback
If you have a floorplan for your block, read in the floorplan as a DEF file, as described in
Reading DEF Files.
If you do not have a floorplan for your block, you can use automatic floorplanning, as
described in Using Automatic Floorplanning.
Reading DEF Files

To read the floorplan information from a DEF file, use the read_def command.
rtl_shell> read_def block.def
Note:
When possible, use DEF v5.8 or later, as this version supports more types of
physical objects and obstructions than previous versions.
By default, the read_def command
• Annotates the floorplan information onto the current block
To annotate the information onto a different block, use the -design option to specify
the block name.
• Preserves the existing floorplan information
In incremental mode,
◦ The placement area is imported based on the current core area and site rows in the
DEF files
◦ Physical constraints that can have only one value are overwritten by the value from
the latest DEF file; for example, port location and macro location are overwritten.
◦ Physical constraints that can have accumulated values are recomputed; that
is, core area can be recomputed based on the existing value and the site row
definitions in the latest DEF file. Placement keepouts from different DEF files
are accumulated and the final keepout geometry is computed internally during
synthesis.
To remove the existing floorplan information before annotating the floorplan information
from the DEF file, use the -no_incremental option. In this mode, the placement area
is imported based on the site rows in the DEF files.
• Uses rule-based name matching for macros and ports

S-2021.06-SP4
Feedback
Rule-based name matching automatically resolves name differences by using the tool’s
intelligent name matching capability. By default, when rule-based name matching is
enabled, the following characters are considered equivalent:
◦ Hierarchical separators { / _ . }
For example, a cell named a.b_c/d_e is automatically matched with the string a/
b_c.d/e in the DEF file.
◦ Bus notations { [ ] __ ( ) }
For example, a cell named a [4] [5] is automatically matched with the string
a_4__5_ in the DEF file.
To disable rule-based name matching and require exact name matches between the
DEF file and the block, set the file.def.rule_based_name_matching application
option to false.
For more information, see “Rule-Based Name Matching” in the RTL Architect Data
Model User Guide.
• Ignores any objects in the DEF file that do not exist in the block, except for PG objects
To allow new non-PG objects to be created from the DEF file, use the
-add_def_only_objects option to specify the types of objects to create. Specify one
or more of the following keywords:
◦ cells
The tool creates the cells that exist only in the DEF file and connects their power
and ground pins as defined in the DEF file; it does not connect the signal, clock, or
tie pins even if these connections are defined in the DEF file. The tool also does not
create new hierarchical cells; any hierarchy specified in the DEF file must already
exist in the block.
◦ nets
The tool creates the signal, clock, and tie nets that exist only in the DEF file
and connects them to the ports specified in the DEF PINS section; it does not
connect the nets to any other ports or pins in the netlist even if these connections

S-2021.06-SP4
Feedback
are defined in the DEF file. The tool does not create new hierarchical nets; any
hierarchy specified in the DEF file must already exist in the block.
◦ ports
The tool creates the signal, clock, and tie ports that exist only in the DEF file and
connects them to the nets specified in the DEF PINS section.
◦ all
The tool creates the non-PG cells, nets, and ports that exist only in the DEF file, as
if you had specified cells, nets, and ports.
Fixing Site Name Mismatches

If the site names used in the DEF file do not match the site names defined in the
technology file, use the -convert_sites option to specify the site name mapping. For
example, if the DEF file uses a site named CORE, but the technology file defines only a
site named unit, use the following command to convert the site names when reading the
DEF file:
rtl_shell> read_def -convert_sites { {CORE unit} } block.def
Validating DEF Files

To analyze the input DEF files before annotating the floorplan information on the block,
enable check-only mode by using the -syntax_only option. The check-only mode
provides diagnostic information about the correctness and integrity of the DEF file. The
check-only mode does not annotate any floorplan information onto the block.
rtl_shell> read_def -syntax_only block.def
Physical Constraints Extracted From the DEF File

The read_def command extracts physical constraint information from DEF files and
annotates it on the block. However, only the following physical constraints are extracted
and annotated:
• Placement Area
• Port Locations
• Cell Locations
• Placement Blockages
• Site Rows
• Routing Tracks
• Placement Bounds

S-2021.06-SP4
Feedback
• Routing Blockages
• Preroutes
To visually inspect the extracted physical constraints, use the layout view in the GUI. All
physical constraints extracted from the DEF file are automatically added to the layout view.
Placement Area
Placement area is computed based on the site array information.
Port Locations
For each port with the location specified in the DEF file, the tool sets the location on the
corresponding port in the block.
Note:
If the DEF file does not contain port-location information, the tool inherits the
port locations from the locations of the pad cells, as described in Ensuring Port
Locations are Inherited From Pads.
Example 1 DEF Port Location Information

PINS 2 ;
-Out1 + NET Out1 + DIRECTION OUTPUT + USE SIGNAL +
LAYER M3 (0 0) (4200 200) + PLACED (80875 0) N;
-Sel0 + NET Sel0 + DIRECTION INPUT + USE SIGNAL +
LAYER M4 (0 0)(200 200) + PLACED (135920 42475) N;
END PINS
Ports with changed names and multiple layers are supported.
Example 2 DEF Port Locations With Changed Names and Multiple Layers
PINS 2 ;
- sys_addr\[23\].extra2 + NET sys_addr[23] + DIRECTION INPUT +USE
SIGNAL
+ LAYER METAL4 ( 0 0 ) ( 820 5820 ) + FIXED ( 1587825 2744180 ) N ;
- sys_addr[23] + NET sys_addr[23] + DIRECTION INPUT + USE SIGNAL +
LAYER
METAL3 ( 0 0 ) ( 820 5820 ) + FIXED ( 1587825 2744180 ) N ;
END PINS
Example 3 DEF Port Orientation Information

PINS 1;
- OUT + NET OUT + DIRECTION INPUT + USE SIGNAL
+ LAYER m4 ( -120 0 ) ( 120 240 )
+ FIXED ( 4557120 1726080 ) S ;
END PINS

S-2021.06-SP4
Feedback
Cell Locations
For each cell with a location and the FIXED attribute specified in the DEF file, the tool
sets the location on the corresponding cell in the block. Example 4 shows DEF macro
location and orientation information, where the letters E and W denote east rotation and
west rotation respectively.
Example 4 DEF Cell Location Information

COMPONENTS 2 ;
- macro_cell_abx2 + FIXED ( 4350720 8160 ) E ;
- macro_cell_cdy1 + FIXED ( 4800 8160 ) W ;
END COMPONENTS
Placement Blockages
The read_def command imports hard, soft, and partial placement blockages defined in
the DEF file.
Note:
DEF versions before version 5.7 did not support partial blockages. In addition,
if your floorplanning tool creates a DEF file with DEF version 5.6, you need to
manually add the #SNPS_SOFT_BLOCKAGE pragma to specify a soft blockage, as
shown in Example 7.
Example 5 DEF Hard Placement Blockage Information

BLOCKAGES 50 ;
...
- PLACEMENT RECT ( 970460 7500 ) ( 3247660 129940 )
...
END BLOCKAGES
Example 6 DEF Version 5.7 Soft Placement Blockage Information

BLOCKAGES 50 ;
...
- PLACEMENT + SOFT RECT ( 970460 7500 ) ( 3247660 129940 ) ;
...
END BLOCKAGES
Example 7 DEF Version 5.6 Soft Placement Blockage Information

BLOCKAGES 50 ;
...
- PLACEMENT RECT ( 970460 7500 ) ( 3247660 129940 ) ;
#SNPS_SOFT_BLOCKAGE
...
END BLOCKAGES

S-2021.06-SP4
Feedback
Example 8 DEF Partial Placement Blockage Information

BLOCKAGES 50 ;
...
- PLACEMENT + PARTIAL 80 RECT ( 970460 7500 ) ( 3247660 129940 ) ;
...
END BLOCKAGES
Site Rows
Site row information in the DEF file defines the placement area.
Example 9 DEF Site Row Information

ROW ROW_0 core 0 0 N DO 838 BY 1 STEP 560 0;
Routing Tracks
The track information in the DEF file defines the routing grid for designs based on
standard cells. This information can be used during routing, and track support can
enhance congestion evaluation and reporting to make it match more closely with the
routing results.
Example 10 DEF Routing Track Information

TRACKS X 330 DO 457 STEP 660 LAYER METAL1 ;
TRACKS Y 280 DO 540 STEP 560 LAYER METAL1 ;
Placement Bounds
If REGIONS defining bounds exist in the DEF file, the read_def command imports those
placement bounds. Also, if any cells in the related GROUP are attached to the region,
fuzzy cell matching occurs between these cells and the ones in the block.matched cells
are attached to the bounds in the following ways:
• If there are regions in the block with the same name as in the DEF, the cells in the
related group are attached to the region by the add_to_bound command in incremental
mode.
• If the region does not exist in the block, it is created with the same name as in the DEF
file by applying the create_bound command; matched cells in the related group are
also attached.
Example 11 DEF Placement Bound Information

REGIONS 1 ;
- c20_group ( 201970 40040 ) ( 237914 75984 ) + TYPE FENCE ;
END REGIONS
GROUPS 1 ;
- c20_group
cell_abc1
cell_sm1
cell_sm2

S-2021.06-SP4
Feedback
+ SOFT
+ REGION c20_group ;
END GROUPS
Routing Blockages
Routing blockages are extracted similar to the way that placement blockages are
extracted.
Preroutes
The tool extracts preroutes that are defined in the DEF file.
Example 12 DEF Preroute Information

SPECIALNETS 2 ;
- vdd
+ ROUTED METAL3 10000 + SHAPE STRIPE ( 10000 150000 ) ( 50000 * )
+ USE POWER ;
...
END SPECIALNETS
Importing a Floorplan Script

After performing design planning in the RTL Architect tool, you can save the floorplan
information as a Tcl script by using the write_floorplan command. To import such a
floorplan Tcl script and apply it to the current block or a specified block, use the source
command.
rtl_shell> source -echo -verbose floorplan/fp.tcl
Table 2 shows commands used in a floorplan Tcl script to define the various elements of
a floorplan. If the Tcl script does not contain port-location information, the tool inherits the
port locations from the locations of the pad cells, as described in Ensuring Port Locations
are Inherited From Pads.
Table 2 Commands for Defining Physical Constraints
To define this physical constraint Use this command
Die area set_attribute [current_block] bbox

or
set_attribute [current_block] boundary
Placement area create_site_row
Keepout margins create_keepout_margin
Macro locations set_cell_location

S-2021.06-SP4
Feedback
Table 2 Commands for Defining Physical Constraints (Continued)
To define this physical constraint Use this command
Pin blockages create_pin_blockage
Pin physical constraints set_individual_pin_constraints
Placement blockages create_placement_blockage
Placement bounds create_bound
Port locations and shape create_shape and create_terminal
Preroutes -net netcreate_shape
Tracks create_track
User shapes create_shape
Vias create_via
Voltage area create_voltage_area
Wiring keepouts create_routing_guide
You can use the commands given in Table 2 to define the floorplan information, as shown
in the following examples:
Example 13 Tcl Command to Create Site Rows

rtl_shell> create_site_row -name ROW_0 -origin {0.000 0.000} \
-site core -site_orientation 0 -orientation H -x_margin 0.560 \
-site_count 838
Example 14 Tcl Command to Set Cell Location and Orientation

rtl_shell> set_cell_location macro_cell_abx2 \
-coordinates { 4350.720 8.160 } -orientation E -fixed
rtl_shell> set_cell_location macro_cell_cdy1 \
-coordinates { 4.800 8.160 } -orientation W -fixed
Example 15 Tcl Command to Create Hard Placement Blockage

rtl_shell> create_placement_blockage -name def_obstruction_23 \
-bbox { {970.460 7.500} {3247.660 129.940} }
Example 16 Tcl Command to Create Soft Placement Blockage

-bbox { {970.460 7.500} {3247.660 129.940 }} -type soft

S-2021.06-SP4
Feedback
Example 17 Tcl Command to Create Partial Placement Blockage

-bbox { {970.460 7.500} {3247.660 129.940} } -type partial \
-blocked_percentage 80
Example 18 Tcl Commands to Create Routing Tracks

rtl_shell> create_track -layer metal1 -dir X -coord 0.100 \
-space 0.200 -count 11577 -bbox {{0.000 0.000} {2315.400 2315.200}}
rtl_shell> create_track -layer metal1 -dir Y -coord 0.200 \
-space 0.200 -count 11575 -bbox {{0.000 0.000} {2315.400 2315.200}}
Example 19 Tcl Command to Create Placement Bound

rtl_shell> create_bound -name "c20_group" \
-boundary {201970 40040 237914 75984} \
-exclusive {cell_abc1 cell_sm1 cell_sm2}
Example 20 Tcl Command to Create Preroute

rtl_shell> create_shape -shape_type path -net vdd \
-layer layer:datatype 0 -shape_use pg_strap -layer METAL3 \
-width 10.000 -path {{10.000 150.000} {50.000 150.000}}
Ensuring Port Locations are Inherited From Pads

If the DEF file or floorplan does not contain port-location information, the RTL Architect
tool inherits the port locations from the locations of the pad cells. To ensure that this
inheritance works on your block, the I/O cells and the pad pins of these I/O must have
the proper attributes. If your cell libraries do not have these attributes, you can use the
set_attribute command to set them.
To identify a library cell as a pad cell, set the pad_cell attribute for the library cell to true.
For example, to identify the library cells named IOCell in all cell libraries as pad cells, use
the following command:
rtl_shell> set_attribute -objects [get_lib_cells */IOCell] \
-name pad_cell -value true
To identify a library cell pin as a pad pin, set the is_pad attribute for the library cell pin to
true. For example, to identify the library cell pins named PADpin on all cells named IOCell
in all cell libraries as pad pins, use the following command:
rtl_shell> set_attribute -objects [get_lib_pins */IOCell/PADpin] \
-name is_pad -value true

S-2021.06-SP4
Feedback
Note:
When you refer to the library in the get_lib_cells command, you must use
the name of the cell library rather than the name of the logic (.db) library. To
search in all libraries, use an asterisk (*) for the library name.
Specifying Locations for Unmapped Cells

You can specify fixed locations for unmapped leaf cells, so the tool does not move these
cells during compile. To do so, specify the location coordinates for leaf cells by using the
set_cell_location command.
To prevent the tool from moving a cell during compile, specify a fixed location for the
cell by using the -fixed option with the set_cell_location command to set the
physical_status attribute to fixed on the cell. To change the location of a cell marked
with fixed placement status, specify the -ignore_fixed option with the command. The
specified coordinates indicate the lower-left corner of the cell boundary. After you run the
set_cell_location command, the unmapped cell gets the specified location in memory,
but the location is not reflected in the layout view before compile. To view the placement of
the cell, run the compile_fusion command.
This example sets the lower-left corner of the out1_reg cell to (20 10) and sets the fixed
physical placement status to prevent the tool from moving the cell during compile.
rtl_shell> set_cell_location -coordinates { 20 10 } out1_reg -fixed
Using Automatic Floorplanning

During early design stages, a design often undergoes many iterations due to changes
such as adding features and macros; as a result, the floorplan contains limited or no
physical information.
Automatic floorplanning can generate high-quality floorplans and create missing physical
information early in the design cycle, which allows you to
• Achieve better correlation between the results of RTL synthesis and design
implementation
• Identify and fix design issues early in the design cycle
• Generate a better starting point for place and route, eliminating costly iterations
During automatic floorplanning in a block-level flow, the rtl_opt command performs the
following tasks:
• Creates the die, rows, and tracks
• Shapes and places voltage areas

S-2021.06-SP4
Feedback
• Places macros
• Places pins and I/Os
By default, the top-level floorplan is created with a core utilization of 0.7. For information
about setting constraints for automatic floorplanning, see Creating Constraints for Auto
Floorplanning.
Creating Constraints for Auto Floorplanning

Use the commands and application options described in this topic to create constraints for
auto floorplanning.
Commands
Use the following two commands to set and report auto floorplanning constraints. These
two commands do not affect explicit floorplanning.
• set_auto_floorplan_constraints
The command sets constraints, such as utilization of the floorplan to be created during
compile. For example,
rtl_shell> set_auto_floorplan_constraints -core_utilization 0.8
• report_auto_floorplan_constraints
The command reports the constraints set by the set_auto_floorplan_constraints

command.
To specify macro placement, pin placement, and voltage area shaping constraints, use the
following commands:
• Macro placement constraints
set_macro_constraints, create_macro_array, create_keepout_margin
• Pin placement constraints

set_block_pin_constraints, set_individual_pin_constraints
• Voltage area shaping constraints

set_shaping_options

S-2021.06-SP4
Feedback
Application Options
Use these application options to set up auto floorplanning.
• compile.auto_floorplan.initialize (default: auto)
◦ auto: Creates missing floorplan information.
The tool exits with an error when inconsistent information is provided.

◦ true: Always creates the core and boundary.
◦ false: Never creates the core and boundary; uses only existing information.
The tool exits with an error when encountering missing or inconsistent information.
By default, the following objects are preserved:
◦ Existing placement of fixed macros
◦ Existing placement of pins and pads
◦ Existing shaping of voltage areas
• compile.auto_floorplan.place_pins (default: unplaced)
compile.auto_floorplan.place_ios (default: unplaced)
compile.auto_floorplan.place_hard_macros (default: unplaced)
compile.auto_floorplan.shape_voltage_areas (default: unshaped)
◦ all: Always places and shapes objects even if they are fixed.
Unplaced and unshaped objects will always be placed and shaped.

◦ unfixed: Places and shapes objects that are not fixed.
Use the fixed information from DEF files or a Tcl floorplan, and use the
set_fixed_objects command to modify. Unplaced and unshaped objects will
always be placed and shaped.
◦ unplaced, unshaped: Never places or shapes objects when they are already
placed.
Unplaced and unshaped objects will always be placed and shaped.
◦ none: Never places or shapes objects even if they are not already placed.
This table summarizes how the tool handles fixed, placed, and unplaced objects for
each setting of these four application options during auto floorplanning.

S-2021.06-SP4
Feedback
Application option Fixed objects Placed objects Unplaced objects

setting
all Placed and shaped Placed and shaped Placed and shaped
unfixed Kept Placed and shaped Placed and shaped
unplaced, unshaped Kept Kept Placed and shaped
none Kept Kept Kept
• compile.auto_floorplan.keep_bounds (default: auto)
◦ auto: Removes existing bounds if either of the following two application options is
set to all.
compile.auto_floorplan.place_hard_macros,
compile.auto_floorplan.shape_voltage_areas
◦ true: Keeps existing bounds.
◦ false: Removes existing bounds.
• compile.auto_floorplan.keep_placement_blockages (default: auto)
◦ auto: Removes existing placement blockages if either of the following two

application options is set to all.
compile.auto_floorplan.place_hard_macros,
compile.auto_floorplan.shape_voltage_areas
◦ true: Keeps existing placement blockages.
◦ false: Removes existing placement blockages.

S-2021.06-SP4
Feedback
Automatic Floorplanning Example

The following example specifies constraints for automatic floorplanning:
# Application options with default settings
# set_app_options -name compile.auto_floorplan.initialize -value auto
# set_app_options -name compile.auto_floorplan.place_pins -value unplaced
# set_app_options -name compile.auto_floorplan.place_ios -value unplaced
# set_app_options -name compile.auto_floorplan.place_hard_macros \
# -value unplaced
# set_app_options -name compile.auto_floorplan.shape_voltage_areas \
# -value unshaped
# Constraint settings for automatic floorplanning

set_auto_floorplan_constraints -core_utilization 0.75 -side_ratio {1 2}
set_macro_constraints -preferred_location {0 0} RAM0
set_block_pin_constraints -self -sides {1 3}
set_individual_pin_constraints -ports [get_ports reset] -side 1
set_shaping_options -guard_band_size 2

S-2021.06-SP4
Feedback
3
Restructuring the RTL
Design hierarchies often need to be restructured to improve metrics such as congestion,
timing, or power. RTL restructuring allows you to change the design hierarchy using one or
more of the following methods:
• Adding Logical Hierarchy Levels (grouping)
• Removing Logical Hierarchy Levels (ungrouping)
• Changing the Parent Module for a Cell (reparenting)
• Partitioning the Logical Hierarchy
To enable these capabilities, you must set the
rtl_restructuring.enable_restructured_rtl_generation application option to true
before analyzing and elaborating the original RTL. When this application option is true,
you can save the restructured RTL by using the write_restructured_rtl command, as
described in Writing the Restructured RTL.
To enable UPF restructuring when performing RTL restructuring, you must set the
following application options to true:
• mv.hierarchical.restructure_upf_for_group
• mv.hierarchical.restructure_upf_for_ungroup
The following limitations apply to RTL restructuring:

• The tool does not support hierarchy movement, such as grouping or reparenting
individual always blocks or assign statements.
• Parameters are not preserved. They are replaced by their evaluated values in the
restructured RTL.
• `ifdef is not preserved in the restructured RTL for modified modules.
• You cannot perform synthesis on the restructured RTL in the same session in which
you performed the restructuring.
To synthesize the restructured RTL, you must write out the restructured RTL with
the write_restructured_rtl command, exit the session, and then read in the
restructured RTL in a new session before synthesizing it.

S-2021.06-SP4
Feedback
Chapter 3: Restructuring the RTL
Adding Logical Hierarchy Levels
Adding Logical Hierarchy Levels

Adding a level of hierarchy is called grouping. A logical hierarchy is called a module.
To create a level of logical hierarchy from a group of cells from the same parent module,
use the group_cells command. The tool uses the following naming conventions for the
new module and the instantiated cell:
• By default, the new module is named group_n. To specify the module name, use the
-module_name option.
• By default, the new cell instance is named group_cell_n. To specify the module name,
use the -cell_name option.
To control the names of new ports created by the group_cells command, use the
design.set_group_port_name application option with the following syntax:
rtl_shell> set_app_options -name design.set_group_port_name \
-value {expression}
The expression you specify as the value for this application option can contain a prefix,
postfix, or both, and one or more of the following keywords:
• #si, which represents the name of the instance driving the new port
• #sp, which represents the name of the pin or port driving the new port
• #netname, which represents the name of the net that is connected to the new port
The following example specifies that the names of new ports created by the group_cells
command should be based on the instance name of the driver and the pin or port name of
the driver:
rtl_shell> set_app_options -name design.set_group_port_name \
-value {#si_#sp}
rtl_shell> group_cells {u2 u3} -cell_name G1 -module_name G
The following figure shows the corresponding logic, before and after grouping.
Figure 3 Before and after grouping cells

The group_cells command also supports a primary module for similarly grouped
instances. Use the -enable_mim option to specify the module name when grouping

S-2021.06-SP4
Feedback
Removing Logical Hierarchy Levels
multiple instances to a primary module. The tool checks and matches the grouped cells
with the targeted primary module.
If the cells are not compatible, the tool issues an error message and proceeds with normal
grouping. You can use the -strict_mim option to stop the tool from performing normal
grouping if the cells are not compatible.
Note:
To enable UPF restructuring when performing RTL grouping, set the
mv.hierarchical.restructure_upf_for_group application option to true.
When you create a new logical hierarchy level, the tool adjusts the connections to the
affected cell instances to maintain connectivity. The ports of the new module are named
after the nets to which they are connected. The direction of each port of the new module is
determined from the pins of the corresponding net.
After creating a new module, you can instantiate that module anywhere in the design.
For example, to group the U1 and U2 cells into a new level of logical hierarchy with a
module name of newmod and an instance name of U, use the following command:
rtl_shell> group_cells [get_cells {U1 U2}] \
-module_name newmod -cell_name U
To group all cells that begin with alu into a new module named uP with an instance name
of UCELL, use the following command:
rtl_shell> group_cells [get_cells alu*] \
-module_name uP -cell_name UCELL
Removing Logical Hierarchy Levels

Removing a level of hierarchy is called ungrouping.
To remove one or more levels of logical hierarchy from a hierarchical module, use the
ungroup_cells command. By default, the tool preserves the hierarchical path names
when naming the cells and nets from the removed hierarchy. To keep the original cell
names (without the hierarchical path), use the -simple_names option. To specify a prefix
for the new cell names, use the -prefix option. Removing logical hierarchy levels does
not impact connections that do not touch the boundary of the removed hierarchies.
Note:
To enable UPF restructuring when performing RTL ungrouping, set the
mv.hierarchical.restructure_upf_for_ungroup application option to
true.

S-2021.06-SP4
Feedback
Changing the Parent Module for a Cell
For example, to ungroup the U1 and U2 cells, use the following command:
rtl_shell> ungroup_cells [get_cells {U1 U2}]
To ungroup the U1 cell and use U1: as the prefix for the new cells, use the following
command:
rtl_shell> ungroup_cells {U1} -prefix "U1:"

Moving a cell from its current logical hierarchy to a different logical hierarchy is called
reparenting.
To move a group of cells from the same parent module to a different parent module,
use the reparent_cells command. When you move the cells, the tool adjusts the
connections to the affected cell instances to maintain connectivity. During reparenting, the
tool
• Reconnects the nets connected to the moved cells
• Keeps the minimum number of ports
• Reuses existing connections from the nearest hierarchy from the destination
• Preserves constraints and port data wherever possible
• (Optional) Removes floating pins and ports
By default, floating pins and ports are retained. To remove floating pins and ports, use
the -remove_floating_pins option.
Note:
To enable UPF restructuring when performing RTL reparenting, you must set
the following application options to true:
• mv.hierarchical.restructure_upf_for_group
• mv.hierarchical.restructure_upf_for_ungroup
To see the effects of reparenting without making the changes, use the -check_only
option. When you use this option, the tool performs the pre-move checks and reports the
moves that would be made, but does not actually make the changes.
The tool uses the following naming conventions for the new cell and the new port:
• By default, the new cells keep the original cell name, if possible. In some cases, the
tool adds a suffix of _# to the cell name to provide a unique identifier.
To specify a prefix for the new cell names, use the -cell_prefix option.

S-2021.06-SP4
Feedback
• By default, the new ports created during port-punching are named after the nets to
which they are connected.
To specify a prefix for the new port names, use the -port_prefix option.
To control the names of new ports created by the reparent_cells command, use the
design.set_reparent_port_name application option with the following syntax:
rtl_shell> set_app_options -name design.set_reparent_port_name \
-value {expression}
The expression you specify as the value for this application option can contain a prefix,
postfix, or both, and one or more of the following keywords:
• #si, which represents the name of the reparented instance
• #sp, which represents the name of the pin or port of the reparented instance that is
connected to the new port
• #netname, which represents the name of the net that is connected to the new port
The following example specifies that the names of new ports created by the
reparent_cells command must be based on the name of the pin or port of the
reparented instance that is connected to the new port, with a prefix of np_:
rtl_shell> set_app_options -name design.set_reparent_port_name \
-value {np_#sp}
rtl_shell> reparent_cells ufpu/u1 -to uwrap
The following figure shows the corresponding logic, before and after reparenting.
Figure 4 Before and after reparenting cells

You can reparent cells to another logical hierarchy in the same level or at a different
level. The following example moves the cell1 instance from the bot0 instance to the bot1
instance, both of which are at the same hierarchical level in the design. Figure 5 shows the
design before and after reparenting.
rtl_shell> reparent_cells -to one_level_below_top/mid1/bot1 \
one_level_below_top/mid0/bot0/cell1

S-2021.06-SP4
Feedback
Figure 5 Same-level reparenting

The following example moves the cell2 instance from the one_level_below_top instance to
the bot1 instance, which is at a lower hierarchical level in the design. Figure 6 shows the
design before and after reparenting.
rtl_shell> reparent_cells -to one_level_below_top/mid1/bot1 \
one_level_below_top/cell2
Figure 6 Lower-level reparenting

The following example moves the cell1 instance from the bot0 instance to the
one_level_below_top instance, which is at a higher hierarchical level in the design.
Figure 7 shows the design before and after reparenting.
rtl_shell> reparent_cells -to one_level_below_top \
one_level_below_top/mid0/bot0/cell1

S-2021.06-SP4
Feedback
Partitioning the Logical Hierarchy
Figure 7 Higher-level reparenting

After reparenting, you can preserve all timing constraints by setting the
time.reparent_enable_inherit_constraints application option to true. This
application option preserves all timing constraints from hierarchical-parent pins to
reparented cell pins when changing the parent module for a cell.

The RTL Architect tool has the capability of automatically partitioning the logical hierarchy
of a design. The following topics give an overview of the automatic partitioning feature and
how to use it:
• Automatic Logical Hierarchy Partitioning
• Performing Automatic Partitioning
Automatic Logical Hierarchy Partitioning

The automatic partitioning feature generates multiple partitioning solutions, based on a
specified cell count limit in a partition and the number of partitions in the design. When
generating these solutions, the tool tries to minimize the pin count of the partitions.
You can run automatic partitioning on either an elaborated or mapped design. After you
run automatic partitioning, you can analyze the different solutions and select the solution
that suits your requirements.

S-2021.06-SP4
Feedback
When creating the partitions, the tool considers the net connectivity of the existing logical
hierarchy blocks. In addition, the tool can consider the following:
• Physical distances
The tool can minimize the physical distances between blocks in a partition by grouping
blocks that are close to each other, as shown in Figure 8. In this example, blocks A and
B are physically close to each other, and so are blocks C and D. Therefore, the tool
groups block A with block B, and block C with block D.
Figure 8 Partitioning Based on Physical Distance

• Physical-feedthrough nets
The tool can consider the effects of physical-feedthrough nets when grouping blocks.
For example, in Figure 9, blocks A and B have a channel between them, which
contains the nets that connect these two blocks, and block C overlaps with this
channel. When considering the effects of feedthrough nets during partitioning, the tool
tries to retain block C in the same partition as block A or B, and not in an altogether
different partition.
Figure 9 Partitioning Based on Feedthrough Calculations


S-2021.06-SP4
Feedback
Performing Automatic Partitioning

The following topics describe how to perform automatic partitioning and select a
partitioning solution:
• Setting Up and Running Automatic Partitioning
• Files Generated During Automatic Partitioning
• Analyzing the Partitioning Results and Selecting a Solution
Setting Up and Running Automatic Partitioning

To set up the design and automatically partition it, perform the following steps:
1. Specify the maximum cell count per partition by using the
plan.auto_group.group_ncells_max application option and the maximum number of
partitions by using the plan.auto_group.groups_count_max application option.
If you do not specify the maximum number of partitions, the tool uses a default of 10.
However, you must specify the maximum number of cells per partition. In addition,
you must ensure that the total number of cells in the design is less than the maximum
number of partitions multiplied by the maximum number of cells per partition.
The following example sets the maximum number of partitions to 12 and the maximum
number of cells per partitions to 10,000:
rtl_shell> set_app_options -name plan.auto_group.groups_count_max \
-value 8
rtl_shell> set_app_options -name plan.auto_group.group_ncells_max \
-value 1000
For this example, if the number of cells in the design exceeds 120,000, the tool issues
an error message and exits.
2. (Optional) Specify the maximum pin count per partition by using the
plan.auto_group.group_npins_max application option as shown in the following
example:
rtl_shell> set_app_options -name plan.auto_group.group_npins_max \
-value 40000
When the pin count is prioritized over the cell count by using the
plan.auto_group.group_npins_max application option the tool creates partitions with
balanced pin count.
3. (Optional) Create balanced partitions with pin count as the highest priority, by using the
following application option setting:
rtl_shell> plan.auto_group.prioritize_factors {pincount cellcount}

S-2021.06-SP4
Feedback
The default for the plan.auto_group.prioritize_factors application option is

{cellcount pincount} which prioritizes cell count over pin count. If you specify only
one value or the same value twice, the tool gives a warning message and assumes the
unspecified value as the second priority constraint.
Note:
• If pin count has the highest priority and the maximum pin count is not
specified, the tool derives a maximum pin count constraint.
• If pin count has a lower priority but is not specified, the partitioning does
not honor the specified or derived maximum pin count constraint.
4. (Optional) Enable partitioning based on physical distances by setting the
plan.auto_group.physical_aware application option to true.
When you enable this feature, the tool considers physical distance blocks and the
effects of physical-feedthrough nets during partitioning.
5. (Optional) Limit the number of solutions to two by setting the
plan.auto_group.multiple_results application option to false.
The default for this application option is true, and then, the tool can generate up to six
partitioning solutions.
6. (Optional) Set up the design for creating an abutted floorplan using the
setup_design_for_auto_partition -abutted_design -verbose command.
When you use this command, at each level of the logical hierarchy, the tool groups
together the glue logic that is not part of any logic block. This helps create the abutted
floorplan because there is no logic present at the top.
7. (Optional) Identify specific instances of modules as multiple instantiated modules
(MIMs) so that they are created as separate partitions during automatic partitioning by
using the setup_design_for_auto_partition -enable_mim command.
The following examples specifies the CX1 and CX2 instances as MIMs:
rtl_shell> setup_design_for_auto_partition \
-enable_mim {CX1 CX2}
To consider all MIMs that have cell count greater than 30 percent of maximum cell
count specified for automatic partition, use the following syntax:
rtl_shell> setup_design_for_auto_partition \
-enable_auto_mim_detection
8. Partition the design by using the explore_logic_hierarchy -auto_partition

command.

S-2021.06-SP4
Feedback
Files Generated During Automatic Partitioning

The explore_logic_hierarchy -auto_partition command generates multiple
Tcl files, each corresponding to one partitioning solution. Each TCL file consists of the
following:
• Commands to create the module boundaries for the selected candidate hierarchies
• Commands to create a virtual group for each partition
• Statistics for each partition of the specific solution, written as Tcl comments
The statistics include
◦ Total cell count
◦ Pin count
◦ Hard macro count
◦ Candidate hierarchies in the partition
◦ Number of candidate hierarchies
The following is an example of a Tcl file generated by the explore_logic_hierarchy
-auto_partition command:
explore_logic_hierarchy -create_module_boundary -cell {TOP/PARSER

TOP/PCTOP TOP/SD_W_MUX TOP/PCW_MUX TOP/SDRAM_TOP TOP/BLENDER_2
TOP/BLENDER_0 TOP/RISC_CORE TOP/CONTEXT_MEM TOP/BLENDER_1
TOP/group_cell_1 RESET_BLOCK CLOCK_GEN group_cell_0 }
explore_logic_hierarchy -virtual_group {CLOCK_GEN TOP/CONTEXT_MEM
TOP/PARSER TOP/PCTOP TOP/RISC_CORE RESET_BLOCK group_cell_0 } -name
auto_group_1
explore_logic_hierarchy -virtual_group {TOP/BLENDER_2 TOP/SDRAM_TOP }
-name auto_group_2
explore_logic_hierarchy -virtual_group {TOP/BLENDER_0 TOP/BLENDER_1
TOP/PCW_MUX TOP/SD_W_MUX TOP/group_cell_1 } -name auto_group_3
explore_logic_hierarchy -organize
# Statistics of Auto Partitioning

# --------------------------------------------------
# Group Name|Number of LHs|Pin Count|#Std-cells|#HMs
# 1| 7| 286| 9420| 39
# 2| 2| 231| 15052| 2
# 3| 5| 221| 19828| 0
# --------------------------------------------------
#Total 14| 738| 44300| 41

S-2021.06-SP4
Feedback
Writing the Restructured RTL
Analyzing the Partitioning Results and Selecting a Solution

During automatic partitioning, the tool generates multiple solutions for partitioning the
design. You can review the statistics for each solution, which is given in the corresponding
Tcl output file, and identify the solution that meets your requirements.
To further analyze these solutions, you can perform the following steps for each solution:
1. Source the Tcl file generated by the tool for the specific solution, as shown in the
following example:
rtl_shell> source auto_group0.tcl
This creates a virtual group for each of the partitions, which does not modify the
design.
2. Analyze the virtual group in the Hierarchy Browser
3. Remove the module boundaries for the virtual groups by using the
explore_logic_hierarchy -remove command
After you identify the partitioning solution you want to implement, to implement the solution
1. Source the Tcl file for the corresponding solution
2. Commit the virtual groups, which are created by the Tcl file, into module boundaries by
using the GUI tool
3. Commit the module boundaries into physical partitions by using the commit_block
command

To write RTL files that reflect the restructured RTL, use the write_restructured_rtl
command.
Note:
This command is available only if you set the
rtl_restructuring.enable_restructured_rtl_generation application
option to true before analyzing and elaborating the original RTL.
This command saves the restructured RTL in the same format (SystemVerilog or Verilog)
as the original RTL input and preserves the original RTL file names. By default, the
command writes the files to a directory named output/Verilog. To specify the directory
name, use the -output option.
The write_restructured_rtlcommand generates
a Formality mapping file for formal verification as the

S-2021.06-SP4
Feedback
rtl_restructuring.enable_formality_script_generationapplication
option, is set to true by default. The command generates a mapping file named
formality_mapping_file.tcl to the specified output directory. If you do not want to generate
the file, set this application option to false.
You can also write a SAIF file that reflects the restructured RTL with the
write_restructured_rtl command.
Note:
You must set the rtl_restructuring.enable_saif_restructuring
application option to true before using the read_saif command.
The restructured SAIF file is written to the ./report directory. By default, the SAIF
file is named the same as the SAIF file read by the read_saif command. To
specify the output file name, use the -restructured_saif_file option with the
set_rtl_restructuring_configuration command.

S-2021.06-SP4
Feedback
4
Synthesizing the Design
The RTL Architect tool provides a single command, rtl_opt, to perform fast, physically
aware synthesis on your RTL design. RTL Architect provides the following benefits:
• Uses predictive delay modeling to provide early visibility into implementation results
that are typically within five percent of the results produced by the Fusion Compiler tool
• Performs automatic floorplanning during RTL synthesis using a native floorplanning
engine that can generate a complete floorplan or generate missing floorplan data
• Supports breakpoints so you can stop the process after specific flow stages
• Supports both block-level and hierarchical flows
For information about synthesizing the design, see the following topics:
• rtl_opt Prerequisites
• Using the rtl_opt Command
• Specifying the Optimization Effort of the rtl_opt Command
• Synthesis
rtl_opt Prerequisites
Complete the following requirements before running the rtl_opt command:
• Libraries
Include a minimum set of standard cells in the reference libraries. For information about
setting up reference libraries, see Setting Up Reference Libraries.
• Design flow
Read the RTL designs by using the analyze and elaborate commands followed by
the set_top_module command. For more information, see Reading the Design.
• UPF
Load power intent by using the load_upf command before compile. For more
information, see Applying the Multivoltage Power Intent.

S-2021.06-SP4
Feedback
Chapter 4: Synthesizing the Design
Using the rtl_opt Command
• Timing, area, and power constraints

Use the most dominant scenario to run compilation. Specify RC parasitics or TLUPlus
information and SDC constraints for timing, area, and power. For more information, see
Specifying Logical Constraints.
• Initial floorplan
Use an initial realistic floorplan to achieve better correlation between physical synthesis
and place-and-route.
◦ By default, the tool performs auto floorplanning when you run the rtl_opt
command. For the best results, specify floorplanning constraints before running the
rtl_opt command, as described in Creating Constraints for Auto Floorplanning.
◦ If you already have a floorplan, you can import it as a DEF file or floorplan Tcl script
as described in Importing the Floorplan Information.

The rtl_opt command supports both block-level and hierarchical flows. The tasks
performed by the rtl_opt command differ in each of these flows. For details, see
• rtl_opt Block-Level Flow
• rtl_opt Hierarchical Flow
rtl_opt Block-Level Flow

Figure 10 shows the tasks performed by the rtl_opt command in the block-level flow.
Auto floorplanning is performed as part of the conditioning stage and the tasks shown
inside the conditioning stage are performed as part of auto floorplanning.

S-2021.06-SP4
Feedback
Figure 10 rtl_opt Block-Level Flow

Each of the top-level tasks in this figure represents a breakpoint for the rtl_opt
command. You can stop the flow after these breakpoints to examine the intermediate
results. By default, the tool performs the complete flow when you run the rtl_opt
command. To enable breakpoints, use the -from and -to options with the rtl_opt
command.
The block-level flow uses the following breakpoints:
• Conditioning (conditioning)
◦ Maps the design to library cells
◦ Optimizes the design for area and timing
To perform only the initial mapping, use the -initial_map_only option with the
rtl_opt command.

S-2021.06-SP4
Feedback
◦ Performs auto floorplanning, which creates the core area using the mapped and
optimized netlist, shapes voltage areas, places macros, and places ports
For details, see Using Automatic Floorplanning.
• Estimation (estimation)
Performs preroute physical optimization, which includes
◦ Placement
To enable direct timing-driven placement, set the
rtl_opt.estimation.enable_dtdp application option to true.
◦ Buffer-tree building
◦ Multiple iterations of optimization for costs such as timing, power, and area.
After using the rtl_opt command to synthesize your design, use the compute_metrics
command to compute various metrics related to congestion, timing, and power, as
described in Computing Metrics.

S-2021.06-SP4
Feedback
rtl_opt Hierarchical Flow

Figure 11 shows the tasks performed by the rtl_opt command in the hierarchical flow.
Figure 11 rtl_opt Hierarchical Flow

Each of the top-level tasks in this figure represents a breakpoint for the rtl_opt
command. You can stop the flow after these breakpoints to examine the intermediate
results. By default, the tool performs the complete flow when you run the rtl_opt
command. To enable breakpoints, use the -from and -to options with the rtl_opt
command.
Note:
If the top-level block uses a fully-abutted floorplan, which has no channels
between the subblocks, the top-level conditioning and estimation
steps are not required. To automatically skip these steps, set the
rtl_opt.flow.fully_abutted_style_floorplan application option to true.

S-2021.06-SP4
Feedback
The hierarchical flow uses the following breakpoints:

• Split constraints (split_constraints)
◦ Applies the full-chip SDC and UPF
◦ Partitions them into top-level and block-level files
◦ Performs I/O budgeting, which is used during block conditioning before actual
budgets are estimated during design planning
By default, the tool performs percentage-based I/O budgeting, and allocates 30%
to the input port and 30% to the output ports for the budget calculation. To change
these values, set the rtl_opt.conditioning.initial_percent_block_budgets
application option.
To use logic-depth-based I/O budgeting instead, set the
rtl_opt.conditioning.initial_percent_block_budgets application option to
logic_depth.
With either method, by default, feedthrough pins are budgeted

at 50% of the available clock cycle. To modify this value, set the
rtl_opt.conditioning.feedthrough_percent_block_budget application option
to specify the percentage to use for the input and output delays.
To disable I/O budgeting, set the
rtl_opt.conditioning.enable_initial_block_budgets application option to
false.
You can also perform I/O budgeting with the split_constraints command as a
standalone command. For more information, see Splitting Constraints.
• Commit blocks (commit)
◦ Partitions the design
◦ Commits the logical hierarchy cells to physical hierarchy blocks
◦ Loads the split constraints into the top-level design and subblocks
• Block conditioning (block_conditioning)
Invokes distributed subblock runs to
◦ Map the block to library cells
◦ Optimize the block for area and timing

S-2021.06-SP4
Feedback
To perform only the initial mapping, use the -initial_map_only option with the
rtl_opt command.
◦ Create an abstract for the block, if the block is specified in the

-abs_block_instances option
• Top conditioning (top_conditioning)

◦ Maps the top-level design to library cells
◦ Optimizes the design for area and timing
By default, the tool does not use abstracts for top-level conditioning. To enable the use
of abstracts, use the -abs_block_instances option.
• Design planning (floorplanning)
Performs auto floorplanning, which creates the core area using the mapped and
optimized netlist, shapes the blocks and voltage areas, places the hard macros and
standard cells, performs global routing of the interface nets to place the block pins and
create feedthroughs, performs timing estimation and budgeting.
To prevent the tool from creating feedthroughs, set the
rtl_opt.floorplan.enable_feedthroughs application option to false.
For more information about auto floorplanning, see Using Automatic Floorplanning. For
details about the design planning steps, see the RTL Architect Design Planning User
Guide.
If you have already loaded some floorplan information using the methods described in
Importing the Floorplan Information, you can skip some of the design planning stages
by setting the rtl_opt.floorplan.skip_stages option. Valid values for this option
are initialize_fp, shape_blocks, hier_placement, top_level_pin_assignment,
block_level_pin_assignment, and budgeting.
• Block estimation (block_estimation)

◦ Invokes distributed subblock runs to
▪ Load the timing-estimation-based budget constraints
▪ Perform preroute physical optimization on the block, which includes
▪ Placement
▪ Buffer-tree building
▪ Multiple iterations of optimization for costs such as timing, power, and area

S-2021.06-SP4
Feedback
Specifying the Optimization Effort of the rtl_opt Command
▪ Create a frame view for the block

▪ Create an abstract view for the block with the -abs_block_instances option
• Top estimation (top_estimation)
Performs preroute physical optimization for the top-level design, which includes
◦ Placement
◦ Buffer-tree building
◦ Multiple iterations of optimization for costs such as timing, power, and area
After using the rtl_opt command to synthesize your design, use the compute_metrics
command to compute various metrics related to congestion, timing, and power, as
described in Computing Metrics.
Specifying the Optimization Effort of the rtl_opt Command

To specify the optimization effort level for -timing, -congestion, and -power, use the
set_rtl_opt_strategy command with the -timing, -congestion, or -poweroption.
The tool supports the following effort levels:

• default, which gives the best compromise between runtime and QoR
• relaxed, which gives the best runtime at the expense of QoR
• high, which gives the best runtime at the expense of QoR
The following example specifies a high optimization effort level for the congestion metrics:
rtl_shell> set_rtl_opt_strategy -congestion high
To report the effort levels specified for the different metrics and the corresponding
application option settings, use the report_rtl_opt_strategy command.
Synthesis
Logic optimization is the RTL Architect synthesis step that maps the design to an optimal
combination of specific target logic library cells, based on the design’s functional, speed,
and area requirements. You can use the rtl_opt command to synthesize and optimize
the design. RTL Architect provides options that enable you to customize and control
optimization, including

S-2021.06-SP4
Feedback
Synthesis
• Ungrouping and boundary optimization, which are performed by default

To disable automatic ungrouping and boundary optimization, set the
rtl_opt.conditioning.disable_boundary_optimization_and_auto_ungrouping
application option to true.
• Multiple port net fixing
• Port isolation
• DRC disabled nets
• The dont_touch, dont_touch_network, and size_only attributes
• Automatic shift-register identification
• Register replication
• Clock gating
• Concurrent clock and data optimization (CCD), which is performed by default
Performing Multibit Register Optimization

The RTL Architect tool can combine (bank) single-bit registers or smaller multibit registers
and replace them with equivalent larger multibit registers. For example, the tool can
combine eight 1-bit registers or four 2-bit register banks and replace them with one 8-
bit register bank or two 4-bit register banks. The tool merges single-bit registers only if
they have the same timing constraints, and it copies the timing constraints to the resulting
multibit register.

S-2021.06-SP4
Feedback
Synthesis
Figure 12 Replacing Multiple Single-Bit Register Cells With a Multibit Register Cell
D Q
SI
SE
2 2
D Q
SI
SE
D Q
SI
SE
Replace with One 2-bit register cell
Two 1-bit register cells
Replacing single-bit registers with multibit registers reduces

• Area due to shared transistors and optimized transistor-level layout
• The total clock tree net length
• The number of clock tree buffers and clock tree power
The tool can also split (debank) large multibit registers into smaller multibit registers or
single-bit registers, if it improves the total negative slack.
Some logic libraries have mixed-drive-strength multibit registers where some bits have a
higher drive strength than others. For designs that use such cells, if a violating path goes
through a lower-drive-strength bit, the tool can rewire the mixed-drive-strength multibit cell
such that the violating path goes through a higher-drive-strength bit.

S-2021.06-SP4
Feedback
Synthesis
Performing Integrated Multibit-Register Optimization

To perform integrated multibit register optimization during the rtl_opt command,
1. Enable multibit register optimization by setting the compile.flow.enable_multibit
application option to true.
When you do so, by default, the tool performs the following multibit optimizations during
the conditioning stage of the rtl_opt command:
• Combines single registers or smaller register banks at the RTL level to create larger
register banks during the conditioning stage
To disable this feature, set the compile.flow.enable_rtl_multibit_banking
application option to false.
• Splits multibit register banks created at the RTL level if the register bank includes
registers on critical timing paths during the conditioning stage
To disable this feature, set the compile.flow.enable_rtl_multibit_debanking
application option to false.
2.
3. Specify settings for multibit register banking by using the set_multibit_options
command.
For example, the following command excludes the reg[1] cell from multibit optimization
during the RTL-banking stage:
rtl_shell> set_multibit_options -exclude [get_cells "reg[1]"] \
-stage rtl
The following command specifies that during the physical-banking stage, the tool banks
only registers that are connected to the same bus:
rtl_shell> set_multibit_options -bus_registers_only \
-stage physical
4. (Optional) Control the naming style used for multibit banking as described in Specifying
Naming Styles for Multibit Registers.
5. Perform optimization by using the rtl_opt command.
6. (Optional) Report multibit information.
To report the multibit register banks inferred by the tool, use the
report_transformed_registers -multibit command, as described in Reporting
Multibit Registers.

S-2021.06-SP4
Feedback
Synthesis
To report multibit statistics such as the total number of single-bit and multibit registers,
the multibit banking ratio, and so on, use the report_multibit command.
For more information about how to determine why multibit register banking is not
performed for specific cells, see Identifying Why Multibit Banking Is Not Performed.
Specifying Naming Styles for Multibit Registers

RTL Architect allows you to customize the naming styles for multibit registers. You can use
the application options described in this topic to modify the default naming styles to match
the requirements of your design flow or a third-party tool.
Specifying a Name Separator
When creating the name for a multibit register, the tool concatenates the names of the
single-bit registers and uses the _ character as the name separator. For example, when
the tool combines the single-bit registers named reg1 and reg2, the multibit register is
named reg1_reg2.
To change the default name separator, use the
multibit.naming.multiple_name_separator_style application option.
Specifying a Name Prefix

To specify a prefix for the multibit register name, use the multibit.naming.name_prefix
application option.
Compacting Hierarchical Names
When combining single-bit registers with hierarchical names, the tool uses the full
hierarchical names of the single-bit registers for the concatenated multibit register name.
For example, when the tool combines the single-bit registers named A/B/P/reg1 and A/B/
Q/reg2, the multibit register is named A/B/P/reg1_A/B/Q/reg2.
To make the multibit register name more compact, specify that
common hierarchical names should not be repeated by setting the
multibit.naming.compact_hierarchical_name application option to true. If you do
so, when the tool combines the single-bit registers named A/B/P/reg1 and A/B/Q/reg2, the
multibit register is named A/B/P/reg1_Q/reg2.
Specifying a Range Separator for Contiguous Bits of a Bused Register
When combining contiguous bits of a bused register, the tool uses the : character as the
range separator. For example, when the tool combines single-bit bused registers named
regA[0], regA[1], and regA[2], the multibit register is named regA[2:0].
To change the range separator, use the multibit.naming.range_separator_style
application option.

S-2021.06-SP4
Feedback
Synthesis
Specifying an Element Separator for Noncontiguous Bits of a Bused Register

When combining noncontiguous bits of a bused register, the tool uses the , character as
the element separator. For example, when the tool combines the single-bit bused registers
named regA[1] and regA[3], the multibit register is named regA[3,1].
To change the element separator, use the multibit.naming.element_separator_style
application option.
Specifying the Expanded Naming Styles When Combining Elements of a
Multidimensional Register Array
To specify the expanded naming styles for the multibit registers created
by combining elements of a multidimensional register array, use the
multibit.naming.expanded_name_style application option. For more information on
this application option, see the man page.
Reporting Multibit Registers

After you run the rtl_opt command, you can report the registers that are transformed
due to multibit banking and debanking by using the report_transformed_registers
-multibit command.
The following example shows a portion of a report generated by the

report_transformed_registers -multibit command.
rtl_shell> report_transformed_registers -multibit
...
****************************************
Attributes:
mb - multibit
mbd - multibit debanked
...
Register Optimization
-----------------------------------
MB_2_MB_1 mb (source:MB_2, MB_1)
MB_0_MB_3 mb (source:MB_0, MB_3)
MB_5, MB_6 mbd (source: MB_5_MB_6)
Identifying Why Multibit Banking Is Not Performed

To report a summary of the multibit banking ratio, a list of reasons for not banking or
debanking cells, and the number of cells for each reason, use the report_multibit
command, as shown in the following example:
rtl_shell> report_multibit
****************************************
Report : report_multibit
...
...

S-2021.06-SP4
Feedback
Synthesis
****************************************
Total number of sequential cells: 4020

Number of single-bit flip-flops: 3149
Number of single-bit latches: 29
Number of multi-bit flip-flops: 842
Number of multi-bit latches: 0
Total number of single-bit equivalent cells: 853

(A) Single-bit flip-flops: 3149
(B) Single-bit latches: 29
(C) Multi-bit flip-flops: 5352
(D) Multi-bit latches: 0
Sequential cells banking ratio ((C+D)/(A+B+C+D)): 62.74%

Flip-flop cells banking ratio ((C)/(A+C)): 62.96%
BitsPerflop: 2.13
Reasons for sequential cells not mapping to multibit during RTL Banking:
Explanations:
r12: Cell is single bit because its parent multibit cell was debanked
due to improve timing (Number of cells: 91)
r31: Cell cannot be banked to multibit because it is assigned to use
single-bit lib cell (Number of cells: 63)
Reasons for multibit sequential cells not debanking to single bit cells
during RTL Debanking:
Explanations::
r45: Multibit cell cannot be debanked because it is not critical
enough (Number of cells: 478)
To report all the cells that are ignored during banking and debanking , use the
-ignored_cells option with the report_multibit command.
To report the compatible multibit and single-bit library cells that can be used for banking
and debanking, use the check_multibit_library command.
The following example generates a compatible library cell report for RTL banking and
debanking:
rtl_shell> check_multibit_library -stage RTL \
-banking -debanking
****************************************
Report : check_multibit_library
Flow : RTL BANKING
****************************************
----------------------------------------------------------------
Single bit Lib cell Compatibility Multi bit Lib cell
----------------------------------------------------------------

S-2021.06-SP4
Feedback
Synthesis
SB_reg1 PIN ORDER MISMATCH MB_reg1

SB_reg2 COMPATIBLE MB_reg2
----------------------------------------------------------------
Singlebit with NO Multibit Equivalents
----------------------------------------------------------------
SB_reg3
****************************************
Report : check_multibit_library
Flow : RTL DEBANKING
****************************************
----------------------------------------------------------------
Multi bit Lib cell Compatibility Single bit Lib cell
----------------------------------------------------------------
MB_reg2 COMPATIBLE SB_reg2
MB_reg1 PIN ORDER MISMATCH SB_reg1
----------------------------------------------------------------
Multibit with NO Singlebit Equivalents
----------------------------------------------------------------
MB_reg3
Improving the Banking Ratio

During the initial_mapping stage, the tool can prioritize the use of
sequential library cells that have functionally equivalent multibit library cells.
After you run the compile_fusion command, if the report_multibit
-ignored_cells command indicates that many cells were not banked due to
a lack of multibit cells in the library, you can enable this feature by setting the
compile.seqmap.prefer_registers_with_multibit_equivalent application option to
true and rerunning the compile_fusion command. However, enabling this feature might
degrade the design QoR.
DFT Support
The purpose of the RTL Architect DFT solution is to account for the additional cells and
nets introduced into the design due to the DFT structures and scan chains, and consider
their effect on area, congestion,and power QoR.
The RTL Architect DFT flow consists of the following two stages:
1. Inserting DFT Structures
2. Performing Scan Synthesis
Inserting DFT Structures

The RTL Architect tool does not insert DFT structures such as compression logic, memory
BIST logic, and so on. Therefore, you need to insert such DFT structures by using a DFT
tool such as the TestMAX Manager tool.

S-2021.06-SP4
Feedback
Synthesis
To do so, in the TestMAX Manager tool,

1. Read in your functional RTL
2. Apply your DFT constraints and setting
3. Insert the DFT structures
4. Write out the updated RTL, which includes the DFT structures
5. Write out the updated DFT constraints and settings
If you do not use the TestMAX Manager tool, you can perform this task in a third-party DFT
tool.
Performing Scan Synthesis

To perform scan synthesis in the RTL Architect tool,
1. Read in the updated RTL, which includes the DFT structures
2. Apply the updated DFT constraints and settings
3. Run the rtl_opt command
The rtl_opt command
1. Performs scan replacement
2. Performs scan stitching based on the following assumptions:
• All scan-replaced cells are eligible for stitching
• All scan cells are in the same clock domain and power domain
• Both clock and power domain mixing is enabled
3. Generates a report named rtla_scan_dft.rpt, which summarizes the scan chain
information
When using the DFT flow, you can specify breakpoint during the rtl_opt command.
However, ensure that you complete all stages of the rtl_opt command. The tool performs
scan stitching during the estimation stage of the rtl_opt command.
RTL Architect scan synthesis supports only the following DFT constraints:
• Maximum scan chain length specified by using the set_scan_configuration
-max_length command
• Scan chain count specified by using the set_scan_configuration -chain_count

command

S-2021.06-SP4
Feedback
Synthesis
• Excluded elements specified by using the set_scan_configuration

-exclude_elements command
• Scan inputs, outputs, enable ports specified by using the set_scan_path or

set_dft_signal command
If you use an unsupported DFT command, the tool issues a warning message as shown in
the following example:
rtl_shell> insert_dft
Warning: insert_dft is unsupported in RTL Architect. Ignored.(DFT-2083)

S-2021.06-SP4
Feedback
5
Analyzing the Design
To analyze the design, first compute the metrics of interest. After generating metrics, you
can visually analyze the metrics in the GUI or generate reports to analyze the metrics. For
information about computing and analyzing metrics, see the following topics:
• Computing Metrics
• Analyzing Metrics in the GUI
• Generating Metrics Reports
• Comparing QoR Data
Computing Metrics
The RTL Architect tool provides a variety of metrics for a synthesized design.
For congestion, timing, and power metrics, use the compute_metrics command with
one or more of the -congestion, -timing, and -power options. When computing timing
metrics for hierarchical designs, use the -hierarchical option with the -timing option.
For clock gating metrics, use the report_clock_gating_metrics command.
For more information about the various metrics, see the following topics:
• Clock Gating Metrics
• Congestion Metrics
• Timing Metrics
• Power Metrics
Clock Gating Metrics

The report_clock_gating_metrics command reports the clock gating metrics of
registers in the design. The results are grouped by the integrated clock gating cell that
drives the registers.

S-2021.06-SP4
Feedback
Chapter 5: Analyzing the Design
Computing Metrics
You can generate a report for specific modes, corners, and scenarios by using the -mode,
-corner, and -scenario options. You can choose how to sort the results by using the
-sortby option and limit the size of the report by using the -nworst option.
The report is similar to the following example. By default, the report is sorted by clock
gating efficiency.
rtl_shell> report_clock_gating_metrics
****************************************
Report: report_clock_gating_metrics
Design: cpu_top
...
****************************************
Clock Clock Clock Gating Q to Clock Register
Name Frequency Gating Type Efficiency Ratio Name
----------- ---------- ----------- ------------ ----------- ----------
clk 0.8000 not gated 0.00% 0.0002 cpu/reg1
clk 0.8000 not gated 0.00% 0.0006 cpu/reg3
clk 0.8000 instantiated 0.01% 0.0029 cpu/reg12
clk 0.8000 inferred 49.75% 0.0002 cpu/reg15
clk 0.8000 both 75.67% 0.0017 cpu/reg28
1
Congestion Metrics
When the tool calculates the congestion metrics, it breaks the congestion map into
windows. Hotspots are determined by considering the overflow in each window. Each
window is a square; the length of each side of the square is specified in terms of the
number of global routing cells. The default is 3. To change the window size, set the
metrics.congestion.hotspot_creation_window_size application option. By default, if
the overflow in a window is greater than 2, the window is considered a congestion hotspot.
To change this limit, set the metrics.congestion.hotspot_creation_min_overflow
application option.
Congestion metrics indicate the contribution of each logical hierarchy in the design to
the overall congestion in the design and the total number cells or interconnections that
contribute to the congestion hotspots within each logical hierarchy.
Congestion in a logical hierarchy could have many causes, such as complex logic
structures, bad cell selection, high placement density, or floorplan issues such has narrow
channels.
To control global routing performed during the compute_metrics command, set the
metrics.congestion.route_global application option as described in the following
table.

S-2021.06-SP4
Feedback
Computing Metrics
metrics.congestion.route_global application compute_metrics command behavior

option setting
auto Automatically runs global routing if there is no

up to date global routing congestion map
off Does not run any form of global routing
always Always runs global routing irrespective of

whether or not there is an up to date global
routing congestion map
auto_floorplan_mode Automatically runs floorplan global routing if

there is no up to date global routing congestion
map
always_floorplan_mode Always runs floorplan global routing whether

or not there is an up to date global routing
congestion map
auto_switch_floorplan_mode Does a quick estimate of the congestion and

if it estimates that route_global might take
longer time to run, it automatically switches to
auto_floorplan_mode. This is the default.
To further understand the congestion seen within each logic hierarchy, as well as the
congestion due to interconnections, the tool computes the following set of congestion
submetrics:
• Utilization congestion
Reports the congestion caused by calculating the ratio of the total area occupied by
cells of the hierarchy and the area of the hierarchy occupied.
• Logic-structure-induced congestion
Reports the congestion caused by cells that belong to large, complex multiplexer
structures that have a high amount of connectivity contained within a small physical
area.
Note:
You can also include cells that are closely connected to SELECTOP cells
by setting the metrics.congestion.selectop_connection_threshold
application option to the number of steps you want to trace from the core
SELECTOP cell. By default, the threshold is 2.

S-2021.06-SP4
Feedback
Computing Metrics
Use the metrics.congestion.tracing_buffers application option to

ignore buffers encountered during tracing. This application option supports
the following values:
◦ The ignore value does not include any buffers encountered during
tracing in the congestion report.
◦ The ignore_but_count value ignores all buffers encountered during
tracing, but counts them as part of the SELECTOP cell structure, so they
are included in the congestion report.
◦ The include value counts all buffers that are encountered during tracing
in the congestion report.
• Floorplan congestion
Reports the contribution to hotspots from cells that are within narrow channels.
• Net congestion
Global interconnect congestion reports the contribution to hotspots from global nets
that connect to cells within a logical hierarchy. Local net congestion identifies nets that
connect to a logical hierarchy and have a pin connection close to the hotspot to which
they belong.
Note:
Supernets are not calculated in the global or local congestion calculations
if tracing buffers are included. To exclude tracing buffers from the metrics
calculations, set the metrics.congestion.tracing_buffers application
option to ignore or ignore_but_count.
• Dispersion
Reports the percentage of cells in a logical hierarchy that are placed away (or
dispersed) from the corresponding hierarchy placement cluster boundary.
• Distortion
Reports the logical hierarchy shape distortion percentage considering the area around
the corners of the distorted shape occupied by external hard macros.
Timing Metrics
Timing metrics indicate the contribution of each logical hierarchy in the design to the
overall timing violations in the design. For each logical hierarchy, the tool computes
the worst negative slack (WNS), total negative slack (TNS), and number of violating
endpoints (NVP). In addition, the violating paths in each logical hierarchy are categorized
into register-to-register and I/O paths. The I/O paths include input-to-register, register-

S-2021.06-SP4
Feedback
Computing Metrics
to-output, and input-to-output paths. By default, the tool considers the 50 worst
violating endpoints per path group per scenario in the entire design for associating
them with the logical hierarchy in which they belong. To change this number, set the
metrics.timing.max_paths application option.
By default, the tool considers the 50 worst violating endpoints per path group per scenario
in the entire design for associating them with the logical hierarchy to which they belong.
To further understand the timing violations seen within each logic hierarchy, the tool
computes the following set of timing submetrics:
• Zero-wire-load violations
A zero-wire-load (ZWL) violation occurs when an endpoint has negative slack when
considering zero wire load (zero capacitance and zero net delay).
To enable zero-wire-load computation use the
metrics.timing.enable_zwl_violations application option. This also restores the
ZWL timing metric column in the GUI Hierarchy Browser View and access to the menu
item in the drill-down window to populate the zero-wire-load violating paths.
By default, the ZWL violations computation and visualization in GUI hierarchy browser
is disabled.
• Bottleneck cell count
A cell is considered a bottleneck when the number of negative slack paths through it
exceeds a certain threshold.
By default, the threshold is 5. To change the threshold, set the
metrics.timing.bottleneck_path_count application option.
• Logic-level violations
A logic-level violation occurs when the number of logic levels for a negative slack
endpoint exceeds a certain threshold.
By default, the threshold is 10. To change the threshold, set the
metrics.timing.logic_level_threshold application option.
When calculating logic-level violation submetrics with the compute_metrics

command, you can specify the threshold per clock or a path group with the
set_timing_metrics_threshold command. Use the -logic_level_threshold
option to specify the logic-level threshold. Optionally, use the -group option with the
-logic_level_threshold option to specify a path group. Use the path group name
derived from the group names reported from the report_path_group command. If the
-group option is not used, the threshold defaults to the global setting.
The logic-level threshold set by the set_timing_metrics_threshold command

overrides the threshold settings from the metrics.timing.logic_level_threshold

S-2021.06-SP4
Feedback
Computing Metrics
application option. Use the -reset option to remove any previously assigned threshold
value.
• Path-length violations
A path-length violation occurs when a timing violating path is longer than a certain
threshold in microns.
By default, the tool automatically computes the threshold as the
metrics.timing.logic_level_threshold value times the
metrics.timing.unbuffered_net_length_threshold value. To change the
threshold, set the metrics.timing.path_length_threshold application option. If
you specify a net estimation rule with the metrics.timing.buffer_spacing_rule
application option, the tool considers the specified spacing requirements when
checking for this violation.
• Net-length violations
A net-length violation occurs when a timing violating path has an unbuffered net longer
than a certain threshold in microns.
The tool calculates a default threshold based on the length a medium-
sized buffer can drive for the technology. To change the threshold, set the
metrics.timing.unbuffered_net_length_threshold application option. If you
specify a net estimation rule with the metrics.timing.buffer_spacing_rule
application option, the tool considers the specified spacing requirements when
checking for this violation.
• Repeater-levels violations
Repeater count in a timing path is the number of buffers and the number of inverter
pairs in the timing path.
The tool computes violations based on the threshold dictated by
metrics.timing.max_repeater_threshold application option. The default is 10.
When the metrics.timing.max_repeater_threshold application option is set to a

value greater than or equal to one, the tool identifies all the violating timing endpoints
belonging to each logical hierarchy having more repeaters than the specified threshold.
When the metrics.timing.max_repeater_threshold application option is set to
a value less than one, the tool interprets it as a percentage of allowed repeaters in a
timing path and identifies all the violating timing endpoints having more repeaters than
the specified percentage with respect to the total cells in the path.
The following example reports the total number of violating timing paths which are also
found to violate the repeater-levels threshold in the logical hierarchy ‘wishbone’.

S-2021.06-SP4
Feedback
Computing Metrics
rtl_shell> get_metrics -metric metrics_tim_repeater_levels_viol \\

-cells wishbone
178
Power Metrics
During SoC architecture planning or RTL coding, power analysis is necessary to design
the shutdown of IP subsystems during different modes of operation to reduce leakage
power, design the power management unit (PMU) to obtain the best software and
hardware architecture for power, and make RTL micro-architectural changes to reduce
dynamic power.
The RTL Architect tool is integrated with the PrimePower RTL tool to run power estimation
on RTL blocks, subsystems, and full SoCs, and provide accurate power analysis reports
after FAST physical synthesis to validate power targets early in the design flow.
Before performing RTL power analysis, specify information for the PrimePower RTL tool
by using the set_rtl_power_analysis_options command.
The following table shows the information you can specify:
Information Default Option to specify
Setup file sourced before reading N/A -setup file_name

the design NDM in PrimePower
Setup file or list of commands to N/A -prepower_setup file_name

apply power analysis settings in
PrimePower
Scenario to use for power Current scenario -scenario scenario_name

analysis
SAIF file to use for power N/A -saif file_name

analysis
SAIF file to use for power N/A -merge_saif_options -option_list

analysis from PrimePower
FSDB file to use for power N/A -fsdb file_name

analysis from PrimePower
Prefix stripped from object names N/A -strip_path path_prefix_string

in the SAIF file
Block on which to perform power Top module of the -design module_name

analysis current block
Output directory for analysis RTLA_WORKSPACE -output_dir directory_name

results

S-2021.06-SP4
Feedback
Computing Metrics
Information Default Option to specify
Path to the PrimePower pwr_shell -pwr_shell file_name

executable
.db files for power analysis from N/A -backup_libs backup_libs

PrimePower
After setting the power analysis options, use the compute_metrics -power command to
invoke the PrimePower RTL tool and perform power estimation. The compute_metrics
-power command also annotates the different power component attributes for each cell
based on the metrics computed by the PrimePower RTL tool.
You can also perform standalone RTL power estimation and detailed RTL power
exploration in the PrimePower tool. Use the export_power_data command to export
your power data and generate a script that can be sourced in the PrimePower RTL tool to
perform power estimation. The export_power_data command creates a workspace with
the same specifications inherited by the compute_metrics -power command.
The following power metrics are generated for each logical hierarchy in the design:
• Total power
• Internal power
• Switching power
• Leakage power
• Glitch power
• Register power
• Memory power
• Combinational power
• Clock power
• Clock-gating efficiency statistics
• Blackbox power
These metrics indicate the power critical areas of the design; you can use this information
to modify the RTL to reduce power.
Reporting Power Metrics

After power analysis, you can view the design data and analysis results in the graphical
user interface (GUI) for visual debugging. You can also generate power metric reports

S-2021.06-SP4
Feedback
Computing Metrics
by using the report_metrics -power command. By default, the power metrics report is
generated in a list format. To view this report in a table format, use the -table option.
Alternatively, use the report_power command to report power metrics in a traditional
format with a detailed breakdown of the power consumption from each power group
across different power components, such as internal, switching, and leakage power. The
supported power groups are defined in Table 3.
Table 3 Power groups
Power groups Definition
I/O pad Cells from the pad cell group in the library
Memory Cells from the memory group in the library
Black box Cells with no functional description in the library
Clock network Cells in the clock network, excluding I/O pad cells
Register Latches and flip-flops driven by the clock network
Sequential Latches and flip-flops clocked by signals that are not in the
clock network
Combinational Nonsequential cells
The generated power report is derived from the PrimePower RTL results. The following
example reports internal, switching, leakage, and total power metrics for different power
groups.
rtl_shell> report_power
****************************************
Report : report_power
-rtl
Design : compile
****************************************
Internal Switching Leakage Total

Power Group Power Power Power Power ( %)
------------------------------------------------------------------------
clock_network 1.326e-06 0.000e+00 0.000e+00 1.326e-06 (18.95%)
register 1.652e-07 7.760e-08 5.445e-08 2.972e-07 ( 4.25%)
combinational 2.458e-06 2.202e-06 7.127e-07 5.373e-06 (76.80%)
sequential 0.000e+00 0.000e+00 0.000e+00 0.000e+00 ( 0.00%)
memory 0.000e+00 0.000e+00 0.000e+00 0.000e+00 ( 0.00%)
io_pad 0.000e+00 0.000e+00 0.000e+00 0.000e+00 ( 0.00%)
black_box 0.000e+00 0.000e+00 0.000e+00 0.000e+00 ( 0.00%)

S-2021.06-SP4
Feedback
Analyzing Metrics in the GUI
You can also get RTL-based power metrics to trace back to the RTL code by using the
get_metrics command. For more information about RTL-based metrics, see Generating
RTL-Based Metrics.

To visually analyze the metrics in the GUI,
• Use the logical hierarchy browser to display the congestion, timing, and power metrics
computed for each logical hierarchy.
The logical hierarchy browser provides features such as a treemap view, advanced
filtering of column values, and table column coloring. The following figure shows an
example of the display for congestion metrics in the logical hierarchy browser.
Figure 13

• Use RTL cross-probing to identify where certain cells originate in the RTL and examine
the corresponding RTL file.
To view the metrics support for RTL constructs in the GUI perform the following steps.

S-2021.06-SP4
Feedback
1. Click the ‘Show/Hide and Configure the Hierarchy Sub-Views’ icon.
2. In the ‘View Configuration Controls’ dialog box, select RTL.

S-2021.06-SP4
Feedback
3. Select ‘Show Logic Constructs’ in the ‘View Configuration Controls’ dialog box.
◦ Congestion metrics is reported against each of the RTL

constructs within each RTL module of the design in the
new RTL Hierarchy view as shown in the following figure:
◦ Power metrics is reported against each of the RTL constructs. It

is computed based on the leaf cells that are originating from the
RTL lines of the construct within each RTL module of the design
in the new RTL Hierarchy view, as shown in the following figure:
◦ Timing metrics is reported against each of the RTL constructs, computed

using all the violated timing endpoints that are cross-referencing.
The RTL lines of the construct within each RTL module of the design

S-2021.06-SP4
Feedback
Generating Metrics Reports
in the new RTL Hierarchy view, as shown in the following figure:
◦ Metrics are annotated for RTL Constructs in the RTL Source Browser. The
following example shows Power Metrics – Total Power metric value annotated
against the always@ RTL Construct in the RTL file viewed in the Browser.
For more information about RTL cross-probing, see the RTL Architect Graphical User
Interface User Guide.

You can generate the following metrics reports:
• To report the congestion, timing, or power metrics, use the report_metrics command
with the -congestion, -timing, or -power option.
By default, the tool reports metrics for the entire design.
◦ To report metrics for specific hierarchical cells, use the -cells option.
◦ To report metrics for a specific line in the RTL source, use the -rtl_line option.

S-2021.06-SP4
Feedback
The following example reports the congestion metrics for line number 50 of the
top.v RTL file:
rtl_shell> report_metrics -rtl_line {top.v 50} \
-congestion
◦ To report metrics for a specific RTL module, use the -rtl_modules option.
To get a collection of RTL modules, use the get_rtl_modules command.
The following example reports the timing metrics for the RTL module named CPU1:
rtl_shell> report_metrics -rtl_modules [get_rtl_modules CPU1] \
-timing
◦ To report metrics for a specific RTL cell, use the -rtl_cells option.
To get a collection of RTL cells, use the get_rtl_cells command.
The following example reports the power metrics for the RTL cell instance named
BlockA/CPU1:
rtl_shell> report_metrics -rtl_cells [get_rtl_cells BlockA/CPU1] \
-power
• To sort the row data in the metrics table, use the -sort option. The specified metrics
must be in the list of metrics to be reported, else the tool errors out. The sort is based
on the value of the metrics. By default, the rows for congestion and power are sorted
in decreasing order. For WNS and TNS the rows are sorted in increasing values and
other timing metrics are in decreasing values.
The following example sorts the timing metrics in the order based on the non-violating
paths in R2R timing path group.
rtl_shell> report_metrics -timing -table -sort {metrics_tim_nvp_r2r}
• To sort the metrics table in increasing order of the metric, use the +sign at the end of
the metric name.
The following example sorts the metrics_tim_nvp_total metric in increasing order.
rtl_shell> report_metrics -timing -table \\
-sort {metrics_tim_nvp_total+}
• To sort the metrics table in decreasing order of the metric, use the -sign at the end of
the metric name.
The following example sorts the metrics_tim_nvp_total metric in decreasing order.
rtl_shell> report_metrics -timing -table \\
-sort {metrics_tim_nvp_total-}

S-2021.06-SP4
Feedback
• To only report the metrics specified by you in the custom list, use the -custom option.
The -custom option must be used with the -table option and is mutually exclusive
with -congestion, -timing, and -power options.
The following example reports metrics based on a custom selection, which in this case
is a timing and a congestion metric:
rtl_shell> report_metrics \\
-custom {metrics_tim_nvp_r2r metrics_cong_percent_cells_in_cong_area}
-table
Note:
The -custom option can also be used with the -sort option.
• To generate metric reports for specific hierarchies or for a specific scenario in a
standard or table format, and compare reports between different experiments, see
Comparing QoR Data.
• To query congestion, timing, and power metrics, use the get_metrics command. For a
complete list of the metrics that can be queried, see the man page.
The get_metrics -metric <name>command supports user metrics. The support is
only for -nworstand-cellsoptions.
◦ To get the worst hierarchical cells for a given metric, use the following syntax:
rtl_shell> get_metrics -nworst <num> -metric <metric>
◦ To return a collection of the leaf cells related to a specific metric and logical
hierarchies, use the following syntax:
rtl_shell> get_metrics -details -metric metric -cells
logical_hierarchy
◦ To query the timing paths object-list associated with a specific timing metric use the
-details option with the get_metrics command. You can also see the violating
timing paths in the drill-down list in GUI hierarchy browser for RTL Timing Metrics.
The following example reports the collection of timing paths that belong to the
‘macstatus1’ hierarchy that violate the logic-levels threshold.
rtl_shell> rtl_shell> get_metrics -metric
metrics_tim_logic_levels_viol \\
-cells macstatus1 -details
{path_to_macstatus1/ShortFrame_reg/D_slack_-0.662579
path_to_macstatus1/ReceivedPacketTooBig_reg_LatchedMRxErr_reg/
D0_slack_-0.614497 path_to_macstatus1/
clock_gate_RetryCntLatched_reg/EN_slack_-0.597154}

S-2021.06-SP4
Feedback
◦ To print the properties of violating timing paths of a selected timing metric in a

tabular format, use the -path_table option as shown in the following syntax. If the
-path_table option is not specified, the command returns a collection of timing
path objects as shown in the previous example.
rtl_shell> get_metrics -metric metrics_tim_nvp_total -details \\
-cell <ce1> -path_table
The output is shown in the following figure:
Note:
If the logical hierarchy is not specified by using the -cells option, the
tool reports the details for the top level.
◦ To query the nWorst RTL constructs across all RTL modules of the design for a
specific type of congestion, timing, and power metric, use the following syntax:
rtl_shell> get_metrics -metric glitch_power -local \\
-rtl_module_construct_nWorst number_of_constructs
◦ To query a metric for a specific RTL construct that belongs to a given RTL module
of the design, use the get_metrics command as shown in the following example:
rtl_shell> get_metrics -metric glitch_power -local
-rtl_module_constructs \\
[get_rtl_module_constructs
eth_wishbone*CASE_/slowfs/cae522/rtl/verilog/eth_wishbone.v_756_819
]
◦ To query a metric for a specific RTL construct that belongs to a given RTL instance
of the design use the get_metrics command as shown in the following example:
rtl_shell> rtl_shell> get_metrics -local -metric
metrics_cong_logic_cong \\
-rtl_cell_constructs [get_rtl_cell_constructs
wishbone/CASE_/slowfs/cae522/rtl/verilog/eth_wishbone.v_1146_1304]
◦ By default, the get_metrics command reports metric information based on the

design's floorplan. To report RTL-based metric information, see Generating RTL-
Based Metrics.

S-2021.06-SP4
Feedback
Generating RTL-Based Metrics

You can get a congestion, timing, or power related metric that is the result of a specific
RTL line or get the RTL lines that contribute the most to a specific congestion, timing, or
power related metric by using the get_metrics command as follows:
• To get the metric value of a specific RTL line, use the following syntax:
rtl_shell> get_metrics -rtl_line rtl_line \
-metric metric
The following example generates the number of congested cells due to line 56 of the
sub1.v RTL file:
rtl_shell> get_metrics -rtl_line {sub1.v 56} \
-metric metrics_cong_number_cells_in_cong_area
• To get the cells that are derived from a specific RTL line and associated with a specific
RTL-centric metric, use the following syntax:
rtl_shell> get_metrics -rtl_line rtl_line \
-metric metric -details
The following example generates a collection of congested cells due to line 56 of the
sub1.v RTL file:
rtl_shell> get_metrics -rtl_line {sub1.v 56} \
-metric metrics_cong_number_cells_in_cong_area -details
• To get the worst RTL lines that contribute to a specific metric, use the following syntax:
rtl_shell> get_metrics -metric metric \
-rtl_worst_lines num
The following example returns the worst 10 RTL lines that cause the most congestion.
The command returns a list with sublists that contain the RTL file, the line number, and
the metric value.
rtl_shell> get_metrics -metric metrics_cong_number_cells \
-rtl_worst_lines 10
You can also get specific timing-, congestion-, or power-related metrics for RTL modules
and cells by using the get_metrics command as follows:
Note:
You must use the -local option with the following options to specify that the
metric data is limited to the immediate children of the RTL module or cell, as
opposed to all the leaf descendents.

S-2021.06-SP4
Feedback
• To get the metric value of a specific RTL module, use the following syntax:
rtl_shell> get_metrics -rtl_modules RTL_module_list \
-metric metric -local
The following example reports the number of congested cells generated by the RTL
module named myRTLmodule:
rtl_shell> get_metrics -rtl_modules myRTLmodule \
-metric metrics_cong_number_cells_in_cong_area -local
• To get the metric value of a specific RTL cell, use the following syntax:
rtl_shell> get_metrics -rtl_cells RTL_cell_list \
The following example reports the number of timing-bottleneck cells generated by the
RTL cell name U22:
rtl_shell> get_metrics -rtl_cells U22 \
-metric metrics_tim_bottleneck_count -local
• To get the specific number of worst RTL modules that contribute to a specific metric,
use the following syntax:
rtl_shell> get_metrics -rtl_modules_nWorst number_modules \
The following example reports the 5 RTL modules that generate the most congested
cells:
rtl_shell> get_metrics -rtl_modules_nWorst 5 \
-metric metrics_cong_number_cells -local
RTL Architect’s RTL-centric-metrics infrastructure supports reporting of congestion, power,

and timing metrics associated with constructs like always@ block, case statement, for,
while loops, and so on, present in RTL modules and RTL instances.
To query RTL constructs in the design that belong to certain RTL modules or RTL
instances, use the get_rtl_module_constructs command, which supports the following
options:
• -quiet: Suppresses warning and error messages if no objects match
• -regexp: Views the patterns argument as real regular expressions rather than simple
wildcard patterns.
• -nocase: Makes matches case-insensitive.
• -exact: Disables simple pattern matching.

S-2021.06-SP4
Feedback
• -expect exact_count: Specifies an expected number of objects to find. If the

command finds a different number of objects, a Tcl error is raised and the command
processing stops.
• -expect_at_least minimum_count: Specifies a minimum number of objects to find.
• -expect_each_pattern_matches: If this is specified, each pattern must match at

least one object. If one or more patterns does not match, a Tcl error is raised and the
command processing stops.
• -filter: Filters the collection based on the user criteria specified for an attribute that
is associated with the RTL module constructs.
• -of_objects: Collection of rtl_module, rtl_cell, rtl_module_construct or
rtl_cell_construct objects.
• pattern: The pattern input with the get_rtl_module_constructscommand returns

rtl_module_constructswhose names match the specified pattern. Patterns can
include the wildcard characters "*" and "?" or regular expressions, based on the
-regexp option. Patterns can also include collections of type cell.
To create a collection of RTL cell constructs, use the get_rtl_cell_constructs

command, which supports the following options:
• -quiet: Suppresses warning and error messages if no objects match.
• -regexp: Views the patterns argument as real regular expressions rather than simple
wildcard patterns.
• -nocase: Makes matches case-insensitive.
• -exact: Disables simple pattern matching.
• -expect_at_least minimum_count: Specifies a minimum number of objects to find.
• -expect_each_pattern_matches: If this is specified, each pattern must match at

least one object. If one or more patterns does not match, a Tcl error is raised and the
command processing stops.
• -filter: Filters the collection based on the user criteria specified for an attribute that
is associated with the RTL module constructs.
• -of_objects: Collection of rtl_module, rtl_cell, rtl_module_construct, or
rtl_cell_construct objects.
• pattern: The pattern input with the get_rtl_module_constructs command

returns rtl_module_constructs whose names match the specified pattern. Patterns

S-2021.06-SP4
Feedback
can include the wildcard characters "*" and "?" or regular expressions, based on the
-regexp option. Patterns can also include collections of type cell.
• -leaf:Returns leaf cells of rtl_cell_construct object.
The following example gets all the RTL cell constructs whose
metrics_cong_number_cells_in_cong_area attribute is greater than 0. The command
processing stops if the filtering criteria is not specified.
rtl_shell> rtl_shell> get_rtl_cell_constructs \\
-filter "metrics_cong_number_cells_in_cong_area>0"
Table 4, Table 5, and Table 6 list the RTL-based metrics related to congestion, timing, and
power that you can specify with the -metric option.
Table 4 Congestion-Related RTL-Based Metrics
Metric Description
metrics_cong_number_cells Number of cells generated by each RTL line
metrics_cong_number_cells_in_cong_area Number of congested cells generated by each RTL line
metrics_cong_percent_cells_in_cong_area Percentage of congested cells due to each RTL line
metrics_cong_number_cells_in_cong_channel Number of cells in narrow channels that contribute to the

congestion by each RTL line
metrics_cong_logic_cong Cells due to an RTL line that cause congestion based on

the logic structure
metrics_cong_overflow Criticality of congestion caused by a RTL line through

cumulative congestion overflow, computed from all the
cells which belong to congested hotspots generated from
that RTL line
Table 5 Timing-Related RTL-Based Metrics
Metric Description
metrics_tim_bottleneck_count Number of bottleneck cells generated by an RTL line
metrics_tim_logic_level_viol Number of violating endpoints generated by an RTL line associated

with timing paths that have logic-levels greater than a specific
threshold
metrics_tim_wns_total Worst negative slack among all the violating endpoints that are
generated by an RTL line
metrics_tim_tns_total Total negative slack of all the violating timing endpoints generated by
an RTL line

S-2021.06-SP4
Feedback
Comparing QoR Data
Table 5 Timing-Related RTL-Based Metrics (Continued)
Metric Description
metrics_tim_nvp_total Number of violating endpoints generated by an RTL line
Table 6 Power-Related RTL-Based Metrics
Metric Description
total_power Total power for all cells generated by a specific RTL line
internal_power Internal power for all cells generated by a specific RTL line
leakage_power Leakage power for all cells generated by a specific RTL line
switching_power Switching power for all cells generated by a specific RTL line
glitch_power Glitch power for all cells generated by a specific RTL line
Comparing QoR Data

You can generate a web-based report to view and compare your QoR data with a
QORsum report by performing the following steps:
1. (Optional) Configure the QoR data, which is captured and displayed in the subsequent
steps, by using the set_qor_data_options command.
• To specify the most critical power scenarios in your design, use the
-leakage_scenario and -dynamic_scenario options.
The tool uses the power scenarios you specify to generate the high-level summary
of the power QoR in the QORsum report. If you do not specify these options, it uses
the active power scenario with the highest total power for both the leakage and
dynamic scenario for the power QoR summary.
These settings are only used for the power QoR summary. The tool uses the power
information of all active power scenarios to capture and report the detailed power
information in the QORsum report.
• To specify the most critical clock name and clock scenario, use the -clock_name
and -clock_scenario options.
The tool uses the clock name and scenario you specify to generate the high-level
summary of the clock QoR in the QORsum report. If you do not specify these
options, the tool identifies the most critical clock and uses it for the clock QoR
summary.

S-2021.06-SP4
Feedback
Comparing QoR Data
These settings are only used for the clock QoR summary. The tool uses all clocks to
generate the detailed clock QoR information in the QORsum report.
• To specify a name to identify the run in the QORsum report, use the -run_name
option.
By default, the tool names each run with a number, such as Run1, Run2, and so
on. You can use this option to give a more meaningful name to each run. You can
also specify the run name by using the -run_names option when you generate the
QORsum report by using the compare_qor_data command in step 3. If you do so,
the tool ignores the run name specify by the set_qor_data_options -run_name
command.
The following example specifies the leakage-power scenario, dynamic-power scenario,
clock scenario, and the clock to use for the corresponding summary in the QORsum
report:
rtl_shell> set_qor_data_options \
-leakage_scenario S1 -dynamic_scenario S2 \
-clock_scenario S3 -clock_name sys_clk
2. Collect the QoR data for your report by using the write_qor_data command.
You can run the write_qor_data command multiple times, at each stage of the design
flow at which you want to capture QoR data. Use the -label and specify a value to
indicate at which stage of the flow you are capturing the data.
rtl_opt
write_qor_data
3. Generate the QORsum report by using the compare_qor_data command.

This command takes the data captured by one or more runs of the write_qor_data
command and creates a web-based report for viewing and comparing those results.
You must specify the location of the output of each of the write_qor_data runs from
the previous step by using -run_locations option. Each path location corresponds to
the run result that you want to compare.
You can generate a QORsum to compare the results of one or more runs of the
write_qor_data command and design-exploration runs performed by using the
explore_design command. If you do so, use the -run_locations option to specify
the location of the outputs from the write_qor_data and explore_design command
runs.
You can assign a specific name to identify the run in the QORsum report by using the
-run_names option. If you do so, the tool ignores the run name specify by using the

S-2021.06-SP4
Feedback
Comparing QoR Data
set_qor_data_options -run_name command. By default, the tool names each run

by a number, such as run1, run2, and so on.
You can specify the output directory by using the -output option. By default, the tool
writes the report to a directory named compare_qor_data. To overwrite exiting output
data, use the -force option. By default, the tool does not overwrite existing output
data.
4. View the generated QORsum report by using the view_qor_data command.
Figure 14 QORsum Report

For more information about exploring the comparison data, see the following topics:
• Setting Your Baseline Run
• Changing the QoR Display Style
• Sorting and Filtering the Data
• Exploring the Detailed Comparison Data
Setting Your Baseline Run

By default, the first row of data is your baseline run against which all other runs are
compared. The name of the baseline run is highlighted in gold to mark it as the “golden,”
or baseline, result.

S-2021.06-SP4
Feedback
Comparing QoR Data
The shading of non-baseline cells indicates the direction and degree by which the data
differs from the baseline:
• Red indicates a degradation compared to the baseline; green indicates an
improvement compared to the baseline
• Lighter shading represents a smaller difference compared to the baseline; darker
shading represents a larger difference compared to the baseline
To view the delta thresholds corresponding to each shade, hover the cursor over the
column headers:
To change your baseline run, click the Runs button and select a new run as the baseline
from the Baseline Run column, as shown in the following figure:


S-2021.06-SP4
Feedback
Comparing QoR Data
See Also
Changing the QoR Display Style

By default, the comparison tables show the QoR values for all runs. For example, the NVE
number for the following run is 2374:
To cycle through different display styles of the data, right-click anywhere in the table. You
can view the data
• as a percentage delta against the baseline
• as an absolute delta against the baseline (shown in italic)
For example, as a percentage delta, the NVE number shows 2.7% fewer failing endpoints
than the baseline:
As an absolute delta, the NVE number shows 65 fewer failing endpoints than the baseline:
See Also

S-2021.06-SP4
Feedback
Comparing QoR Data
Sorting and Filtering the Data

You can sort and filter the run data to reveal patterns in the results and determine the
parameters you want to explore further.
To sort and filter the data, see the following topics:
• Sorting the Data
• Filtering Metrics
• Filtering Runs
• Example Analysis
See Also

S-2021.06-SP4
Feedback
Comparing QoR Data
Sorting the Data

Click any column header to sort the data using that metric. The first click performs an
ascending sort, while the second click performs a descending sort.
For example, to show the worst TNS numbers at the top of the table and the best TNS
numbers at the bottom, click the TNS column header:
Click the TNS column header again to show the best TNS numbers at the top and the
worst at the bottom:


S-2021.06-SP4
Feedback
Comparing QoR Data
Filtering Metrics
To control which metrics are displayed in the table, click the Metrics button and select or
deselect the metrics from the Metrics dialog box accordingly.
For example, to show only the setup timing, netlist area, and cell counts, select the metrics
as shown in Figure 15.
Figure 15 Metrics Dialog Box

Filtering Runs
To control which runs are displayed in the table, click the Runs button and select or
deselect the exploration runs accordingly from the Visible Runs (Summary) column.
For example, to display only the first four runs in a table, select the runs as shown in
Figure 16.
Figure 16 Choose Baseline and Visible Runs Dialog Box


S-2021.06-SP4
Feedback
Comparing QoR Data
Example Analysis
The following example demonstrates how you might sort and filter your data to narrow
down the runs you would like to explore further.
Suppose you open the comparison report shown in Figure 17 and set the
util60_aspect1%1_layerM9 run as the base run.
Figure 17 Comparison Report

You could look at your TNS numbers first and sort the data from best TNS to worst TNS,
as shown in the following figure:

Notice that the best TNS runs have the M9 top layer, and the worst have the M7 top layer.
This suggests that restricting the metal layers significantly impacts timing.

S-2021.06-SP4
Feedback
Comparing QoR Data
You could then restrict your analysis to your M9 runs by turning off the visibility of your M7
runs, as shown in the following figure:

Now that you have your best TNS runs, you could compare their congestion by sorting
the GRCOverflow column to show the worst overflow at the top, as shown in the following
figure:

Notice that your higher-utilization runs have more congestion than your lower-utilization
runs. You could restrict your analysis to your lower-utilization runs by turning off the

S-2021.06-SP4
Feedback
Comparing QoR Data
visibility of your higher-utilization runs as shown in Figure 18, leaving you with a

manageable subset of exploration runs that better meet your timing and congestion goals.
Figure 18 Displaying Lower-Utilization Runs

Exploring the Detailed Comparison Data

When you launch the QORsum report, the application opens the QOR Summary table,
which summarizes high-level timing, power, and congestion metrics for each of your runs.
This and other summary views help you sort and filter the data to pinpoint the runs you
want to explore further.
After you have identified your best candidate runs using the summary tables, you can use
the detailed tables to provide deeper insights into your data. While summary tables give
a high-level overview of design QoR across all of your runs, such as the overall design
timing (WNS, TNS, and NVE) for every run, the detailed table can show the path-group-
based timing for all path groups in the design. Detailed tables allows you to view the timing
of a specific path group for all your runs or view the timing of all path groups for up to
six of your runs at once. All detailed tables follow the naming convention of ending with
“Details.” For example, Path Type Details table shows information about your path-type-
based timing.

S-2021.06-SP4
Feedback
Comparing QoR Data
By default, the detailed tables start in the Focused View, as shown in Figure 19.
Figure 19 Focused View

The Focused View shows you one path group at a time. To change your focus, use the
drop-down menus at the top. For example, you can specify a scenario and path group as
shown in Figure 20.
Figure 20 Focused View Drop-down Menu

The Focused View focuses on a specific property for all runs. However, you can also look
at all of the properties for a smaller number of runs.
For example, you can identify the worst path group by viewing all path groups
simultaneously. To view the data from the traditional detailed view, click the Focused View
toggle button at the top menu, as shown in Figure 21.
Figure 21 Focused View Toggle Button


S-2021.06-SP4
Feedback
Comparing QoR Data
To view detailed comparison data for a particular metric, click one of the detailed views in
the panel on the left.
For example, to view the details of your path-group-based timing, select Path Group
Details, as shown in Figure 22.
Figure 22 Path Group Details

Whereas each row in a summary table shows the results for a flow, each row in a detailed
table shows detailed information such as path group names. The flows are shown side
by side as columns under each metric. For example, the WNS column group (and the
column group of each metric) shows the same six columns labeled 1, 2, 5, 6, 9, 10. These
columns represent the results of each flow, and are given a flow ID number, rather than
showing the full flow name, to prevent the columns from being too wide. The first column
under each metric is the baseline, and the other five are the test flows being compared
to that baseline. A legend is shown above the table with the flow ID number in a gold box
(for the baseline) or a blue box (for the test flows), followed by the flow name. You can
expand or collapse the legend by clicking the Legend button. You can also see the flow
ID numbers in the “Choose Baseline and Visible Runs” dialog box, which is opened by
clicking the Runs button.
The detailed table views can display up to six runs at one time (your baseline run, plus
the first five other runs selected in the Choose Baseline and Visible Runs dialog box). To
change the runs that are displayed,
1. Click the Runs button to open the Choose Baseline and Visible Runs dialog box.
2. From the Visible Runs (Summary) column, select or deselect the runs accordingly. This
selects and deselects those runs from the Visible flows (Detailed) column.

S-2021.06-SP4
Feedback
Comparing QoR Data
Filtering the Detailed Data

Detailed views offer filters to focus on specific data. Some views have default filters that
are shown automatically. For example, the following detailed views have default scenario
and path group filters: Path Type Details, Path Group Details, and Logic Level Details.
You can modify the default filters by
• Removing the filter by clicking the X symbol before the filter name
• Changing the filter value
• Enable and disable the filter by clicking anywhere on the filter but the X symbol or value
field
You can also apply custom filters to the detailed data. To create a custom filter,
1. Click the Filter button to display the Add Filter fields, which are shown in the following
figure:
2. Define the filter by defining the filter criteria and selecting the datasets to include in the
results.
To define the filter, select the column and comparison type, and then specify the
comparison value.
• To perform a numeric comparison, select one of the following comparison types: =,
!=, <, <=, >, or >= and specify a numeric value in the Value field.
• To perform a string comparison, select the contains comparison type and specify a
string value in the Value field.
• To perform a regular expression comparison, select the regexp comparison type
and specify a regular expression in the Value field.
• To filter based on the available values of the selected column, select the enum
comparison type, which populates the Value field with a drop-down menu that
contains the available values, and then enable one or more of the displayed values.
When a value is enabled, a check mark is displayed before the value.

S-2021.06-SP4
Feedback
Comparing QoR Data
To enable or disable a value, highlight the value by clicking it or navigating to it

by using the Up and Down arrows, and then press Enter, which toggles the value
status. You can also type a string in the Value field to filter the available values in
the drop-down menu. To dismiss selected values, click the X symbol.
3. Apply the filter by clicking the green check mark.
For example, to filter the Path Group Details view by displaying the path groups in the
func@cworst scenario, define the filter as shown in the following figure:

S-2021.06-SP4
Feedback
6
Exploring the Design
After you have elaborated your design, linked it, and applied your constraints, you can use
the tool's design exploration capabilities to sweep multiple parameters to identify the best
implementation for your design. Traditionally, design exploration requires time-intensive,
manual set up of individual sweep parameters and exploration runs. The RTL Architect
tool makes it easy to launch and compare large numbers of exploration runs at once.
• The set_explore_design_options command lets you specify multiple ranges of
parameters
• The explore_design command takes your parameters and launches multiple
exploration runs at once
• The tool runs the rtl_opt and compute_metrics commands on each run to generate
implementation results
• The tool summarizes the implementation results in a web-based report for easy
comparative analysis
Based on your results, you might launch another set of exploration runs with different
parameters and compare the results, as shown in Figure 23. You can launch as many
exploration runs as needed until you identify the best implementation for your design.

S-2021.06-SP4
Feedback
Chapter 6: Exploring the Design

Figure 23 Exploring the Design Using Different Parameters

To run the design exploration flow,

1. Set up your exploration parameters
2. Launch your exploration runs
3. Analyze your exploration results
4. (Optional) Repeat steps 1-3 with a new set of parameters.
The following script demonstrates a basic design exploration flow. See the preceding
topics for more information about each step in the flow.
source scripts/rtl_setup.tcl
open_block BlockA.ndm:BlockA_top/pre_explore_design.design

S-2021.06-SP4
Feedback
Setting Up the Exploration Runs
set_app_options -name compile.auto_floorplan.enable -value true

set_app_options -name compile.auto_floorplan.initialize -value true
# Set up the exploration runs

set_host_options -max_cores 4 -num_processes 40 -name dist
set_explore_design_options -utilization {0.6 0.7 0.8 0.85} \
-aspect_ratio {1:1 1:2 2:3 3:2 2:1} \
-max_routing_layer {M9 M7}
# Launch exploration
run_monitor_gui
explore_design -host_options dist
# Generate exploration report

report_explore_design_result
save_lib -all

Before you launch a set of exploration runs, you must set your exploration parameters. To
do so,
1. Set your distributed processing configuration.
2. Specify the parameters you want to sweep.
3. Specify the power analysis information.
See Also
• Reporting Exploration Parameters and Runs
• Launching Exploration Runs
• Analyzing Exploration Results
Setting the Distributed Processing Configuration

Distributed processing performs tasks in parallel by using multiple machines. When using
distributed processing, each parallel task is called a process, and each process uses its
own process memory image.

S-2021.06-SP4
Feedback
To set a distributed processing configuration, use the set_host_options command. You

can specify one or more of the following settings, among others:
• The job submission command (the -submit_command option)
If you do not specify this option, the tool uses the rsh command to submit the parallel
processes.
• The list of host machines (the host_names argument)
• The maximum number of processes (the -num_processes option)
• The maximum number of cores (the -max_cores option)
• The configuration name (the -name option)
For the best performance during distributed processing, limit the number of processes to
the number of available cores, which is the sum of the number of CPUs times the number
of cores per CPU for each host machine.
The following example defines a distributed processing configuration named dist. This
configuration uses a maximum of 4 cores and 40 processes:
rtl_shell> set_host_options -max_cores 4 -num_processes 40 -name dist
Specifying Exploration Parameters

When you specify your exploration parameters, you are setting up the exploration runs
you want to launch. For example, you might specify two different floorplan utilizations, two
different aspect ratios, and three different supply voltages at which to run your design,
which generates 12 different exploration runs when launched.
To specify your exploration parameters, see the following topics:
• Specifying a Range of Parameters
• Excluding Parameters From a Run
• Including Parameters in a Run
• Adding User-Defined Parameters in a Run
See Also
• Reporting Exploration Parameters and Runs
Specifying a Range of Parameters

To specify a range of exploration parameters, use the set_explore_design_options
command.

S-2021.06-SP4
Feedback
You can specify ranges for multiple parameters, such as floorplan utilization, aspect ratio,
supply voltage, maximum routing layer, reference libraries, and more.
The following example sets up four different exploration runs, each at a different floorplan
utilization and aspect ratio, as shown in Figure 24.
rtl_shell> set_explore_design_options -utilization {0.6 0.8} \
-aspect_ratio {2:3 4:5}
Figure 24 Generated Exploration Runs

To save disk space when you launch the exploration runs, specify the -no_copy_data
option. By default, the tool launches each run on a unique copy of the design and saves
the run data to disk. When you specify the -no_copy_data option and launch the runs, the
tool runs each experiment on the original design in read-only mode and does not save the
run data to disk.
-aspect_ratio {2:3 4:5} -no_copy_data
Sweeping Across Floorplan Shape

You can sweep the floorplan shape during exploration by using the -shape option. The
following example specifies that the explore_design command runs four experiments
with R, L, T, and U floorplan shapes.
rtl_shell> set_explore_design_options -shape { R L T U }
The explore_design command uses shape R by default. However, you can specify R, L,
U, and T shapes.
Sweeping Across Side Length for a Given Shape
You can sweep different lengths of a floorplan for a given shape using the -side_length
option. The following example runs two experiments with two different width and height
combinations on a rectangular floorplan shape.

S-2021.06-SP4
Feedback
rtl_shell> set_explore_design_options -shape R \\

-side_length { { 300 400 } { 450 600 } }
The following figure shows the number of side length to be specified for different floorplan
shapes.
• For R shape, specify two side lengths, that is, width and height
• For L shape, specify four side lengths
• For T, and U shape, specify six side lengths
Excluding Parameters From a Run

By default, when you launch a set of exploration runs, the tool runs all combinations of the
parameters you set with the set_explore_design_options command. You can also use
the set_explore_design_options command to exclude one or more of these parameter
combinations from being run.
• To exclude one or more parameter combinations from being run, specify them with the
-exclude option.
You can specify values for the following parameters: utilization, aspect_ratio,
supply_power, max_routing_layer, and var_list.
• To add additional parameter combinations to the exclude list, specify them with the
-add_to_exclude option.
Note:
Do not add additional parameter combinations to the exclude list with the
-exclude option, which overwrites the existing exclude list with the values
you supply to the option.
Note that the -exclude and -add_to_exclude options are mutually exclusive with the
-include and -add_to_include options.
Suppose you specify the following parameters, which generates eight different exploration
runs when launched:
rtl_shell> set_explore_design_options \
-utilization {0.5 0.6} \

S-2021.06-SP4
Feedback
-aspect_ratio {2:1 4:3} \

Suppose you want to exclude the following runs from being launched:
• Runs with an utilization of 0.5 and an aspect ratio of 2:1
• Runs with an aspect ratio of 4:3 and a maximum routing layer of M8
To do so, specify the parameter combinations with the -exclude option:
-max_routing_layer {M8 M9} \
-exclude { {{utilization 0.5} {aspect_ratio 2:1}} \
{{aspect_ratio 4.3} {max_routing_layer M8}} }
As a result, the following exploration runs are not launched:
Suppose you decide to exclude the 0.6 utilization from being launched, in addition to the
parameter combinations you already excluded. To do so, specify the parameter with the
-add_to_exclude option:
-add_to_exclude {{utilization 0.6}}

S-2021.06-SP4
Feedback
The exclude list now includes runs with an utilization of 0.6, runs with an utilization of 0.5
and a ratio of 2:1, and runs with an aspect ratio of 4:3 and a maximum routing layer of M8.
Only Run 4 is launched, as shown in the following figure:
Including Parameters in a Run

By default, when you launch a set of exploration runs, the tool runs all combinations of
the parameters you set with the set_explore_design_options command. You can also
use the set_explore_design_options command to specify a subset of these parameter
combinations to be run.
• To specify one or more parameter combinations to run, specify the values with the
-include option.
You can specify values for the following parameters: utilization, aspect_ratio,
supply_power, max_routing_layer
• To add additional parameter combinations to the include list, specify those values with
the -add_to_include option.
Note:
Do not add additional parameter combinations to the include list with the
-include option, which overwrites the existing include list with the values
you supply to the option.
Note that the -include and -add_to_include options are mutually exclusive with the
-exclude and -add_to_exclude options.
Suppose you specify the following parameters, which generates eight different exploration
runs when launched:

S-2021.06-SP4
Feedback
Suppose you want to launch only following runs:

• Runs with an utilization of 0.5 and an aspect ratio of 2:1
• Runs with an aspect ratio of 4:3 and a maximum routing layer of M8
To do so, specify the parameter combinations with the -include option:
-max_routing_layer {M8 M9} \
-include { {{utilization 0.5} {aspect_ratio 2:1}} \
{{aspect_ratio 4:3} {max_routing_layer M8}} }
As a result, only the following exploration runs are launched:
Suppose you want to launch the 0.6 utilization parameter in addition to those you already
specified in the include list. To do so, specify the parameter with the -add_to_include
option:
rtl_shell> set_explore_design_options -add_to_include {{utilization 0.6}}
Now the include list includes the following runs:

• Runs with a utilization of 0.6
• Runs with a utilization of 0.5 and a ratio of 2:1
• Runs with a ratio of 4:3 and a maximum routing layer of M8

S-2021.06-SP4
Feedback
After adding the 0.6 utilization parameter to the include list, the following exploration runs
are launched:
Adding User-Defined Parameters in a Run

If you want to use parameters, such as frequency, that are not directly supported by the
set_explore_design_options command, you can provide a script to be sourced during
the exploration runs. The script can include variables to assign different values for the
runs. To specify the script name, use the -user_script option. To specify the values
for the variables in the script, use the -var_list option. The variables are treated as
additional parameters when determining the parameter combinations.
For example, to perform design exploration using different frequencies, you could create a
script named freq.tcl that uses two variables, $freq and $freq2, which are shown in purple
in the following example:
create_mode mode1
set target_freq $freq
set clk_period exp[1 / target_freq]
create_clock -name clk -period $clk_period [get_ports clk]
create_mode mode2
set target_freq2 $freq2
set clk_period2 exp[1 / target_freq2]
create_clock -name clk -period $clk_period2 [get_ports clk]
To source the freq.tcl script during the exploration runs with $freq values of 2 and 2.2
and $freq2 values of 3 and 3.3, as well as utilizations of 0.5 and 0.6, use the following
command:
-user_script freq.tcl -var_list { { freq {2 2.2} } {freq2 {3 3.3} } }

S-2021.06-SP4
Feedback
This example generates eight exploration runs:
Run 1 Run 5
utilization 0.5 utilization 0.6
variable freq 2 variable freq 2
variable freq2 3 variable freq2 3
Run 2 Run 6
variable freq 2 variable freq 2
variable freq2 3.3 variable freq2 3.3
Run 3 Run 7
variable freq 2.2 variable freq 2.2
variable freq3 3 variable freq2 3
Run 4 Run 8
variable freq 2.2 variable freq 2.2
variable freq2 3.3 variable freq2 3.3
To exclude specific variable values, use the following syntax:

rtl_shell> set_explore_design_options \\
-exclude {{{var_list var_name value} ...}}}
In addition to the -exclude option, this syntax applies to the -include,

-add_to_exclude, and -add_to_include options as well. Then when the
explore_design command generates experiments, it excludes or includes experiments
that have these variable values.
The RTL Architect tool allows you to apply additional constraints like PG creation,
bounds, path groups and so on, after conditioning the logical netlist. To do so include the
constraints in a script and pass it to the tool by using the -post_conditioning_script
option, as shown in the following example:
rtl_shell> set_explore_design_options \\
-post_conditioning_script my_script.tcl
Following is the example of a Tcl file generated:

...
rtl_opt -to conditioning
source_user_script my_script.tcl
rtl_opt -from estimation
...

S-2021.06-SP4
Feedback
Specifying the Power Analysis Information

To specify the information for power analysis, use the
set_rtl_power_analysis_options command, as described in Power Metrics. Scripts
generated for RTL power analysis in the exploration runs inherit the settings specified from
this command, except the directories specified with the -output_dir option.
Note:
If you do not specify the power analysis information, the explore_design
command fails.
Reporting Exploration Parameters and Runs

Before launching a set of exploration runs, you can report the exploration parameters you
have set and the runs those parameters generate.
• To report the exploration parameters you have set, use the
report_explore_design_options command.
• To report the exploration runs those parameters generate, use the explore_design
-report_only command and option.
For example, suppose you set the following exploration parameters:

-supply_power {{VDD {1.0 2.0 }} { VDD1 {2.0 4.0 } } } \
-max_routing_layer {M11 AP} \
-library {mylib1 mylib2} \
-exclude {{{utilization 0.5} {supply_power VDD1 2.0}} \
{{max_routing_layer M11} {aspect_ratio 1:2}}}
To report these exploration parameters,

rtl_shell> report_explore_design_options
*********************************************************
Report: set_explore_design_options
Design: top
Version: Q-2019.12-SP2
Date: Mon Mar 23 9:27:37 2020
*********************************************************
set_explore_design_options
-utilization { 0.50 0.60 }
-aspect_ratio { 1:2 3:4 }
-supply_power { { VDD 1.0 2.0 } { VDD1 2.0 4.0 } }
-max_routing_layer { M11 AP }
-library { { mylib1 } { mylib2 } }

S-2021.06-SP4
Feedback
Launching Exploration Runs
-exclude {
{ { utilization 0.5} { supply_power VDD1 2.0 } }
{ { max_routing_layer M11 } { aspect_ratio 1:2 } }
}
To report the exploration runs that are generated by these parameters,

rtl_shell> explore_design -report_only
*********************************************************
Report: explore_design -report_only
Design: top
...
*********************************************************
Exploration options
Option Value
utilization { 0.50 0.60 }
aspect_ratio { 1:2 3:4 }
supply_power { { VDD 1.0 2.0 } { VDD1 2.0 4.0 } }
max_routing_layer { M11 AP }
library { { mylib1 } { mylib2 } }
Experiment 1
utilization 0.60
aspect_ratio 3:4
supply_power VDD 1.00 VDD1 2.00
max_routing_layer M11
library mylib1
...
Experiment 18
utilization 0.60
aspect_ratio 3:4
supply_power VDD 2.00 VDD1 4.00
max_routing_layer AP
library mylib1
See Also
• Setting Up the Exploration Runs
• Launching Exploration Runs
Launching Exploration Runs

After setting your exploration parameters with the set_explore_design_options
command, you can launch your exploration runs.
To launch your exploration runs, use the explore_design command and specify the
distributed processing configuration you want to use with the -host_options option.

S-2021.06-SP4
Feedback
Handling Missing Data During Design Exploration
The tool creates a work directory that contains subdirectories for each exploration run.
The tool saves the run data for each run to its respective subdirectory. By default, the work
directory is named work_dir/run_explore_design/design_name/RTL/experiment_name,
where design_name is the name of the design being run. To specify a different name for
the work directory, use the -work_dir option.
Caution:
If you run multiple iterations of the explore_design command, use the
-work_dir option to specify a new name for the work directory to avoid
potential naming conflicts.
To monitor the progress of each exploration run, use the run_monitor_gui command
before using the explore_design command.
The following example launches a set of exploration runs and monitors their progress:
rtl_shell> run_monitor_gui
rtl_shell> explore_design -host_options dist
See Also
• Analyzing Exploration Results
Handling Missing Data During Design Exploration

When performing design exploration with the explore_design command, you can specify
how the tool handles the following missing data:
• The script specified by using the set_explore_design_option -user_script
command, which is sourced in each experiment Tcl script generated by the
explore_design command
To specify that the explore_design command should exit if this file is missing, apply
the following setting before you run the explore_design command:
rtl_shell> set_early_data_check_policy \
-check rtla.explore_design.missing_user_tcl_script \
–policy error
To specify that the explore_design command should ignore this file if it is missing and
not include it when generating the Tcl scripts for each experiment, apply the following
setting before you run the explore_design command:
-check rtla.explore_design.missing_user_tcl_script \
–policy repair

S-2021.06-SP4
Feedback
Analyzing Exploration Results
• The tool shell specified for power analysis by using the

set_rtl_power_analysis_options -pwr_shell command
To specify that the explore_design command should exit if the power-analysis shell is
missing, apply the following setting before you run the explore_design command:
-check rtla.explore_design.missing_pwr_shell \
–policy error
To specify that the explore_design command should try to locate a pt_shell, which is
the default power-analysis-tool shell, in the Synopsys installation directory, apply the
following setting before you run the explore_design command:
-check rtla.explore_design.missing_pwr_shell \
–policy repair

After you launch a set of exploration runs with the explore_design command, you can
generate a web-based report to analyze the results.
You can use this report to identify your best runs and perform further design exploration
within an optimal range of parameters. For example, you might find that your best runs
fall within the 60 - 70% utilization range. You could launch a new set of exploration runs
that sweep a 62%, 65%, and 67% utilization and compare the results. You could continue
launching, comparing, and refining different exploration runs until you identify an optimal
combination of parameters for implementation.
To generate an exploration report and analyze the results, see the following topics:
• Generating an Exploration Report
• Working With Summary Data
• Launching the Comparator Tool
Generating an Exploration Report

To generate a web-based report of your exploration run results, use the
report_explore_design_result command:
rtl_shell> report_explore_design_result

S-2021.06-SP4
Feedback
The command launches the Explore Design Summary page, where you can view a
summary of the run data:
Figure 25 Explore Design Summary Page

See Also
• Working With Summary Data
Working With Summary Data

When you generate a web-based report with the report_explore_design_result
command, the tool opens the Explore Design summary page (as shown in Figure 25),
where you can view high-level timing, power, and congestion metrics for each exploration
run.
To view the parameters for a particular run, hover the cursor over the name of that run.

S-2021.06-SP4
Feedback
To view more detailed timing, congestion, and power metrics for a particular run, click the
name of the run. The tool opens the Design Statistics and Summary page (Figure 26),
which summarizes the types and counts of cells in your design.
• To see detailed timing metrics for the run, click the timing tab at the top of the page
• To see detailed power metrics for the run, click the metrics tab at the top of the page
• To see detailed congestion metrics for the run, click the congestion tab at the top of the
page
Figure 26 Design Statistics and Summary Page

See Also
Launching the Comparator Tool

The web-based exploration report contains a unique comparator tool to help you compare
the quality of your runs and identify those you might explore further.
To launch the comparator tool, click the Comparator button on the Explore Design
Summary page:
The Comparator button opens the QOR Summary table (Figure 27), which summarizes
high-level timing, power, and congestion metrics for each of your exploration runs.

S-2021.06-SP4
Feedback
Exploring Different RTL Versions
Figure 27 QOR Summary Table

For more information about the QOR Summary table, see the following topics:
• Setting Your Baseline Run

You can use the tool's design exploration capabilities to sweep multiple versions of RTL for
a given design and identify the best RTL for that design.
To do so, use the following steps:
1. Create a design library for each version of RTL by performing the following steps:
a. Create a design library by using the create_lib command.
b. Analyze and elaborate the RTL by using the analyze and elaborate commands.
c. Apply all design constraints and settings.
d. Save and close the design library by using the save_block and close_block
commands.
Repeat these steps for each version of RTL.

S-2021.06-SP4
Feedback
Note:
You must close all the design libraries you created for each version of RTL
before you can proceed to the next step.
2. Specify the distributed processing configuration by using the set_host_options
command.
For more information, see Setting the Distributed Processing Configuration.
3. Specify exploration parameters by using the set_explore_design_options
command.
Specify the different versions of RTL you saved as design libraries in step 1 by using
the -block_rtl option.
For more information about the other exploration parameters you can specify with the
set_explore_design_options command, see Specifying Exploration Parameters.
4. Launch exploration runs by using the explore_design command.

For more information, see Launching Exploration Runs.
5. Analyze the exploration results by using the report_explore_design_result
command.
For more information, see Analyzing Exploration Results.
The following is an example script for exploring three versions of RTL for a given design.
# Step 1: Create design library for each version of RTL

#-------------------------------------------------------
create_lib design1.ndm
analyze rtl/rtl1.v
elaborate top
load_upf top.upf
source mcmm.tcl
save_block
close_block
analyze rtl/rtl2.v
elaborate top
load_upf top.upf
source mcmm.tcl
save_block
close_block
analyze rtl/rtl3.v

S-2021.06-SP4
Feedback
elaborate top
load_upf top.upf
source mcmm.tcl
save_block
close_block
# Step 2: Specify distributed processing configuration

#------------------------------------------------------
set_host_options -max_cores 8 -submit_command sh \
-name bhost
# Step 3: Specify exploration parameters

#----------------------------------------
set_explore_design_options \
-block_rtl { \
{ design1.ndm:top rtl1 } \
{ design2.ndm:top rtl2 } \
{ design3.ndm:top rtl3 }} \
-utilization {0.6 0.8}
# Step 4: Launch exploration runs

#---------------------------------
explore_design -host_options bhost \
-work_dir my_work_dir
# Step 5: Analyze exploration results

#-------------------------------------
report_explore_design_result -work_dir my_work_dir

S-2021.06-SP4

RTL Architect™ User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RTL Architect™ User Guide

Uploaded by

Copyright:

Available Formats

RTL Architect™ User Guide

Version S-2021.06-SP4, December 2021

RTL Architect™ User Guide 2

1. Working With the RTL Architect Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Defining the Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3. Restructuring the RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4. Synthesizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

5. Analyzing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Generating Metrics Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6. Exploring the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

About This User Guide

New in This Release

RTL Architect™ User Guide 7

Related Products, Publications, and Trademarks

Courier Indicates syntax, such as write_file.

Courier italic Indicates a user-defined value in syntax, such as

Purple • Within an example, indicates information of special interest.

[] Denotes optional arguments in syntax, such as

... Indicates that arguments can be repeated as many times as

| Indicates a choice among alternatives, such as

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Bold Indicates a graphical user interface (GUI) element that has an

RTL Architect™ User Guide 8

Ctrl+C Indicates a keyboard combination, such as holding down the Ctrl

RTL Architect™ User Guide 9

Contacting Customer Support

RTL Architect™ User Guide 10

RTL Architect™ User Guide 11

• Viewing Man Pages

RTL Architect Design Flow

Figure 1 RTL Architect Design Flow

RTL Architect™ User Guide 12

• Synthesizing the Design

Starting the Command-Line Interface

RTL Architect™ User Guide 13

• -x command to execute a command

• -output_log_file file_name to create a log file of your session

At startup, the tool performs the following tasks:

Exiting the RTL Architect Tool

RTL Architect™ User Guide 14

Entering rtl_shell Commands

Interrupting or Terminating Command Processing

command, press Ctrl+C.

RTL Architect™ User Guide 15

When you use Ctrl+C, keep the following points in mind:

Getting Information About Commands

Displaying Command Help

RTL Architect™ User Guide 16

Using Application Options

To generate a report of application options, use the report_app_options command.

RTL Architect™ User Guide 17

Viewing Man Pages

RTL Architect™ User Guide 18

Using Tcl Scripts

RTL Architect™ User Guide 19

Using Setup Files

Using the Command Log File

RTL Architect™ User Guide 20

Enabling Multicore Processing

RTL Architect™ User Guide 21

Configuring Distributed Processing

RTL Architect™ User Guide 22