ISSUE 483

Number 483
Category errata
Synopsis 4.2: Bit/part-selects of parameters
State lrmdraft
Class errata-discuss
Arrival-DateSep 18 2003
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001b: 4.2
Environment
Description
Sections 4.2 and 4.2.1 should mention that it is possible to take
the bit- and part-select of parameters that are not declared
real or realtime.

And in constant_primary the parameter_identifier production should
be changed to something like --

| parameter_identifier
[ {"[" constant_expression "]" }
"[" constant_range_expression "]"
]

Also, is it true that any constant_primary is also a primary?
This is not obvious from the BNF.

-- Brad


Fix
2004-11-15: In this final version of the proposal, I:
- deleted part 2, which related to the scalared and vectored keywords,
due to controversy;
- in part 7, added "strings" after "constant numbers"
- in part 8, added "(not real)" in array element selects
- in part 15 (BNF), changed curly brackets to square brackets


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. Deleted from proposal


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


5A. In 3.11.2 ("Local parameters - localparam"), ADD a new
paragraph after the first paragraph as follows:

"Bit-selects and part-selects of local parameters which are
not of type real shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real) or string
-- Parameter (including local and specify parameters)
-- Parameter (not real) bit-select or part-select (including local and specify parameters)
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element (not real) bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier [ [ constant_range_expression ] ]
| specparam_identifier [ [ constant_range_expression ] ]

Audit-Trail
From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/483: 4.2: Bit/part-selects of parameters
Date: Fri, 19 Sep 2003 12:32:05 +0300 (IDT)

> Sections 4.2 and 4.2.1 should mention that it is possible to take
> the bit- and part-select of parameters that are not declared
> real or realtime.

This is sort of a side-question, but what is the type of a parameter
without a type specification? The LRM does not say explicitly (3.11.1).
I think it should say that it is implicitly declared as a "reg" type,
like functions.

Also, the last two rules (5 and 6 of 6) in 3.11.1 are confusing.

Rule 5 says,

"A parameter with no range specification, and with either a signed type
specification or no type specification, shall have ..."

and Rule 6 says,

"A parameter with no range specification, and with either a signed type
specification or no type specification, and for which the final value
assigned to it is unsized, shall have ..."

I think Rule 5 should specify also that it is for the case where the
parameter is assigned a sized value.

Also, the original issue was that in Clause 4, the definition of
"operand" should include parameters and their bit/part-selects
(and also bit/part-selects of array elements), or rewrite that paragraph
entirely.


> And in constant_primary the parameter_identifier production should
> be changed to something like --
>
> | parameter_identifier
> [ {"[" constant_expression "]" }
> "[" constant_range_expression "]"
> ]

Why

