Cadence Design With RTL Compiler Physical PDF
Cadence Design With RTL Compiler Physical PDF
Cadence Design With RTL Compiler Physical PDF
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
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
Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . 51
Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . 52
Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Synthesizing with Rapid Placement Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
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
Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . 72
Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Loading the Encounter Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . 73
Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Synthesizing, Estimating, and Optimizing for Silicon . . . . . . . . . . . . . . . . . . . . . . . . . 79
Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
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
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.
README File
README File
NEW FEATURES AND
SOLUTIONS TO PROBLEMS
What’s New in Encounter RTL
Compiler
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
Customer Support
Cadence offers live and online support, as well as customer education and training programs.
http://support.cadence.com
http://www.cadence.com/support
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:
[email protected]
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
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:
[email protected]
For example:
rc:/> help path_delay
For example:
rc:/> get_attribute max_transition * -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
■ 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>
Documentation Conventions
1
Introduction
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.
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.
Encounter
DEF Synthesis RTL Configuration Constraint
Floorplan Libraries Files File File
File
RTL Compiler
LEF Capacitance
Libraries Table File
Files added
for physical
Optional file
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
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.
(rc/>)
root
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
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.
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
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.
Start
Target
Read timing libraries
libraries
LEF
Read LEF libraries
libraries
Capacitance
file Load parasitic information
QRC tech
file
Synthesize No
Export design
Optional task Yes
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
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).
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}
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
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
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 /
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.
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.
RTL Compiler reports the inconsistencies in the log file. You should review the log file. For
example, check for messages PHYS 24 through 27.
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.
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
Layer / Length Data source:
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
Layer / Length Data source:
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:/>
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.
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.
Warning : A DEF component does not exist in the netlist. [PHYS-171]
: 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.
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Placed: 0
Unplaced: 1
TOTAL: 72 (1 is class macro)
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
========================
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.
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
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.
➤ 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
============================================================
Generated by: Encounter(R) RTL Compiler version
...
Interconnect mode: global
Area mode: physical library
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0
Instance Count
--------------
Leaf Instance Count 4969
Sequential Instance Count 546
Combinational Instance Count 4423
Hierarchical Instance Count 26
Since you performed physical synthesis and started with a floorplan, the report also contains
the floorplan utilization in %.
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
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 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
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.
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
■ Overview on page 46
■ Attributes Affecting the Spatial Flow on page 47
■ Tasks on page 48
❑ Setting up the Spatial Flow on page 48
❑ Reading the LEF Libraries on page 49
❑ Loading the Parasitic Information on page 50
❑ Reviewing Consistency Between the LEF and Parasitic Files on page 51
❑ Setting the Appropriate Synthesis Mode on page 52
❑ Checking the Physical Layout Estimation Information on page 52
❑ Reading the Floorplan on page 54
❑ Loading Generated PLE Data on page 57
❑ Synthesizing with Rapid Placement Input on page 58
❑ Analyzing the Results on page 59
❑ Exporting Files for Place and Route on page 61
■ Sample Script for Spatial Flow on page 62
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
Read timing libraries
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
■ Reading the LEF Libraries on page 49
■ Loading the Parasitic Information on page 50
■ Reviewing Consistency Between the LEF and Parasitic Files on page 51
■ Setting the Appropriate Synthesis Mode on page 52
■ Checking the Physical Layout Estimation Information on page 52
■ Reading the Floorplan on page 54
■ Loading Generated PLE Data on page 57
■ Synthesizing with Rapid Placement Input on page 58
■ Analyzing the Results on page 59
■ Exporting Files for Place and Route on page 61
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
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).
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}
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
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
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 /
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.
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.
■ 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.
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.
As shown in Figure 4-2 on page 53, 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 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.
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
Layer / Length Data source:
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
Layer / Length Data source:
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:/>
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.
Warning : A DEF component does not exist in the netlist. [PHYS-171]
: 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 4-3 on page 55 shows an example of DEF statistics printed after the DEF file has been
processed.
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Bump: 0
Placed: 0
Unplaced: 1
TOTAL: 72 (1 is class macro)
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
========================
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.
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
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.
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
The Interconnect mode in the report header is now set to spatial because the design
was synthesized using fast 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.
➤ 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
============================================================
Generated by: Encounter(R) RTL Compiler version
...
Interconnect mode: spatial
Area mode: physical library
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0
Instance Count
--------------
Leaf Instance Count 6015
Sequential Instance Count 546
Combinational Instance Count 5469
Hierarchical Instance Count 26
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.
5
RC-Physical Flow
■ Overview on page 64
■ Attributes Affecting the RC-P Flow on page 66
■ Tasks on page 68
❑ Setting up the RC-P Flow on page 68
❑ Reading the LEF Libraries on page 69
❑ Loading the Parasitic Information on page 71
❑ Reviewing Consistency Between the LEF and Parasitic Files on page 72
❑ Setting the Appropriate Synthesis Mode on page 72
❑ Loading the Encounter Configuration File on page 73
❑ Checking the Physical Layout Estimation Information on page 73
❑ Reading the Floorplan on page 75
❑ Loading Generated PLE Data on page 78
❑ Synthesizing, Estimating, and Optimizing for Silicon on page 79
❑ Analyzing the Results on page 80
❑ Exporting Files for Place and Route on page 82
■ Sample Script for RC-P Flow on page 83
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.
Start
Target
libraries
Read timing libraries
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
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
■ Reading the LEF Libraries on page 69
■ Loading the Parasitic Information on page 71
■ Reviewing Consistency Between the LEF and Parasitic Files on page 72
■ Setting the Appropriate Synthesis Mode on page 72
■ Loading the Encounter Configuration File on page 73
■ Checking the Physical Layout Estimation Information on page 73
■ Reading the Floorplan on page 75
■ Loading Generated PLE Data on page 78
■ Synthesizing, Estimating, and Optimizing for Silicon on page 79
■ Analyzing the Results on page 80
■ Exporting Files for Place and Route on page 82
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
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).
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}
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 /
RTL Compiler supports LEF 5.3 and above. Refer to the LEF/DEF Language Reference
for more information on LEF files.
Troubleshooting Tips
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
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 /
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.
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.
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.
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.
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.
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
As shown in Figure 5-2 on page 74, 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 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.
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
Layer / Length Data source:
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
Layer / Length Data source:
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:/>
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.
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.
Warning : A DEF component does not exist in the netlist. [PHYS-171]
: 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. After reading the DEF you can view the floorplan in the GUI.
Figure 5-3 on page 76 shows an example of DEF statistics printed after the DEF file has been
processed.
Components
----------
Cover: 0
Fixed: 71
Physical: 0
Bump: 0
Placed: 0
Unplaced: 1
TOTAL: 72 (1 is class macro)
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
========================
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.
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
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.
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:
synthesize -to_generic
synthesize -to_mapped -no_incremental
synthesize -to_mapped -incremental
synthesize -to_placed
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
The Interconnect mode in the report header is now set to placement because the
design is synthesized using detailed 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.
➤ 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
============================================================
Generated by: Encounter(R) RTL Compiler version
...
Interconnect mode: placement
Area mode: physical library
============================================================
Timing
--------
Clock Period
--------------
vclk01 5000.0
vclk02 6000.0
vclk1 5000.0
vclk2 5000.0
Instance Count
--------------
Leaf Instance Count 6099
Sequential Instance Count 546
Combinational Instance Count 5553
Hierarchical Instance Count 26
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.
Use the -basename option to specify both an output directory and a custom basename:
rc:/> write_design -encounter -basename output/final
6
Structured Data Path
■ Overview on page 86
■ 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.
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.
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.
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.
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
Related Information
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
Related Information
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}]
Descriptions
flip {X | Y | XY} Specifies to flip the instance 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
instance.
Default: SW
name Specifies the name of the instance.
orient {R0|R90|R180|R270|MX|MY|MY90|MX90}
Specifies the orientation to be set for the instance.
Default: R0
row Statement
row row {
[ 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 {...}]
| 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
Related Information
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| column column {
[ orient {...}]
[ justifyBy {...}]
[ flip {...}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| row row {
[ orient {R0|R90|..}]
[ justifyBy {NW|SW|SE|NE|W|E|N|S|MID}]
[ flip {X| Y| XY}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| colomn column {... }]...
}
}...
}...
}...
datapath name {
[hierPath name]
[origin x y]
column column {
[ orient {R0|R90|..}]
[ justifyBy {NW|SW|SE|NE|W|E|N|S|MID}]
[ flip {X| Y| XY}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| row row {
[ orient {...}]
[ justifyBy {...}]
[ flip {...}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| column column {
[ orient {R0|R90|..}]
[ justifyBy {NW|SW|SE|NE|W|E|N|S|MID}]
[ flip {X| Y| XY}]
[ skipSpace Val
| inst name [orient {...}] [justifyBy {...}] [flip {...}]
| row row {... }]...
}
}...
}...
}...
(rc/>)
root
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
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.
SDP file
datapath my_row {
row adder {
justifyBy SW
inst inMux
inst inFF
inst leftShifter
inst rightShifter
inst outFF
inst outMux
}
}
Visual Representation
/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/skip_instance_1
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/skip_instance_2
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/skip_instance_3
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/skip_instance_4
/designs/test/sdp_groups/my_row/sdp_rows/adder/sdp_instances/skip_instance_5
/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.
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
/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/M1
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_instances/M2
/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_instances/skip_instance_1
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/inMux/sdp_instances/skip_instance_2
/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_columns/skip_column_1
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_1/sdp_instances ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_1/sdp_rows ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_2
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_2/sdp_instances ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_2/sdp_rows ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_3
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_3/sdp_instances ;empty
/designs/test/sdp_groups/mydp/sdp_rows/adder/sdp_columns/skip_column_3/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.
A
Terminology
Abbreviations
Glossary
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