08-26-2019 07:15 AM
I am using the ZCU104 Evaluation Board with a 16GB SODIMM DDR4 Module connected to the PL side and I want to access the 16GB of data via the Microblaze processor.
I am using extended addressing which is set to 64GB and assigned the DDR4 memory addresses from 0x4_0000_0000 to 0x7_FFFF_FFFF. I also have a system ILA connected to the M_AXI_DP interface between the Microblaze and the AXI_Interconnnect, and another system ILA connected to the M_AXI between the AXI_Interconnect and the DDR4 MIG IP.
The Instruction and Data caches are disabled in the design.
The Microblaze has the Memory Management Unit enabled and configured to 'USERMODE' as I do not want virtualization. I just need to access the data directly via the Microblaze.
In turn this sets the following parameters in xparameters.h:
Which should indicate that PAE is enabled and that the MMU is in USERMODE, according to UG984.
I then run code similar to the example in UG984 (pg.142):
u64 Addr = 0x0000_0004_0000_0000LL;
Byte = lbuea(Addr);
But I don't witness any transactions occuring on the System ILAs.
I also read (UG984) that the instructions LBUEA and SBEA are privileged and require C_MMU_PRIVILEGED_INSTR between 2 or 3. I edited xparameters.h to reflect these values but I still had no success.
Can anybody indicate what the problem might be? Or maybe indicate the proper procedure to use extended addressing? I can't find much material on this subject so any help would be greatly appreciated.
09-02-2019 02:22 PM - edited 09-02-2019 02:24 PM
It looks like we might be in similar predicaments... See:
The above post deals with accessing BRAM using a MicroBlaze with a 36-bit address bus, but we are having trouble accessing our 4-GB DDR4 interfaces, as well. (Problems occur using both 32-bit and 64-bit MicroBlazes...)
The only way we can get memory accesses to work, is by "compressing" everything to fit into a 4-GB space and resorting to a 32-bit-wide address for the MB.
Are you able to access your 16-GB DDR through other means--e.g., JTAG AXI or an IP?
09-05-2019 04:01 AM
09-05-2019 10:13 AM - edited 09-05-2019 12:01 PM
Thanks for the reply.
We've been finding it hard to get traction.
We were able to write to BRAM (but not DRAM) yesterday using one design, but I'm not 100% sure that design wasn't compressed to 32-bits. (SW needs some HW to keep working, so we've provided them with a compressed design that fits into a 4-GB/32-bit address space.) That success has not been reproduced today.
We streamlined our 2018.3 version of a design somewhat by simplifying the AXI Interconnect, to aid in debug:
We then instrumented it with an ILA, and noticed this:
Somehow, the top 4 bits of the AXI Write Address are being presented as "F", instead of "0". The actual XSCT command was mwr -size D 0x90000000 0xaaaabbbbccccddd'. That's preventing a properly decoded access to BRAM (address 0x9000_0000). Note the "dec0de1c" being returned from AXI Interconnect as Read Data--because it has no idea what to do with the (erroneous) address(es) being presented to it.
Somehow, the MicroBlaze and XSDB/XSCT are not operating as expected. We are hoping that the means and methods to get it all working are simply eluding us right now.
09-06-2019 12:33 AM
As far as I know, the SW tools in 2019.1 only handles up to 40 bit address, unless you enable position independent code.