Hardware interview practice
How to Pass a Virtual Interface with uvm_config_db
A top-level module must make one virtual bus_if available to both an agent's driver and monitor. Which pattern is most idiomatic?
Answer choices
- A. Use a type override from virtual bus_if to the concrete interface instance
- B. Pass the interface through every transaction using the sequencer
- C. Store virtual bus_if in config_db at a path matching the agent descendants, then get it in the relevant component build phases
- D. Create the interface with uvm_factory::create_component_by_name
Concise answer
The answer and the key reason
Deeper explanation
Work through the implementation and tradeoffs
The top module elaborates the real `bus_if` instance and can publish its virtual handle under a field such as `vif`. A target pattern like `uvm_test_top.env.a0.*` makes that entry visible to descendants of the selected agent. Both driver and monitor then perform a type-matched `get` during construction.
Keep the scope narrow enough that another agent cannot accidentally receive the wrong interface. The template type and field name used by `set` and `get` must agree, and consumers should report a fatal error when retrieval fails. Passing the handle inside transactions confuses stimulus data with structural connectivity, while UVM factory APIs cannot elaborate a SystemVerilog interface.
What to remember
- Publish a virtual handle
- Scope it to agent descendants
- Verify every config `get`
Practice the complete prompt
