From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Wed Dec 09 1998 - 10:53:30 PST
The purpose of this e-mail is to summarize key configuration points and
differences made by Cliff Cummings (Sunburst Design), Tom Fitzpatrick
(Cadence) and Jay Lawrence (Cadence).
Anyone who would like to be on the Behavioral Task Force (BTF) e-mail list
may send an e-mail message to majordomo@boyd.com and include in the body of
the message: subscribe btf <user's e-mail>
Statement of problem (quick summary): Verilog users currently use -f, -y,
-v, +libext, etc. to build Verilog configurations files (command files).
One major limitation of these switches is that one currently cannot
instantiate multiple copies of the same model into a design and simulate
some instances from one module (example: RTL code) and other instances from
another module (example: gate-level model) unless `uselib switches are
added to the top-level source code or the gate-level module name is
changed, also requiring modification to the top-level source code.
Original enhancement purpose:
(P1) Add capabilities to solve the above problem
(P2) Standardize a subset of commonly used command switches (-f, -y, -v,
+libext, etc.)
Additional capabilities that have been requested for this enhancement:
(P3) Enhance configuration capabilities to include the concept of common
libraries for compiled simulation
(P4) Make configuration enhancements compatible with VHDL configuration
capabilities.
Points of discussion include:
==========
1 - Current command line switches probably would not be included in the
IEEE specification. Acknowledged: almost all vendors already use the same
-f, -y, -v, +libext, etc. that we have all come to know and love, but a new
(and hopefully superior) configuration standard would eventually become
widespread and at some point in the distant future, vendors might choose to
drop support for -f, -y, etc. (i.e. - don't burden the standard language
with unintuitive command line switches such as -v)
Summary: we were doing away with enhancement proposal P2 in favor of some
form of configuration file(s)
Update from conference call of 11/02/1998:
I believe we agree that standardize some of the better command line
switches such as the -f switch for command files would be beneficial to
Verilog users. The switch +define+<macro>="<parameter>" might also be a
good candidate for standardization.
I believe we agree that the library-type command line switches, -y, -v,
+libext, etc., would not be standardized. We did not want to burden Verilog
with these switches.
==========
2 - Should configurations permit the mapping of Verilog instances to
specific Verilog source code files located somewhere in the file system?
Currently: Verilog command line switches do this.
Currently: VHDL does not do this.
Editorial opinion from Cliff Cummings: Having done design work with both
languages, I found this to be a feature I liked about Verilog and missed in
VHDL. I believe most BTF members that are Verilog users strongly desire
this feature.
Cadence Position: The mapping of modules to source files should be included
in the library declaration (whatever form that takes) and not in the
configuration declaration itself. In the simple form where no configuration
is really needed, simply declaring the libraries and establishing a
set of rules for pulling things out of libraries would be sufficient.
Cliff's Position: I currently would like to see this capability permitted
in both library and configuration declarations.
I believe one of the key sticking points with this proposal can be summed
up in an excerpt from Tom's e-mail dated 10/22/98:
>The major limitation is that it requires the actual source paths and file
>extensions to be embedded in the hdl text. This will cause many problems,
>including:
> differences in path syntax on UNIX vs. NT
> case sensitivity of filenames on UNIX vs. NT
> forces design files to be kept in the same relative position in the
> filesystem. Makes delivering/packaging designs very hard
>
>`uselib suffers from the above problems (and others) and we should learn
>our lesson and not repeat it. It is our opinion that the language should
>provide a mechanism whereby a library can be declared, and whereby a module
>or udp can be said to exist in a given library. The mechanism for
>specifying which source files comprise the library may be related to the
>second of these goals but should not be intertwined with the config syntax.
>
>One of the key functions of a configuration is the ability to specify
>uniquely the contents of a given design. By embedding filesystem paths in
>the syntax (particularly with the uselibfile and uselibdir directives), it
>makes it nearly impossible share configurations between users, let alone
>between users using different platforms.
>
>Keeping libraries fundamentally separate from configs also makes it easier
>for configs to be hierarchical, which we believe is a key requirement.
Cliff's comments on the above issues:
- I do not believe either differences in path syntax or case sensitivity of
filenames in UNIX vs. NT is a problem. I have been able to use my existing
Verilog command files with UNIX case sensitive paths on my PC because other
Verilog vendors have done the translation themselves.
- If we do permit file mapping, the relative position issue does exist.
In UNIX, design teams currently circumvent the problem by adding symbolic
links from the relative position to the absolute location. My
understanding is that NT does not support symbolic links.
Cadence comments on the above issues:
- The third issue listed is really the most important one as far as we're
concerned. As mentioned, it makes it extremely difficult to package a
design and transport it, because all of the files would need to remain in
the same relative position to each other. By separating the file paths into
library declarations and keeping configs file-system-independent, it makes
it much easier to package the design with the config.
Adam's idea of making the file paths relative to the location of the
library declaration file is a good one, and makes it easier to transport
designs.
ENVIRONMENTAL VARIABLES?: In the recent past, we discussed adding command
file support for environmental variables (a feature that many UNIX-based
Verilog users have desired to resolve relative file location problems
without having to create symbolic links). We discarded the idea because
environmental variables are handled differently on UNIX and NT systems, and
handled differently between different shells on UNIX.
Cadence opinion:
- We are neutral on the issue of environment variables.
PROPOSAL?: Perhaps we could take a Synopsys dc_shell-like approach to the
problem? Create a new compiler directive or function such as
"get_env_variable" that could be used in command files, library files and
configuration files (and modules??).
Usage (LSI_INSTALL_DIR is an environmental variable set by whatever file
system):
===
Compiler directive for:
`get_env_variable LSI_INSTALL_DIR ASICLIBDIR
...
uselibdir = `ASICLIBDIR/vlog:v+p++
// similar to -y <lsi_install_dir_path>/vlog +libext+.v+.p
Permitting capture of environmental variables might solve all relative file
system issues on any file system, UNIX or PC. This works great for Synopsys
dc_shell scripts
===
ASICLIBDIR = get_env_variable(LSI_INSTALL_DIR);
library srclib;
// similar to -y /<full path name to LSI install dir>/vlog +libext+.v+.p++
uselibdir = $ASICLIBDIR/vlog:v+p++ // .v .p (no extension)
endlibrary
==========
<p>>A problem that exists with configurations is the case where #(parameter
>redefinition) is used with a parameterized RTL model but the corresponding
>synthesized gate-level model no longer has parameters. How can we allow RTL
>models with parameters to recognize parameter redefinition, but permit
>gate-level models to ignore the rtl-parameter. Options:
>
>1. Ignore the problem and ask synthesis vendors to include parameter
>declarations in the gate-level model (would require synthesis to store
>parameters to be written into a gate-level model).
>
>2. Ignore the problem and force the user to use makefiles and scripts to
>add unused-parameter declarations into gate-level models prior to simulation.
>
>3. Specify that Verilog compilers would only issue warnings and not errors
>for missing parameters that are passed to a model. Could still cause
>problems with synthesis tools if the same top-level model were used to
>subsequently tie together compiled gate-level models.
>
>4. Add a construct to configuration files to specify which parameters are
>ignored for specific simulation runs (of gate-level models).
>
>
>Some of these ideas were started months ago and may either be incomplete or
>obsolete. I thought I would at least throw these ideas of the wall (the BTF
>reflector) and gather comments. - Cliff
==========
Verilog/VHDL configuration compatibility
Cliff's position:
Making configuration enhancements compatible with VHDL configuration
capabilities is a secondary goal. If VHDL-compatible enhancements add
complexity to Verilog, then I am much less likely to support this goal.
Cadence position:
We do not want to add unnecessary complexity to Verilog simply to achieve
compatability with VHDL, either, but being able to combine Verilog and VHDL
configurations is a useful goal for the significant number of our customers
who require mixed-language simulation (and other verification
methodologies). We believe it is important for the Verilog standard to
recognize the fact that Verilog is being used and will continue to be used
for more than just simulation.
==========
Adding Configuration Views
Cliff's position:
I believe views generally add unnecessary complexity to configurations. If
views are mostly transparent to the user, I am less likely to oppose them.
I would like to see Cadence's configuration files for the examples and
directory structure that I have already e-mailed, then I will pass
judgement on the complexity of views.
The only Cadence example that I believe would benefit from views, was the
example where the same models are compiled both with and without delays.
Being able to select the timing view of the compiled gate library does have
some advantage.
Cadence's position:
Thanks for the acknowledgement, Cliff 8-). The concept of
library/module/view is very similar to the VHDL concept of
library/entity/architecture, which we believe is one of the things that
makes VHDL useful. Particularly for compiled-code simulators, being able to
compile multiple views of a module is extremely handy, both as you're
developing a design and when it comes to regression runs. The example you
cite is only one example. I may also want to have a "debuggable" version of
a module where every node is visible and an optimized version which runs
faster. Once I've verified the module with the debug version, then I can
switch to the optimized version for the rest of my development and/or
regression simulations.
>From an implementation standpoint, it's a lot easier (i.e. faster) to find
a module in a library and then choose the view you want than it is to scan
multiple libraries for a particular module. We've also found it to be
easier conceptually for our users to have to worry about fewer libraries,
since the view is implicitly part of the library. Libraries have be
declared and managed.
Of course, for those folks who don't want to use views, they don't have to.
If you always use the default view, then it's completely transparent. But
for the users who want to use them, it's an extremely powerful tool and we
feel strongly that the standard should not limit itself to preclude this
capability.
==========
Additional Command Line Options
Cliff's position:
The original configuration enhancement that we proposed in December 1997
received a frigid reception from other members of the Verilog Standards
Group. For this reason, current proposals mostly avoid standardization of
command lines switches (with a few exceptions). For this reason, Cliff is
largely opposed to adding command line switches to support a configuration
proposal.
Cadence's position:
We agree.
==========
Cadence editorial comments:
The fundamental disagreement between the two proposals is in whether
configurations themselves should be separated from library declarations and
therefore from the file system. As you'll notice in Cliff's proposal, he
"blurs the line" between configs and libraries. We don't have any major
objections to Cliff's library proposal, which fits pretty nicely with
existing Verilog concepts of -y/-v etc. (it is left to the reader to
determine if this is really a good thing 8-)). We feel that this is an
acceptable method for specifying which source code descriptions go into
which libraries. I am working on a method for expanding this proposal to
include views, which we consider essential.
Once you've established the contents of your libraries, then it is no
longer necessary to maintain a filesystem-specific view of things. A more
symbolic view of the world (i.e. "mylib.foo" to refer to module foo in
library mylib) makes things more manageable and transportable, in our opinion.
<p><p>//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
---------------
Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc.
Cycle Simulation Products 270 Billerica Rd.
Logic Design and Verification Business Unit Chelmsford, MA 01824
x6438 (978)446-6438
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:02 PDT
and
sponsored by Boyd Technology, Inc.