RC Migration Guide

RC 101: RC Migration Guide
CADENCE DESIGN SYSTEMS
RC 101: RC Migration
Guide
Application Note
Cadence Design Systems, Inc
4/7/2012
This document outlines the basic synthesis flow supported by Encounter RTL Compiler (referred as RC
throughout the document) and is meant to help the new users to migrate from their existing flow to RC
effortlessly and with utmost ease. Intentionally, the language of the document is kept very simple and
scope is limited to discussing the basic synthesis features provided by RC. The scope of the discussion
does not cover the advanced synthesis features such as low power and physical synthesis. The
commands and features being discussed here are based on RC 11.1 and future releases.
COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED
Page 1
Contents
Contents ........................................................................................................................................................ 2
Overview ....................................................................................................................................................... 3
RTL Compiler Optimization Philosophy...................................................................................................... 3
RTL Compiler - Basic Design Flow ................................................................................................................. 3
Major Commands.......................................................................................................................................... 4
Elaborating the Design .............................................................................................................................. 4
Super-Threading........................................................................................................................................ 5
Synthesizing the Design ............................................................................................................................ 6
Generic Synthesis .................................................................................................................................. 7
Global Mapping ..................................................................................................................................... 8
Incremental Synthesis (IOPT) ................................................................................................................ 8
Setting Effort Levels .............................................................................................................................. 8
Generating Reports ................................................................................................................................... 9
Interfacing with Formal Equivalence tool............................................................................................ 10
Interfacing with Place & Route tool..................................................................................................... 11
Simple Synthesis Template ..................................................................................................................... 11
Migration to RC (Common Commands) .................................................................................................. 12
Some Important Commands and Attributes in RC ................................................................................. 14
Page 2
Overview
Encounter RTL Compiler (RC) is a fast, high capacity synthesis solution for demanding chip designs. The
core technologies embodied in RCs global synthesis approach produce superior logic and interconnect
structures for nanometer-scale physical design and routing. RTL Compiler complements the existing
Cadence solutions and delivers the best QoR for nanometer-scale designs.
RTL Compiler Optimization Philosophy

RTL compiler is different from other synthesis tools in a way that it works towards finding and optimizing
for global minima rather than squeezing the best of out of various local minima present in the design.
Once design sizes start growing it becomes imperative for the tool to look at the global picture keeping
in mind aggressive performance, power and area targets.
RC achieves this by creating the most optimal netlist structure first and then working around it for
getting the most optimal results.
RTL Compiler - Basic Design Flow

Basic design flow within RC remains similar to that of any other synthesis tool available. RC requires the
following inputs before synthesizing the design:
1.
2.
3.
4.
Technology libraries for both the standard cells and the hard-macros
RTL Files implementing the designs functionality
Design Constraints in either SDC format or native RC format
Physical Data (optional) such as LEF libraries, capable and floorplan DEF
Out of the inputs mentioned above, physical data is optional. However, it is advised to provide this data
if it is readily available. The flow has been depicted in the picture below and captures different steps
that are executed as part of the synthesis flow. These steps are run sequentially and allow the designer
to observe and monitor the health of the run by looking at the intermediate results.
Page 3
Fig. 1
Major Commands
Following are the most important steps in the RC design flow. Each of these perform a specific function
and have an important role to play in determining the overall optimization strategy. These steps form
the basic building blocks of the optimization script and all other attributes and variables are just
used to guide these basic steps.
Elaborating the Design

Elaboration involves various design checking and optimizations and is a necessary step to proceed with
synthesis. The elaborate command automatically elaborates the top-level design and all of its
references. During elaboration, RTL Compiler performs the following tasks:
Builds data structures

