RC Phys

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 Cadences 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Physical Information in Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flows, and Product and License Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Files for Physical Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Information in the Design Information Hierarchy . . . . . . . . . . . . . . . . . . . . . . . .
17 18 19 20 22
2 Simple PLE Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Attributes Affecting the PLE Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
November 2013 1999-2013
Product Version 13.1 All Rights Reserved.
Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample Script for Simple PLE Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28 30 31 31 33 34 37 39 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 46 47 48 48 49 50 51 52 52 54 57 58 59 61 62
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributes Affecting the Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up the Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synthesizing with Rapid Placement Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample Script for Spatial Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
November 2013 1999-2013
5 RC-Physical Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributes Affecting the RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up the RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading the LEF Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the Parasitic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing Consistency Between the LEF and Parasitic Files . . . . . . . . . . . . . . . . . . Setting the Appropriate Synthesis Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the Encounter Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking the Physical Layout Estimation Information . . . . . . . . . . . . . . . . . . . . . . . . Reading the Floorplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Generated PLE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synthesizing, Estimating, and Optimizing for Silicon . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Files for Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample Script for RC-P Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63 64 66 68 68 69 71 72 72 73 73 75 78 79 80 82 83
6 Structured Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDF File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDP File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alias Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . datapath Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . column Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . inst Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . row Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDP File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDP Information in the Design Information Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . SDP Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85 86 87 87 88 88 88 89 90 91 92 93 98
November 2013 1999-2013
A Terminology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
November 2013 1999-2013
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
November 2013 1999-2013
Design with RTL Compiler Physical 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.
November 2013 1999-2013
How to Use the Documentation Set

Cadence Installation Guide Cadence License Manager README File
INSTALLATION AND CONFIGURATION
README File Whats New in Encounter RTL Compiler Known Problems and Solutions in Encounter RTL Compiler
NEW FEATURES AND SOLUTIONS TO PROBLEMS
Getting Started with Encounter RTL Compiler
Using Encounter RTL Compiler
TASKS AND CONCEPTS

HDL Modeling in Encounter RTL Compiler ChipWare Developer in Encounter RTL Compiler Library Guide for Encounter RTL Compiler
Datapath Synthesis in Encounter RTL Compiler
Setting Constraints and Performing Timing Analysis in Encounter RTL Compiler
Low Power in Encounter RTL Compiler
Design for Test in Encounter RTL Compiler
REFERENCES
Attribute Reference for Encounter RTL Compiler
Command Reference for Encounter RTL Compiler
ChipWare in Encounter RTL Compiler
GUI Guide for Encounter RTL Compiler
Quick Reference for Encounter RTL Compiler
November 2013 1999-2013
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
November 2013 1999-2013
10
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 servicesOffers 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
November 2013 1999-2013
11
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
November 2013 1999-2013
12
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
November 2013 1999-2013
13
Command-Line Help
You can get quick syntax help for commands and attributes at the RTL Compiler commandline 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.
November 2013 1999-2013
14
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
November 2013 1999-2013
15
Documentation Conventions
Text Command Syntax
The list below defines the syntax conventions used for the RTL Compiler text interface commands. literal arguments and options | [] Nonitalic words indicate keywords you enter literally. These keywords represent command or option names. Words in italics indicate user-defined arguments or information for which you must substitute a name or a value. Vertical bars (OR-bars) separate possible choices for a single argument. Brackets indicate optional arguments. When used with ORbars, 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.
{}
November 2013 1999-2013
16
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
November 2013 1999-2013
17
Design with RTL Compiler Physical 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 wireload 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 wireload 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) Uses actual design and physical library information. Dynamically calculates wire delays for different logic structures in the design. Wire-load Models (WLM) Wire-load models are statistical. Wire-load models are calculated based on 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 wireload models.
November 2013 1999-2013
18
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.
November 2013 1999-2013
19
Special Files for Physical Flows

