Re: Generate proposal

From: Steven Sharp (sharp@cadence.com)
Date: Fri Jan 09 2004 - 17:00:31 PST

  • Next message: Krishna Garlapati: "Re: Generate proposal"

    > The proposed draft looks good. Many thanks for the task force in
    >getting this done.

    Jason Woolf should be credited with actually writing almost everything,
    with Shalom providing most of the feedback so far.

    >1. I don't understand the reason (or spirit) why the following the
    >usage is illegal:
    >
    >reg a;
    >for(i=1; i < 0; i=i+1) begin : a
    >end
    >
    >Why is it an error if a block name collides with a declaration name ??

    First of all, this is consistent with everything similar in Verilog.
    You cannot declare an object with the same name as a named behavioral
    sequential or parallel block, or a module instance, in the same scope.
    For example, it is illegal to declare

    reg a;
    initial
    for (i=1; i < 0; i=i+1) begin : a
    end

    which differs from your example only in being a named sequential block
    rather than a named generate block.

    It is much simpler for implementation, and avoids user confusion, if
    there can only be one declaration of a name in a given scope.

    In addition, I believe that there are situations where an actual
    ambiguity could arise if these were allowed to have the same name.
    There are some system tasks which will accept names of objects or
    names of scopes as arguments, such as $dumpvars. If you allowed them
    to have the same name, you couldn't tell which was intended. I think
    that PLI routines like vpi_handle_by_name would also have problems if
    names were not unique.

    This would become much worse if any of the proposals for struct data
    types are approved. If you allow a generate block named b in the same
    scope as a struct variable b, how could you distinguish whether b.c was
    a reference to the variable c declared in generate block b, or a reference
    to field c in the struct variable b? It would be impossible to tell.

    >2. I think the proposed 12.4.3 for generating names is not very
    >intuitive. Instead, why dont we make the naming of a generated block
    >mandatory ?? I believe that a designer might find it easy to track
    >generated logic if it is based on his names than based on a global count
    >and all the associated name collusion avoidance issues.
    >
    >What do you think ??

    I agree with you, and so did most of the group members who are implementers.

    However, many group members who are users did not agree. They felt that
    the extra typing required to put a name on all generated blocks was too
    much effort. Kurt Baty had the further issue that he has written some
    amount of Verilog-2001 code already, without block names, and did not want
    to have to change any of it. So this approach of allowing you to leave off
    the block names, and requiring it only if you want to make hierarchical
    references through the block, was agreed upon as a compromise.

    I think that the response to your concern would be that if a designer
    agrees with you, they have the option of putting names on all their blocks.
    Some companies might adopt that as a style guideline, if they run into
    problems with this.

    The block names on for-generates were mandatory in the balloted LRM.
    However, once you have allowed them to be left off of conditional generate
    blocks, with the compiler generating scopes and names for them, it is more
    consistent to allow the same thing on for-generates also. Consistency is
    a good thing. It should also please those who want to reduce typing.

    The task force considered not specifying what the standard generated
    names should be, leaving that implementation-specific. However, that could
    create incompatibilities between tools, such as making it hard to compare
    VCD dumps from two different simulators. We also considered going the
    other direction and allowing these names to be used in hierarchical
    references inside the design. However, that is dangerous, since changes
    to the module could unintentionally change the hierarchical name of objects.
    This might not even be apparent, since the name might resolve to a different
    object that now matches the name (possibly one in a different module, found
    via an upward name resolution).

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Fri Jan 09 2004 - 16:48:56 PST and
    sponsored by Boyd Technology, Inc.