Hi,
I have a problem with the signals that i received on my slave for the PS. The problem its when I declared not cacheable the memory spaced asigned to the interfaces of the M_AXI_XX (XX its LPD or FPD depends of the core) the behavior changes.
The three write channels works at expected but when you ask for a reading the signals change.
Am example its:
memcpy(0xA0000000 , datos,8);
memcpy(datos_read,0xA0000000,8);
The axi_width its 4 bytes and the memory is aligned with 8 bytes. The core of the APU its a cortexa_53 with a bus width of 16 bytes.
On this case the values of the signals on the write channel are AWSIZE = 2 and AWLEN = 1 which its interpreted as a writing of 8 bytes and the values of the signals on the read channel are AWSIZE = 2 and AWLEN = 3 which its interpreted as a reading of 16 bytes.
When I change the axi_width to 16 bytes.
On this case the values of the signals on the write channel are AWSIZE = 4 and AWLEN = 0 which its interpreted as a writing of 16 bytes and the values of the signals on the read channel are AWSIZE = 3 and AWLEN = 0 which its interpreted as a reading of 16 bytes but in this case the Write Strobes signals are enabled with a value of FF00 therefore the reading should be 8 bytes.
If anyone has any idea what might be going on. I'd appreciate it.
PD: The AXI its declared as a full AXI transfer.
The question is probably better suited for posting on a Xilinx message board, but just looking at this from an AXI perspective...
You are getting a bit confused with the AXI signal names as you use AW signal names for both read and write transfers.
On the 32-bit bus (axi_width = 4 bytes), the write transaction uses AWSIZE=2 (32-bit, 4 bytes) and AWLEN=1 (2 transfers), so a maximum of 8 bytes written (depending on what WSTRB indicated).
Then the read access on the 32-bit bus uses ARSIZE(?)=2 (32-bit) and ARLEN(?)=3 (4 transfers), so 16 bytes as you stated. This does make me wonder if the transaction was actually performed as cacheable, so fetching in a full cache line of 16 bytes into the A53, even though only 8 bytes were needed. What did ARCACHE indicate for this transaction ?
Then on the 128-bit bus (axi_width = 16 bytes), the write transaction uses AWSIZE=4 (128-bit, 16 bytes) and AWLEN=0 (1 transfer), so yes, 16 bytes. You later mention that WSTRB=FF00 for the read, but as there are no WSTRB signals on read transactions I assume you meant for this write, so only 8 bytes actually requested.
However as AWADDR=0xA000_0000 I would have expected WSTRB to be 00FF so that it is the lowest 8 bytes that were written. Can you check the WSTRB value, or else was AWADDR driven to 0xA0000008 which would then mean you are using the upper half of the 128-bit data bus for the 8 byte write, and so WSTRB could then be FF00 ?
Then the final read, using ARLEN(?)=3 (64-bit, 8 bytes) and AWLEN=0 (1 transfer), you have an 8-byte read, not the 16 bytes you describe. Can you check that ARSIZE was not actually 4 for this transfer so that it is a 16-byte read, which would then match the 16-byte (possibly cacheable) read we saw earlier ?
Hopefully that gives you a few facts to check in your question so that it reads more clearly, but I would think that as you are asking about a Xilinx board implementation of an AXI system it would be better asking on a Xilinx forum (unless anyone here knows what the issue might be).
Yes, sorry my write strobe are as you say, but my memory space associated with the three master channels of the ps (0x8000_0000, 0xA000_0000, 0xB000_0000) are asigned as not cacheable with the following command:
Xil_SetTlbAttributes(0xA000_0000,NORM_NONCACHE); on the cortexa_53 space.
Xil_SetMPURegion(0x8000_0000, 0x80000,PRIV_RW_USER_RW | NORM_NSHARED_NCACHE);
The ARCACHE and AWCACHE are set on 0011
Unfortunately then I can't explain why you are seeing this behaviour on the AXI bus. A non-cacheable read shouldn't then result in a longer burst which I was guessing would be a cache line fill.
It is almost certainly something specific to this Xilinx board you are using, so you would be much more likely to get an intelligent reply if you ask on a Xilinx discussion board (as opposed to my guesses).