Infers registers in the design
Performs higher level HDL optimization, such as dead code removal
Checks semantics
Page 4
If there are any gate-level netlists read in with the RTL files, RC automatically links the cells to their
references in the technology library during elaboration. Users need not issue any additional command
for linking. Additionaly, the elaborate command automatically elaborates the design by propagating
parameter values specified for instantiation.
At the end of elaboration, RTL Compiler displays any unresolved references (immediately after the key
words Done elaborating):
Done elaborating '<top_level_module_name>'.
Cannot resolve reference to <ref01>
...
After elaboration, RC has an internally created data structure for the whole design so users can apply
constraints and perform other operations. Attribute hdl_track_filename_row_col enables RC to keep
track of filenames, line numbers, and column numbers for all instances before optimization. RC uses this
information in subsequent error and warning messages.
Users can generate a generic netlist for a specific Verilog module and all its sub-modules, or a VHDL
entity and all its components using the following command:
elaborate des_top
Super-Threading
RTL Compilers super-threading capability allows you to reduce synthesis turn-around time by
distributing the processing work across multiple CPUs. The CPUs may be on the same machine on which
RTL Compiler was launched, or it may be on different machines across a network.
Unlike previous approaches to parallelize logic synthesis, RTL Compilers capability is unique: the
synthesis results produced through parallel processing are identical to those produced in a non-parallel
run. Therefore, only the turn-around time is affected. In addition, RTL Compiler provides support for
super-thread caching. Caching allows keeping the data and the result associated with a super-threaded
job and retrieving this result when a subsequent job is attempted. Caching can be used regardless of the
number of servers specified (even if no servers are specified).
If you enable super-threading, distributed processing occurs during RTL optimization (synthesize to_generic, global mapping and global incremental phases of the synthesize -to_mapped) command.
RC supports super-threading on LSF and the Sun Grid Engine (SGE).
The following examples illustrate how to set super-threading optimization in various scenarios:
The following example illustrates RTL Compiler L launching a single process for super-threaded
optimization on the machine on which RTL Compiler is currently running. In super-threaded
Page 5

optimization mode, the original process merely serves as a work-dispatcher. This will only slow
synthesis compared to if no super-threading were specified due to inter-process communication
overhead.
rc:/> set_attribute super_thread_servers {localhost} /
The following example illustrates RTL Compiler launching three processes on the current
machine for super-threading. If the current machine has at least three CPUs, a significant turnaround time reduction can be achieved.
rc:/> set_attribute super_thread_servers {localhost localhost localhost} /
RTL Compiler will support super-thread servers of different platform types. The following
example illustrates RTL Compiler launching two remote server processes on the machine
called linux33 and two processes on sun42.
rc:/> set_attribute super_thread_servers {linux33 linux33 sun42 sun42} /
Following are the licensing requirements to launch the remote server processes:
Product/Option
Number of remote server processesenabled

by
First license
Subsequent
license
RTL Compiler L
RTL Compiler XL
RTL Compiler CPU Accelerator

Option
2
Table 1
Synthesizing the Design

Synthesis is the process of transforming your HDL design into a gate-level netlist, given all the specified
constraints and optimization settings. Within RC, synthesis is performed in the following two steps:
1.
Synthesizing the design to generic logic (RTL and datapath optimizations are performed in this step)
2.
Mapping to the technology library and performing incremental optimization.
These two sequential steps are represented by the synthesize command options -to_generic and
-to_mapped
Page 6
The picture above depicts in brief the tasks carried out during each of the individual steps within the
synthesize command. Now well discuss each of these individual steps in more detail.
Generic Synthesis
In this stage, RC performs technology-independent optimizations, including constant propagation,
resource sharing, logic speculation, MUX optimization, and carrysave arithmetic optimizations.
Users can run this stage separately by using the following command:
synthesize to_generic -effort <effort_level>
The medium effort is the default choice but users can use high effort for datapath intensive designs,
or designs for which it is hard to meet timing. RC optimizes sequential instances that transitively do not
fan out to primary output. This information is reported in the log file. Another way to catch these points
is to use output of formal verification. Users can see unmapped points in formal verification and check
for deleted sequential instances in the log file.
Please note that it is not advisable to use this commands while loading a verilog mapped netlist. Please
take care while using this command on a mapped netlist unless it is absolutely necessary, as it will
unmap the design.
Page 7
Global Mapping
In this phase, RC maps the generic gate level netlist to the technology library cells. This step internally is
broken down into two related activities. In the first phase of global mapping, RC performs tentative
structuring and computes the estimated arrival and required times for all the endpoints, based on the
effort level that you set. The result of this stage is the target for each cost group, a concept unique to RC
In the second phase of global mapping, RC restructures paths and computes delays based on the targets
and the effort level that you set. The goal of this phase is to meet the target timing that was inferred in
the previous optimization pass. Finally, RC refines the timing and area of all critical paths by remapping
the cells according to the new surroundings of that particular cell.
synthesize to_map -no_incremental -effort <effort_level>
Incremental Synthesis (IOPT)

