Subject: Re: [sv-ec] Disables fork
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Oct 27 2003 - 13:26:07 PST
Francoise,
You understanding is correct: The disable fork terminates any processes spawned by the call to another_task_call (as well as the fork...join_any). Perhaps I misunderstood your question. I thought you were referring to the another_task_call itself, which cannot be terminated since it must have returned by the time the disable fork statement executes.
Arturo
----- Original Message -----
From: Francoise Martinolle
To: Arturo Salz ; sv-ec@eda.org
Sent: Monday, October 27, 2003 1:15 PM
Subject: Re: [sv-ec] Disables fork
Arturo,
The specification of a disable fork in section 9.8.2 does not seem to agree with your interpretation of the example #2.
Section 9.8.2 says :
The disable fork statement terminates all descendants of the calling process, as well as the descendants of
the process' descendants, that is, if any of the child processes have descendants of their own, the disable fork statement shall terminate them as well.
Since my task another_task_call in after the fork join in, there are possible forked processes of the fork join any still executing after another_task_call returns.
I would have thought that the disable fork kills all remaining processes from the fork_join_any + any other processes spawned by another_task_call .
Am I wrong?
Francoise
'
At 09:57 PM 10/24/2003 -0700, Arturo Salz wrote:
Francoise,
In the first example all processes spawned by the get_first task are disabled. That is, all four
wait_device task processes are killed, which also kills any processes spawned therefrom.
In the second example, the task is not disabled because the task get_first does not execute
in parallel with the task another_task_call. The disable fork executes after another_task_call
returns. By the way, if that other task call does spawn additional processes then all those
processes would be killed by the disable fork.
In the last example the 3 tasks (task1, task2, and task3) do not execute concurrently, so there
is nothing to kill. Unless those tasks did spawn additional processes, which would then be killed.
Arturo
----- Original Message -----
From: Francoise Martinolle
To: sv-ec@eda.org
Sent: Friday, October 24, 2003 12:28 PM
Subject: [sv-ec] Disables fork
Some questions about the disable fork.
Can someone answer them?
I looked at the example given in section 9.8.2 and I have a question.
If I modify the task to have two forks, does the disable fork applies to all processes spawned by both forks?
task get_first( output int adr );
fork
wait_device( 1, adr );
wait_device( 7, adr );
wait_device( 13, adr );
join_any
fork
wait_device (2, adr);
join_none ;
disable fork;
endtask
If I modify the task to add another task call before the disable fork. Does the disable fork also disables this task call?
task get_first( output int adr );
fork
wait_device( 1, adr );
wait_device( 7, adr );
wait_device( 13, adr );
join_any
another task_call (adr);
disable fork;
endtask
What about if I write:
task get_first( output int adr );
task1( 1, adr );
task2( 7, adr );
task3( 13, adr );
disable fork;
endtask
Does "disable fork" disables task1, 2 and 3 even though there is no fork?
Francoise
'
At 03:11 PM 10/20/2003 -0400, Joao Geada wrote:
Hi John,
What I meant is that in SystemVerilog there is a new category of disables
(disable fork, Section 9.8.2) which are intended to be used to kill specific
threads of execution, more specifically, this construct causes all child threads of
a particular thread of execution to be terminated.
The typical useage assumed for this construct is testbench architectures that
are organized as sets of communicating parallel processes, and this form of
disable is used to abort a specific set of such processes.
(transaction oriented testbenches are typically organized this way, which is
why I mentioned them in the original email)
Look at the example on page 67 (section 9.8.2). This shows an example of the use
of the new form of disable.
For comments on the more "Verilog"ish disables and why I believe these are
likely to be used less in SystemVerilog, read section 8.1 (Procedural Statements
and Control Flow, Introduction) and section 8.9 (Disable)
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Stickley, John
> Sent: Monday, October 20, 2003 11:11 AM
> To: Joao.Geada@synopsys.COM
> Cc: Sv-Cc
> Subject: Re: [sv-cc] Disables and DPI interaction
>
>
> Joao,
>
> If you don't mind ...
>
> Joao Geada wrote:
> > Disable usage notes:
> > In Verilog, disables were primarily used to effect exception control jumps.
> > (note: there were other uses of disable, but such uses were rarer)
> > In SV 3.1 that purpose of disable is largely superceded by the provision of
> > additional control constructs (break, continue, return, etc);
> > However, due to all the testbench process control constructs it is possible
> > that disables will be used to control "transactions" within the testbench.
>
>
> ... I was wondering if you can clarify what you meant by this last statement.
>
> Thanks,
> -- johnS
>
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
This archive was generated by hypermail 2b28 : Mon Oct 27 2003 - 13:34:37 PST