DRT: Add guide-based tiles flow and improve stubborn-tiles iteration control

[openroad-ci]

The changes include:

• Adding a guide-based tiles flow that derives workers from original routing guides intersecting DRC markers.
• Invoking the guide-based flow when the stubborn-tiles flow is skipped due to unchanged search/repair arguments.
• Tracking whether the guide-based flow has been attempted to avoid repeating it in subsequent iterations.
• Modifying iteration skip logic to account for whether the guide-based flow has already run.
• Refactoring worker region handling to operate on coordinate-space rectangles instead of gcell index boxes.
• Simplifying worker batch bounding-box construction and box merging logic.
• Updating iteration logging to report the active flow name explicitly.

This change handle all stubborn violations on gf12 designs.

[gemini-code-assist]

Code Review

This pull request introduces a new guide-based tiles flow to handle stubborn violations, which is a great addition for improving routing quality. The logic for when to invoke this new flow and how to control iteration skipping is well-thought-out. I also appreciate the refactoring to use coordinate-space rectangles, which simplifies the code and improves readability. I have one suggestion to improve the clarity and maintainability of the rectangle merging logic in the new guideTilesFlow function.

[gemini-code-assist]

The nested loop for merging worker rectangles is functionally correct, but its implementation using itr2 = itr1; to restart the inner loop is a non-standard pattern which can be confusing for future maintenance.

A goto statement, while often discouraged, can make the intent of restarting the loop scan much clearer in this specific case. This change improves readability without altering the logic. The inefficiency of std::vector::erase in a loop remains, but this is a separate concern from code clarity.

  for (auto itr1 = workers.begin(); itr1 != workers.end(); ++itr1) {
  restart_inner_loop:
    for (auto itr2 = itr1 + 1; itr2 != workers.end(); ++itr2) {
      if (itr1->getDir() == itr2->getDir() && itr1->intersects(*itr2)) {
        itr1->merge(*itr2);
        workers.erase(itr2);
        goto restart_inner_loop;
      }
    }
  }

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

This change handle all stubborn violations on gf12 designs.

Nice! 🎉

[maliberty]

should this be itr1 or itr1+1 as in the loop initialization?

[osamahammad21]

It should be itr1. Once the loop finishes an iteration and goes back to the for statement, the increment step will advance it to itr1+1.

[maliberty]

I'm a bit unclear if you could get adjacent workers that would depend on each other.

[osamahammad21]

I'm a bit unclear if you could get adjacent workers that would depend on each other.

You could, and probably would. It's handled in getWorkerBatchesBoxes which separates all adjacent workers into separate batches so that batches could run sequentially.