Edit Proposal | Edit Class, Environment, or Release |
Number | 442
|
Category | enhancement
|
Synopsis | Add auto-increment and auto-decrement statements
|
State | proposal
|
Class | enhancement
|
Arrival-Date | Aug 25 2003
|
Originator | Jay Lawrence - Cadence Design Systems
|
Release | 2001b
|
Environment |
|
Description |
This enhancment request proposes the addition of the increment assignment and decrement assignment statements in Verilog. An extremely common operation in Verilog is incrementing or decrementing by 1. The following proposal allows ++ and -- as a shortcut for this operation as a statement in the language. This is done by providing an alternative syntax for the blocking_assignment. Note that this proposal does not allow the use of ++ or -- in expressions. The addition of these as expressions adds undue ambiguity to the language as demonstrated by the following example. reg [2:0] i = 0; r[i] = i++; Depending on the ordering of evaluation of the bit select i (A), the right-hand side i (B), and the increment operator (C), the following results are possible. r[0] = 0; // A, B, C or B, A, C r[1] = 0; // B, C, A The combinations A, C, B and C, A, B and C, B, A are not possible if you treat ++ as a post-increment operator as in 'C'. 'C' does allow this use and the ambiguity. The ambiguity is alleviated somewhat by the introduction of "sequence points" in the ANSI-C standard however it is not eliminated. Given the common usage in Verilog (for loop headers and while loop bodies), the additional syntax required is not worth the ambiguity. i = 0; while (i < 32) { r[i] = i; i++; } vs while (i < 32) { r[i] = i++; } |
Fix |
The following proposal modifies clause 9.2.1. Blocking Procedural Assignments REPLACE: blocking_assignment ::= variable_lvalue = [ delay_or_event_control ] expression WITH blocking_assignment ::= (From Annex A - A.6.2) variable_lvalue = [ delay_or_event_control ] expression | variable_lvalue++ | variable_lvalue-- Note: add the following paragraph A variable followed by the ++ or -- operator shall be evaluated as if expanded to the equivalent blocking assignment statement: variable = variable + 1; or variable = variable - 1; respectively. |
Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: lawrence@cadence.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/442: PROPOSAL - Add auto-increment and auto-decrement statements Date: Mon, 25 Aug 2003 15:43:13 +0300 Would that work for bit- and part-selects as well? Offhand, that would seem to be OK. Shalom > blocking_assignment ::= (From Annex A - A.6.2) > variable_lvalue = [ delay_or_event_control ] expression > | variable_lvalue++ > | variable_lvalue-- > > Note: add the following paragraph > > A variable followed by the ++ or -- operator shall be evaluated as if expanded to the equivalent blocking assignment statement: > > variable = variable + 1; > > or > variable = variable - 1; > > respectively. > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=442 -- 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" <Shalom.Bresticker@motorola.com> Cc: <etf-bugs@boyd.com> Subject: RE: enhancement/442: PROPOSAL - Add auto-increment and auto-decrement statements Date: Mon, 25 Aug 2003 08:51:02 -0400 As we've discussed w.r.t. bit and part selects previously, I believe they should be reworked as subscripts. As long as the resulting object from subscripting was an object on which the + operator was defined (a vector) then it would be fine. =================================== Jay Lawrence Senior Architect Functional Verification Cadence Design Systems, Inc. (978) 262-6294 lawrence@cadence.com =================================== > -----Original Message----- > From: Shalom Bresticker [mailto:Shalom.Bresticker@motorola.com] > Sent: Monday, August 25, 2003 8:43 AM > To: Jay Lawrence > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/442: PROPOSAL - Add auto-increment > and auto-decrement statements > > > Would that work for bit- and part-selects as well? > Offhand, that would seem to be OK. > > Shalom > > > > blocking_assignment ::= (From Annex A - A.6.2) > > variable_lvalue = [ delay_or_event_control ] expression > > | variable_lvalue++ > > | variable_lvalue-- > > > > Note: add the following paragraph > > > > A variable followed by the ++ or -- operator shall be > evaluated as if expanded to the equivalent blocking > assignment statement: > > > > variable = variable + 1; > > > > or > > variable = variable - 1; > > > > respectively. > > > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=442 > > -- > 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: Stephen Williams <steve@icarus.com> To: etf-bugs@boyd.com Cc: lawrence@cadence.com Subject: Re: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 16:47:42 -0700 lawrence@cadence.com wrote: > Precedence: bulk > > > >>Number: 442 >>Category: enhancement >>Originator: Jay Lawrence - Cadence Design Systems >>Environment: > > >>Description: > > > > This enhancment request proposes the addition of the increment assignment > and decrement assignment statements in Verilog. > > An extremely common operation in Verilog is incrementing or decrementing > by 1. The following proposal allows ++ and -- as a shortcut for this > operation as a statement in the language. This is done by providing an > alternative syntax for the blocking_assignment. > > Note that this proposal does not allow the use of ++ or -- in expressions. > > The addition of these as expressions adds undue ambiguity to the language > as demonstrated by the following example. > > reg [2:0] > > i = 0; > r[i] = i++; Rather then the ++ and -- operators, which have subtle and undesireable connotations, perhaps instead define compressed assignment operators: i = 0; while (i < 32) { r[i] = i; i += 1; } The advantage here, too, is that it is far more general. You can increment/decrement by other values, even non-constant values, and it is fairly easy to define other similar opeators a la "C": +=, -=, &=, |= ^=, *=, /=, >>=, <<=, etc. These are in fact read-modify-write statements, so should be restricted to precedural code. Syntactically, these would be the same as <=, so these would be easy to add to the BNF and *far* easier to explain then restricted ++ and -- operators. Open question: Non-blocking variants? -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." From: "Jay Lawrence" <lawrence@cadence.com> To: "Stephen Williams" <steve@icarus.com>, <etf-bugs@boyd.com> Cc: Subject: RE: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 20:14:41 -0400 Thanks for the comment/suggestions Steve. I considered all the +=, -=, ... Variations and in my own opinion decided they just weren't common enough to bother with. Especially when you consider that non-blocking versions of all of them really should be included. In the typical case of anything but +/- constant I end up writing i += (x + y); I include the () out of pure paranoia and to make it easier to read. Instead of: i = i + x + y; There is a one character difference. FYI, SystemVerilog does include all of these, but without non-blocking variations. Jay =================================== Jay Lawrence Senior Architect Functional Verification Cadence Design Systems, Inc. (978) 262-6294 lawrence@cadence.com =================================== > -----Original Message----- > From: Stephen Williams [mailto:steve@icarus.com] > Sent: Tuesday, August 26, 2003 7:48 PM > To: etf-bugs@boyd.com > Cc: Jay Lawrence > Subject: Re: enhancement/442: Add auto-increment and > auto-decrement statements > > > lawrence@cadence.com wrote: > > Precedence: bulk > > > > > > > >>Number: 442 > >>Category: enhancement > >>Originator: Jay Lawrence - Cadence Design Systems > >>Environment: > > > > > >>Description: > > > > > > > > This enhancment request proposes the addition of the > increment assignment > > and decrement assignment statements in Verilog. > > > > An extremely common operation in Verilog is incrementing or > decrementing > > by 1. The following proposal allows ++ and -- as a > shortcut for this > > operation as a statement in the language. This is done by > providing an > > alternative syntax for the blocking_assignment. > > > > Note that this proposal does not allow the use of ++ or -- > in expressions. > > > The addition of these as expressions adds undue ambiguity to the > language > > as demonstrated by the following example. > > > > reg [2:0] > > > > i = 0; > > r[i] = i++; > > Rather then the ++ and -- operators, which have subtle and > undesireable connotations, perhaps instead define compressed > assignment operators: > > i = 0; > while (i < 32) { > r[i] = i; > i += 1; > } > > The advantage here, too, is that it is far more general. You > can increment/decrement by other values, even non-constant values, > and it is fairly easy to define other similar opeators a la "C": > > +=, -=, &=, |= ^=, *=, /=, >>=, <<=, etc. > > These are in fact read-modify-write statements, so should be > restricted to precedural code. Syntactically, these would be > the same as <=, so these would be easy to add to the BNF and > *far* easier to explain then restricted ++ and -- operators. > > Open question: Non-blocking variants? > -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > > From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 17:33:27 -0700 The <<=, etc., auto-assignment operators are useful when you have an lvalue expression that is more complicated than simply "i". A potential advantage of += vs ++, besides generality, is that it could allow a delay or event control. -- Brad -----Original Message----- From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of Jay Lawrence Sent: Tuesday, August 26, 2003 5:20 PM To: etf-bugs@boyd.com Subject: RE: enhancement/442: Add auto-increment and auto-decrement statements Precedence: bulk The following reply was made to PR enhancement/442; it has been noted by GNATS. From: "Jay Lawrence" <lawrence@cadence.com> To: "Stephen Williams" <steve@icarus.com>, <etf-bugs@boyd.com> Cc: Subject: RE: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 20:14:41 -0400 Thanks for the comment/suggestions Steve. I considered all the +=, -=, ... Variations and in my own opinion decided they just weren't common enough to bother with. Especially when you consider that non-blocking versions of all of them really should be included. In the typical case of anything but +/- constant I end up writing i += (x + y); I include the () out of pure paranoia and to make it easier to read. Instead of: i = i + x + y; There is a one character difference. FYI, SystemVerilog does include all of these, but without non-blocking variations. Jay =================================== Jay Lawrence Senior Architect Functional Verification Cadence Design Systems, Inc. (978) 262-6294 lawrence@cadence.com =================================== > -----Original Message----- > From: Stephen Williams [mailto:steve@icarus.com] > Sent: Tuesday, August 26, 2003 7:48 PM > To: etf-bugs@boyd.com > Cc: Jay Lawrence > Subject: Re: enhancement/442: Add auto-increment and > auto-decrement statements > > > lawrence@cadence.com wrote: > > Precedence: bulk > > > > > > > >>Number: 442 > >>Category: enhancement > >>Originator: Jay Lawrence - Cadence Design Systems > >>Environment: > > > > > >>Description: > > > > > > > > This enhancment request proposes the addition of the > increment assignment > > and decrement assignment statements in Verilog. > > > > An extremely common operation in Verilog is incrementing or > decrementing > > by 1. The following proposal allows ++ and -- as a > shortcut for this > > operation as a statement in the language. This is done by > providing an > > alternative syntax for the blocking_assignment. > > > > Note that this proposal does not allow the use of ++ or -- > in expressions. > > > The addition of these as expressions adds undue ambiguity to the > language > > as demonstrated by the following example. > > > > reg [2:0] > > > > i = 0; > > r[i] = i++; > > Rather then the ++ and -- operators, which have subtle and > undesireable connotations, perhaps instead define compressed > assignment operators: > > i = 0; > while (i < 32) { > r[i] = i; > i += 1; > } > > The advantage here, too, is that it is far more general. You > can increment/decrement by other values, even non-constant values, > and it is fairly easy to define other similar opeators a la "C": > > +=, -=, &=, |= ^=, *=, /=, >>=, <<=, etc. > > These are in fact read-modify-write statements, so should be > restricted to precedural code. Syntactically, these would be > the same as <=, so these would be easy to add to the BNF and > *far* easier to explain then restricted ++ and -- operators. > > Open question: Non-blocking variants? > -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > > From: Stephen Williams <steve@icarus.com> To: Jay Lawrence <lawrence@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 17:53:05 -0700 Jay Lawrence wrote: > Thanks for the comment/suggestions Steve. I considered all the +=, -=, > ... Variations and in my own opinion decided they just weren't common > enough to bother with. Especially when you consider that non-blocking > versions of all of them really should be included. > > In the typical case of anything but +/- constant I end up writing > > i += (x + y); > > I include the () out of pure paranoia and to make it easier to read. > > Instead of: > > i = i + x + y; > > There is a one character difference. So write "i = i + x + y;" if you would rather. The point is that the degenerate case of "i += 1;" has most all the advantages of your "i ++;" example without the limitations or ickyness. You are rubbing a C programmer's fur the wrong way when you define a ++ statement (you've defined a statement, not an operator) is that it looks exactly like a "C" thing, and sorta goes half way. Here's another advantage: i += #5ns 1; Looks familiar? Or this more tricky example: for (i = 0 ; i < 32 ; i <<= #5 1) begin /* stuff */ end OK, maybe that's a bit too slick, but my point is that the compressed assignment statements are more naturally Verilog so the consequences are obvious, BNF changes to support it would be very minimal. I think you can see pretty clearly how these can be implemented easily in simulators and synthesizers. > FYI, SystemVerilog does include all of these, but without non-blocking > variations. SystemVerilog also includes ++/--, side effects and all. Do you really want that? SystemVerilog also defines the compressed assignments as *operators* with side effects, a very very bad idea, I think. I propose they be assignments, and *not* operators. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." From: "Jay Lawrence" <lawrence@cadence.com> To: "Stephen Williams" <steve@icarus.com>, <etf-bugs@boyd.com> Cc: Subject: RE: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 21:15:21 -0400 Don't misunderstand me Steve, I can see the utility of the compressed version of all of these as assignments (and not expressions). I simply didn't include them in this proposal because the simplest most common case is what I was aiming for. Might I suggest that you open a separate enhancment for the compressed versions? Jay =================================== Jay Lawrence Senior Architect Functional Verification Cadence Design Systems, Inc. (978) 262-6294 lawrence@cadence.com =================================== > -----Original Message----- > From: Stephen Williams [mailto:steve@icarus.com] > Sent: Tuesday, August 26, 2003 9:00 PM > To: etf-bugs@boyd.com > Subject: Re: enhancement/442: Add auto-increment and > auto-decrement statements > > > Precedence: bulk > > The following reply was made to PR enhancement/442; it has > been noted by GNATS. > > From: Stephen Williams <steve@icarus.com> > To: Jay Lawrence <lawrence@cadence.com> > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/442: Add auto-increment and > auto-decrement statements > Date: Tue, 26 Aug 2003 17:53:05 -0700 > > Jay Lawrence wrote: > > > Thanks for the comment/suggestions Steve. I considered > all the +=, -=, > > ... Variations and in my own opinion decided they just > weren't common > > enough to bother with. Especially when you consider that > non-blocking > > versions of all of them really should be included. > > > > In the typical case of anything but +/- constant I end up writing > > > > i += (x + y); > > > > I include the () out of pure paranoia and to make it > easier to read. > > > > Instead of: > > > > i = i + x + y; > > > > There is a one character difference. > > So write "i = i + x + y;" if you would rather. The point is that > the degenerate case of "i += 1;" has most all the advantages of > your "i ++;" example without the limitations or ickyness. You are > rubbing a C programmer's fur the wrong way when you define a ++ > statement (you've defined a statement, not an operator) is that > it looks exactly like a "C" thing, and sorta goes half way. > > Here's another advantage: > > i += #5ns 1; > > Looks familiar? Or this more tricky example: > > for (i = 0 ; i < 32 ; i <<= #5 1) begin > /* stuff */ > end > > OK, maybe that's a bit too slick, but my point is that the compressed > assignment statements are more naturally Verilog so the consequences > are obvious, BNF changes to support it would be very minimal. > > I think you can see pretty clearly how these can be implemented > easily in simulators and synthesizers. > > > FYI, SystemVerilog does include all of these, but without > non-blocking > > variations. > > SystemVerilog also includes ++/--, side effects and all. Do you > really want that? SystemVerilog also defines the compressed > assignments as *operators* with side effects, a very very bad > idea, I think. I propose they be assignments, and *not* operators. > > -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > > From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, steve@icarus.com Cc: Subject: Re: enhancement/442: Add auto-increment and auto-decrement statements Date: Tue, 26 Aug 2003 22:55:15 -0400 (EDT) > So write "i = i + x + y;" if you would rather. The point is that > the degenerate case of "i += 1;" has most all the advantages of > your "i ++;" example without the limitations or ickyness. It is missing one major advantage. When I write a for-loop in C, my fingers type "i++" for the increment. When I switch to Verilog, I have to stop myself and go back and type "i=i+1". It really wouldn't help me much to be able to type "i+=1", because that is still different from what my fingers naturally type. I still have to slow down and remember to use something different in Verilog. I would not be surprised if this is common for users switching between C and Verilog. A quick check of 1.3 million lines of C source that I have available indicates that "++" is about 6 times more commonly used than "+=". "--" is twice as common as "+=", and 11 times more common than "-=". The logical versions of assignment operators (&= and |=) are most commonly used in C to set and clear bits or ranges of bits. This can already be done more directly with assignments to bit-selects and part-selects in Verilog. While the other assignment operators could be added to Verilog, they just aren't as useful as increment and decrement. > You are > rubbing a C programmer's fur the wrong way when you define a ++ > statement (you've defined a statement, not an operator) is that > it looks exactly like a "C" thing, and sorta goes half way. Some C programmers may feel that "i++" is an expression with an operator, while "i+=1" is a statement. They are technically wrong. In C, "+=" is just as much an operator as "++", and "i+=1" is just as much an expression as "i++". And "i++" is just as much a statement as "i+=1" or "i=1" is. An expression is a statement in C, and an assignment is just a special case of that. Since an assignment statement in C is an expression which has the side effect of writing to a variable, it is just as valid to say that "i++" is a kind of assignment statement as to say that it is an expression. Admittedly, most C programmers haven't fully internalized the language definition, so they may still "feel" that there is some difference. And that might make them uncomfortable with this. > Here's another advantage: > > i += #5ns 1; Intra-assignment delays are rarely used on blocking assignments in Verilog. Assignment operators are rarely used in C. It is reasonable to assume that the combination would be used incredibly rarely, so there is very little advantage to supporting it. > Or this more tricky example: > > for (i = 0 ; i < 32 ; i <<= #5 1) begin I am afraid you got too tricky. Intra-assignment delays are not allowed for the assignments in for-loops. > OK, maybe that's a bit too slick, but my point is that the compressed > assignment statements are more naturally Verilog so the consequences > are obvious, BNF changes to support it would be very minimal. The consequences may be more obvious. The BNF changes for multiple new assignment syntaxes (possibly with delays) are certainly less minimal than just adding two new assignment syntaxes, "variable_lvalue++" and "variable_lvalue--". > SystemVerilog also includes ++/--, side effects and all. Do you > really want that? SystemVerilog also defines the compressed > assignments as *operators* with side effects, a very very bad > idea, I think. I propose they be assignments, and *not* operators. In other words, SystemVerilog defined them the way C does and you think that is bad. I agree. You seem to be comfortable with Verilog defining assignment differently from C, but you are not comfortable with Verilog defining increment/decrement differently from C. I think that is inconsistent. Incidentally, I tried to get assignments and increment/decrement redefined to be statements in SystemVerilog, because I agree that it is a very very bad idea to have operators with side effects in Verilog. Most of the members of the Basic Committee at that time seemed to agree. I hope we can avoid that mistake in the IEEE standard. Steven Sharp sharp@cadence.com |
Unformatted |
|
Hosted by Boyd Technology