Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Wed May 21 2003 - 09:09:29 PDT
Hi Dave,
I agree with your exception for fork_none, but believe this should be
the rule, not the exception (see my reply to Mac).
-randy.
Dave Rich wrote:
> 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
>> > >>
>> > >
>> >
>>
>>
>>
>
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 09:46:33 PDT