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

Then why not just remove the distinctions between tasks and functions
and be done with it?

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Steven Sharp
Sent: Wednesday, April 26, 2006 4:23 PM
To: sv-ec@eda.org; sv-bc@eda.org; michael.burns@freescale.com
Subject: Re: [sv-ec] No event triggers in functions?

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