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

>> Yes, this was the case that I thought of also.  The behavior is strange,
>> since each call gets back the result assigned by the previous call.
>
>I don't agree that those are the obvious semantics.  Every call should
>get back the result assigned by the last call in the previous iteration
>of the process (always block).

Obvious or not, those are the correct semantics by the LRM.  You do have
to notice that storage for static functions is not explicitly described,
so you have to use the rules in 10.2.3 (1364-2001) for static tasks.
Those rules state that "All variables of a static task shall be static in
that there shall be a single variable corresponding to each declared local
variable in a module instance, regardless of the number of concurrent
activations of the task."

Note that it says a single variable for each instance, not a single
variable for each call site or each process.  All calls to a static
task (or function) instance share a single set of static variables.
And 10.3.2 defines that the function return value is a variable implicitly
declared in the function.  So that function return value is shared by all
the callers of a particular static function instance.

Given this, it is technically noncompliant to inline a static task or
function at a call site using variables local to that call site or
calling process.  However, I wouldn't expect anyone to complain about it.
The sharing of these statics for locals in a static task or function is
generally considered a potential problem to be avoided, not something to
rely on.  On the other hand, I would expect a complaint if you didn't
properly share variables explicitly declared as static in an automatic
task or function.

BTW, my original description is only accurate if the later call happens
enough after the previous one for the NBA to have completed.  Multiple
calls between NBA queues would keep getting the value assigned by the
last NBA to complete.

Steven Sharp
sharp@cadence.com