Gord, That is OK with me. The 'assuming' was copied from the same wording in 7.2.1 and 7.3.1. The wording is 7.4.1 is, "Although an integer type with a predefined width n is not a packed array, it matches (see 6.22), and can be selected from as if it were, a packed array type with a single [n-1:0] dimension." I don't like 'assuming' either. We could change the other uses at the same time. Brad points out that "was a packed array" should probably be "were". Thanks, Shalom > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Wednesday, November 07, 2007 6:38 PM > To: Bresticker, Shalom > Cc: sv-bc@server.eda.org > Subject: Re: [sv-bc] part selects on arbitrary expressions > > > Shalom, I think that I can accept this. > > One minor suggestion -- in the sentence: > > One or more bits of a concatenation can be selected as if > it were a packed > array, assuming an [n-1:0] numbering, except on the > left-hand side of an assignment: > > I'd prefer to see the "except" either lead the sentence or be > broken out. I'd also prefer to lose the "assuming". So how > about: > > One or more bits of a concatenation can be selected as if > the concatenation was > a packed array with the range [n-1:0]. Such a select > shall not be legal as a > net_lvalue, variable_lvalue or in any equivalent use. > > > The "equivalent use" ties in with tf calls and some "lvalue" > restictions elsewhere in the LRM. > > > Gord > > Bresticker, Shalom wrote: > > Ignore the previous mail. The attachment had an error in the BNF. > > > > Shalom > > > >> -----Original Message----- > >> From: owner-sv-bc@server.eda.org > >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom > >> Sent: Wednesday, November 07, 2007 5:53 PM > >> To: sv-bc@server.eda.org > >> Subject: RE: [sv-bc] part selects on arbitrary expressions > >> > >> Hi, > >> > >> I have attached a proposal for bit-selects on part-selects on > >> concatenations. > >> > >> Please review. > >> > >> Thanks, > >> Shalom > >> > >>> -----Original Message----- > >>> From: owner-sv-bc@server.eda.org > >>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of > Bresticker, Shalom > >>> Sent: Monday, November 05, 2007 5:20 AM > >>> To: Brad Pierce; sv-bc@server.eda.org > >>> Subject: RE: [sv-bc] part selects on arbitrary expressions > >>> > >>> I have been thinking about this for a long time. I > believe that the > >>> simplest thing to do and the way that has the best chance > of being > >>> passed within the short time that we have is to define selects on > >>> concatenations. There is no ambiguity in that case. It has some > >>> limitations, you only have vectors, but I believe it would > >> still add a > >>> lot of usefulness. > >>> > >>> Shalom > >>> > >>>> -----Original Message----- > >>>> From: owner-sv-bc@server.eda.org > >>>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce > >>>> Sent: Sunday, November 04, 2007 10:50 PM > >>>> To: sv-bc@server.eda.org > >>>> Subject: Re: [sv-bc] part selects on arbitrary expressions > >>>> > >>>> Following up to http://www.eda-stds.org/sv-bc/hm/5506.html > >>> , I, too, > >>>> would like to see this enhancement (selects of arbitrary > >>> primaries) in > >>>> SV-2008. > >>>> > >>>> In SV-2005, for any expression 'expr', one can already declare > >>>> > >>>> var type(expr) temp; > >>>> > >>>> and then write > >>>> > >>>> temp = expr; > >>>> ... temp[5] ... > >>>> > >>>> But one ought to be able to simply write > >>>> > >>>> ... (expr)[5] ... > >>>> > >>>> More generally, for any primary 'p', one ought to be > able to write > >>>> > >>>> ... p[5] ... > >>>> > >>>> Consider the defintion of static cast -- > >>>> > >>>> "If the expression is assignment compatible with the > >>> casting type, > >>>> then the cast shall return the value that a variable of > >> the casting > >>>> type would hold after being assigned the expression." > >>>> > >>>> We could come up with a similar rule that generalizes selects. > >>>> > >>>> I don't think it's a strong argument against this > >>> enhancement to say > >>>> that the type() operator is not well enough defined, as noted in > >>>> > >>>> http://www.eda-stds.org/sv-bc/hm/7082.html > >>>> > >>>> To me that is just an argument for clarifying the > >> definition of the > >>>> type() operator. > >>>> > >>>> -- Brad > >> > --------------------------------------------------------------------- > >> 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. > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > Mantis 1197 > > > > Allow bit- and part-selects from concatenations > > > > P1800-2008/D4 > > > > In Section 11.4.12 > > > > CHANGE > > > > The concatenation is treated as a packed vector of bits. It can be > > used on the left-hand side of an assignment or in an expression. > > > > * * > > > > *logic** *log1, log2, log3; > > > > {log1, log2, log3} = 3'b111; > > {log1, log2, log3} = {1'b1, 1'b1, 1'b1}; // same effect as 3'b111 > > > > TO > > > > The concatenation is treated as a packed vector of bits. It can be > > used on the left-hand side of an assignment or in an expression. > > > > * * > > > > *logic** *log1, log2, log3; > > > > {log1, log2, log3} = 3'b111; > > {log1, log2, log3} = {1'b1, 1'b1, 1'b1}; // same effect as 3'b111 > > > > > > > > One or more bits of a concatenation can be selected as if it were a > > packed array, assuming an [n-1:0] numbering, except on the > left-hand > > side of an assignment: > > > > *byte* a, b ; > > *bit* [1:0] c ; > > c = {a + b}[1:0]; // 2 lsb's of sum of a and b > > > > In 11.5.1, CHANGE > > > > *11.5.1 Vector bit-select and part-select addressing* > > > > /Bit-selects /extract a particular bit from a vector net, vector > > variable, packed array, packed structure or parameter. The > bit can be > > addressed using an expression. If the bit-select is out of > the address > > bounds or the bit-select is x or z, then the value returned by the > > reference shall be x. A bit-select or part-select of a > scalar, or of a > > real variable or real parameter, shall be illegal. > > > > > > > > Several contiguous bits in a vector net, vector variable, packed > > array, packed structure or parameter can be addressed and > are known as > > /part-selects/. > > > > ... > > > > An indexed part-select of a vector net, vector variable, > packed array, > > packed structure or parameter is given with the following syntax: > > > > ... > > > > A part-select of any type that addresses a range of bits that are > > completely out of the address bounds of the vector net, vector > > variable, packed array, packed structure parameter, 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. > > > > > > > > TO > > > > *11.5.1 Vector bit-select and part-select addressing* > > > > /Bit-selects /extract a particular bit from a vector net, vector > > variable, packed array, packed structure or parameter , > parameter, or > > concatenation. The bit can be addressed using an expression. If the > > bit-select is out of the address bounds or the bit-select > is x or z, > > then the value returned by the reference shall be x. A > bit-select or > > part-select of a scalar, or of a real variable or real parameter, > > shall be illegal. > > > > > > > > Several contiguous bits in a vector net, vector variable, packed > > array, packed structure or parameter can be addressed and > are known as > > /part-selects/. > > > > ... > > > > An /indexed part-select/ indexed part-select of a vector > net, vector > > variable, packed array, packed structure or parameter is given with > > the following syntax: > > > > ... > > > > A part-select of any type that addresses a range of bits that are > > completely out of the address bounds of the vector net, vector > > variable, 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. > > > > > > > > > > > > > > > > In A.8.4, CHANGE > > > > constant_primary ::= > > > > ... > > > > | constant_concatenation > > | constant_multiple_concatenation > > > > ... > > > > > > > > primary ::= > > > > ... > > > > | concatenation > > > > | multiple_concatenation > > > > ... > > > > > > > > TO > > > > constant_primary ::= > > > > ... > > > > | constant_concatenation [ [ constant_range_expression ] ] > > | constant_multiple_concatenation [ [ constant_range_expression ] ] > > > > ... > > > > primary ::= > > > > ... > > > > | concatenation [ [ range_expression ] ] > > > > | multiple_concatenation [ [ range_expression ] ] > > > > ... > > > > > > > > range_expression ::= > > > > expression > > > > | part_select_range > > > > > > > > > > > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > --------------------------------------------------------------------- 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 Wed Nov 7 08:45:19 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 07 2007 - 08:45:35 PST