Skip to Factory + stimulus questions

Part 2 · Factory and stimulus

Use late binding deliberately, trace one sequence item through arbitration and pin-level driving, and coordinate multiple interfaces without hiding ownership.

Question directory

Questions for Factory + stimulus

Open an authored answer here, then follow its diagram and implementation example in context.

  1. Factory and configurationWhat problem does the UVM factory solve?UVM interview answer
  2. Factory and configurationHow would you replace a default driver with an error-injecting driver?UVM interview answer
  3. Factory and configurationHow is uvm_config_db different from a direct hierarchical reference?UVM interview answer
  4. Factory and configurationWhat do uvm_component_utils and uvm_object_utils actually do?UVM interview answer
  5. Sequences and driversHow do a sequence item, sequence, and sequencer differ?UVM interview answer
  6. Sequences and driversWhat is the exact sequence-driver handshake?UVM interview answer
  7. Sequences and driversWhat is a virtual sequence, and when is it useful?UVM interview answer
  8. Sequences and driversWhat are m_sequencer and p_sequencer?UVM interview answer

UVM Factory and configuration Swap behavior without rewiring.

Use the factory to replace types at creation time and the configuration database to deliver typed settings by scope, while keeping both mechanisms predictable.

Concept model

Two late-binding paths, two different jobs

Factory pathChange the created type
test installs override
factory resolver
error_driver
agent.driver

The environment still requests base_driver. The factory selects the compatible override before creation.

Configuration pathChange component policy
typed set()
scope + field
checked get()
agent config

The component type is unchanged. A typed value, often a config object or virtual interface, controls its behavior.

A factory override changes what gets created. A config_db entry changes how an existing component behaves. Both must be installed before the consumer needs them.

Strong answer

The factory separates the type requested by reusable code from the type actually created, so a test can substitute behavior without editing the environment.

Reason it through

  • Factory registration supplies a type proxy. type_id::create() asks the factory to resolve that proxy using type and instance overrides.
  • A type override affects every matching creation unless a more specific instance override wins. An instance override affects only a matching hierarchical context.
  • The override must be installed before the target create() call. Factory debug output is the fastest way to prove what the resolver selected.

UVM Sequences and drivers Follow one request end to end.

Trace arbitration, request delivery, pin driving, completion, and multi-interface coordination without confusing sequences, sequencers, items, or drivers.

Concept model

A request moves; ownership changes

system scenariovirtual sequence
control busregister sequencer
data busstream sequencer
creates intentsequence
arbitratessequencer
drives pinsdriver
observes signalsDUT
  1. 01start_item()wait for grant
  2. 02finish_item()send request
  3. 03get_next_item()receive request
  4. 04drive()honor protocol
  5. 05item_done()release sequence

The sequence creates intent, the sequencer arbitrates, the driver converts the granted item to signal activity, and the DUT sees only the interface protocol.