shadow variables in system verilog.

[sense]

This is a post related to system verilog.

for(i=0;i<10;i=i+1)

 

[sense]

On Aug 1, 5:27 pm, sense <sagar.1...@gmail.com> wrote:

This is a post related to system verilog.

for(i=0;i<10;i=i+1)

Sorry, the post died. Here is the full question:

This is a post related to system verilog.

How do we have shadow variables in system verilog? For example:

for(i=0;i<10;i=i+1)
if(arr)
fork
begin
apply(arr);
end
join_none

Having a normal integer for i, results in wrong values read in each
child process ( each child process does not have a copy of i).

I tried a work around as:

for(i=0;i<10;i=i+1)
if(arr)
apply_task(arr);

task apply_task(integer j);
fork
begin
apply(j);
end
join_none
endtask

The automatic task creates local copies which serve the purpose, but
will the child processes be killed when the task ends?

Thanks, and sorry for my bad english.

 

[Jonathan Bromley]

On Sat, 1 Aug 2009 05:33:20 -0700 (PDT), sense wrote:

for(i=0;i<10;i=i+1)
if(arr)
fork
begin
apply(arr);
end
join_none

Having a normal integer for i, results in wrong values read in each
child process ( each child process does not have a copy of i).

Yes. A process launched with fork...join_none does not begin
execution until its parent process reaches a timing control
such as #N or @(event). So all branches will see i=10.

I tried a work around as:

for(i=0;i<10;i=i+1)
if(arr)
apply_task(arr);

task apply_task(integer j);
fork
begin
apply(j);
end
join_none
endtask

The automatic task creates local copies which serve the purpose, but
will the child processes be killed when the task ends?

No need to worry about the child process being killed;
fork...join_none launches a completely independent thread.
It can be killed by "disable fork", but not by its parent
thread doing a task exit.

However, I'm not sure your workaround is reliable. The
inner "begin...end" should not begin executing until the
task stalls. If you were to add #0; immediately before
the endtask, it would definitely be OK.

Another solution, probably easier and safer:

for(i=0;i<10;i=i+1)
if(arr)
fork
automatic int identity = i;
begin
apply(arr[identity]);
end
join_none

Now the "identity" variable is sure to be initialized
when the fork...join_none is set up, NOT when the child
thread starts to execute (which is too late).

Thanks, and sorry for my bad english.

I don't think you need to apologize for that in any way.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

On Aug 1, 8:33 am, sense <sagar.1...@gmail.com> wrote:

task apply_task(integer j);
      fork
        begin
          apply(j);
        end
      join_none
endtask

The automatic task creates local copies which serve the purpose, but
will the child processes be killed when the task ends?

No, the child processes will not be killed when the task ends. And
they continue to have access to the automatic variables of the task.

You are describing this as an automatic task, but have not declared it
to be automatic. I assume that this must be inside a class or in some
other situation where it is automatic by default.

Assuming this is actually an automatic task, your workaround should
work fine.

 

On Aug 1, 11:42 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

However, I'm not sure your workaround is reliable.  The
inner "begin...end" should not begin executing until the
task stalls.  If you were to add #0; immediately before
the endtask, it would definitely be OK.

The work around is reliable.

It doesn't matter when the forked subprocess begins executing. The
loop index was copied to the argument j of apply_task by the parent
process when it called the task. The forked subprocess will not
execute until after the parent process returns and then blocks some
time later, but when it does, it still has a stable copy of the loop
index in j.

This #0 idea could be used in the original code, after the
fork..join_none. This would block the parent process so that the
child gets a chance to run, and then the call to the apply task would
capture a copy of the loop index in its argument.