Re: New Generate Proposal

From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Fri Feb 06 2004 - 10:29:10 PST

  • Next message: Karen Pieper: "Fwd: Meeting Monday"

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

    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.

    -- Brad

    This archive was generated by hypermail 2.1.4 : Fri Feb 06 2004 - 10:15:35 PST and
    sponsored by Boyd Technology, Inc.