Jump to content
Sign in to follow this  
Robert.g.Liu

need clarification: local constructor issue in singleton class

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by Robert.g.Liu

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×