Dependencies Between Yosys Passes (hierarchy, proc, memory, fsm, opt, setundef，Alumacc....etc...)

[1353369570]

I am working on optimizing the logic synthesis flow in Yosys and I want to better understand the dependencies between different passes. Specifically, I would like to know whether there are strong dependencies or recommended execution orders between the following passes:

1.Does proc always need to run after hierarchy? Since hierarchy resolves module instances and eliminates unused modules, should it always precede proc?
2.When should setundef be run relative to opt? Should setundef always be followed by an opt pass to remove unnecessary logic introduced by constant assignments?
3.Future, flatten, dff2dffe, dffsr2dff, clk2fflogic, coolrunner2_sop, alumacc, rmports
are all part of the transformation and optimization process from AST (Abstract Syntax Tree) to RTL Cell types. Should these passes be executed before the RTL-to-generic netlist conversion (e.g., before $Not cell transformations)?

I’d appreciate insights into the best order for these passes in relation to AST → RTL → generic netlist conversion, as well as any dependencies that should be considered.

[KrystalDelusion]

I've converted this to a discussion because this is a question not an issue.

The Synthesis starter guide goes through the usual ordering of common passes, including a note

hierarchy should always be the first command after the design has been read. By specifying the top module, hierarchy will also set the (* top *) attribute on it. This is used by other commands that need to know which module is the top.

proc is only needed if there are process blocks, but has no effect if there aren't any so is always safe to run after hierarchy. opt, opt_clean, and some of the other opt_* passes are called throughout synthesis; there is no one best place where to call them. Passes generally shouldn't delete any disconnected modules, instead leaving this for a subsequent call to opt_clean; this includes setundef.

It might be not be completely up to date, but there is documentation for the AST and the RTLIL formats. Note that most passes only operate on the RTLIL, not the AST itself (or even the RTL itself). As discussed in the Synthesis starter guide (linked above) and the Synthesis in detail section of the documentation, the main split for passes is whether they operate on the coarse-grain representation (word-level, parametrizable width) or fine-grain representation (bit-level) as in the cell library. In general, cell names like $and are coarse-grain; while cell names like $_AND_ are fine-grain. The technology mapping page discusses this. Note that once it reaches technology/platform specific cells, like the ice40 SB_LUT4, then the vast majority of passes will no longer change anything.

[1353369570]

In the RTLIL-level optimization process, which of the passes such as proc，Future, flatten, dff2dffe, dffsr2dff, clk2fflogic, coolrunner2_sop, alumacc, rmports，opt, lux2mux,... etc,are coarse-grain optimizations, and which are fine-grain optimizations?

Do these coarse-grain passes affect subsequent fine-grain transformations (bit-level transformations), such as $Not cell transformations?

Is there a recommended execution order for these passes to ensure optimization effectiveness and correctness?

Are there any dependencies between passes that should be carefully considered?

[widlarizer]

Generally passes support working on both fine-grained and coarse-grained if possible. However, alumacc and lut2mux are examples of fundamentally requiring certain coarse-grained cells on the input. They're just not going to do anything if they don't see those

By the way your answer suggests you're using a very old version of yosys since Merged "dffsr2dff", "opt_rmdff", "dff2dffe", "dff2dffs", "peepopt.dffmux" passes into a new "opt_dff" pass is in the yosys 0.10 changelog, so you're more than 3 years behind