AXI manager's memory address offsets

[nathanielnrn]

This was initially a mail I sent to @andrewb1999 and @rachitnigam. Posted here to open up discussion with slight changes.

I anyone has any ideas I'd love to hear them to help move things forward.

I have the outline of a cocotb test harness using AXI rams as suggested by @andrewb1999. My main problem is knowing the addresses we need to be writing our data to.
Looking at waveforms, in dot product and vadd the addresses are 0x0000, then 0x1000, then 0x2000 for each successive memory.

Similarly, in the cocotb-ext examples, this 0x1000 increment appears as well

Based on the kernel.xml for vadd, I don't see a correlation between this file and the addresses we're looking for. So in general it's not obvious to me where these addresses come from. If the source of these offsets could be found, it should be pretty easy to make a generalized test harness.

@sampsyo Raised the idea that maybe this 0x1000 (4096 base 10) is the result of chunking of our AXI bus of width 512.

Currently work is being done on hard-coded tests (this one is vadd). ATo try to find the source of the offsets I'm considering looking at PYNQ's source code to try to get a better understanding of things (mainly how the subordinate control_axi WDATA channel, which propagates to axi manager base offsets, is controlled).

[nathanielnrn]

So looking at things today, it seems as if this whole incrementing address business is only relevant for the host? Internal bram addresses are calculated separately and do not involve the BASE_OFFSET the managers do. The AW and ARADDR ports are only output to the host, which in the case of PYNQ seems to do it's own magic and is happy with the addresses we've been sending it so far. Guess this seemed to be a bigger problem than it actually is. For now things seem to be okay regarding cocotb and these weird addresses (although they may cause problems down the line if they aren't correct).

[nathanielnrn]

So this turns out to be seemingly not important, closing this.