Macro Placement

This article discloses the implementation of our submission in the Macro Placement Challenge 2026 hosted by Partcl x Hudson River Trading!

DISCLAIMER : THIS ARTICLE WILL KEEP SEEING NEW ADDITIONS

See more: https://github.com/partcleda/macro-place-challenge-2026

Team Name : Two-IIITK-Kids

Team Members : Myself (Amruth Ayaan Gulawani) and Joel Dan Philip

Submission Repository : https://github.com/NotCleo/Macro-Placer

Submission Name : SmoothGDCDGPSA

(Smooth surrogate Gradient Descent + Coordinate Descent + Global Placement + Simulated-Annealing-family finisher)

This article will discuss our bulky codebase covered in Part I; sections I-V.
   a) Section I : Formally defining the challenge
   b) Section II : Formal problem statement
   c) Section III : The three metrics (WL, C, D)
   d) Section IV : The input files, formats, schemas
   e) Section V : File inventory, dependency tree

After you finish a top view reading of the challenge itself (link above),
then this article, then our codebase, then the performance, you will be
able to finally understand how we built the macro placer from ground up.

The first five sections are for anyone that participated in
the challenge / EDA tool R&D/developer or Physical Design Enthusiast
can grasp it slightly fast.

For someone, who is like me, an ordinary electronics undergrad, or who is
new to ASIC Physical Design, understands basic programming experience, math,
digital electronics, ASIC Design flow, machine learning, optimizations.

I have laid out my chain of thoughts while building this thing in Part II.

I have laid it out as follows:
1) Our Initial thoughts about this challenge
2) What (and How) we tried in initially in this challenge
3) How I formally elaborated and scaled the challenge's problem statement
4) How I used my current knowlegde to start designing a naive placer 
5) How I found all the breakthrough points and their workarounds
6) A collection of algorithms/definitions/techniques
7) A detailed description of how to start reading our codebase

We certainly did not arrive at these fancy solutions by prompting 
"hey claude, make me a macro placer, make no mistakes!" ;)

But first do have a look at the cool GIFs of each benchmark :)

Thank you for reading this article!

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

About the team:
 
I and Joel are ECE undergrads at IIITK,

He found our first major breakthrough where he beat the hardest proven 
baseline aka RePLAce's, which is the global analytical placer used in 
OpenROAD's placement engine). Glad to have worked on this exhaustively!

A quick overview about the challenge itself :

Macro placement is the problem of positioning large fixed-size blocks (SRAMs, IPs, analog macros, etc.) on a chip floorplan so that routing congestion, timing, power delivery, and area constraints are balanced. Unlike standard-cell placement, macros have strong geometric and connectivity constraints, so the challenge is to explore a highly discrete design space while minimizing wirelength, avoiding blockages, and preserving downstream routability and timing quality.

How did our submission perform?

We are global rank 13

The rank was produced after taking in three metrics (congestion, wirelength, density) to produce a proxy cost (lower the better)

Proxy Cost = 1.0 × Wirelength + 0.5 × Density + 0.5 × Congestion

The following is our performance for the ICCAD04 benchmark;

(Official Best) Proxy Cost = 1.0295, Time = 2432s/benchmark

(Unofficial Best) Proxy Cost = 0.9767, Time = 3160s/benchmark

The proxy was computed by TILOS MacroPlacement evaluator (the Circuit-Training proxy from Google’s Nature 2021 RL-placement).

Our placer’s floorplan visuals for all benchmarks :

Part I [Section I-V]

Consider reading these definitions :

Section I : Formally defining the challenge

This section lays out our ground work :)

A chip floorplan is a canvas. We are given a few hundred rigid rectangles (hard macros like SRAM blocks) and a somewhat larger set of squishy rectangles (soft macros like some abstracted clusters of standard cells, executing some logic), plus a list of nets: groups of pins that must eventually be connected by wires. What’s our job? the job: choose an (x,y) position for every rectangle within this canvas so that a judge’s cost function (aka the proxy) is as low as possible, with zero overlap between any two hard rectangles, everything inside the canvas, and the whole computation finishing in under one hour per validation benchmark.

Seems goofy? The analogy that holds up best: Imagine planning a city district.

