Open maliberty opened 1 year ago
I'm not sure that the number of instances makes for a good heuristic in the place where flattening is done currently (at the very beginning of the flow). Is this the script you are currently using to pick what to keep? That seems to be based on the number of gates in the synthesized module. If you want to make the decision based on the size in gates of the design, there isn't really a choice but to synthesize to gate level first and then decide. You might be able to save a little time by selectively flattening the in-memory design at that point and re-running the optimization directly on the fine-grain (and you wouldn't need any modification to flatten or synth for that, if you're using tcl, you could directly add the keep_hierarchy attributes to the design).
Have you experimented a bit with replacing "synth" with its component passes and inserting your selective flattening heuristic in various places to see what the effects on the results are?
Yes that script is what we currently use. The actual value for ungroup_threshold is quite heuristic. I don't think it is worth getting a precise area to just apply an imprecise cutoff. I'm thinking a simpler proxy that is earlier in the flow might be just as good.
Why do you think the number of instances wouldn't make a good heuristic early on?
I haven't tried the experiment you suggest. Are you suggesting that I start without flattening, set the keep_hierarchy attributes mid-way through optimization, then call flattening, and continue the optimization passes (or possibly restart them)?
Yes, that's the experiment I'm thinking of - that's also essentially how the change you're proposing would be implemented, just minus the extra work to get the data into tcl to set the attributes from there, but you already have that part, so that can give us a quick answer to whether it'll get us good results.
I don't really have a reason to think it would be a bad heuristic, my first instinct was just that the number would not correlate well with the area since one arithmetic operator can be very few or a lot of gates, not to mention flatten right now is before even the most basic optimizations like opt_clean
which removes unused cells. I'd at least want to put it after opt_expr
and opt_clean
, but if you can get reasonable results without changing the script beyond setting a flag, that'll be a much easier PR to get merged.
@nakengelhardt is there a better way to get out the area or cell instance count than writing 'stat' to a file and parsing it? Currently we do https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/scripts/synth_hier_report.tcl
Not yet, but we're working on it! #3566 and #3572 will add the ability to return results from commands in tcl mode. stat
is the first supported as it already has a json mode that outputs the data in machine-readable fashion (that's very close to writing it to a file then parsing it, but at least it skips the disk). select
is the obvious next candidate that we should work on making return data.
This idea has an implementation at #4344
Feature Description
In OpenRoad-flow-scripts we use yosys calling synth --flatten. This has worked well but we would like to keep the hierarchy in the final result. If we simply remove --flatten then QOR takes a hit as optimization across module boundaries can't happen.
Therefore we would like to flatten small modules while keeping larger modules to minimize QOR loss while retaining the useful hierarchy information (for display, clustering, UPF, hierarchical SDC, etc.). While the user could do this manually we would like to have an automated default.
The current approach is to run yosys hierarchically, decide what to keep, and re-run with keep_hierarchy settings. This works but requires two full runs which isn't great. I would like to enhance flatten to have some option(s) to control flattening (and perhaps add them to synth).
Would something like "flatten -cell_threshold" make sense?
I'm glad to prepare a PR but I don't want to spend the time if this isn't the right approach and it wouldn't be accepted. Of course I'm glad for someone else to do it too :)