Fundamental of Loic Synthesis

Fundamentals of Logic Synthesis
with Design Compiler

Imran Mirza
Course Agenda:
ASIC Design Flow

Fundamental synthesis concepts.
DesignWare Libraries.
Levels of Optimization.
Design Compiler tool Interface.
Synthesis Setup
Library Overview
Reading Design
Defining Constraints.
Environmental Constraints.
Uniquify.
Compile strategies
Saving Results & Report generation.
STA Basics & Delay Calculation.
Timing Exceptions.
Multiple/Virtual clocks.
Help.
Verdana regular 7pt.
Legal text goes here
09.14.05
Verdana Bold 8 write title of presentation here
ASIC Design flow

Application Specific Integrated Circuit (ASIC) is silicon design
targeted for a specific application.
FPGA (Field programmable Gate Arrays that are pre-manufactured
and design independent. These contain number of design blocks that

are programmable vis switch matrix.
High level flow for Synthesis based ASIC design flow:
Product Idea.
Functional specification.
RTL/HDL coding .
Functional simulation & Analysis
Logic Synthesis.
Static Timing Analysis (STA).

Physical Synthesis.
Verification tasks (STA,GLS,FV etc.)
Place & Route.
Extraction
Post Route STA.
Post Route Optimization
Physical Verification (LVS/DRC)
Tape out for chip manufacturing.
09.14.05
Some Key Terminologies & Definitions

Logic Synthesis is a process by which a circuit represented in an
abstract form of HDL/RTL is implemented in terms of logic gates.

Alternatively, it can simply be defined as a process of transforming
RTL description of a design into standard cell gates of technology
library.
Standard Cells represent logic cells that belong to a technology
library that is characterized for a particular process. e.g. AND, OR,

INVERTER, Flip Flops etc.
Netlist is post synthesis abstraction of a design.

Netlist description represents a design in terms of an
interconnection of Std cells that are connected via wires also

referred to as nets in Synthesis world.
Netlist representation of a design is used for down stream flows
during ASIC flow. e.g. for gate level simulation and place & route
etc.
09.14.05
Major Synthesis Steps

Synthesis process is comprised of 3 main steps of Translation,
Optimization & Mapping.
Translation is a process of converting RTL description into intermediate

format represented in form of Boolean equations. Boolean form is than
implemented using intermediate generic cells (GTECH). GTECH cells
simply describe functionality without any timing info and other
characteristics.
Optimization is a process of finding optimal solution to intermediate logic
structures/equations based upon a criteria (constraints) specified before
synthesis.
Mapping is process of translating optimized generic gates to cells in target
technology library (Std. Cell Library).
HDL
If (sel == 1) {
Translation
GTECH
Out <= z }

09.14.05
Optimize +
Mapping
Target_library
(p1265)
Synthesis Steps cntd.

Typically, after initial mapping during synthesis process; synthesis
tools continue to perform iterative Optimizations & Mapping steps in

an effort to achieve the best solution.
Initial optimization phase involves technology independent algorithms to
select best structure for logic functions.
During mapping circuit logic is mapped to gates of technology library to
transform the circuit to network of gates.
Followed by technology dependant optimization algorithms to perform
further logic minimization.

09.14.05
Design Ware (DW) Libraries

DW library is a selection of technology independent and pre-verified
synthesizable IP blocks supplied by synopsys.
DW libraries are used during High Level Optimization (HLO) of

synthesis process.
DW IP blocks range from simple logic functions of AND,NAND,NOR to

arithmetic functions (+,-,<= i.e. adders, comparators, ALU etc.). As
well as complex IPs like DSP cores (FIR, IIR filters etc.).
Structure of DW IP Library consists of two parts:

Design Library
Ckt. Description of various IP

architecture.
(parameterizable)
09.14.05
Synthetic Library
Binary file that associates ckt. in design

Library with synthesis tool.
HDL
Operators in HDL (+, - etc.)
Synthetic library
Synthetic Operators
ADD_UNS_OP
High Level Optimization tasks like
resource sharing etc. is related
to this phase
Have Bindings to Synthetic

Modules :
ADD_SUB
ADD
ALU
Several Implementations
Of Modules Exist in
Design Library
Ripple
CLA

09.14.05
Custom IP
Implementation selection
Of synthetic modules is done from
various implementation
available in Design Library.
During Optimization process
Constraint-driven Implementation
Selection takes place to meet
timing/area goals. DW
implementation is eventually
mapped to target-library and
further optimized.
3 Levels of Optimization
Logic Optimization occurs at 3 levels:
Architectural
Logic
Gate Level.
After initial high level architectural optimization, Design Compiler

mostly iterates between Logic & Gate level optimization.
DC moves the logic functions back and forth between logic & gate
level representations to fully take advantage of various optimization

techniques.
Optimization process continues until no further improvements in the

logic structure are possible.
i.e. No further improvements to Optimization Cost function are

possible.
Note: These optimization steps can be guided by user.

09.14.05
Architectural Optimization: This type of Optimization
occurs
on HDL description and is also referred to as high level optimization
(HLO). It includes several sub phases:
DW Implementation Selection.
Arithmetic or Data path Optimization.
Resource sharing.
Reordering operators.
Design is represented in terms of GTECH cells after HLO.

Except DW Implementation most of the above mentioned tasks
occur only in the beginning i.e. during optimization of unmapped

design. Therefore it is technology independent.
Implementation selection is the process of mapping HDL logic to a

library of DesignWare (DW) components (also reffered to as
GTECH).
Initial mapping to DW is constraint independent. But later in the process

synthesis tools evaluate speed/area tradeoffs to select best
implementation e.g for adders selecting carry look-ahead (for speed) or
even better Brent-Kung (fastest) vs ripple carry (smallest) etc.
10
09.14.05
Implementation Selection process:

(HDL)
Z <= X+Y
Operator Inference
+
Timing driven
Synthetic Operator
Area driven
r
CLA
Ripple Carry

11
09.14.05
Constraint driven Implementation

Selection
Resource Sharing
Resource Sharing is HLO technique. It can occur during
implementation of +,-,*,>,< operators.
Resource sharing can happen if resources are in the same block
i.e. always statement of Verilog (or process block in VHDL).
For example if two adders have same destination path to a
MUXED output than resource sharing can take place if constraints
are meet:
If (ctl) {
z = a + b;
else
z = c + d;
Resource sharing reduces the amount of hardware needed to

implement HDL operation resulting in smaller area.

12
09.14.05
Arithmetic Optimization:
Arithmetic Optimization uses simple rules of algebra to improve
designs performance/area.
For example arithmetic expression a+b+c+d can be implemented
using 3 level cascaded addition operation or faster logic with 2-levels

cascaded operation via Rearranging Operators
Identifying arithmetic expressions & optimization is sometimes

called data-path synthesis.
3 level cascaded addition

a+b+c+d
+
+
+
+
+
+
13
09.14.05
After arithmetic
optimization (rearranging
opertors) 2 level
cascaded addition
(a+b)+(c+d)
Logic Optimization: After high level architectural optimization,

design is represented in terms of GTECH components.
Logic optimization works on GTECH representation (representation after

elaborate).
During logic synthesis, tools try to improve logic structure by reducing
SOP form via minimization of product terms. This is achieved using 2
techniques:
Structuring.
Flattening.
Structuring: It is the logic optimization technique by which tool
adds intermediate variables and logic structures to a design,

resulting in reduced logic area. Typically tool tries to search for subfunctions that can be factored out.
It is ON by default in timing driven mode. i.e. timing driven structuring
improves structures on critical paths without touching non-timing critical
logic paths.
Structuring works best on random logic strcutures such control logic. It is
not very effective on adders, ALUs etc.
14
09.14.05
Example of Structuring:
Before structuring:
func_1 = ab + ac
func_2 = b + c+ d
After structuring:
t0 = b + c
func_1 = t0.a
func_2 = t0 + d
DC command to play with structuring options is set_structure.

15
09.14.05
Before
structuring
A
B
func_1
func_2
D
After
Structuring
A
B
func_1

16
09.14.05
func_2
Flattening: Flattening is a logic optimization technique by which all

intermediate variables are removed; consequently related logic
structures.
Boolean distributive laws are used to remove all parenthesis. Removing

poor intermediate variables helps synthesis tools to achieve more efficient
functions.
Flattening is off by default because default timing-driven structuring can
improve critical paths & flattening can potentially increase area.
It is independent of constraint unlike structuring.
Result of flattening is a two level Sum of Product form
Result of flattening can be input to structuring phase to find optimal
solution to logic equations.
Example:
Before flattening
out = t1 t2
t1 = a + b(c + f)
t2 = d + e
After flattening
out = ad + bcd + bdf + ae bce + bef
17
09.14.05
Gate Level: Gate Level optimization works on a generic netlist
created by logic synthesis to produce technology specific netlist (i.e

netlist mapped to gates in target technology library).
Based upon constraints; this process implements the fastest and smallest
circuit implementation in terms of logic gates from technology library.
Several things happen during gate level optimization:
Mapping:
Mapping to gates to meet constraints, can be controlled by compile
command.
Delay Optimization:
Goal is to fix timing violations introduced during mapping phase.
DRC violations are not fixed.
DRC optimization:
DRC fixing is done. At first DRC fixing is attempted without affecting
timing/area goals. But if necessary DRC fixing takes place at the
expense of timing/area.
Area Optimization:
Last optimization function to fix. DC does not allow area-recovery at
the expense of timing & area constraints.
18
09.14.05
Snippet from DC log file:

Beginning Pass 1 Mapping
-----------------------Processing 'mux2_32_1
Processing 'edff1_32_0
Beginning Implementation Selection
---------------------------------Processing 'eu_spedp_DW01_cmp2_5_0
Beginning Mapping Optimizations (Ultra High effort)
Structuring 'eu_staging'
Mapping 'eu_staging'
Beginning Delay Optimization Phase
---------------------------------Beginning Design Rule Fixing (max_transition)
----------------------------

19
09.14.05
Figure showing Internal operations during

Optimization
Structuring
Flattening
Logic Level
Gate Level
Mapping

20
09.14.05
Design Compiler (DC) tool Interface.

Design Compiler (DC) is industry standard Logic Synthesis tool from
Synopsys.
Tool interface and commands used for this training will be DC

centric.
Constraints
WLM
RTL/Netlist
Design Compiler
Synthesized
database i.e.
Netlist/ddc
21
09.14.05
Technology
Library
Synthesis
Reports
Macro
Library
Main steps during typical synthesis process.

Synthesis setup
No
Read Design & Libs
Read Constraints
No
Synthesize
Generate Reports & Save
Outputs
Analyze
No
Good

22
09.14.05
No
Yes
Done
Synthesis Setup
Some basic variables to be included in synthesis setup are as
follows:
target_library: Specifies the library used by synthesis during
optimization process to map logic to standard cell gates from specific

technology library. e.g. p1265_lp_rsss_1.15v_110c.db.
Traditionally this is a single library.
New features in DC allows for multiple libraries (MVDD, MVT etc)
link_library: This variable contains the names of all libraries that are
used to link the design. i.e. standard cell and macro libraries that
contain leaf cell definitions of cells instantiated in the design.
In DC, term link is used to imply resolving references of all
instances in the design. Or simply put find all references in the
design.
Linking also Means Correct Design Composition w.r.t cell names,
ports/pins directions, vector range and connectivity etc.
In a hierarchical design the lower level designs themselves become
part of link variable collection.

23
09.14.05
Synthesis Setup
search_path: Is used to include paths to directories containing
target_library, link_libraries and any reference designs. Tool searches for

libraries & ref designs in all directories specified with search_path
variable.
synthetic_library: This is an optional variable and points to DesignWare
libs. Basic DW libs are loaded by default. Use this to add advanced
libraries.

24
09.14.05
Setup Examples:
Example:
set
set
set
set
link_library {* p1265_lp_rsss_1.15v_110c.db}
target_library {p1265_lp_rsss_1.15v_110c.db}
synthetic_library {dw_foundation.sldb standard.sldb}
search_path [concat /nfs/adg_pde_8/Eval65/library/stdcell_lp_frams/LM \
$search_path]
OR
set search_path /nfs/adg_pde_8/Eval65/library/stdcell_lp_frams/LM \
$search_path
Example:
module test_fub (a, z);
inputs a;
outputs z;
sub_fub_1 U1 (.a(a), .b(net_1));
sub_fub_2 U2 (.m(net_1), .o(z));
endmodule
25
09.14.05
Example cntd.
Dir1/test
Libs/
p1265_lp_rsss_1.15v
_110c.db
Src/
test_fub.v
sub_fub_1.v
Tmp/
sub_fub_2.ddc
set link_library {* p1265_lp_rsss_1.15v_110c.db}

set target_library {p1265_lp_rsss_1.15v_110c.db}
set synthetic_library {dw_foundation.sldb standard.sldb}
set search_path [concat ./src $search_path]
read_verilog sub_fub_1.v
read_verilog test_fub.v
Current_design test_fub
Link
Error: Unable to resolve reference sub_fub_2.
To fix this Error edit search_path as follows:

set search_path [concat ./tmp $search_path]
OR
lappend
search_path ./tmp
Verdana
regular 7pt.
26
09.14.05
Technology Library
Lets examine technology library a little (p1265_lp_rsss_1.15v_110c.lib):
library ("p1265_lp_rsss_1.15v_110c") {
/* **************************************************************************
* Intel Confidential
****************************************************************************
revision : "lp_lib";
date : "Mon Aug 22 14:22:11 MST 2005" ;
comment : "PROCESS: p1265, MODEL: lp, VOLTAGE: 1.15v, TEMP: 110c, SKEW: rsss; " ;
/* ************************************
** UPF used : p1265_1x0r1v1.upf
** Shrink applied : 1
************************************* */
technology (cmos) ;
delay_model : table_lookup ;
time_unit : "1ps";
pulling_resistance_unit : "1kohm" ;
capacitive_load_unit(1,pf) ;
voltage_unit : "1V" ;
current_unit : "1uA" ;
leakage_power_unit : "1pW" ;

27
09.14.05
Library header cntd:

operating_conditions("rsss_1.15v_110c") {
process : 1.0;
temperature : 110.00;
voltage : 1.15;
tree_type : "balanced_tree";
}
nom_process : 1.0 ;
nom_temperature : 110.00;
nom_voltage
: 1.15;
default_max_transition : 1100 ;
default_fanout_load : 1.0 ;
default_output_pin_cap : 0.0 ;
default_inout_pin_cap : 0.010 ;
default_input_pin_cap : 0.010 ;
default_cell_leakage_power : 0.000001;
default_operating_conditions : rsss_1.15v_110c;
default_wire_load_mode : enclosed;
default_wire_load_capacitance : 0.0000873;
default_wire_load_resistance : 0.100;
default_wire_load_area : 15.5;

28
09.14.05
Library Cell Description:

/* Begin cell: lp0in00x6 */
lu_table_template (delay_outputslew_template_5X5_lp0in00x6) {
variable_1 : total_output_net_capacitance ;
variable_2 : input_net_transition ;
index_1 ("1.0, 1.1, 1.2, 1.3, 1.4");
index_2 ("2.0, 2.1, 2.2, 2.3, 2.4");
}
power_lut_template (internalPowerTable_5X5_lp0in00x6) {
variable_1 : total_output_net_capacitance ;
variable_2 : input_transition_time ;
index_1 ("1.0, 2.0, 3.0, 4.0, 5.0");
index_2 ("1.0, 2.0, 3.0, 4.0, 5.0");
}
cell ("lp0in00x6") {
nandgates : 3 ;
area : 3.696 ;
cell_footprint : lp0in00 ;
cell_leakage_power : 49512 ;
pin ("o") {
direction : output ;
29
09.14.05
Lib cell description cntd:

function : "!(a)" ;
max_capacitance : 1.17877 ;
timing() {
cell_fall ("delay_outputslew_template_5X5_lp0in00x6") {
/* Simulation data for spec: `tp_a_xy_o_10_max' */
index_1 ("0.0032143, 0.0915343, 0.2415343, 0.6015343, 1.6575343") ;
index_2 ("25.0000000, 699.9990000, 850.0000000, 1000.0000000, 1100.0010000") ;
values (\
"18.0516507, 80.9752712, 91.3866032, 100.8858463, 107.5135250",\
"62.9328920, 232.2513450, 254.3557764, 274.5694844, 288.2005986",\
"128.4946355, 377.2112071, 411.7081601, 443.4568683, 464.3401994",\
"284.0081877, 616.2618329, 669.1884016, 718.0893649, 749.9088390",\
"740.2694301, 1139.8097050, 1214.0552580, 1287.8451130, 1336.2840450"\
);
}
cell_rise ("delay_outputslew_template_5X5_lp0in00x6") {
index_1 ("0.0032143, 0.0915343, 0.2415343, 0.6015343, 1.6575343") ;
index_2 ("24.9990000, 700.0010000, 850.0000000, 1000.0000000, 1100.0010000") ;
values (\
"15.2790723, 0.0000000, 0.0000000, 0.0000000, 0.0000000",\
"61.2986975, 145.3533894, 149.7023032, 153.4330957, 153.3298057",\
"131.3437529, 290.6696952, 307.1302922, 321.4521477, 327.8411756",\
"299.1350892, 533.7899475, 568.5006742, 599.4795268, 616.5449063",\
"791.1555851, 1082.2604470, 1135.6769800, 1186.8994620, 1217.9290430"\
);
}
30
09.14.05
fall_transition ("delay_outputslew_template_5X5_lp0in00x6") {

index_1 ("0.0032143, 0.0915343, 0.2415343, 0.6015343, 1.6575343") ;
index_2 ("25.0000000, 699.9990000, 850.0000000, 1000.0000000, 1100.0010000") ;
values (\
"10.1024224, 96.0716241, 113.2238550, 129.4873606, 141.0555352",\
"56.7503343, 196.0574868, 220.1910273, 244.6424514, 260.7628678",\
"136.9945580, 295.4627289, 326.1557160, 355.8550934, 376.5465104",\
"334.6133697, 484.4706030, 520.9409643, 559.2599686, 582.9060445",\
"920.5215483, 1025.3939690, 1060.9164640, 1088.7083360, 1114.7036800"\
);
}
rise_transition ("delay_outputslew_template_5X5_lp0in00x6") {
index_1 ("0.0032143, 0.0915343, 0.2415343, 0.6015343, 1.6575343") ;
index_2 ("24.9990000, 700.0010000, 850.0000000, 1000.0000000, 1100.0010000") ;
values (\
"12.0370839, 100.1307945, 116.6247064, 132.6044484, 143.3954581",\
"76.5285867, 214.6937751, 240.8224270, 263.3653485, 278.8470840",\
"192.3296389, 341.3812802, 372.7134246, 403.8706037, 422.3452089",\
"468.3673746, 591.1956305, 628.3677618, 665.3410636, 689.3084127",\
"1284.3755410, 1348.5314550, 1386.3845050, 1424.2627460, 1438.6392750"\

);
}

31
09.14.05
timing_sense : negative_unate ;
related_pin : "a" ;
}
}
pin ("a") {
capacitance : 0.00965679129 ;
direction : input ;
}
}
/* End cell: lp0in00x6 */

32
09.14.05
Read Design
Commands to read design:
read_file -format verilog rtl_file_name
read_file -format vhdl rtl_file_name
analyze/elaborate i.e:
Preferred Method
define_design_lib work -path ./worklib
for RTL designs
analyze -f verilog ${DESIGN}.v
elaborate ${DESIGN}
analyze reads RTL description and if there are no syntax issues; saves
the intermediate binary format to work library.
elaborate is used to to actually build the design, so its ready for
synthesis with compile command.
If input format is RTL, analyze/elaborate commands are

recommended.
If input format is gate level netlist use read_file commands.

33
09.14.05
DC script building with commands learned

Lets start building a script using commands as we learn them:
Setup file .synopsys_dc.setup will look like :
set sh_enable_line_editing true
set text_editor_command {xterm -fn 8x13 -e vi %s &}
set link_library {* p1265_lp_rsss_1.15v_110c.db}
set target_library {p1265_lp_rsss_1.15v_110c.db}
set synthetic_library {dw_foundation.sldb standard.sldb}
set search_path "./rtl
/nfs/ch/disks/ch_com_disk026/design_kit/p1265_1/stdcell_lp/synthesis/1.3/synopsy
s/2000.11 $search_path
Lets start synthesis script training.tcl:

source -echo read_file
analyze -f verilog ${rtl_list}
elaborate exunit

34
09.14.05
Constraining the Design

Design constraints are circuit goals to ensure that final chip works
after manufacturing. They are used to specify performance (timing),

area & power goals of your design.
Optimization process uses design constraints to guide the tool to

achieve required goals. Constraints are classified under following
categories:
Optimization Constraints.
Design Rule Constraints.
Environmental Constraints (operating conditions, K-factor & WLM etc.).
Optimization constraints are timing, area constraints.

Design Rule Constraints are electrical requirements that must be
meet to ensure chip functionality e.g. max_capacitance,
max_fanout, max_transition etc.
35
09.14.05
Optimization Constraints
Timing Constraints: Are used to specify designs timing specifications
to guide synthesis process.
By default timing constraints have higher priority over area.

Order of cost priorities can be changed (to be discussed later)
Clocks are used to specify operating frequency of the design.
Clock definition is needed to constrain internal paths i.e. flop2flop paths.
create_clock -name clk -period 15000 [get_ports clk]
In pre-layout synthesis clocks created with create_clock are assumed
ideal by default.
Ideal nets are nets with zero delay (i.e. 0 clock network latency &
transitions).
DC synthesis does not insert any buffers/inverter on clock nets i.e. timing
check & optimization is off.
Ideal nets are also free of DRC constraints.
36
09.14.05
Clock uncertainty
Clock uncertainty is used to model difference in arrival time of clock
edges. It includes following items:
Clock Jitter:
Jitter is the unpredictability of the PLL/Oscillator output in terms of exact time
when a clock edge is going to arrive.
A perfect oscillator would have rising edges occurring at precise moments in time
that would never vary. This, of course, is impossible in real electronics, which have
sources of noise and other imperfections.
Expected Clock Skew.

Process Guardband.
In DC uncertainty is specified using following commands:

set_clock_uncertainty 500 [get_clocks clk]
set_clock_uncertainty 200 -from [get_clocks clkB] -to [get_clocks
clkA]

37
09.14.05
Clock Latency
Clock latencies are used to model delay in clock network.
Clock source latency models clock insertion delay to the
clock definition point. i.e. time taken by clock signal to
propagate from clock generation point to clock definition
point.
Clock network latency is used to model delay due to clock
network from clock definition point to register clock pin.
set_clock_latency 1000 [get_clocks clk]
NOTE: Use -source option to model clock source latency.
Clock Source Latency can be used to model reality of top
level tree delay in a hierarchical chip (if there is huge
difference in clock arrival time between APR blocks).

38
09.14.05
Figure 1: Clock constraining internal timing

Flop 2 Flop path w.r.t 66 MHz
clock Frequency
Combinational
logic
Clock Definition
point
CLK
CLK
PLL
Clock origin
point
Ideal Clock
Clock Launch
Edge
Clock Capture
Edge
15 ns clock period
Non Ideal Clock

39
09.14.05
skew + jitter
etc.
Constraining Interface Paths

Constraining the Input Path.
Your inputs come from the outside world or blocks designed by other
designers. When do they come during the clock cycle? Do they come at
4ns after the rise of clock ?
The synthesis tool needs to know this to figure out how much time it
really has left to meet the timing on path.
set_input_delay -max 4000 -clock clk [get_ports A]
This tells the tools that external world uses 4000ps (4ns) of time based on
the clock period of clk. If clk was 66MHZ (15ns) the tool has 15-4 = 11ns
for all it internal logic.
For setup analysis, input_delay is the worst case delay value (-max).
For hold analysis, input_delay will be the best case delay value (-min). i.e.
shortest delay value.

40
09.14.05
set_driving_cell
This command impacts input ports transition delay and is a DRC
constraint in reality.
It helps with more accurate timing calculation on input ports by

annotating non-zero transition delay on input ports.
There can be more optimistic input path timing without modeling
input transition time. Without set_driving_cell at input ports, default

transition delay is zero.
set_driving_cell -library p1265_lp_rsss_1.15v_110c -lib_cell lp0bf00x3 pin o
[remove_from_collection [all_inputs] [all_clocks]]
To be pessimistic use a weak cell driving the inputs ports.

set_input_transition is another way of doing the same thing.

41
09.14.05
set_output_delay
It constrains output interface. i.e

set_output_delay 7000 -max -clock clk [get_ports B]
This means that out of 15 ns of clock cycle time available; 7 ns is taken by

external logic. i.e. 15-7=8ns is the remaining time left for logic cone ending in
port B.
Note: set_input_delays are applied w.r.t launching clock edge and
set_output_delay is done w.r.t latching clock edge.
Input/Output Delays
set_input_delay
set_output_delay
4 ns
CK 1
CK 1
create_clock

42
09.14.05
7 ns
CK 2
Set_load
On output ports need to specify external capacitive load to accurately

calculate timing and accordingly size the driver of output ports during timing
optimization. Command to use is set_load e.g.
set_load load_value [get_ports]
or
set_load [expr [load_of p1265_lp_rsss_1.15v_110c/cell/pin] * 2] [get_ports A]
Usually it is specified on output ports but can also be specified on input ports.
But not recommended for input ports as it can make input loading constraint
unnecessarily pessimistic since usually set_max_capacitance is already
used for input ports.
For budgeting of set_load on output ports, its a good idea to have design
knowledge to gauge how many blocks does the output port talk to.
set_load sometimes is also referred to as environmental constraint.

43
09.14.05
Training.tcl
Now state of training.tcl script is:

elaborate exunit
current_design exunit
link
set_clock_uncertainty -setup 450 [all_clocks]
set_input_delay 750 -max -clock clk [remove_from_collection [all_inputs] [all_clocks]]
set_output_delay 750 -max -clock clk [all_outputs]
set_load [expr [load_of p1265_lp_rsss_1.15v_110c/lp0an02x2/a] * 2] [all_outputs]

44
09.14.05
Area Constraint
To enable area optimization in DC you need to use:
set_max_area 200
By default DC performs very little area optimization as timing has

higher priority over area cost unless higher priority is placed on
Area.
By default area optimization happens only on paths that meet

timing.
Typically value for area constarint used is set_max_area 0. Tool

tries to achieve the smallest area possible.
Area optimization can be turned off by using a switch to compile

command.
Area units are dependant upon library. i.e. area is usually in terms of
sq. microns. It can be normalized in terms of NAND gates.
45
09.14.05
Design Rule Constraints

Design Rule Constraints (DRC) must be meet to ensure that design
functions correctly.
DRC have higher priority than optimization constraints.

DRC constraints are typically defined by default in technology library
for the tool to use.
User can also specify explicit DRC constraints.

Synthesis tool will try to meet more restrictive constraints.
DC tries to address DRC violation using repeater insertion & cell
sizing techniques.
Types of DRC:
Maximum transition time
Maximum fanout
Minimum and maximum capacitance
46
09.14.05
set_max_transition
max_transition constraint on net is defined as the longest time
required by the driving pin of the net to change its logic value.
By default DC computes transition time using timing data in target
technology library depending upon the type of delay model used in

library i.e. CMOS delay model or non-linear delay model etc.
Optionally, explicit and more restrictive transition times can also

specified on net, ports, designs etc. using command
set_max_transition.
In the presence of implicit library drived max_tran & explicit
set_max_transition, DC adheres to more restrictive constraint.

47
09.14.05
set_max_capacitance
Max_capacitance design rule constraint is also imposed implicitly via
technology library.
DC compiler tries to ensure that total capacitive load on a net (i.e.

interconnect cap + load pin cap ) is less than max_capacitance
attribute of driver pin.
Explicit max_capacitance attribute can also be specified on design or

input ports using command, set_max_capacitance.
In presence of both library max_capacitance & designs
max_capacitance value, DC adheres with more restrictive constraint.

Note: max_tran & max_fanout constraint also impact
max_capacitance constraint of nets indirectly.

48
09.14.05
set_max_fanout
Max_fanout is another type of DRC constraint that can be placed on
a design or input ports.
If its placed on a design it applies globally to all driver pins of nets in

the design.
In the presence of global max_fanout on design or explicit

max_fanout on ports, DC honors most restrictive.
If this attribute exists, DC tries to ensure that its meet by ensuring

that sum fanout_load atttribute on all input pins driven by net in
question is less than max_fanout attribute specified by
set_max_fanout command or if implicit default max_fanout
attribute exists in the library.

49
09.14.05
Training.tcl
elaborate exunit
link

#Try to be conservative on your selection of driving cell.

set_driving_cell -library p1265_lp_rsss_1.15v_110c -lib_cell lp0bf00x3 -pin o
[remove_from_collection [all_inputs] [all_clocks]]

50
09.14.05
Constraint priorities
Design Rule constraints have higher priority over optimization constraints.

Default order of constraint priorities honored by DC is as follows:
DRC
Max_delay (setup violations)
Min_delay (hold violations)
Area.
Note: This precedence order can be changed by user, especially the setup/hold priority
DCs optimization algorithms rely on minimizing cost functions.

During Optimization process, DC strives to reduce costs of various types of constraints
down to zero and finally gives up when no further improvements to cost functions are
possible. e.g. Cost function for max_delay constraint is given by sum of worst violator
across all path groups e.g. if there are m path groups:
v1.w1 + v2.w2 + v3.w3 + +vm.wm
Where :
v = worst violator of given group.
w = weight assigned to each path group.

51
09.14.05
Environmental Constraints
In addition to set_driving_cell, set_max_capacitance,
set_max_transition & set_load etc. , there are few other things that
are important for defining designs environment.
Operating conditions.
Wire load models.
K-factor.
During optimization DC, scales cell & net delays extracted from
lookup tables based on the operating conditions defined in
technology library.
Operating conditions consider variations in process, voltage &

temperature (PVT). Operating conditions are specified using
command:
set_operating_conditions max rsss_1.15v_110c max_library
p1265_lp_rsss_1.15v_110c min rfff_1.50v_n30c min_library
p1265_lp_rfff_1.50v_n30c
If no operating conditions are specified, DC picks defaults specified

via library variable, default_operating_conditions
52
09.14.05
K-Factor
K-factors are used to simulate alternate choices for cell delays in the
timing libraries by using a scaling factor (less than or greater than
1.0).
It is not possible to characterize 1000s of stdcell for all possible

silicon applications in a particular process.
So, library developers typically re-design/characterize few sample cells

and find a number thru extrapolation to be used in timing alalysis.
Operating Conditions and K-factors can be embedded in the .lib file

or can be defined through tool commands (DC/PC/PT/Astro).

53
09.14.05
P1265 example
To report operating conditions you can do:

dc_shell-xg-t> report_lib
p1265_lp_rsss_1.15v_110c
nom_process : 1.0 ;
nom_temperature : 110.00;
nom_voltage
: 1.15;
These are the nominal values for

PVT, on which the delay scaling
formulas are based that scale delays
from lookup tables. Numbers defined
inside Operating Condition section
are deviations from the nominal
values.
operating_conditions("rsss_1.15v_110c") {
process : 1.0;
temperature : 110.00;
voltage : 1.15;
tree_type : "balanced_tree";
}
Note: balanced_tree is an interconnection
delay model for driving pin & network loads.
54
09.14.05
The Value Associated with

process is called K-factor
in almost all cases. We
typically never change the
temperature and voltage.
P861.6 example
nom_voltage :1.39;
nom_temperature : 113.0 ;
nom_process : 1.0 ;
This library contains operating

conditions with multiple K-process
factors. Notice VT does not change
from nominal values.

55
09.14.05
operating_conditions("slow_1.00") {
process : 1.00 ;
temperature : 113.00 ;
voltage : 1.39 ;
tree_type : "balanced_tree" ;
}
process : 1.01 ;
voltage : 1.39 ;
}
process : 1.02 ;
voltage : 1.39 ;
}
process : 0.93 ;
voltage : 1.39 ;
}
Delay Scaling Formula with K-Factor

