ISSUE 442

Edit Proposal  Edit Class, Environment, or Release
Number 442
Category enhancement
Synopsis Add auto-increment and auto-decrement statements
State proposal
Class enhancement
Arrival-DateAug 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