SynthesiS

This slides will cover

● Basic concept of synthesis
● Synthesis using tool
1
Contents:
● Introduction
● Synthesis Stages
● Design compiler and Design flow
● Synthesizable verilog cells and operators
● Steps before synthesis
● Synthesis flow of Cadence Genus and Synopsys Design Compiler
● Supported User Interfaces of Genus
● Target Library
● Link library variable
● Design objects
● Read HDL
2
Contents:
● Performing elaboration
● Multiple objects with same name
● Get command exercise
● RT overview
● Path and Delay
● Constraints
● Basic mode specific constraints of genus
● SDC
● Analysis and report
● Extracting output files
● Constraints Design_compilar vs Genus
● Generic flow
3
Introduction:
● Synthesis can be defined as the process of converting the VHDL/Verilog
code into a Gate Level Netlist with the help of a synthesis tool.
● RTL is higher level behavioral code and is intended to be synthesized. It
defines a circuit as a combination of interconnected registers and the
operations performed on signals between those registers.
● In Gate level we can see only netlist (gates and wire) in the code and
generally it is a synthesized gate level Verilog/VHDL file.

So Basically ,
Synthesis = translation + optimization + mapping

4
Synthesis in a nutshell:

5
Synthesis Stage:

RTL

Generic
TRANSLATION Boolean
(Read Verilog) Gates

OPTIMIZATION + Gate
MAPPING Level
(COMPILE ) Netlist

Target Library Based

6
Synthesis Stage:
Translation:
❏ Check RTL for valid syntax

❏ Transform RTL to unoptimized GTECH gates

❏ Link all the part of design

Optimization and Mapping:

❏ Driven by constraints and target cell library
❏ Optimize to meet design goals :
❏ Design rules
❏ Timing
❏ Area
❏ Power

7
Synthesis Stage:

8
Compile:

9
Design Compiler and the design Flow:

10
Design Compiler and the design Flow:
➔ Design Compiler uses technology libraries, and symbol libraries to implement
synthesis and to display synthesis results graphically.During the synthesis process, dc
translates the HDL description to components extracted from the generic technology
(GTECH) library and Design Ware library. The GTECH library consists of basic logic
gates and flip-flops. The Design Ware library contains more complex cells such as
adders and comparators. Both the GTECH and Design Ware libraries are technology
independent, that is, they are not mapped to a specific technology library. Design
Compiler uses the symbol library to generate the design schematic.

➔ After translating the HDL description to gates, Design Compiler optimizes and maps
the design to a specific technology library, known as the target library. The process is
constraint driven. Constraints are the designer’s specification of timing and
environmental restrictions under which synthesis is to be performed.
11
Design Compiler and the design Flow:

➔ After the design is optimized, it is ready for test synthesis. Test synthesis is the
process by which designers can integrate test logic into a design during logic
synthesis. Test synthesis enables designers to ensure that a design is testable and
resolve any test issues early in the design cycle.

➔ The result of the logic synthesis process is an optimized gate-level netlist, which is a
list of circuit elements and their interconnections. After test synthesis, the design is
ready for the place and route tools, which place and interconnect cells in the design.
Based on the physical routing, the designer can back-annotate the design with actual
interconnect delays; Design Compiler can then resynthesize the design for more
accurate timing analysis.
12
Synthesizable Verilog cells & Operators:

● AND ● Bitwise (~ , & , | , ^ , ~^ )

● OR ● Logical ( ! , && , || )
● NOT ● Relational ( > , < , >= , <= )
● NAND ● Equality ( == , != )
● Logic shift ( >>, << )
● NOR
● Conditional ( ?: )
● XOR ● Concatenation ( { } )
● XNOR ● 2’s complement arithmetic ( +, -, *, /, % )
● BUFFER
● INVERTER

13
An Example:

14
Steps before synthesis:

1. RTL should be syntax checked and basic functionality verified.

2. Test benches should be verified.
3. Good coding styles give optimum results and easy debugging after synthesis.
4. However, good code can result in a design that is both smaller in area and faster.
5. The area and timing of your circuit are mainly determined by circuit architecture and coding style.

Note :

The only trade-off available with a synthesis tool is timing versus area. But with advent of mobile
devices, power has entered the equation.

Design is now optimized for three constraints; PPA ( Power, Performance, Area)

In fact, a super tight timing constraint may be worked while synthesis, but failed in the Place & Route
(P&R) procedure.
15
Synthesis Flow:

Generic Genus Work Flow Generic dc Work Flow 16

