ASIC DESIGN FLOW

CHIP DESIGN SPECIFICATIONS

⇩
DESIGN ENTRY / FUNCTIONALITY VERIFICATION (GENERATING RTL CODE & VERIFYING)

⇩
RTL SYNTHESIS / LOGIC SYNTHESIS

⇩
PARTITIONING OF CHIP

⇩
DESIGN FOR TESTABILITY (SCAN CHAIN INSERTION)

⇩
FLOOR PLANNING

⇩
PLACEMENT

⇩
CLOCK TREE SYNTHESIS

⇩
ROUTING

⇩
FINAL VERIFICATION(PHYSICAL VERIFICATION AND TIMING) LVS,DRC,LEC

⇩
GDSⅡ (GRAPHIC DATA STREAM)
 ❖ RTL code is developed using microarchitecture of design which is derived from chip design
requirements.
❖ This RTL code description is written using verilog hardware description language (verilog HDL) or
very large scale integration hardware description language (VHDL).

LOGIC SYNTHESIS / RTL SYNTHESIS

❖ In this phase, the hardware description (RTL) is converted to a gate-level netlist. This process is
performed by a synthesis tool that takes a standard cell library, constraints and the RTL code and
produces a gate-level netlist.
❖ Synthesis tools are running different implementations to provide the best gate level netlist that
meets the constraints. It takes into account power, speed, size and therefore the results can vary
much from each other. To verify whether the synthesis tool has correctly generated the gate-level
netlist a verification should be done.
❖ In this stage the technological independent rtl code is converted to technological dependent gate
level netlist using synthesis tool. We are creating a hardware environment which can easily optimize
without changing the functionality.
❖ We are only considering the setup analysis in the synthesis stage with an ideal clock(i.e no skew)
which has one clock period for transferring the data between two registers which can minimize the
setup violations after the post CTS and routing stages.
❖ We are also considering zero wire load models for logic synthesis

Setup slack : data required time > data arrival time

Tcapture + Tcycle - Tsetup - Uncertainty > Tlaunch + Tck2q + Tcombo +Twire
Hold slack : data arrival time > data required time
Tcapture + Thold < Tcomb+Tck2q+Tlaunch+Twire+Uncertainty
EDA tools for logic synthesis :
Synopsys - DESIGN COMPILER (DC)
Cadence - INNOVUS
Steps required to convert RTL code to gate level netlist using DC tool :
Inputs required
➢ RTL code
➢ .lib (liberty/library file) or .db file
Lib file is basically a timing model file which contains cell delay, cell transition time, setup and hold
time requirement of the cell. So Lib file basically contains the timing and electrical characteristics of
a cell or macros.
Synopsys uses .db format files which are not readable
Cadences uses .lib format files which are readable
➢ Synopsys design constraints (timing constraints).
Outputs
➢ Gate Level netlist - net.v
➢ SDC constraints
➢ reports
READING LIBRARY FILES
We are reading libraries using three key words in DC TOOLsuch as
1. search_path
2. link_library
3. target_library
 set search_path "../inputs /proj1/pd/test_cases/28nm/alu/synthesis_dc/inputs/28_libs/hvt.db/
/proj1/dataIn/Rock_R2G/TSMC_28nm_collaterals/std_cells_and_memory/tsmc28nm_9track_hvt_BE_FE
/TSMCHOME/digital/Front_End/timing_power_noise/CCS/tcbn28hpcplusbwp30p140hvt_180a/
/proj1/dataIn/Rock_R2G/TSMC_28nm_collaterals/std_cells_and_memory/ts1n28hpcpuhdhvtb2048x129
m4swbso_170a/NLDM/”
➢ Whenever the tool needs a file, it searches for the required file in the paths which are assigned to
this keyword.
Set link_library "tcbn28hpcplusbwp40p140hvtffg0p88v125c.db
tcbn28hpcplusbwp40p140hvtssg0p72v125c.db tcbn28hpcplusbwp40p140hvttt0p8v25c.db
tcbn28hpcplusbwp40p140hvtffg0p88vm40c.db tcbn28hpcplusbwp40p140hvtssg0p72vm40c.db"
➢ The link_library variable specifies every library that has cells referenced by the netlist.
➢ The tool uses the libraries specified in the link_libary variable for resolving references(linking).
➢ The link_library can include memory (RAM, ROM or any macro) in addition to the standard cell
library.
set target_library "tcbn28hpcplusbwp40p140hvtssg0p72vm40c.db"
➢ The target library variable specifies the library that the design compiler uses to select cells for
optimization and remapping. It is typically set to only the standard cell library.
Technologically dependent cells are mapped in this stage during optimization.
➢ In target_library we use the worst PVT corner .db file(i.e high threshold voltage(hvt), slow slow
process, low voltage, high/low temperature) to meet the setup slack.
➢ We use max data path for setup, if it meets the worst corner then every PVT corner, setup slack will
be achieved with the same optimization technique.
Sanity check :
get_libs whether the libs are loaded or not.

analyze -format verilog alu.v

➢ This command reads the RTL file and checks for the syntax errors in the file.
➢ If any syntax errors are found report it to the RTL team.
elaborate rp_top_top
➢ All the codes and arithmetic operators are converted into Gtech and DW (Design Ware)
components. These are technology independent libraries.
Gtech- contains basic logic gates & flops.
DesignWare- contains complex cells like FIFO, counters.
➢ Links the every cell instantiation called in the RTL file with GTECH and DESIGNWARE cells which are
technology independent.
❖ If any cells which are called from RTL are not available in gtech or designware components then the
referred cell is linked from the library files, which are loaded in the link_library variable.
➢ When RTL file references are missing it gives the unresolved references or black box as error.
ERROR: while the design is elaborating it gives the unresolved reference when the referred module is not
found in the .lib files in the link_library variable.
Fix : To fix this error, make sure all the referred modules should exist in the files which are stored in
link_library.
To verify this check rtl file with the get_designs command.
Sanity checks after elaborate :
get_designs checks whether all modules called in the rtl file are loaded or not.
Error : It gives an error as linking error when referred modules are not loaded in the design.
FIX : To fix this we have to use the link command or reload the rtl file into the tool.

