0% found this document useful (0 votes)
14 views40 pages

Place_and_Route_Flow

This document outlines the step-by-step process for place and route using Cadence Innovus in digital VLSI design. It covers workspace setup, design inputs, design import, floorplanning, and pre-placement of physical cells, providing detailed commands and best practices for each stage. The guide emphasizes the importance of maintaining a structured directory and using shared files to streamline the design flow.

Uploaded by

cyhbtx2b6c
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views40 pages

Place_and_Route_Flow

This document outlines the step-by-step process for place and route using Cadence Innovus in digital VLSI design. It covers workspace setup, design inputs, design import, floorplanning, and pre-placement of physical cells, providing detailed commands and best practices for each stage. The guide emphasizes the importance of maintaining a structured directory and using shared files to streamline the design flow.

Uploaded by

cyhbtx2b6c
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 40

Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Basic Place and Route Flow - Step by Step


This guide will take you through the place and route flow in Cadence Innovus.

1 Workspace Setup
1.1 Directory Structure
You can set up your workspace however you like, but here is my suggestion (illustrated in Figure 1):
• Project Root: Start a new directory, which will be the source for your entire project. Inside
the root directory, you will have separate directories for the source code, the simulation
environment and the physical implementation.
• sourcecode: This is where you store all your RTL files. A subdirectory (tb) will store all your
Testbench files.
• simulation: This is where you will run your incisive (or other tool) logic simulations. Store
your scripts inside the scripts subdirectory.
• rtl2gds: This is where you will run all your backend flow, from synthesis, through place and
route. The rtl2gds directory will (at least) the following subdirectories.
o workdir: The workdir is where you will actually run your place and route (P&R) tool, so
all the “junk” that they put out will be stored “out of the way”. You can also set up
several workdirs for different runs, if you want to save old log files or whatever.
o synthesis: This is where you will run your synthesis with RTL Compiler or other tool.
o inputs: This is where you will store or link to the inputs to your tools, such as design
definitions, SDC files, etc.
o scripts: This is where you will store your scripts for running your tools.
o export: This is where you will dump your exports, such as netlists, saved states, etc.
o reports: This is where you will dump your reports for different stages of the flow.

Project root sourcecode tb


simulation scripts
rtl2gds workdir
synthesis
inputs
scripts
export
reports
Figure 1: Suggested Workspace Setup

1.2 Design Inputs


A very strong suggestion is to share as many common files as possible between tools, with conditions in
the scripts to adapt to each tool. This will eliminate the need for updating multiple files during every
edit/change along the way. For example, if there is a change in your SDC and you maintain a separate

©Adam Teman 2017 1


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

SDC for synthesis, pre-CTS, and post-CTS, you will need to update each one of them when deciding on a
change. Instead, create one file and point to it with each tool, maintaining a global variable that can be
used to condition what parts of the file are (not) read.
Accordingly, I suggest preparing the following files in your inputs directory that, if necessary, are
shared by several tools:
• defines.tcl: A TCL file that includes definition of basic definitions that are relevant for the
design, such as the name of the top level module ($design(TOPLEVEL)) and the target clock
period. The majority of the values defined in this file are stored in the $design TCL array,
introduced below.
• libraries.tcl: A TCL file that includes definitions for paths and important files that are
provided as part of the PDK and/or the libraries to be used at various stages of the flow by all
projects implemented in this technology. The majority of the values defined in this file are
stored in the $paths and $tech_files TCL arrays, introduced below.
• TOPLEVEL.sdc: The constraints file that is shared by synthesis and P&R.
• TOPLEVEL.mmmc: The Multi-Mode Multi-Corner (MMMC) view definitions file that is shared by
all tools (synthesis, P&R). See Section 12.2 for example syntax.
• TOPLEVEL.cpf: The Common Power Format (CPF) file that is shared by all tools (simulation,
synthesis, P&R, LEC).
• TOPLEVEL.ccopt: The Concurrent Clock Optimization (CCOpt) specifications file for this
project. See Section 12.4 for example syntax.
• TOPLEVEL.io: The I/O definition file to provide a location for the toplevel I/Os. See Section
12.3 for example syntax.
Note that in the framework of this introductory course, we will not use a CPF file and we will
not use an MMMC file during synthesis.
1.3 Global Variables
In order to “make a bit of order” in our design flow, I suggest to define a number of global variables
and TCL arrays (=key/value pairs) that store the variables that will need to be accessed at various
stages of the design. I suggest using as few standard variables as possible, and instead use arrays, as
this helps eliminate variable duplication and since they can be passed to TCL procedures with a single
global definition, which simplifies code maintenance.
Recommended global variables and arrays:
• design: a global array with key/value pairs to store design-particular values, such as target
clock period.
• paths: a global array with key/value pairs to store paths to PDK/library installation and work
directories.
• tech_files: a global array with key/value pairs to store paths to important files from the
PDK/libraries.

2 Design Import
The first step, when moving from Synthesis to P&R is to import the design. The command that initiates
design import is init_design, which starts running various procedures according to a number of

©Adam Teman 2017 2


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

preset variables. These can either by defined by command line (recommended) or set up the first time
with the FILEIMPORT DESIGN form.
2.1 Important Design Import Variables
The following variables should be set prior to design import (GUI field name in MENU FORMAT):
• init_verilog: VERILOG The post synthesis verilog netlist (I recommend linking to the
synthesis export from ../inputs/TOPLEVEL.v)
• init_lef_file: LEF FILES A list of the lef files that define the abstract layouts of all IPs
(standard cells, memories, I/Os, other macros).
Note that If the technology LEF is separate from the standard cell LEF, then the technology file
must be the first member in the list.
• init_io_file: The I/O configuration file (../inputs/TOPLEVEL.io) that you prepared
apriori. See Section 12.3 for I/O file syntax.
• init_gnd_net, init_pwr_net: POWER NETS and GROUND NETS Creates global nets named for
each member of these two lists and defines them as toplevel power and ground nets.
Note that this does not connect the power/ground nets to the power/ground pins of the
standard cells and macros. You will need to use globalNetConnect to connect the pins to
these nets.
• init_mmmc_file: MMMC VIEW DEFINITION FILE Sources the MMMC script that sets up the LIBs,
extraction rules, constraints, etc. See Section 12.2 for an example MMMC script.
Note that you can use the CREATE ANALYSIS CONFIGURATION form to set up an initial MMMC
view definitions file, but I highly recommend editing this and storing your own file for repeated
use.
• init_cpf_file: CPF FILE If you are running a CPF flow, you should point to a CPF file instead
of an MMMC View Definition file (only one of them will be loaded!). This does not load all CPF
commands, just those that are equivalent to MMMC commands, and you will need to define RC
Corners separately.
An example script for setting these variables and initiating init_design is given in Section 12.5. The
design import form is shown in Figure 2 with some example values.

©Adam Teman 2017 3


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 2: Design Import Form

2.2 Checking Design Import Results


The init_design command initiates many operations and procedures, which run automatically.
These include:
• Loading the LEF files
• Reading the Verilog netlist
• Loading the MMMC or equivalent CPF definitions, including
o Loading the LIB files
o Loading the extraction rules
o Loading the design SDC
There are many potential mistakes that could have been made along the way, such as a syntax error in
one of the definition scripts or the SDC, or perhaps a change in the path of a file. Therefore, it is
essential to carefully go over the logfile after design import finishes and rerun it after fixing any errors
and important warnings, until the results are satisfactory.
Finally, run the checkDesign command:
checkDesign -all

©Adam Teman 2017 4


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

3 Floorplanning
After design import, the tool will be in “Floorplan View”, which will show you (see Figure 3):
• Center: a default floorplan with the locations of the I/Os (if an I/O file was provided)
• Left: A hierarchical view of the verilog modules, sized according to estimated standard cell area.
• Right: A box for each hard macro (such as SRAMs) according to their LEF defined shape.

Figure 3: Floorplan View after Import Design

3.1 Specify Floorplan


The floorplan box at this stage is set either according to the I/O configuration file or based on a default
utilization (70%) with a 1:1 ratio. However, you should setup the floorplan according to your specific
intent. This is done with the floorPlan command or the FLOORPLANSPECIFY FLOORPLAN form, shown
in Figure 4.

