Arbitration

When two masters share a bus, only one can drive it at a time. An arbiter decides who. Its rules matter more than they seem: a badly chosen policy lets one master take the bus forever while another starves. This article explains bus arbitration, compares fixed priority and round robin in a simulation, and shows where arbiters sit in real buses.

8 min read | Beginner to Intermediate

What You'll Learn

• Explain why a shared bus needs an arbiter
• Compare fixed-priority and round-robin arbitration
• Recognize starvation and how to prevent it
• Implement a two-master arbiter in Verilog

Who Owns the Bus?

A shared bus has one set of address and data wires. If two masters drive them at the same time, the values collide. So each master raises a request, an arbiter grants the bus to one of them, and a multiplexer connects only the granted master to the bus. The other master keeps its request up and waits.

Fixed Priority

The simplest policy gives every master a fixed rank. When several request, the highest-ranked one wins. It is small and predictable, and it suits masters with real-time deadlines, such as a display controller that must never miss a pixel.

Its weakness is starvation: a high-priority master that requests all the time keeps the bus, and the lower-priority masters never get it.

Round Robin

A round-robin arbiter remembers who was granted last and gives the next conflict to the other master. Every master gets a turn, so none can starve. Here is a two-master arbiter that does either, selected by a parameter:

module bus_arbiter #(
  parameter ROUND_ROBIN = 0              // 0 = fixed priority (master 0 wins), 1 = round robin
) (
  input            clk,
  input            rst,
  input      [1:0] req,
  output reg [1:0] gnt
);
  reg last;                              // the master granted last time

  always @(posedge clk) begin
    if (rst) begin
      gnt  <= 2'b00;
      last <= 1'b1;
    end
    else begin
      if (req == 2'b11) begin
        if (ROUND_ROBIN) begin
          gnt  <= last ? 2'b01 : 2'b10;  // the other master gets the next turn
          last <= ~last;
        end
        else begin
          gnt <= 2'b01;                  // master 0 always wins
        end
      end
      else begin
        gnt <= req;                      // only one or no request: grant it
        if (req == 2'b01)
          last <= 1'b0;
        else if (req == 2'b10)
          last <= 1'b1;
      end
    end
  end
endmodule

Each grant lasts one cycle, enough for one transfer to a slave that is always ready.

The Two Policies Side by Side

The testbench drives both arbiters with the same requests: both masters want the bus for eight cycles.

fixed priority: master 0 got 8 transfers, master 1 got 0
round robin:    master 0 got 4 transfers, master 1 got 4

Fixed priority starved master 1 completely. In a real system, master 1 could be a DMA engine moving audio data, and the audio would stop. Round robin split the bus evenly.

Arbitration in Real Buses

• AHB with several masters uses an arbiter with HBUSREQ and HGRANT signals in the classic AMBA 2 form. AHB-Lite has a single master; multi-master systems put an arbiter in the interconnect instead.
• AXI has no arbitration signals at all. Each master has its own port into the interconnect, and arbiters inside the interconnect decide, per slave, which request goes next.
• Real arbiters often combine policies: priority classes with round robin inside each class, or weights so that a master gets a guaranteed share of the bandwidth.

Running It in ChipVerify Lab

The example contains the arbiter, a shared bus built around it, and the testbench that compares both policies. Run it and compare the two grant patterns in the waveform.

Common Mistakes

req = 2'b11;                     // both masters request ...
repeat (4) @(negedge clk);
req = 2'b10;                     // ... then only master 1
repeat (4) @(negedge clk);
req = 2'b00;