synthesis: minimal synthesis to drive MAX_UNGROUP_SIZE policy

[oharboe]

@gadfort @maliberty Thoughts?

This roughly cuts hierarchical synthesis times in half.

[gadfort]

@oharboe what are you attempting to accomplish with this?

[oharboe]

@oharboe what are you attempting to accomplish with this?

The first stage of synthesis takes seconds instead of hours this way...

[gadfort]

Instead of relying on an area estimate (I've been using a instance count instead, which doesn't require a techmap to occur). Running two sets of synthesis is wasteful (I don't think the current setup in ORFS is doing us any favors and this just pushes off fixing it properly)

[oharboe]

Instead of relying on an area estimate (I've been using a instance count instead, which doesn't require a techmap to occur). Running two sets of synthesis is wasteful (I don't think the current setup in ORFS is doing us any favors and this just pushes off fixing it properly)

I'm counting cells instead of area in this PR.

[gadfort]

I see, still without running a techmap it's not clear that you are getting a proper count since $lcu and other complex structures would still be left behind. If your method works properly, I don't see the need for the python script since then you can just have a single synthesis run without the need to invoke yosys twice.

[oharboe]

I see, still without running a techmap it's not clear that you are getting a proper count since $lcu and other complex structures would still be left behind. If your method works properly, I don't see the need for the python script since then you can just have a single synthesis run without the need to invoke yosys twice.

Good point, that would be much nicer.

How do you "use instance count"? Is that in the SiliconCompiler?

[gadfort]

you can see https://github.com/siliconcompiler/siliconcompiler/blob/1122fadb92b4ca5803b7b66f0b071f3185310ffb/siliconcompiler/tools/yosys/syn_asic.tcl#L185
Like @maliberty said this has not been evaluated to make sure it works in all cases, but I suspect it would work for you, except it will take longer than a few seconds since it's doing some extra work along the way.

[oharboe]

you can see https://github.com/siliconcompiler/siliconcompiler/blob/1122fadb92b4ca5803b7b66f0b071f3185310ffb/siliconcompiler/tools/yosys/syn_asic.tcl#L185 Like @maliberty said this has not been evaluated to make sure it works in all cases, but I suspect it would work for you, except it will take longer than a few seconds since it's doing some extra work along the way.

Interesting. How is this .tcl file run? It looks like you running it from tclsh and are importing yosys as a module and restarting synthesis a number of times, so there's some global state kept in the yosys module across "yosys foo" calls.

[gadfort]

it's run via SC, we don't import yosys commands so the tcl script is purely tcl and yosys calls are via the yosys foo (which is how yosys set it up). It runs several trial flattenings to see when the design is no longer "benefits" from flattening. Long term yosys needs a better system which is compiled in since that would give better access to the FFs etc which is really what determines the level of flattening that is possible.

[oharboe]

it's run via SC, we don't import yosys commands so the tcl script is purely tcl and yosys calls are via the yosys foo (which is how yosys set it up). It runs several trial flattenings to see when the design is no longer "benefits" from flattening. Long term yosys needs a better system which is compiled in since that would give better access to the FFs etc which is really what determines the level of flattening that is possible.

Silly question: how is state persisted between invocations of yosys in your .tcl script? In ram? on disk?

[gadfort]

in ram, the call https://github.com/siliconcompiler/siliconcompiler/blob/1122fadb92b4ca5803b7b66f0b071f3185310ffb/siliconcompiler/tools/yosys/syn_asic.tcl#L41
saves the state (that way I can make some speculative changes and see if they are any good before commiting to that)
and https://github.com/siliconcompiler/siliconcompiler/blob/1122fadb92b4ca5803b7b66f0b071f3185310ffb/siliconcompiler/tools/yosys/syn_asic.tcl#L56
loads it back into the working memory.

[oharboe]

@gadfort @maliberty Single pass hierarchical synthesis. The first pass is very fast. Use number of cells as driver for the policy on whether to flatten modules or not.

There is a failure, but I wouldn't expect identical results.

I tried it on MegaBoom and it ran through rtlmp, which fails for a flattened design.

This implementation is a mix between tcl & python. The tcl interface in Yosys leaves something to be desired, so there's something to be said for exporting a .json file of everything and using Python or Tcl to examine the model, rather than try to use the yosys interface...

[oharboe]

@maliberty Trying to graph the new policy vs. proper cell count after full synthesis when using cells for MAX_UNGROUP_SIZE.

Note! This only shows whether the policy is similar, it doesn't show anything about the difference in quality of results!

make DESIGN_CONFIG=designs/nangate45/bp_multi_top/config.mk synth

NOTE!!! I fixed the label, the red stars is "flattened in neither case", i.e. policy is the same.

Adding to fast build:

techmap
opt -fast -full -purge

[oharboe]

@maliberty Cell count and area are not correlated in an obvious way... my thinking is that the hieararchy is not taken into account. A module that has almost no cells could contain two modules that has lots of cells... In that case, which modules do you keep, which do you flatten?

I'm puzzled by the current policy. Is there a reason it was done this way or was this just the way it was implemented initially and as it turned out it gave better numbers than the triton partitioner?

[oharboe]

Using stat -tech cmos we get an estimate of number of transistors which correlate strongly to area after very coarse synthesis.

[oharboe]

The policy is very nearly identical...

[maliberty]

Note that the '+' means there were gates that couldn't be counted and were assigned zero.