From: Steven Sharp (email@example.com)
Date: Wed Apr 20 2005 - 20:39:22 PDT
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
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.
This archive was generated by hypermail 2.1.4
: Wed Apr 20 2005 - 20:16:12 PDT
sponsored by Boyd Technology, Inc.