picosoc_demo example hits yosys ABC9 assert during synth

[Arvind-Srinivasan]

As mentioned in Slack, following the steps in issue #120 as @Xiretza except attempting to build the picosoc_demo results in a similar issue with an assert failing

25.5.2. Executing ABC9_OPS pass (helper functions for ABC9).
ERROR: Assert `modules_.count(name) == 0' failed in kernel/rtlil.cc:616.

However, it seems that this can be resolved successfully by commenting out that specific assert on line 616 which is seemingly not present in the Conda packaged version.

[Ravenslofty]

I'm going to come back to this tomorrow, but here's my debugging so far:

The problem here is that ABC9 is trying to create a bypass module for FDCE, but because ABC9 has already been run, this already exists, and Yosys throws an assert because of the name collision.

I'm not entirely sure what to do here; the bypass module is mostly just a buffer and according to a comment should have been removed at the end of ABC9.

[litghost]

I'm not entirely sure what to do here; the bypass module is mostly just a buffer and according to a comment should have been removed at the end of ABC9.

Is it possible that some of cleanup is not triggering? As a debugging idea, could all new modules from ABC9 be marked with an attribute, and then add an assertion something like assert len(select modules where attribute == "added_for_abc9") == 0 after the clean-up?

[dnltz]

I had the same issue some days ago and opened an issue on Yosys: https://github.com/YosysHQ/yosys/issues/2581

In my case this was due a really strange, wrong call from PROC_CLEAN into the abc9 function which only occurred when building it by myself. My solution was to use the litex-hub binary ...

[Ravenslofty]

That's an interesting hint, thank you.

[Arvind-Srinivasan]

The asserts are optimized out on the Litex-hub binary no? That would explain why it never causes an issue.