Figure 4: Specify Floorplan Form

You can specify the floorplan according to various parameters, such as:
• Coordinates
• Width and Height
• Aspect ratio and Initial Utilization (based on gate size from the netlist)

©Adam Teman 2017 5


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

In addition, you can specify the distance between the borders of the design and the core area (where
the standard cell rows are created). If you have I/Os then this distance will usually be from the inner
boundary of the I/O ring to the core area. This space is usually used to make rings for the power and
ground signals and leave room from routing to the I/Os.
An example command for specifying a floorplan with a square ratio, a target utilization of 70% and 5
microns between the boundary and the standard cell rows (with the standard cell SITE called “CORE”) is:
floorplan -site CORE -r 1.0 0.7 5 5 5 5
For additional details see the user manual or run man floorPlan .
3.2 Place Macro Cells
There are three basic ways to place macro cells:
1. Drag and Drop: In the Floorplan View, drag the boxes on the right and manually set them inside
the floorplan area.
2. Specify coordinates for the macro: Use the setObjFPlanBox command. An example
placement would be:
setObjFPlanBox Instance SRAM1 {10 20 30 40}
3. Use relative floorplannig: Use the FLOORPLANRELATIVE FLOORPLANEDIT CONSTRAINT form to
define a relative placement for an instance, such as x and y from the design corner or from
another instance.
3.3 Add Rings around Macros
It is usually a good idea to add power/ground rings around macros in order to enable easy connection to
the power stripes and connection to the power/ground pins of the macros themselves. As usual, this can
be done through the command line, using the addRing command or through the GUI with the
POWERPOWER PLANNINGADD RING form, shown in Figure 5.
When defining rings, you will need to set the nets (vdd, gnd, etc.), the layer for the horizontal (top and
bottom) and vertical (left and right) edges, the widths of the rings, the spacing between them, etc. An
example command for adding VDD and GND rings in M1 and M2 around a selected macro would be:
selectInst ${TOPLEVEL}/SRAM1
addRing -around selected -nets {VDD GND} -type block_rings \
-layer {bottom metal1 top metal1 right metal2 left metal2} \
-width 4 -spacing {bottom 0.24 top 0.24 right 0.28 left 0.28} \
-offset 0.31
deselectAll

©Adam Teman 2017 6


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 5: The Add Rings Form

Note that some macros, especially SRAMs, are designed to efficiently connect to the
power/ground stripes in high layers without needing rings in order to save area.
3.4 Add Halos around Macros
Good practice is to add placement blockage around macros, so the placer won’t put any standard cells in
the immediate area around the macro, potentially blocking routing to the pins or causing other
congestion. A special command, addHaloToBlock can add this blockage, or it can be achieved with the
FLOORPLANEDIT FLOORPLANEDIT HALOS form, shown in Figure 6. An example command to add a 14
micron halo around a memory instance would be:
addHaloToBlock 14 14 14 14 ${TOPLEVEL}/SRAM1

Figure 6: Edit Halo Form

©Adam Teman 2017 7


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

3.5 Create Placement Regions/Guides


Placement guides enable several levels of constraining instances to a certain area, according to the
following hierarchy:
• Soft Guide: The tool will try to place the instances close to each other without an actual location
constraint.
• Guide: The tool will try to place the instances within the defined area.
• Region: The tool has to place the instances within the defined area, but other instances can also
be placed inside.
• Fence: The tool has to place the instances within the defined area, and not other instances are
allowed to be placed inside.
• Density: Set a different utilization target for a specified area than the global utilization target.
The way to define these guides is a bit awkward: first create a “group” with a constraint (such as region
or density) and then add instances to the group. This is done with the following commands:
createInstGroup <name> [-guide|-region|-fence <coords>|-density <val>]
addInstToInstGroup <groupName> (<hInstName | instName | groupName>)
3.6 Pre-place Physical Cells
3.6.1 Add Well Taps
In most modern technologies, the standard cells do not include well taps (body connections) inside the
cell itself. The DRC of the technology states the minimum distance between taps to protect from
latchup, and usually this is around 20 microns. Therefore, the library vendor provides special well tap
cells that should be spread in every other row (only one tap needed per continuous well) with a spacing
of less than the DRC requirement. This is done with the addWellTap command or with the
PLACEPHYSICAL CELLADD WELL TAPS form from the GUI, shown in Figure 7. For example, to add well
taps every other row, every 10 micron, starting at 3 microns from the left, the command would be:
addWellTap -cell $WELLTAPCELL -skipRow 1 -prefix WELLTAP \
-inRowOffset 3 -cellInterval 10

Figure 7: Add Well Taps form

To check that there is a sufficient number of well taps in the design, use the verifyWellTap
command, where the -rule option sets the allowed distance between taps:
verifyWellTap -rule 20
Finished verifyWellTap, 0 violations found.

©Adam Teman 2017 8


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

3.6.2 End Caps


In some technologies, End Cap cells are required. The definition of these can vary, but they are usually
cells that “finish” the row well in a “clean” way, especially if deep N-Wells are used. There can be end
cap cells meant for all sides of the core area, but usually left and right end caps are sufficient.
To add end caps, use the addEndCap command or from the GUI PLACEPHYSICAL CELLADD END CAPS .
addEndCap -preCap $ENDCAP -postCap $ENDCAP -prefix ENDCAP
3.7 Define Pin Placement
If you are working on a block, rather than the full chip, you will not define an I/O file during design
import, and therefore, the ports to your design will be simple pins, i.e., pieces of metal around the
boundary of the floorplan. After initializing your design, the pins all be on top of each other at
coordinate (0,0) in the bottom left corner, as shown in Figure 8.

Figure 8: Default pin location after import design

This is obviously bad. It is also not recommended to let the placement algorithm move the pins to
wherever it feels best, since the pins have a significant influence on the placement and the location of
the pins is important for connection outside the block. There are several methods for providing a
location for pins, including:
• Dragging and dropping: Just click on a pin and click on the MOVE/RESIZE/RESHAPE
button (Shift+R), then click a pin, and drag it wherever you want it.
• Command Line: Change the location, size, metal layer, etc. of a pin or of a group of
pins, using the editPin command. For example, to move the clk pin to the top side of the
macro on M3 at the coordinate (0.0, 3.9):
editPin -pin clk -use CLOCK - assign 0.0 3.9 -fixOverlap 1 \
-side Top -layer 3 - pinWidth 0.1 -pinDepth 0.1
Or, for example, to spread a list of pins along the entire bottom edge of the macro in M2:
editPin -pin $PINS -spreadType side -side Bottom -layer 2 \
-spreadDirection clockwise -fixOverlap 1

©Adam Teman 2017 9


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

• Pin Editor Form: A big form for editing pins is the pin editor form, shown in Figure 9, accessible
from the GUI at EDITPIN EDITOR .

Figure 9: Pin Editor Form

• Pin Groups: You can define pin groups through the form found at EDITEDIT PIN GROUP .
• Pin Guides: You can define pin guides through the form found at EDITEDIT PIN GUIDE .

©Adam Teman 2017 10


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

4 Power Planning
Power planning is part of the Floorplanning stage, during which the power and ground nets are routed.
This is achieved through several different tools, commands, and stages in Innovus, which are not entirely
intuitive, so follow closely.
4.1 Global Net Connection
During design import, names were defined for the power and ground nets to be used in the design.
These are also created in a CPF flow. However, the virtual connection between a global net and the pins
of a macro has to be defined separately. For example, if init_pwr_nets was set to VDD during design
import, but the power pin of the standard cell library is called vcc, then the tool has to be told to
connect the two. This is done with the globalNetConnect command or the POWERCONNECT GLOBAL
NETS form, shown in Figure 10, (and can also be done within the CPF flow).
Note that the Global Net Connections form is both very confusing and it is really hard to verify
that all the things you meant to connect were actually done, so I recommend setting this up
and running it from the command line, followed by careful verification.
A sample command for connecting the VDD net to the vcc pins of a standard cell library would be:
globalNetConnect VDD -type pgpin -pin vcc -inst *
Note that the GUI for this command is quite unintuitive. For example, to apply the above command with
the GUI, you will need to follow these steps:
1. Choose PIN
2. INSTANCE BASENAME : *
3. PIN NAME(S): vcc
4. TO GLOBAL NET : VDD
5. Now click ADD TO LIST
6. Now click APPLY
Following the application of a global net connection, EDI will inform you of the number of actual
connections made:
1750 new gnd-pin connections were made to global net VSS.
1750 new pwr-pin connections were made to global net 'VDD'.
If you have constants in your netlist (i.e., 1’b0 and/or 1’b1), which is almost certainly the case, you
must inform the tool which global net to connect them to (per power domain). This is done with the
-type tiehi and tielo options:
globalNetConnect VDD -type tiehi
After running each globalNetConnect command, go over the summary to see that the number of
connections made makes sense. Alternatively, run with -verbose option to print out all connections
made.

