[phsauter]

Summary

Extends pin access generation to find more viable access points aligned with the preferred upper-layer tracks. It preserves preexisting candidates and via alternatives and just expands on it using an expanded NearbyGrid search when too few access points are found so far.

Type of Change

• New feature

Impact

Pin access should be able to find more access points especially for pins with few APs before. It still retains and uses the other candidates so I would not expect any impact for most simpler pins.

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.
• I have included tests to prevent regressions.
• I have signed my commits (DCO).

[github-actions]

This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size.

[gemini-code-assist]

Code Review

This pull request introduces a new via access search algorithm (ViaAccessSearch) in FlexPA to generate via access points for standard cell pins, along with associated unit tests. The review feedback suggests adding an underflow check for track coordinates on layers to prevent potential out-of-bounds values, and adding a defensive null check for pin_access in revertAccessPoints to avoid a potential null pointer dereference.

[gemini-code-assist]

The current check only validates if the last track coordinate exceeds the maximum limit. However, the track coordinates can also underflow the minimum limit of frCoord (e.g., if start is extremely negative). To ensure complete robustness, we should check both the start and last coordinates against the minimum and maximum limits of frCoord.

    if (count != 0) {
      const int64_t last = start + (count - 1) * spacing;
      if (start < std::numeric_limits<frCoord>::min()
          || last > std::numeric_limits<frCoord>::max()) {
        logger_->error(DRT,
                       kMsgIdPinAccessCoordinateDomain,
                       "Track coordinates on layer {} are outside "
                       "the native coordinate range.",
                       layer_num);
      }
    }

[phsauter]

start is already of type frCoord and spacing is unsigned, so coords cannot fall below its minimum. Only an overflow is possible, which the existing check covers.

[gemini-code-assist]

If pin_access is null (e.g., if pin access generation failed or was skipped for this pin), dereferencing it with pin_access->getAccessPoints() will cause a null pointer dereference crash. Adding a defensive null check prevents this.

      auto pin_access = pin->getPinAccess(pin_access_idx);
      if (!pin_access) {
        continue;
      }
      for (auto& access_point : pin_access->getAccessPoints()) {

[phsauter]

Initialization allocates an access container for every pin including skipped pins. No APs leave an empty container, generation failures throw before this. So a null check would just mask an initialization bug.

[phsauter]

I had to update metrics to make this pass. I had a look at all of them and to me this does not seem like a failure or problem with this PR but rather just noise from routing.
This is how they change:

Design	Setup timing	Clock skew	Worst slew margin	Worst capacitance margin
AES Sky130 HD	17 ps worse	20 ps worse	+4.91% → −0.68%	+6.65% → −1.05%
Ibex Sky130 HD	29 ps worse	11 ps better	+4.91% → +3.56%	+3.46% → +2.04%
JPEG Sky130 HD	24 ps better	9 ps worse	−1.22% → −1.41%	−3.61% → −2.93%

Setup is fine, clock skew fails for AES and worst slew margin and worst cap fail for all three.
Looking at AES, preferred APs on non-antenna cells remain unchanged. All five actual pin-contact vias on the affected net are also identical. The wire is 0.55% shorter with the same vias, the difference is just a longer parallel run which increases wire cap.