Sequence Libraries and Default Sequences: Startup Without Chaos

Why libraries and defaults matter

As test suites grow, ad hoc sequence startup in each test becomes brittle. Sequence libraries and default sequence policies centralize startup behavior and keep smoke/sanity flows consistent.

[SEQ] library goals

reuse:
  common sequence sets shared across tests

consistency:
  deterministic phase startup behavior

extensibility:
  tests can override with focused scenarios

visibility:
  startup path is declarative, not hidden in random test code

class apb_base_lib extends uvm_sequence_library #(apb_item);
  `uvm_object_utils(apb_base_lib)
  `uvm_sequence_library_utils(apb_base_lib)

  function new(string name = "apb_base_lib");
    super.new(name);
    init_sequence_library();
    add_typewide_sequence(apb_smoke_seq::get_type());
    add_typewide_sequence(apb_rand_rw_seq::get_type());
    add_typewide_sequence(apb_reset_recovery_seq::get_type());
  endfunction
endclass

• Use libraries to standardize baseline traffic sets across regressions.

• Keep startup declarative so phase behavior is easy to inspect.

• Allow targeted overrides without copy-pasting startup boilerplate.

Default sequence configuration patterns

Default sequences can be configured through config DB at sequencer phase paths. This is useful for smoke bring-up but should be controlled to avoid hidden traffic when tests need full explicit control.

function void build_phase(uvm_phase phase);
  super.build_phase(phase);

  uvm_config_db#(uvm_object_wrapper)::set(
    this,
    "env.agt.sqr.main_phase",
    "default_sequence",
    apb_smoke_seq::type_id::get()
  );
endfunction

[SEQ][UVM] default sequence governance

good use:
  - smoke bring-up
  - sanity suites
  - environment self-check phase traffic

use carefully:
  - complex scenario tests needing explicit orchestration
  - virtual sequence dominated flows

project rule:
  document who sets default_sequence and where

[SEQ] startup conflict anti-pattern

test starts explicit virtual sequence
AND
default sequence auto-starts on same sequencer

result:
  unexpected contention, hard-to-explain arbitration outcomes

• Use defaults intentionally; disable when explicit virtual control is required.

• Track default sequence settings in one central test-base location.

• Avoid hidden startup traffic that interferes with targeted tests.

Library/default validation walkthrough

Treat startup behavior as testbench functionality that needs verification. Add smoke checks that confirm expected sequence launch and no accidental extras.

[SEQ] validation checklist

1) which sequence should auto-start in this phase?
2) did exactly that sequence start?
3) did any unexpected sequence start?
4) are arbitration metrics consistent with expected startup set?
5) does disabling default restore explicit control path?

task check_default_start(env e);
  if (!e.agt.sqr.seen_seq("apb_smoke_seq"))
    `uvm_error("DEF_SEQ", "expected default sequence did not start")

  if (e.agt.sqr.seen_seq("unexpected_seq"))
    `uvm_warning("DEF_SEQ", "unexpected sequence observed at startup")
endtask

[SEQ][UVM][AGT] startup visibility practice

at start_of_simulation:
  print sequencer startup plan

at end_of_main_phase:
  print started sequence list + grant counts

goal:
  startup intent and runtime behavior should match clearly

Key takeaways

• Sequence libraries and defaults improve startup consistency and reuse.

• Default sequence policy must be explicit to avoid hidden contention.

• Startup behavior should be validated with dedicated smoke assertions.

• Centralized configuration prevents drift across large test suites.

Common pitfalls

• Setting defaults in scattered tests with conflicting policies.

• Running defaults and explicit virtual sequences simultaneously by accident.

• Treating startup traffic as implicit and unobservable behavior.

• Copy-pasting sequence lists instead of using libraries.