Supported User Interfaces of Genus:
Genus supports the following user interfaces:

● Unified User Interface: Genus offers a fully unified Tcl scripting language
and GUI environment also referred as Stylus Common UI.
The default interface is Stylus Common UI.
genus@root:>
● Legacy User Interface: Genus can also operate in legacy mode which
supports RTL Compiler commands/attributes and scripting.
legacy_genus:/>

One can switch from Stylus COmmon UI to Legacy UI by using-

genus@root:> set_db common_ui false

17
Setting the Appropriate Synthesis Mode:

● Genus has two modes to synthesize the design. The synthesis mode is
determined by the setting of the interconnect_mode attribute:
○ wireload (default) indicates to use wire-load models to drive synthesis
○ PLE indicates to use Physical Layout Estimators (PLEs) to drive synthesis

PLE uses physical information, such as LEF libraries, to provide better closure
with backend tools.

Note: When you read in LEF files, the interconnect_mode attribute is

automatically set to PLE.
18
Technology library:
Question :

● When your synthesis tool

maps a circuit how will it
know which cell lib you are
using?
● How will it know the timing
of your cells?

Your ASIC vendor must provide a

synthesis compatible technology
library for synthesis.

19
Target library variable:
➔ The target library is the library used by synthesis tool for building a circuit.
➔ During mapping , synthesis tool will :
◆ Choose functionally-correct gates from this library
◆ Calculate the timing of the circuits using vendor-supplied timing data
for these gates.

★ In DC target_library is a reserved variable.

■ set target_library "mylib.db"
★ In Genus set_db library is a reserved variable.
■ set_attribute library {slow.lib} (legacy ui)
■ set_db library {slow.lib} (common ui)
20
Link library variable :
➔ Used to resolve references.
➔ First DC searches the memory and then the library files specified in the
link_library variable.
➔ Second DC searches the all paths defined in the search_path variable.
◆ Set link_lib “my_tech.db”

N.B. Genus don’t have this option in their tool.

But what do you think about this ? Will this help you anywhere?

21
Design Objects : verilog Perspective

22
Design Objects : Schematic Perspective

23
Read HDL :
➔ Use the read_hdl command to read HDL files into Genus. When you issue
a read_hdl command, Genus reads the files and performs syntax checks.
➔ In DC it use one of the following methods to read HDL design files:
◆ The analyze and elaborate commands :
To use this method, analyze the top-level design and all subdesigns in
bottom-up order and then elaborate the top-level design and any
subdesigns that require parameters to be assigned or overwritten.
For example, enter
dc_shell> analyze -format verilog -lib -work nelist.v
dc_shell> analyze -format vhdl -lib -work {ALU.vhd
STACK_TOP.vhd STACK_MEM.vhd...}
dc_shell> elaborate RISC_CORE -arch STRUCT -lib WORK
-update 24
Read HDL : (another way )

➔ The read_file command

For example, enter
dc_shell> read_file -format verilog netlist.v
➔ The read_verilog or read_vhdl command
◆ For example, enter

dc_shell> read_verilog netlist.v

The read_file command does the following:

• Reads several different formats.
• Performs the same operations as analyze and elaborate in a single
step.
25
Performing Elaboration (Genus only):
In Genus after load the hdl ,elaboration takes part in the flow.

Elaboration is only required for the top-level design. The elaborate command
automatically elaborates the top-level design and all of its references. During
elaboration ,Genus performs the following tasks:

➔ Builds data structures

➔ Infers registers in the design
➔ Performs high-level HDL optimization, such as dead code removal
➔ Checks semantics

After elaboration, Genus has an internally created data structure for the whole
design so you can apply constraints and perform other operations.
26
Multiple objects with same name :

Let’s say a command set_load 5 CLK

Does “CLK” refer to a clock, port,net or pin object??

Does it matter onto which object synthesis tool places the load??

get commands return a collection of object names. If none are found ,an empty collection is returned.
It searches the current design and can be used stand-alone or composed with other functions.

Set_load 5 [get_nets CLK]

27
Get command exercise :

28
Get command exercise :

29
RT overview :

30
Path and Delay:
So we have three types of path :
1.Input to Register
2.Register to Register
3.Register to Output

R2R delay :
Setup time is defined as the minimum amount of time before the clock's active edge
that the data must be stable for it to be latched correctly. Any violation may cause
incorrect data to be captured, which is known as setup violation.

