Factory Failures

UVM Debugging · Module 27 · Page 27.2

The Engineering Problem

You registered a factory override — your extended driver should replace the base, your error-injecting monitor should replace the normal one — and nothing changed. The base type ran as if the override didn't exist. No error, no warning — the testbench built and ran, just with the wrong type. This is the factory's characteristic failure (from 27.1's symptom map: a base type running where an override was expected → factory), and it's especially confusing because the most common cause leaves the override looking perfectly correct: you can print the factory and see your override registered, exactly as written — and it still doesn't take. The reason is a truth about the factory that's easy to forget: the factory can only override what it creates. An override is a substitution rule the factory applies when it is asked to construct a type — and if the object was constructed some other way (a direct new()), the factory never saw the request, so no rule could apply. Beyond that, the override can fail to register (the type wasn't registered with the factory), register too late (after the target was already built), or register with the wrong scope (a type override where an instance was needed, or an instance path that doesn't match). The problem this chapter solves is factory failures: applying the methodology (27.1) to the factory — reading the symptom (base type ran), observing with the factory print and topology, and confirming and fixing each of the few specific root causes so the override actually takes.

Factory failures are the silent non-application of a factory override — the base type runs where your override was expected — caused by one of a few specific conditions. The root causes: the object was constructed with new() instead of create(), so the factory never saw it (the most common — and the override still shows as registered, which misleads); the type wasn't registered with the factory (missing uvm_component_utils / uvm_object_utils), so the factory can't substitute it; the override was set after the target was already built (an ordering problem — overrides must be registered before the factory creates the target); or the wrong override flavor or scope was used (a type override where an instance override was needed, or an instance override with a path that doesn't match where the component actually sits). The methodology applied: the symptom is the base type ran (your behavior absent, the original's present); localize to the factory; observe with factory.print() (are the overrides registered? correct base→override? correct scope?) and uvm_top.print_topology() (what type was actually built?); confirm which root cause; and fix (use create(), register the type, set the override before build, correct the flavor/path). The cardinal truth: the factory can only override what it creates — so the single most common factory failure is constructing with new() instead of create(), which leaves the override correctly registered yet never applied. This chapter is factory failures: the symptom, the root causes, the observation, and the fixes.

Why does a factory override silently do nothing — the base type running instead — and how do you tell which root cause it is (new() instead of create(), unregistered type, override set too late, or wrong flavor/path) by observing the factory print and topology, then fix it so the override actually takes?

Motivation — why factory overrides fail silently

The factory's power — substituting types without editing code — comes with silent failure modes, because an override that doesn't apply produces no error, just the original behavior. The reasons it's worth knowing the specific causes:

• The failure is silent — the base type just runs. An override that doesn't take doesn't error; the testbench builds and runs with the base type. So you don't get told it failed — you discover it from a downstream symptom (your error injection didn't happen, your extended check didn't run).
• The most common cause looks correct. create()-versus-new() is insidious because the override is registered correctly — factory.print() shows it — and it still doesn't apply. The override isn't wrong; the construction bypassed the factory. Without knowing this, you stare at a correct override and can't see why.
• Ordering is invisible. Whether the override was set before or after the target was created is a matter of phase and call order you can't see from the override line itself — and build runs top-down, so an override set too late applies to nothing already built.
• Type-versus-instance scope is easy to get wrong. A type override hits all instances; an instance override hits one by path. Using the wrong flavor, or an instance path that doesn't match the actual hierarchy (a typo, or the hierarchy changed), means the override targets nothing.
• The fix differs per cause. Each root cause has a different fix (use create(), register the type, reorder, correct the path) — so you must know which one it is, which means observing the factory and topology, not guessing.

The motivation, in one line: factory overrides fail silently (the base type just runs, no error), the most common cause (new() instead of create()) leaves the override looking correct, ordering and scope problems are invisible from the override line, and each cause has a different fix — so you must observe the factory print and topology to confirm which root cause it is, then apply the matching fix.

Mental Model

Hold a factory override as a substitution rule at a supply desk — applied only to orders placed at the desk, never to parts grabbed off the shelf directly:

Picture a parts supply desk in a workshop. There's a clerk, and you can register substitution rules with them: "whenever someone orders part A, give them part B instead." From then on, every order placed at the desk for part A is quietly fulfilled with part B. This works beautifully — you can change what everyone receives without anyone changing their order — but only under conditions. First and most important: the substitution happens only for orders placed at the desk. If a worker walks past the desk and grabs part A straight off the shelf themselves, the clerk never saw the order, so no substitution happens — that worker gets part A, no matter how correctly your rule is written in the clerk's book. The rule is right there, registered, and it simply never had a chance to apply. Second, the rule has to be posted before the orders come in; a rule added after the morning's orders were already filled does nothing for them. Third, the rule has to name the right part — a rule to substitute part A does nothing for someone ordering part C — and the right scope: "substitute for everyone" versus "substitute only for the order under this specific job number," and if you wrote the wrong job number, the order you cared about isn't covered. So when someone receives the original part A despite your substitution rule, the rule being in the book is not the answer — you have to ask: did they order at the desk or grab it off the shelf, was the rule posted in time, and does it name the right part and scope? Picture a parts supply desk. A clerk applies substitution rules you register: "whenever someone orders part A, give them part B." Every order placed at the desk for A is fulfilled with B. This works — you change what everyone receives without anyone changing their order — but only under conditions. First and most important: the substitution happens only for orders placed at the desk. If a worker grabs part A off the shelf directly, the clerk never saw the order, so no substitution — that worker gets A, no matter how correctly your rule is written. The rule is right there, registered, and it simply never had a chance to apply. Second, the rule must be posted before the orders come in. Third, the rule must name the right part (a rule for A does nothing for C) and the right scope (everyone versus this specific job number — and a wrong job number misses the order you cared about). So when someone receives the original A despite your rule, the rule being in the book is not the answer — ask: did they order at the desk or grab it off the shelf, was the rule posted in time, and does it name the right part and scope?

So a factory override is a substitution rule at a supply desk: the factory is the clerk, create() is ordering at the desk (the factory sees the request and applies the rule), and new() is grabbing the part off the shelf (the factory never sees it, so no override applies — the base type, every time, no matter how the override is registered). The conditions map directly: the rule must be posted before orders (set the override before the target is built), name the right part (override the right base type), and have the right scope (type override for all, instance override for one by path — wrong path misses). And the diagnostic is the clerk's question: when the base type ran despite a registered override, the override being registered is not the answer — ask the four questions: was it created via the factory (create) or built directly (new), was the type registered, was the override set in time, and does it name the right base and scope. Treat the override as a desk-substitution rule: it applies only to what the factory creates, only if posted before construction, only for the right type and scope — so when the base type runs, observe the factory and topology to find which condition failed. The factory can only override what it creates.

Visual Explanation — the four root causes

The defining picture is the four root causes of a silent factory failure — the checklist the base-type-ran symptom routes you through.

The figure shows the four root causes. new() instead of create() (the warning-colored — the most common): the factory never saw the object, so no override could apply — and the override still prints as registered, which misleads. Type not registered (brand-colored): missing uvm_component_utils/uvm_object_utils — the factory can't substitute a type it doesn't know. Override set too late (success-colored): registered after the factory already built the target — the already-built component is the base type. Wrong flavor or path (default-colored): a type override where instance was needed, or an instance override whose path doesn't match the actual hierarchy. The crucial reading is that the symptom is identical for all four — the base type ran — so you cannot tell them apart from the symptom alone; observation (the factory print and topology) is what distinguishes them. The warning color on new()-instead-of-create() marks it as both the most common and the most misleading: with the other three, the factory print often shows something wrong (the override absent — for unregistered or too-late, depending; or with a mismatched path), but with new(), the factory print shows the override perfectly registered and it still doesn't apply — because the failure isn't in the override, it's in the construction (the object bypassed the factory). This is why the topology print is essential alongside the factory print: the factory print tells you what overrides are registered, but the topology print tells you what type was actually built — and comparing them reveals the new() case (override registered, base type built). The diagram is the factory failure differential: four causes, one symptom, distinguished by observation. A silent factory failure is one of four specific causes — new()-not-create(), unregistered type, too-late override, or wrong flavor/path — all with the same base-type-ran symptom, told apart only by observing the factory and topology.

RTL / Simulation Perspective — the four causes and their fixes

In code, each root cause is concrete and has a specific fix. The example shows all four and the observation that confirms each.

// === CAUSE 1 (most common): new() instead of create() — the factory never sees the object ===
class my_env extends uvm_env;
  my_driver drv;
  function void build_phase(uvm_phase phase);
    drv = new("drv", this);                        // ✗ direct new() — BYPASSES the factory
    // factory.print() SHOWS the override registered, but the base/this type ran anyway
    drv = my_driver::type_id::create("drv", this); // ✓ FIX: create() routes through the factory
  endfunction
endclass
 
// === CAUSE 2: type not registered — the factory can't substitute it ===
class my_driver extends base_driver;
  // ✗ missing registration
  `uvm_component_utils(my_driver)                  // ✓ FIX: register with the factory
endclass
 
// === CAUSE 3: override set too late — after the target was already built ===
function void build_phase(uvm_phase phase);
  super.build_phase(phase);                         // ✗ this already CREATED drv as the base type
  base_driver::type_id::set_type_override(my_driver::get_type());  // too late for drv
endfunction
function void build_phase(uvm_phase phase);
  base_driver::type_id::set_type_override(my_driver::get_type());  // ✓ FIX: override BEFORE create
  super.build_phase(phase);                         // now create() sees the override
endfunction
 
// === CAUSE 4: wrong flavor / path — instance override with a path that doesn't match ===
// ✗ instance override targeting a path that doesn't exist in the topology:
base_driver::type_id::set_inst_override(my_driver::get_type(), "env.agnt.drv");  // actual path: env.agent.drv
// ✓ FIX: correct the path (or use set_type_override for all instances):
base_driver::type_id::set_inst_override(my_driver::get_type(), "env.agent.drv");
 
// === OBSERVE to confirm which cause ===
function void end_of_elaboration_phase(uvm_phase phase);
  factory.print();              // are the overrides registered? correct base→override? correct path?
  uvm_top.print_topology();     // what type was ACTUALLY built? (override registered + base built → new())
endfunction

The code shows the four causes, their fixes, and the observation. Cause 1 (new()): drv = new(...) bypasses the factory — the fix is my_driver::type_id::create(...), which routes through the factory; the tell is that factory.print() shows the override but the base type ran. Cause 2 (not registered): missing uvm_component_utils — the fix is to add it, so the factory knows the type. Cause 3 (too late): set_type_override after super.build_phase (which already created drv) — the fix is to set the override before super.build_phase, so create() sees it. Cause 4 (wrong path): set_inst_override with a path that doesn't match (env.agnt.drv vs the actual env.agent.drv) — the fix is to correct the path (or use set_type_override for all instances). Observe: factory.print() shows what's registered (overrides, base→override, scope/path), and uvm_top.print_topology() shows what was actually built — and comparing them confirms the cause (override registered + base type built → the new() case). The shape to carry: each cause is a specific, fixable condition, and the factory print plus topology print distinguish them — the factory print alone isn't enough (it can't reveal the new() case, where the override is registered), so you pair it with the topology to see what was actually constructed. Observe the factory print and topology together — the factory print shows what's registered, the topology shows what was built, and comparing them confirms which of the four causes it is.

Verification Perspective — why create() is the linchpin

The defining truth — the factory can only override what it creates — makes create() versus new() the linchpin of the whole mechanism. Seeing why clarifies the most common failure.

The figure shows create() routing through the factory and new() bypassing it. When a component is constructed with type_id::create, the request goes through the factory (the success → brand path), which consults its registered overrides and substitutes the override type if one applies — so the override takes (override type runs). When a component is constructed with a direct new(), it never goes through the factory at all (the warning → default path bypasses the brand factory node); the factory has no knowledge of the request and no chance to substitute, so the base type is constructed regardless of any registered override. The verification insight is why this makes create() the linchpin: the factory's entire mechanism — consulting overrides and substituting — only runs when the factory is asked to construct, and create() is that ask. new() constructs without asking — it directly instantiates the named type — so the factory is simply not in the loop. This is the deep reason the factory can only override what it creates: an override is not a global rewrite of "whenever this type is constructed"; it's a rule the factory applies when the factory does the constructing. The crucial consequence is that a perfectly registered override silently does nothing when the target was built with new() — and this is the case that misleads, because the override isn't wrong (it's registered exactly as intended), the construction simply bypassed the mechanism that applies it. The success-colored create path → override runs versus the warning-colored new path → base runs make the fork explicit: the single choice of create() versus new() determines whether the override can apply at all. The crucial point is that this is why create() is non-negotiable for any type you might ever want to override — and since reuse (Module 26) means you might want to override almost anything, the discipline is to always construct components and overridable objects with create(), never new(). The diagram is the linchpin: create() lets the override apply; new() bypasses the factory so the base type always runs. Always construct with type_id::create, never new() — the factory can only override what it creates, so a direct new() makes even a perfectly registered override silently do nothing.

Runtime / Execution Flow — diagnosing a factory failure

At run time, diagnosing a factory failure follows the methodology: symptom → observe factory + topology → identify the cause → fix. The flow shows the factory-specific diagnostic.

The flow shows the factory-specific diagnostic. Symptom (step 1): the base type ran — your override's behavior absent, the original's present — which localizes to the factory. Print the factory (step 2): is the override registered? with the correct base, override type, and scope/path? Print the topology (step 3): what type was actually built at the target location? Read together → cause → fix (step 4): if the override is absent → not registered or set too late; if present with a mismatched instance path → fix the path; if present and correct but the topology shows the base type was built → new() instead of create(). The runtime insight is that the two prints together are what turn the identical symptom into a precise diagnosis — neither alone suffices. The factory print alone can mislead: in the new() case, it shows the override correctly registered, so if you stop there, you conclude the override is fine and don't know why it didn't apply. The topology print is what closes the gap: it shows what was actually built, and when that's the base type despite a correctly registered override, the only explanation is that the construction bypassed the factory (new()). Conversely, if the factory print shows the override absent, you don't need the topology to know it's a registration or ordering problem. So the diagnostic logic is: factory print establishes what the factory knows, topology print establishes what actually happened, and the combination uniquely identifies the cause. The brand (symptom) → success (two prints) → warning (identify/fix) flow shows evidence (the two prints) preceding the conclusion. The crucial point is that this is the methodology (27.1) specialized to the factory: observe with the factory's specific introspection (factory print + topology), confirm the cause from what they show, fix the matching cause — not guess. The flow is the factory diagnostic: base type ran → factory print + topology print → read together → cause → fix. Diagnose a factory failure by printing both the factory and the topology and reading them together — the factory print shows what's registered, the topology shows what was built, and only the combination distinguishes the four causes.

Waveform Perspective — the base type's behavior, observed

A factory failure is observable as base-type behavior where override behavior was expected — and distinct from a sequencer failure because the driver is running, just as the wrong type. The waveform shows it.

The waveform shows the base type's behavior, observed. The driver is active — valid pulses as transactions are driven, so this is not a "nothing drives" sequencer failure. But the mode field carries the base type's default value (0) on every transfer, when the override was expected to drive its custom value (2). The crucial reading is the combination: the driver is running (transactions happen — valid pulses) but with base-type behavior (mode = 0, the default) rather than the override's (mode = 2). That combination is the signature of a factory failure: the wrong type was constructed, so the original behavior appears — the driver works, it's just the base driver, not yours. This distinguishes it sharply from the sequencer failure of 27.1 (where nothing would drive at all — valid flat): here, stimulus is flowing, so the sequence started and the driver runs — the problem is which driver. Reading the symptom this way — is the driver running, and is its behavior the base's or the override's? — localizes to the factory (the override didn't take) rather than the sequencer (no stimulus) or the DUT (the testbench side is producing base behavior, not a DUT response). The picture to carry is that a factory failure looks like "the right activity, the wrong flavor" — transactions happen, but with the base type's behavior, because the base type was built. Once you've read this — driver running, base behavior — you print the factory and topology to find which of the four causes prevented the override. The driver active but driving base-type values is the waveform signature that says factory, not sequencer. A factory failure shows the driver running with base-type behavior, not the override's — transactions happen but in the wrong flavor, which distinguishes it from a sequencer failure (nothing drives) and points to the factory.

DebugLab — the correctly-registered override that never took

✗ THE TARGET WAS BUILT WITH new() — bypassing the factory:
  class apb_agent extends uvm_agent;
    apb_driver drv;
    function void build_phase(uvm_phase phase);
      drv = new("drv", this);          // ✗ direct new() — the factory is NOT in the loop
    endfunction
  endclass
  // factory.print() shows: apb_driver -> err_driver (type override)  ← REGISTERED, correct
  // topology print shows:  env.agent.drv  (type apb_driver)          ← BASE type was BUILT
  // → the override is correct; the construction bypassed the factory → base ran (override never applied)
 
✓ CONSTRUCT WITH create() — route through the factory:
  function void build_phase(uvm_phase phase);
    drv = apb_driver::type_id::create("drv", this);   // ✓ factory sees the request → applies override
  endfunction
  // now topology print shows: env.agent.drv (type err_driver)  ← the override TOOK

Common Mistakes

• Constructing with new() instead of create(). A direct new() bypasses the factory, so no override applies; always use type_id::create for overridable components and objects.
• Trusting the factory print alone. A registered override proves the override is correct, not that it was applied; print the topology to see what was actually built.
• Forgetting to register the type. Without uvm_component_utils or uvm_object_utils, the factory can't substitute the type; register every overridable type.
• Setting the override too late. An override registered after the target was built applies to nothing already constructed; set overrides before the factory creates the target.
• Using the wrong override flavor or path. A type override hits all instances, an instance override hits one by path; a mismatched instance path targets nothing.
• Assuming the override is wrong when the base ran. The override is often correct; the construction or ordering is the failure — observe both factory and topology.

Senior Design Review Notes

Interview Insights

Exercises

1. Identify the cause. For each — factory print shows the override but topology shows the base type; factory print doesn't list the override; instance override path is env.agnt.drv but topology shows env.agent.drv — name the root cause and the fix.
2. Find the bypass. Given an agent whose build_phase contains drv = new("drv", this), explain why a correct override doesn't take and rewrite the line.
3. Order the override. Given an override set after super.build_phase, explain why it's too late and where to move it.
4. Choose the flavor. Decide whether to use a type or instance override to replace only one of three identical agents' drivers, and write the call.

Summary

• Factory failures are the silent non-application of a factory override — the base type runs — caused by one of four specific conditions, all with the same symptom.
• The root causes: new() instead of create() (the factory never saw the object — the most common, and the override still prints as registered); type not registered (missing uvm_component_utils/uvm_object_utils); override set too late (after the target was built); or wrong flavor/path (type where instance was needed, or an instance path that doesn't match).
• The cardinal truth: the factory can only override what it creates — an override is a substitution rule applied when the factory constructs, so a direct new() bypasses it and runs the base type no matter how correctly the override is registered.
• Observe with both factory.print() (what's registered — base, override, scope) and uvm_top.print_topology() (what was actually built); reading them together distinguishes the causes — a correct override + base type built uniquely points to new().
• The durable rule of thumb: when a factory override silently does nothing and the base type runs, don't assume the override is wrong — print both the factory and the topology and read them together; a registered override with the base type built means the target was constructed with new() instead of create(), so the factory was bypassed (the factory can only override what it creates) — always construct overridable components with type_id::create, register every overridable type, set overrides before the target is built, and match the override flavor and instance path to the actual hierarchy.

Next — Config DB Failures: the methodology turns to the configuration database. Why a component receives a default or null value it was configured to override — a set/get path or scope mismatch, a type mismatch between set and get, the set happening after the get, or the wrong field name — how to read the symptom (a default value, or a null-handle crash), how to observe it (the config-DB trace), and how to fix each so the configuration actually reaches the component.