D(scaled) = D_original_from_LookUp_Table(1 + d'process * K-process) \
(1 + d'temp * K-temp) \
( 1 + d'voltage * K-voltage)
Where,
dprocess
= (process_operating_cond - process_nominal )
dtemp
= (temp_operating_cond - temp_nominal)
dvoltage
= (voltage_operating_cond - voltage_nominal)
In most cases
K-process for cell_rise/fall = 1
K-process rise/fall_transition = 1
K-voltage = 0
K-temp = 0
Hence in most cases:
D(scaled) = D_original_from_LookUp_Table (1 + d'process * K-process) (1 + 0) ( 1 + 0)
= D_original_from_LookUp_Table (1 + d'process * K-process)

56
09.14.05
Wireload models.
WLM contain information to estimate nets interconnect delay (i.e nets RC) and area etc.
WLM are statistical estimates based on nets fanout numbers.
Estimates are generated based upon designs that have gone thru place & route and
used same process technology in the past.
wire_load_table("1.9_million") {
fanout_length( 1, 20.8158);
fanout_capacitance( 1, 0.0055);
fanout_resistance( 1, 35.2344);
fanout_area( 1, 2.1840);
fanout_length( 2, 50.1063);
fanout_capacitance( 2, 0.0133);
fanout_resistance( 2, 70.4688);
fanout_area( 2, 2.7300);
Command:
set_wire_load_model -name "poulsbo2d_core_custom_wireload" -library
"poulsbo_custom_wireload"

57
09.14.05
Uniquify the design:

You are almost ready to start synthesizing, there is one last thing
that need to be done before Compile.
If block to be synthesized contains multiple instances of some

reference design than we need to uniquify the synthesis block.
Command used:
uniquify.
Its to ensure that each instance of reference design is synthesized in

its own environment (output loading, input transition etc.).

58
09.14.05
U1
U2
Fub_A
Before
Uniquify
Fub_B
U3
Fub_A
U1
U2
Fub_A_0
After Uniquify
Fub_B
U3
Fub_A_1

59
09.14.05
Compile Strategies
You are now all prepped up to start design optimization.
Primarily two types of synthesis approaches are commonly used.
Top-down vs bottoms-up:
Top-down:
partition
-------------
unit_A
unit_B
unit_C
Bottoms-up:
partition
-------------
unit_A -------------
unit_B -------------
unit_C -------------
Compile.
link here or compile top

Compile
Compile
Compile

60
09.14.05
Advantage and Disadvantages

Top Down
Pros:
Only top level constraints needed

Better results due to optimization across boundaries
Cons:
Longer Compile Times

Incremental Changes require complete re-synthesis
Bottom Up
Pros:
Sub-blocks changes shorter turn-around time.
Divide & conquer approach and maybe somewhat easy to debug issues.
Cons:
Many scripts to coordinate, update, and budget
Top level may need incremental compile to fix DRC

61
09.14.05
Compile Strategies
There are endless design optimization strategies that can be tried.

Lets take a look at some common synopsys suggested strategies.
1) Run compile with default settings i.e:
compile -map_effort medium scan
if constraints meet, you are done.

2) If initial compile does not work, you can try tightening the constraints by
10% to 15%.
3) Try two pass back2back compile approaches i.e.
compile -map_effort medium scan
compile -incremental_mapping scan map high
For 2nd pass you can also use following without high effort; if only gate level remapping will fix issues:
compile -incremental_mapping scan

62
09.14.05
Compile Strategies cntd.

4) Use DC Ultra license feature. DC ultra uses advanced critical path
resynthesis (CPR) algorithms when used with high effort compile to
improve performance. This feature is turned on with set_ultra_optimization
command.
Set_ultra_optimization helps with critical path synthesis by duplicating fanin cones to

