RE: Elaboration algorithm proposal

In 1364-2005, 12.2.1 says,

 

"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. 

--8<--------------------------------------------------------------------
-------- 

7.8 Elaboration 

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). 

--8<--------------------------------------------------------------------
-------- 

Cheers, 
Marq 


Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors