Exploring top-level power routing options for Caravel user projects

This article provides an overview of effective power routing on caravel user project's top level

The method by which power routing for designs is performed varies depending on the integration method used. For integration methods, check this blog article. For option #2 in the integration methods (flattening the user macros with the user project wrapper), there are no special considerations and the default hardening flow should automatically be able to power-route the design successfully.

Options #1 and #3 however are considerably more involved- the power routing techniques vary according to the characteristics of the macros being used and indeed- how they were hardened.

Regardless of the power routing method being used, you need to ensure that your design is configured as follows:

The Verilog headers for the submacros have the power pins declared as follows (with a preprocessor guard):
```
`ifdef USE_POWER_PINS
    inout vccd1,
    inout vssd1,
`endif
```
The configuration includes hooks to show OpenLane how to connect the signals, as well as the name of the preprocessor guard for the power pins. Additionally, we ignore OpenROAD's PSM network checker as it lacks the ability to check hierarchical designs correctly.
- In Tcl that would be:
```
set ::env(FP_PDN_MACRO_HOOKS) {mprj vccd1 vssd1 vccd1 vssd1}
set ::env(SYNTH_POWER_DEFINE) {USE_POWER_PINS}
set ::env(FP_PDN_CHECK_NODES) {0}
```
- And in JSON:
```
"FP_PDN_MACRO_HOOKS": "mprj vccd1 vssd1 vccd1 vssd1",
"SYNTH_POWER_DEFINE": "USE_POWER_PINS",
"FP_PDN_CHECK_NODES": false
```

Caravel has two pairs of power/ground pins: vccd1/vssd1 and vdda1/vssa1. The former are to be used for integrating digital macros and the latter for integrating analog macros.

To integrate macros that use both pairs (i.e. macros that themselves integrate both digital and analog components,) you will need to provide a custom OpenROAD PDN script. You can do this using the FP_PDN_CFG variable.

Method 1 - Hierarchical Method:

Saves space, but less routing layers are available for the macros (i.e. for a Macro nested i-deep, N - i metal layers are available for routing.)

The hierarchical method works as follows: the top level integration has access to all metal layers; and the deeper you go in the macro hierarchy, you lose the top-most metal layer as being available for routing.

Example; a macro routed for top-level integration must not have any signals or power routed on met5. A macro routed within that must not have any signals or power routed on met4. And so on.

The power straps on the top-most metal layer of a submacro are then connected to the layer above using vias. (There is no continuity between power straps within each metal layer across the macro boundary.)

The topmost metal layer, met5, is the lightest gray, while met4 and met3 are darker. Vias between metal layers are represented in green.

As you may be able to tell from the figure; sub-macros must be large enough for the straps in the layer above them to intersect with the straps in its topmost layer, otherwise the macro would not be connected to power.

Additionally, particularly in option 1, there are metal "stubs" generated as part of the power distribution network, which aren't connected to any macros. These are generally harmless but do cause higher routing congestion at the top level. If the configuration variable FP_PDN_SKIPTRIM is set to false, the PDN will attempt to remove those stubs.

The hierarchical mode is the default used by OpenLane and no configuration other than that which was shown above is required.

Method 2 - Ring Method:

The ring method works as follows: each macro is hardened with a "power ring" around the core area of the macro, which unlike the hierarchical method, does interrupt the straps on the top level.

This allows the use of the full layers stack for routing, however, it takes more area, making it less space-efficient.

Akin to the hierarchical method; sub-macros must be large enough for the straps in the layer above them to connect to the rings, otherwise the macro would not be connected to power.

The core ring method does not actually require any special configuration for the top-level integration, but all macros need to be hardened with the following options:

FP_PDN_CORE_RING: A boolean indicating whether to form a core ring around a macro or not. false to disable, and true to enable.
FP_PDN_HORIZONTAL_LAYER: While the vertical layer may remain unchanged, the vertical layer should be different from the integrator (i.e.) met5 as .
FP_PDN_CORE_RING_HWIDTH: The width of the horizontal straps forming the core ring.
FP_PDN_CORE_RING_VWIDTH: The width of the vertical straps forming the core ring.
FP_PDN_CORE_RING_HOFFSET: The distance between the horizontal boundaries of the die area and the beginning of the horizontal core ring straps.
FP_PDN_CORE_RING_VWIDTH: The distance between the vertical boundaries of the die area and the beginning of the vertical core ring straps.
FP_PDN_CORE_RING_HSPACING: The intra-strap distance within the two sets of horizontal straps forming the core ring.
FP_PDN_CORE_RING_VSPACING: The intra-strap distance within the two sets of vertical straps forming the core ring.

All distances in µm.