I believe that string literals are described as integral values that may be converted to string in a string context, not vice versa.
It doesn't make sense to have a general rule that only applies to one situation (enums), and creates problems by appearing to apply to other situations (real and shortreal). If it only applies to enums, then we should replace it with a rule for enums.
You may be right that in SV 3.1a it made more sense. The term "bit-level type" may have been more limited than "integral type".
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Thursday, September 22, 2011 3:32 PM
To: Steven Sharp; sv-bc@eda.org
Subject: RE: Mantis 1523 conditional operator with arrays
The only other case I can think of right now is maybe string literals.
However, this wording comes from SV 3.1a.
The wording in SV 3.1 is a little different, and maybe makes a little more sense:
SystemVerilog extends the conditional operator to non bit-level types and aggregate expressions using the following rules:
- If both expression2 and expression3 are bit-level types, or a packed aggregate of bit type, the operation proceeds as defined.
- If expression2 or expression3 is a bit-level type and the opposing expression can be implicitly cast to a bitlevel type, the cast is made and proceeds as defined.
Shalom
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Thursday, September 22, 2011 10:14 PM
To: Bresticker, Shalom; Rich, Dave; Arturo Salz; sv-bc@eda.org
Subject: RE: Mantis 1523 conditional operator with arrays
What are these non-integral types that can be implicitly cast to integral types that the text is talking about? Besides reals and shortreals, to which this isn't intended to apply, the only thing I can think of is enums.
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Thursday, September 22, 2011 2:39 PM
To: Rich, Dave; Arturo Salz; sv-bc@eda.org
Subject: [sv-bc] RE: Mantis 1523 conditional operator with arrays
If what you mean is 'correct according to the LRM' = 'real cast to integral',
and 'observed behavior' = 'integral cast to real',
that is what my proposal (which you requested) is intended to correct in the LRM.
That would also be consistent with 11.8.1 and the two implementations I have access to.
Or did you mean that generally, the integral type should be cast to the non-integral type, and not just where the non-integral type is a real type?
I'm confused.
Shalom
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Thursday, September 22, 2011 9:34 PM
To: Bresticker, Shalom; Arturo Salz; sv-bc@eda.org
Subject: RE: Mantis 1523 conditional operator with arrays
That's correct according to the LRM, but not the observed behavior in at least two implementations.
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Thursday, September 22, 2011 11:25 AM
To: Rich, Dave; Arturo Salz; sv-bc@eda.org
Subject: RE: Mantis 1523 conditional operator with arrays
I don't see how you can say that 'reals should be treated like any other non-integral data type'.
According to the LRM, if one expression is integral and the other is not, the non-integral type is cast to integral.
Here the reverse happens.
Shalom
From: Rich, Dave [mailto:Dave_Rich@mentor.com]<mailto:[mailto:Dave_Rich@mentor.com]>
Sent: Thursday, September 22, 2011 8:41 PM
To: Arturo Salz; Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: RE: Mantis 1523 conditional operator with arrays
IMHO, reals should be treated like any other non-integral data type. It seems most implementations treat it that way. The only two exceptions should be when both expressions are integral (packed arrays) types, we do bit-by-bit evaluation, and for unpacked arrays, we evaluate each element and treaty that element as we would any non-integral type (even if it is integral) and return the default uninitialized value if needed.
From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org]<mailto:[mailto:owner-sv-bc@eda.org]> On Behalf Of Arturo Salz
Sent: Thursday, September 22, 2011 9:31 AM
To: Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] RE: Mantis 1523 conditional operator with arrays
On remaining question is should the same casting rules apply to arrays? For example, an array of real vs an array of shortreal/integer.
Arturo
From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org]<mailto:[mailto:owner-sv-bc@eda.org]> On Behalf Of Bresticker, Shalom
Sent: Thursday, September 22, 2011 3:48 AM
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] RE: Mantis 1523 conditional operator with arrays
By the way, the text in 11.8.1 and 11.8.2 that covers real needs to be extended to shortreal also.
Shalom
From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org]<mailto:[mailto:owner-sv-bc@eda.org]> On Behalf Of Bresticker, Shalom
Sent: Thursday, September 22, 2011 1:44 PM
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] FW: Mantis 1523 conditional operator with arrays
Hi,
I realized that the changes I suggested in my previous mail do not take into consideration that SV has shortreal as well as real. So here is a revised revision:
Change the following wording in the current proposal:
"For integral expressions, if the cond_predicate evaluates to an ambiguous value and the expressions are not logically equivalent, their results shall be combined bit by bit using Table 11-20 to calculate the final result unless either the first or second expression is real, in which case the result shall be 0."
to
"When both the first and second expressions are of integral types, if the cond_predicate evaluates to an ambiguous value and the expressions are not logically equivalent, their results shall be combined bit by bit using Table 11-20 to calculate the final result."
Change the following LRM text:
"The conditional operator can be used with nonintegral types (see 6.11.1) and aggregate expressions (see 11.2.2) using the following rules:
- If both the first expression and second expression are of integral types, the operation proceeds as defined.
- If the first expression or second expression is an integral type and the opposing expression can be implicitly cast to an integral type, the cast is made and proceeds as defined."
to
"The conditional operator can be used with nonintegral types (see 6.11.1) and aggregate expressions (see 11.2.2) using the following rules:
- If both the first expression and second expression are of integral types, the operation proceeds as defined.
- If both expressions are real, then the resulting type is real. If one expression is real and the other expression is shortreal or integral, the other expression is cast to real, and the resulting type is real. If one expression is shortreal and the other expression is integral, the integral expression is cast to shortreal, and the resulting type is shortreal.
- Otherwise, if the first expression or second expression is of an integral type and the other expression can be implicitly cast to an integral type, the cast is made and proceeds as defined above for integral types."
Shalom
From: Rich, Dave [mailto:Dave_Rich@mentor.com]<mailto:[mailto:Dave_Rich@mentor.com]>
Sent: Tuesday, September 20, 2011 5:55 PM
To: Bresticker, Shalom; Steven Sharp; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: RE: Mantis 1523 conditional operator with arrays
Hi Shalom,
We discussed the fact that the behavior of real types was not accurate, nor likely to reach consensus. Further, this mantis item is addressing a different area.
I would really appreciate it if you could come up with wording that would remove your objections. Preferably, we should pass this at the champions committee and make the LRM better, and file another mantis issue to address the existing issues with reals. That is the role of the champion committee.
Dave
---------------------------------------------------------------------
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<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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. --------------------------------------------------------------------- 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<http://www.mailscanner.info/>, 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.Received on Thu Sep 22 14:32:14 2011
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2011 - 14:32:20 PDT