This is the final optimization phase in the synthesis process. The primary intent of this stage is to clean
up timing using local optimizations, such as CRR (critical region resynthesis), and to insert scan chains if
enabled. All the violations arising due to max_cap, max_trans and max_fanout constraints are
consideredand subsequently fixed in this step. Optimizations performed during IOPT improve timing and
area and fix DRC violations.
By default, timing has the highest priority and RTL Compiler will not fix DRC violations if doing so causes
timing violations. This priority can be over ridden by setting the drc_first attribute to true. In this case,
all violations will be fixed as well as those paths with positive slack. Optimizations performed during this
phase include multi-bit cell mapping, incremental clock gating and retiming, tie cell insertion and assign
removal.
synthesize to_map -incremental -effort <effort_level>
Setting Effort Levels

Users can specify an effort level by using the -effort {low | medium | high} option with
the synthesize command. The possible values for the -effort option are as follows:
Page 8
Low: The design is mapped to gates, but RC does very little RTL optimization, incremental clean
up, or redundancy identification and removal. The low setting is generally not recommended
Medium (Default): RC performs better timing-driven structuring, incremental synthesis,

and redundancy identification and removal on the design
High: RC does the timing-driven structuring on larger sections of logic and spends more time and
makes more attempts on incremental clean up. This effort level involves very aggressive
redundancy identification and removal
Following table captures the summary of the discussion on the synthesize command.
SpecifiedOption Current Design State

RTL
No OptionSpecified
Generic
RTL
Optimization
Mapped
Mapping
Unmapping
Incremental
Optimizations
Mapping
Incremental
Optimizations
-to_generic
RTL
Optimization
Nothing
Unmapping
-to_mapped
RTL
Optimization
Mapping
Unmapping
Incremental
Optimizations
Mapping
RTL
Optimization
Mapping
Placement
Placement
Mapping
Post-placement
Placement
incremental
optimizations
Post-placement
incremental
optimizations
Mapping
Incremental
Optimizations
-to_placed
Post-placement
Incremental
Optimizations
incremental
optimizations
Table 2
Generating Reports
This section discusses how to analyze the synthesis results using the report command and the log file.
Page 9
The report timing command should be used to generate reports on the timing of the current design.
The default timing report generates the detailed view of the most critical path in the current design. The
timing report provides the following information:
Type of cell (flop-flop, or, nor, and so on)

The cell's fanout and timing characteristics (load, slew, and total cell delay)
Arrival time for each point on the most critical path
Use the -from and -to options to report the timing value between two points in the design. The
timing points in the report are designatedwith the <<< indicator.
The area report gives a summary of the area of each component in the current design. The report gives
the number of gates and the area size based on the specified technology library. Levels of hierarchy are
indented in the report.
In the outputs generated by report gates and report area commands, RC shows the technology library
name, operating conditions, and the wire-load mode used to generate these reports. report gates is
the command to generate a report of the gate profile being used in the design. At the end of the gate
report, RC shows the total number of instances and the area for all the sequential cells, inverters,
buffers, logic, and timing-models, if any. To get a report on the total combinational area, users need to
add the logic, inverter, and buffer area numbers.
Interfacing with Formal Equivalence tool

RC interfaces with Encounter Conformal Equivalence Checker software for equivalence checking. RC
writes out an intermediate dofile along with the netlist. The dofile is an ASCII file that includes Encounter
Conformal commands.
To interface with Conformal, RC generates "dofiles" that should be loaded into Conformal. The following
steps illustrate a high-level flow for creating dofiles:
To check if the final netlist is functionally equivalent to the initial design read into RC,
write_do_lec command is used to generate a dofile to interface with Conformal LEC
To check if the netlist conforms to low power rules defined in the Common Power Format (CPF)
file, write_do_clp command generates a dofile to interface with Conformal Low Power
Note: Using a high effort level during synthesis can creates challenges in some scenarios for
Conformal LEC depending on the design type and optimization aggressiveness. Complex
datapath designs and designs using retiming are often problematic.
Page 10
Interfacing with Place & Route tool
After the completion of the synthesis, users can write out files for processing by the Place & Route
tools. RC generates run files that can be used by the user to load the design seamlessly in the
Encounter Digital Implementation System (EDIS) P&R tool.
Using write_design encounter, RC will generate the following files in the working directory:
top.conf
top.g
top.rc_setup.tcl
top.v
top.enc_setup.tcl
top.mode
top.sdc
To start an EDIS session, users now only need to source the top.enc_setup.tcl file which will in turn load
the necessary files (such as the libraries, the generated netlist file, and SDC constraints) written out by
RC.
Apart from this, RC also writes out other files that can be used by other P&R tools. Following are the
commands used to dump out these files:
Netlist: write_hdl dumps out the netlist from RC

