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

If I understand the argument in favor of fork-join_none in functions
correctly, it is that the join_none allows the function itself to execute
and return in zero time, even if the threads that are forked consume time.
I can understand the argument that C++ programmers and verification
engineers might find this useful.  BUT, in my opinion, all fork-join
constructs in functions should be illegal in SystemVerilog, which, as has
been established, is compatible with the Verilog-2001 standard (and arguably
earlier versions of the standard through wording in the text but not the
BNF).

My reasoning for not allowing fork-join in functions is because
Verilog/SystemVerilog is a hybrid verification AND hardware modeling
language.  It is NOT a pure programming language like C++.  I think that for
intuitive simulation behavior of hardware models, is important to maintain
the restriction that a function execute in zero time, including not allowing
a function to spawn threads that potentially consume time.

For the verification and/or IP scenario that Arturo describes, there is a
simple, and obvious, change that maintains all the advantages Arturo pointed
out.  Make the class method a task instead of a function.  Having class
methods that can be either a function or a task allows verification
engineers to have the coding functionality needed.  And it allows functions
to have the restrictions that hardware simulation behavior that is important
in a Hardware Description Language.

Just my thoughts on the topic.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Clifford E. Cummings
> Sent: Friday, February 17, 2006 6:41 PM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: 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
> 
>