©Adam Teman 2017 11


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 10: The Global Net Connections form

4.2 Create FullChip Rings


Good practice is to create nice wide power and ground rings around the chip (between the I/Os and the
core) to distribute the power evenly from the power/ground pads and to make connecting to the
power/ground nets easier for power stripes and follow pins. This is done with the same addRing
command or the POWERPOWER PLANNINGADD RING form, used in Section 3.3, only this time select the
AROUND CORE BOUNDARY option or the -around core option for command line. An example command
to add I/O Rings would be:
addRing -around core -nets {VDD GND} \
-layer {bottom metal1 top metal1 right metal2 left metal2} \
-width 20 -spacing 1 -offset 0.31
An example of what it looks like after successfully adding a set of power/ground rings around the Core
Boundary is shown in Figure 11.

©Adam Teman 2017 12


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 11: Example of Ring around Core Boundary

4.3 Special Route


This is a horrible name for a set of operations that all use the same command, sroute. and with the
same form ROUTESPECIAL ROUTE , shown in . Depending on the values added with the -connect
option, various nets can be routed, as follows:
• sroute -connect blockPin BLOCK PINS : Connects the power/ground pins of macros to
either rings around the macros or to power stripes or pins of I/Os.
• sroute -connect padPin PAD PINS : Connects the power/ground pins of I/O to either rings
around the chip or to power stripes or to pins of macros.
• sroute -connect padRing PAD RINGS : Connects the internal power ground rings that are
inside the I/Os. If you have a complete pad ring, this should be already achieved by abutment,
but this at least tells the tool they are virtually connected.
• sroute -connect corePin FOLLOW PINS : Connects the power/ground rails of the standard
cell rows, also known as “follow pins”. These, also, should be connected through abutment
(after adding fillers) but this virtually connects them and also connects them to the vertical rings
around the boundary. An example of a floorplan with follow pins connecting to the rings is
shown in Figure 12.
• sroute -connect floatingStripe FLOATING STRIPES :
• sroute -connect XXX SECONDARY POWER PINS : Connects secondary power pins, which could
be:
o Body Bias connections.
o Second power connection of Level shifters.
Note that the order of running the sroute command can be important. For example, if you
connect follow pins before creating an I/O ring, the follow pins may not find a target to
connect to.

©Adam Teman 2017 13


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 12: Example of floorplan with rings after adding Follow Pins

The sroute command has many many options that can be applied as flags to either the sroute
command, itself, or to the setSrouteMode command. These include options that tell the tool what
nets to route, what layers to use, and many more. Good luck!
The setting for the setSrouteMode can be defined through the GUI by pressing the
MODE SETUP button on the SRoute form.
Here is an example sroute command, but do this first with the GUI and copy the command that was
run after you get it to work.
sroute -connect { blockPin padPin } -nets {VDD GND} \
-layerChangeRange { metal1 metal5 } -allowJogging 1 \
-blockPinTarget { nearestRingStripe nearestTarget } \
-padPinPortConnect { allPort oneGeom } -allowLayerChange 1 \
-checkAlignedSecondaryPin 1 -crossoverViaBottomLayer metal1 \
-targetViaTopLayer metal5 -crossoverViaTopLayer metal5 \
-targetViaBottomLayer metal1 -blockPin useLef

Figure 13: The SRoute Form

Note that you may need to play around a lot with these settings to get what you want to
actually connect!

©Adam Teman 2017 14


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

4.4 Power Stripes


Now that we have a ring around the chip and horizontal follow pins to create/connect the standard cell
rows, it is important to provide low resistance paths to every point in the floorplan. This is usually done
by creating a power grid, or in other words, routing vertical and horizontal stripes in different metal
layers to carry current to the standard cells and other power consuming instances.
Stripes are created with the addStripes command or with the POWERPOWER PLANNINGADD STRIPES
form, shown in Figure 14. There are many options for creating stripes, starting with the nets to route,
the layer to use, the width and spacing between the stripes, the distance between sets of stripes, and
the target to connect to, such as the core ring or the internal pad ring. An example command for
creating 5 micron wide VDD and GND stripes in M2 every 100 microns could be:
addStripe -nets {VDD GND} -layer metal2 -width 5 \
-spacing 0.32 -xleft_offset 100 -xright_offset 100 \
-set_to_set_distance 100

Figure 14: Add Stripes Form

An example of stripes added in M2 with successful connections to both rings and follow pins is shown in
Figure 15.

©Adam Teman 2017 15


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 15: Example of floorplan with rings and follow pins after adding Stripes in M2

4.5 Verifying the Floorplan


After creating the floorplan and finishing the power routing, it is essential to run DRC and LVS
verification. This should probably be run with an external DRC tool (such as Assura or Calibre DRC), but
at the very least, you should run Innovus’s internal DRC and LVS checks.
4.5.1 Running DRC with verifyGeometry
EDI’s internal tool for running DRC is called verifyGeometry. For below 28nm processes, the tool has
changed to verify_drc, but the concept is the same. You can also invoke the tool from the GUI at
VERIFYVERIFY GEOMETRY (or VERIFY DRC).
encounter 3> verifyGeometry
*** Starting Verify Geometry (MEM: 771.4) ***

VERIFY GEOMETRY ...... Starting Verification


VERIFY GEOMETRY ...... Initializing
VERIFY GEOMETRY ...... Deleting Existing Violations
VERIFY GEOMETRY ...... Creating Sub-Areas
...... bin size: 2880
VERIFY GEOMETRY ...... SubArea : 1 of 1
VERIFY GEOMETRY ...... Cells : 0 Viols.
VERIFY GEOMETRY ...... SameNet : 0 Viols.
VERIFY GEOMETRY ...... Wiring : 0 Viols.
VERIFY GEOMETRY ...... Antenna : 0 Viols.
VERIFY GEOMETRY ...... Sub-Area : 1 complete 0 Viols. 0 Wrngs.
VG: elapsed time: 0.00
Begin Summary ...
Cells : 0
SameNet : 0
Wiring : 0

©Adam Teman 2017 16


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Antenna : 0
Short : 0
Overlap : 0
End Summary

Verification Complete : 0 Viols. 0 Wrngs.

**********End: VERIFY GEOMETRY**********


*** verify geometry (CPU: 0:00:00.1 MEM: -81.9M)
4.5.2 Running LVS with verifyConnectivity
Innovus’s internal tool for running LVS is called verifyConnectivity, and it can be invoked from the
GUI at VERIFYVERIFY CONNECTIVITY . This is one of the tougher tools to get to work correctly, since as
opposed to standard LVS, which compares two spice netlists (the schematic and the GDS), this tool is
comparing the virtual connectivity of the database with the LEF abstracts of the macros and the routing
data. Therefore, you can expect many errors that can be a result of factors, such as incomplete global
net definitions, opens due to lack of fillers, strange LEF definitions of macros, etc.
To try and get a clean LVS at this stage:
• Add filler cells prior to running verifyConnectivity and then erase them after.
• Run verifyConnectivity with the -type special option to check only special routes
encounter 4> verifyConnectivity -type special
VERIFY_CONNECTIVITY use new engine.

******** Start: VERIFY CONNECTIVITY ********


Start Time: Wed Jan 11 09:37:40 2017

Design Name: sm
Database Units: 2000
Design Boundary: (0.0000, 0.0000) (41.3850, 36.4000)
Error Limit = 1000; Warning Limit = 50
Check specified nets

Begin Summary
Found no problems or warnings.
End Summary

End Time: Wed Jan 11 09:37:40 2017


Time Elapsed: 0:00:00.0

