Logic Synthesis

1. Steps and major precautions

- The first step is to read the logic libraries related to the design (libraries related to the linking
stage must be present). (set link_library ). After the link libraries readind, the library with the
worst case delay is chosen as the target library. (set target_library)

- Next, all the RTL files need to be read and analyzed for syntax errors. The command analyze
with -format switch can be used to perform this action. (analyze -format verilog alu.v)

- The next step is to elaborate the design and link the references. This step is where the HDL
codes are translated into GTECH (technology independent design) and DesignWare
components. The command for this step in dc_shell is elaborate.

- SDC contains commands related clock definition, uncertainty, IO delays, max tran, max cap and
path groups, driving cells and loads for ports. A special precaution that needs to be taken is to
provide sufficient time for feed-through paths (i2o paths).(derates)

- Next step in the synthesis flow is to map our generic cells to actual cells (cells in target library),
the command compile is used in dc_shell to achieve this. During compile the tool performs
optimization and maps our design into technology dependent cell level design.

3. Checks and Fixes

- To verify if all the required libraries and designs are read, the get_libs and get_deisgns
command can be used.

- All the errors in RTL have to be reported to the RTL team (from analyze command).

- Elaboration can produce unresolved references or black boxes, which could mean that the
instances referenced in the RTL code are not defined. This can be resolved by checking if all
the required link libraries are read.

- check_design is an important sanity check that needs to be performed before SDC.

check_design performs various checks (multidriven inputs, floating i/o pins, pin count
mismatch).(write about harms and other things due to floating io pins and others).
 - check_timing is a sanity performed after the SDC has been read. Several checks are done as
part of this (unconstrained endpoints, clock crossing, combinational loops, unexpandable
clocks). If unconstrained endpoints error pops up, the following might be the issues, the
mentioned register may not be receiving a clock, the driver of the mentioned register might
not be getting the clock, ports may not be having input output delays. (all_fanin, all_fanout,
get_pins might be useful commands while solving these errors).

- - report_timing, is the command used to check the path with worst slack, various options
such as -group, -to, -from, -nworst, -lesser_than, -greater_than can be used to check timing
of the required paths.

- report_qor(quality of results) command displays TNS, WNS and various other details about
the design. If some paths have TNS, then appropriate weights need to be added to these
paths and re-compile the design.

- If the design synthesized after thus process does not converge with setup constraints,
compile_ultra command can be used, the tool places more computational effort to meet the
timing.

- If timing is not met yet then, maybe the reason for the setup cause is due to high levels of
logic or the depth of logic. (Add about timing exceptions).

Floorplan

1. Steps and Major Precautions

- First step is to read all the .lefs and .libs (ndms for ICC2) (create_lib –ref_lib -technology).
Next netlist from the synthesis stage can be read (read_verilog). After the libs and Verilog
are read, direction of the metal layers have to be set (set_attribute <collection of metal
layers> -direction <horizontal/vertical>)

- initialize_floorplan command is used to create the floorplan of the design, some useful
switches are:- -aspect_ratio, core_utilization, core_offset, orientation, boundary, shape etc.

- Pin guides need to be created for the tool to know where the ports are to be placed, the
command create_pin_guide can be used to create the pin guides, with the switches -
boundary, -pin_spacing , -name. place_pins -self, will place the ports in the locations
designated by the guides.

- Next step is macro placement, Macros in the design can be placed manually or
automatically. While placing the macros one has to follow the macro guidelines and flyline
analysis. Appropriate keepout margins and Macro spacing should be given to avoid issues in
placement and routing. (create_keepout_margin with –type and -outer option can be used)

- Auto macro placement can be achieved by create_placement –floorplan (see the app option
for this in section 2).

- Before placement of standard cells, some physical only cells need to be added to the design
to ensure the proper working of the design. Tap cells have to be inserted every 30um, a
staggered pattern can be used. The command create_tap_cell with the switches -offset, -
distance, -lib_cell, -prefix,-pattern can be used. Boundary cells are to be inserted at either
ends of the core boundary and macro boundaries, LEFT and RIGHT boundary cells are
present in the libraries, these can be added with the command create_boundary_cells and
options -left -right -prefix etc.

