Q008FreeDesign Verification
uvm_object vs. uvm_component
Question
A reusable packet configuration has no hierarchy, ports, or phase behavior. Why is extending uvm_object usually preferable to extending uvm_component?
Answer choices
- A. Only uvm_object can be randomized
- B. uvm_object instances are lightweight data objects and do not participate in the component hierarchy or phasing
- C. uvm_component cannot be registered with the factory
- D. uvm_object automatically raises and drops run-phase objections
Short answer
Use `uvm_object` because the configuration is data rather than a structural testbench element. It needs neither a hierarchical parent nor phase callbacks, ports, or persistent component lifetime. Choosing an object keeps construction and reuse simpler without preventing factory registration or randomization.
Why this reasoning works
`uvm_component` is intended for entities that occupy the UVM hierarchy, such as environments, agents, drivers, monitors, and scoreboards. Components have parent-child relationships, names within that hierarchy, and participation in the UVM phase schedule. Those services are useful for testbench structure but unnecessary overhead for a packet configuration value.
`uvm_object` suits transient or portable data including transactions, sequence items, policies, and configuration records. It can still define random fields, constraints, copy and compare behavior, printing, and factory registration. If the class later needs ports, automatic phase methods, or a stable place in the component tree, converting its role to a component may then be justified.
Interview takeaways
- Objects represent data
- Components form hierarchy
- Both support the factory