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

Yes. That is still an unresolved issue, and I made this same point in a
previous message:

 

I believe that the LRM needs some work regarding what package
declarations 

are allowed or disallowed. For example, should a class object
declaration that 

includes a call to the constructor be allowed in the package? Similar
questions 

can be asked of any dynamic construct, such as a dynamic array that
includes 

a call to its constructor. However, the problem is not because they
spawn threads 

but because it's unclear under what conditions the object is created.

 

And, I'll reiterate my point again. This problem is a limitation of
packages, which is an

orthogonal issue that has nothing to do with allowing threads in
functions. The problem is 

brought on by allowing functions to create dynamic data as side effects,
and those side 

effects includes threads as well as data. Note that we could close this
one issue by making 

such package declarations illegal, that is, functions that lead to
dynamic creation of data or 

threads. But, perhaps there's a more elegant solution.

 

A point that I want to make absolutely clear is that precisely because
packages do not allow 

threads, such as the auxiliary always block I used before, it is
impossible for IP providers to 

deliver packages containing classes that can create background threads
implicitly, that is, 

without an additional explicit task call by the end-user of the class.
And that problem severely 

limits the utility of packages for delivering this type of IP. Allowing
fork/join_none in a class 

constructor does solve that problem.

 

            Arturo

 

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
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