Cadence Design With RTL Compiler Physical PDF

Design with RTL Compiler Physical
Product Version 13.1

November 2013
© 2007-2013 Cadence Design Systems, Inc. All rights reserved.
Used by permission. Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document
are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks,
contact the corporate legal department at the address shown above or call 800.862.4522. All other
trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and
contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or
distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as
specified in this permission statement, this publication may not be copied, reproduced, modified, published,
uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence.
Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to
print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability for damages or
costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Additional References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
How to Use the Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Reporting Problems or Errors in Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Cadence Online Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Other Support Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Command-Line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Getting the Syntax for a Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Getting the Syntax for an Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Searching for Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Searching For Commands When You Are Unsure of the Name . . . . . . . . . . . . . . . . 15
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Text Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Using Physical Information in Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Flows, and Product and License Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Special Files for Physical Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Physical Information in the Design Information Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 22
2
Simple PLE Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Attributes Affecting the PLE Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
November 2013 3 Product Version 13.1

© 1999-2013 All Rights Reserved.
Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . 31
Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . 31
Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Sample Script for Simple PLE Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3
Generating PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Generating the PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Using the PLE Data in the Physical Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4
Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Attributes Affecting the Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Setting up the Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Synthesizing with Rapid Placement Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Sample Script for Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5
RC-Physical Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Attributes Affecting the RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Setting up the RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Loading the Encounter Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Synthesizing, Estimating, and Optimizing for Silicon . . . . . . . . . . . . . . . . . . . . . . . . . 79
Sample Script for RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6
Structured Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
SDF File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
SDP File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
alias Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
datapath Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
column Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
inst Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
row Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
SDP File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
SDP Information in the Design Information Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
SDP Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Preface
■ About This Manual on page 8

■ Additional References on page 8
■ How to Use the Documentation Set on page 9
■ Customer Support on page 11
■ Messages on page 12
■ Man Pages on page 13
■ Command-Line Help on page 14
■ Documentation Conventions on page 16

Preface
About This Manual

This manual describes how to use physical infromation in RTL Compiler.
Additional References
The following sources are helpful references, but are not included with the product
documentation:
■ TclTutor, a computer aided instruction package for learning the Tcl language:
http://www.msen.com/~clif/TclTutor.html.
■ TCL Reference, Tcl and the Tk Toolkit, John K. Ousterhout, Addison-Wesley
Publishing Company
■ IEEE Standard Hardware Description Language Based on the Verilog Hardware
Description Language (IEEE Std.1364-1995)
■ IEEE Standard Hardware Description Language Based on the Verilog Hardware
Description Language (IEEE Std. 1364-2001)
■ IEEE Standard VHDL Language Reference Manual (IEEE Std. 1076-1987)
■ IEEE Standard VHDL Language Reference Manual (IEEE Std. 1076-1993)
Note: For information on purchasing IEEE specifications go to http://shop.ieee.org/store/ and
click on Standards.

Preface
How to Use the Documentation Set
Cadence Installation Guide

INSTALLATION AND CONFIGURATION
Cadence License Manager
README File
README File
NEW FEATURES AND
SOLUTIONS TO PROBLEMS
What’s New in Encounter RTL
Compiler
Known Problems and Solutions in

Encounter RTL Compiler
Getting Started with Encounter

RTL Compiler
Using Encounter RTL Compiler
TASKS AND CONCEPTS
HDL Modeling in Encounter RTL ChipWare Developer in Library Guide for Encounter RTL
Compiler Encounter RTL Compiler Compiler
Setting Constraints
Datapath Synthesis in Low Power in Design for Test in
and Performing Timing
Encounter RTL Encounter RTL Encounter RTL
Analysis in Encounter
Compiler Compiler Compiler
RTL Compiler
REFERENCES
Attribute Reference Command Reference ChipWare in GUI Guide for Quick Reference for
for Encounter RTL for Encounter RTL Encounter RTL Encounter RTL Encounter RTL
Compiler Compiler Compiler Compiler Compiler

Preface
Reporting Problems or Errors in Manuals

The Cadence® Help online documentation, lets you view, search, and print Cadence product
documentation. You can access Cadence Help by typing cdnshelp from your Cadence tools
hierarchy.
Contact Cadence Customer Support to file a PCR if you find:

■ An error in the manual
■ An omission of information in a manual
■ A problem using the Cadence Help documentation system

Preface
Customer Support
Cadence offers live and online support, as well as customer education and training programs.
Cadence Online Support

The Cadence® online support website offers answers to your most common technical
questions. It lets you search more than 40,000 FAQs, notifications, software updates, and
technical solutions documents that give you step-by-step instructions on how to solve known
problems. It also gives you product-specific e-mail notifications, software updates, case
tracking, up-to-date release information, full site search capabilities, software update
ordering, and much more.
For more information on Cadence online support go to:
http://support.cadence.com
Other Support Offerings

■ Support centers—Provide live customer support from Cadence experts who can
answer many questions related to products and platforms.
■ Software downloads—Provide you with the latest versions of Cadence products.
■ Education services—Offers instructor-led classes, self-paced Internet, and virtual
classroom.
■ University software program support—Provides you with the latest information to
answer your technical questions.
For more information on these support offerings go to:
http://www.cadence.com/support

Preface
Messages
From within RTL Compiler there are two ways to get information about messages.
■ Use the report messages command.
For example:
rc:/> report messages
This returns the detailed information for each message output in your current RTL
Compiler run. It also includes a summary of how many times each message was issued.
■ Use the man command.
Note: You can only use the man command for messages within RTL Compiler.
For example, to get more information about the "TIM-11" message, type the following
command:
rc:/> man TIM-11
If you do not get the details that you need or do not understand a message, either contact
Cadence Customer Support to file a PCR or email the message ID you would like improved
to:
rc_pubs@cadence.com

Preface
Man Pages
In addition to the Command and Attribute References, you can also access information about
the commands and attributes using the man pages in RTL Compiler. Man pages contain the
same content as the Command and Attribute References. To use the man pages from the
UNIX shell:
1. Set your environment to view the correct directory:
setenv MANPATH $CDN_SYNTH_ROOT/share/synth/man
2. Enter the name of the command or attribute that you want either in RTL Compiler or
within the UNIX shell. For example:
❑ man check_dft_rules
❑ man cell_leakage_power
You can also use the more command, which behaves like its UNIX counterpart. If the output
of a manpage is too small to be displayed completely on the screen, use the more command
to break up the output. Use the spacebar to page forward, like the UNIX more command.
rc:/> more man synthesize

Preface
Command-Line Help
You can get quick syntax help for commands and attributes at the RTL Compiler command-
line prompt. There are also enhanced search capabilities so you can more easily search for
the command or attribute that you need.
Note: The command syntax representation in this document does not necessarily match the
information that you get when you type help command_name. In many cases, the order of
the arguments is different. Furthermore, the syntax in this document includes all of the
dependencies, where the help information does this only to a certain degree.
If you have any suggestions for improving the command-line help, please e-mail them to:
rc_pubs@cadence.com
Getting the Syntax for a Command

Type the help command followed by the command name.
For example:
rc:/> help path_delay
This returns the syntax for the path_delay command.
Getting the Syntax for an Attribute

Type the following:
rc:/> get_attribute attribute name * -help
For example:
rc:/> get_attribute max_transition * -help
This returns the syntax for the max_transition attribute.

Preface
Searching for Attributes

You can get a list of all the available attributes by typing the following command:
rc:/> get_attribute * * -help
You can type a sequence of letters after the set_attribute command and press Tab to
get a list of all attributes that contain those letters.
rc:/> set_attr li
ambiguous "li": lib_lef_consistency_check_enable lib_search_path libcell
liberty_attributes libpin library library_domain line_number
Searching For Commands When You Are Unsure of the Name

You can use help to find a command if you only know part of its name, even as little as one
letter.
■ You can type a single letter and press Tab to get a list of all commands that start with
that letter.
For example:
rc:/> c <Tab>
This returns the following commands:

ambiguous "c": cache_vname calling_proc case catch cd cdsdoc change_names
check_dft_rules chipware clear clock clock_gating clock_ports close cmdExpand
command_is_complete concat configure_pad_dft connect_scan_chains continue
cwd_install ..
■ You can type a sequence of letters and press Tab to get a list of all commands that start
with those letters.
For example:
rc:/> path_<Tab>
This returns the following commands:

ambiguous command name "path_": path_adjust path_delay path_disable path_group

Preface
Documentation Conventions
Text Command Syntax

The list below defines the syntax conventions used for the RTL Compiler text interface
commands.
literal Nonitalic words indicate keywords you enter literally. These

keywords represent command or option names.
arguments and Words in italics indicate user-defined arguments or information
options for which you must substitute a name or a value.
| Vertical bars (OR-bars) separate possible choices for a single
argument.
[] Brackets indicate optional arguments. When used with OR-
bars, they enclose a list of choices from which you can choose
one.
{} Braces indicate that a choice is required from the list of
arguments separated by OR-bars. Choose one from the list.
{ argument1 | argument2 | argument3 }
{ } Braces, used in Tcl commands, indicate that the braces must
be typed in.
... Three dots (...) indicate that you can repeat the previous
argument. If the three dots are used with brackets (that is,
[argument]...), you can specify zero or more arguments. If
the three dots are used without brackets (argument...), you
must specify at least one argument.
# The pound sign precedes comments in command files.

1
Introduction
■ Using Physical Information in Synthesis on page 18

■ Special Files for Physical Flows on page 20
■ Physical Information in the Design Information Hierarchy on page 22

Introduction
Using Physical Information in Synthesis