> [ {"[" constant_expression "]" } ?

There are no arrays of parameters
(although maybe there should be).

I think

| parameter_identifier [ "[" constant_range_expression "]" ]

is sufficient.

I guess the same should apply to specparam_identifiers as well.


> Also, is it true that any constant_primary is also a primary?
> This is not obvious from the BNF.

It better be.
And as far as I can tell, it is.

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: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/483: 4.2: Bit/part-selects of parameters
Date: Mon, 22 Sep 2003 18:29:54 -0400 (EDT)

> This is sort of a side-question, but what is the type of a parameter
> without a type specification? The LRM does not say explicitly (3.11.1).
> I think it should say that it is implicitly declared as a "reg" type,
> like functions.

I'm not sure what you mean here. "reg" isn't really a data type.
A variable declared with the keyword "reg" has a datatype of a scalar or
vector of 4-state bits. But that is not specific to regs, since there are
nets and parameters of that type. A parameter without a type specification
takes on the type of the value it is set to, which is either real or vector
(which can be signed or unsigned).

The other aspect of a reg, besides its data type, is that it is a variable.
A parameter is not a variable, and does not have the same read/write
semantics as a variable. Perhaps you meant that it is not a net, which is
true. It is a parameter, which has semantics distinct from variables and
nets. Unlike nets, it does not have strength or delay or drivers. Unlike
variables, it cannot be written to in procedural code.

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: errata/483: 4.2: Bit/part-selects of parameters
Date: Thu, 25 Sep 2003 11:46:21 +0300

From the point of view of the LRM, "reg" most certainly is a "data type",
as stated explicitly in 3.2.2 and elsewhere.

You are correct that if neither type nor range is specified, then the
parameter gets the type and range of the value assigned to it.
So I agree that it is more complicated than I initially thought.

As far as a "reg" being a variable, whereas parameters are constants,
that is not a difficulty, because the same applies to declaring a parameter
with type integer, real, realtime, or time. Obviously, its variability
is not being referred to here.

Also, I again refer you to the parallel case of function type in 10.3.1

> > This is sort of a side-question, but what is the type of a parameter
> > without a type specification? The LRM does not say explicitly (3.11.1).
> > I think it should say that it is implicitly declared as a "reg" type,
> > like functions.
>
> I'm not sure what you mean here. "reg" isn't really a data type.
> A variable declared with the keyword "reg" has a datatype of a scalar or
> vector of 4-state bits. But that is not specific to regs, since there are
> nets and parameters of that type. A parameter without a type specification
> takes on the type of the value it is set to, which is either real or vector
> (which can be signed or unsigned).
>
> The other aspect of a reg, besides its data type, is that it is a variable.
> A parameter is not a variable, and does not have the same read/write
> semantics as a variable. Perhaps you meant that it is not a net, which is
> true. It is a parameter, which has semantics distinct from variables and
> nets. Unlike nets, it does not have strength or delay or drivers. Unlike
> variables, it cannot be written to in procedural code.

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: Steven Sharp <sharp@cadence.com>
To: sharp@cadence.com, Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/483: 4.2: Bit/part-selects of parameters
Date: Fri, 26 Sep 2003 13:33:21 -0400 (EDT)

Yes, you are correct that the LRM uses the term "data type" to refer to
the distinction between variables and nets (and then in 3.11, parameters
are stated to be distinct from either). It fails to properly distinguish
between how objects "are assigned and hold values" (3.2), and what is
traditionally called a data type in any other language, which is the set of
values an object can hold. The closest it gets to this is the "value set"
described in 3.1, which completely leaves out the fact that there is an
alternative value set called reals. The proposed Extended Data Types
enhancement distinguishes these two aspects of an object, and makes them
orthogonal (something that already started with parameters being declared
as integer, real, realtime, time or a vector of the "Verilog HDL value set"
from 3.1).

I will try to use the current LRM terminology in the rest of this. A
parameter is never of the reg data type. A reg is one of the variable
data types (3.2 and 3.2.2). A parameter does not belong to either the
variable or net group (see 3.11). Therefore a parameter is inherently
never of a reg data type. It can hold the same "Verilog HDL value set"
as a reg, but that does not make it a reg. As stated in 3.1, "almost all
of the data types in the Verilog HDL store all four basic values."

The statement in 10.3.1 that a function "defaults to a one bit reg for
the return value", is more mixed up and sloppy terminology. A function
is not a reg, it is a function, which is a different class of object.
This sloppy terminology is probably used because there is no proper
terminology in the LRM for what would be called a "data type" in another
language. What is meant is "one bit of the Verilog HDL value set described
in 3.1", but that is rather clumsy. The confusion here is worsened by the
fact that there _is_ a variable implicitly declared inside the function, with
the same name as the function (10.3.2).

At any rate, this same kind of defaulting does not apply to a parameter
anyway. A parameter with no explicit type does not default to "one bit of
the Verilog HDL value set described in 3.1". It defaults to the type of
the expression that it gets set to, which is either a real, or a signed or
unsigned vector of bits of "the Verilog HDL value set described in 3.1".

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/483: 4.2: Bit/part-selects of parameters
Date: Thu, 19 Aug 2004 14:41:42 +0300 (IDT)

On Thu, 18 Sep 2003, Brad Pierce wrote:

> Sections 4.2 and 4.2.1 should mention that it is possible to take
> the bit- and part-select of parameters that are not declared
> real or realtime.

Or overridden with type real/realtime.
Or an unsized, unranged parameter assigned a value of type real/realtime.
In short, a parameter which is not of type real/realtime.

Presumably, reading an out-of-bounds bit of a parameter will also
return x.

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/483: PROPOSAL: 4.2: Bit/part-selects of parameters
Date: Sat, 6 Nov 2004 23:36:45 +0200 (IST)

The following was the original issue:

> Sections 4.2 and 4.2.1 should mention that it is possible to take
> the bit- and part-select of parameters that are not declared
> real or realtime.
>
> And in constant_primary the parameter_identifier production should
> be changed to something like --
>
> | parameter_identifier
> [ {"[" constant_expression "]" }
> "[" constant_range_expression "]"
> ]
>
> Also, is it true that any constant_primary is also a primary?
> This is not obvious from the BNF.

During the ensuing discussion, there was also a tangential discussion of
the 'type' of a parameter.

I think this issue should be split into 2 separate ones.

The following is a proposal to deal with the original issue.
At the same time, it also makes a few more semi-related changes.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. In section 3.3.2 ("Vector net accessibility"),

CHANGE the last sentence from

"If the keyword scalared is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."

TO

"If the keyword scalared is used or if neither scalared nor
vectored is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."


Also ADD to the Examples the following:

reg [31:0] bus32 ; // a bus that will be expanded


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real)
-- Parameter
-- Parameter (not real) bit-select or part-select
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element bit-select or part-select
-- A call to a ... function ..."


9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."


11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold.


15. In A.8.4, and wherever else the constant_primary production appears
CHANGE

| parameter_identifier

TO

| parameter_identifier { [ constant_range_expression ] }


Wow! I made it!


--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478


Fix replaced by Shalom.Bresticker@freescale.com on Sun Nov 7 02:59:40 2004

0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. In section 3.3.2 ("Vector net accessibility"),

CHANGE the last sentence from

"If the keyword scalared is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."

TO

"If the keyword scalared is used or if neither scalared nor
vectored is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."


Also ADD to the Examples the following:

reg [31:0] bus32 ; // a bus that will be expanded


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real)
-- Parameter
-- Parameter (not real) bit-select or part-select
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier

TO

| parameter_identifier { [ constant_range_expression ] }




Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 8 02:25:55 2004
2004-11-08: I added to the proposal an additional change in
the BNF of constant_primary to support bit- and part-selects
of specify parameters. Shalom


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. In section 3.3.2 ("Vector net accessibility"),

CHANGE the last sentence from

"If the keyword scalared is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."

TO

"If the keyword scalared is used or if neither scalared nor
vectored is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."


Also ADD to the Examples the following:

reg [31:0] bus32 ; // a bus that will be expanded


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real)
-- Parameter
-- Parameter (not real) bit-select or part-select
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier { [ constant_range_expression ] }
| specparam_identifier { [ constant_range_expression ] }



From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
To: <Shalom.Bresticker@freescale.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 08:58:54 -0800

I have two questions:

First is a general question. Many of the proposed changes involving adding
bit- and part-selects of parameters. Why were specparam and localparam
constants excluded from these changes?

Second is a question that I'd like to hear the thoughts of other 1364 WG
members about. The change is to make the informative note that the size of
an integer type shall be "at least 32 bits" into normative text. Rather
than make this ambiguous size normative, perhaps this is the time to remove
the ambiguity and simply state that an integer type SHALL BE 32 bits wide.
I am well aware of why we made this ambiguous to begin with, which was to
copy the behavior of C and to possibly allow software tools to optimize
integer types for different operating systems. However, Verilog is a
hardware modeling language, whereas C is a programming language. Hardware
vector widths do not arbitrarily change sizes because the operating system
changed. Further, I do not think it would be desirable for the results of
synthesizing a Verilog model to result in very different designs simply
because I re-synthesized on a different platform. Since Verilog is modeling
hardware, the integer type should have a fixed, and consistent size, like
hardware. One could argue that the integer type should only be used in
testbenches and other software-like contexts, but there is nothing in the
language that prevents using integer types in synthesizable hardware models,
and I suspect there are many existing hardware models that use integer
types. In fact, even testbench constructs in Verilog, such as $fopen,
expect an integer type to be 32 bits. Also worth considering is what do
synthesis compilers do with the integer type? The 1364.1 standard says the
integer type is synthesizable, but does not specify a size. However, in
Section 7.10.3 of 1364.1, it specifically states "A port of an integer type
shall be treated as a 32 bit signed type,".

