bazel-orfs use-case for fast turnaround times when analyzing large designs

[oharboe]

For large designs that takes many hours to build, I've (re)discovered a number of tricks for bazel-orfs.

Faster synthesis:

• It is the technology mapping(abc) that is slow in synthesis, I use bazel-orfs to do synthesis in parallel on modules that are not flattened
• Some slow to synthesize modules hardly ever change, there I use pinning of the synthesis result so I don't have to re-run synthesis for large modules like multipliers, register files, floating point units, etc.

This takes synthesis down from hours to minutes for something like MegaBoom (ca. 1 million instance CPU).

Hunting for egregious timing problems:

• When hunting for egregious timing issues, it is enough to get a first inaccurate report from synthesis. I view this in the OpenROAD GUI(timing report, end point slack histogram, etc.) using bazelisk run MyModule_synth /tmp/synth gui_synth
• I then find and create github issues for egregious timing paths. Once I have written up an issue, I no longer want to see that problem in the End Point Slack Histogram, so I run a set_false_path *slowmodule* and hit the Update button in the Endpoint Slack Histogram. This takes seconds or a minute or so, rather than waiting for the entire flow to run again. Before I had this trick, I would try to hunt for different kinds of problems in the Endpoint Slack histogram, but I would often have to fix a problem before I could see beyond the first few problems. Now I can see a couple of more issues ahead before things get murky and I need to fix problems and re-run the flow.

Looking for routing/placement problems:

• Next I run bazelisk run MyModule_grt /tmp/grt gui_grt and look for paths that have a large Logic Delay to non-Logic delay ratio. Usually this is a sign that architectural retiming is needed to handle the physical layout of the design to keep up the clock period.
• Again, here the set_false_path *slowmodule* trick shines, because I can see a couple more issues into the future without having to fix one issue at the time and re-run the flow.

Going from post-synthesis RTL to RTL:

• It is hard to go from flattened post-synthesis RTL to your original RTL, unless you keep modules in synthesis(don't flatten them). Unflattened modules have better names. In bazel-orfs it is easy to set up a flow where modules are kept to a greater degree to get better names and visibility in OpenROAD GUI when hunting for issues and another variant of the same build that flattens everything best PPA, separting the concern of getting best possible PPA and maximum visibility and fastest possible turnaround times.

[oharboe]

@benreynwar FYI

[maliberty]

FYI, Google has opened a series of PRs to yosys to parallelize tech-mapping in abc. Once they land we should see a good reduction in runtime based on their experience.

[oharboe]

@maliberty @QuantamHD Pinning

[maliberty]

@rocallahan would your method from YosysHQ/yosys#5266 work on flat designs? I imagine it would but would like you to confirm.

[rocallahan]

I've been working with flows that flatten before techmapping. We get a large speedup on flattened designs from YosysHQ/yosys#5239 and YosysHQ/yosys#5266.

The Yosys techmapping pass partitions cells by (clk, enable, arst, srst) signals and runs ABC on each partition. In our larger circuits that produces hundreds or thousands of partitions and as many ABC runs. Overlapping the ABC runs with each other and the Yosys (single-threaded) processing is very beneficial.

So that may not be directly applicable to the context here, if you're not already splitting modules into multiple ABC runs.

[maliberty]

We are not doing anything special - just whatever yosys would have done without your changes.

[rocallahan]

Then hopefully you'll have a good time!