BRAM synthesis bug?

It was noticed that writes to the QSFP modules stopped working. Simulations looked fine. The limited capacity I had to observe on-chip behavior looked fine (writes to the BRAM appeared to happen, as did reads). However, the data that was always being read out was 0x0. Things looked fine in the BSV and I scoured the generated Verilog and could not find anything anomalous. While trying to figure out what could have changed, I remembered that I bumped up the size of the read/write BRAMs from 128 to 256 so place and route would automatically put them in hard RAM blocks, not lutrams. When I reverted the size of the write BRAM back down to 128 (resulting in it synthesizing to lutram), it worked correctly! When I tested a bitfile with 128 and synthesized with the -nolutram property, it also worked and had synthesized to hard logic. Simulations worked the whole time.

Notably, we haven't found any issues with the read BRAM after the size change. I'm guessing that is due to using the higher level BRAM2Port interface provided by mkBRAM2Server, which introduces FIFOs at the ports of the BRAM, compared to the more bare bones BRAM_DUAL_PORT interface given by mkBRAMCore2.

The generated Verilog for 128 vs 256 looks exactly the same aside from the memsize parameter on the BRAM instantiation changing. I am not going to spend the time chasing this down right now given other priorities (DVT/PVT builds, compliance), so I'm opening this issue as a tracker for later.

Start with the BRAM2Port/mkBRAM2Server and BRAM_DUAL_PORT/mkBRAMCore2 entry points, then compare synthesis of the 128- and 256-entry write BRAMs. Reproduce the discrepancy with and without the -nolutram property, comparing simulation, generated Verilog, and the resulting bitfile. Done means identifying and fixing the synthesis or configuration cause, with the write path working at the larger size.