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

[mhayat-10xe]

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?

[niwis]

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]

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]

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

[mhayat-10xe]

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

[niwis]

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: https://github.com/pulp-platform/common_cells/blob/69d40a536665ab9c8f0066ee48b139579df7fccd/src/rr_arb_tree.sv#L23-L25