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

Steven Sharp wrote:
>>> ... each call gets back the result assigned by the previous call.
>>
>> Every call should
>> get back the result assigned by the last call in the previous iteration
>> of the process (always block).
> 
> 
> "All variables of a static task shall be static"

Got that; I agree it complicates life because concurrent uses of the
function produce asynchronous multiple drivers of the static storage
registers.  Let's set that aside and say there's just one process.

> 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.

Breaking up the static storage is non-standard, but in the days before
the "automatic" keyword this was considered by many folks as the "friendly"
thing to do.  Let's confine that to non-standard operating modes and
say that there is one register for the result.

Is it still non-compliant to inline the static task or function?

I think not.  I don't believe that sequential calls which share a
storage location can communicate via non-blocking assignment.  It's
certainly not deterministic behavior, which puts it outside the
synthesizable/formally verifiable subset.  If you plan to specify
semantics for NBAs in functions (why?) they should at least resemble
the equivalent inlined code semantics - which from the sounds of
your proposal would have to include a partial SYNC statement that can
implement the mid-clock update to the bound values of the function's
locals.  Lacking that bit of semantics, I'd say that "last value from
the previous iteration of the process" is the best deterministic
definition around.

Greg

P.S. I don't favor extending functions to allow NBAs - symmetry with
      tasks is not that important.

> 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
>