[sv-bc] FW: [sv-ec] Mantis 1067 proposal uploaded

Forwarding mail from Jonathan.
I suggest we postpone discussion on this issue.

Shalom

-----Original Message-----
From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
Sent: Monday, April 11, 2011 12:36 PM
To: Bresticker, Shalom; sv-ec@eda.org
Subject: Re: [sv-ec] Mantis 1067 proposal uploaded

hi Shalom

Yes.... I have done some work on this, and had hoped to have a fixed proposal
ready for today, but it hasn't quite happened. The relationship between 7.4 and
11.5 needs quite a lot of tidying-up and it has taken longer than I anticipated.

I'm currently disqualified from attending meetings under the new rules; we're
reviewing this internally within Verilab and I may to be able to rejoin the
effort before very long. Meanwhile I'll get this proposal finished and pass it
on; at present I still have access to Mantis and the SV-EC list but I imagine it
won't be long before Karen completes her purge and so I may need to ask one of
you to post it on my behalf. Already I'm off the BC list so perhaps you could
forward this message there too.

Apologies for the delay, and thanks again
Jonathan

----- Original Message ----
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> To: SV-BC <sv-bc@eda.org>
> Cc: "sv-ec@eda.org" <sv-ec@eda.org>; Jonathan Bromley
><jonathan.bromley@verilab.com>
> Sent: Mon, 11 April, 2011 9:57:45
> Subject: FW: [sv-ec] Mantis 1067 proposal uploaded
>
> Hi,
>
> I have attached the last mail sent on the subject of Mantis 1067.
>
> The modifications I think that need to be made to the current proposal are:
>
> 1. Table 7-1 should move from 7.8.6, which is specific to associative arrays,
>to 7.4.6 (Indexing and slicing of arrays), which is general.
>
>
> 2. In 7.10.1, the proposal changes "with X's or Z's" to "has one or more X or
>Z bits". The new text should be colored blue.
>
>
> 3. 11.5.1 contains, "or the bit-select is x or z". This should probably be
>changed to "or any bit of the bit-select is x or z", to be more precise and
>more consistent with other places. This paragraph, describing bit-selects,
>should also say what happens if such a bit-select is written as well as read.
>
> There is also another paragraph in 11.5.1 that needs to be modified:
>
> "A part-select that addresses a range of bits that are completely out of the
>address bounds of the vector, packed array, packed structure, parameter or
>concatenation, or a part-select that is x or z shall yield the value x when
>read and shall have no effect on the data stored when written. 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."
>
> The two pieces of text, describing the behavior when a bit-select or
>part-select index contains x/z, is out of bounds, or partially out of bounds,
>can be combined into a single text that describes both bit-selects and
>part-selects.
>
> 4. 7.9.11 says, "If a default value is specified, then reading a nonexistent
>element shall yield the specified default value, and no warning shall be
>issued. Otherwise, the default initial value as described in Table 7-1 shall be
>returned."
>
> However, Table 7-1 does not describe default initial values, certainly not
>after this proposal. So this text should be modified.
>
> Regards,
> Shalom
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>Bresticker, Shalom
> Sent: Monday, March 28, 2011 4:00 PM
> To: Jonathan Bromley
> Cc: sv-ec@eda.org; sv-bc@server.eda.org
> Subject: [sv-bc] RE: [sv-ec] Mantis 1067 proposal uploaded
>
> Hi,
>
> I agree that 7.4.6 should tell the full story, for both packed and unpacked
>arrays, and that 11.5.x can mostly reference 7.4.6, being just a special case.
>That is assuming that 11.5.1 and 11.5.2 should even survive. Also see Mantis
>2423. I think they should just be merged into 7.4.6. The terms 'bit-select' and
>'part-select' are used many times before being defined in 11.5.1. Discussing
>them earlier would reduce that problem also.
>
> The case of a part-select being partly out of bounds does need to be described
>somewhere.
>
> The current situation, where the same information is described multiple times,
>leads to inconsistencies, especially where the texts were different at
>different times.
>
> In contrast to what you wrote in rev A of the proposal, I don't think it would
>be 'unreasonably disruptive' to move Table 7-1.
>
> Regards,
> Shalom
>
>
> > -----Original Message-----
> > From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
> > Sent: Monday, March 21, 2011 11:14 PM
> > To: Bresticker, Shalom
> > Cc: sv-ec@eda.org
> > Subject: Re: [sv-ec] Mantis 1067 proposal uploaded
> >
> > Shalom
> >
> > Once again, thanks for your precise review.
> >
> > Looking more closely at clauses 11.5.1 and 11.5.2, I'm very reluctant
> > to
> > fiddle with their text any more. They simply don't take into account
> > the variety of possibilities now that we have multi-dimensional packed
> > and unpacked arrays, packed structs and unions, and 2-state types.
> > Rather than trimming the existing text I'm working on a rewrite that
> > deals with multi-dimensional arrays properly by appealing to clause 7 -
> > I think we all understand what's supposed to happen, but it's pretty
> > much impossible to divine it from 11.5 unless you know all the history.
> > The result will probably be of more interest to BC than EC.
> >
> > Currently, clause 7 cheats by referring to 11.5.1 and 11.5.2 (last few
> > words of 7.4, just before 7.5). That's the wrong way around; it's 7.4
> > that tells the full story, and 11.5.x should merely describe how that
> > applies to the denotation of operands in an expression.
> >
> > Sorry to be grumpy about this, but I'm losing patience with adding yet
> > more warts to obsolete text.
> >
> > Jonathan Bromley
> >
> >
> > On 14/03/2011 13:16, Bresticker, Shalom wrote:
> > > I like the proposal, but I have a few comments:
> > >
> > > 1. Table 7-1 should move from 7.8.6, which is specific to associative
> > arrays, to 7.4.6 (Indexing and slicing of arrays), which is general.
> > >
> > > 2. The proposal distinguishes between unpacked arrays, saying that
> > they return the value shown in Table 7-1, and bit-selects/part-selects,
> > that return x for 4-state values and 0 for 2-state values. I think the
> > wording in the proposal leaves unclarified cases of multiple packed
> > dimensions, where there is an x/z or out-of-bounds index in a packed
> > dimensions that is not the least significant dimension.
> > >
> > > 3. If Table 7-1 is going to have special entries for variable-size
> > arrays and for fixed-size arrays, then what about structs and unions?
> > Table 6-7 does not have special entries for arrays.
> > >
> > > 4. In 7.10.1, the proposal changes "with X's or Z's" to "has one or
> > more X or Z bits". The latter should be colored blue.
> > >
> > > 5. 11.5.1 contains, "or the bit-select is x or z". This should
> > probably be changed to "or any bit of the bit-select is x or z", to be
> > more precise and more consistent with other places. This paragraph,
> > describing bit-selects, should also say what happens if such a bit-
> > select is written as well as read.
> > >
> > > 6. There is also another paragraph in 11.5.1 that needs to be
> > modified:
> > >
> > > "A part-select that addresses a range of bits that are completely out
> > of the address bounds of the vector, packed array, packed structure,
> > parameter or concatenation, or a part-select that is x or z shall yield
> > the value x when read and shall have no effect on the data stored when
> > written. 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."
> > >
> > > 7. Some changes in the proposal delete the word "address", as in
> > 11.5.1. In 11.5.2, the word remains. Is that deliberate?
> > >
> > > 8. 7.9.11 says, "If a default value is specified, then reading a
> > nonexistent element shall yield the specified default value, and no
> > warning shall be issued. Otherwise, the default initial value as
> > described in Table 7-1 shall be returned."
> > >
> > > However, Table 7-1 does not describe default initial values,
> > certainly not after this proposal.
> > >
> > > Regards,
> > > Shalom
> > >
> > >> -----Original Message-----
> > >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> > >> Jonathan Bromley
> > >> Sent: Monday, March 14, 2011 2:01 AM
> > >> To: sv-ec@eda.org
> > >> Subject: [sv-ec] Mantis 1067 proposal uploaded
> > >>
> > >> hi EC,
> > >>
> > >> I've uploaded a draft proposal for 1067 (LRM consistency issues
> > >> regarding access to nonexistent array elements). There are a
> > >> couple of non-trivial issues involved and I'd be grateful if
> > >> we could take a look at it soon.
> > >>
> > >> I had intended to do this a long while ago, but vacation and
> > >> DVCon preparation got in the way. It may be better to delay
> > >> discussion to the March-28 meeting to give people time to look
> > >> at it more carefully.
> > >>
> > >> Thanks
> > >> --
> > >> Jonathan Bromley
>
> ---------------------------------------------------------------------
> 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.