11-29-2018 08:06 AM
How to force the PS axi master to do the burst transactions to PL slave. I've tried using memcpy() function. But, it does the burst length of 4 irrespective of the array length of the variable mem32burst.
u32 pl_base_addr = 0x80000000; //M_AXI_LPD port u32 mem32burst ;
//Write Data for (int id=0; id < 16 ; id++) mem32burst[id] = 0xA5A5+id;
//Burst Write memcpy((u32*)pl_base_addr , mem32burst, 16*sizeof (u32)); //Reset Array for (int id=0; id < 16 ; id++) mem32burst[id] = 0x0000; //Burst Read memcpy(mem32burst, (u32*)(pl_base_addr), 16* sizeof (u32));
P.S. I use vivado 2017.4 and using ILA to monitor the AXI transactions.
11-30-2018 01:19 PM
This looks like standard C code running on one of the ARM processors in a Zynq PS.
The short answer is that you are probably getting the best performance you can for the default MMU or MPU settings. (MMU is for A-series processors, MPU is for R-series processors.) SDK defaults the PL memory regions, like the one at 0x8000_0000 in MPSoC, to use Strongly Ordered or Device-nGnRnE settings. This means that hardware is not allowed to combine read/write accesses into longer bursts. The initial size and length of the request must be honored. SDK uses this because it is a safe setting and ideal for code that talks to registers.
Depending on your requirements, you might consider changing the MMU settings for the 0x8000_0000 region of interest to either Normal Non-cacheable or Normal write back cacheable. (There are functions in xil_mmu.c to do this.) If you are moving a lot of data between memory regions, you may also want to consider using one of the DMAs in the PS.
12-04-2018 02:40 PM
>> SDK uses this because it is a safe setting and ideal for code that talks to registers.
How does SDK know if the address is Register/Memory? Can I force to SDK to treat the address as memory ?
>>you might consider changing the MMU settings for the 0x8000_0000 region of interest to either Normal Non-cacheable or Normal write back cacheable.
When I changed the settings, the application hangs at a line where memory read/write happens. Any idea why it could happen?
>> you may also want to consider using one of the DMAs in the PS.
No, There is not much data to go for DMA.