Hold time is defined as the minimum amount of time after the clock's active edge
during which data must be stable. Violation in this case may cause incorrect data to be
latched, which is known as a hold violation. Note that setup and hold time is measured
with respect to the active clock edge only.
31
Path and Delay:
I2R delay:
Input delay to chip is also external input delay (time take from outside world to
the chip)

R2O delay:
output delay or output external delay how time it takes from the output of the
chip to the input of the next chip/system.

This is the only bullshit in the whole chip. Now you ,how to put your input
register to input,output register to output depends upon i/o timing right?.

32
Constraints:
Constraints are the instructions that the designer apply during logic synthesis.

❏ After loading and elaborating your design, you must specify constraints. The
constraints
Include:
❏ Operating conditions
❏ Clock waveforms
❏ I/O timing
❏ You can apply constraints in several ways:
❏ Type them manually in the Genus shell.
❏ Include a constraints file.
❏ Read in SDC constraints.

33
Types of Constraints:
There are two basic types of constraints, Timing constraints & Physical constraints.

● Timing Constraints ● Physical Constraints

- Clock period - Everything that is not timing
- Input signal arrival times - IO constraints
- Output signal required times a) IO standards
- Exceptions b) Package pin LOC
a) False paths - Floorplanning
b) Multiple clock cycle a) Instance LOC/BEL
paths b) Area group or Pblock
c) Fixed delay - Device configuration
requirements

34
Basic mode specific constraints of Genus:
Genus has some mode specific constraints.

● Create_mode
● Define_clock
● External_delay
● Multi_cycle
● Path_adjust
● Path_delay
● Path_disable
● Path_group
● Specify_path
35
Mode specific constraints: Create_mode
Create_mode: Specifies the mode for power and timing analysis and
optimization.

● Mode creation happens after loading and elaborating the design and before
reading in the SDC file and constraints: define_clock,
external_delay, multi_cycle, path_adjust, path_delay,
path_disable, path_group, and specify_paths.

Ex. create_mode -name "mode1 mode2" -design design_name

● After creating modes, use the -mode option with the read_sdc command.

Ex. read_sdc -mode mode1 a.sdc

read_sdc -mode mode2 b.sdc 36

Mode specific constraints: Define_clock
Define_clock: Defines a clock waveform. A clock waveform is a periodic signal with
one rising edge and one falling edge per period. The command returns the directory
path to the clock object that it creates.

Ex. define_clock -period 10000 -name 100MHz -design /designs/alu

define_clock -name 100 MHz -period 10000 -rise 20 -fall 80

Defining the clocks:

● User must define the clock source,

clock period & clock name.
● Clock offset, clock skew can also
Be defined while define clock.
37
Mode specific constraints: External_delay
External Input delay:
● Input might be connected with an external logic which contains some delay.
So it needs to be defined while synthesize.

38
Mode specific constraints: External_delay
External Output delay:
● Output can also be connected with some other external logic. So some
delays needs to be added with the output pin.

39
Mode specific constraints: External_delay
External_delay: Constraints ports and pins within the design. Timing is specified
as either an input or output delay, and is specified relative to a clock edge.

● External delays are most often specified on top-level ports of your design.

Ex. external_delay -input 300 -edge_fall -clock [find / -clock

clock1] \ [find / -port a*]

external_delay -output 1300 -clock [find / -clock clock1] \

[find / -port a*]

40
Mode specific constraints: Genarate_constraints
Genarte_constraints verifies the false path and multi-cycle paths.

False path: A false path is a path for which you will ignore timing constraints.

41
Mode specific constraints: Genarate_constraints
Genarate_constraints: Verifies the false paths and multi-cycle paths in the SDC
files against the RTL or netlist and then generates any missing functional false
paths or multi-cycle paths.

● Generate_constrains is used any time after elaboration.

● It is used for false path generation, directed false path generation and
timing report validation flows.

Ex. generate_constraints -fpgen -rtl -in_sdc /home/test/top.sdc \

-out_sdc /home/cody/top_out.sdc

generate_constraints -dfpgen -netlist generic.nl.v -in_sdc top.sdc \

-report top_out.rep -slack 2 -out_sdc top_out.sdc
42
Mode specific constraints: Multi_cycle
Multi_cycle: Creates a timing exception object that overrides the default clock
edge relationship for paths that meet the path selection criteria.

● Paths can be selected using the -from, -through, -to, or -paths options.
● At least one of these four options must be provided.
● The -paths option cannot be used in conjunction with any of the other three
path selection options.

Ex. multi_cycle -from ff1/Q -to ff2/D

43
Mode specific constraints: Path_delay
Path_delay: Specify the timing constraint for paths that meet the path selection
criteria.