- Pg planning is the next step, if power nets and ports are not in the design, then create the
ports using the commands below.
create_port -direction in -port_type power $vdd_port

create_port -direction in -port_type ground $vss_port

create_net -power $vdd_net

 create_net -ground $vss_net

- After the creation of ports and nets, to connect the pg ports and nets with the pg pins of all
the cells in the design. The commands below are used for this purpose.

connect_pg_net -automatic

connect_pg_net -net $vdd_net [get_pins */VDD*]

connect_pg_net -net $vss_net [get_pins */VSS*]

connect_pg_net –automatic

- Using the power calculations required, create the pg shapes required, pg rings, pg staps and
pg rails. create_pg_ring_pattern, set_pg_strategy, compile_pg commands with appropriate
switches are to be used.

2. App options used

- plan.macro.macro_place_only, this app option stops the placement once the macros have
been placed. An important thing to notice is if the auto macro placement is in cohesion with
macro guidelines, else it needs to be fixed.
- plan.pgroute.disable_via_creation, to stop the tool from creating vias by itself.
- plan.pgroute.via_site_threshold, set this app option to 1 to stop creation of vias on
incomplete intersection of metals.

3. Checks and Fixes

- check_pin_placement, is the command needed to check if the pin placement is valid.

Possible error being pin overlap/shorts, this might occur due to the pin guide being smaller
than necessary. To solve this, check if appropriate pin spacing is given during pin guide
creation.

- Pg checks that are to be performed are:- check_pg_drc, check_pg_missing_vias,

check_pg_connectivity. Shorts might be caused if some vdd and vss of cells are not
connected to vdd and vss nets. Run the above commands of pg pin connection and rerun the
checks.
Placement

1. Steps and Major Precautions

- Before the start of placement, a prerequisite is to read/create an MMMC file. First step is to
create the required modes, ICC2 has the command create_mode. Next step is to read all the
necessary ITF files, the command read_parasitic_tech is used to read the tluplus files in
ICC2. After the creation of modes, corners are defined iteratively. To create a corner
create_corner command is used, for each created corner, its parameters are set by using
set_process_number, set_process_number, set_voltage, set_temperature,
set_parasitic_tech and set_operating_conditions –analysis_type on_chip_variation.
Scenario creation is the next step, the command create_scenario can be used and the
command set_scenario_status is used to disable hold checks and fixing in setup scenarios
and vice versa. The final step is to disable hold scenarios, this is achieved by
set_scenario_status <collection of hold scenarios> -active false.

- After the MMMC file, SDC can be read for each mode. read_sdc can be used.

- The above 2 steps are prerequisites for starting the process of placement. Once they are
completed, the process of placement can be started. To start off, a constraint on max tran
and max cap can be placed (a good reference point can be that of a D8 buffer). The
commands set_max_transition <transition_limit> and set_max_capacitance
<capacitance_limit>.

- Next step is to tell the tool which cells to use and which not to. For placement, clock cells,
delay buffers and high drive strength cells should not be used. In ICC2 the command
set_lib_cell_purpose -include none {CK* DEL* *D24* *D18* *D16* *D20* *D21*} can
be used to achieve this.

- Before placement, port buffer need to be added. The port buffers are added with the
command add_buffers with the switches –lib_cell, -new_cell_names –new_net_names. As
port buffers are to be placed next to the ports a magnet placement can be done with ports
being used as the magnet objects. magnet_placement <collection of magent objects> -
cells <collection of port buffers>. A set_dont_touch can be placed on these buffers so as to
not disturb them during the placement.
 - The last step is to run place_opt, it can be run as is or in parts by using the switches –from
and –to. The stages can be listed by the using the –list_only.

2. App options used

- place.coarse.continue_on_missing_scandef, generally place opt stops running if scan def is

missing, but us this app option is set to true the placeopt proceeds without a scan def.
- opt.common.user_instance_name_prefix, this app option is used to set the prefix of cells
added during place opt
- opt.tie_cell.max.fanout, controls the fanout of the tie cells added during place opt
- plan.macro.macro_place_only, this app option when set true stops place opt after macro
placement, so this app option needs to be disabled.

