From: James A. Markevitch (jam@magic.com)
Date: Mon Nov 01 1999 - 21:30:08 PST
Per our discussion during the VSG meeting today, here is an updated version
of Stu Stutherland's wording of the parameter proposal. I made the
following changes:
Eliminated the [range] for integers.
Eliminated text referencing range for integers.
Removed extra square brackets around integer, real, realtime, time.
I would also like to propose some text to indicate the valid bit range
for parameters with no explicit range. The possibilities below are labeled
A1, A2, and A3. I favor A1, but existing implementations may dictate
either A2 or A3 being chosen. Note that A1 would make newconst[3] an
illegal bit select. Alternatively, we can say that the whole thing is
implementation-dependent.
Each of these proposals would be added to section 3.11.1
OPTIONAL PROPOSAL A1
- A parameter with no range specification, and with either a signed
type specification or no type specification, shall have an implied
range with an lsb equal to 0 and an msb equal to one less than the
size of the final value assigned to the parameter.
ADD THE FOLLOWING EXAMPLE
parameter newconst = 3'h4; // Implied range of [2:0]
OPTIONAL PROPOSAL A2
- A parameter with no range specification, and with either a signed
type specification or no type specification, shall have an implied
range of [31:0].
ADD THE FOLLOWING EXAMPLE
parameter newconst = 3'h4; // Implied range of [31:0]
OPTIONAL PROPOSAL A3
- A parameter with no range specification, and with either a signed
type specification or no type specification, shall have an implied
range with an lsb equal to 0 and an msb which is implementation-
dependent, but which shall be at least 31.
ADD THE FOLLOWING EXAMPLE
parameter newconst = 3'h4; // Implied range of at least [31:0]
Finally, I would also like to propose some text to indicate the valid range
for an unsized parameter being assigned an unsized value. The possibilities
below are labeled B1 and B2. I favor B3, but I think that conflicts with
existing implementations, in which case I probably prefer B2. Alternatively,
we can say the whole thing is implementation-dependent.
OPTIONAL PROPOSAL B1
- 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 an implied range of [31:0].
ADD THE FOLLOWING EXAMPLE
parameter newconst = 4; // Implied range of [31:0]
OPTIONAL PROPOSAL B2
- 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 an implied range with
an lsb equal to 0 and an msb equal to an implementation-dependent
value of at least 31.
ADD THE FOLLOWING EXAMPLE
parameter newconst = 4; // Implied range of at least [31:0]
OPTIONAL PROPOSAL B3
- 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 also be unsized.
ADD THE FOLLOWING EXAMPLE
parameter newconst = 4; // Unsized parameter
<p><p><p><p>----------------------------
Draft 3, Page 31, Section 3.11.1, Syntax 3-5:
CHANGE THE PARAMETER SYNTAX FIGURE:
WAS:
parameter_declaration ::= parameter list_of_param_assignments ;
list_of_param_assignments ::= param_assignment { , param_assignment }
param_assignment ::= parameter_identifier = constant_expression
PROPOSED IS:
paramater_declaration ::=
parameter [signed] [range] list_of_param_assignments ;
| parameter integer list_of_param_assignments ;
| parameter real list_of_param_assignments ;
| parameter realtime list_of_param_assignments ;
| parameter time list_of_param_assignments ;
param_assignment ::=
parameter_identifier = constant_expression
----------------------------
Draft 3, Page 31, Section 3.11.1:
ADD THE FOLLOWING PARAGRAPHS JUST BEFORE THE EXAMPLES:
A module parameter can have a type specification and a range
specification. The type and range of module parameters shall
be in accordance with the following rules:
- A parameter declaration with no type or range specification
shall default to the type and range of the final value assigned
to the parameter, after any value overrides have been applied.
- A parameter with a range specification but with no type
specification shall be the range of the parameter declaration,
and shall be unsigned. The sign and range shall not be
affected by value overrides.
- A parameter with a type specification but with no range
specification shall be of the type specified. A signed
parameter shall default to the range of the final
value assigned to the parameter, after any value overrides
have been applied.
- A parameter with a signed type specification, and
with a range specification, shall be signed, and shall be
the range of its declaration. The sign and range shall not be
affected by value overrides.
----------------------------
Draft 3, Page 31, Section 3.11.1
ADD THE FOLLOWING EXAMPLES AT THE END OF THE CURRENT EXAMPLES:
parameter signed [3:0] mux_selector = 0;
parameter real r1 = 3.5e17;
parameter p1 = 13'h7e;
parameter [31:0] dec_const = 1'b1; // value converted to 32 bits
----------------------------
Draft 3, Page 31, Section 3.11.2, Syntax 3-6:
CHANGE THE FIRST LINE OF THE SPECPARAM DECLARATION SYNTAX:
WAS:
specparam_declaration ::= specparam list_of_specparam_assignments ;
PROPOSED IS:
specparam_declaration ::= specparam [ range ]
list_of_specparam_assignements ;
----------------------------
Draft 3, Page 32, Section 3.11.2:
ADD THE FOLLOWING PARAGRAPHS JUST BEFORE THE EXAMPLES:
A specify parameter can have a range specification. The range
of specify parameters shall be in accordance with the following
rules:
- A specparam declaration with no range specification shall
default to the range of the final value assigned to the parameter,
after any value overrides have been applied.
- A specparam with a range specification shall be the range of
the parameter declaration. The range shall not be affected
by value overrides.
----------------------------
Draft 3, Page 56, Section 4.5.1:
STRIKE THE BULLET REGARDING PARAMETERS, AND ITS ASSOCIATED NOTE:
- Parameters are signed if and only if the expression assigned to the
parameter is signed.
NOTE--This is true whether the expression is assigned via a
parameter declaration statement, a defparam statement, or a module
instance parameter value assignment.
----------------------------
Draft 3, Page 169, Section 12.2
REPLACE THE SECOND AND THIRD PARAGRAPHS:
WAS:
There are two kinds of parameter declarations. The first kind of
parameter declaration has a type and or range qualification,
and second does not. When an untyped and unranged parameterÆs
value is overridden, the parameter takes on the range and type of
the override.
When a typed and/or ranged parameter is overriden, the new value
is converted to the type and range of the destination, and assigned
to that parameter.
PROPOSED IS:
A module parameter can have a type specification and a range
specification. The effect of parameter overrides on a parameter's
type and range shall be in accordance with the following rules:
- A parameter declaration with no type or range specification
shall default to the type and range of the final override value
assigned to the parameter.
- A parameter with a range specification but with no type
specification shall be the range of the parameter declaration,
and shall be unsigned. An override value shall be converted
to the type and range of the parameter.
- A parameter with a type specification but with no range
specification shall be of the type specified. An override value
shall be converted to the type of the parameter. A signed
parameter shall default to the range of the final
override value assigned to the parameter.
- A parameter with a signed type specification, and with
a range specification, shall be a signed, and shall be the range
of its declaration. An override value shall be converted to the
type and range of the parameter.
----------------------------
Draft 3, Page 169, Section 12.2
REPLACE THE TWO PARAGRAPHS FOLLOWING THE EXAMPLE:
WAS:
Parameter A is a typed and/or ranged parameter, and so the defparam
of f1.A with the value 3.1415 is performed by converting the
floating point number 3.1415 into a fixed point number Æ3Æ and then
the low 3 bits of 3 are assigned to A.
Parameter B is not a typed and/or ranged parameter, and so the
defparam of f1.B with the value 3.1415 replaces BÆs current value of
3Æh2 with the floating point number 3.1415.
PROPOSED IS:
Parameter A is a typed and/or ranged parameter, so when its value
is redefined, the parameter retains its original type and sign.
Therefore, the defparam of f1.A with the value 3.1415 is performed
by converting the floating point number 3.1415 into a fixed point
value of 3, and then the lower 3 bits of the value are assigned to A.
Parameter B is not a typed and/or ranged parameter, so when its
value is redefined, the parameter type and range take on the
type and range of the new value. Therefore, the defparam of f1.B
with the value 3.1415 replaces B's current value of 3'h2 with the
floating point number 3.1415.
James Markevitch
jam@magic.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:31 PDT
and
sponsored by Boyd Technology, Inc.