Professional Documents
Culture Documents
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
25
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
85 86 87 87 88 88 88 89 90 91 92 93 98
A Terminology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
Preface
About This Manual on page 8 Additional References on page 8 How to Use the Documentation Set on page 9 Customer Support on page 11 Messages on page 12 Man Pages on page 13 Command-Line Help on page 14 Documentation Conventions on page 16
Additional References
The following sources are helpful references, but are not included with the product documentation:
TclTutor, a computer aided instruction package for learning the Tcl language: http://www.msen.com/~clif/TclTutor.html. TCL Reference, Tcl and the Tk Toolkit , John K. Ousterhout, Addison-Wesley Publishing Company IEEE Standard Hardware Description Language Based on the Verilog Hardware Description Language (IEEE Std.1364-1995) IEEE Standard Hardware Description Language Based on the Verilog Hardware Description Language (IEEE Std. 1364-2001) IEEE Standard VHDL Language Reference Manual (IEEE Std. 1076-1987) IEEE Standard VHDL Language Reference Manual (IEEE Std. 1076-1993)
Note: For information on purchasing IEEE specifications go to http://shop.ieee.org/store/ and click on Standards.
README File Whats New in Encounter RTL Compiler Known Problems and Solutions in Encounter RTL Compiler
REFERENCES
An error in the manual An omission of information in a manual A problem using the Cadence Help documentation system
10
Customer Support
Cadence offers live and online support, as well as customer education and training programs.
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.
11
Messages
From within RTL Compiler there are two ways to get information about 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
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:
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
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
For example:
rc:/> get_attribute max_transition * -help
14
You can type a sequence of letters after the set_attribute command and press Tab to get a list of all attributes that contain those letters.
rc:/> set_attr li ambiguous "li": lib_lef_consistency_check_enable lib_search_path libcell liberty_attributes libpin library library_domain line_number
You can type a single letter and press Tab to get a list of all commands that start with that letter. For example:
rc:/> c <Tab>
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>
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.
{}
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
17
18
19
Synthesis Libraries
RTL Files
Constraint File
RTL Compiler
LEF Libraries Capacitance Table File
SDC Constraints
DEF File
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
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.
21
(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
blockages bumps defpins fills gcells groups layers fills nondefaultrules pcells pdomains pnets regions rows sites slots specialnets styles tracks vias
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.
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.
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
25
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
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
26
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
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}
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:
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
29
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:
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.
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.
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.
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:/>
32
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.
33
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.
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.
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.
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
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
36
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.
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
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 %.
November 2013 1999-2013 38 Product Version 13.1 All Rights Reserved.
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
39
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
41
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
42
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.
43
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.
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
45
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
No
Meet constraints?
Yes
Product Version 13.1 All Rights Reserved.
46
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
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
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
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
48
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}
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:
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
November 2013 1999-2013 49 Product Version 13.1 All Rights Reserved.
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:
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
Note: If you specify both a capacitance table file and a QRC technology file, the QRC technology file takes precedence.
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.
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.
51
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.
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.
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 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.
52
Design with RTL Compiler Physical Spatial Flow Figure 4-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:/>
53
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.
RTL Compiler will perform a consistency check between the DEF and the Verilog netlist and issue relevant messages if necessary. For example:
Parsing DEF file... Warning : A DEF component does not exist in the netlist. [PHYS-171] : The component IOPADS_INST/Pcornerll does not exist. : This message has a default max print count of 25, which can be changed by setting the max_print attribute. Warning : A DEF component does not exist in the netlist. [PHYS-171] : The component IOPADS_INST/Pcornerlr does not exist. ... Done parsing DEF file.
The DEF file must define the die size. For better synthesis results, you should also have the pin, macro locations, and standard cell placement specified in the DEF, although it is not required. Figure 4-3 on page 55 shows an example of DEF statistics printed after the DEF file has been processed.
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.
55
Design with RTL Compiler Physical Spatial Flow Table 4-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
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
56
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
57
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
58
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.
59
To get an overall report containing slack information, instance count, area information, cell power, runtime, and host name information, use the report qor command.
rc:/> report qor ============================================================ Generated by: Encounter(R) RTL Compiler version ... Interconnect mode: spatial Area mode: physical library ============================================================ Timing -------Clock Period -------------vclk01 5000.0 vclk02 6000.0 vclk1 5000.0 vclk2 5000.0 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
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.
61
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
63
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
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
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
Optional task
65
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
true
false
true
Default
false true
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
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
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
68
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}
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:
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
November 2013 1999-2013 69 Product Version 13.1 All Rights Reserved.
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:
rc:/> set_attribute lib_lef_consistency_check_enable false /
RTL Compiler supports LEF 5.3 and above. Refer to the LEF/DEF Language Reference for more information on LEF files. Troubleshooting Tips 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
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.
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.
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.
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.
November 2013 1999-2013 72 Product Version 13.1 All Rights Reserved.
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.
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
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 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.
November 2013 1999-2013 73 Product Version 13.1 All Rights Reserved.
Design with RTL Compiler Physical RC-Physical Flow Figure 5-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:/>
74
Logical information includes grouping information and physical constraints Physical information includes
The die or block bounding box The die determines the placement area and therefore influences the net length.
Pin and macro locations These influence the standard cell placement and thus the net length.
RTL Compiler supports DEF 5.3 and above. Refer to the LEF/DEF Language Reference for more information on DEF files.
RTL Compiler will perform a consistency check between the DEF and the Verilog netlist and issue relevant messages if necessary. For example:
Parsing DEF file... Warning : A DEF component does not exist in the netlist. [PHYS-171] : The component IOPADS_INST/Pcornerll does not exist. : This message has a default max print count of 25, which can be changed by setting the max_print attribute. Warning : A DEF component does not exist in the netlist. [PHYS-171] : The component IOPADS_INST/Pcornerlr does not exist. ... Done parsing DEF file.
The DEF file must define the die size. For better synthesis results, you should also have the pin, macro locations, and standard cell placement specified in the DEF, although it is not required. After reading the DEF you can view the floorplan in the GUI. Figure 5-3 on page 76 shows an example of DEF statistics printed after the DEF file has been processed.
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.
76
Design with RTL Compiler Physical RC-Physical Flow Table 5-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
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
77
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
78
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
79
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.
November 2013 1999-2013 80 Product Version 13.1 All Rights Reserved.
To get an overall report containing slack information, instance count, area information, cell power, runtime, and host name information, use the report qor command.
rc:/> report qor
============================================================ Generated by: Encounter(R) RTL Compiler version ... Interconnect mode: placement Area mode: physical library ============================================================ Timing -------Clock Period -------------vclk01 5000.0 vclk02 6000.0 vclk1 5000.0 vclk2 5000.0 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
nW nW
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
82
83
84
6
Structured Data Path
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
85
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.
86
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.
{ }
87
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
November 2013 1999-2013 88 Product Version 13.1 All Rights Reserved.
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
November 2013 1999-2013 89 Product Version 13.1 All Rights Reserved.
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
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.
91
92
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:
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
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.
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
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.
November 2013 1999-2013 97 Product Version 13.1 All Rights Reserved.
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.
98
Design with RTL Compiler Physical Structured Data Path Figure 6-3 One pass FF Column SDP Flow
99
100
A
Terminology
101
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
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.
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
LEF LEF RC
pdomain PIN
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
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.
DEF LEF
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
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.
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
107
108