RE: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator

The existing Verilog rules do not tell whether the types should be
normalized or not. They just tell what the size and signedness should be
(for integral types). You're still free to choose whether to use
normalized types or not, without breaking backward compatibility.

In case the types of then- and else- expressions, as well as the type of
the context are not the same, then indeed there is no choice but to pick
a type that is not matching with at least one of these types. 

But if all the types are the same, it seems to me quite natural to use
the same common type for the type of the conditional operator as well.
Both for integral types and non-integral ones.

I'm starting to have a feeling that the actual reason of why the
normalized types are seemingly preferred by at least several people here
is due to the way the existing tools are already implemented. These
tools were designed at times when integral types were the only types
existing, and perhaps their infrastructure is not well suited for
working with non-normalized types, if needed. That may be a good
argument in favor of normalized types too; there is just a need to
weight in all pros and cons.

--Yulik.

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Steven Sharp
Sent: Friday, October 19, 2007 12:40 AM
To: sharp@cadence.com; Greg.Jaxon@synopsys.com; Feldman, Yulik
Cc: sv-bc@server.eda-stds.org; gordonv@model.com
Subject: RE: [sv-bc] confusion in determining the type of an self
determined binary expression during evalution of type operator


>From: "Feldman, Yulik" <yulik.feldman@intel.com>
>
>Since all integral types are assignment compatible, it is indeed not
>much important to let the conditional operator return the original
>"common" matching type of the then- and else- expressions, when the
type
>is integral. The main reason for still doing that, in my eyes, is
>consistency of the definition with non-integral types. If the
definition
>is different for integral and non-integral types, it will be more
>complex to describe and understand it, not vice versa.

Verilog already has rules that specify most of the properties of
the result of a conditional operator applied to integral types.
Those rules may specify a result type that is not the common matching
type of the then- and else- expressions.  So if the definition for
non-integral types is specified that way, then the definition for
integral types must be different from it.

If you want consistency, it is the rules for the non-integral types
that would have to change.  I suspect that it is possible to specify
the current behavior of most non-integral types in a way that is
consistent with the existing rules for integral types.  Their behavior
would remain the same, but the rules that specified it would be
different from the current ones.  I suspect that these alternate rules
would be harder for most people to understand.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.