RE: [sv-bc] potential command line option

From: Steven Sharp (sharp@cadence.com)
Date: Wed Apr 20 2005 - 20:39:22 PDT

  • Next message: Brad Pierce: "Re: Configs Intent - was: potential command line option"

    Mark Hartoog wrote:
    >In the section on Hierarchical configurations the 1364-2001/1364-2005
    >LRMs say you can specify the following mapping:
    >
    >instance top.a1.foo use lib1.foo:config;
    >// bind to the config foo in library lib1
    >
    >This clearly implies that a config can be an "cell" in a library.

    I agree, and I consider this desirable. The current proposal allows
    this. The current proposal also attempts to be compatible with the
    existing 1364-2001 standard (both text and BNF). I ran into the issues
    that you raised, but found a way of resolving them within the text of
    the existing standard (though this may not have been the intended
    interpretation of the text).

    As you say, there needs to be a way of reading in configs from a
    source file (which does not need to be a normal Verilog source file).
    The text says that the parser shall read the library mapping information
    from a pre-defined file prior to reading any source files. However,
    it also says that a compliant tool shall provide a mechanism to
    specify one or more library mapping files, and that if multiple mapping
    files are specified, they shall be read in the order specified.

    This allows the possibility of a tool reading a pre-defined file first
    to get the mapping information, then reading more files containing
    configs (which are technically library map files, because they follow
    the library map syntax that allows configs, but are also considered
    source files). To reduce confusion, my proposal introduces the term
    config file for these.

    It would have been possible to introduce the config file as a new kind
    of file, rather than as a special case of a library map file that
    contains only configs. This would have been easier to follow. However,
    I was trying to write a proposal that was compatible with the existing
    text even if it required a bit of a strain.

    From this viewpoint, here are the answers to the questions you raise:

    >The BNF only allows configs in library mapping files. How would
    >you get the configs into a libraries? Would you name the library mapping
    >file in the wild card patterns so that its contents would be mapped
    >into the library also?

    You could name the multiple library map files (i.e. the config files)
    in the wild card patterns so that they would be mapped into the library.

    >In the section on libraries (13.2.1 in 1364-2001) it says "When parsing
    >a source description file (or files), the parser shall first read the
    >library mapping information from a pre-defined file prior to reading
    >any source files." This implies that library mapping files are NOT
    >source files.

    This implies that the pre-defined file is read first, but does not
    prevent reading more library map files (i.e. config files) that are
    source files. Whether the pre-defined file is considered to be a
    source file depends on whether you are willing to interpret that text
    as meaning "prior to reading any *other* source files".

    BTW, since configs are allowed in the pre-defined library map file,
    independent of whether they are allowed elsewhere, this question of
    whether the library mapping information applies to the pre-defined
    library map file itself has to be resolved regardless.

    >I think the 1364-2001 LRM is inconsistent about where configuration may
    >appear. Either it was an error in the BNF that configurations can not
    >appear in source files, or it was an error that configurations can be
    >cells that are in libraries.

    Or the source files that they can appear in are distinct from the ones
    that Verilog modules can appear in.

    >I think we should allow configurations in libraries, so I think we should
    >say it was an error in the BNF. I don't like the idea of creating two
    >classes of source files, normal verilog and config, but I suppose I can
    >live with that, if we have too.

    I think it is better than making 15% of existing Verilog designs illegal.

    BTW, Verilog already has multiple classes of source files, if you consider
    SDF to be a language.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Wed Apr 20 2005 - 20:16:07 PDT and
    sponsored by Boyd Technology, Inc.