Share pass uses too much system memory for large combinatorial networks

JulianKemmerer commented 9 months ago

Version

Yosys 0.36+85 (git sha1 f26495e54, clang 10.0.0-4ubuntu1 -fPIC -Os)

On which OS did this happen?

Linux

Reproduction Steps

yosys_crash.zip

Extract the .zip file
cd yosys_crash/top
bash ghdl_and_yosys.sh

The .sh script invokes the GHDL plugin for yosys and then yosys like so (just with a bunch more VHDL files than show below - sorry):

#!/usr/bin/env bash
export GHDL_PREFIX=/usr/local/lib/ghdl
# Elab+Syn
/usr/local/bin/yosys -m ghdl  -p 'ghdl --std=08 -frelaxed ../top/top_f7ea.vhd  -e top_f7ea; synth_ecp5 -abc9 -nowidelut  -top top_f7ea -json top_f7ea.json; write_edif -top top_f7ea  top_f7ea.edf'

The design is a large combinatorial network between a set of registers. Directory is output from a tool, not human written code.

Expected Behavior

Output .json file, no huge jump in RAM use that locks up the system.

Actual Behavior

During step 2.17. Executing SHARE pass (SAT-based resource sharing). RAM usage on my PC climbs rapidly (typically uses total few GBs then climbs to 10+GB). System/program crashes eventually.

Can be worked around by commenting out the share pass from https://github.com/YosysHQ/yosys/blob/f26495e54d936830e067e66b91bfac824011897c/techlibs/ecp5/synth_ecp5.cc#L294

Also share -fast seems to behave the same way.

nakengelhardt commented 9 months ago

Yes, this is known/expected given the way share works. Although I didn't expect to need a -noshare option (like the synth pass has) for smaller devices, as I thought it's not likely to run into designs that cause excessive time/memory usage, but it seems you managed to find one. Is the design realistic/something you would actually want to run on an ecp5 board in practice, or more of a benchmark?

Either way, the only solution I can think of is not running share for this design.

JulianKemmerer commented 9 months ago

Yes, a cmd line switch to disable this share pass would be great, ex. if -noshare existed to use in this case.

I would turn that switch on for this particular version of the design to disable share. The goal here is to continue to PnR and evaluate the timing of the large combinatorial path. So this version of code will never see real hardware, just collecting data.

However, given the data collected, the large comb. network is pipelined and that version of the design would benefit from turning share back on (not being all comb. shouldnt use a bunch of ram). That design absolutely runs on ecp5 does very cool stuff in hardware :nerd_face: https://blog.yosyshq.com/p/3d-raytracing/ <ghdl,yosys,nextpnr3

YosysHQ / yosys