Re: generate proposal

From: Steven Sharp (sharp@cadence.com)
Date: Tue Feb 17 2004 - 15:03:00 PST

  • Next message: Stefen Boyd: "Re: etf minutes"

    We still need to deal with the problems of how generates interact with
    defparams, which we discussed at the last ETF meeting. I would like
    to start by summarizing the problems. There are two separate problems
    here, though the solutions may be related.

    The first problem is that a generate construct could instantiate something
    containing a defparam which changes a parameter that affects what the
    generate construct should have done. The current LRM prevents that by
    forbidding a defparam in the hierarchy under a generate construct from
    affecting any parameter outside that generate construct. The new proposal
    has a restriction based on a specified elaboration order, which is less
    restrictive but more complex to understand. The extra situations that it
    allows do not seem useful. I have suggested going back to the earlier
    simpler restriction.

    The second problem is one that Gord pointed out more recently. Verilog
    allows upwards name referencing, searching upwards to find names. But
    with generates, what it finds first may change as things get generated.
    Most hierarchical references can just wait to be resolved at the end,
    after generates are done. But defparams cannot wait, since generates
    need the parameter values so they can decide what to do. Depending on
    the order of resolving defparams and expanding generates, different
    implementations could produce different results.

    The current LRM does nothing to deal with this second problem. The
    elaboration order specified by the new proposal standardizes the results,
    and requires consistency of the final results. This fixes the problem,
    but the resulting restriction is complex to understand. Shalom has
    expressed concern about that. Unfortunately, I don't see a reasonable
    alternative here.

    The upwards name referencing is the root of the problem, but that can't
    be eliminated without causing backward compatibility problems.

    A restriction that would avoid the problem would be to say that a
    defparam outside a generate construct would never be resolved to a
    parameter inside the hierarchy under a generate construct. (You cannot
    let it resolve and then call that an error, because that still leaves
    the same problem. One implementation could resolve it one way and
    produce an error, while another resolves it in an order that does not.)
    This would have a couple of problems.

    First, a name used in a defparam could resolve to a different object than
    the same name used for something else in the same scope. Preventing that
    would require a further restriction, complicating this solution.

    Second, this would prevent certain common usages of defparams. Designers
    will configure a design by putting their defparams into a top-level module.
    They would not be able to do this any longer for parts of the design under
    a generate. This seems like a pretty severe restriction. While many
    of us dislike defparams for the problems that they cause, we do have a
    responsibility to all of the users of the language, with their different
    design styles. From what Shalom has said about defparams in the past, he
    may not like this restriction.

    If someone can come up with a better solution, that would be great. But
    I really don't think that there is any. I think that the choices are:

    1. The solution in the proposal, which has a complex restriction, but
       one that probably won't affect real-world usages.
       
    2. The more severe restriction, which is simpler to describe, but
       eliminates valuable real-world usages.

    3. Say that the behavior is undefined (though describing the situation
       that is undefined is about as complicated as describing the solution
       in the proposal).

    4. Ignore the problem and hope nobody ever runs into it.

    I personally think that users will be served best by the solution in the
    new proposal.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Tue Feb 17 2004 - 14:48:38 PST and
    sponsored by Boyd Technology, Inc.