******** End: VERIFY CONNECTIVITY ********


Verification Complete : 0 Viols. 0 Wrngs.
(CPU Time: 0:00:00.0 MEM: 0.000M)

5 Placement
Following the creation of a floorplan, we can now move on to standard cell placement
5.1 Setup Placement Options
As you have already seen, or will see from now on, almost every “big” command in Innovus has a
corresponding command for setting up mode options. Since the (traditional) placement command is

©Adam Teman 2017 17


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

placeDesign, the corresponding setup mode command is setPlaceMode and the currently set
options (including defaults) can be printed out with the getPlaceMode command. This can be accessed
through the GUI either directly by OPTIONSSET MODEMODE SETUP or by clicking on the Mode button
on the PLACEPLACE STANDARD CELL form. The form is shown in Figure 16.

Figure 16: Placement Mode Options Form

As with all mode setting commands, there are many options that can do anything but make you coffee,
so you will have to open the manual or Cadence Support to try and figure out what all of them are. But
here are a few important ones:
• Be aware of clock gates
setPlaceMode -clkGateAware true
• Try to eliminate congestion problems around macros
setPlaceMode -macroBlockageAware true -autoBlockageInChannel true
• Add padding (extra space) around cells in a certain module
setPlaceMode -modulePadding <moduleName> <factor>
5.2 Run Placement
The super command for running placement in EDI is PLACEDESIGN . This can also be accessed from the
GUI through PLACE PLACE STANDARD CELL . The PLACE menu is shown in Figure 17.
placeDesign
Note that the placeDesign command belongs to the old (Encounter) flow. For Innovus, this
has been replaced with place_opt_design, which runs the GigaPlace placement engine that
concurrently runs placement and timing optimization.

©Adam Teman 2017 18


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 17: Place Menu

5.2.1 Pre Placement Optimization


The placement procedure is pretty straight forward, and most of the options are set through the
setPlaceMode command. However, take into consideration the -prePlaceOpt option (this has
changed to -noPrePlaceOpt in some versions).
Pre placement optimization assumes that during synthesis, there was no physical data and so any
buffering is wrong. Therefore, it essentially deletes all buffers from the imported netlist prior to
placement and will only buffer large loads and high fanout nets either during placement or post
placement optimization. If you are running topographical synthesis, you should probably skip pre
placement optimization.
placeDesign -prePlaceOpt
5.3 Placement of Special Cells
5.3.1 Manual cell placement/movement
If for some reason, you need to make manual changes in the placement, you can do so either through
the GUI by selecting the move icon, or with the placeInstance command. However, unless you
carefully calculated the move to fit on the placement grid and not overlap with another cell, you will
need to legalize the placement. This is achieved with the refinePlace command:
placeInstance TOP/G123 34.0 52.0 -fixed
refinePlace
5.3.2 Tie Cell Placement
Tie cells are gates that do nothing other than connect to VDD and GND to provide a ‘1’ or ‘0’ signal that
is tied to some inputs. They are not required in all processes, but some libraries require the use of them.
Since these are constant signals that do not drive any current, there is essentially no timing constraint
on them, but driving a high fanout with a single cell is not a good idea. Therefore, it is recommended to
erase any automatically placed tie cells, define constraints for them (maximum fanout, maximum
distance to the gate, etc.) and replace them. This is achieved with the following commands (assuming
the tie cells in the library are called “TIE1” and “TIE0”):
deleteTieHiLo -cell {TIE1 TIE0}
setTieHiLoMode -reset
setTieHiLoMode -maxFanout 20 -maxDistance 250 -cell "TIE0 TIE1"
addTieHiLo -prefix tieoff
refinePlace

©Adam Teman 2017 19


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

5.4 Post Placement Checks/Reports


5.4.1 Check Placement
The checkPlace command, also accessible from PLACECHECK PLACEMENT…,checks the placement
with all kinds of preset checks:
checkPlace
5.4.2 Check Density
The design density can be reported in several ways:
• The queryPlaceDensity command PLACEQUERY DENSITYQUERY PLACE DENSITY
Average module density = 0.853.
Density for the design = 0.853.
= stdcell_area 842 sites (404 um^2) / alloc_area 987 sites (474 um^2).
Pin Density = 0.246.
= total # of pins 227 / total Instance area 922.
• The reportDensityMap command will return a (text) histogram of the density of your design:
default core: bins with density > 0.75 = 25 % ( 1 / 4 )
bin size: 120 sites by 10 row(s). total 4 bins ( 2 by 2 )
density range #bins %
0.9 - 0.95 1 25
total 1 25
• The PLACEDISPLAYDISPLAY DENSITY MAP menu will show you the density map with a color
scheme on the floorplan itself.
• Pressing the percentage icon and then selecting an area on the screen will return the
placement density in the selected area:
Utilization in area (23249 -1352) (23373 -1352) = 0.0%
StdInstArea/freeSpace = 87.3%(442.56/506.88)
macroInstArea/totArea = 0.0%(0.00/823.68)
powerMetalArea/totArea = 38.5%(316.80/823.68)
PlacementObsArea/totArea = 0.0%(0.00/823.68)
Utilization in area (-1672 -1475) (84071 74398) = 87.31%
This can be displayed on the floorplan with the GUI from. Yet another way to measure the utilization of
an area on the floorplan is to select and then select a box on the screen. The Utilization will be reported
in the log:
5.4.3 Check Timing
Even though the placement is run without timing optimization, you can still check timing:
report_timing
Or run the timeDesign super command, which will dump a whole set of timing reports:
timeDesign -preCTS -idealClock
5.5 Placement Optimization
The flow in Innovus uses a separate optimization engine that is invoked after every stage of the design.
In other words, during placement (or any other stage), timing is not considered, and timing constraints
are only fixed during an optimization stage. The command for running optimization is optDesign or
can be accessed through the GUI at , as shown in Figure 18. In the case of post placement optimization,
the command is:

©Adam Teman 2017 20


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

optDesign -preCTS ; # “preCTS” because Clock Tree Synth is next!

Figure 18: Optimization Form

Note that, as mentioned above, the new place_opt_design command runs concurrent
placement and timing optimization. Therefore, if this command is used, there is no need to
run post placement timing optimization.
To check timing after placement optimization, again, you can run the timeDesign super command:
timeDesign -preCTS -idealClock -pathReports -drvReports \
-slackReports -numPaths 50 -prefix preCTS -outDir reports/preCTS
5.5.1 Repairing Congestion
If you see congestion problems at the post placement or post-CTS stages, try the congRepair
command:
congRepair

©Adam Teman 2017 21


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

6 Clock Tree Synthesis


Clock Tree Synthesis is achieved with the Clock Concurrent Optimization (CCOpt) engine. This requires
setting up several configuration commands (depending on the clock tree complexity) and running
ccopt_design.
Note that ccopt_design can be run in three modes: CCOpt, CTS, and Clustering. The
recommended mode is CCOpt, which builds a clock tree without skew balancing and optimizes
it to meet setup and hold requirements. However, some methodologies will prefer the
traditional skew balanced clock tree synthesis approach, which is called “CTS mode”. While
CCOpt mode includes timing optimization, CTS mode does not, and therefore, should be
followed by an optDesign -postCTS stage. The Clustering mode is just the first stage of
CCOpt where a minimum insertion delay clock tree is built (to meet DRV requirements)
without any timing or skew optimizations. This should only be used for initial clock tree
debugging.
6.1 Create Automatically Generated CCOpt Configuration
To automatically generate a clock tree specification file for CCOpt, use the
create_ccopt_clock_tree command. I recommend doing this the first time or after any significant
change in your SDC, but then manually edit your own configuration file
(../inputs/${TOPLEVEL}.ccopt), which includes the settings that you really want.
Create_ccopt_clock_tree -file <filename>
6.2 Define Clock Trees and Skew Groups
The basic (most simple) clock tree configuration will have a clock tree for each clock defined in the SDC
and a skew group of the same name that includes all of the clock tree’s sinks. These are created, as
follows:
create_ccopt_clock_tree -name clock -source CLK -no_skew_group
create_ccopt_skew_group -name clock_ -sources CLK -auto_sinks
The rest of the commands below require more knowledge about clock tree synthesis, and I will not
explain them in this document. But I have included the most relevant commands for reference.
6.3 Define Special Pins
6.3.1 Stop Pin
A Stop Pin is a sink that should be considered part of a skew group. The -auto_sinks option of
create_ccopt_skew_group will traverse the clock tree and automatically mark all sinks (clock pins)
as Stop Pins. However, if for some reason, you would like to mark an additional pin in your design as a
Stop Pin:
set_ccopt_property sink_type -pin $pin stop
In addition, you can add sinks to an existing skew group with the modify_ccopt_skew_group
command:
modify_ccopt_skew_group -skew_group clock -add_sinks $pins
Note that I am careful not to write that a Stop Pin is considered for skew balancing. This is
because CCOpt doesn’t necessarily attempt to balance skew, just to make sure there are no