Figure1-1 shows the data flow for the physical flows. Figure 1-1 Physical Information Files
DEF Floorplan File
Synthesis Libraries
RTL Files
Encounter Configuration File
Constraint File
RTL Compiler
LEF Libraries Capacitance Table File
SDC Constraints
DEF File
Gate-Level Netlist Files
Encounter Database
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
November 2013 1999-2013
20
Design with RTL Compiler Physical 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.
November 2013 1999-2013
21
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 design_name constants dft instances_comb instances_hier instances_seq nets physical port_busses_in port_busses_out ports_in ports_out subdesigns timing messages
ENC PHYS PLC
object_types
libraries
hdl_libraries
library_name operating_conditions wireload_models wireload_selections
blockages bumps defpins fills gcells groups layers fills nondefaultrules pcells pdomains pnets regions rows sites slots specialnets styles tracks vias
libcells physical_cells operating_conditions wireload_models wireload_selections libcells
November 2013 1999-2013
22
Design with RTL Compiler Physical 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.
November 2013 1999-2013
23
Design with RTL Compiler Physical 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.
November 2013 1999-2013
24
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
November 2013 1999-2013
25
Design with RTL Compiler Physical 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 libraries LEF libraries Capacitance file QRC tech file Read timing libraries
Read LEF libraries
Load parasitic information
Review consistency between LEF and parasitic files HDL files Read HDL files and elaborate design Check physical layout estimation information Set synthesis mode DEF file SDC constraints Change physical constraints Read floorplan Change SDC constraints Apply constraints Synthesize Task added for Physical Analyze Export design No Meet constraints? Yes Modify source
Optional task
November 2013 1999-2013
26
Attributes Affecting the PLE Flow

Attribute Name aspect_ratio cap_table_file interconnect_mode lef_library lef_stop_on_error lib_lef_consistency_check_enable number_of_routing_layers phys_ignore_nets phys_ignore_special_nets qrc_tech_file shrink_factor use_area_from_lef utilization Object design root root root root root design design design root root root layer Type float string string string boolean boolean integer boolean boolean string float boolean float true false false false true wireload Default 1.0
November 2013 1999-2013
27
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}
November 2013 1999-2013
28
Design with RTL Compiler Physical 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
November 2013 1999-2013
29
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 backend. 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.
November 2013 1999-2013 30 Product Version 13.1 All Rights Reserved.
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.
November 2013 1999-2013
31
Design with RTL Compiler Physical 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 Shrink factor Scale of res/length Scale of cap/length Net derating factor Site size : : : : : : 1.00 1.00 1.00 1.00 1.00 5.70 um (from lef [tech+cell]) Data source: cap_table_file
Capacitance Layer / Length Name Direction Utilization (pF/micron) -----------------------------------------------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 Name Direction Utilization (ohm/micron) ------------------------------------------------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 Name Direction Utilization (micron) ------------------------------------------------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:/>
Data source: lef_library
November 2013 1999-2013
32
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.
November 2013 1999-2013
33
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. 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.
November 2013 1999-2013
34
Design with RTL Compiler Physical 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 4 / 4 71 / 0 I W I PHYS-154 PHYS-171 PHYS-181 Creating physical pin. Component not present in netlist. Full preserve set on instance.
Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s)..
November 2013 1999-2013
35
Design with RTL Compiler Physical Simple PLE Flow Table 2-1 Component Types
Type Cover Explanation Tip
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. 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 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. A component that has a location and that can be These components are not expected in a moved by automatic tools. floorplan. A component that has no location. These components are not expected in a floorplan. The number of class macros should be less than or equal to the number of fixed components.
Fixed
Physical Placed Unplaced
class macro A large component. For example, a memory.
Table 2-2 Pin Types

Type Cover Explanation A pin that has a location, orientation, and that is part of the cover macro. A COVER pin cannot be moved A pin that has a location, orientation and that cannot be moved by automatic tools. A pin that has a location, orientation and that can be moved by automatic tools. A pin that has no location. It is recommended to have all pins fixed. Tip
Fixed Placed Unplaced
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
November 2013 1999-2013
36
Analyzing the Results
To print an area report, use the report area command.