Traditional synthesis tools use vendor-supplied wire-load models based on fanouts, which do
not provide accurate wire delay information especially for designs where a significant portion
of the delays are contributed by the wires. Consequently, you can see relative big differences
in performance, area, and power between the logic and physical designs.
Custom wire-load models are considered to be the starting point for synthesis, as they are
more accurate than the vendor-supplied wire-load models. But the disadvantage is that you
need to place the design to create custom wire-load models. In addition, placement depends
on an initial pass of gate generation done with ad hoc methods. Furthermore, custom wire-
load models represent a static view of the design and depend on the netlist used to generate
the placement. As the RTL and constraints change over the design cycle, the custom wire-
load models become increasingly inaccurate.In many cases, the custom wire-load models
generated at the start of the design can be worse than the vendor-supplied wire-load models
at the end of the project.
Physical layout estimation (PLE) uses physical information to model the effects of placement
based on the current state of the RTL and the constraints, and provides you with a level of
analysis and optimization that would not be available with a traditional synthesis methodology.
Furthermore, using physical information gives a level of down-stream predictability that is
superior to using vendor supplied wire-load models. Predictability will enable you to better
gauge how the design will perform after place and route and help to reduce frontend to
backend hand-off iterations. Ultimately, using physical information in synthesis gives you the
opportunity to develop a smaller, faster design in less time than with traditional synthesis.
Table 1-1 summarizes the differences between performing synthesis using physical layout
estimation or wire-load models.
Table 1-1 PLE versus WLM
Physical Layout Estimation (PLE) Wire-load Models (WLM)

Uses actual design and physical library Wire-load models are statistical.
information.
Dynamically calculates wire delays for Wire-load models are calculated based on
different logic structures in the design. the nearest calibrated area.
Selection of appropriate wire-load models for
a design is tedious.
Correlates better with place and route. Correlation is difficult even with custom wire-
load models.

Introduction
Flows, and Product and License Requirements

RTL Compiler offers three physical-related flows. They provide increasing accuracy in
predicting the wire lengths.
The simple PLE flow uses technology information and cell areas from the LEF libraries
instead of from the synthesis technology libraries. The PLE flow uses parasitic resistance and
capacitance values from the LEF libraries or the capacitance tables (if available) when
estimating the wire lengths. This flow works in all base RTL Compiler products.
The RC-Spatial flow uses in addition a rapid placement to better estimate long wires in your
design. This helps deliver more accuracy to the core synthesis optimization engine during
RTL-to-gate synthesis. This flow works in all base RTL Compiler products, but requires
access to the Encounter Digital Implementation System.
The RC-Physical flow uses in addition a complete placement and considers congestion
and legal placement as a cost function during the RTL-to-gates phase, to create a better
netlist. This flow requires an RTL Compiler Advanced Physical Option license in addition to a
base RTL Compiler product license and requires access to the Encounter Digital
Implementation System.
You do not need a deep, technical knowledge of physical design to use physical information
in RTL Compiler. The usage model is kept simple on purpose and the physical data is as
abstract as possible. Reading through this document should be sufficient to becoming
effective in using physical information in synthesis.

Introduction
Special Files for Physical Flows

Figure1-1 shows the data flow for the physical flows.
Figure 1-1 Physical Information Files
Encounter
DEF Synthesis RTL Configuration Constraint
Floorplan Libraries Files File File
File
RTL Compiler
LEF Capacitance
Libraries Table File
SDC Gate-Level Encounter

DEF
Constraints Netlist Database
File
Files
Files added
for physical
Optional file
The following file is required for the three physical-related flows.

■ LEF — The LEF libraries are the physical libraries that contain information such as layer,
via, placement site type, routing design rules, process information, and standard cell and
macro cell definitions.
The following file is optional but recommended for the three physical-related flows.
■ Capacitance Table — Capacitance tables contain the same type of parasitic
information as the LEF files but the resistance and capacitance information in the
capacitance table is more detailed and therefore more accurate than in the LEF file. The

Introduction
values in a capacitance table comes from the same process definition files that drive sign
off extraction as well as the various other extractors used in Cadence tools.
The following file is optional but recommended in the RC-PLE and RC-Spatial flow, and is
required for the RC-Physical flow:
■ DEF — DEF files are ASCII files that contain information that represent the design at any
point during the layout process. In RTL Compiler, the DEF is primarily used for floorplan
information.
The following file is optional and can be only used in the RC-Physical flow:
■ Encounter Configuration — The Encounter configuration file contains Tcl variables
that describe design information such as the netlist, technology libraries, LEF
information, constraints, capacitance tables, resistance scaling factors, capacitance
scaling factors, and floorplan parameters. The ability to import the settings from an
Encounter Configuration file provides a way for existing Encounter users to quickly get
up and running. The preferred methodology is to specify the settings using native RTL
Compiler commands.

Introduction
Physical Information in the Design Information Hierarchy

RTL Compiler stores the original design data along with additional information in the physical
files in the design information hierarchy in the form of attributes. Figure 1-2 shows the design
information hierarchy.
Figure 1-2 Design Information Hierarchy
(rc/>)
root
designs messages object_types libraries hdl_libraries
design_name ENC library_name
constants PHYS
operating_conditions
PLC
dft wireload_models
instances_comb wireload_selections
blockages
bumps
libcells
instances_hier
defpins
instances_seq physical_cells
fills
gcells
nets operating_conditions
groups
physical layers wireload_models

fills
wireload_selections
port_busses_in nondefaultrules
pcells
libcells
port_busses_out pdomains
pnets
ports_in
regions
ports_out rows
sites
subdesigns slots
specialnets
timing
styles
tracks
vias

Introduction
The root directory contains the root attributes which apply to all designs that you read in. The
root directory has six main directories.
■ The designs directory can have several subdirectories each representing a design in
memory.
■ The hdl_libraries directory contain information about the ChipWare and third party
libraries, and about the Verilog modules and/or VHDL architectures and entities that
were read using the read_hdl command.
■ The libraries directory can have several subdirectories each representing a
technology library in memory. The physical_cells contain information about the
physical cells that are present in the LEF files (have a LEF MACRO definition), but not in
synthesis libraries.
■ The messages directory contains all information for all messages that can be displayed
during an RTL Compiler session. Physical-related messages are stored in the ENC,
PHYS, and PLC subdirectories.
■ The object_types directory lists all attributes for all database objects (designs,
subdesigns, pins, and so on) in the design hierarchy.
As shown in Figure 1-2 on page 22, each design also has several objects. The physical
engine uses and updates physical-specific attributes on the following object types:
■ Root
■ Design
■ Pin
Note: These attributes apply to objects in the pins_in and pins_out directories—
subdirectories of objects in the instances_comb, instances_hier, and
instances_seq directories.
■ Net
■ Port
■ Subdesign
■ Instance
Note: These attributes apply to objects in the instances_comb, instances_hier,
and instances_seq directories.

Introduction
Each design also has a physical directory with the following subdirectories:
■ blockages contain information about the BLOCKAGES defined in the DEF file.
■ bumps contain information about the solder bumps on the chip. A BUMP is instantiated
in the DEF COMPONENTS section but is not instantiated in the netlist.
■ defpins contain information about external pins in the design. The information is based
on the PIN statement in the DEF file.
■ fills contain information about every metal FILL defined in the DEF file.
■ gcells contain information about the global routing cells (gcell). Gcells are derived from
the GCELLGRID statements in the DEF file.
■ groups contain information about the GROUPS defined in the DEF file.
■ layers contain information about the metal layers defined in the LEF or capacitance
table file.
■ nondefaultrules contain information based on the NONDEFAULTRULES statement in the
DEF file.
■ pcells contain information about the physical cells (pcell) instantiated in the
COMPONENTS section of the DEF file. Pcells are not instantiated in the netlist.
■ pdomains contain physical information about the power domains defined in the DEF file.
■ pnets contain information information based on the NETS section in the DEF file.
■ regions contain information about every REGION defined in the DEF file.
■ rows contain information about every ROW defined in the DEF file.
■ sites contain information based on the SITE statement in the LEF file.
■ slots contain informationabout the slotting of the wires in the design. The information
is based on the SLOTS statement in the DEF file.
■ specialnets contain information based on the SPECIALNETS statement in the DEF
file.
■ styles contain information based on the STYLES statement in the DEF file.
■ tracks contain track (or routing grid) information for each layer. The information is
based on the TRACKS statements in the DEF file.
■ vias contain information about fixed vias and generated vias. The via names
correspond to the via names specified in the VIAS statement.

2
Simple PLE Flow
■ Overview on page 26
■ Attributes Affecting the PLE Flow on page 27
■ Tasks on page 28
❑ Reading the LEF Libraries on page 28
❑ Loading the Parasitic Information on page 30
❑ Reviewing Consistency Between the LEF and Parasitic Files on page 31
❑ Checking the Physical Layout Estimation Information on page 31
❑ Setting the Appropriate Synthesis Mode on page 33
❑ Reading the Floorplan on page 34
❑ Analyzing the Results on page 37
❑ Exporting Files for Place and Route on page 39
■ Sample Script for Simple PLE Flow on page 40

Simple PLE Flow
Overview
The simple PLE flow does not differ much from the generic flow except that you will be using
LEF files and capacitance tables to drive synthesis. Any steps that overlap with the generic
flow will not be covered in this chapter. Refer to Using Encounter RTL Compiler for more
information on the generic flow.
Figure 2-1 Simple PLE Flow
Start
Target
Read timing libraries
libraries
LEF
Read LEF libraries
libraries
Capacitance
file Load parasitic information
QRC tech
file
Review consistency between

LEF and parasitic files
Read HDL files and elaborate Modify source

HDL
files design
Check physical layout

estimation information
Set synthesis mode

Change physical constraints
DEF
Read floorplan
file
Change SDC constraints
SDC Apply constraints
constraints
Synthesize No
Task added for Meet

Physical Analyze constraints?
Export design
Optional task Yes

Simple PLE Flow
Attributes Affecting the PLE Flow
Attribute Name Object Type Default

aspect_ratio design float 1.0
cap_table_file root string
interconnect_mode root string wireload
lef_library root string
lef_stop_on_error root boolean false
lib_lef_consistency_check_enable root boolean true
number_of_routing_layers design integer
phys_ignore_nets design boolean false
phys_ignore_special_nets design boolean false
qrc_tech_file root string
shrink_factor root float
use_area_from_lef root boolean true
utilization layer float

Simple PLE Flow
Tasks
The tasks below list only those that are different from the generic flow or illustrate a new step.
■ Reading the LEF Libraries on page 28
■ Loading the Parasitic Information on page 30
■ Reviewing Consistency Between the LEF and Parasitic Files on page 31
■ Checking the Physical Layout Estimation Information on page 31
■ Setting the Appropriate Synthesis Mode on page 33
■ Reading the Floorplan on page 34
■ Analyzing the Results on page 37
■ Exporting Files for Place and Route on page 39
Reading the LEF Libraries

