Axi4Stream: userWidth tied to dataWidth about spinalhdl HOT 5 OPEN

For user bits, I totally agree.

And yes, we have the problem that the current components are not spec compliant, so we either break old code or keep being incompatible with the spec.

I am not sure if there is a way to fix this. Maybe we can first change the implementation to deal with arbitrary user widths also, then change the API with new signatures?

I think the spec has higher priority and our implementation is incompliant.

(I have not used the SpinalHDL AXI Streaming components from the library for reasons like this.)

(I would even consider to allow for an arbitrary number of bits in the data width. For me it makes perfect sense to stream 12-bit video or image samples across AXI Stream.)

from spinalhdl.

The width of the TUSER (user) field can be any number of bits, according to the AMBA AXI 4 Stream specification.

Thus there is no implicit correlation between the data width and the user width.

Quoting the specification: TUSER width. Recommended number of bits is an integer multiple of the width of the interface in bytes.(https://documentation-service.arm.com/static/642583d7314e245d086bc8c9?token=)

The data width is typically specified in bytes; the specification requires this to be integer multiple of bytes.

In case we only want to allow the recommendation, the user width is a multiple integer number of bits for each byte in the data width.

Ideally though, we allow the number of user bits to be anything.

from spinalhdl.

ok so no I just got to an IP which has this :

So maybe it should be better to keep userWidth as bits,
keep the that.config.userWidth <= this.config.userWidth assert,
let the subdivideIn make slices being bits, and let the pairing make sure that.config.userWidth is a multiple of this.config.userWidth ?

from spinalhdl.

Thanks a lot for the clarification @likewise,
so as I get it,
the current choice has been to only allow the recommendation then.

Would an additional Boolean like userWidthIntMultiple true as default, to keep current code fully compatible,
but which could allow to opt-out of the recommendation for cases like the one in my first message (being 3:2),
be conceivable ?

from spinalhdl.

I'd be for allowing an arbitrary number of bits, I have seen a bunch of components that did not conform to the ARM recommendation.
If we allow something that is not an integer multiple of the data width then I don't see a reason why we'd limit it to bytes?

W.r.t. connecting: we could pre-pad with zeros in case the master is narrower then the slave, and create an error in case the master is too wide for the slave? (a user can then still manually resize if they know it's ok to throw bits away?)

The only question: how to do the change w/o breaking older code?

from spinalhdl.