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

Shalom,

1. The proposal was updated on Nov-27 to remove the word 'mature"

2. The description in 10.2.3 is redundant. Tasks, and with this proposal
- functions, do not add any rules for what is legal to be the target of
an NBA.

The text in 10.3 does not apply because functions cannot be disabled.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Monday, December 04, 2006 9:21 AM
> To: sv-ec@server.eda-stds.org
> Subject: [sv-ec] FW: [sv-bc] Can a function contain a
fork/join/any/none?
> 
> This is about Mantis 1336.
> 
> Shalom
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Wednesday, November 22, 2006 1:51 PM
> To: Brad Pierce; sv-bc@server.eda.org
> Subject: RE: [sv-bc] Can a function contain a fork/join/any/none?
> 
> The proposal allows, among other things, nonblocking assignments and
> procedural continuous assignments in functions, which were not allowed
> till now.
> 
> 1. The proposal also says,
> "A function that schedules an event to mature after that function
> returns shall be illegal in any context in which a side effect is
> disallowed or in any context other than procedural code originating in
> an initial or always block."
> 
> I already mentioned that the term "mature" needs to be defined.
> Do nonblocking assignments and procedural continuous assignments fall
> into that category (maturing after return)?
> 
> 
> 2. 1364-2005 says in 10.2.3, regarding tasks:
> 
> "Because variables declared in automatic tasks are deallocated at the
> end of the task invocation, they shall not be used in certain
constructs
> that might refer to them after that point:
> 
> - They shall not be assigned values using nonblocking assignments or
> procedural continuous assignments.
> 
> - They shall not be referenced by procedural continuous assignments or
> procedural force statements.
> 
> - They shall not be referenced in intra-assignment event controls of
> nonblocking assignments.
> 
> - They shall not be traced with system tasks such as $monitor and
> $dumpvars."
> 
> and 10.3 says,
> 
> "The results of the following activities that can be initiated by a
task
> are not specified if the task is disabled:
> - Results of output and inout arguments
> - Scheduled, but not executed, nonblocking assignments
> - Procedural continuous assignments (assign and force statements)"
> 
> Should the proposal change any of this, at least regarding the
> nonblocking and procedural continuous assignments?
> 
> 
> 3. If not, the proposal might need to include similar statements
> regarding functions.
> 
> Thanks,
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On
> > Behalf Of Brad Pierce
> > Sent: Saturday, November 11, 2006 9:17 PM
> > To: sv-bc@server.eda.org
> > Subject: Re: [sv-bc] Can a function contain a fork/join/any/none?
> >
> > Please review Dave's proposal for Mantis 1336.  A copy of his
proposal
> > is attached.
> >
> > -- Brad