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>

>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.

Exactly.  In fact, the type may not match either type, or any type in
the expression or the entire design.  You have no choice but to
normalize in that case.  So the only way to be consistent is to
always normalize.

You have expressed concern about consistency between integral types
and other types, even though it is clear where the different rules
are applied.  And yet you seem to have no concern about consistency
within integral types, even though it is less clear where the
different rules would be applied.

>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.

It is more consistent for integral types to always work the same way,
than to work like the non-integral types in some situations and not
in others.  You cannot make integral types consistent with non-integral
types by ignoring the situations where they aren't and pretending those
situations don't exist.  And the cost of trying to do so is a loss of
consistency for integral types.

You haven't even given us your definition of what it means for integral
types to be the "same".  Needing such a definition already complicates
the rules.  And if everyone does not find that definition intuitively
obvious, there is even more potential for surprises.


>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.

Any existing Verilog implementation probably processes integral
expressions by independently propagating width and signedness,
because that is what the language rules say to do.  Any attempt
to propagate an additional data type separately would be pointless
under the current language rules, whether the implementation was
designed before or after non-integral types were added.

Steven Sharp
sharp@cadence.com


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