• Wirelength : total commuting distance. Buildings that talk should be close.
• Density : how crowded the most-crowded map tiles are. Cramming everything into one corner is penalized even if commutes are short.
• Congestion : traffic on the road grid. Every commute occupies road segments; each map tile has a fixed road capacity; the judge looks at the worst jams. Towers additionally block roads that pass over them.

Here’s the challenge! The three pull against each other, which is the entire game of this competition: clustering shortens wires but jams roads and crowds tiles; spreading relieves jams but stretches wires. This means trying to reduce wirelength between macros increases density and congestion, so this is a three way trade-off to balance!

Here’s the complete list of the notation/representations used :

From a bird’s eye view :

Big picture

We put in a benchmark and its initial positions as input to our macro placement engine which outputs the final positions.

What are these benchmarks?

For example, the ibm01 benchmark has:

• 246 hard macros of varying sizes (ranging from 0.8 to 27 μm², with 33× size variation)
• 7,269 nets connecting macros to each other and to 894 pre-placed standard cell clusters
• A 22.9 × 23.0 μm canvas with 42.8% area utilization

Before that, here are the rigid rules of the challenge :

• Must use TILOS MacroPlacement evaluator
• Hardcoding solutions for specific benchmarks
• Using external/proprietary placement tools
• Exceeding runtime limits (1 hour per benchmark hard timeout)
• Overlaps in resulting placement. Participants should add small gaps in their legalization to avoid float-precision edge cases.
• 90° rotations of hard macros (R90, R270, FE, FW) ; the fakeram45 SRAMs in our benchmarks aren't designed for rotation (pin access and internal metal direction assume a fixed orientation)
• Resizing soft macros ; soft-macro size is a proxy-only concept for density/congestion that doesn’t translate to Tier 2; sizes are locked to the initial .plc values on every compute_proxy_cost call

Algorithm Design Rule Check (how we satisfy the strict rules)

The details of the benchmarks are :

ICCAD04 Benchmarks: Classic macro placement benchmark suite used in academic research

Certain independent facts make this problem brutal.

How big is the search space to place these macros? (continuous view)

it is 10⁸⁰⁰…, a placement is one choice of center for every movable rectangle. On ibm01 (smallest benchmark) that is 246 (Hard)+894 (Soft)=1,140 movables × 2 coordinates each:

a single point in a 2,280-dimensional space. Analogy: a mixing console with 2,280 sliders, where the score depends jointly on all of them and moving any one slider changes what every other slider should be.

How big is the search space to place these macros? (counting view)

A continuum has infinitely many points, so to count configurations you discretize at the coarsest resolution the metric can still distinguish. The congestion metric only changes when a pin moves from one grid cell to another, so the coarsest honest discretization is one candidate position per grid cell. ibm01’s grid has

By the multiplication principle, macro 1 within ibm01 has 1,845 choices, and for each of those macro 2 has 1,845 choices, and so on — the number of distinct placements of just the 246 hard macros is

Atoms in the observable universe: ∼10⁸⁰. Legal Go positions: ∼10¹⁷⁰. Chess game tree: ∼10¹²⁰.

Some formalized definitions before breaking down our algorithm:

After this analysis, I came to an understanding of how to finally start designing our engine!

The algorithm design boils down to :

Choosing an approach: the elimination ladder

Section II : Formal problem statement

In this section I will define the world, the objects, the variable, the constraints.

• The world: what a die looks like, and what the benchmark keeps of it

  =========================================================   =  die / core boundary
  = - - - - - - - - - - - - - - - - - - - - - - - - - - - =      (I/O + power ring outside)
  = |      |      | +----------+ |      |      |      |   =
  = - - - - - - - - |          | - - - - - - - - - - - -  =   -  horizontal power rails
  = |      |      | |   SRAM   | |      |      |      |   =      (every std-cell row)
  = - - - - - - - - |  (hard   | - - - - - - - - - - - -  =
  = |      |      | |   macro) | |  ..........  |      |  =   |  vertical power straps
  = - - - - - - - - +----------+ -  ..........  - - - - - =      (upper metal)
  = |      |      |      |      |   ..........  |      |  =
  = - - - - - - - - - - - - - - - - ..........- - - - - - =   .. a *soft* cluster: a
  = |      |      |      |      |      |      |      |    =      neighborhood of std
  = - - - - - - - - - - - - - - - - - - - - - - - - - - - =      cells, no fixed outline
  =========================================================

