Re: Configurations issues and questions

From: Shalom.Bresticker@motorola.com
Date: Sat Mar 08 2003 - 12:10:51 PST

  • Next message: Shalom.Bresticker@motorola.com: "Re: There were a few more..."

    Precedence: bulk

    It looks to me like a sub-committee is indeed needed.

    (I will NOT be on this one, I think. Configurations are not my strong point.
    On the other hand, Section 13 is so hard to understand, maybe I should be there
    to work on making it more readable...)

    If so, I would suggest that at the same time, the committee should look at the
    other issues that came up during balloting, mainly by Cadence.

    Shalom

    On Fri, 7 Mar 2003, Karen Pieper wrote:

    > Date: Fri, 07 Mar 2003 16:22:39 -0800
    > From: Karen Pieper <Karen.Pieper@synopsys.com>
    > To: Gordon Vreugdenhil <Gordon.Vreugdenhil@synopsys.com>, etf@boyd.com
    > Subject: Re: Configurations issues and questions
    >
    > Precedence: bulk
    >
    > Unless we are going to write exactly one proposal to cover this (do we want
    > a configurations
    > sub committee? ) I'd prefer to break it apart so that we can fix each
    > separately. How do you
    > think it needs to be worked on?
    >
    > K
    >
    > At 02:49 PM 3/7/03 -0800, Gordon Vreugdenhil wrote:
    > >Precedence: bulk
    > >
    > >The following is a fairly linear pass through Clause 13;
    > >I haven't really taken the time yet to fully consider
    > >all of the implications, but at least this is a start
    > >on the V2K issues that immediately came to mind. I don't know
    > >if we want to enter this as a single issue or burst it. Karen,
    > >what would you prefer?
    > >
    > >Gord.
    > >
    > >---------------
    > >
    > >
    > >Questions and Issues on Configurations
    > >
    > >1) 13.1.2 (and other places) talk about "the top-level module".
    > > This appears to likely be a VHDL-centric view being exposed,
    > > but we need to make sure that everything is clear about
    > > there being many top-level modules. More on this later.
    > >
    > >2) 13.1.2 and/or 13.3.1.3
    > > a) What if the specified instance name matches something
    > > other than an instance?
    > > b) What if there is no match?
    > > c) Can you configure one element of an instance array?
    > > What about an instance whose hierarchical name
    > > crosses an array instance hierarchy? What if the
    > > instance elements are irregular due to parameters
    > > and generate?
    > > d) Similar to (c), can you configure one element in
    > > the elaboration of a generate block?
    > >
    > >3) 13.2.1
    > > a) "..." has interesting issues such as (on Unix)
    > > whether symbolic links are followed. Also the
    > > definition says "hierarchical directories"; I
    > > assume that the intent there is "descendents"
    > > similar in intent to a Unix "find".
    > > b) Paths in library declarations should permit
    > > or require quoting.
    > > c) Path resolution could be interesting -- consider
    > > something like "./.../x/../y/*.v". There should
    > > probably be a restriction that "..." can only
    > > be followed by a single file name including only
    > > wildcards ? or *.
    > > d) I am not sure about basing searches on the location
    > > of the lib.map file. It may be better to allow
    > > a lib.map file to contain something like a
    > > basedir=path to root the searches.
    > > e) The whole issue of "work" an top modules is very
    > > fuzzy to me. Consider that "Any file
    > > encountered by the compiler which does not match
    > > any library's file_path specification shall by
    > > default be compiled into a library named work."
    > > Does that mean "Any file encountered while
    > > considering library map file expansion"? If not,
    > > are all modules in "work" considered to be top
    > > modules? 13.4.2 seems to support the latter
    > > interpretation, but that can't possibly be the
    > > intent. The statement in 13.2.1.1 that "all source
    > > files encountered by the parser/compiler can be
    > > mapped to a unique libaray" also supports this.
    > >
    > >4) 13.2.1.1
    > > Cell names within a lib must be unique since the LAST
    > > one wins. "work" is going to be very noisy in terms
    > > of required warnings for the "single invocation" model.
    > > Particularly given 3e above, the "single invocation"
    > > rule is unclear at best. The intent is clear but I
    > > don't know that I agree with the assumption that
    > > multiple cells compiled into the same lib are "likely"
    > > incorrect in a "single invocation" versus multiple.
    > > If the intent is to have a model for both separate
    > > and single compilation, let's have consistent rules
    > > so that the library state is predictable no matter
    > > what the tool does. This model is very "VHDLish"
    > > but without the dependency requirements, etc. which
    > > end up weakening the semantic integrity of the model.
    > > This also doesn't allow cell renaming in order to
    > > avoid conflicts without changing an entire config
    > > due to a library name change.
    > >
    > >5) 13.2.3
    > > "... the name of the source file being parsed is
    > > compared ...". How do 'line directives influence
    > > this? What about included source? This mapping
    > > (and much of the configurations model overall) appears
    > > to assume a rather tight cell<->file relationship
    > > with no complex file inclusions, etc. That isn't
    > > going to correspond to existing language features
    > > and methodologies very well.
    > >
    > >6) 13.3.1.1
    > > "There shall be one and only one design statement..."
    > > I assume that should read "...per configuration".
    > >
    > >7) 13.3 (in general)
    > > The text consistently uses the terms "expansion clause"
    > > and "selection clause". These terms need to be
    > > defined rather than implied.
    > >
    > >8) 13.3.1.3
    > > "The instance name ... is a Verilog hierarchical
    > > name starting at the top-level module of the config..."
    > > So such hierarchical names are strictly downwards and
    > > rooted in the topology at the point of the instance?
    > > Assumably such names may not be resolved upwards.
    > > Also, any such bindings must be deferred until
    > > post-generate elaboaration since instance name
    > > existence may be impacted.
    > >
    > > What happens if there are multiple matches for
    > > an instance clause? Error? Last one wins?
    > >
    > >9) 13.3.1.4
    > > If I am reading the term "expansion clause" correctly,
    > > it appears that a cell clause with a library name can
    > > only be used in a use clause. Is that correct?
    > >
    > >10) 13.3.2
    > > a) With the given instance clause, assume that the
    > > original instantiation of top.a1.foo was based on
    > > module "M". If top.a1.foo is the only instance of
    > > M, does M become a top module or does it "disappear"
    > > from the design space? What about the reverse, ie.
    > > if M would have been a top module, does creating an
    > > instance via binding make it non-top?
    > > b) Given that a config cannot "reach into" another
    > > configured sub-hierarchy, it appears that either
    > > all configs must be considered simultaneously or
    > > that sub-hierarchies must be marked as a "by
    > > configuration" sub-hierarchy in order to have the
    > > global invariant validated. This interacts with
    > > (8) above in that an explicit instance binding
    > > may exist and then have a binding via configuration.
    > > By 13.3.2, binding via config and then explicit
    > > binding would be an error. Is the reverse also
    > > true?
    > >
    > >11) 13.4.2 assumes that "top level modules" can be found
    > > during parsing. In the presence of generate that is
    > > no longer the case. 13.4.3 requires one to list all
    > > the top modules which is in conflict with the automatic
    > > determination that is done over all source currently.
    > >
    > >
    > >
    > >General Comment
    > >
    > >The existing text seems to me to be an attempt to apply
    > >some VHDL library and configuration ideas onto a more
    > >file-centric approach. The result doesn't appear to be
    > >a very clean model to me. It makes more sense to me
    > >to completely decouple the abstract library from the
    > >underlying file system and deal with design configuration
    > >solely at the "cell" level. Having a mix of design
    > >element configuration and file management configuration
    > >in one set of in-language functionality leads to issues
    > >that become very implementation sensitive which defeats
    > >the whole purpose.
    > >
    > >Gord.
    > >
    > >
    > >--
    > >----------------------------------------------------------------------
    > >Gord Vreugdenhil gvreugde@synopsys.com
    > >Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054
    > >Synopsys Inc., Beaverton OR
    >
    >

    This archive was generated by hypermail 2.1.4 : Sat Mar 08 2003 - 12:12:47 PST and
    sponsored by Boyd Technology, Inc.