In short, my second question is: Can we make the size of the integer type a
fixed 32 bits, instead of changing the informative note that it "at least 32
bits" into normative text?

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898


> -----Original Message-----
> From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On
> Behalf Of Shalom.Bresticker@freescale.com
> Sent: Sunday, November 07, 2004 3:00 AM
> To: etf-bugs@boyd.com
> Subject: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
>
>
> 0. Add references to 487 and 489 to see further discussion in 483.
>
>
> 1. Section 3.3.1 ("Specifying vectors") ends as follows:
>
> "NOTES:
>
> 1) Implementations may set a limit on the maximum length of a
> vector, but they will at least be 65536 (2**16) bits.
>
> 2) Implementations do not have to detect overflow of integer
> operations."
>
> Since NOTES are not normative, CHANGE these to:
>
> "Implementations may set a limit on the maximum length of a
> vector, but the limit shall be at least 65536 (2**16) bits.
>
> Implementations are not required to detect overflow of
> integer operations."
>
>
> 2. In section 3.3.2 ("Vector net accessibility"),
>
> CHANGE the last sentence from
>
> "If the keyword scalared is used, bit-selects and
> part-selects of the object shall be permitted, and the PLI
> shall consider the object expanded."
>
> TO
>
> "If the keyword scalared is used or if neither
> scalared nor vectored is used, bit-selects and
> part-selects of the object shall be permitted, and the PLI
> shall consider the object expanded."
>
>
> Also ADD to the Examples the following:
>
> reg [31:0] bus32 ; // a bus that will be expanded
>
>
> 3. Section 3.6 is "Net initialization". The corresponding
> text for variables is in 3.2.2 ("Variable declarations").
>
> The proposal is to delete this sub-section and move its text
> to be a new paragraph at the end of 3.2.1 ("Net declarations").
>
>
> 4. In 3.9 ("Integers, reals, times, and realtimes"), ADD a
> new paragraph after the paragraph beginning "The time variables...".
>
> The new paragraph is:
>
> "Bit-selects and part-selects of vector regs, integer
> variables, and time variables shall be allowed (See 4.2)."
>
>
> CHANGE
>
> "NOTE--Implementations may limit the maximum size of an
> integer variable, but they shall at least be 32 bits."
>
> TO
>
> "Implementations may limit the maximum size of integer
> variables, but it shall be at least 32 bits."
>
>
> 5. In 3.11.1 ("Module parameters"), ADD a new paragraph at
> the end, but before the Examples. The new paragraph is:
>
> "Bit-selects and part-selects of parameters which are not of
> type real shall be allowed (See 4.2)."
>
>
> 6. In 3.11.3 ("Specify parameters"), ADD a new paragraph
> before the first "Examples:". The new paragraph is:
>
> "Bit-selects and part-selects of specify parameters which are
> not of type real shall be allowed (See 4.2)."
>
>
> 7. In the introduction to Section 4, paragraph 3 contains,
>
> "The operands of a constant expression consist of constant numbers,
> parameter names, constant bit-selects of parameters, constant
> part-selects
> of parameters, and constant function calls (see 10.3.5) only, ..."
>
> CHANGE this to:
>
> "The operands of a constant expression consist of constant numbers,
> parameters, constant bit-selects and part-selects of parameters,
> and constant function calls (see 10.3.5) only, ..."
>
>
> 8. Paragraph 5 says,
>
> "An operand can be one of the following:
>
> -- Constant number (including real)
> -- Net
> -- Variables of type reg, integer, time, real, and realtime
> -- Net bit-select
> -- Bit-select of type reg, integer, and time
> -- Net part-select
> -- Part-select of type reg, integer, and time
> -- Array element
> -- A call to a ... function ..."
>
> CHANGE this to:
>
> "An operand can be one of the following:
>
> -- Constant number (including real)
> -- Parameter
> -- Parameter (not real) bit-select or part-select
> -- Net
> -- Net bit-select or part-select
> -- reg, integer, or time variable
> -- reg, integer, or time variable
> bit-select or part-select
> -- real or realtime variable
> -- Array element
> -- Array element bit-select or part-select
> -- A call to a ... function ..."
>
>
>
>
> 9. In Table 4-1, add a new row after the first row:
>
> -------------------------------------
> | unary + unary - | Unary operators |
> -------------------------------------
>
>
> 10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:
>
> "There are several types of operands that can be specified in
> expressions.
> The simplest type is a reference to a net or a variable in
> its complete form --
> that is, just the name of the net or variable is given. In
> this case, all
> of the bits making up the net or variable value shall be used
> as the operand.
>
> If a single bit of a vector net, reg variable, integer
> variable, or time
> variable is required, then a bit-select operand shall be
> used. A part-select
> operand shall be used to reference a group of adjacent bits
> in a vector net,
> vector reg, integer variable, or time variable.
>
> A memory word can be referenced as an operand. A
> concatenation of other
> operands (including nested concatenations) can be specified
> as an operand.
> A function call is an operand."
>
> TO
>
> "There are several types of operands that can be specified in
> expressions.
> The simplest type is a reference to a net, variable or
> parameter in its complete
> form -- that is, just the name of the net, variable or
> parameter is given.
> In this case, all of the bits making up the net, variable or
> parameter value
> shall be used as the operand.
>
> If a single bit of a vector net or reg, integer or time
> variable, or parameter
> is required, then a bit-select operand shall be used. A part-select
> operand shall be used to reference a group of adjacent bits
> in a vector net
> or reg, integer or time variable, or parameter.
>
> An array element or a bit-select or part-select of an array
> element can be
> referenced as an operand. A concatenation of other
> operands (including nested concatenations) can be specified
> as an operand.
> A function call is an operand."
> 11. In 4.2.1 ("Vector bit-select and part-select addressing")
> CHANGE the beginning from:
>
> "Bit-selects extract a particular bit from a vector net, vector reg,
> integer variable, or time variable. The bit can be addressed using an
> expression. If the bit-select is out of the address bounds or
> the bit-select
> is x or z, then the value returned by the reference shall be
> x. A bit-select
> or part-select of a scalar, or of a variable declared as real
> or realtime,
> shall be illegal.
>
> Several contiguous bits in a vector net, vector reg, integer variable,
> or time variable can be addressed and are known as part-selects."
>
> TO:
>
> "Bit-selects extract a particular bit from a vector net or reg,
> integer or time variable, or parameter. The bit can be
> addressed using an
> expression. If the bit-select is out of the address bounds or
> the bit-select
> is x or z, then the value returned by the reference shall be
> x. A bit-select
> or part-select of a scalar, or of a variable or parameter of
> type real or
> realtime, shall be illegal.
>
> Several contiguous bits in a vector net or reg, integer or
> time variable,
> or parameter can be addressed and are known as part-selects."
>
>
> 12. In paragraph 4, CHANGE
>
> "An indexed part-select of a vector net, vector reg, integer
> variable, or time
> variable is given with the following syntax"
>
> TO:
>
> "An indexed part-select of a vector net or reg, integer or
> time variable,
> or parameter is given with the following syntax"
>
>
> 13. In paragraph 6, CHANGE
>
> "Part-selects of any type that address a range of bits that
> are completely
> out of the address bounds of the net, reg, integer, or time, ..."
>
> TO:
>
> "Part-selects of any type that address a range of bits that
> are completely
> out of the address bounds of the net, reg, integer, time or
> parameter ..."
>
>
> 14. Note: In all these places, "reg", "integer", "time" and
> "parameter"
> should be bold. "net" should not be bold.
>
>
> 15. In Syntax 4-2 and A.8.4, in the constant_primary production,
> CHANGE
>
> | parameter_identifier
>
> TO
>
> | parameter_identifier { [
> constant_range_expression ] }
>
>
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&datab
> ase=default&pr=483
>
>
>


