| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 409
|
| Category | enhancement
|
| Synopsis | lists in part-selects
|
| State | open
|
| Class | enhancement
|
| Arrival-Date | Jul 28 2003
|
| Originator | Shalom Bresticker <Shalom.Bresticker@motorola.com>
|
| Release | 2001b
|
| Environment |
|
| Description |
like a[3:5,7,9:11,13] |
| Fix |
|
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: enhancement/409: lists in part-selects Date: Tue, 29 Jul 2003 19:39:51 -0400 (EDT) >like a[3:5,7,9:11,13] I assume you would intend this to be equivalent to {a[3:5],a[7],a[9:11],a[13]} I don't see any inherent technical problems with this, but I don't know whether this kind of thing comes up often enough to warrant adding the extra complexity to the language. Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Wed, 30 Jul 2003 11:44:08 +0300 You'd be surprised. If often comes up in contexts like "if ((a[3:5] == 3'b101) & !a[7] & (a[9:11] == 3'b110) & a[13])". Now suppose that "a" is not called "a", but is actually a 25-character-long signal name, which you do so that the name will be meaningful, indicate where the signal is originating from, and also indicate that it is active low, for example. Shalom Steven Sharp wrote: > >like a[3:5,7,9:11,13] > > I assume you would intend this to be equivalent to > > {a[3:5],a[7],a[9:11],a[13]} > > I don't see any inherent technical problems with this, but I don't know > whether this kind of thing comes up often enough to warrant adding the > extra complexity to the language. > > Steven Sharp > sharp@cadence.com -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Wed, 30 Jul 2003 20:35:27 -0400 (EDT) >You'd be surprised. > >If often comes up in contexts like > >"if ((a[3:5] == 3'b101) & !a[7] & (a[9:11] == 3'b110) & a[13])". I assume you are suggesting recoding this as if (a[3:5,7,9:11,13] == 8'b10101101) or if (a[3:5,7,9:11,13] == 8'hab) This can already be done with bit masks. Assuming a[0:15], if (a & 16'b0001110101110100 == 16'b0001010001100100) or if (a & 16'h1d74 == 16'h1464) This is similar in compactness (regardless of the length of the signal name). It should execute faster, since it uses bitwise operations that can be done in parallel, rather than extracting and reassembling bit fields sequentially. Most C programmers should already be familiar with the technique of using bit masks to extract only a desired subset of bits for testing. A bit mask can be a parameter or can be derived from multiple partial masks by operators, while a list of ranges and bits cannot. This makes it easier to parameterize the code if desired. And bit masks can be done without any language additions. Some designers may not know how to do this with the existing language features, but it is no harder than learning how to do it a new way, and it actually works better. Steven Sharp sharp@cadence.com From: Michael McNamara <mac@verisity.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Wed, 30 Jul 2003 17:13:50 -0700 Steven Sharp writes: > Precedence: bulk > > The following reply was made to PR enhancement/409; it has been noted by GNATS. > > From: Steven Sharp <sharp@cadence.com> > To: sharp@cadence.com, Shalom.Bresticker@motorola.com > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/409: lists in part-selects > Date: Wed, 30 Jul 2003 20:35:27 -0400 (EDT) > > >You'd be surprised. > > > >If often comes up in contexts like > > > >"if ((a[3:5] == 3'b101) & !a[7] & (a[9:11] == 3'b110) & a[13])". > > > I assume you are suggesting recoding this as > > if (a[3:5,7,9:11,13] == 8'b10101101) > > or > > if (a[3:5,7,9:11,13] == 8'hab) > > > This can already be done with bit masks. Assuming a[0:15], > > if (a & 16'b0001110101110100 == 16'b0001010001100100) > > or > > if (a & 16'h1d74 == 16'h1464) > > This is similar in compactness (regardless of the length of the signal > name). It should execute faster, since it uses bitwise operations > that can be done in parallel, rather than extracting and reassembling > bit fields sequentially. Most C programmers should already be familiar > with the technique of using bit masks to extract only a desired subset of > bits for testing. A bit mask can be a parameter or can be derived from > multiple partial masks by operators, while a list of ranges and bits > cannot. This makes it easier to parameterize the code if desired. > And bit masks can be done without any language additions. > > Some designers may not know how to do this with the existing language > features, but it is no harder than learning how to do it a new way, > and it actually works better. > > > > > Steven Sharp > sharp@cadence.com > I agree with Steve, but suggest he meant to type if ( (a & 16'b0001110101110100) == 16'b0001010001100100) begin as in Verilog (and C) the == operator binds tighter than the & operator, so what Steve typed would be interpreted as if it were if ( a & (16'b0001110101110100 == 16'b0001010001100100)) From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, mac@verisity.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Wed, 30 Jul 2003 21:22:26 -0400 (EDT) >I agree with Steve, but suggest he meant to type > > if ( (a & 16'b0001110101110100) == 16'b0001010001100100) begin Oops. I left out the parentheses in a misguided attempt to make my version more compact. Normally I put them in even where they aren't needed. I just hope nobody finds an error in my constant values... Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Thu, 31 Jul 2003 12:05:37 +0300 Steven Sharp wrote: > >You'd be surprised. > > > >If often comes up in contexts like > > > >"if ((a[3:5] == 3'b101) & !a[7] & (a[9:11] == 3'b110) & a[13])". > > I assume you are suggesting recoding this as > > if (a[3:5,7,9:11,13] == 8'b10101101) > > or > > if (a[3:5,7,9:11,13] == 8'hab) Actually I would probably write it as if (a[3:5,7,9:11,13] == { 3'b101, 1'b0, 3'b110, 1'b1 }). > This can already be done with bit masks. Assuming a[0:15], > > if (a & 16'b0001110101110100 == 16'b0001010001100100) > > or > > if (a & 16'h1d74 == 16'h1464) > > This is similar in compactness (regardless of the length of the signal > name). It should execute faster, since it uses bitwise operations > that can be done in parallel, rather than extracting and reassembling > bit fields sequentially. Most C programmers should already be familiar > with the technique of using bit masks to extract only a desired subset of > bits for testing. A bit mask can be a parameter or can be derived from > multiple partial masks by operators, while a list of ranges and bits > cannot. This makes it easier to parameterize the code if desired. > And bit masks can be done without any language additions. > > Some designers may not know how to do this with the existing language > features, but it is no harder than learning how to do it a new way, > and it actually works better. Yes, I could write it that way, but it is far more difficult to write and far, far less readable. (Incidentally, the compactness in your style does depend on the total vector length.) Consider how much time it will take you to figure out which bits are being masked and which are not and what the comparison values are. Then you have to go back and double-check that you did not make a mistake in counting bit-positions while you are getting cross-eyed from all those 1's and 0's. Furthermore, if it goes into a sensitivity list, I don't want the simulator to trigger on the irrelevant bits (inefficient). And I don't want a smart code-checking or formal verification tool telling me that I have redundant logic. And I don't want my code coverage tool looking at the irrelevant bits either. And how many people are going to fall on that parentheses bug, just like you did? Most importantly, I don't want to write low-level code when I can write at a higher level, just like I write RTL instead of gate level, and just like we want to add at sorts of higher level constructs into Verilog than exist now, even those which "only" make it easier to do things which we can already do today. It's certainly a much more beneficial improvement than allowing commas in sensisitivity lists as well as the word "or". The role of EDA tool vendors is to serve their customers, not the other way around. Any and all improvements to Verilog are going to require tool vendors to add more code and work harder. That is the way of the world. And finally, "the customer is always right". Shalom -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Kurt Baty <kurt@wsfdb.wsfdb.com> To: Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com, kurt@wsfdb.wsfdb.com Subject: Re: enhancement/409: lists in part-selects Date: Thu, 31 Jul 2003 11:15:14 -0500 (CDT) > Most importantly, I don't want to write low-level code when I can write at a > higher level, > just like I write RTL instead of gate level, and just like we want to add at > sorts of higher level > constructs into Verilog than exist now, even those which "only" make it easier > to do things which we can already do today. > > It's certainly a much more beneficial improvement than allowing commas in > sensisitivity lists as well as the word "or". > > The role of EDA tool vendors is to serve their customers, not the other way > around. > > Any and all improvements to Verilog are going to require tool vendors to add > more code and work harder. > That is the way of the world. > > And finally, "the customer is always right". Go Shalom Go!! ;) kurt From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Thu, 31 Jul 2003 15:35:32 -0400 (EDT) While I disagree with a number of your points, I don't want to get further into this level of detail at this point in the process. As I noted earlier, I don't see any particular implementation issues with this. If it weren't for PLI, it could be implemented just by having the compiler convert it into an equivalent concatenation. However, PLI should presumably see what the user actually wrote. As with any other construct, a full proposal would need to specify what this would look like to PLI. I would also like to point out that this is not a customer-vendor situation; this is a standardization effort. As an individual representative, I feel a responsibility to the long-term quality of the language and the interests of the entire industry, not just the short-term goal of making a sale. Steven Sharp sharp@cadence.com From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Thu, 31 Jul 2003 16:32:13 -0400 (EDT) Note that the suggested use for this would also be covered by enhancement/404, which proposes wildcards for equality compares. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT) > I would also like to point out that this is not a customer-vendor situation; > this is a standardization effort. As an individual representative, I feel > a responsibility to the long-term quality of the language and the interests > of the entire industry, not just the short-term goal of making a sale. I am also trying to consider "the interests of the entire industry" by looking at what designers actually need on a day-to-day basis. Sometimes people get so caught up in big revolutionary changes that they forget the little things which make a big difference in how good a tool really is. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Fri, 1 Aug 2003 10:37:05 +0300 (IDT) > Note that the suggested use for this would also be covered by enhancement/404, > which proposes wildcards for equality compares. I should point out that lists in part-selects would have much wider uses which 404 would not cover. For example, I might want to write a[1:3,5] = {3'b101, 1'b1} ; or (a[1:3,5] & b[3:0]) etc. Besides which, the use of the wildcards in this context has the disadvantages I previously mentioned (less readable, less compact, sensitivity list, etc.) -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: "Jay Lawrence" <lawrence@cadence.com> To: <Shalom.Bresticker@motorola.com>, <etf-bugs@boyd.com> Cc: Subject: RE: enhancement/409: lists in part-selects Date: Fri, 1 Aug 2003 08:15:38 -0400 Shalom, I think this is an interesting enhancement that makes currently expressible things more succinct and clear. As long as the user community does not confuse succinctness with performance this is OK. This enhancement is closely related to another concept we've been discussing internally here at Cadence related to bit-selects, part-selects, and data types. Bit-selects and part-selects are currently defined as operands, not as an operator. Most other languages treat subscripting as a general operator. This allows things like subscripting to participated in precendence relationships and arbitrary expressions. Once the language has things like structs you get (for some struct s) expressions like: s.x[2] Now you need to define structure references as an operand as well or define precedence of '.' and '[]'. One advantage of treating subscripting as an operator would be simplifying the LRM signficantly. Currently anywhere operands are discussed there is are special rules about bit-selects and part-selects. If we just made them operators and defined what objects they were allowed to operate on all this special purpose text goes away. It appears your enhancments request here would fit into this concept nicely. The [] operator would be defined to be able to contain a list of either integers or ranges. There are some difficult cases like: reg [10:0] r1; reg [20:10] r2; reg r; r = (r1 & r2)[3]; What is the range of the expression (r1 & r2)? Is [3] a legal subscript in this range? Either by defining such a range, or by disallowing subscripting on expressions with a self-determined width, but no defined range these could be handled. As someone who has invested a huge amount of time in clarifying the LRM, I'ld love to hear your opinion on whether this change from operand to operator would significantly simplify the LRM. Jay =================================== Jay Lawrence Senior Architect Functional Verification Cadence Design Systems, Inc. (978) 262-6294 lawrence@cadence.com =================================== > -----Original Message----- > From: Shalom.Bresticker@motorola.com > [mailto:Shalom.Bresticker@motorola.com] > Sent: Friday, August 01, 2003 3:40 AM > To: etf-bugs@boyd.com > Subject: Re: enhancement/409: lists in part-selects > > > Precedence: bulk > > The following reply was made to PR enhancement/409; it has > been noted by GNATS. > > From: Shalom.Bresticker@motorola.com > To: Steven Sharp <sharp@cadence.com> > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/409: lists in part-selects > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT) > > > I would also like to point out that this is not a > customer-vendor situation; > > this is a standardization effort. As an individual > representative, I feel > > a responsibility to the long-term quality of the language > and the interests > > of the entire industry, not just the short-term goal of > making a sale. > > I am also trying to consider "the interests of the entire > industry" by looking > at what designers actually need on a day-to-day basis. > > Sometimes people get so caught up in big revolutionary > changes that they > forget the little things which make a big difference in how good a > tool really is. > > -- > Shalom Bresticker > Shalom.Bresticker@motorola.com > Design & Reuse Methodology Tel: > +972 9 9522268 > Motorola Semiconductor Israel, Ltd. Fax: > +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: > +972 50 441478 > > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: enhancement/409: lists in part-selects Date: Sun, 03 Aug 2003 11:19:51 +0300 Also, it should be possible to list them out of order or more than once. E.g., a[5, 1:3, 5] is the same as { a[5], a[1:3], a[5] }. From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Jay Lawrence <lawrence@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Sun, 03 Aug 2003 12:19:52 +0300 Hi, Jay. That's a very interesting and elegant idea. I actually had to think about how indexing is defined in the Verilog language when I was looking at 3.9.1, bullet 2, which seems to relate to indexing as an operator, since the title of 3.9.1 is "Operators and real numbers". I don't think it was deliberate there, just not very precise wording and organization, but it got me to thinking about it. I understand what you wrote and I think it is worth further work. I am not sure it would simplify the LRM, though. You wrote that "Most other languages treat subscripting as a general operator. " Could you give a couple of references? My first mental association when I read that was the APL language, but I am not familiar with how languages like C and PERL relate to it. I like the idea of being able to write (r1 & r2)[3]. One other feature which would be occasionally useful is subscripting of constants. Thanks and regards, Shalom Jay Lawrence wrote: > Shalom, > > I think this is an interesting enhancement that makes currently > expressible things more succinct and clear. As long as the user > community does not confuse succinctness with performance this is OK. > > This enhancement is closely related to another concept we've been > discussing internally here at Cadence related to bit-selects, > part-selects, and data types. > > Bit-selects and part-selects are currently defined as operands, not as > an operator. Most other languages treat subscripting as a general > operator. This allows things like subscripting to participated in > precendence relationships and arbitrary expressions. Once the language > has things like structs you get (for some struct s) expressions like: > > s.x[2] > > Now you need to define structure references as an operand as well or > define precedence of '.' and '[]'. > > One advantage of treating subscripting as an operator would be > simplifying the LRM signficantly. Currently anywhere operands are > discussed there is are special rules about bit-selects and part-selects. > If we just made them operators and defined what objects they were > allowed to operate on all this special purpose text goes away. > > It appears your enhancments request here would fit into this concept > nicely. The [] operator would be defined to be able to contain a list of > either integers or ranges. > > There are some difficult cases like: > > reg [10:0] r1; > reg [20:10] r2; > reg r; > > r = (r1 & r2)[3]; > > What is the range of the expression (r1 & r2)? Is [3] a legal subscript > in this range? > > Either by defining such a range, or by disallowing subscripting on > expressions with a self-determined width, but no defined range these > could be handled. > > As someone who has invested a huge amount of time in clarifying the LRM, > I'ld love to hear your opinion on whether this change from operand to > operator would significantly simplify the LRM. > > Jay > > =================================== > Jay Lawrence > Senior Architect > Functional Verification > Cadence Design Systems, Inc. > (978) 262-6294 > lawrence@cadence.com > =================================== > > > -----Original Message----- > > From: Shalom.Bresticker@motorola.com > > [mailto:Shalom.Bresticker@motorola.com] > > Sent: Friday, August 01, 2003 3:40 AM > > To: etf-bugs@boyd.com > > Subject: Re: enhancement/409: lists in part-selects > > > > > > Precedence: bulk > > > > The following reply was made to PR enhancement/409; it has > > been noted by GNATS. > > > > From: Shalom.Bresticker@motorola.com > > To: Steven Sharp <sharp@cadence.com> > > Cc: etf-bugs@boyd.com > > Subject: Re: enhancement/409: lists in part-selects > > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT) > > > > > I would also like to point out that this is not a > > customer-vendor situation; > > > this is a standardization effort. As an individual > > representative, I feel > > > a responsibility to the long-term quality of the language > > and the interests > > > of the entire industry, not just the short-term goal of > > making a sale. > > > > I am also trying to consider "the interests of the entire > > industry" by looking > > at what designers actually need on a day-to-day basis. > > > > Sometimes people get so caught up in big revolutionary > > changes that they > > forget the little things which make a big difference in how good a > > tool really is. > > > > -- > > Shalom Bresticker > > Shalom.Bresticker@motorola.com > > Design & Reuse Methodology Tel: > > +972 9 9522268 > > Motorola Semiconductor Israel, Ltd. Fax: > > +972 9 9522890 > > POB 2208, Herzlia 46120, ISRAEL Cell: > > +972 50 441478 > > > > -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Michael McNamara <mac@verisity.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Mon, 4 Aug 2003 10:11:57 -0700 Shalom Bresticker writes: > Precedence: bulk > > The following reply was made to PR enhancement/409; it has been noted by GNATS. > > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > To: Jay Lawrence <lawrence@cadence.com> > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/409: lists in part-selects > Date: Sun, 03 Aug 2003 12:19:52 +0300 > > Hi, Jay. > > That's a very interesting and elegant idea. > > I actually had to think about how indexing is defined in the > Verilog language when I was looking at 3.9.1, bullet 2, which > seems to relate to indexing as an operator, since the title of > 3.9.1 is "Operators and real numbers". > > I don't think it was deliberate there, just not very precise > wording and organization, but it got me to thinking about it. > > I understand what you wrote and I think it is worth further work. > I am not sure it would simplify the LRM, though. > > You wrote that "Most other languages treat subscripting as a > general operator. " Could you give a couple of references? My > first mental association when I read that was the APL language, > but I am not familiar with how languages like C and PERL relate to > it. In Appenix A, section 7.3 of tha ANSI C standard, C defines [] as one of its postfix operators (along with exp ++, exp --, exp -> id, exp . id, and exp () ). Hence in C you can do things like: char a = "hello world"[6]; or a = m(6)[4]; // assuming m returns an array (or pointer); C++ goes further and allows you to overload the subscript operator [] by saying: class X { X operator []() { // } } Java pulled back from that degree by removing the overload facility. Perl went further than C, but no overload; allowing appling this operator to anonymous arrays and hashes: $a = (1,2,3)[2]; -mac > > I like the idea of being able to write (r1 & r2)[3]. One other > feature which would be occasionally useful is subscripting of > constants. > > Thanks and regards, > Shalom > > > Jay Lawrence wrote: > > > Shalom, > > > > I think this is an interesting enhancement that makes currently > > expressible things more succinct and clear. As long as the user > > community does not confuse succinctness with performance this is OK. > > > > This enhancement is closely related to another concept we've been > > discussing internally here at Cadence related to bit-selects, > > part-selects, and data types. > > > > Bit-selects and part-selects are currently defined as operands, not as > > an operator. Most other languages treat subscripting as a general > > operator. This allows things like subscripting to participated in > > precendence relationships and arbitrary expressions. Once the language > > has things like structs you get (for some struct s) expressions like: > > > > s.x[2] > > > > Now you need to define structure references as an operand as well or > > define precedence of '.' and '[]'. > > > > One advantage of treating subscripting as an operator would be > > simplifying the LRM signficantly. Currently anywhere operands are > > discussed there is are special rules about bit-selects and part-selects. > > If we just made them operators and defined what objects they were > > allowed to operate on all this special purpose text goes away. > > > > It appears your enhancments request here would fit into this concept > > nicely. The [] operator would be defined to be able to contain a list of > > either integers or ranges. > > > > There are some difficult cases like: > > > > reg [10:0] r1; > > reg [20:10] r2; > > reg r; > > > > r = (r1 & r2)[3]; > > > > What is the range of the expression (r1 & r2)? Is [3] a legal subscript > > in this range? > > > > Either by defining such a range, or by disallowing subscripting on > > expressions with a self-determined width, but no defined range these > > could be handled. > > > > As someone who has invested a huge amount of time in clarifying the LRM, > > I'ld love to hear your opinion on whether this change from operand to > > operator would significantly simplify the LRM. > > > > Jay > > > > =================================== > > Jay Lawrence > > Senior Architect > > Functional Verification > > Cadence Design Systems, Inc. > > (978) 262-6294 > > lawrence@cadence.com > > =================================== > > > > > -----Original Message----- > > > From: Shalom.Bresticker@motorola.com > > > [mailto:Shalom.Bresticker@motorola.com] > > > Sent: Friday, August 01, 2003 3:40 AM > > > To: etf-bugs@boyd.com > > > Subject: Re: enhancement/409: lists in part-selects > > > > > > > > > Precedence: bulk > > > > > > The following reply was made to PR enhancement/409; it has > > > been noted by GNATS. > > > > > > From: Shalom.Bresticker@motorola.com > > > To: Steven Sharp <sharp@cadence.com> > > > Cc: etf-bugs@boyd.com > > > Subject: Re: enhancement/409: lists in part-selects > > > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT) > > > > > > > I would also like to point out that this is not a > > > customer-vendor situation; > > > > this is a standardization effort. As an individual > > > representative, I feel > > > > a responsibility to the long-term quality of the language > > > and the interests > > > > of the entire industry, not just the short-term goal of > > > making a sale. > > > > > > I am also trying to consider "the interests of the entire > > > industry" by looking > > > at what designers actually need on a day-to-day basis. > > > > > > Sometimes people get so caught up in big revolutionary > > > changes that they > > > forget the little things which make a big difference in how good a > > > tool really is. > > > > > > -- > > > Shalom Bresticker > > > Shalom.Bresticker@motorola.com > > > Design & Reuse Methodology Tel: > > > +972 9 9522268 > > > Motorola Semiconductor Israel, Ltd. Fax: > > > +972 9 9522890 > > > POB 2208, Herzlia 46120, ISRAEL Cell: > > > +972 50 441478 > > > > > > > > -- > Shalom Bresticker Shalom.Bresticker@motorola.com > Design & Reuse Methodology Tel: +972 9 9522268 > Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 > > > From: Shalom.Bresticker@motorola.com To: Jay Lawrence <lawrence@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Sun, 17 Aug 2003 17:28:57 +0300 (IDT) Coincidentally, I just saw the following on comp.lang.verilog: ========================================================================= Subject: syntax question Date: Fri, 15 Aug 2003 14:37:20 -0700 From: Ron Smith <rdNOsmith@sedSPAMona.intel.com> Newsgroups: comp.lang.verilog Why does this work: wire [1:0] foo,bar; assign {foo,bar}=4'b1000; at setting foo to 2'b10 and bar to 2'b00, but this gives a syntax error: wire [1:0] foo,bar; assign {foo,bar}=4'b0000; assign {foo,bar}[3]=1'b1; but this also works: wire [3:0] foobar; assign foobar=4'b0000; assign foobar[3]=1'b1; Please note that I'm not trying to argue over the finer points of style, the above is simply a trivial and overly simplistic example of something I tried that I thought "should" work, but of course it didn't. ========================================================================= Shalom On Sun, 3 Aug 2003, Shalom Bresticker wrote: > Date: Sun, 03 Aug 2003 12:19:52 +0300 > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > To: Jay Lawrence <lawrence@cadence.com> > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/409: lists in part-selects > > Hi, Jay. > > That's a very interesting and elegant idea. > > I actually had to think about how indexing is defined in the Verilog language > when I was looking at 3.9.1, bullet 2, which seems to relate to indexing as an > operator, since the title of 3.9.1 is "Operators and real numbers". > > I don't think it was deliberate there, just not very precise wording and > organization, but it got me to thinking about it. > > I understand what you wrote and I think it is worth further work. > I am not sure it would simplify the LRM, though. > > You wrote that "Most other languages treat subscripting as a general > operator. " Could you give a couple of references? > My first mental association when I read that was the APL language, > but I am not familiar with how languages like C and PERL relate to it. > > I like the idea of being able to write (r1 & r2)[3]. > One other feature which would be occasionally useful is subscripting of > constants. > > Thanks and regards, > Shalom > > > Jay Lawrence wrote: > > > Shalom, > > > > I think this is an interesting enhancement that makes currently > > expressible things more succinct and clear. As long as the user > > community does not confuse succinctness with performance this is OK. > > > > This enhancement is closely related to another concept we've been > > discussing internally here at Cadence related to bit-selects, > > part-selects, and data types. > > > > Bit-selects and part-selects are currently defined as operands, not as > > an operator. Most other languages treat subscripting as a general > > operator. This allows things like subscripting to participated in > > precendence relationships and arbitrary expressions. Once the language > > has things like structs you get (for some struct s) expressions like: > > > > s.x[2] > > > > Now you need to define structure references as an operand as well or > > define precedence of '.' and '[]'. > > > > One advantage of treating subscripting as an operator would be > > simplifying the LRM signficantly. Currently anywhere operands are > > discussed there is are special rules about bit-selects and part-selects. > > If we just made them operators and defined what objects they were > > allowed to operate on all this special purpose text goes away. > > > > It appears your enhancments request here would fit into this concept > > nicely. The [] operator would be defined to be able to contain a list of > > either integers or ranges. > > > > There are some difficult cases like: > > > > reg [10:0] r1; > > reg [20:10] r2; > > reg r; > > > > r = (r1 & r2)[3]; > > > > What is the range of the expression (r1 & r2)? Is [3] a legal subscript > > in this range? > > > > Either by defining such a range, or by disallowing subscripting on > > expressions with a self-determined width, but no defined range these > > could be handled. > > > > As someone who has invested a huge amount of time in clarifying the LRM, > > I'ld love to hear your opinion on whether this change from operand to > > operator would significantly simplify the LRM. > > > > Jay > > > > =================================== > > Jay Lawrence > > Senior Architect > > Functional Verification > > Cadence Design Systems, Inc. > > (978) 262-6294 > > lawrence@cadence.com > > =================================== > > > > > -----Original Message----- > > > From: Shalom.Bresticker@motorola.com > > > [mailto:Shalom.Bresticker@motorola.com] > > > Sent: Friday, August 01, 2003 3:40 AM > > > To: etf-bugs@boyd.com > > > Subject: Re: enhancement/409: lists in part-selects > > > > > > > > > Precedence: bulk > > > > > > The following reply was made to PR enhancement/409; it has > > > been noted by GNATS. > > > > > > From: Shalom.Bresticker@motorola.com > > > To: Steven Sharp <sharp@cadence.com> > > > Cc: etf-bugs@boyd.com > > > Subject: Re: enhancement/409: lists in part-selects > > > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT) > > > > > > > I would also like to point out that this is not a > > > customer-vendor situation; > > > > this is a standardization effort. As an individual > > > representative, I feel > > > > a responsibility to the long-term quality of the language > > > and the interests > > > > of the entire industry, not just the short-term goal of > > > making a sale. > > > > > > I am also trying to consider "the interests of the entire > > > industry" by looking > > > at what designers actually need on a day-to-day basis. > > > > > > Sometimes people get so caught up in big revolutionary > > > changes that they > > > forget the little things which make a big difference in how good a > > > tool really is. > > > > > > -- > > > Shalom Bresticker > > > Shalom.Bresticker@motorola.com > > > Design & Reuse Methodology Tel: > > > +972 9 9522268 > > > Motorola Semiconductor Israel, Ltd. Fax: > > > +972 9 9522890 > > > POB 2208, Herzlia 46120, ISRAEL Cell: > > > +972 50 441478 > > > > > > > > -- > Shalom Bresticker Shalom.Bresticker@motorola.com > Design & Reuse Methodology Tel: +972 9 9522268 > Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 > > -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Michael McNamara <mac@verisity.com> To: Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/409: lists in part-selects Date: Wed, 20 Aug 2003 11:38:55 -0700 Shalom.Bresticker@motorola.com writes: > Precedence: bulk > > Why does this work: > > wire [1:0] foo,bar; > > assign {foo,bar}=4'b1000; > > at setting foo to 2'b10 and bar to 2'b00, but this gives a syntax error: > > wire [1:0] foo,bar; > > assign {foo,bar}=4'b0000; > assign {foo,bar}[3]=1'b1; > > but this also works: > > wire [3:0] foobar; > > assign foobar=4'b0000; > assign foobar[3]=1'b1; > > Please note that I'm not trying to argue over the finer points of style, > the above is simply a trivial and overly simplistic example of something > I tried that I thought "should" work, but of course it didn't. > > ========================================================================= > > Shalom In a language like perl assign {foo.bar}[3] = 1'b1; would work; and I believe it is a useful RFE for 1364 verilog. Again, one would discourage folks from typing the above directly; but it may be very useful to do: `define CPU_REG {mode,exception_mask,interrupt_mask,cpu_id} ... if ( `CPU_REG[5:0] == 6'b0 ) begin // we are the boot cpu; load the OS ... end which would expand to the same thing. -mac |
| Unformatted |
|
Hosted by Boyd Technology