RE: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Mon Sep 26 2011 - 05:39:03 PDT

Oops, I think I found another issue.

While looking at Mantis 1523, I saw that 11.4.11, on the conditional operator, says,

"For nonintegral and aggregate expressions, if cond_predicate evaluates to an ambiguous value, then:
- If the first expression and the second expression are of a class data type and if the conditional operation is legal, then the resulting type is determined as defined above and the result is null.
- Otherwise, both the first expression and second expression shall be evaluated, and their results shall be combined element by element. If the elements match, the element is returned. If they do not match, then the default-uninitialized value for that element's type shall be returned."

I think the last sentence there needs to be changed as in other places from "default uninitialized value" to "the value specified in Table 7-1".

Shalom

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Sunday, September 25, 2011 4:22 PM
> To: Jonathan Bromley
> Cc: sv-ec@eda.org; sv-bc@eda.org
> Subject: [sv-ec] RE: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)
>
> I finished reviewing the proposal and found only one more issue.
>
> 11.5.1 says,
>
> "Part-selects that are partially out of range shall, when read, return x for
> the bits that are out of range and shall, when written, only affect the bits
> that are in range."
>
> In Verilog, this had no relevance to unpacked arrays and Verilog did not
> have multidimensional packed arrays, either. However, SV has slices, and
> this is relevant in those cases as well. I think 7.4.6 has to say the same
> thing for slices.
>
> Other than that, I think the proposal is very nicely done.
>
> Regards,
> Shalom
>
>
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> > Bresticker, Shalom
> > Sent: Thursday, September 22, 2011 1:53 PM
> > To: Gordon Vreugdenhil; Jonathan Bromley
> > Cc: sv-ec@eda.org; sv-bc@eda.org
> > Subject: [sv-ec] RE: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)
> >
> > I like the proposal, but I did not yet verify that it deals with all the
> > issues in 1067 (excluding nets, which the proposal does not purport to
> > cover).
> >
> > However, I found a small problem with the text coloring.
> >
> > The first paragraph in 11.5.1 in the current LRM is:
> >
> > "Bit-selects extract a particular bit from a vector, packed array, packed
> > structure, parameter, or concatenation. The bit can be addressed using an
> > expression that shall be evaluated in a self-determined context. If the
> > bitselect is out of the address bounds or the bit-select is x or z, then
> the
> > value returned by the refernce shall be x. A bit-select or part-select of
> a
> > scalar, or of a real variable or real parameter, shall be illegal."
> >
> > The proposal changes the text to:
> >
> > "Bit-selects extract a particular bit from a vector, packed array, packed
> > structure, parameter, or concatenation. The bit can be addressed using an
> > expression that shall be evaluated in a self-determined context. If the
> bit-
> > select address is invalid (it is out of bounds or has one or more x or z
> > bits), then the value returned by the reference shall be x for 4-state and
> 0
> > for 2-state values. A bit-select or part-select of a scalar, or of a real
> > variable or real parameter, shall be illegal."
> >
> > The words "is invalid" also need to be blue, as they are added text.
>
> ---------------------------------------------------------------------
> 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.
>

---------------------------------------------------------------------
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 Mon Sep 26 05:39:56 2011

This archive was generated by hypermail 2.1.8 : Mon Sep 26 2011 - 05:40:00 PDT