Contact us

What is Physical Design?

Physical Design (PD) is the stage in the VLSI design flow where a synthesized logical netlist (created after RTL design and synthesis) is converted into a physical layout—the geometrical representation of the circuit that can be fabricated on silicon.

In simpler terms: it’s where your 0s and 1s become transistors and wires.

Think of it like constructing a skyscraper:

  • RTL is the architectural plan.
  • Synthesis is the structural design (which beams, columns, floors exist).
  • Physical design is where you actually build the structure on land, ensuring plumbing, wiring, and strength are correct.

PD must satisfy performance (timing), area (size), power, and signal integrity goals—collectively known as PPA. The final product of PD is a GDSII file, which goes to the foundry for chip fabrication.

Input Files Required for Physical Design

Physical Design starts after synthesis. The quality and completeness of inputs directly determine how smooth your flow will be.

Category File Type Example Description
Logical Gate-level Netlist (.v) top_chip.v Output of synthesis, defines connectivity of gates.
Timing Liberty File (.lib) slow.lib,
fast.lib		 Contains timing/power arcs for each cell, at various corners.
Physical Technology LEF (.lef)
Cell LEF (.lef)		 tech.lef
stdcells.lef,
macros.lef		 Defines routing layers, spacing, via rules.
Defines standard cell dimensions and pin locations.
Constraints SDC File (.sdc) top_constraints.sdc Defines clocks, input/output delays, false/multicycle paths.
Floorplan / DEF DEF File (.def) initial.def Optional pre-defined floorplan from previous stage.
Power Intent UPF or CPF power.upf Defines power domains and isolation.
TCL Setup Tool Scripts setup.tcl Contains environment paths, licenses, and flow setup.

Cross Question: What happens if .lib and .lef are mismatched (e.g., different versions)?

Answer: The timing arcs and cell dimensions won’t match; routing may violate spacing or STA may fail. Always ensure all views (timing, logical, physical) come from the same release.

Physical Design Flow:-

Import Design Data
↓
Partitioning (optional)
↓
Floorplanning
↓
Power Planning
↓
Placement
↓
Clock Tree Synthesis(CTS)
↓
Routing (Global & Detail)
↓
Physical Verification
↓
Signoff (Timing/Power/DFM checks)
↓
Tapeout (GDSII generation)

Importing Design Data in Physical Design (PD)

1. Introduction

In the Physical Design (PD) flow of VLSI, importing design data is the first and one of the most crucial steps. This process involves gathering all the necessary input files and libraries required to begin the back-end design process. Without proper data import and verification, the subsequent stages—like floorplanning, placement, clock tree synthesis, and routing—cannot proceed correctly.

Design data serves as the foundation for the PD flow. It includes various files that describe the logical, timing, and physical aspects of a digital integrated circuit. These files are generated in earlier design stages (like RTL synthesis) and are imported into PD tools such as Cadence Innovus, Synopsys IC Compiler II (ICC2), or Siemens Aprisa.

2. What is Design Data?

Design data consists of all the inputs required for physical implementation. It includes multiple file types:

a) Logical Data
  • Netlist File (.v or .vhdl) – A gate-level description of the circuit obtained after synthesis. It contains standard cell instances and connectivity.
    Example: v
b) Timing Data
  • SDC File (.sdc) – Synopsys Design Constraints define timing requirements such as clock definitions, input/output delays, and false paths.
    Example: create_clock -period 5 [get_ports clk]

c) Physical Data

  • LEF File (.lef) – Library Exchange Format file that provides the physical geometry and pin locations of standard cells and macros.
    • Two types:
      1. Tech LEF: Contains process-specific layers, design rules, and manufacturing grid.
      2. Macro LEF: Describes layout of cells/macros.
    1.  
  • DEF File (.def) – Design Exchange Format that provides placement and routing information from previous runs (optional during import).
d) Library Files
  • Liberty Files (.lib) – Contains timing, power, and noise models for standard cells. Multiple libraries may exist for different process corners (slow, typical, fast).