reduce loading of critical paths.
It also maps to complex wide fanin cones.
5) Use critical_range during synthesis (will be discussed in Advanced section).

6) Perform path group segregation using group_path approach.
7) Several things can be tried with DesignWare Components. E.g. if critical path
contain DW components, ungroup DW hierarchy for further optimization.
8) Ungroup smaller designs if they contain critical path to take advantage of
logic merging.
9) For area critical designs compile for area first followed by timing if timing is
easily meet.
10) Constant propagation with set_logic_one, set_logic_zero, set_unconnected,
set_logic_dc etc. it simplifies logic connected to constants.
63
09.14.05
Compile options switches/options

dc_shell-xg-t> compile -help
Usage: compile
# compile design
[-map_effort effort] (map effort: low, medium, high)

[-area_effort effort] (area effort: none, low, medium, high)
[-incremental_mapping] (perform only incremental mapping changes)
[-exact_map]
(sequential cells to be mapped exactly as indicated in HDL)
[-ungroup_all]
(ungroup all hierarchy)
[-boundary_optimization]
(optimize across hierarchical boundaries)
[-auto_ungroup automatically ungroup small hierarchies]
(auto ungroup: area, delay)

[-no_design_rule]
(don't fix design rules)
[-leakage_mode]
(Use leakage power as the secondary cost)
[-no_map]
(don't map design; leave as generic logic)
[-only_design_rule]
(only fix design rules)
[-only_hold_time]
(only fix hold time violations)
[-top]
(optimize the interface logic of the hierarchical sub-designs)
[-scan]
(replace all sequential elements by scan equivalent)

64
09.14.05
Power of compile_ultra
This is one of the new feature of DC that provides push button
approach to achieving convergence for high-performance designs.
Embedded two-pass approach under the hood.

No need to use two back to back runs like compile. But it wont
hurt to try
Uses DC-Ultra license & feature.

This command does delay-based auto ungrouping of design
hierarchies by default.
By default, it ungroups DW hierarchies during 2nd pass phase.

Hierarchical boundary-optimization also turned ON by default.

65
09.14.05
Compile_ultra switches/options
dc_shell-xg-t> compile_ultra -help
Usage: compile_ultra
# compile design
[-no_autoungroup]
[-no_uniquify]
[-exact_map]
indicated in HDL)
[-scan]
equivalent)
(supress delay-based auto_ungroup)

