The Factory Pattern

UVM Factory · Module 6 · Page 6.2

The Engineering Problem

The previous chapter established why the factory exists — substitution without modification. This one covers how: the factory pattern itself, a classic creational design pattern from software engineering that UVM applies almost textbook. Understanding the pattern explains the two macros and one method you've been using (uvm_component_utils, uvm_object_utils, type_id::create) — what each actually does and why both halves are required.

The pattern has a precise structure, and missing half of it is a common bug. There are two halves: registration — every class tells the factory "I exist, here's how to make me" (the uvm_*_utils macro registers the class via a lightweight proxy); and creation — instead of new, you ask the factory "make me one of these" (type_id::create), which the factory fulfils by consulting its registry, applying any override, and instantiating. The indirection between asking for a type and getting an instance — mediated by the proxy and the factory's registry — is exactly what lets an override change what you get. Use create without registering, and the factory has no proxy to make the type; register without using create, and you've bypassed the indirection. This chapter is the pattern: its two halves, the proxy that connects them, and why the indirection is the whole point.

What is the factory pattern, how does UVM implement it with registration (uvm_*_utils) and creation (type_id::create), what is the type_id proxy that connects them, and why does that indirection enable type substitution?

Motivation — why the pattern has this structure

The factory pattern's two-half structure is exactly what's needed to make construction substitutable:

• Direct new is the problem the pattern removes. new binds the construction site to a concrete type with no indirection — there's nowhere to insert a substitution. The factory pattern adds a layer between "I want a driver" and "here's a my_driver", and that layer is where an override can change the answer.
• Registration makes types known to the factory. A factory can only create types it knows about. Registration (uvm_*_utils) is how a class announces itself — it builds a lightweight proxy the factory stores in a registry, so when someone asks for that type, the factory has a way to construct it. Without registration, the factory has nothing to make.
• Creation goes through the indirection. type_id::create is the request — "factory, give me an instance of this type." The factory looks up the type (and any override) in its registry and instantiates via the proxy. This is the delegation at the heart of the pattern: you don't construct, you ask, and the factory decides what to construct.
• The proxy is the lightweight stand-in that makes it efficient. Rather than the factory holding heavy machinery per type, each type registers a small proxy (type_id) that knows how to create one instance. The factory manipulates proxies — registering them, overriding one with another — which is what makes registration cheap and overrides simple.

The motivation, in one line: substitution needs a layer of indirection between requesting a type and constructing it, so the factory pattern provides exactly that — registration builds a proxy the factory knows, and creation routes construction through the factory, with the proxy as the swappable connector that overrides target.

Mental Model

Hold the factory pattern as a parts counter with a registry of part numbers:

The factory pattern is a parts counter where you order by part number instead of fabricating parts yourself. Two things make it work. First, registration: every part manufacturer files a small catalogue card with the counter — "part number my_driver, here's how to produce one" (that card is the proxy, the type_id). The counter keeps a registry of these cards. Second, ordering: instead of fabricating a driver at your workbench (new), you go to the counter and order by part number (type_id::create) — "one my_driver, please." The clerk (the factory) looks up the card, checks for any substitution note ("for this customer, my_driver means err_driver"), and produces the part the card describes. The magic is the counter in the middle: because you order through it rather than fabricating directly, a substitution note can change what you receive without you changing your order. File a card to be orderable; order through the counter to be substitutable.

So in UVM: register every class (uvm_*_utils) so it has a catalogue card (proxy) at the counter, and order through the counter (type_id::create) rather than fabricating (new). The counter's indirection — and the swappable cards — is the whole pattern.

Visual Explanation — direct new vs the factory pattern

The pattern is the layer of indirection between requesting a type and getting an instance. new has no such layer; the factory pattern inserts the factory (and the proxy) between the request and the construction.