From: "Francoise Martinolle" <fm@cadence.com>
To: "'Stuart Sutherland'" <stuart@sutherland-hdl.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 15:01:31 -0500

Stuart,

Regarding your second remark, there is a related erratum in SV-BC:#51 which
I have been assigned for resolution. There has been some discussion around
it in the bc reflector.
The issue I see is that by doing the change you suggest, we may make some
existing implementations incompatible with the new standard. However the
advantage is that
we are making it consistent with all the other 2 state data types which
have a fixed size.
In that discussion thread on the bc commitee, it was also said that they
don't use integer for synthesis but rather specify the size using a range.
This seems contradictory
with what you say below.

Francoise
'


-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Stuart
Sutherland
Sent: Monday, November 08, 2004 11:50 AM
To: etf-bugs@boyd.com
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters

The following reply was made to PR errata/483; it has been noted by GNATS.

From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
To: <Shalom.Bresticker@freescale.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 08:58:54 -0800

I have two questions:

First is a general question. Many of the proposed changes involving adding
bit- and part-selects of parameters. Why were specparam and localparam
constants excluded from these changes?

Second is a question that I'd like to hear the thoughts of other 1364 WG
members about. The change is to make the informative note that the size of
an integer type shall be "at least 32 bits" into normative text. Rather
than make this ambiguous size normative, perhaps this is the time to remove
the ambiguity and simply state that an integer type SHALL BE 32 bits wide.
I am well aware of why we made this ambiguous to begin with, which was to
copy the behavior of C and to possibly allow software tools to optimize
integer types for different operating systems. However, Verilog is a
hardware modeling language, whereas C is a programming language. Hardware
vector widths do not arbitrarily change sizes because the operating system
changed. Further, I do not think it would be desirable for the results of
synthesizing a Verilog model to result in very different designs simply
because I re-synthesized on a different platform. Since Verilog is modeling
hardware, the integer type should have a fixed, and consistent size, like
hardware. One could argue that the integer type should only be used in
testbenches and other software-like contexts, but there is nothing in the
language that prevents using integer types in synthesizable hardware models,
and I suspect there are many existing hardware models that use integer
types. In fact, even testbench constructs in Verilog, such as $fopen,
expect an integer type to be 32 bits. Also worth considering is what do
synthesis compilers do with the integer type? The 1364.1 standard says the
integer type is synthesizable, but does not specify a size. However, in
Section 7.10.3 of 1364.1, it specifically states "A port of an integer type
shall be treated as a 32 bit signed type,".

In short, my second question is: Can we make the size of the integer type a
fixed 32 bits, instead of changing the informative note that it "at least 32
bits" into normative text?

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898


