circt-synth has been trying to provide a good default pipeline, but still it is essential to provide a mechanism for users to execute specific, custom pipelines (e.g., Yosys scripts or general ABC optimization sequences). A native MLIR-based approach to achieve this would be to leverage the MLIR Transform dialect.
For example if an STA pass were available (currently not), it could be utilized as a "failable" pass; if timing is satisfied, the process completes, but if it fails, the system could fall back to a different strategy or re-budgeting. We can represent this kind timing loop naturally with transform dialect (even though I'm not sure transform dialect actually provide control-flow like "loop", but still we can unroll the loop if necesssary). Additionally, a Functional Reduction pass would compose well with this workflow: we could try different pipelines in parallel, connect the outputs via a choice operator, run FunctionalReduction to merge intermediate nodes, and finally perform technology mapping.
circt-synth has been trying to provide a good default pipeline, but still it is essential to provide a mechanism for users to execute specific, custom pipelines (e.g., Yosys scripts or general ABC optimization sequences). A native MLIR-based approach to achieve this would be to leverage the MLIR Transform dialect.
For example if an STA pass were available (currently not), it could be utilized as a "failable" pass; if timing is satisfied, the process completes, but if it fails, the system could fall back to a different strategy or re-budgeting. We can represent this kind timing loop naturally with transform dialect (even though I'm not sure transform dialect actually provide control-flow like "loop", but still we can unroll the loop if necesssary). Additionally, a Functional Reduction pass would compose well with this workflow: we could try different pipelines in parallel, connect the outputs via a choice operator, run FunctionalReduction to merge intermediate nodes, and finally perform technology mapping.