Tip:
Highlight text to annotate it
X
Hello my name is Axel Scherer. I will give you a quick introduction into Factory Methods
in UVM. Factory methods create a lot of flexibility
in your verification environment. They basically avoid hard coding and creating a lot of dependencies.
So when you do a construction of an object, you can do it on the fly. Implicitly, this
will make your code much more stable. First of all, you need much fewer code. The dependency
chains will be broken and you can basically change anything, anywhere, in the system very
easily. Let’s look at an example. In a classic way let’s say we have a class called Mid
and we want to create an object inside of the task. The object would be of type class
Bottom. This is how we would do it. We basically use the constructor new. All good and dandy
and this works fine. But let’s say we have a different kind of application of the same
system. How are we going to deal with this? Now we have an alternative class. Now I can
derive this Class Bot from the original Class Bot. That saves me some code. That’s good
and we certainly will do that, but that’s the effect of actually using this? I would
have to change actually here my instantiation to make this happen. In effect, his means
I would have to change my class Mid and if Class Mid is also instantiated at a higher
level I would have to change that as well. Implicitly, you see where this leads. You
have a ripple effect of a little code change at the bottom going up through the system.
That creates a major maintenance nightmare. Using factory methods will solve this problem.
We start again with our Class Bottom and want to create an object here. Instead of using
new, we are using factory method Create. By default, it will still create an object of
Class Bot, but we can now easily change this. We can now say “Hey, I need Class Bot Alternative”.
And we can use a factory override method. So basically, change the behavior during the
construction. This change of behavior does not influence Class Mid. So, the structure
will stay the same and you have enormous flexibility at any layer of your hierarchy to swap things
around and then change things, as you need it. Let’s look at this in terms of a interface
UVC. Let’s say we have our agent with all the subcomponents and now you have some change
in requirements. You don’t have to change the agent anymore. In the past you would have
to do that. You can just take your driver, the new driver alternative and do an override.
And again the code for all the agents and the UVC on top of that and the test bench
on top of that all stay the same. Let’s look at some actual code for this. Here we
have a agent, just like we saw it. This is an apb_master_agent, so it will have to create
its environment and this happens down here - let me go down further - where is it – I
overshot. Here we go, you can see when the sequencer is created, the subcomponent of
the agent, it doesn’t use the new constructor, it uses the factory method create, and the
default type is apb_master_sequencer. So, if you build this and you don’t tell the
system anything, it will create a sequence of type apb_master_sequencer, but you have
the opportunity to overwrite what type the agent should create in the system and the
agent will stay the same. It will not notice the change by itself, it will happen on the
fly.
You can find more videos like this, either on this youtube channel or at the video library
for the Incisive Simulator at support.cadence.com. Thank you very much, have a great day and
talk to you soon.