Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Dave Rich (David.Rich@synopsys.com)
Date: Wed May 21 2003 - 07:29:29 PDT
Hi folks,
I agree with Mac 100% for join and join_any,but not for join_none, the
case where the spawned thread might out-live the normal lifetime of the
automatic variables it may reference. And if you have multiple spawned
threads, you now have a difficult problem of trying to figure out which
thread will become the end of life for an automatic variable, which may
not be known until runtime.
Another problem is passing unique values to multiple spawned threads.
Suppose I wanted to write this
for(int i = 0;i<N;i++)
fork
do_this(i);
do_that(i);
join_none
Unless I put a non-zero delay in the loop, all of the tasks will pass
the final value of i as its argument, not 0,1,2,3....
By creating a copy of the automatic variables for each thread, both
problems are eliminated. For communication between threads, use static
variables or mailboxes.
Dave
Michael McNamara wrote:
>Randy Misustin writes:
> > Hi Dave and Jamie,
> >
> > I feel like one of the core issues is getting obfuscated. Please allow
> > me to submit a different snippet of code. In:
> >
> > begin
> > automatic int i = 0;
> > fork
> > i = 1;
> > join
> > #10 $display(i);
> > end
> >
> > ..does the value 0 get displayed or the value 1? Does the answer change
> > if the join is a join_any?
> >
> > -randy.
>
>I would be very surprised if the answer anything other than 1; and
>there would certainly be backwards compatibility issues.
>
>If we want to stick to Verilog-1364 semantics, then fork does not
>create a new variable, and instead references the nearest enclosing
>declaration of an 'i', which is the automatic int; this same 'i' is in
>scope to the fork, and to the $display; and the $display can not be
>executed until the join completes: hence the fork..join wrapper should
>have no effect. The fork..join does not create any new scopes as
>well.
>
>In 1364, all the automatic does is make the 'i' cease to exist once we
>leave the begin .. end (as well as make the 'i' invisible to
>$monitors, $dumpvars, pli accesses, et cetera), as well as make
>multiple silmultaneous executions of this begin end have their own
>copy of an i.
>
>Because of the '= 0' the automatic doesn't even usefully serve to
>prevent a previous value of i from being available, as the unilateral
>assignment to 0 overwrites this old value when the scope is reentered.
>
>-mac
>
> > Dave Rich wrote:
> >
> > > Hi Jamie,
> > >
> > > The same rules apply. Tasks and functions are just another local
> > > namespace for variable declaration, just like a begin/end.
> > >
> > > In your fork/join example below, the output is copied when the task
> > > exits, not when the thread it spawns ends.
> > >
> > > In SV3.0, the process statement created its own copy of automatic
> > > variables used in its thread. I think the same will have to apply to
> > > join_none.
> > >
> > > Dave
> > >
> > >
> > > Jamie LaFlamme wrote:
> > >
> > >> Hi Arturo,
> > >>
> > >> I was specifically talking about the SV extension to allow automatic
> > >> variables within named blocks that are not part of a task or
> > >> function. The Verilog 2001 restrctions only talk about hierarchical
> > >> references to automatic task and function items.
> > >>
> > >> Regards,
> > >> -Jamie
> > >>
> > >> -----Original Message-----
> > >> *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> > >> *Sent:* Monday, May 19, 2003 5:46 PM
> > >> *To:* Jamie LaFlamme; sv-ec@eda.org
> > >> *Subject:* Re: [sv-ec] fork..join_none/join_any and automatic
> > >> variables
> > >>
> > >> Jamie,
> > >> Automatic variables were introduced into Verilog 2001.
> > >> Accordingly, limitations on the usage of automatic variables are
> > >> listed in IEEE-1364 LRM. I've reproduced the relevant section below:
> > >> _In Section 10.2.3_
> > >> Because variables declared in automatic tasks are deallocated at
> > >> the end of the task invocation, they shall not be used in certain
> > >> constructs that might refer to them after that point.
> > >> They shall not be assigned values using non blocking
> > >> assignments or procedural continuous assignments.
> > >> They shall not be referenced by procedural continuous
> > >> assignments or procedural force statements.
> > >> They shall not be referenced in intra-assignment event
> > >> controls of non blocking assignments.
> > >> They shall not be traced with system tasks such as *$monitor
> > >> *and *$dumpvars*.
> > >> _In Section 10.3.1_
> > >> Automatic function items can not be accessed by hierarchical
> > >> references. Automatic functions can be invoked through the use of
> > >> their hierarchical name.
> > >> Arturo
> > >> ----- Original Message -----
> > >> *From:* Jamie LaFlamme <mailto:jamiel@Model.com>
> > >> *To:* 'sv-ec@eda.org' <mailto:%27sv-ec@eda.org%27>
> > >> *Sent:* Monday, May 19, 2003 1:06 PM
> > >> *Subject:* [sv-ec] fork..join_none/join_any and automatic variables
> > >>
> > >> Has there been any discussion about what the expected behavior
> > >> should be when automatic variables are used within a
> > >> fork..join_none or fork..join_any block?
> > >>
> > >> For example:
> > >>
> > >> task automatic auto_fork(output a, output b);
> > >> fork
> > >> #10 a = 1; // argument 'a' updates after auto_fork()
> > >> task exits???
> > >> #20 b = 1;
> > >> join_none
> > >> endtask
> > >>
> > >> Should references to automatic variables declared in a parent
> > >> block of a fork be disallowed from within the fork (at least for
> > >> join_none and join_any)? Is there some other way to address this
> > >> issue?
> > >>
> > >> Related to this, I noticed that the end of section 5.5 includes
> > >> the following restriction: "automatic or dynamic variables cannot
> > >> be used to trigger an event expression". This restriction doesn't
> > >> exist in the 1364-2001 LRM - was the change intentional? If any
> > >> forked processes are allowed to access automatic variables
> > >> declared in an enclosing block then it seems like triggering off
> > >> an automatic variable should be allowed. Personally I'd rather
> > >> just prohibit access to automatic variables in parent blocks from
> > >> ALL forks in both SV and 1364...
> > >>
> > >> Also, the ballot draft doesn't explicitly prohibit hierarchical
> > >> references to automatic variables in a named block like:
> > >>
> > >> initial
> > >> begin : init1
> > >> automatic int count;
> > >> ...
> > >> end
> > >> initial init1.count++;
> > >>
> > >> Should this be added to the spec?
> > >>
> > >> Thanks,
> > >> -Jamie LaFlamme
> > >>
> > >
> >
>
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 07:51:50 PDT