In the previous post we looked at how we can use the factory to direct an existing test by changing the type of sequence items that get created by that test's sequence. The UVM factory's type override mechanism is indispensable in achieving this degree of flexibility. For small designs with interfaces of different kinds, type overrides are sufficient, but once we start talking about DUTs with two or more interfaces of the same type, we will immediately run into limitations.
And you mentioned if we weren’t using the sequence macros, we’d need to make sure we set the context of the item we would be creating. So we should set the content for some_component in
some_object obj = some_object::type_id::create(“obj”, some_component);
I think the “some_object” may be the uvm_item inside the sequence.
May I know “some_component” is the p_sequencer in sequence or the hierarchy name of some other component ?
You’re half right. For the root sequence (the one you’re starting on the sequencer directly), you’d set it’s context using the sequencer. If you want to create sequences/sequence items inside other sequences, then it’s even better to use the “create_item(…)” function to specify the new sequence as a child to the parent sequence:
A good way of seeing how this works is to look in the expansions of the `uvm_do macros.
After look at the detail of the `uvm_do macros, it looks like passing the m_sequencer as the “some_component”.
I can using the get_full_name() to get the correct path of sequence.
There is a third argument as well to this function: which is ‘contxt’. And this is a string to which, generally hierarchical path should be passed. This hierarchical path will now become the new context
Even this could be used to set the context of an object. Somehow, this third argument is given more priority than the second argument of create function call.
You might be already knowing this… But posting here just as additional information…
Yep, I didn’t want to complicate the post even more. I mentioned the context argument in a different post. It’s useful if you want to create an instance tree of objects (not components), for example sequences.
The override will change the type of object being created, but the variable which stores the reference will still be of the base type. This means it won’t be possible to access the new methods through that variable. With casting (i.e. the $cast function), you could get a reference to the new type and access the new methods. This isn’t a very clean OOP style, though. Ideally you would not need any new methods, because you would be able to override the existing methods in such a way that they do what you need, without having to change anything in the code that calls them.