check_design
➢ Checks related to design :
○ Floating pins
○ multi driven inputs
○ un-driven inputs and outputs
○ normal cells in clock path
○ pin direction mismatch
○ don’t use cells
Runs predefined or user-defined checks on current design.
1. Input pin floating
Error: If any input pins are floating in the design it gives the error, this input causes the logic functionality
change due to coupling capacitance the voltage at input pin may vary between logic 0 and logic 1 which
gives the metastable state and high power dissipation takes place because of short circuit between power
and ground. This could be a major issue.
FIX: This can be eliminated by connecting the floating pin to either logic 0 , 1 Or report to the rtl team.
2. Output pin floating
Error: if the output pin is floating there is no issue because the synthesis tool removes the path for timing
analysis. Because there is no continuity and functionality requirement in the path from input to output
port.
FIX: this error can be fixed while optimizing the design by tool, it removes the paths like this.
This is called pruning.
3. Multi Driven logics
Error: this error is caused when the logic gate doesn’t know which input to take while it is connected to
two or more logic outputs.
FIX: this fault belongs to the rtl team. We should report it to the rtl team.

SDC CONSTRAINTS:

❖ STATIC TIMING ANALYSIS (STA) is the best method for determining timing analysis, if the circuit
meets the timing constraints without having to simulate.
❖ We should provide required timing constraints based on the design , the tool checks the slack
violation using STA(static timing analysis).
create_clock -name clk -period 2.22 -waveform {0 1.11} [get_ports clk]
➢ We should provide the clock constraints to all the clk ports in the design.
create_generated_clock -multiply_by 2 -name ckGen2x -source clk [get_pins ckGen/U8/Z]
➢ If there is any pins which has the source clk input we should create generated clk
set_clock_uncertainty 0.4 [get_clock clk]
➢ We are setting 20% of clk period as clock uncertainty which is an ideal case. We took it as the limit
for the possible deviation of the clk edge from its ideal location.
set_clock_latency -source 0.2 clk
➢ We are setting insertion delay from clock source to clock definition point as 10% of clock period.
set_clock_latency 0.2 clk
➢ Similarly, we are setting insertion delay from clock port to clk sink point of sequential elements as
10%.
set_input_delay 1.33 [all_inputs] -clock clk
➢ We are setting input delay as 60% of clk period for every register to input port paths.
set_output_delay 1.33 [all_outputs] -clock clk
➢ Similarly, we are setting output delay as 60% for every output port to register paths.

❖ For feed through paths the delay is considered as 30% ideal case, otherwise we get input from full
chip level.
set x [filter [all_fanout -from [all_inputs]] "port_direction == out"]
➢ We are filtering out feed through paths from input to output and taking output ports as a list.
set y [filter [all_fanin -to [all_outputs]] "port_direction == in"]
➢ We are filtering out feed through paths from output to input and taking input ports as a list.
set_input_delay 0.77 [get_ports $y] -clock clk
➢ We are setting input delay as 35% for every register to input port paths.
set_output_delay 0.77 [get_ports $x] -clock clk
➢ We are setting output delay as 35% for every output port to register paths.
❖ We are creating four group paths and checking whether the timing constraints have been met or
not.
group_path -name i2o -from [all_inputs] -to [all_outputs]
group_path -name i2r -from [all_inputs] -to [all_registers]
group_path -name r2r -from [all_registers] -to [all_registers]
group_path -name r2o -from [all_registers] -to [all_outputs]
Sanity check :
➢ Checks related to timing : check_timing
○ Combinational loops
○ Un-clocked registers
○ unconstrained IO’s
○ IO delay missing
○ Un-expandable clocks
○ Master slave separation
○ multiple clocks : checks if there are any multiple clocks in the design.
This command checks for possible timing problems in the current design.
1. Unclocked registers
Error: check timing gives the unclocked registers where clock is not coming to the clk pin of registers.
Fix: to fix this issue define the clk in the constraints as ‘create_clk -name’.
2. Unconstrained endpoint
We can find how the cell is unconstrained by checking the fanin of clk pin of sequential elements and
checking the clock pin of the predecessor register by finding the all_fanin of the output pin of the register.
Error: it gives unconstrained endpoints when the clock is not connected to the register of the predecessor
stage or clk pin is connected to either logic 0 or 1. It also gives unconstrained output while the output pin
of the predecessor register is connected as a clock pin to the next register, whose clock pin is connected
to either logic 0 or 1.
Fix: to fix this issue either define the clock in sdc constraints or report to the rtl team if the clock pin is
connected to either logic.
 3. Unexpandable clocks
Error: in the design many clocks are used with different frequencies, the two different clock frequencies
which are not multiple to each other get the timing violation in a particular path.
Fix: to fix this issue the clock synchronizer should be used between two different clock domains or false
path as timing exceptions can be used.
We should report this to the rtl team about the clock synchronizer in the design .
4. Racing condition
Error: this gives the list of combinational loops, because of continuous looping the higher power
dissipation takes place.
Fix: we can use timing exceptions here like creating a false path as this error is from the rtl side.

TIMING EXCEPTIONS :

❖ Timing exceptions allow you to modify the default timing analysis rules for specific paths, such as
multicycle paths, false paths, and minimum and maximum delays.
1. set_false_path
2. set_multicycle_path
3. set_max_delay
4. set_min_delay
report_transitive_fanout -from spi_clk
➢ This command reports the information of the full path with which this clk port is connected.
set_false_path -from [get_ports spi_clk] -to [get_pins spi_slave0/spi_clk_q_reg/D]
➢ A false path is a path existing in a design which should not be analyzed for timing.
➢ If there are two different clocks which are not synchronized and a path between two multiplexed
blocks that are never enabled at the same time etc couldn’t meet the setup slack.
set_multicycle_path 2 -from [get_pins REGc/regout_reg[1]/CP] -to [get_pins MUL1/q_reg[12]/CP ] -setup
➢ In this step we are creating a multicycle for reliable capture of required data by setting the number
of clock cycles in a path.
set_max_delay
➢ With this command we can set more time to the path which is violating.
Set_min_delay
➢ This command is mainly for hold operation, we can set minimum delay to particular path.
set_driving_cell -library tcbn28hpcplusbwp30p140hvtssg0p72vm40c_ccs -lib_cell
BUFFD0BWP30P140HVT [remove_from_collection [all_inputs ] clk]
➢ If we don’t set the drive strength for input ports, there is no limit in driving by input ports which
cause the delay in the cells due to high transition time and load, it leads to violation in setup slack.
set_max_capacitance 2 [all_outputs]
➢ Similarly, as in case of output ports it is not defined to limit HFNS, which leads to increase in delay.
set_max_area 0
➢ We are setting max area to zero, so that the tools tries to use as minimum area as possible.
Compile
❖ In this phase mapping is done with the cells in the target library files which are referred with the
gtech and designware components.
Performs Boolean optimization.
Maps all the cells to technology libraries.
Performs logic and design optimization.
 ➢ Logic optimization