(no uniquify is needed)
(sequential cells to be mapped exactly as
(replace all sequential elements by scan
[-no_boundary_optimization]
(do not run hierachical boundary optimization)
66
09.14.05
What is boundary Optimization?
Boundary optimization is a process

of optimizing across hierarchical
boundaries in DC.
Optimizing across hierarchical
boundaries can perform logic
merging by moving logic across
hierarchical boundary, if it results in
better logic optimization.
By default, in DC boundary
optimization is turned off.
Boundary optimization can be
problematic from FV perspective.

67
09.14.05
Boundary
Opt (fig 1)
Boundary Opt
(fig 2)
After
Boundary Opt
logic sense of
pin A changes
Advanced Compile strategies with critical_range,

group_path & group/ungroup commands
By default DC works only on critical path in the design.

To enable optimization of near-critical paths, two common approaches used
are:
Synthesis with critical_range.

Grouping specific paths into separate path groups with group_path.
Critical_range Optimization is turned on using set_critical_range command:

set_critical_range 1000 [current_design]
Critical range defines the range of violations over which compile works to
improve violations.
It works on TNS instead of WNS i.e. it works on improving overall delay cost
of the design instead of worst violator by improving near_critical paths.
Improving TNS can make WNS better as a pleasant side effect, if cones of
logic are shared (e.g. incase of structured logic, datapath logic etc.)
Critical_range optimization will not improve sub-critical paths if it worsens

the critical path.
68
09.14.05
group_path
By default DC creates a separate path group for every clock domain
in the design and works on optimizing WNS independently within
each path_group.
WNS in one path_group does not prevent optimization in other
(different) path_groups. i.e. cost function for max_delay only takes

into account worst violator within each path group seperately.
Using Divide & conquer approach with group_path helps by
dividing timing critical designs into possibly several separate path

groups making it easier for DC to meet timing.

69
09.14.05
group_path example:
Example: Consider a design with single clock called clk.
It has internal register to register paths.

I/O to Register
Combinational feedthru paths.
If combinational feed thru path happens to contain critical_path, this

will impact optimization of sequential paths.
Creating following path_group for Feed-thru paths will isolate these

and let DC concentrate on feed-thru paths seperately without
impacting optimization QoR for sequantial path.
group_path name FEED_THRU from [all_inputs] to [all_outputs]

All remaining paths will stay in default clk path group.

70
09.14.05
Example:
You can even further break it down to more path groups, to make
tools job even easier:
group_path name input_interface from [all_inputs]

group_path name output_interface to [all_outputs]
group_path name FEED_THRU from [all_inputs] to [all_outputs]

71
09.14.05
group/ungroup
Removing level of hierarchy is one of the strategies to achieving
desired timing goals.
Command compile_ultra performs delay based ungroup by

defualt.
Similarly compile switch -auto_ungroup can also be used to

enable ungrouping during synthesis.
Note: compile switch for ungrouping is used in conjunction with following

variable settings that define threshold for ungrouping:
compile_auto_ungroup_area_num_cells = "30"
compile_auto_ungroup_delay_num_cells = "500
(if design hier has less than 500 cells compile auto_ungroup delay will ungroup that level of
hierarchy)
In addition, DC provides the capability to modify hierarchy OR repartition blocks using group/ungroup commands.

72
09.14.05
Group/ungroup
Command ungroup can be used remove level of design hierarchy.
This is also referred to as flattening the design.
Usage: ungroup
[-all]
# ungroup hierarchy
(ungroup all cells)
-prefix <prefix>]
[-flatten]
(prefix to use in naming cells

(expand all levels of hierarchy)
[-simple_names]
(use simple, non-hierarchical names)
[-small <n>]
(ungroup all small hierarchy)
[-force]
(ungroup dont_touched cells as well)
[-soft]
(remove group_name attribute)
[-start_level <n>]
(flatten cells from level:
Value >= 1)
[cell_list]
(list of cells to be ungrouped)
To completely flatten the design, you can do:

ungroup all -flatten
73
09.14.05
Group command
Command group is used to create a new level of hierarchy.
Example: to understand group/ungroup:
Consider following hierarchy:

Chip
fub_1
U1
fub_2
U2
fub_3
U3
Lets group instance U1 & U2 into new design called grouped_design
group -design_name grouped_design cell_name U12 {U1 U2}
Now design hierarchy will look like:
Chip
grouped_design
U12
fub_1
U1
fub_2
U2
fub_3
U3
Now perform ungrouping:
Chip
grouped_design
U12
fub_3
U3
ungroup U12 -start_level 2

74
09.14.05
Saving optimized database & generating

reports:
To save database after optimization you can use several types of
commands:
To save in db format (old synopsys binary format)

write -format db -h -o ./outputs/${DESIGN}.db
Now it is recommended to use new internal binary format called

ddc format. It is supported in XG-mode:
write -format ddc -h -o ./outputs/${DESIGN}.ddc
To save in verilog netlist format:

change_names -hierarchy -rules verilog
write -format verilog -hierarchy -o ./outputs/${DESIGN}.vg
Note: In addition to logical information about the design; ddc (& db mode)
also contain any constraints and any attribute information.
75
09.14.05
Training.tcl

elaborate exunit
link


#Try to be conservative on your selection of driving cell.
set_driving_cell -library p1265_lp_rsss_1.15v_110c -lib_cell lp0bf00x3 -pin o [remove_from_collection [all_inputs] [all_clocks]]
set_operating_conditions -max_library p1265_lp_rsss_1.15v_110c -max rsss_1.15v_110c

###############################################
# If you wanted to define OC for min corner do:
###############################################
##set_operating_conditions -max_library p1265_lp_rsss_1.15v_110c -max rsss_1.15v_110c -min_library p1265_lp_rfff_1.50v_n30c -min
rfff_1.50v_n30c
############################################
# Write Outputs
############################################
#write -format ddc -h -o ./outputs/exunit.ddc
change_names -hierarchy -rules verilog
#write -format verilog -hierarchy -o ./outputs/${DESIGN}.vg
76
09.14.05
Write SDC file & SDF.

You can also write out SDC file to be used by APR. Command used is
write_sdc ${DESIGN}.sdc.
SDC has constraints such as clock definition, I/O timing, set_loads,

FP, MCPs etc.
SDF file can also be written out for PT timing analysis or GLS.
This SDF is based on WLM so accuracy is questionable.
Meaningful SDF/set_load is generated from post-Route database.

77
09.14.05
Reports.
There are several type of reports available for design analysis. But
most common ones are as follows:
report_area
----------------- Reports area information.
report_timing ----------------- Reports path timing information
report_constraint --------------- Reports summary of violated constraints
report_qor ---------------------- Reports quality of results summary.
report_net ---------------------- Reports on designs nets
report_net_fanout
----------- Reports net fanout info.
report_clock
----------- Reports clock information, skew etc.
report_cell
----------- Reports cell instance information.
Check_design
----------- Checks for possible design issues.
Check_timing
----------- Check for possible timing related issues.
For details do man on dc_shell-t prompt:

man report_clock
78
09.14.05
Advanced topics (set_cost_priority)
Previously, mentioned order of

constraint priorities as DRC,
max_delay, min_delay & Area.
Constraint priority in
descending order
Constraint Type
min_capacitance
DRC
Default order of cost priorities can

be changed using set_cost_priority
command.
max_transition
DRC
max_fanout
DRC
max_capacitance
DRC
cell_degradation
DRC
max_delay
Optimization Constraint
min_delay
Power
Area
To use this command effectively

need to further break down
constraint priorities as given in
table:

79
09.14.05
Static Timing Analyses (STA) using Design Compiler
You are done with your synthesis session. Now what?

You should be able to analyze the database, look at the timing
reports etc.
Analyzing timing reports in DC is very similar to performing static

timing analysis (STA) using industry standard FC timing sign-off
tool, PrimeTime.
Timing engine embedded in DC is called DesignTime. Although PTs
timing engine is not the same but tool interface/commands are very
similar.
STA is a process of validating timing performance of design without

running long and time consuming dynamic simulations.
No test vectors needed for STA.

STA is fast and checks all timing paths exhaustively.
80
09.14.05
DesignTime divides design database into several timing paths and

check to see if they meet timing w.r.t constraints.
Delay of all paths is calculated and can be reported with

report_timing.
Timing Startpoints & Endpoints:
Timing paths consist of Startpoint & Endpoint.

Input ports & clock pin of Registers are two valid forms of
Startpoints.
Output ports & pins of Registers other than clock pin form a valid
Endpoint.

81
09.14.05
Types of timing paths

1) Input port to registers (pins other
than clock pins).
2) Register clock pin to output ports.
3) Register to Register (clock pin to

pins other than clocks).
Timing Paths
4) Input to Output port.

