validate post GRT WNS opto

[openroad-ci]

Timing benefits on private PDK designs seem quite significant.

Runtime impact seems small for hercules_is_int:
Base runtime (verific): 582 sec
Test runtime (verific): 575 sec

[gemini-code-assist]

Code Review

This pull request introduces a new optimization step, controlled by the OPT_POST_GRT_WNS variable, to optimize worst negative slack (WNS) after global routing using VT swapping and wire rerouting. Feedback on these changes highlights a redundant detailed placement and global routing run that occurs when this optimization is enabled, and recommends propagating the MATCH_CELL_FOOTPRINT and SETUP_SLACK_MARGIN parameters to the repair_timing command to ensure user configurations are respected.

[precisionmoon]

@jhkim-pii, @jfgava, FYI.

[jfgava]

If the focus is just on WNS, we can try different phases, such as the "WNS" policy (-phases "WNS"). The problem is that it will focus only on the most critical path. If it can't be optimized, the run ends. There is no optimization on the secondary paths (no TNS gains).
But maybe it is worth trying. I think the objective here is to go a bit further on QoR, using optimizations that don't disturb placement and routing.
What are your thoughts? @jhkim-pii

[jhkim-pii]

I agree that focusing on WNS rather than TNS is required to minimize the PNR impact.
But @precisionmoon said that WNS policy does not work well unfortunately.

I also investigate how to fix the post-route timing violations effectively.
I am trying to insert buffers more precisely to avoid causing additional displacement impact or routing detour for nets w/ large delay.