Updatemem and MMI firmware merge issue

[sundarbas]

Hi,

I am upgrading my FPGA system from Virtex-6 to Kintex Ultrascale and I am new to the Vivado way of doing things.

We do not use a Microblaze processor, but a custom RISC-V processor. We have a ROM initialization from Block memory generator and it has been initialized with a COE file. I verified that the processor was able to execute from the ROM. But when I do an updatemem with the resources from this AR: http://www.xilinx.com/support/answers/63041.html, the MCU could not start execution. I believe the merge was not successful.

My memory is a 32kx32 (32 width and 32768 depth, Write first) SPROM created with block mem gen. The algorithm is Fixed Primitives and it is with 4kx4 primitives.  I am attaching my MMI file and UCF File (file format changed for easier upload) for the memory placement here. 

Does the order matter on how the Bus Block or Bit Lane are ordered? How should I find the order for it?

Please let me know if anyother stuff would be useful to help me better.

Regards,
Sundar

[stephenm]

There is a wiki beliw that you can use to create the MMI manually:

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

[sundarbas]

Hi Stephen,

I have went through the wiki already. 

I have manually created my MMI file based on this. But I am not sure about the order with which the RAM instances have to be placed. How do I find out the order with which the memories are arranged? Do they matter for post implementation merge?

Could you have a look at the MMI file and check if it matches your requirement and point out if I am doing anything wrong?

Thanks,

Sundar

[stephenm]

You should be able to view the netlist to see how the address bus is connected and use this to update the mmi bitlanes.

However, you can just place some data at the base address and read this in hardware. This will give you an idea how the brams are formed.

How to you test on HW?

[sundarbas]

Hi Stephen,

I believe there are some typos in your reply.

You mean to say - check how it is addressed from the schematic?

Is there any deterministic approach to see how these memories are always arranged? I fear if they are synthesized from BMG again, the order might change?

Could you expand more on how to place the data at base address? And what is a he? You mean HW?

So the only way I can test that now is I see MCU execution without the merge. But because of something being wrong with the merging, I cannot see my MCU working. I also have an ILA which I can use to check data if necessary.

Regards,

Sundar

[stephenm]

I fixed the auto correct. The tools should be deterministic. If you don't make changes to the bmg, then this should be the same.

By place data at a base address. I mean create a mem file with a known value (for example 0x12345678), and place this in memory. Then read this for memory to see if it matches

[sundarbas]

Hi Stephen,

Thank you for helping me out with this.

I tried looking up the netlist of the BMG but it does not look very readable and the schematic has LUTs which make it difficult to decode the address spec.

I found that my order of Bus blocks could be wrong and have fixed it. But I am still not able to find out which is the correct order of the bus blocks because the addr[14:13] decoder logic is not visible as it is a LUT.

Please check if this would be the correct arrangement of the 32 BRAMs in Bus blocks as below:

              BL7         BL6       BL5        BL4         BL3         BL2         BL1        BL0

BB0       28           24            20           16           12            8              4              0

BB1      29             25            21           17            13           9             5               1 

BB2      30              26            22            18            14          10           6               2

BB3       31             27              23           19            15            11          7              3

I verified Bus Block 0 with few data coming out in a sim with an MIF file. But I cannot figure out why post update mem,  data cannot be read out properly. I am not sure what happens after update mem. 

Please let me know if there is a way to find out more evidence why merge does not work.
Also is there a way to compare contents of bitstream to find this out?

Regards,

Sundar

[stephenm]

I cant tell by tge screenshot alone. However, as I stated, you may just need to see how it look in HW.

[sundarbas]

Thank you for replying to me.

I have not been able to zero in on the issue yet. If I may trouble you with one more question:

The following is from the wiki you posted:
"As we can see here, the information from the BMM_INFO_* properties is used to populate this file too. For example the BMM_INFO_PROCESSOR property is used to populate the <processor> cell info. The BMM_INFO_ADDRESS_SPACE property is used to populate the <AddressSpace> cell, or cells if more than one BRAM controller. Finally, the bmm_info_memory_device properties is used to populate the <BusBlock> cells.