3. Checks and Fixes

- check_legality, this checks if placement is legal, might include non-alignment to rails or

overlapping cells. The reason for legality violations might be due to manual placement of
cells. This can be solved by removing a set_dont_touch (it is an attribute) or unlock the
cells and run the legalize_placement command for these particular cells. Another reason for
legality issue is for high cell density (check the high cell density point for resolving this).

- Cell density can be checked in GUI. The tool creates a cell density map for analysis. The
design is temperature mapped, the red part of the spectrum of cell density represents high
cell density. It is of a concern only if there exist cell density hotspots (scattered high density
regions are fine). If the density is in a particular area, then creating a partial blockage can do
the job (create_placement_blockage –type partial is the command), else if the cell density
throughout the design then the only option is to increase the design area.

- Congestion check is the next check, the command report_congestion or GUI can be used for
creating a congestion map. Similar to density map, a congestion map maps high overflow to
the end of red spectrum. And only the areas with congestion hotspots are a concern. A
partial blockage can be created. Alternatively if a specific set of cells (cells with high pin
density like AOI or OAI cells, a pin density map can be created too, to check if congestion
 is due to pin density) are the reason behind congestion, then a padding/keepout margin can
be created for these specific cells. Another reason for congestion can be due to macro
corners, a cautionary step for a design with bigger area is to create a partial blockages
around macro corners beforehand. Insufficient macro spacing is also a reason for
congestion, the minimum spacing can be calculated using the macro spacing formula.

- For timing qor and DRV checks, the commands report_timing with –group –to and –from,
report_qor, report_constraints with –all_violators and –type, analyze_design_violations with
–type switch are used.

- Setup violations, the causes could be due to over addition of buffers, this might happen due
to very tight limit on tran and cap, a simple fix is to set a reasonable values to trans and cap
and rerun the place_opt.

- Another reason for setup violation is because of un-optimized nets, this might happen due to
setting the net to set_dont_touch. This causes the tool to not buffer these data paths and
hence cannot be optimized for setup.

- Distant placement of cells that communicate with each other is another reason, this can
solved by using appropriate bounds, create_bound with the switches –type and –boundary
can be used for this problem.

- Another reason for timing violations is due to bad input transitions.

- If these above do not fix the violations, then creating a group path (create_group –from and
–to can be used). After the path group creation assign high weights to this specific path
group and rerun the place_opt.

- Max tran/max cap are also caused due to unoptimized nets, the fix is the same as mentioned
above.

- Net going through a un-buffereable region is also cause, the net might got through hard
placement blockages, macros etc. If the net is above multiple macros, move the macros
apart and create soft blockages between them, so that the tool has some place to add buffers.

- Tie cells do not have multiple flavors of drive strengths, that means that tie cells’ fanout
should be limited. The app option mentioned in the section 2 of placement can be set to 1 or
 2. Instead of limiting the faonout of the tie cells which might increase the cell count, a
buffer can be added to tie cells to increase the drive strength.

- If set_max_capacitance and set_max_transition is already not set then it can be set and rerun
the place_opt.

- Lastly, as CTS is yet pending a permissible amount of setup violations are allowed, as some
useful skew can fix it.

Clock Tree Synthesis

1. Steps and Major Precautions

- To start with, we decide our target and set it to the desired clock tree, the command
set_clock_tree_options –target_skew <target_skew> -clocks <collections of the 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 decrease by the amount of the
target skew given in the previous step. (For better timing qor target skew can be a lower
value). The command set_clock_uncertainty is to be applied with the switches –setup, –hold
and -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 the switches –rules –multiplier_width and -multiplier_spacing
can be used. (Generally double width and double spacing is used). If design demands for
shielding of the clock tree, then the switch –shield can be used.

- To set the above created routing rule to the clock tree, set_clock_routing_rules -clocks clk
-max_routing_layer <max_layer> -min_routing_layer <min_layer> -rules <routing
rule name> 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 path.

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.

