Synthesis

Synthesis

Convert RTL to technology dependent netlist satisfying constraints

Constraints
Technology dependent
Inputs

Technology dependent
Satisfying Constraints

RTL Synthesizer Netlist

 SYNTHESIS AREA SETUP

The synthesis directory called “syn” should contain the following

directory structure:

Description:
 Inputs/ - contains the input files such as timing constraints, upf and other
such files
 Scripts/ - contains the block_setup.tcl and other such files needed by RDT
flow
 Outputs/ - contains the outputs of each stage of syn such as sdc, ddc, vg, etc
 Reports/ and logs/ contain what their name suggests
 Rest of directories and files are created by syn and the flow that you use
Inputs, Outputs & Reports

Logical Libraries
Topo
GTECH
Symbol
DesignWare
STANDARD CELL Outputs
MACROS/HIPS
Gate level Netlist
Physical Libraries scandef
Standard cell
Macros/HIPs
DDC
Design (.v, .vhdl, .sv) UPF
Constraints mwdb
Timing
DC
DEF
Area
Power Reports
UPF QoR (T, A, P)
Scan constraints mv checks
scan checks
Techfile
Tluplus
Layermap file
DEF
 LIBRARIES

GTECH: This is a virtual internal library of Synopsys. Before the design is mapped to a
technology library, it gets mapped to this virtual library after elaborate is done. This
describes the basic functionality of the cell (ex: AND, AOI, etc) and is useful to see how
the design will map in the early stages itself.
SYMBOL: This is also an internal library of Synopsys (though every vendor has a version
of it). This library contains the different symbol shapes of the different cells that have
been mapped to the GTECH cells (and which later are mapped to tech library).
DESIGNWARE: It is a real implementation for a complicated function like multiplier,
divider etc.. it is an function-optimized ,but technology independent, macro that gets
instantiated if your code implies (or explicitly instantiates) an arithmetic or some other
standard function. Means you really don't need to know how to build a booth multiplier
or a priority encoder etc; you just write your code so that this functionality is required,
Synopsys will throw in the best-fit hardware implementation it knows for that function.
STANDARD CELL: This is a technology dependent library provided by the foundry to the
designer. It contains the logical, timing and physical information about the cells that will
be used during compile.
 LIBRARIES (2)
$search_path – This is the path the DC uses to search for the libraries
specified in the design. This should contain the paths of the
directories containing lib files
$target_library – DC uses the libraries specified in this variable during
compile process
$link_library - DC uses the list of design files and libraries specified
here during linking. It tries to resolve references of all files from
libraries specified here.
Physical Libraries – In case, DC-topo is used, certain other tech files
such as tluplus files, layermap files, etc for a physical-aware
synthesis.
Macro/HIP Library – The interface paths and definitions of Ips used in
the RTL require that their respective .libs be available as part of
$link_library.
 SYNTHESIS STAGES
 Import_design
 Upf
 Saif
 Uniquify
 Floorplan
 Constraints
 Compile
 Insert_dft
 Compile_incr
 Syn_final
The highlighted stages are general stages of synthesis. Rest are
optional.
 Import_design

It reads the RTL from rtl_list.tcl. It reads the RTL one-b-one nd finally converts it into a
technology independent netlist i.e. a netlist mapped to GTECH cells.
This step executes two important commands:
 Analyze – this command does a “code-compile” on the rtl files read. It checks for
errors such as missing definitions, syntax or semantic errors.
 Elaborate – after analyze, this command finally elaborates the different verilog files and
converts them into a netlist mapped to GTECH cells.
What to check:
 Link – link command tells you if there are any cells in your design that are not mapped
to GTECH or macro libraries. They appear as blackboxes.
 Check_design – check_design generates a report which tells about the health of the
netlist. It reports out errors relating to any blackboxes in the design, shorted outputs,
multi-driven nets, unclocked registers and so on.
Always check these two reports and give the relevant feedback back to the FE designer.
 UPF

UPF stage reads the <design_name>.upf file into the DC shell.

What to check:
 Check_mv_design – this command generates a report describing the health of the design after UPF
implementation. It will eport out issues such as missing isolation cells, power supplies, missing level-
shifters etc.
All errors in this report are to be cleaned by the block owner. He/she may have to edit the UPF for this
or he/she has to talk to the FE designer regarding any UPF related cells inserted in rtl.
 Sometimes, the FE designer defines power signals in his design. These power signals are interpreted
as a port with attribute type “signal” by the DC. When we define the power rails in UPF, DC interprets
them as a port with type “power”. We cannot have both of them present at the same type. If so, the
tool errors out.
Solution: Remove all power signals defined in the RTL before implementing UPF.
set rtl_pwer_port [get_object_name [get_ports -quiet "vss vcc*_1p03"]]
foreach ob $rtl_power_port {remove_port $ob}
set rtl_power_net [get_object_name [get_nets -quiet "vss vcc*_1p03"]]
foreach ob $rtl_power_net {remove_net $ob}
 Uniquify