rc:/> report area ============================================================ 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 ============================================================ 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 postroute 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.
November 2013 1999-2013
37
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 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 Sequential Instance Count Combinational Instance Count Hierarchical Instance Count Area & Power -----------Total Area Cell Area Floorplan Utilization Leakage Power Dynamic Power Total Power Max Fanout Min Fanout Average Fanout Terms to net ratio Terms to instance ratio Runtime Hostname
4969 546 4423 26
1293018.485 1218397.679 36.45% 4480.258 nW 247756070.964 nW 247760551.222 nW 540 (scan_enI) 0 (n_3) 2.5 3.5 3.9 77 seconds host
Since you performed physical synthesis and started with a floorplan, the report also contains the floorplan utilization in %.
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
November 2013 1999-2013
39
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
November 2013 1999-2013
40
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
November 2013 1999-2013
41
Design with RTL Compiler Physical 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.
November 2013 1999-2013
42
Generating the PLE Data

At the start of the synthesis process, use the following flow to generate the PLE data.
set_attribute lib_search_path path / 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.
November 2013 1999-2013
43
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.
November 2013 1999-2013
44
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
November 2013 1999-2013
45
Design with RTL Compiler Physical 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 Capacitance file QRC tech file
Read timing libraries Read LEF libraries Load parasitic information Review consistency between LEF and parasitic files Read HDL files and elaborate design Set synthesis mode Check physical layout estimation information
Modify source
HDL files
DEF file SDC constraints
Read floorplan Apply constraints
Change physical constraints Change SDC constraints
Load generated PLE data Check physical layout estimation information
Using generated PLE data
Task added for Physical Optional task
Synthesize with rapid placement input Analyze Export design
No
Meet constraints?
Yes
November 2013 1999-2013
46
Attributes Affecting the Spatial Flow
Attribute Name aspect_ratio cap_table_file encounter_executable init_core_utilization interconnect_mode lef_library lef_stop_on_error lib_lef_consistency_check_enable number_of_routing_layers phys_ignore_nets phys_ignore_special_nets pqos_ignore_msv pqos_ignore_scan_chains qos_report_power qrc_tech_file scale_of_cap_per_unit_length scale_of_res_per_unit_length shrink_factor use_area_from_lef utilization
Object design root root design root root root root design design design root root root root root root root root layer
Type float string
Default 1.0
float string string boolean boolean integer boolean boolean boolean boolean boolean string float float float boolean float true 1.0 1.0 false false false false false false true wireload
November 2013 1999-2013
47
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
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
November 2013 1999-2013
48

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 spatial 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

Use the get_attribute command to confirm the list of imported LEF files:

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
Design with RTL Compiler Physical Spatial Flow synthesis) and a warning message will be issued. To turn off this consistency checking, set the lib_lef_consistency_check_enable attribute to 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.



Note: If you specify both a capacitance table file and a QRC technology file, the QRC technology file takes precedence.
November 2013 1999-2013
50
Design with RTL Compiler Physical Spatial Flow 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 backend. RTL Compiler will check if the following information is available in the parasitic file:

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.
November 2013 1999-2013
51


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.

report ple
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.
November 2013 1999-2013
52
Design with RTL Compiler Physical Spatial Flow Figure 4-2 Example of Report PLE
November 2013 1999-2013
53

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.

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.
November 2013 1999-2013
54
Design with RTL Compiler Physical Spatial Flow Figure 4-3 Example of DEF Statistics
Summary report for DEF file /xxx/fplan_mp.def Components ---------Cover: 0 Fixed: 71 Physical: 0 Bump: 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 4 / 4 71 / 0 I W I PHYS-154 PHYS-171 PHYS-181 Creating physical pin. Component not present in netlist. Full preserve set on instance.
Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s).
November 2013 1999-2013
55
Design with RTL Compiler Physical Spatial Flow Table 4-1 Component Types
Fixed
Table 4-2 Pin Types


