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

-----Non-member submission by Michael Burns-----
Sent: Wednesday, April 26, 2006 4:57 PM

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
>