Re: generate proposal

From: Jason Woolf (jasonw@cadence.com)
Date: Tue Feb 03 2004 - 13:23:04 PST

  • Next message: Steven Sharp: "re: generate proposal"

    > I believe that Jason has a problem with that formulation because it would
    > be more difficult and possibly inefficient to implement a strict check for
    > it in tools.

    Not really, Steve. My concern is for the language, and whether we are
    making a rule more restrictive than it has to be based only on how hard it
    is to describe. However, the more I think about it (and I delayed my response
    so that I had some time to do so), the more I think it is a good formulation.

    As I see it, there are two extremes: one is to use this formulation which puts
    a aggressive restriction on defparams to prevent paradoxes and ambiguities, and
    the other is to remove the restriction altogether and allow an implementation to
    deal with them however it wants. What I have done in my proposal is something
    in between, which relaxes the restriction somewhat and then forces an
    implementation to resolve ambiguities in a certain way. If Section 12.8 were
    to be accepted in principal (the "phased" approach to elaboration, a
    bredth-first algorithm for expanding a hierarchy with generates) then to
    describe a relaxed defparam restriction using this model seemed reasonable.
    But perhaps for a restriction that users do need to comprehend, it is not so
    reasonable.

    The main reason for Section 12.8 was the problem discussed in the second
    half of the section, where the hierarchical name in a defparam has to be
    resolved before the heirarchy is done expanding (see example at the end
    of the section). So, with that in mind, do we feel it is acceptable to have
    the breadth-first algorithm described in the LRM?

    -Jason

    This archive was generated by hypermail 2.1.4 : Tue Feb 03 2004 - 13:09:38 PST and
    sponsored by Boyd Technology, Inc.