November 2013 1999-2013
56
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 ============================================================ ....... Interconnect mode: global Area mode: physical library ============================================================ Aspect ratio Shrink factor Scale of res/length Scale of cap/length Net derating factor Site size : : : : : : 0.98 1.00 1.00 1.00 1.00 5.70 um (from lef [tech+cell]) Data source: user override
Capacitance Layer / Length Name Direction Utilization (pF/micron) -----------------------------------------------<extracted> U n/a 0.000126 <extracted> V n/a 0.000128 <extracted> H n/a 0.000125 Resistance Layer / Length Name Direction Utilization (ohm/micron) ------------------------------------------------<extracted> U n/a 0.353355 <extracted> V n/a 0.353355 <extracted> H n/a 0.353355 Area Layer / Length Name Direction Utilization (micron) ------------------------------------------------Metal1 H 1.00 0.230000 Metal2 V 1.00 0.280000 ... Metal6 V 1.00 0.440000
Data source: user override
November 2013 1999-2013
57
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
November 2013 1999-2013
58
To print an area report, use the report area command.
rc:/> report area ============================================================ Generated by: Encounter(R) RTL Compiler version Generated on: date Module: DTMF_CHIP Technology libraries: library1 library2 ... physical_cells Operating conditions: slow Interconnect mode: spatial Area mode: physical library ============================================================ Instance Cells Cell Area Net Area Total Area ---------------------------------------------------------------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 TDSP_CORE_GLUE_INST 550 8516 7328 15843 DECODE_INST 175 5612 1164 6776 PORT_BUS_MACH_INST 93 2921 705 3626 DATA_BUS_MACH_INST 96 2974 558 3532 PROG_BUS_MACH_INST 76 2791 452 3243 TDSP_CORE_MACH_INST 49 1364 389 1753 ACCUM_STAT_INST 22 363 143 506 RAM_256x16_TEST_INST 18 113643 397 114040 RAM_128x16_TEST_INST 18 100792 130 100921 ARB_INST 25 69458 201 69659 RESULTS_CONV_INST 1756 40143 25149 65292 SPI_INST 56 2475 959 3434 DMA_INST 63 1983 445 2427 ULAW_LIN_CONV_INST 86 1201 746 1947 DATA_SAMPLE_MUX_INST 27 662 290 952 DIGIT_REG_INST 12 738 78 817 TDSP_DS_CS_INST 35 542 118 660 TDSP_MUX 17 439 32 471 TEST_CONTROL_INST 6 160 0 160
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 postroute 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.
November 2013 1999-2013
59
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 Cost Critical Violating Group Path Slack TNS Paths -------------------------------------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 -------------Leaf Instance Count Sequential Instance Count Combinational Instance Count Hierarchical Instance Count Area & Power -----------Total Area Cell Area Floorplan Utilization Leakage Power Dynamic Power Total Power Max Fanout Min Fanout Average Fanout Terms to net ratio Terms to instance ratio Runtime Hostname 1339067.505 1224973.972 30.96% 4486.729 nW 242947906.974 nW 242952393.703 nW 540 (scan_enI) 0 (DTMF_INST/ULAW_LIN_CONV_INST/lpcm[13]) 2.6 3.6 3.9 28 seconds host
6015 546 5469 26
November 2013 1999-2013
60
Design with RTL Compiler Physical 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) Encounter configuration file (.conf), SDC constraints (.sdc) Tcl script (.enc_setup.tcl) Mode file (.mode) 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.
November 2013 1999-2013
61
Sample Script for Spatial Flow

