Backside PDN in OpenROAD (BSPDN)

[gudeh]

I would like to open a discussion on implementing backside Power Delivery Network (PDN) support in OpenROAD.

-We could introduce two separate layer stacks (frontside and backside), both owned by dbTech, potentially through a new stack abstraction class.
-We would need to support Through-Silicon Vias (TSVs) for vertical connectivity between backside and frontside layers.
-Some routing tools, such as CTS, may need to be made aware of backside connections.
-We should also consider how to reflect backside layers in LEF/DEF and within the OpenDB (odb) representation.

This was already attempted in industry.
IMEC

[maliberty]

@gadfort @QuantamHD @rovinski opinions on how to represent backside layers in ODB?

[rovinski]

Unfortunately no, I BSPDN is quite new and I have 0 experience with it.

[maliberty]

In the current odb the layer stack is implicit in LEF ("You must define layers in process order from bottom to top.") and in dbTech::getLayers(). Layers also have getNumber() and routing layers (except MIMCAP) have getRoutingLevel(). Both are in [1..N] and can be used as array indices.

We could continue with this model but now the stack would extend from backside to frontside. The transistors would sit in the middle of the stack and std cell pins would no longer be at the bottom. Various code assumptions would be broken but the [1..N] indexing would still work.

A variant of the above would be to use negative indices for the backside in number and routing level. Front side only tools would find this simpler but using the values as indices would not be safe in general.

The stack could be broken into two separate stacks (front & back). The number & routing level would then be stack specific. Tools that only deal with the front side would need minimal updating. Tools that deal with both stacks would be more complex. Care would need to be taken not to mix up indices from the two stacks (perhaps strong C++ types could be used).

Even with a single stack we could have a "front side view" and "back side view" adaptors.

There are a bunch of tradeoffs and I'm interested in opinions or experience.

[gadfort]

@maliberty as discussed at DAC. I think the "correct" solution is to preserve the stack in order as provided by the LEF, maybe remove the routing level concept. To help, we could provide a frontside and backside or all layer iterator (which might avoid confusing folks too much since all current tools are using frontside iterators now).
Tools that heavily rely on the routing layer concept could create a map themselves.

[maliberty]

In looking at the current uses I see it is helpful to have a method like isAbove/isBelow to compare two tech layers. I think keeping routing level as an internal field to the db that can be used to quickly implement such relative methods would be helpful, but we could remove the public usage of the exact value.