Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to implement the factory mechanism". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Factory is actually a macro, and it is necessary to understand the principle of the factory mechanism when designing operations such as set_override. Factory mechanism is more reflected in internal programming applications, and it provides the possibility for the implementation of many other mechanisms. In other words, the factory mechanism is the internal work of UVM, so the external work of UVM is naturally the field automation mechanism.

1.UVM certification

When defining a class, UVM strongly recommends using uvm_component_utils or uvm_object_utils macros to register. UVM knows that we have defined a class:

Class An extends uvm_component

`uvm_component_utils (A)

....

Endclass

When you register A with the above code, to create an instance of A, you can do this:

An a

A = A::type_id::create ("a", this)

Assuming that your A does not use uvm_component_utils instantiation, then An instantiation only uses this way:

An a

A = new ("a", this)

This idea seems a little simpler than the previous one, but the last one is recommended by UVM. Instantiation using UVM authentication allows you to use many of the features of UVM, but not the latter.

2.override function

Suppose we have defined a my_driver ourselves, and this driver is sufficient for running 80% of the case, but in the remaining 20% of the case, we need to make some changes to the behavior of the my_driver, and then we can use the override function. The first step in using the override feature is to derive a class from my_driver and define the behavior of the class:

Class new_driver extends my_driver

...

`uvm_component_utils (new_driver)

Endclass

After that, call the override-related function in the build_case of the specific case:

Class case_x extends base_test

Function void build_phase (uvm_phase phase)

...

Set_type_override_by_type (my_driver::get_type (), new driver::get_type ())

Endfunction

Endclass

After the above process, then when running case_x, the my_driver running in the system is of type new_driver, and its behavior is the behavior of new_driver. However, there is a premise that when my_driver is instantiated in his agent, he should instantiate it in the way factory does.

Class my_agent

My_driver drv

Function void build_phase (uvm_phase phase)

...

Drv=my_driver::type_id::create ("drv", this)

Endfunction

Endclass

If you do not use the above method of writing, but use the writing method of drv=new ("drv", this) for instantiation, then the override function cannot be achieved.

The essence of 3.factory: rewriting the new function

With factory, in addition to creating an instance using the class name, you can instantiate it through a string that represents the class name, and you can also perform override functions. So in essence, the factory mechanism is actually an overload of the new function in systemverilog. Because the original new function is too simple and has too few functions, after the improvement of the factory mechanism, there are many more ways to instantiate.

This is the end of the content of "how to implement the factory mechanism". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.