The uniquify process copies and renames any multiply referenced design so that each
instance references a unique design. The process removes the original design from
memory after it creates the new, unique designs.
Ex: Suppose, initially U3 and U4 have the same reference, an ADDER. It may be required to
make some changes to the ADDER to optimize U3. But those changes, will also be
reflected in U4, which we do not want. In this case, we use uniquify. After, uniquify
process, two copies of reference ADDER are made, ADDER_1 and ADDER_2 as shown.
This resolves our optimization conundrum explained above.

Command:
To uniquify specified designs:
uniquify -cell $uniquify_cells

To uniquify all:
uniquify -f -dont_skip_empty_designs
 Constraints (1)

This is one of THE most important stages in synthesis. All the design
constraints related to timing, area and power are usually specified in this
stage. The constraints specified here control the entire compilation process
and are responsible for the quality of the synthesized design.

Remember: “garbage in” = “garbage out”

The various steps involved in constraints stage are:
 timing_constraints
 mbist_constraints
 lbist_constraints
 Syn_constraints
 constrain_visa_logic
 area_constraints
 operating_conditions
 power_constraints

All the design constraints can be provided either in a single .sdc (synopsys
design constraints) file or as a group of files that can be sourced individually.
 Constraints (2)
Timing constraints
All constraints related to the timing intent. Includes:
 Clock definitions
 Clock uncertainty
 Clock groups
 Latency and transition specifications for clocks
 IO timing
 Macro interface timing
 Timing derates
 Timing exceptions
 Case analysis

These are specified in $WARD/syn/inputs

 Constraints (3)

LBIST/MBIST Constraints
If the design contains LBIST or MBIST cells, constraints must be
specified for controlling and correct functioning of these blocks.
These constraints specify:
 Clock definitions of MBIST/LBIST
 Constrains for building scan chain
 Case analysis
 Constraints for Loading and reading test vectors from RF
VISA Constraints
These are constrains relating to the VISA architecture in your
design. VISA clocks are separate from functional clocks, and need to
be stamped at VISA muxes among other points in design. Hence, a
separate set of timing constraints are needed for VISA. For a sample
of VISA constraint files, look at slide 12.
 Constraints(4)

Area Constraints
Can specify max area constraint
set_max_area <area_value>

Power Constraints
These are related to multi_voltage and power optimization techniques to be
followed by DC. The following commands generally form part of these
constraints.
 Enable Multi-VT design optimizations
set_multi_vth_constraint -lvth_percentage [getvar G_LVT_PERCENT] -
lvth_groups “ln” –type <hard/soft> -cost area
 Set power constraints
set_max_leakage_power <value>
set_max_dynamic_power <value>
 Enable dynamic and leakage power optimization
set_dynamic_optimization true
set_leakage_optimization true
set_leakage_power_model -type leakage
 Constraints(5)

Synthesis constraints
 Design Rule constraints
set_max_capacitance
set_max_fanout
set_max_transition

 Wire Load Models

set_wire_load_model –name <ldb name> <design_name>

 Operating Conditions
set_operating_conditions -max typical_1.00 -max_lib <max_lib_name>
For setting a global operating condition, you can skip “-max_lib”

 I/O constraints
Not related to timing constraints
set_drive
set_driving_cell
set_fanout_load
set_load
 Compile

 This stage performs the function of mapping the design to a

technology-dependent library.
 After this stage is complete, all cells which were till now mapped to
GTECH library are mapped to technology libraries.
 The compile stage optimizes the design in order to satisfy the
timing, power and area constraints specified earlier.
 The default command in our flow for compile is given below:
compile_ultra -no_seq_output_inversion -no_autoungroup -no_boundary_optimization
 To enable further optimizations, the following can be done:
set_app_var compile_seqmap_propagate_constants true
set_app_var compile_delete_unloaded_sequential_cells true
set_app_var compile_preserve_subdesign_interfaces false
set_app_var compile_seqmap_propagate_high_effort true
 Compile (2)
WHAT TO CHECK?
 Check the check_design report and the check_mv_design report. There should be no errors in
both reports. No new issues should crop up.
 Also, if we are optimizing using the four commands given before in point 4, the number of
issues in check_design report should reduce.
 When set_app_var compile_delete_unloaded_sequential_cells true, the tool removes the
unloaded cells with a OPT-1207 warning. Compile a list of all such cells and share with the front-
end designer to make sure that these are indeed redundant and can be removed!!!
 To check for completeness of timing constraints, check the check_timing report. Although, all of
this report should be checked thoroughly by STA guy and DE, pay attention to Unclocked
Registers. Report them to front-end designer.
 Check for unmapped logic after compile. These represent the cells that could not be mapped to
