Unparameterization
Expand away modules with parameters; similar to the idea of
elaboration of the design.
Unparameterization is a Verilog transformation which, given a set
of Verilog modules, is supposed to produce an equivalent, parameter-free set of
modules.
Background on Parameters
See vl-paramtype and vl-paramdecl for background on our
representation of parameter declarations. Parameters can be declared as either
ordinary parameters or as localparams. Parameters may have default
values, and their defaults can refer to other parameters in the module. Some
simple examples of parameters are:
module m (a, b, c) ;
...
parameter size = 4 ;
localparam twosize = 2 * size ;
...
endmodule
Such a module can be instantiated in various ways, e.g.,:
module uses_m (x y z) ;
...
m #(6) m_instance_1 (.a(x), .b(y), .c(z)) ; // size 6
m #(.size(6)) m_instance_2 (.a(x), .b(y), .c(z)) ; // size 6
m m_instance_3 (.a(x), .b(y), .c(z)) ; // size 4
...
endmodule
Local parameters are just like parameters except that they cannot be
assigned to from outside the module. They seem like about the cleanest way to
introduce named constants, as unlike `define they don't pollute the global
namespace.
Parameters can also be given values via the defparam statement, but
this construct is being deprecated (see SystemVerilog-2012 section C.4.1) and
may be removed from future versions of the language. We generally think that
using defparam is bad form. VL does not support defparam, so we do
not consider it here.
Unparameterization
The basic idea behind unparameterization is pretty simple.
Suppose we are dealing with a parameterized module called plus, which
takes a single parameter called size. There may be several modules, say
m1, m2, and m3, which contain instances of plus with
different sizes, say 8, 16, and 32.
Our general goal is to eliminate plus from our module list by replacing
it with three new modules, plus$size=8, plus$size=16, and
plus$size=32, which are copies of plus except that size has been
replaced everywhere with 8, 16, or 32 as suggested by their
names.
At the same time, we need to change the instances of plus throughout
m1, m2, and m3 with appropriate instances of the new modules.
Finally, once all of the instances of the generic plus have been done away
with, we can safely remove plus from our module list.
Subtopics
- Scopesubst
- Scope aware substitution that replaces occurrences of resolved
parameters with their values.
- Vl-scopeinfo-resolve-params
- Vl-make-paramdecloverrides
- Line up parameter arguments with parameter declarations.
- Vl-unparam-inst
- Try to unparameterize a single module instance.
- Vl-scope-finalize-params
- Vl-override-parameter-value
- Try to override an arbitrary parameter with its final value.
- Vl-unparam-instlist
- Vl-create-unparameterized-module
- Vl-module-default-signature
- Vl-modulelist-default-signatures
- Vl-gencase-some-match
- Vl-gencase-match
- Vl-make-paramdecloverrides-named
- Line up named parameter arguments with parameter declarations.
- Vl-unparam-newname
- Generate a new name for an unparameterized module.
- Vl-paramdecl-set-default
- Vl-unparam-signature
- Vl-genblob-collect-modinst-paramsigs
- Collect parameterization signatures needed for module instances of a given module.
- Vl-design-unparameterize
- Top-level unparameterization transform.
- Vl-paramdecllist-remove-defaults
- Vl-unparam-newname-exprstring
- Vl-paramdecl-remove-default
- Vl-unparam-sigalist
- An alist mapping vl-unparam-signature-p to vl-scopestack-p.
- Vl-unparam-signaturelist
- A list of vl-unparam-signature-p objects.
