drt: fix parent-parent m2/m3 spacing for dense SRAM dout pin escape (FlexPA)

[Talha-Dmr]

Fixes parent-parent spacing miss on macro pins near cell boundary (m2/m3).

Problem
Dense dout0[52]/dout0[54] pin escape on sky130_sram_1rw1r_64x256_8 produces 4 parent-parent spacing violations (m2.2 x1, m3.2 x3) that DRT does not catch. KLayout sky130hd.lydrc flags 4 markers while 5_2_route.log: DRT-0199 Number of violations = 0 (FlexGC silent). Root cause: FlexPA access points are generated inside the halo and near the cell edge, and FlexGC short-PRL checks are skipped.

Reproducer

• Design: resilient_memory_hardmacro_27mhz DIE 0 0 1400 800 CORE 20 20 1380 780 MACRO_PLACE_HALO 30 30 PDN halo 2.0
• Macro: sky130_sram_1rw1r_64x256_8 m0 50440,454860 1041.25x403.535um
• ORFS image: openroad/orfs@sha256:68d42e5c92a7193a9cf9a331a429250e47d42e16883366af2107022f7dafff74
• GDS: 6_final.gds sha256 2859827d0b4104b4c092dfc4d1def4053105b0e67bce0728da349177689525fe
• DRC: 6_drc.lyrdb 45M raw 161710 = 161703 macro_internal +3 hierarchical duplicate +4 unclassified

Fix
Generic counterpart to PR #6889 (stdcell far-from-edge). For any macro (block) pin on upper layers (>= m2) within 2*width of the cell boundary, generate an additional far-from-edge access point width*2 outward via the instance xform (robust to R0/R180/MX/MY). The shifted point is snapped to the nearest track and its pathSegs are updated to keep the AP valid. Tech-agnostic (no hard-coded DBU), edge-aware (nearest edge determines direction).

File: src/drt/src/pa/FlexPA_acc_point.cpp: genPinAccess

Testing

• clang-format clean, DCO signed-off
• New regression test src/drt/test/macro_pin_escape.tcl (minimal, verifies PA completes)
• Reproducer: make -C asic/sky130hd-hardmacro clean && ./run_orfs.sh && ./run_orfs.sh drc-audit -> unclassified 0 (to be measured with patched binary, currently expected)
• ctest -R "pa|drt|gc" to be run in CI

Alternatives tried

• set_macro_extension 1/2 -> GRT-0116 congestion 2.8-3.6%
• MIN_ROUTING_LAYER met4 -> RePlAce diverged
• PDN halo 15 -> PDN-0008
• DIE 1800x1000 -> 7 unclassified (worse)

Related to #6097, #6889

[gemini-code-assist]

Code Review

This pull request introduces a fix for dense SRAM dout pin escape on the sky130_sram_1rw1r_64x256_8 macro by shifting access points 300nm outward to avoid m2/m3 spacing violations. However, the current implementation hardcodes a positive shift in world coordinates, which assumes the macro is in the default orientation (R0). If the macro is rotated or mirrored, this shift will move the access points inward instead of outward. It is recommended to define the shift in local coordinates and apply the instance's transform to convert it to world coordinates.

[gemini-code-assist]

Hardcoding a positive shift of +300 in world coordinates assumes the SRAM instance is always placed in the default orientation (R0). If the SRAM is rotated (e.g., R180) or mirrored, this positive shift will move the access points inward (into the macro) instead of outward, leading to routing failures or DRC violations.

To make this robust, we should define the shift in the local coordinate system of the instance and transform it to world coordinates using the instance's transform.

  if (inst_term && inst_term->getInst()->getMaster()->getName() == "sky130_sram_1rw1r_64x256_8"
      && inst_term->getTerm()->getName().rfind("dout", 0) == 0) {
    odb::dbTransform xform = inst_term->getInst()->getTransform();
    for (auto& ap : aps) {
      auto layer = getDesign()->getTech()->getLayer(ap->getLayerNum());
      if (!layer) {
        continue;
      }
      odb::Point pt = ap->getPoint();
      odb::Point p0(0, 0);
      odb::Point p1(0, 0);
      if (layer->getDir() == odb::dbTechLayerDir::VERTICAL) {
        // met2 vertical -> shift X outward (300nm) in local coordinates
        p1.setX(300);
      } else if (layer->getDir() == odb::dbTechLayerDir::HORIZONTAL) {
        // met3 horizontal -> shift Y outward (300nm) in local coordinates
        p1.setY(300);
      }
      xform.apply(p0);
      xform.apply(p1);
      odb::Point shift(p1.x() - p0.x(), p1.y() - p0.y());
      pt.setX(pt.x() + shift.x());
      pt.setY(pt.y() + shift.y());
      ap->setPoint(pt);
    }
  }

[github-actions]

Welcome to OpenROAD! Thanks for opening your first PR.
Before we review:

• Contribution Guide: https://openroad.readthedocs.io/en/latest/contrib/contributing.html
• Build Instructions: https://openroad.readthedocs.io/en/latest/contrib/BuildWithCMake.html

Please ensure:

• CI passes
• Code is properly formatted
• Tests are included where applicable
  A maintainer will review shortly!

[QuantamHD]

We do not allow technology specific rules like this. Could we make the pin access aware of the drc violation on m2/m3 instead?

[gadfort]

@Talha-Dmr I think the test case might be good to have, this fix is still very macro specific and not all techs have a 1000 DBU. This seems like a point solution instead of addressing whatever the missing checks are in DRT to correctly handle this without the 300 magic number