-
Notifications
You must be signed in to change notification settings - Fork 145
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
Comments
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? |
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. |
Can you observe |
Hi @hayat10x, would this statement explain your observation?
from here: common_cells/src/rr_arb_tree.sv Lines 23 to 25 in 69d40a5
|
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?
The text was updated successfully, but these errors were encountered: