Observations MegaBoom including L2 DigitalTop module

[oharboe]

(I'm going to edit this post with some more detail and corrections as I gather it, the build is long running and I usually get some feedback from colleagues...)

Some observations when building the DigitalTop module from https://github.com/The-OpenROAD-Project/megaboom, which includes L2 and more. #1710 I plotted only up to and including the BoomTile module.

The results are for The-OpenROAD-Project/megaboom@bd036b2

Log                       Elapsed seconds
2_1_floorplan                    248
2_2_floorplan_io                   7
No elapsed time found in bazel-bin/logs/asap7/DigitalTop/base/2_3_floorplan_tdms.log
2_4_floorplan_macro             2379
2_5_floorplan_tapcell            488
2_6_floorplan_pdn               2120
3_1_place_gp_skip_io             418
3_2_place_iop                     15
3_3_place_gp                    6394
3_4_place_resized               1444
3_5_place_dp                     998
4_1_cts                         2525
5_1_grt                         2971
5_2_fillcell                      56
5_3_route                      33842
6_1_merge                        202
6_report                        2842
generate_abstract                613
Total                          57562

Some noteworthy recent improvements in OpenROAD

Since #1710:

• 2_1_floorplan used to spend an hour or so in remove_buffers
• 2_4_floorplan_macro is has much more conscise output
• 4_1_cts has much more concise output

Building use Bazel and Google Cloud Artifacts

• I discovered that I can only create a .json authentication file to pass to .bazelrc from a Google Service service account, so create a google service account that is owned by your google account and add it to the google storage bucket.

Set up a .bazelrc file in the megaboom folder as follows:

build --remote_cache=https://storage.googleapis.com/megaboom-bazel-artifacts --google_credentials=<path>/innate-diode-408109-9c5d0543f9b3.json --experimental_remote_cache_compression=true

Running times

• PDN and macro placement take almost the same time here, ca. 20% if counting time up to and including CTS.
• Global placement placement takes quite a bit of time.... There has been some discussions about make global placement use multithreading, as I recall.

Mocking hard macros

• mock SRAMs are created by running SRAM behavioral verilog through floorplan, then creating an abstract. The utilization is set to 200-400% to reduce the area of these SRAMs. Timing is of course horrible, but the plan is to use derating once it works to try to create mock SRAMs with some more reasonable timing and area: write_timing_model doesn't consider set_timing_derate OpenROAD#4359.
• An idea is to to similarly create mock hard macros for multiplication, barrel shifters, floating point operations, etc. For these modules I would expect some special effort would be made if there was enough resources available for a commercial product. Alternatively, https://github.com/antonblanchard/vlsiffra could be used to create multipliers, but that would be more work than to simply mock these modules.
• The pins on these macros are all on the left side, which makes these mock macros less symmetric. Less symmetric macors is a good though, because it allows mpl2 to try different rotations of the macros. If the macros are symmetric, then rotating/mirroring macros won't change macro placement quality.

Synthesis

• 1229956 instances
• There are a lot of logic that probably should be hardened as small SRAMs, so the instance count is probably misleadingly high.

Floorplan

• hundreds of small macros to be place, not counting the macros inside the icache and dcache, which mpl2 is able to do
• manually placing these macros, especially given long turnaround times for flows, would be a lot of work. What has been discussed is to add placement constraints a la io pin constraints that would help mpl2 place the macros better.
• I didn't try to optimize area, only to reduce area to rein in running times a bit.

CTS

Something is wrong with CTS, the same problem appears at floorplan...

>>> report_clock_min_period
clock period_min = 0.00 fmax = inf
clock_vir period_min = 0.00 fmax = inf
>>> report_clock_properties
Clock                   Period          Waveform
----------------------------------------------------
clock                  8500.00        0.00   4250.00
clock_vir              8500.00        0.00   4250.00

Aha... There is more than one clock in this design. The name gives it away, but also the very large fanout of this signal...

Three clocks total from reading the design:

https://github.com/The-OpenROAD-Project/megaboom/blob/bd036b21c9217355c31a34a2a2ef41c049586a91/rtl/DigitalTop.sv#L13

So... the constraints-top.sdc needs to be adjusted to accomodate the three clocks...

Route

• Global and detailed routing is reasonably fast, I suppose. Routing is done after 9 iterations there's only 1 DRC left that detailed routing could not sort out: Failed to fix all DRC errors in detailed routing OpenROAD#4426

Report

• Slow, even if power is not reported: https://github.com/The-OpenROAD-Project/megaboom/blob/bd036b21c9217355c31a34a2a2ef41c049586a91/openroad.bzl#L79

Next steps

• An updated constraints file is needed for top level that includes all three clocks. The clues in Chipyard example design are a bit limited and apply to RocketTile(a smaller prior generation of MegaBoom), not MegaBoom: https://github.com/ucb-bar/chipyard/blob/32f79a82bbf67745660eae14678173692ed6e0d8/vlsi/example-designs/sky130-openroad.yml#L6
• Break out L2 as a macro to speed up top level design and study L2 separately: InclusiveCache: added a target, useful for testing megaboom#5

[maliberty]

Thanks for the update. It looks like we need a CTS test case.

The heatmap obscures the hierarchy display in your image.

[oharboe]

Coming up... The same problem exists after floorplan.tcl: The-OpenROAD-Project/OpenROAD#4425