Q044FreeDesign Verification
How to Pass a Virtual Interface with uvm_config_db
Question
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
Short answer
Publish the concrete interface handle through `uvm_config_db#(virtual bus_if)` using a scope that covers the agent’s driver and monitor, then retrieve it during each component’s build phase. The UVM factory cannot create an HDL interface instance.
Why this reasoning works
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.
Interview takeaways
- Publish a virtual handle
- Scope it to agent descendants
- Verify every config `get`