Experiment with partitioning for abc

[povik]

What are the reasons/motivation for this change?

To obtain statistics about the potential to partition a design into fully connected components which can be independently processed by ABC (in parallel).

[wjrforcyber]

Hi! Have you tried this on any benchmark? Our group used to implement a "structure analyser" before passing a flattened design(Seq component removed) to ABC, to check whether it is possible to run independent subgraph in parallel, but it seems that only few cases have fully-connected independent subgraph.
Idk, if one could know any circumstances that design is likely to have fully-connected subgraph in advance would be nice.

[povik]

Hi! Your method sounds identical to what this command is doing.

it seems that only few cases have fully-connected independent subgraph.

Yes, I've tried on few designs from OpenROAD-flow-scripts and they were usually dominated by one large connected component so that there wasn't much to gain from parallizing on the components. I'm curious to hear about other methods of partitioning that people have tried, or that may be suitable here.

[wjrforcyber]

I'm curious to hear about other methods of partitioning that people have tried, or that may be suitable here.

If jump out of the fully-connected subgraph, the most hard problem would be how to do the partition, ABC has a command &stochsyn, which directly splits and stitches back based on size (without strategy here), it may boost speed but every split brought boundary and every boundary brought structure bias which usually lead to decreased performance in result. This is still a good method though, since one can't be so unlucky to split on same edges when run multiple times into saturation.
LSOracle has a KaHyPar partition framework, it could split as few edges as possible, don't know if it is suitable, I'm still looking into this now, "hurt as few edges as possible" sounds reasonable to me even on optimisation level.

Looking forward to see other people's idea on this too.