From: Steven Sharp (firstname.lastname@example.org)
Date: Tue Apr 19 2005 - 18:04:13 PDT
Adam Krolnik wrote:
>Since most files are distinguished by suffix rules, rather than command line
>why not include a note suggesting suffixes for library map files and
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
>configuration block can be compiled (in a tool that is not a separate
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,
>a suggested option for selecting and using a specific configuration name. That
>all the configuration files can be in one file and a specific one chosen for a
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
>files an error? Nobody on the BTF specified this and this was done as part of
>editorial work on the document. If this is an error, I would support not being
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.
This archive was generated by hypermail 2.1.4
: Tue Apr 19 2005 - 17:41:13 PDT
sponsored by Boyd Technology, Inc.