Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Wed May 21 2003 - 15:25:29 PDT
Mac & Steve,
Truly, your attempts to educate me are appreciated. Alas, though, all
this is unnecessary. I understand extremely well how traditional Verilog
works, I've got a pretty solid grasp of Verilog 2001, and an
ever-expanding appreciation of SystemVerilog's additions to the fray.
The semantics of fork-join in a static environment are very well
understood by customers and vendors, alike. The entire discussion/debate
I intended to launch is limited to semantic quirks around forks in the
presence of automatic variables and then whether SystemVerilog's
introduction of a fork-join_none has any bearing on all this. I don't
believe the discussions about how static variables interact with
fork-join are pertinent, except to indicate the probable expectations of
a user coming from a long history of Verilog.
-randy.
Michael McNamara wrote:
>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 - 15:37:23 PDT