e) Technology Files
  • Includes process technology information like layer stack, vias, design rules, and metal resistances.
    Example: .tf (in Synopsys) or .tech (in Cadence).

f) Other Supporting Data
  • IO Placement File (.io) – Defines pad and IO pin locations.
  • UPF/CPF Files – Define power intent (for multi-voltage or power-gated designs).
  • Constraint Files – Contain custom design rules, tie-offs, or floorplan boundaries.

3. Objective of Importing Design Data

The main objective of importing design data is to ensure that the PD environment has all necessary information about the cells, timing, and physical layers before any floorplanning or placement begins.

Key goals include:

  • Verifying data integrity between netlist and library.
  • Checking for missing cells or mismatched names.
  • Ensuring unit consistency (micron vs. nanometer).
  • Setting up the technology database for tool usage.

4. Step-by-Step Process of Importing Design Data

We are explaining the step-by-step flow used to import design data into tools like Cadence Innovus and Synopsys ICC2.

Step 1: Create a New Design Environment

Set up the working directory and define environment variables.

In Innovus:

set DESIGN_NAME top_chip
set DESIGN_DIR /home/user/projects/top_chip
cd $DESIGN_DIR

In ICC2:

set_design_name top_chip
set_workspace ./top_chip_workspace

Step 2: Load Technology and Library Files

Load LEF, LIB, and technology files.

Innovus Example:

set init_tech_lef {tech.lef}
set init_lef_file {stdcells.lef macros.lef}
set init_lib_file {slow.lib typical.lib fast.lib}

ICC2 Example:

read_tech -lef tech.lef
read_lib -liberty {slow.lib typical.lib fast.lib}
read_lef stdcells.lef
read_lef macros.lef

Step 3: Import Netlist and Constraints

Read the gate-level netlist and timing constraints.

Innovus Example:

set init_verilog {top_chip.v}
set init_design_settop 1
set init_mmmc_file design_setup.tcl
set init_top_cell top_chip

ICC2 Example:

read_verilog top_chip.v
current_design top_chip
source constraints.sdc

Step 4: Import Floorplan or DEF (If Available)

If an initial DEF exists from a previous stage (like block-level PD), import it.

Innovus Example:

set init_def_file {floorplan.def}

ICC2 Example:

read_def floorplan.def

Step 5: Initialize the Design

Finally, invoke the initialization command to bring all data into the design database.

Innovus Example:

init_design

ICC2 Example:

create_mw_cel -design top_chip
link

5. Common Verification Checks After Import

Once the design is imported, the following checks must be performed:

  • Check Design Consistency:
    check_design
    report_design

  • Check for Missing Cells:
    report_missing_lib_cells

  • Check Connectivity and Power Nets:
    verify_connectivity -type all
    verify_pg_nets
  • Check Timing Integrity:
    report_timing

  • Check for Unit and Scale Errors:
    Verify that library and tech file units match the design grid.

6. Real-Life Example

Consider a SoC design with CPU cores, memory blocks, and peripheral interfaces. The synthesis team delivers a top-level netlist along with multiple block-level libraries. During import:

  • LEF files define the physical dimensions of each macro (like SRAM).
  • Liberty files specify timing at various corners.
  • The DEF might define pre-placed macros.
  • The SDC ensures clock paths and IO delays are defined.

Once imported successfully, the PD tool can generate a full chip floorplan with correct macro and IO locations.

7. Typical Issues During Import

  1. Unresolved Library References: Missing cells not found in the loaded .lib or .lef.
  2. Inconsistent Units: Tech LEF in nanometers but DEF in microns.
  3. Corrupted Netlist: Mismatched hierarchy or naming issues.
  4. Incomplete Constraints: Missing clock or IO definitions in SDC.

Debug using:

report_libs
report_clocks
report_power_domains

9. Summary

Importing design data is the foundation of the PD flow. It ensures that the tool environment correctly understands the circuit’s structure, timing, and physical layers. Proper import guarantees error-free downstream operations in floorplanning, placement, CTS, and routing.

