Hardware interview practice
uvm_object vs. uvm_component
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
Concise answer
The answer and the key reason
Deeper explanation
Work through the implementation and tradeoffs
`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.
What to remember
- Objects represent data
- Components form hierarchy
- Both support the factory
Practice the complete prompt
