Re: [sv-ec] RE: [sv-bc] RE: Can a function contain a fork/join/any/none?

>From: Gordon Vreugdenhil <gordonv@model.com>

>I think that the statement "functions are not supposed
>to interact with the scheduler" was intended to mean
>"functions are not supposed to be able to direct the
>scheduler to suspend the current thread".  The latter
>is certainly true.

Not quite, at least according to the LRM.  If it were true,
then we could clearly rule out the legality of fork...join
and fork...join_any inside functions based on it.  Both of
them direct the scheduler to suspend the current thread to
to wait for all or some of the subprocesses to complete.

If you believe that it *should* be true, then it is a reason
why these fork statements should not be allowed in functions.


>Functions are not guaranteed
>to be "atomic" in the sense of requiring a scheduler
>to guarantee that no intervening action occurs.  Given:
>   int x,y,z;
>   function void f;
>     y = x;
>     z = x;
>   endfunction
>   initial f();
>   initial begin x = 1; x = 2; end
>It would be valid for an implementation to have y and z
>end up with different values.  Most users would likely
>be both surprised by this and would immediately send
>in support mail saying "your simulator is broken".

And I would agree with them, regardless of what the LRM says.
The LRM goes overboard in allowing arbitrary interleaving of
processes.  If we really accepted those sections of the LRM
as the concurrency model of Verilog, then there would be very
little valid Verilog code out there.  With no operations
that can be assumed to be atomic, it would be very difficult to
write anything that was guaranteed to work.

I agree with you that users often rely on particular behavior
from designs with race conditions, and that they should not.
Scheduling order is not guaranteed, and should not be.

But if users have to write code that assumes process execution
could be interleaved in a completely arbitrary way, that is too
much of a burden.


Steven Sharp
sharp@cadence.com