set_attribute source_verbose true / set_attribute information_level 9 / suppress_message "xxx " set_attribute encounter_executable path_to_soc_executable 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 #if using generated PLE data, add following two commands # decrypt PLE_file # report ple synthesize -to_generic synthesize -to_mapped -no_incremental synthesize -to_mapped -incremental synthesize -to_mapped -spatial synthesize -to_mapped -spatial -incremental report area report qor write_design -encounter
November 2013 1999-2013
62
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
November 2013 1999-2013
63
Design with RTL Compiler Physical 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.
November 2013 1999-2013
64
Design with RTL Compiler Physical RC-Physical Flow Figure 5-1 RC-P Flow
Start
Target libraries LEF libraries Capacitance file QRC tech file
Read timing libraries Read LEF libraries Load parasitic information Review consistency between LEF and parasitic files Read HDL files and elaborate design Set synthesis mode Check physical layout estimation information
Modify source
HDL files
DEF file SDC constraints
Read floorplan Apply constraints
Change physical constraints Change SDC constraints
Load generated PLE data Check physical layout estimation information
Using generated PLE data
No Synthesize, estimate, and optimize for silicon with synthesize -to_placed Analyze Perform incremental optimization with synthesize -to_placed -incremental Export design Meet constraints? Yes
Task added for Physical
Optional task
November 2013 1999-2013
65
Attributes Affecting the RC-P Flow
Attribute Name aspect_ratio auto_super_thread cap_table_file congestion_avoid congestion_effort def_output_escape_multibit def_output_version enc_assign_buffer enc_assign_removal enc_force_place_incr enc_gzip_interface_files enc_launch_servers enc_module_plan enc_postload_script enc_pre_place_opt enc_preexport_script enc_preload_script enc_scan_def_file enc_temp_dir enc_timing_driven_place enc_user_contsraint_file enc_user_mode_file encounter_executable init_core_utilization interconnect_mode
November 2013 1999-2013
Object design root root libcell root root root root root root root root root root root root root root root root root root root design root
66
Type float boolean string boolean string boolean string string boolean boolean boolean string boolean string boolean string string string string boolean string string
Default 1.0 true
false off true 5.7 none false false true
true
false
true
float string wireload

Attribute Name lef_library lef_stop_on_error lib_lef_consistency_check_enable number_of_routing_layers physical_aware_mapping physical_aware_restructuring
Object root root root design design design subdesign
Type string boolean boolean integer boolean boolean boolean boolean
Default
false true
false false false false
physical_aware_structuring
design subdesign
enumerated type inherited boolean boolean boolean boolean boolean string boolean string float float float boolean float true 1.0 1.0 false false false false false no_value false
phys_fix_multi_height_cells phys_ignore_nets phys_ignore_special_nets pqos_ignore_msv pqos_ignore_scan_chains pqos_placement_effort qos_report_power qrc_tech_file scale_of_cap_per_unit_length scale_of_res_per_unit_length shrink_factor use_area_from_lef utilization
root design design root root root root root root root root root layer
November 2013 1999-2013
67
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
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
November 2013 1999-2013
68

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 RC-P 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

Use the get_attribute command to confirm the list of imported LEF files:

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
Design with RTL Compiler Physical RC-Physical Flow synthesis) and a warning message will be issued. To turn off this consistency checking, set the lib_lef_consistency_check_enable attribute to false:
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.
November 2013 1999-2013
70



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:

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.
November 2013 1999-2013
71
Design with RTL Compiler Physical RC-Physical Flow 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.

You can skip this step if you are using generated PLE data. 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.


When you read in LEF libraries, the interconnect_mode attribute is automatically set to ple.
Design with RTL Compiler Physical RC-Physical Flow Note: If you want to use wireload mode, you must manually set the interconnect_mode attribute to wireload after loading the LEF libraries. 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_hdl read_sdc
read_encounter config

report ple
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.
Design with RTL Compiler Physical RC-Physical Flow Figure 5-2 Example of Report PLE
November 2013 1999-2013
74

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.

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.
November 2013 1999-2013
75
Design with RTL Compiler Physical RC-Physical Flow Figure 5-3 Example of DEF Statistics
Summary report for DEF file /xxx/fplan_mp.def Components ---------Cover: 0 Fixed: 71 Physical: 0 Bump: 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 4 / 4 71 / 0 I W I PHYS-154 PHYS-171 PHYS-181 Creating physical pin. Component not present in netlist. Full preserve set on instance.
Done reading and processing DEF file '/xxx/fplan_mp.def' (time: 1s).
November 2013 1999-2013
76
Design with RTL Compiler Physical RC-Physical Flow Table 5-1 Component Types
Fixed
Table 5-2 Pin Types