©Adam Teman 2017 22


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

setup and hold violations. In CTS Mode, all Stop Pins of a skew group are considered for skew
balancing.
6.3.2 Ignore Pin
An ignore pin is a pin that should not be considered for skew balancing/analysis, but you would still like
to build your clock tree up to this pin (i.e., fix DRV violations up to the pin). An example of an ignore pin
is the clock input to a clock divider.
set_ccopt_property sink_type -pin $pin ignore
6.3.3 Exclude Pin
An exclude pin is similar to an ignore pin, but it is also removed from the clock tree. Honestly, I am not
sure how this actually affects us, other than that it will not be displayed in the reports and clock tree
debugger…
set_ccopt_property sink_type -pin $pin exclude
6.3.4 Through Pin
A through pin is a pin along the clock tree that was probably thought to be a sink (a stop pin), but we
want the clock tree to propagate through it. DRV violations will be fixed up to such a pin, but it will not
be considered for skew balancing/analysis.
set_ccopt_property sink_type -pin $pin through
6.4 Define CCOpt Constraints
6.4.1 Clock Period
I’m not sure what this actually does, but here goes:
set_ccopt_property clock_period -pin clk 1.5
6.4.2 Max Transition
set_ccopt_property target_max_trans $max_clock_trans
6.4.3 Max Fanout
set_ccopt_property max_fanout $max_fanout
6.4.4 Max Capacitance
set_ccopt_property target_max_capacitance $max_cap
6.4.5 Case Analysis
set_ccopt_property case_analysis -pin ${ext_clk_pad}/A 0
6.5 Define Library Cells
6.5.1 Driving Cell for Clock Net
set_ccopt_property source_driver -clock_tree clk BUFFX8/Z
6.5.2 Define Buffers and Inverters for building a clock tree
set_ccopt_property buffer_cells $CLOCK_BUF_LIST
set_ccopt_property inverter_cells $CLOCK_INV_LIST

©Adam Teman 2017 23


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

6.6 Running Clock Tree Synthesis


6.6.1 Clock Concurrent Optimization
ccopt_design
6.6.2 Skew Balanced Clock Tree Synthesis
Define skew targets for your skew groups:
set_ccopt_property -skew_group clock target_skew 0.2
ccopt_design -cts
optDesign -postCTS
optDesign -postCTS -hold
6.6.3 Minimum Insertion Delay Clock Tree Synthesis
You may want to run a buffer tree insertion algorithm on the clock tree that just fixes DRVs without
actually considering skew or timing. In other words, build a minimum insertion delay clock tree. This, in
fact, is the first stage of the CCOpt engine. An example for a reason to do this would be to quickly see
what is going on in your clock tree (i.e., debugging) to fix configurations before moving on to a much
longer CCOpt run, which could take many hours.
This mode of running CCOpt is known as “cluster mode” and it is set using:
set_ccopt_mode -cts_opt_type cluster
6.7 CCOpt Clock Tree Debugger
The CCOpt Clock Tree debugger is a GUI feature that enables you to graphically display your clock tree
and see all the sources, sinks and their skew. This can be used before CTS to see that your clock trees
and skew groups have been properly defined, and after CTS to analyze the results. The debugger can be
opened from the command line with the ctd_win command or from CLOCK CCOPT CLOCK TREE
DEBUGGER….

6.8 Clock Tree Reports


6.8.1 Post CTS Timing
As usual, use the timeDesign super command, but now check hold, as well as setup:
timeDesign -postCTS -pathReports -drvReports -slackReports \
-numPaths 50 -prefix postCTS -outDir reports/cts
timeDesign -postCTS -hold -pathReports -slackReports \
-numPaths 50 -prefix postCTS -outDir reports/cts

7 Route
Routing in Innovus is achieved with the NanoRoute engine. This engine concurrently runs timing-driven
and signal integrity (SI) driven routing. Additionally, it can perform multi-cut via insertion, wire widening
and spacing.
7.1 Setting Route Options
Route options are set with the setNanoRouteMode command or through the Mode Options form,
show in Figure 19 and Figure 20.

©Adam Teman 2017 24


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 19: NanoRoute Mode Options Form – Route Tab

Figure 20: NonoRoute Options Form - Timing/SI Tab

7.1.1 NanoRoute Mode Defaults


By default, both timing-driven and SI-driven are set, when using the routeDesign command, i.e.:
setNanoRouteMode -routeWithTimingDriven true -routeWithSiDriven true
In addition, clock nets are unfixed to enable ECOs for postCTS optimization and for fixing DRVs, i.e.:
setNanoRouteMode -routeDesignFixClockNets false
These defaults can be changed before running routeDesign.
7.1.2 Create Shielding for a certain Net
setAttribute –net CLK –shield VDD
setNanoRouteMode –drouteAutoCreateShield true
createShield
7.2 Running NanoRoute
routeDesign
7.3 DRC/LVS Checking
7.3.1 Run DRC
To run an initial DRC, use the verifyGeometry command or from the GUI, select VERIFYVERIFY
GEOMETRY . The Verify Geometry form is show in Figure 21, and the command can be run as:
verifyGeometry

©Adam Teman 2017 25


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Figure 21: The Verify Geometry Form

For below 28nm processes. the verify_drc command (and form) replaces the verifyGeometry
command:
verify_drc
Note that verifyGeometry and verify_drc are not “sign off” DRC runs, but rather check the LEF
routing rules. You should run a sign off DRC tool, such as Assura or Calibre, for a final DRC.
The verifyGeometry command will divide the design into sub-areas and can distribute the DRC tasks
over multiple CPUs. Depending on the size of your design and the complexity of your process, these
checks can take some time. At the end, you will get a summary of the violations found, categorized with
names, such as “SameNet”, “Antenna”, “Short” and “Overlap”. These violations can be accessed through
the Violation Browser at TOOLSVIOLATION BROWSER . A sample state of the violation browser is shown in
Figure 22. This form enables operations, such as automatic zoom in to the area of the violation.

Figure 22: Violation Browser

©Adam Teman 2017 26


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

Pay attention that the verifyGeometry command is affected by options set by the
setVerifyGeometryMode settings. For example, using these settings, you can limit
verifyGeometry to only check a certain area (for a much faster incremental DRC run).
setVerifyGeometryMode -area { 83.831 87.597 831.406 830.806 }
verifyGeometry
7.3.2 Try and fix violations
editDeleteViolations
ecoRoute
7.3.3 Run LVS
To run an initial LVS, use the verifyConnectivity command or from the GUI, select VERIFYVERIFY
CONNECTIVITY . Violations are debugged with the Violation Browser, accessible from TOOLSVIOLATION
BROWSER , shown in Figure 22.
verifyConnectivity
7.3.4 Check for Antenna Violations
verifyProcessAntenna
7.3.5 Loading Violations from Calibre
If you run DRC/LVS from a sign off tool, such as Calibre, you can load the markers back into Innovus. You
just have to figure out the offset from the origin that is seen in the GDS of the chip/block. If the offset is
($x, $y) and the Calibre database is saved at ${TOPLEVEL}.drc.db then you would load the
markers with:
loadViolationReport -type Calibre -filename ${TOPLEVEL}.drc.db \
-xoffset $x -yoffset $y
7.3.6 Clearing Violations
To clear up all the markers left by previous verification checks, run:
clearDrc
7.4 Fixing Post Route Problems
This is always a headache, and it can be very hard to do. Sometimes, you have to go down the painful
path of exporting your design to Virtuoso and fixing the DRCs by hand. However, Innovus provides many
ways to fix DRCs systematically, so you should try them first (this is by no means an exhaustive list).
7.4.1 Instance Overlaps
One major problem that looks like a routing problem is actually illegal placement. This can be caused by
some utilization/congestion or other floorplanning problem. For example, if the floorplan is too dense,
the placer will put cells on top of each other (this includes CTS cells or new buffers during optimization)
and they will cause a million shorts that will screech out during DRC check.
This is a relatively “easy” or at least “straightforward” fix.
• Run refinePlace. If it can, the legalization algorithm will shift the cells to remove overlaps.
• If refinePlace fails, then there are FIXED cells or not enough room. Change the status and/or
manually move the cells, and run refinePlace again.

