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

Round robin arbitration is not properly implemented in stream_xbar.sv module #212

Open
mhayat-10xe opened this issue Jan 30, 2024 · 5 comments

Comments

@mhayat-10xe
Copy link

mhayat-10xe commented Jan 30, 2024

I am currently working on the formal verification of the stream_xbar. During my analysis, I have identified an abnormality in its behavior.

In the 2nd clock cycle of the picture below, we have requests for output number 4 simultaneously. However, in the 3rd clock cycle, idx_o[4] serves input number 3, which is incorrect. It should serve input number 2 first, and then input number 3 should be served afterward. Is this a bug or a lack of understanding from my side?

Screenshot from 2024-01-30 21-13-36

@niwis
Copy link
Collaborator

niwis commented Jan 31, 2024

Hi @hayat10x, the round-robin arbiter has an internal state that determines which input is served in the current cycle. The output of stream_xbar depends on that initial state. Does this answer your question, or could you elaborate on why you expect input 2 to be served first?

@mhayat-10xe
Copy link
Author

Hello @niwis, I've configured the design with FairArb set to 1 and Extprio to 0. When Extprio is set to 0, the design internally calculates the priority. With FairArb set to 1, the design prioritizes the next unserved request with a higher index.
So, if input 1 is served in the second cycle, the design should prioritize the next unserved request with a higher index in the third cycle, which in this case should be input 2, not input 3.

@niwis
Copy link
Collaborator

niwis commented Jan 31, 2024

Can you observe rr_q inside the round-robin arbiter? could you share the waveform corresponding to the case above?

@mhayat-10xe
Copy link
Author

sure, I have attached the rr_q of output number 4.
image

@niwis
Copy link
Collaborator

niwis commented Feb 2, 2024

Hi @hayat10x, would this statement explain your observation?

The arbitration tree will choose the input with the same index as currently defined by the state if it has an active request. Otherwise a random other active input is selected.

from here:

/// `ExtPrio` is `1'b1` this state is provided from the outside.) The arbitration tree will
/// choose the input with the same index as currently defined by the state if it has an active
/// request. Otherwise a *random* other active input is selected. The parameter `FairArb` is used

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