Subject: Re: [sv-bc] Fwd: Re: [sv-cc] Semantics of disable as applied to task/func arguments
From: Peter Flake (Peter.Flake@synopsys.com)
Date: Mon Oct 27 2003 - 05:25:01 PST
Dave,
Surely the side effects that consist of assigning to global variables or
ref arguments are well defined by procedural order. They happen before the
disable or they do not happen.
The other effects on output or inout arguments will not happen, since they
are copied after the function return.
Peter.
At 13:00 24/10/2003 -0700, Dave Rich wrote:
>Steven,
>
>I still don't think there is any issue here. Section 11 of 1364-2001
>defines the behavior as undefined, but even if it did define a behavior,
>it wouldn't matter because the statement that called the function would
>also be disabled, so the return value is discarded anyway. Side effects
>are inherently undefined in this case.
>
>Dave
>
>
>Steven Sharp wrote:
>
>>>A) you are not allowed to disable a function, only tasks and named blocks
>>>
>>
>>You cannot disable a function directly. You can still disable it by
>>disabling a named block or task from which it was called. In particular,
>>the function itself could disable the block from which it was called,
>>in which case the function is guaranteed to be active when the disable
>>happens.
>>
>>Steven Sharp
>>sharp@cadence.com
>>
>>
>>
>
>--
>--
>David.Rich@Synopsys.com
>Technical Marketing Consultant
>http://www.SystemVerilog.org
>tele: 650-584-4026
>cell: 510-589-2625
>
>
This archive was generated by hypermail 2b28 : Mon Oct 27 2003 - 05:56:34 PST