cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
361 Views
Registered: ‎02-12-2019

Help with accessing wide data width BRAM from PS through AXI BRAM controller

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:

image.png

image.png

 

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.

Tags (2)
0 Kudos
5 Replies
Highlighted
Moderator
Moderator
334 Views
Registered: ‎06-30-2019

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.

 

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
294 Views
Registered: ‎02-12-2019

Hi shengjie, thanks for getting back. Thought i had posted the block diagram but it didn't show up. Here it is again:

image.png

And here is the settings on the controller and BMG:

Controller:

image.png

BMG:

image.pngimage.pngimage.png

0 Kudos
Highlighted
Visitor
Visitor
291 Views
Registered: ‎02-12-2019

@shengjie 

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?

image.png

0 Kudos
Highlighted
Moderator
Moderator
235 Views
Registered: ‎06-30-2019

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.

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
157 Views
Registered: ‎02-12-2019

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:

image.pngAnd here is the new waveform:

image.png

Address mapping:

image.png

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:

image.png

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?

 

0 Kudos