mpl2: IOs abstraction adaptation to ORFS flow - first version (simplified)
Resolve the first top level task in #5669. Close #4867.
Introductory Considerations
- This is the first step of the enhancements to adapt the IOs abstractions inside mpl2 to ORFS flow.
- This first version will not consider the dimensions of the constraints whether they are -exclude constraints or pins' constraint regions.
Goals
- Improve QoR in terms of WL.
- Ease the life of the annealer for some cases (e.g., sky130hd/uW) that require extreme virtual std cell utilization configurations to converge.
- Further steps into switching from old mpl to mpl2 for cases such as sky130hd/chameleon (This will still require clustering work)
Main Changes
Modify IO Clusters
IO clusters that represent bundledIOs created from the pins placed by random PPL are now groups of unplaced IOs with the same constraints based on the following:
-
Individual Pin Constraints:
- If an IO has a constraint region in a certain boundary, it is constrained to that entire boundary.
- If an IO has no constraint region, it is constrained to all boundaries.
-
Global Pins' Constraints (-exclude)
- If a boundary has more than 70% of its extension blocked, it is considered a blocked boundary for IOs.
What Annealing Sees
- WL between a cluster/macro (soft/hard) M and an IO cluster IO is represented as follow:
- If IO represents pins constrained to a certain boundary A, WL is the minimum distance between M's bundled center pin and A.
- If IO represents unconstrained pins, WL is the minimum distance between M's bundled center pin and the closest non-blocked boundary.
Obs: This distance only reduces cost when M is inside the outline.
Collateral Changes
Needed for the Approach to Work
- Add Cluster support to HardMacro so that SA can check if they are IO clusters' fixed terminals.
- Make both Soft/HardMacroSACores have access to the PhisycalHierarchical data where the global constraints are now stored.
- Make fixed terminals that represent IO clusters have the cluster data inside them so that this data is accessible inside SA for both Soft and Hard. I.e., the cluster of a fixed terminal that represents an IO cluster will be != nullptr
Blockages for Pin Access
Generated based on a combination of both global and individual pins' constraints:
- If there are pins constrained to a certain boundary, we'll generate a blockage for that boundary.
- If there are no pins constrained a boundary A but there are pins constrained to all boundaries, A won't have a pin access blockage. (Specially important so that SA has more freedom).
- The depth of the blockage is a combination of the extension of IO clusters and std cell area (this can definitely be further improved to consider the IOs density)
Orientation Improvement
When iterating a net, compute HPWL based on the center of the constraint region for each IO instead of its location.
Debug Mode
- Blocked boundaries are marked with a red X in the center of their extension
- Draw distance to constraint || closest boundary only when the cluster/macro is inside the outline
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
"Lint Tcl code" needs fixing.
If a pin has been manually placed with place_pin (status=FIRM), will this code consider its location rather than its constraint?
@maliberty I edited the description of the PR/Issue to make it clear that this is a simplified version of these enhancements. I also pushed the change regarding the blocked boundaries as discussed (I'll also add a regression for this - it will help testing the debugger as well).
When addressing the review I'll fix the Lint Tcl.
clang-tidy review says "All clean, LGTM! :+1:"
Conflict to resolve
Resolved.
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
Some unit test need fixing:
[2024-11-14T19:15:30.551Z] mpl2
[2024-11-14T19:15:37.996Z] io_constraints1 (tcl) *FAIL*
[2024-11-14T19:15:46.470Z] io_constraints2 (tcl) *FAIL*
It would be good to merge master and do a fresh secure CI as this PR is a bit old
I ran an updated Secure-CI in the weekend and the only concerning thing is a WL degradation in gf180/uartblocks:
gf180 uart-blocks [ERROR] globalroute__antenna_diodes_count fail test: 11.0 <= 10.0 [ERROR] detailedroute__route__wirelength fail test: 23164.0 <= 19722.0
I'll investigate it.
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
The problem with uart-blocks was due to the fact that I wasn't considering the case in which a pin was not constrained to any region in the orientation improvement step. Now we compute WL with a similar technique used in SA: we get the closest point in the closest boundary and merge it's rect in the net_box.
I'm including this in the PR description for documentation.
Before:
After:
Also: While updating the regression tests I found a bug in the pin access blockage creation which was fixed. The same for a bug in graphics.
I'm running a new secure-CI with my latest changes and master.
Secure-CI is fine. There a couple designs that need metrics update.
There a couple designs that need metrics update.
Is there a PR for this?
Is there a PR for this?
I opened #2582. However, a metrics conflict emerged from another PR. I'm re-running Secure-CI to update the metrics correctly.
@AcKoucher what remains to merge this?
@maliberty This PR is blocked by a gpl divergence in uW (See #6235).
I resolved the conflicts here.
With the updates from master, GPL no longer diverges in uW. However, now GRT is throwing an error due to high congestion in post-drt. I'm investigating.
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
Updating..
I ran a new Secure-CI with a custom GRT routing layer adjustment and it solved uW's congestion problem. However, now g12/ca53 is failing in DPL.
Edit: The failure happens at CTS legalization. It looks like the clock gaters enhancement in #6134 added a very large number of buffers and put the design in the limit of having a legalization problem - the changes here unluckily triggered it. @arthurjolo is investigating.
clang-tidy review says "All clean, LGTM! :+1:"
clang-tidy review says "All clean, LGTM! :+1:"
Settings changes and metrics update in #2706