Path 3
Path 2
Path 1
How many path groups?

IN
Combo
CLK_1
Combinational
logic
CK
Path 4
Combo
82
09.14.05
CK
CLK_2
Combo
out
Components of delay calculation
In timing reports total path delay is typically a function of following factors.
Delay model from library e.g. generic cmos, Non-Linear Delay model. Usually its
Non-Linear delay model.
Interconnect delay model is used to model type of distributed RC Network.
WLM used for numerical estimates of RC values to be used for net parasitics.
PVT from operating conditions.
Cell Delays are computed from non-linear delay models specified in library.
This net transition contributes to input transition of next stage of cells.
Cell delays are a function output loading & input pin transition.
Input pin transition & output loading also determine transition delay of net
attached to output pin (driver pin).
Net delays are a function of WLM, tree_type & interconnect RC delay.

83
09.14.05
Types of Interconnect RC delay model

There are basically three RC tree_types for Interconnect models:
Best_case: Both driver & reciever are considered adjacent to each other
causing zero resistance and so zero interconnect delay.
Delay = 0
Balanced_case: All loads are on equal branches of net segments such that
each net segment incurs equal percentage of nets R & C.
Delay = (Rnet/N) * (Cnet/N + Cpin)
Worst_case: Driver and receiver are assumed far form each other such
that ecah load incurs fully lumped R & C.
Delay = Rnet(Cnet +Cpin)

