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

I'm just going to copy the sv-ec from now on, since from the perspective
of the sv-bc, this only deal with issues related to the testbench. The
main place that I have seen this is in the new function for a
constructor.

This snippet of code below was submitted to the SPIRIT working group
back in September. Since then I have seen it in a few other places,
basically the same.

class ahbram;
   ahb_slv_if.comp sigs;
   local ahbram_callbacks cbs[$];
   local bit [1023:0] ram;

   extern function new(string          instance,
                       ahb_slv_if.comp sigs);

   extern function bit [1023:0] peek(bit [31:0] addr);
   extern function void poke(bit [  31:0] addr,
                             bit [1023:0] data);

   extern function void register_callbacks(ahbram_callbacks cb);

   extern local task main();
endclass: ahbram


function ahbram::new(string          instance,
                     ahb_slv_if.comp sigs);
   this.sigs = sigs;
   fork
      this.main();
   join_none    
endfunction: new


I would grant that if a fork/jone_none were legal in a function, then I
can see stretching the LRM to say that the task call inside the fork is
executing outside the function, or even stretching the LRM to say that
the "new" function is not really a function, its a constructor and
doesn't have to follow the rules of Verilog function.

Now we have the statement

ahbram R1 = new();

creating a thread. But that statement could be in a package, or inside
another function be called outside of a procedural context

Dave



> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Brad
> Pierce
> Sent: Friday, February 17, 2006 12:23 PM
> To: sv-bc@eda.org
> Cc: sv-ec@eda.org
> Subject: Re: [sv-bc] Can a function contain a fork/join/any/none?
> 
> Cliff,
> 
> That's not at all what I asked.  I don't see anything wrong with using
> fork-join in functions.
> 
> INSTEAD, I asked Dave, who started this thread, why so many people are
> asking him the question in his subject line.  My guess is that they
are
> indeed seeing examples of this style and then asking Dave, "is that
> really legal?".
> 
> Yes, it's really legal.
> 
> How might they be seeing examples of this legal usage?  Maybe the
people
> that are asking him are tool developers who are getting bug reports
> about this legal usage, in which case the need for backward
> compatibility would be even stronger.  It would be interesting to
know.
> 
> -- Brad
> 
> -----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 12:01 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] Can a function contain a fork/join/any/none?
> 
> Hi, All -
> 
> Just the sv-bc on this message (I'm tired of getting two of everyone
> of these messages)
> 
> Brad asked the question and I think Stu hinted around the question:
> 
> What is the use-model for adding fork-join to a function?
> 
> Are there any engineers doing this? (And has anybody slapped them for
> doing it?  :-) )
> 
> The engineers that ask this question, do they understand that no
> delays are allowed in a function (not even #0 delays or nonblocking
> assignments that cause events to be scheduled in later event regions
> within the same timestep) and that fork-join are generally not
> synthesizable and are really most useful when you add some form of
> delay to the forked paths within a testbench?
> 
> I can't say for sure, but I don't believe either Stu or I have ever
> shown engineers a fork-join in a function in training and I don't
> think we ever intend to teach this coding style.
> 
> I understand that it might be important to add some form of
> clarification to the LRM but whatever clarification we add should
> come with the strong editorial comment that this is/was a bad idea.
> 
> I will support whatever the group goes for on this and then I will
> never teach an engineer to add fork-join to a function (unless
> somebody can come up with some ultra-astonishing use-model that I
> have not heretofore recognized).
> 
> Regards - Cliff
> 
> ----------------------------------------------------
> 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
>