Problem simulating SRAM with Byte Enables

1

I’ve been using qmegawiz to generate Block RAM for a long time.

However, while adding the FPGA’s latest feature, I added a block ram that uses four independent write enables on a 32 bit wide SRAM.

Writes do not happen, so reads are 32’ZZZZZZZZ.

I compared the 8 bit blocks to the 32 bit blocks with byte enables in my system and there was one significant difference.

The 8 bit SRAM skeleton show an internal node called, “sub_wire0” which if you look at the skeleton is connected to the altsyncram data out. The 32 bit SRAM skeleton do not contain that node, as if it has been optimized away. Thus there is no SRAM in the model.

I noticed that the b port byte enables are tied to 1’b1, that would be an error if it is configured to be 4 bits wide, so I’ll try to enable byte enables for the output port and tie them high to see if that fixes the issue.

If that doesn’t work, I’m going to recode it as four independent 8 bit SRAMS (the rest of my system uses 8 bit SRAMs with no byte enables. That will hopefully get my simulations up and running, the problem is: it will use four times the block ram. That will probably be okay, but I’d rather be efficient.

Has anyone else run into this issue?

2

It’s not just the byte enables.

I can’t can’t get it to generate a working model at all in any configuration.

I wonder if the tool is completely broken.

I should probably try the old version of the tool.

3

Update. I could not get qmegawiz to work. Period.

I ended up inferring it with verilog according to intel’s advice found here:

This appears to work properly in both simulation and synthesis.

I won’t know for sure until my board gets back next year.