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

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