LEF files are ASCII files that contain physical library information such as layer, via, placement
site type, routing design rules, process information, and standard cell and macro cell
definitions. The technology information and the cell definitions are usually available in
separate LEF files for easier management.
In the simple PLE flow, the cell area defined in the LEF libraries is used instead of the cell
area defined in the timing library (.lib).
The timing library area will be used if

■ The physical libraries do not contain any cell definitions.
■ You only read in the technology LEF file (containing only the metal routing layer
information without the standard cell/macro definitions).
For best results, always use all available LEF files (standard cell, macro and technology LEF).
To import LEF files, use the lef_library attribute. Specify all LEF files, the technology
library and the cell libraries. It is a good practice to specify the technology LEF file first.
The following example imports a technology and cell library LEF files.
rc:/> set_attribute lef_library {tech.lef cell.lef}

Simple PLE Flow
Use the get_attribute command to confirm the list of imported LEF files:
rc:/> get_attribute lef_library
tech.lef
cell.lef
RTL Compiler will check whether the following definitions are in the LEF file:
■ CAPACITANCE CPERSQ
■ EDGECAPACITANCE
■ RESISTANCE RPERSQ
■ SITE
■ WIDTH
If any of these definitions are missing, RTL Compiler will issue a warning message.
If there is at least one MACRO definition in the LEF file, RTL Compiler checks if all the cells in
the timing library have a corresponding definition in the LEF library. Any cells that are defined
in the timing library but not in the LEF will be marked as avoid (they will not be used during
synthesis) and a warning message will be issued. To turn off this consistency checking, set
the lib_lef_consistency_check_enable attribute to false:
rc:/> set_attribute lib_lef_consistency_check_enable false /
The resistance and capacitance information can be found in the capacitance table file.
RTL Compiler supports LEF 5.3 and above. Refer to the LEF/DEF Language Reference
for more information on LEF files.
Troubleshooting Tips
Only one LEF file seems to be imported
Check if the lef_library attribute was set more than once or was part of a loop.
In the following example, the existing LEF file is replaced because it specifies the files
separately with two set_attribute commands as opposed to a Tcl list with one
set_attribute command.
rc:/> set_attribute lef_library tech.lef
rc:/> set_attribute lef_library cell.lef

Simple PLE Flow
Loading the Parasitic Information

Capacitance tables files or QRC technology files contain the same type of parasitic
information as the LEF files but the resistance and capacitance information in these files have
a finer granularity. For technologies below 28nm, the Encounter Digital Implementation
System requires a QRC technology file instead of a capacitance table file.
The capacitance in a LEF comes from a foundry and is generated by whatever process it sees
as appropriate. The capacitance information in a capacitance table or QRC technology file
comes from the same process definition files that drive sign off extraction as well as the
various other extractors used in Cadence tools. The process definition files define layer
thicknesses, compositions, and spacings.
■ To load the capacitance table file, use the cap_table_file attribute:
rc:/> set_attribute cap_table_file my.cap /
■ To load the QRC technology file, use the qrc_tech_file attribute:

rc:/> set_attribute qrc_tech_file techfile.qrc /
Note: If you specify both a capacitance table file and a QRC technology file, the QRC
technology file takes precedence.
It is recommended to specify both LEF and parasitic files. However, you can specify the LEF
files only, if the parasitic files are not available.
Scaling factors are used to align a design with a particular process. A capacitance table is
process specific where as a scaling factor is design specific. The scaling factors are provided
to be consistent with Encounter. Only use a scaling factor if it will also be used in the back-
end.
RTL Compiler will check if the following information is available in the parasitic file:
■ PROCESS_VARIATION
■ BASIC_CAP_TABLE
■ width
■ Cc
■ Carea
■ Cfrg
If any of these definitions are missing, RTL Compiler will issue a warning message. It will
purposely disregard the EXTENDED_CAP_TABLE section because the PLE is intended to
synchronize with a view of the design where fast extractors are typically used.

Simple PLE Flow
Tip
For best results, the corner for the parasitic file used should match the corner for the
timing library. That is typically max or worst.
Reviewing Consistency Between the LEF and Parasitic Files

After you load both your LEF and parasitic files, RTL Compiler will perform consistency
checks between the two files. This happens automatically, much like the check between the
LEF and timing library files.
■ Number of Layers — RTL Compiler will check to determine if the number of layers
defined in the LEF and the parasitic files are equal.
If the LEF has more layers than the parasitic file, then an error message will be issued
and you will need to manually check both of the files to resolve the inconsistency.
If the parasitic file has more layers than the LEF, a warning message will be issue and
the number of routing layers will be set to the number specified in the parasitic file.
■ Width of Layers — RTL Compiler will check to determine if the width of the layers
defined in the LEF and the parasitic files are equal. A warning will only be issued if the
width difference defined in the two files is greater than 10%.
RTL Compiler reports the inconsistencies in the log file. You should review the log file. For
example, check for messages PHYS 24 through 27.
Checking the Physical Layout Estimation Information

After loading the LEF libraries, the capacitance information, and the design information, you
can check the physical layout estimation information for the design.
➤ To report the physical layout estimation information for the design, once all physical data
has been read in, use the following command:
report ple
As shown in Figure 2-2 on page 32, this command reports information like aspect ratio, shrink
factor, site size, layer names, direction of layers, capacitance, resistance, and area. It also
shows the source that it used to extract the physical information.
The Interconnect mode line in the report header is set to global, which indicates that
you are running in PLE mode. In this flow, this value is kept throughout the flow.

Simple PLE Flow
Figure 2-2 Example of Report PLE

rc:/> report ple
============================================================
Generated by: Encounter(R) RTL Compiler version
Generated on: date
Module: DTMF_CHIP
Technology libraries: library1
library2
...
physical_cells
Operating conditions: slow
Interconnect mode: global
Area mode: physical library
============================================================
Aspect ratio : 1.00

Shrink factor : 1.00
Scale of res/length : 1.00
Scale of cap/length : 1.00
Net derating factor : 1.00
Site size : 5.70 um (from lef [tech+cell])
Capacitance
Layer / Length Data source:
Name Direction Utilization (pF/micron) cap_table_file
------------------------------------------------
M1 H 1.00 0.000274
M2 V 1.00 0.000242
M3 H 1.00 0.000242
M4 V 1.00 0.000242
M5 H 1.00 0.000242
M6 V 1.00 0.000304
Resistance
Name Direction Utilization (ohm/micron) lef_library
-------------------------------------------------
Metal1 H 1.00 0.439130
Metal2 V 1.00 0.360714
Metal3 H 1.00 0.360714
Metal4 V 1.00 0.360714
Metal5 H 1.00 0.360714
Metal6 V 1.00 0.102273
Area
Name Direction Utilization (micron) lef_library
-------------------------------------------------
Metal1 H 1.00 0.230000
Metal2 V 1.00 0.280000
Metal3 H 1.00 0.280000
Metal4 V 1.00 0.280000
Metal5 H 1.00 0.280000
Metal6 V 1.00 0.440000
rc:/>

Simple PLE Flow
Setting the Appropriate Synthesis Mode

RTL Compiler has two synthesis modes: wireload and ple. These modes are set using the
interconnect_mode attribute.
■ In wireload mode (default), you use wire-load models to drive synthesis.
■ In ple mode, you use Physical Layout Estimation (PLE) to drive synthesis. PLE is the
process of using physical information, such as LEF libraries, to provide better closure
with back-end tools
When you read in LEF libraries, the interconnect_mode attribute is automatically set to
ple.
Note: If you want to use wireload mode, you must manually set the interconnect_mode
attribute to wireload after loading the LEF libraries.
For this flow, do not change the setting.

Simple PLE Flow
Reading the Floorplan

Similar to providing timing and design constraints for the logic design, you should provide
physical constraints in the form of a floorplan when you use PLE.
In RTL Compiler, you provide floorplan information through a DEF file.

■ The die or block bounding box determines the placement area and therefore influences
the net length.
■ Pin and macro locations influence the standard cell placement and thus the net length.
RTL Compiler supports DEF 5.3 and above. Refer to the LEF/DEF Language Reference
for more information on DEF files.
➤ To import a DEF file, use the read_def command.
rc:/> read_def def_file
RTL Compiler will perform a consistency check between the DEF and the Verilog netlist and
issue relevant messages if necessary. For example:
Parsing DEF file...
Warning : A DEF component does not exist in the netlist. [PHYS-171]
: The component ’IOPADS_INST/Pcornerll’ does not exist.
: This message has a default max print count of ’25’, which can be
changed by setting the ’max_print’ attribute.
: The component ’IOPADS_INST/Pcornerlr’ does not exist.
...
Done parsing DEF file.
The DEF file must define the die size. For better synthesis results, you should also have the
pin, macro locations, and standard cell placement specified in the DEF, although it is not
required.
Figure 2-3 on page 35 shows an example of DEF statistics printed after the DEF file has been
processed.

Simple PLE Flow
Figure 2-3 Example of DEF Statistics

Summary report for DEF file ’/xxx/floorplan/fplan_mp.def’
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Placed: 0
Unplaced: 1
TOTAL: 72 (1 is class macro)
There are 4 components that do not exist in the netlist.
Pins
----
Cover: 0
Fixed: 0
Physical: 5
Placed: 0
Unplaced: 57
TOTAL: 62
Nets
----
Read: 0
Skipped: 0
TOTAL: 0
SpecialNets
-----------
Read: 2
Skipped: 0
TOTAL: 2
Fences: 0
Guides: 1
Regions: 0
Done processing DEF file.
========================
Physical Message Summary
========================
5 / 5 I PHYS-154 Creating physical pin.

4 / 4 W PHYS-171 Component not present in netlist.
71 / 0 I PHYS-181 Full preserve set on instance.
Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s)..

