Improve quality of results of MegaBoom design

[oharboe]

Description

After learning more about Chipyard+MegaBoom and how it is built with commercial tools.

Here is the order to things to improve quality of results best as I know:

1. Build BoomTile with set_clock_latency roughly equal to average clock insertion latency. Single clock.
2. Set synchronous reset to false path, for now.
3. Flatten BoomTile and get macro placement to do a decent job without hierarchical analysis, will certainly require macro placement constraints file. Syntax TBD.
4. Build L2 cache(InclusiveCache) as a macro in the same way as BoomTile, with source latency.
5. Update clock tree synthesis to take macro insertion latency into account
6. Build ChipTop flattened.
7. Yosys / OpenROAD will need register retiming and cloning as the Chipyard MegaBoom design depends on it. Commercial tools get to 1000ps clock period on 28nm. As of writing, clock period_min = 6579.57

Other:

1. Improve running times of global route. OpenSTA speedups or algorithmic speedups?
2. There are some DRC errors.
3. Improve running times of SYNTH_HIERARCHICAL. Switch metrics from area to something else that's good enough to determine which modules should be flattened or not, so as to get a single synthesis pass.

There is an asynchronous FIFO crossing between BoomTile and L2, which both connects to a system bus. With this asynchronous FIFO, the skew of the clock tree insertion latency of BoomTile and L2 won't matter w.r.t. the ChipTop pins. I tried and failed to find a macro that had this asynchronous FIFO inside of it. It turns out that TilePRCIDomain, if configured with an asynchronous FIFO crossing, only has one half of the FIFO; the ChipTop design really has to be flattened the way that RTL is structured.

Some screenshots from bazelisk build BoomTile_route BoomTile_route_orfs and bazel-bin/logs/asap7/BoomTile/base/route.sh gui_route:

1500um x 1500um

Suggested Solution

Keep improving OpenROAD

Additional Context

No response

[oharboe]

@rovinski @tspyrou @maliberty @louiic @precisionmoon I thought it was useful to write up a feature request that gives some context to the individual improvements in the pipeline.

[maliberty]

Other than the items that are already open I'm not clear what you are requesting. Retiming is a large task and would be a yosys task so you would have to get their interest in it.

[oharboe]

Other than the items that are already open I'm not clear what you are requesting. Retiming is a large task and would be a yosys task so you would have to get their interest in it.

There is no request here, but I thought it would be useful to have a public writeup that ties together why these individual improvements are requested.