Priority & set_arbitration: set_priority and Arbitration Modes

Sequence priority — biasing the arbiter

Every uvm_sequence_base carries a priority field. Higher priority sequences win arbitration when multiple sequences have pending start_item calls and the sequencer is in a priority-aware mode. Priority does not preempt an in-flight driver item — it only affects which pending start_item is granted next.

class urgent_rst_seq extends uvm_sequence #(apb_item);
  `uvm_object_utils(urgent_rst_seq)

  task body();
    set_priority(100);  // higher than default (0)

    apb_item req = apb_item::type_id::create("req");
    start_item(req);
    assert(req.randomize() with { addr == REG_RESET; data == 1; write == 1; });
    finish_item(req);
  endtask
endclass

// Or set before start:
urgent_rst_seq rst = urgent_rst_seq::type_id::create("rst");
rst.set_priority(200);
rst.start(env.apb_agent.sqr);

When priority helps — and when it does not

Good uses

• [STIM] Inject reset sequence while background traffic runs — reset wins next slot.

• [STIM] Setup sequence completes before stress — setup.set_priority(50) at start.

• [STIM] Error injection gets precedence over low-priority generators.

Priority is NOT lock

• Priority affects ordering of pending start_item — not exclusive access.

• High-priority sequence still interleaves one item at a time with others.

• For atomic multi-beat: use lock, not high priority.

• Default FIFO mode ignores priority unless mode is WEIGHTED or similar.

[SEQ] priority vs lock — different guarantees

  set_priority(200) on setup_seq:
    setup item → bg item → setup item → bg item  (interleaved, setup wins TIES)

  lock(this) on setup_seq:
    setup item → setup item → setup item → unlock → bg item  (exclusive)

set_arbitration — choosing the policy

The sequencer's set_arbitration() selects how pending requests are ordered. Set it in build_phase or env configuration:

function void build_phase(uvm_phase phase);
  super.build_phase(phase);
  apb_agent.sqr.set_arbitration(UVM_SEQ_ARB_FIFO);      // default
  // apb_agent.sqr.set_arbitration(UVM_SEQ_ARB_WEIGHTED); // use priority field
  // apb_agent.sqr.set_arbitration(UVM_SEQ_ARB_RANDOM);   // stress diversity
  // apb_agent.sqr.set_arbitration(UVM_SEQ_ARB_USER);     // custom hook
endfunction

• UVM_SEQ_ARB_FIFO — first pending start_item wins; priority ignored.

• UVM_SEQ_ARB_WEIGHTED — priority field weighted selection among pending.

• UVM_SEQ_ARB_RANDOM — random among pending sequences; good for stress regressions.

• UVM_SEQ_ARB_USER — custom arbitration via user hook; rare in production TBs.

Weighted mode — how priority affects selection

In UVM_SEQ_ARB_WEIGHTED, sequences with higher priority values are selected proportionally more often when multiple start_item calls are pending. A priority-100 sequence wins more often than priority-0 background traffic, but low-priority sequences still get slots — no starvation by design unless lock is misused.

[UVM] weighted arbitration — conceptual

  Pending:  bg_seq (pri=0)   setup_seq (pri=100)   stress_seq (pri=50)

  Weighted selection among pending:
    setup_seq  ~50% of grants  (highest weight)
    stress_seq ~33% of grants
    bg_seq     ~17% of grants

  Still one item at a time — weighting affects FREQUENCY not exclusivity

// Typical chip env: background low, setup high, stress medium
function void configure_arbitration();
  env.apb_agent.sqr.set_arbitration(UVM_SEQ_ARB_WEIGHTED);
endfunction

task run_phase(uvm_phase phase);
  apb_bg_seq bg = apb_bg_seq::type_id::create("bg");
  bg.set_priority(0);
  bg.start(env.apb_agent.sqr);

  apb_setup_seq setup = apb_setup_seq::type_id::create("setup");
  setup.set_priority(100);
  setup.start(env.apb_agent.sqr);  // wins more pending slots during setup window
endtask

Key takeaways

• set_priority biases next-slot selection — not exclusive access.

• Priority only matters in WEIGHTED (and some USER) modes — FIFO ignores it.

• Use lock for atomic multi-beat; use priority for biasing interleaving frequency.

Common pitfalls

• Setting high priority expecting atomic access — still interleaves one item at a time.

• UVM_SEQ_ARB_WEIGHTED without setting priorities — all default 0, behaves like uniform random.

• Changing arbitration mode mid-test without documenting — regression non-determinism.