Simple PLE Flow
Table 2-1 Component Types
Type Explanation Tip
Cover A component that has a location and is a part of A large number of cover cells can indicate that
a cover macro. A COVER component cannot be the DEF file is not a floorplan but instead
moved. could be the DEF for a fully placed design.
Fixed A component that has a location and that cannot All components in a floorplan DEF should be
be moved by automatic tools. set as fixed to avoid unwanted movement
during placement
Physical A component that is instantiated in the DEF but A large number of physical components can
not in the netlist. indicate that the DEF is not a floorplan DEF.
Placed A component that has a location and that can be These components are not expected in a
moved by automatic tools. floorplan.
Unplaced A component that has no location. These components are not expected in a
floorplan.
class macro A large component. For example, a memory. The number of class macros should be less
than or equal to the number of fixed
components.
Table 2-2 Pin Types
Cover A pin that has a location, orientation, and that is

part of the cover macro. A COVER pin cannot
be moved
Fixed A pin that has a location, orientation and that It is recommended to have all pins fixed.
cannot be moved by automatic tools.
Placed A pin that has a location, orientation and that
can be moved by automatic tools.
Unplaced A pin that has no location.
There is also a summary of the blockages defined in the DEF file:

Fences: 0
Guides: 1
Regions: 0
For more information on these terms, refer to the Glossary on page 103
To check which DEF is loaded in the tool, use the def_file attribute:
rc:/> get_attribute def_file /designs/design

Simple PLE Flow
Analyzing the Results

➤ To print an area report, use the report area command.
rc:/> report area
============================================================
Generated on: date
Module: DTMF_CHIP
library2
...
physical_cells
============================================================
Instance Cells Cell Area Net Area Total Area

------------------------------------------------------------------
DTMF_CHIP 4969 1218398 74621 1293018
IOPADS_INST 67 721450 0 721450
DTMF_INST 4902 496948 71032 567980
TDSP_CORE_INST 2831 74538 41884 116422
MPY_32_INST 775 21339 10900 32238
M16X16_INST 592 18422 7083 25505
EXECUTE_INST 631 21472 7071 28543
ALU_32_INST 583 8898 7730 16628
TDSP_CORE_GLUE_INST 458 8073 5268 13341
DECODE_INST 157 5279 1394 6673
PROG_BUS_MACH_INST 57 2628 474 3102
PORT_BUS_MACH_INST 57 2635 466 3100
DATA_BUS_MACH_INST 55 2644 437 3081
TDSP_CORE_MACH_INST 36 1221 383 1604
ACCUM_STAT_INST 17 316 119 435
RAM_256x16_TEST_INST 17 113630 132 113762
RAM_128x16_TEST_INST 17 100778 132 100910
RESULTS_CONV_INST 1779 46573 23785 70358
ARB_INST 22 69455 233 69688
SPI_INST 45 2415 509 2924
DMA_INST 45 1943 454 2396
ULAW_LIN_CONV_INST 58 1207 592 1800
DATA_SAMPLE_MUX_INST 28 659 85 744
DIGIT_REG_INST 10 725 0 725
TDSP_DS_CS_INST 22 446 123 568
TDSP_MUX 17 439 12 451
TEST_CONTROL_INST 8 126 49 175
The Interconnect mode in the report header is still set to global because in the simple
PLE flow the design is synthesized without placement information.
The report shows the total count of cells mapped against the hierarchical blocks, the
combined cell area in each of the blocks and the top level design. The Cell Area numbers
are based on the information in the LEF libraries. The Net Area refers to the estimated post-
route net area and is based on the minimum wire widths defined in the LEF and capacitance
table files and the area of the design blocks.

Simple PLE Flow
➤ To get an overall report containing slack information, instance count, area information,
cell power, runtime, and host name information, use the report qor command.
rc:/> report qor
============================================================
...
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0
Cost Critical Violating

Group Path Slack TNS Paths
--------------------------------------
default No paths 0
vclk01 No paths 0
vclk02 No paths 0
vclk1 -423.7 -671 4
vclk2 2021.0 0 0
--------------------------------------
Total -671 4
Instance Count
--------------
Leaf Instance Count 4969
Sequential Instance Count 546
Combinational Instance Count 4423
Hierarchical Instance Count 26
Area & Power

------------
Total Area 1293018.485
Cell Area 1218397.679
Floorplan Utilization 36.45%
Leakage Power 4480.258 nW
Dynamic Power 247756070.964 nW
Total Power 247760551.222 nW
Max Fanout 540 (scan_enI)

Min Fanout 0 (n_3)
Average Fanout 2.5
Terms to net ratio 3.5
Terms to instance ratio 3.9
Runtime 77 seconds
Hostname host
Since you performed physical synthesis and started with a floorplan, the report also contains
the floorplan utilization in %.

Simple PLE Flow
Exporting Files for Place and Route

The final part of the physical flow involves exporting the data for place and route processing.
This is done through the write_design -encounter command.
The write_design -encounter command generates the following files:

■ Netlist (.v)
■ Encounter configuration file (.conf),
■ SDC constraints (.sdc)
■ Tcl script (.enc_setup.tcl)
■ Mode file (.mode)
■ DEF file (.def)
■ Timing derate file (.derate.tcl) — generated when RTL Compiler changed the default
timing derate values

Simple PLE Flow
Sample Script for Simple PLE Flow

set_attribute source_verbose true /
set_attribute information_level 9 /
suppress_message "xxx "
set_attribute enc_temp_dir rc_enc /
set_attribute lib_search_path path /
set_attribute library "library_list" /
set_attribute lef_library "lef_list" /
# read parasitic information from capacitance table or QRC tech file
# set_attribute cap_table_file file /
# set_attribute qrc_tech_file techfile.qrc /
read_hdl DESIGN/dtmf_chip.v
elaborate DTMF_CHIP
report ple
read_sdc dtmf.sdc
read_def DESIGN/floorplan/dtmf.def
synthesize -to_mapped
report area
report qor
write_design -encounter

3
Generating PLE Data
■ Introduction on page 42
■ Generating the PLE Data on page 43
■ Using the PLE Data in the Physical Flows on page 44

Generating PLE Data
Introduction
Using LEF libraries and optionally parasitic information (through capacitance tables or QRC
technology files) for Physical Layout Estimation (PLE) improves the correlation with the
backend as compared to using wire-load models. However with shrinking technologies, it
becomes a challenge to correlate well with the place and route tools. There is a need to
handle special rectilinear floorplan effects. With no parasitic information or just a rudimentary
parsing of the information, the correlation will be off. The solution is to create customized PLE
information.
➤ To create PLE correlation data for the design, use the following command:
generate_ple_model design -outfile PLE_file
Net capacitances and resistances depend on technology parameters as well as the floorplan.
This command refines the PLE parameters by taking both these variables into account and
by comparing the PLE data with the SPEF data from Encounter. This results in a highly
customized PLE equation for the given design and technology libraries.
The generated file is an encrypted file that contains

■ Average Capacitance and Resistance values based on placement and default routing
■ Adjustments for PLE equation parameters
The header of the generated file is readable. Check the header against the current design
data to avoid miscorrelation. The header might look like:
# DESIGN NAME: DTMF_CHIP
# TECHNOLOGY LEF: all.lef
# CAP-TABLE: typical.captbl
# CAP SCALE: 1.0
# RES SCALE: 1.0
# ASPECT RATIO: 0.9814
If the design data is inconsistent, a message will be issued.

Generating PLE Data
Generating the PLE Data

At the start of the synthesis process, use the following flow to generate the PLE data.
set_attribute library library_list /
set_attribute lef_library lef_files /
read_hdl hdl_file
elaborate
# read constraint files including scaling factors
read_def def_file
generate_ple_model design -outfile ple_file
quit
This flow does not require a floorplan, though having a good floorplan is highly
recommended. Since the flow generates a quick placement, you need access to the
Encounter Digital Implementation System.
If you start from RTL, RTL Compiler will run the following command:
synthesize -to_mapped -effort medium
Note: You can also start with a mapped or a placed design to generate the PLE data.
Once the PLE data are generated, quit the session and start a new session with the PLE data.
Tip
Run this flow once to generate PLE correlation data separately for each design. You
can use the same model for small changes in the design, such as small RTL
modifications, slight floorplan size changes, or slight macro movements. You can
also use the model for different designs with the same technology libraries, but in
the latter case the impact of the aspect ratio on the net lengths may be lost.

Generating PLE Data
Using the PLE Data in the Physical Flows

Source the generated PLE data file for every subsequent run that starts from RTL.
set_attribute library library_list /
set_attribute lef_library lef_files /
read_hdl hdl_file
elaborate
# read constraint files including scaling factors
read_def def_file
decrypt ple_file
synthesize ...
Since you need access to the Encounter Digital Implementation System to generate the PLE
data, the use of the generated PLE data is only shown in the Spatial Flow and RC-Physical
Flow.

4
Spatial Flow
■ Attributes Affecting the Spatial Flow on page 47
❑ Setting up the Spatial Flow on page 48
❑ Loading Generated PLE Data on page 57
❑ Synthesizing with Rapid Placement Input on page 58
■ Sample Script for Spatial Flow on page 62

Spatial Flow
Overview
In addition to using technology information and cell areas from the LEF libraries, and parasitic
resistance and capacitance values from the LEF libraries or capacitance tables, the RC-Spatial
flow uses a rapid placement to better estimate long wires in your design. This improves the
accuracy of the core synthesis optimization engine during RTL-to-gate synthesis.
This flow is useful for blocks or chips with simple floorplans.
Figure 4-1 Spatial Flow
Start
Target
libraries
LEF libraries Read LEF libraries

Capacitance
QRC tech
file

HDL files
design
Set synthesis mode


DEF file Read floorplan
SDC Change SDC constraints

Apply constraints
constraints
Load generated PLE data Using

generated
Check physical layout PLE data
Synthesize with rapid No

Task added for placement input
Physical
Meet
Analyze constraints?
Optional task
Export design
Yes

Spatial Flow
Attributes Affecting the Spatial Flow

encounter_executable root
init_core_utilization design float
pqos_ignore_msv root boolean false
pqos_ignore_scan_chains root boolean false
qos_report_power root boolean false
scale_of_cap_per_unit_length root float 1.0
scale_of_res_per_unit_length root float 1.0

Spatial Flow
Tasks
The tasks below list only those that are different from the generic flow or illustrate a new step.
■ Setting up the Spatial Flow on page 48
■ Loading Generated PLE Data on page 57
■ Synthesizing with Rapid Placement Input on page 58
Setting up the Spatial Flow

