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

Hi, a few more points:

As pointed out below, the words "is invalid" also need to be blue, as they are also added text.

The wording in 11.4.11 (conditional operator) is changed in Mantis 1523, which we also passed, to be consistent with Mantis 1067, but is not dependent on Mantis 1067.

The remaining hole, to extend the text of 11.5.1 on part-selects, to array slices as well, should be noted in a bug note in Mantis 1067, and filed as a new Mantis.

And the other point not treated by this proposal, the value returned by a read to an invalid index of a net, should also be noted in a bug note in 1067, and again filed as a new Mantis.

Regards,
Shalom

> -----Original Message-----
> From: Maidment, Matthew R
> Sent: Monday, September 26, 2011 8:57 PM
> To: Jonathan Bromley; sv-ec@eda.org; sv-bc@eda.org; Bresticker, Shalom
> Subject: RE: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)
>
> During this morning's SV-BC meeting
>
> http://www.eda.org/sv-bc/minutes/sv-bc_11_09_26.txt
>
> the SV-BC approved Jonathan's proposal with the following friendly
> amendments:
>
> 1. Add a row to table 7-1 after class handle where the first cell
> contains "virtual interface" and the second cell contains "null"
>
> 2. All keywords in all cells of table 7-1 should be in bold and use
> courier font.
>
> Jonathan, would you please work with me to update the proposal and re-upload
> to Mantis?
>
> Thanks,
>
> Matt
> --
> Matt Maidment
> mmaidmen@ichips.intel.com
>
>
> >-----Original Message-----
> >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> >Bresticker, Shalom
> >Sent: Monday, September 26, 2011 5:39 AM
> >To: Jonathan Bromley
> >Cc: sv-ec@eda.org; sv-bc@eda.org
> >Subject: RE: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)
> >
> >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.