November 2013 1999-2013
77
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 ============================================================ ....... Interconnect mode: global Area mode: physical library ============================================================ Aspect ratio Shrink factor Scale of res/length Scale of cap/length Net derating factor Site size : : : : : : 0.98 1.00 1.00 1.00 1.00 5.70 um (from lef [tech+cell]) Data source: user override
Capacitance Layer / Length Name Direction Utilization (pF/micron) -----------------------------------------------<extracted> U n/a 0.000126 <extracted> V n/a 0.000128 <extracted> H n/a 0.000125 Resistance Layer / Length Name Direction Utilization (ohm/micron) ------------------------------------------------<extracted> U n/a 0.353355 <extracted> V n/a 0.353355 <extracted> H n/a 0.353355 Area Layer / Length Name Direction Utilization (micron) ------------------------------------------------Metal1 H 1.00 0.230000 Metal2 V 1.00 0.280000 ... Metal6 V 1.00 0.440000
Data source: user override
November 2013 1999-2013
78
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:

synthesize -to_placed
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 synthesize synthesize synthesize -to_generic -to_mapped -no_incremental -to_mapped -incremental -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
November 2013 1999-2013
79
To print an area report, use the report area report.
rc:/> report area Computing net loads. ============================================================ Generated by: Encounter(R) RTL Compiler version Generated on: date Module: DTMF_CHIP Technology libraries: library1 library2 ... physical_cells Operating conditions: slow Interconnect mode: placement Area mode: physical library ============================================================ Instance Cells Cell Area Net Area Total Area -----------------------------------------------------------------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 TDSP_CORE_GLUE_INST 550 8516 8640 17156 DECODE_INST 175 5612 973 6585 PORT_BUS_MACH_INST 93 2921 780 3700 PROG_BUS_MACH_INST 76 2791 815 3606 DATA_BUS_MACH_INST 96 2974 417 3391 TDSP_CORE_MACH_INST 49 1364 321 1685 ACCUM_STAT_INST 22 363 132 495 RAM_256x16_TEST_INST 18 113643 1118 114761 RAM_128x16_TEST_INST 18 100792 1222 102014 RESULTS_CONV_INST 1840 40802 30706 71508 ARB_INST 25 69458 167 69625 SPI_INST 56 2475 915 3390 DMA_INST 63 1983 439 2422 ULAW_LIN_CONV_INST 86 1201 692 1893 DATA_SAMPLE_MUX_INST 27 662 387 1049 DIGIT_REG_INST 12 738 72 811 TDSP_DS_CS_INST 35 542 82 624 TDSP_MUX 17 439 27 466 TEST_CONTROL_INST 6 160 0 160
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.
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 Cost Critical Violating Group Path Slack TNS Paths -------------------------------------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 -------------Leaf Instance Count Sequential Instance Count Combinational Instance Count Hierarchical Instance Count Area & Power -----------Total Area Cell Area Floorplan Utilization Leakage Power Dynamic Power Total Power Max Fanout Min Fanout Average Fanout Terms to net ratio Terms to instance ratio Runtime Hostname Silicon Virtual Prototype ------------------------Total Net Length Average Net Length Routing Congestion
November 2013 1999-2013
6099 546 5553 26
1353792.755 1225632.599 38.47% 4518.249 nW 226315685.082 226320203.331
nW nW
540 (scan_enI) 0 (DTMF_INST/ULAW_LIN_CONV_INST/lpcm[13]) 2.6 3.6 3.9 58 seconds host
484867.62 um 78.00 um H: 0.87% V: 0.63%

81 Product Version 13.1 All Rights Reserved.
Design with RTL Compiler Physical 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) 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 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
November 2013 1999-2013
82
Sample Script for RC-P Flow