> -----Original Message-----
> From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On > Behalf Of
Shalom.Bresticker@freescale.com > Sent: Sunday, November 07, 2004 3:00 AM
> To: etf-bugs@boyd.com > Subject: errata/483: PROPOSAL - 4.2:
Bit/part-selects of parameters > > > 0. Add references to 487 and 489 to
see further discussion in 483.
>
>
> 1. Section 3.3.1 ("Specifying vectors") ends as follows:
>
> "NOTES:
>
> 1) Implementations may set a limit on the maximum length of a > vector,
but they will at least be 65536 (2**16) bits.
>
> 2) Implementations do not have to detect overflow of integer >
operations."
>
> Since NOTES are not normative, CHANGE these to:
>
> "Implementations may set a limit on the maximum length of a > vector,
but the limit shall be at least 65536 (2**16) bits.
>
> Implementations are not required to detect overflow of > integer
operations."
>
>
> 2. In section 3.3.2 ("Vector net accessibility"), > > CHANGE the last
sentence from > > "If the keyword scalared is used, bit-selects and
> part-selects of the object shall be permitted, and the PLI > shall
consider the object expanded."
>
> TO
>
> "If the keyword scalared is used or if neither > scalared
nor vectored is used, bit-selects and > part-selects of the object
shall be permitted, and the PLI > shall consider the object
expanded."
>
>
> Also ADD to the Examples the following:
>
> reg [31:0] bus32 ; // a bus that will be expanded > > > 3. Section 3.6
is "Net initialization". The corresponding > text for variables is in 3.2.2
("Variable declarations").
>
> The proposal is to delete this sub-section and move its text > to be a
new paragraph at the end of 3.2.1 ("Net declarations").
>
>
> 4. In 3.9 ("Integers, reals, times, and realtimes"), ADD a > new
paragraph after the paragraph beginning "The time variables...".
>
> The new paragraph is:
>
> "Bit-selects and part-selects of vector regs, integer > variables, and
time variables shall be allowed (See 4.2)."
>
>
> CHANGE
>
> "NOTE--Implementations may limit the maximum size of an > integer
variable, but they shall at least be 32 bits."
>
> TO
>
> "Implementations may limit the maximum size of integer > variables, but
it shall be at least 32 bits."
>
>
> 5. In 3.11.1 ("Module parameters"), ADD a new paragraph at > the end,
but before the Examples. The new paragraph is:
>
> "Bit-selects and part-selects of parameters which are not of > type
real shall be allowed (See 4.2)."
>
>
> 6. In 3.11.3 ("Specify parameters"), ADD a new paragraph > before the
first "Examples:". The new paragraph is:
>
> "Bit-selects and part-selects of specify parameters which are > not of
type real shall be allowed (See 4.2)."
>
>
> 7. In the introduction to Section 4, paragraph 3 contains, > > "The
operands of a constant expression consist of constant numbers, > parameter
names, constant bit-selects of parameters, constant > part-selects > of
parameters, and constant function calls (see 10.3.5) only, ..."
>
> CHANGE this to:
>
> "The operands of a constant expression consist of constant numbers, >
parameters, constant bit-selects and part-selects of parameters, > and
constant function calls (see 10.3.5) only, ..."
>
>
> 8. Paragraph 5 says,
>
> "An operand can be one of the following:
>
> -- Constant number (including real)
> -- Net
> -- Variables of type reg, integer, time, real, and realtime > -- Net
bit-select > -- Bit-select of type reg, integer, and time > -- Net
part-select > -- Part-select of type reg, integer, and time > -- Array
element > -- A call to a ... function ..."
>
> CHANGE this to:
>
> "An operand can be one of the following:
>
> -- Constant number (including real)
> -- Parameter
> -- Parameter (not real) bit-select or part-select > -- Net > -- Net
bit-select or part-select > -- reg, integer, or time
variable > -- reg, integer, or time variable >
bit-select or part-select > -- real or realtime variable >
-- Array element > -- Array element bit-select or part-select > -- A call
to a ... function ..."
>
>
>
>
> 9. In Table 4-1, add a new row after the first row:
>
> -------------------------------------
> | unary + unary - | Unary operators | >
-------------------------------------
>
>
> 10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:
>
> "There are several types of operands that can be specified in >
expressions.
> The simplest type is a reference to a net or a variable in > its
complete form -- > that is, just the name of the net or variable is given.
In > this case, all > of the bits making up the net or variable value
shall be used > as the operand.
>
> If a single bit of a vector net, reg variable, integer > variable, or
time > variable is required, then a bit-select operand shall be > used. A
part-select > operand shall be used to reference a group of adjacent bits
> in a vector net, > vector reg, integer variable, or time variable.
>
> A memory word can be referenced as an operand. A > concatenation of
other > operands (including nested concatenations) can be specified > as
an operand.
> A function call is an operand."
>
> TO
>
> "There are several types of operands that can be specified in >
expressions.
> The simplest type is a reference to a net, variable or > parameter in
its complete > form -- that is, just the name of the net, variable or >
parameter is given.
> In this case, all of the bits making up the net, variable or > parameter
value > shall be used as the operand.
>
> If a single bit of a vector net or reg, integer or time > variable, or
parameter > is required, then a bit-select operand shall be used. A
part-select > operand shall be used to reference a group of adjacent bits
> in a vector net > or reg, integer or time variable, or parameter.
>
> An array element or a bit-select or part-select of an array > element
can be > referenced as an operand. A concatenation of other > operands
(including nested concatenations) can be specified > as an operand.
> A function call is an operand."
> 11. In 4.2.1 ("Vector bit-select and part-select addressing") > CHANGE
the beginning from:
>
> "Bit-selects extract a particular bit from a vector net, vector reg, >
integer variable, or time variable. The bit can be addressed using an >
expression. If the bit-select is out of the address bounds or > the
bit-select > is x or z, then the value returned by the reference shall be
> x. A bit-select > or part-select of a scalar, or of a variable declared
as real > or realtime, > shall be illegal.
>
> Several contiguous bits in a vector net, vector reg, integer variable, >
or time variable can be addressed and are known as part-selects."
>
> TO:
>
> "Bit-selects extract a particular bit from a vector net or reg, >
integer or time variable, or parameter. The bit can be > addressed using an
> expression. If the bit-select is out of the address bounds or > the
bit-select > is x or z, then the value returned by the reference shall be
> x. A bit-select > or part-select of a scalar, or of a variable or
parameter of > type real or > realtime, shall be illegal.
>
> Several contiguous bits in a vector net or reg, integer or > time
variable, > or parameter can be addressed and are known as part-selects."
>
>
> 12. In paragraph 4, CHANGE
>
> "An indexed part-select of a vector net, vector reg, integer > variable,
or time > variable is given with the following syntax"
>
> TO:
>
> "An indexed part-select of a vector net or reg, integer or > time
variable, > or parameter is given with the following syntax"
>
>
> 13. In paragraph 6, CHANGE
>
> "Part-selects of any type that address a range of bits that > are
completely > out of the address bounds of the net, reg, integer, or time,
..."
>
> TO:
>
> "Part-selects of any type that address a range of bits that > are
completely > out of the address bounds of the net, reg, integer, time or >
parameter ..."
>
>
> 14. Note: In all these places, "reg", "integer", "time" and >
"parameter"
> should be bold. "net" should not be bold.
>
>
> 15. In Syntax 4-2 and A.8.4, in the constant_primary production, >
CHANGE >
> | parameter_identifier
>
> TO
>
> | parameter_identifier { [
> constant_range_expression ] }
>
>
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&datab
> ase=default&pr=483
>
>
>




