Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Understanding Linear implementation of a round-robin arbiter

Status
Not open for further replies.

promach

Advanced Member level 4
Joined
Feb 22, 2016
Messages
1,199
Helped
2
Reputation
4
Reaction score
5
Trophy points
1,318
Activity points
11,636
For Efficient microarchitecture for network-on-chip routers , do anyone know how this round-robin arbiter actually works ?


Note: The corresponding verilog codes seem to be located at c_rr_arbiter_base.v and c_rr_arbiter.v

QgIoh0B.png
 

It seems that the top block keeps track of the last grant, and activates the 'p' signal for the next block to give it the highest priority.
However, any block can make a request.
The priority logic is combinatorial and the outputs can have glitches, so the request inputs and the grant outputs should go to synchronous logic in the same clock domain.

r = request
g = grant
p = priority
c = chain/carry for priority
 

@std_match

What is wrong with my verilog code implementation that resulted in wrong waveform result ?

uGFct.png




Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
module arbiter2 #(parameter WIDTH = 4) (clk, reset, req, grant);
 
input clk, reset;
input [WIDTH-1:0] req;
output [WIDTH-1:0] grant; 
 
// 'grant' is one-hot vector, which means only one client request is granted/given green light to proceed
// note that 'base' is one-hot vector, 
// 'base' signal helps round-robin arbiter to decide which 'req' to start servicing
reg [WIDTH-1:0] base;
 
always @(posedge clk)
begin
    if(reset) base <= 1;
 
    else base <= (base[WIDTH-1]) ? 1 : (grant == 0) ? 1 : (grant << 1);
end
 
wire [WIDTH-1:0] priority_in;
reg [WIDTH-1:0] priority_out;
 
genvar index;
generate
    for(index = 0; index < WIDTH; index = index + 1)
    begin
        if(index > 0) assign priority_in[index] = base[index] | priority_out[index-1];
 
        else assign priority_in[index] = base[index] | priority_out[WIDTH-1];
    end
endgenerate
 
assign grant = (reset) ? 1 : req & priority_in;
 
always @(posedge clk) priority_out <= (~req) & priority_in;
 
`ifdef FORMAL
initial assume(reset);
 
reg first_clock_had_passed;
initial first_clock_had_passed = 0;
 
always @(posedge clk) first_clock_had_passed <= 1;
always @(posedge clk) if(first_clock_had_passed && $past(first_clock_had_passed) && $past(first_clock_had_passed, 2) && $past(first_clock_had_passed, 3)) assume(&req); // ALL requests ON
 
// covers the ability to handle requests properly even with ALL requests ON
always @(posedge clk) cover(first_clock_had_passed); 
`endif
 
endmodule

 

What is the actual purpose of the chain of fixed-priority cells F in figure 2.3 ?

How does this chain actually help to eliminate the circular loop logic as described in the paper itself ?

5Yvk3nu.png
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top