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>

>[Yulik] You're right. Defining the type of the context should be a part
>of the definition of types of expressions.

This is unnecessary if we normalize integral results of operators,
including the conditional operator.


>[Yulik] Unfortunately, you're right. This weird x-value behavior of
>conditional operators is more confusing than helping, in my eyes. It
>looks like the problem started with the introduction of 2-state types,
>which were introduced, but the semantics of conditional operators was
>not updated accordingly. I think it would be more appropriate if the
>type of the conditional would be calculated by the above simple rules,
>and any possible x-values would be converted to 0s, if the corresponding
>bit of the result is a part of 2-state type. If someone needs
>x-propagation, he should use 4-state types for all relevant expressions,
>to ensure that the type of the conditional is 4-state and the x's are
>propagated.

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.

If someone wants purely 2-state semantics, he should use 2-state types
for all relevant expressions.  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.

The current rules are also simpler than the alternative that you have
only partially defined.

Regardless of what you think of the current rules, any additional rules
about the type of an expression must be consistent with them.  Your
partially defined rule is not consistent with the existing rules, when
applied to 2-state types or enums.  So your rules would need exceptions
for those.  They already have to fall back on normalizing in the cases
where not all the types match (including the still-undefined type of the
context).

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.

Steven Sharp
sharp@cadence.com


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