Why does the UVM factory use a proxy when we register a class in the factory?

Why does the UVM factory use a proxy when we register a class in the factory? What does the proxy exactly do?

Thanks in advance!

1 Like

In reply to Verif Engg:

A proxy is a way of representing the class type as another object. You can’t pass types around dynamically like you can pass a handle to an object. Think of the proxy class handle as an encoded value that represent a type you want to construct.

Please see my course on SystemVerilog OOP, especially the 3rd session.

Also see this paper: http://go.mentor.com/yin-and-yang

In reply to dave_59:

In reply to Verif Engg:
A proxy is a way of representing the class type as another object. You can’t pass types around dynamically like you can pass a handle to an object. Think of the proxy class handle as an encoded value that represent a type you want to construct.

Hi Dave,

I understand how to register an obj/comp with the factory and how to use it. But the need for the proxy class is still confusing.
Could you simplify the above paragraph some more please?

Any class is a data type. Class data type can be dynamically constructed to create class objects, the class objects are accessed via class handles.
I need clarification on what it means when we say we cannot pass types around like we can with a handle/why do we need to represent the class type as another object?

Thanks a lot.

In reply to UVM_beginner:

This is explained in the two links I gave above. But it might help to explain what the alternatives are if we didn’t have the proxy class available to us.

When using the override method we need an argument to pass that represents the class type we want overwritten. We could use a numeric encoding, but that means the create method would have to know in advance the available class starts are


obj = class_base::type_id::create(...);
...
function class_base create(..)
  class_base h;
  ... // code to figure out actual override type
  case (override_type)
    0 : h = class_zero::new();
    1 : h = class_ome::new();
    2 : h = class_two::new();
  endcase[
  return create;
endfunction

This is certainly not OOP friendly. You don’t want to go change this code every time a new class gets added.

Another option is using the actual object itself to pass through the override methods instead of the proxy class object. Then you could just clone the object inside the create method. But this has the problem that many extra objects get constructed that were never intended to be used. For example, classes objects derived from umm_compoent will have all their phase methods called.