Vivado 2018.2 2019.2 hard crash during synthesis

[dcabreraSilabs]

Hello Xilinx Community Forums,

I'm using a xcku115-flvd1924-2-as an emulation platform for a SoC we're developing. The board is an in house design. Vivado consistently crashes during synthesis on both 2018.2 and 2019.2. Vivado is run on a Red Hat  Enterprise Linux Server 7.7 server that allocates 8 cores and 32GB of memory. We are trying to pinpoint the specific RTL changes that cause this as reverting to a previous version of the RTL compiles successfully. Attached to this post are several of the stack dumps generated by vivado.

Regards,

David Cabrera

[anusheel]

@dcabreraSilabs 

The crash log shared looks different in all four logs, this could be due to the unsupported OS used.
2018.2

2019.2:

Can you please try to synthesize on supported OS and let us know if that helps to avoid the crash?

Thanks
Anusheel 

[dcabreraSilabs]

Hello @anusheel thanks for the quick response.

All the logs with vivado2018 in the previous message were from the same run. That particular compilation was restricted to 1 core so maybe that explains the difference between the stack dumps. I have tried compiling the same design this time in Vivado 2020.1 as it was easier to bump up to a newer revision than getting a server with the supported RHE version. Attached to this message you will find the stack dumps of each failed synthesis run. Given that this is reproducible in 2020.1 with a supported OS, my first guess is that it is not OS related. 

Looking at hs_err_pid24383_vivado2019.log, hs_err_pid15765_vivado2018.log and hs_err_pid4785_vivado2020.log, the stack dump is the same save for a few addresses. A similar design sharing most of the RTL code but with different constraints and clock speeds fails with the same stack dump. Newer compilations of the design incorporating more RTL changes fail with the same stack dump.

The design uses about 68% of CLB LUTs, 13% of CLB registers, 37% of Blockrams and less than 3% of DSP48E2. So we're not pushing it particularly hard in terms of usage.

[dcabreraSilabs]

@anusheel

I forgot to add. Vivado 2020.1 throws the following segfault error

# source fpga_files.tcl > $outputDir/fpga_files.log
# source fpga_synthesis.tcl > $outputDir/synth_design.log
segfault in /tool/vivado/2020.1/Vivado/2020.1/bin/unwrapped/lnx64.o/vivado -exec vivado -notrace -mode batch -source /tool/vivado/2020.1/Vivado/2020.1/scripts/rt/data/task_worker.tcl -nolog -nojournal -tclargs SYNTH_DESIGN_PARENT703_0_1601421516_cfg SYNTH_DESIGN_PARENT703_0_1601421516_buf SYNTH_DESIGN_PARENT703_1601421516 xcku115-flvd1924-2-e, exiting...
segfault in /tool/vivado/2020.1/Vivado/2020.1/bin/unwrapped/lnx64.o/vivado -exec vivado -notrace -mode batch -source /tool/vivado/2020.1/Vivado/2020.1/scripts/rt/data/task_worker.tcl -nolog -nojournal -tclargs SYNTH_DESIGN_PARENT703_1_1601421518_cfg SYNTH_DESIGN_PARENT703_1_1601421518_buf SYNTH_DESIGN_PARENT703_1601421516 xcku115-flvd1924-2-e, exiting...

[dcabreraSilabs]

We have narrowed down the issue to an RTL issue with memories. It seems vivado has trouble inferring memories that span beyond a certain size. The passing code had the following line 

logic [38:0] memory [0:2047] /* synthesis syn_ramstyle="block_ram" */;

when increased to 

logic [38:0] memory [0:20470] /* synthesis syn_ramstyle="block_ram" */;

Vivado crashes. Attached you will find a verilog file that can make vivado crash in 2018.2 when running synthesis of this module as top level. I have not tried compiling this in 2019.2 or 2020.1.

Note that the original file name extension should be .sv but I got the following warning

Correct the highlighted errors and try again.

• The attachment's bram_infer_128kb.sv content type (application/octet-stream) does not match its file extension and has been removed.

[richardhead]

@dcabreraSilabs 

Did you try making the large ram a power of 2?

logic [38:0] memory [0:32767] /* synthesis syn_ramstyle="block_ram" */;

[anusheel]

Hi @dcabreraSilabs 

Yes, I am able to reproduce the crash at my end. A CR is filed for this issue.

Can you rewrite the code in below format to work around the issue:
always_ff@(posedge clk) begin
  for(i=0;i<5;i=i+1) begin
   if(write_enable) begin
    if(byte_enable[i]) begin
     memory[addr][i*8 +: 8] <= wdata[i*8 +: 8];
    end
   end
  end
 end

I had to increase the width from [38:0] to [39:0] for the loop to work. 

Thanks
Anusheel 

[dcabreraSilabs]

Hello @richardhead .

Yes, I tried changing the large ram a power of 2. I was able to reproduce it with ram sizes

logic [38:0] memory [0:32767] /* synthesis syn_ramstyle="block_ram" */;

logic [38:0] memory [0:16387] /* synthesis syn_ramstyle="block_ram" */;

In a couple of cases Vivado managed to print this to the terminal

"reason is address width (15) is more than optimal threshold of 12. Implementing using BWWE will require more logic and timing would be suboptimal
Abnormal program termination (11)"

Given this error, we were able to rewrite our code as 10 smaller memories and stitching them up together in RTL.