Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Axi4Stream user signal width should not be multiplied by data width #1294

Open
KireinaHoro opened this issue Jan 23, 2024 · 1 comment
Open

Comments

@KireinaHoro
Copy link
Contributor

In the current implementation the user signal in Axi4StreamBundle is defined to be dataWidth * userWidth:

val user = (config.useUser) generate Bits(config.userWidth*config.dataWidth bit)

This directly contradicts the scaladoc comment defining userWidth:

* @param userWidth Width of the User field in bits

The behaviour of enforcing the number of bits in user to be a multiple of number of bytes in data is, in the AXI Stream standard, a recommendation, but not a requirement:

It is recommended, but does not require, that the number of TUSER bits is an integer multiple of the width of the
interface in bytes. The User signals for each byte must be packed together in adjacent bits within TUSER

Furthermore, there is a use-case of transfer-based information, which is what I'm trying to do:

TUSER can be used to convey information that is relevant to an entire transfer rather than to individual bytes. For
example, when the same information applies to every byte in a transfer, it is more efficient to indicate the additional
information once only for the entire transfer rather than replicating it for each byte within the transfer.

In this case it does not make sense to enforce user to be a multiple of number of bytes in data.

@oletf
Copy link
Contributor

oletf commented Jan 24, 2024

related to #1252 if I've understood correctly,
there's an attempt here ce8d0ba in progress

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants