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

Non-member submission from Kevin Cameron
-----Original Message-----
Date: Sat, 18 Feb 2006 21:45:51 -0800 (PST)
Message-ID: <Pine.LNX.4.58.0602182145001.7269@typhoon.he.net>

My 2c worth:

The problem is that a function is a dynamic context, if the threads of
the
fork access the context (stack frame) of the function the function
cannot
complete until the fork completes (even if it's a join-none). Analysing
the usage is non-trivial so it's better (IMO) to disallow the fork.

Kev.


On Fri, 17 Feb 2006, Stuart Sutherland wrote:

>
> 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
> >
> >
>
>