- Before running clock opt, if there is a necessity of routing blockages needed, they can be
created.

- The final step before running CTS is to active all the scenarios that might have been
disabled during the previous stages. (As meeting hold is necessary 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 run 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*]

2. 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.

3. 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 comprehensive 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_transition, min_delay, -max_delay, -max_capacitance can be used. For
checking timing report of a path, report_timing can be used, for hold checks the switch –
delay_type min_delay is used.

- analyze_design_violators command with the switch –type can be used to categorize the
violations with different parameters. It can be used to debug the cause of violations.

- Max transition/max cap fixes are the same as that of the place_opt stage.

- Setup violations in CTS are mostly caused because of the negative skew. Negative skew
might occur due to overbuffering of launch clock or no buffering on the capture clock. One
reason for the tool to not place buffers in the capture clock path is due to high cell density.
This can be fixed by placing appropriate partial blockage in the placement stage. One reason
for over buffering can be due high hold uncertainty (as tool will place buffers to increase the
delay), the simple fix for this problem is to set reasonable hold uncertainty and rerun the
CTS. Another reason for over overbuffering can be an error in SDC such as wrong clock
edge check during the declaration of a mutli cycle path statement.

- 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. set_min_delay for the data paths
can also be provided to resolve this issue.

- After all the timing and DRVs meet, congestion and cell density maps have to be checked
again for the presence of any hotspots.

Routing

1. Steps and Precautions

 - Before the start of routing, if there is a requirement to create routing blocakges, the
command create_routing_blockages with the switches –nets, -layers, -name_prefix, -
boundary can be used.

- 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 prone to x-talk, a NDR
(create_routing_rules and set_routing_rules commands are used for this) can be created
with 1w2s and can be routed to using this command.

- After the routing of clock nets and critical nets, signal nets can be routed. For routing signal
nets ICC2 provides the command route_auto, alternatively routing can be performed in
stages, the commands route_global, route_track, route_detail can be used for this
purpose.

2. App options used

- route.detail.hop_layers_to_fix_antenna, this app option is used to specify whether layer

hopping or insertion of antenna diodes are used to fix antenna effect.

- route_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 options helps fix some DRC

which can be resolved by metal patching

3. Checks and Fixes

- Timing violations post routing can happen due to 3 reasons crosstalk, detours, pre-route to
post-route estimation.

- Violations due to cross-talk: It can be seen in report_timing –crosstalk_delta the impact of

crosstalk on timing. To fix these violations, the nets that are prone 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 the nets> -detail_route and can be
routed again by using route_eco –nets <collection of the nets>.

- Crosstalk increases if the runlength 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 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’s driver or to downsize
the aggressor net’s driver. (Be cautious of this, as it may lead to –ve slacks in setup or hold,
if enough slack is not there before changing the size of the driver).

- Violations due to Detours: The tool might take a detour while routing a net, this maybe
because all the routing resources available may have been exhausted. This can fixed by
checking congestion map, if the congestion map suggests of any hotspots, then the simple
fix is to fix the underlying congestion issue.

- If there are only few nets that are violating due to detour, then fixing congestion by going
back to the placement stage 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, –objects, –min_layer, –max_layer, –
path can be used.

- Estimation Issues: RC estimations of the tool pre routing may not be accurate, it can be
checked if this is the source of errors by comparing a violating path’s report_timing –
capacitance pre and post routing. If the difference is large enough then ICC2 has a provision
to account for this.

- Apart from timing qor, there can DRC and LVS issues as well ,the commands for these are
check_route and checklvs respectively. To route open nets, route_eco –open_nets can be
used. As for shorts, if the shorts are scattered around the design and are less than 200 then it
is not of a concern, but if the shorts are clumped then the congestion map has to be checked
and needs to be fixed.

- Before proceeding to further stages it needs to be made sure that; WNS for setup < 50ps;
Enough space is left for hold buffer placement(if a lot of hold violations are present); DRC
count < 200; short and opens < 30; maxtran, maxcap have no violations and finally there
should not exist any legality issues.