● Paths can be selected using the -from, -through, -to, or -paths options.
● At least one of these four options must be provided.
● The -paths option cannot be used in conjunction with any of the other three
path selection options.
● These path constraints could have been computed by the timing engine
using the launching and capturing waveforms.

Ex. path_delay -delay 5000 -from ff1/Q -to ff3/D

44
Mode specific constraints: Validate_constraints
Validate_constraints: Validates the SDCs specified in the SDC files against the
RTL or netlist.

● Validate_constraints is used any time after elaborating the design.

● It is used in the False Path and Multi-cycle Path validation flows.

Ex. validate_constraints -rtl -sdc /home/test/top.sdc

validate_constraints -netlist
/home/cody/design/netlist.nl.v \
-sdc /home/cody/lane.sdc

45
SDC(Standard Design Constraint) Constraints:
Genus has its own mode specific constraints. But when Synopsys Design
Constraints(SDC) got standardize as Standard Design Constraint, Genus had to
merge with the standard version of constraints.

So, we mostly use Standard Design Constraints for logic synthesis.

Now, SDC Constraints can be segregated based on the changes they bring to the
design.

● Operating condition set_operating_condition

46
SDC(Standard Design Constraint) Constraints:

set_wire_load_mode
set_wire_load_model
● Wire load model set_wire_load_selection_group
set_wire_load_min_block_size

set_drive
set_driving_cell
set_input_transition
● System interface set_load
set_port_fanout_number

set_fanout_load
set_max_fanout
● Design rule constraints set_max_capacitance
set_min_capacitance
set_max_transition

47
SDC(Standard Design Constraint) Constraints:
create_clock
set_clock_latency
set_clock_transition
set_clock_uncertainty
set_clock_groups
set_clock_sense
create_generated_clock
set_clock_gating_check

Timing Constraints group_path

set_ideal_latency
set_ideal_network
set_ideal_transition
set_data_check
set_disable_timing
set_input_delay
set_output_delay
set_max_time_borrow
set_propagated_clock
set_resistance
set_timing_derate

48
SDC(Standard Design Constraint) Constraints:
set_false_path
● Timing exceptions set_max_delay
set_min_delay
set_multicycle_path

● Area constraint set_max_area

create_voltage_area
set_level_shifter_strategy
set_level_shifter_threshold
● Multi-voltage and Power Optimization Constraints set_max_dynamic_power
set_max_leakage_power

set_case_analysis
set_logic_dc
● Logic Assignments set_logic_one
set_logic_zero

49
Set_input_transition:
Set_input_transition: Sets a specific transition time (slew) on the specified input
and inout ports. One can specify the minimum rise, minimum fall, maximum
rise, or maximum fall slew.

● It is used to specify fixed transition time for input ports.

● This value is used to compute the delays of logic driven by the port.

set_input_transition [-rise] [-fall] [-min] [-max] [-clock clock_name]

[-clock_fall] transition port_list

set_input_transition -rise 0.5 [get_ports GPIO*]

50
Set_max_fanout:
set_max_fanout: Specifies the maximum allowed fanout for specified input ports
or all input ports of the design.

● The synthesis or optimization tool uses this information to keep the number
of loads connected to the input ports to be no more than the specified
maximum value.
● Sets the max_fanout attribute on the specified design or port.

Set_max_fanout [fanout_number] [port]

set_max_fanout 6 [get_ports IN1]

51
Set_max_capacitance:
Set_max_capacitance: Specifies the maximum allowed capacitance for the
specified input ports or all input ports of the design.

Set_max_capacitance [-value] [-port]

set_max_capacitance 1.2 [get_ports IN1]

52
Set_max_transition:
Set_max_transition: Specifies the maximum transition for the specified design or
port list.

● Defines maximum allowed signal transition time for a net, applied to nets
belonging in one clock group, specified ports or entire design.
● The synthesis or optimization tool ensures that the transition time is no
more than specified maximum value.

Set_max_transition [-value] [-design] [-port] [-clock]

set_max_transition 2.5 [get_ports IN1]

53
Create_clock:
Clock: A clock is a periodic waveform with a fixed frequency that is used to sequence
the operation of a circuit. A clock sets the time allowed for signals to propagate
between sequential elements.

create_clock -period period_value [-name clock_name] [-waveform

edge_list]
Ex. create_clock -name 100Mhz -period 10 -waveform {2 8}