Constraints: write_sdc dumps out constraints in the SDC format
DEF: write_def can be used to dump out a DEF file from RC (to be used if a DEF was read
previously)
SDF: write_sdf dumps out the SDF file that can be used by other P&R tools
Simple Synthesis Template

The following script is a simple script which delineates the very basic RTL Compiler flow. Apart from this
users can use the write_template command to dump out a basic skeleton and then modify the same
to suit their designs. This modification is minimal and usually contains adding design inputs like
libraries, RTL and constraints.
set_attribute lib_search_path <full_path_of_technology_library_directory> /
set_attribute hdl_search_path <full_path_of_hdl_files_directory> /
Page 11
set_attribute library <technology_library> /

read_hdl <hdl_file_names>
elaborate <top_level_design_name>
read_sdc <sdc_file_name>
set clock [define_clock -period <periodicity> -name <clock_name> [clock_ports]]
external_delay -input <specify_input_external_delay_on_clock>
external_delay -output <specify_output_external_delay_on_clock>
synthesize -to_mapped
report timing > <specify_timing_report_file_name>

report area > <specify_area_report_file_name>
write_hdl > <specify_netlist_name>

write_script > <script_file_name>
Migration to RC (Common Commands)
Task
Specifying
ibraries
RC Command
RC expects both the link and the target libraries to be specified together as part of
one list. RC automatically infers the references from the library set. Please note that
RC will use cells from both the libraries to build the circuit for design under
consideration.
Ex.
set_attribute library {mylib1.lib mylib2.lib}
Page 12

In RC, design can be read using the combination of "read_hdl" and "elaborate"
commands. "read_hdl" parses the file and check for the syntactical errors. Then
"elaborate" commands translates the RTL in to GTECH gates
Reading the
Design
Ex. (Assuming design name to be TOP).

read_hdl -verilog TOP.v
elaborate TOP
For reading the mapped verilog netlist, use "read_netlist" command instead
Specifying
Constraints
RC can read in the constraints in either native RC format or it can also read in the
constraints written in SDC format (most of the cases, SDC is made available as part of
the design data).
Ex.
read_sdc TOP.sdc
Following attributes define the DFT configuration within RC. Once these attributes are
set, during synthesis scan is inserted automatically. Please note that scan is added if
some or all the registers pass DFT rules. During mapping, DFT setup is done and
connection of the scan chain happens by invoking "connect_scan_chain" command.
Specifying
DFT
directives
Specifying
Low Power
Directives
Ex.
Define_dft test_clock -period 100 [find / -port clk]
define_dft test_mode -active high [find /-port rst]
define_dft test_mode -active high [find / -port test_mode]
define_dft shift_enable -active high [find / -port se]
set_attribute dft_mix_clock_edges_in_scan_chain false /des*/*
define_dft scan_chain -name chain1 -sdi si -sdo so -shift_enable se
synthesize -to_map (insert the scan structures)
connect_scan_chains (connects the scan chains in the design)
In RC, insertion of clock gating is controlled using following set of attributes. These
attributes need to be set before "synthesize" command.
Ex.
Set_attribute lp_insert_clock_gating true /
set_attr lp_clock_gating_style latch /des*/*
set_attr lp_clock_gating_test_enable scan_enable /des*/*
Page 13
Specifying
Low Power
Directives
In RC, multi-Vt optimization is done in a manner similar to that of competing synthesis

tools. All the libraries are mentioned together and the max_leakage_power attribute
is set.
Ex.
Set_attribute library {hvt.lib svt.lib lvt.lib}
set_attr max_leakage_power 0 /des*/*
set_attr lp_multi_vt_optimization_effort high /
RC also uses the activity file to read in the switching activity and use the same for
dynamic power optimization. Better the switching activity file, more accurate the
optimization.
Ex.
Read_saif top.saif
Synthesizing
the Design
Generating
the Reports
Writing out
the Interface
Files
Once all the optimization directives (including DFT and Low Power) are applied, the
design is ready to be synthesized. In RC, this is done using the "synthesize" command
and this is used in conjunction with the "effort" level
Ex.
ESynthesize -to_mapped -eff high
Many reporting commands exist in RC to analyze the results of the execution. Primary
of these are:
check_design
report area
report timing
In RC, "write_design" command is used to dump out the design database. Verilog
netlist, SDC, DEF and other important files are written out as part of this command
Table 3
Some Important Commands and Attributes in RC
When reading in the timing libraries (only Liberty format supported), RC might mark some library
cells as unusable for use. RC can mark a library cell as avoid (dont_use) when the cell exists in the
timing library but does not exist in the physical library (LEF file). This behavior usually surprises the
user when it comes to mapping
Page 14
o Look for LBR-171 kind of messages in the logfile

