From: Michael McNamara (mac@surefirev.com)
Date: Wed Jan 13 1999 - 13:58:57 PST
Tom Fitzpatrick writes:
> >I also am beginning to dislike the implicit reading of the file
> >lib.map. Is it too much to require specifying the library mapping
> >files as part of the command line or in a command file (-f file)?
>
> Yes, I think it is, because you are going to require the lib.map
> information every time you run the tool. This is information that will be
> set up once and referred to several times. Requiring lib.map to be
> specified on the command line is going to tick people off, particularly
> since the lib.map information is required before any verilog source is
> encountered.
I disagree; see below.
>
> By the way, I think this is a good time to explain our philosophy here.
> This will also address some of your concerns later in this note.
>
> The lib.map file contains mapping information, NOT command information. It
> is intended to accomodate both "single-verb" incovations, like Verilog-XL,
> and "multi-verb" (separate compile and simulate steps) incovations, like
> NC-Verilog. The lib/view mapping information in lib.map is intended to be
> applied when a module is parsed/compiled. The compiler goes through the set
> of files given on its command line and when it encounters a module
> declaration, it looks at the state of its world
>
> what file am I parsing?
> what directory am I in?
> what macros are defined? what are their values?
> what command line arguments were selected?
>
> It then takes this information and compares it to the view and library
> statements specified in lib.map. When it encounters a library statement
> that matches the current "state", then it places the compiled module into
> that library, otherwise it goes into the default work library. If a view
> statement matches the current "state", then the compiled module goes into
> the matching view, otherwise it goes into the default view. It doesn't
> matter if the compile happens separately, or if it happens when the module
> is encountered at bind-time.
>
> That's why this information is separated from the verilog source and why
> the information is required before any regular verilog is
> encountered.
X-Lines: 59
Content-Type: text/plain; charset="us-ascii"
Content-Length: 2463
X-Status: $$$$
X-UID: 0000000798
Status: RO
None of these above issues require the file to be hidden, rather
than on the command line.
>
> By the way, since we've removed `view and `library from lib.map, we could
> now add them back in as regular compiler directives:
> `view <name>
> `library <name>
>
> These could be used to override any lib.map information and force the
> compilation of the following module into the specified library/view. This
> is your standard double-edged sword that could cut you badly with things
> like cross-file inheritance. We can discuss this more on Friday.
What if the lib.map file changes between compilation and run?
<p>I strongly dislike hidden files.
I strongly endorse a command line/ file.f way of specifing the map
file. Environment variables are horrible! Shared libraries are even
worse! (a few reasons are given below:)
1) Real users never specify command line arguments when they run a
verilog tool. Instead, Real users create a shell script, or a
file.f and use that. It's just compiler developers that have so
few source files that casually using the command line is common.
2) Introducing a hidden file makes tracking down a bug encountered in
one users environment from another environment very
difficult. Perhaps the hidden file is subtly different in the two
environments...
3) Introducing a hidden file makes setting up regression runs very
difficult.
4) Introducing a hidden file makes it difficult to simultaneously
run two tests in one directory (perhaps on different machines) that
require differences in the hidden file.
5) Having a hidden file that is accessed at 'uncontrolled' times makes
maintenence of the file difficult. If you edit the hidden file
after the first pass of NC, but before the second pass, things will
be difficult to keep in sync.
6) if the lib.map file is shared amongst the whole project, then things
get even worse. If the CAD manager changes the lib.map file to
reflect a new vendor library, then any running simulations or
regressions are suspect. (this is why I detest shared libraries)
<p>
--
/\ Michael McNamara <mac@surefirev.com>
/\// SureFire Verification Inc. 408-374-4100 x 100
/\///\ <http://www.surefirev.com> 408-374-4174 FAX
_\///\/ Formerly Silicon Sorcery
\//\/ Get my verilog emacs mode from
\/ <http://www.surefirev.com/verilog-mode.html>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.