ISSUE 409

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 409
Category enhancement
Synopsis lists in part-selects
State open
Class enhancement
Arrival-DateJul 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