➤ To specify the Encounter executable that you want to use for the
synthesize -spatial command, set the following root attribute:
set_attribute encounter_executable path_to_soc_executable /
If this attribute is not set, the following (default) search order is used:
1. ENCOUNTER environment variable
2. PATH environment variable
3. CDS_SYNTH_ROOT environment variable

Spatial Flow

In the spatial flow, the cell area defined in the LEF libraries is used instead of the cell area
defined in the timing library (.lib).

tech.lef
cell.lef
■ EDGECAPACITANCE
■ SITE
■ WIDTH

Spatial Flow
The resistance and capacitance information can be found in the capacitance table file.



Spatial Flow
to be consistent with Encounter. Only use a scaling factor if it will also be used in the back-
end.
■ BASIC_CAP_TABLE
■ width
■ Cc
■ Carea
■ Cfrg
Tip


Spatial Flow

with back-end tools
When you read in LEF libraries, the interconnect_mode attribute is automatically set to
ple.
For this flow, do not change the setting.

report ple
The report header contains an Interconnect mode line which indicates that you are
running in PLE mode. In this case, the value is set to global because you run the report before
the design is synthesized.

Spatial Flow

rc:/> report ple
============================================================
Generated on: date
Module: DTMF_CHIP
library2
...
physical_cells
============================================================
Aspect ratio : 1.00

Capacitance
------------------------------------------------
M1 H 1.00 0.000274
M2 V 1.00 0.000242
M3 H 1.00 0.000242
M4 V 1.00 0.000242
M5 H 1.00 0.000242
M6 V 1.00 0.000304
Resistance
-------------------------------------------------
Metal1 H 1.00 0.439130
Metal2 V 1.00 0.360714
Metal3 H 1.00 0.360714
Metal4 V 1.00 0.360714
Metal5 H 1.00 0.360714
Metal6 V 1.00 0.102273
Area
-------------------------------------------------
Metal1 H 1.00 0.230000
Metal2 V 1.00 0.280000
Metal3 H 1.00 0.280000
Metal4 V 1.00 0.280000
Metal5 H 1.00 0.280000
Metal6 V 1.00 0.440000
rc:/>

Spatial Flow

Similar to providing timing and design constraints for the logic design, you should provide
physical constraints in the form of a floorplan when you use a physical flow.
In RTL Compiler, you provide floorplan information through a DEF file.

■ The die or block bounding box determines the placement area and therefore influences
the net length.
■ Pin and macro locations influence the standard cell placement and thus the net length.
Parsing DEF file...
...
required.
processed.

Spatial Flow

Summary report for DEF file ’/xxx/fplan_mp.def’
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Bump: 0
Placed: 0
Unplaced: 1
Pins
----
Cover: 0
Fixed: 0
Physical: 5
Placed: 0
Unplaced: 57
TOTAL: 62
Nets
----
Read: 0
Skipped: 0
TOTAL: 0
SpecialNets
-----------
Read: 2
Skipped: 0
TOTAL: 2
Fences: 0
Guides: 1
Regions: 0
========================
========================

Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s).

Spatial Flow
during placement
floorplan.
components.
Table 4-2 Pin Types

be moved

Fences: 0
Guides: 1
Regions: 0

Spatial Flow
Loading Generated PLE Data

➤ To load the encrypted customized PLE information for the design, use the following command:
decrypt PLE_file
Refer to Chapter 3, “Generating PLE Data,” for more information on howe to create this file.
A successful restoration will issue the following message:
PLE correlation data restored.
If the PLE model is stale, the tool will issue warnings indicating a possible number of reasons
why the model might not be valid. Check the header of the encrypted file for clues.
When you compare the PLE report (Figure 4-4) with the PLE report when no generated PLE
data are used (Figure 4-2 on page 53), you see that the Data source for the capacitance and
resistance values is no longer the cap_table_file, but user override, because the
values are based on trialRoute extraction.
Figure 4-4 Report PLE with generated PLE data

rc:/> report ple
============================================================
.......
============================================================
Aspect ratio : 0.98
Capacitance
Name Direction Utilization (pF/micron) user override
------------------------------------------------
<extracted> U n/a 0.000126
<extracted> V n/a 0.000128
<extracted> H n/a 0.000125
Resistance
Name Direction Utilization (ohm/micron) user override
-------------------------------------------------
Area
-------------------------------------------------
Metal1 H 1.00 0.230000
Metal2 V 1.00 0.280000
...
Metal6 V 1.00 0.440000

Spatial Flow
Synthesizing with Rapid Placement Input

After you have set the logical and physical constraints for your design, you can proceed with
synthesizing your design.
➤ To improve the modeling of the long wires and thus add more physical reality to the cost
functions used for optimization, use the following command:
sythesize -to_mapped -spatial
Important
You must have access to the Encounter® place and route tool to run this command
option.
This command performs a fast coarse-grained placement to get a better estimate of the long
wires.
For a verification-friendly flow, you can break up the synthesis steps as follows:
synthesize -to_generic
synthesize -to_mapped -no_incremental
synthesize -to_mapped -incremental
synthesize -to_mapped -spatial
synthesize -to_mapped -spatial -incremental

Spatial Flow

➤ To print an area report, use the report area command.
rc:/> report area
============================================================
Generated on: date
Module: DTMF_CHIP
library2
...
physical_cells
Interconnect mode: spatial
============================================================

----------------------------------------------------------------
DTMF_CHIP 6015 1224974 114094 1339068
IOPADS_INST 67 721450 139 721589
DTMF_INST 5948 503524 109532 613056
TDSP_CORE_INST 3827 87275 68331 155606
MPY_32_INST 1103 27330 17380 44709
M16X16_INST 817 23405 8335 31739
EXECUTE_INST 748 22217 7533 29750
ALU_32_INST 907 13083 10883 23966
DECODE_INST 175 5612 1164 6776
RAM_256x16_TEST_INST 18 113643 397 114040
RAM_128x16_TEST_INST 18 100792 130 100921
ARB_INST 25 69458 201 69659
SPI_INST 56 2475 959 3434
DMA_INST 63 1983 445 2427
TDSP_MUX 17 439 32 471
The Interconnect mode in the report header is now set to spatial because the design
was synthesized using fast placement information.
are based on the information in the LEF libraries. The Net Area refers to the estimated post-
route net area and is based on the minimum wire widths defined in the LEF and capacitance
table files and the area of the design blocks.

Spatial Flow
rc:/> report qor
============================================================
...
Interconnect mode: spatial
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0

--------------------------------------
default No paths 0
vclk01 No paths 0
vclk02 No paths 0
vclk1 -1890.3 -1890 1
vclk2 1061.8 0 0
---------------------------------------
Total -1890 1
Instance Count
--------------
Area & Power

------------
Cell Area 1224973.972

Min Fanout 0 (DTMF_INST/ULAW_LIN_CONV_INST/lpcm[13])
Average Fanout 2.6
Runtime 28 seconds
Hostname host

Spatial Flow
Note: Comparing the results with the results of the simple PLE flow, you may notice some
apparent degradation in some of the metrics. This degradation is to be expected since spatial
mode incorporates placement information, and thus more accurate wire lengths and delays
are used. Therefore, the results are a better indicator of the results that will be achieved once
you have performed place and route.


■ Netlist (.v)
■ DEF file (.def) —of the floorplan
■ Timing derate file (.derate.tcl) — generated when RTL Compiler changed the
default timing derate values
■ An encrypted file containing placement information (.spl.etf)
To reload this file, use the decrypt command.

Spatial Flow
Sample Script for Spatial Flow

set_attribute encounter_executable path_to_soc_executable
# set_attribute qrc_tech_file techfile.qrc /
elaborate DTMF_CHIP
report ple
read_sdc dtmf.sdc
#if using generated PLE data, add following two commands
# decrypt PLE_file
# report ple
synthesize -to_mapped -spatial
synthesize -to_mapped -spatial -incremental
report area
report qor
write_design -encounter

5
RC-Physical Flow
■ Attributes Affecting the RC-P Flow on page 66
❑ Setting up the RC-P Flow on page 68
❑ Loading the Encounter Configuration File on page 73
❑ Loading Generated PLE Data on page 78
❑ Synthesizing, Estimating, and Optimizing for Silicon on page 79
■ Sample Script for RC-P Flow on page 83

RC-Physical Flow
Overview
In addition to using technology information and cell areas from the LEF libraries, and parasitic
resistance and capacitance values from the LEF libraries or capacitance tables, the RC-P
flow uses a complete placement and considers congestion and legal placement as a cost
function during the RTL-to-gates phase, to create a better netlist. This flow ensures both the
best accuracy and the most predictable closure with back-end tools.
Specifically, the physical flow will:

■ Use physical process information along with areas and fanout to dynamically derive wire
length
■ Calculate load and delay using average resistance (in OHMs per micron) and
capacitance (in pF per micron) per unit length. The resistance and capacitance are
derived from the process technology information.
Alternatively, extracted resistance and capacitance parasitic information is used when
available.
■ Calculate wire area in microns using the average net width from the process technology
information
■ Perform physically-aware synthesis
This flow is useful for blocks or chips with complex floorplans.

RC-Physical Flow
Figure 5-1 RC-P Flow
Start
Target
libraries
LEF libraries Read LEF libraries

Capacitance
QRC tech
file

HDL files
design
Set synthesis mode


DEF file Read floorplan
SDC Change SDC constraints

Apply constraints
constraints
Load generated PLE data Using

generated
Check physical layout PLE data
No
Synthesize, estimate, and
optimize for silicon with Meet
synthesize -to_placed constraints?
Task added for
Physical
Analyze Yes
Perform incremental
Optional task optimization with
synthesize -to_placed
-incremental
Export design

RC-Physical Flow
Attributes Affecting the RC-P Flow

auto_super_thread root boolean true
congestion_avoid libcell boolean false
congestion_effort root string off
def_output_escape_multibit root boolean true
def_output_version root string 5.7
enc_assign_buffer root string none
enc_assign_removal root boolean false
enc_force_place_incr root boolean false
enc_gzip_interface_files root boolean true
enc_launch_servers root string
enc_module_plan root boolean true
enc_postload_script root string
enc_pre_place_opt root boolean false
enc_preexport_script root string
enc_preload_script root string
enc_scan_def_file root string
enc_temp_dir root string
enc_timing_driven_place root boolean true
enc_user_contsraint_file root string
enc_user_mode_file root string
encounter_executable root
init_core_utilization design float

