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

Mike,

You'd still have two more hurdles to jump over to get NBAs into your
functions once this restriction is removed.

1. NBAs to program variables are not allowed. I think this restriction
belongs in the realm of linters. It forces a methodology that I know a
lot of people don't agree with.

2. NBAs to dynamically allocated elements (i.e. class members) are not
allowed. I think limiting dynamic elements to a strict procedural
context is more of an implementation consideration than imposing a
methodology. We already have defined events on dynamic elements, so it
should be possible to define what the non-procedural semantics should
be. Perhaps we could limit these contexts to this.member and
const_class_handle.member references when we know the handle would not
be null.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Michael Burns
> Sent: Tuesday, May 02, 2006 9:31 AM
> To: Bresticker, Shalom
> Cc: Arturo Salz; sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: 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