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

I sorry, Stu, but from the quoted email it seems you misunderstood.  The
use of fork join in functions is ALLOWED in Verilog 1.1a (March 1987),
and ALLOWED in 1364-1995, and ALLOWED in 1364-2001.

Use of delay statements is NOT allowed in functions.

Now, the use of a fork join statement which does not contain a delay
statement is of so little utility that it is really of no practical use.
The simulator is free to run in any order the various blocks within the
fork join statement, and is not mandated to run them in a particular
order.  All of them must complete in zero time. Hence at best this could
be used to construct a random number generator.  However, as a practical
basis, a simulator is free to pick an order at compile time and always
run the set of statements enclosed in the function in any order.  Hence
the random number generator would not be.

A fork that can not contain a delay is like a $write that can not have
an argument.

Now, consider the fork join_none.  We can allow this in functions, and
still require no use of delay statements in the blocks so contained.
This will be consistant with 1364 Verilog, both in leaving the freedom
for folks to use whatever statements they like in functions; also
consistant in making the fork join_none of no real use as its statements
will all complete in zero time.  

And then we can move on to the next topic...


Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Saturday, February 18, 2006 9:19 AM
To: sv-bc@eda.org
Subject: Re: [sv-bc] Can a function contain a fork/join/any/none?

Non-member submission from Ambar Sarkar

-----Original Message-----
Sent: Saturday, February 18, 2006 5:13 AM

Stu,

Just another point of view here. 

I understand that from a hardware modeling point of view, fork-join/none
in
a function does not seem intuitive. But we are talking about a
verification
point of view as well, which adds in levels of abstraction and aspects
that
are not intuitively mapped to hardware. For example, what do the
constructor
and destructor methods have to do with hardware? 

Coming from that angle, and having looked at various verification
environments, VIP codes, and similar stuff at several client
engagements,
what Arturo says below re: fork/join none is in fairly common use.
Disallowing that may help with some tool implementation issues, but the
users will be somewhat inconvenienced. I suspect that verification
engineers
will just decide to stay away from defining functions, as they cannot
always
anticipate how the functionality embedded in a function may be extended
in
future..

BTW, here is an informal vote in favor of merging the Verilog and SV
standards. As a user, I find it extremely frustrating to find out what
SV
says, what Verilog LRM says, and then make sense of it. Of course, I in
no
way undermine the scope of that effort and let those more knowledgeable
decide.

Respectfully,

-Ambar



-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Stuart
Sutherland
Sent: Saturday, February 18, 2006 1:50 AM
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?


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