Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Michael McNamara (mac@verisity.com)
Date: Tue May 20 2003 - 19:34:51 PDT
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 : Tue May 20 2003 - 17:53:00 PDT