RC-Physical Flow

physical_aware_mapping design boolean false
physical_aware_restructuring design boolean false
subdesign boolean false
physical_aware_structuring design boolean false
subdesign enumerated type inherited
phys_fix_multi_height_cells root boolean false
pqos_ignore_msv root boolean false
pqos_ignore_scan_chains root boolean false
pqos_placement_effort root string no_value
qos_report_power root boolean false
scale_of_cap_per_unit_length root float 1.0
scale_of_res_per_unit_length root float 1.0

RC-Physical Flow
Tasks
The tasks below list only those that are different from the generic synthesis flow or illustrate
a new step.
■ Setting up the RC-P Flow on page 68
■ Loading the Encounter Configuration File on page 73
■ Loading Generated PLE Data on page 78
■ Synthesizing, Estimating, and Optimizing for Silicon on page 79
Setting up the RC-P Flow

➤ To specify the Encounter executable that you want to use for the RC-P flow, set the
following root attribute:
set_attribute encounter_executable path_to_soc_executable /
If this attribute is not set, the following (default) search order is used:
1. ENCOUNTER environment variable
2. PATH environment variable
3. CDS_SYNTH_ROOT environment variable

RC-Physical Flow

In the RC-P flow, the cell area defined in the LEF libraries is used instead of the cell area
defined in the timing library (.lib).

tech.lef
cell.lef
■ EDGECAPACITANCE
■ SITE
■ WIDTH

RC-Physical Flow

RC-Physical Flow


to be consistent with Encounter. Only use a scaling factor if it will also be used in the
back-end.
■ BASIC_CAP_TABLE
■ width
■ Cc
■ Carea
■ Cfrg

RC-Physical Flow
Tip

You can skip this step if you are using generated PLE data.

with back-end tools
When you read in LEF libraries, the interconnect_mode attribute is automatically set to ple.

RC-Physical Flow
Do not change the setting for the RC-P flow.
Loading the Encounter Configuration File

The Encounter configuration file contains Tcl variables that describe design information such
as the RTL or netlist, technology libraries, LEF information, constraints, capacitance tables,
resistance scaling factors, capacitance scaling factors, and floorplan parameters.
Load the Encounter configuration file through the read_encounter command. If you load
an Encounter configuration file, the only other input you need to load is the DEF file (for the
floorplan).
rc:/> read_encounter config my_design.conf
Tip
If you load an Encounter configuration file, you do not need to load the timing library,
LEF library, capacitance table file, RTL or netlist, and constraints.
set_attribute library
set_attribute lef_library
set_attribute cap_table_file read_encounter config
read_hdl
read_sdc

report ple
The report header contains an Interconnect mode line which indicates that you are
running in PLE mode. In this case, the value is set to global because you run the report before
the design is synthesized.

RC-Physical Flow

rc:/> report ple
============================================================
Generated on: date
Module: DTMF_CHIP
library2
...
physical_cells
============================================================
Aspect ratio : 1.00

Capacitance
------------------------------------------------
M1 H 1.00 0.000274
M2 V 1.00 0.000242
M3 H 1.00 0.000242
M4 V 1.00 0.000242
M5 H 1.00 0.000242
M6 V 1.00 0.000304
Resistance
-------------------------------------------------
Metal1 H 1.00 0.439130
Metal2 V 1.00 0.360714
Metal3 H 1.00 0.360714
Metal4 V 1.00 0.360714
Metal5 H 1.00 0.360714
Metal6 V 1.00 0.102273
Area
-------------------------------------------------
Metal1 H 1.00 0.230000
Metal2 V 1.00 0.280000
Metal3 H 1.00 0.280000
Metal4 V 1.00 0.280000
Metal5 H 1.00 0.280000
Metal6 V 1.00 0.440000
rc:/>

RC-Physical Flow

Similar to providing timing and design constraints for the logic design, you must provide
physical constraints in the form of a floorplan in the physical flow.
In RTL Compiler, you provide floorplan information through a DEF file. DEF files can contain
both logical information and physical information.
■ Logical information includes grouping information and physical constraints
■ Physical information includes
❑ The die or block bounding box
The die determines the placement area and therefore influences the net length.
❑ Pin and macro locations
These influence the standard cell placement and thus the net length.
Parsing DEF file...
...
required. After reading the DEF you can view the floorplan in the GUI.
processed.

RC-Physical Flow

Summary report for DEF file ’/xxx/fplan_mp.def’
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Bump: 0
Placed: 0
Unplaced: 1
Pins
----
Cover: 0
Fixed: 0
Physical: 5
Placed: 0
Unplaced: 57
TOTAL: 62
Nets
----
Read: 0
Skipped: 0
TOTAL: 0
SpecialNets
-----------
Read: 2
Skipped: 0
TOTAL: 2
Fences: 0
Guides: 1
Regions: 0
========================
========================

Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s).

RC-Physical Flow
during placement
floorplan.
components.
Table 5-2 Pin Types

be moved

Fences: 0
Guides: 1
Regions: 0

RC-Physical Flow
Loading Generated PLE Data

➤ To load the encrypted customized PLE information for the design, use the following command:
decrypt PLE_file
Refer to Chapter 3, “Generating PLE Data,” for more information on howe to create the file. A
successful restoration will issue the following message:
PLE correlation data restored.
If the PLE model is stale, the tool will issue warnings indicating a possible number of reasons
why the model might not be valid. Check the header of the encrypted file for clues.
When you compare the PLE report (Figure 5-4) with the PLE report when no generated PLE
data are used (Figure 5-2 on page 74), you see that the Data source for the capacitance and
resistance values is no longer the cap_table_file, but user override, because the
values are based on trialRoute extraction.
Figure 5-4 Report PLE with generated PLE data

rc:/> report ple
============================================================
.......
============================================================
Aspect ratio : 0.98
Capacitance
Name Direction Utilization (pF/micron) user override
------------------------------------------------
Resistance
Name Direction Utilization (ohm/micron) user override
-------------------------------------------------
Area
-------------------------------------------------
Metal1 H 1.00 0.230000
Metal2 V 1.00 0.280000
...
Metal6 V 1.00 0.440000

RC-Physical Flow
Synthesizing, Estimating, and Optimizing for Silicon

After you have set the logical and physical constraints for your design, you can proceed with
synthesizing your design.
➤ To run physical-aware synthesis, use the following command:
The synthesize -to_placed command calls the Encounter® place and route tool to
create a good quality initial placement.
Important
You will need the RTL Compiler Advanced Physical Option (RC340) to execute the
command and to access an Encounter executable. It is highly recommended to use
the same version of Encounter as RTL Compiler, or at most one version older.
The synthesize -to_placed command will not work with encrypted netlists.Therefore,
decrypt your netlist before using this command.
For a verification-friendly flow, you can break up the synthesis steps as follows:
The tool generates several Encounter® interface files during the synthesize -to_placed
command. Files with the rc2enc prefix can be used to transfer data from RTL Compiler to
the Encounter® place and route tool. Files with the enc2rc prefix can be used to transfer
data from the Encounter place and route tool to RTL Compiler.
➤ Before you use the synthesize -to_placed command, set the following root
attribute to specify the directory where these files should be stored.
rc:/> set_attribute enc_temp_dir directory /
Tip
Setting this attribute prevents deletion of the directory. In case you encounter a
program failure, you can use these files to restore the session. For example,
source enc2rc.rc_setup.tcl
synthesize –to_placed –incremental

RC-Physical Flow

➤ To print an area report, use the report area report.
rc:/> report area
Computing net loads.
============================================================
Generated on: date
Module: DTMF_CHIP
library2
...
physical_cells
Interconnect mode: placement
============================================================

------------------------------------------------------------------
DTMF_CHIP 6099 1225633 128160 1353793
IOPADS_INST 67 721450 0 721450
DTMF_INST 6032 504183 118310 622493
TDSP_CORE_INST 3827 87275 65911 153185
MPY_32_INST 1103 27330 15057 42387
M16X16_INST 817 23405 6739 30143
EXECUTE_INST 748 22217 8052 30269
ALU_32_INST 907 13083 9116 22199
DECODE_INST 175 5612 973 6585
RAM_256x16_TEST_INST 18 113643 1118 114761
RAM_128x16_TEST_INST 18 100792 1222 102014
ARB_INST 25 69458 167 69625
SPI_INST 56 2475 915 3390
DMA_INST 63 1983 439 2422
TDSP_MUX 17 439 27 466
The Interconnect mode in the report header is now set to placement because the
design is synthesized using detailed placement information.
are based on the information in the LEF libraries. The Net Area refers to the estimated
post-route net area and is based on the minimum wire widths defined in the LEF and
capacitance table files and the area of the design blocks.

RC-Physical Flow
rc:/> report qor
============================================================
...
Interconnect mode: placement
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0

--------------------------------------
default No paths 0
vclk01 No paths 0
vclk02 No paths 0
vclk1 -2201.5 -2219 5
vclk2 1551.7 0 0
---------------------------------------
Total -2219 5
Instance Count
--------------
Area & Power

------------
Cell Area 1225632.599

Min Fanout 0 (DTMF_INST/ULAW_LIN_CONV_INST/lpcm[13])
Average Fanout 2.6
Runtime 58 seconds
Hostname host
Silicon Virtual Prototype

-------------------------
Total Net Length 484867.62 um
Average Net Length 78.00 um
Routing Congestion H: 0.87% V: 0.63%

RC-Physical Flow
Because you executed the synthesize -to_placed command, the QoR report also
contains a Silicon Virtual Prototype section that lists the total and average net length in
micron, and the routing congestion in %. Routing congestion is a measure of track overflow.


■ Netlist (.v)
■ DEF file (.def)
■ Timing derate file (.derate.tcl) — generated when RTL Compiler changed the default
timing derate values
■ Congestion map (.cmap.gz)
Note: The full DEF file that is generated is the exact same DEF file that was loaded or
generated by synthesize -to_placed. However, RTL Compiler generates the
information for the Scan DEF file (.scan.def). Although the scan chains will be re-ordered
in the back-end once the placement is determined, any scan reordering done in synthesis is
based on the current placement. This placement may not be carried forward. For example,
the placement will change if more optimization is done in RTL Compiler. There will always be
slight adjustments to the scan order, which are best accomplished in the back-end. The scan
DEF file is generated for continual convergence: getting closer to the final result with each
reordering.
Use the -basename option to specify both an output directory and a custom basename:
rc:/> write_design -encounter -basename output/final

