If I did not get the axi specification terribly wrong or misunderstood the mentioned modules, there is an issue with the address increment:
The generic axi masters mkAxi4MasterRead and mkAxi4MasterWrite appear to not use the correct increment for cases in which
the total burst size is not the max. size of 4096 bytes and where the first burst crosses a 4096 barrier. Currently, the increment always is bytesPerFullBurst(), regardless of a shorter burst in the beginning, which aligns the following bursts with the barriers. This should be adjusted to the actual amount of bytes that are transferred in a transaction.
To illustrate this, here is an image written to a RAM model with the current code, where the first burst will cross a barrier:
You can see that there is a black gap after the first few pixels (second row), which leads to the rest of the image being shifted. The gap represents addresses, which are, as a result of the wrong increment, skipped by the Axi4Master.
Hello,
If I did not get the axi specification terribly wrong or misunderstood the mentioned modules, there is an issue with the address increment: The generic axi masters mkAxi4MasterRead and mkAxi4MasterWrite appear to not use the correct increment for cases in which the total burst size is not the max. size of 4096 bytes and where the first burst crosses a 4096 barrier. Currently, the increment always is
bytesPerFullBurst()
, regardless of a shorter burst in the beginning, which aligns the following bursts with the barriers. This should be adjusted to the actual amount of bytes that are transferred in a transaction. To illustrate this, here is an image written to a RAM model with the current code, where the first burst will cross a barrier: You can see that there is a black gap after the first few pixels (second row), which leads to the rest of the image being shifted. The gap represents addresses, which are, as a result of the wrong increment, skipped by the Axi4Master.Regards, Tim