[SOLVED] simple 5 input variable priority Arbiter not working and no idea why!?

[BartlebyScrivener]

I am trying to write a 5 input round robin arbiter. It appears to work in isolation, but when used in my network it seems to be failing me.

It is hard for me to find when it is failing in the network due to complexity, but when I use a different fixed priority arbiter module I wrote that I know works in my network, the network drops no packets, but when using the round robin arbiter It drops approx 1% of packets. Can anyone see why from this code?

I really can't see anything wrong with the actual code/logic I have checked it loads and it seems simple, but then perhaps I am blinded from something simple!

module arbiter
  
  // The amount of lines to arbitrate is passed as a parameter, the default being 5.
  
  #(parameter n = 5)
  
  
  // The arbiter outputs a one-hot n bit word denoting the port request that has been granted from
  // the port requests inputted in a one-hot fashion.
  
  (output logic [n-1:0] portGrant,
    input logic [n-1:0] portRequest,
    input logic         reset, clk);
    
    
  // Internal logic for priority and carry bits.
  
  logic [n-1:0] portPriority;
  logic [n-1:0]   carryBit;
  
  
  // Combinational logic describing an n-bit variable priority iterative arbiter.  This logic
  // should be able to be used with different schemes to generate the one-hot priority input but this didnt work
 // so I commented it out and tried making individual arbiter cells and instantiating them below.
  /*
  always_comb
    begin
      for (int i=0; i<n; i++)
        begin
        portGrant[i] = (portRequest[i] && ( carryBit[i] || portPriority[i] ));
        carryBit[i+1] = (!portRequest[i] && ( carryBit[i] || portPriority[i] ));
        end
      carryBit[0] = carryBit[n]; 
    end
    */

    variablePriorityArbiter arbite0 (portGrant[0], carryBit[1], portPriority[0], portRequest[0], carryBit[0]);
    variablePriorityArbiter arbite1 (portGrant[1], carryBit[2], portPriority[1], portRequest[1], carryBit[1]);   
    variablePriorityArbiter arbite2 (portGrant[2], carryBit[3], portPriority[2], portRequest[2], carryBit[2]);
    variablePriorityArbiter arbite3 (portGrant[3], carryBit[4], portPriority[3], portRequest[3], carryBit[3]);
    variablePriorityArbiter arbite4 (portGrant[4], carryBit[0], portPriority[4], portRequest[4], carryBit[4]);
   
    
    
  // Priority input generation. 
    
  always_ff @ (posedge clk)
    begin
      if (reset)
        portPriority <= 'b00001;
      else
        begin
        // Round Robin
        portPriority <= |portGrant ? {portGrant[n-2:0], portGrant[n-1]} : portPriority;
        end 
    end
      
endmodule

The cell I made is ...

module variablePriorityArbiter
  (output logic G, Cout,
    input logic P, R, Cin);
    
    logic a;
    
    or  gate1 (a, Cin, P);
    and gate2 (G, R, a), gate3 (Cout, a, ~R);
    
endmodule

---------- Post added at 16:59 ---------- Previous post was at 16:55 ----------

Does Modelsim SystemVerilog get confused by the wrap around? Is it program confusion as appose to programming confusion? This has been rattling my head all day, I have rewritten it so many times!

 

[mrflibble]

With just this information, wouldn't know. Your code looks decent, so nothing there either...

Mmmh, maybe just a code style suggestion. You could use a "generate" block so you don't have to instantiate it 5 times. But I'm afraid that won't help you solve your problem, sorry.

About 1% packet drop you say. I always get a little suspicious with numbers like that. So it's not something obvious as having N states, and only the Nth state has a problem. You'd get higher packet drops then. This sounds more like a clock domain problem or something. The reason I say that is that roughly that percentage of packet drop was precisely what I got when I did stupid things with clock domains. And the other reason ... you said it works fine in isolation but doesnt work in the entire system which is complex. So presumably you have tested it on the workbench (single clock) and now it doesnt work in system (multiple clocks). So if you are using multiple clocks are you really really sure you synchronized everything properly? Just for kicks you could add an extra synchronizer FF at all points, and make sure to keep the pipeline correct. And then see if your error rate changes.

Sorry I couldn't be of more help...

 

[BartlebyScrivener]

Thanks, I wrote the logic as a netlist, without the wrap around and found that the problem still existed. It turned out that I had forgotten to connect a buffer full signal in one place. Schoolboy error!