Re: Proposal for ETF erratum 350

From: Steven Sharp (sharp@cadence.com)
Date: Tue Apr 19 2005 - 18:04:13 PDT

  • Next message: Shalom.Bresticker@freescale.com: "RE: FW: New Mantis Issue #667 for V-1364"

    Adam Krolnik wrote:
    >Since most files are distinguished by suffix rules, rather than command line
    options,
    >why not include a note suggesting suffixes for library map files and
    configuration files?

    I could do that. It might make sense to suggest that the default library
    map file be called "lib.map" as in the example in the section on library
    map files. Is there likely to be a need for multiple library map files
    that actually contain library mapping directives, to justify suggesting
    a ".map" suffix? The LRM seems to assume that you will use includes to
    deal with multiple map files. I assume that ".cfg" would be reasonable for
    config files. From what Neil said, there may already be tools that use a
    ".cfg" suffix, but I would not expect these to be fed directly in as
    source files to a Verilog compiler.

    >Also it would seem that suggesting command line options for configuration files
    >precludes a simulation reading multiple configuration files. Is this saying
    only one
    >configuration block can be compiled (in a tool that is not a separate
    compilation tool?)

    I don't see anything in the use of a command line option that would preclude
    reading multiple config files. For example, you might be allowed to specify
    the command line option multiple times on the same command line, with a
    different config file after each.

    Ultimately, this is up to individual tools. I was just asked to add an
    informative note to try to help get more compatibility.

    >Maybe instead of an option to specify configuration and library mapping files,
    one needs
    >a suggested option for selecting and using a specific configuration name. That
    way
    >all the configuration files can be in one file and a specific one chosen for a
    specific
    >simulation.

    I believe you can do this with some possible tool use-models. The tool can
    allow you to specify the top-level module or config to start elaborating
    from, and ignore any unused modules or configs in the source.

    >Does the BTF consider the inclusion of config and library file grammar into the
    verilog
    >files an error? Nobody on the BTF specified this and this was done as part of
    the
    >editorial work on the document. If this is an error, I would support not being
    bound by
    >its ramifications.

    Actually, the config and library file grammar was _not_ included in the
    Verilog file grammar. There are two separate grammars in Annex A, one
    for Verilog source files and the other for library map files. The grammar
    allows configs in library map files, and not in Verilog source files.

    So this proposal does not need to modify the BNF. It just clarifies the
    text to match what the BNF already says.

    > Also note that there is not much support and use of this feature
    >due to raised issues on its definition and implementation.

    Yes, that does seem to be the case. That is convenient at the moment,
    when there are these two incompatible interpretations of where configs
    can appear. However, once we settle this major issue, we should address
    those other issues too.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Tue Apr 19 2005 - 17:41:13 PDT and
    sponsored by Boyd Technology, Inc.