Re: Configurations issues and questions

From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Sat Mar 08 2003 - 22:25:01 PST

  • Next message: Shalom Bresticker: "issue 123"

    Precedence: bulk

    Shalom.Bresticker@motorola.com wrote:
    >
    > Precedence: bulk
    >
    > It looks to me like a sub-committee is indeed needed.

    That was my assumption based on the number of issues (on my first read).
    I haven't seen the comments from Cadence, so I don't know how much
    commonality of concern there is.

    Perhaps we should touch on this during Monday's meeting to decide
    how/when to deal with configurations.

    Gord.

    > (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
    > >
    > > 

    -- 
----------------------------------------------------------------------
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 - 22:26:07 PST and
    sponsored by Boyd Technology, Inc.