BRAM not being utilized in spite of it being recognised during synthesis

[nkyparissas]

I am copying the text of the question I just asked in Xilinx forums:

I have designed a system with Bluespec SV (BSV), but when I implement the generated Verilog design with Vivado 2021.1, no BRAM is used.

I am using a BRAM2Server BSV module in my design, which is generated as an array of registers in Verilog with a wrapper around it. Vivado is not putting the array in BRAM during synthesis though, even if I explicitly add the (* ram_style = "block" *) attribute in front of the array at the generated Verilog.

Even with the -verbose attribute given to synthesis, the only thing that appears in the synthesis report is the following:

INFO: [Synth 8-7030] Implemented Non-Cascaded Block Ram (cascade_height = 1) of width 9 for RAM "BRAM2Load:/RAM_reg"
INFO: [Synth 8-7030] Implemented Non-Cascaded Block Ram (cascade_height = 1) of width 7 for RAM "BRAM2Load:/RAM_reg"
INFO: [Synth 8-3971] The signal "BRAM2Load:/RAM_reg" was recognized as a true dual port RAM template.
and then no BRAM is used, without any message telling me what happened to RAM_reg. Unisim Transformation does not mention anything about BRAM either.

I have tried different sizes of arrays (1KB - 32KB) in case BRAM usage was inefficient because of the array's size, but no.

What am I missing?

[quark17]

I don't have experience with this, so hopefully someone who does (here or on the Xilinx forums) will respond. If I were try to help, I would start by asking what "no BRAM is used" means -- what are you actually observing that makes you say this? Also, does the synthesized design run successfully on FPGA? (thus showing that the array is actually being used, and hasn't been optimized away, say)

But the reason I wanted to comment, was this that you said:

even if I explicitly add the (* ram_style = "block" *) attribute in front of the array at the generated Verilog.

The is no array in the generated Verilog files; the array is in a file BRAM2Load.v that comes with BSC, and it already has the explicit attribute (if you're using the right file). I just wanted to make sure that you're aware that there is a directory inst/lib/Verilog.Vivado/ that has Vivado-specific versions of some files found in inst/lib/Verilog/. The BRAM2Load.v there has the attribute, on the reg called RAM. If you're using Vivado, use the files in inst/lib/Verilog.Vivado/ before going to inst/lib/Verilog/.

[nkyparissas]

Thank you very much for your reply! You were absolutely right, I was using the Verilog files found in inst/lib/Verilog/ instead of the ones in inst/lib/Verilog.Vivado/.

Unfortunately, it did not make a difference (the only difference between the two files is the (* ram_style = "block" *) attribute/directive), but I noticed there was a MakeClock.v file in the inst/lib/Verilog.Vivado/ directory as well. Maybe the problem is that my BRAM is driven by a clock signal I generate with ClockDiv.v. I will try to use the MakeClock.v file found in inst/lib/Verilog.Vivado/ instead and get back to you. Thanks again!

[nkyparissas]

Update: I used only the source clock ("current clock") to drive everything while using the BRAM Verilog file found in inst/lib/Verilog.Vivado/ and nothing changed.

I forgot to mention before that the synthesized design works on the FPGA - I am using the BRAM module as a look-up table and the numerical results are correct. I can also see the "BRAM" module implemented as distributed RAM on the FPGA layout after place-and-route.

Also, the Verilog code that is generated from my Bluespec design works perfectly well when I connect a Xilinx BRAM IP named "BRAM2Load" to my generated system instead of the original BRAM2Load.v, so I don't believe the problem has anything to do with the Bluespec wrapper of BRAM2Load.

I am preparing a simple BSV design consisting only of an AXI wrapper and BRAM2Load. I'll get back to you once I have tested that!

[nkyparissas]

Update: I did what I mentioned before and had the same problem.

Nonetheless, I figured out what the problem was and it had nothing to do with BSV, but I will write the answer here in case people have the same issue.

I synthesized the same design with an older version of Vivado (2018.3) to see if the messages change, and it was eliminating the BRAM because "it was not being used" (in spite of it being used and WORKING in the implemented version!)

The problem was that I was initializing the BRAM module with a .txt/.mem file and I was using it as a look-up table, hence I was never writing to it! The moment I added a dummy cycle where I am writing 1 word to it after reset, Vivado decided to keep the BRAM!