Arbitration and priority

Where the choice is made

In U4.1 a sequence asked for a grant with start_item and got one when the driver asked for an item. With one sequence there was nothing to decide. With several, every start_item puts a request into the sequencer's arbitration queue, and the sequencer chooses among the queued requests each time the driver calls get_next_item.

A request is a candidate only if three things hold. It is a plain item request, so lock requests are handled first and separately. Its sequence is not blocked by another sequence's lock. And the sequence's is_relevant() returns 1, which it does unless you override it. U5.2 covers locks and relevance; this lesson assumes every request is a candidate.

When only one request is a candidate, every mode grants it at once without reading a priority. The mode matters only when two or more sequences are waiting at the same moment. That is why a priority bug hides in tests where sequences rarely overlap, and shows up when traffic gets dense.

The driver drives the choice. Nothing is granted while the driver is busy with an item, so a sequence that calls start_item during another item waits until that item's item_done. In the example, every scenario starts three sequences in the same time step, so they compete from the first grant.

The six modes, measured

The example runs the same three sequences, A, B and C with three items each, under every mode. The driver takes one item per clock and appends the item's sequence name and index to a grant log, which the test prints as one line per scenario.

Read the FIFO line first. The order is a round robin, and here is why. After A0 is done, A asks again, and its new request goes to the back of the queue, behind B0 and C0. Every sequence re-requests after each item, so the three take turns. Giving A, B and C different priorities changes nothing, as the second scenario of the example shows.

Now the STRICT_FIFO line. C has the highest priority, so C0 wins. When C0 is done, C's next request is already in the queue, because the sequencer lets the sequences run for a delta before it arbitrates again. C1 wins, then C2. B gets the driver only when C has nothing left, and A only after B. A sequence that keeps asking starves everyone below it.

STRICT_RANDOM gives the same order here, because at every arbitration only one candidate had the highest priority. It differs from STRICT_FIFO only when two sequences share the top priority: then it picks one of them at random where STRICT_FIFO takes the older request.

WEIGHTED shares the driver in proportion. Each candidate's chance is its priority divided by the sum of the candidates' priorities, so with 100, 200 and 300 the chances are one sixth, one third and one half. Proportion is all it promises. Every draw is fresh, with no memory of who has waited, so a low weight can lose many draws in a row. A priority of 0 is legal but never wins while a positive one competes. In the measured run C0 won the first draw and B0 the second. RANDOM ignores priorities and draws uniformly. Both orders come from the simulator's random seed: repeated runs here agree, because the seed is fixed, but another seed or another simulator gives another order.

Where a priority comes from

A sequence gets its priority from the third argument of start(sequencer, parent, priority). The default, -1, means inherit: 100 for a sequence with no parent, and the parent's priority for a child. Anything below -1 is a fatal error. You can also change it at any time with set_priority(value); the new value is used at the next arbitration.

An item can carry its own priority. start_item(it, priority) and the PRIORITY argument of uvm_do attach it to that one request. When the arbiter compares requests, an item priority other than -1 wins over the sequence's priority, and it must be greater than 0. Higher numbers win.

The fourth scenario shows the two together under STRICT_FIFO. A keeps priority 100, the lowest, but gives its first item priority 500. That item, A0, is granted first. A's later items fall back to 100, so A1 and A2 go last: A0 C0 C1 C2 B0 B1 B2 A1 A2.

fork
  ctrl.start(sqr, this, 500);   // sqr is still in FIFO
  bulk.start(sqr, this, 100);
join

sqr.set_arbitration(UVM_SEQ_ARB_STRICT_FIFO);
fork
  ctrl.start(sqr, this, 500);
  bulk.start(sqr, this, 100);
join

Only three modes read priorities: WEIGHTED, STRICT_FIFO and STRICT_RANDOM. If a test sets priorities, it must also set one of these modes, and the natural place is the sequence that starts the competing sequences, through m_sequencer.set_arbitration(...).

Writing your own rule

The sixth mode hands the decision to you. Extend the sequencer and override user_priority_arbitration(int avail_sequences[$]). The argument lists the positions, in the arbitration queue, of every request that is a candidate right now. Return one of them. The default implementation returns the first, which makes USER behave like FIFO; returning a position that is not in the list is a fatal error.

