Upcoming ABC flow changes

Hello,

I have been working on some big changes on the interface to ABC in Yosys and wish to inform others about them.

Yosys presently has three different commands for running ABC: abc, abc9 and abc_new.

abc is the original optimisation/technology mapping flow using ABC; it supports LUT and standard cell mapping, plus mapping to sum-of-products architectures (e.g. synth_coolrunner2). It’s robust and bug-free, but reliant on BLIF for communication to and from ABC, which is not very efficient.

abc9 is the state of the art flow for FPGAs in Yosys, because it brings timing-driven mapping of LUTs and flops, as well as box support to describe fixed-function combinational logic (e.g. carry chains and hard multiplexers). It uses XAIGER to communicate with ABC because boxes are not supported in BLIF. It’s been the default LUT mapping flow for the past two and a half years for synth_ice40, synth_ecp5 and synth_gowin.

abc_new attempts to bring the efficiency benefits of an XAIGER flow to a standard-cell mapping flow, while also supporting boxes to represent hand-optimised macro blocks. It has a lot of overlap with abc9, with a few improvements that could be ported back to it. Unfortunately, the developer working on this flow left the company while working on this, and the resulting code is poorly understood.

This situation is not ideal, so I would like to rework these into a less confusing flow.

The abc9 pass is fairly mature and robust for LUT mapping, so I would like to rename it abc_lut (abc_fpga has also been suggested as a name), and remove LUT mapping functionality from the abc pass.

abc_new for standard-cell mapping is admittedly much less mature than abc, but I believe it to be a technologically superior base which would reduce resource usage on large designs. As such, I would like to rename it abc_scl (or abc_asic), develop it further and in the long term remove standard-cell mapping functionality from the abc pass.

This would leave the abc pass as existing solely for SOP mapping for synth_coolrunner2, which isn’t ideal and I’m unsure what to do there, but that can be solved later.

6 Likes

I added support for parallel ABC runs to abc last year. This is a pretty huge speedup in some situations. Can we have that in abc_new?

Um, hmm; abc9 and abc_new are both laid out as “scripts”, rather than the monolithic “blob” that is abc. The actual calls to ABC happen in abc9_exe for both passes, and both passes iterate over each selected module; I think they would have to be reworked a bit to enable this parallelism. Happy to discuss how to go about that.

Clock domain parallelism is a key feature we definitely don’t want to lose in this refactor. There was a good discussion about the changes in the original PR:

Script passes are just one possible way to build a decent level of abstraction and if that clashes with parallelization we’ll bake the parallel part of what is currently the script pass into a single pass. Passes are just functions that take a Design* and allow for taking a design snapshot conveniently. Having things split into lots of passes is great for allowing users to build super custom flows without touching C++. By the time people are sequencing abc-related passes themselves, they’re hopefully fine hacking at basic C++