UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor xanthos
Visitor
2,552 Views
Registered: ‎09-05-2017

hand-coded MMI file issue

Jump to solution

I a ROM instantiation in my design as shown in the pictures below:

Rom Instance 

 

with these characteristics from the RAM36E1 model:

 ROM_Characteristics


I am using updatemem tool to change the specific rom data that i have already preloaded from Synthesis. I am sure that the memory file syntax is correct. I have used two syntacticly different ones, that both worked. So, probably the problem lies on the MMI file.

 

I created the MMI file, but I always get wrong data after running the updatemem tool. 

Can somebody help me, and check weather my MMI file is correct or not?

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
3,646 Views
Registered: ‎09-12-2007

Re: hand-coded MMI file issue

Jump to solution

I created an AR for this a while back:

https://www.xilinx.com/support/answers/63041.html

 

Your flow (workflow2) is covered here. 

 

Note: you can also just write directly to the init_strings of the ROM in Vivado

 

0 Kudos
10 Replies
Voyager
Voyager
2,534 Views
Registered: ‎06-24-2013

Re: hand-coded MMI file issue

Jump to solution

Hey @xanthos,

 

Your hand-coded MMI file looks a little fishy ...

                <BusBlock>
                <BitLane MemType="RAMB32" Placement="X4Y25">
                        <DataWidth MSB="31" LSB="30"/>
                        <AddressRange Begin="0" End="4095"/>
                        <Parity ON="false" NumBits="0"/>
                </BitLane>

 

A RAMB32 has 32kbit, so that would result in either two bit with 16k range or eight bit with 4k range, not two bit with 4k range.

 

You have 16 such blocks in your .mmi, so a total of  128k bit or 16k byte of data, but your data files have 146x32 or 584x8 bit values (a total of 4672 bits).

 

Hope this helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Visitor xanthos
Visitor
2,529 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

Thank you for the answer.

So my data can fit in the memory, right?  Memory capacity is 16 Kbytes and my data are 584 bytes.
In my case, I want 2 bits with 16K range.
So, if I understood correctly, I have to change each Bitlane like this?

<BusBlock>
                <BitLane MemType="RAMB32" Placement="X4Y25">
                        <DataWidth MSB="31" LSB="30"/>
                        <AddressRange Begin="0" End="16384"/>
                        <Parity ON="false" NumBits="0"/>
                </BitLane>

 Having 16 such blocks, why is it 128k? 
isn't it 16*16K = 256?

Sorry for my wrong assumptions. I may have understood wrong.
Thank you though !!! It helped me

0 Kudos
Voyager
Voyager
2,498 Views
Registered: ‎06-24-2013

Re: hand-coded MMI file issue

Jump to solution

Hey @xanthos,

 

So, if I understood correctly, I have to change each Bitlane like this?

Yes, this looks more appropriate!

 

Having 16 such blocks, why is it 128k? 

isn't it 16*16K = 256?

The 128k calculation was for 16x8k (2x4k) you had before.

With 32k (2x16k) you get a total of 512k bit (or 64k byte)

 

Thank you though !!! It helped me

You're welcome!

 

Hope this clarifies,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Visitor xanthos
Visitor
2,463 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

I think I understand now. Thank you for that. 

I want to be more specific and ask you you opinion.

My memory has 16 bitlanes with the RAMB36E1 model. I don't have parity bits. My ram is dual port with read/write width as 2 bits for each port.

 

My bitlanes look like this. Are they correct?
mem0.PNG

 

After checking the memory contents, I see that behavior.

mem1.PNG

First line has the value that I load, and second line has the value that I get. It is like that I have some sort of shifting

Changing the MSB and LSB change my values.

I have tried to run a tcl script from an other Xilinx answer that creates the MMI file (write_mmi.tcl), but it didn't work because my Vivado project derives from an other tool and is not built from scratch. So, the script fails.
I was able to confirm the Address Range, but I do fail to understand the MSB and LSB. 

Can somebody clarify that?
Thank you

0 Kudos
Visitor xanthos
Visitor
2,438 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

Mistyped something in the image: 

 

mem1.PNG

 

And here is a better overview of what is happening:

 

ROM_detailed.PNG

 

The endianness is little.

0 Kudos
Visitor xanthos
Visitor
2,397 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

Running Command:

report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE == BMEM.bram.RAMB36E1}] 0]

 

I get the result below, which is confusing cause the Address_begin and end are FALSE(null)(don't exist); width and lsb/msb too.  

 

mem_false.png

 

Probably, updatemem tool of Xilinx may not be a solution at all to my problem :/ .

 

Can anyone help???

0 Kudos
Moderator
Moderator
3,647 Views
Registered: ‎09-12-2007

Re: hand-coded MMI file issue

Jump to solution

I created an AR for this a while back:

https://www.xilinx.com/support/answers/63041.html

 

Your flow (workflow2) is covered here. 

 

Note: you can also just write directly to the init_strings of the ROM in Vivado

 

0 Kudos
Visitor xanthos
Visitor
2,318 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

@stephenm I used your guide, but I couldn't complete it.

  • I tried the manual approach and got the above results.
  • I tried the write_mmi script but it fails cause it get's null{false} data from the properties of the RAM(like the width, the lsb, msb, etc)
  • I tried to write directly to the INIT strings, but for my case it is painful and needs conversion. Also, I still haven't verified if the init strings that I wrote had correct results.

    It seems, that is maybe a weird scenario, that my RAM models are having faulty or wrong properties. Probably, Xilinx interception on that may help or I need to open a ticket on their support page.

    Thank you for your reply me friend.
0 Kudos
Moderator
Moderator
2,311 Views
Registered: ‎09-12-2007

Re: hand-coded MMI file issue

Jump to solution

Have you a project that you can share? I will try to create the MMI file.

0 Kudos
Visitor xanthos
Visitor
822 Views
Registered: ‎09-05-2017

Re: hand-coded MMI file issue

Jump to solution

Well, I wasn't able to share content, but at last all the guidance in the solution's above link were enough. 
The problem was , that if you have eg. a 64kB memory and you PRE-load less like 16KB, Vivado optimizes away the RAMB36E1 models and the interpretation of the design into the FPGA is faulty.

 

So, always PRELOAD as much in size contents as your ROM actually is. Also, I have to mention that the ROM data should be Random or Actual ROM code and not only continues 00...0s or FF...Fs, because Vivado will interprete them as LUT's and not as memory models like RAMB36E1.

 

Thanks everyone for everything !!!

0 Kudos