Weighted round robin arbiter allows each requestor a share of the common resource which is relative to its predefined weight. For example, if two requestors have the weight of 3 and 7 respectively, then over a long period of time, assuming both requestors always have their request asserted, the first one will get 30% of the grants and the second will get 70% of the total grants.

A weighted round robin arbiter design with a total of 3 requests, i.e., req[2:0], is shown in the Verilog code below.

The design consists of 2 parts: a credit mask logic and a normal round robin arbiter. The credit mask logic generates the masked version of requests and feeds them into round robin arbiter. The round robin arbiter produces the final grant.

The credit mask logic keeps one credit counter for each request, indicating number of credits used by the request so far, and the initial values of the credit counters are all 0. The corresponding credit counter increments when the arbiter grants the request, and the request will be masked out if it reaches its threshold. All credit counters will be reset to 0 when none of the asserted requests have credits, and the next cycle starts.

7 Comments

  1. Hi, I would suggest you changing max_thre to be an array to indicate the different weights for each request, because the code shown here doesn’t really reflect weighted grant behavior.
    Here is what I modified

    input [2:0][$clog2(MAX_THRE+1)-1:0] max_thre,


    assign has_crd[i] = (crd_cnt_incr[i] <= max_thre[i]);

    For example, if max_thre is [2,3,5], it turns out to be the req[2] get 5/10 grants, and req0 and req[1] gained 2/10 and 3/10 respectively.

  2. Hey can u explain by examples for the case of 1:3:5 weights in the above code

    1. same as rrb_arb in the last line u need to add
      assign grant = (mask_req == ‘0) ? raw_grant : mask_grant;

      to make it work for continuous requests like of this type req=3’b001 for a long period of time.

  3. In the line number 30 u need to make
    assign has_cred[i] = crd_cnt_incr[i] <= max_thre[i];

  4. Hello,

    I believe the decode for “replenish” must factor an additional term that ensures a request is present. Otherwise, lack of requests will replenish the credit counters.

    Current version:
    assign replenish = ((req & has_crd) == ‘0);

    Modified version:
    assign replenish = (req != ‘b0) && ((req & has_crd) == ‘0);

    Does this look reasonable?

    Regards,
    Adithya

  5. Great explanation.
    I have one question though!
    Why should we replenish when you have no requests at all. Shouldn’t ‘everyone’s credit being saturated’ be enough to say we are good to replenish?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.