○ Constant folding
○ Detect identical cells
○ Optimize mux(dead branches in mux) ,consolidate mux and reduce inputs(many to single)
○ Remove DFF with constant value
○ Reduce word size of the cells
○ Remove unused cells and wires
➢ Design optimization
○ Reduce TNS and WNS
○ Power Optimization
○ Area Optimization
○ Meet the timing DRV’s
○ incremental clock gating.
report_timing
➢ This command gives the report of the worst setup slack violation of every path group in the design.
➢ If any path gives the setup violation then we need to set the weightage to the violated path group.
➢ This weightage value multiplies with TNS value and the higher the value gets the more time to
optimize the path groups which are violated.
group_path -name i2r -from [all_inputs] -to [all_registers] -weight 3
group_path -name r2r -from [all_registers] -to [all_registers] -weight 4
❖ Again run the design using compile command, even if the setup slack is slightly violated then we can
go for the compile_ultra command.
compile_ultra -no_boundary_optimization
➢ This command takes more time for optimization and mapping than the compile command.
ERROR : reg to reg path slack is violating with higher value because the timing path uses different clock
sources without synchronizer. So, it does not meet the setup slack.
FIX: I used a false_path as a timing exception for that path after apprising the RTL team.
❖ If the slack is met then we need to get the gate level netlist and sdc constraints.
write_file -hierarchy -format verilog -output ../reports/net.v
➢ Get the gate level netlist file
write_sdc -version 2.1 ../reports/rptop.sdc
➢ Get the sdc constraints file
❖ If we import UPF file and scan config (for DFT) then we get the UPF file and ScanDEF file-information
of scan flops and their connectivity in a scan chain as an output from synthesis.
sizeof_collection [get_flat_cells ]
➢ Note the collection of cells in the design
Sanity check :
report_qor (quality of results )
➢ This command reports the TNS and WNS of the design, count of leaf cells, sequential and
combinational cells and also the information related to the power and area of the design.
check_timing
➢ Displays the pins related to timing information
check_library
➢ It checks the relation between logical and physical of library cells.
report_constraints
➢ It gives the report of timing violations of constraints and the violating cells.
check_netlist
➢ The command checks the design for netlist connectivity errors and and design violations. This
command gives preliminary information about the state of the netlist and if there are any potential
problems with the netlist. This informs about the potential errors that might occur during the later
stages.

NOTE :
➢ Even after the compile_ultra phase, if the slack is violated with higher negative value (i.e greater
than 40% of clock) then we need to check the cause of the violations in the path group.
➢ If there are no issues in the RTL code we can use the timing exceptions and pipelining process to
fix the violations in that path group.
➢ If there is a slight setup slack violation in (picoseconds) we can proceed to the physical design
flow which can fix this violation after the routing stage.

PHYSICAL DESIGN

❖ In this first stage of PD flow after partitioning the chip into blocks from full chip level, the
required files of related blocks are imported into the tool.
Inputs required :
1. Gate level netlist in verilog format.
2. Logical (Timing) & Physical views of standard cells & all other IPs used in the design, ndm file (new
data mode) (.lib and .lef of standard cells)
3. Timing constraints (SDC)
4. Power Intent (UPF / CPF)
5. FloorPlan DEF & Scan DEF
6. Technology file (.tf)
7. RC Co-efficient files tlu+ (ITF file)

READING FILES:
create_lib rptoplib -ref_libs
Sanity check :
get_libs c
➢ whether the .lib files are loaded or not.

read_verilog ../inputs/final_netlist.v
➢ Read the verilog netlist which is the output of logic synthesis.
get_layers -filter "is_routing_layer == true"
➢ Collecting the routing layers.
set vertical_layers [gets stdin]
set horizontal_layers [gets stdin]
➢ Dividing the layers into horizontal and vertical directions.
set_attribute [get_layers $vertical_layers ] routing_direction vertical
➢ Assigning the selected layer routing direction as an attribute which defines the direction of the layer
i.e vertical layers.
set_attribute [get_layers $horizontal_layers ] routing_direction horizontal
➢ Assigning the selected layers routing direction as an attribute which defines the direction of the
layer i.e horizontal layers.
 FLOORPLAN

➢ Floorplan is one the critical & important steps in Physical design. Quality of your Chip / Design
implementation depends on how good the Floorplan is. A good floorplan can be made into an
implementation process (place, cts, route & timing closure) cake walk. On similar lines a bad
floorplan can create all kinds of issues in the design (congestion, timing, noise, ir, routing issues). A
bad floorplan will blow up the area, power & affect reliability, life of the IC and also it can increase
overall IC cost (more effort to closure, more LVTs/ULVTs).
➢ Before starting Floorplan, it is better to have basic design understanding, data flow of the design,
integration guidelines of any special analog hard IPs in the design. And for block/partition level
designs understanding the placement & IO interactions of the block in Full chip will help in coming
up with a good floorplan.
➢ In flooplan DEF file contains the information about shape of block, core utilization, side_ratio or
side_length, macro, IO placement, blockages and keepout margin etc.

Types of floorplan techniques used in Full Chip plan

1. Abutted (All inter block pin connections are done through FTs).
2. Non abutted (Channel based. All inter block pin connections are routed in channels).
3. Mix of both – partially abutted with some channels.

initialize_floorplan -control_type die -core_utilization 0.65 -shape R -orientation N -side_ratio {1 1}

