Fix strb of Axi4Master (spinal.lib.bus.amba4.axi.sim)

[Nik-Sch]

Context, Motivation & Description

The strb for the Axi4Master (sim) was wrong for aligned transfers with len>0. I fixed this and added a simple testbench that verifies the Axi4Master against the AxiMemorySim.

Impact on code generation

None

Checklist

• Unit tests were added
• API changes are or will be documented:
  • using Scaladoc comments: /** */?
  • on RTD?
  • thanks to a new tracking issue on RTD?

[Dolu1990]

Hi,

(~((BigInt(1) << padBack) - 1)) & ((BigInt(1) << bytePerBeat) - 1)

Does it work for burst where size is smaller than the whole bus width ?
Seems like & ((BigInt(1) << bytePerBeat) - 1) will not work in all cases (last beat not finishing at the start of the data word.

[Nik-Sch]

Yes, you are correct, there were some weird bugs...
I added tests for unaligned transfers and fixed the problems. Should I test something else?

[Dolu1990]

I don't understand why there is actualLen ?
What is the purpose of the len argument then ?

[Nik-Sch]

When the len a larger transaction than the data.length (i.e. (len + 1) * bytePerBeat > data.length), the axi4master would issue more beats (transfer in axi notion) after the last data transfer. This would lead to zeros (at least in verilator) being written after the actual last byte.

This often happens when using the write or writeCB function where multiple transfers are initiated until the data is exhausted. I could also move the actualLen calculation to writeCB but I found it quite unexpected behavior that the master would write (a lot of) zeros (with active strb) after the data I want it to write.

[Dolu1990]

My understanding so far was that the len parameter is the number of beat, not the number of bytes in the data.
See the asserts : assert(len <= 255, s"max burst in one transaction is 256")

[Nik-Sch]

Yes, len specifies the number of transfers (beats in this naming here) in one transaction (off by one per axi standard). But the old version of the AXI Master would always issue a full transaction regardless of how many data bytes are provided.
An example:

• data.length = 20 (20 bytes)
• size = 3 -> bytePerBeat = 8
• len = 7 -> 1 transaction is 8 transfers of 8 bytes each, resulting in 64 written bytes.

In the old implementation this would have written the 20 input bytes at the specified address and then additionally 44 bytes 0x00. I fixed this by using the len parameter rather as a maxLen and then calculating the actualLen to be 2 (3 transfers) where the strb in the last transfer is set such that only 4 of the 8 bytes are written.