From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Tue Feb 23 1999 - 12:03:46 PST
BAD MSG:
Hi Cliff,
-Lines: 246
Content-Type: text/plain; charset="us-ascii"
Content-Length: 10006
X-Status: $$$$
X-UID: 0000000838
Status: RO
I've interspersed your requirements list with specifics of our
configuration proposal that address them. As always, comments and questions
are welcome.
-t
At 12:48 PM 2/22/99 -0800, you wrote:
>What goals do we want to accomplish with configurations?
>
>There is some redundancy in this list but I did not want to filter ideas.
>
>1) Simple library usage.
>User provides only part of a design and a collection of files containing
>modules that may be needed in the simulation. This works ok with
>-y,-v,+libext.
Old: -y lib1 +libext+.v -v lib2.v
New: (lib.map) library lib1 "./lib1/*.v";
library lib2 "./lib2.v";
>
>2) Add a configuration capability to directly replace the -v, -y and
>+libext switches (Cliff)
Old: -y lib1 +libext+.v -v lib2.v // order-dependent search
New: (config) default liblist lib1 lib2;
>
>3) Define named libraries that can be referenced. (Adam)
>Make the library mechanism automatically update out-of-date libraries,
>similar to Makefiles. For compiled-code simulators, the compiled library
>modification date would be compared to the source file modification dates
>that are called for the library. If updating is required, compile the
>appropriate files; otherwise use the existing compiled library (Cliff)
>The connotations of -y, -v contain too many problems (Adam)
This is handled by the source-to-library mapping in the lib.map file. I
disagree that we should standardize on a tool behavior of automatically
updating libraries. While this may be desirable in most cases, we should
not preclude the ability of the user to not do this. I expect that this
will be a tool-specific issue, with the tool automatically updating by
default, but implementing a +noupdate switch or something like that.
>
>4) Inheritance
>A design and its sub-instances should have the ability to inherit the same
>libraries that were used for specific instances.
This is built into the syntax of configs. A liblist specified for a
particular instance using the cell, inst and path selection clauses is
automatically inherited down the hierarchy until a new liblist is
specified. This is also handled by the hierarchical use of configs using
the binding clause.
path top.a1.foo liblist lib1 lib2;
allows all subinstances of foo to get the liblist lib1 lib2.
path top.a1.foo binding foo_cfg;
uses the preconfigured foo_cfg to represent top.a1.foo and all of its
subinstances.
>
>5) Ability to easily specify the library search order (Adam)
>Should have the ability to change the search order for different sub-blocks
>of a design.
Again, this is built into the syntax of configs.
path top.a1.foo liblist lib1 lib2; // looks in lib1 first, then lib2
path top.a1.bar liblist lib2 lib1; // looks in lib2 first, then lib1
path top.a1.bar.b1 liblist lib3 lib4; // lib3 first, then lib4
>
>6) Document the default library resolution priority
>Specify what the default search order is and what constitutes a search
>order syntax error.
Libraries are always searched in the order specified. Searching for each
new module always starts at the beginning of the list. This eliminates the
worry about +liborder +librescan, etc.
>
>7) Module name collisions.
>User needs two versions of the same module. We need a better solution than
>the `uselib hack.
Lets try to avoid the term "version", as that tends to imply revision
control. We prefer the term "representation" or "abstraction". Suppose we
have two representations - gate and RTL. This is where views come in handy:
path top.a1.foo viewlist gate;
path top.a2.foo viewlist rtl;
>Ability to run a system simulation with multiple ASIC libraries that have
>same-named modules (Mac)
path top.a1 liblist vendorlib1;
path top.a2 liblist vendorlib2;
>Ability to fill model requirements from one library and still pick up
>missing models from another library (Mac) (falls under search order above?)
path top.a1 liblist vendorlib1 otherlib;
path top.a2 liblist vendorlib2 otherlib;
All subinstances of top.a1 will first be looked for in vendorlib1. Any
modules not found there will be searched for in otherlib. If not found in
otherlib, it's an error. Similarly for top.a2 and vendorlib2.
>
>8) Top level modules.
>User specifies names of top-level modules and the compiler searches for
>them in the specified libraries. [Currently only top-level filename
>specification is possible.] (Adam Krolnik)
This is what the design statement does.
config foo;
design worklib.top:rtl;
<rest of config>
endconfig
By specifying just the file containing the config foo, we automatically get
the rtl view of top as our top-level module, configured as specified.
Alternatively, if the tool precompiles things, then you would really only
need to pass the compiled configuration to the simulator as
worklib.foo:config.
Using this capability, along with hierarchical configs, makes it real easy
to go from simulation to synthesis. If I use one configuration for my
testbench, which hierarchically uses a separate config for my DUT,
config test1;
design worklib.test1:rtl;
default liblist lib1 lib2;
cell DUT binding worklib.dut:config;
endconfig
Then when it's time to synthesize, I can simply pass the worklib.dut:config
to the synthesis tool and I'm guaranteed to synthesize what I simulated!
(Of course, you do have to make sure that there are no defparams in test1
that affect parameters in the dut, but that's a workable issue).
NOTE: While it is possible to specify multiple top-level modules in a
design statement, it shall be an error if a config with multiple top-level
modules is used hierarchically, since a config may be bound only to an
instance of a module. You can't bind the mulitple top-levels in the
sub-config to the single instance in the top config.
>
>9) Easy way to incorporate released designs and updated designs. (James
>Markovitch)
If I change my design, and specify a new config for it, like
worklib.dut_released:config, then I simply modify my test config as follows:
config test1_with_released_dut;
design worklib.test1:rtl;
default liblist lib1 lib2;
cell DUT binding worklib.dut_released:config;
endconfig
>
>10) Prefer to have revision control separate from the Verilog language. Do
>not burden Verilog with revision control (James Markovitch)
I couldn't agree more.
>
>11) Different levels of debugging capability is desirable (James Markovitch)
This is especially where views make a difference. This actually falls most
naturally into the separate-compile use-model, where I can compile my
module several times with different options:
compile foo.v
compile foo.v +debug
compile foo.v +delay_mode_zero
etc.
Then, with these in different views from my lib.map file
library lib1 "foo.v";
view rtl "foo.v";
view debug "*.v" arg +debug;
view nodly "*.v" arg +delay_mode_zero
I can choose the different views for specific instances of module foo:
default liblist lib1
path top.a1.foo viewlist rtl;
path top.a2.foo viewlist debug;
path top.a3.foo viewlist nodly;
This method can also work for the "single-pass" use model as well, but it
requires the parser/compiler to be a bit more intelligent. It does require
the set of source files, including the configuration file, to be provided
on the command line (and this is in no way incompatible with -y/-v for
specifying groups of modules which may or may not be compiled, but it does
enforce the more rigorous search rules).
1) When the parser/compiler encounters instance top.a1.foo, it uses the
liblist and viewlist to determine that it needs the lib1.foo:rtl cell.
2) Using the lib.map file, it resolves that lib1.foo:rtl comes from file
foo.v (with default options), and invokes the compiler as: "compile foo.v"
3) When it encounters instance top.a2.foo, it uses the liblist and viewlist
to determine that it needs lib1.foo:debug.
4) Using the lib.map file, it resolves that lib1.foo:debug comes from file
foo.v, compiled with the +debug command-line argument set, so it invokes:
"compile foo.v +debug"
5) The same is done for the top.a3.foo instance.
This is how the library mapping supports both use models. In the precompile
use model, it's up to the user to compile the source with the right command
line options to produce the views he needs, and then the simulator only
needs the top-level compiled module to know how to get everything else out
of the library. In the single-pass use-model, the user provides all of the
files, and the tool must determine from the library and view specifications
what the compile-time environment must be to produce the required view(s).
>
>12) Consolidate libraries into one place (James Markovitch)
All libraries are listed in the lib.map file. Using the include statement
in a lib.map file allows you to use vendor-supplied or company-wide lib.map
files that are associated with a particular library.
include "/vendors/vendor1/lib.map";
All relative paths in the vendor's lib.map file are relative to
"/vendors/vendor1/" (which is what I meant in the draft 2 proposal, but
apparently it wasn't clear enough), so the vendor library is easily
transportable.
>
>13) Not excited about adding features to support anticipated future
>capabilities (Mac)
>Only put in what is really required today (Anders)
What do you think of the simulation-to-synthesis flow described in point
(8) above? This is exactly the type of flow that we envision for passing
this data around to other tools as well.
>Don't put in anything that would inhibit Cadence future enhancement
>features (Anders)
Thanks!
>
>14) Include clear usage examples with whatever is standardized (Alex)
I think we're making progress on this one, but we still have some ways to go.
---------------
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:26 PDT
and
sponsored by Boyd Technology, Inc.