grt,cts,est: backside-aware fixes (cross-side direction check, NDR creation, parasitic midpoint)

[mguthaus]

Summary

Three small backside-aware fixes uncovered while bringing up the
gt2n BSPDN PDK in OpenROAD-flow-scripts. Each is independent and
sits as its own commit. The underlying theme is the same: routines
that walk dbTech::findRoutingLayer(1..count) without an
isBackside() guard misbehave on a tech whose routing-layer
enumeration interleaves a backside stack (BPR, BM*, BRDL) with the
familiar frontside stack (M0 .. RDL).

Commits

1. grt: skip cross-side pairs in checkAdjacentLayersDirection
   GRT-126 is a hard error fired when two consecutive routing levels
   share a preferred direction. On a BSPDN tech the level-l /
   level-l+1 pair can straddle the backside boundary (e.g. BPR(H) and
   M0(H)). Those layers are not physical neighbors and direction
   agreement across the boundary is not a misconfiguration. Skip the
   pair when isBackside() differs.

2. cts: skip backside layers in writeClockNDRsToDb
   The default-NDR creation loop builds a dbTechLayerRule for every
   routing layer in the tech. Clock trees route on the frontside.
   The backside rules are derived from backside design rules and
   would never apply to a clock net, but still live in the
   dbTechNonDefaultRule and could leak through by-name lookups.

3. est: keep cut-resistance fallback midpoint on the frontside stack
   computeAverageCutResistance falls back to
   getRoutingLayerCount() / 2 when block max routing layer is unset.
   With backside layers in the count, that midpoint lands on the
   backside via stack instead of the signal-routing via stack the
   function is meant to characterize. Anchor the fallback at
   firstFrontsideRoutingLayer() and halve the frontside-only count.
   Legacy non-backside techs are unchanged.

Why now / impact

The GRT-126 case is not theoretical. Lowering MIN_ROUTING_LAYER to
M0, a perfectly reasonable choice that @gadfort appears to have been
running when he flagged this, is enough to make the check walk the
BPR(H) / M0(H) pair and abort the flow with a hard error on a valid
BSPDN PDK. The default ORFS gt2n config sets MIN_ROUTING_LAYER=M2
today and so happens to skip over the boundary, which masks the bug;
any config that opens the bottom of the stack hits it immediately.

The CTS and EST cases are quieter. The bogus NDR rules on backside
layers never get applied to a clock net in practice, and the EST
fallback only fires when block max routing layer is unset. They are
the same underlying pattern and worth cleaning up at the same time.

Test plan

• Local incremental rebuild clean.
• gt2n/gcd ORFS run through 5_1_grt clean with the series
  applied (no GRT-126, no behavioral change vs. unpatched for
  that config since MIN_ROUTING_LAYER=M2 and block max is set).
• Existing GRT / CTS / EST regressions cover the no-backside path,
  which is what the legacy-equivalence arms of each patch preserve.

Related

@gadfort flagged the GRT-126 case on a review comment elsewhere.
Filing the cluster of three together since they all share the same
underlying pattern.

[gemini-code-assist]

Code Review

This pull request introduces changes to handle backside routing layers appropriately across TritonCTS, EstimateParasitics, and GlobalRouter. Specifically, it skips backside routing layers when writing clock NDRs, refines the fallback logic for estimating parasitics to focus on the frontside routing stack, and avoids adjacent layer direction checks across the backside/frontside boundary. The review feedback highlights potential segmentation faults in TritonCTS.cpp and GlobalRouter.cpp due to missing null checks on routing layer pointers returned by findRoutingLayer before calling isBackside().

[gadfort]

@mguthaus I just reran with this PR and no errors this time. Thanks

[mguthaus]

Had to rebase/push again since Jenkins randomly failed.