From: by way of Tom Fitzpatrick (tfitz@cadence.com)
Date: Fri Dec 11 1998 - 11:35:59 PST
BAD MSG:
Hi Everyone,
-Lines: 262
Content-Type: text/plain; charset="us-ascii"
Content-Length: 8858
X-Status: $$$$
X-UID: 0000000753
Status: RO
I apologize to the BTF members who've seen this before, but I wanted to get
this out to everyone before Monday's discussion.
<p>Before I get to specific examples, I'd like to talk a bit about the purpose
of configurations.
As we all know, verilog-XL is a "single-verb" tool. You invoke it by saying
%verilog <source_files>
where <source_files> is one or more verilog source files. Verilog would
always scan the entire source description for the design, which essentially
involved looking for the "module-endmodule" keywords in the specified
files. These files may also include library files and/or files within
library directories, but you're still just specifying a set of verilog
module source descriptions to simulate. The disadvantage is that you always
have to scan the entire design every time you simulate.
With the advent of compiled code simulators, this single-verb approach has
changed a bit. The tools can still be invoked using
%my_verilog <source_files>
but what happens "behind the scenes" is a little different. In a compiled
code simulator, you essentially need to perform two steps prior to
simulation. First, each source module must be compiled into some
intermediate form, and second the design must be elaborated, where each of
these compiled modules is connected and the executable code for the design
is generated. The simulator then just runs the executable code to perform
the simulation.
In either case, you perform the same two basic steps to assemble a design:
1) Find all modules available for binding in the current design
2) Go through the design hierarchically and bind instances to available
modules
Cliff's proposal closely couples the set of available modules for binding
to their physical location in the filesystem, while ours simply names the
components (using the lib.cell:view syntax) so that they can be referenced
independent of their physical location. We think this is a critical
differentiator and is a requirement for configs to be used to package
designs for portability from vendor to user, between design groups, and
across machines (unix vs. nt).
In our opinion, it doesn't really matter how you specify that a given
module description appears in a given library. The four proposed mechanisms
are:
1) `library directive embedded in the source code
2) External file using LIBRARY_MAP
3) Cliff's library-endlibrary mechanism
4) Command line option
%verilog +library+lib1 -y ./foo +library+lib2 -v bar.v
OR
%verilog -L lib1 -y ./foo -L lib2 -v bar.v
A quick look shows that choices 2 & 3 are essentially the same with the
exception of the "syntactic sugar" they use. Any and all of these are
acceptable, and the method for how to put something into a library could be
a healthy source of competition among vendors. It is essential, however,
that the method for specifying something once it's in a library be
standardized.
We also believe that the view capability will be essential to the effective
deployment of configurations, particularly in the area of flexibility, and
should be included in the standard. This could also be invoked in several
ways:
1) `view directive
2) external file using VIEW_MAP
3) Command line option
%verilog +library+lib1 +view+rtl +define+RTL -y ./foo
>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).
I don't particularly care for these commands. They appear only to be a
method for specifying file paths within the config, which we believe is
undesirable. The only benefit might be as an alternative invocation
mechanism where you invoke the tool on the configuration itself rather than
on the set of files. Since there is already a method for specifying the
files on the command line, this doesn't seem a whole lot more useful than
the -f option and has the disadvantage of being filesystem-dependent.
>All of the examples below are intended to give the same result:
>
>// 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 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
// Note that these library directives can be included
// in the source file with the config or can be
// in a separate file which gets `included
`library vlib file="/proj/vlog/adder.v"
`library glib file="/proj/gates/adder.v"
// OR use LIBRARY_MAP in a separate file
// LIBRARY_MAP = (
// /proj/vlog/ => vlib,
// /proj/gates/ => glib,
// * => work) // work is the default by default
config adders1;
default liblist vlib;
inst (work.top)i2 liblist glib;
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
config adders1a;
design work.tb:module;
default liblist vlib;
inst (vlib.top)i2 liblist glib;
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
We could configure the module top separately, and then reference this
config within the tb config:
config adders;
design vlib.top:module;
default liblist vlib; // Not necessary since we're already in vlib
inst (vlib.top)i2 liblist glib;
endconfig
config tb;
inst (work.tb)top binding vlib.adders:config;
endconfig
Then, if I wanted instead to configure top to use all rtl versions of adder,
config addersrtl;
design vlib.topLmodule;
default liblist vlib;
endconfig
config tb_rtl;
inst (work.tb)top binding vlib.addersrtl:config;
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
See my previous example.
>
>// 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
If we assume that the appropriate components are in asiclib1 and top is in
vlib (as before), this configuration would be:
config asic1;
design work.tb:module;
default liblist vlib;
cell vlib.top liblist vlib, asiclib1;
endconfig
Hmm. just noticed something else I find confusing with Cliff's proposal.
It's unclear whether the usedir and usefile commands apply to the instance
in which they appear, or to the subinstances of that instances.
Talk to you all on Monday at the conference call.
Thanks,
-Tom
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:02 PDT
and
sponsored by Boyd Technology, Inc.