Closed growly closed 3 years ago
Hi @growly, yes, we have come across similar behaviour on large designs. We should probably reduce the number of times "rewriting verilog" happens; we only do that to keep all gate-level netlists in a canonical format and to avoid issues with the netgen verilog parser.
Good to know that the insane running time is related to the verilog version... I will try the latest HEAD, but just in case, which commit was the one you tried?
Thanks.
I'm at commit 347dd01c2f7dff6e8222c5f9d360f84a17c937b5; it definitely seems to have alleviated the problem!
confirm:
yosys --version
Yosys 0.9+2406 (git sha1 347dd01, gcc 8.3.1 -fPIC -Os)
@growly: The yosys version has been updated in rc4 and we're no longer facing this. I'll close this issue. Please, reopen, if you found otherwise.
I'm on rc3 -
The
yosys_rewrite_verilog.tcl
step of this flow is taking a strangely long time. yosys is consuming ~92 GB of RAM and has been spinning a core at ~100% for 16.5 hours.The command is
yosys -c /openLANE_flow/scripts/yosys_rewrite_verilog.tcl -l /openLANE_flow/designs/151/runs/06-10_16-40/logs/synthesis/yosys_rewrite_verilog.log
, but the log file is empty. I believe it's still in theread_verilog
step of the script but I can't really be sure. The design is the same as in #39.I had a stab at debugging yosys; it gets stuck in a recursive call and I couldn't observe progress over a few hours. It might just be really slow.
I built Yosys at HEAD instead and this problem seems to have gone away, with the rewrite step now completing in ~7 hours.
Has anyone else run into this problem with the yosys commit in rc3? (347dd01c2f7dff6e8222c5f9d360f84a17c937b5)