Subject: Re: [sv-ec] Disables fork
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Oct 27 2003 - 13:15:56 PST
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: <mailto:fm@cadence.com>Francoise Martinolle
>To: <mailto:sv-ec@eda.org>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:20:50 PST