After elaborating the design, users should check if any unresolved references are present. This is
essential as this ensures that the whole design has been read in properly
o check_design unresolved
Once the constraints are read, check the SDC statistics in the logfile. This will tell the user if any of
the constraints got dropped. In case any of the constraints are getting dropped, users can refer to
the line number of the error and resolve the same
o Query word Statistics in the logfile for seeing SDC statistics
Users should use timing lint report to check if constraints are getting applied properly. This checks
for the missing I/Os, timing loops present in the design and the flops not getting any clock. Timing is
the first priority during synthesis, thats why RC is very sensitive to the timing constraints. Hence,
users should ensure the validity of the constraints
o Report timing lint
SDC commands can also be applied in the interactive mode using the prefix dc::
o dc::set_case_analysis 0 [dc::get_pins A/z]
Generally, RC structures and optimizes logic better when there is no module hierarchy. Use the
following attribute to allow RC to ungroup the design automatically for better QoR
o set_attribute auto_ungroup both /
o set_attribute ungroup_ok false <instance/subdesign> (To disable ungrouping on an
instance or a subdesign)
By default RC optimizes across the hierarchies in order to come up with the best QoR. However,
designers might have certain constraints with respect to preservation of the module boundaries.
Use the following attribute to turn off boundary optimization on selected modules
o set_attribute boundary_opto false <subdesign>
By default, RC optimizes for the WNS. In case users wants to guide the tool to optimize for TNS, then
use the following attribute:
o set_attribute tns_opto true /
Sometimes it is possible to achieve better QoR if we specify how to treat the unconnected
pins/ports in the design. In RC, this is governed by following three attributes. Please ensure these
attributes are set before elaborating the design
o set_attribute hdl_unconnected_input_port_value 0 /
o set_attribute hdl_undriven_output_port_value 0 /
o set_attribute hdl_undriven_signal_value
0/
By default, RC considers the async paths as ideal and hence does not consider these for
optimization. In order to optimize such paths as well, use the following attribute
o set_attribute time_recovery_arcs true /
RC by default can use the SDFF present in the library for functional use in addition to scan. RC can do
this to improve the QoR of the design. However, this may cause problem with the DFT insertion later
on. Hence, use the following attribute to tell RC to not pick SDFF type libcells for functional use
o set_attribute use_scan_seqs_for_non_dft false /
Page 15

RC Migration Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RC Migration Guide

Загружено:

Авторское право:

Доступные форматы

RC 101: RC Migration Guide

CADENCE DESIGN SYSTEMS

RC 101: RC Migration Guide

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

RTL Compiler Optimization Philosophy

RTL Compiler - Basic Design Flow

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

Elaborating the Design

Builds data structures

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

Number of remote server processesenabled

RTL Compiler CPU Accelerator

Synthesizing the Design

Mapping to the technology library and performing incremental optimization.

RC 101: RC Migration Guide

RC 101: RC Migration Guide

Incremental Synthesis (IOPT)

Setting Effort Levels

RC 101: RC Migration Guide

Medium (Default): RC performs better timing-driven structuring, incremental synthesis,

SpecifiedOption Current Design State

RC 101: RC Migration Guide

Type of cell (flop-flop, or, nor, and so on)

Interfacing with Formal Equivalence tool

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

Interfacing with Place & Route tool

Netlist: write_hdl dumps out the netlist from RC

Simple Synthesis Template

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

set_attribute library <technology_library> /

report timing > <specify_timing_report_file_name>

write_hdl > <specify_netlist_name>

Migration to RC (Common Commands)

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

Ex. (Assuming design name to be TOP).

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

In RC, multi-Vt optimization is done in a manner similar to that of competing synthesis

Some Important Commands and Attributes in RC

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

RC 101: RC Migration Guide

o Look for LBR-171 kind of messages in the logfile

COPYRIGHT 2012, CADENCE DESIGN SYSTEMS, INC. ALL RIGHTS RESERVED

Вам также может понравиться