Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Tue May 20 2003 - 17:17:34 PDT
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.
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:30:10 PDT