Here is a brief note on SV - constants. Constants are data objects that never change. SV provides the following types of constants.
Elaboration time constants:-
1) parameter - A parameter has two attributes, type and range.
e.g. parameter logic[7:0] BASE_ADDR = 8;
By default a parameter would take the type and range of the final value assigned to it. By default any parameter would be unsigned. Hierarchical references are not allowed in parameter declarations, reason being these are elaboration type constants. Package references are however allowed in parameter declarations. A parameter can be overridden by a defparam statement. However there is an exception in case of type parameters.
Type parameters:- A parameter constant which specifies a data type, e.g.,
A type parameter cannot be overridden by a defparam statement.
2) localparam - local parameters (localparam) are identical to paramters except they cannot be overridden by defparam or instance parameter value assignments.Inside a compilation unit, generate block, package or class body, parameter and localparam are synonymous.
3) specparam - this is a parameter type intended only for providing timing values or delays. These can be declared within specify blocks or the module body.
Note: specparam and param are not interchangeable.
Run-time constant:-
1) const - const can be set during elaboration and simulation/run time. However localparam can be set only during elaboration time.
The following code-snippet might give some insights into the usage details of the different constant types.
Parameter as $ : Parameter can be assigned a value $ for integer types only.
The LRM gives an example in terms of assertions.
It would be interesting to run the following code-snippet and see how different simulators respond to it.
A note on defparam : Parameter values can be changed in any module, interface or program using cross-module references using the defparam statement.
However the SV-2012 LRM does give an indication to deprecate this feature in future versions, hence it is a good idea to take care of not using this feature where re-usability is of prime importance (which is always !!)
Elaboration time constants:-
1) parameter - A parameter has two attributes, type and range.
e.g. parameter logic[7:0] BASE_ADDR = 8;
By default a parameter would take the type and range of the final value assigned to it. By default any parameter would be unsigned. Hierarchical references are not allowed in parameter declarations, reason being these are elaboration type constants. Package references are however allowed in parameter declarations. A parameter can be overridden by a defparam statement. However there is an exception in case of type parameters.
Type parameters:- A parameter constant which specifies a data type, e.g.,
module m1 (parameter type p1 = shortint);
p1 i = 0; // i here is shortint
initial begin
int j = 0;
j = i + 2;
.
.
end
endmoduleA type parameter cannot be overridden by a defparam statement.
2) localparam - local parameters (localparam) are identical to paramters except they cannot be overridden by defparam or instance parameter value assignments.Inside a compilation unit, generate block, package or class body, parameter and localparam are synonymous.
3) specparam - this is a parameter type intended only for providing timing values or delays. These can be declared within specify blocks or the module body.
Note: specparam and param are not interchangeable.
Run-time constant:-
1) const - const can be set during elaboration and simulation/run time. However localparam can be set only during elaboration time.
The following code-snippet might give some insights into the usage details of the different constant types.
Parameter as $ : Parameter can be assigned a value $ for integer types only.
The LRM gives an example in terms of assertions.
It would be interesting to run the following code-snippet and see how different simulators respond to it.
A note on defparam : Parameter values can be changed in any module, interface or program using cross-module references using the defparam statement.
However the SV-2012 LRM does give an indication to deprecate this feature in future versions, hence it is a good idea to take care of not using this feature where re-usability is of prime importance (which is always !!)