Mastering data import commands and troubleshooting techniques in tools like Cadence Innovus and Synopsys ICC2 is essential for every physical design engineer aiming for efficient, timing-clean silicon implementation.

Partitioning in Physical Design (PD)

1. Introduction

Partitioning is the first step in the physical design flow after design data import. It involves dividing the complete chip (SoC) into smaller, manageable sections or blocks. Each block can then be designed, optimized, and verified independently, improving design efficiency, reusability, and timing control.

For large SoCs containing millions of standard cells and multiple functional modules (CPU, GPU, Memory, IO, etc.), direct full-chip design is computationally heavy and complex. Hence, partitioning provides a structured, hierarchical approach to implementation.

2. What is Partitioning?

Partitioning is the process of dividing a large design into smaller blocks or partitions based on functionality, timing, and area constraints while minimizing inter-block connections.

Each partition (also called a block or sub-module) behaves like an independent design with its own floorplan, placement, and routing. Once all partitions are implemented, they are integrated at the top level for final signoff.

3. Objectives of Partitioning

Manageability: Break a huge design into smaller, more manageable sub-blocks.
Parallel Work: Multiple teams can work on different partitions simultaneously.
Timing Closure: Easier to achieve timing within smaller partitions.
Reusability: Frequently used IPs (e.g., memory, UART, PCIe) can be reused in multiple designs.
Hierarchical Flow: Reduces runtime and improves convergence of P&R tools.

4. Design Data Used in Partitioning

To perform partitioning, the following data from the design import stage is required:

  • Synthesized netlist
  • SDC constraints for clocks, IO delays, and timing exceptions
  • Library files (.lib) for each block
  • LEF files defining physical dimensions
  • Technology LEF for process and routing rules

5. Partitioning Strategies

Partitioning can be classified into several types depending on the design style:

a) Functional Partitioning
  • Divides the design based on module functionality.

  • Example: Separate blocks for CPU, Memory Controller, and GPIO.
b) Physical Partitioning
  • Based on area, location, or physical constraints.

  • Example: Grouping cells based on floorplan boundaries.
c) Hierarchical Partitioning
  • Subdivides top-level modules into smaller sub-blocks for ease of integration.
d) Timing-Based Partitioning
  • Partition boundaries defined by critical timing paths to ensure minimal cross-block delay.

6. Partitioning Flow

Step-by-step partitioning procedure used in PD tools like Cadence Innovus or Synopsys ICC2.

Step 1: Define Hierarchy

The RTL or gate-level netlist usually defines a hierarchy. Analyze it to identify suitable module boundaries.

report_hierarchy

Step 2: Determine Partition Criteria

Choose partitions based on:

  • Functional modules
  • Timing domains
  • Power domains
  • Area constraints
Step 3: Create Partitions

Innovus Command:

create_partition -name CPU_CORE -area {0 0 2000 2000}
create_partition -name MEMORY_CTRL -area {2100 0 4000 2000}

ICC2 Command:

create_partition -name CPU_CORE -bbox {0 0 2000 2000}
create_partition -name MEM_CTRL -bbox {2100 0 4000 2000}

Step 4: Assign Modules to Partitions

Assign sub-modules to defined partitions.

