Sequencer Role: What It Owns, What It Must Not Own

Core responsibilities

A sequencer owns arbitration and transaction routing . It decides which requesting sequence can send an item next, then passes that item to the driver using standard seq_item pull APIs.

It does not own bus timing, pin toggling, or protocol waveforms. Those remain driver responsibilities. It also does not replace monitor analysis or checking logic.

[SEQ] owns

- sequence request arbitration
- req item handoff to driver
- rsp routing to sequence context
- sequence lifecycle interactions (locks/grabs/priority)

does not own
- interface pin drives
- waveform timing details
- passive protocol observation
- scoreboard expectations

class apb_agent extends uvm_agent;
  `uvm_component_utils(apb_agent)
  apb_sequencer sqr;
  apb_driver    drv;
  apb_monitor   mon;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    if (is_active == UVM_ACTIVE) begin
      sqr = apb_sequencer::type_id::create("sqr", this);
      drv = apb_driver::type_id::create("drv", this);
    end
    mon = apb_monitor::type_id::create("mon", this);
  endfunction

  function void connect_phase(uvm_phase phase);
    if (is_active == UVM_ACTIVE)
      drv.seq_item_port.connect(sqr.seq_item_export);
  endfunction
endclass

• Keep sequencer focused on flow control and ownership semantics.

• Driver should remain the only component driving protocol pins.

• Monitor and checker pipelines should stay independent of sequencer policy internals.

Sequence, sequencer, driver boundary

A clean three-way split improves maintainability: sequences describe intent, sequencer arbitrates intent sources, and driver converts granted items into cycle-accurate behavior.

[UVM][SEQ][DRV] boundary model

sequence:
  decides "what to do next" (transaction intent)

sequencer:
  decides "whose request is served now" (policy)

driver:
  decides "how to drive this on pins" (timing/protocol)

if a concern crosses all three, split it by this ownership model

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

  task body();
    apb_item req;
    repeat (16) begin
      req = apb_item::type_id::create("req");
      start_item(req);
      assert(req.randomize() with { kind == APB_WRITE; });
      finish_item(req);
    end
  endtask
endclass

[SEQ] sequence authoring guideline

sequence should not:
  - drive vif directly
  - peek driver private handshake state

sequence should:
  - create/fill req items
  - set priorities/constraints intentionally
  - handle responses or completion policies

• Enforce sequence intent abstraction to keep tests portable across protocol variants.

• Avoid direct sequence-to-driver couplings outside sequencer API boundaries.

• Use sequence-level constraints for traffic shape, not protocol handshakes.

Role validation checklist

During code review, classify each change by role ownership. This catches architectural drift before it becomes pervasive.

[SEQ][UVM][AGT] role-review checklist

1) Does sequencer code reference interface signals?
   -> if yes, likely wrong ownership.

2) Does driver select among multiple sequence requests?
   -> if yes, arbitration leaked out of sequencer.

3) Does sequence inspect monitor analysis queues?
   -> if yes, checker coupling risk.

4) Is response ownership preserved per requesting sequence?
   -> must hold for robust multi-sequence operation.

[MON][UVM][AGT] coordination without coupling

sequencer path:
  sequence -> sequencer -> driver -> DUT

monitor path:
  DUT -> monitor -> analysis subscribers

both paths meet at DUT behavior,
not by direct component cross-calls

Key takeaways

• Sequencer owns request arbitration and response routing only.

• Driver owns waveform timing and pin-level execution.

• Sequences express intent while staying protocol-abstract.

• Role-based review prevents long-term agent architecture drift.

Common pitfalls

• Adding protocol signal logic to sequencer helper methods.

• Driver implementing ad hoc arbitration policies.

• Sequence reaching into monitor or scoreboard internals.

• Ambiguous response ownership in multi-sequence scenarios.