-core_offset {2.2 1.4} -flip_first_row true -coincident_boundary true.
➢ This command is used to create floorplan using switches ,the values for switches provided by full
chip level.
➢ Generally we take core utilization around 60 - 70 percent, and the other switches control_type (die
or core), shape is rectilinear (R, L, U, T) orientation,side_ratio(side_ratio considers the block of the
block using height and width with area of total number of cells in netlist with core_utilizatin factor,
side_length is the direct values of the sides of the block, flip_first_row is the default condition
which the cell rows with vdd and vss the cells at first row and second shares the common point by
flipping the cell while placing.

IO PORT PLACEMENT:

❖ After the floorplan we need to place the pins according to fullchip level arrangement depending on
the communication with other blocks.
❖ IOs / Pins are placed at the boundary of the block. Usually pin placement information is pushed
down from the FC floorplan. But these locations can be changed based on block critical
requirements. Any change in pin location has to be discussed with the FC floorplan team. Timing
critical interfaces need special attention, like the next 2-3 levels of logic from IOs are pre-placed
near the IOs). Source synchronous interfaces requires delay balancing taking OCV into
considerations (This will require manual placement & scripting)

create_pin_guide -boundary {{-0.1 100} {2.1 250}} -name rp_inputs [get_ports -filter "direction == in"]
-pin_spacing 1
➢ To place the pins we need to create a boundary between the core to die space with the coordinates
with lower left and upper right.
place_pins -ports [get_ports -filter "direction == in"]
➢ This command places the pins in the specified boundary with pin to pin spacing.(input ports)
create_pin_guide -boundary {{1378 100} {1379.9 300}} -name rp_outputs [get_ports -filter "direction ==
out"] -pin_spacing 1
➢ Similarly, create a boundary for output ports.
place_pins -ports [get_ports -filter "direction == out"]
➢ This command places the pins in the specified boundary with pin to pin spacing.(output ports)

Sanity check :
Check_pin_placement
➢ This command checks whether the pin placement is done correctly without overlapping.
Errors : the pin placement errors are caused due to more number of ports placed in small boundary
regions with large spacing between pins. The pins also place around the core to die region, if we do not
provide the correct coordinates while creating the pin_guide.
Fix : create a pin guide with a larger boundary.

MACRO PLACEMENT

➢ There are certain guidelines for macro placement. Macro placement can be done automatically and
manually. some guidelines are not a must for the placement of macros.
➢ The command for automatic placement of macros is
create_placement -floorplan with the app_option plan.macro.macro_place_only set to true.
➢ This app option stops the placement once the macros have been placed.
➢ After placing the macros automatically it does not follow some guidelines properly so, we can
change placement of macros according to guidelines and fly line analysis.
Guidelines:
1. Macros should be placed near the core boundary.
2. Same hierarchy macros should be grouped.
3. Create a keep out margin to avoid abutting with standard cells.
4. Avoid port access issues due to macro placement.
5. macro pins face towards core region (std cell area).
Precautions :
➢ Macros should not overlap.
➢ Create soft blockages in notches.
➢ Create soft keep out margins.
➢ Macro pins should align to tracks.

PREPLACEMENT CELLS :
➢ In this preplacement stage some physical only cells need to be added before placement of standard
cells. These physical only cells need to be placed at certain positions to avoid some issues caused
due to the latch up in standard cmos structure using N-tub process and process variations at
boundaries of chips.
Boundary cell:
create_boundary_cells -left_boundary_cell tcbn28hpcplusbwp30p140hvt/BOUNDARY_LEFTBWP30P140
-right_boundary_cell tcbn28hpcplusbwp30p140hvt/BOUNDARY_RIGHTBWP30P140 -prefix ENDCAP
➢ To avoid well-proximity effect and N-well continuity the boundary cells are placed on either side of
the cell rows.
➢ Below 16nm design boundary cells are placed on all sides of the design.
Tap cell:
create_tap_cells -lib_cell tcbn28hpcplusbwp30p140hvt/TAPCELLBWP30P140 -distance 30 -pattern stagger
-prefix TAP -skip_fixed_cell
➢ To avoid latch up effect due to the standard cmos structure, the unwanted parasitic BJT are formed.
➢ Tap cells are inserted at every 30um distance in 28nm technology, for 16nm technology these cells
are placed for every (<45um) distance.
➢ We are placing tap cells in staggered patterns for better connectivity with the same area.
Sanity_checks :
check_boundary_cells
check_tap_cells
ERRORS : The error comes when the boundary cells and tap cells are not aligned to the rails perfectly i.e
legal positioning of cells. The cause of the error is macros obstructing the legal position of physical cells
that obstruct the connection of physical cells ro rails.
FIXES:
1. This error can be fixed by moving the macros that leave space for connection of physical cells to
rails.
2. We can obstruct the placing of cells around the boundary of macros by keeping hard blockage.

POWER PLANNING :

➢ In this stage we are providing power supply to the block. The power requirements of the block are
defined from full chip level.
➢ To create a power plan we need to take higher metal layers, because higher metal layers have less
resistance due to high cross sectional area, it carries high currents, these layers are directly
connected to the power supply.
➢ All blocks have to follow the same pitch and spacing between stripes to align at full chip level.
➢ The stripes of the second level grid only connect to the core boundary to not get any metal to metal
shorts.
➢ As coming to lower layers the resistance increases with metal layers, the required power for the
region could be achieved by the level shifters connecting from grids to rails.
➢ To create a power plan we need to create supply ports and supply nets and create logical
connections between supply pins of standard cells, macros to the supply nets.
create_port -port_type power -direction in VDD
create_port -port_type ground -direction in VSS
create_net -power VDD
create_net -ground VSS
connect_pg_net -net VDD [get_pins -physical_context */VDD]
connect_pg_net -net VSS [get_pins -physical_context */VSS]
➢ To create power planning in icc2 tool we need to create some strategies to create core rings, power
grids and vias .
➢ The required values for creating strategies will be from full chip level like number of stripes for first
level grid, the metal layers used for it and second level rid and the metal layers, offset distance ,
min width of metal, min spacing, pitch.
➢ Creating a lowermost layer for rails {VDD,VSS},min width, min spacing, etc, for the alignment of cells
between these rails.
➢ While creating pg strategy we need to assign metal layers as VDD and VSS nets.
➢ we should compile these strategies using the compile command.
PRECAUTION:
We need to set the app option to true to disable the automatic creation of PG vias.
Create multi stacked vias which reduces the resistance from single via enclosure.
➢ We are creating pg vias from first level grid to second level grid from M9 to M8 to M7 to M6 to M5.
➢ After that again pg vias are created from M5 to M1, passing through M4 ,M3,M2 with different
array dimensions.
➢ The creation of two PG vias is due to different pitch values of metal layers in the design.the format
this design follows is 4 2 2 1 {M9 to M6} {M5 , M4} {M3,M2} {M1}.
➢ Creating master vias for macro pins i.e M5 to M4. The power supply pins for macros are in the M4
layer.

The commands used to create power planning :

#To disable via creation during compile pg
set_app_options -name plan.pgroute.disable_via_creation -value true
###To create M1 rails
create_pg_std_cell_conn_pattern rail_pattern -layers M1 -rail_width 0.15
set_pg_strategy M1_rails -core -pattern {{name: rail_pattern} {nets: VDD VSS}}
###Define PG mesh for M5 to M7 layers (only in core region)
create_pg_mesh_pattern m5tom7_mesh_pattern -layers {{{vertical_layer: M5} {width: 0.45} {spacing:
minimum} {pitch: 5.0} {offset: 0.6}} \{{horizontal_layer: M6} {width: 0.45} {spacing: minimum} {pitch: 5.0}
{offset: 0.6}} \ {{vertical_layer: M7} {width: 0.62} {spacing: minimum} {pitch: 3.0} {offset: 0.6}}}
set_pg_strategy PG_mesh -core -pattern {{name: m5tom7_mesh_pattern} {nets: VDD VSS}} -extension
{{layers: M5} {stop: 0.2}}
##Define PG mesh for M8 & M9 (extended till die boundary, assuming they need to be aligned at top)
create_pg_mesh_pattern m8m9_mesh_pattern -layers {{{horizontal_layer: M8} {width: 1.52} {spacing:
minimum} {pitch: 6.0} {offset: 3.2}} \ {{vertical_layer: M9} {width: 3.0} {spacing: minimum} {pitch: 7.3}
{offset: 3.48}}}
set_pg_strategy M8M9PG_mesh -design_boundary -pattern {{name: m8m9_mesh_pattern} {nets: VDD
VSS}} -extension {{stop: design_boundary_and_generate_pin}}
compile_pg -strategies {M8M9PG_mesh PG_mesh M1_rails}
###Create PG vias
set layer_pairs [list {M9 M8 VIA89_1cut} {M8 M7 VIA78_1cut} {M7 M6 VIA67_1cut} {M6 M5 VIA56_1cut}]
foreach lyr_pr $layer_pairs {
set frm_lyr [lindex $lyr_pr 0]
set to_lyr [lindex $lyr_pr 1]
set via_mstr [lindex $lyr_pr 2]
puts "$via_mstr"
#create_pg_vias -from_layers $frm_lyr -to_layers $to_lyr -nets {VDD VSS} -within_bbox [get_attribute
[current_block] bbox] -via_masters $via_mstr
create_pg_vias -from_layers $frm_lyr -to_layers $to_lyr -nets {VDD VSS} -within_bbox [get_attribute
[current_block] bbox]
}
##Creating pg vias between M1 & M5
set_pg_via_master_rule via1_rule -contact_code VIA12_1cut -cut_spacing 0.1 -via_array_dimension {3 1}
set_pg_via_master_rule via2_rule -contact_code VIA23_1cut -cut_spacing 0.1 -via_array_dimension {3 1}
set_pg_via_master_rule via3_rule -contact_code VIA34_1cut -cut_spacing 0.1 -via_array_dimension {3 1}
set_pg_via_master_rule via4_rule -contact_code VIA45_1cut -cut_spacing 0.1 -via_array_dimension {3 1}
create_pg_vias -from_layers M5 -to_layers M1 -nets {VDD VSS} -within_bbox [get_attribute
[current_block] bbox] -via_masters {via1_rule via2_rule via3_rule via4_rule}
puts "USER_INFO: ####----------------------End of PG insertion--------------------------------####"
#Via over macro pins
set_pg_via_master_rule via4_macro_rule -contact_code VIA45_1cut -cut_spacing 0.1
-via_array_dimension {3 2}
create_pg_vias -from_types macro_pin -from_layers M4 -to_types stripe -to_layers M5 -nets {VDD VSS}
-via_masters {via4_macro_rule}