The contrast is the presence of a layer. With new (top row), the construction site names a concrete type and gets exactly that — there is no intermediary, so there is nowhere to insert a substitution; the type is fixed at the site. With the factory pattern (bottom row), the site issues a request (type_id::create) to the factory, which consults its registry of proxies (populated by registration), applies any override, and constructs the instance via the chosen proxy. The factory and the proxy form a layer of indirection between "I want this type" and "here's the instance" — and that layer is precisely where an override operates. So the pattern's power comes entirely from inserting that intermediary: new is request-equals-construction (rigid), while the factory is request-then-the-factory-decides-construction (substitutable). The diagram is the whole pattern: add a factory and a proxy between the request and the instance.

RTL / Simulation Perspective — the two halves in code

The pattern is two macros and one method: register the class (the uvm_*_utils macro builds the proxy) and create through the factory (type_id::create instead of new). Both halves are required.

// ── HALF 1: REGISTRATION — the class registers with the factory ──
class my_driver extends uvm_driver#(my_item);
  `uvm_component_utils(my_driver)        // registers my_driver; builds its type_id proxy
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
endclass
 
class my_item extends uvm_sequence_item;
  `uvm_object_utils(my_item)             // registers my_item; builds its type_id proxy
  function new(string name = "my_item"); super.new(name); endfunction
endclass
 
// ── HALF 2: CREATION — ask the factory, don't new ──
function void my_agent::build_phase(uvm_phase phase);
  drv = my_driver::type_id::create("drv", this);   // factory request → proxy → instance
endfunction                                        //   (vs.  drv = my_driver::new(...)  — bypasses the factory)

The two halves are clearly separable. Registration is the uvm_component_utils(my_driver) / uvm_object_utils(my_item) macro inside each class: it registers the class with the factory and builds its type_id proxy — the lightweight stand-in the factory stores in its registry and uses to construct instances of that type. (Note the matching macros: uvm_component_utils for components, uvm_object_utils for objects, Module 4.3.) Creation is my_driver::type_id::create("drv", this): instead of my_driver::new(...), it asks the factory — via the type's proxy — for an instance, and the factory consults its registry, applies any override, and constructs. The ::type_id::create syntax is the pattern's indirection made concrete: type_id is the proxy, create is the request to the factory. Both halves are mandatory — without the uvm_*_utils registration the factory has no proxy to create from (the next-chapter-bug, and our DebugLab), and without type_id::create you've bypassed the factory and lost substitutability (Module 5.2's bug).

Verification Perspective — the type_id proxy connects the halves

The piece that makes the two halves work together is the proxy — the type_id. Registration builds a proxy; creation uses it; an override swaps one proxy for another. Understanding the proxy is understanding how the pattern's indirection actually functions.

The proxy is the elegant core of the implementation. A proxy (the type_id) is a tiny object — one per registered class — whose only job is to construct one instance of its class. Registration builds this proxy and files it in the factory's registry under the class's name; the class itself doesn't need to be heavyweight at the factory level, just represented by its small proxy. Creation asks the factory for a type, and the factory's job is to find the right proxy — the default one, or an overriding proxy if a test registered an override — and call it to construct. An override, then, is simply the factory replacing one proxy with another in its registry: after set_type_override, a create request for my_driver finds the err_driver proxy instead, and constructs an err_driver. So the proxy is the swappable connector: registration installs it, creation invokes it, and overrides exchange it — all without the construction sites (which only issue create requests) knowing or changing. This is why the pattern enables substitution cleanly: everything routes through small, swappable proxies in a central registry.

Runtime / Execution Flow — creation resolves through the factory at build time

At run time, the pattern's creation half happens during build_phase: each type_id::create is a request the factory resolves — looking up the proxy, applying overrides, constructing — so the tree is built through the factory's indirection.

This ties the pattern to the phase schedule. Registration is effectively done before the run — the uvm_*_utils macros register each class's proxy statically, so by the time anything runs, the factory's registry is fully populated. Creation happens during build_phase (Module 5.2): every type_id::create call is a request to the factory, and the factory resolves it — looking up the proxy for the requested type, checking for an override the test registered, and constructing the resulting instance. So the entire component tree is built through the factory's indirection: not one component is constructed by direct new; each is a request the factory fulfils. That's what makes the whole environment substitutable — because every construction is a factory request, an override registered before build (in the test, top-down) is applied to every matching request as the tree builds. The pattern isn't an isolated trick at one site; it's the uniform construction mechanism for the whole environment, resolved through the factory at build time.

