gpl: cover bterms after callbacks processing

[gudeh]

Callback modifications introduce pointer invalidation to gpl c++ vectors, these invalidations are addressed with NesterovBaseCommon::fixPointers() which restores references to vector elements. However, it was missing logic to account for dbBTerm objects. As a result, instances connected to bTerms ended up with invalid pin values.

The observed effect was that instances connected to bTerms (such as TIE cells with a single pin) had no influence on HPWL and moved solely based on the density gradient, drifting away from their associated bTerm connection.

The issue was resolved with the current branch by including the bTerms loop.

I ran a test-CI at test-gpl-callback-cover-bterms and we are currently having a GRT failure during 5_2 with sky130hd/microwatt:

[INFO DRT-0267] cpu time = 06:54:19, elapsed time = 00:31:01, memory = 4095.61 (MB), peak = 5047.65 (MB)
[INFO DRT-0180] Post processing.
Took 1984 seconds: detailed_route -output_drc ./reports/ihp-sg13g2/jpeg/base/5_route_drc.rpt -output_maze ./results/ihp-sg13g2/jpeg/base/maze.log -bottom_routing_layer Metal2 -top_routing_layer Metal5 -droute_end_iter 64 -verbose 1 -drc_report_iter_step 5
[INFO GRT-0012] Found 59 antenna violations.
[INFO GRT-0015] Inserted 105 diodes.
[ERROR GRT-0232] Routing congestion too high. Check the congestion heatmap in the GUI.

[gudeh]

@jeffng-or FYI, you mentioned this issue today I believe.

[github-actions]

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

[github-actions]

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

[github-actions]

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

[github-actions]

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

[gudeh]

I just triggered the updateRules in the ORFS PR for metrics: The-OpenROAD-Project/OpenROAD-flow-scripts#3293

OR CI here has an error for bazel.

[eder-matheus]

Overall it looks good, but I wonder if the debugPrints in else statements should be turned into an error message or not. Is there any scenario where the gPins wouldn't be neither a bterm or iterm?

[gudeh]

Overall it looks good, but I wonder if the debugPrints in else statements should be turned into an error message or not. Is there any scenario where the gPins wouldn't be neither a bterm or iterm?

It would not be expected. I just left it to be sure. The callbacks from set_debug_level has other similar checks like this, only for checking unexpected things.