On a real chip, the placement canvas is the core area of the die ; a rectangle wrapped by the I/O ring, striped by horizontal power rails (VDD/VSS on metal-1, one pair per standard-cell row) and vertical power straps on upper metals, with macros dropped into that fabric and standard cells filling the rows between them.

The Tier-1 benchmark keeps the geometry and throws away the electricity: no power rails, no rows, no metal layers, no timing. What survives is exactly what the three metrics need ; a bare canvas, a scoring grid laid over it, and ports pinned to the boundary.

     p1  p2  p3   ...   p246        ← 246 ports: fixed points on the top edge (y = 23.035)
   ┌────┬────┬────┬────┬────┐  y = H = 23.04
   │    │    │████│████│    │
   ├────┼────┼────┼────┼────┤       45 × 41 evaluation grid; each cell 0.510 × 0.562
   │    │░░░░│████│████│    │       (this grid exists only for SCORING — macros sit at
   ├────┼────┼────┼────┼────┤        arbitrary real coordinates, not snapped to it)
   │    │    │    │    │    │
   ├────┼────┼────┼────┼────┤       ████ cells fully covered by a hard macro
   │    │    │    │    │    │       ░░░░ partially covered (fractional occupancy)
   └────┴────┴────┴────┴────┘  y = 0
   x = 0                x = W = 22.95

the optimizer acts in the bottom picture, but every design decision in it (blockage allocations, the no-90°-rotation rule, density caps) is a shadow of the top picture.

The cast of objects

Hard macro : a rigid rectangle with pins riveted to it. The pins are the only thing wires connect to; the body is what must not overlap:

A hard macro is a finished piece of layout: for the SRAMs that dominate real designs, a bitcell array (6T/8T cells drawn at pushed design rules), row decoders, column muxes/sense amplifiers, and self-timed control, delivered by a memory compiler as GDS (polygons) + LEF abstract (outline, pins, blockages) + Liberty timing + Verilog model. Its placement-relevant attributes: width×height, pin list with fixed offsets and layers, allowed orientations, blocked routing layers, power-pin geometry, and required keepout halo

        ◄────── w_i = 1.28 ──────►
   +--------------●--------------+    ▲     +  rigid boundary — no other HARD macro may
   |                             |    │        overlap it, ever (the one hard constraint)
   ●            ×                |  h_i =   ●  pins (MACRO_PIN nodes), riveted at fixed
   |     c_i = (x_i , y_i)       ●   0.76      offsets δ from the centre; e.g. the left
   |                             |    │        pin here: δ = (−0.64, +0.10), world pos
   +---------●-------------------+    ▼        π = c_i + δ
                                            ×  the ONLY decision variable: the centre c_i

Soft macro : a standard-cell neighborhood abstracted to a square whose area equals the summed cell area. It is “soft” because it is not a physical object with edges:

   · · · · · · · ·
   ·             ·     dotted boundary: soft — hard macros and other softs MAY overlap it
   ·      ●      ·     exactly ONE pin, at the centre (δ = 0) — all its nets attach there
   ·             ·     side = √(Σ std-cell area of the cluster); resizing it is forbidden
   · · · · · · · ·     it still counts fully toward density (overlaps double-count!)

ibm01 has 894 softs. They are 78 % of the movables ; which is why two whole stages (opt1, the Laplacian resolve) exist just for them.

Port : a fixed point on the canvas boundary where a net enters/leaves the block (the abstraction of an I/O pad or a parent-level pin).

ibm01: 246, strung along the top edge.

Pin : not an independent object: a named connection point owned by a macro (offset from its center) or coincident with a port.

The asymmetry in the last column is load-bearing: only hard macros block routing, so spreading hards relieves congestion twice (demand moves and blockage spreads), while spreading softs only moves demand

• The Variables

• The constraints

I would like to clear that our placer does not use orientations!

Macros can be placed with certain legal orientations too!!

here’s the formal legality :

Klein four-group