Waveform Perspective — creation through the factory at build time

The pattern's creation half happens at build_phase (zero time), where each create request resolves through the factory. The waveform locates that — registration before the run, creation during build, all before any behaviour.

The create_req pulses in the build_phase region are the pattern's creation half in action: each is a type_id::create resolving through the factory — looking up the proxy, applying any override, constructing the instance — all at zero time, because construction is a function-phase activity (Module 5.1). There's no pin activity during build because nothing behaves yet; the factory is just constructing the tree through its indirection. Registration happened even earlier, at elaboration (the static uvm_*_utils macros), so the registry is ready when these requests arrive. Then run_phase begins and the constructed tree runs (the valid/data activity). The waveform places the pattern precisely: registration before the run, creation (factory requests) in the zero-time build sliver, behaviour after — so the entire tree is built through the factory's request-resolve-construct indirection before a single cycle of behaviour.

DebugLab — the type that couldn't be created (no registration)

my_comp:   class my_comp extends uvm_component;   // NO `uvm_component_utils(my_comp)  ✗
creation:  my_comp::type_id::create("c", this);    // needs a type_id proxy...
reality:   no `uvm_component_utils → no type_id proxy → no factory registry entry
result:    type_id doesn't exist (compile) / factory can't find the type (runtime) → create fails
fix:       add the registration half:
           class my_comp extends uvm_component;
             `uvm_component_utils(my_comp)         // builds the type_id proxy; registers with factory

Common Mistakes

• Missing the uvm_*_utils registration. Without it, there's no type_id proxy, so type_id::create can't construct the type (compile or factory error). Register every class with the matching macro.
• Creating with new instead of type_id::create. Bypasses the factory's indirection, so overrides are ignored (Module 5.2). Use the creation half so construction routes through the factory.
• Mismatching the registration macro. uvm_component_utils for components, uvm_object_utils for objects. The wrong macro registers the wrong kind and can break creation.
• Thinking registration alone is enough (or creation alone). Both halves are required: registration builds the proxy, creation invokes it through the factory. One without the other doesn't give you a substitutable construction.
• Treating type_id::create as just a fancy new. It's the request half of a delegation pattern — the factory decides what to construct (applying overrides). The indirection, not the syntax, is the point.

Senior Design Review Notes

Interview Insights

Exercises

1. Name the halves. For a new component, write the two halves of the factory pattern — the registration line and the creation line — and state what each produces (proxy, instance).
2. Diagnose the failed create. A my_comp::type_id::create(...) fails with "type_id not a member" or "not registered." State the missing half and the fix.
3. Trace the proxy. Explain, in order, what registration, creation, and an override each do to the type_id proxy (build, invoke, swap).
4. Pattern vs new. Explain why type_id::create enables a test's override to take effect while new does not, in terms of the layer of indirection.

Summary

• The factory pattern delegates object construction to a factory instead of direct new, inserting a layer of indirection between requesting a type and getting an instance — and that layer is where substitution happens.
• UVM implements it in two halves: registration (uvm_component_utils/uvm_object_utils registers the class and builds its lightweight type_id proxy in the factory's registry) and creation (type_id::create asks the factory for an instance, which it resolves via the proxy). Both halves are required.
• The type_id proxy connects the halves: registration builds it, creation invokes it through the factory, and an override swaps one proxy for another in the registry — which is mechanically how a substitution works.
• At run time, registration happens at elaboration and creation resolves through the factory during build_phase, so the entire tree is constructed via the factory's request-resolve-construct indirection — making the whole environment substitutable.
• The durable rule of thumb: implement both halves — register every class with uvm_*_utils (builds the proxy) and create every instance with type_id::create (invokes it through the factory) — because the indirection between request and construction is the pattern, and it's exactly where overrides take effect.

Next — The UVM Factory: with the pattern understood, the next chapter looks at the UVM factory as a concrete object — the singleton factory that holds the registry, the API for registration and creation, and how it fits with the rest of the framework you've built up.