● A clock waveform is a periodic signal with one rising edge and one falling edge
per period.
● Create_clock is a sdc equivalent of
define_clock
54
Ex. create_clock -period 20 [get_ports Clk]
Create_clock:
Create_clock: Creates a clock constraints timing paths between registers.

create_clock -period 20 [get_ports Clk]

create_clock___________________

#Clock speed 125 MHz, name sysclock. Now create a clock.

create_clock___________________________________ 55
Create_generated_clock:
Create_generated_clock: Creates a new clock signal from the clock waveform
of a given pin in the design.

● Generated clocks are the clocks that are generated from other clocks.
● Master clocks are defined by ‘create_clock’. The source of generated
clock is specified by -source
● Generated clocks can be divided or multiplied from the main clock by using
-divided_by, -multiply_by
● Duty cycle can also be defined while generate clocks by -duty_cycle
● The -invert option can be specified if the phase of the clock has been
inverted.

56
Create_generated_clock:
create_generated_clock [-name clock_name] -source master_pin [-edges edge_list]
[-divide_by factor] [-multiply_by factor] [-duty_cycle percent] [-invert]

Ex. create_generated_clock -divide_by 2 -source [get_ports

sys_clk] -name gen_sys_clk -master_clock clk -add [get_pins
UFF/Q]

57
Set_clock_sense:
Set_clock_sense: Sets the clock sense on the specified pins and ports.

● -clocks: Specifies the clocks for which the clock sense must be set.
● -logical_stop_propagation: Stops the propagation of the specified clocks
through the specified pins.
● -negative: Specifies that the specified pins and ports are inverted sources of the
clock.
● -pins/-ports: Specifies the name of the pins and ports for which the clock
sense must be set.
● -stop_propagation: Stops the propagation of the specified clocks and clock
source data paths through the specified pins.

set_clock_sense -stop_propagation -clocks CHA_CLK [get_pins

TST_clk_tsa_mux/Z] 58
Set_clock_uncertainity:
Specifies the clock uncertainty for clocks. It is a way to incorporate a margin of
error in the design to account for possible variances in the clock propagation times
in the post-layout design.

● The setup uncertainty is subtracted from the data required time for a path.
● The hold uncertainty is added to the data required time for each path.

set_clock_uncertainty [-from from_clock] [-to to_clock] [-rise_to rise_to_clock]

[-fall_to fall_to_clock] [-rise] [-fall] [-setup] [-hold]

set_clock_uncertainty -setup -rise -fall 0.2

[get_clocks CLK2]
59
Set_clock_uncertainity:
Set_clock_uncertainity: Specify the uncertainty on the clock network. Either a simple
or an inter-clock uncertainty can be specified by set_clock_uncertainty.

● Simple uncertainties are defined directly on a clock, port, pin, or instance.These

uncertainty values are stored in attributes.

Ex. set_clock_uncertainty -setup -rise 0.4 [find / -pin

reg1/CK]

● The inter-clock uncertainties (defined using options such as -from, -to,

-rise_from, -rise_to) are modeled as path_adjust exceptions. These
uncertainties take precedence over the simple uncertainty values.

Ex. set_clock_uncertainty -setup -from clk2 -to clk1 0.5

60
Group_path:
Group_path: The grouping of path can be done using group_path.

● It groups a set of paths or endpoints for timing analysis.

● Paths within a group are optimized and reported separately from the other
groups.

group_path -name inreg -from [all_inputs]

group_path -name regout -to [all_outputs]

group_path -name inout -from [all_inputs] -to [all_outputs]

61
Set_input_delay:
Set_input_delay: Specifies the data arrival times at the specified input ports relative to
the clock specified.

● The set_input_delay command constrains input paths.

● It is used to specify how much time is used by external logic.

set_input_delay [-clock clock_name] [-max] [-min] [-add_delay]

Ex. set_input_delay -clock SYSCLK 1.1 [get_ports MDIO*]
set_input_delay -clock virtual_mclk 2.5 [all_inputs] 62
Set_input_delay:

Ex. set_input_delay ________________________________

63
Set_output_delay:
Set_output_delay: Specifies the required time of the output relative to the clock.

● The set_output_delay command constrains output paths.

● specify how much time is needed by external logic.

set_output_delay [-clock clock_name] [-max] [-min] [-add_delay]

set_output_delay -max 5.4 -clock Clk [get_ports B]

64
Set_output_delay:

Set_output_delay___________________________________
65
Set_clock_transition:
Set_clock_transition: Specifies the clock transition at the clock definition point.

● Specifies the clock transition (slew) on the specified clocks.

