From: Adam Krolnik (adamk@cyrix.com)
Date: Tue May 26 1998 - 20:24:57 PDT
Good morning:
I would like to note another problem (or a variation on this theme)
that I hope this enhancement would cover.
The problem is is basically the global namespace of modules.
This is a problem when importing foreign code, or code from a
different project.
Consider a simple (common) name for a module and two code sets
each having a module with that name. The problem them becomes
how do I specify that one code set use their module, and
another code set it's own. Another variation is having a set of
code that uses an older library that has names in common with
a newer library. The problem is how to specify the old library
for the old code, and the new library for the new code.
Of course, you can change the name of one of the modules and the
instantiation point. You can also do this for the problem described
below, but people are interested in solving the problem below with
a more robust way.
Maybe one way to consider this is to be able to specify how to build a module
(by specifying the source, modules and libraries to choose from) that doesn't
globally describe how to build other modules. I.e. a file to
build one or more modules with a specific description.
E.g.
old_module_list
---------------
<file1>
<file2>
<file3>
-y <libdir1>
-y <libdir2>
-v <libfile1>
ystem_list
-----------------
<nfile1>
<nfile2>
-y <libdirA>
-y <libdirB>
-y <libdirC>
-incdir <includedir>
// Ignore all previous settings and load the old module code.
-L old_module_list
<p>I feel that the amount of work left on this enhancement will preclude it from
making it into the June 8th deadline.
Adam
Begin forwarded message:
Date: Fri, 2 May 1997 07:32:39 -0700 (PDT)
To: 1364core@galaxy.nsc.com (IEEE-1364 Core Group Reflector)
From: cliffc@europa.com (Clifford E. Cummings)
Subject: Subject: BTF - B05 - Verilog Configuration Capability
Subject: BTF - B05 - Verilog Configuration Capability
Behavioral Task Force - Enhancement Request
Assigned Enhancement Request Number: B05
Enhancement Name (Description): Verilog Configuration Capability
Date Submitted: 960227
Requestor: IVC96 (Cliff Cummings)
Status: RO
Is enhancement intended to be synthesizable?: No
To improve Verilog testing capability
Abstract: What Are Configurations? A configuration file describes which
modules (source files) will be used during simulation.
Configurations can contain:
- all behavioral models
- all gate-level (structural) models
-a mix of behavioral and structural models
Different configuration files are used to increase testing productivity
by allowing slower gate-level models to be simulated with faster
behavioral models in a larger design; thereby improving simulation
efficiency.
One example of mixing gate and behavioral instances in the same design
is instantiating four identical adders into a model, 3 behavioral
adders, 1 gate-level adder.
The Cadence approach (not in the IEEE-1364 Standard)is the inclusion of
`uselib compiler directives in the source code, which requires multiple
source files for multiple configurations. I believe this is an
undesirable solution.
Possible proposals: The VSG may need to standardize some command
switches, including:
-f to call command files and source listing files
-y to specify library directories
+libext+.v to specify file extensions
-v to specify library files
Similarly, we may want to add command-line switches for configuration
purposes? These could be placed in a separate <configuration>.f file by
Verilog users?
+uselib+<source_directory_or_file>[+<optional_libext>]=<instance_name>[+
<instance_name>]*
+uselib+/proj/gates/adder.v=i2
+uselib+/proj/vlog+libext+.v+.p=i1+i3+i4
The above syntax still needs help! We should be seeking for a
simple/consistent syntax to address this issue. We should avoid a
complex VHDL-like solution to configurations.
I have had many Verilog students ask if environmental variables could be
used in .f files. I believe it is a good idea (except for PC-Verilog
compatibility?)
//********************************************************************//
// Cliff Cummings E-mail: cliffc@europa.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 //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:53 PDT
and
sponsored by Boyd Technology, Inc.