08-11-2016 02:46 PM
I've created a simple block design in Vivado consisting of a microblaze, one DDR4 MIG, UART, and associated components to hook it all up. Synthesis/implementation completes without error. Address editor shows the "ddr4_0" range at offset "0x8000_0000", size 2G. As far as I'm aware this is all correct and matches what my board (VCU108) has available for the first DDR4 channel.
From here I can generate the bitstream and hardware .hdf files for importing into the SDK. No errors there. Within the SDK I can look at the linker script and see that it correctly identifies "ddr4_0" as a memory region at the correct offset and size.
So long as I tell the linker to map everything into the small local memory ("microblaze_0_local_memory_ilmb_bram_if_cntlr_microblaze_0_local_memory_dlmb_bram_if_cntlr") programs can be loaded and execute fine. UART works, memory test of the ddr4_0 address space pass, life is good. If I map stack/heap onto ddr4_0 it works fine as above. If I map any critical ELF section into ddr4_0 the code never starts, no errors from the tool. That's using Vivado's "Associate ELF" and re-building the bitstream path to programming.
If I attempt to program from the SDK I obviously have to load in the bitstream and BMM/MMI from the implemented Vivado project. During the process of building the new bitstream it reports a critical error:
CRITICAL WARNING: [Updatemem 57-154] Matching address space for code segment 1 not found. Code segment occupies [0x80000000:0x80001D63]
ERROR: [Updatemem 57-153] Failed to update the BRAM INIT strings for [sdkproject]/Release/ddr4_c.elf and [vivadoproject]/[vivadoproject].runs/impl_1/mb_wrapper.mmi.
Manually examining the MMI file being loaded shows two Address Spaces identified:
<AddressSpace Name="mb_i_ddr4_0_inst_u_ddr4_mem_intfc_u_ddr_cal_riu_mcs0_microblaze_I.mb_i_ddr4_0_inst_u_ddr4_mem_intfc_u_ddr_cal_riu_mcs0_lmb_bram" Begin="0" End="98303"> <AddressSpace Name="mb_i_microblaze_0.mb_i_microblaze_0_local_memory_dlmb_bram_if_cntlr" Begin="0" End="8191">
I don't know why it's identifying the ddr4_0 as 96kB long and makes no mention of the offset. I presume it's this mismatch that's causing the critical error and preventing the programming process from correctly populating that address space. The local memory is correctly identified as 8kB.
Manually generating a BMM from Vivado using write_bmm <filename> shows similar results:
ADDRESS_SPACE mb_i_ddr4_0_inst_u_ddr4_mem_intfc_u_ddr_cal_riu_mcs0_lmb_bram COMBINED [0x00000000:0x00017FFF]
Size concurs with the MMI but I don't know why it doesn't match the expected 2G.
Thoughts? I'm new to the Virtex Ultrascale family but I've used this workflow on older boards without problems.
08-11-2016 10:42 PM
08-11-2016 10:42 PM
08-26-2018 11:03 PM
Actually, the topic of the AR is "Vivado IP Integrator - How to populate the BRAM in processorless IP Inegrator systems". It implies that the AR is suitable for the projects without processors. It is not applicable for the current problem. As antoshre mentioned, "I've created a simple block design in Vivado consisting of a microblaze, one DDR4 MIG, UART, and associated component to hook it all up." There is a procesor, i.e., microblaze in the project.