Re: Configurations issues and questions

From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Fri Mar 07 2003 - 16:22:39 PST

  • Next message: Karen Pieper: "ETF issue to vote on closing 3/14/03"

    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 : Fri Mar 07 2003 - 16:23:54 PST and
    sponsored by Boyd Technology, Inc.