Concept Round: Factory and config_db · UVM

Part 13Senior PrepIntermediate

On this page

This round is where interviewers separate people who have used the factory from people who have debugged it. Almost every question has a confident wrong answer that sounds right: "the more specific path wins", "the last override wins", "run_test's argument picks the test". Each of those is false in the library, and the interviewer knows it.

A senior answer states the rule as the library implements it, says why the rule exists, and names how you would prove it on a live bench (a factory print, a config trace). The DMA bench supplies the examples: a type override that cuts packets short, an instance override that swaps one agent, and a passive agent that only stays passive if super.build_phase() runs.

The questions

Why type_id::create() instead of new()? Is new() illegal on a component?

A derived class has no registration macro. What happens when you create it or override to it?

Two instance overrides match the same path. Which one wins? And two type overrides?

Weak answer: The last one wins, like config_db.

Strong answer: For instance overrides, the first registered matching override wins: they are pushed in order and the lookup stops at the first match, and there is no replace flag. Type overrides have a replace argument, default 1, so a second type override for the same type replaces the first. The trap in practice: a base test registers an instance override for *.out_agt, a derived test adds a more specific one for env.out_agt, and the base's still wins because it was registered first. On the DMA bench, dma_backpressure_test swaps only env.out_agt to axis_sink_agent; env.in_agt keeps axis_agent.

Follow-up: “Is the instance path relative?” With the form the bench uses, axis_agent::type_id::set_inst_override(axis_sink_agent::get_type(), "env.out_agt", this), the path is relative to the caller, so it means uvm_test_top.env.out_agt.

Home lesson: How create resolves overrides

When must an override be registered for it to take effect?

Weak answer: Anywhere in the test; the factory applies it.

Strong answer: Overrides are read at create time, so they must be registered before the object is created. In practice that is the test's build_phase, before the env is created: dma_truncate_test calls set_type_override and then super.build_phase(phase), with the comment that the env is created after the override. An override registered after creation changes nothing for objects that already exist; for items created per transaction it applies from then on.

Follow-up: “Can you override from the command line?” Yes: +uvm_set_type_override=<req>,<override>[,<replace>] and +uvm_set_inst_override=<req>,<override>,<full_path>, applied in uvm_root's build_phase, before the test's build_phase creates anything. The test object itself already exists by then, so it cannot be replaced this way.

Home lesson: Command-line overrides

The env and the test both set the same config_db field for the agent. Which value does the agent get?

Weak answer: The more specific path wins, or else the last set.

Strong answer: During build_phase, the setter higher in the hierarchy wins: precedence is 1000 minus the setter's depth, so uvm_top or a null context is 1000, the test usually 999, the env 998. The test wins even if the env set later and even if the env used an exact path while the test used a wildcard; path specificity does not decide precedence. Between sets of equal precedence, and for every set made after build, the last set wins. The point of the rule: a test can override an env default without editing the env.

Follow-up: “How do you debug a config surprise?” +UVM_CONFIG_DB_TRACE shows every set and get with its scope; print_config() and check_config_usage() show what was set and never read.

Home lesson: Config resolution order

You set is_active with the path "env.agt.*". Does the agent see it?

The top calls run_test("dma_smoke_test") and the command line has +UVM_TESTNAME=dma_rand_test. Which test runs?

You pass +uvm_set_config_int=uvm_test_top.env,num_jobs,5 and the env's config_db#(int)::get misses it. Why?

Your agent's build_phase skips super.build_phase(). What breaks?

One config object per agent, or many scalar config_db entries?

Weak answer: Many scalars; each knob can be set independently.

Strong answer: One typed config object per agent, set once by the env or test and read once in build. It carries the virtual interface, is_active and protocol knobs; it can have constraints and be randomized; and a typo becomes a compile error instead of a silent miss. config_db lookups are string matches over the resource pool, so their cost grows with the number of entries and wildcards: never call get() per transaction in run_phase.

Follow-up: “Can the config change during the run?” The object is a handle, so a component that reads a field when it uses it sees the change; document which fields are live. For a value that must wake a component, wait_modified() exists but is rarely the cleanest answer.

Home lesson: config_db performance

How do you prove which class the factory actually built?

Rapid fire

Check yourself The env sets max_len to 16 at the end of its build_phase; the test set it to 64 earlier in its own build_phase. What does the agent read, and would it change if the env set it in run_phase?

64 during build: the test's set has precedence 999 against the env's 998, whatever the order. In run_phase the rule changes: the last set wins, so a get after the env's run-time set reads 16.

Check yourself A derived test adds set_inst_override for env.out_agt to a new monitor-only agent, but the base test already overrode *.out_agt. Which agent is built?

The base test's choice. Instance overrides are matched in registration order and the first match wins; the base test's build_phase registered its override first.

Check yourself A test calls super.build_phase() (where the base test creates the env) and only then registers a type override for the stream driver. Does the override apply to the driver? Would an override of the env type apply?

The driver override applies: the env object exists, but its build_phase, which creates the agents and their drivers, runs after the test's build_phase returns. An env-type override does not, because the env was already created. Register overrides before super.build_phase() so the answer never depends on who creates what.

Next: Concept Round: TLM and Analysis: the scoreboard compared nothing; where did the transactions go?

Up nextConcept Round: TLM and Analysis

Practice this lesson Report an error