©Adam Teman 2017 27


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

• If there just is no room to move the cells, tough luck. Go back and redo your floorplan – make it
bigger, reduce the utilization in that area, apply placement blockages, or use one of the other
methods we’ve discussed.
7.4.2 Local Reroute
There are various ways to make the router try harder or incrementally route a certain area. Since
routing can take really really long, making it focus on a certain area is a very useful approach. The easiest
way in my opinion is to open the ROUTENANOROUTEROUTE… form, select AREA ROUTE and click on
SELECT AREA AND ROUTE , as shown in Figure 23. Then select a box around the problematic area, wait
until it finishes, and see if your DRCs disappeared.

Figure 23: Fixing DRCs with Select Area and Route

7.4.3 FIXED Nets and Instances


Often the problem is due to a wire being marked as FIXED. For example, if the wire was routed during
CTS, it is probably considered FIXED and shouldn’t be tampered with (since the whole CCOpt analysis
used the extraction of this particular routing). However, it seems that the router used during CCOpt
sometimes overlooks some DRCs, causing a problem that will not automatically be taken care of.
To solve this problem, change the status of the wire to ROUTED and make an incremental route.
Similar problems can be caused by pre-routes, such as power routing, which may be somewhere that
physically blocks the router from achieving a DRC clean route, and furthermore, some cells may be pre-
placed or FIXED where a pin is blocked by a FIXED net or something similar. Garbage-In, Garbage-Out.
Note that after placement, the default settings of EDI will not move clocked elements (i.e.,
registers). This can cause, such unroutable situations, where a pin of a FIXED flip flop is
inaccessible or something. Just move the problematic instance…
7.4.4 Brute Force It!
When nothing else works, roll up your sleeves and use the trustworthy Brute Force technique. In other
words:
1) Select a bunch of wires in the problematic area, hit delete, and then reroute the area.
2) If that doesn’t work, select a few standard cells around the DRC violation, move them, refine
place and reroute the area. Works like a charm!

©Adam Teman 2017 28


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

7.4.5 Fix it manually… In Innovus


Well, good luck with this one, but Innovus provides tools for push polygon manual routing. It’s very
painful, but if you get the hang of it, it could be scripted and stay internal to the tool, rather than going
out to Virtuoso and possibly coming back…
7.5 PostRoute Parasitic Extraction and Timing
7.5.1 RC Extraction Mode
Parasitics extraction is achieved by Innovus with the extractRC command, which is run as part of many
commands, such as report_timing (if an updated extraction isn’t present). To make sure you are
getting accurate post-route timing, adjust setExtractRCMode:
setExtractRCMode -engine postRoute
setExtractRCMode -effortLevel low | medium | high | signoff
The effortLevel setting is very important at this time. It defaults to low, which uses the native (fast)
extraction engine, but for more accurate extraction, use the medium (Quantus QRC), high (Integrated
QRC) or signoff (Standalone QRC) levels.
Note that higher extraction levels come at the expense of both run time and tool licenses.
However, in the university environment, we have access to advanced licenses, and therefore,
only run time should be taken into consideration.
• Importing extraction information from a third-party tool: If you prefer to use an external
extraction tool, the resulting SPEF file can be imported for each corner, as follows:
spefIn rc_corner1.spef -rc_corner rc_corner1
7.5.2 Analysis Mode
Timing analysis is controlled by the setAnalysisMode command:
• On Chip Variation (OCV): OCV analysis derates the launch path and accelerates the capture path
during setup check, and applies the opposite during hold checks. To enable OCV analysis:
setAnalysisMode -analysisType onChipVariation
• Clock Pessimism Recovery Removal (CPRR): CPRR brings timing a bit back to reality by removing
the derating on the part of the clock path that is shared by both the launch and capture clocks.
To apply CPRR analysis to both hold and setup checks:
setAnalysisMode -cppr both
• SI CPRR: Additionally, you can apply signal integrity CPRR with the following global variable:
set_global timing_enable_si_cppr true

7.5.3 Delay Calculation Mode
If that wasn’t enough, an additional mode setting affects the timing calculation, controlled by the
setDelayCalMode command.
• For SI-Aware delay calculation:
setDelayCalMode -SIAware true

©Adam Teman 2017 29


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

7.6 Post Route Optimization


7.6.1 Post Route Timing Optimization
The post route timing optimization engine can cut wires, insert buffers and locally update the timing
graph to evaluate the change. Post-route optimization is run with:
optDesign -postRoute
Since hold needs to be optimized after route, as well, repeat with the -hold option:
optDesign -postRoute -hold
Or run them together…
optDesign -postRoute -setup -hold
• Mult-VT Optimization: To allow cell swapping between multi-VT options at the post-route
stage:
setOptMode -allowOnlyCellSwapping true
7.6.2 Post Route Wire Optimization
NanoRoute has several heuristics for improving the wiring for better yield (DFM), reducing resistance
and capacitance, and improving SI (lowering coupling capacitance). These are controlled with the
following options:
• Wire Spreading:
setNanoRouteMode -droutePostRouteSpreadWire true
• Via reduction:
setNanoRouteMode -routeConcurrentMinimizeViaCountEffort high
• Apply multi-cut vias for vias that cannot be eliminated:
setNanoRouteMode -drouteUseMultiCutViaEffort high
Incremental routing for wire optimization is then run with the -wireOpt option:
setNanoRouteMode -routeWithTimingDriven false
routeDesign -wireOpt
7.6.3 Via Optimization
routeDesign -viaOpt
7.6.4 Fix Antenna Violations
setNanoRouteMode –drouteFixAntenna true \
–routeInsertAntennaDiode true –routeAntennaCellName <CELLNAME>

©Adam Teman 2017 30


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

8 Finalize Design
8.1 Insert Fillers
To add filler cells, either use the addFiller command and its associated setFillerMode to set the
command options, or run through the GUI at PLACEPHYSICAL CELL ADD FILLER , as shown in Figure 24.
setFillerMode -reset
setFillerMode -core $FILLER_CELLS -corePrefix FILLER \
-createRows 1 -doDRC 1 -deleteFixed 1 -eco
addFiller -cell <list of filler cells> -prefix FILLER

Figure 24: Add Fillers Form with Select Fille Cells Form

Note that fillers can be removed with the deleteFiller command, but post-route
optimization can automatically remove the fillers, perform optimization, and re-insert them.
8.1.1 Insert Decap Cells
Decap cells can add MOSCAPs between VDD and GND to provide better local voltage stability. These are
added with the addDeCap command. Some recommendations for adding Decaps could be:
• Add DeCaps adjacent to Clock Buffers in order to improve the resilience to voltage droops that
would affect the clock.
• Same principle but next to Flip Flops to make sure the setup and hold times are more stable.
• Add DeCaps instead of regular fillers to the entire design. But beware that in some processes,
the leakage through DeCaps is substantial.
DeCaps are considered by EDI to just be another type of filler, so use the addFiller command, just
provide a list of DeCap cells and the area in which to add them:
addFiller -cell <decap list> -prefix FILLER_DECAP -area {x1 y1 x2 y2}
8.2 Add Metal Density Fill
For older process nodes (above 28nm), you can use EDI to insert Metal Density Fill. However, in newer
nodes, the rules are more complex, and you should use an external tool (such as Calibre DRC) to insert
the density fillers.
addMetalFill –layer {1 2 3} –area 100 200 300 400 –net {VDD GND}
To add fillers in EDI, use the addMetalFill command or from the GUI ROUTEMETAL FILL  ADD . In
general, the metal fill rules should be defined in the LEF file. However, if you want to override these
rules, use the setMetalFill command or from the GUI ROUTEMETAL FILL  SETUP .
setMetalFill –layer 1 –windowSize 200 200 –windowStep 100 100

