re: errata/113: generate

From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Tue May 20 2003 - 04:30:08 PDT

  • Next message: Michael McNamara: "RE: enhancement/350: Proposal to deprecate configs in Verilog source files"

    Precedence: bulk

    The following reply was made to PR errata/113; it has been noted by GNATS.

    From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: re: errata/113: generate
    Date: Tue, 20 May 2003 14:28:47 +0300

     I resend Gord's 'progress report' to get it into the database:
     
     There are numerous issues that the Verilog2001 ETF sub-group
     on "generate" has been dealing with. The following is a
     summary of a few of the main ideas that the committee is
     working on formalizing. Any additional input to the process
     would be appreciated since we would like to end up with
     a broadly acceptable and consistent interpretation.
     
     Some of the issues in the current LRM are related to the
     fact that there isn't really a well-described model for
     the post-elaboration design and how the pre-elaboration
     structures map to the final elaborated design. This is
     particularly evident in the fact that there is no defined
     mechanism in VPI to access "generated" structures. The
     generate sub-group is working with the PLI group to resolve
     all issues simultaneously so that we end up with a consistent
     model.
     
     The current members of the sub-group are:
         Gord Vreugdenhil (Synopsys)
         Steven Sharp (Cadence)
         Dennis Marsa (Xilinx)
         Shalom Bresticker (Motorola)
     
     with the following also tracking the discussion:
         Michael McNamara (Verisity)
         Charles Dawson (Cadence)
     
     
     Please note that the description and proposals that follow
     are preliminary and subject to change. There is still
     ongoing discussion within the sub-group about various
     aspects but due to the nature of the proposals, a wider
     discussion was deemed to be valuable.
     
     --------------------
     
     One important issue to be aware of when understanding generate,
     is that generate constructs cannot be considered as compile
     time only preprocessing of the design. The handling of
     generate constructs is an elaboration time activity due
     to the interactions between defparam statements, parameter
     resolution, and name resolution.
     
     
     1) Elaboration sequencing and hierarchical name resolution
     
     In the presence of conditionally generated identifiers,
     it is possible for implementations to incorrectly resolve
     hierarchical names. The main issue, particularly for
     defparams, is that there may be an upwards resolution of
     a hierarchical name and a *possible* downwards resolution
     depending on elaboration. The elaboration sequencing
     must commit to either an upwards or downwards resolution
     without knowing whether the resolution will be correct.
     
     Example:
     
     module top;
        Mid m();
     endmodule;
     
     module Mid();
        parameter p = 2;
     
        defparam m.p = 1;
     
        generate
           if (p == 1)
              Mid2 m();
        endgenerate
     endmodule
     
     module Mid2();
        parameter p = 1;
     endmodule
     
     In such a case, the name "m.p" might resolve downwards but
     there is also an upwards resolution possible. In this case,
     committing to the upwards resolution would lead to the
     elaboration of top.m.m in which case the resolution is
     incorrect since the LRM requires downwards resolution in
     such cases. However, committing to the possible downwards
     resolution is also incorrect since top.m.m would not exist
     without the upwards resolution.
     
     Although the above case is constructed to expose the worst
     possible situation, upwards/downwards resolution choices
     can exist in real designs.
     
     The sub-group's current position on this is that non-defparam
     hierarchical names must be resolved in the post-elaboration
     context. defparam hierarchical names are to be resolved in
     as early as possible -- as soon as a possible resolution
     exists during elaboration, one must choose that resolution.
     Then, following elaboration, each defparam hierarchical
     name must be checked to see if the elaboration time selected
     resolution is consistent with the post-elaboration design.
     If the resolution in the post-elaboration design is different,
     the implementation must report an error and the design is
     considered to be erroneous.
     
     The requirement to report an error is not definite yet; the
     sub-group is still considering that issue.
     
     
     --------------------
     
     2) Data model and syntax for generate for statements
     
     The data model and interaction of "genvar" declarations
     and generate-for loops is not very clean in the current LRM,
     both in terms of any possible VPI model and name resolution
     and scoping issues.
     
     A reasonable way to resolve the issues is to take two
     steps:
       a) a closer relationship between "genvar" and the
          generate-for loop
       b) a better model for generated blocks in the post-elaboration
          design
     
     
     For (a), the sub-group is recommending the that generate-for
     loops have the following general form:
     
         for (localparam i = 0; i < 10; i = i + 1) begin : b
         end
     
     The "localparam" would (likely) be optional. The post-elaboration
     model is closer to the VHDL model -- the name "i" is introduced
     as a localparam declaration within each instance of block
     "b" with the value of the localparam being the iteration value.
     There would be no restriction on the value (negatives would
     be permitted) other than requiring that index values be unique.
     
     The group had discussed retaining "genvar" in place of
     "localparam" in the syntax, but since "localparam" expresses
     exactly the desired semantics, there didn't seem to be any
     value in keeping the keyword "genvar", particularly since
     that keyword would conflict with its use in the Verilog-AMS
     standard.
     
     For backwards compatibility, the group is currently recommending
     that the current form of genvar declarations remain legal
     (deprecated) syntax but that such declarations be completely
     ignored. Making the "localparam" optional then ensures that
     virtually any currently legal design would remain legal.
     
     The advantage of this model is that it is easier to explain,
     reduces issues in terms of detemining the validity of
     hierarchical references to genvar declarations, and eliminates
     potentially strange name resolution issues.
     
     Examples:
         generate
            genvar i;
            for (i = 0; i < 5; i = i + 1) begin:b
               reg i;
            end
         endgenerate
     
     In the current LRM, such an example would likely be legal although
     opinions in the sub-group vary on that. Even more strange would
     be:
            for (i = 0; i < 5; i = i + 1) begin:b
               reg i = i;
            end
     which could use the "genvar" value of i for the RHS.
     
     Both examples would be illegal in the new form since the
     for-loop iterator "i" becomes an implicit declaration
     with block "b".
     
     
     For part (b), the VPI data model, the group is recommending
     that we adopt a "sparse instance array" model for named blocks
     generated by a generate-for loop. The idea is that the base
     name of the block ("b" in the above case) becomes the name
     of an array of scopes. One would then iterate over the
     scopes and could ask for the indexExpr of each block. This
     model also resolves numerous issues that arise in terms of the
     current LRM's description of names such as "b[0]" as a special
     kind of identifier rather than an indexed scope. Instance
     arrays and indexed scopes are then essentially symmetric in
     the LRM other than the requirement that in VPI one must iterate
     to find the index expressions of a scopes in a generated
     scope array.
     
     --------------------
     
     3) Scoping and conditional names
     
     This issue is one that is still undergoing consideration
     in the committee. It is partly driven by efficiency concerns,
     particularly once future language extensions (SystemVerilog
     constructs in particular) come into play. The issue is whether
     to disallow named object declarations within an unnamed
     generated block. This is a harder issue to have a strong
     rationale for other than the fact that implementors across
     a number of companies and product lines agree that not naming
     the blocks makes things more difficult and irregular in
     terms of implementing generate.
     
     
     
     Consider the following:
         generate
             if (c)
                 wire x;
             else
                 reg x;
         endgenerate
     
         initial $monitor(x);
     
     It is not possible to bind "x" to a definition until elaboration
     time. Conceptually, if one thinks of "x" as a prefix-free
     hierarchical name, then the rules presented in issue (1)
     apply and everything falls out.
     
     The concern is that we now have to treat *every* simple
     identifier that doesn't have a binding in the immediate scope
     as a hierarchical name and defer its resolution. In
     SystemVerilog, simple identifiers can bind to "$root" names
     which means that such binding issues may happen significantly
     more often and impact performance.
     
     The proposal is to require named blocks for conditionally
     instantiated names. There are a couple of options the group
     is considering:
     
       a) require a named block on each branch of a conditional
          generate statement (case or if). The names could be
          duplicated as long as only one was elaborated.
     
          if (c) begin:b
              wire x;
          end
          else begin:b
              reg x;
          end
     
       b) introduce new syntax to "label" the statment.
     
          if:b (c)
              wire x;
          else
              reg x;
     
     
     Requiring scope names for declarations ensures that all such
     name references end up being hierarchical references and you
     only end up "paying" for conditional binding when necessary.
     
     
     
     
     
     --------------------
     
     4) Minor clarifications and Interpretations
     
     a) Recursive instantiations are permitted
     
     b) A "top module" is a module that **does not have an
        instantiation statement** versus a module that is
        not instantiated. The latter (current LRM wording)
        leads to contradictions. The new definition does imply
        that, in absence of configurations, etc, that a design
        that consists solely of a recursive module (or recursive
        clique) would not have a top module and would thus be
        invalid.
     
     c) Name conflicts within the same immediate scope
        cause errors even if the scope is not elaborated
     
        ie: if (0) begin
                 reg x;
                 reg x;
              end
     
     d) Two generate-for constructs are not permitted to have
        same named block identifier even if their generate index
        values are distinct.
     
     e) The sub-group is also considering whether to make the
        generate and endgenerate keywords optional (or to remove
        them) since they provide no semantic meaning or scoping.
     

    This archive was generated by hypermail 2.1.4 : Tue May 20 2003 - 04:31:01 PDT and
    sponsored by Boyd Technology, Inc.