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

I was thinking about using the definition of matching types for this
purpose. It is already defined and may be OK to use. The algorithm is
then:

1. If all types match, return one of them.
2. If they don't match, and they are not integral, it is an error.
3. If they don't match, and they are integral, return the normalized
type.

Isn't this simple enough?

Regarding your comment about propagating the data type for integral
types in the existing tools, I agree that under the existing rules it is
not required. However, perhaps the main reason for that is that the
language is still underspecified and leaves the definition open to tool
implementers (as well as the definition of constructs like $left() and
$right()). It looks to me that somebody designing a tool from scratch,
thinking about support for both integral and non-integral types, would
just carry over the data type of any expression, integral or
non-integral, without distinction, both because it is simple to do (same
data structures used, simpler to understand and implement) and because
it should be efficient enough for practical purposes. The only good
reason I can think about somebody implementing support for integral
types significantly different from non-integral types (like keeping size
and signedness information in a special local data, rather than keeping
a pointer to a type descriptor object) is if support for integral types
was implemented separately from support for non-integral types (i.e.
before the non-integral types were added to the language).

--Yulik.

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Wednesday, October 24, 2007 3:37 AM
To: sharp@cadence.com; Greg.Jaxon@synopsys.com; Feldman, Yulik
Cc: sv-bc@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>

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