©Adam Teman 2017 31


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

8.2.1 Verifying Metal Density


After inserting metal fill, use the verifyMetalDensity command to verify the DRC requirements are
met.
verifyMetalDensity
8.2.2 Using an external tool for metal fill
To add metal fill with an external tool, stream out the GDS and apply the metal density fill in the
external tool. For a Cadence PVS flow, this can be done from within EDI:
streamOut -mapFile gds_map -outputMacros -units unit gds_file
run_pvs_metal_fill -ruleFile PVS_RULE_DECK -defMapFile map_file \
-gdsFile gds_file -cellgds_top_cell
8.2.3 Trimming the metal fill for timing
Adding metal fill can add unexpected timing problems due to increased parasitics. To trim back the
metal layers close to critical nets, use the trimMetalFillNearNet command or from the GUI
ROUTEMETAL FILL  TRIM :
setMetalFill -windowStep x_step y_step -windowSize x y
trimMetalFillNearNet -slackThreshold $slack1 -spacing value \
-spacingAbove value -spacingBelow value -minTrimDensity value

9 Generating Reports
9.1 Design Summary
You can automatically generate a summary report that can be exported as a text file or in a very
convenient HTML file that can be viewed with a web browser. This is done with the summaryReport
command or from the GUI at FILEREPORTSUMMARY .
9.2 Netlist Statistics
To get statistics, such as number of cells, fanout distribution of nets, number of instances of each
standard cell, etc., use the reportNetStat command or from the GUI FILEREPORTNETLIST
STATISTICS .
reportNetStat
9.3 Gate Count
To get a gate count and area report for each module, use the reportGateCount command or from the
GUI FILEREPORTGATE COUNT .
reportGateCount -level 5 -limit 100
9.4 Placement Density
To get the overall placement density:
queryPlaceDensity
To get a density map:
reportDensityMap
9.5 Check Timing
check_timing -verbose

©Adam Teman 2017 32


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

9.6 Report Timing


Either use the timeDesign super command or directly use the report_timing command.

10 Exporting Your Design


10.1 Export Your Netlist
Use the saveNetlist command or from the GUI, FILESAVENETLIST .
10.1.1 For SDF Back Annotation
saveNetlist -excludeLeafCells ../export/${TOPLEVEL}.PLS.v
10.1.2 For LVS
saveNetlist -includePhysicalCells -excludeLeafCells \
../export/${TOPLEVEL}.LVS.v
10.2 Export an SDF for Back Annotation
Use the write_sdf command or from the GUI, TIMINGWRITE SDF.
write_sdf -view analysis_view_wc ../export/${TOPLEVEL}.sdf
10.3 Export Your GDS
Use the streamOut command or from the GUI, FILESAVEGDS/OASIS.
streamOut ../export/${TOPLEVEL}.gds -mapFile $MAPFILE \
-libName ${TOPLEVEL} -structureName ${TOPLEVEL} \
-merge $GDS_FILES -units 1000 -mode ALL
10.4 Export OA Database

©Adam Teman 2017 33


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

11 Useful Tips
11.1 Printing out messages in the log file
Here’s one I’ll bet you’d never find out (it took me several years to figure it out!). If you use the puts
command, a string will be printed on the screen (similar to “print” or “echo” in various languages). But it
will not be written to the log file. To get it written to the log file, as well, just capitalize the “P”, i.e.:
Puts “This will be written to the log file. Duh!”
puts “This will not be written to the log file…”
11.2 Grepping for warnings and errors
Log files are long. Very long. Warnings and Errors tend to truly get lost inside. Therefore, I highly
recommend “grepping” (i.e., running grep) to extract the warnings and errors from your log file. For
example, you could use the following procedure:
proc printOutWarningsErrors { } {
set logfile [getLogFileName]
set known_warnings “EMS-42 NRIF-47”
set grep_minus_v “”
foreach warning $known_warnings {
set grep_minus_v “$grep_minus_v | $warning “
}
exec egrep -i "warn|error" $logfile | $grep_minus_v > warn_err.rpt
}
11.3 Updating SDC Constraints
By default, EDI does not let you just type in SDC commands at the command line. If you try to, it will give
you a warning telling you to run the set_interactive_constraint_modes command. So, you may
as well do what it tells you…:
set_interactive_constraint_modes [all_constraint_modes -active]
11.4 Deleting Trial Route
Before actually routing the design, EDI runs trial routes at virtually every stage. These do not pass DRC
(by definition) and can cause verifyGeometry to go crazy. The wires can also make a mess on your
screen Therefore, you may want to delete the trial route with the following command:
dbDeleteTrailRoute

©Adam Teman 2017 34


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

12 Example Files
12.1 SDC File
create_clock –name clock –period 10.0 [get_ports clock]
set_clock_uncertainty 0.2 clock
set_input_delay 5.0 –clock clock [all_inputs]
set_driving_cell -lib_cell PRDWUW0408SCDG_HI -pin PAD [all_inputs]
set_output_delay 5.0 –clock clock [all_outputs]
set_load 0.3 [all_outputs]
set_max_delay 5.0 –from [all_inputs] –to [all_outputs]
12.2 MMMC View Definition File
# Constraint Modes #
# ---------------- #
create_constraint_mode \
-name functional_mode \
-sdc_files $design(functional_sdc)

# RC Corners #
# ---------- #
create_rc_corner \
-name bc_rc_corner \
-T $tech_files(TEMPERATURE_BC) \
-qx_tech_file $tech_files(QRCTECH_FILE_BC)
-cap_table $tech_files(CAPTABLE_BC) \

create_rc_corner \
-name wc_rc_corner \
-T $tech_files(TEMPERATURE_WC) \
-qx_tech_file $tech_files(QRCTECH_FILE_WC)
-cap_table $tech_files(CAPTABLE_WC) \

# Library Sets #
# ------------ #
create_library_set \
-name bc_libset \
-timing $tech_files(ALL_LIBRARY_BC_LIBS)

create_library_set \
-name wc_libset \
-timing $tech_files(ALL_LIBRARY_WC_LIBS)

# Delay Corners #
# ------------- #
create_delay_corner \
-name bc_dly_corner \
-library_set bc_libset \
-rc_corner bc_rc_corner

create_delay_corner \
-name wc_dly_corner \
-library_set wc_libset \
-rc_corner wc_rc_corner

©Adam Teman 2017 35


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

# Analysis Views #
# -------------- #
create_analysis_view \
-name bc_analysis_view \
-constraint_mode functional_mode \
-delay_corner bc_dly_corner

create_analysis_view \
-name wc_analysis_view \
-constraint_mode functional_mode \
-delay_corner wc_dly_corner

# Selected Analysis Views #


