Q: What is the difference between uvm_component and uvm_object?
OR
Q: We already have uvm_object, why do we need uvm_component which is actually derived class of uvm_object?
A: uvm_component is a static entity and always tied(bind) to a given hardware and/or a TLM interface
uvm_object is a dynamic entity and is not tied to any hardware/TLM interface
uvm_component like uvm_driver is always connected to a particular DUT interface because throughout the simulation its job is fixed i.e. to drive the designated signals into DUT
uvm_object like uvm_transaction is not connected to any particular DUT interface and its fields can take any random value based on randomization constraints.
Though uvm_component is derived from uvm_object, uvm_component has got these additional interfaces
* Hierarchy provides methods for searching and traversing the component hierarchy.
* Phasing defines a phased test flow that all components follow, with a group of standard phase methods and an API for custom phases and multiple independent phasing domains to mirror DUT behavior e.g. power
* Configuration provides methods for configuring component topology and other parameters ahead of and during component construction.
* Reporting provides a convenience interface to the uvm_report_handler. All messages, warnings, and errors are processed through this interface.
* Transaction recording provides methods for recording the transactions produced or consumed by the component to a transaction database (vendor specific).
* Factory provides a convenience interface to the uvm_factory. The factory is used to create new components and other objects based on type-wide and instance-specific configuration
Acronyms used:-
DUT - Design Under Test
TLM - Transaction Level Modelling
API - Application Programming Intefaces
OR
Q: We already have uvm_object, why do we need uvm_component which is actually derived class of uvm_object?
A: uvm_component is a static entity and always tied(bind) to a given hardware and/or a TLM interface
uvm_object is a dynamic entity and is not tied to any hardware/TLM interface
uvm_component like uvm_driver is always connected to a particular DUT interface because throughout the simulation its job is fixed i.e. to drive the designated signals into DUT
uvm_object like uvm_transaction is not connected to any particular DUT interface and its fields can take any random value based on randomization constraints.
Though uvm_component is derived from uvm_object, uvm_component has got these additional interfaces
* Hierarchy provides methods for searching and traversing the component hierarchy.
* Phasing defines a phased test flow that all components follow, with a group of standard phase methods and an API for custom phases and multiple independent phasing domains to mirror DUT behavior e.g. power
* Configuration provides methods for configuring component topology and other parameters ahead of and during component construction.
* Reporting provides a convenience interface to the uvm_report_handler. All messages, warnings, and errors are processed through this interface.
* Transaction recording provides methods for recording the transactions produced or consumed by the component to a transaction database (vendor specific).
* Factory provides a convenience interface to the uvm_factory. The factory is used to create new components and other objects based on type-wide and instance-specific configuration
Acronyms used:-
DUT - Design Under Test
TLM - Transaction Level Modelling
API - Application Programming Intefaces
1 comment:
Thank you for sharing information it was really useful . You can also refer to our UVM Papers ,Also you can visit at
E Learning VLSI Expert
Post a Comment