Re: [sv-ec] RE: [sv-bc] Can a function contain a fork/join/any/none?

Doug,

The notion of a Singleton object is a well-known Object-Oriented design
pattern. I believe that this design pattern can be constructed using existing
language constructs contained in the current LRM. No changes to the current LRM
should be required in order to support Singleton objects.

The following example is based on the description contained in:
"Design Patterns Elements of Reusable Object-Oriented Software", Gamma, et al.


class Singleton;
   local static Singleton _instance;             // handle to the only instance

   static function Singleton getSingleton();
      if (_instance == null) _instance = new();  // lazy initialization
      return _instance;
   endfunction

   protected function new();             // can only access via getSingleton()
   endfunction
endclass : Singleton

Singleton ms;    // handle to a Singleton

ms = Singleton::getSingleton;
ms = new();                     // illegal - new() is protected


Only one instance of Singleton can be constructed since all instances
of it are managed by Singleton::getSingleton().


Neil



Warmke, Doug wrote On 03/02/06 08:08,:
> Francoise,
> 
> IMHO the horses have left the barn.
> Class object handles can exist in packages, and can be
> initialized with calls to new().  Other variables can be
> initialized using variable declaration assignments (VDA's),
> and the rhs of those can include function calls.
> 
> So whether you feel it's an intended use or not, we are
> already allowing code to execute in the package's scope. 
> And the LRM needs to define semantics for when that code
> is executed.
> 
> To me, it's simply too complicated to try and select exactly
> which items in the package scope are actually allocated and
> initialized depending on use.  It's simpler to just say all
> items get elaborated if the package is referenced in any way
> by the rest of the design getting elaborated.  Further, this
> allows the interesting singleton use model I have demonstrated,
> which many will feel is cleaner than the alternative you
> demonstrated.  I don't see a reason not to allow it.
> 
> Hope you have a great vacation!
> 
> Regards,
> Doug
>  
> 
> -----Original Message-----
> From: francoise martinolle [mailto:fm@cadence.com] 
> Sent: Tuesday, February 28, 2006 1:39 PM
> To: Warmke, Doug; 'francoise martinolle'; 'Arturo Salz'; Rich, Dave;
> sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
>  
> 
> Doug,
> 
> I am still against saying that the whole package gets elaborated, 
> even for declarations which are not used. That is a waste.
> I would prefer to not say anything in the standard.
> That is fine as long as there is no execution code in a package. As soon
> as
> you put executable code, then we have that issue. I still argue that a
> package
> is not built specifically for what you are trying to do.
> A single top level module which does open and close a file is what I
> would
> use.
> 
> I hope this discussion will continue when I come back from vacation a
> week
> from today 
> because I am very interested in this definition.
> 
> Francoise
>     '
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Warmke,
> Doug
> Sent: Tuesday, February 28, 2006 3:23 AM
> To: francoise martinolle; Arturo Salz; Rich, Dave; sv-bc@eda.org;
> sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
> Francoise,
> 
> Thanks for the feedback.
> 
> I don't have a problem with your first statements about only elaborating
> a
> package if something declared in it is actually used in a design.
> Another choice could be that the package is simply referenced, say with
> a
> wildcard import, but then nothing is actually used.
> That would qualify the package for a full elaboration.
> But real use of package identifiers would be fine with me as a criteria
> for
> elaborating the package.
> 
> Still, the question is open about other items in that package which are
> not
> actually used.  My answer would be:  They are all
> guaranteed to be elaborated by the LRM.   But we should hear
> opinions from others on that topic.  Maybe there is some reason not to
> do
> so, but I can't think of anything significant.
> 
> Finally, the example you rewrote defeats the original purpose I had in
> mind.
> i.e., the package is supposed to completely encapsulate a
> coherent set of utility functions.   For someone to use that 
> functionality, they simply have to import and use functions, tasks, and
> objects from the package.  In your style, a client of that package would
> be
> responsible for writing separate initial and final blocks that take care
> of
> internal package details.  That is bad encapsulation and an unclean
> usage
> model for the client.  Furthermore, a module isn't really ideal for that
> job, since you can instantiate a module more than once.  What you want
> is a
> singleton-instanced scope, like a package.
> 
> I don't see any problem with allowing some executable code in packages.
> We already have the cat out of the bag when you consider that class
> objects
> can be initialized using new() at their declaration sites. 
> I wouldn't condone initial or always blocks in packages, but I don't see
> the
> harm in allowing final blocks to exist.  Otherwise there is no way in
> the
> language to encapsulate singleton destruction code, and provide a
> completely
> encapsulated set of functionality in a package.
> 
> Regards,
> Doug
> 
> -----Original Message-----
> From: francoise martinolle [mailto:fm@cadence.com]
> Sent: Monday, February 27, 2006 8:53 AM
> To: Warmke, Doug; 'Arturo Salz'; Rich, Dave; sv-bc@eda.org;
> sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
> 
> I think it would be an advantage for the tool if the LRM specified that
> unless something of a package is
> used, that package is not elaborated. The parser can easily detect that.
> On
> the
> contrary it would be much more difficult for a tool to determine that
> the
> elaboration of such 
> package can be avoided because initializers inside it have no side
> effect
> (if the LRM stated 
> that all packages are elaborated).
> In the single command line invocation, users throw design source modules
> and
> libraries and the tool
> elaborates what it needs. We do not want to elaborate all the packages
> found
> in the libraries 
> just because they are scanned. We elaborate a module because we have
> found a
> module instance that uses it.
> 
> I think that we should not allow execution in a package.
> I believe that all behavioral execution should be in modules. This
> was I think one of the main difference for which we created a new design
> unit.
> Typically a package should contain generic functionality which can be
> shared
> by more than one design unit in the design and by many designs. This
> concept
> forces and
> enables to write shareable functions/tasks/types and global variable
> declarations.
> For ex, I see a different way that users would code an IO package.
> I rewrote the io example that Doug has in mantis 878 in a way that does
> not
> use final blocks in packages.  It is slightly more complex but adds a
> few things which are representative of what would be placed in a
> package:
>    - general library functions to open and close 
>    - with strong error checking and messaging.
> 
> 
> If someone just wants to open a file, then I think they would write it
> like
> Doug and place it in a module rather than a package (and place the final
> block
> in the module as well).
> 
> My example of a typical IO package.
> 
> package IO;
> 
>     function int open_f(input string filename, input const string access
> )
>     begin
>         int errno;
>         reg [1024:0] errmsg;
>         int mcd = $fopen(filename, access));
>     
>         if (mcd >0)
> 	     return mcd;
>         else begin
>              errno = $ferror(mcd, errmsg);
>              $display("Failed to open %s", filename); 
>              if (errno!= 0)
> 	          $display ("error %s", errmsg);
>         end
>     end
>     endfunction 
> 
>     function void close_f (input int mcd)
>     begin
>         int errno;
>         reg [1024:0] errmsg;
>         $fclose(mcd);
>         errno = $ferror(mcd, str);
>         if (errno != 0)
> 		$display ("error closing %d", mcd);
>     end
>     endfunction
> 
>     io_mcd;  // mcd visible to whole design
> 
> endpackage
> 
> module top;
> import IO::*;
> 
>    initial
>        io_mcd = open_f("+w", "my_file");
> 
>    final
> 	 close_f(io_mcd);
> 
> 
> endmodule
> 
>  
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Warmke,
> Doug
> Sent: Saturday, February 25, 2006 1:09 AM
> To: Arturo Salz; Rich, Dave; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
> Arturo,
> 
> I agree the question is valid.
> The reason I have the answer I do is to provide for a means of singleton
> object construction and destruction.
> 
> Even if others don't agree with my take on it, I still think the LRM
> should
> address the issue about allocation and initialization of declaration
> initializers for package items that are not explicitly imported into the
> simulation's elaborated image.
> 
> Note that this issue can apply in a few scenarios:
> 1. A package contains multiple object declarations with initializers.
>    Some are imported or explicitly referenced, others are not.
>    Are the unimported objects allocated and initialized?
> 2. A package contains multiple object declarations with initializers.
>    A wildcard import statement in the design references the package,
>    but in fact no items are imported from the package at all.
>    Are any objects in the package allocated and initialized?
> 3. A package is somehow included in a simulation database, but there
>    are no import statements or explicit references to the package.
>    Are any objects in the package allocated and initialized?
> 
> Probably 3 is out of the scope of the LRM.  I would expect that if a
> tool
> did provide a means for inclusion of such a package in the simulation
> database, the answer to 3 would follow the pattern established in 1 and
> 2.
> 
> For ease of reasoning and intuitive behavior, I would like the answers
> to
> questions 1 and 2 to be "yes".  This also allows users the possibility
> of
> singleton initializer function semantics.
> If an implementation determines that an initializer function has no side
> effects, then it can optimize away calls to that function.
> 
> We should address both issues 1 and 2 in the LRM.
> Otherwise we'll get into a lack of portability across tools.
> 
> If SV-EC agrees with my answers of "yes", I can create a proposal
> instituting this semantic in the LRM.
> 
> If anyone thinks "no" is the right answer, please explain.
> 
> Regards,
> Doug
>  
> 
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Friday, February 24, 2006 1:19 AM
> To: Warmke, Doug; Rich, Dave; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
> Doug,
> 
> But, Dave's question is still valid. If a package is (by some
> unspecified
> tool dependent mechanism) included in a design but no element from the
> package is imported either via an import statement or using the
> package-qualified name then should the simulator even allocate and
> execute
> the declaration initializers (which may contain functions with
> additional
> side effects)?  And, if no data from a package is ever used and no
> function
> from the package is ever called, should the simulator even call the
> corresponding final block (assuming we allow that).
> 
> So is this behavior just an optimization, or something that the LRM
> should
> address.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Warmke,
> Doug
> Sent: Thursday, February 23, 2006 4:30 PM
> To: Rich, Dave; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
> fork/join/any/none?
> 
> Dave,
> 
> I would like the answer to your question to be "yes".
> And I think this should be specified in the LRM.
> 
> That way folks could count on using VDA's in packages as a way of
> getting
> singleton initialization code to run.
> 
> SV currently lacks a way to run singleton destruction code based in
> packages.
> 
> See http://www.eda.org/svdb/bug_view_page.php?bug_id=0000878,
> which expresses the possibility of allowing final blocks to be declared
> in
> packages for this purpose.
> 
> I also thought of Francoise's refinement points, but she beat me to the
> punch on those.
> 
> Regards,
> Doug
> 
>  
> 
> 
>>-----Original Message-----
>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>>Rich, Dave
>>Sent: Thursday, February 23, 2006 3:14 PM
>>To: Steven Sharp; sv-ec@eda.org; sv-bc@eda.org; 
>>Arturo.Salz@synopsys.com
>>Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a 
>>fork/join/any/none?
>>
>>This raises the question "Does a package exist if no one imports it?"
>>Having static space allocated by an unused package is not usually an 
>>issue, but if it creates threads, I can see that as being a problem. I
> 
> 
>>vaguely remember this as the reason that modules and continuous 
>>assignments were not allowed in packages.
>>
>>
>>>-----Original Message-----
>>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>>
>>Steven
>>
>>>Sharp
>>>Sent: Thursday, February 23, 2006 12:24 PM
>>>To: sharp@cadence.com; sv-ec@eda.org; sv-bc@eda.org; 
>>>Arturo.Salz@synopsys.com
>>>Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a 
>>>fork/join/any/none?
>>>
>>>
>>>
>>>>[Arturo]
>>>>My point is that all of these issues exist in other
>>
>>contexts and the
>>
>>>>tools must be able to deal with them. By extension, these do not 
>>>>represent any fundamental or implementation problem.
>>>
>>>But Dave has pointed out that this allows some things that are not 
>>>possible with functions triggering other processes, or with tasks.
>>>In particular, it allows creating a thread whose parent is a 
>>>variable initialization.  This in turn means it has allowed root 
>>>threads to be created in a package, which could not happen before.
>>>
>>>I don't know what specific problems Dave is concerned this
>>
>>will cause.
>>
>>>Steven Sharp
>>>sharp@cadence.com
>>
>>
>>
> 
> 
> 
> 
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------