mpl: IOs abstraction adaptation to ORFS flow - second version (enhanced)

[AcKoucher]

Resolve #5669

Introductory Considerations

• This is the second and final step of the enhancements to adapt the IOs abstraction inside MPL to ORFS flow.
• Differently from the first version, in which we made simplifications w.r.t. dimensions of the constraints, this second version considers the actual dimensions of the constraints regions for pins, whether they are -exclude constraints or pins' constraints.

Goals

1. Further improve QoR in terms of WL.
2. Improve accuracy of the locations that can be occupied by macros w.r.t. pin access.

Main Changes

Modify Shapes of Clusters of Unplaced IO Pins

Instead of virtually constraining IOs to the edges of the die area, we now use the actual constraint region that comes from ODB. This results in:

• A cluster of unplaced IOs have now the dimensions of the constraint region to which those pins are constrained to. I.e., pins are constrained to regions instead of boundaries.
• The cluster of unplaced IOs without any constraint is a special case. The pins are constrained to all available regions for pins i.e., the regions that are not blocked. The shape of this cluster is the die area itself.

As we create these clusters, we populate a map that links them with their respective BoundaryRegion (the new object in MPL's framework to help handling constraint regions - for constrained pins' clusters - & available regions - for the unconstrained pins' cluster - inside SA and during orientation improvement).

Computation of Available Regions For Pins

When there are no constrained pins, but there are -exclude constraints set by the user, we use the blocked regions for pins which are stored in ODB to compute a list of available regions for pins (this is made by doing regions' subtraction across the edges of the die area, see HierRTLMP::computeAvailableRegions).

Pin Access

The alternatives for pin access blockages' generation are still the same as the first version. However, we now use the dimensions of constraint regions:

• If there are constrained pins, we create blockages for the respective constraint regions.
• If there are no constrained pins, but there are -exclude constraints set by the user, we use the available regions for pins to create the pin access blockages.
• If there are no constraints at all - neither pins' constraints or -exclude constraints - we don't create pin access blockages to give more freedom to SA.

The depth now is limited by the dimensions of the die area. A horizontal blockage will have at max 20% of the die width; a vertical blockage will have at max 20% of the die height.

There is one important difference w.r.t the first version: We now consider the density of IOs when computing the depth of the blockages for constrained pins. Denser regions are deeper, i.e., have thicker blockages.

Cluster / Macro Placement (SA)

In the first version of the new IOs, WL was computed based on distance to the edges:

• In the case of a cluster for constrained pins, the distance to its specific edge of constraint;
• In the case of the cluster of unconstrained pins, the distance to the closest unblocked boundary.

Now, as the clusters of unplaced IOs are constrained to actual regions, we compute WL as:

• In the case of a cluster of constrained pins, we compute the distance from the macro bundled pin to the nearest point inside the constraint region.
• In the case of the cluster of unconstrained pins, we compute the distance from the macro bundled to the nearest point of the nearest available region for pins.

Obs: When initializing the SA Core, we create a cache of these regions offset w.r.t. current outline.
Obs2: The new WL computation is made in DBU, so the annealer needs a dbBlock* in order to allow us to perform unit conversion.

Boundary Pushing

As we now store the pin access blockages in a vector instead of a map Boundary -> Blockage, because we don't need the boundary data anymore, the Pusher receives this vector and, when working, computes overlap iterating the blockages of this vector.

Orientation Improvement

When computing HPWL for a certain orientation and iterating bterms of a net:

• If the pin is constrained to a region, use the nearest point of this region.
• If the pin is not constrained to any region, use the nearest point of the nearest available region for pins.

[github-actions]

clang-tidy made some suggestions

[maliberty]

Nice description!

[github-actions]

clang-tidy made some suggestions

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[AcKoucher]

I adapted the implementation to avoid using the center of regions when computing WL and these changes are ready for a first round of review. I also updated the description accordingly so it should give a reasonable explanation of what is going on.

[maliberty]

secure CI?

[AcKoucher]

secure CI?

Running.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[AcKoucher]

Running new Secure-CI.

[AcKoucher]

As I was addressing the last comment of the review I found a bug which is now fixed. I'm running a new Secure-CI.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[eder-matheus]

Waiting on secure-CI to merge.

[AcKoucher]

Secure-CI had some failures which are addressed in #3175.

[eder-matheus]

I can't merge the PR without @maliberty's approval.

[maliberty]

I've approved and will look more closely tomorrow's