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

Hi folks,

The fork/join_none is a different class of issue - it's clearly more 
problematic, and less important to me. The others (nonblocking assign, 
intra-assignment delay, event triggers - dont' forget nonblocking event 
triggers) are pretty straightforward. If we're concerned about 
synthesizability, that's a whole new discussion. Event triggers are 
already not synthesizable (at least according to 1364.1).

I personally agree with Arturo - I don't see the need for the 
restrictions I mentioned; I just thought they might make it more 
palatable to those who are concerned about side effects of functions on 
scheduling for design.

-Mike

Bresticker, Shalom wrote:
> Arturo,
> 
> The trigger operator less worries me.
> 
> I was more worried about some of the other stuff Mike suggested:
> 
> 
>>are less restrictive - allow fork/join_none, nonblocking assign,
>>inta-assignment delays, even triggering, anything else that doesn't
>>block.
> 
> 
> But I guess synthesis compilers and lint checks could cover all the
> problematic constructs.
> 
> Shalom
> 
> 
> 
>>-----Original Message-----
>>From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
>>Sent: Monday, May 01, 2006 9:45 PM
>>To: Michael Burns; Bresticker, Shalom
>>Cc: sv-ec@eda.org; sv-bc@eda.org
>>Subject: 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