Sanity checks :
check_pg_drc this command gives the drc violations.
ERRORS : the drc errors are formed due to metal shorts and metall spacing issue due to via enclosure
coming out of the metal.
FIXES :
1. metal shorts can be fixed by using connect_pg_net -automatic command to connect all
unconnected power and ground pins based on the power domain connections.
2. Metal spacing issue can be resolved by decreasing the metal spacing while creating the pg mesh
and also fix manually by positioning the vias inside metal.

Check_pg_missing_vias:
check_pg_missing_vias -ignore_small_intersections
➢ This command checks for missing vias between overlapping regions of different metal layers. The
error info can be viewed from the error browser written to a file. You can define via rules to be
checked by writing the rules to a file and importing the file with the -via_rule_file option.
Check_pg_connectivity
➢ This command checks the physical connectivity of the power ground network. The command
generates information for floating wires, vias, pads, macro pins, and standard cell pins. The
information can be viewed by using the error browser. More detailed info can also be written to
file. The command also returns a collection of floating vias and wires. You can easily remove these
floating objects using remove_objects command.

MMMC CORNERS :
➢ There are two different modes in our design, so design has to be checked for timing for each mode.
The two different modes are 1) functional mode and 2)scan mode
➢ In lower technology nodes the minimum width of the metal is less ,so small variation in metal width
due to etching or improper fabrication can cause the delay of the metal ,due to change in RC, so we
have to consider all these variations during manufacturing.
➢ so we have to sign off the design at different RC corners.
➢ closing the design at all the scenarios is difficult and increases our runtime ,so some of the
scenarios are redundant, excluding them based on the design requirements.
➢ We are creating PVT corners and read the parasitic tech files based on RC corners
{Setup-RCworst & Cworst, Hold Cbest & RCbest}
➢ After that we are setting different operating conditions for different scenarios based on creating
worst scenarios for setup and hold requirements.

