03-25-2019 07:37 PM
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
04-03-2019 10:59 AM
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
03-26-2019 03:13 AM
There is a wiki beliw that you can use to create the MMI manually:
03-26-2019 08:17 AM
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
03-26-2019 01:41 PM - edited 03-27-2019 01:09 AM
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?
03-26-2019 03:45 PM
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
03-27-2019 01:12 AM
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
03-27-2019 08:59 AM - edited 03-27-2019 09:06 AM
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
03-27-2019 09:10 AM
I cant tell by tge screenshot alone. However, as I stated, you may just need to see how it look in HW.
03-27-2019 11:17 AM - edited 03-27-2019 11:36 AM
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:
Similarly for 8 BRAMs (ie each block is 4 bits wide):
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
03-27-2019 12:59 PM
What do you read back from HW
MMI version should not matter here
03-28-2019 10:14 AM
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 -
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
03-28-2019 10:19 AM
There is a patch for updatemem that might be the reason for your issue:
03-28-2019 10:41 AM
Hi Stephen,
Do you know if this patch can be done for 2017.4 version of Vivado as well?
Regards,
Sundar
03-28-2019 10:44 AM
should be OK in 2017.4
Can you post your MMI, and your updatemem command line
03-28-2019 10:52 AM
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
04-01-2019 07:40 AM
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
04-02-2019 04:50 PM
04-03-2019 10:59 AM
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
04-03-2019 12:43 PM
Great to see it all working now. only Little endiann is supported.