GenericAxiMaster wrap around of dynamic address part

[timksf]

Wrap around of dynamic address part in GenericAxiMasters

Hi, I've encountered an issue with the generic axi masters.
Following situation:

• start address: 0x6d900000
• address_width: 32
• amount_width: 24
• data width: 128
• burst size: 256

  This leads to the following widths for the address partitioning:

• address_static = 7
• address_dynamic = 13
• address_offset = 12

  The start address then looks like this: $$0110110 | 1100100000000 | 000000000000$$

A single burst has an address increment of Since the first burst will not cross a 4096 barrier, addressing starts with the start address 0x6d900000. The issue is now that there is a certain amount of bursts, after which the dynamic part of the address wraps around, this amount of bursts does not cover the whole range of the $24$ amount bits though: The dynamic range is offset by some amount, the max. number of bytes that can be transferred before the wrap around is: This equates to the following number of bursts: Burst number $1791$ starts with address translating to The next burst, burst number $1792$, wraps around the dynamic address to $0$ and thus starts with which is even below the start address.
To combat this, the start address needs to be taken into account when deciding on the width of the dynamic part of the address. The issue is that the widths have to be calculated at compile time which would take away the flexibility of being able to dispatch multiple requests with different starting addresses. I think that the address partitioning was introduced to have slimmer logic for calculating new addresses (?). The somewhat "dirty" fix I used, was to also increase the then-not-so-static-anymore part of the address, when the dynamic part wraps around. Maybe there could be an optional Parameter for that. This kind of defeats the purpose of the partitioned address I think. Choosing more amount bits solves the issue in this case as well but I don't think thats a good way of handling it either. If you have any other fixes or if this problem is beyond the scope of the intended use cases, let me know!

Please excuse the use of screenshots, I could not get the math environment working properly.

[jahofmann]

Thank you for the bug report. You're right, many of the design decisions trim the Generic AXI master for performance. The first target of the code is the BlueDMA used in TaPaSCo, which had to run at 250MHz on Virtex 7 devices. Without the precalculation this wasn't possible.

Using the static part might still be possible when you can predict that you have to increase and do that in the next cycle. Doing it in the same cycle with the dynamic part calculations might introduce a too long critical path.

I'll have to look at the code to see if I have another idea.