Support partial automatic macro placement

[oharboe]

Description

The thinking is: in megaboom, there are two giant macros, the integer and floating point register files, that are best placed manually as their pin orientation and position is what is needed to be locked down first as a constraint to finding a viable macro placement. The smaller macros for megaboom are placed fine by automatic placement.

untar partial-automatic-macro-placement.tar.gz

$ ./run-me-aes-block-asap7-base.sh
OpenROAD v2.0-16688-g86a2cb529 
Features included (+) or not (-): +Charts +GPU +GUI +Python
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
source macros.tcl
[INFO MPL-0035] Macro u0/r0 placed. Bounding box (124.176um, 7.157um), (133.411um, 16.392um). Orientation MX
[INFO MPL-0035] Macro u0/u0 placed. Bounding box (7.008um, 7.152um), (23.579um, 23.723um). Orientation R0
[INFO MPL-0035] Macro u0/u1 placed. Bounding box (7.008um, 33.696um), (23.579um, 50.267um). Orientation R0
[INFO MPL-0035] Macro u0/u2 placed. Bounding box (33.600um, 7.152um), (50.171um, 23.723um). Orientation R0
[INFO MPL-0035] Macro u0/u3 placed. Bounding box (155.101um, 7.152um), (171.672um, 23.723um). Orientation MY
[INFO MPL-0035] Macro us00 placed. Bounding box (7.008um, 61.632um), (23.579um, 78.203um). Orientation R0
[INFO MPL-0035] Macro us01 placed. Bounding box (87.085um, 155.005um), (103.656um, 171.576um). Orientation R180
[INFO MPL-0035] Macro us02 placed. Bounding box (33.936um, 155.005um), (50.507um, 171.576um). Orientation MX
rtl_macro_placer -halo_width 5 -halo_height 5 -report_directory ./objects/asap7/aes-block/base/rtlmp -target_util 0.65
Floorplan Outline: (0.0, 0.0) (178.724, 178.724),  Core Outline: (2.052, 2.16) (176.688, 176.58)
    Number of std cell instances: 4377
    Area of std cell instances: 531.75
    Number of macros: 21
    Area of macros: 5577.25
    Halo width: 5.00
    Halo height: 5.00
    Area of macros with halos: 9178.23
    Area of std cell instances + Area of macros: 6109.00
    Core area: 30460.01
    Design Utilization: 0.20
    Core Utilization: 0.02
    Manufacturing Grid: 1

[ERROR ODB-0360] Attempt to change the orientation of LOCKED instance u0/r0
Error: macros.tcl, 18 ODB-0360
openroad> 

Suggested Solution

Support partial automatic macro placement

Additional Context

If support is added, I'll update https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2516

[AcKoucher]

@oharboe I had a discussion with @maliberty and, before actually digging into the implementation of partial placement, our idea is to allow the already existing mpl2 guidance mechanism to be used. We support it internally, but there's no .tcl API to actually used it.

Basically we'd let the user specify a certain region in which the macro must be placed in order to guide the automated placement. I think that can help solving the issue.

Having a mechanism capable of incorporating the data of a placed macro into the floor-plan packing during SA would be challenging to implement. It'd be a bigger project.

[oharboe]

@oharboe I had a discussion with @maliberty and, before actually digging into the implementation of partial placement, our idea is to allow the already existing mpl2 guidance mechanism to be used. We support it internally, but there's no .tcl API to actually used it.

Basically we'd let the user specify a certain region in which the macro must be placed in order to guide the automated placement. I think that can help solving the issue.

Having a mechanism capable of incorporating the data of a placed macro into the floor-plan packing during SA would be challenging to implement. It'd be a bigger project.

Specifying regions sounds like a better feature. For megaboom, I could specify that integer register file with pins on horizontal edge is placed near the center top of the design and that the floating point register file with pins on vertical edge is placed near middle of the left edge, for instance.

However, how small can these regions be? A single location? What should the user expect if he chooses a region that is effectively a single location? Just curious if this is supported and how it is handled.

[AcKoucher]

However, how small can these regions be? A single location? What should the user expect if he chooses a region that is effectively a single location? Just curious if this is supported and how it is handled.

We'll try to align the center of the macro with the center of the specified region. With regards to how small it could be, I don't see a reason to have a lower limit. However, I think that using a single location would be less practical - and a bit more odd - than just specifying a rectangle that covers a somewhat interesting region for the macro. That's just my opinion though.

Note: I'm interpreting a single location as a region made of a single point: ( x1 , y1 ), ( x2 , y2 ) where x1 = x2 and y1 = y2.

[oharboe]

In terms of surprises and expectations, I think I would find it less surprising if I could specify a rectangle in which the macro must be placed.

I can read trivially these numbers out of the GUI using the mouse to position and note the coordinates.

I would have to do quite a bit of math to figure out the rectangle in which the center of the macro should be.

BTW what happens if I want to have multiple macros inside a rectangle? (a bank of sram macros).

This would be very confusing and a meticulous thing to articulate for each macro defining the area in which the center should be.

Defining areas in which macros must reside seems much better, easier.

[AcKoucher]

BTW what happens if I want to have multiple macros inside a rectangle? (a bank of sram macros).

You could set the same region for all these macros (in this case the region would cover the area of all the macros). However, there's no guarantee that annealing will find the perfect desired position. The macros will be guided to that area during the convergence process.

I think it will be clearer when testing.

[AcKoucher]

Created #6200 for the guidance regions. I finished the first initial version and found bugs in the original code when testing. @joaomai is taking over the debugging part.