grt: Implement timing-driven net sorting for incremental CUGR

[Divinesoumyadip]

This PR prioritizes timing-critical nets during the incremental rerouting process. By querying fresh slack data from OpenSTA before rerouting, the tool ensures that nets with the worst negative slack (WNS) get the first choice of routing resources.

In the previous incremental flow, nets were rerouted in an arbitrary order. This often led to non-critical nets occupying the most direct tracks, forcing critical timing paths into long detours. This PR ensures that "VIP" nets (those with negative slack) are handled first to protect chip performance during ECO passes.

I modified CUGR::rerouteNets to refresh timing data before routing.Integrated a loop to querysta_(OpenSTA) for each net's current slack.Utilizes sortNetIndices to re-order the reroute queue so that nets with the most negative slack are at the front.

Reduces timing degradation during ECO passes and improves the overall Timing Quality of Results (QoR) by prioritizing paths that define the chip's maximum clock frequency.

[gemini-code-assist]

Code Review

This pull request introduces timing-driven net sorting for incremental routing in CUGR. The changes in rerouteNets correctly query slack data from OpenSTA and prioritize critical nets. A new helper function, removeRouteUsage, is also added for ripping up individual nets. The implementation is sound and aligns with the goal of improving timing QoR during ECOs. I have one suggestion to merge two loops in rerouteNets for better performance, aligning with principles of optimizing loop structures.

[gemini-code-assist]

For better performance, the loop for ripping up nets and the loop for querying slacks can be merged into a single loop. This avoids iterating over net_indices twice, which can be a significant saving if the number of nets to reroute is large. This aligns with the principle of optimizing loop structures to reduce redundant iterations, similar to how a single-pass approach can be more efficient than a two-pass approach.

  for (const int idx : net_indices) {
    GRNet* gr_net = gr_nets_[idx];
    if (gr_net->getRoutingTree()) {
      grid_graph_->removeTreeUsage(gr_net->getRoutingTree());
    }

    if (sta_ != nullptr) {
      odb::dbNet* db_net = gr_net->getDbNet();
      float slack = getNetSlack(db_net);
      gr_net->setSlack(slack);
    }
  }

  // 3. Sort if timing is available
  if (sta_ != nullptr) {
    // Sort: Most negative slack (critical) nets go FIRST
    sortNetIndices(net_indices);
  }

References

1. When analyzing code within a loop, consider the entire loop structure. Operations at the beginning of the loop can affect the logic within the loop body, potentially making similar calls inside the loop redundant. Also, a single-pass method can be more efficient than a two-pass approach by avoiding processing all items multiple times.

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: out-of-line definition of 'removeRouteUsage' does not match any declaration in 'grt::CUGR' [clang-diagnostic-error]

void CUGR::removeRouteUsage(odb::dbNet* db_net)
           ^

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: no viable conversion from 'value_type' (aka 'std::unique_ptrgrt::GRNet') to 'GRNet *' [clang-diagnostic-error]

    GRNet* gr_net = gr_nets_[idx];
           ^

[eder-matheus]

The idea of the PR is good, but if you look at the patternRoute, patternRouteWithDetours and mazeRoute functions, you'll see that they already call the sortNetIndices internally. So the new process introduced in this PR is redundant.

[eder-matheus]

Where's this function used? I believe the first lines of the rerouteNets function already covers this process.

[eder-matheus]

You don't need this sta_ check (here and below).

[eder-matheus]

This comment seems a bit out of place - where are steps 1. and 2.? Please remove it (and the comment below), the functions are self documented.