function int user_priority_arbitration(int avail_sequences[$]);
  foreach (avail_sequences[i])
    if (arb_sequence_q[avail_sequences[i]].sequence_ptr.get_name() == favourite)
      return avail_sequences[i];
  return avail_sequences[0];
endfunction

The queue, arb_sequence_q, is a protected member of uvm_sequencer_base, so a subclass may read it. Each entry has a sequence_ptr to the requesting sequence and an item_priority. With the favourite set to B, the measured order is B0 B1 B2 A0 C0 A1 C1 A2 C2: B takes every slot while it has a request, and the rest is FIFO.

A user rule is the right tool when the bus has a documented arbitration scheme that the test must mimic. A fixed slot order or a credit scheme per requester are examples. For anything simpler, one of the built-in modes is easier to explain in a review.

Choosing a mode

FIFO is fair, repeatable and the default; most agents never need anything else. STRICT_FIFO is the choice when one path must win whenever it asks, such as a control sequence that reconfigures the design between bursts. There the starvation it causes is the point. WEIGHTED produces a traffic mix with a chosen ratio. The price is an order that depends on the seed, and no bound on how long one requester may wait. When a sequence needs bounded service, use FIFO, or a user rule that ages or caps requests.

Two cautions. The mode is a property of the sequencer, so sequences started on it from anywhere see the same rule. Set it in one place, usually the virtual sequence or the test, and log it. And a starved sequence looks exactly like a hung one in the log. When a sequence seems stuck under a strict mode, print the sequencer with sqr.print() to see the queue before suspecting the driver.

Try it

Each line is one scenario: the mode, the three priorities, and the grant order the driver saw. The WEIGHTED and RANDOM lines are drawn from the simulator's random stream and depend on its seed; the other six are fixed by the rules above.

Change favourite to "C" and predict the USER line before you run. Then give B's first item priority 500 as well as A's in the fourth scenario: both have the top priority, so STRICT_FIFO falls back to request order between them.

Check yourself

`timescale 1ns/1ns
`include "uvm_macros.svh"
import uvm_pkg::*;
class item_c extends uvm_sequence_item;
  `uvm_object_utils(item_c)
  int idx;
  function new(string name = "item_c"); super.new(name); endfunction
endclass
class drv_c extends uvm_driver #(item_c);
  `uvm_component_utils(drv_c)
  string grants = "";
  int done;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  task run_phase(uvm_phase phase);
    forever begin
      seq_item_port.get_next_item(req);
      grants = {grants, " ", req.get_parent_sequence().get_name(), $sformatf("%0d", req.idx)};
      #10;
      seq_item_port.item_done();
      done++;
    end
  endtask
endclass
class seq_c extends uvm_sequence #(item_c);
  `uvm_object_utils(seq_c)
  int first_pri = -1;
  function new(string name = "seq_c"); super.new(name); endfunction
  task body();
    for (int i = 0; i < 2; i++) begin
      item_c it = item_c::type_id::create("it");
      it.idx = i;
      start_item(it, (i == 0) ? first_pri : -1);
      finish_item(it);
    end
  endtask
endclass
class my_test extends uvm_test;
  `uvm_component_utils(my_test)
  drv_c drv;
  uvm_sequencer #(item_c) sqr;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void build_phase(uvm_phase phase);
    drv = drv_c::type_id::create("drv", this);
    sqr = uvm_sequencer #(item_c)::type_id::create("sqr", this);
  endfunction
  function void connect_phase(uvm_phase phase);
    drv.seq_item_port.connect(sqr.seq_item_export);
  endfunction
  task run_phase(uvm_phase phase);
    seq_c a = seq_c::type_id::create("A");
    seq_c b = seq_c::type_id::create("B");
    a.first_pri = 500;
    sqr.set_arbitration(UVM_SEQ_ARB_STRICT_FIFO);
    phase.raise_objection(this);
    fork
      a.start(sqr, null, 100);
      b.start(sqr, null, 300);
    join
    $display("order:%s", drv.grants);
    phase.drop_objection(this);
  endtask
endclass
module tb;
  initial run_test("my_test");
endmodule

Practice

• Catch the sequencers that grant out of turn Verify · Medium