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

Shalom,

Yes, an implementation may choose to suspend a function
in the middle, but that is an implementation's choice.
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.  Obviously functions can cause
scheduling events by performing activities such as writing
to variables on which other threads have sensitivities or
by disabling other threads.  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".

Given the kinds of arguments that we (as a vendor) still
here about wanting particular results from designs with
clear races, I suspect that many users do not really
understand the Verilog concurrency model; they certainly
often express displeasure about implementations having
different behavior on designs for which Verilog provides
no guarantees.  I've often thought that a useful (and amusing)
switch to have in an implementation would be "-randomize_scheduling"
which would actually go out of its way to permute the "natural"
scheduling order.  This would expose huge numbers of bad
assumptions that designers make regarding simulation
semantics.

Gord.


Bresticker, Shalom wrote:
> Hi,
> 
> I never got any responses to this. Any comments?
> 
> Thanks,
> Shalom
> 
> 
>>-----Original Message-----
>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>>Behalf Of Bresticker, Shalom
>>Sent: Friday, February 17, 2006 11:46 AM
>>To: Rich, Dave; sv-bc@eda.org; sv-ec@eda.org
>>Subject: [sv-bc] RE: Can a function contain a
>>fork/join/any/none?
>>
>>Is it really true that "functions are not supposed to interact
>>with the scheduler"?
>>
>>In 1364-2005, 11.4.1(a) says, "Execution of statements in a
>>particular begin-end block can be suspended in
>>favor of other processes in the model;"
>>
>>and 11.4.2 says, "Another source of nondeterminism is that
>>statements without time-control constructs in behavioral
>>blocks do not have to be executed as one event... At any time
>>while evaluating a behavioral statement, the simulator may
>>suspend execution and place the partially completed event as a
>>pending active event on the event queue. The
>>effect of this is to allow the interleaving of process
>>execution, although the order of interleaved execution is
>>nondeterministic and not under control of the user."
>>
>>This implies that the scheduler may suspend function execution
>>in the middle. If this is not so, it needs to be explicitly
>>stated.
>>
>>Shalom
>>
>>________________________________________
>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>>Behalf Of Rich, Dave
>>Sent: Thursday, February 16, 2006 4:12 PM
>>To: Ambar Sarkar; sv-ec@eda.org; sv-bc@eda.org
>>Subject: [sv-bc] RE: [sv-ec] Can a function contain a
>>fork/join/any/none?
>>
>>"time consuming"  would mean anything that could block a
>>thread(process). But there are really two separate issues here.
>>One is the fact that functions are not supposed to interact
>>with the scheduler. Events get created outside the function as
>>outputs are assigned, but the function does no scheduling. We
>>also don't have to worry about active region functions versus
>>inactive-region(program block) functions either.
>>
>>But the other major issue is that time consuming threads roots
>>can start from more places than just always or initial blocks
>>if you allow a function to call a fork_join_none. They can
>>start form continuous assignments or in variable declarations.
>>And those variable declarations could be in a package, which in
>>turn are not supposed to contain any rooted threads.
>>
>>Dave
> 
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com