84
09.14.05
Sample timing Path

dc_shell-xg-t> report_timing
****************************************
Report : timing
-path full
-delay max
-max_paths 1
Design : exunit
Version: X-2005.09-SP1
Date
: Tue May 2 15:46:59 2006
****************************************
# A fanout number of 1000 was used for high fanout net computations.
Operating Conditions: rsss_1.15v_110c Library: p1265_lp_rsss_1.15v_110c
Wire Load Model Mode: enclosed
Startpoint: se_astat_x1f[5]
(input port clocked by clk)
Endpoint: eu_dreg_g1f[17]
(output port clocked by clk)
Path Group: clk
Path Type: max
85
09.14.05
Timing path cntd:

Des/Clust/Port
Wire Load Model
Library
-----------------------------------------------exunit
500_k
p1265_lp_rsss_1.15v_110c
eu_rfctl
40_k
p1265_lp_rsss_1.15v_110c
mux8_16_16
40_k
p1265_lp_rsss_1.15v_110c
mux4_32_5
40_k
p1265_lp_rsss_1.15v_110c
Point
Incr
Path
-------------------------------------------------------------------------clock clk (rise edge)
clock network delay (ideal)
0.00
0.00
0.00
0.00
input external delay
750.00
se_astat_x1f[5] (in)
0.00
750.00 r
rf_ctl/ccin_x1f (eu_rfctl)
0.00
750.00 r
rf_ctl/U3/o (lp0in00x16)
750.00 r
14.91
764.91 f
rf_ctl/U362/o (lp0na02x4)
22.98
787.88 r
32.39
820.27 f
rf_ctl/U127/o (lp0no02x4)
33.18
853.45 r
rf_ctl/U354/o (lp0no02x4)
27.11
880.56 f
31.80
912.37 r
rf_ctl/U157/o (lp0cb00x16)
65.06
977.42 r