set_attribute source_verbose true / set_attribute information_level 9 / suppress_message "xxx " set_attribute encounter_executable path_to_soc_executable 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 file / read_hdl DESIGN/dtmf_chip.v elaborate DTMF_CHIP report ple read_def DESIGN/floorplan/dtmf.def read_sdc dtmf.sdc #if using generated PLE data, add following two commands # decrypt PLE_file # report ple synthesize -to_generic synthesize -to_mapped -no_incremental synthesize -to_mapped -incremental set_attribute enc_temp_dir directory / synthesize -to_placed synthesize to_placed incremental report area report qor write_design -encounter -base rcp_output
November 2013 1999-2013
83
November 2013 1999-2013
84
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
November 2013 1999-2013
85
Design with RTL Compiler Physical Structured Data Path
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.
November 2013 1999-2013
86
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. 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 ORbars. You must choose one from the list { argument1 | argument2 | argument3 } Braces, used in Tcl command examples, indicate that the braces must be typed in.
italic
[ ]
{ }
...
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.
{ }
November 2013 1999-2013
87
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 {...} hierPath name name origin x y row {...} Related Information column Statement on page 89 row Statement on page 91
Describes one column in the relative placement. Specifies the hierarchical path name of the data path structure in the design. Specifies the name of one data path structure. Specifies the location of the database structure. Describes one row in the relative placement.
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 {...} skipSpace Val Related Information inst Statement on page 90
Describes one row in the column. Skips the specified number of spaces in the column.
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 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
November 2013 1999-2013
90
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 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 justifyBy {SW|SE|NW|NE|N|W|S|E|MID} Specifies the anchor point that will be used to align the row. Default: SW inst name Describes one instance in the row.
orient {R0|R90|R180|R270|MX|MY|MY90|MX90} Specifies the orientation to be set for the row. Default: R0 row skipSpace Val Related Information inst Statement on page 90 Specifies the name of the row. Skips the specified number of spaces in the row.
November 2013 1999-2013
91
SDP File Syntax Summary

[alias new_keyword predefined_keyword ]... datapath name { [hierPath name ] [origin x y ] 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 { [ 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 {... }]... } }... }... }...
November 2013 1999-2013
92
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 design constants cpf dex_settings dft instances_comb instances_hier instances_seq modes nets port_busses_in port_busses_out ports_in ports_out power sdp_groups subdesigns timing sdp_group sdp_rows sdp_row sdp_columns sdp_instances sdp_columns sdp_colum sdp_instances sdp_rows dex hdl_libraries libraries messages SDP object_types
November 2013 1999-2013
93
Design with RTL Compiler Physical Structured Data Path 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
November 2013 1999-2013
94
Design with RTL Compiler Physical Structured Data Path 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/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.
November 2013 1999-2013
95
Design with RTL Compiler Physical Structured Data Path 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
November 2013 1999-2013
96
Design with RTL Compiler Physical Structured Data Path 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/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 SDPDatapath SDP flowfor 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
November 2013 1999-2013
98
Design with RTL Compiler Physical Structured Data Path Figure 6-3 One pass FF Column SDP Flow
November 2013 1999-2013
99
November 2013 1999-2013
100
A
Terminology

