sv2v hangs and eventually OOM

[flaviens]

Hi there!

I encountered a sv2v hang that eventually goes OOM (requires 100+GB RAM). I could narrow it down to the following commands:

git clone https://github.com/black-parrot/black-parrot.git
cd black-parrot
git submodule update --init --recursive
sv2v -I ./external/HardFloat/source/RISCV/ -I./external/HardFloat/source/ -I./external/basejump_stl/bsg_misc/ -I./external/basejump_stl/bsg_noc/ -Ibp_common/src/include -Ibp_fe/src/include bp_fe/src/include/bp_fe_pkg.sv bp_common/src/include/bp_common_pkg.sv bp_be/src/include/bp_be_pkg.sv bp_fe/src/v/bp_fe_top.sv

It seems that this is not the only problematic occurrence in this repository, but the problem is probably common to all of these occurrences.

I'm using sv2v v0.0.10-1-gc00f508.

Thank you! Flavien

[zachjs]

Thanks for reporting this issue and providing a reproducer!

I have isolated the problem to the always_comb changes made in #199. I have not yet been able to track down the root cause or implement a fix. In the meantime, you may be able to workaround the issue using -E always if your downstream target supports the SystemVerilog always variants.

[flaviens]

Hi Zach,

It indeed solved the problem for the narrowed down instance, thank you!

However, with the attached more real-world example bp_pickled.zip, it still seems to still abnormally take a long time:

sv2v -DSYNTHESIS -DVERILATOR -E always bp_pickled.sv -w sv2v_out.v

EDIT: Actually it succeeds after a long while with -E always, but is still much slower than what it is typically with other designs.

[zachjs]

I've pushed some fixes and optimizations. With those changes, the -E always workaround isn't needed, and your most recent example converts in under 90 seconds on my machine. Can you give this a shot and let me know if it works for you?

[flaviens]

Cool, thanks! In fact I'll continue using -E always because usually downstream tools seem to work fine with that at the moment. That said, this is a great addition for Verilog compliance.