Synthesis taking a lot of time (memory block?)

roby2014 commented 1 year ago

Version

Yosys 0.24+10 (git sha1 69cbef966, gcc 12.2.0 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -fPIC -Os)

On which OS did this happen?

Linux

Reproduction Steps

git clone https://github.com/roby2014/iob-soc
cd iob-soc
make fpga-build BOARD=COLORLIGHT_5A-75E REVISION=8.0

Expected Behavior

Bitstream generation.

Actual Behavior

Synthesis taking a lot of time. The log file has about ~36k lines (in 5/10 min of waiting).

Any idea what could be causing this? (after some research I found people talking about memory being instantiated in individual flip flops instead of BRAM)

I suppose the issue comes from synth_ecp5.

The script that is run looks something like this:

read -define INIT_MEM DATA_W=32 ADDR_W=32 BOOTROM_ADDR_W=12 SRAM_ADDR_W=15 FIRM_ADDR_W=15 DCACHE_ADDR_W=24 N_SLAVES=1  E=31  P=30  B=29  UART=0 N_SLAVES_W=0 USE_MUL_DIV=1 USE_COMPRESSED=1 DDR_DATA_W= DDR_ADDR_W= 

verilog_defaults -add  -I../../../../submodules/UART/hardware/include -I../../../../submodules/LIB/hardware/include -I../../../../hardware/include -I../../../../submodules/LIB/hardware/include 

read_verilog ../../../../submodules/LIB/hardware/iob_merge/iob_merge.v ../../../../submodules/LIB/hardware/iob_split/iob_split.v ../../../../submodules/LIB/hardware/iob_pulse_gen/iob_pulse_gen.v ../../../../submodules/LIB/hardware/iob_edge_detect/iob_edge_detect.v ../../../../submodules/LIB/hardware/iob_reg/iob_reg.v ../../../../submodules/MEM/hardware/rom/iob_rom_sp/iob_rom_sp.v ../../../../submodules/MEM/hardware/ram/iob_ram_dp/iob_ram_dp.v ../../../../submodules/MEM/hardware/ram/iob_ram_dp_be/iob_ram_dp_be.v ../../../../submodules/PICORV32/hardware/src/picorv32.v ../../../../submodules/PICORV32/hardware/src/iob_picorv32.v ../../../../submodules/UART/hardware/src/uart_core.v ../../../../submodules/UART/hardware/src/iob_uart.v ../../../../hardware/src/boot_ctr.v ../../../../hardware/src/int_mem.v ../../../../hardware/src/sram.v system.v ../../../../submodules/LIB/hardware/iob_reset_sync/iob_reset_sync.v ./verilog/top_system.v 

synth_ecp5 -top top_system -json top_system.json

This is the log file (it should help understand whats going on maybe): https://easyupload.io/7zsz70

gatecat commented 1 year ago

The problem seems to be the iob_ram_dp_be isn't being inferred correctly by Yosys. Although I believe true dual port memories like this should be supported to some extent, is it possible to try a simpler memory style for now?

gatecat commented 1 year ago

I suspect it's because iob_ram_dp_be requires transparency semantics (i.e. behaviour during collisions between memory ports or the read data returned while writing) that can't be implemented by the underlying hardware. Vendor tools tend to be more liberal here, you can mimic this behaviour in Yosys by passing -no-rw-check to synth_ecp5.

roby2014 commented 1 year ago

Yes I do believe its because of iob_ram_dp_be, if I comment this section:

   /*iob_ram_dp_be
     #(
       .HEXFILE(HEXFILE),
       .ADDR_W(`SRAM_ADDR_W-2),
       .DATA_W(`DATA_W)
       )
   main_mem_byte
     (
      .clk   (clk),

      // data port
      .enA   (d_valid),
      .addrA (d_addr),
      .weA   (d_wstrb),
      .dinA  (d_wdata),
      .doutA (d_rdata),

      // instruction port
      .enB   (i_valid),
      .addrB (i_addr),
      .weB   (i_wstrb),
      .dinB  (i_wdata),
      .doutB (i_rdata)
      );*/

It already compiles fine.

-no-rw-check also solves the long time compilation issue.

YosysHQ / yosys