From: Shalom.Bresticker@freescale.com
To: Stuart Sutherland <stuart@sutherland-hdl.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 22:18:37 +0200 (IST)

Stu,

Thanks for the comments.

On 1: specparams and localparams are not excluded. The text I added includes
specparams, I added the BNF today. See item 6 in the changes.
Throughout the LRM, the term 'parameters'
is used for all types of parameters, except where 3.11 specifically notes
that there are differences. Though I am sure you can find a few exceptions
to that rule. If you want more explicit text about localparams, we can add it.

On 2: Without taking a position, that is a completely separate issue which is
out of the scope of 483. All I did was to take a note which was intended to be
normative and has always been treated as normative and make it explicitly
normative. Changing the content of the note is a new issue.

With respect to the actual suggestion, I believe that SV already makes that
change. Note that the note talks about integer variables, not integer types.
An integer constant, for example, is a different story. I think it would be
necessary to find all the places in the LRM which talk about 32 bit sizes in
order to keep them consistent.

Shalom


On Mon, 8 Nov 2004, Stuart Sutherland wrote:

> I have two questions:
>
> First is a general question. Many of the proposed changes involving adding
> bit- and part-selects of parameters. Why were specparam and localparam
> constants excluded from these changes?
>
> Second is a question that I'd like to hear the thoughts of other 1364 WG
> members about. The change is to make the informative note that the size of
> an integer type shall be "at least 32 bits" into normative text. Rather
> than make this ambiguous size normative, perhaps this is the time to remove
> the ambiguity and simply state that an integer type SHALL BE 32 bits wide.
> I am well aware of why we made this ambiguous to begin with, which was to
> copy the behavior of C and to possibly allow software tools to optimize
> integer types for different operating systems. However, Verilog is a
> hardware modeling language, whereas C is a programming language. Hardware
> vector widths do not arbitrarily change sizes because the operating system
> changed. Further, I do not think it would be desirable for the results of
> synthesizing a Verilog model to result in very different designs simply
> because I re-synthesized on a different platform. Since Verilog is modeling
> hardware, the integer type should have a fixed, and consistent size, like
> hardware. One could argue that the integer type should only be used in
> testbenches and other software-like contexts, but there is nothing in the
> language that prevents using integer types in synthesizable hardware models,
> and I suspect there are many existing hardware models that use integer
> types. In fact, even testbench constructs in Verilog, such as $fopen,
> expect an integer type to be 32 bits. Also worth considering is what do
> synthesis compilers do with the integer type? The 1364.1 standard says the
> integer type is synthesizable, but does not specify a size. However, in
> Section 7.10.3 of 1364.1, it specifically states "A port of an integer type
> shall be treated as a 32 bit signed type,".
>
> In short, my second question is: Can we make the size of the integer type a
> fixed 32 bits, instead of changing the informative note that it "at least 32
> bits" into normative text?
>
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 12:35:31 -0800

Shalom,

You might want to look over the BNF changes the SV-BC recently approved for

http://www.eda.org/svdb/bug_view_page.php?bug_id=0000034

Maybe they should be extended to handle specparams?

-- Brad

-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
Shalom.Bresticker@freescale.com
Sent: Monday, November 08, 2004 12:10 PM
To: etf-bugs@boyd.com
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters


The following reply was made to PR errata/483; it has been noted by GNATS.

From: Shalom.Bresticker@freescale.com
To: Stuart Sutherland <stuart@sutherland-hdl.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Mon, 8 Nov 2004 22:18:37 +0200 (IST)

Stu,

Thanks for the comments.

On 1: specparams and localparams are not excluded. The text I added
includes
specparams, I added the BNF today. See item 6 in the changes.
Throughout the LRM, the term 'parameters'
is used for all types of parameters, except where 3.11 specifically notes
that there are differences. Though I am sure you can find a few exceptions
to that rule. If you want more explicit text about localparams, we can add
it.

On 2: Without taking a position, that is a completely separate issue which
is
out of the scope of 483. All I did was to take a note which was intended to
be
normative and has always been treated as normative and make it explicitly
normative. Changing the content of the note is a new issue.

With respect to the actual suggestion, I believe that SV already makes that
change. Note that the note talks about integer variables, not integer
types.
An integer constant, for example, is a different story. I think it would be
necessary to find all the places in the LRM which talk about 32 bit sizes
in
order to keep them consistent.

Shalom


On Mon, 8 Nov 2004, Stuart Sutherland wrote:

