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