uvm_reg doesn’t have `uvm_object_utils macro. As a result, it won’t allow factory override. Why is UVM designed this way?
Thanks!
In reply to eda2k4:
uvm_reg is a virtual class that should never get constructed so it doesn’t make sense to register it with the factory. This is true for most classes in the UVM bass class library.
Given that most RALL descriptions are automatically generated and contain tens of thousands of registers, using the factory is unnecessary and would create a tremendous amount of overhead.
In reply to dave_59:
Hi Dave,
Thanks for your reply. We are not trying to construct uvm_reg type object directly. The scenario we have is that we want to add some feature to all generated uvm_reg type classes. As you mentioned RAL are typically autogenerated, those classes are extended directly from uvm_reg. We are not able to modify the script to generate these classes. If uvm_reg allows factory override, we can create a new class from uvm_reg, add this new feature, then simply type-override uvm_reg with new type (with added feature). This way all generated classes will get this new feature.
In reply to eda2k4:
The UVM factory won’t help you here. You can only override the top level class you’re trying to construct. It won’t let you override an underlying base class. You need to write another script that modifies the output of your register model generator to extend from your class extended from uvm_reg. If you told us what features you’re trying to add, there might be other ways of accomplishing what you want.
In reply to dave_59:
If you wanted to implement the pre and post callback tasks for the read and write operations in the register model, would you then have to extend the uvm_reg class and modify your generator or are there other ways to do that?
In reply to rol@napatech.com:
This i believe is unnecessary since you can easily create your own cbs by extending yhe uvm_reg_cbs class.
Then you would simply add it after creation:
Your_reg_cb = cbs_type::type_id::create( “your_reg_cb” );
uvm_reg_cb::add(your_reg_blok.target_reg, your_reg_cb );
Since you will not create a cb per register since it simply emulate a function shared by several registers (like fuses or lock registers or similars) you just have to add to all the registers which have the same functionality
Regards
In reply to Rsignori92:
I actually do want post read and write for all the registers and preferably achieve this without changing the register model generator. I also got the same idea as eda2k4 that if I extended the uvm_reg class and used the factory to override it I could accomplice this. As dave_59 stated you can only use the factory to override the top-level class, but at the same time he hinted that there might be another way depending on what you wanted to change. So is there another way of adding post read and write callbacks to all registers or should I extend the uvm_reg class and modify the generator to use the extended class?
In reply to rol@napatech.com:
Yes you can use register callbacks to add post read and write functionality to your registers.
So you could override the base top class, or you can extend each class (using a script) which will add local to each register the function you need or you can use the callback to add such post write read. This is mainly up to you or your encouragement