Re: New Generate Proposal

From: Shalom.Bresticker@motorola.com
Date: Sun Feb 08 2004 - 06:27:28 PST

  • Next message: Shalom Bresticker: "Re: New Generate Proposal"

    Brad,

    On Fri, 6 Feb 2004, Brad Pierce wrote:

    > Although I like the generate proposal, I have some concerns about
    > its BNF changes. First consider two smaller issues --
    >
    > Creating genvar_primary and moving genvar_identifier out of
    > constant_primary makes it impossible to use a genvar in a
    > constant_expression. But constant_expression is used in generate-if
    > and generate-case conditions and in generate-case item expressions.
    > It seems unnatural to prevent genvars in those contexts.
    >
    > If genvar_identifiers are not part of a constant_expression, then they
    > aren't part of a genvar_initialization, making it impossible to use a
    > genvar from a surrounding generate scope as the initializer in the local
    > generate scope (as in nested generate-for loops). This also seems
    > unnatural.
    >
    > (I guess one *could* say that a genvar is an implicit localparam,
    > hence is handled by parameter_identifier. Very unsatisfying.)

    I had exactly the same question.
    However, Jason and Steven feel it is important to emphasize that genvars
    do not exist after elaboration. References to genvars within the code are
    exactly references to the implicit localparam.

    Therefore, 12.4.1 emphasizes the following:
    "Within the generate block of a loop generate construct, there is an
    implicit localparam declaration. This parameter has the same name as the
    loop index variable, and its value within each instance of the generate
    block is the value of the index variable at the time the instance was
    elaborated. This parameter can be used anywhere within the generate block
    that a normal parameter with an integer value can be used. It can be
    referenced with a hierarchical name.

    Because this implicit localparam has the same name as the genvar, any
    reference to this name inside the loop generate block will be a reference
    to the localparam, not to the genvar."

    There was supposed to be a comment in 12.4.1, Example 2 (in the draft
    containing the entire text and not just the changes) on the line

    assign bin[i] = ^gray[SIZE-1:i];

    as follows:

      // i refers to the implicitly defined localparam whose value in each instance
      // of the generate block is the value of the genvar when it was elaborated.

    We forgot to insert that comment.

    Jason had wrote:

    "I understand that it seems simpler to call these "genvar references", but
    the situation will get tricky and more confusing at the VPI level if we
    let this go. I believe it is very important to maintain a clear distinction
    between an object that has no value at simulation time (the genvar) and an
    object that has a different constant value inside each instance of the loop
    generate block. These cannot be the same conceptual object from the VPI point
    of view without creating a whole new interface routine to select which version
    of the declaration is being referenced. Not worth it.

    That is why, to clarify and remove the confusion from this double (triple,
    quadruple...) life that these genvars seem to lead, it is better to state
    explicitly that there is an implicit localparam inside loop generate blocks
    with the same name as the genvar. Now we can say with clarity that the
    genvar declaration does not create an object that exists at simulation time.

    I agree that the BNF should not be used to convey semantic information. That's
    not what I'm doing. I am trying to make the BNF consistent with the statement
    that genvars do not have a value at simulation time. How could they be included
    in constant_primary given that?

    Lastly, I agree that this is less intuitive. That is why I feel the whole
    concept of a genvar was a bad idea. All we need is the implicitly declared
    constant inside the loop (or call it explicitly declared by the generate scheme
    itself, as in VHDL). But alas we are stuck with genvars and their unintuitive
    nature."

    And Steven Sharp wrote:

    "What percentage of the engineers writing Verilog code also have to write
    PLI/VPI code?

    As you point out, these objects are distinct from the PLI viewpoint. But
    someone writing Verilog code can think about it with the simpler (though
    technically incorrect) view, and get what they expect. The main part of
    the LRM could describe it that way, but at the cost of making the PLI part
    more confusing (i.e. it would have to start by saying that the main part
    wasn't really correct, and what is really going on is...) This might make
    sense if only a small percentage of users actually have to deal with the
    PLI view of it.

    On the other hand, how many unsophisticated users will actually be trying
    to learn how this works by using the LRM text? It is supposed to be a
    language reference manual that precisely defines the language, not a simple
    tutorial. It is more important that it be technically correct, than that
    it avoid saying anything that might confuse a beginner."

    > The above issues though are just a symptom of a more general problem,
    > namely, trying to impose semantic checks with BNF syntax rules.
    >
    > We should be getting rid of mirror sublanguages like constant_expression
    > and module_path_expression, not adding another one.
    >
    > My recommendation --
    > Do not change constant_primary.
    > Do not define genvar_primary and genvar_expression.

    I really do not think that constant_expression is just a mirror
    sublanguage of expression and only semantically different. It is
    syntactically different. I do agree that sometimes it becomes awkward
    and complex and it is not worthwhile to make a new syntactic construct.
    I do not think that is the case here.

    Anyway, regarding the specific question of the genvars, we have a draft
    proposal and the ETF and the VSG can make changes in it. 

    -- 
Shalom Bresticker                         Shalom.Bresticker@motorola.com
Design, Verification & Reuse Methodology             Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd.                  Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 441478

    This archive was generated by hypermail 2.1.4 : Sun Feb 08 2004 - 06:13:51 PST and
    sponsored by Boyd Technology, Inc.