From: Marq Kole <marq.kole_at_.....>
Date: Fri Dec 15 2006 - 07:39:50 PST
Shalom,
Thanks for the data. Yesterday in the
conference call the proposal was made for a stronger restriction on defparam
in paramsets, essentially disallowing defparam statements in the hierarchy
in or under a paramset instance. I had originally opted for the same restriction
as in generate constructs, but in the call the feeling was that defparam
use should be discouraged -- it is mainly present in the standard for the
larger installed base of older verilog code that contains a lot of defparam
statements. If users would start asking for support of defparam inside
paramset hierarchies, the definition could always be extended in a later
version of the standard.
As it is, the paramset selection mechanism
cannot be used for any digital code which relies on this legacy code.
“However, a defparam statement
in a hierarchy in or under a generate block instance (see 12.4) or an array
of
instances (see 7.1 and 12.1.2)
shall not change a parameter value outside that hierarchy.
Each instantiation of a generate
block is considered to be a separate hierarchy scope. Therefore, this rule
implies that a defparam statement
in a generate block may not target a parameter in another instantiation
of
the same generate block, even
when the other instantiation is created by the same loop generate construct.
For example, the following code
is not allowed:
genvar i;
generate for (i = 0; i <
8; i = i + 1) begin : somename
flop my_flop(in[i],
in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz
= i ;
end endgenerate
Similarly, a defparam statement
in one instance of an array of instances may not target a parameter in
another instance of the array.”
This shows why Kev’s simplification
would be ambiguous. The term “upwards defparam” could be interpreted
in more than one way.
12.8.2 also says,
“It shall be an error if a hierarchical
name in a defparam is resolved before the hierarchy is completely
elaborated and that name would
resolve differently once the model is completely elaborated.”
Shalom
From: owner-verilog-ams@server.eda.org
[mailto:owner-verilog-ams@server.eda.org] On Behalf Of edaorg@v-ms.com
Sent: Friday, December 15, 2006 10:38 AM
To: verilog-ams@server.verilog.org
Cc: Marq Kole
Subject: Re: Elaboration algorithm proposal
Marq Kole wrote:
All,
I've given some thought to the elaboration algorithm, but it turns out
that the possibility for ambiguity occurs mainly from the presence of defparam
statements. This means that the algorithm in section 7.8.4 that was copied
from 1364-2005 needs only very few adaptions.
The discipline resolution algorithm is not needed at this point as for
that the whole hierarchy needs to be present -- connectivity cannot be
correctly resolved if new connections to a net can occur due to parameter-dependent
evaluation of generate constructs. The only additions to the hierarchy
after discipline resolution are the automatically inserted connect modules.
Paramsets play a role in that the correct selection of a paramset can only
occur when the arguments of the paramset instantiation have attained their
final values. This essentially means that a paramset can ony be evaluated
after the defparam statements. Unfortunately, a paramset-selected module
may contain a defparam statement itself that could make the paramset selection
itself ambiguous. Unlike the combination of the generate constructs and
defparam statements, there is no restriction currently on the use of defparams
in combination with paramsets. My proposal to resolve this would be to
add the same limitation of defparams in generate constructs to paramsets.
This limitation is at this moment only mentioned in the elaboration algorithm:
"no defparam inside the hierarchy below a generate
construct is allowed to refer to a parameter outside the generate construct."
There is no other reference to this limitation in section 7.5 on generate
constructs in the merged_hier.pdf, but I might have missed something in
the 1364-2005 LRM. Anyway, the limitation on modules selected by paramsets
would become:
"no defparam inside the hierarchy below a paramset
is allowed to refer to a parameter outside the selected module."
How about simplifying it to just no "upward" defparams? - I can't
think of any good reason for allowing them.
This text would need to be added to section 7.2.1 (on defparam) or in section
7.3 (on paramsets). This depends on the place where this is defined in
1364-2005. I don't have the 1364-2005 standard at hand, so if someone would
be so kind to have a look at defparam restrictions before tonights/tomorrow's
call we could use that input as well.
Here is the proposed text for section 7.8, I'll be posting an integrated
text in PDF tomorrow, including the proposed changes to sections 7.2 and/or
7.3, unless discussion in the conference call tonight/tomorrow gives reason
to reconsider.
Elaboration is the process that occurs between parsing and simulation.
It binds modules to module instances, builds the model hierarchy, computes
parameter values, selects paramsets, resolves hierarchical names, establishes
net connectivity, resolves disciplines and inserts connect modules, and
prepares all of this for simulation. With the addition of generate constructs,
the order in which these tasks occur becomes significant.
7.8.1 Concatenation of analog blocks
A module definition may have multiple analog blocks. The simulator shall
internally combine the multiple analog blocks into a single analog block
in the order that the analog blocks appear in the module description. In
other words, the analog blocks shall execute in the order that they are
specified in the module.
Concatenation of the analog blocks occurs after all generate constructs
have been evaluated, i.e. after the loop generate constructs have been
unrolled, and after the conditional generate constructs have been selected.
If an analog block appears in a loop generate statement then the order
in which the loop is unrolled during elaboration determines the order in
which the analog blocks are concatenated to the eventual single analog
block after elaboration.
This sounds bad to me. As a user
I would expect to get the same behavior if I put the analog blocks
in the same module or in separate modules if their connectivity is the
same - I don't see that being the case if the blocks get concatenated.
Reodering always blocks in Verilog doesn't change the behavior,
the same should be true for analog blocks.
I think there should be an explicit statement to the effect that: the reordering
of analog blocks within a module or declaring them in seperate modules
should not change the results of simulation for pure analog (to exclude
A/D issues at ports).
Kev.
7.8.2 Elaboration and paramsets
If a generate construct contains an instantiation of an overloaded paramset,
then the paramset selection is performed after the generate construct has
been evaluated. The evaluation of the generate construct may influence
the values and connections of the paramset instance, and hence the selection
of the matching paramset and module.
7.8.3 Elaboration and connectmodules
Automatic insertion of connect modules is a post-elaboration operation,
as first the disciplines of the various nets needs to be resolved. This
is described in detail in Section 8.8.
Discipline resolution can only occur after elaboration of the generate
constructs once the connections of all nets has been resolved. It should
also occur after the paramset selection as the choice for a particular
module instantiation may affect the disciplines of the connected nets.
7.8.4 Order of elaboration
Because of generate constructs and paramsets, the model hierarchy can depend
on parameter values. Because defparam statements can alter parameter values
from almost anywhere in the hierarchy, the result of elaboration can be
ambiguous when generate constructs or paramsets are involved. The final
model hierarchy can depend on the order in which defparams, generate constructs
and paramsets are evaluated.
The following algorithm defines an order that produces the correct hierarchy:
1. A list of starting points is initialized
with the list of top-level modules.
2. The hierarchy below each starting point is
expanded as much as possible without elaborating generate constructs or
selecting paramsets. All parameters encountered during this expansion are
given their final values by applying initial values, parameter overrides,
and defparam statements.
In other words, any defparam statement whose target can be resolved within
the hierarchy elaborated so far must have its target resolved and its value
applied. defparam statements whose target cannot be resolved are deferred
until the next iteration of this step. Because no defparam inside the hierarchy
below a generate construct or paramset is allowed to refer to a parameter
outside the generate construct or paramset, it is possible for parameters
to get their final values before going to step 3).
3. Each generate construct encountered in step
2) is revisited, and the generate scheme is evaluated. After that, each
paramset instantiation encountered in step 2) is revisited, even when that
paramset instantiation was part of a now evaluated generate construct,
and the correct module is selected. The resulting generate block instantiations
and paramset-matching module instantiations make up the new list of starting
points. If the new list of starting points is not empty, go to step 2).