Section III : The three metrics (WL, C, D)

Section IV : The input files, formats, schemas, and what the code actually reads

Two text files fully define a benchmark :

netlist.pb.txt is the guest list plus who-must-sit-near-whom (every object, its size, its pins, and every relationship)

initial.plc is the venue spec plus a suggested seating chart (canvas dimensions, the scoring grid, routing capacities and a starting position for everyone, which turns out to be illegal anyway).

Everything the evaluator will ever know comes from these two files; everything the placer is allowed to change is the seating.

Node types and their attributes:

node {                                # an I/O port
  name: "p3"
  input: "a7419/IP1"                  # ← connectivity: this node is driven by pin IP1 of macro a7419
  attr { key: "type"  value { placeholder: "PORT" } }
  attr { key: "side"  value { placeholder: "TOP" } }
  attr { key: "x"     value { f: 0.75 } }      # fixed world position
  attr { key: "y"     value { f: 23.035 } }
}
node {                                # a hard macro
  name: "a7419"
  attr { key: "type"   value { placeholder: "MACRO" } }
  attr { key: "width"  value { f: 1.28 } }
  attr { key: "height" value { f: 0.76 } }
  attr { key: "x" ... } attr { key: "y" ... }  # position (overwritten by .plc)
}
node {                                # a pin OF that macro
  name: "a7419/IP1"
  attr { key: "type"    value { placeholder: "MACRO_PIN" } }
  attr { key: "macro_name" value { placeholder: "a7419" } }
  attr { key: "x_offset" value { f: -0.4 } }   # offset from macro CENTER
  attr { key: "y_offset" value { f:  0.2 } }
  attr { key: "weight"  value { f: 1.0 } }     # net weight (all 1.0 here)
  input: "a123/OP2"                    # nets = driver pin → sink pins via input edges
}

Soft macros appear as MACRO nodes with soft_macro semantics

(single center pin, SOFT_MACRO/SOFT_MACRO_PIN counted in the .plc header).

Get Amrut’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

How nets are reconstructed from input: edges. There is no net { } record anywhere; connectivity is stored inverted, as each sink naming its driver. The parser walks all nodes, groups every pin/port that names the same driver, and that group is the net:

                  ┌── input: "a123/OP2" ──  node "a7419/IP1"   (a hard-macro pin)
node "a123/OP2" ◄─┼── input: "a123/OP2" ──  node "p3"          (a port)
(the driver pin)  └── input: "a123/OP2" ──  node "a88/IP4"     (another macro's pin)

 ⇒  net = { a123/OP2 (source);  a7419/IP1, p3, a88/IP4 (sinks) },  weight w = 1.0
   exposed as plc.nets = { "a123/OP2": ["a7419/IP1", "p3", "a88/IP4"], … }

This is the same information a Verilog netlist carries as wire n1; assign … ; just stored edge-by-edge on the receiving end. Nets whose driver or all sinks fail to parse into usable pins are dropped, which is why ibm01 loads 5,993 nets from 7,269 raw records.

The name of our submission decodes the pipeline: Smooth surrogate Gradient Descent + Coordinate Descent + Global Placement + Simulated-Annealing-family finisher.

 SETUP     load plc · attach pin-level nets · seed RNGs · mode = std/HUGE/very_huge · cd_cfg(K,R)
   │
   ▼
 BASIN CONSTRUCTION (deterministic, GPU)
   Phase α  focused-electrostatic GP: 8 Adam replicas, FFT-Poisson top-k density field,
   │        RUDY top-k congestion, annealed weights, replica-exchange   [std benches only]
   ▼
   legalize (bulk push-apart → greedy → spiral → grid-snap; 0.005 margin, 1e-4 f32 nudge)
   ▼
   Cycle 1  Adam GD on smooth proxy (γ 0.5→2→8, noise) → legalize → CD   [+2 extra seeds unless basin strong]
   Cycle 2  short GD (γ3→8, cong_w auto 3/4/5) → CD → cong-CD            [skipped on most HUGE]
   Cycle 3  shorter GD (γ4→8) → CD → cong-CD
   swap → cd_final → cd_cong
   │
   ▼
 REFINEMENT GAUNTLET (each stage oracle-gated; wholesale-skipped via fast_path)
   T3 longest-net compaction · opt1 soft-centroid pull · opt3 hot-cell attack ·
   Hessian-eigvec escape · signal-LNS escape · T1 cong-SA · wide-area swap ·
   refine_iter×≤10 (swap+CD+congCD, hotspot hops) · polish×≤4 · fine_swap
   │
   ▼
 FINISHER (stochastic; the budget's real owner)
   Laplacian soft-resolve (closed-form clique-quadratic HPWL for softs, CG + α line-search)
   LAHC restarts (1/2/3× by budget) with Laplacian interludes between restarts
   │
   ▼
 return best zero-overlap placement ever recorded   (else V12 salvage chain)

Section V : File inventory, dependency tree, full function tables

File inventory

Now comes a high overview, what order do we read our code-base in?

1) SCORING.md
2) external/MacroPlacement/Testcases/ICCAD04/ibm01/netlist.pb.txt
3) external/MacroPlacement/Testcases/ICCAD04/ibm01/initial.plc
4) external/MacroPlacement/CodeElements/Plc_client/plc_client_os.py
5) macro_place/_plc.py
6) macro_place/benchmark.py
7) macro_place/loader.py
8) macro_place/objective.py
9) macro_place/evaluate.py
10) script4.py
11) script3.py
12) script5.py
13) script2.py
14) script1.py
15) script6.py
16) script7.py
17) placer.py
18) script16.py
19) script17.py
20) script18.py
21) script13.py
22) script8.py
23) script12.py
24) script11.py
25) script10.py
26) script14.py
27) script9.py
28) script15.py
29) script20.py
30) script19.py
31) placer.py
32) script21.py
34) Performance/performance.txt

