From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Sep 04 1998 - 08:18:34 PDT
BAD MSG:
(Y2K compliant date ;-)
-Lines: 336
Content-Type: text/plain; charset="us-ascii"
Content-Length: 13057
X-Status: $$$$
X-UID: 0000000632
Status: RO
Dear BTF -
In an effort to prove I am still alive and at least thinking about BTF
issues, below are some of my current thoughts on B05 - Verilog Configurations.
Regards - Cliff
After the last IEEE VSG meeting, the BTF, at Maq's coercing, decided to
again address one of the Verilog top-5 enhancement issues. Configurations.
General thoughts that were shared:
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)
2 - Although the Cadence e-mail on configurations includes many good ideas
about implementing configurations, there is not too much enthusiasm for the
concept of "views". The main objections are two-fold:
(a) Views add a level of abstraction that can be confusing. The same
capabilities can be accomplished by creating separate libraries instead of
views to a single library. We don't think that we will have a proliferation
of too many types of libraries by omitting views as suggested in e-mail
from Cadence.
(b) Adding views to a single library might actually be dangerous from a
design perspective. If an ASIC designer simulates a design with a library
that includes both behavioral and gate-model views, the engineer might
accidentally call a combination of both when he/she thought that only
gate-level models were being used, causing a potentially flawed and costly
ASIC design to be approved for tape-out. This is less likely to happen if a
configuration only calls the gate-level library, which is separate from a
behavioral-model library.
3 - Separate Configuration keywords and separate library keywords do appear
to be favored, as opposed to requiring library declarations to be included
within every configuration. This way a library can be compiled separately
and called by multiple configuration files.
4 - If everyone agrees that using "config" instead of "configuration" makes
it easier for EDA vendors to distinguish between Verilog and VHDL
configuration files in a co-simulation environment, I have no problem with
the abbreviated keyword. This was a very interesting point that was noted
by Cadence.
Take a peak at some of the rough ideas below.
Regards - Cliff
<p>One 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).
<p>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
A library_source shall include one or more library declarations.
Verilog comments are permitted in a library file.
A library source description contains one or more library declarations used
to compile libraries for use within a configuration source description.
library_source ::= library library_identifier { library_item } endlibrary
A configuration_source shall include at least one library declaration or at
least one instance declaration.
Verilog comments are permitted in a configuration file.
A configuration file that contains one or more library declarations and no
instance declarations is used to compile libraries for use by other
configurations.
A configuration source file that contains one or more instance declarations
and no library declarations shall only use the following instance items: ...
configuration_source ::= config config_identifier { config_item } endconfig
config_item ::=
lib_declaration {lib_declaration } { instance_declaration }
| {lib_declaration } instance_declaration { instance_declaration }
Configuration files can specify libraries to either be compiled or
interpreted (depending on the whether the Verilog tool compiles and uses or
reads and interprets the design modules) using the library-endlibrary
keywords.
All Verilog files or modules listed between the library-endlibrary keywords
will be compiled into a library identified by the user-selected
library-identifier (lib_identifier).
The libfile command is used to specify a file containing one or more
modules to be compiled. If a user chooses to only compile one module from a
library file that contains multiple modules, the libfile directive can
specify a dot-separated file.module (file_identifier.module_identifier)
pair to be compiled. Multiple libfile directives can be used to specify
additional file.module pairs to be compiled from the same file. It is
legal, although redundant, to use libfile directives to specify both an
entire file using a libfile directive and file.module pairs from the same
file. libfile
lib_declaration ::= library lib_identifier { lib_item } endlibrary
instance_declaration ::=
instance hierarchical_identifier { instance_item } endinstance
lib_item ::=
libfile = file_identifier [ : module_identifier
{ + module_identifier } ] ;
| libdir = directory_identifier [ : file_ext { + file_ext } ] ;
instance_item ::=
uselib lib_identifier ;
|uselibfile file_identifier ;
|uselibdir directory_ identifier [ : file_ext { + file_ext } ] ;
|uselibcell lib_identifier ;
|defparam list_of_param_assignments ;
The uselib statement specifies which library will be used for the specified
instance.
The usefile, uselibdir and uselibfile directives assume that no library
will be created from the sources used for the specified instance. Whether
or not this is desirable is debatable. Or perhaps an implied library with
the hierarchical instance name is created (which might be both easy and
very desirable).
The defparam statement would be useful when instantiating a module from two
different libraries with different parameters.
All of the examples below are intended to give the same result:
config adders1
instance top.i2
uselibfile /proj/gates/adder.v
endinstance
instance top.i1
uselibfile /proj/vlog/adder.v
endinstance
instance top.i3
uselibfile /proj/vlog/adder.v
endinstance
instance top.i4
uselibfile /proj/vlog/adder.v
endinstance
endconfig
uselib lib_identifier ;
|uselibfile file_identifier ;
|uselibdir directory_ identifier [ : file_ext { + file_ext } ] ;
|uselibcell lib_identifier ;
// Default implied configuration for designs that are run
// without a configuration file
config work
uselibdir . // read a Verilog source file from the current directory
endconfig
// Design Scenario #1a (replace with LRM example #)
// testbench tb
// top instance tb.top
// adder instance tb.top.i2 using the /proj/gates/adder.v file
// adder instances tb.top.i1, tb.top.i3, tb.top.i4 using
// the /proj/vlog/adder.v file
//
config adders1a;
instance tb;
uselibfile /proj/tb/tb.v;
endinstance
instance tb.top;
uselibfile /proj/vlog/top.v;
endinstance
instance tb.top.i2;
uselibfile /proj/gates/adder.v;
endinstance
instance tb.top.i1;
uselibfile /proj/vlog/adder.v;
endinstance
instance tb.top.i3;
uselibfile /proj/vlog/adder.v;
endinstance
instance tb.top.i4;
uselibfile /proj/vlog/adder.v;
endinstance
endconfig
// Design Scenario #1b (replace with LRM example #)
// Same as above, except this time declaring the
// adder instances tb.top.i1, tb.top.i3, tb.top.i4 using
// only one instance declaration
//
config adders1b;
instance tb;
uselibfile /proj/tb/tb.v;
endinstance
instance tb.top;
uselibfile /proj/vlog/top.v;
endinstance
instance tb.top.i2;
uselibfile /proj/gates/adder.v;
endinstance
instance tb.top.i1, tb.top.i3, tb.top.i4;
uselibfile /proj/vlog/adder.v;
endinstance
endconfig
// Design Scenario #1c (replace with LRM example #)
// Same as above, except this time declaring the
// adder instances tb.top.i1, tb.top.i3, tb.top.i4 using
// only one instance declaration
//
config adders1c;
instance tb;
uselibfile /proj/tb/tb.v;
uselibdir /proj/vlog:.v
instance tb.top.i2;
uselibfile /proj/gates/adder.v;
endinstance
endinstance
endconfig
// ASIC Design Scenario #1c (replace with LRM example #)
// Create a library called asiclib1; Same as above, except this time
declaring the
// adder instances tb.top.i1, tb.top.i3, tb.top.i4 using
// only one instance declaration
//
library asiclib1;
// only include modules dsp1, dsp2, dsp3 in the compiled library
libfile = /home/asic1_install/core/ver/dsps.v:dsp1+dsp2+dsp3;
libdir = /home/asic1_install/lib/ver:v;
libdir = /home/asic1_install/io/ver:v
endlibrary
config asic1;
instance tb;
usefile /proj/tb/tb.v
instance tb.top;
// top-level model and first-level hierarchical blocks are
// located in the /proj/vlog directory. All other library
// primitives were compiled into the asiclib1 library.
usedir /proj/vlog:.v
uselib asiclib1;
endinstance
endinstance
endconfig
library fpgalib1;
// FPGA vendor #1 supplies a set of Verilog UDPs (User Defined Primitives)
// in a single file in the prim subdirectory. The rest of the Verilog
// gate-level models are located in the ver subdirectory.
libfile = /home/fpga1_install/prim/udp_primitives.v;
libdir = /home/fpga1_install/ver:v;
endlibrary
library fpgalib2;
// FPGA vendor #2 supplies of the Verilog gate-level models in the src
// subdirectory. All gate-level file names match the corresponding module
// name for each primitive and include a ".v" extension
libdir = /home/fpga2_install/src:v;
endlibrary
library srclib1;
// A vendor of source-level models for logic chips has supplied a
// subdirectory of models, some with a .v extension, some with
// a .p extension and some with no extension
libdir = /home/src1_dir:v+p++; // .v .p (no extension)
endlibrary
library srclib2;
// A second vendor of source-level models for logic chips has supplied
// a subdirectory of models, some with a .v and some with no extension
libdir = /home/src2_dir:v; // .v
libdir = /home/src2_dir; // (no extension)
endlibrary
library srclib3;
// A third vendor of a multi-module model has supplied a set of files to
// model the complex funtionality of a bus functional model but the file
// names do not match the module names. These files are listed individually
// into a separate library file to permit the entire set of collection of
// files to be compiled separately and accessed by one library call.
libfile = /home/src3_dir/top1_v1; // top1 module instantiates blk1 and blk2
libfile = /home/src3_dir/blk1_v1; // blk1 module instantiates sub1 and sub2
libfile = /home/src3_dir/blk2_v1; // blk2 module instantiates sub3 and sub4
libfile = /home/src3_dir/sub1_v1a; // version 1a
libfile = /home/src3_dir/sub2_v1; // version 1
libfile = /home/src3_dir/sub3_v1; // version 1
libfile = /home/src3_dir/sub4_v3; // version 3
endlibrary
config asic1;
instance tb;
usefile /proj/tb/tb.v
instance tb.top;
// top-level model and first-level hierarchical blocks are
// located in the /proj/vlog directory. All other library
// primitives were compiled into the asiclib1 library.
usedir /proj/vlog:.v
uselib asiclib1;
endinstance
endinstance
endconfig
<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 //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:59 PDT
and
sponsored by Boyd Technology, Inc.