updatemem fails on Large MEM file

[jonathanrainer]

I've noticed recently that if I fill a .mem file with more than 32768 bits I get the following Critical Warning message from updatemem (From 2018.2 running on Ubuntu 18.04.02 LTS):

CRITICAL WARNING: [Memdata 28-247] The input .mem file has exceeded 32768 which is the maximum number of bits for a RAMB18 primitive. The updating of the BRAM init string is terminated. Please check your input .mem file.

Now this would be fine but my design includes only RAMB36's so surely it should be possible for updatemem to write more than 32768 bits if the primitives allow? Is there some kind of switch for updatemem that needs to be flicked to indicate you're using RAMB36's or is a bug? It does mean that I have to resynthesise my design every time I want to change a large program which is a pain so if there is a solution I'd be very interested to hear it.

[stephenm]

RAMB36 = 32 data bits + 4 parity bits. 32 x 1024 = 32768

updatemem doesnt use the parity bits, so the error you are seeing is correct.

[jonathanrainer]

Hi @stephenm,

I agree with you very much and that was my calculation as well however, I'm using XPMs to generate me a memory device that stores 32-bit wide words. The MMI file for this is attached to this post. My reading of the file is that it uses 32 RAMB36's and stores 1 bit of each word in each BlockRAM location so that when a read is perform each bit of the word is clocked into a register so the whole word can be read in one cycle. With that being the case the total capacity of this memory structure should be 32 * 32768 = 1048576 bits. Further more I could configure the XPM to provide twice as much memory as this, putting the individual RAMB36's into cascade mode and then have 64 * 32768 = 2097152 bits (which I have done and updatemem fails because it is expecting 32 BRAMs and finds 64 which is not the case but that's a different question though I would also appreciate an answer there as well). That being the case how can updatemem write to the whole contents of a memory of this size when you can only specify an instance of an XPM to write to? Is there a way to specifiy multiple date files per instance (-proc option) or is there some fundamental limitation that I can't see?

[stephenm]

you have 16 RAMB36, so 16 x 1024.

I dont see the address range in your MMI file

[jonathanrainer]

Sorry I misrembered the figures. My point still stands though, with 16 BRAMs I should have access to 1048576 bits, why can updatemem not set those bits?

[stephenm]

Are you not missing an address range?

[jonathanrainer]

The address ranges are in the AddressRange tags for example <AddressRange_PortA Begin="0" End="16383"/>

[stephenm]

I meant the address range for the entire memory block

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842458/Understanding+MEMDATA+flow+and+how+to+manually+create+MMI+file

[jonathanrainer]

So this is the MMI file that comes out of the tools directly. It works differently to the example you linked which essentially creates a dummy processor to instantiate the memory of, whereas this seems to declare BlockRAM primitives to use instead.