Improve user experience and documentation for large designs failing to pass synthesis

[oharboe]

Description

When trying out large designs, Yosys can easily get stuck on some futile optimizations due to a missing inferred memory or pathological sizes in some module.

Example below:

Untar slang-stuck.tar.gz

Run the below:

make --file=~/OpenROAD-flow-scripts/flow/Makefile SYNTH_HDL_FRONTEND=slang SYNTH_MEMORY_MAX_BITS=1024 DESIGN_CONFIG=~/OpenROAD-flow-scripts/flow/designs/asap7/minimal/config.mk DESIGN_NAME=CoralNPUChiselSubsystem  SDC_CONSTRAINTS=~/OpenROAD-flow-scripts/flow/designs/asap7/mock-alu/constraints.sdc VERILOG_FILES=./home/oyvind/coralnpu/bazel-bin/fpga/ip/coralnpu_chisel_subsystem_default/CoralNPUChiselSubsystem.sv SDC_CONSTRAINTS=~/OpenROAD-flow-scripts/flow/designs/asap7/mock-alu/constraints.sdc do-yosys-canonicalize do-yosys

Fails quickly, as expected, memories are inferred:

6.15.10. Executing MEMORY_COLLECT pass (generating $mem cells).
6.16. Executing OPT_CLEAN pass (remove unused cells and wires).
ERROR: TCL interpreter returned an error: Source files actually used in the design:
 home/oyvind/coralnpu/bazel-bin/fpga/ip/coralnpu_chisel_subsystem_default/CoralNPUChiselSubsystem.sv
Memories found in the design:
 Rows | Width |   Bits | Module               | Instances                                                                       
---------------------------------------------------------------------------------------------------------------------------------
 2048 |   128 | 262144 | Sram_2048x128$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.dtcm.sram.sramModules_0 | CoralNPUChiselSubsystem.instantiatedModules_0_2.rvv_coreTlul$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.rvv_coreAxi$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.dtcm.TCM128_1$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.dtcm.sram.SRAM_2048x128$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.dtcm.sram.sramModules_0
  512 |   128 |  65536 | Sram_512x128$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.itcm.sram.sramModules_0 | CoralNPUChiselSubsystem.instantiatedModules_0_2.rvv_coreTlul$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.rvv_coreAxi$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.itcm.TCM128$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.itcm.sram.SRAM_512x128$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.itcm.sram.sramModules_0
  256 |   128 |  32768 | read_data_buffer_sram_256x128$CoralNPUChiselSubsystem.instantiatedModules_1_2.read_data_buffer_sram_ext | CoralNPUChiselSubsystem.instantiatedModules_1_2.Spi2TLUL$CoralNPUChiselSubsystem.instantiatedModules_1_2.read_data_buffer_sram_ext

Follow the tips in https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/docs/user/LargeDesigns.md

Setting SYNTH_MOCK_LARGE_MEMORIES=1 gets synthesis further, but it gets stuck here for ca. 12-24 hours:

8.4.573. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
8.4.574. Executing OPT_EXPR pass (perform const folding).
8.4.575. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
8.4.576. Executing OPT_EXPR pass (perform const folding).
8.4.719. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
8.4.720. Executing OPT_EXPR pass (perform const folding).
[12 hours later or so]
8.5. Executing OPT pass (performing simple optimizations).
8.5.1. Executing OPT_EXPR pass (perform const folding).
8.5.2. Executing OPT_MERGE pass (detect identical cells).
8.5.3. Executing OPT_DFF pass (perform DFF optimizations).
[20 hours later]
Warning: Wire rvv_backend_rob$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.core.rvvCore.rvvCoreWrapper.core.backend.u_rob.$techmap$auto$extract_fa.cc:504:run$25937281.$not$/home/oyvind/OpenROAD-flow-scripts/flow/platforms/asap7/yoSys/cells_adders_R.v:49$25937291_Y is used but has no driver.
Warning: Wire rvv_backend_rob$CoralNPUChiselSubsystem.instantiatedModules_0_2.coreAxi.core.rvvCore.rvvCoreWrapper.core.backend.u_rob.$techmap$auto$extract_fa.cc:504:run$25937281.$not$/home/oyvind/OpenROAD-flow-scripts/flow/platforms/asap7/yoSys/cells_adders_R.v:50$25937292_Y is used but has no driver.
20. Printing statistics.
Synth 12
21. Executing CHECK pass (checking for obvious problems).
ERROR: Found 150818 problems in 'check -assert'.
Command exited with non-zero status 1
Elapsed time: 20:42:52[h:]min:sec. CPU time: user 55473.09 sys 2954.69 (78%). Peak memory: 28137692KB.
make: *** [Makefile:262: do-yosys] Error 1

Suggested Solution

Maybe this is simply a bug in Yosys rather than some pathological Verilog that needs to be fixed in the input to Yosys?

I don't know slang/yosys in any meaningful detail, but it seems to me that this may be more of an ORFS reporting issue than a problem with yosys as such. Yosys should get stuck when trying to synthesize giant memories from flip-flops, though better progress messages would make the experience less mysterious.

Spefically, I think it would help to write out a report that shows sizes of modules and what they contain in descending order in github .md syntax. The earliest this can be done is immediately after canonicalization.

This will allow the user to figure out which module to take a closer look at.

Additional Context

No response

[maliberty]

@povik any thoughts on how this can be implemented?

[povik]

@maliberty Yosys can estimate the size of modules before they have been synthesized. We use it in ORFS for automatic ungrouping. We could use the same estimatation to generate Oyvind's table, it would require (1) a new Yosys api and (2) a piece of tclware.

[oharboe]

We are running into trouble occasionally with firtool generating code that Yosys can't consume, but slang can. The trouble is that slang gets stuck "running forever". This is either due to a bug or missing feature in slang/Yosys or something in our code that is causing Yosys(after canonicalization) indigestion.

firtool is unethusiastically supporting outputting the Yosys Verilog subset, so a switch to slang would be nice to let everyone move forward.

[povik]

@oharboe We're considering a blanket switch to slang and it would be good to fix your "stuck forever" issue. If you leave a reproducer with @maliberty I can take a look.

[oharboe]

@oharboe We're considering a blanket switch to slang and it would be good to fix your "stuck forever" issue. If you leave a reproducer with @maliberty I can take a look.

There is a reproduction case in this issue...

[povik]

I missed it because this issue is a feature request too but indeed there is.

[oharboe]

I missed it because this issue is a feature request too but indeed there is.

I don't know if this is a bug or a missing feature 😺

[oharboe]

Also try https://github.com/The-OpenROAD-Project/megaboom, another big design, which I upgraded to slang on main...

bazelisk build BoomTile_synth

Looks like it is stuck too, didn't wait for it to complete. I think it is worth retrying after looking into the problem at the top of this issue.

[povik]

@oharboe does that one finish faster without slang?

[oharboe]

@oharboe does that one finish faster without slang?

Don't know, testing...