Wirelength v/s Congestion v/s Density for all benchmarks :

Part II [Section I-VII]

Section I : My Initial Thoughts ?

I had vague understanding of physical design before this challenge, happened while tinkering with OpenRoad

I scratched the surface by,

1. Understanding different stages and different Input file formats and Output file formats and their structures and their contents
2. Understanding basic primary rules about macro placement and it’s ordering in the PD flow.
3. Understanding the challenge’s README.md, SETUP.md, SCORING.md and different Input file formats and Output file formats and their structures and their contents

Elaborated PD Flow

One can see that “Macro Placement” belongs to “Floorplanning” stage of ASIC Design.

These below diagrams show a preview of different files of RTL handoff.

Floorplan Specifications

Interconnect Metal Stack- Metals and Vias, Pitches, Aspect Ratios

Metal Layers on Silicon

Section II : My initial attempt?

I started building my first macro placer using Simulated Annealing.

This was mostly about optimization of our objective proxy function.

I then started hunting for different optimization algorithms across YouTube and Research Papers.

Optimization can be explorative or exploitive.

Macro placement requires a highly calibrated transition between both exploration and exploitation.

Need for Exploration (Early-Stage Global Search)

• The Landscape Challenge: The macro placement search space is filled with deep local minima. For example, an algorithm might find a configuration where a group of memory macros is packed perfectly together (a local minimum). However, if that cluster is on the wrong side of the die relative to the logic that communicates with it, the global wirelength and timing will be ruined.
• The Role of Exploration: the algorithm must act disruptively. It must be willing to accept “worse” moves ; temporarily increasing area, overlap, or wirelength ; to jump out of local traps and evaluate completely different topological arrangements (swapping a block from the top-left corner to the bottom-right).
• Algorithms Applied: High-Temperature Simulated Annealing, Sequence Pair / B*-Tree Random Walks.

Need for Exploitation (Late-Stage Local Refinement)

• The Landscape Challenge: Once the macros are in the right general zones, continued exploration becomes destructive. Randomly swapping blocks at this stage will shatter the timing paths and ruin the carefully structured layout.
• The Role of Exploitation: The algorithm must pivot to a greedy, highly focused search. It zeroes in on the immediate neighborhood to pack the macros tightly, align input/output pins, insert routing halos, snap the blocks to the manufacturing grid, and resolve any remaining physical overlaps (legalization).
• Algorithms Applied: Steepest-Ascent (Greedy) Hill Climbing, Tabu-Assisted Hill Climbing, Record-to-Record Travel (RRT).