86
09.14.05
Timing path cntd.

rf_ctl/storesell_g1f[2] (eu_rfctl)
0.00
rf_store_g1f_int_lmux/sel[2] (mux8_16_16)
977.42 r
0.00
977.42 r
rf_store_g1f_int_lmux/U189/o (lp0in00x6)
25.96
1003.39 f
rf_store_g1f_int_lmux/U192/o (lp0no03x4)
85.42
1088.81 r
55.67
1144.48 f
46.50
1190.98 r
42.59
1233.56 f
rf_store_g1f_int_lmux/U157/o (lp0na02x4)
28.32
1261.88 r
rf_store_g1f_int_lmux/U135/o (lp0ci00x8)
31.40
1293.28 f
rf_store_g1f_int_lmux/U177/o (lp0ci00x16)
22.97
1316.26 r
0.00
1316.26 r
rf_store_g1f_int_lmux/z[1] (mux8_16_16)
rf_strmux/i2[17] (mux4_32_5)
0.00
1316.26 r
rf_strmux/U333/o (lp0an02x2)
72.33
1388.58 r
rf_strmux/U367/o (lp0no02x4)
31.24
1419.83 f
rf_strmux/U427/o (lp0na02x4)
33.97
1453.80 r
rf_strmux/z[17] (mux4_32_5)
0.00
1453.80 r
eu_dreg_g1f[17] (out)
data arrival time
0.32
1454.12

87
09.14.05
1454.12 r
Timing Path cntd:

clock clk (rise edge)
clock network delay (ideal)
clock uncertainty
output external delay
data required time
2250.00
2250.00
0.00
-450.00
2250.00
1800.00
-750.00
1050.00
1050.00
-------------------------------------------------------------------------data required time

data arrival time
1050.00
-1454.12
-------------------------------------------------------------------------slack (VIOLATED)
88
09.14.05
-404.12
Report_timing analysis.
By default report_timing shows full cell delay annotated to the
output pin of cell.
But if you use input option than it also shows delay annotated to
input pin. Snippet:
rf_store_g1f_int_lmux/U189/a (lp0in00x6)
0.51
977.94 r
25.45
1003.39 f
rf_store_g1f_int_lmux/U192/b (lp0no03x4)
0.20
1003.59 f
85.22
1088.81 r
Yet with even more option i.e. -input , -net, -cap -tran; it
shows nets attached to pins, fanout, capaitive load & transition delay
at output pin. Same snippet from above:
37.59
0.51
977.94 r
18.03
25.45
1003.39 f
rf_store_g1f_int_lmux/net371276 (net)
0.01
rf_store_g1f_int_lmux/U192/b (lp0no03x4)
18.47
0.20
99.27
85.22
rf_store_g1f_int_lmux/net281862 (net)
0.02

89
0.00
09.14.05
0.00
1003.39 f
1003.59 f
1088.81 r
1088.81 r
Cell Delay Calculation Example

Fanout Cap
rf_ctl/U157/o (lp0cb00x16)
Trans
36.46
rf_ctl/storesell_g1f[2] (net)
0.09
rf_ctl/storesell_g1f[2] (eu_rfctl)
rf_storesell_g1f_2_ (net)
0.09
rf_store_g1f_int_lmux/sel[2] (mux8_16_16)
rf_store_g1f_int_lmux/sel[2] (net)
0.09
Incr
Path
64.72
977.42 r
0.00
977.42 r
0.00
977.42 r
0.00
977.42 r
0.00
977.42 r
0.00
977.42 r
37.59
0.51
18.03
25.45 1003.39 f
rf_store_g1f_int_lmux/net371276 (net) 3
Fanout
number
Cap load
0.01
Transition delay
at output pin