add_to_partition CPU_CORE [get_cells cpu_core/*]
add_to_partition MEMORY_CTRL [get_cells mem_ctrl/*]

Step 5: Save and Verify Partitions

report_partitions
check_partition_integrity

7. Basic Partitioning Calculations

To ensure proper area utilization and routing feasibility:

Core Area (A):
 [ A = \frac{Total_Cell_Area}{Utilization} ]

Example:
 If total cell area = 2 mm² and utilization = 70%,
 [ A = \frac{2}{0.7} = 2.86 mm² ]

Each partition should be sized so that cell density remains within 60–80%, allowing enough space for routing and buffers.

8. Macro and Standard Cell Partitioning

  • Macros: Large blocks such as SRAM, ROM, PLLs. These should be placed near partition edges to reduce routing congestion.

  • Standard Cells: Smaller logic cells. These are distributed throughout the partition core region.

Example: If the CPU partition contains two SRAM macros, place them symmetrically near the top corners and keep standard cells between them.

Commands:

place_instance SRAM_1 100 1800
place_instance SRAM_2 1800 1800

9. Power and Timing Considerations

  • Define separate power domains for partitions if required.
  • Ensure inter-partition nets have proper timing constraints using set_max_delay or set_false_path.
  • Use level shifters or isolation cells for voltage domain crossings.

Example:

set_false_path -from [get_clocks CPU_CLK] -to [get_clocks MEM_CLK]

10. Verification After Partitioning

Perform the following checks:

  • Area Check: Ensure total area of partitions matches chip core.
    report_area

  • Connectivity Check: Verify all nets between partitions.
    check_connectivity -type all

  • Timing Check:
    report_timing -path full

  • Power Domain Integrity:
    report_power_domains

11. Real-Life Example

Consider a Smartphone SoC containing:

  • CPU Cluster
  • GPU Cluster
  • DDR Controller
  • ISP (Image Signal Processor)
  • IO Subsystem

Each of these modules can be treated as a partition. Teams can independently work on each partition with separate constraints. Once optimized and routed, they are integrated into the top-level floorplan. This modular design approach significantly reduces PD runtime and allows easy debug.

12. Common Issues During Partitioning

  1. Improper Partition Boundaries: May cause excessive cross-partition connections.
  2. Overlapping Areas: Partitions physically overlap, causing DRC errors.
  3. Unbalanced Area Utilization: Some partitions too dense, others too sparse.
  4. Timing Violation Between Partitions: Inadequate timing budgeting.

Debug commands:

report_congestion
report_interpartition_nets

13. Summary

Partitioning is a crucial and strategic phase in physical design. It simplifies chip complexity, allows parallel work, improves timing closure, and enhances design manageability. A well-thought-out partitioning strategy can drastically reduce turnaround time in PD while ensuring high-quality, reusable design blocks.

By mastering partitioning techniques, physical design engineers can handle large-scale designs efficiently, ensuring scalability and optimized performance in modern semiconductor projects.

Floorplanning in Depth — Comprehensive Guide for VLSI Engineers

1. Introduction to Floorplanning

Floorplanning is the first and one of the most critical stages of Physical Design (PD). It defines the placement of major functional blocks, macros, I/O pads, power grids, and routing channels. A well-optimized floorplan directly impacts timing closure, power efficiency, and routability of the chip.

Objective: Optimize area utilization, minimize wire length, balance power distribution, and ensure timing convergence.

Real-world analogy: Imagine constructing a city — before building roads or houses, you must plan where residential areas, factories, and highways go. Similarly, floorplanning decides where each block of logic sits on the silicon die.

2. Input Files for Floorplanning

To begin floorplanning, several design data inputs are required:

  • Netlist (.v or .vhdl): Post-synthesis gate-level representation.
  • Technology File (.tf / .tlu+): Contains layer, spacing, and resistance-capacitance data.
  • LEF/DEF: Library Exchange Format files provide cell and macro geometry.
  • Timing Constraints (.sdc): Setup, hold, and clock definitions.
  • Power Intent (UPF/CPF): Defines power domains and voltage islands.

Command Example (Cadence Innovus):

read_verilog design.v
read_libs stdcell.lef macro.lef
read_tluplus tech.tlu+
read_sdc constraints.sdc

3. Floorplan Objectives

  • Optimize die and core area utilization.
  • Ensure routing feasibility and congestion reduction.
  • Minimize interconnect delay.
  • Proper power distribution.
  • Ensure thermal and signal integrity.
  • Reserve space for clock tree synthesis and routing.

Formula for Die/Core Area:
[ \text{Core Area} = \frac{\text{Total Cell Area}}{\text{Utilization Factor}} ]

Where:

  • Utilization = Ratio of standard cell area to total core area.
  • Typical utilization: 70%–85%.

Example:
If total standard cell area = 8 mm² and utilization = 80%, then:
[ \text{Core Area} = \frac{8}{0.8} = 10\ mm^2 ]

4. Aspect Ratio and Die Shape

Formula:
[ \text{Aspect Ratio (AR)} = \frac{\text{Height}}{\text{Width}} ]

  • AR = 1 → Square die (ideal for balanced routing).
  • AR > 1 → Tall and narrow die.
  • AR < 1 → Wide and short die.

Aspect Ratio Visualization:

+———–+———–+

|           |           |

|           |           |

|  Square   |  Tall/Narrow |

|           |           |

+———–+———–+

5. Macro Placement

Macros are large blocks (memories, PLLs, analog IPs) that must be placed early to optimize connectivity and routing.

Macro Placement Strategy:
  • Place near related standard cell clusters.
  • Avoid overlapping or creating dead spaces.
  • Leave routing channels between macros.
  • Align macros to edges for better accessibility.

Command (Innovus):

create_floorplan -core_util 0.75 -aspect_ratio 1.0 -left_io2core 20 -bottom_io2core 20
place_macros -auto

Macro Placement Flow Diagram:

[Read Design Data] → [Define Core Area] → [Place Hard Macros] → [Add Blockages] → [Save DEF]

Macro Placement Issues:
  • Routing Congestion: Macros too close together.
  • Power Drop: Insufficient power straps.
  • IR Drop: Improper placement of high-power macros.

6. Standard Cell Placement Region

After macros, define placement regions for standard cells.

Commands:

create_place_blockage -type soft -rect {x1 y1 x2 y2}

Guidelines:

  • Avoid placing cells under power rings.
  • Reserve buffer and inverter space near clock nets.
  • Ensure even distribution for density and timing.

7. Routing Channels and Power Planning

Routing Channel: Space reserved for interconnect wires between macros.

Formula for Channel Width:
 [ W_c = \frac{N_t \times P_t}{M} ]
 Where:

  • ( N_t ): Number of tracks per metal layer.
  • ( P_t ): Pitch of tracks.
  • ( M ): Number of routing layers.

Power Planning Layers Visualization:

+—————————–+  Metal 8  → Power Ring

|          Power Ring         |

+—————————–+  Metal 7  → Horizontal Straps

|        Power Straps         |

+—————————–+  Metal 6  → Vertical Straps

8. Floorplan Validation

Once the floorplan is ready, run DRC, congestion, and area checks.

Innovus Commands:

check_drc
report_congestion
report_utilization

Synopsys ICC2:

check_floorplan
report_utilization
report_power_structure

9. Floorplanning Flow Step-by-Step

  1. Import design data
  2. Define core area and aspect ratio
  3. Place I/O pads and macros
  4. Define placement blockages and routing channels
  5. Create power rings and straps
  6. Validate floorplan and fix congestion
  7. Save floorplan (DEF format)

10. Common Floorplan Issues & Fixes

Issue Cause Fix
Congestion Macros close together Increase channel spacing
IR Drop Insufficient power grid Add more straps/rings
Timing Violations Poor macro alignment Move macros closer to related logic
Area Overflow High utilization Increase die/core area

11. Real-World Example

Design: 16nm SoC with ARM Cortex Core

  • Macros: 10 SRAMs, 2 PLLs, 1 USB PHY.
  • Core area: 8mm × 8mm.
  • Utilization: 78%.
  • Routing layers: M2–M8.

Outcome: Proper macro alignment reduced congestion by 12%, improved WNS (Worst Negative Slack) from -0.2ns to +0.05ns.

Summary

Floorplanning bridges design intent and physical realization. A robust floorplan ensures optimal PPA (Power, Performance, Area) and smooth transition to placement and routing. Modern tools like Cadence Innovus and Synopsys ICC2 automate much of the flow but still depend on engineering judgment for macro placement and power planning.

Illustrations Included:

  • Aspect Ratio visualization
  • Macro Placement Flow diagram
  • Power Planning Layer stack

Floorplan Flow schematic

Page 21