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

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