a technology library and are still GTECH cells. You can check it by checking the
unmapped_logic.rpt generated by the flow OR do the following to report all unmapped designs:
get_cells -hierarchical -filter "is_unmapped==true”
 Check the timing reports and ensure that setup timing is met for all paths after taking into
account all derates and guardbands. If not, you have to debug to see wherein lies the problem.
If timing is not clean here, then it will be even worse when we start APR.
Automatic Ungrouping

Merges sub designs of a given level of the hierarchy into the parent cell or design.
 Removes hierarchical boundaries
Before Ungrouping
 Improves timing by reducing the levels of logic
 delay based auto ungrouping - default

 Improves area by sharing logic

 area based auto ungrouping

dont_touch attributes are honored After Ungrouping

DW components are not ungrouped
(already highly optimized)

compile_ultra -auto_ungroup
report_auto_ungroup
 Sequential Output Inversion

Problem:
If you are inferring an asynchronous set pins in RTL
If your library has only Registers with asynchronous clear
pins

Solution: Inverting the output phase of Sequential Elements

You can allow Design Compiler to map to the opposite type of register and invert
all the data inputs and outputs by using

set compile_seqmap_enable_output_inversion true

compile_ultra -no_seq_output_inversion
 Boundary Optimization

Propagates:
Constants
Equal and opposite information &
Unconnected port information
Across the Hierarchies

By default, DC does boundary optimization. To disable use the following switch

compile_ultra -no_boundary_optimization

Disable boundary optimization for a hierarchy

set_boundary_optimization <cell_name> false
 Retiming

Retiming is a sequential logic/circuit optimization technique that moves registers

forward or backward across combinational elements in a circuit.

Types of Register Retiming:

Forward Retiming: removing a fixed number of registers from each input of a gate
and inserting the same number of registers at the output.
Backward Retiming: removing a fixed number of registers from the output of a gate
and insert the same number of registers in front of each gate.

Advantages:
Min-period: minimize the clock period of the circuit
Min-area: minimize the number of registers in the circuit
Constrained min-area: minimize the number of registers in the circuit subject to a
maximum constraint on the clock period, or indicate failure if the target period cannot be
achieved.
Reduce the power consumption and logic synthesis
 Retiming (Example)

Case A: simple circuit

Clock period -> 6 units; Registers => 4

Case B: Retiming for minimum Registers

Clock period => 4units; Registers => 3

Case C: Retiming for minimum period

Clock period => 2units; Registers => 4

compile_ultra -retime #adaptive retiming, improves WNS, works best with general non-pipelined logic
optimize_registers #minimizes clock period, minimizes register count, executes incremental optimization
of the combinational logic. Performs retiming of sequential cells for pipelined designs
balance_registers #minimizes clock period, performs sequential mapping after moving registers
 Removing Unnecessary Registers

Removing unconnected registers

registers that do not drive any load
combo logic associated with the input of the register can also be deleted if the cell is not used
elsewhere in the design.

set compile_delete_unloaded_sequential_cells [true|false]

Eliminating constant registers

Certain registers in a design might never change their state because they have
constant values on one or more input pins.

set compile_seqmap_propagate_constants [true|false]

Set compile_seqmap_propagate_high_effort [true|false]
What if while elaborating or reading RTL, these unloaded sequential cells are removed from
design?
control it using hdlin_preserve_sequential variable
 Register Replication

Replicating registers can address

 Timing QoR,
 Congestion and
 Fanout issues

TOPO Placement aware, can help reduce congestion in some cases

WLM Load of the original replicated register is evenly distributed among the new
replicated register

set_register_replication
 Merging Equal and Opposite Registers

Equal in all states (can be reached from the reset state)

Applies the same to opposite states

Advantages:
Reducing Registers
Logic Optimization

By default, DC does this optimization

Fixing Nets Connected to Multiple Ports

-feedthroughs

-outputs

-constants

-buffer_constants

DC uses assign statements in the Gate Level Netlist to represent such nets.
Backend tools could potentially have problems with assign statements

Default Behavior: Tool doesn’t fix them Use command: set_fix_multiple_port_nets

set_fix_multiple_port_nets -all -buffer_constants

 Commands, switches & variables
compile_ultra <switches>
Switch What it does

-no_autoungroup Automatic Ungrouping – Disabled

-no_seq_output_inversion Sequential output inversion – Disabled

-no_boundary_optimization Boundary Optimization – Disabled

-retime Register retiming – enabled

-gated_clock Clock gating – enabled

Topic Commands

Register Retiming optimize_registers

balance_registers

Register Replication set_register_replication

Buffering Multiport Nets set_fix_multiple_port_nets -all -buffer_constants

Remove unloaded registers set compile_delete_unloaded_sequential_cells true

Eliminating constant registers set compile_seqmap_propagate_constants true

set compile_seqmap_propagate_high_effort true
Thank You!