Re: [sv-ec] fork..join_none/join_any and automatic variables


Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Michael McNamara (mac@verisity.com)
Date: Thu May 22 2003 - 02:51:08 PDT


Let me try.

The ways to create a new scope are:

via a named block, a named fork, a task, a function, or a module
keyword.

All a fork does is start new thread(s) of execution. It has no effect
on the lives of other variables, be they automatic or not.

An unnamed fork does not create a new scope. Definition of fork is in
clause 9.8.2 of IEEE 1364-2001 (page 146 in my printed copy)

There is also a named fork, which may be confusing you; and while this
does create a new scope, this has no effect on other variables in the
design, whether automatic or not.

In truth the main reason for the named fork is so one can conveniently
disable execution of all threads started by the fork, and hence
implement a timeout:

fork : get_memory
  #100 disable get_memory; // after 100 ticks give up
  fetch_data(data,address,clk); // fill 'data' with value in cell 'address'
join

One could define a variable in this named scope, as follows:

 reg [128*8:1] string = "cheap viagra";
 
 fork: search
   reg [8*128:1] result = "Not Found";

   begin
     WebSearch("Google",string,result);
     disable search;
   end

   begin
     WebSearch("AltaVista",string,result);
     disable search;
   end

   begin
     WebSearch("AskJeeves",string,result);
     disable search;
   end
   
 join
 
 theresult = search.result;

 Of course what fork doesn't do is not stated, as the standard is
 written affirmatively, telling you what will happen, rather than
 listing all of what will not happen.

 A useful way to think of the Verilog memory model is like the Fortran
 NAMED COMMON, rather than Pascal or C stacks.

 Until 'automatic' was added to the language, there was no user
 visible dynamic memory allocation needed for Verilog.* Hence at
 design elaboration time, one would know precisly how much memory is
 needed to implement the design. Again, this makes sense as Verilog
 is a hardware description language, and it's hard to add registers to
 a piece of silicon after its been wrapped in plastic

 *yes Steve, one does need dynamic memory to implement the trasnport
 delay features of non blocking assigns. However, these are not user
 visible.



This archive was generated by hypermail 2b28 : Wed May 21 2003 - 14:51:01 PDT