GRT: Bad GRT guides results in DRT break

[osamahammad21]

Describe the bug

#5637 triggered an issue in DRT that originates in GRT guides. GRT chooses to create a 2-gcells route segment on Metal1 for net clknet_4_6_0_clk to access pin clkbuf_4_6_0_clk/Z. It makes more sense if GRT chooses one gcell to access the pin. The available tracks on Metal1 should be 0 in that area.

Expected Behavior

GRT accesses the pin using 1 gcell only on Metal1

Environment

refer to https://github.com/The-OpenROAD-Project/OpenROAD/issues/5637

To Reproduce

refer to #5637

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[eder-matheus]

You are right. Even if we allow Metal1 routing (as in this design), all tracks are completely obstructed by the instance pins and obstructions. I will see what's wrong in GRT. Probably I'm not iterating over a list of obstructions.

[maliberty]

My guess is that since the AP is on the border that confuses grt as well about which gcell the ap is in.

[eder-matheus]

My guess is that since the AP is on the border that confuses grt as well about which gcell the ap is in.

I think the problem is simpler than that. GRT understands that the pin is on the gcell shown in the picture. However, when I look at the resources available at Metal1 in this gcell, it shows much more than I would expect (9 tracks of 15, while I would expect at most 3 tracks available). Since ew allow Metal1 routing in this design, it decided to create the segment in Metal1.

I need to understand why it is not computing the resources properly.

[maliberty]

I would expect 0 - why 3?

[osamahammad21]

@eder-matheus Any update on this?

[eder-matheus]

@eder-matheus Any update on this?

I'm trying to solve congestion issues in 3 designs of the public CI. I believe we are having problem with pin access in GRT that is causing the congestion, because the values are large.