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

 

 

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Saturday, October 27, 2007 10:03 PM
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

 

This is unnecessary if we normalize integral results of operators,

including the conditional operator.

[Yulik] You have to define the type of expressions and the type of
context, even if you are going to define them as being normalized for
integral types. There are at least two reasons for that:

 

1.    Disambiguating array querying functions (a must).

2.    Introducing select operators (nice to have).

 

The definition based on normalized types will not be simpler than the
definition based on non-normalized types, due to the existence of
expressions that must stay non-normalized for backward compatibility
reasons, such as simple identifiers, assignment operators, type
operators or contexts of assignment patterns, for example. However, a
definition based on normalized types has additional advantages that much
worth the effort on defining it (a one-time effort).

 

Note that normalized types are just original types with shape/bound
information stripped from them. If you have information on original
type, you can always compute its normalized form, if you need that form
for whatever reasons, but not vice versa. 

 

I disagree.  Simulation should be conservative, minimizing the chances

of design errors slipping through.  Mixtures of 2-state and 4-state

types should use 4-state semantics, to ensure that x-values are kept

unless explicitly discarded.

[Yulik] Read carefully my suggestion. I didn't suggest otherwise. If the
types do not match, we fall back to normalizing the types, and then
you're free to define that the resulting normalized type should be
4-state. I have just said that if the types do match, and they are all
2-state types, then we should get the "same" 2-state type in the result,
which is consistent with your suggestion.

 

With the current rule, this still ensures

that the results will be in the 2-state value set, as long as division

by zero is avoided.

[Yulik] In fact, I read the LRM differently. Table 11-22 says explicitly
that the result should be 'x, if the values of the then- and else-
expressions are not the same. It says nothing about whether the type
should be 2-state or 4-state. So, I assumed that the type must be forced
to 4-state to be able to return the 'x, independently of the kind of
types of then- and else- expressions. This is what I meant by saying
that the semantics of conditional seems weird to me.

 

I understand the desire to make the rules work more like those of other

languages you are familiar with, especially since similar rules were

borrowed for use with newly borrowed types.  But those rules just aren't

compatible with the pre-existing Verilog rules for integral types.

[Yulik] Actually, I was not thinking about other languages before, but
now I do ;) In any case, I don't think anything I suggested until now
was incompatible with existing rules. In the specific case of
conditional operators, there is some ambiguity in the language, which
can be resolved in several ways, and the difference between backward
incompatibility and errata may be quite delicate. I was just trying to
suggest a solution of how to both resolve the ambiguity and re-use the
simple "definition" of non-normalized types. Anyhow, the way the
conditional operators are defined should not have strong influence on
how the types of other kinds of expression are defined.

 

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