Simulated Annealing remains to be really useful, It acts as an automatic slider between the two extremes (exploration and exploitation);

• High Temperature (Explorative): The acceptance probability for bad moves is near 100%. The algorithm behaves like a pure Random Walk, freely bouncing around the search space to find the best general region.
• Medium Temperature (Balanced): The algorithm begins to favor the downward gradient but still occasionally jumps over small ridges to test adjacent layout configurations.
• Low Temperature / Quenching (Exploitive): The acceptance probability for bad moves approaches 0%. The algorithm transforms into a pure Hill Climber, aggressively exploiting the local gradient to lock the macros into their final, legalized coordinates.

Hill Climbing Algorithms [Exploitive]

1. Simulated Annealing (Stochastic Hill Climbing) : The industry-standard core engine for global macro floorplanning (Parquet, TimberWolf).
2. Steepest-Ascent Hill Climbing : Fast local post-placement legalization, grid-snapping, pin alignment, and macro channel sizing.
3. Late Acceptance Hill Climbing (LAHC) : Multi-objective macro floorplanning (wirelength, area, congestion) without needing complex temperature schedule tuning.
4. Tabu-Assisted Hill Climbing : Prevents cyclic thrashing (oscillating macro swaps) during local legalization and space refinement.
5. Look-Ahead (Multi-Step) Hill Climbing : Coordinates multi-macro shifts to escape local traps where single-block moves worsen cost.

Random Walk Algorithms [Explorative]

1. Sequence Pair / B*-Tree Perturbation Walk : Standard topological state-space transition mechanism (swaps, rotations, tree restructuring) for non-overlapping macro placement.
2. Metropolis-Hastings Random Walk : The Markov-chain sampling kernel driving SA-based global macro placement engines.
3. Great Deluge Random Walk (GDA) : Fast traversal across flat wirelength cost plateaus without calculating expensive exponential temperature probabilities.

Since SA seemed like a good start, I started to explore SA.

Simulated Annealing

If a liquid material cools and anneals too quickly, then the material will solidify into a sub-optimal configuration. If the liquid material cools slowly, the crystals within the material will solidify optimally into a state of minimum energy.

Perturbations mean small changes in the normal state.

Energy function approaches the minima after perturbations

Since we cannot find energy for every configuration (enormous design space), we use the Metropolis Algorithm.

The Metropolis algorithm is the core engine inside simulated annealing. It decides whether to accept a new, worse solution to escape local traps. It calculates an acceptance probability using the energy difference and a decreasing temperature parameter, allowing random exploration that gradually shifts into a focused local search over time

Key Ingredients for SA
1. A concise description of a configuration (architecture, design,
topology) of the system (Design Vector).
2. A random generator of rearrangements of the elements in a
configuration (Neighborhoods). This generator encapsulates rules
so as to generate only valid configurations. Perturbation function.
3. A quantitative objective function containing the trade-offs that
have to be made (Simulation Model and Output Metric(s)).
Surrogate for system energy.
4. An annealing schedule of the temperatures and/or the length of
times for which the system is to be evolved.

I followed up SA by looking into Placement and Routing categories.

Placement and Routing are split into stages to manage computational complexity. Placement determines the physical (X, Y) locations of components, while routing connects those components with physical metal wires.

├── Routing                   
│   ├── Detailed     
│   ├── Global          
│   └── Specialized                   
├── Placement                 
│   ├── Detailed     
│   ├── Global          
└── └── Specialized 

Global Placement

Global Placement is the initial, coarse phase of placement where the engine determines the approximate relative locations of all components (standard cells and macros) across the chip area.

Instead of enforcing strict non-overlapping rules, global placement treats the chip as a continuous field. Modern placers use analytical placement algorithms (such as force-directed methods or electrostatics-based analogies like ePlace and RePlAce) to solve a continuous optimization problem: minimizing total wirelength while spreading out cell density. It does not yield a legal floorplan (macros will overlap each other and extend beyond die boundaries), but it provides the spatial target coordinates used to seed SA

Detailed Placement (Legalization)

Detailed Placement takes the rough, overlapping positions generated by Global Placement and legalizes them into exact, non-overlapping, DRC-compliant physical positions.