#creating mode
create_mode func
sanity_check:
get_modes
It gives the created mode list

set b 0
set e 0
set h 0
#creating PVT corners
set x {ss1_0p81v_125c_rcw ss1_0p81v_m40c_cw ff1_0p99v_125c_rcb ff1_0p99v_m40c_cb}
foreach i $x {
create_corner $i
sanity_check:
get_corners
It gives the list of corners created

#creating RC corners
set a {_rcw _cw _rcb _cb}
set d [lindex $a $e]
set y [ lsearch -all -inline [ glob /home/guepd08031susdp21/vnth/synthesis/rp_top_top/pnr/inputs/* ]
*$d* ]
read_parasitic_tech -name $j -tlup $y
incr e
sanity_check:
get_parasitic_techs
➢ It gives the list of loded parasitic tech files of different rc corners.

#setting operating conditions

set z [ list {0.81 0.00 125} {0.81 0.00 -40} {0.99 0.00 125} {0.99 0.00 -40} ]
current_corner $i
set_voltage [ lindex [ lindex $z $b] 0] -object_list VDD
set_voltage [ lindex [ lindex $z $b] 1] -object_list VSS
set_temperature [lindex [ lindex $z $b] 2]
set_process_number 1.0
set_operating_conditions -analysis_type on_chip_variation
set_parasitic_parameters -early_spec $d -late_spec $d -corners [ get_corners $i ]
incr b

#creating scenarios
set f {func_setup func_setup func_hold func_hold func_hold }
set g [lindex $f $h]
create_scenario -mode func -corner $i -name $g-$i
incr h
}
sanity_check:
report_scenarios
This command gives the report of modes, corners, active state of setup and hold, maxcap, maxtran,
mincap.
set_scenario_status -setup true -hold false [get_scenarios *setup*]
 ➢ We are making the setup active for rc worst and c worst corners.
set_scenario_status -setup false -hold true [get_scenarios *hold*]
➢ We are making the hold active for rc best and c best corners.
current_mode func
source ../inputs/rp_top.sdc
➢ For every mode we should read the sdc file.
current_scenario func_setup_ssg0p81vm40c_cw
➢ For every scenario we check the violations using the report_constraints command.

PLACEMENT

Precautions before placement :

set_lib_cell_purpose -include none [get_lib_cells { CK* *D24* *D21* *D18* *D16* } ]
➢ We are taking a list of cells as don’t use cells which have higher drive strength leads to Maxtran
violations that increase the cell delay which leads to violation in the critical path.
set_app_options -name place.coarse.continue_on_missing_scandef -value true
➢ We are making this app option from default false to true i.e to proceed to further stage without
including the scandef config. file.
add_buffer -lib_cell tcbn28hpcplusbwp30p140hvt/GBUFFD8BWP30P140HVT -new_cell_names
PORT_BUFFER [remove_from_collection [get_ports ] {VDD_1 VSS_1 clk spi_clk}
➢ We are adding a port buffer cell to limit the drive strength of the port as equal to buffer cell
strength. If we don’t add the buffer cell to the port it has no limit in driving the cell which leads to
timing violations.
magnet_placement -mark_legalize_only [get_ports] -cells [get_cells *PORT*]
➢ This magnet placement command places the buffer cells near to the port with legalized locations i.e
proper alignment to rails.

Standard cells placement :

❖ Placement of standard cells based on

1. Timing driven or timing aware placement.
2. Routing aware placement. (congestion)
3. Density aware placement.
❖ For placing the standard cell we use the place_opto mega command to do the operation in five
stages.
❖ We can skip to any stage in the place_opto command for standard cell placement.

set_app_options -name opt.common.user_instance_name_prefix -value INITIAL_PLACE

➢ We are setting an app option to create the cell name with a prefix.
➢ By setting the app option we got to know how many new buffer or inverter cells are added in
place_opt stage . We need to set an app option at each stage to know how many cells are added at
each stage.
➢ These buffers are added to meet the max tran and max cap limit . (long net)
Place_opto
set_app_options -name opt.common.user_instance_name_prefix -value INITIAL_PLACE
place_opt -to initial_place
sizeof_collection [get_cells *INITIAL_PLACE*] >> ../outputs/cellcount.rpt
 ➢ In INITIAL_PLACE stage rough or coarse placement of standard cells takes place based on timing
and congestion.
➢ The cells overlap on each other and legal placement does not take place in this stage.

set_app_options -name opt.common.user_instance_name_prefix -value INITIAL_DRC

place_opt -from initial_drc -to initial_drc
sizeof_collection [get_cells *INITIAL_DRC*] >> ../outputs/cellcount.rpt
➢ In the INITIAL_DRC stage having more than predefined fanout, gets buffered due to limiting the
fanout i.e HFNS(high fanout net synthesis).
➢ To avoid maxcap violations we are limiting the fanout of the cells.

set_app_options -name opt.common.user_instance_name_prefix -value INITIAL_OPT

place_opt -from initial_opto -to initial_opto
sizeof_collection [get_cells *INITIAL_OPTO*] >> ../outputs/cellcount.rpt
➢ In the INITIAL_OPTO stage data path optimization takes place by adding buffers. This is due to
long nets between the cells which dominates the cell delay(lower nodes).
➢ Pin swapping takes place in this stage to meet the setup critical.
➢ Layer promotion avoids the usage of buffer adding , it goes with connection of routing between
the cells with higher metal layers which has less resistance (i.e less delay) when there is a long
net.

set_app_options -name opt.common.user_instance_name_prefix -value FINAL_PLACE

place_opt -from final_place -to final_place
sizeof_collection [get_cells *FINAL_PLACE*] >> ../outputs/cellcount.rpt
➢ In this FINAL_PLACE stage, final placement of cells takes place with legalized placement i.e proper
alignment of standard cells to the rails.

set_app_options -name opt.common.user_instance_name_prefix -value FINAL_OPT

place_opt -from final_opto -to final_opto
sizeof_collection [get_cells *FINAL_OPTO*] >> ../outputs/cellcount.rpt
➢ IN this FINAL_OPTO stage , incremental optimization takes place.

CHECKS AND FIXES :

➢ CHECK_LEGALITY: this command is used to check if all the standard cells are placed correctly or
aligned to the standard cell row, and also it will check if there is any overlap in the standard cells.
FIXES: this cell overlap is due to higher utilization ,the fix is to increase the die or core area, this also
might happen if manual placement of any cell is improper ,the fix could be to do the manual
placement correctly.
➢ CELL_DENSITY: This command used to check the cell density of our design, the tool will divide the
entire design into 5*5 boxes (means 5 standard cell height and 5 standard cell width), so in each box
it will check the density of cells, or in each area or box it will check the utilization. • It is only a
concern if the high-density boxes are clumped together which looks like a red coloured hotspot in
the cell density map.
FIXES: create partial blockage for that particular region, and rerun the place opt,so this is how we
can control the standard cell placement in certain regions.
➢ PLACEMENT_UTILIZATION: This command used to check the utilization jump from floor plan to
after placement. After placement if you are seeing the higher utilizations this may be due the
addition of buffers during place_opt,or due to over buffering in the place_opt stage .
 FIXES: if the higher utilization after place_opt is due to over buffering ,then its due to tighter max
tran limit,the max tran limit is too less the tool will try to over buffer to meet the transition
requirement, so ,check the max tran limit ,and change it.
➢ CHECK CONGESTION IN GUI: Check the congestion map in the design, it will show the capacity and
demand (demand of metal tracks and capacity of metal tracks)of a particular GRC (global routing
cell),if demand greater than capacity then it is overflow, if demand less than capacity then it is
under flow. It is of a concern only when all the GRCS with high overflow are next to each other (as
detours can be performed if high overflow grcs are spread)
● The congestion is mainly due to high pin density in a particular region, this can be due to
complex AOI or OAI cells sitting next to each other.
● To tell if congestion is due to high pin density, congestion map and pin density map can be
opened parallelly.
FIXES: if the congestion is due to AOI OR OAI cells sitting next to each other, the fix will be ,give cell
padding or keepout margin between AOI or OAI cells to avoid congestion issues .
➢ Another cause of congestion is insufficient macro to macro spacing, this will cause congestion.
FIXES: To avoid the congestion due to insufficient macro spacing, go back to floor plan and increase
the channel spacing as appropriate.
➢ Another reason for congestion is the lower number of routing tracks available around macro
corners.
FIXES: create partial blockage around macro corners.
➢ REPORT_CONSTRAINTS : this command can be used to check setup ,max tran ,max cap, and hold
violations .
➢ SETUP violation cause:
➢ It can be due to too many buffers added in the Datapath.
FIXES: create bounds to avoid logic spread to reduce the number of buffers.
➢ Another reason for over buffering can be a tight limit on max tran/max cap.
FIXES:
● So this can be fixed by giving a reasonable max tran/max cap limit.
● If the setup violations are limited then, use a group path with critical range and give more
weightage for these endpoints.

➢ Another cause can be unoptimized nets (if there is any don’t touch on the net, then it will cause
setup violations).
FIXES: remove the don’t touch on the particular net and rerun the place_opt.
➢ Another cause can be, if two hierarchy cells have many data paths which are too long, this can also
cause setup violations.
FIXES: create soft bound for the two hierarchies and rerun the place_opt.
➢ Another reason can be if a net is crossing to macros which have no space between them the net
cannot be buffered leading to bad transitions and setup violations.
FIXES: move the macros apart and create a soft blockage between them ,so that there is enough
space to add a buffer.
➢ MAXTRAN and MAXCAP : The max tran and max cap violations can be due to non bufferable
regions,high fanout,lower drive strength cells ,long nets .
FIXES:if the violations are due to long nets then add the buffer, if the violation is due to weak driver
then upsize the driver ,check if max transaction limit is there are not, the violations can be due to
non bufferable regions, if the max cap violations are due to tie cells .then change the tie cell fanout
,to reduce maxcap violations.
 ➢ ANALYZE_DESIGN_VIOLATIONS -ALL_VIOLATORS ,there are many options in this command like
maxtran, setup, max capacitance. By using this command with a particular option, we can find the
various reasons behind that violation, it will show all categories of violations.
➢ REPORT_QOR This command can be used to get the number of violating paths ,worst negative slack
and total negative slack, and how many paths are violating in each scenario.

CLOCK TREE SYNTHESIS

➢ First we have to set the target skew for the clock ,the command we can use to specify the target
skew is SET_CLOCK_TREE_OPTIONS TARGET_SKEW < VALUE> -CLOCKS COLLECTION OF CLOCKS.
➢ After setting the target skew,the next step is to update the uncertainty(as uncertainty until cts
contains skew component as well),the uncertainty is decreased by the amount of target skew in the
previous step,for better timing qor target skew can be lower value,the command set clock
uncertainty is to be applied with the switches -setup ,-hold -scenarios ,hold uncertainty can be set
to 30ps.
➢ The next step is to create NDRS for the clock tree routing,the command create_routing_rules with
switches -rules -multiplierspacing and -mutiplierwidth ,generally double width and double spacing
is used.if design demands for shielding for clock tree then the switch -SHEILD can be used.
➢ To set the above created routing rule to the clock tree, set_clock_routing_rules - clocks clk
-max_routing_layer -min_routing_layer -rules is used. The above command not only sets the
routing rule but also provides a restriction to the clock tree as to which layers are permissible.
➢ Next step is to create the CTS references, the cells to remove from this are:- low drive strength cells,
high drive strength. Also if the design contains multiple VT cells, it is preferred for cts that all the
clock cells are of a single VT. Apart from this, the tool needs to be restricted to only the cells that
were designed to be used in clock paths.
set_lib_cell_purpose -exclude cts [get_lib_cells]
set_lib_cell_purpose -include none [get_lib_cells CK*]
set_lib_cell_purpose -include cts [get_lib_cells {CK*4* CK*6* CK*8* CK*12* CK*16*}]
The above commands are used to set the clock tree references.
➢ Declare all the explicit clock tree exceptions if required. The command set_clock_balance_points
can be used to set any explicit clock tree exceptions. The switches determine the clock tree
exceptions (-delay, -consider_for_balancing, - clocks, -balance_points).
➢ Clock skew groups can also be created by using the command create_clock_skew_groups with the
switches –name and –objects.
➢ The final step before running CTS is to activate all the scenarios that might have been disabled
during the previous stages. (Meeting hold is necessary after post CTS).
➢ Run the first two stages of clock_opt (build_clock and route_clock) or the command
synthesize_clock_tree can be used. After this stage, for post-CTS optimization, we include the use of
DEL* cells and D1* cells for hold fixing and running the final stage of clock_opt (final_opto). The
below command can be used for the same.
set_lib_cell_purpose -include hold [get_lib_cells */DEL*]
set_lib_cell_purpose -include hold [get_lib_cells *BUFFD1*]
APP OPTIONS USED :
➢ cts.common.user_instance_name_prefix, this app option is used to specify the prefix that is used
for the cells placed during clock_opt.
➢ clock_opt.flow.enable_ccd, this app options can be modified to enable or disable ccd.
➢ cts.common.max_fanout, this app option mentions the max fanout limit for clock cells.
 ➢ clock_opt.flow.enable_global_route_opt, this app option is used to enable or disable the global
route stage of the clock_opt.

Checks and fixes:

➢ Post CTS skew, latency and other reports can be generated using report_clock_timing with switches
-skew, -latency, -to, -from, -verbose.
➢ To get a summary of the clock DRC, max latency and max skew for each scenario use
report_clock_qor.
➢ After the skew and latency checks,timing and constraint checks have to be performed,as
setup,hold,max tran,max cap,need to be met. report_constraints with switches -all_violators,
-max_trasition, min_delay, -max_delay, -max_capacitance can be used.for checking timing report of
a path ,report_timing can be used for hold checks with switch -delay_type min_delay is used.
➢ Analyze_design_violatiors command with the switch -type can be used to categorize the violations
with different parameters .It can be used to debug the cause of the violations.
➢ Max tran or max cap fixes are the same as that of the place_opt stage .
Setup violation cause :
Setup violations in cts are mostly caused because of the negative skew.negative skew might occur due to
the over buffering of launch clock or no buffering on the capture clock.one reason for the tool to not to
place the buffers in the capture clock path is due to high cell density.
Fixes:
This can be fixed by placing appropriate partial blockage in the placement stage .one reason for over
buffering can be due to high hold uncertainty . (as tool,will place buffers to increase delay ) ,the simple fix
for this problem is to set reasonable hold uncertainty and rerun the CTS.another reason for over buffering
can be an error in sdc such as wrong clock edge check during declaration of multicycle path statement.
Hold fix:
If there is a hold violation post cts,a simple fix would be to add buffers in the data path,DEL* buffer or d1*
cells can be used for this purpose.
➢ After all the timing and DRVS meet,congestion and cell density maps have to be checked again for
any presence of any hotspots.

ROUTING
➢ Before routing can be performed we need to set app options.
➢ If there is a requirement to treat some nets as special nets ,maybe timing critical nets ,the
command route_group can be used . For nets known to be prone to crosstalk, a NDR
 (create_routing_rules) and set_routing_rules commands are used for this) can be created with
1w2s and can be routed using this command .
➢ After the routing of clock nets and critical nets, signals can be routed. For routing signal nets ICC2
provides the command ROUTE_OPTO , alternatively routing can be performed in stages, the
commands route_global, route_track, route_detail, route_auto.

APP OPTIONS USED :

➢ Route.detail.hop_layersbto fix antenna,this app option Is used to specify whether layer hopping or
insertion of antenna diodes are used to fix antenna effect.
➢ Routr_opt.flow.enable_ccd ,this app option is used to turn ccd on during route opt.
➢ Route.detail.check_patchable_drc_from_fixed_shapes ,this app option helps fix some DRC which
can be resolved by metal patching.
CHECKS :
➢ After the CTS the timing violations are mainly due to three reasons.
➢ They are crosstalk,detours,and pre route to post routes RC estimation.
➢ Crosstalk violations .
➢ These violations due to crosstalk can be seen by using the command REPORT_TIMING -CROSSTALK
-DELTA.
FIXES:
➢ The nets that are prone to this can be routed specially,NDR of 1w2s can be created and set for these
nets,these specific routes can be removed using remove_routes - nets collection of nets
-detail_route and can be routed again by using the rout_eco - nets collection of nets.
➢ Crosstalk increases if the net length is too long, so the net can be broken using a buffer. The
command add_buffer_on_route with the switches -repeater_distance _ratio and -lib_cell can be
used to add the buffer on the route without disturbing any logical connections of other nets.
➢ Another fix for violation due to crosstalk is to upsize the victim net driver or to downsize the
aggressor net driver.
DETOUR VIOLATIONS :
➢ The tool might take the detour while routing net, this may be because all the routing resources
available may have been exhausted ,this can be fixed by checking congestion map, if the congestion
map suggests pf any hotspot, then the simple fix is to fix the underlying congestion issue.
➢ If there are only a few nets that are violating due to detour, then fixing congestion by going back to
the placement is wise . all the paths that are timing critical can be routed using routing corridors
which would avoid any possible detours of the nets, the command create_routing_corridor with the
switches -name 0bjects,-min layer ,- max layer path can be used .
PREROUTE TO POST ROUTE RC ESTIMATIONS ERRORS:
➢ Rc estimation of the tool pre cts may not be accurate,it can be checked if this is the source of errors
by comparing a violating paths report timing capacitance pre and post routing .if the difference is
large enough then icc2 has a provision to account for this.
➢ Before proceeding to the next stages it need to be make sure that, wns for setup<50ps, enough
place is left for hold buffer placement ifa lot of hold violations are present .drc count <200,and
shorts and opens <30 ,maxtran, maxcap have no violations.

PHYSICAL SYNTHESIS

➢ It is nothing but a timing optimization technique to fix negative slack.

➢ Timing budget include
 1. Allocate target delay along with path and nets.
2. Done during placement and routing stage.
3. Also be done during timing correction optimization.
➢ Timing correction done by various technique
1. Gate sizing
2. Buffering
3. Netlist restructuring
4. Cloning - sometimes we have to replicate the gate for a gate containing a large number of
fanouts and gate delay will be large so we use cloning.
5. Redesign Fanin tree
6. Redesign Fanout tree
7. Swapping commutative pins without changing cell logic. violations and finally there should
not exist any legality issues.