05-27-2020 05:10 PM
Let the saga begin...
So i have bd that includes a True dual port 256 bit wide BRAM in BRAM controller mode, with one port connected to the AXI BRAM controller IP and the other one as an external connection which will be connected in the fabric later on, as shown in the screenshot below.
To verify the design, I wrote couple of lines in the SDK to memcpy data to the BRAM base address. Here is the function:
void single_write(){ char buf[64]; for (int i = 0; i < 64; i++){ buf[i] = i; } memcpy((void*)XPAR_BRAM_0_BASEADDR, buf, sizeof(char)*64); }
The code basically fills the data buffer with 64 bytes of data, from 0x00-0x3F, then write to the bram base address via memcpy. After executing the function, it seems the memory viewer of the BRAM address space does not reflect the data written to the BRAM, as shown here:
From the ILA, it seems the data was going through the AXI interconnect, to the AXI BRAM controller, than to the BRAM. But the data read back seems completely off, both from the memory viewer and memcpy() from base address back to the buffer. What am I missing here?
Beside this problem, couple of questions on the AXI operation:
1. Per the ILA it seems the write was done in narrow bursting. My understanding of narrow bursting is that it only happens when data being sent is less than the data width of the BRAM. In this case, the data sent over is in multiple of 256 bits. Why did narrow bursting kick in?
2. Again from the ILA, it seems the data was written starting from 0x0020, rather than 0x0000. Is this normal?
Thanks in advance. Any help is much appreciated.
05-27-2020 07:52 PM
Hi @yeungt2 ,
It looks like a cache problem.
Maybe you can try to add "Xil_DCacheInvalidateRange(XPAR_BRAM_0_BASEADDR, sizeof(char)*64);" after memcpy, or just disable cache at the beginning of main() function.
As for AXI operation:
1. Can you share Block Design and highlight the AXI interface especially data width.
2. Did you mean data written to bram from 0x0020? That is not right. Data will be written to bram when we and en signals are high. So the start address is 0x0 then 0x0020.
05-28-2020 05:50 AM
Hi shengjie, thanks for getting back. Thought i had posted the block diagram but it didn't show up. Here it is again:
And here is the settings on the controller and BMG:
Controller:
BMG:
05-28-2020 06:00 AM
I've also tried invalidating the Dcache range and disable DCache with Xil_DCacheDisable() just before executing any write/read, that did not seem to help. As per your comment on #2, it seems the AXI address from the master is pointing to 0x0020 on the first write but on the BRAM side it looks correct. Could there be some address translation issue or maybe related to the address width mismatch between the controller and bram?
05-28-2020 07:40 PM
Hi @yeungt2 ,
AXI write address channel(AW) and write data(W) channel are independent.
Slave gets the first target address 0x0 when awvalid and awready handshakes. Then slave gets valid data when wvalid and wready handshakes. There is noting wrong on the waveform.
Can you try to reload memory UI and check the data? Or you can use "mrd <address>" instruction in XSCT to check data.
06-11-2020 01:41 PM
Sorry for the lack of response, was delayed by some other issue. So i changed up the design a little, instead of using smartconnect i went with the normal interconnect. Here is the updated design for the BRAM:
And here is the new waveform:
Address mapping:
Code i'm using to issue the write. Note that i did issue Xil_DCacheDisable() prior to calling this function
void single_write(){ char buf[64]; for (int i = 0; i < 64; i++){ buf[i] = i; } memcpy((void*)(XPAR_BRAM_0_BASEADDR), buf, sizeof(char)*64); }
Memory monitor:
mrd from xsct:
xsct% mrd 0xa0008000 10 A0008000: 00000000 A0008004: 00000000 A0008008: 00000000 A000800C: 00000000 A0008010: 00000000 A0008014: 00000000 A0008018: 00000000 A000801C: 00000000 A0008020: 00000000 A0008024: 00000000
@shengjieafter studying the waveform a little more I do agree that handshaking looks correct. But somehow the data isn't getting commited to the BRAM. The data and control appear to be correct at the BRAM. Any ideas?