[A simple question] what dose the prefix "m_" mean?

[SeanChou]

Hi,

As title, the "m_" for "m_packed_size" in uvm_packer.svh. I guess it means local or protected, but why not add local or protected? (m_sequencer is protected)

Are this kind of prefix defined any where in the document? thanks!

[uwes]

members labeled m_* are typically fields/tasks/functions which should be considered internal/implementation dependent and are not part of the UVM standard. they are subject to change at any time without notice or deprecation process. no user code should be using any m_* coming from the uvm_pkg. the standard+library reference also should not have references to any m_* field/member.

why is that:

the reason for this is that sv doesnt have "friend" modifiers like c++ has (http://www.cplusplus.com/doc/tutorial/inheritance/). basically the externally visible api of a sv class is the same for ALL other classes. you cant distinguish between code which can access certain members and classes which cannot access certain members.

[SeanChou]

Thanks for this comprehensive answer! will there be a friend in SV2012?

[dave_59]

Sean,

So far, no one has requested that the friend construct be added to SystemVerilog. SystemVerilog is derived from Java, which does not have the concept of friends. Do a search for "Friends in Java" and you will see the proper way to deal with this issue.

Many times I see people forget that a member is always a friend to a class of the same or derived type. For example

class Packet;
  protected int i;
  function integer compare (Packet other);
    compare = (this.i == other.i);
  endfunction
endclass

The reference to other.i is allowed because other is the same class type.

Another problem is the fact that the OVM/UVM was designed without the use packages in mind, mainly because of inconsistent SystemVerilog implementations at the time. Everything in is one giant monolithic package, so importing uvm_pkg exposed everything unprotected to the user.