Different types of blockages could be treated differently in MPL

[AcKoucher]

The idea here emerged from an offline discussion that I was having with @eder-matheus.

Basically, since #8438, blockages are treated as hard constraints by MPL. Of course that placement blockages require that kind of handling as they're hard constraints set directly by the user. However, after some testing and also observing some of the current master results I think that the virtual pin access blockages generated by MPL could work better as soft constraints i.e., clusters of std cells should be allowed to occupy the area of pin access blockages. The rationale would be that, if the area of pin access is inaccessible for std cell clusters, then there is a clear discrepancy between MPL and GPL behavior, as GPL will definitely be able to use an empty area to place std cells and AFAIU that will rarely generate pin access problems.

The context in which I think this is relevant relates to my tests for #8665. An initial Secure-CI run led ngt45/ariane133 to fail due to literally lack of space even with 100% utilization (note that currently on master we do a bunch of attempts using high utilization values, that's why we're able to converge). There are other ways to deal with this failure for the purpose of merging the utilization re-work branch (such as lowering the halos - there are many macros and the sum of the halos' areas is quite relevant for feasibility), but it's important to notice that, the amount of area covered by the green pin access blockage does play an important role in this failure:

Any thoughts on this?

[maliberty]

The pin access blockage is just to keep macros away from the pins as they tend to block many layers (possibly including the pins' layer). Std cells are not such an issue so it is ok for std cells to occupy that space.

[AcKoucher]

Opened #9226.