# ----------------------- #
set_analysis_view \
-setup $design(selected_setup_analysis_views) \
-hold $design(selected_hold_analysis_views)
12.3 I/O Definition File
This file is used to provide a location for the I/O cells around the periphery of the chip. The exact syntax
is described in the user manuals, and an I/O file can be exported from EDI, but for your convenience, an
example is provided below:
(iopad
(topleft
(inst name="pad_corner1" orientation=R90 )
)
### left side (W, bottom to top)
(left
(inst name="pad_vcc_p2" offset=140.12 ) # pin no: 14
(inst name="pad_DIxDI_0" offset=220.10 ) # pin no: 12
(inst name="pad_DIxDI_1" offset=300.08 ) # pin no: 12
(inst name="pad_DIxDI_2" offset=380.06 ) # pin no: 11
(inst name="pad_DIxDI_3" offset=460.04 ) # pin no: 10
(inst name="pad_mvdd_VAR" offset=540.02 ) # pin no: 9
(inst name="pad_gnd_c1" offset=620.00 ) # pin no: 8
(inst name="pad_vcc_c1" offset=699.98 ) # pin no: 7
(inst name="pad_WAddrxDI_0" offset=779.96 ) # pin no: 6
(inst name="pad_WAddrxDI_1" offset=859.94 ) # pin no: 5
(inst name="pad_StartBISTxSI" offset=939.92 ) # pin no: 4
(inst name="pad_ResetxSI" offset=1019.90 ) # pin no: 3
(inst name="pad_ClkxCI" offset=1099.88 ) # pin no: 2
(inst name="pad_gnd_p1" offset=1179.86 ) # pin no: 1
)
(bottomleft
(inst name="pad_corner2" orientation=R180 )
)
12.4 CCOpt Spec File
# Define Clock Trees and Skew Groups
create_ccopt_clock_tree -name $design(CLK_NAME) \
-source $design(CLK_PORT) -no_skew_group
create_ccopt_skew_group -name $design(CLK_NAME) \
-sources $design(CLK_PORT) -auto_sinks

©Adam Teman 2017 36


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

set_ccopt_property source_driver \
-clock_tree $design(CLK_NAME) $tech_files(CCOPT_DRIVING_PIN)

set_ccopt_property clock_period -pin $design(CLK_PORT) $design(CLK_PERIOD)

# SDC Style Constraints


set_ccopt_property target_max_trans $design(CLOCK_MAX_TRANSITION)
set_ccopt_property max_fanout $design(CLOCK_MAX_FANOUT)
set_ccopt_property target_max_capacitance $design(CLOCK_MAX_CAPACITANCE)

# Library Cells
set_ccopt_property buffer_cells $tech_files(CLOCK_BUFFERS)
set_ccopt_property clock_gating_cells $tech_files(CLOCK_GATES)
set_ccopt_property inverter_cells $tech_files(CLOCK_INVERTERS)
set_ccopt_property logic_cells $tech_files(CLOCK_LOGIC)
set_ccopt_property delay_cells $tech_files(CLOCK_DELAYS)

check_ccopt_clock_tree_convergence
12.5 Example Full Place and Route Script:
set runtype "pnr"
set design(TOPLEVEL) "sm"

############################################
# Init Design
############################################
# Set up specific defines for this run
source ../inputs/$design(TOPLEVEL).defines
# Set up the "paths" and "tech_files" variables
source ../inputs/libraries.tcl

setDesignMode -process $tech_files(process_node)

# Setup initialization variables


set init_gnd_net $design(ALL_GROUND_NETS)
set init_pwr_net $design(ALL_POWER_NETS)
set init_lef_file $tech_files(ALL_LIBRARY_LEFS)
set init_verilog $design(postsyn_netlist)
set init_mmmc_file $design(mmmc_view_file)

if {$design(FULLCHIP_OR_MACRO)=="FULLCHIP"} {
set init_io_file $design(io_file)
}

init_design

setAnalysisMode -analysisType onChipVariation

# Connect Global Nets


clearGlobalNets
# Connect standard cells to VDD and GND
globalNetConnect $design(digital_gnd) \
-pin $tech_files(STANDARD_CELL_GND) -all -verbose

©Adam Teman 2017 37


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

globalNetConnect $design(digital_vdd) \
-pin $tech_files(STANDARD_CELL_VDD) -all -verbose
# Connect constants
globalNetConnect $design(digital_vdd) \
-type tiehi -all -verbose
globalNetConnect $design(digital_gnd) -type tielo \
-pin $tech_files(STANDARD_CELL_GND) -all -verbose

############################################
# Floorplan
############################################
setDrawView fplan
# Specify Floorpan
floorPlan -site $tech_files(STANDARD_CELL_SITE) \
-r $design(floorplan_ratio) $design(floorplan_utilization) \
{*}$design(floorplan_space_to_core) -adjustToSite
analyzeFloorplan
fit

# Set up pads (for fullchip) or pins (for macro)


if {$design(FULLCHIP_OR_MACRO)=="FULLCHIP"} {
# Reload the IO file after resizing the floorplan
loadIoFile $design(io_file)
# Add IO Fillers
addIoFiller -cell $tech_files(IO_FILLERS) -prefix IOFILLER
# Connect Pad Rings
sroute -connect {padRing} -nets "$design(digital_gnd) \
$design(digital_vdd) $design(io_gnd) $design(io_vdd)"
} elseif {$design(FULLCHIP_OR_MACRO)=="MACRO"} {
# Spread pins
set pins_to_spread [get_object_name [get_ports]]
editPin -fixOverlap 1 -spreadDirection clockwise -side Bottom \
-layer 4 -spreadType side \
-pin $pins_to_spread
# Make pin "act" fixed so the placer won't move it.
setPtnPinStatus -cell sm -pin act -status fixed
}
redraw

################################################
# Place Hard Macros
################################################
#clearRelativeFPlan
# Example of placing a macro at a certain point
#setObjFPlanBox Instance $design(imem1) 146.7185 143.0825 354.1685 172.5475

# Example of relative floorplanning


# imem[0] bank will be 20 microns above of imem[1] bank
#relativeFPlan --relativePlace $design(imem0) TR $design(imem1) TL 0 20 R0
# dmem[0] bank will be 20 microns to the right of imem[0] bank
#relativeFPlan --relativePlace $design(dmem0) TR $design(imem1) BR 20 0 R0
#clearRelativeFPlan

#getAddRingMode
# Add rings and halos around macros

©Adam Teman 2017 38


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

# imem[0]
#deselectAll
#selectInst $design(imem0)
#addRing -around selected -type block_rings -nets "$design(digital_gnd)
$design(digital_vdd)" \
# -layer {bottom M1 top M1 right M2 left M2} -width 3 -spacing 0.5
#addHaloToBlock {10 10 10 10} $design(imem0)

# Connect VDD/GND connections on macros to rings


#getSrouteMode
#sroute -connect {blockPin} -nets "$design(digital_gnd) $design(digital_vdd)"
-detailed_log

###############################################
# Connect Power
###############################################

# Create Core Ring


addRing -type core_rings -nets $design(core_ring_nets) -center 1 \
-follow core -layer $design(core_ring_layers) \
-width $design(core_ring_width) -spacing $design(core_ring_spacing)
# Connect Follow Pins
sroute -connect { corePin } -nets \
"$design(digital_gnd) $design(digital_vdd)" -detailed_log
# Connect pads to the rings
sroute -connect {padPin} -nets $design(core_ring_nets) \
-padPinPortConnect allGeom -detailed_log

# Add End Caps


addEndCap -preCap [lindex $tech_files(ENDCAPS) 0] \
-postCap [lindex $tech_files(ENDCAPS) 0] -prefix ENDCAP

# Add Well Taps


addWellTap -cell $tech_files(WELLTAP) -skipRow 1 \
-cellInterval $design(well_tap_interval) \
-inRowOffset $design(well_tap_offset) -prefix $design(well_tap_prefix)
verifyWellTap -rule $tech_files(WELLTAP_RULE)

# Add Stripes
addStripe -nets $design(M2_stripe_nets) -width $design(M2_stripes_width) \
-set_to_set_distance $design(M2_stripes_interval) \
-spacing $design(M2_stripes_spacing) \
-xleft_offset $design(M2_stripes_from_left) \
-layer [lindex $tech_files(layer_names) 2]

# Check DRC/LVS
verifyGeometry
clearDrc

verifyConnectivity -type special


clearDrc

checkDesign -all
defOut -floorplan -noStdCells ../export/floorplan.def

©Adam Teman 2017 39


Digital VLSI Design and Physical Implementation Place and Route – Step by Step

saveDesign ../export/floorplan.enc

############################################
# Placement
############################################
setDrawView place

place_opt_design

checkPlace
reportDensityMap
queryPlaceDensity

report_timing

############################################
# Clock Tree Synthesis
############################################
# create_ccopt_clock_tree_spec -file tmp_clock_spec
source $design(clock_tree_spec)

ccopt_design

# Open the clock tree debugger


ctd_win

report_ccopt_skew_groups
report_ccopt_clock_trees

############################################
# Route
############################################
globalRoute
# Now check congestion

routeDesign

routeDesign -viaOpt
routeDesign -wireOpt

optDesign -postRoute
optDesign -postRoute -hold

############################################
# Verify and Export
############################################
# Check DRC/LVS
verifyGeometry
clearDrc

verifyConnectivity -type special


clearDrc
saveNetlist $design(postroute_netlist)
write_sdf $design(postroute_sdf)

©Adam Teman 2017 40

You might also like