90
09.14.05
0.00
977.94 r
1003.39 f
Cell delay
annotated
to output
pin
Degraded
input pin
Transition
Interconnect
RC
Worst delay
edge
Timing Library LookUp Table
Understanding a
cell_fall ("delay_outputslew_template_8X8_r14cip00hx120") {
Index_1 Increasing CAP
/* Simulation data for spec: `tp_ckb_xy_o_10_min_max' */

index_1 ("0.0023242, 0.0464835, 0.0929670, 0.1394510, 0.2324170, 0.3253850, 0.4648350, 0.6972530") ;
index_2 ("0.0050000, 0.0720000, 0.1330000, 0.1940000, 0.2660000, 0.3250000, 0.4330000, 0.6500000") ;
values (\
"0.0094544, 0.0185783, 0.0214518, 0.0236007, 0.0253379, 0.0262552, 0.0272282, 0.0275904",\
"0.0162273, 0.0331686, 0.0396203, 0.0439910, 0.0480818, 0.0509845, 0.0540329, 0.0590189",\
"0.0229267, 0.0445651, 0.0545321, 0.0611686, 0.0671197, 0.0700321, 0.0753469, 0.0851278",\
"0.0295431, 0.0544924, 0.0670831, 0.0758769, 0.0836995, 0.0867423, 0.0949430, 0.1071260",\
"0.0427102, 0.0726367, 0.0882396, 0.1007730, 0.1110430, 0.1172860, 0.1290020, 0.1461220",\
"0.0557998, 0.0886394, 0.1074140, 0.1221190, 0.1356480, 0.1436800, 0.1586330, 0.1804830",\
"0.0754076, 0.1105390, 0.1338060, 0.1511390, 0.1675510, 0.1777430, 0.1972450, 0.2262090",\
"0.1082070, 0.1435670, 0.1730870, 0.1953680, 0.2154180, 0.2272280, 0.2517220, 0.2892730"\
);
fall_transition ("delay_outputslew_template_8X8_r14cip00hx120") {
/* Simulation data for spec: `tp_ckb_xy_o_10_min_max' */
index_1 ("0.0023242, 0.0464835, 0.0929670, 0.1394510, 0.2324170, 0.3253850, 0.4648350, 0.6972530") ;
index_2 ("0.0050000, 0.0720000, 0.1330000, 0.1940000, 0.2660000, 0.3250000, 0.4330000, 0.6500000") ;
values (\
"0.0061389, 0.0186050, 0.0271472, 0.0330667, 0.0409234, 0.0477795, 0.0586398, 0.0787963",\
"0.0146870, 0.0298953, 0.0417526, 0.0504997, 0.0592868, 0.0668663, 0.0808903, 0.1052830",\
"0.0245473, 0.0410504, 0.0528621, 0.0639379, 0.0748730, 0.0845219, 0.1018660, 0.1263720",\
"0.0340386, 0.0497603, 0.0632419, 0.0754232, 0.0882203, 0.1016720, 0.1160920, 0.1442230",\
"0.0525267, 0.0680215, 0.0831561, 0.0963495, 0.1118690, 0.1224300, 0.1423730, 0.1773050",\
"0.0711111, 0.0841070, 0.1015420, 0.1170980, 0.1355360, 0.1428940, 0.1648110, 0.2031320",\
"0.1012570, 0.1112820, 0.1274450, 0.1473200, 0.1665090, 0.1762910, 0.1964440, 0.2373340",\
"0.1467670, 0.1540650, 0.1700650, 0.1904480, 0.2104150, 0.2204380, 0.2469340, 0.2914650"\
);
Timing Report
TRAN Index is Column

Selector
CAP Index is Row Selector

Index_2 Increasing TRAN

91
09.14.05
2D LookUp Table
Startpoint: FF_1 (rising edge-triggered flip-flop clocked by clk)

Endpoint: out_1 (output port clocked by clk)
Path Group: clk
Path Type: max
Point
Fanout Cap
Trans
Incr
Path
-------------------------------------------------------------------------------------------------------clock clk (rise edge)
0.0000000 0.0000000
clock source latency
2.0000000 2.0000000
clk (in)
0.1330000 0.0000000 2.0000000 r
clk (net)
1 0.0400261
BUF_1/ckb (r14cip00hx120)
0.1330000 0.0010161 2.0010161 r
BUF_1/o (r14cip00hx120)
0.0831561 0.0875449 + 2.0885611 f
n1 (net)
1 0.2324170
0.0831561 0.0059004 + 2.0944614 f
0.0300929 0.0325592 2.1270206 r
n2 (net)
1 0.0400261
0.0300929 0.0010161 2.1280367 r
0.0189827 0.0211189 2.1491556 f
Things to look for to debug timing issues.
Big delay cells & possible causes.

Relaistic interface timing constraints.
Many back2back buffers/inverters.
Traverse levels of logical hierarchy in path.
Unrealistically high level of logic cells.
Revisit compile strategy.

92
09.14.05
Timing exceptions
Timing exceptions are needed to account for non-default behaviour
of synchronous paths.
False Paths (FP).

Multicycle Paths. (MCP).
False Paths (FP):

Are paths that are free of any timing constraints.
Consequently such paths are skipped during timing optimization in DC.
Command set_false_path is used to remove/disable timing constraints
from a path.
Correct identification of FP is very critical for quality synthesis & timing
closure.
Some example of paths that could be declared as false are.
Cross clock paths i.e paths that are launched and captured by different
clocks that are asynchronous w.r.t each other e.g. clocks with different
frequencies
Paths that are functionally never executed or dont impact design
operation.
set_false_path from [get_clocks clk1] to [get_clocks clk2]
93
09.14.05
Timing exceptions cntd.

Multicycle Paths (MCP):
By default all paths are single cycle paths.

Paths that take multiple clock cycles to propagate from launch to capture
edge.
Command set_multicycle_path is used to specify paths as MCP.
Example: Register to Register path that goes thru an Adder may take
multiple clocks cycles to propagate.
set_multicycle_path 2 from [get_pins reg_1/CK] to [get_pins reg_2/D]
set_multicycle_path setup 2 through {U1,U2} to [ger_ports X].

94
09.14.05
Multiple Clocks & Virtual clocks
In real designs usually there are more than one clock within single
block or across multiple blocks.
DC determines and uses the worst case relationship between clock

edges to optimize the path for worst case scenario.
Virtual clocks are the clocks that are physically non-existent in

design under synthesis but may exist in another block.
Virtual clocks do not have a clock entry port (clock definition point) in the
design being synthesized.
Virtual clocks are typically used for applying constraints between cross
clock paths.

95
09.14.05
Virtual/Multiple Clock
example
3ns
CK 2
in
Combo
Combo
???
out
CK 1
5 ns
CK 3
CK 1 (20 ns period)
10
20
30
40
CK 2 (10 ns period)
10
15
20
25
30
35
40
CK 3 (14 ns period)
14
21

96
09.14.05
28
35
42
Virtual Clock Example 1:

In previous figure which clocks determine worst case setup
relationship???
What should be the max delay allowed for yellow cloud of logic
during synthesis???
create_clock name CK1 period 20000 [get_ports CK1]

create_clock name CK2_virtual -period 10000
create_clock name CK3_virtual period 14000
set_output_delay 5000 max clock CK3_virtual [get_ports out]
set_output_delay 3000 max clock CK2_virtual -add_delay [get_ports
out]
Note: Since block under synthesis does not contain CK2 &
CK3 ports, therefore virtual clocks were defined for assigning
interface timing constraint.
97
09.14.05
Answers to Example:
CK1 edge @ 20 ns -> CK3 edge @ 28 ns determines the worst case
relationship.
Logic cloud yellow should be synthesized to 3 ns.

98
09.14.05
Help & Useful Commands:
get* --------- Family of commands that create collection of objects.
e.g. get_cells, get_nets etc.
If you dont know exact command that you are looking for simply do
following at prompt:
dc_shell-xg-t> help get*

get_attribute
get_cells
# get attribute values

# create a collection of cells
get_clocks
# create a collection of design clock
all_input ------- Returns list of input/inout ports.

all_outputs ---- Returns list of outputs ports.

99
09.14.05

dc_shell-xg-t> help all*
all_clocks
# return all clocks in the current design
all_connected
all_critical_cells
all_designs
# return objects connected to a net, port, or pin

# return critical cells
# return all designs
all_dont_touch
all_fanin
all_fanout
# Returns all dont touch objects

# return pins or cells in transitive fanin
# return pins or cells in transitive fanout

100
09.14.05

dc_shell-xg-t> help set*
set_clock_latency
# set clock_latency
set_clock_transition # set clock_transition

set_clock_uncertainty # set clock_uncertainty
set_ideal_net
# set_ideal_net
set_ideal_network
# set_ideal_network
set_ideal_transition # set_ideal_transition
set_input_delay
set_output_delay
# set input_delay
# set output_delay

101
09.14.05

Following gives list of all matching commands:
dc_shell-xg-t> help set*
Once you know the command, to look at its switches do following:

dc_shell-xg-t> set_output_delay -help
Usage: set_output_delay
# set output_delay
[-clock clock_name]
(relative clock)
[-clock_fall]
(delay is relative to falling edge of clock)
[-level_sensitive]
(delay is from level-sensitive latch)
To look at full man page:

dc_shell-xg-t> man set_output_delay

102
09.14.05
Some helpful solvenet articles on Compile

strategies:
https://solvnet.synopsys.com/retrieve/901881.html

103
09.14.05
Acknowledgements & References

Special thanks to following individuals for proof reading the foils:
Pokhrel, Khem C
Gourlay, Stephen
(FM)
(HD)
References:
Synopsys Documentation.
Khem Pokhrels STA document.

104
09.14.05

Fundamental of Loic Synthesis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fundamental of Loic Synthesis

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentals of Logic Synthesis

with Design Compiler

ASIC Design Flow

Verdana Bold 8 write title of presentation here

ASIC Design flow

FPGA (Field programmable Gate Arrays that are pre-manufactured

and design independent. These contain number of design blocks that

High level flow for Synthesis based ASIC design flow:

Static Timing Analysis (STA).

Verdana Bold 8 write title of presentation here

Some Key Terminologies & Definitions

abstract form of HDL/RTL is implemented in terms of logic gates.

Standard Cells represent logic cells that belong to a technology

library that is characterized for a particular process. e.g. AND, OR,

Netlist is post synthesis abstraction of a design.

interconnection of Std cells that are connected via wires also

Netlist representation of a design is used for down stream flows

Verdana Bold 8 write title of presentation here

Major Synthesis Steps

Translation is a process of converting RTL description into intermediate

Verdana regular 7pt.

Verdana Bold 8 write title of presentation here

Synthesis Steps cntd.

tools continue to perform iterative Optimizations & Mapping steps in

Verdana regular 7pt.

Verdana Bold 8 write title of presentation here

Design Ware (DW) Libraries

DW libraries are used during High Level Optimization (HLO) of

DW IP blocks range from simple logic functions of AND,NAND,NOR to

Structure of DW IP Library consists of two parts:

Ckt. Description of various IP

Verdana Bold 8 write title of presentation here

Binary file that associates ckt. in design

Operators in HDL (+, - etc.)

Have Bindings to Synthetic

Verdana regular 7pt.

Verdana Bold 8 write title of presentation here

After initial high level architectural optimization, Design Compiler

level representations to fully take advantage of various optimization

Optimization process continues until no further improvements in the

i.e. No further improvements to Optimization Cost function are

Note: These optimization steps can be guided by user.

Verdana Bold 8 write title of presentation here

Architectural Optimization: This type of Optimization

Design is represented in terms of GTECH cells after HLO.

occur only in the beginning i.e. during optimization of unmapped

Implementation selection is the process of mapping HDL logic to a

Initial mapping to DW is constraint independent. But later in the process

Verdana Bold 8 write title of presentation here

Implementation Selection process:

Verdana regular 7pt.

Verdana Bold 8 write title of presentation here

Constraint driven Implementation

Resource sharing reduces the amount of hardware needed to

Verdana regular 7pt.

Verdana Bold 8 write title of presentation here

For example arithmetic expression a+b+c+d can be implemented

using 3 level cascaded addition operation or faster logic with 2-levels

Identifying arithmetic expressions & optimization is sometimes

3 level cascaded addition

Verdana Bold 8 write title of presentation here

Logic Optimization: After high level architectural optimization,

Logic optimization works on GTECH representation (representation after

Structuring: It is the logic optimization technique by which tool