cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jonathanrainer
Visitor
Visitor
1,278 Views
Registered: ‎01-19-2017

updatemem fails on Large MEM file

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.

0 Kudos
Reply
8 Replies
stephenm
Moderator
Moderator
1,235 Views
Registered: ‎09-12-2007

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.

 

 

0 Kudos
Reply
jonathanrainer
Visitor
Visitor
1,221 Views
Registered: ‎01-19-2017

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?

0 Kudos
Reply
stephenm
Moderator
Moderator
1,214 Views
Registered: ‎09-12-2007

you have 16 RAMB36, so 16 x 1024.

I dont see the address range in your MMI file

0 Kudos
Reply
jonathanrainer
Visitor
Visitor
1,210 Views
Registered: ‎01-19-2017

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?

0 Kudos
Reply
stephenm
Moderator
Moderator
1,207 Views
Registered: ‎09-12-2007

Are you not missing an address range?

0 Kudos
Reply
jonathanrainer
Visitor
Visitor
1,205 Views
Registered: ‎01-19-2017

The address ranges are in the AddressRange tags for example <AddressRange_PortA Begin="0" End="16383"/>
0 Kudos
Reply
stephenm
Moderator
Moderator
1,204 Views
Registered: ‎09-12-2007

0 Kudos
Reply
jonathanrainer
Visitor
Visitor
1,202 Views
Registered: ‎01-19-2017

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.
0 Kudos
Reply