Users will also note, that the data is swapped (byte and nibble). For example for a 32 bit wide, 16 BRAMs would look like:

• 7:6, 5:4, 3:2, 1:0, 15:14,13:12,11:10,9:8,23:22,21:20,19:18,17:16,31:30,29:28,27:26,25:24

Similarly for 8 BRAMs (ie each block is 4 bits wide):

• 7:4, 3:0,15:12,11:8,23:20,19:16,31:28,27:24

However, this is just for the Microblaze. If users are using a non-processor flow with an external third party processor then the parsing here would depend on how the processor expects the data to be presented. "

Could you please explain this example with 8 BRAMs model with the data from MEM file

@00000000
0x12345678

How will the data be arranged?
00:0x78,

01:0x56,

02:0x34,

03: 0x12 

Is that right? My processor expects it this way. But my current MMI file is arranged 3:0, 7:4, 11:8, 15:12, 19:16, 23:20,27:24, 31:28.

I will try out this bit lane format and check if that works meanwhile. My byte nibble maybe swapped. Please let me know if my understanding is correct.
Sorry it will take another day for me to synthesize my HW again and i would like to see something conceptually first.

Update: It did not work with this change as well. Could you let me know if the version of the MMI file matters? I am using 2017.4 version of Vivado and 1.5 version of  MMI file.

Regards,

Sundar

[stephenm]

What do you read back from HW

MMI version should not matter here 

[sundarbas]

Hi Stephen,

I have the following data in my MEM file at a particular memory location:

0xFEDCBA98

When I sim with the associated MIF file (has no bearing to the update mem issue we face here) I get this

0xFEDCBA98

When I read it from HW post update mem, I get this:

0x98BADCFE

It sure does look like my Bit lanes are not in order, so I tried to change the MMI file accordingly and tried, it didnt work. It was almost as if the update_mem ignored my MMI file and populated with default values. Is that possible?

Also when I try to attach my MMI file, I get the following error - 

• The attachment's stingray.mmi content type (application/octet-stream) does not match its file extension and has been removed.

Is it indicative of any syntax/formatting issue with my file?

I have attached my MIF file without it being modified again(Uploading txt version of it). Could you have a look? Let me know if there are any issues with it or the order of the bit lanes? My read width is 4 bits out of 32 total of BRAM.

Regards,
Sundar

[stephenm]

There is a patch for updatemem that might be the reason for your issue:

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

[sundarbas]

Hi Stephen,

Do you know if this patch can be done for 2017.4 version of Vivado as well?

Regards,

Sundar

[stephenm]

should be OK in 2017.4

Can you post your MMI, and your updatemem command line

[sundarbas]

Hi Stephen,

Do you mean to say this patch will not be needed in ver 2017.4? That there is no issue? Or should I apply the patch and try?

Attaching my mmi file in txt format with this post.

My command line is: exec updatemem -force --meminfo stingray.mmi --data stingray_bootloader.mem --bit ${design_name}.bit --proc e21_core --out ${design_name}_merged.bit

Regards,
Sundar

[sundarbas]

Hi Stephen,

Thank you for letting me know. I tried the command line you provided and I was not able to comprehend from the dump.

I am attaching my files here, could you let me know how the merge is happening?

I have attached my MMI file, dump.txt, and bootloader.mem (which contains only one line @80000000 FEDCBA98 just for testing.

Also, do you know why I am unable to attach MMI and MEM files in their native file extensions in the forum here?

Thanks,
Sundar

[stephenm]

Can you strip your MMI down to just on bus block (attached), with a simple mem:

@80000000

12345678

[sundarbas · Accepted solution]

Hi Stephen,

I did some more testing with the debug option you provided:

exec updatemem -debug -force --meminfo stingray.mmi --data bootloader.mem --bit stingray.bit --proc e21_core --out stingray_merged.bit > bump.txt

I was able to change my MMI accordingly to make it work. Thanks for your help.

I think the Endianness specified in the MMI file does not work. This might need some addressing from Xilinx.

Thanks,
Sundar

[stephenm]

Great to see it all working now. only Little endiann is supported.