It operates discretely, snapping components to placement site rows/grids, enforcing minimum spacing rules, and resolving overlaps while minimizing the total displacement (distance moved) from the Global Placement targets. It ensures valid abutted layout, valid orientations and alignments.

Specialized Placement

Specialized Placement refers to dedicated placement steps required for non-standard circuit structures that have specific functional, electrical, or physical constraints beyond generic logic gates.

Examples include placing I/O pads along the die perimeter, clock tree buffers, decoupling capacitors, power-tap cells, and boundary/end-cap cells.

Global Routing

Global Routing is a coarse-grain path planning phase. The engine divides the entire die area into a 3D or 2D grid of coarse tiles called Global Routing Cells (GCells).

GR does not assign exact metal tracks or draw individual wires. Instead, it determines which sequence of GCells a net should pass through from source to target, balancing wirelength against GCell routing capacity to avoid congestion bottlenecks.

• Routability Evaluation of Macro Floorplans: If macros are placed too close together, GR highlights red “congestion hotspots” in the narrow channels between them.
• Macro Blockage Maps: Hard macros consume lower metal layers internally (typically M1 up to M4 or M5). GR treats the macro region as a routing blockage on those lower layers, forcing global signal paths to either route through higher metal layers (M6+) over the macro or route completely around its perimeter.
• Pin Access Channeling: GR plans the global corridors needed to bring wide multi-bit buses into tightly grouped macro pin arrays without choking the surrounding channel capacity.

Detailed Routing (DR)

Detailed Routing takes the coarse GCell paths produced by Global Routing and generates the actual physical metal geometries, vias, and layer assignments for every net.

DR works locally (box by box) and must strictly comply with thousands of foundry Design Rule Checking (DRC) rules, including minimum wire width, spacing, enclosure, via rules, and antenna effects.

• Physical Macro Pin Connection: DR makes the final physical connection to the macro’s internal pin shapes. This is a common failure point in physical design due to high pin density at macro edges.
• Internal Blockage Avoidance: DR must navigate around the macro’s internal metal blockages on lower layers, ensuring top-level wires do not drop vias into active macro structures.
• Channel Routing: In the tight spaces between macros (macro channels), DR must fit all interconnecting wires, power straps, and shield wires without violating parallel-run length or minimum-spacing DRC rules

Specialized Routing

Specialized Routing handles dedicated, high-priority, or electrically sensitive networks that cannot be handled by standard signal routers.

This includes Power Distribution Networks (PDN), Clock Tree Networks (CTS), Analog/RF differential pairs, and critical high-speed buses requiring shielding.

At this point I got a feeling this whole challenge is about finding the best optimization algorithm stack.

The below exhaustive list of algorithms/methods :

1. Large Neighborhood Search
2. Iterative Local Search
3. Gradient Descent Algorithms (AdamW, SGD + Nesterov Momentum)
4. Coordinate Descent Algorithms (Accelerated Randomized Coordinate Descent, Stochastic Dual Coordinate Ascent, Block Coordinate Descent, Gauss-Southwell Coordinate Descent)
5. FFT based 2D Poisson Equation solvers
6. Hessian-guided Perturbed Wasserstein Gradient Flows
   (Escaping Saddle Points)

References :

1. https://github.com/The-OpenROAD-Project/OpenROAD
2. https://openroad.readthedocs.io/en/latest/
3. https://github.com/partcleda/macro-place-challenge-2026
4. https://chipdesignrashid.github.io/chip-design-website/
5. https://medium.com/@agnathavasi360
6. https://www.physicaldesign4u.com
7. https://www.youtube.com/@TeamVLSI/videos
8. https://eclass.uth.gr/modules/document/file.php/E-CE_U_104/Practical_Problems_in_VLSI_Physical_Design_Automation.pdf
9. https://theswissbay.ch/pdf/Gentoomen%20Library/Misc/Springer%20-%20VLSI%20Physical%20Design.pdf
10. https://github.com/hemanthkumardm/SFAL-VSD-SoC-Journey
11. https://www.cse.iitm.ac.in/~vplab/courses/optimization/Optim_methods.pdf
12. https://siliconpath.in/P