place_density_with_lb_addon mechanism should live inside GPL

[AcKoucher]

Description

If we set a high CORE_UTILIZATION along with a high CELL_PAD_IN_SITES_GLOBAL_PLACEMENT, the density lower bound may be higher than 1.0. For such a case we should error and inform the user that in may be required to lower either utilization or padding.

However, as we compute the placement density from the lower bound density using PLACE_DENSITY_LB_ADDON in a helper ORFS script util.tcl, we're obligated to error from the script (FLW messages).

#4486 shows an example of such a case.

Suggested Solution

It looks like all this computation should really happen internally to GPL so that,if we detect that the either the lower bound or the true computed density is "illegal" (>1.0), the error comes from OR and not from a script in ORFS.

[oharboe]

This sounds like a linting type error that shouldn't have to run the flow at all. Perhaps this can be implemented in python with python unit-tests?

It could be hooked up to a "make lint" target that runs checks all variables.

Otherwise it will be an edge case that will never be exercised and as probably dead code in CI in OpenROAD and ORFS because those tests focus on flows and tests cases that should succeed.

[gudeh]

The LB addon calculation uses a special initialization of GPL where we only initiate it to calculate the uniform density. If we calculate the uniform density outside GPL it would not be the exact same as the one calculated by GPL.

We could move the LB addon calculation inside GPL, although it is also used by MPL currently: macro_place_util.tcl:63 → rtl_macro_placer -target_util