Connected PDN Routing

The connected-PDN extension routes pad, internal-module, and generated-decoupling-capacitor power pins to nearby VDD or GND rails while keeping the original signal-routing flow isolated.

Why a Separate Flow Exists

The standard Hanan router remains the signal router. Power routing needs different endpoint semantics: a module power pin may connect to any suitable nearby point on a rail rather than to one remote fixed pin. COmPOSER therefore copies only the power-specific net behavior into ROUTER/pdn_router/src/Net.cpp and builds a separate pdn_router binary. Shared geometry, placement, parsing, and A* infrastructure still come from ROUTER/hanan_router.

No existing router script or binary is replaced. When the selected config.json contains pdn_routing, composer.sh automatically uses perform_routing_with_pdn.py; configurations without that section retain the signal-only flow.

Build and Run

export PROJECT_HOME=/path/to/COmPOSER
make -C ROUTER/hanan_router
make -C ROUTER/pdn_router

./composer.sh EXAMPLES/LNA_1/config.json
./composer.sh EXAMPLES/PA_2/config.json

No separate PDN command or config_pdn.json is required. The normal composer sequence produces placement and routing inputs, then the routing step performs signal routing, PDN generation, dedicated power routing, and final hierarchical GDS assembly.

End-to-End Sequence

1. Run the normal Hanan router for signal nets.
2. Use utils/gen_rt_hier_gds.py to assemble the routed design and optionally export one GDS cell/file per signal net through --net_gds_dir.
3. Use perform_power_grid_with_pdn_routing.py to create VDD/GND rails, insert decaps, discover power endpoints, create local rail targets, and write PDN routing inputs.
4. Run the dedicated ROUTER/pdn_router/pdn_router binary.
5. Use utils/gen_pdn_rt_gds.py to convert routed power DEF geometry into a hierarchical final GDS.

Local Endpoint Routing

The generator does not create one full-chip bounding-box problem for an entire power net. It creates one virtual rail target for each physical endpoint, near that endpoint and within its local endpoint-to-rail region. When physical and virtual port counts match, the copied net implementation pairs each physical port with its nearest available virtual rail port. The router therefore solves short endpoint-to-rail connections instead of exploring the entire chip for every connection.

The existing signal DEF is parsed as fixed routing obstruction geometry so new power routes do not ignore already-routed signal metal.

Pin and Layer Semantics

• Pad power pins, internal-module VDD/GND pins, and decap pins remain physical endpoints.
• Ordinary module pins are not flattened or expanded across layers.
• Only generated power-grid rail targets are represented across the configured grid layers.
• For LNA_1, GND targets span the M1/M2 mesh and VDD targets span the M8/M9 mesh.
• This lets the router enter a rail on an appropriate grid layer and avoids unnecessary via stacks to an artificially extreme pin-box layer.

Decap Discovery and Connectivity

Decaps are placed after signal routing and before grid construction. Legal candidate locations are filtered against existing geometry. The selected instances are appended to a PDN-specific placement JSON and their macro/pin definitions are appended to a PDN-specific LEF, so the router handles them like other placed modules without mutating the original placement result.

Each example's existing config.json uses decap_count: 3 for a fast sanity-check layout. decap_vdd_net and decap_gnd_net explicitly select the decap supply and return nets.

Configuration Responsibilities

"pdn_routing": {
  "router_bin": "ROUTER/pdn_router/pdn_router",
  "vdd_nets": ["net26", "net12", "net29", "net17"],
  "gnd_nets": ["gnd"],
  "decap_vdd_net": "net12",
  "decap_gnd_net": "gnd",
  "decap_count": 3
}

• vdd_nets: every supply net connected to the shared VDD mesh.
• gnd_nets: every electrically common ground net connected to the shared GND mesh.
• decap_vdd_net and decap_gnd_net: configured power nets receiving generated decap pins.
• Legacy scalar vdd_net and gnd_net fields remain accepted.
• PDK layer JSON: drawing, pin, label, blockage, width, pitch, direction, and via rules.
• Power-grid layer configuration: VDD top/bottom and GND top/bottom rail layers.
• Router constraints: net ordering, permitted layers, and non-default widths.
• Signal DEF: existing routed metal used as PDN obstacles.
• Decap GDS: geometry plus PLUS, MINUS, BULK1, and BULK2 labels.

Generated Files

Final GDS Hierarchy

<top>_GRIDFILLED
└── PDN_ROUTES
    ├── PDN_NET_gnd
    ├── PDN_NET_net12
    ├── PDN_NET_net17
    ├── PDN_NET_net26
    └── PDN_NET_net29

The final generator reads power-net RECT geometry from the PDN DEF and places each net in its own child cell. Signal routes also remain available as net-specific GDS outputs. This structure allows manual inspection of the generated routes without flattening the entire final layout.

Finding Unrouted Power Pins

The augmented placement JSON and LEF define the expected physical endpoints, while the routed PDN DEF and route.log record the realized net routes. Compare endpoints grouped by their mapped power net against the corresponding DEF net and review router completion markers in the log. The expected mapping comes from the original module/pad net assignment plus the explicit decap-label mapping above; it should never be inferred only from physical proximity.

Isolation Guarantees

• The original Hanan router implementation is unchanged.
• The original placement JSON and combined LEF are not overwritten by decap augmentation.
• Power-specific multilayer pin expansion applies only to configured grid rails.
• PDN routing is selected only when the chosen config.json contains pdn_routing; signal-only configurations retain the original behavior.
• Multiple names in gnd_nets share one physical GND mesh and therefore must be electrically common. Isolated ground domains require separate meshes.