> I have two questions:
>
> First is a general question. Many of the proposed changes involving
adding
> bit- and part-selects of parameters. Why were specparam and localparam
> constants excluded from these changes?
>
> Second is a question that I'd like to hear the thoughts of other 1364 WG
> members about. The change is to make the informative note that the size
of
> an integer type shall be "at least 32 bits" into normative text. Rather
> than make this ambiguous size normative, perhaps this is the time to
remove
> the ambiguity and simply state that an integer type SHALL BE 32 bits
wide.
> I am well aware of why we made this ambiguous to begin with, which was to
> copy the behavior of C and to possibly allow software tools to optimize
> integer types for different operating systems. However, Verilog is a
> hardware modeling language, whereas C is a programming language.
Hardware
> vector widths do not arbitrarily change sizes because the operating
system
> changed. Further, I do not think it would be desirable for the results
of
> synthesizing a Verilog model to result in very different designs simply
> because I re-synthesized on a different platform. Since Verilog is
modeling
> hardware, the integer type should have a fixed, and consistent size, like
> hardware. One could argue that the integer type should only be used in
> testbenches and other software-like contexts, but there is nothing in the
> language that prevents using integer types in synthesizable hardware
models,
> and I suspect there are many existing hardware models that use integer
> types. In fact, even testbench constructs in Verilog, such as $fopen,
> expect an integer type to be 32 bits. Also worth considering is what do
> synthesis compilers do with the integer type? The 1364.1 standard says
the
> integer type is synthesizable, but does not specify a size. However, in
> Section 7.10.3 of 1364.1, it specifically states "A port of an integer
type
> shall be treated as a 32 bit signed type,".
>
> In short, my second question is: Can we make the size of the integer type
a
> fixed 32 bits, instead of changing the informative note that it "at least
32
> bits" into normative text?
>
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478


From: Shalom.Bresticker@freescale.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Tue, 9 Nov 2004 10:33:42 +0200 (IST)

Brad,

What was the context of that bug report?

I don't understand what the description

"The BNF does not allow field, bit, word, part, or
indexed part selects to be constant expressions.
This disallows selects into aggregate parameters
as well as bit/part selects into parameters. This appears
to be a problem inherited from the 1364-2001 grammar."

was referrring to.

1364 has constant_range_expression.

Shalom


On Mon, 8 Nov 2004, Brad Pierce wrote:

> The following reply was made to PR errata/483; it has been noted by GNATS.
>
> From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> To: <etf-bugs@boyd.com>
> Cc:
> Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
> Date: Mon, 8 Nov 2004 12:35:31 -0800
>
> Shalom,
>
> You might want to look over the BNF changes the SV-BC recently approved for
>
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000034
>
> Maybe they should be extended to handle specparams?
>
> -- Brad

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary


Fix replaced by Shalom.Bresticker@freescale.com on Tue Nov 9 08:11:59 2004
2004-11-09: I added more explicit language in 3.11.2 and in
4 to clarify that localparams and specparams can use selects
as well. In 4, I also added strings to list of operands
(see issue 609).

2004-11-08: I added to the proposal an additional change in
the BNF of constant_primary to support bit- and part-selects
of specify parameters. Shalom


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. In section 3.3.2 ("Vector net accessibility"),

CHANGE the last sentence from

"If the keyword scalared is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."

TO

"If the keyword scalared is used or if neither scalared nor
vectored is used, bit-selects and part-selects of the
object shall be permitted, and the PLI shall consider the object
expanded."


Also ADD to the Examples the following:

reg [31:0] bus32 ; // a bus that will be expanded


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


5A. In 3.11.2 ("Local parameters - localparam"), ADD a new
paragraph after the first paragraph as follows:

"Bit-selects and part-selects of local parameters which are
not of type real shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real) or string
-- Parameter (including local and specify parameters)
-- Parameter (not real) bit-select or part-select (including local and specify parameters)
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier { [ constant_range_expression ] }
| specparam_identifier { [ constant_range_expression ] }



From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Tue, 9 Nov 2004 11:07:59 -0800

Shalom,

The erratum description was entered directly into the database, not
in response to a reflector thread.

A reason for the more complicated BNF in the SystemVerilog case is
that a parameter can be a structure, not just a vector. For example,

module m #($unit::My_Struct P = ...) (...);
...

mod #(.N(P.n)) inst(x,y);
...
endmodule

-- Brad


-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
Shalom.Bresticker@freescale.com
Sent: Tuesday, November 09, 2004 12:30 AM
To: etf-bugs@boyd.com
Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters


The following reply was made to PR errata/483; it has been noted by GNATS.

From: Shalom.Bresticker@freescale.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
Date: Tue, 9 Nov 2004 10:33:42 +0200 (IST)

Brad,

What was the context of that bug report?

I don't understand what the description

"The BNF does not allow field, bit, word, part, or
indexed part selects to be constant expressions.
This disallows selects into aggregate parameters
as well as bit/part selects into parameters. This appears
to be a problem inherited from the 1364-2001 grammar."

was referrring to.

1364 has constant_range_expression.

Shalom


On Mon, 8 Nov 2004, Brad Pierce wrote:

> The following reply was made to PR errata/483; it has been noted by
GNATS.
>
> From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> To: <etf-bugs@boyd.com>
> Cc:
> Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
> Date: Mon, 8 Nov 2004 12:35:31 -0800
>
> Shalom,
>
> You might want to look over the BNF changes the SV-BC recently approved
for
>
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000034
>
> Maybe they should be extended to handle specparams?
>
> -- Brad

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary



Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 15 09:44:23 2004
2004-11-09: I added more explicit language in 3.11.2 and in
4 to clarify that localparams and specparams can use selects
as well. In 4, I also added strings to list of operands
(see issue 609).

2004-11-08: I added to the proposal an additional change in
the BNF of constant_primary to support bit- and part-selects
of specify parameters. Shalom


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. Deleted from proposal


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


5A. In 3.11.2 ("Local parameters - localparam"), ADD a new
paragraph after the first paragraph as follows:

"Bit-selects and part-selects of local parameters which are
not of type real shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real) or string
-- Parameter (including local and specify parameters)
-- Parameter (not real) bit-select or part-select (including local and specify parameters)
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element (not real) bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier [ [ constant_range_expression ] ]
| specparam_identifier [ [ constant_range_expression ] ]




Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 15 10:00:45 2004
2004-11-15: In this final version of the proposal, I:
- deleted part 2, which related to the scalared and vectored keywords,
due to controversy;
- in part 7, added "strings" after "constant numbers"
- in part 8, added "(not real)" in array element selects
- in part 15 (BNF), changed curly brackets to square brackets


