03-19-2020 12:20 PM
I have an embedded microblaze application with some typical IPs (uart, timers, etc). The part I am using is spartan XC7S25 which includes 45 block RAMs (202.5 KB). Most of my IPs use logic cells only. The block RAM is mostly used as a microblaze memory space. Initially I have vivado address editor allocating 128KB of RAM for microblaze but I am running out of code space. Allocating 256KB results in an error as expected. Is there a way to allocate a different memory range than the ones available in the drop box list (ex: 192KB) (see attached screen shot for reference). This will solve my code space issue and better utilizes my FPGA resources.
03-20-2020 12:47 AM
Hi @mustafa.homsi ,
If you try the Tcl command to allocate different memory range
The size of all address ranges must be a power of 2, as determined by 2**Mmm_Aaa_ADDR_WIDTH.
The Mmm_Aaa_BASE_ADDR of all ranges must be aligned to (integer multiple of) its size. There must
be no overlap among all address ranges across all MI slots configured in the AXI Crossbar. Unused
address ranges are designated by setting Mmm_Aaa_ADDR_WIDTH = 0 and setting BASE_ADDR to all
ones (0xFFFFFFFFFFFFFFFF). AXI Crossbar does not support address remapping. you can find more details here.
You can assign address range depends on the starting address such that the end address will not cross over (or in another words, no carry over) to the next bit.
If you assign the offset address as 0x40020000, you can set the range to be 128K, which mean 0x40020000 to 0x4003FFFF.
Another workaround you could consider is to access DDR memory by CDMA or VDMA.
Even if you do not partition in Vivado address editor, it is fine. But you need to make sure that VDMA is configured to store the frames in corresponding memory. As generally DDR huge enough, you may not face any constraints.
Please let me know if you still need more assistance.
03-20-2020 01:46 AM
The reason for the 192KB not working is that donw the line the updatemem would be needed to populate the BRAM. For a 192KB, this would lead to memories of different bitlanes which updatemem doesnt support.
You could however, just add a 128 + 64 in concat (one after the other). You would need to manually update your linker.
Also, your MMI would have two ranges. So, you would need to convert your elf to mem and do the split manually too.