add round-robin distributor

[micprog]

No description provided.

[andreaskurth]

This does not guarantee that a valid_o remains high once asserted until the handshake, correct? Many of our modules that work with valid/ready assume this property (borrowed from AXI handshakes), because it makes handling inputs much easier

[micprog]

Doesn't it? valid_o will only be high if ready_i is high (and valid_i is high), meaning that whenever valid_o is high the handshake completes, and isn't high otherwise.

[andreaskurth]

You are totally right, I don't remember why I asked this. 🙂

But I see another problem with this code: For the output handshake, valid_o depends on ready_i, but the rule in valid/ready handshaking is that ready can depend on valid, but not vice-versa (to prevent combinatorial loops).

Fortunately, the fix should be relatively simple:

always_comb begin
  valid_o = '0;
  valid_o[rr_q] = valid_i;
end
assign ready_o = ready_i[rr_q];

[andreaskurth]

Is it intentional that the counter increases in cycles when there is no handshake? Or should this condition be valid_i && ready_i[rr_q] (or, equivalently after the change above, valid_i && ready_o)?

[micprog]

@thommythomaso is this intentional?
It being intentional would make sense to me, as in this case a valid will be served within a few cycles if any subordinate is available, even if the next in the rr distribution scheme is not ready yet (e.g. stalled for 100s of cycles). With the change discussed above, this may cause deassertion of the valid signal however, which would be against the ready/valid rules. However, not implementing the change above is also against these rules. I currently don't see a clean way to implement this feature while conforming to ready/vaild handshake rules.

[andreaskurth]

Indeed. I suggest we clarify what "forwards requests to individual outputs in a round robin fashion" means in conjunction with valid/ready handshaking.

If that is not possible or does not make sense, an option could be to relax to req/gnt handshaking (where req can be deasserted without gnt, but req must still not depend on gnt).

[andreaskurth]

Thanks for the clarification!

Now, is StrictRR = 1'b0 an actual use case? Also asking @thommythomaso?

[micprog]

The behavior outlined by StrictRR = 1'b0 is currently used in the HERO dma implementation as far as I know, allowing for automatic distribution of dma transfers of different lengths. This way, if many requests are issued (> number of channels) and some are extremely long, the next transfer will be issued as soon as a dma is available, instead of waiting for the next channel in line to be available.

[andreaskurth]

I understand, thanks for the explanation.

Wouldn't it make sense to reverse the handshake on the output interface? That is

// output stream
input  logic  [NumOut-1:0] req_data_valid_i,
output logic  [NumOut-1:0] req_data_ready_o,
output data_t [NumOut-1:0] data_o,
output idx_t               sel_o

Downstream modules could then request data through req_data_valid_i as soon as they are available, and the rr_distributor can select one of them and set its req_data_ready_o.