0. Add references to 487 and 489 to see further discussion
in 483.


1. Section 3.3.1 ("Specifying vectors") ends as follows:

"NOTES:

1) Implementations may set a limit on the maximum length of a vector,
but they will at least be 65536 (2**16) bits.

2) Implementations do not have to detect overflow of integer operations."

Since NOTES are not normative, CHANGE these to:

"Implementations may set a limit on the maximum length of a vector,
but the limit shall be at least 65536 (2**16) bits.

Implementations are not required to detect overflow of integer operations."


2. Deleted from proposal


3. Section 3.6 is "Net initialization". The corresponding text for variables is
in 3.2.2 ("Variable declarations").

The proposal is to delete this sub-section and move its text to be a new
paragraph at the end of 3.2.1 ("Net declarations").


4. In 3.9 ("Integers, reals, times, and realtimes"),
ADD a new paragraph after the paragraph beginning "The time variables...".

The new paragraph is:

"Bit-selects and part-selects of vector regs, integer variables, and time
variables shall be allowed (See 4.2)."


CHANGE

"NOTE--Implementations may limit the maximum size of an integer variable,
but they shall at least be 32 bits."

TO

"Implementations may limit the maximum size of integer variables,
but it shall be at least 32 bits."


5. In 3.11.1 ("Module parameters"), ADD a new paragraph at the end, but
before the Examples. The new paragraph is:

"Bit-selects and part-selects of parameters which are not of type real
shall be allowed (See 4.2)."


5A. In 3.11.2 ("Local parameters - localparam"), ADD a new
paragraph after the first paragraph as follows:

"Bit-selects and part-selects of local parameters which are
not of type real shall be allowed (See 4.2)."


6. In 3.11.3 ("Specify parameters"), ADD a new paragraph before the first
"Examples:". The new paragraph is:

"Bit-selects and part-selects of specify parameters which are not of type
real shall be allowed (See 4.2)."


7. In the introduction to Section 4, paragraph 3 contains,

"The operands of a constant expression consist of constant numbers,
parameter names, constant bit-selects of parameters, constant part-selects
of parameters, and constant function calls (see 10.3.5) only, ..."

CHANGE this to:

"The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only, ..."


8. Paragraph 5 says,

"An operand can be one of the following:

-- Constant number (including real)
-- Net
-- Variables of type reg, integer, time, real, and realtime
-- Net bit-select
-- Bit-select of type reg, integer, and time
-- Net part-select
-- Part-select of type reg, integer, and time
-- Array element
-- A call to a ... function ..."

CHANGE this to:

"An operand can be one of the following:

-- Constant number (including real) or string
-- Parameter (including local and specify parameters)
-- Parameter (not real) bit-select or part-select (including local and specify parameters)
-- Net
-- Net bit-select or part-select
-- reg, integer, or time variable
-- reg, integer, or time variable bit-select or part-select
-- real or realtime variable
-- Array element
-- Array element (not real) bit-select or part-select
-- A call to a ... function ..."




9. In Table 4-1, add a new row after the first row:

-------------------------------------
| unary + unary - | Unary operators |
-------------------------------------


10. In Section 4.2 ("Operands"), CHANGE the 3 paragraphs from:

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net or a variable in its complete form --
that is, just the name of the net or variable is given. In this case, all
of the bits making up the net or variable value shall be used as the operand.

If a single bit of a vector net, reg variable, integer variable, or time
variable is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net,
vector reg, integer variable, or time variable.

A memory word can be referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."

TO

"There are several types of operands that can be specified in expressions.
The simplest type is a reference to a net, variable or parameter in its complete
form -- that is, just the name of the net, variable or parameter is given.
In this case, all of the bits making up the net, variable or parameter value
shall be used as the operand.

If a single bit of a vector net or reg, integer or time variable, or parameter
is required, then a bit-select operand shall be used. A part-select
operand shall be used to reference a group of adjacent bits in a vector net
or reg, integer or time variable, or parameter.

An array element or a bit-select or part-select of an array element can be
referenced as an operand. A concatenation of other
operands (including nested concatenations) can be specified as an operand.
A function call is an operand."
11. In 4.2.1 ("Vector bit-select and part-select addressing")
CHANGE the beginning from:

"Bit-selects extract a particular bit from a vector net, vector reg,
integer variable, or time variable. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable declared as real or realtime,
shall be illegal.

Several contiguous bits in a vector net, vector reg, integer variable,
or time variable can be addressed and are known as part-selects."

TO:

"Bit-selects extract a particular bit from a vector net or reg,
integer or time variable, or parameter. The bit can be addressed using an
expression. If the bit-select is out of the address bounds or the bit-select
is x or z, then the value returned by the reference shall be x. A bit-select
or part-select of a scalar, or of a variable or parameter of type real or
realtime, shall be illegal.

Several contiguous bits in a vector net or reg, integer or time variable,
or parameter can be addressed and are known as part-selects."


12. In paragraph 4, CHANGE

"An indexed part-select of a vector net, vector reg, integer variable, or time
variable is given with the following syntax"

TO:

"An indexed part-select of a vector net or reg, integer or time variable,
or parameter is given with the following syntax"


13. In paragraph 6, CHANGE

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, or time, ..."

TO:

"Part-selects of any type that address a range of bits that are completely
out of the address bounds of the net, reg, integer, time or parameter ..."


14. Note: In all these places, "reg", "integer", "time" and "parameter"
should be bold. "net" should not be bold.


15. In Syntax 4-2 and A.8.4, in the constant_primary production,
CHANGE

| parameter_identifier
| specparam_identifier

TO

| parameter_identifier [ [ constant_range_expression ] ]
| specparam_identifier [ [ constant_range_expression ] ]



Unformatted


Hosted by Boyd Technology