set_clock_transition [-rise] [-fall] [-min] [-max]

Ex. set_clock_transition -min 0.5 [get_clocks SERDES_CLK]

66
Set_clock_latency:
Set_clock_latency: Specifies a clock source or network, early or late latency value
of one or more clocks that propagate to the specified pin or port.

● There are two types of latency: network and source.

● Source latency is the clock network delay between the clock definition pin and
its source.
● network latency is the clock network delay between the clock definition pin
and the flip-flop clock pins.

Set_clock_latency [-min] [-max]

[-source] [-early] [-late]
[-clock ] <latency_value>
67
Set_false_path:
Set_false_path: Specifies path for which Genus will ignore timing constraints.

● Used to disable timing-based synthesis on a path-by-path basis.

● Useful for asynchronous paths and logically false paths.

Set_false_path [-from] [-port] [-to] [-port]

set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB]

68
set_max_delay:
Set_max_delay: Specifies the required maximum delay for the specified paths.

● -from from_list: Specifies a list of timing path starting points.

● -to to_list: Specifies a list of timing path ending points.
● The propagation delay through the combinational path must be less than or
equal to max delay.

set_max_delay delay_value [-from from_list]

[-to to_list]

69
Set_multicycle_path:
Multicycle path: A multicycle path is one that requires either more or less than one
clock cycle. That is why those paths need special checks for setup and hold.

Set_multicycle_path: Specifies the paths which requires multiple cycles to operate.

set_multicycle_path 2 -from A -to B

set_multicycle_path 2 -setup -from [get_cells FF1] -to [get_cells FF2]

70
Physical Constraints :

➔ What physical information about the chip is required in order to accurately

calculate the speed of each path?
➔ What information (besides external setup) does tool require in order to
ensure logic S meets timing?
➔ What information (besides input delay) does DC require in order to ensure
71
logic N meets timing?
Environmental Attributes :

72
Modeling Capacitive Load :

➔ In order to accurately calculate the timing of an output circuit, synthesis

tools needs to know the total capacitance driven by the output cells.
➔ set_load allows the user to specify the external capacitive
load on ports:
◆ By default, tool assumes that the external load on ports is 0
◆ You can specify some other constant value, or
◆ The load_of command can be used to specify the external load as the
pin load of a cell in your technology library. 73
Examples :
1. Use set_load to specify a load value on an output port:

2. Use set_load load_of lib/cell/pin to place the load of a gate from

the technology library on the port:

3. set_load [load_of my_lib/and2a0/A] [get_ports OUT1]

4. set_load [expr [load_of my_lib/inv1a0/A] * 3] OUT1

74
Input Driving strength :
➔ In order to accurately calculate the timing of an input circuit, tool needs to
know the transition time of the signal arriving at the input port.
➔ set_driving_cell allows the user to specify a realistic external cell
driving the input ports.
➔ By default, tools assumes that the external signal has a transition
time of 0.
➔ Placing a driving cell on the input ports causes tool to calculate the actual
(non-zero) transition time on the input signal as though the specified library
cell was driving it.

75
Example :
➔ set_driving_cell -lib_cell and2a0 [get_ports IN1]

76
Variation in cell delays:
➔ Library cells are usually characterized using “nominal” voltage and
temperature.
◆ Example:
● Nom_process 1.0
● Nom_voltage 2.0
● Nom_temperature 25

➔ What if the circuit is to operate at a voltage and/or temperature rather

than nominal?
➔ So tool companies allows for synthesis of circuits which will not operate
under “nominal” conditions by embedding operating condition models in the
technology libraries.

77
Example :
➔ Operating conditions can be placed on your design by
using the set_operating_conditions command.
➔ During synthesis, “nominal”cell and wire delays will be scaled
based on the operating conditions.

By default NO operating conditions are specified for a design.

78
Example :
➔ Use report_lib libname to list the vendor-supplied operating conditions.

➔ To set operating conditions enter:

◆ set_operating_conditions -max “slow_125_1.62”

quotes are optional

79
Wire load :
➔ A wire load model is an estimate of a net’s RC parasitics based on the net’s
fanout:
● Model is created by tool
● Estimates are based on statistics from other designs the vendor has
fabricated using this process

80
 Example :
➔ Here we can see a standard
format.
➔ set_wire_load_model -name
160KGATES
➔ Report_lib mylib

➔ Turn off automatic wire load

model selection by set auto_wire_load_selection false 81
Analysis and Report :
❖ all_connected

all_connected {net | pin | port}...

