Handling Traffic

DESCRIPTION:

If you looked inside a router, one logic block you would most definitely find is a packet scheduling arbiter that selects which of the multiple incoming channels gets to go out first.

Interestingly, the design of the arbiter forms the basis of several ethical, legal and political debates around ‘Net Neutrality’. You are encouraged to read more about this.

An arbiter is simply the traffic signal in a router, SOC or memory sub-system that allows multiple masters to access the same shared resource (here: data bus, peripherals, memory) based on pre-established rules and priorities.

An arbiter can be quite simple or quite complex based on the system requirements. For example, in a design where there is a fixed priority order assigned for different channels, the arbiter is simply a cascaded if-else condition. On the other hand, many practical situations are not that simple. A fixed priority arbiter has the major problem of letting one requestor monopolise the bus and prevent any other requestor’s transactions from ever going through.

This brings about metrics like ‘fairness criteria’ which measure how fair the arbiter is by design in the sense that will every request be serviced within a reasonable time frame or will possibly be blocked indefinitely.

A round robin arbiter is one design that addresses this problem by ensuring every requestor gets access to the resource for an equal amount of time.

A weighted round robin arbiter cleverly brings a tradeoff between the criterion of fairness and that of unique priorities between channels. It does this by letting the user specify a relative measure of how long each requestor needs the bus once it is given access to it in the form of weights. Eg: if requestor A has twice the weight of B, then A will get access to the bus for twice as long as B, at the same time fairness is guaranteed because this is still a round robin arbiter.

Despite the simple description above, there are innumerable ways to specify an arbitration criterion for your design based on the requirements.

In this problem and the next, we shall be designing two kinds of weighted round robin arbiters and analyse the performance on different criteria like fairness and configurability.

PROBLEM STATEMENT:

For the first part, we will design the arbiter for an application that lets different customers use a shared optical line across the Atlantic ocean by paying for a certain share of its bandwidth. The fibre can carry 64 Gbps of data and each customer can purchase anywhere from 1 to 64 Gbps of bandwidth share.

The line is a time shared bus that arbitrates between 8 unique channels of different bandwidths thus serving up to 8 unique customers. A time window of 64 clock cycles is defined and is split among the unique channels based on their requirements. I.e sum(weightsch) == 64 A customer that purchases more bandwidth also gets higher priority, however even the lowest customer needs to be served in every time window. When arbitrating between two channels with the same weight, the channel with a lower index can be given priority.

Interface Definition
The module consists of two interfaces

The input interface:

input [63:0]  weights_i -> priority for requesters 0 to 7. 8-bits per channel

The output interface

Output [7:0] gnt_o      -> output grant. one bit per requestor
Output gnt_valid_o      -> qualifier for output grant

Interface Requirements:

1. weights_i is a static configuration that is done at the start of the test. It will not change during the test.
2. All weights will be non-zero values.
3. There is no latency rule on the first grant given by the arbiter.
4. Testbench expects the arbiter to continuously give grants indefinitely without break once the first grant is given. i.e no clock cycles should be wasted once the time window begins.
5. It is understood that once a time window completes a new one starts immediately with the same weights.
6. Given constraints 3 and 4 above, it is obvious that gnt_valid_o once asserted should never be de-asserted during the entire test.

Interface Timing Diagram:
Below diagram shows an example of operation with the weights vector unpacked for ease of visualization