PDN creates ring outside of die area

[jeffng-or]

Describe the bug

For some of some of the MegaBoom macros, PDN ends up creating the power ring outside of the die area boundary. As a result, the pins are no longer accessible to the detailed router when we are trying to route BoomTile. The power ring creates an obstruction that doesn't align with the die boundary, which effectively covers the pin shapes:

In this case of btb_128x56, the ring area is ( -72 144 ) ( 47106 25236 ) and the die area is ( 0 0 ) ( 47060 25232 )

It looks like the shapes are created outside of the die area since that the inner ring core is calculated at ( 240 456 ) ( 46794 24924 ) and then adjusted by the horizontal/vertical width calculation. The net effect is that the ring outline gets grown by 624 (x lo shifted left by 312 and x hi shifted right by 312). Since the inner ring core is starting at 240, the resulting x lo for the ring ends up at -72.

Expected Behavior

Either the ring is created within the die boundary or we error out if it isn't possible.

Environment

My local workspace is pointing to:

commit ad1b24dbd83dbaadaf5b5df8effc6c9d643b1421 (HEAD -> master, origin/master, origin/HEAD)
Merge: 0812b358 261a6266
Author: Matt Liberty <[email protected]>
Date:   Mon Dec 23 15:15:32 2024 -0800

    Merge pull request #2620 from The-OpenROAD-Project-staging/secure-yosys0.48
    
    update Yosys to version 0.48

To Reproduce

Test case can be found at

https://drive.google.com/file/d/10UJD8IatCit-IcZ3RZsMG0kk4vgCjEhh/view?usp=drive_link

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[maliberty]

@gadfort are you available to look at this?

[gadfort]

@maliberty I believe this was intentional because openlane was inserting rings outside of the die area and then adjusting their die area. Personally I agree that the tools should not generate shapes outside of the die area and I'm happy to change the behavior to error out (it's easy to detect so should not require much to implement). If we are okay with changing this behavior to be an error, I can do that.

[maliberty]

It feels backwards to get a ring outside and then post-adjust the die area. @donn do you have any concerns about making this an error?

@jeffng-or are you able to modify the pdn setup to avoid this issue?

[donn]

I believe this was before my time, so I'd have to figure out why with the team first. I'll get back to you.

[jeffng-or]

The SRAM flow is using the BLOCK_grid_strategy.tcl directly from the asap7 platforms area, so I'm not sure how much flexibility I have to modify it.

The SRAMs are all generated using the mock area flow in megaboom, so I could look at what needs to be tweaked in order to avoid the issue. Of the fifteen SRAM types in megaboom, nine have this obstruction issue.

@oharboe FYI.

[oharboe]

A surprising behavior....

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[maliberty]

The problem here is the floorplan setup isn't compatible with the pdn setup. In pdn

add_pdn_ring    -grid {top} -layers {M5 M4} -widths {0.12 0.12} -spacings {0.072} -core_offset {0.084}

which means you will need at least .084 + 12 + .072 + .12 = .396 between core and die edge to fit the rings inside. But you only have 0.324

How did you determine the core spacing?

[maliberty]

Most designs in ORFS are using at least 1 micron and so don't have this issue:

aes-block/config.mk:13:export CORE_MARGIN            = 2
aes-mbff/config.mk:13:export CORE_MARGIN              = 2
aes/config.mk:13:export CORE_MARGIN              = 2
aes_lvt/config.mk:13:export CORE_MARGIN            = 2
ethmac/config.mk:11:export CORE_MARGIN            = 2
ethmac_lvt/config.mk:12:export CORE_MARGIN            = 2
gcd/config.mk:9:export CORE_AREA              = 1.08 1.08 15.12 15.12
ibex/config.mk:11:export CORE_MARGIN            = 2
jpeg/config.mk:13:export CORE_MARGIN            = 2
jpeg_lvt/config.mk:22:export CORE_MARGIN            = 2
mock-cpu/config.mk:11:export CORE_MARGIN              = 2
riscv32i/config.mk:23:export CORE_AREA = 5 5 75 85 
swerv_wrapper/config.mk:21:export CORE_AREA   = 5 5 545 595 
uart/config.mk:11:export CORE_AREA              = 1.08 1.08 16 16

[oharboe]

@louiic Made the BLOCK_ and BLOCKS_ .tcl files for mock-array

Later, I have been using them in test designs where there are macros built by OpenROAD and a top level.

[maliberty]

There is nothing wrong with the BLOCK* files - you have to use them intelligently. If you lower the core margin too much you get this problem.

[oharboe]

An actionable error message would be instructive.

[maliberty]

That is pending on Donn's response as to whether they need this behavior.

[donn]

So, we don't know what you mean by the resizing thing, probably a one-off thing in the early days, but what we do know is that we intentionally create PDN rings outside the die area regardless.

This is the XOR template for the power grid for caravel user project: the I/O pins are at the edge of the die area and the rings surround the I/Os.

Should PDNs outside the die area be disallowed, we would have to update a ton of layout files and configuration files so that the PDN goes inside the die area, and the pins are not laid out across the die area boundaries. Additionally, this would allow routes for the pins to be created in the new area, which we do not want to happen, so we'd have to add blockages… The drawbacks keep piling up.

We do understand your concern however, as this IS surprising behavior for 99% of users. We would be okay with updating the default behavior, but with an escape hatch (-allow_outside_die_area or whatever, dealer's choice) to revert to the previous behavior.

[gadfort]

A flag seems like a reasonable idea to me.

[maliberty]

@donn how do you generate LEF abstracts for these blocks? What do they look like? The issue we saw was the obs covering the rings blocks the signal pins on other layers.

[maliberty]

Perhaps it would be better to compute the bounds per layer in write_lef_abstract and leave this as a warning?