For specified object net, the command returns the list of all the pins connected to the
net. If the object is a pin or a port, the command returns the net connected to the pin or
the port.

❖ all des

all des {inps | insts | outs | seqs}

Generates a Tcl list based on the specified object.The following example returns all the
input ports for the clock named clock1:

rc:/> all des inps -clock clock1 82

Analysis and Report :
❖ all lib

all lib {bufs | ties}

Generates a Tcl list of library cell. “bufs” Generates a list of all the buffers in the loaded
library. “ties” Generates a list of all the tie-cells in the loaded library.

❖ check_design

Provides information on undriven and multi-driven ports and pins, unloaded sequential
elements and ports, unresolved references, constants connected ports and pins, any assign
statements and preserved instances in the given design. In addition, the command can
report any cells that are not in both .lib and the physical libraries (LEF files).

check_design [-lib_lef_consistency][-undriven [-threshold_fanout]]

[-multidriven] [-unloaded] [-unresolved] [-constant [-threshold_fanout]]
[-assigns][-preserved] [-report_scan_pins][-all] [design] [> file] 83
Analysis and Report :
➔ Examples
◆ The following example shows a sample report given when the command is executed without
any options: rc:/> check_design
◆ The following example reports all the possible information on the design.
rc:\> check_design -all
◆ The following example reports the preserved instances in your design.
rc:/> check_design -preserved
◆ The following command reports the cells which are only in .lib or in the physical library (LEF
files). rc:/> check_design -lib_lef_consistency
◆ The following command reports all undriven pins including the DFT-related pins (highlighted
in the report below). rc:/> check_design -report_scan_pins -undriven
➔ By default, if you do not specify an option, the check_design command reports a
summary table

84
Analysis and Report :
❖ Clock_ports
◆ clock_ports [design]
➢ Returns input ports of your design that are clock inputs.Note: Only input ports at the top
level are listed. Gated clocks and clock pins that are present in the hierarchical design
internally (typical PLL outputs) will not be identified.
➢ The following example finds all of the clock ports of a design:
◆ rc:/> clock_ports
➢ In the following example, the clock_ports command is embedded within a create_clock
command to apply a clock waveform to all clock input ports of the design:
◆ rc:/> create_clock -period 3000 -name clk [clock_ports]
❖
❖ Fanout
➢ Returns all the pins and ports in the fanout cone for the specified
pins and ports.

85
Analysis and Report :
❖ Fanin
➢ Returns all the pins, ports, and subports in the fanin cone for the specified pins and ports
➢ The following example returns all the
pins in the fanin cone for port out:
■ rc:/> fanin out
/designs/test/instances_seq/out_reg/pins_out/Q
/designs/test/instances_seq/out_reg/pins_in/CK

➢ The following example specifies to only return the startpoint for port out shown in the
design above:
■ rc:/> fanin out -startpoint out
/designs/test/instances_seq/out_reg/pins_in/CK
➢ The following example executes a path disable from all the start points that fan out to
reg1/D:
■ rc:/> path_disable -from [fanin -startpoint reg1/D]

86
Analysis and Report :
❖ Fanout
➢ Returns all the pins, ports, and subports in the fanout cone for the specified pins and ports
➢ The following example returns all the
pins in the fanout cone of port en
The design shown in figure.
■ rc:/> fanout en

➢ The following example executes a path disable on all the endpoints to which reg1/CK fans
out:
■ rc:/> path_disable -to [fanout -endpoint reg1/CK]

87
Analysis and Report :
➔ report {area | boundary_opto | cdn_loop_breaker | cell_delay_calculation |
clock_gating | clocks | congestion | cwd | datapath | design_rules |
dft_chains | dft_registers | dft_setup | dft_violations |
disabled_transparent_latches | gates | hierarchy | instance | isolation |
level_shifter | memory | memory_cells | messages | net_cap_calculation |
net_delay_calculation | net_res_calculation | nets | operand_isolation | ple
| port | power | power_doamin | qor | scan_power | sequential |
slew_calculation | state_retention | summary | timing | yield}

Generates the specified report on synthesis results.

