FW: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

-----Original Message-----
From: Will Adams [mailto:wadams@freescale.com] 
Sent: Friday, August 11, 2006 5:14 PM
To: Bresticker, Shalom
Cc: sv-bc@eda.org; michael.burns@freescale.com
Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

For the operators covered in Section 5.1 `Operators' of IEEE 1364-2005, 
I think that subsection 5.1.4 `Expression evaluation order' should be 
changed to say that, apart from cases where there is a required operand 
evaluation order (ie, `&&', `||' and `?:'), operands may be evaluated in

any order. This subsection should also strengthen the conditions for 
short-circuiting (for operators other than those for which it is 
required) to allow it only when the overall effect of the expression is 
the same (ie, the result and any side-effects are the same).

This could be handled at a higher level by stating here that all 
operands must be evaluated, unless explicitly stated otherwise, and 
elsewhere defining a global `as if' rule that allows implementors to 
change the stated execution semantics, provided the observable effect is

as if the rules had been followed. The short-circuiting condition given 
above follows from this `as if' rule.

will adams


Bresticker, Shalom wrote:
> I hate to seem like I'm just jumping on the bandwagon, but are there
> other operators where this would be desirable besides &&, ||, and ?:
?.
> 
> It would seem to be applicable in generates as well. That way, you
could
> start with a test of $isunbounded(param_name) and continue only if the
> parameter is not $.
> 
> Note that changing && and || in this way would cause them to be
> different from & and | even for 1-bit operands, which they are not
> today, contrary to popular belief.
> 
> Shalom
> 
> 
> 
>> -----Original Message-----
>> From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-
>> stds.org] On Behalf Of Warmke, Doug
>> Sent: Friday, August 11, 2006 12:24 AM
>> To: Steven Sharp; wadams@freescale.com
>> Cc: sv-bc@server.eda.org; Brad.Pierce@synopsys.com;
>> michael.burns@freescale.com
>> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
>>
>> I agree that short-circuit evaluation is highly desirable.
>> It will provide greater compatability across simulators,
>> and it will be more consistent with C's precedent.
>>
>> It sounds like there aren't really any backwards compatability
>> issues, since previously the precise behavior was undefined.
>> As someone recently told me, any rule is backwards compatible
>> with chaos.
>>
>> Doug
>>
>>> -----Original Message-----
>>> From: owner-sv-bc@server.eda-stds.org
>>> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Steven Sharp
>>> Sent: Thursday, August 10, 2006 12:00 PM
>>> To: sharp@cadence.com; wadams@freescale.com
>>> Cc: sv-bc@server.eda.org; Brad.Pierce@synopsys.com;
>>> michael.burns@freescale.com
>>> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
>>>
>>> I agree with Will Adams.  I would support adding a requirement to
> the
>>> LRM that &&, || and the conditional operator be evaluated with
> short-
>>> circuiting.  This didn't really matter much in Verilog, but becomes
> a
>>> serious issue in SystemVerilog with all the side-effects (such as
>>> run-time errors) that can occur in expression evaluation.
>>>
>>> As I wrote earlier, this should not present any problem for
> synthesis.
>>> Any expression where short-circuiting makes a difference will not be
>>> synthesizable anyway.  Synthesis tools can ignore the
>>> requirement, since
>>> they will have already disallowed any situation where it
>>> matters.  Note
>>> that if synthesis did have any problem with short-circuiting, it
> would
>>> have the same problem when the user had to rewrite their code
>>> with nested
>>> if-statements to get the same short-circuiting.
>>>
>>> The &&& is a kludge that should be eliminated in favor of
>>> making && work
>>> the way most users would expect.
>>>
>>> For reference, Verilog-XL appears to short-circuit && and ||,
>>> at least in
>>> if-statement conditions (and in the situation where it is
>>> detectable, i.e.
>>> where there is a function call in the right operand).
>>>
>>> Steven Sharp
>>> sharp@cadence.com
>>>
>>>
>