Place_and_Route_Flow
Place_and_Route_Flow
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.
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
preset variables. These can either by defined by command line (recommended) or set up the first time
with the FILEIMPORT 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.
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.
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)
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 FLOORPLANRELATIVE FLOORPLANEDIT 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
POWERPOWER PLANNINGADD 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
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
FLOORPLANEDIT FLOORPLANEDIT 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
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.
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
• Pin Editor Form: A big form for editing pins is the pin editor form, shown in Figure 9, accessible
from the GUI at EDITPIN EDITOR .
• Pin Groups: You can define pin groups through the form found at EDITEDIT PIN GROUP .
• Pin Guides: You can define pin guides through the form found at EDITEDIT PIN GUIDE .
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 POWERCONNECT 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.
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
Note that you may need to play around a lot with these settings to get what you want to
actually connect!
An example of stripes added in M2 with successful connections to both rings and follow pins is shown in
Figure 15.
Figure 15: Example of floorplan with rings and follow pins after adding Stripes in M2
Antenna : 0
Short : 0
Overlap : 0
End Summary
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
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
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 OPTIONSSET MODEMODE SETUP or by clicking on the Mode button
on the PLACEPLACE STANDARD CELL form. The form is shown in Figure 16.
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.
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
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
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.
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 TOOLSVIOLATION 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.
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 VERIFYVERIFY
CONNECTIVITY . Violations are debugged with the Violation Browser, accessible from TOOLSVIOLATION
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.
• 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 ROUTENANOROUTEROUTE… 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.
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 PLACEPHYSICAL 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 ROUTEMETAL 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 ROUTEMETAL FILL SETUP .
setMetalFill –layer 1 –windowSize 200 200 –windowStep 100 100
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 FILEREPORTSUMMARY .
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 FILEREPORTNETLIST
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 FILEREPORTGATE 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
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
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
# 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
set_ccopt_property source_driver \
-clock_tree $design(CLK_NAME) $tech_files(CCOPT_DRIVING_PIN)
# 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
if {$design(FULLCHIP_OR_MACRO)=="FULLCHIP"} {
set init_io_file $design(io_file)
}
init_design
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
################################################
# 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
#getAddRingMode
# Add rings and halos around macros
# 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 Power
###############################################
# 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
checkDesign -all
defOut -floorplan -noStdCells ../export/floorplan.def
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
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