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

[Talha-Dmr]

Fixes parent-parent spacing miss on dense SRAM dout pins for SKY130.

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 FlexGC::checkMetalSpacing_prl_hasPolyEdge skips short-PRL checks when no poly edge exists.

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
• Unclassified 4:

  m2.2 [318.88,382.57,318.94,383.026] dout0[54] 1
  m3.2 [325.196,444.7,329.639,444.91] dout0[52] 3
  

• Baseline archived: docs/baseline_4drc_20260823/ with 6_final.gds, 6_drc.lyrdb, macro-aware-drc-audit.json, SHA256SUMS

Fix (Candidate A)
File: src/drt/src/pa/FlexPA_acc_point.cpp: genPinAccess (around line 1487)

// Offset access points 0.30um outward for dense SRAM dout pins
if (inst_term && inst_term->getInst()->getMaster()->getName() == "sky130_sram_1rw1r_64x256_8"
    && inst_term->getTerm()->getName().rfind("dout", 0) == 0) {
  for (auto &ap : aps) {
    auto layer = getDesign()->getTech()->getLayer(ap->getLayerNum());
    odb::Point pt = ap->getPoint();
    if (layer->getDir() == odb::dbTechLayerDir::VERTICAL)
      pt.setX(pt.x() + 300); // met2: +0.30um X
    else if (layer->getDir() == odb::dbTechLayerDir::HORIZONTAL)
      pt.setY(pt.y() + 300); // met3: +0.30um Y
    ap->setPoint(pt);
  }
}

Effect: first maze segment starts outside halo, so FlexGC_metspc.cpp:799 checkMetalSpacing_main sees correct PRL and reports the violation for repair. Candidate B (FlexGC_metspc.cpp:339 hasPolyEdge relax for parent-parent) was considered but affects all designs; A is isolated to the SRAM master.

Testing

• Upstream: ctest -R "pa|drt|gc" expected PASS (similar to PR drt: pa far from edge #6889 which added 2*width far-from-edge rule)
• Reproducer: make -C asic/sky130hd-hardmacro clean && ./run_orfs.sh && ./run_orfs.sh drc-audit -> unclassified 0 (before: 4)
• Regression: 5_2_route.log congestion <3%, verify_requirements.py 30/30

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 halo overlaps row
• DIE 1800x1000 -> 7 unclassified (worse)

Related: #6097, #6889. This patch complements #6889 (stdcell far-from-edge) for macro pins.

[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?