RC-Physical Flow
Sample Script for RC-P Flow

set_attribute encounter_executable path_to_soc_executable
# set_attribute qrc_tech_file file /
elaborate DTMF_CHIP
report ple
read_sdc dtmf.sdc
#if using generated PLE data, add following two commands
# decrypt PLE_file
# report ple
set_attribute enc_temp_dir directory /
synthesize –to_placed –incremental
report area
report qor
write_design -encounter -base rcp_output

RC-Physical Flow

6
Structured Data Path
■ SDF File Syntax on page 87
❑ SDP File Skeleton on page 88
❑ alias Statement on page 88
❑ datapath Statement on page 88
❑ column Statement on page 89
❑ inst Statement on page 90
❑ row Statement on page 91
❑ SDP File Syntax Summary on page 92
■ SDP Information in the Design Information Hierarchy on page 93
❑ Row with several instances on page 94
■ SDP Flows on page 98

Overview
RTL Compiler with the RTL Compiler Advanced Physical Option allows you to specify
Structured Data Path (SDP) information to get better performance, power, and area.
You can specify the SDP information by importing an SDP relative placement file. Correct
SDP placement ensures uniform routing.
Use the SDP capability when:

■ The design is data path intensive
That is, the design contains standard cell columns and rows that require alignment
■ Performance increase is required
■ Time to market does not allow for full custom flow
Important
SDP is a semi-custom methodology that requires manual intervention so you need
to have detailed design knowledge in order to get better speed, power, and area.
The tool makes it easy for you to try different SDP experiments and evaluate their
impact on congestion, timing, and power. However, the tool still relies on the relative
placement information you specify for placing and handling SDP elements.
Benefits of Using SDP
SDP provides a uniform environment for data path and control logic for placement, routing,
and timing analysis.
SDP controls data path cell placement so that SDP cells are fixed before normal placement
for other standard cells.
The main advantage of this SDP placement is that it ensures uniform routing.

SDF File Syntax

This section describes the syntax of the SDP relative placement file.
Syntax Conventions
The list below describes the syntax conventions used in the SDP file statements.
literal or boldface Nonitalic words indicate keywords that you must type literally.
They can only be used in the places indicated by the syntax.
Keywords are case insensitive.
italic Words in italics indicate user-defined arguments for which you
must substitute a name or a value.
| Vertical bars (OR-bars) separate possible choices for a single
argument.
[ ] Brackets denote options. When used with OR-bars, they
enclose a list of choices from which you can choose one.
{ } Braces denote arguments and are used to indicate that a
choice is required from the list of arguments separated by OR-
bars. You must choose one from the list
{ argument1 | argument2 | argument3 }
Braces, used in Tcl command examples, indicate that the
braces must be typed in.
... Three dots (...) indicate that you can repeat the previous
argument. If the three dots are used with brackets (that is,
[argument]...), you can specify zero or more arguments. If
the three dots are used without brackets (argument...), you
must specify at least one argument, but can specify more.
{ } Braces in bold-face type must be entered literally.

SDP File Skeleton

[alias new_keyword predefined_keyword]...
datapath name {
[hierPath name]
[origin x y]
{row row {...} | column {...} }...
}...
The SDP file describes the relative placement of structured datapath elements in the design.
alias Statement
alias new_keyword predefined_keyword
Redefines a predefined keyword. You can redefine any predefined keyword. For a list of all
predefined keywords, see the words marked in bold in SDP File Syntax Summary.
datapath Statement
datapath name {
[hierPath name]
[origin x y]
{row row {...} | column {...} }.....
}...
Describes the relative placement of a data path structure. The file can have many datapath
statements, each describing the placement of one data path component. The placement is
described in terms of rows and columns that can be nested.
Descriptions
column {...} Describes one column in the relative placement.

hierPath name Specifies the hierarchical path name of the data path structure
in the design.
name Specifies the name of one data path structure.
origin x y Specifies the location of the database structure.
row {...} Describes one row in the relative placement.
Related Information
column Statement on page 89
row Statement on page 91

column Statement
column column {
[ orient {R0|R90|R180|R270|MX|MY|MY90|MX90}]
[ justifyBy {NW|SW|SE|NE|W|E|N|S|MID}]
[ flip {X| Y| XY}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| row row {...}]...
}
Describes one column in the relative placement of a data path structure. A column
statement can be specified many times in a datapath statement. As shown in the SDP File
Syntax Summary it can appear almost immediately after the datapath statement or it can
appear within a row statement.
A column can contain the following elements: empty spaces, instances or rows. These
elements will be placed in the column in the order they are specified in the column
statement.
Descriptions
column Specifies the name of the column.

flip {X | Y | XY} Specifies to flip the column (and its elements) around the X or Y
axis, or both.
Default: Y
justifyBy {SW|SE|NW|NE|N|W|S|E|MID}
Specifies the anchor point that will be used to align the column.
Default: SW
inst name Describes one instance in the column.
orient {R0|R90|R180|R270|MX|MY|MY90|MX90}
Specifies the orientation to be set for the column.
Default: R0
row {...} Describes one row in the column.
skipSpace Val Skips the specified number of spaces in the column.
Related Information
inst Statement on page 90

inst Statement
inst name
[orient {R0|R90|R180|R270|MX|MY|MY90|MX90}]
[justifyBy {NW|SW|SE|NE|W|E|N|S|MID}]
[flip {X| Y| XY}]
Describes an instance. An instance statement can be specified many times in a column

or row statement.
Descriptions
flip {X | Y | XY} Specifies to flip the instance around the X or Y axis, or both.
Default: Y
Specifies the anchor point that will be used to align the
instance.
Default: SW
name Specifies the name of the instance.
Specifies the orientation to be set for the instance.
Default: R0

row Statement
row row {
[ flip {X| Y| XY}]
[ skipSpace Val
| column column {...}]...
}
Describes one row in the relative placement of a data path structure. A row statement can
be specified many times in a datapath statement. As shown in the SDP File Syntax
Summary it can appear almost immediately after the datapath statement or it can appear
within a column statement.
A row can contain the following elements: empty spaces, instances or columns. These
elements will be placed in the row in the order they are specified in the row statement.
Descriptions
column Describes one column in the row.

flip {X | Y | XY} Specifies to flip the row (and its elements) around the X or Y
axis, or both.
Default: Y
Specifies the anchor point that will be used to align the row.
Default: SW
inst name Describes one instance in the row.
Specifies the orientation to be set for the row.
Default: R0
row Specifies the name of the row.
skipSpace Val Skips the specified number of spaces in the row.
Related Information
inst Statement on page 90

SDP File Syntax Summary

