efabless
Optimize Global Routing and Resizer PostGRT steps
Description
As it turns out estimating routing parasitics in OR needs a call for GRT in the same script (it cannot load all the info from the db). Some steps in the Classic flow use this. At the moment there are a lot of redundant GRT calls that slows down the flow in large designs.
Proposal
Access and revisit the situation. Additionally, GRT_RESIZER_RUN_GRT should only disable the final GRT step in the script. Finally, we should access incremental routing as well.
Wasn't this addressed in https://github.com/efabless/openlane2/commit/a8a6e84d4970c94641f2be62c8bc709ca353ed59
Wasn't this addressed in a8a6e84
No. The solution is not complete and wrong given the current state of OR db.
The solution doesn't consider other places in the flow that uses GRT parasitics estimation. It doesn't consider that there is a redundant GRT run before OpenROAD.RepairDesignPostGRT for example.
It is wrong because it turns out that GRT is needed in the same script as the ones modified in the PR. A similar PR should only disable GRT ran after calling resizer.
If this is a Classic flow issue, not a step issue, that's a separate discussion. For the giant designs in question our PnR engineers tend to define custom sequential flows in the JSON…