need clarification: local constructor issue in singleton class

[Robert.g.Liu]

One of the singleton class coding styles is like this:

module top;

class singleton;

static local singleton me = new;

local function new ();

endfunction

endclass: singleton

endmodule: top

The invocation of "new" constructor is in the class but not in the static function like "get_inst". Simulators don't handle this code uniquely.

Please help confirm whether it is allowed by the LRM.

[uwes]

hi,

one issue here between the lines is that the execution order of static initializers is NOT defined in the LRM as far as i know. so it would be unclear what the result would be

class singleton;

int a=3; // 3 for sure

int c=a+1; // could be 1 or 4

endclass

another issue with the singleton code the way its written is that the singleton is unconditionally allocated and not just on demand. typically the singletons look like

module top;

class singleton;

static local singleton me;

local function new ();

endfunction

static function singleton get();

if(me==null)

me=new();

return me;

endfunction

endclass: singleton

initial

singleton::get();

initial

singleton::get();

endmodule: top

[Robert.g.Liu]

Hi Uwe,

Actually we can have two kinds of coding style for singleton class: let's call them "starve" and "lazy". If I know the instance of the singleton is a must in a testbench and it doesn't play with other classes, it can use this "starve" coding style, eliminating the get_inst method and its invocation.

For example, we can put the waveform dump function call in the constructor with local attribute, use can "include" the class file inside his tb top module and it's done.

Not all the simulation can compile the code: static local singleton me = new; since the "new" has a "local" modifier.

How does the LRM state this point?

[uwes]

you can have the local/protected modifier for new. i think this was not in the original ieee1800-2005 lrm but its in the -2009 release. as far as i know all of questa,vcs,ius support this.

[Erling]

hi,

one issue here between the lines is that the execution order of static initializers is NOT defined in the LRM as far as i know. so it would be unclear what the result would be

class singleton;

int a=3; // 3 for sure

int c=a+1; // could be 1 or 4

endclass

Is this really correct? The expression c=a+1 refers to a, and the rule is then that a must have been declared already. The initializer for a is part of the declaration of a, thus the value is known already to be 3 at point of declaration of c, and the initializer for c should therefore be 4. What do you mean the value could be 1?

One should think that one reason for merging initialization with the declaration was to avoid this confusion. In C++ for example, where the two steps are separated, the initializers can be listed in an order that isn't the actual initialization order (which is the declaration order). It would seem that if the SV improvement in this regard comes with undefined initialization order, then this isn't an improvement after all, but a defect.

Erling

[Robert.g.Liu]

no, actually questa doesn't support this, even I enabled -sv09compat. It said, "Illegal access to local constructor."

[dave_59]

A local method is only available to methods of the same class. You cannot initialize a static member by calling a local method. Instead try

local static singleton me = singleton::get();

P.S local constructors have always been in the IEEE 1800 standard and has been supported Questa.

[Erling]

A local method is only available to methods of the same class. You cannot initialize a static member by calling a local method.

Is this a bug or does the LRM state that an initializer for a static member is not in the scope of the member's class?

Erling

[Robert.g.Liu]

I found a statement in the LRM-2009, page 138.

8.17 Data hiding and encapsulation

A member identified as local is available only to methods inside the class.

That way the "static local singleton me = new;" should be illegal per the LRM.

However, I think the LRM statement is too restrictive. The invocation of local member should be allowed in the scope of its class, rather than only in the scope of methods inside the class. And constructor function is also a kind of member as well.

In addition, this is supported by all simulators, though it appears illegal per the LRM:

module top;

class singleton;

static local bit _dummy = do_something();

static local function bit do_something ();

endfunction

local function new();

endfunction

endclass: singleton

endmodule: top

Edited November 22, 2012 by Robert.g.Liu