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
> 
> 
>