➔ report clock_gating
◆ Reports clock-gating information for the design.
◆ -detail Reports detailed clock-gating information. Lists all the clock-gating instances inserted,
including the library cell used for the clock-gating cell, the clock-gating style, the signals
connected to the inputs and outputs of the gating logic, and the flip-flops gated by this gating
cell. If you specify only this option, the return value of this command is the total number of
clock-gating logic inserted in the design 88
Analysis and Report :
➔ report_clocks
◆ Generates a report on the clocks of the current design. Reports the clock period,
rise, fall,domain, setup uncertainty, latency, clock ports or sources in the
current design. Use the -generated option to report generated clock
information, and use the -ideal option to report an ideal clock - clock
relationship.
➔ report_congestion
◆ Reports the total number (and percentage) of gcells with overflow, the total
overflow of the design as well as the maximum overflow and the associated
gcell.
➔ report design_rules
◆ Reports any design rule violations that are present in the specified design
objects like Max_transition, Max_capacitance, Max_fanout.

89
Analysis and Report :
➔ report_gates
◆ report_gates [-library_domain library_domain_list] [-power] [-yield]
[-instance_hier instance] [design] [> file]
◆ Reports the technology library cells that were implemented (and identifies their originating
libraries), the area of the cell instances, and the break up of the instances into timing models,
sequential cells, inverters and logic gate cells.
◆ Optionally power information can be reported. Note: Timing models can refer to memory cells, IPs,
integrated clock-gating cells, and so on.
➔ report_nets
◆ report_nets [-hierarchical] [-pin pin...] [-minfanout integer] [-maxfanout
integer] [net | instance]... [-sort string] [-cap_worst integer] [> file]
◆ Generates a report on the nets of the current design. The report gives information for the top-level
nets in the design. You can specify pin names, nets, instances, maximum and minimum fanout
threshold values, nets, and instances.
◆ Control the data printed out using the -minfanout and -maxfanout options for nets that have
fanout between these values.

90
Analysis and Report :
➔ report_ple
◆ report_ple [design]... [> file]
◆ Returns the physical layout estimation information for the specified design. The command
reports information like aspect ratio, shrink factor, site size, layer names, direction of
layers, capacitance, resistance, area, and the source used to extract the physical
information.
➔ report_power
◆ { -rtl_cross_reference [-detail] [-flat [-nworst number]] [-sort
mode] [design | instance] [-mode mode] [-tcf_summary] [-hier | -flat
[-nworst number]] [-depth number] [-sort mode] [design | instance |
net] [-mode mode] [-tcf_summary] -clock_tree [clock] -width float
-height float }
◆ Reports the power consumed. The information returned depends on your current position in
the design hierarchy and on the specified objects. If no objects are specified, the report is
given for the design or instance at the current position in the design hierarchy.
91
Extracting Output files :
➔ Write_def
◆ write_def [-ignore_groups] [-ignore_placed_instances] [-scan_chains]
[design] [-version] [> file]
◆ Writes a floorplan, in DEF format, for the specified design. RTL Compiler does not store all
the information from the original DEF (for example, VIAS, SLOTS, ROWS, TRACKS, etc.).
However, the generated floorplan includes data from both the RTL Compiler session as well
as the original imported DEF. The DEF does not contain the netlist information (net
connectivity information) aside from the power/ground nets defined in the input DEF
(SPECIAL NETS section).
➔ Write_hdl / write -mapped
◆ Write_hdl [-abstract] [-depth] [-equation] [-generic] [-language]
[-lec] [-suffix] [-pg] [> file]
◆ Automatically write out a gzip compressed Verilog file.
◆ Generates a structural netlist using generic logic
◆ Generates a structural netlist using mapped logic
92
Extracting Output files :
➔ write_sdc
◆ write_sdc [-version {1.1|1.3|1.4|1.5|1.5rc}] [-strict] [-mode mode_name]
[-no_split] [design] [> file]
◆ Writes out the current design constraints in Standard Design Constraint (SDC) format. The
write_sdc command can also compress the SDC constraints with gzip (.gz extension).
◆ For those SDCs that are not supported, RTL Compiler will issue a warning message but store
them for output for the write_sdc command. RTL Compiler will only store the SDCs and not
manipulate any data with them

93
Constraints- DC_shell Vs Genus:

94
Constraints- DC_shell Vs Genus:

95
Analyzing Results- DC_shell Vs Genus:

96
Saving design- DC_shell Vs Genus:

Varying default units- DC_shell Vs Genus:

97
Generic Flow:
#set the paths
set_db init_lib_search_path path
set_db init_hdl_search_path path
#load the library
set_db library library_name
#load and elaborate the design
read_hdl design.v
elaborate
#specify timing and design constraints
read_sdc sdc_file
#synthesize the design
syn_generic
syn_map
#analyze design
report_area
report_timing
report_gates
#export design
write_hdl > dessign.vm
write_sdc > constraints.sdc
write_script > constraints.g
98