RE: [sv-bc] Re: [sv-ec] No event triggers in functions?

Mike,

I don't know if such restrictions might be valuable, or they may simply
result in more confusion. The fact is that currently functions do allow
triggering of arbitrary activity via side effects: writing to variables
outside the function boundary that are waited for in an event control,
"@". Other than the syntactical difference of the trigger operator (and
the fact that events are currently non-synthesizable), I don't see any
semantic difference between triggering an event (which is prohibited)
and triggering the activity by writing to a variable that is outside the
function (which is permitted).

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Michael Burns
Sent: Monday, May 01, 2006 8:11 AM
To: Bresticker, Shalom
Cc: sv-ec@eda.org; sv-bc@eda.org
Subject: Re: [sv-bc] Re: [sv-ec] No event triggers in functions?


How about having it depend on the context of the function definition? 
Functions defined inside modules, interfaces, and packages (i.e., design

contexts) have the more restrictive requirements, while those in 
programs and package anonymous program blocks (i.e., testbench contexts)

are less restrictive - allow fork/join_none, nonblocking assign, 
inta-assignment delays, even triggering, anything else that doesn't
block.

--Mike Burns

Bresticker, Shalom wrote:
> I don't know about 'context', but as for 'pure', it might be better to
> have 'pure' be a default, as you would have to write 'impure' if you
> wanted to write risky or non-synthesizable code.
> 
> Shalom
> 
> 
>>-----Original Message-----
>>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> 
> On
> 
>>Behalf Of Brad Pierce
>>Sent: Thursday, April 27, 2006 7:32 AM
>>To: sv-ec@server.eda.org; sv-bc@server.eda.org
>>Subject: [sv-bc] Re: [sv-ec] No event triggers in functions?
>>
>>Another possibility would be to enhance function and task declarations
>>with the 'context' and 'pure' keywords of 26.4.2 and 26.4.3.
>>
>>
>>>Relaxing the restrictions on side-effects is less of a problem.  I
>>>don't know how valuable their protection is to designers.  If they
>>>are seen as too valuable to give up, I suppose one compromise would
>>>be to remove the restrictions only on class method functions.
>>
>>-- Brad
> 
>