Abbreviations on page 102 Glossary on page 103
November 2013 1999-2013
101
Design with RTL Compiler Physical Terminology
Abbreviations
Design Exchange Format Library Exchange Format Physical layout Estimation Resistance/Capacitance (parasitics) Encounter RTL Compiler with Physical Synopsys Design Constraints Standard Parasitic Exchange Format Silicon Virtual Prototype Wire Load Model
DEF LEF PLE R/C RC-P SDC SPEF SVP WLM
November 2013 1999-2013
102
Glossary
Term BLOCKAGES
Origin DEF
Definition Prevent either placement or routing in the specified area. Types are: LAYERprevent signal net routing PLACEMENTprevent 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: BLOCKhierarchical block COREstandard cell, including memory cells COVERcontains fixed floorplan data, such as power routing PADI/O cell
congestion
tool
Measures the routability of the design by comparing the number of required tracks and the number of available tracks. See PARTIAL
density screen FENCE FILL gcell GCELLGRID GROUPS DEF DEF DEF DEF
Type of REGION that only allows instances associated with the region to be placed in it. Rectangular shape that defines a metal fill in the design. One unit of the GCELLGRID. Global routing grid whose cells enclose a specified number of tracks Defines a group of components (logical elements) that are typically placed close together.
November 2013 1999-2013
103
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. Placement blockage around a component. This type of blockage is associated with the component. As a result a halo moves with the component. Layer information. Physical description of a library cell. Congestion optimization technique that moves cells from high utilization regions to low utilization regions. Defines the netlist connectivity for nets. Nondefault rules used in this design that are not specified in the LEF file. Routing layer obstruction associated with a MACRO. Type of PLACEMENT blockage that allows a percentage of the blockage area to be used for standard cells during initial placement. Cell with a physical description that does not appear in the RTL/netlist. Examples are filler cells, antenna cells, feedthrough cells. tool DEF Physical information for a CPF power domain. Defines the direction, layer, location, and size of a signal or power connection point on a MACRO.
HALO
DEF
LAYER MACRO morphing
LEF LEF RC
NETS NONDEFAULTRULES OBS PARTIAL (placement blockage) pcell
DEF DEF LEF DEF
pdomain PIN
November 2013 1999-2013
104
PITCH porosity
LEF tool
Defines the distance between routing tracks in the preferred direction for a given routing layer. Measure of unused space during initial placement which allows for cell resizing and new cell insertion during optimization. Technique to create a new process by optically shrinking the geometries from an existing process.
process shrink
PUSHDOWN
DEF
Type of PLACEMENT blockage created a higher level in the hierarchy and pushed down into the block. 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.
REGION
DEF
Rho ROW
capacitance table DEF
resistivity table based on the width and spacing of the layer Core rows in the core area of the design define the legal placement locations for the standard cells. Factor used to model the process shrink technique. Defines a placement site in the design Type of PLACEMENT blockage that prevents instances from being placed in the specified area during initial placement. Defines the rectangular shapes that are cut into wide metal wires to prevent dishing. Specifies the minimum spacing allowed between wires on the same layer, or between two via cuts on the same net or on different nets.
ShrinkFactor SITE SOFT (placement blockage) SLOTS SPACING
capacitance table LEF DEF
DEF LEF
November 2013 1999-2013
105
SPECIALNETS
DEF
Describes the wiring of prerouted nets, such as power and ground nets. These nets are not touched by the automatic router. 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.
steiner tree
STYLES TRACKS utilization
DEF DEF tool
A style polygon defines a wire's outer boundary. Predefined routing resources that define the routing grid. 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. Describes fixed vias and generated vias.
VIAS
DEF
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.
November 2013 1999-2013
106
Index
A
attributes cap_table_file 30, 50, 71 def_file 36, 56, 77 encounter_executable 48, 68 interconnect_mode 33, 52, 72 lef_library 28, 49, 69 lib_lef_consistency_check_enable 29, 50, 70 qrc_tech_file 30, 50, 71 read_def 54
S
scripts RC-P flow 83 simple PLE flow 40 spatial flow 62 SDF file syntax 87 SDP file reading in 98
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
November 2013 1999-2013
107
November 2013 1999-2013
108

RC Phys

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

RC Phys

Încărcat de

Drepturi de autor:

Formate disponibile

Design with RTL Compiler Physical

Product Version 13.1 November 2013

Design with RTL Compiler Physical

2 Simple PLE Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical

3 Generating PLE Data

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical

6 Structured Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

About This Manual

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

How to Use the Documentation Set

INSTALLATION AND CONFIGURATION

NEW FEATURES AND SOLUTIONS TO PROBLEMS

Getting Started with Encounter RTL Compiler

Using Encounter RTL Compiler

TASKS AND CONCEPTS

Datapath Synthesis in Encounter RTL Compiler

Setting Constraints and Performing Timing Analysis in Encounter RTL Compiler

Low Power in Encounter RTL Compiler

Design for Test in Encounter RTL Compiler

Attribute Reference for Encounter RTL Compiler

Command Reference for Encounter RTL Compiler

ChipWare in Encounter RTL Compiler

GUI Guide for Encounter RTL Compiler

Quick Reference for Encounter RTL Compiler

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

Reporting Problems or Errors in Manuals

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

Cadence Online Support

Other Support Offerings

For more information on these support offerings go to: http://www.cadence.com/support

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

Use the report messages command. For example:

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

man check_dft_rules man cell_leakage_power

November 2013 1999-2013

Product Version 13.1 All Rights Reserved.

Design with RTL Compiler Physical Preface

Getting the Syntax for a Command