[alias new_keyword predefined_keyword]...
datapath name {
[hierPath name]
[origin x y]
row row {
[ flip {X| Y| XY}]
[ skipSpace Val
| column column {
[ orient {...}]
[ justifyBy {...}]
[ flip {...}]
[ skipSpace Val
| row row {
[ orient {R0|R90|..}]
[ flip {X| Y| XY}]
[ skipSpace Val
| colomn column {... }]...
}
}...
}...
}...
datapath name {
[hierPath name]
[origin x y]
column column {
[ orient {R0|R90|..}]
[ flip {X| Y| XY}]
[ skipSpace Val
| row row {
[ orient {...}]
[ justifyBy {...}]
[ flip {...}]
[ skipSpace Val
| column column {
[ orient {R0|R90|..}]
[ flip {X| Y| XY}]
[ skipSpace Val
| row row {... }]...
}
}...
}...
}...

SDP Information in the Design Information Hierarchy

RTL Compiler stores the original design data along with additional information in the SDP file
in the design information hierarchy in the form of attributes. Figure 6-1 highlights where the
information is stored in the design information hierarchy.
Figure 6-1 Design Information Hierarchy
(rc/>)
root
designs dex hdl_libraries libraries messages object_types
design
SDP
constants
cpf
dex_settings
dft
instances_comb
instances_hier
instances_seq
modes
nets
port_busses_in
port_busses_out
ports_in
ports_out sdp_instances
power sdp_columns sdp_colum sdp_rows •••

sdp_groups sdp_group
subdesigns sdp_rows sdp_row sdp_columns •••

timing sdp_instances

The design hierarchy has a directory for datapath components, columns, rows, and instances.
To represent spaces between rows, columns, and instances, the concept of dummy rows,
columns, and instances was introduced. For each row, column, or instance defined in the
SDP file a corresponding dummy is added:
■ skip_column_x
■ skip_row_x
■ skip_instance_x
Each dummy item has the same attributes as the corresponding actual items, but only two
attributes are relevant: index and skip_value. These attributes give an indication of the
position of the empty spaces and how many empty spaces there are. See the examples below
for more information.
Example 6-1 Row with several instances
SDP file
datapath my_row {
row adder {
justifyBy SW
inst inMux
inst inFF
inst leftShifter
inst rightShifter
inst outFF
inst outMux
}
}
Visual Representation

Representation in the hierarchy
/designs/test/sdp_groups/my_row/
/designs/test/sdp_groups/my_row/sdp_columns ;empty
/designs/test/sdp_groups/my_row/sdp_rows/
/designs/test/sdp_groups/my_row/sdp_rows/adder
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_columns ;empty
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/skip_instance_0
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/inFF
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/inMux
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/leftShifter
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/outFF
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/outMux
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/rightShifter
/designs/test/sdp_groups/my_row/sdp_rows/skip_row_0/
/designs/test/sdp_groups/my_row/sdp_rows/skip_row_0/sdp_columns ;empty
/designs/test/sdp_groups/my_row/sdp_rows/skip_row_0/sdp_instances ;empty
In this example, one actual row was created with 6 instances (shown in blue). The tool created
dummy entries for each of these actual SDP items (shown in red). Since the SDP file has no
skipSpace statements, the skip_value will be 0 for all the dummy entries.

Example 6-2 Columns nested in row
SDP file
datapath mydp {
row adder {
justifyBy SW
column inMux {
inst M0
inst M1
inst M2
}
column inFF {...}
skipSpace 2
column outFF {...}
column outMux {...}
}
}
Visual Representation

Representation in the hierarchy
/designs/test/sdp_groups/mydp
/designs/test/sdp_groups/mydp/sdp_columns ;empty
/designs/test/sdp_groups/mydp/sdp_rows
/designs/test/sdp_groups/mydp/sdp_rows/adder
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inFF
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inFF/sdp_instances/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inFF/sdp_rows/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_instances
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_instances/M0
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_instances/skip_instance_0
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_rows ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outFF
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outFF/sdp_instances/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outFF/sdp_rows/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outMux
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outMux/sdp_instances/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/outMux/sdp_rows/...
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_0
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_0/sdp_instances ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_0/sdp_rows ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_instances ;empty
/designs/test/sdp_groups/mydp/sdp_rows/skip_row_0
/designs/test/sdp_groups/mydp/sdp_rows/skip_row_0/sdp_colums ;empty
/designs/test/sdp_groups/mydp/sdp_rows/skip_row_0/sdp_instances ;empty
This example has one actual row with 4 columns (shown in blue). The first column has 3
instances. The dummy entries for each of these actual SDP items are shown in red. The SDP
file has one skipSpace statement, the skip_value will be 2 for skip_column_1.

SDP Flows
This section shows two flows using RC Physical and EDI:
■ The traditional SDP—Datapath SDP flow—for large SDP blocks in the design, shown in
Figure 6-2
■ The one pass FF Column SDP flow for small and medium-sized SDP blocks, shown in
Figure 6-3 on page 99
Both flows read in an SDP file which describes the relative placement of structured datapath
elements in the design.
➤ To read in a SDP relative placement file, use the read_sdp_file.
Figure 6-2 Datapath SDP Flow

Figure 6-3 One pass FF Column SDP Flow


A
Terminology
■ Abbreviations on page 102

■ Glossary on page 103

Terminology
Abbreviations
DEF Design Exchange Format

LEF Library Exchange Format
PLE Physical layout Estimation
R/C Resistance/Capacitance (parasitics)
RC-P Encounter RTL Compiler with Physical
SDC Synopsys Design Constraints
SPEF Standard Parasitic Exchange Format
SVP Silicon Virtual Prototype
WLM Wire Load Model

Terminology
Glossary
Term Origin Definition

BLOCKAGES DEF Prevent either placement or routing in the
specified area. Types are:
LAYER—prevent signal net routing
PLACEMENT—prevent placement. See also
SOFT, PARTIAL, and PUSHDOWN.
BUMP DEF Defines a solder bump on the chip.
Bumps are instantiated in the DEF
COMPONENTS section but not instantiated in
the netlist. Bump cells are usually placed with
+ COVER placement status.
CLASS DEF Defines the macro type. Examples are:
BLOCK—hierarchical block
CORE—standard cell, including memory cells
COVER—contains fixed floorplan data, such as
power routing
PAD—I/O cell
congestion tool Measures the routability of the design by
comparing the number of required tracks and
the number of available tracks.
density screen See PARTIAL
FENCE DEF Type of REGION that only allows instances
associated with the region to be placed in it.
FILL DEF Rectangular shape that defines a metal fill in
the design.
gcell One unit of the GCELLGRID.
GCELLGRID DEF Global routing grid whose cells enclose a
specified number of tracks
GROUPS DEF Defines a group of components (logical
elements) that are typically placed close
together.

Terminology
You can associate a REGION with a group. If

you do not associate a region with the group,
the group can be placed anywhere but the
instances in the group will be placed closely
together.
GUIDE DEF Type of REGION in which instances associated
with the region should be placed by preference.
Other instances can also be placed in this
region, and the instances associated with the
region can migrate outside the boundary of the
region.
HALO DEF Placement blockage around a component. This
type of blockage is associated with the
component. As a result a halo moves with the
component.
LAYER LEF Layer information.
MACRO LEF Physical description of a library cell.
morphing RC Congestion optimization technique that moves
cells from high utilization regions to low
utilization regions.
NETS DEF Defines the netlist connectivity for nets.
NONDEFAULTRULES DEF Nondefault rules used in this design that are not
specified in the LEF file.
OBS LEF Routing layer obstruction associated with a
MACRO.
PARTIAL (placement DEF Type of PLACEMENT blockage that allows a
blockage) percentage of the blockage area to be used for
standard cells during initial placement.
pcell Cell with a physical description that does not
appear in the RTL/netlist. Examples are filler
cells, antenna cells, feedthrough cells.
pdomain tool Physical information for a CPF power domain.
PIN DEF Defines the direction, layer, location, and size of
a signal or power connection point on a
MACRO.

Terminology
PITCH LEF Defines the distance between routing tracks in

the preferred direction for a given routing layer.
porosity tool Measure of unused space during initial
placement which allows for cell resizing and
new cell insertion during optimization.
process shrink Technique to create a new process by optically
shrinking the geometries from an existing
process.
PUSHDOWN DEF Type of PLACEMENT blockage created a
higher level in the hierarchy and pushed down
into the block.
REGION DEF Defines a location (physical area) for a GROUP.
By default, all instances in the group are placed
inside the predefined location, but other
instances can also be placed in this location.
You can further constrain a region by assigning
a type: choose between FENCE and GUIDE.
Rho capacitance resistivity table based on the width and spacing
table of the layer
ROW DEF Core rows in the core area of the design define
the legal placement locations for the standard
cells.
ShrinkFactor capacitance Factor used to model the process shrink
table technique.
SITE LEF Defines a placement site in the design
SOFT (placement DEF Type of PLACEMENT blockage that prevents
blockage) instances from being placed in the specified
area during initial placement.
SLOTS DEF Defines the rectangular shapes that are cut into
wide metal wires to prevent dishing.
SPACING LEF Specifies the minimum spacing allowed
between wires on the same layer, or between
two via cuts on the same net or on different
nets.

Terminology
SPECIALNETS DEF Describes the wiring of prerouted nets, such as

power and ground nets. These nets are not
touched by the automatic router.
steiner tree An algorithm to find the shortest interconnect
for a given set of objects. Given a set V of points
(vertices), "steiner tree" interconnects them by
a network (graph) of the shortest length, where
the length is the sum of the lengths of all edges.
STYLES DEF A style polygon defines a wire's outer boundary.
TRACKS DEF Predefined routing resources that define the
routing grid.
utilization tool Percentage of available placement area filled
with placed instances. High utilization can lead
to congestion. Low utilization can lead to long
wires and need for buffering.
VIAS DEF Describes fixed vias and generated vias.
■ A fixed via is defined using rectangles or
polygons, and does not use a VIARULE.
■ A generated via is defined using VIARULE
parameters that are derived from a
VIARULE GENERATE statement in the LEF
file.
All vias consist of shapes on three layers: a cut
layer and two routing layers that connect
through the cut layer.

Index
A S
attributes scripts
cap_table_file 30, 50, 71 RC-P flow 83
def_file 36, 56, 77 simple PLE flow 40
encounter_executable 48, 68 spatial flow 62
interconnect_mode 33, 52, 72 SDF file
lef_library 28, 49, 69 syntax 87
lib_lef_consistency_check_enable 29, SDP file
50, 70 reading in 98
qrc_tech_file 30, 50, 71
read_def 54
C
cells
reporting cell count 37, 59, 80
commands
read_def 34, 54, 75
read_encounter 73
read_sdp_file 98
report area 37, 59, 80
report ple 31, 52, 73
report qor 38, 60, 81
synthesize -to_placed 79
sythesize -spatial 58
write_design -encounter 61
write_design encounter 39, 82
D
design information hierarchy
physical information 22
SDP information 93
P
physical information
in design hierarchy 22



Cadence Design With RTL Compiler Physical PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cadence Design With RTL Compiler Physical PDF

Uploaded by

Copyright:

Available Formats

Design with RTL Compiler Physical

Product Version 13.1

November 2013 3 Product Version 13.1

Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

November 2013 4 Product Version 13.1

November 2013 5 Product Version 13.1

November 2013 6 Product Version 13.1

■ About This Manual on page 8

November 2013 7 Product Version 13.1

About This Manual

November 2013 8 Product Version 13.1

How to Use the Documentation Set

Cadence Installation Guide

Known Problems and Solutions in

Getting Started with Encounter

Using Encounter RTL Compiler

TASKS AND CONCEPTS

November 2013 9 Product Version 13.1

Reporting Problems or Errors in Manuals

Contact Cadence Customer Support to file a PCR if you find:

November 2013 10 Product Version 13.1

Cadence Online Support

For more information on Cadence online support go to:

Other Support Offerings

For more information on these support offerings go to:

November 2013 11 Product Version 13.1

November 2013 12 Product Version 13.1

November 2013 13 Product Version 13.1

Getting the Syntax for a Command

This returns the syntax for the path_delay command.

Getting the Syntax for an Attribute

This returns the syntax for the max_transition attribute.

November 2013 14 Product Version 13.1

Searching for Attributes

Searching For Commands When You Are Unsure of the Name

This returns the following commands:

This returns the following commands:

November 2013 15 Product Version 13.1

Text Command Syntax

literal Nonitalic words indicate keywords you enter literally. These

November 2013 16 Product Version 13.1

■ Using Physical Information in Synthesis on page 18

November 2013 17 Product Version 13.1

Using Physical Information in Synthesis

Table 1-1 PLE versus WLM

Physical Layout Estimation (PLE) Wire-load Models (WLM)

November 2013 18 Product Version 13.1

Flows, and Product and License Requirements

November 2013 19 Product Version 13.1

Special Files for Physical Flows

Figure 1-1 Physical Information Files

SDC Gate-Level Encounter

The following file is required for the three physical-related flows.

November 2013 20 Product Version 13.1

November 2013 21 Product Version 13.1

Physical Information in the Design Information Hierarchy

Figure 1-2 Design Information Hierarchy

designs messages object_types libraries hdl_libraries

design_name ENC library_name

physical layers wireload_models

November 2013 22 Product Version 13.1

November 2013 23 Product Version 13.1

November 2013 24 Product Version 13.1