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

Hi, Arturo -

Am I missing something here?

Don't the two threads T1() and T2() have to be 0-delay threads and 
therefore the fork-join-none really makes no difference? (Just put 
the two threads into the void function).

Have I missed something about classes or void functions that allow 
delays to creep into functions?

Regards - Cliff

At 04:52 PM 2/17/2006, Arturo Salz wrote:

>When 1364-2001 writes "A function shall execute in one simulation 
>time unit", I
>understand that users take that quite literally as the meaning of 
>"time consuming".
>And, after introducing fork/join_none, which is definitely not time 
>consuming, I
>can understand why many people would conclude that fork/join_none must be
>allowed in functions. Frankly, I see nothing wrong with allowing 
>fork/join_none in
>functions. A fork/join_none is semantically equivalent to triggering 
>the execution
>of one or more threads from within the function, as in the following code:
>
>             function void F();                       function void F();
>                 // some initialization                   // some 
> initialization
>                 fork                                          -> ev;
>                     T1();                                  endfunction
>                     T2();
>                 join_none                              always @ev T1();
>             endfunction                               always @ev T2();
>
>Both versions of the above function F() accomplish the same thing, 
>except that
>the one on the right is more verbose and doesn't encapsulate the functionality
>as well as the one the left. If the threads triggered by the 
>function are related
>to the function call --- for example, they may be associated with 
>the particular
>transactor being created --- then the code on the right becomes a 
>exceedingly more
>difficult to write: For example, the function may have to add the 
>transactor handle
>to some dynamic data such as queue, which is then examined by the threads.
>It's also important to remember that the code on the right  cannot 
>be written in a
>package, thus, making life even more difficult for both model 
>writers and users of
>the model.
>
>Forking threads from within a constructor is very common idiom in 
>both Vera and
>C++ models. If we were to disallow this in P1800, I imagine a lot of 
>IP writers will
>be upset. I suspect that these are the same people that have been questioning
>Dave on the availability of this feature. I'm not advocating that 
>SystemVerilog allow
>all types of fork/join within functions, only fork/join_none, which 
>is fundamentally
>not a time consuming construct.
>
>Sorry for blasting this to both sv-bc and sv-ec, but I believe it is 
>important to let
>both committees know about this (sorry for the copies Cliff).
>
>             Arturo

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training