1.I have learnt that it is not necessary to register all component class to factory only test is enough. What if I register all component during verification excution what are the consequence I can face?
thanks
Ridip
In reply to ridip.mandal:
All UVM components, i.e. units which are building your UVM environment should be registered with the factory and also all transient objects. There are 2 exceptions:
(1) there is no need to register configuration objects with the factory.
(2) Components like analysis_ports, exports, tlm_fifo need not be registered with the factory. These are components which are not intended to be replaced.
In reply to ridip.mandal:
All uvm objects and components should be registered with factory to get leverage of factory override features, which will help you in writing an reusable env.
Regarding your second point, I have never seen any difference in simulation behavior w.r.t. factory registration. It would help if you can post an example code or trying using same random seed for both runs to rule out any dut issue.
In reply to rohitk:
The second topic is a tool-related topic. Optimization means the simulator is removing all content which is not relevant for him, reducing the amount of code he has to process.
All simulators allow you to remain the visibility of internal signals even in the optimization mode. Contact your simulator provider to get the right switch for the simulation command.
In reply to chr_sue:
Thanks for clarification, I was also confused on how factory registration is related to optimization. This needs to be taken up with tool vendor.
In reply to ridip.mandal:
There are no consequences for registering a class definition with the factory other than it limits your constructor to having one argument (name) for classes derived from uvm_object, and two arguments (name, parent) for classes derived from uvm_component. There can be performance consequences for creating class objects with the factory if you are going to be creating a lot of objects over time.
You should get in the habit of registering all classes with the factory. You may not have a reason for overriding it now, but at some point, someone will want to do it and they can’t because you did not register it with the factory. An exception to this might be automatically generated classes, like a register model where you know it will not use the factory. An there can be a slight time 0 performance penalty for registration once you start getting into the 10s of thousands of class registrations.
My other suggestion is to get in the habit of always using the factory create() method instead of new() to construct any class derived from uvm_component or uvm_sequence_item that is not defined inside the UVM base class library(uvm_tlm_fifo).
In reply to dave_59:
Hi Dave,
When I checked for the uvm_heartbeat class in the UVM library, it’s not registered with the factory (I don’t see uvm_object_utils). Now I need to extend this class to add custom features. How should I proceed further?
In reply to muneebullashariff:
As you noticed, uvm_heartbeat is not registered with the factory. Also, none of its methods are virtual. So any use of your extended uvm_heartbeat would have to know about it anyway. So using the factory does not make much sense.
In reply to dave_59:
In reply to muneebullashariff:
As you noticed, uvm_heartbeat is not registered with the factory. Also, none of its methods are virtual. So any use of your extended uvm_heartbeat would have to know about it anyway. So using the factory does not make much sense.
Hi Dave,
Many thanks for your quick response.
Out-of-curiosity, is this the right way of coding? What benefits or drawbacks we would encounter with this?