Issue with RoB

[mivicTT]

I think there might be an issue when using a RoB, since it doesn't differentiate AR/R and AW/B case, leading to either needing a huge RoB for writes or a big performance degradation. The RoB allocates space for the entire AXI burst, as in floo_rob line 350:

  // Mark the entries in the reorder buffer as occupied
  // Only the last entry is set to 1 which is enough, since
  // the free buffer size is just calcluated with a leading-zero-counter
     rob_alloc_d[rob_next_free_idx + ax_len_i] = 1'b1; 

which makes sense for reads since the response is a burst of data, but for writes the response has length one. This leads to allocating a lot of unused space in case of burst writes, the RoB fills up a lot quicker than it should and new write requests are stalled.

A simple fix could be in floo_nw_chimney when instantiating RoBs for AW/B, with ax_len_i tied to '0 instead of len of AXI request.

[fischeti]

You are right! the RoB does not account for this. I didn't focus too much on B responses reordering, since most of our traffic is read based, and we also kind of moved away from the RoB implementations since we believe handling the ordering in the endpoints themselves is more efficient.

But I think the fix you suggested should work, and I can add this quickly. Btw, the RoBs are not super well tested however and it could be that there are more issues with them.