Yosys Synthesis Error: Hash Table Exceeded Maximum Size

[LoSyTe]

Version

yosys 0.41+126

On which OS did this happen?

Linux

Reproduction Steps

Hello, I encountered another issue while using Yosys to synthesize a Verilog file. The specific details are as follows: I used the Verilog file rtl.v, and during the Yosys synthesis, a yosys_stderr.log file was generated with the following content:

“terminate called after throwing an instance of 'std::length_error' what(): hash table exceeded maximum size.”

The synthesis process was interrupted due to this error. I suspect this is because the design file is too large, causing the hash table to exceed its maximum size limit. To rule out issues with the design file itself, I have checked the structure of the Verilog file but did not find any obvious problems. Additionally, I am using the latest version of Yosys.

Attached is the Verilog file (rtl.v) that triggers this issue. I hope to get the community's help and attention. design_file.zip

Expected Behavior

synthesis success

Actual Behavior

synthesis fail

[whitequark]

You should minimize the reproducer further.

[mtuomi]

I have previously fixed this locally by adding large prime like 1955854157 at the end of zero_and_some_primes array in hashlib.h (inside hashtable_size function). I couldn't reproduce the problem with your design_file.zip. I've seen this only with really massive designs with hundreds of millions of gates.

[Kmanfi]

Seen also same error with huge designs. Haven’t made an issue here coz privacy of those designs. I confirm: By adding additional prime will fix the issue, as explained in previous comment. I have seen the issue during flattening already compiled huge designs.

[georgerennie]

The reason you are hitting this limit seems to be because of the large structures from your large constant shifts interacting badly with peepopt shiftadd, the same thing that caused issues in #4445. Please minimize and look into whether you are seeing duplicates of this issue yourself first as they have come up a few times.

If you try running with patch #4455, this issue isn't hit as it doesn't generate these massive intermediate nodes.

[LoSyTe]

@whitequark @georgerennie Thank you for your responses. I have tried using the patch from #4455, but the issue still persists. I have simplified my program and would appreciate your help in analyzing and resolving this problem. Looking forward to your feedback, thank you.

design_file.zip

[whitequark]

Thanks, the new reproducer is vastly more useful.

[georgerennie]

Could you double check you have the patch from #4455 applied correctly? For me on latest main (1288166f7ac03456b6beb0acff5d4fc84f63f57c) without it I can reproduce your issue still with the new rtl, but when I cherry pick that patch synthesis completes quickly without issue.

I applied the patch by doing something along the lines of

git fetch
git checkout main
git cherry-pick 2f0f10cb871228248c8e012a9d6756c1e1b972c1

I am using yosys -p "read_verilog rtl.v; synth" to test it.

I should also add that I think the hash table error is one worth fixing (it seems by adding another prime), but hopefully applying this patch would allow you to stop hitting these cases with the fuzzing work.

[LoSyTe]

Could you double check you have the patch from #4455 applied correctly? For me on latest main (1288166) without it I can reproduce your issue still with the new rtl, but when I cherry pick that patch synthesis completes quickly without issue.

I applied the patch by doing something along the lines of

git fetch
git checkout main
git cherry-pick 2f0f10cb871228248c8e012a9d6756c1e1b972c1

I am using yosys -p "read_verilog rtl.v; synth" to test it.

I should also add that I think the hash table error is one worth fixing (it seems by adding another prime), but hopefully applying this patch would allow you to stop hitting these cases with the fuzzing work.

Thanks for your reply. I thought only one file was repaired, but then I noticed that two files were repaired in total. After I recompiled, the problem disappeared.