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

Thanks - I  apologize for causing this thread to unblock :) I know 
there's been an awful lot of discussion on this topic.

Our perspective is definitely a verification one - we're looking to do a 
verification class library, and satisfying the function restrictions 
turns out to be challenging in some circumstances. I can understand the 
concerns with fork/join_none - having threads spawn from unanticipated 
places seems pretty perilous. However, I'm frankly having a difficult 
time seeing the peril motivating the other restrictions, such as no 
event triggers, no non-blocking assigns, and things like that. They 
don't seem necessary to avoid any semantic or implementation snafus; 
they just look like an attempt to enforce an idea of good modelling 
practice - an idea that is losing applicability now that the scope of 
the language has grown to encompass verification as well as design.

My fear here is that if SystemVerilog as defined in the standard proves 
unweildy to verification engineers, vendors are going to just go ahead 
and add subtly nonstandard extensions (such as more accomodating 
functions) to please their customers. Then, our dream of having portable 
testbenches will be gone - we'll become dependent, without even 
realizing it, on vendor-specific non-standard features - it will be 
almost impossible to avoid.

Mike Burns

Steven Sharp wrote:
> Mike,
> 
> I believe that the reason that restriction was added was simple: Verilog-XL
> does not allow event triggers in functions, and the rules in that section
> are largely based on the language as originally defined by Verilog-XL.
> 
> However, I think this is a symptom of a philosophical split over the
> purpose of functions in Verilog.  One view is from a design perspective,
> and appears to be close to the original intent.  In this view, a function
> should be reasonably "pure", avoiding side effects on the design.  It is
> supposed to represent a user-defined operator on its inputs, like a piece
> of combinational logic.  The language was never very strict about this.
> Things like print statements are useful to debugging.  You can't keep a
> function from writing to variables, even though that might create side-
> effects unless you added a lot of extra messy rules.  But most of the
> rules in 10.4.3 seem intended to avoid "impurities".  Since triggering
> an event has no purpose other than to create a side-effect, prohibiting
> it is consistent with this philosophy.
> 
> The other view is from a verification perspective, and is closer to that
> of common software languages.  In this view, a function is just a subroutine
> that returns a value, and in Verilog, has no delay.  There is no expectation
> that it be "pure", and side-effects may be the main reason for calling it.
> The relaxation in SystemVerilog of many of the Verilog rules on functions
> (allowing output and inout arguments, or no input arguments, or void
> function returns) came from this viewpoint.
> 
> There will be other disagreements because of this split.  For example, the
> issue was raised recently of whether fork-join_none should be allowed in
> functions, including subprocesses that contain time-controlled statements.
> The philosophical views came up during the discussion (though there are
> other technical issues involved also).  Within the last week I got a
> request to allow nonblocking assignments within functions, so that they
> could be used in put()/get() class method functions, to avoid race
> conditions.  This was intended for a verification class library.
> 
> Steven Sharp
> sharp@cadence.com
>