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

Steven,

I think Stu is asking for language that's like that used for && and ||.
They are not required to be short-circuiting.  The short-circuiting is
optional only.

-- Brad 

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Wednesday, August 02, 2006 4:36 PM
To: Brad.Pierce@synopsys.COM; sv-bc@eda.org; stuart@sutherland-hdl.com
Cc: WADAMS@freescale.com; michael.burns@freescale.com
Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]


>From: "Stuart Sutherland" <stuart@sutherland-hdl.com>

>First, the wording that one of the expressions "shall not be evaluated"

>is too strong.  Not evaluating one of the expressions only works for 
>simulation.  A conditional operator is a MUX in hardware, and the 
>inputs of MUX will always be evaluated, whether they are selected or 
>not.  For the standard to work for simulation, synthesis, formal 
>analysis, etc., the wording has to be relaxed and say that a tool "may"

>choose not to evaluate the expression that was not selected.

The LRM defines the language semantics in terms of the simulation
semantics.  This is true everywhere in the LRM.  Other tools just do
their best to approximate those semantics.

If a conditional operator is synthesizable, then presumably neither of
the expressions can have any side effects from evaluation.  In that case
it becomes irrelevant whether both expressions are evaluated.  The rule
only affects the semantics in non-synthesizable cases.

So I don't see any problem with specifying it this way.

Note that the same situation applies to the && and || operators, which
are specified to be short-circuiting.


>Second, the proposal states that if the expression2 and expression3 are

>compared, the shorter of those expressions will always be left extended

>with zeros.  I would expect that if the expression is signed, it will 
>be sign extended rather than zero extended.

You are correct.  This is addressed in the erratum that Brad referred
to:

     http://www.boyd.com/1364_btf/report/full_pr/463.html


Steven Sharp
sharp@cadence.com