Physical Design Inputs
• Netlist --->format is .v -->given by Synthesis People
• Synthesis Design Constraints -->format is .SDC -->given by
Synthesis People.
• Logical libraries --> format is .lib --->given by Vendors
• physical libraries -->format is .lef --->given by vendors
• Technology file -->format is .tf --->given by fabrication peoples
• TLU+ file -->format is .TLU+ -->given by fabrication people.
Netlist (.v or .vhd)
• It is the combination of sequential elements and their logical connectivity.
• wire information
• cell & instance information
• module information
• Hierarchy information
• port information
Eg of a Netlist:
Module half-adder (C,S,A,B);
Input A,B;
Output C,S;
AND2 U1(.Y(C), .A(A), .B(B));
EXOR U2(.Y(S), .I1(A), .I2(B));
Endmodule
Synopsys Design Constraints (SDC)
The Synopsys Design Constraints (SDC) format is used to specify the design intent, including timing, power
and area constraints for a design. This format is used by different EDA tools to synthesize and analyse a
design. SDC is based on the tool command language (Tcl).
SDC file contains the following information:
• SDC version (optional)
• SDC units (optional)
• Design Constraints
• Design Objects
• Comments (optional)
The information specified in design constraints is operating conditions, wire load models, system interface,
design rule constraints, timing constraints, timing exceptions, area constraints, multi-voltage & power
optimization constraints and logic assignments.
Design constraints will have all the object access commands. Objects can be design, clock, port, pin, cell, net,
library, etc.
These are timing constraints and used to meet the timings.
• constraints are :
• create clock definition
• generated clock definition
• Virtual clock
• input delay
• output delay
• max delay
• min delay
• max transition
• max capacitance
• max fanout
• clock latency
• clock uncertainty etc..
and clock exceptions are also present in SDC
• Multicycle Path
• False Path
• Half Cycle Path
• disable timing arcs
Liberty Timing File (.lib or .db)
• .lib is basically a timing model contains cell delays, transition, setup and hold time
requirements. CCS and NLDM techniques are used to generate .lib files.
• In CCS (composite current source) current source is used for driver modeling, CCS has 20
variables to account input slew and output load data where as, NLDM uses the voltage
source for driver modeling and it has only 2 variables which are not sufficient for modeling
the nonlinearity of any circuit.
• So CCS is more accurate than NLDM. Because of the difference in number of variables used
in both the models, size of CCS file is 10X times larger than the NLDM file.
• Also the run time for CCS is more when compared to NLDM.
• The design needs to be tested for certain PVT (process voltage and temperature) corners.
But for every PVT corner, the timing of the cells are different. Hence there is a .lib file for
every PVT corner.
In .lib file following unit attributes are present
• Time unit
• Voltage unit
• Current unit
• Leakage power unit
• Capacitive load unit
• Slew rate : Lower and upper limit values are defined in terms of percentage for both rise and fall
time
• Input threshold at rise and fall time
• Output threshold for rise and fall time
• Look Up table templates are defined for different parameters like delay, hold, passive energy,
recovery, removal, setup, with different matrix.
For each cell (AND, NAND, Or etc..) following attributes are defined:
• Area of cell
• Leakage power
• Capacitance
• Rise and fall capacitance
• Properties such as capacitance, direction of the pin etc. for each pin (input and output) will be
defined.
.lib file Example:
Cell (AND2_3) {
area : 8.000
pin (o) {
direction : output;
timing () {
related_pin : “A”;
rise_propagation () }
rise_transition () }
function : “(A & B)”;
max_cap :
min_cap : }
pin (a) {
dir : input;
cap : ;
}
Library Exchange Format(LEF)
• The LEF file is the abstract view of cells. It only gives the idea about PR
boundary, pin position and metal layer information of a cell.
• To get the complete information about the cell, DEF (Design Exchange Format)
file is required. In this 3 sections are defined, i.e. technology, site, macros.
• In the technology part layers, design rules, via definitions and metal capacitance
are defined. In the site, site extension is defined and in the macros the
information about cell description, dimension, layout of pins and blockages and
capacitance are defined.
• For every technology the layer and the via statements are different. So for the
layer and via, the type of the layer (layer may be routing type, master slice or
overlap), width/pitch and spacing, direction, resistance, capacitance, and antenna
factor are defined.
LEF contains
• Cell Name, Shape, Size, Orientation
& Class
• Port/Pin Name, Direction and
Layout Geometries
• Obstruction/ Blockages
• Antenna Diff. Area
.lef file Example:
Layer m1
Type routing
width 0.50;
End m1
Layer via
Type cut
End via
Macro NAND_1
Foreign NAND_1 0.00.00
Origin 0.00.00
Size 4.5 by 12.0
Symmetry x y;
Site core;
Pin A
Dir input;
Port
Layer m1 End
Technology file
Technology file: format is .tf:
• It contains Name,Number conventions of layer and via
• It contains Physical,electrical characteristics of layer and via
• In Physical characteristics Min width,Min Spacing,Min Hight are present.
• In Electrical characteristics Max Current Density is present.
• Units and Precisions of layer and via .
• Colors and pattern of layer and via .
• Physical Design rules of layer and via
• In Physical Design rules Wire to Wire Spacing,Min Width between Layer and via are present.
Layer Info :
• Mask Name
• Visible
• Selectable
• Line Style(Solid)
• Patteren
• Pitch
• Cut Layer
TLU+ file
• TLU+ file is a binary table format that stores the RC Coefficients. The TLU+ models enable accurate RC
extraction results by including the effect of width, space, density and temperature on the resistance
coefficients.
• The map file matches the layer and via names in the Milkyway technology file with the names in the ITF
(Interconnect Technology Format) file.
• The main functions of this file can be given as finding:
• R,C parasitics of metal per unit length.
• These parasitics are used for calculation Net delays.
• If TLU+ files are not given, then these are extracted from .ITF file.
• For loading TLU+ files, we have to load three files Max TLU+, Min TLU+ and Map file.
• Map file maps the .ITF file & .tf file of the layer and via names.
DEF File
• The DEF file basically contains the placement information of macros , standard cells, I/O
pins and other physical entities.
• The logical design data to place and route tool and takes the physical design data from
place and route tool in form of DEF.
• The logical design data contains the internal connectivity, grouping information, and
physical constraints and the physical design data contains routing geometry data,
placement location and orientation.
• DEF is used as an input for various stages.Floorplan DEF is given at the import design
stage to provide information about macro location, IO ports and block shape, SCANDEF
is given at the import design stage for scan chain reordering which contains the
connectivity information of scan flops and it is also an input of scan tracing stage, DEF
generated by PnR is used in Star RC extraction.
DEF File contains:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Die Area
Tracks
Components (macros)
I/O Pins
Nets
Blockages
Halo
Scan Chain
Vias
Slots
Fills
Region
Row
Metal layers
Sanity Checks
• Sanity checks are an important step for physical design engineers to make sure that the inputs
received for physical design are correct and consistent. Any issues in the input files may cause
problems in the later stages.
• So it is important to perform the sanity checks in the initial stage that is when the design is
loaded in PnR tool and before the start of the floorplan.
• Sanity Checks mainly checks the quality of netlist in terms of timing.
• It also consists of checking the issues related to Library files, Timing Constraints, IOs and
Optimization Directives
Library Check:
• In library check, basically, we validate the libraries before starting the physical design by checking the
consistency between the physical and logical library. It also checks the quality of both libraries and
reports the error if any.
• The cells used in the design must be present in the logical as well as in the physical library.
Innovus commands:
• checkDesign -physicalLibrary
This command will check the physical library and report that all the cells used in design have their
LEF view or not.
• checkDesign -timingLibrary
This command will check the timing library and report whether all the cells used in the design have
been defined in the timing library or not.
• checkDesign -all
This command will check the missing or inconsistent library and design data.
ICC2 commands:
• check_library
Performs consistency checks between the logical and physical library, across the logical library and
within the physical library.
Netlist Check:
Netlist must be checked for consistency. This check analyzes the currently loaded netlist
and reports the inconsistency if any. Netlist check mainly checks:
• Floating input pins and nets
• No direct connection between VDD and VSS
• Multidriven nets
• combinational loops
• Unloaded outputs
• Uncontraints pins
• Mismatch pin count between instance and reference
• Innovus command:
checkDesign -netlist
• ICC command:
check_design
SDC Check:
• SDC file must be checked before start the design. Some of the common issues in SDC
file are as follow.
• Unconstrained path
• Clock is reaching to all synchronous elements
• Multiclock driven registers
• Unconstrained endpoint
• Input/output delay missing for a port
• Slew or load constraint missing for a port
• Missing clock definition
• Innovus command:
check_timing
• ICC command:
check_timing
Sign Off
Sign off is a process of logical and physical verification of our chip.
Sign-off Checks
• Logical Checks
• LEC ( Logical Equivalence Checks)
• Post Layout STA
• Physical Checks
• LVS (Layout vs Schematics)
• DRC (Design Rule Checks)
• ERC (Electrical Rule Check)
• Antenna Check
• Power Checks
• Dynamic IR
• EM (Electromigration)
LEC ( Logical Equivalence Checks)
• Equivalency checking tool compares RTL and netlist and points out the functional
differences if any, otherwise they are reported as equivalent.
• EC tool will make sure that pnr netlist has the same functionality as the synthesized
netlist. Thus EC tool always works on two inputs and compares whether they are
functionally equivalent or not.
• As the tool always compares two inputs, one is considered as golden and other is
revised.
• For equivalence check between RTL and synthesized netlist, RTL is considered as
golden as all functionality implemented has been verified by other methods like
simulation, assertion based verification etc.
• Formal EC can tell revised design(In this case, synthesized netlist) has the same
functionality as golden or not.
• LVS (Layout vs Schematics)
• Inputs: .v netlist of the design, GSD-layout database of the design, LVS rule
deck (.v and
GDS should be of the same stage).
• LVS rule deck file contains the layer definition to identify the layers used in
layout file and to match it with the location of layer in GDS. It also contains
device structure definitions.
• LVS check includes following comparisons:
• Number of devices in schematic and its layout.
• Type of devices in schematic and its layout.
• Number of nets in schematic and its layout.
Typical errors which can occur during LVS checks are:
• Shorts: Shorts are formed, if two or more wires which should not be
connected together are connected.
• Opens: Opens are formed, if the wires or components which should be
connected together are left floating or partially connected.
• Component mismatch: Component mismatch can happen, if components of
different types are used (e.g, LVT cells instead of HVT cells).
• Missing components: Component missing can happen, if an expected
component is left out from the layout.
• Parameter mismatch: All components has it’s own properties, LVS tool is
configured to compare these properties with some tolerance. If this tolerance
is not met, then it will give parameter mismatch.
DRC (Design Rule Checks)
• Design rules are written to verify shapes and sizes of various circuit components that are
diffused in, deposited on, or etched on a semiconductor wafer.
• Foundry defines thousands of DRC rules in each Technology nodes. Complexity of these
rules increases as you go down / lower the technology nodes.
• Different foundry defines these rules differently as per their manufacturing process
constraints. There may be several rules which are not present in one foundry and present
for other foundry for a same technology Node. But still there are few basics rules which
are almost common to all foundry.
• For the EDA tools, different vendors have different ways to code these rules in different
format, so that their corresponding tools understand those rules and perform
corresponding checks accordingly. A set of rules for a particular process is referred to as
a run-set, rule deck, or just a deck.
• DRC is a very computationally intense task, It takes from few Hr to Few Days depends
on the complexity of Design and the type of machine resources you are using.
ERC (Electrical Rule Checks)
• ERC involves checking a design for all electrical connection.
• Checks such as:
• Well and subtract area for proper contact and spacing.
• Unconnected input or shorted output.
• Gates should not connect directly to supply (Must be connect through TIE
high/low cells only).
• Floating gate error:
• If any gate is unconnected, this could lead to leakage issues.
• VDD/VSS errors:
• The well geometries need to be connected to power/Ground and if the PG
connection is not complete or if the pins are not defined, the whole layout
can report errors like “NWELL not connected to VDD.
• Antenna Check
• The antenna effect is caused by the charges collected on the floating
interconnects, which are connected to only a gate oxide.
• During the metallization, long floating interconnects act as temporary
capacitors and store charges gained from the energy provided by fabrication
steps such as plasma etching and CMP.
• If the collected charges exceed a threshold, tunneling current will discharge
through the thin oxide and cause gate damage.
• On the other hand, if the collected charges can be released before exceeding
the threshold through a low impedance path, such as diffusion, the gate
damage can be avoided.
Solution for antenna violation
• Jumper insertion: A jumper is a forced layer change from one metal layer to
another, and then back to the same layer. Jumper insertion breaks up a long wire
so that the wire connected to the gate input is shorter and less capable of
collecting charge.
• The advantage of jumper insertion is that it is fully controlled by the routing tool.
The disadvantage is that it can potentially contribute to routing congestion
problems in upper metal layers.
• Embedded protection diode: Add protection diodes on every input port for every
standard cell. Because these diodes are embedded and fixed, they consume
unnecessary area when there is no violation at the connecting wire.
EM – electro migration
• EM leads to open circuits due to voids in wires or vias and leads to short
circuits on wires.
• During older technology nodes EM was considered only on power wires
and clock wires, But now signal wires also need to be considered due to
increased current density in them.
• Method to fix EM
• Widen the wire to reduce current density.
• Keep the wire length short.
• Reduce buffer size in clock lines.
• Lower the supply voltage.
IR Drop Analysis:
• IR Drop can be defined as the voltage drop in metal wires constituting power grids
before it reaches the vdd pins of the cells.
• IR drop occurs when there are cells with high current requirement or high switching
regions. IR drop causes voltage drop which in-turn causes the delaying of the cells
causing setup and hold violations. Hold violations cannot be fixed once the chip is
fabricated.
Methods to reduce IR drop:
• Robust power mesh– Initial power grid is made based on static ir analysis due to late
availability of switching activity. If there is IR drop due to some of the clustered cells
then adding a strip will make the power mesh more robust.
• De-cap– These are decoupling capacitors which are spread across the high switching
region to maintain the voltage.
• Reducing load– Cells driving more load will be drawing more current. Hence reducing
load will reduce IR drop.
• Downsizing– Cells of smaller size will draw less current. But the transition of cells
should not become worse.
get_attributes
• Returns attribute values on the specified objects.
• This command searches the object_list for the specified attribute and returns a list of attribute
values. An empty list is returned if the attribute is not found on any of the specified objects.
• The following example gets the value of the load attribute for all ports whose names begin
with OUT:
• get_attribute -objects [get_ports OUT*] -name load
• 1.0 2.0 2.5 1.0
• get_attribute [get_selection] width
• get_attribute [get_selection] name
• get_attribute [get_selection] design_type
• get_attribute [get_selection] outer_keepout_margin_hard
• get_attribute [get_selection] number_of_pins
list_attributes
• The list_attributes command displays an alphabetically sorted list of currently
defined attributes. There are two categories of tool attributes: applicationdefined and user-defined.
By default, list_attributes lists all user-defined
attributes.
• To add the application attributes to the listing, use the -application option. Note that
there are many application attributes. It is often useful to limit the listing to a
specific object class by using the -class option.
• The following example limits the listing to net attributes only.
prompt> list_attributes -application -class net
• The following example limits the listing to port attributes only.
prompt> list_attributes -application -class port
• The following example limits the listing to pin attributes only.
prompt> list_attributes -application -class pin
set_attributes
• Sets attribute values to the specified value on the specified list of objects.
• This command sets the attribute values on the specified objects. This
command returns a collection of objects that have the specified attribute
value set.
• set_attribute [get_selection] outer_keepout_margin_hard -value {5 5 5 5}
• set_attribute [get_selection] physical_status -value fixed
• set_attribute [get_selection] physical_status -value unplaced
• set_attribute [get_selection] orientation -value r90
get_app_options
• Returns a list of valid application option names.
• This command returns a list of application options whose names match the specified pattern.
• If a block is specified, only those options that are explicitly set on the block will be
returned.
• The return value may be an empty list if there are no such options.
• The default behavior is to return all the application options.
• The following example gets the list of all options that contain "dir" in their names.
prompt> get_app_options *dir*
shell.tmp_dir_path
• The following example gets the list of all options in the timer category, which are explicitly set
on the current block.
prompt> get_app_options timer.* -block [current_block]
time.all_clocks_propagated time.enable_preset_clear_arcs
set_app_options
• Sets application options to the specified value on the specified block.There are two types of
application options:
• Global application options, which apply everywhere within the current session Global application
option settings are not stored and are not carried over from one session to the next.
• Block-level application options, which apply only to the blocks on which they are set Block-level
application option settings are saved with the block in the design library and are persistent
across tool sessions except when they are set by the set_app_options -as_user_default command.
• The following example sets the value of the time.enable_preset_clear_arcs application
option to true on the current block.
set_app_options -name time.enable_preset_clear_arcs -value true
time.enable_preset_clear_arcs true
• The following example sets the value of the place.coarse.continue_on_missing_scandef
application option to true on the current block.
set_app_options -name place.coarse.continue_on_missing_scandef -value true
place.coarse.continue_on_missing_scandef true
Floorplan
• Quality of your Chip / Design implementation depends on how good is the Floorplan.
• A good floorplan can be make implementation process (place, cts, route & timing closure)
simple.
• A bad floorplan can create all kind issues in the design (congestion, timing, noise, IR,
routing issues). A bad floorplan will blow up the area, power & life of the IC and also it
can increase overall IC cost.
Objectives of floorplan:
• Minimize the area
• Making routing easy
• Reduce the wire length
• Reduce the IR drop
Inputs for floorplan:
• 1. Netlist (.v)
• 2. Synopsys design constraints (.SDC)
• 3. Timing Library files (.lib)
• 4. Physical library (.lef)
• 5. Technology file (.tf)
• 6. TLU+
Floorplan initilization
• initialize_floorplan -control_type die -boundary {{0 0} {1680 1680}} core_offset {690} -use_site_row -site_def unit -flip_first_row true
Floor plan steps:
• Initialize with Chip & Core Aspect Ratio (AR)
• Initialize with Core Utilization
• Initialize Row Configuration & Cell Orientation
• Provide the Core to Pad/ IO spacing (Core to IO clearance)
• Pins/ Pads Placement
• Macro Placement by Fly-line Analysis
• Macro Placement requirements are also need to consider
• Blockage Management (Placement/ Routing)
Checks after floorplan
•
•
•
•
•
•
•
No I/O ports short
All I/O ports should be placed in routing grid
All macros in placement grid
No macros overlapping
Check PG connections (For macros & pre-placed cells only)
All the macros should be placed at the boundary
There should not be any notches. If unavoidable, proper blockages has to be
added
• Remove all unnecessary placement blockages & routing blockages (which
might be put during floor-plan & pre-placing)
standard cell row:
• The area allotted for the standard cells on the core is divided into rows where standard cells are
placed.
• The height of the row is equal to the height of the standard cell and width varies.
• The height varies according to multiple standard cell row height. there may be double-height cells,
triple-height cells, etc.
• The standard cells will sit in the row with proper orientation.
create_site_def -name -height -width -symmetry { X Y }
create_site_array -name SA1 -site {unit:3 punit:2} -boundary {{100 100} {200 200}} -y_margin
{0.5 1}
create_site_row -name -site unit -origin {0 100} -site_count 1000 -orientation.
Fly lines:
• Fly lines are a virtual connection between macros macro and macros to IO
pads.
• This helps the designer about the logical connection between macros and
pads.
• Fly lines act as guidelines to the designer to reduce the interconnect length
and routing resources.
Blockages
• blockages are specific location where placing of cells are blocked.
• blockages acts like guidelines for placement of std cells.
• blockages will not be guiding the tool to place the std cells at some particular
area, but it won't allow the tool to place the std cell in the blocked area.
• Blockages can be classified as• Hard Blockage
• Soft Blockage
• Partial Blockage
1. Hard Blockage
• Complete Standard Cell Blockage
• std cell blockages are mostly used to
• avoid routing congestion at macro corners
• Restrict std cells to certain regions in the design
• control power rail generation at macro cells
2.Soft Blockage
• Non-Buffering Blockage, only buffers can be placed and std cells cannot be
placed
3.Partial Blockage
• Partial Standard Cell Blockage and is used to avoid congestion
• We can Block Standard Cells as per the required percentage value
Macro placement:
• Macros may be memories, analog blocks. Proper placement of macros
has a great impact on the quality and performance of the ASIC design.
Macro placement can be manual or automatic.
Guidelines to place macros:
• Placement of macros are the based on the fly-lines ( its shows the
connectivity b/w macro to macro and macro to pins) so we can minimize
the
interconnect length between IO pins and other cells.
• Place the macros around to the boundary of the core, leaving some
spacebetween macro to core edge so that during optimization this
space will be used for buffer/inverter insertion and keeping large areas
for placement of standard cells during the placement stage.
• Macros that are communicating with pins/ports of core place them
near to core boundary.
• Place the macros of same hierarchy together.
• Keep the sufficient channel between macros
• channel width = (number of pins * pitch )/ number of layers either
horizontal or vertical
Ring creation
• This example creates a simple pattern of four PG rings for the
VDD and VSS nets.
• create_pg_ring_pattern ring_pattern -horizontal_layer M7 \
-horizontal_width {5} -horizontal_spacing {2} \
-vertical_layer M8 -vertical_width {5} -vertical_spacing {2}
• set_pg_strategy core_ring \
-pattern {{name: ring_pattern} \
{nets: {VDD VSS VDD VSS}} {offset: {3 3}}} -core
• compile_pg -strategies core_ring
Stripe creation
• This example creates a simple PG mesh for two layers (M5
and M6) and four nets (VDD1, VDD2, VSS1, VSS2).
• create_pg_mesh_pattern
mesh_pattern
\
-layers
{{{vertical_layer: M6} {width: 0.6}\ {pitch: 20} {offset:
20}}\ {{horizontal_layer: M5} {width: 0.6}\ {pitch: 20}
{offset: 20}}}
• set_pg_strategy
M5M6_mesh
\
-pattern
{{name:
mesh_pattern} \ {nets: VDD1 VSS1 VDD2 VSS2}} -core
• compile_pg -strategies M5M6_mesh
PG Standard Cell Rails
• This example inserts standard cells rails for nets
VDD and VSS on layer M1. The width is not
specified, so the tool creates the rails with the same
width as the standard cell pins.
• create_pg_std_cell_conn_pattern rail_pattern -layers
M1 rail_width {0.06}
• set_pg_strategy M1_rails -core \ -pattern {{name:
rail_pattern}{nets: VDD VSS}}
• compile_pg -strategies M1_rails