Macro placement and macro rotation by 90 degrees

[oharboe]

Description

For megaboom we can create mock sram macros and register files that have the pins on the sides or on top/bottom. However, macro placement can not rotate the macro 90 degrees, only mirror about the x and y axis.

The register files are large and they are very influential on the macro placement and they have purposely been created with pins on the top and left edges thinking that this gives some assymetry that macro placement can use to improve placement.

Being able to rotate the macro 90 degrees would double the number of orientations that macro placement has available to it, but the developer has to pick which edge to put pins on vertical or horizontal edge.

Suggested Solution

Can macro placement be extended such that alternatives for macros can be provided? The thinking is that these alternatives are identical, except for pin location and dimensions.

Something like ADDITIONAL_LIBS=foo1.lib,foo2.lib,foo3.lib bar.lib,bar2.lib

Macro placement would then pick which version to use or at least create a report on which macro versions would have been best.

Additional Context

No response

[gadfort]

One possible solution would be to allow the user to define "equivalent" macros (like "equivalent" stdcells) in the database and then the tools can just swap the masters as needed.

[oharboe]

I could try all the combinations in bazel-orfs for the biggest macros, but for, say two register files that is 4 full builds of megaboom, if I cheat and skip resynthesis and measure WNS after CTS, I think I could try 1 combination in 4 hours. So I could check 2 macros in 16 hours.

Is there a way to tell after macro_place how good the result is?

Of course, in megaboom there are 10s of macros, so 2^30 combinations or so....

[stefanottili]

I wouldn't worry about r90.

I've never seen any ram/rom with r90 since the 2000's ...
rx, ry mirror only and the input/output pins usually were on opposing sides.

There were a few aspect ratio options depending on the internal muxing, but no rotation.

[oharboe]

r90 is not my intention to suggest, but the macro placer could have multiple versions of a macro to choose from, such as a register file with pins on vertical or horizontal edge.

an example is megaboom where there are two large registerfiles and having this freedom can be useful.

simlarly for l1 dcache rams: I am looking for information from the macro placer which orientation/aspect is best.

[rovinski]

FWIW I don't know of any RAM compilers that give you a choice of which side to put pins on. Whatever they give you is what you get.

[oharboe]

Understood: the use case is registerfiles, often implemented as flip flops because of the large number of ports(a defining feature of sram is that it is dominated by storage bits and hence few ports).

Also, megaboom as modeled in the OpenROAD project excludes the complication handled by barstools: matching srams to the actual RTL behavior. The banks of SRAMs will have pins on vertical or horizontal side. So this feature is somewhat useful in approximating what would happen with barstools.

Also, non sram macros(multiplier) would be able to choose edge to put pins on.

[rovinski]

RAM compilers is inclusive of SRAM, RF, or ROM. Commercial RF compilers use a latch-based design which cuts area in roughly half of pure flip-flop-based designs. All of the above typically only give you pins on one side.

Providing a user macro like a multiplier with multiple implementations seems very unconventional, and would require a lot more support than just from from the placer.

[oharboe]

I think a good next step would be to demonstrate that a lot of performance is left on the table. The macro placer has some nice bugfixes coming up that will make various exploration much easier.

I can prototype this easily with megaboom.

[oharboe]

@AcKoucher Reopening now that I have evidence from a use-case that this should have a non-trivial effect on global route.

In #6197, I think megaboom has examples seen with RUDY that clearly show that rotating macros would have been useful:

If these macros had had their pins on the bottom edge instead of left, then these could have been a bank of branch predictor meta data at the top of the design where there is free space:

[oharboe]

One possible solution would be to allow the user to define "equivalent" macros (like "equivalent" stdcells) in the database and then the tools can just swap the masters as needed.

I think a report needs to be created without "equivalent macros". Otherwise there is nothing to motivate the user to provide alternative macros, which will reduce the potential userbase of this feature to effectively zero.

The report should show the alternative macro layout if the orientation could be chosen more freely. The report might take the form of the output format of write_macro_placement, but where illegal orientations are used.

The user could then run make gui_2_2_floorplan_io.odb and source reports/.../alternative_macros.tcl to examine the floorplan. OpenROAD would need to support the illegal rotations sufficiently that the macros can be displayed.

Though... At what point in the flow would such illegal orientations create problems? Only at detailed route?

If the problems in the flow only appear in detailed route, then an alternative implementation would be to add an ORFS RTLMP_EXPLORE_ORIENTATION=1 where the flow continues with illegal orientations. Once the user has finished exploration, they can go through the effort to provide the macro alternatives and set RTLMP_EXPLORE_ORIENTATION=0.

Running an experiment with macros rotated 90 degrees to see what that does... The-OpenROAD-Project/megaboom#209

[AcKoucher]

In #6197, I think megaboom has examples seen with RUDY that clearly show that rotating macros would have been useful

Useful with regards to congestion? WL? Timing? Apparently GPL didn't place std cells near that macro as the higher density concentrates in the middle. Both btb.meta_0_ext and btb.meta_1_ext actually sit in a somewhat "free" space with respect to global placement. Unless the congestion happens as a result of blocking the macros "behind" them, i.e., closer to the upper right corner.

I think a report needs to be created without "equivalent macros".

Are you suggesting that we output two results, one with the "optional" orientations for the macros and other and it currently is? We'd literally run twice as internal hierarchical levels depend on the external ones.

OpenROAD would need to support the illegal rotations sufficiently that the macros can be displayed.

The 90 degrees rotation are not illegal, but the router will struggle to route those, because the pins are directional and not using the preferred direction can be very challenging for the router.

If these macros had had their pins on the bottom edge instead of left, then these could have been a bank of branch predictor meta data at the top of the design where there is free space

If we look at this macro individually that surely makes sense. But how about situations in which this macro gets grouped with other similar macros during macro placement (Btw this is exactly what happens to this macro)? It doesn't seem trivial to say that allowing a right angle rotation will solve any problem.