Drt gc eol fixed

[openroad-robot]

No description provided.

[osamahammad21]

Checking for same pin is ok for me.
Regarding checking fixed shapes, this was supposed to be handled by hasRoute, when hasRoute is false, it indicates that neither the edge or ptr are route shapes. However, the implementation has a silly logical bug. hasRoute is the same for all edges queried in checkMetalEndOfLine_eol_hasEol. So when it turns true for one edge in an iteration in the for loop, it's true for all next edges in the for loop even if the edges are fixed.
Anyways I find the hasRoute technique complicated and I don't really understand why not just check if edges are fixed.

[maliberty]

@osamahammad21 what is the "silly logical bug"?

[osamahammad21]

@maliberty
In checkMetalEndOfLine_eol_hasEol, assume hasRoute=false passed to the function. Then we query the surrounding edges. Assume they are 2 edges. The first edge is routed and the second is fixed. in the first iteration in the for loop, hasRoute will change to true because the edge is routed. In the second iteration, where the edge is fixed, hasRoute is still true although both edges are fixed. That's why you got the weird violation between two blockages I guess.
I am not sure if that explains my idea.
I think we should either remove hasRoute and keep your changes, or we fix the hasRoute part. both would be redundant.

[maliberty]

@osamahammad21 I see your point. I'm going to merge this PR so it unblocks my other work and I'll start a new PR to resolve your point. This passes secure-CI.